Re: Action item from yesterday's meeting

I don't think I fully understand the issue yet

Let's ignore FTP for a second but consider any protocol that has separated
control and media channels. For example, if SIP was used to set of a MSRP IM
session - it seems like this problem would happen. Am I confused? Actually I
can answer that, I am confused, let me restate the questions - Can you
straighten me out on how this all works? I am particularly interested in the
case of SIP setting up a session of RTP and TCP sessions between endpoints.

For simplicity sake, lets imagine that internal endpoint A0 is also a SIP UA
that can control the middle box.



On 11/26/04 2:07 PM, "Pyda Srisuresh" <[email protected]> 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).
> 
> 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