Hi Pekka, Please see comments inline. Thanks Suresh
On Wed, 20 Oct 2004, Pekka Savola wrote: >On Wed, 20 Oct 2004, Suresh Krishnan wrote: >> >Has the protection from your ISPs and federal agencies etc. really >> >been the requirement/goal from the start? >> >> On-path does not have to be FBI/NSA or ISPs. It can be anyone on an >> upstream network (even in the same organization as the user). I would >> assume if the FBI/NSA or the ISPs wanted to intercept they could do >> so at the layer 2 connection to the provider. Do you want me to add a >> statement about lawful intercept still being possible? > >It doesn't need to be about lawful intercept, but I'd add something >about the power of being on the path, maybe like: > >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? > >> >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." > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
