[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on draft-ietf-ipv6-privacy-addrs-v2-00.txt

On Wed, 20 Oct 2004, Suresh Krishnan wrote:
> >o  An attacker who is in the path between the node in question and
> >       the peer(s) it is communicating to, and can view the IPv6
> >       addresses present in the datagrams.  
> >
> >                                   However, note that such on the path 
> >       attacks are likely able to perform significant correlation 
> >       even with RFC 3041 addresses especially if the payloads are not 
> >       encrypted.
> I would rather state something like this
> "However, note that an attacker, who is on path, may be able to
>  perform significant correlation based on the payloads of the packets
>  on the wire. Use of temporary addresses will not prevent such payload
>  based correlation"
> This clearly indicates that the correlation is done using data present 
> in the payload. Is this text acceptable to you?

That's fine.

> >> >As far as I can see, it's exactly the opposite -- privacy extensions 
> >> >should not be enabled by default for ULAs.
> >> 
> >> This is already the case. Privacy extensions are disabled by default for 
> >> ALL types of global addresses (including the ULA). 
> >
> >Yes, it's not default -- but what I want to have is being able to 
> >distinguish between "enabling privacy for all prefixes" and "enabling 
> >privacy for global range prefixes".
> >
> >I.e., the implementations, when privacy is enabled, should not start
> >using privacy extensions by default for ULA addresses, but doing so
> >might be configurable.
> >
> >I think that would be in line with most ULA users' goals.. too bad 
> >it's relatively difficult to unambugously say what those global, 
> >non-ULA addresses should be called..
> One way to go about this will be to attach a disable flag for specific 
> prefix ranges. i.e. fc00::/7 in case of ULAs. This flag will override the 
> global enable setting if present for the fc00::/7 range.
> I will add the following text after the first paragraph of 
> "Deployment Considerations"
> "Additionally, sites might wish to disable the use of temporary 
>  addresses for some prefixes while still using them for other global 
>  prefixes. For example, a site might wish to disable temporary address 
>  generation for "Unique local" [ULA] prefixes while still generating
>  temporary addresses for all other global prefixes.To support this behavior,
>  implementations MAY provide a way  to disable generation of temporary
>  addresses for specific prefix subranges. This setting, if present, 
>  MUST override the global settings on the node with respect to the
>  specified prefix subranges."

I'm slightly unconformtable with this approach for a couple of
reasons.  First, by default, privacy addresses are generated for ULAs
as well.  Second, such a flag is just a MAY.

What I'd propose is specify that ULAs SHOULD be excluded by default
when privacy addresses are enabled, but that there MAY [or SHOULD] be 
a flag to enable privacy addresses for ULAs.

Would that be reasonable?

Note that this will create a dependency on ULA spec(s) becoming RFC
before this one does (so that the IANA assigns the prefix range), but
that might not be a problem, as AFAIR they're relatively far in the
process.  There's no need for normative reference as we want just to
know the prefix(es).

Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6