Re: Action item from yesterday's meeting

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


=====