Subject: [tram] Points that should be clarified in STUN-bis and TURN-bis

From: Jonathan Lennox <[email-masked]>
Date: Fri, 7 Feb 2014 19:39:16 +0000

I'm in the middle of doing a TURN client implementation from scratch, which gives me the opportunity to note several items that I think should be clarified as TRAM works on STUN-bis and TURN-bis.

Some of these are statements, based on what I think are obvious conclusions about how the protocols should behave; some are questions.  Answers, or disagreement, are welcome for any or all of them.

I haven't cleanly separated STUN and TURN issues here.

Questions:

1. If a STUN (TURN) client receives a "300 Try Alternate" response to a STUN request sent over TLS, it should then connect to a different STUN server over TLS.  What subjectAltName should it expect in the redirected-to server's certificate?

2. What behavior is expected if a TURN ALLOCATE request does not contain a REQUESTED-ADDRESS-FAMILY (RFC 6156) attribute?  Is the server expected to allocate an IPv4 address (since RFC 5766 explicitly says it only discusses IPv4 addresses), or is it at the server's discretion?

3. What should a TURN server's behavior be if it receives a CreatePermission request with multiple XOR-PEER-ATTRIBUTE addresses, and some (but not all) of the addresses are administratively forbidden?  Should it create or refresh permissions for the subset of the destinations that are allowed, despite sending a 403 Forbidden response, or should its operation be atomic (meaning if any are rejected, none are refreshed)?

3a. Relatedly: do we want to add an informational CreatePermission response attribute listing which addresses were forbidden?

4. How should TURN channel de-framing be done if a TURN entity receives a message with a channel ID in the reserved range (0x8000 - 0xffff) over TCP or TLS?  The size of the frame differs depending on whether the message is a TURN message (length+20) or a ChannelData message (length+4, rounded up to a multiple of 4).  There's no obvious reason to expect any particular length formula for items in the reserved range, unless we specify one preemptively.  However, the spec says that an implementation MUST NOT assume that a TURN message always starts with a 0 bit.

Statements:

1. Since all TURN requests must be authenticated, any TURN request can receive a 401 or 438 response, which should be handled in the same manner as described in the TURN spec for the Allocate request.  (401 would normally only happen when the credentials provisioned for the user are changed.)

2. The REQUESTED-ADDRESS-FAMILY attribute (RFC 6156) may be used for TURN/TCP allocations (RFC 6062), if a TURN server supports both mechanisms. (Neither of these documents normatively cites the other, though RFC 6156 notes that TURN can be used to request address/port pairs for receiving TCP.)

3. Nonces are independent for different STUN servers.  STUN clients using long-term credentials should normally expect to receive a 438 Stale Nonce response to the request they send after a 300 Try Alternate redirection, unless they've previously been redirected to that address and already know a nonce to use.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 07 Feb 2014 15:05:44 -0500

Jonathan,

This is great input, thanks! Let's see if we can file issues in our Trac
project so that we don't forget...

A quick remark about this item:

Le 2014-02-07 14:39, Jonathan Lennox a écrit :
> 2. What behavior is expected if a TURN ALLOCATE request does not
> contain a REQUESTED-ADDRESS-FAMILY (RFC 6156) attribute?  Is the
> server expected to allocate an IPv4 address (since RFC 5766
> explicitly says it only discusses IPv4 addresses), or is it at the
> server's discretion?

Answer: It must create an IPv4 allocation.

Remark: In TURN bis I would want clients to *always* send
REQUESTED-ADDRESS-FAMILY. That does not necessarily imply merging TURN
with TURN-IPv6, but it's an option I would consider.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 7 Feb 2014 12:58:48 -0800

Still we want a default behavior when a client (legacy ?) does not send
REQUESTED-ADDRESS-FAMILY (which is IPv4). I do not see any good reason to
introduce a backward incompatibility for the legacy clients unless there is
a good really important security reasons. I do not see any security problem
with the default behavior.

On Fri, Feb 7, 2014 at 12:05 PM, Simon Perreault <
[email-masked]> wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Simon Perreault <[email-masked]>
Date: Fri, 07 Feb 2014 16:15:08 -0500

Le 2014-02-07 15:58, Oleg Moskalenko a écrit :
> REQUESTED-ADDRESS-FAMILY (which is IPv4). I do not see any good reason
> to introduce a backward incompatibility for the legacy clients unless
> there is a good really important security reasons. I do not see any
> security problem with the default behavior.

