On 4/18/12 5:43 PM, Fernando Gont wrote: > Hi, Eliot, > > On 04/18/2012 06:37 AM, Eliot Lear wrote: >>> On 04/13/2012 10:09 AM, Eliot Lear wrote: >>>> At one point you write that the intent is to replace EUI-64-based >>>> addresses (Section 5). >>> Exactly. > [Correcting myself] > > The intent is to have draft-gont-6man-stable-privacy-addresses used > instead of the IIDs that embed IEEE identifiers. > > > >> Yes, I'm looking at the quoted paragraphs (I'm not quite sure from where >> you're quoting): >>> As noted in [RFC4941], "anytime a fixed identifier is used in >>> multiple contexts, it becomes possible to correlate seemingly >>> unrelated activity using this identifier". Therefore, since >>> "privacy addresses" [RFC4941] do not eliminate the use of fixed >>> identifiers for server-like functions, they only *partially* >>> mitigate the correlation of host activities (see Section 7 for >>> some example attacks that are still possible with privacy >>> addresses). Therefore, it is vital that the privacy >> And so on. In essence you set up an argument against 4941 but that >> isn't really your argument for the draft and so I don't really know what >> it's doing there. > It's not an argument against RFc4941, but rather an argument that even > with RFC4941, you still need to do something about the IEEE-based IIDs. > At the Paris IETF, some folks argued that if you have RFC 4941 in place, > you don't need draft-gont-6man-stable-privacy-addresses. Section 7 of > draft-gont-6man-stable-privacy-addresses (which should be an Appendix, > rather than a section in the main body of the document) illustrates that > that's not the case: even if you're employing RFC4941, you're still > subject to host-scanning attacks and host tracking.
Well, host scanning at least. Host tracking depends on the implementation. > > It is *not* an argument *against* RFC 4941, since it *is* valuable to > have addresses that change over time for outging communications. > > > >> But perhaps that's not as important as this: >> >>>> I am concerned that adopting this >>>> mechanism will make matters worse if this mechanism is being used as an >>>> alternative to CGAs, as opposed to EUI-64s.. >>> I don't follow. Could you clarify your concern? >> You argue that this is an alternative to EUI-64s. > Let me correct myself: this is an alternative to IIDs that embed IEEE > identifiers: The modified EUI-64 format is a general format, and it does > not need to embed IEEE identifiers (for instance, RFC4941 produce > Mod-EUI-64 format identifiers, bu clearly do not embed IEEE identifiers). > > >> But in practice I am >> concerned that people will not use this as an alternative to EUI-64s, >> but instead as an alternative to CGAs, > Why? > > I don't really follow the relationship of > draft-gont-6man-stable-privacy-addresses with CGAs. CGAs are used for > SEND, and are not even mentioned in this I-D. > > How do you arrive to the conclusion that people might want to use this > instead of CGAs?? > > As noted in the I-D tihs mechanism is meant to be a replacement for IIDs > based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal > to CGAs. I know what you mean. That matters less than how other people make use of the work. Believe me I know. I've got my name on RFC-1918, for crying out loud. Eliot -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
