Subject: [BEHAVE] Summary of TURN open-issues call on 7 Feb 2008

From: Philip Matthews <[email-masked]>
Date: Thu, 7 Feb 2008 17:03:49 -0500

TURN open-issues call on Thursday, 7 Feb 2008

Attendees:
Philip Matthews
Jonathan Rosenberg
Rohan Mahy
Dan Wing
Eric Rescorla
Marc Petit-Huguenin
Derek MacDonald
Remi Denis-Courmond

A big thanks to everyone who dialed in. The discussions were good and  
we reached agreement on a lot of open issues.

*) Unbinding Channels: Do we need a mechanism to remove a channel  
binding?
Two possible reasons for having such a mechanism were discussed. The  
first was a DOS attack by the client against the server where the  
client would allocate lots and lots of channels and consume lots of  
resources on the server. After discussion, it was agreed that we were  
not really worried about this case, since the client needs a username  
and password to use the server and can thus be assumed to be somewhat  
trusted. The second reason, which was felt to be more compelling, was  
a client with a long-lived allocation; the client is not trying to be  
hostile, but without a method of unbinding channels, the client will  
naturally allocate more and more channels and consume resources on  
the server.
The attendees then reached consensus on the following proposal for  
cleaning up unneeded channel bindings:
* The server will only allow unbound channels to be bound. Attempts  
to bind an already bound channel are rejected.
* If a client or server receives a ChannelData msg on an unbound  
channel, the msg is silently discarded.
* A channel becomes unbound some time (perhaps 5 minutes, perhaps  
longer) after its associated permission expires.
On the second bullet point, the attendees discussed whether the  
server should sent an indication to the client that the channel is  
unbound. There was lots of discussion on possible race conditions  
that might produce this condition and why an indication might be  
necessary or very useful, but no clear problem emerged. It was  
finally agreed that the problem could be detected and was probably  
best detected at the application layer (because application data  
would not make it through).
On the first bullet point, it was agreed that unbinding the channel  
immediately when the permission expired might lead to race  
conditions, and waiting for some time afterwards would probably  
eliminate them.

*) Port Adjacency: How can a client allocate an even port number, or  
a pair of adjacent ports?
After the previous call, Cullen e-mailed a proposal to the mailing  
list. In brief, his proposal was that an Allocate request could  
contain either (a) a flag requesting an even port, or (b) a flag  
requesting a pair of adjacent ports. In the latter case, the server  
would return a token which the client could use in an Allocate  
request on a different 5-tuple to allocate the higher numbered port.  
The higher numbered port would be reserved for "at least 30  
seconds" (allowing an implementation to either use a timer, or to  
simply reserve it for the lifetime of the allocation of the lower- 
numbered port).
There was agreement to use Cullen's proposed mechanism.
There was then a discussion on whether a mechanism was needed to  
request the same IP address as a previous allocation, so that related  
video and audio streams would have the same IP address. Aattendees  
were split whether UAs today could handle the streams using different  
IP addresses, but there was a feeling that there might be  
applications (perhaps non-SIP apps) that could not handle different  
IP addresses. So the attendees agreed to a proposal from Jonathan  
that the server should try to allocate subsequent relayed transport  
addresses on the same IP address as the first (if possible). This  
proposal is consistent with the recommendation in RFC 4787 that NATs  
use an "IP Address Pooling" behavior of "Paired".

*) Permission and Allocation Lifetimes:
The attendees agreed to the following two proposals with little  
discussion:
* Permission lifetimes MUST be at least 2 minutes, with a recommended  
value of 5 minutes.
* The spec will NOT include a mechanism for either adjusting or  
learning the permission lifetime.
However, there was no agreement on the following proposal (from Cullen):
* No explicit allocation lifetime; allocation expires 30 seconds  
after the last permission expires.
ACTION: Philip and Cullen to send e-mail to the mail list why they  
thing this last point is desirable.

*) Preserving bits in the IP header
The attendees agreed to the following proposal:
* Do not set the DF bit if possible (some stacks supposedly always  
set this bit)
* ECN bits are not copied
* TTL bits are not copied
* DSCP bits are copied if possible (it seems that some stacks allow  
the DSCP bits to be read, but other do not)
* The document will discuss in detail the implications of the first  
bullet on Path MTU Discovery
The motivation for this proposal has been discussed on the mailing list.
There was a brief discussion on whether to define a forwarding  
behavior which mimics forwarding at the IP layer, but none of the  
attendees was interested in work out or implementing this.
The attendees recognized that no all views on this issue were present  
on the call, and so more discussion on this point might be necessary.

*) Demuxing ChannelData msgs
After some discussion, the attendees agreed to go with the demuxing  
method described in TURN-06 (= the first two bits of a STUN-formatted  
msg are 00).

*) Permission Policy
The attendees re-affirmed the decision to go with an address- 
restricted permission policy. Philip argued that specifying this  
policy was unnecessary because an IT admin would just allow access to  
TURN servers that implemented acceptable policies; others agreed but  
still felt that the address-restricted permission policy should be  
mandatory.

*) Must the server use authentication?
The attendees agreed that the server 'MUST implement and SHOULD use'  
the long-term credential mechanism.

*) Does allocating a channel install/refresh a permission?
The attendees agreed to "Yes".

*) Should an ICMP message be sent in reply if the server discards an  
incoming UDP packet because there is no corresponding permission?
ACTION: Philip to look at what the BEHAVE-ICMP document says.

