Re: Action item from yesterday's meeting

Suresh,

A hint from RFC 3235 on FTP's PORT command and NATs.  The section refers to 
NAPT but this holds definitely true for twice-NAT as well (see Section 3.5 
of the same document).

The base line for FTP PORT command: Do not use and promoted it anymore, 
since it is not state of the art.  Use PASV or EPSV instead and you are 
fine in any environment.

My conclusion on the PORT command:  The FTP protocol has been developed in 
October 1985 and at this point of time firewalls and especially Network 
Address Translators have not been around.  Nowadays, PORT command is being 
replaced by the use of PASV and EPSV, which is, architectural speaking, the 
clean way.

  Martin


RFC 3235       NAT Friendly Application Design Guidelines   January 2002


3.2.2 Avoid Session Bundles

   Independent sessions, such as used by POP or SMTP, are preferred to
   protocols that attempt to manage a bundle of related sessions, such
   as FTP.  The term "session" here is used to refer to any association
   between end systems, and may be using any transport protocol or
   combination of protocols (UDP, TCP, SCTP).

   In the FTP protocol, port information is passed over one TCP
   connection and is used to construct a second TCP connection for
   passing the actual data.  Use of a separate connection to transfer
   the file data makes determination of file end quite simple, however
   other schemes could be envisioned which could use a single
   connection.

   The HTTP protocol, for example, uses a header and content length
   approach to passing data.  In this model, all data is transferred
   over the single TCP connection, with the header portion indicating
   the length of the data to follow.  HTTP has evolved to allow multiple
   objects to be passed on a single connection (thereby cutting the
   connection establishment overhead).  Clearly a new file transfer
   function could be built that would perform most of the functions of
   FTP without the need for additional TCP connections.

   The goal is to keep to single connections where possible.  This keeps
   us from needing to pass addressing information of any sort across the
   network.  However, multiplexing traffic over a single connection can
   create problems as well.

3.2.3. Session Bundles Originate From Same End

   Origination of connections is an important consideration.  Where
   possible, the client should originate all connections.  The FTP
   protocol is the most obvious example, where by default the server
   opens the data connection to a port on the client (the client having
   specified the port number via a PORT command over the control TCP
   session).

   As pointed out in [RFC1579], the use of the passive open option in
   FTP (PASV) remedies this situation as the client is responsible for
   opening the connection in this case.  With client-opened connections,
   the standard functions of NAPT will process the request as it would
   any other simple TCP connection, and so an ALG is not required.

   In cases where session bundles are unavoidable, each session in the
   bundle should originate from the same end station.





Senie                        Informational                      [Page 6]


--On Montag, 29. November 2004 5:16 Uhr -0800 Pyda Srisuresh 
<[email protected]> wrote:

