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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
