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

From: "Francois Audet" <[email-masked]>
Date: Fri, 28 Oct 2005 15:27:08 -0700 (PDT)

Make sense to me.

Wouldn't it be better to say "STUN Protocol" instead of "STUN
Framework"?
I like "STUN Usage" for the second part.

PS: ICE refers to RFC 3489. I believe it should refer to rfc3489bis.

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Jonathan Rosenberg
> Sent: Friday, October 28, 2005 14:51
> To: Behave
> Subject: [Ietf-behave] RFC3489bis - towards a framework approach
> 
> 
> 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 _______________________________________________
> Ietf-behave mailing list
> Ietf-behave@xxxxxxxxxxxxxxxxxxx 
> https://list.sipfoundry.org/mailman/listinfo/ietf-behave
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 28 Oct 2005 19:46:24 -0700 (PDT)

First a Chair comment ....

We have a Jul 05 deliverable for a revision of STUN. This is important work.
I hope everyone can give Jonathan the input he need so this can get done
quickly.

Second a individual contributor comment ...

Framework always sounds sort of complicated but ignoring that, when I think
about the key changes needed here I see

* make it so a server is allowed to run on only one IP address (but may
still do two)

* allow binding requests over TCP

I think both of these are fine ideas. Perhaps framework is way to go -
Perhaps it could be done by defining one protocol called STUN, then defining
STUN servers, then defining a new type of special server called a STUN-TEST
server that is exactly a STUN server except it MUST have two IP addresses
and support the CHANGE-REQUEST flags.

That's my 2 cents but I agree with what you are proposing.

Cullen

On 10/28/05 3:27 PM, "Francois Audet" <audet@xxxxxxxxxx> wrote:

> _______________________________________________
> Ietf-behave mailing list

---

From: Saikat Guha <[email-masked]>
Date: Fri, 28 Oct 2005 23:47:20 -0700 (PDT)

> * allow binding requests over TCP

I agree. This is the primary functionality required for TCP NAT
traversal.

Some considerations: RFC3489 requires that the TCP port reserved for
STUN be used for TLS encoded Shared Secret exchanges; the same port
number for UDP is used directly for binding discovery. TCP bindings
could be sent to (i) a different (new) reserved port, or (ii) to the old
port with the server figuring out whether it is a binding request or a
TLS session initiation (ugh), or (iii) to a new port discovered over the
TLS session or (iv) over TLS to the old port (both bad ideas
latency-wise).

-- 
Saikat
Attachment:
signature.asc

---

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

Francois Audet wrote:

Make sense to me.

Wouldn't it be better to say "STUN Protocol" instead of "STUN
Framework"?
I like "STUN Usage" for the second part.
I latched onto framework because the idea was, you couldn't use the 
framework directly - you needed an usage to tell you how.

PS: ICE refers to RFC 3489. I believe it should refer to rfc3489bis.
Yes. I havent done that yet.

-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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 31 Oct 2005 20:13:35 -0800 (PST)

inline.

Cullen Jennings wrote:

I think both of these are fine ideas. Perhaps framework is way to go -
Perhaps it could be done by defining one protocol called STUN, then defining
STUN servers, then defining a new type of special server called a STUN-TEST
server that is exactly a STUN server except it MUST have two IP addresses
and support the CHANGE-REQUEST flags.
Unfortunately its a bit more complicated than that; things like security 
bootstrapping differ amongst these usages, IP address and port discovery 
too.

-Jonathan R.

---

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

inline.

Saikat Guha wrote:

Yes, this has been one of the few remaining open issues in TURN for some 
time, which has the same problem since it allowed TCP-based bindings to 
be allocated.

I kind of prefer option (i); as you say its the easiest. My only 
hesitation is that I know there tends to be reluctance in allocating 
separate ports for protocols just because they run over tls. But I 
suppose the idea is that there are really two sub-protocols here - a 
password allocation protocol and a binding allocation protocol, and that 
its THOSE we are running on different ports. Indeed, if you want to run 
a Binding Request over TCP/TLS, you would need TLS for both sub-protocols...

-Jonathan R.