Re: Action item from yesterday's meeting

Folks,

This is the last outstanding item to be closed for the Midcom MIB design team.
I belive, all other items have a closure, as of now. Below is the problem
description and a proposed fix. Please review and let us know if you see any
issues with the proposal. Thanks.

Problem: 
The semantics assigned to internal/external terminology in figure 7 and the
subsequent use in sections 6.4 through 6.6 assumes traditional NAT and is not
applicable to other NAT types.

Take the case of twice-NAT, where the address space of the internal/private
realm is exclusive from the address space of the external realm. Twice-NAT is
is different from a traditional NAT scenario, in that the private address realm
for a traditional space is a superset of the external address space. Say, a
node on the private realm initiates FTP and uses PORT command. Assume, the
Midcom-client is on the client node itself. In the above twice-NAT scenario,
the midcom-client knows only the IP addresses in its private address realm and
hence is able to supply just the endpoints in its realm (A0, A1) to make the
midcom PER request for setting up the FTP data session. This is different from
the semantics in fig 7 & sections 6.4 through 6.6 which assume that the input
parameters are A0 & A3. Hence, the PRR and PER as defined in these sections
will not be adequate for the above twice-NAT scenario.

I discussed this with Juergen and Martin. Both agreed the current midcom model
fails in the above scenario. Essentially, the scenario is not specific to FTP,
but is applicable to all apps that require a Midcom client (i.e., external ALG)
to patch payloads which contain IP addresses and ports. With a small change to
the semantics diagram (figure 7) and terminology, the PRR and PER can be made
to support all NAT flavors. The suggested fix below would work for all types of
NAT. In a traditional NAT scenario, there is little difference between the two
approaches.

Proposed fix: 
The proposal essentialy is based on the notion that a NAT middlebox provides
session translations from one address realm to another. The change will not
alter the functioning of Midcom with traditional NAT. It simply extends support
to twice NAT (incl NAT-PT) and other NAT devices. 

Consider the following diagram. 

 +----------+                                                +----------+
 | internal |A0<-->A1         +-----------+          A2<-->A3| external |
 | endpoint +-----  Internal -+ middlebox +- External -------+ endpoint |
 | (A0)     |       realm     +-----------+  realm           | (A3)     |
 +----------+                                                +----------+

     Figure n: End-2-end application Flow traversal through a middlebox

A0: InsideSrcEndPoint  (Addr:Port, <protocol>)
A1: InsideDestEndPoint (Addr:Port, <Protocol>)
A2: OutsideSrcEndPoint (Addr:Port, <protocol>)
A3: OutsideDestEndPoint (Addr:Port, <Protocol>)

Inputs to a middlebox, i.e., PRR and PER shall be one of A0+A1 (or) A2+A3. The
NAT middlebox provides translation to one or both end-points, depending upon
the direction of session, the realm in which the session originated & the NAT
address map applied.

As an FYI, I believe, the above fix would also address the issue that Bob
Penfield raised a couple of months ago in an e-mail dated circa 07/28/04. 
 
Thats all for now. Thank you.

regards,
suresh

--- Melinda Shore <[email protected]> wrote:

> The design team is deadlocked over an issue related to whether
> inputs should take the form of an end-to-end description of a
> data flow or a description of the specific resources on the
> participating middleboxes.  Suresh has promised to post a
> description of the problem that he sees to the mailing list, and
> I would like to get this resolved within the next several weeks -
> by November 26.  Because the difference is over a matter for which
> there's already wg consensus it requires a compelling technical
> argument for a change in the description.
> 
> Thanks,
> 
> Melinda
> 
> 
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom
> 


=====