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

From: Philip Matthews <[email-masked]>
Date: Fri, 18 Jan 2008 18:01:25 -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?
>

Ignoring for now what it says in the document, I don't see any reason  
right now why this shouldn't work.

If the allocation is expired, then it seems to be that all state  
concerning the allocation should be released. So, if one second  
later, the TURN server receives an Allocate Request using the same 5- 
tuple as the just released allocation, then it should create a new  
allocation. Of course, it is fairly unlikely that the server will  
allocate the same relayed transport address.

Anyone see any problems with this? There should not be any problems  
with this happening accidently since the client must use Refresh  
instead of Allocate for refreshes.

Comments?

- Philip

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 18 Jan 2008 16:18:42 -0800

Philip Matthews wrote:
>> There is no explanation on what can be done after an allocation expires.
> concerning the allocation should be released. So, if one second later,
> the TURN server receives an Allocate Request using the same 5-tuple as
> the just released allocation, then it should create a new allocation. Of
> course, it is fairly unlikely that the server will allocate the same
> relayed transport address.

"fairly unlikely" is short for "It will only happen when you demo your
product in front of a full room".

> 
> Anyone see any problems with this? There should not be any problems with
> this happening accidently since the client must use Refresh instead of
> Allocate for refreshes.
> 

I think that this is the right thing to do, I just wanted be sure that
it was explicitly said in the I-D that a new allocation can be created
in this case, eventually with a different username/realm/password.

Thanks.

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]

---

From: Philip Matthews <[email-masked]>
Date: Fri, 18 Jan 2008 19:33:41 -0500

On 18-Jan-08, at 19:18 , Marc Petit-Huguenin wrote:

>> later,

Just don't have any expectations about which relayed transport  
address you
get back and everything should be ok.

> in this case, eventually with a different username/realm/password.

Right now, it is in as an open issue. If I get time over the weekend,  
I will make sure the text reflects this.

- Philip

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 18 Jan 2008 16:51:58 -0800

> Ignoring for now what it says in the document, I don't see 
> any reason right now why this shouldn't work.
> 
> Anyone see any problems with this?

draft-ietf-tsvwg-udp-guidelines-04 describes a concern with
immediately re-using the same socket:

   When an application closes a TCP, SCTP or DCCP socket, the transport
   protocol on the receiving host is required to maintain TIME-WAIT
   state.  This prevents delayed packets from the closed connection
   instance from being mistakenly associated with a later connection
   instance that happens to reuse the same IP address and port pairs.
   The UDP protocol does not implement such a mechanism.  Therefore,
   UDP-based applications need to robust to this case.  One application
   may close a socket or terminate, followed in time by another
   application receiving on the same port.  This later application may
   then receive packets intended for the first application that were
   delayed in the network.

I think some text to that point would be useful, something like:

  When the TURN server allocates an IP and UDP port, that transport
  address SHOULD remain unusable for two minutes after it is freed.  
  This is to avoid packets delayed in the network from a previous 
  session from being sent to a new TURN client 
  [I-D.ietf-tsvwg-udp-guidelines].

-d

> There should not be any problems

---

From: Philip Matthews <[email-masked]>
Date: Mon, 21 Jan 2008 08:37:10 -0500

Just to be clear, I think we are talking about two slightly different  
things here.

Marc was talking about the 5-tuple (client's IP address, client's  
port, server's IP address, server's port, transport), while you are  
talking about the relayed transport address.

Never-the-less, I think your comment is a good one and will add it to  
the document.

- Philip