TURN: XOR peer address; remove two-minute rule

[Philip Matthews]

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
Behave@...
https://www.ietf.org/mailman/listinfo/behave

[Marc Petit-Huguenin-2]

Philip Matthews wrote:
> 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.

Do you mean XOR-MAPPED-ADDRESS?

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

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
> implementors that backwards compatibility is not important, I plan to
> make the change unless someone objects.

[...]

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

[Philip Matthews]

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

On Fri, 26-Sep-08, at 13:01 , Marc Petit-Huguenin wrote:

> Philip Matthews wrote:
>> 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.
>
> Do you mean XOR-MAPPED-ADDRESS?

Yes.

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

Whoops!

>
>
> Since I have been repeatedly told by
>> implementors that backwards compatibility is not important, I plan to
>> make the change unless someone objects.
>
> [...]
>
> --
> Marc Petit-Huguenin           [                                 ]
> Home: marc@... [RFC1855-compliant space for rent ]
> Work: marc@...            [                                 ]
> [                                                               ]
>

_______________________________________________
Behave mailing list
Behave@...
https://www.ietf.org/mailman/listinfo/behave