Re: Action item from yesterday's meeting

Martin,

Claiming these apps work under certain constraints is not meaningful is my
opinion. The devil is in the details. For the same two applications in the
scenarios I described, I have demonstarted in detail how the current MIB does
not work. Most recently, Senthil pointed out a third example with SIMPLE where
a midcom agent is on the callee in the external realm and the current MIB
doesnot work. With the proposed fix, the MIB will work in all three examples. I
am convinced that the current MIB is problematic.

It is unfortunate the discussion cannot continue on the list.

regards,
suresh
 
--- Martin Stiemerling <[email protected]> wrote:

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


=====