Subject: [Sip] Proposed change in draft-ietf-sip-nat

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jun 2002 01:06:45 -0400

Folks,

I would like to propose a change in draft-ietf-sip-nat.

Right now, this document specifies two very independent and orthogonal
things. One of them is the rport parameter. This is a Via param that
makes sure that the SIP response gets routed back to the source IP and
port where the request came from. Without it, SIP over UDP doesn't work
through any NATs. It allows SIP to work like most other protocols in
terms of its port usage. I think its uncontroversial and should move 
forward as is.

THe other aspect is the Translate header. Its aimed at making 
registrations work through NAT. However, there are several problems with 
the Translate header right now:

1. It "competes" with other solutions, such as STUN and TURN/SPAN, which 
would allow for incoming INVITEs through NAT without any SIP specific 
extensions.

2. It tries to optimize for the full-cone case, by including a parameter 
that indicates whether the client is behind a full-cone or symmetric 
NAT. I would rather not pollute SIP with this kind of NAT-specific 
stuff; rather, relegate it to STUN/TURN.

3. UDP registrations through NAT are really troublesome. They require 
very frequent re-registrations to maintain the binding (under a minute). 
This poses a serious load. If you have to use UDP, a STUN or TURN 
solution is much better, since refreshes of the NAT bindings would occur 
through those protocols, rather than SIP, and they scale much better. 
So, if you consider TCP (which works even better still, since you don't 
need to refresh the registration in order to keep the binding active), 
the problem is not really translating the contact header as it is TCP 
connection reuse for incoming requests. Indeed, the same problem occurs 
in record-routing - you want to be able to specify to your peer to reuse 
the connection for incoming requests. Thats not even a nat-specific 
thing; its just a capability that, if we had a better story on, would be 
useful for NAT.

As a result, I would propose that draft-ietf-sip-nat move forward with 
just the rport stuff, and we look at the registration problem 
separately. I would like a solution for SIP that didn't depend on 
STUN/TURN, but I have convinced myself that this solution needs to be 
TCP-based, and that it is best viewed as a problem of connection reuse. 
ROhan has posted a requirement draft on that topic.

Flame away....

-Jonathan R.

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

_______________________________________________
Sip mailing list  https://www1.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: "David R. Oran" <[email-masked]>
Date: Fri, 28 Jun 2002 08:43:24 -0400

I think this is a reasonable way forward. The less NAT-specific stuff we 
embed in SIP itself the more likely generic solutions will make their way 
into the market, and the less baggage we add to SIP itself.

Dave.

--On Friday, June 28, 2002 1:06 AM -0400 Jonathan Rosenberg 
<[email-masked]> wrote:

> that indicates whether the client is behind a full-cone or symmetric NAT.
> I would rather not pollute SIP with this kind of NAT-specific stuff;
> rather, relegate it to STUN/TURN.
>
> through those protocols, rather than SIP, and they scale much better. So,
> if you consider TCP (which works even better still, since you don't need
> to refresh the registration in order to keep the binding active), the
> problem is not really translating the contact header as it is TCP
> just the rport stuff, and we look at the registration problem separately.
> I would like a solution for SIP that didn't depend on STUN/TURN, but I
> have convinced myself that this solution needs to be TCP-based, and that
> it is best viewed as a problem of connection reuse. ROhan has posted a
> requirement draft on that topic.
>
> Flame away....
>
> -Jonathan R.
>
>
>
>
> --

-----------------------------------------------------------
David R. Oran                   Phone/Fax: +1 978 264 2048
Cisco Systems                   VoIP: +1 408 571 4576
7 Ladyslipper Lane              Email: [email-masked]
Acton, MA 01720

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 28 Jun 2002 10:16:25 +0100

Sounds reasonable except that to be in line with the pre-midcom / midcom
work all references to TURN should be to SPAN (Simple Protocol for
Augmenting NATs), at least for the time being.

For those that are interested, a candidate for SPAN is at:

http://www.ietf.org/internet-drafts/draft-cordell-midcom-span-a-00.txt

But be advised that this is iteration 1 and so subject to change.

Pete.

---

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 28 Jun 2002 11:08:46 -0700

One point about UDP registrations, I don't know if you really need to send a
true registration, you can just send any message that creates minimal load
on the proxy. For example the UA could send a single CRLF to the proxy. The
proxy could have some code to silently ignore any message that is clearly
too short to be a valid SIP message. Obviously this won't work in the cases
where the UA sends to a proxy inside the NAT then the proxy sends to a
another proxy outside the NAT. It also has the problems with no response so
you don't know if the message made it to the NAT or not.

Do folks see this as an ideal worth pursing or a really bad idea that we
should suggest people don't do?

Cullen

---

From: "Cullen Jennings" <[email-masked]>
Date: Fri, 28 Jun 2002 11:35:12 -0700

My read of the SPAN document was it did not even represent consensus of the
design team much less the midcom WG.

Why should references to TURN or SPAM be changed to just SPAN?

Thanks, Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Pete
> Cordell
> Sent: Friday, June 28, 2002 2:16 AM
> To: Jonathan Rosenberg; [email-masked]
> Subject: Re: [Sip] Proposed change in draft-ietf-sip-nat
>
>

---

From: Sean Olson <[email-masked]>
Date: Fri, 28 Jun 2002 11:43:10 -0700 (PDT)

This seems to have too many holes. 
However, it *might* be useful to define a
lightweight SIP keep-alive mechanism.

/sean

--- Cullen Jennings <[email-masked]> wrote:
> Sip mailing list 
> https://www1.ietf.org/mailman/listinfo/sip

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jun 2002 16:25:08 -0400

> design team much less the midcom WG.

Correct.

> Why should references to TURN or SPAM be changed to just SPAN?

More importantly, this issue is totally irrelevant to this thread. 
Draft-ietf-sip-nat will have references to neither TURN, nor SPAN, nor 
STUN. Connection reuse has nothing to do with it either. THe only place 
TURN/SPAN/STUN should show up is the nat-scenarios document. That one is 
on the backburner until these issues are sorted out, and is not what 
this thread is about in any case.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Jun 2002 16:32:03 -0400

The holes that this "CRLF approach" has are similar to some of the 
generic problems of STUN, which I would prefer be kept isolated there. 
THe main one really is that the frequency of the refreshes is dependent 
on the binding lifetime; that is not generally known, either to the UA, 
or the registrar. TCP works better there. Because TCP connections have 
an explicit teardown, they are held in NATs for a long time without 
keepalives.

There is also the needless network traffic from these 1 byte UDP packets 
flying around (with 8 bytes UDP, 20 bytes IPv4 headers), a huge waste.

-Jonathan R.