Subject: [Ietf-behave] RFC3489bis - towards a framework approach

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Oct 2005 14:51:02 -0700 (PDT)

Folks,

Unfortunately, I didnt get around to submitting a much-needed revision 
to rfc3489bis. One of the reasons is that I believe it requires a fairly 
substantive change in structure (though not so much a change on the 
wire), and I wanted to run this by the group.

At this point in time, we actually have several things we are doing with 
STUN, and indeed, when folks say "stun", its not clear what they 
actually mean. STUN refers to any or all of the following:

1. The specific approach to nat traversal in rfc3489 that involves 
determingin your nat type through a test, and then figuring out your 
address on the outside of the nat for use in an offer or answer.

2. The specific request/response protocol that provides a client with a 
mapped address on the other side of the nat.

3. The usage with draft-ietf-sip-outbound which muxes STUN on the SIP 
ports (over UDP and TCP) for the purposes of binding keepalives and 
detection of nat reboots.

4. The usage with ICE whereby a client allocates a candidate for 
inclusion in an offer or answer.

5. The usage with ICE for connectivity checks.

I think its good that we have this general nat traversal tool that is 
finding use inside several other protocols. However, it is beginning to 
be unclear about how these all inter-relate, and what the requirements 
are on the protocol for each of these usages. Indeed, we have small 
variations in what is needed. In case (1) above, the CHANGE-REQUEST 
flags are important, while in others (3,4,5) this flag is not needed. 
ICE, in fact, tells an endpoint to reject a request if the flag is present.

So, what I wanted to do is restructure the spec, so that it is really 
two parts. One is the "STUN Framework". This framework defines the basic 
stun transaction, message encoding, transport. It defines a base set of 
attributes, and two request types (BindingRequest and SharedSecret 
Request). It defines the notion of a usage, which is a concrete use case 
for the stun protocol, and defines requiremetns for usages. Those 
requirements would be definition of new attributes or messages, and 
specification of whether certain attributes are required or need to be 
omitted, how authentication happens, etc.

Then, the spec would define two usages. These are the "Binding 
Acquisition" and the "Connectivity Check". The former usage is how you 
talk to a stun server on the public network, and get an address for 
inclusion in an offer/answer. The latter is the usage we have in 
sip-outbound and ICE, where its used as a keepalive and connectivity 
check, multiplexed on the port of some other protocol.

Other protocols have been structured this way. DIAMETER comes to mind as 
a good example.

I think this change would very much clear up the confusion around what 
STUN actually is, and also allow for the usages we have in ICE and 
sip-outbound in a more clean way. The only way it would change things on 
the wire are the fixes we know we need to make for sip-outboudn and ICE, 
namely:

  a. allowing BindingRequest over TCP
  b. making CHANGE-REQUEST optional in the BindingRequest
So, before I go and do this, I wanted some feedback. Is this a good 
direction to take?

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: David Barrett <[email-masked]>
Date: Fri, 28 Oct 2005 19:54:38 -0700 (PDT)

Hi there, I think this is a great idea.  However, one challenge I've had 
with STUN/TURN/ICE their rather clunky "glued on" feel with respect to 
SIP.  STUN and TURN are similar, but ICE is very different, and SIP even 
more different still.  In my ideal world, SIP would be expanded to 
include all the functionality of STUN/TURN/ICE, within the context of a 
single design/grammar.  Yes, there are valid arguments to keep them 
apart, but I'm making the opposite case.

Granted, this is far outside the scope of what you're proposing, but 
that's my feedback anyway.

-david

Jonathan Rosenberg wrote:
Folks,

Thanks,
Jonathan R.

---

From: Alan Hawrylyshen <[email-masked]>
Date: Fri, 28 Oct 2005 23:10:45 -0700 (PDT)

Jonathan,

I support these changes and think it is a better way to structure the  
protocol description and application notes (if you will) so people  
better pick up on the concepts around STUN. Other than the additional  
work invovled, I think this is a win.

Cheers,

Alan Hawrylyshen
ahawrylyshen@xxxxxxxxxxxxx
Ditech Communications Corp

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 31 Oct 2005 20:20:38 -0800 (PST)

inline.

David Barrett wrote:

Hi there, I think this is a great idea.  However, one challenge I've had 
with STUN/TURN/ICE their rather clunky "glued on" feel with respect to 
SIP.  STUN and TURN are similar, but ICE is very different, and SIP even 
more different still.  In my ideal world, SIP would be expanded to 
include all the functionality of STUN/TURN/ICE, within the context of a 
single design/grammar.
Are you talking literally a grammar, in terms of syntax? Or something 
else? Perhaps my perspective is tainted by my closeness to the work, but 
I don't really see how ICE could be done much differently from a call 
flow perspective. Maybe we could have simplified the RTP/STUN demux, 
that is true, but I'm not sure what else.

I will say that, had I the ability to do it over again, I would have 
made all of this nat traversal stuff part of the baseline specs, rather 
than something we did afterwards. From my perspective, sip-outbound and 
ICE are really essential parts of the protocol, and any implementation 
that is not doing them should be viewed as missing a major part of the 
protocol. But, SIP was developed at IETF back in the days when NATs were 
largely ignored in IETF, and so here we are...

-Jonathan R.