RE: Action item from yesterday's meeting
"Pyda Srisuresh" <[email protected]> Thu, 2 Dec 2004 09:16:41 -0800
| Newsgroups | gmane.ietf.midcom |
|---|---|
| Message-ID | <[email protected]> |
[I sent an e-mail response a few hours ago. I dont see it on this list yet. There may be some issues with my e-mail. I am resending. Sorry, if you get two copies] Martin, That there are apps working is meaningless without specifying the restraints under which they did. The devil is in the details. I illustrated with 2 examples in detail where the current model fails with twice-NAT. Most recently, Senthil gave a third example where the model fails once again when the midcom agent is on the callee (external). I am convinced the current model is problematic. It is unfortunate the discussion cannot continue. regards, suresh > -----Original Message----- > From: Martin Stiemerling [mailto:[email protected]] > Sent: Thursday, December 02, 2004 12:16 AM > To: Pyda Srisuresh; Midcom > Subject: Re: [midcom] Action item from yesterday's meeting > > > Suresh, > > A quick note to correct your statement w.r.t. MIDCOM and twice-NAT: > > 1. SIMPLE is WORKING > 2. FTP is WORKING too. > 3. Video on Demand (RTSP+RTP) is WORKING too. This has been arbitrary > example which is similar to FTP. > > Sorry for not elaborating on this in-depth anymore, I'm going to stop > arguing now; we are spinning round without getting further. > > Martin > > --On Mittwoch, 1. Dezember 2004 5:35 Uhr -0800 Pyda Srisuresh > <[email protected]> wrote: > > | Juergen, > | > | I illustrated two applications (FTP & SIMPLE) that exhibit the same > | problem in the midcom MIB, when used in conjunction with twice-NAT. > | First, you claim, FTP-ALG example is not relevant for midcom. Then, you > | claim, SIMPLE example shoudl have a proxy. That a problem can be shown > | without a proxy enroute seems immaterial to you. You mandate > requirements > | in the examples. You even say, twice-NAT may not be acceptable for > | telephony applications. I dont see where this line of reasoning > is going. > | > | As far as I know, to disprove the working of a theory, all you > need is one > | example to prove where the assertion fails. I gave two. Further, I also > | pointed out how the proposed fix would fix both the problems with the > | current model. Lastly, I know of no example where the proposed fix would > | fail and the current model would work. Perhaps, it is time you proved to > | the WG why the fix should not be adapted and what it breaks if any. > | > | Specific responses inline below. > | > | regards, > | suresh > | > | > | --- Juergen Quittek <[email protected]> wrote: > | > |> > |> > |> --On 30.11.2004 9:10 Uhr -0800 Pyda Srisuresh wrote: > |> > |> > My comments inline below. > |> > > |> > regards, > |> > suresh > |> > > |> > --- Juergen Quittek <[email protected]> wrote: > |> > > |> >> > |> >> > |> >> --On 30.11.2004 7:34 Uhr -0800 Pyda Srisuresh wrote: > |> >> > |> >> > Cullen, > |> >> > > |> >> > Thanks for suggesting a new application and simplifying > the protocol > |> >> sequence > |> >> > for the apllication. This, I believe, is yet another example > |> illustrating > |> >> the > |> >> > problem with the current model as you will see in my comments > |> >> > below. I > |> am > |> >> > making the following assumptions w.r.t. the example. Do > let me know > |> >> > if > |> you > |> >> > disagree. Thanks. > |> >> > > |> >> > 1. I have not seen any mention of proxies. If you assume > a proxy, we > |> need > |> >> to > |> >> > redraw the picture with proxy in one of the realms. So, I will > |> >> > assume no proxies. > |> >> > > |> >> > 2. The NAT middlebox in use is a twice NAT. I.e., It has address > |> >> > maps to translate source and destination endpoints of a session > |> >> > flow. A0, A1 are > |> IP > |> >> > addresses in private space and are non-overlapping with A2, A3 in > |> >> > the > |> >> external > |> >> > address space. For simplicity, let us assume, the address A1 is > |> statically > |> >> > mapped to A3 for destination endpoint on outbound flows. > |> >> > |> >> This assumption is usually not feasible. I definitely cannot expect > |> >> in advance that all external SIP terminals I ever want to call from > |> >> an > |> internal > |> >> phone are statically mapped by a twice-NAT. This twice-NAT needs to > |> >> map > |> the > |> >> entire outside network into the internal one. Your assumption is OK > |> >> with IPv6 internally and IPv4 externally. But it fails for every > |> >> other combination > |> >> of IP versions. > |> >> > |> > [suresh] That is how it works in twice-NAT. You use name service to > |> > resolve names into IP addresses. > |> > |> That's how it works? This is a very limited view. Why should > we exclude > |> dynamic > |> creation of NAT bindings in the twice-NAT case? If you established all > |> bindings > |> at a twice-NAT in advance, you do not need to control the NAT, you just > |> need a > |> firewall at the NAT to be controlled. This would make the story much > |> easier. > |> > |> But this is not acceptable for IP telephony and other applications. > |> How would you communicate with a mobile WLAN phone or PC at a hotspot? > |> Do you claim this does not work at all without having the hot spot's > |> address range mapped at the NAT in advance ??? > |> > | [suresh] Juergen - You misunderstood what I said. I was saying that your > | statement that static address mapping is usually not feasible > and that it > | usually fails in scenarios other than V4/V6 setup is not correct. Static > | address mapping for destination end points in outbound flows is a fairly > | common setup in twice-NAT. Dynamic mapping for load share purposes is > | another scenario. For the purposes of this discussion, static address > | mapping is appropriate. Note, large blocks of addresses can be > statically > | mapped. It doesnt have to be the Internet. Twice-NAT coudl be setup for > | accessing specific well-known resources, not necessarily the mobile > | Phone/pc users you have in mind. > | > |> >> > 3. There is a midcom agent on UA1 that is responsible for > |> >> > interacting > |> with > |> >> NAT > |> >> > and ensuring that the application works between UA1 and UA2. I.e., > |> >> > there > |> is > |> >> no > |> >> > other entitity outside of UA1 that is acting as midcom agent. > |> >> > > |> >> > 3. Name service is external to this application. I.e., nodes learn > |> >> > of IP addresses for a name from an independent name service in > |> >> > their realm. > |> So, > |> >> when > |> >> > a caller UA1 uses its name service to lookup UA2, it > resolves to A1. > |> This > |> >> is > |> >> > because, the private address space in the current example includes > |> >> > just > |> A0 > |> >> and > |> >> > A1. > |> >> > > |> >> > 4. In the outset, UA1 uses name service to resolve UA2. Name > |> >> > service > |> >> returns > |> >> > the IP address of UA2 to be A1. > |> >> > > |> >> > Please see my comments below in-line. > |> >> > > |> >> > regards, > |> >> > suresh > |> >> > > |> >> > > |> >> > --- Cullen Jennings <[email protected]> wrote: > |> >> > > |> >> >> > |> >> >> Ok, I think I understand - combining Juergen's and > Martin's emails > |> >> >> - > |> just > |> >> to > |> >> >> make sure I have this right, in the case with an > outbound call (so > |> >> >> UA1 called UA2) and UA1 controls NAT. > |> >> >> > |> >> > [suresh] Right. UA1 calls UA2 using the session tuple of > (A0/blah0, > |> >> A1/5060). > |> >> > Twice-NAT would translate the session tuple into (A1/blah1, > |> >> > A3/5060). > |> >> > > |> >> >> +-----+ > |> >> >> | M | > |> >> >> | I | > |> >> >> | I | > |> >> >> | D | > |> >> >> UA1 | L | UA2 > |> >> >> +------+ | E | > +------+ > |> >> >> | SIP UA+------------------+ B +------------------+SIP > |> >> >> | UA| MIDCOM| | O | | > |> >> >> | EXT | AGENT +..................+ X > |> >> >> | +..................+ | > |> >> >> +------+ +-----+ > +------+ > |> >> >> A0 A1 A2 A3 > |> >> >> > |> >> >> > |> >> >> UA1 contacts NAT with a PER for (A0/port0, */*) direction inbound > |> >> >> and > |> the > |> >> >> NAT returns A2/port2. > |> >> > > |> >> > [suresh] The above PER specifies just one endpoint of a > session. One > |> >> end-point > |> >> > alone is not adequate to establish a twice-NAT session. One > |> >> > end-point is adequate to send a binding, not a session. Twice-NAT > |> >> > will translate both endpoints of a session. This is where the two > |> >> > models differ. > |> >> > > |> >> > In the current model - UA1 only knows of A0 and A1. The PER in the > |> >> > MIB > |> only > |> >> > allows A0 & A3 as input. So, the midcom agent on UA1 specifies A0 > |> >> > alone > |> as > |> >> > input. The midcom agent does not know A3 to specify as input. > |> >> > |> >> No. You do not know A1 before you request a binding for A0-A2. > |> >> Based on what input would you know about A1? > |> >> > |> > [suresh] Please refer assumption 4. UA1 learns the address of UA2 in > |> > the > |> outset > |> > to A1 using name service. > |> > > |> >> Please remember that A3 is determined by SIP routing of your INVITE > |> message. > |> >> > |> >> You cannot make any assumption about A3 before you receive > a reply on > |> >> your INVITE message with a SDP payload. Then you learn about A3 and > |> >> must > |> ensure > |> >> that the twice NAT will provide you with a binding A1-A3. This > |> >> binding cannot be established before A3 is known, which is > before you > |> >> received a reply on your INVITE message. > |> >> > |> > [suresh] Please refer assumption 1. There are no proxies to route SIP > |> messages. > |> > If a proxy is assumed, we need to redraw the picture with a > proxy and > |> > go > |> over > |> > the steps one more time. > |> > |> I'm sorry, I misunderstood assumption 1. > |> In this case I do not just have problems assumption 2, but also with > |> assumption 1. > | > | [suresh] Sounds like, you are mandating requirements. Why do > you mandate a > | proxy enroute for the example? > | > |> If I call into the public network I should not assume that my SIP > |> signaling directly reaches the terminal I want to call, even if I get > |> the address from a redirect server. > |> > | > | [suresh] As I said, there are cases where SIMPLE isnt necessarily used > | for the whole Intenret and public network. > | > | regards, > | suresh > | > |> Kind regards, > |> > |> Juergen > |> > |> >> 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 > |> > > |> >> > |> >> > |> >> > In the new model - UA1 knows of A0 and A1. The PER in the MIB > |> >> > allows A0 > |> & > |> >> A1 as > |> >> > input. So, the midcom agent on UA1 sends a PER for > (A0/port0, A1/*), > |> >> direction > |> >> > inbound. Twice-NAT would return (A2/Port2, A3/*) and enable a > |> NAT-session > |> >> for > |> >> > the same. > |> >> > > |> >> >> UA1 sends A2/port2 in offer SDP. > |> >> > [suresh] Yup. > |> >> > > |> >> >> > UA2 starts > |> sending > |> >> >> early media to A2/port2 this which gets forwarded to A0/port0. > |> >> > > |> >> > [suresh] This would work only if the NAT-session was setup > |> >> > correctly in > |> the > |> >> > first place by the midcom agent on UA1. > |> >> > > |> >> > In the current model - there is no session permitted from A3/* to > |> A2/port2. > |> >> All > |> >> > that existed was a port-Bind to A2/Port2 for use as destination > |> endpoint. > |> >> > > |> >> > In the new model - the twice-NAT would have setup a NAT-session > |> correctly > |> >> for > |> >> > the tuple (A2/Port2, A3/*), direction inbound. So, no problem for > |> twice-NAT > |> >> in > |> >> > allowing the flow (A3/*, A2/port) in external realm and translatng > |> >> > it > |> into > |> >> > (A1/*, A0/port0) in private realm. > |> >> > > |> >> >> > Th > |> >> >> > en > |> UA2 > |> >> >> sends answer with A3/port3 to UA1. > |> >> > > |> >> > [suresh] > |> >> > > |> >> > In the current model - Assuming the twice-NAT had let the session > |> through, > |> >> the > |> >> > midcom agent on UA1 has no knowledge of A3. So, the > payload goes as > |> >> > is > |> to > |> >> UA1. > |> >> > UA1 will have a problem when it sees A3, which it does not > |> >> > recognize. > |> UA1 > |> >> might > |> >> > just give up. > |> >> > > |> >> > In the new model proposed - The midcom agent on UA1 will translate > |> A3/port3 > |> >> in > |> >> > the payload to A1/Port3 prior to sending the payload to UA1. > |> >> > > |> >> >> UA1 tells NAT to create > |> >> >> (A0/port0,A3/port3) outbound and NAT returns A1/port1 then UA1 > |> >> >> starts sending media to A1/port1 and NAT forwards to A3/port3. > |> >> > > |> >> > [suresh] > |> >> > > |> >> > In the current model - UA1 knows only of A0 & A1. UA1 > does not know > |> >> > A3. > |> >> Now, > |> >> > the midcom agent does not A3 either. > |> >> > > |> >> > In the new model proposed - UA1 knows only of A0 & A1. The midcom > |> >> > agent > |> on > |> >> UA1 > |> >> > contacts NAT with a PER for (A0/port0, A1/Port3) outbound and the > |> >> > NAT > |> >> returns > |> >> > (A1/Por1, A3/port3). Subsequently, when the UA1 initiates > a session > |> >> (A0/port0, > |> >> > A1/Port3), the NAT lets it through. > |> >> > > |> >> >> UA2 > |> >> >> > answers and > |> >> >> sends 200 which UA1 accepts then UA1 changes the (A0/port0,*/*) > |> >> >> inbound mapping to be a (A0/port0,A3/port3) inbound mapping. > |> >> >> > |> >> > [suresh] As you can see, there are problems with the current model > |> >> > in twice-NAT. The current model allows only one end-point within a > |> >> > realm to > |> be > |> >> > specified as input. The new model fixes this so two endpoints from > |> >> > the > |> same > |> >> > realm can be specified as input. This in turn allows twice-NAT to > |> >> > setup NAT-sessions. > |> >> > > |> >> > > |> >> >> Did I get this right? I think I understand now - thanks for the > |> >> >> clarification. > |> >> >> > |> >> > [suresh] Hope my comments illustrates the problems with > the current > |> model > |> >> and > |> >> > the fix from the new model. Well, that is my perspective, anyways. > |> >> > > |> >> > regards, > |> >> > suresh > |> >> > > |> >> >> > |> >> >> > |> >> >> > |> >> >> On 11/29/04 5:25 AM, "Juergen Quittek" <[email protected]> > |> >> >> 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. 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 > |> >> >> > |> >> >> > |> >> >> > |> >> > > |> >> > > |> >> > ===== > |> >> > > |> >> > > |> >> > _______________________________________________ > |> >> > 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 > >