I phrased my wish very carefully:

"In TURN bis I would want clients to *always* send
REQUESTED-ADDRESS-FAMILY."

Note that I did not say anything about server behaviour. Intentionally. :)

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 7 Feb 2014 13:19:33 -0800

Well... OK. If we want the client always to send the address-family - but
we do not enforce that on the receiving side... that sounds awkward,  like
a speed limit without cops. It is great - but does that strict requirement
make sense without enforcement ? We can always say that TURN client SHOULD
send the address-family, but MUST probably would be too strict... I guess.

On Fri, Feb 7, 2014 at 1:15 PM, Simon Perreault <[email-masked]
> wrote:

---

From: Simon Perreault <[email-masked]>
Date: Fri, 07 Feb 2014 16:50:05 -0500

Le 2014-02-07 16:19, Oleg Moskalenko a écrit :
> Well... OK. If we want the client always to send the address-family -
> but we do not enforce that on the receiving side... that sounds
> awkward,  like a speed limit without cops. It is great - but does that
> strict requirement make sense without enforcement ? We can always say
> that TURN client SHOULD send the address-family, but MUST probably would
> be too strict... I guess.

The idea is: first, we specify that TURN bis clients MUST send
REQUESTED-ADDRESS-FAMILY. Then we specify TURN bis server behaviour
depending on the value of REQUESTED-ADDRESS-FAMILY. We do *not* specify
TURN bis server behaviour when that parameter is absent. If the
parameter is absent, the client is not following the TURN bis spec, and
the server is free to behave however it wants. That includes *wink wink*
being backward-compatible with TURN.

This is exactly like the STUNv2 magic cookie: STUNv2 clients MUST send
the magic cookie, and STUNv2 server behaviour is defined when the cookie
is present. But STUNv2 does not specify server behaviour when the cookie
is absent. The cookie being absent means the client is not a STUNv2
client. The server is free to behave however it wishes. That includes
*wink wink* being backward-compatible with STUNv1.

Simon

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 7 Feb 2014 14:08:30 -0800

OK, that's fine.

Oleg

On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault <[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 09 Feb 2014 13:24:39 -0500

Shouldn't backward compatibility of TURN-bis servers with TURN clients 
be *mandatory*, rather than optional?

	Thanks,
	Paul

On 2/7/14 5:08 PM, Oleg Moskalenko wrote:
> OK, that's fine.
>
> Oleg
>
>
> On Fri, Feb 7, 2014 at 1:50 PM, Simon Perreault
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 9 Feb 2014 16:15:14 -0800

I am not sure whether we want a very strict language here.

This is about how the TURN server will react in case of missed
REQUESTED-TRANSPORT attribute. There may be three ways to react:

1) Respond with IPv4 relay endpoint (the current TURN way of doing things);
2) Reject the request (strict enforcement of REQUESTED-TRANSPORT attribute);
3) Respond with IPv6 relay endpoint (may make sense in some networks with
heavy IPv6 infestation, like mobile networks).

The new standard (TURN-bis) may have three options for the TURN server:

1) Keep the 1st way (as in current TURN) as backward-compatible solution;
2) Require that the client always includes that attribute and the TURN
server rejects the request if not;
3) Make the behavior undefined (as Simon suggests).
4) Make the behavior configurable.

I can see a sense in options 1 and 3. The first option is 100%
backward-compatible and that's good. The third option allows legacy TURN
clients in networks where IPv6 is the default protocol (if the legacy
client is IPv6 - aware) and leaves the decision to the TURN server
administrator or implementation. I am not sure about the fourth option - it
may impose unnecessary complication on the implementation.

But I am against the option 2. It is too harsh and it introduces mandatory
backward incompatibility.

Oleg

On Sun, Feb 9, 2014 at 10:24 AM, Paul Kyzivat <[email-masked]> wrote:

> Shouldn't backward compatibility of TURN-bis servers with TURN clients be
> *mandatory*, rather than optional?
>
>         Thanks,
>         Paul
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 09 Feb 2014 21:44:31 -0500

IMO only (1) makes sense. With the others, migration becomes a 
nightmare. No flag days!

	Thanks,
	Paul

