Subject: [BEHAVE] TURN: XOR peer address; remove two-minute rule

From: Philip Matthews <[email-masked]>
Date: Fri, 26 Sep 2008 11:41:18 -0400

After a phone call today to discuss TURN, Jonathan and I have two more  
proposed changes to TURN:

1) XOR the IP address in the PEER-ADDRESS attribute. We are proposing  
to change the PEER-ADDRESS attribute so that the IP address in the  
attribute is XORed in the same way as in the MAPPED-ADDRESS attribute.  
This was prompted by an example that I came up with that might require  
XORing to have TURN work correctly. Jonathan and I are not 100% sure  
about the example, however we would like TURN to be as bullet-proof as  
possible and the only reason to not make this change would be to  
maintain backwards compatibility. Since I have been repeatedly told by  
implementors that backwards compatibility is not important, I plan to  
make the change unless someone objects.

2) Remove two-minute rule. Currently, TURN states that a server must  
not allow a 5-tuple to be re-used for two minutes after the allocation  
is deleted. The motivation was as follows. Say a client sends a number  
of Send indications messages that get delayed somehow. Meanwhile, the  
allocation gets deleted and the 5-tuple is re-used for a different  
allocation (because the server does not implement the 2-minute rule).  
When these Send indications finally arrive at the server, they will be  
forwarded to the peer but will come from a different relayed-transport- 
address. If, instead of Send indications, the messages are ChannelData  
messages, then the messages might get mis-forwarded if the channel  
number has been bound to a different peer.
In discussing this problem, Jonathan and I noted:
a) A robust receiving application must be able to detect and discard  
mis-delivered packets. This can happen all the time with STUN and NATs.
b) An application that is concerned about its packets being accidently  
mis-delivered should encrypt its application data.
For these reasons, the two-minute rule doesn't seem to add anything.  
Furthermore, it makes things more complex on both the server and  
client: the server must remember the 5-tuple for two minutes after the  
allocation goes away, and a client cannot re-use a local port  
immediately for a different allocation but must allocate a different  
port.
So unless someone has a better argument for why the two-minute rule  
should be kept, we are proposing to remove it.

- Philip

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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 26 Sep 2008 10:01:22 -0700

Philip Matthews wrote:
> 1) XOR the IP address in the PEER-ADDRESS attribute. We are proposing to
> change the PEER-ADDRESS attribute so that the IP address in the

Do you mean XOR-MAPPED-ADDRESS?

> maintain backwards compatibility. 

I am confused, PEER-ADDRESS is already XORed, at least this is how I
understand the following (section 13.3):

"It is encoded in the same way as XOR-MAPPED-ADDRESS."

This said, why not follow the same naming scheme than in rfc3489bis and
behavior-discovery, and call this attribute XOR-PEER-ADDRESS (and also
change RELAYED-ADDRESS to XOR-RELAYED-ADDRESS if the intent is also to
have it XORed).

Since I have been repeatedly told by
> make the change unless someone objects.

[...]

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Fri, 26 Sep 2008 14:35:46 -0400

Whoops! You are correct and I am wrong. Both attributes are already  
XORed.
You would think I would know the spec better... ;-(

I think your suggestion to change the names is good, since Jonathan or  
I remembered this.

- Philip

> Do you mean XOR-MAPPED-ADDRESS?

Yes.

> change RELAYED-ADDRESS to XOR-RELAYED-ADDRESS if the intent is also to

Whoops!