Re: Action item from yesterday's meeting

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.

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


=====