Re: Action item from yesterday's meeting
Juergen Quittek <[email protected]> Tue, 30 Nov 2004 10:26:44 +0100
| Newsgroups | gmane.ietf.midcom |
|---|---|
| Message-ID | <2147483647.1101810404@[10.1.1.171]> |
Senthil,
Thanks for the question. Please see a reply inline.
Juergen
--On 29.11.2004 17:13 Uhr -0800 Senthil Sivakumar wrote:
> At 02:25 PM 11/29/2004 +0100, Juergen Quittek wrote:
>> Cullen,
>>
>> --On 27.11.2004 15:12 h -0800 Cullen Jennings wrote:
>>
>>> 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.
>>
>> This case, which is one of the core scenarios of the MIDCOM WG.
>> It is fully supported by the current semantics as well as by the
>> semantics Suresh suggested even in case of a twice-NAT.
>>
>> Let's assume that the SIP UA operates behind a NAT and that it has
>> already established NAT binding and session that allows communication
>> with other SIP UAs and servers across the twice NAT using the SIP
>> protocol. Then SIP signaling itself is not the problem.
>>
>> In case of an INVITE message issues by the local terminal,
>> the SIP UA could operate as follows:
>>
>> 1. scan the SDP payload and extract the local terminal's address
>> parameters A0 (IP address, port number)
>> 2. request address translation of these local address parameters
>> at the NAT using the MIDCOM protocol.
>> Here both semantics under discussion are similar.
>> The only input you have is the local terminal address A0.
>> This is sent to the NAT as input parameter
>> The NAT returns the translated external parameters A2.
>> If you want to apply a more tight security policy, you use
>> the Policy Reserve Rule (PRR) transaction that does not yet
>> enable NAT service for the address and that may block early
>> media. Otherwise you would use the Policy Enable Rule (PER)
>> that immediately enables the NAT service.
>> 3. Then the original invite message needs to be patched replacing
>> the original address parameters A0 with the parameters A2 returned
>> by the NAT. The patched message if forwarded following SIP routing
>> rules.
>> 4. On receipt of an OK message, the UA scans the SDP payload and
>> extracts the other terminal's address parameters A3.
>
> How did the UA get A3 and not A1? The UA would only scan the invite
> messages and not other messages to replace its local address with
> the natted address?
I am sorry for not explaining this issue sufficiently.
Please note that SIP is quite flexible. The callee's UA may attach
the SDP payload specifying its address and codec parameters to the
180 RINGING message as well as to the 200 OK message or other messages.
For this example, I assume that the SDP is carried by the 200 OK
message, but the example works analogously for other messages carrying
the callee's SDP payload.
The OK message is sent by the called external terminal. In the SDP
payload of the OK message the terminal states at which IP address
and port number it is expecting to receive data. This is the A3
information. A1 may not have been chosen at the NAT until this point
in time.
In step 5, A3 and A0 are inout parameters and A1 is returned by the
middlebox. Then the UA translates the SDP payload of the OK message
(replacing A3 with A1) and forwards the OK message to the application.
Thanks,
Juergen
> Senthil
>> 5. Now a mapping for the reverse direction need to be established
>> using the MIDCOM protocol again. According to the current
>> semantics, the SIP UA sends A0 and A3, the terminal's address
>> parameters, with Suresh's semantics it would be A2 and A3.
>>
>> For the reverse direction (incoming call, the procedure is similar.
>>
>> This all works for RTP, RTSP, TCP, etc.
>>
>> 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
>>
>>>
>>> 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
>>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> midcom mailing list
>> [email protected]
>> https://www1.ietf.org/mailman/listinfo/midcom
>