Subject: [BEHAVE] Conf call on TURN scheduled

From: Philip Matthews <[email-masked]>
Date: Mon, 21 Jan 2008 15:14:32 -0500

The conf call on TURN is now scheduled for Monday, 28 Jan at the  
following time:
11 - 13 Pacific / 14 - 16 Eastern / 21 - 23 Finland

Bridge information will be sent out tomorrow.

This call is open to anyone who wishes to attend. However, I would  
really appreciate it if you would RSVP if you plan to attend, so I  
can make sure the bridge will have enough capacity.

The goal of the call is to discuss the open issues in TURN-06.

- Philip

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

---

From: Philip Matthews <[email-masked]>
Date: Tue, 22 Jan 2008 12:02:45 -0500

A small change from what I said yesterday.

The call is open to anyone who wishes to attend. However, I ask that  
you send me an e-mail if you are interested in joining this call, and  
I will then send you the information on how to join.

- Philip

---

From: "Rohan Mahy" <[email-masked]>
Date: Mon, 28 Jan 2008 13:04:17 -0800

On the call we had a question about whether the DF bit can be set by
applications on common OSes.  The following tool, allegedly allows user
control over the DF bit and runs on UNIX, Mac, and Windows.

http://www.hping.org/

thanks,
-rohan

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jan 2008 13:50:10 -0800

At Mon, 28 Jan 2008 13:04:17 -0800,
> control over the DF bit and runs on UNIX, Mac, and Windows.

Looks to me like it uses raw sockets. There are lots of tools
that allow fine control of the IP header (e.g., traceroute)
as long as you can use raw sockets.

Unfortunately, raw sockets have two disadvantages:
      
(1) It requires being root on most UNIXes, at least.
(2) It means you need to reimplement the entire transport protocol
    in your app. This is no big deal for UDP, but for TCP, not
    so much.

-Ekr

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 29 Jan 2008 10:03:32 +0200

Hello,

As promised during the telco:
Note that I am only considering plain application-layer non-privileged 
sockets, here.

Linux sets the DF bits according path MTU per-socket setting, which can accept 
for different values (from man 7 ip):

  Path MTU discovery flags   Meaning
  IP_PMTUDISC_WANT           Use per-route settings.
  IP_PMTUDISC_DONT           Never do Path MTU Discovery.
  IP_PMTUDISC_DO             Always do Path MTU Discovery.
  IP_PMTUDISC_PROBE          Set DF but ignore Path MTU.

IP_PMTUDISC_WANT is the default, which basically defers to the routing table. 
By default and in most cases, that enables Path MTU discovery, as 
IP_MTUDISC_DO.

The purpose of IP_PMTUDISC_PROBE is to allow userland software to do path MTU 
probing by themselves.

It is also possible to read the current estimate of the Path MTU (IP_MTU 
getsockopt), or to try to check if a message of a given size is sufficiently 
small (MSG_PROBE send flag).

As for DSCP resp. TTL, they can be set on a per-socket basis (IP_TOS resp. 
IP_TTL setsockopt). ECN bits cannot be set manually.

With UDP *only*, TTL resp. DSCP bits of incoming packets can be received 
(IP_RECVTTL resp. IP_RECVTOS setsockopt); this obviously does NOT work for 
TCP.

-- 
Rémi Denis-Courmont

---

From: Lars Eggert <[email-masked]>
Date: Tue, 29 Jan 2008 14:26:17 +0200

> Unfortunately, raw sockets have two disadvantages:
...
>    in your app. This is no big deal for UDP, but for TCP, not

Well, you could use something like BSD divert sockets to intercept  
kernel-generated IP packet, diddle bits at in an app and reinject them  
using RAW sockets, but that's ugly.

Lars

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Tue, 29 Jan 2008 14:53:45 +0200

> using RAW sockets, but that's ugly.

BSD divert sockets, and Linux packet sockets have all kind of cool features, 
such as kernel-level filtering using BPF, and memory mapped I/O with ring 
buffers for high performance logging. It would work.

For unfragmented UDP packets, it's even not that complicated.

For TCP (or UDP fragments), it's not "ugly", it's an horrible awful hack, 
taking into account that you may have to do TCP re-assembly, and then demux 
TURN control messages, and channels stuff. Basically, it's like an 
transparent ALG, but more complicated. I guess that's what EKR was hinting 
at.

And then comes the problem of preventing the "regular" IP stack from answering 
the packets - if you don't use the normal API, it will think the port is not 
allocated and send a ICMP Port Unreachable or TCP/RST back. So you have to 
mess up with the firewalling framework, and/or the normal socket API too. 
Though one could argue that once you've gone to the pain of divert sockets, 
these is not that much extra hacking.

In any case, while I have no immediate use case for TURN on a "client" box, I 
reckon some folks want to deploy TURN servers as normal unprivileged 
software, to run some kind of peer-to-peer overlay. In this case, they can 
neither require privileges, neither extend the existing stack.

I think the spec should say what the TURN servers SHOULD do with these 
controversial bits, but it would be unrealistic that they MUST do that, lest 
there be many non-conformant TURN servers.

-- 
Rémi Denis-Courmont

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Wed, 30 Jan 2008 09:38:21 +0200

> (IP_RECVTTL resp. IP_RECVTOS setsockopt); this obviously does NOT work for

Woops. ECN bits can be set manually, for UDP, just as DSCP, i.e. you can set 
all of the 8 TOS bits. However, values of 0xA0 and above (historically 
critical precedence and higher), are reserved for root.

ECN bits can however NOT be set for TCP - any attempt to set them will be 
ignored. Only the higher 6 order bits of TOS can be set in this case, subject 
to the same restriction as above.

-- 
Rémi Denis-Courmont