Re: Action item from yesterday's meeting
Juergen Quittek <[email protected]> Sat, 27 Nov 2004 00:19:15 +0100
| Newsgroups | gmane.ietf.midcom |
|---|---|
| Message-ID | <[email protected]> |
Suresh,
--On 26.11.2004 14:07 Uhr -0800 Pyda Srisuresh wrote:
> 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).
Yes, sometimes they call it an ALG, sometimes a proxy. But this
discussion is not about how to call this device correctly.
I argued that there are kinds of ftp-ALGs (or ftp proxies) for which
there are good reasons to set them up - in contrast to setting up an
ftp-ALG as you describe it below for supporting an unfavorable (and
outdated) protocol option.
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
> 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
>>
>>
>>
>>
>>
>
>
> =====
>