Subject: [BEHAVE] TCP TURN transport with UDP to peers

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 25 Mar 2008 22:58:38 -0400

Howdy,
draft-ietf-behave-turn-07.txt, which is purely for UDP transport on the TURN-to-peer side, allows the TURN connection between a TURN client and the TURN server to be TCP or TLS/TCP.  The stated reason is:
   ...TURN allows both TCP and TLS over TCP
   as transports in part because many firewalls are configured to not
   pass any UDP traffic.

I find that reasoning disturbing.  One almost expects the next sentence to say "The TURN server listen port should be the STUN one (3478), but if that doesn't work, then try ports 80, 443, 25, 23, ...".  :)

Subverting the policies of a firewall is not a good model.  We should not be in the business of creating standard mechanisms to subvert firewall policies, because it is a losing game.  I realize there are poorly provisioned firewalls, such as those in hotels, which would let UDP work if they were better managed - they aren't blocking it on purpose.  But there is no way for a client to guess as to the rationale of the firewall policies in place, for good or ill.  I believe corporate VPN software which mostly uses UDP encapsulation of IPSEC is driving them to open UDP more anyway, or provide "click here for a public IP" type options when signing in to the hotel portal.

Furthermore, I don't actually think it really works as defined, for general applications.  There is only lip-service paid to how application data over a TCP TURN connection would work to a UDP peer connection.  For example, let's say someone were to run SIP over TURN.  Per RFC 3261, SIP behaves differently on a reliable transport (TCP), than an unreliable one (UDP).  So let's say I send a SIP INVITE.  The TURN server gets it, and its TCP stack sends an ACK.  I believe it's delivered.  The TURN server then sends it over UDP and for some reason it got lost.  Who retransmits it?  The TURN server doesn't, and my SIP client doesn't.  Whereas for RTP that's ok.  Generally, switching application transports while being agnostic to the application is not a good idea.

Therefore, I propose that draft-ietf-behave-turn-07 NOT define TCP or TLS/TCP as a valid transport for UDP peer connections, and since that's the only type it supports, I recommend it not define TCP or TLS/TCP use at all.  For transport security between a TURN client and TURN server, DTLS can be used if needed.  Let turn-tcp handle how to support TCP peer connections.

-hadriel

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Mar 2008 20:41:59 -0700

At Tue, 25 Mar 2008 22:58:38 -0400,
Hadriel Kaplan wrote:
> draft-ietf-behave-turn-07.txt, which is purely for UDP transport on
> the TURN-to-peer side, allows the TURN connection between a TURN
> client and the TURN server to be TCP or TLS/TCP.  The stated reason
> is:
> I find that reasoning disturbing.  One almost expects the next
> sentence to say "The TURN server listen port should be the STUN one
> (3478), but if that doesn't work, then try ports 80, 443, 25, 23,
> ...".  :)
>
> Subverting the policies of a firewall is not a good model.  We
> should not be in the business of creating standard mechanisms to
> subvert firewall policies, because it is a losing game.  I realize
> there are poorly provisioned firewalls, such as those in hotels,
> which would let UDP work if they were better managed - they aren't
> blocking it on purpose.  But there is no way for a client to guess
> as to the rationale of the firewall policies in place, for good or
> ill.  I believe corporate VPN software which mostly uses UDP
> encapsulation of IPSEC is driving them to open UDP more anyway, or
> provide "click here for a public IP" type options when signing in to
> the hotel portal.

I'm definitely very sensitive to the firewall policy argument,
but I think in this case it's somewhat more subtle. The major
reason to forbid UDP in firewalls isn't that UDP or the protocols
that run over it are especially bad, but rather but that 
there's no generic method of determining the extent of 
an association as there is with TCP. Rather, you need to
parse the application layer protocols, which is sort of
impractical. Obviously, UDP over TCP is a different story.

> Furthermore, I don't actually think it really works as defined, for
> general applications.  There is only lip-service paid to how
> application data over a TCP TURN connection would work to a UDP peer
> connection.  For example, let's say someone were to run SIP over
> TURN.  Per RFC 3261, SIP behaves differently on a reliable transport
> (TCP), than an unreliable one (UDP).  So let's say I send a SIP
> INVITE.  The TURN server gets it, and its TCP stack sends an ACK.  I
> believe it's delivered.  The TURN server then sends it over UDP and
> for some reason it got lost.  Who retransmits it?  The TURN server
> doesn't, and my SIP client doesn't.  Whereas for RTP that's ok.
> Generally, switching application transports while being agnostic to
> the application is not a good idea.

I don't think it makes sense to think of TURN UDP over TCP as
reliable transport. It's not. I usually think of TURN as a 
network interface with an incredibly long cable :) So, I think
of TURN UDP over TCP as an unreliable transport.

-Ekr

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 26 Mar 2008 00:38:00 -0400

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]]
>

Sure, and I don't doubt for many vendors that's the reason.  But we can't know a priori that that's the reason a particular private network has such a restriction.  It could be, for example, to stop STUN/TURN-type mechanisms from working.  But I guess I'm ok with that explanation, as long as the draft says so.

> of TURN UDP over TCP as an unreliable transport.

OK, so are saying the application should act like it's an unreliable transport?  I don't think that's spelled out in the draft.
And what does that mean at a TURN server, receiving UDP from the peer and sending over TCP to the client - if the TCP side has congestion or window issues which make it less throughput than the UDP volume, does the TURN server queue UDP messages (how many?), or does it discard once its allocated TCP buffers are full?

-hadriel

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 25 Mar 2008 21:58:26 -0700

At Wed, 26 Mar 2008 00:38:00 -0400,
Hadriel Kaplan wrote:
> Sure, and I don't doubt for many vendors that's the reason.  But we
> can't know a priori that that's the reason a particular private
> network has such a restriction.  It could be, for example, to stop
> STUN/TURN-type mechanisms from working.  But I guess I'm ok with
> that explanation, as long as the draft says so.

I agree it should say that... We might even want a section on 
recognizing TURN for firewall--though I guess that's hard if
TLS is used....

> OK, so are saying the application should act like it's an unreliable
> transport?  I don't think that's spelled out in the draft.

Me neither.

>  And what
> does that mean at a TURN server, receiving UDP from the peer and
> sending over TCP to the client - if the TCP side has congestion or
> window issues which make it less throughput than the UDP volume,
> does the TURN server queue UDP messages (how many?), or does it
> discard once its allocated TCP buffers are full?

An excellent set of questions. I wonder if we can leave this up
to implementors, seeing as UDP is inherently unreliable...

-Ekr

---

From: Philip Matthews <[email-masked]>
Date: Wed, 26 Mar 2008 16:21:08 -0400

> that explanation, as long as the draft says so.

I absolutely agree that the motivation in the document for TCP and  
especially TLS over TCP transport is weak. EKR provides an  
interesting argument that I have not heard before -- anyone else have  
any comments on this issue?

> OK, so are saying the application should act like it's an  
> unreliable transport?  I don't think that's spelled out in the draft.
> And what does that mean at a TURN server, receiving UDP from the  
> peer and sending over TCP to the client - if the TCP side has  
> congestion or window issues which make it less throughput than the  
> UDP volume, does the TURN server queue UDP messages (how many?), or  
> does it discard once its allocated TCP buffers are full?

I agree with EKR's interpretation: the application should see this as  
unreliable UDP transport, and the fact that a portion of the path is  
over TCP should be invisible.

At the server, when relaying from the peer to the client, the server  
should just do a socket send (or equivalent) and if the socket would  
otherwise block, then the UDP packet should be dropped.

I will try to make this clearer in the next revision of the document.

- Philip