Re: Action item from yesterday's meeting

Thanks for the reply.. Some comments inline..



>>>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.

OK, I think my question was, why would not this UA query the NAT
to get the translated information for its local address/port. So when the
initiated UA receives the OK, it is A1 and not A3.

Secondly, the reason for twice NAT, most likely is because there is
another A3 in A0's realm. How would the NAT distinguish between
the two A3's? If the query was originated by A3 in the different realm
then NAT can distinguish between these two requests because of the
domains the requests are originating from.. (Is that a supported scenario
where you have two A3s one in each realm?.).

Thanks
Senthil


>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
>
>
>