Re: Action item from yesterday's meeting

Juergen,

All flavors of NAT boxes supporting FTP-ALG do support "PORT cmd". I donot know
what you mean by "there are many situations where ftp PORT fails" in a NAT box.
"PASV" command is recommended as a work around in firewalls and traditional NAT
devices only because that obviates the need for FTP-ALG. Anyways, FTP (with
"PORT" cmd) is not the only application that fits the description below. There
are several others. Real-Audio application has the same issue when the client
operates in UDP mode. Client specifies a port to which the server initiates a
data connection. Netshow/Windows Media Services/MMS has the same issue. Client
specifies the IP address and port to which the server initiates a UDP data
session. And, so on...

As for updating the MIDCOM MIB, I donot see the effort as being high. I
believe, we can state early on in the draft where it differs from the semantics
draft. It might be as simple as a paragraph of text below. If there are no
objecions, I promise to complete all the edits related to this in the MIDCOM
MIB draft over a weekend. 

regards,
suresh

--- Juergen Quittek <[email protected]> wrote:

> Hi Suresh,
> 
> --On 12.11.2004 8:00 Uhr -0800 Pyda Srisuresh wrote:
> 
> > 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.
> 
> Certainly we agree that there is a problem with the ftp PORT command across a
> twice-NAT.  However, this is not the only situation where ftp PORT fails;
> there are many more.  But ftp has a well known workaround for this problem
> which is the ftp PASV command.  With PASV, the client receives the server
> address (A3) to connect to and then has exactly what is needed A0 (its own
> address) and A3 for configuring the NAT.
> 
> With this simple and well known workaround, I do not think that the problem
> case you describe gives sufficient reason for changing the semantics we
> already
> agreed on.
> 
>     Juergen
> 
> 
> > 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.
> 
> You suggestion is feasible, but the effort would be high.  First we would
> have
> to go back to the semantics specification, change the PRR and PER semantics,
> and update the semantics document consistently.  And then of course we have
> to
> modify several section of the MIDCOM MIB I-D.
> 
> Best regards,
> 
>     Juergen
> -- 
> Juergen Quittek        [email protected]       Tel: +49 6221 90511-15
> NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
> Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de
> 
> 
> > 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
> >>
> >
> >
> > =====
> >
> >
> > _______________________________________________
> > midcom mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/midcom
> 
> 
> 
> 
> 


=====