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