Re: Action item from yesterday's meeting

Suresh,


--On Freitag, 26. November 2004 14:42 Uhr -0800 Pyda Srisuresh 
<[email protected]> wrote:

|
| Contrary to what Juergen & Martin continue to insist, the semantics in the
| midcom MIB simply does not support twice-NAT. I tried to explain this in
| several e-mails. The reason is fairly simple. The current MIB assumes
| that the input to PRR/PER is constitued of an end-point in the private
| realm and an end-point in the external realm. This only makes sense in
| the case of traditional NAT where the end-point in externasl realm is
| also an end-point in private realm. In a traditional NAT, the private
| address space is fully inclusive of the external address space. As a
| general rule, a midcom agent cannot know session tuples such that one
| end-point(<address>:<port>) is in private realm and the other
| end-point(<address>:<port>) is in external realm.
|
| I presented a detailed example of how the above is true with an FTP-ALG
| while processing PORT command across a twice-NAT. The problem in no way
| is limited to FTP. You pick any application-ALG that knows the tuples of
| a session it needs to enable in its realm and use the resulting
| translation parameters to modify the payload. You will see the problem
| loud and clear.
|

The current semantics and MIDCOM MIB DOES support twice-NAT.  Taking an 
arbitrary example with an application level gateway:  Video on Demand with 
RTSP as signalling protocol and RTP unicast stream from video server to 
client.  Video server located in the public reachable Internet and client 
behind a twice NAT.  This scenario is comparable with PORT/FTP since the 
client is opening a TCP connection to the server and the server is sending 
back to the client's IP address the video stream.

(Warning: RTSP message exchange is simplified since many messages are 
probably exchanged between server.  BUT not all messages are necessary for 
the data transport, i.e., they are for video.)

Case 1: RTSP proxy and client located in separate entities. RTSP can do DNS 
without twice-NAT modification.

1. Client sends RTSP/TCP to RTSP proxy indicating the IP address and port 
number where it likes to receive the video. The server name is indicated 
too.

2. RTSP proxy receives the request and determines the IP address of the 
server.  RTSP proxy talks to middlebox via MIDCOM giving (A0, A3) as input 
parameter and gets (A1,A2) as response.

3. RTSP proxy forward request to server with client's IP address set to A2 
(destination parameter within RTSP).

4. Some RTSP chitchat, interesting for video codec etc.

5. RTSP Server send the video stream to IP address indicated in RTSP (which 
is A2).

====> Summary: Works.




Case 2: RTSP proxy and client located in same entity. RTSP can do DNS 
without twice-NAT modification.

1. Client does DNS and acquires A3.

2. Client does MIDCOM with (A0, A3) and retrieves (A1, A2).

3. Client sets destination parameter within RTSP to A2 and sends RTSP/TCP 
to A1. A1 being forwarded to A3 after mapping.

4. Video stream sent from server to A2 after receiving the RTSP messages.

====> Summary: Works.

Case 3: RTSP proxy and client located in same entity. DNS is doing already 
the configuration of the middlebox and gives back A1 as server's address.

1. Client sends RTSP/TCP to A1 with no destination parameter set, just with 
client_port parameter set.

2. Server receives RTSP and starts sending UDP to A2 from where the TCP 
connection is originated.

No need for MIDCOM at the client/proxy.

====> Summary: Works.


This has been an arbitrary ALG example with three cases and it works in any 
case without modifying MIDCOM.

  Martin

|
| regards,
| suresh
|
| --- Juergen Quittek <[email protected]> wrote:
|
|> Hi Cullen,
|>
|> --On 24.11.2004 11:23 Uhr +0100 Martin Stiemerling 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.
|>
|> The only concrete case that Suresh presented is the one of ftp PORT.
|>
|> RFC 1579 recommended already 10 years ago that the PORT command should
|> not be preferred anymore.  Since then, protocol design considered this
|> advice and new developed protocols avoid the problem of ftp PORT.
|>
|> Therefore I agree with Martin that the presented case is not relevant.
|> In contrary, it would be a step into the wrong direction adding support
|> for unfavorable (and outdated) protocol design.
|>
|> 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
|>
|>
|> >   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
|>
|
|
| =====
|