Re: Action item from yesterday's meeting

Suresh,

--On 29.11.2004 4:36 Uhr -0800 Pyda Srisuresh wrote:

> Juergen,
>
> Calling a proxy an ALG is marketing speak. A proxy is not an ALG and is in no
> way associated with a NAT middlebox. Check out RFC 2663 for the definition of
> an ALG.

Fine. As I said: this is not subject of the discussion.

> If you still donot believe, the FTP ALG example I gave is not legitimate, there
> is not much reason to move on with this thread. Every ALG is likely to have an
> equivalent application proxy solution and hence midcom may not be required.

Actually I do not know if an example can be 'legitimate' or not.

But my position is that you cannot derive compelling arguments from an example
that is based on an old protocol option that RFC 1579 recommends not to use
even in the absence of middleboxes.

Kind 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 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
>> >>
>> >>
>> >>
>> >>
>> >>
>> >
>> >
>> > =====
>> >
>>
>>
>>
>>
>>
>> _______________________________________________
>> midcom mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/midcom
>>
>
>
> =====
>