Subject: Re: [BEHAVE] WGLC: TURN and TURN-IPv6 (draft-ietf-behave-turn-11, draft-ietf-behave-turn-ipv6-05)

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 01 Mar 2009 13:09:48 +0200

Hi Magnus,

thanks for your comments. Answers inline:

> 1. See TURN last call comment about loop attack if address checking as
> mitigation is written into the TURN spec, then this needs to be marked
> as non effective when implementing this extension.

I will work with Philip on this one so that both documents are aligned.

> 2. Section 3:
>    TURN servers allocate a single relayed-transport-address per
>    allocation request.  Therefore, Allocate Requests cannot carry more
>    than one REQUESTED-ADDRESS-TYPE attribute.  Consequently, a client
>    that wishes to allocate more than one address at a TURN server (e.g.,
>    an IPv4 and an IPv6 address) needs to perform several allocation
>    requests (one allocation request per address).
> 
> It is not clear how this relates to the rule about a single allocation
> per 5-tuple? Is this changing that?

No, it is not changing that. The Overview of Operation section is 
non-normative and, thus, does not change anything.

> 3. Section 4.1:
> 
>    Reserved: at this point, the 24 bits in the reserved field SHOULD be
>    set to zero by the client and MUST be ignored by the server.
> 
> I don't like the SHOULD in this sentence. That makes it impossible for
> future revisions to be certain that these bits are set to 0. Thus it
> makes them unusable for extension.

I have changed it to a MUST.

> 
> 4. Section 6:
> 
>    TURN
>    relays performing an IPv4-to-IPv6 or an IPv6-to-IPv4 translations
>    SHOULD translate other header fields following SIIT (Stateless IP/
>    ICMP Translation Algorithm) as described in Sections 3 and 4 of
>    [RFC2765] respectively.
> 
> I think there need to be some exceptions to this:
> 
> - Source address when translating from v4 to v6: SIIT specifies:
>          Source Address:
>                  The low-order 32 bits is the IPv4 source address.
>                  The high-order 96 bits is the IPv4-mapped prefix
>                  (::ffff:0:0/96)
> 
>   To me it seem that the allocation's relayed IPv6 address should be
>   used in the client-> peer direction and the servers transport address
>   in the other.
> 
> - Destination address:
>                  The low-order 32 bits is the IPv4 destination
>                  address.  The high-order 96 bits is the IPv4-
>                  translated prefix (0::ffff:0:0:0/96)
> 
>   Also in this case it seem that the peer address or the client's server
> reflexive address is the one to use.
> 
> In the reverse direction you also to change the address field
> specifications:
> 
>         Source Address:
>                  If the IPv6 source address is an IPv4-translated
>                  address then the low-order 32 bits of the IPv6 source
>                  address is copied to the IPv4 source address.
>                  Otherwise, the source address is set to 0.0.0.0.  The
>                  use of 0.0.0.0 is to avoid completely dropping e.g.
>                  ICMPv6 error messages sent by IPv6-only routers which
>                  makes e.g. traceroute present something for the
>                  IPv6-only hops.
> 
>          Destination Address:
>                  IPv6 packets that are translated have an IPv4-mapped
>                  destination address.  Thus the low-order 32 bits of
>                  the IPv6 destination address is copied to the IPv4
>                  destination address.
> 
> 
> I also think some remarks or reduced scoping is needs as Section 3.4 and
> 4.4 are not applicable to TURN address family translations.

per other comments we received, the translation sections have been 
rewritten. The issues you bring up above are addressed in the new text.

Thanks,

Gonzalo