Re: Action item from yesterday's meeting

Juergen,

The solution you refer to is a transparent proxy solution (even though
Clavister.com refers to it as ALG). Check out the last parapgraph in Clavister
web site which confirms that this is a proxy solution
(http://www.clavister.com/technology). 

The FTP-ALG that I am refering to is not a proxy. Unlike the proxy, the FTP-ALG
does not terminate FTP sessions with client and server and does not inject
packets of its own. The ALG simply inspects FTP control packets and modifies
payloads containing PORT/EPRT/PASV/EPSV commands as appropriate and sets up
NAT-sessions on the NAT device. This is what NAT vendors typically do.

I believe, what you & Martin are saying is that a) the transparent proxy
solution exists for FTP, so vendors should use the proxy solution instead of
the FTP ALG, and b) The FTP ALG example I gave cannot be used to illustrate a
problem with the midcom semantics, because it is a solved problem (proxy
solution). I disagree with this argument because what we are talking about in
this WG is not replacing ALGs with proxies, but rather use Midcom to
externalize ALG intelligence. For that reason, the FTP ALG example is a good
way to illustrate the problem with the sematics in the MIB draft. Let me see if
I can reword the problem description differenctly. Consider the following
diagram. 

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

An application client, or an application server or a midcom agent acting as ALG
for a given application can know the session tuples in one realm or the other.
Only the NAT middlebox knows the combined session tuples (i.e., session tuples
in either realm), as NAT sets up the translation sessions. Midcom agent can
request NAT middlebox to set up NAT sessions and learn of the translation
parameters,  but it cannot know the translation parameters apriori.

In a traditional NAT, A1 and A3 are the same. The current semantics assume that
midcom agent knows to provide A0 & A1 (as defined above) as input for all the
PRR/PER queries. This is a reasnable assumption for traditional NAT. But, the
problem is easy to see when A0 is different from A2 and A1 is different from
A3. That is why I took the case of twice NAT and FTP-ALG for PORT command to
illustrate the problem. But, the problem is neither specific to twice-NAT nor
the FTP-ALG. You can conjure up several scenarios with a) applications that
require an ALG and a) traversing bi-directional NAT or NAT-PT or a NAT with a
combination of several types of address maps, and c) the midcom agent only
knows the session tuples in external realm(i.e., A2 & A3). You will quickly
note that assuming A0 & A1 alone as input will not be adequate for these apps.
There must be an option to select the input parameter realm. This is exactly
what I proposed. Nothing more to it.

Incidentally, this also the issue that I believe, Bob Penfield raised in the
email dated 08/05 (You can refer the midcom archives fo rthis e-mail). Here is
an excerpt from the e-mail.

   > 2) Step 3 of the PRR (section 6.4) states that the SNMP manager sets the
   > internal endpoint address components. This is correct if the signaling
   > (going thru the MIDCOM client) is outbound. If the signaling is inbound,
   it
   > contains the external endpoint addresses.
   >
   What I am talking about here is the case where the signaling protocol (e.g.
   SIP) carries the endpoint media addresses for a media session (e.g. in SDP).
   A SIP INVITE coming from the external network will hve SDP that contains the
   address of the external endpoint. The internal endpoint media addresses
   won't be know until the 200 OK response comes from the internal endpoint.

Hope this helps explain the problem better.

regards,
suresh

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

> Suresh,
> 
> --On 24.11.2004 17:33 Uhr -0800 Pyda Srisuresh wrote:
> 
> > Juergen,
> >
> > If you are saying that FTP-ALG is not required, that is simply not true.
> 
> I was just saying that I do not see a problem with the PORT command
> as long as PASV is available.
> 
> Here is a quote from RFC 1579 written by Steve Bellovin in 1994:
> 
>    "Recommendation
> 
>       We recommend that vendors convert their FTP client programs
>       (including FTP proxy agents such as Gopher [3] daemons) to use PASV
>       instead of PORT.  There is no reason not to use it even for non-
>       firewall transfers, and adopting it as standard behavior will make
>       the client more useful in a firewall environment."
> 
> I do not say that ftp-ALGs are not required at all.
> What I say is that enabling the PORT command across a NAT is not a
> sufficient reason for installing a ftp-ALG.
> 
> This does not exclude that ftp-ALGs may be very useful for solving
> other problems.
> 
> - One of them is firewall control.  In a highly secured/restricted
>   environment even the PASV command might need a ftp-ALG in order
>   to work across a firewall.  Actually, Martin and I implemented
>   such an ALG two years ago.
> 
> - Considering the PASV command as more secure for the client and the
>   PORT command as more secure for the server, the ideal ftp-ALG
>   coverts a PASV command from the client into a PORT command to the
>   server as for example described at
>   <http://www.clavister.com/manuals/ver8.4x/manual/ftp_alg.htm>.
> 
> - Another reason for an ftp-ALG may be policy control.  The ALG
>   could limit ftp access to a given set of servers and/or clients.
> 
> - ... and probably there are more good reasons for using ftp-ALGs.
> 
> > Users have the option to use PASV command. But, they dont have to. PORT and
> EPRT
> > commands are still supported FTP commands. NAT vendors donot mandate that
> users
> > use PASV command.
> >
> > PORT command simply illustrates the problem. Demonizing PORT commnd does
> not
> > make the problem non-existant. Have a good weekend.
> 
> I did not intend to demonize anything - at least no further than
> RFC 1579 did already ;-)
> 
> 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
> 
> 
> > regards,
> > suresh
> >
> > --- Juergen Quittek <[email protected]> wrote:
> >
> >> Suresh,
> >>
> >> --On 24.11.2004 8:37 Uhr -0800 Pyda Srisuresh wrote:
> >>
> >> > Martin,
> >> >
> >> > Melinda suggested that I come up with an example to illustrate that the
> >> current
> >> > sematics and MIB is problematic for certain types of NATs. I did this
> with
> >> FTP
> >> > and PORT command in twice NAT scenario. You claim the FTP example is not
> >> real.
> >> > That simply is not true. FTP is a common ALG used with NATs and is very
> >> real.
> >> > That you dont like the FTP ALG would not make the problem go away. There
> is
> >> a
> >> > real problem with the MIB, the way it is. And, there is a simple fix to
> it.
> >> >
> >> > Hope you understand. Thanks.
> >>
> >> I do understand that you solve the problem of ftp using the PORT command.
> >> But you are solving a problem, that has been solved already a long time
> ago.
> >> There is the ftp PASV command and every decent ftp client supports (if not
> >> prefers) it.  Therefore, I still do not see a reason for changing the
> >> semantics.
> >>
> >> 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
> >>
> >>
> >> > regards,
> >> > suresh
> >> >
> >> > --- Martin Stiemerling <[email protected]> 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.
> >> >>
> >> >>   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
> 
> 
> 
> 
> 


=====