Re: Action item from yesterday's meeting

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.

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. 

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


=====