Subject: [BEHAVE] Comments on draft-ietf-behave-turn-ipv6-05

From: Philip Matthews <[email-masked]>
Date: Fri, 28 Nov 2008 16:16:01 -0500

Gonzalo and Oscar:

Here are my comments on your draft. I apologize for sending these at  
the last minute. I hope you find them useful.

*) I would like to see the abstract, Introduction, and Overview  
sections focus more on the overall idea of adding IPv6 support to  
TURN, with the associated concepts of relaying v6-to-v6 and v4-to-v6/ 
v6-to-v4. Personally, I think that is the big concept that this draft  
needs to define. Once that is done, adding a way for the client to  
specify the address family of the relayed-transport-address seems just  
a little add-on.

*) Must a TURN server implementing this draft support v4-to-v6/v6-to- 
v4 relaying? What about v6-to-v6 relaying?
Personally, I feel that a server should be able to conform to this  
draft if it just supports the REQUESTED-ADDRESS-TYPE attribute and  
only relays v4-to-v4.
Whatever decision is made, I think the draft should make a definite  
statement on these points.

*) I think the draft needs to state the following:
   a) That the client transport address and the server transport  
address must use the same address family;
   b) That the relayed-transport-address and all peer transport  
addresses must use the same address family;
   c) That the addresses in permissions and channel bindings are of  
the same family as the relayed-transport-address.
Actually, points (a) and (b) need more words, since the actual address  
families can differ if a NAT64 or NAT46 sits in the path between the  
client and the server, or the server and a peer. What must be true is  
that the address families as seen by the client and as seen by the  
server must be the same.

*) This draft proposes an error code 440 "Address Family not  
supported". But I think this error code needs to be redefined as  
"Requested address family relaying not supported".
For example, if a server supports only v4-to-v4 and v6-to-v6 relaying,  
and it receives an Allocate request with a REQUESTED-ADDRESS-TYPE  
attribute specifying IPv6 on a IPv4 server address, then the problem  
is not that IPv6 is not supported, but that v4-to-v6 relaying is not  
supported.

*) I think this draft needs to define an additional error code: "Peer  
address family mismatch". This error code is returned whenever a  
CreatePermission or ChannelBind request is received with an XOR-PEER- 
ADDRESS attribute whose address family does not match the address  
family of the relayed-transport-address.
Similarly, I think this draft needs to define what happens when a Send  
or Data indication is received where the XOR-PEER-ADDRESS attribute  
contains an address of the wrong family.

*) This draft defines how a TURN server reacts if a Refresh request  
contains an (unexpected) REQUESTED-ADDRESS-TYPE attribute. This may be  
desirable, but I will note that the base TURN spec says nothing  
similar about all the other attribute of TURN. Furthermore, this draft  
says nothing about an unexpected REQUESTED-ADDRESS-TYPE attribute in a  
CreatePermission, ChannelBind, Send, or Data message.
So I think the WG needs to decide that either such behavior needs to  
be specified, or that it does not need to be specified, and the two  
drafts updated appropriately.

*) The draft references the SIIT spec (RFC 2765) for the details of  
how to translate v4-to-v6 and v6-to-v4. However, the base TURN  
specification is carefully written so that a TURN server can be  
implemented by a userland process without special privileges, and  
unfortunately most of the translations specified by SIIT require  
detailed header access of the kind not normally available to an un- 
privileged userland process.
In my opinion, we want to preserve this property of TURN, and thus  
this draft should define translations that satisfy this constraint.

*) The above comment also applies to the v6-to-v6 relaying rules  
specified in section 6 of this draft. Some of the v6-to-v6 rules  
specified cannot normally be implemented by an un-privileged userland  
process. For example, un-privileged userland processes cannot  
typically send ICMP messages.

*) Section 12 of the base TURN spec describes header field processing  
in terms of Preferred and Alternate behaviors. I think that section 6  
of this draft should do the same.

*) Suggestion: rename REQUESTED-ADDRESS-TYPE to REQUESTED-ADDRESS- 
FAMILY. I feel this would make the purpose of the attribute clearer.

- Philip

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

---

From: Simon Perreault <[email-masked]>
Date: Fri, 28 Nov 2008 16:30:23 -0500

