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

From: Simon Perreault <[email-masked]>
Date: Mon, 08 Mar 2010 10:43:10 -0500

On 2010-01-15 10:42, Magnus Westerlund wrote:
> 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?

Is there anything needed of me other than "I confirm"?

I confirm.

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

New text:

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

There is no IANA registry.

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

New text:

       For both preferred and alternative behavior, the DONT-FRAGMENT
       attribute ([I-D.ietf-behave-turn], Section 14.8) MUST be ignored
       by the server.

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

This is part of the "Fragmentation" bullet. When following the preferred 
behaviour, we just do as specified in draft-ietf-behave-v4v6-xlate, 
which is what you want I think.

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

I'm not following you. Unless I'm mistaken, non-root user-space can't 
indicate to the kernel whether a fragmentation header should be included 
or not.

The IPV6_DONTFRAG socket option specified in RFC 3542 section 11.2 
doesn't seem to do what we want.

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

New text:

9.  Security Considerations

    Translation between IPv4 and IPv6 creates a new way for clients to
    obtain IPv4 or IPv6 access which they did not have before.  For
    example, an IPv4-only client having access to a TURN server
    implementing this specification is now able to access the IPv6
    internet.  This needs to be considered when establishing security and
    monitoring policies.

    The loop attack described in [I-D.ietf-behave-turn] Section 17.1.7
    may be more easily done in cases where address spoofing is easier to
    accomplish over IPv6.  Mitigation of this attack over IPv6 is the
    same as for IPv4.

    All the security considerations applicable to STUN [RFC5389] and TURN
    [I-D.ietf-behave-turn] are applicable to this document as well.

I'll update the references and produce a new version shortly.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 09 Mar 2010 11:42:07 +0100

Thanks,

I will start IETF last call. Then hand this draft over to David Harrington.

Cheers

Magnus

-- 

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