On 2/9/14 7:15 PM, Oleg Moskalenko wrote:
> 3) Respond with IPv6 relay endpoint (may make sense in some networks
> with heavy IPv6 infestation, like mobile networks).
>
> administrator or implementation. I am not sure about the fourth option -
> it may impose unnecessary complication on the implementation.
>
> But I am against the option 2. It is too harsh and it introduces
> mandatory backward incompatibility.
>
> Oleg
>
>
>
>
>
>
> On Sun, Feb 9, 2014 at 10:24 AM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Shouldn't backward compatibility of TURN-bis servers with TURN
>     clients be *mandatory*, rather than optional?
>
>              Thanks,
>              Paul
>
>
>         <[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
>
>               > awkward,  like a speed limit without cops. It is great -
>         but does
>              that
>              DTN made easy, lean, and smart -->
>         http://postellation.viagenie.__ca <http://postellation.viagenie.ca>
>              _________________________________________________
>              tram mailing list
>         [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>
>         https://www.ietf.org/mailman/__listinfo/tram
>         <https://www.ietf.org/mailman/listinfo/tram>
>
>
>
>
>
>         _________________________________________________
>         tram mailing list
>         https://www.ietf.org/mailman/__listinfo/tram
>         <https://www.ietf.org/mailman/listinfo/tram>
>
>
>     _________________________________________________
>     tram mailing list
>     https://www.ietf.org/mailman/__listinfo/tram
>     <https://www.ietf.org/mailman/listinfo/tram>
>
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Feb 2014 09:21:26 -0500

> be *mandatory*, rather than optional?

In my experience that's not how I've see IETF specs handle backward
compatibility. See STUNv1 vs STUNv2 for an example.

Now, what I do feel strongly about is that TURN-bis should not make it
impossible for a server to be backward-compatible if it wants to.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Feb 2014 09:27:48 -0500

> IMO only (1) makes sense. With the others, migration becomes a

Option 1 means there is no migration at all. You're stuck with the past
forever.

Option 3 means you don't have to keep backward compatibility around
forever. Practically, all TURN-bis servers would be backward compatible
from day 1. Then as time passes the client population would gradually
migrate to TURN-bis. When the non-TURN-bis client population becomes too
small to justify the cost of backward compatibility, you can throw
compat away. For example, if you start a new implementation of STUN
today, it could be possible to ignore STUNv1 (depending on your target
market), and thus make the implementation smaller, simpler, easier to
test, and faster to develop.

Simon

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2014 10:18:28 -0500

> test, and faster to develop.

It would be more of an issue of there was a real issue if there was a 
significant cost to supporting backward compatibility. But IIRC, the 
only cost for backward compatibility here is filling in a standard 
default if the parameter is missing.

The consequence of not requiring backward compatibility is that a 
developer does exactly as you describe above - ignore STUNv1 
compatibility in his server because he thinks his target market won't 
need it. Then it turns out that there is a STUNv1 client. And that 
client just fails because of this.

	Thanks,
	Paul

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 10 Feb 2014 16:19:12 +0000

I agree with Paul.

That said, I could potentially see a use case for allowing servers to select option (3) -- but if we want to support that, we should define a *new* TURN attribute that indicates that the client is giving the server the freedom to pick the relay's address family.

On Feb 9, 2014, at 9:44 PM, Paul Kyzivat <[email-masked]>
 wrote:

> IMO only (1) makes sense. With the others, migration becomes a nightmare. No flag days!
> 
> 	Thanks,
> 	Paul
>

---

From: Simon Perreault <[email-masked]>
Date: Mon, 10 Feb 2014 11:37:13 -0500

> default if the parameter is missing.

You are correct in this particular instance, of course. In general,
things may be different.

> client just fails because of this.

Correct. And then either 1) the developer realizes that this STUNv1
client is important enough to warrant additional development, or 2) the
developer says "tough luck" to the client, and the client's only
recourse it to upgrade to STUNv2. IMHO, that's exactly the kind of
thinking that we want to encourage! :)

Anyway, we're just philosophizing, this has no practical impact on
anything at this point.

Simon

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2014 11:54:42 -0500

> You are correct in this particular instance, of course. In general,

My philosophy is to start out assuming backward compatibility.
If something is found that makes that much of a burden, then discuss 
what to do about it.

> thinking that we want to encourage! :)

If the new thing isn't compatible with TURNv1 then call it something 
different, so that the process of discovering a TURN server only gets 
the appropriate kind.

> Anyway, we're just philosophizing, this has no practical impact on

Sure.

	Thanks,
	Paul