Subject: Re: [BEHAVE] TURN Issue: Re-using the 5-tuple

From: Philip Matthews <[email-masked]>
Date: Tue, 12 Feb 2008 12:28:56 -0500

On 19-Dec-07, at 10:14 , Marc Petit-Huguenin wrote:
> There is no explanation on what can be done after an allocation  
> expires.
> Is it possible to create a new one from the same source IP and port?
> With the same username/realm/password?
>

As I think more about this, I now think that the TURN server should  
do the following:
1) It should not reuse the relayed transport address, AND
2) It should reject attempts to re-use the 5-tuple
for some time after the allocation expires.

Point (1) prevents data packets from the peer to the server from  
being delivered to the wrong client. Point (2) prevents data packets  
from the client to the server from being delivered to the wrong peer.

I am thinking that the time should be either 2 minutes (as suggested  
by Dan) or 4 minutes (2*MSL, which is what BEHAVE-TCP uses).

Comments?

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 12 Feb 2008 10:29:08 -0800

Philip Matthews wrote:
>> There is no explanation on what can be done after an allocation expires.
> As I think more about this, I now think that the TURN server should do
> the following:
> Point (1) prevents data packets from the peer to the server from being
> delivered to the wrong client. 

I agree with this.

> Point (2) prevents data packets from the
> client to the server from being delivered to the wrong peer.

What happen when a NAT reuse the same port after the expiration of the
binding?

192.168.1.1       208.77.188.166
  Client               NAT               TURN
    | Port 5000         |                 |
    |------------------>| Port 49567      |
    |                   |---------------->|
    :                   :                 :
    |                   | Binding expires |
    :                   :                 :
    | Port 5001         |                 |
    |------------------>| Port 49567      |
    |                   |---------------->| Rejected

If the Binding on the NAT expires after 15 seconds, but the TURN server
rejects allocations two minutes after the expiration of the allocation,
then legitimate allocation from a different port will fail (note that
the NAT should apply the same rule and do not reuse port 49567 for 2
minutes after the binding expires, but you cannot count on it).

A solution would be to have a specific return code in this case, so the
client knows that the NAT reused a port less than two minutes after the
binding expires.  The client can then retry.

Also the I-D should say that the TURN client cannot reuse a port for two
minutes (or perhaps that this should be said in rfc3489bis?)

> 
> I am thinking that the time should be either 2 minutes (as suggested by
> Dan) or 4 minutes (2*MSL, which is what BEHAVE-TCP uses).
> 
> Comments?
> 
> - Philip
> 

-- 
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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 12 Feb 2008 10:38:03 -0800

...
> Also the I-D should say that the TURN client cannot reuse a 
> port for two minutes (or perhaps that this should be said in 
> rfc3489bis?)

I don't believe rfc3489bis should say anything about this; the MSL isn't
relevant for classic STUN.

In TURN, I would cite as justification for the two minutes Section 3.3 of
draft-ietf-tsvwg-udp-guidelines-05 which reads, in part:

   ...
   Finally, it is important to note that delay spikes can be very large.
   This can cause reordered packets to arrive many seconds after they
   were sent.  [RFC0793] defines the the maximum delay a TCP segment
   should experience - the Maximum Segment Lifetime (MSL) - as 2
   minutes.  No other RFC defines an MSL for other transport protocols
   or IP itself.  This document clarifies that the MSL value to be used
   for UDP SHOULD be the same 2 minutes as for TCP.  Applications SHOULD
   be robust to the reception of delayed or duplicate packets that are
   received within this 2-minute interval.
   ...

-d

---

From: Philip Matthews <[email-masked]>
Date: Tue, 12 Feb 2008 14:36:27 -0500

On Tue, 12-Feb-08, at 13:29 , Marc Petit-Huguenin wrote:

>> being

The obvious code to use in this case is 437 Allocation Mismatch.

As I think more about this, I see the following recovery actions for  
the client on receipt of a 437 (in this case or in other cases):
1) If the client sent an Allocate request, then this means that the  
server thinks the allocation already exists for some reason. Since  
the client thinks there is no allocation, its recovery action is to  
try a different 5-tuple.
2) If the client sent any other request, then this means that the  
server thinks the allocation does not exist. Since there is no way  
for the client to recover its allocation, its only recovery action is  
to start over with a different 5-tuple.

If this seems reasonable, I will add some text about how a client can  
recovery from a 437 to the document.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Tue, 12 Feb 2008 14:37:29 -0500

>    received within this 2-minute interval.

Thanks for the pointer. I will add this to the document.

- Philip

---

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

I'm a bit confused about this whole open issue so take this email with  
a huge grain of salt. Hopefully when I read it in the draft I will  
understand better.

> 1) It should not reuse the relayed transport address, AND

I wonder if you are over engineering this. I'm not sure I understand  
the case you are trying to fix with this right but ... Let's say I  
have a 10 minute permission/binding from device A, and device A is  
receiving streaming video, and I am 2 minutes into the permission when  
a power outage happens at my site. The devices at my site all reboot  
and a different device, device B, gets the IP that device A used to  
have.  For the next several minutes, Device B is going to be getting  
the streaming video packets until the permission expires. It seems  
like we can't fix this but we are trying to fix a far more unlikely  
corner case.

> for some time after the allocation expires.

I don't know what 5 tuple you are talking about here. If you have a  
have a music on hold server that used a fixed port and public IP, and  
you had a call where when you put me on hold then which transferred  
the audio stream to the music on hold server, then took me off hold,  
then put me back on, it seems like I might want to reuse the same 5  
tuple. Anyways, I could be very confused here - I'm having a hard time  
following what is being proposed so my concern may be totally bogus.

---

From: Philip Matthews <[email-masked]>
Date: Wed, 13 Feb 2008 21:05:12 -0500

On Wed, 13-Feb-08, at 17:58 , Cullen Jennings wrote:

>
> I'm a bit confused about this whole open issue so take this email  
> with a huge grain of salt. Hopefully when I read it in the draft I  
> will understand better.

I am working hard right now on getting TURN-07 out. All these little  
e-mails I am sending are arising from things that strike me as I work  
on it. With all the changes we have made, it will be another major  
revision ...

> I wonder if you are over engineering this. I'm not sure I  
> understand the case you are trying to fix with this right but ...  
> Let's say I have a 10 minute permission/binding from device A, and  
> device A is receiving streaming video, and I am 2 minutes into the  
> permission when a power outage happens at my site. The devices at  
> my site all reboot and a different device, device B, gets the IP  
> that device A used to have.  For the next several minutes, Device B  
> is going to be getting the streaming video packets until the  
> permission expires. It seems like we can't fix this but we are  
> trying to fix a far more unlikely corner case.

I suppose this could happen in an enterprise setting where the NAT or  
FW is on a UPS, but the DHCP server (a different box) is not.

Not sure how likely this case is, but I also don't see any way to fix  
it.

> have a music on hold server that used a fixed port and public IP,  
> and you had a call where when you put me on hold then which  
> transferred the audio stream to the music on hold server, then took  
> me off hold, then put me back on, it seems like I might want to  
> reuse the same 5 tuple. Anyways, I could be very confused here -  
> I'm having a hard time following what is being proposed so my  
> concern may be totally bogus.

This is the 5-tuple that describes the communication path between the  
client and the server: (client IP address, client port, server IP  
address, server port, transport protocol). This 5-tuple is one way to  
uniquely identify an allocation (the other way being the relayed  
transport address).

I believe you are thinking of the 5-tuple that describes the  
communication path between the server and the peer. I don't think  
there is any problem in the scenario you are talking about  -- but  
hey, I may be wrong.

- Philip