Subject: [Sip] update to nat traversal draft!

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2001 03:51:16 -0400

Folks,

I've submitted an update to draft-rosenberg-sip-entfw, which discusses
traversal of SIP through enterprise and residential nats. There are a LOT of
differences between this version (-02) and the previous. Specifically:

1. SIP "via port" parameter defined to allow SIP-UDP traversal
2. Translate header replaces Contact cookie
3. NAT detection and allocation protocol is defined, and used between the UA
and some elements deployed in the SIP provider network. This is effectively
midcom without midcom compliant nats. It vastly simplifies things and also
solves the case where both sides are behind a symmetric nat.
4. lots more

Until the draft appears in the archives, you can pick up a copy at:

http://www.jdrosen.net/papers/draft-rosenberg-sip-entfw-02.txt

Thanks,
Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 24 Jul 2001 03:15:58 -0700

Hi Jonathan,

Very interesting draft. 

I have a couple of comments. It seems that in section 4.2 Contact
Translation (and maybe I am being thick...) that the proxy Y is not required
to Record-Route the call:

   "In order for this connection to be used for re-INVITEs or BYEs, the
   proxy needs to record route."

Thus when Joe calls Bob and Proxy Y does not Record-Route then the Joe would
send the ACK directly to the Translated Contact in the 200 OK from Bob.
However this is not going to work for a symmetric NAT. Shouldn't there be
some sort of requirement that Proxy Y must Record-Route unless Bob's NAT is
known to be a cone NAT (eg indicated in Translate header)? Am I completely
missing something here?

Also for the symmetric RTP section: I think would be much more interoperable
if we define symmetric RTP as being indicated when transport profile RTP/AVP
is used _AND_ the a=direction parameter is present (rather than a new
transport profile "RTP/UDP"). In this manner a UA supporting symmetric RTP
and a plain vanilla UA can still communicate when NAT is not involved.
Obviously it is much cleaner that a separate transport profile is used but I
believe it will hamper the deployment of your suggestion. 

In the above suggestion, a UA not understanding symmetric RTP (ie, not
understanding the direction attribute) will setup a call as normal.
Additionally, the UA supporting symmetric RTP can detect that the peer does
not support the extension by the lack of the a=direction attribute in the
SDP answer. Simple!

Regards,

Robert.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 8:51 AM
> To: [email-masked]'
> Subject: [Sip] update to nat traversal draft!
> 
> 
> Folks,
>

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 24 Jul 2001 04:55:12 -0700

Perhaps I am misinterpreting the quoted statement (in original email),
Jonathan? I think perhaps you might be saying that the proxy Y must always
record-route - regardless of whether the proxy wants to be on the call path
for re-INVITE's and BYE's. However, there doesn't seem to be any requirement
for this when the NAT is known to be of the cone type.

Robert.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Jul 2001 15:41:51 -0400

> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Tuesday, July 24, 2001 6:16 AM
> To: 'Jonathan Rosenberg'; [email-masked]'
> Subject: RE: [Sip] update to nat traversal draft!
> 
> 
> Hi Jonathan,
> 
> Very interesting draft. 
> 

No, you are correct. The bit about record-routing is unchanged from the -01
version, where this was needed. Now, if the proxy is contacting a user
behind a full-cone nat, it isn't needed.

> believe it will hamper the deployment of your suggestion. 

Oops! My bad. I meant to say RTP/AVP, not RTP/UDP. My apologies. It is
supposed to be interoperable in this way as you have described. The UAC
sends an INVITE, and lists RTP/AVP with the port and IP address it wishes to
receive on. If its supporting symmetric RTP, it includes a direction. Lets
say it wishes to be active. So, it includes:

a=direction:active

And it is still prepared to receive media on the IP/port it listed. Lets say
this hits a UAS which doesn't support symmetric RTP. In this case, the SDP
in the response doesn't include a direction attribute, and if there is no
nat, the UAC gets media on the IP and port it placed into the INVITE. Now,
if the UAS does support symmetric RTP, it returns in the response the IP and
port, with RTP/AVP as the transport, and then indicates a direction of
passive. When the UAC sees this, it begins sending RTP to the IP/port in the
200 OK, and then prepares to receive media on the socket it sent RTP from.

> not support the extension by the lack of the a=direction 

Right! And that was the whole idea, but I fouled it up by putting UDP
instead of AVP into the example SDP. Thanks for pointing it out, Robert.

-Jonathan R.

---

---

From: [email-masked]
Date: Thu, 26 Jul 2001 14:22:17 -0700

Jonathan,

I may have missed something, but I feel that there may be limitations to
the proposed scheme. I am unable to see how 2 SIP devices behind the
same NAT device are going to communicate with each other.

A secondary issue is that you would be exposing private IP addresses
on the outside.

In the port sharing (on the AVT mailing list) case, with a VPN like
tunnel, local calling (2 sip devices behind the same NAT) may require
sending all packets across the WAN link and back.

Shiv
[email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 31 Jul 2001 01:59:43 -0400

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 5:22 PM
> To: Fairlie-Cuninghame, Robert; 'Jonathan Rosenberg'; [email-masked]'

Well, it will work fine, but the media may be routed to the enterprise nat
and back in, when it doesn't really have to be. There are ways to fix that
problem if either the UA or proxy know set of users behind the nat. So, lets
say A calls B through proxy P. A and B are in some enterprise that has a
nat. A allocates an address using the mechanisms specified. The call is
routed out of the enterprise to proxy P. P determines the called party B,
and knows (presumably through configuration) that A and B are behind the
same NAT. If it can recognize the address in the SDP as a public binding, it
can reject the request and inform the caller to retry without the binding. A
similar thing can be done if the UAS recognizes the scenario rather than the
proxy. Lots of assumptions here about detection this case.

I'll note that the problem isn't really specific to this solution. The same
problem would arise if a traditional SIP ALG were embedded in the nat. It
would also arise if a midcom nat were used, and the client or proxy
allocated bindings. It would also arise (and, in fact, be far worse) if VPN
were being used, as the media would not just go to the enterprise nat and
back, but all the way to the vpn server and back. 

An interesting solution might be for the caller (and callee) to always offer
two alternate media streams (using the FID draft), one of which is with its
public address, and another with the private address. If media starts
arriving on the private address, it re-invites to disable the stream on the
public one. Actually, that is probably the most robust and simplest
solution. Not sure FID gives you all the semantics you need for this,
though...

> A secondary issue is that you would be exposing private IP addresses

How is that? The whole idea is that a public address is used in the SDP.

> sending all packets across the WAN link and back.

Yes, as I comment above, it is worse for the VPN case.

-Jonathan R.

---

---

From: John Lazzaro <[email-masked]>
Date: Tue, 31 Jul 2001 10:16:09 -0700

> Jonathan Rosenberg <[email-masked]> writes

> solution. Not sure FID gives you all the semantics you need for this,

Yes, the online gaming world uses this technique and it seems to work  
well, so there's some successful history with the general idea of 
"send to both the public and private address and see what comes back
in the return packets on the same UDP port." Also, if the source 
address on the return packet is neither the public or private address
that a third party has handed you, its an indication that the sender
is behind a NAT that is not a Full Cone NAT, I think (not totally sure).

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------