*) Is it possible to change the password while an allocation is still  
alive?
Rohan has proposed that the document be silent about this, and the  
attendees agreed.

- Philip

_______________________________________________
Behave mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/behave

---

From: "Alfred E. Heggestad" <[email-masked]>
Date: Fri, 08 Feb 2008 10:33:29 +0100

Philip Matthews wrote:
<snip>
> on the call, and so more discussion on this point might be necessary.

I have a suggestion for how to keep the TOS field for outgoing packets
on the external interface;

since not all platforms allow per-packet TOS field, it might be better
and more practical to do it per *session* instead.

Some SIP UAs have a configurable TOS-value for outgoing SIP and RTP
packets. is it likely that this value will change during a session?
No.

So we could add a new TURN attribute TOS-FIELD which contains
an 8-bit value which will be used for all outgoing packets,
from the external interface of the TURN server. This will then
be per session..

/alfred

<snip>

---

From: Philip Matthews <[email-masked]>
Date: Fri, 8 Feb 2008 07:47:16 -0500

> from the external interface of the TURN server. This will then

How do you handle packets traveling from the peer to the client?

- Philip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 8 Feb 2008 15:35:03 +0200

> on the external interface;

On most (all?) platforms, TOS is per-socket, not per-packet. But as long as 
the TOS value can be modified during the socket lifetime, it's as if it were 
a per-packet API.

> since not all platforms allow per-packet TOS field,
> it might be better and more practical to do it per *session* instead.
>

Actually, it is likely. I can very well see why the audio and video flows 
would get a different TOS. Under a model where the server only handles 1:1 
flows, your proposal may make sense. But this was rejected. TURN is going to 
handle 1 client-server flow to N server-peer flows. As such I think your 
assumption is too restrictive, provided we care about TOS.

> from the external interface of the TURN server. This will then

That could actually work, on a per-channel rather than per-allocation basis 
(maybe).

Still... it is clear that some OSes could do per-packet TOS "carry-over", 
without root privileges. It is also clear that some other OSes will not 
support any kind of TOS support.

What's wrong with "In the UDP-to-UDP case, TURN server ××× preserve the TOS 
bits in both directions"? We can debate whether ××× is MUST NOT, SHOULD NOT, 
MAY, SHOULD, MUST.

-- 
Rémi Denis-Courmont

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 13 Feb 2008 14:37:07 -0800

> packets. is it likely that this value will change during a session?

There are some video systems that mark the packets for different parts  
of the video stream with different TOS values. The idea is to try and  
bias things so that the important parts of the video stream are not  
lost (Such as I frames). This would result in changing TOS values in a  
single session.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Feb 2008 11:21:50 +0100

> on the call, and so more discussion on this point might be necessary.

Hi,

Sorry for being quite late on commenting on this. However, this is not
acceptable. You are breaking IP functionality by this stated direction.
I do understand that you are trying to do this in OS userland. But if OS
userland doesn't support what you need to be doing, you can't use userland.

You will need to work through this and for each field find what is
acceptable to do or not. Some of these can probably be made to work in a
compliant way combined with the correct relay behavior.

For example ECN can be correctly handled if the all CE (Congestion
Experienced) marked packets when they arrive are dropped by the relay.
However, that is just as likely not implementable in user-land as
copying the value from incoming to outgoing.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 20 Feb 2008 12:18:29 +0100

On Wed, Feb 20, 2008 at 11:21:50AM +0100,
 Magnus Westerlund <[email-masked]> wrote 
 a message of 54 lines which said:

> You are breaking IP functionality by this stated direction.

I am, as always, very surprised by this argument. NAT breaks IP
functionality. BEHAVE stuff tries to reestablish *some* of the
functionality but it is certainly not realistic to hope that we could
maintain 100 % of the end-to-end experience with BEHAVE protocols,
specially with TURN, which is the furthest away from E2E IP!

IMHO, "keeping IP functionality" is a non-goal.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 20 Feb 2008 13:33:26 +0200

Le Wednesday 20 February 2008 13:18:29 ext Stephane Bortzmeyer, vous avez 
> specially with TURN, which is the furthest away from E2E IP!

Do you know any NAT that does anything *except* one of the the following with 
the TOS bits:
- leave them unmodified, or
- reset them to zero.

Do you know any NAT that does anything *except* one of the the following with 
the TTL:
- decrement it by one unit (and discard the packet if 0), or
- leave it unmodified.

Certainly, if NATs commonly break down upon seeing TOS, we should force them 
to zero. However as a matter of fact, I've been using TOS on my NAT'ed home 
network for the sake of fair queuing, and it works great, and I would rather 
keep it. In any case, it would seem from earlier discussions that some people 
*DO* use TOS with traffic that may eventually be relayed with TURN.

As for IP fragmentation, there are many ways NAT may screw it up, but we 
cannot really ignore the problem.

> IMHO, "keeping IP functionality" is a non-goal.

I thought the goal of TURN was to restore IP functionality.

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Feb 2008 14:23:42 +0100

> IMHO, "keeping IP functionality" is a non-goal.

So you argue that TURN should break things that aren't broken or only 
minor problematic in IP simply because NATs where so badly standardized. 
So any bad thing done previously is a allowing for all future continue 
to do bad things. I don't think so, or at least not on my watch.

Please accept that TURN will not be able to advance until the 
specification explicitly discuss how to threat the IP and transport 
header fields when relaying. And I do expect that these description are 
compatible with the specification of these fields.

Regards

Magnus Westerlund