Subject: [BEHAVE] AD comments on draft-ietf-bahve-turn-ipv6-08

From: Magnus Westerlund <[email-masked]>
Date: Fri, 15 Jan 2010 16:42:00 +0100

Hi,

Here are my AD comments on Traversal Using Relays around NAT (TURN)
Extension for IPv6 - draft-ietf-behave-turn-ipv6-08:

1. Can the authors please confirm that they really can provide the
rights as requested by RFC 5378 and that it is intentional, rather than
an omission that there are no pre-RFC5378 disclaimer?

2. Section 4.1.1:
Family: there are two values defined for this field and specified in
   [RFC5389]: 0x01 for IPv4 addresses and 0x02 for IPv6 addresses.

I think the definition of this field should be made clearer and point at
where the address family field actually are defined in RFC 5389. I also
think an explicit mention of the IANA registry for the value also should
be made here.

3. Section 8.1: Fragmentation:
      For both preferred and alternative behavior, the DONT-FRAGMENT
      attribute MUST be ignored by the server.

I think a reference to the definition of this TURN attribute is need.

4. Section 8.1 and 8.3: DF bit

What is the behavior in setting the DF bit in IPv4 and if a
fragmentation header is included in an outgoing IPv6 packet. I think
this needs further clarification. Can you explain why their isn't a
separate bullet for handling the DF bit, if not set, shouldn't be the
fragmentation header be added unless the packet size is below the 1280
required to support size?

The two alternative behavior that I see result from either being unable
to read the incomming or set the outgoing. In the first case there is
still the question if the default is to include fragmentation header or
not. And for setting, the lower layer defaults take over.

5. Sec consideration

This clearly has new security considerations. Simply the fact that you
can switch address family must have some impact on security. Monitoring
of flows is one thing that gets more complicated. Also the question of
loops are an issue, especially as you can't assure that the preferred
behavior is performed here. Also, can't the loop attack described in
TURN spec be more easily done using two address families?

I think you need to make clear the things you have considered even if
they are not affecting security.

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------