| Juergen,
|
| I cannot go on in this thread so long as you continue to argue that the
| FTP PORT example used to illustrate the problem is not relevant. That is
| a basic problem.
|
| regards,
| suresh
|
| --- Juergen Quittek <[email protected]> wrote:
|
|> Suresh,
|>
|> --On 26.11.2004 14:42 h -0800 Pyda Srisuresh wrote:
|> >
|> > Contrary to what Juergen & Martin continue to insist, the semantics in
|> > the midcom MIB simply does not support twice-NAT.
|>
|> I know that you know that this is not a correct statement.
|>
|> The current MIDCOM solution explicitly supports twice-NAT.
|> The only concrete case we identified so far for which the current
|> solution has a problem is the ftp PORT command over twice-NAT.
|>
|> Our ongoing discussion is about whether or not this case is
|> sufficiently relevant  for changing the MIDCOM semantics on
|> which we already have WG consensus.  Considering the
|> availablility of the PASV command and considering the
|> recommendation in RFC 1519 that ftp clients should always use
|> PASV instead of PORT, I do not think your case is sufficiently
|> relevant.
|>
|> Thanks,
|>
|>     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
|>
|>
|> > I tried to explain this in
|> > several e-mails. The reason is fairly simple. The current MIB assumes
|> > that
|> the
|> > input to PRR/PER is constitued of an end-point in the private realm
|> > and an end-point in the external realm. This only makes sense in the
|> > case of traditional NAT where the end-point in externasl realm is also
|> > an end-point
|> in
|> > private realm. In a traditional NAT, the private address space is fully
|> > inclusive of the external address space. As a general rule, a midcom
|> > agent cannot know session tuples such that one
|> > end-point(<address>:<port>) is in private realm and the other
|> > end-point(<address>:<port>) is in external
|> realm.
|> >
|> > I presented a detailed example of how the above is true with an FTP-ALG
|> while
|> > processing PORT command across a twice-NAT. The problem in no way is
|> limited to
|> > FTP. You pick any application-ALG that knows the tuples of a session it
|> needs
|> > to enable in its realm and use the resulting translation parameters to
|> modify
|> > the payload. You will see the problem loud and clear.
|> >
|> >
|> > regards,
|> > suresh
|> >
|> > --- Juergen Quittek <[email protected]> wrote:
|> >
|> >> Hi Cullen,
|> >>
|> >> --On 24.11.2004 11:23 Uhr +0100 Martin Stiemerling wrote:
|> >>
|> >> > Hi Cullen,
|> >> >
|> >> > --On Dienstag, 23. November 2004 17:31 Uhr -0800 Cullen Jennings
|> >> <[email protected]> wrote:
|> >> >
|> >> >|
|> >> >| I have not been participating closely I the group so I may have a
|> complete
|> >> >| clueless opinion here but ... It seems that people are continuing
|> >> >| to deploy things like twice NAT, if we can make the protocol work
|> >> >| in these cases without causing major complexity or big issues to
|> >> >| the protocol,
|> why
|> >> >| wouldn't we? It seemed to me that Srisuresh was proposing that a
|> >> >| few
|> >> >
|> >> > Just to make it clear: The MIDCOM MIB already supports twice-NATs
|> >> > and
|> the
|> >> semantics did so from the beginning.  So in this sense there is
|> >> anyway no change needed.
|> >> >
|> >> >| simple changes could make the protocol be about the same in the
|> >> >| case we currently have plus make it usable for a few more cases.
|> >> >
|> >> > The case presented do not represent a real case in my opinion.
|> >>
|> >> The only concrete case that Suresh presented is the one of ftp PORT.
|> >>
|> >> RFC 1579 recommended already 10 years ago that the PORT command should
|> >> not be preferred anymore.  Since then, protocol design considered this
|> >> advice and new developed protocols avoid the problem of ftp PORT.
|> >>
|> >> Therefore I agree with Martin that the presented case is not relevant.
|> >> In contrary, it would be a step into the wrong direction adding
|> >> support for unfavorable (and outdated) protocol design.
|> >>
|> >> Thanks,
|> >>
|> >>     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
|> >>
|> >>
|> >> >   Martin
|> >> >
|> >> >|
|> >> >|
|> >> >| On 11/16/04 10:19 AM, "Melinda Shore" <[email protected]> wrote:
|> >> >|
|> >> >|> I'm intending to get this issue closed in the next week (or
|> >> >|> sooner, if possible).  Juergen and Suresh have presented their
|> >> >|> concerns, and if there are other people who have opinions or
|> >> >|> questions or even just want to indicate how they're leaning, that
|> >> >|> would be a big help.
|> >> >|>
|> >> >|> 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
|> >> >
|> >> >
|> >> >
|> >> > _______________________________________________
|> >> > midcom mailing list
|> >> > [email protected]
|> >> > https://www1.ietf.org/mailman/listinfo/midcom
|> >>
|> >>
|> >>
|> >>
|> >>
|> >> _______________________________________________
|> >> midcom mailing list
|> >> [email protected]
|> >> https://www1.ietf.org/mailman/listinfo/midcom
|> >>
|> >
|> >
|> > =====
|> >
|>
|>
|>
|>
|>
|> _______________________________________________
|> midcom mailing list
|> [email protected]
|> https://www1.ietf.org/mailman/listinfo/midcom
|>
|
|
| =====
|
|
| _______________________________________________
| midcom mailing list
| [email protected]
| https://www1.ietf.org/mailman/listinfo/midcom