Philip Matthews wrote:
> *) Must a TURN server implementing this draft support v4-to-v6/v6-to-v4 
> relaying? What about v6-to-v6 relaying?
> Personally, I feel that a server should be able to conform to this draft 
> if it just supports the REQUESTED-ADDRESS-TYPE attribute and only relays 
> v4-to-v4.

I disagree. If I'm shopping around for a TURN server, looking at spec 
sheets, and I see RFCXXXX (i.e. the future name of this draft) listed, I 
would expect it to imply that the server can handle IPv6 packets.

So I would like the draft to state some minimum level of compliance that 
would be more than just parsing an additional parameter.

> *) The draft references the SIIT spec (RFC 2765) for the details of how 
> to translate v4-to-v6 and v6-to-v4. However, the base TURN specification 
> is carefully written so that a TURN server can be implemented by a 
> userland process without special privileges, and unfortunately most of 
> the translations specified by SIIT require detailed header access of the 
> kind not normally available to an un-privileged userland process.
> In my opinion, we want to preserve this property of TURN, and thus this 
> draft should define translations that satisfy this constraint.

I find this very important.

> process. For example, un-privileged userland processes cannot typically 
> send ICMP messages.

Again, +1.

-- 
Please try Numb, a STUN/TURN server implementation.
Free access at http://numb.viagenie.ca/.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Fri, 28 Nov 2008 23:09:19 -0500

Two additional comments.

*) If the RESERVATION-TOKEN attribute is present in the Allocate  
request, then I think the REQUESTED-ADDRESS-TYPE attribute must not be  
present, and the address family is determined from the reserved  
transport address. Furthermore, I suggest that we allow the Allocate  
request containing the RESERVATION-TOKEN attribute to arrive over any  
transport (as is done today), including over a different address  
family -- thus it is possible that this subsequent request will  
involve a different form of relaying. (I.e., the first request might  
be v4-to-v4 relaying, while the second is v6-to-v4 relaying).

*) The draft says:

    If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST
    allocate an IPv4 transport address to the TURN client.

If the request does not contain a REQUESTED-ADDRESS-TYPE attribute,  
then it is from an client that supports only v4-to-v4 relaying. So I  
am thinking that the server should reject this request if it arrives  
on a v6 server transport address.

- Philip

On Fri, 28-Nov-08, at 16:16 , Philip Matthews wrote:

> v6-to-v4. Personally, I think that is the big concept that this  
> draft needs to define. Once that is done, adding a way for the  
> client to specify the address family of the relayed-transport- 
> address seems just a little add-on.
>
>
> Actually, points (a) and (b) need more words, since the actual  
> address families can differ if a NAT64 or NAT46 sits in the path  
> between the client and the server, or the server and a peer. What  
> must be true is that the address families as seen by the client and  
> as seen by the server must be the same.
>
>
> For example, if a server supports only v4-to-v4 and v6-to-v6  
> relaying, and it receives an Allocate request with a REQUESTED- 
> ADDRESS-TYPE attribute specifying IPv6 on a IPv4 server address,  
> then the problem is not that IPv6 is not supported, but that v4-to- 
> v6 relaying is not supported.
>
>
> *) I think this draft needs to define an additional error code:  
> "Peer address family mismatch". This error code is returned whenever  
> a CreatePermission or ChannelBind request is received with an XOR- 
> PEER-ADDRESS attribute whose address family does not match the  
> address family of the relayed-transport-address.
> Similarly, I think this draft needs to define what happens when a  
> Send or Data indication is received where the XOR-PEER-ADDRESS  
> attribute contains an address of the wrong family.
>
>
> contains an (unexpected) REQUESTED-ADDRESS-TYPE attribute. This may  
> be desirable, but I will note that the base TURN spec says nothing  
> similar about all the other attribute of TURN. Furthermore, this  
> draft says nothing about an unexpected REQUESTED-ADDRESS-TYPE  
> attribute in a CreatePermission, ChannelBind, Send, or Data message.
> specified cannot normally be implemented by an un-privileged  
> userland process. For example, un-privileged userland processes  
> cannot typically send ICMP messages.
>
>
> *) Section 12 of the base TURN spec describes header field  
> processing in terms of Preferred and Alternate behaviors. I think  
> that section 6 of this draft should do the same.
>
>