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

[Pekka Savola <pekkas@xxxxxxxxxx>]

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
ipv6@xxxxxxxx
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------