Subject: Re: [BEHAVE] DF bit in TURN

From: Philip Matthews <[email-masked]>
Date: Wed, 6 Feb 2008 16:09:26 -0500

Marc: Many thanks for doing this investigation!

As I see it, here are the relevant points in this discussion:
* We don't know a way to read the DF bit on a received packet without  
using RAW sockets (which requires root privileges)
* Requiring root privileges is undesirable for P2P apps, but might be  
acceptable for a stand-alone server
* Always setting the DF bit will result in large UDP packets (e.g.  
SIP msgs) always getting dropped.
* Forwarding packets at the IP layer (which Marc mentioned) also  
requires RAW sockets.

So here is my new strawman proposal:
* In normal operation, a TURN server does not set the DF bit when  
sending over UDP (either to the client or to the peer).
* An application using TURN that wants to ensure that its packets are  
not fragmented must keep its packet size below 576 bytes.
* A TURN server MAY choose to do IP layer forwarding on UDP-to-UDP  
connections; in this case, it should preserve the DF bit when  
forwarding.

By not setting the DF bit, a TURN server is following the principle  
of "maximize the chances of getting the application data through"  
which is the whole point of TURN in the first place. An application  
on the client or the peer doing 4821 will not determine the Path MTU,  
but will determine the maximum UDP packet size that will be delivered  
to the remote destination; the resulting UDP datagram might get  
fragmented, but it will be delivered. The result may not be optimal,  
but TURN is not really optimal anyway.

A TURN server that wants do provide a "high-quality" service may  
choose to do IP layer forwarding using RAW sockets. This would mean  
that 4821 would determine the actual Path MTU. Though complex to  
implement, I think it is do-able. I would be interested in hearing  
from those interested in this option, and of any attempts to  
implement it.

Comments?

- Philip

On Tue, 5-Feb-08, at 13:05 , Marc Petit-Huguenin wrote:

> To understand the problems with the bits to preserve in the IP header
> when tunneling through TURN, I tried to implement something that  
> use the
> DF bit.  My idea was that two endpoints exchanging video over
> RTP/UDP/IPv4 would certainly benefit of using RFC 1191 and RFC 4821 to
> find the PMTU in each direction and use it to adjust the maximum  
> size of
> the RTP packets that can be sent.  I am assuming that both  
> endpoints are
> using ICE, so they both contain a STUN client and a STUN server for  
> the
> connectivity checks.  It is then easy to implement PMTU discovery by
> using something like a Echo transactions with the PADDING attribute[1]
> as probes.
>
>  From the point of view of the endpoint using TURN there is two cases,
> PMTU discovery from this endpoint to the other endpoint, and PMTU
> discovery from the other endpoint to this endpoint.
>
> It is assumed that both the TURN client and the TURN server know the
> PMTU inside the tunnel in each other direction, i.e. for TCP or TLS it
> would be something like 65535 minus various headers and for UDP it can
> be discovered by the same algorithm than described above.
>
> The simplest case is PMTU discovery from the endpoint behind the TURN
> tunnel to the other endpoint.  The STUN client behind the TURN client
> sends a probe, the TURN server relays it to the other endpoint (peer)
> after setting the DF bit.  If a router on the path between the TURN
> server and the peer drops the packet because it would be fragmented,
> then the RFC 4821 algorithm will work.  If a router sends back an ICMP
> Packet Too Big then it will be dropped by the TURN server, and the RFC
> 4821 algorithm will also work.  There can be two improvements that can
> be done in the TURN protocol to help; firstly to add a way for the  
> TURN
> client to set the value of the DF bit that will be used to forward the
> packets to the peer and secondly to tunnel the ICMP packets  
> received by
> the TURN server to the TURN client.
>
> Now a more difficult case is PMTU discovery from the other endpoint to
> the endpoint behind the TURN tunnel.  The TURN server will receive a
> packet from the peer with the DF bit set, but a TURN server running in
> userland cannot retrieve the value of this bit.  If the transport
> between the TURN server and the TURN client is TCP this is not a
> problem,  the tunnel PMTU been close to 65535 there is no reason to  
> send
> an ICMP Packet Too Big or to drop the packet.  But if the transport  
> used
> is UDP, then the TURN server is supposed to send an ICMP Packet Too  
> Big
> or to drop the packet if the DF bit is set, or to send it  
> fragmented to
> the TURN client if the DF bit is not set.  And this is the second
> problem, there is no way in TURN to fragment the packet between the  
> TURN
> server and the TURN client.  It is certainly possible to extend  
> TURN to
> do that, but it does not solve the problem that a userland application
> cannot test the DF bit in a received packet.  There is also, AFAIK, no
> way to send an ICMP packet after receiving a UDP packet in  
> userland, but
> this is less a problem, as simply dropping the packet would work with
> RFC 4821.
>
> A simple alternative to this mess would be to tunnel IP packets over
> TURN instead of UDP packets.  This would solve the DF problem and also
> the problems for the other IP header bits, but it left open the  
> problem
> of TCP[2] between the TURN server and the peer (additionally to the
> problem that the TURN server needs to be root).
>
>
> [1] draft-ietf-behave-nat-behavior-discovery
> [2] http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf
>
> -- 
> Marc Petit-Huguenin           [                                 ]
> Home: [email-masked] [RFC1855-compliant space for rent ]
> Work: [email-masked]            [                                 ]
> [                                                               ]
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/behave
>

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 06 Feb 2008 14:23:45 -0800

At Wed, 6 Feb 2008 16:09:26 -0500,
> acceptable for a stand-alone server

This isn't an issue primarily of root privileges. If you're using
raw sockets you are rquired to do the transport layer. This is
totally prohibitive if that's TCP.

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Wed, 6 Feb 2008 17:40:55 -0500

> totally prohibitive if that's TCP.

I agree that we would only want to use RAW sockets for UDP packets.

- Philip