inline > Fernando Gont <mailto:[email protected]> > 7 September 2013 02:58 > Hi, Ray, > > Thanks so much for the review! -- Please find my comments in-line... > > On 09/06/2013 04:56 AM, Ray Hunter wrote: >> Summary Recommendations ======================= >> >> 1. Proceed with the document and the proposed solution. >> >> 2. Given the likely ubiquitous deployment of this standard, I think >> it would greatly enhance the credibility of the resulting RFC if the >> WG could see running code on: - Linux - an embedded device or other >> memory-constrained device. - (BSD implementation is already OK >> AFAIK) > > I'm told a Linux patch is being submitted in the upcoming weeks. And > other folks are working on a BSD implementation. > > My plan is to add an Ack and reference to these implementations in the > "Acknowledgements" section when they become available. I bet that by the > time the document enters the AUTH48 state, those implementations will be > out there, and I'll be able to add such acks/references.
Excellent. > > >> 3. I think there should be some words on the quality requirements of >> the PRF F(), and also any security impact of this being weak/ >> predictable. > > mm.. should we really say more than "it is cryptographically secure", as > already stated in the document? In my head, F() would be something like > SHA-*.. but even MD5 would probably be good enough for this purpose. > I am thinking the opposite. Saying that "F MUST be cryptographically secure" might be too onerous for embedded systems. I think current reality of IID distribution (generated from MAC addresses) is maybe just 20 to 24 bits of entropy with very significant skew. More entropy is better for privacy. Less skew is arguably better too. But Appletalk Phase II Ethertalk networks settled down to stable address assignments using just 8 bits for the NodeID even with say 100 nodes sharing one layer2 link. OK there's little privacy, but you do have the unique IIDs necessary for communication. I'll leave how you properly word that requirement/compromise to the real software engineers amongst us. "SHOULD be cryptographically secure" would be OK by me. >> 4. Add something on backwards compatibility e.g. "An implementation >> MAY avoid using RIDs with u=1 if the implementor is concerned about >> backwards compatibility with older SLAAC implementations sharing the >> same L2 link." Section 3 brushes this issue aside, but I still have >> doubts. > > I have no issues with adding that. But truth is that since Windows has > replaced the IEEE-identifier-derived IIDs with ones that use u=0. I > don't think you really improve backwards compatibility by setting u=0. > > Thoughts? This is possibly paranoia on my part (thinking manufacturing/ automotive and 30 year product life cycles plus the 100BaseTX auto config debacle that still hits operations regularly) If the WG has already reached rough consensus, who am I to overturn that? > > >> 5. Add random delay before regenerating tentative addresses when >> incrementing the DAD counter to avoid lock step behavior (section >> 4). > > Next question is... "In what range"? 0..1 seconds? > Should probably be defined to be "between 0 and the DAD RetransTimer as defined in RFC4862" [yes, by default that's 0 .. 1] > >> 6. Clarify that "The use of non-volatile memory is optional, and >> hosts that do not implement this feature are still compliant to the >> protocol specification." (in section 4) > > Isn't that already implicit in the "MAY"? > The IETF likes dense text. This is for the benefit of dense readers. It's just one sentence. I can live without it. > > >> Technical ========= >> >> I have some doubts about the (lack of) specification of the PRF F(). >> Achieving 64 bits of entropy is not trivial (especially on smaller >> systems or those without many external inputs) > > In my head, the PRF would be something like e.g. SHA-256. -- I'd argue > that even MD5 would be fine for this purpose. > > F() needs to be cryptographically secure. But different implementations > may have their won preferences wrt which function to use. > > > >> /IPv6 implementations conforming to this specification MUST generate >> Interface Identifiers using the algorithm specified in this section >> in replacement of any other algorithms used for generating "stable" >> addresses with SLAAC/ >> >> Is this MUST per interface or per IPv6 node? > > The node. If you have multiple interfaces, and one of them uses a > trackable IID, you're still in trouble. > ACK > >> AFAICS there'd be no harm if a specialised LAN interface on a router >> used MAC based SLAAC on one interface, but opaque addresses on >> another. > > I'm generally of in favor of "secure defaults". So, if we proceed this > way, I'd add "this should default to..". However, I think since we're > generally moving away from IEEE-identifier-derived IIDs, it's better > that "if you enable this, do it for all interfaces" -- "special cases > are seldomly good. > ACK > >> /Implementations conforming to this specification SHOULD provide the >> means for a system administrator to enable or disable the use of >> this algorithm for generating Interface Identifiers./ >> >> Again, per interface or per node? > > Per node, as per the above comment. > ACK > >> Section 3 brushes aside likely IID collisions with older SLAAC >> implementations but I still have doubts. > > Note: One of the currently most deployed systems (Windows) has moved > away from traditional SLAAC since a long time ago > > >> How about "An implementation of this algorithm MAY avoid using RIDs >> with u=1 if the implementor is concerned about backwards >> compatibility with older SLAAC implementations sharing the same L2 >> link." > > Since we're already in the process of deprecating special bits in IIDs, > I'd prefer to use the IID as an opaque field. -- but of course I'm open > to proceed otherwise. > > > >> Section 4 /Resolving Duplicate Address Detection (DAD) conflicts/ >> Should there be some words about random back-off / retry time to >> avoid nodes lock-step incrementing the DAD counter? >> >> e.g. "Hosts SHOULD introduce some random delay before regenerating a >> new temporary address when incrementing the DAD counter, to avoid >> lock-step behavior of multiple hosts" ? > > I have no objections to that. If we proceed that way, I guess the random > delay would be in the range 0..1 second? > > > >> Clarify that non-volatile memory is optional (in section 4) e.g. >> "The use of non-volatile memory is optional, and hosts that do not >> implement this feature are still compliant to the protocol >> specification." > > Since this is marked as "OPTIONAL" in the algorithm spec, and as "MAY" > in section 4, I believe that's already clear. But if you still think the > clarification would be valuable, please let me know and we can add such > paragraph. > >> Editorial ========= >> >> IMHO The intro is a long slog to read and could do with having some >> information either culled or broken up or moved elsewhere. >> >> Specifically: The natural end of the introduction to me is the line >> "Hence, there is a motivation to improve the properties of "stable" >> addresses regardless of whether temporary addresses are employed or >> not." >> >> plus >> >> "This document specifies a method to generate Interface Identifiers >> that are stable/constant for each network interface within each >> subnet, but that change as hosts move from one network to another, >> thus keeping the "stability" properties of the Interface Identifiers >> specified in [RFC4291], while still mitigating address-scanning >> attacks and preventing correlation of the activities of a node as it >> moves from one network to another." >> >> >> The information on "Relationship to Other standards" should probably >> be separate from the Introduction, with subsections for "Temporary >> Addresses", "SLAAC" and "DHCPv6" . > > Ok. I will look at the intro, and move that other text to an Appendix. I > will come back to you with a specific proposal. > > Not sure it needs an appendix. I think it is just a question of adding appropriate section breaks. > >> Key Words (2119) is also usually a separate section from what I can >> recall. > > Some documents do it in the intro, but other do it in a separate > section. Anyway, I'll move that to a "Terminology" section. > > > >> There are references to 2464. How about adding 2467 and 2470 or >> 3572? > > Sounds reasonable. How about replacing all instances of: > > "(such as those specified in [RFC2464])" > > with > > "(such as those specified in [RFC2464], [RFC2467], and [RFC2470])" > > > The only downside is that there are many instances of this, and hence > the text would become a bit cumbersome. I see your point. The reason I specifically mention RFC3572 is that MAPOS has to synthesise an EUI64 address (by borrowing from another interface), because HDLC interfaces do not include the concept of a "burned in address" (section 3 of RFC3572) I think it would be very instructive to check if stable-privacy-addresses are applicable to such link technologies that have no native burned-in-address. [I personally think stable-privacy-addresses are very applicable as long as the interface can perform DAD, and maybe we should have picked this up much earlier ;) ] > > > >> Nits ==== >> >> indentation of /Cryptographically Generated / >> >> indentation of / It should be noted that temporary addresses/ >> >> I understand that the indentation had some meaning, but it's lost >> without the WG context. > > Oh... this are my parenthetical notes (borrowed in style from Rich > Stevens) that everyone hates :-). -- is there any better way to do that? plain vanilla text works for me. > -- FWIW, these notes are text that provide additional detail, but you > may skip while reading the document. > > P.S.: I *knew* you were ging to make me work! ;-) > > Thanks so much! > Ray Hunter <mailto:[email protected]> > 6 September 2013 09:56 > The 6man chairs and the author have requested that I perform an > additional detailed review of > > A Method for Generating Semantically Opaque Interface Identifiers with > IPv6 Stateless Address Autoconfiguration (SLAAC) > draft-ietf-6man-stable-privacy-addresses-13 > > > High Level > ========== > > The document is well-written and has been subject to intense debate in > the WG. > > I support taking it further. > > > Summary Recommendations > ======================= > > 1. Proceed with the document and the proposed solution. > > 2. Given the likely ubiquitous deployment of this standard, > I think it would greatly enhance the credibility of the resulting RFC if > the WG could see running code on: > - Linux > - an embedded device or other memory-constrained device. > - (BSD implementation is already OK AFAIK) > > 3. I think there should be some words on the quality requirements of the > PRF F(), and also any security impact of this being weak/ predictable. > > 4. Add something on backwards compatibility > e.g. "An implementation MAY avoid using RIDs with u=1 if the implementor > is concerned about backwards compatibility with older SLAAC > implementations sharing the same L2 link." > Section 3 brushes this issue aside, but I still have doubts. > > 5. Add random delay before regenerating temporary addresses when > incrementing the DAD counter to avoid lock step behavior (section 4). > > 6. Clarify that "The use of non-volatile memory is optional, and hosts > that do not implement this feature are still compliant to the protocol > specification." (in section 4) > > 7. Restructure the intro. > > 8. Handle the nits. > > Goals > ===== > > There's a balance between the requirements of an IID being opaque to > prevent unwanted correlation and tracking, > and the need for network managers to be able manage a network, and > remote users to connect to server processes. > > Although far from being a universal solution, I think this document hits > the design goals that it sets out to achieve. > > There are likely to be other solutions proposed for IID generation in > the future that have different design goals. > This document does not block such proposals, provided they implement DAD. > > The incorporation of the shared secret mitigates that bad guys can > trivially guess or correlate > the opaque IID with much certainty when machines change IPv6 prefix > (although I recognise that there's a limited number > of bits of entropy in an IID and there are plenty of other mechanisms > that can be used > to achieve the same result.) > > There is also extensive documentation on the "how to" section of the IID > generation, > which is likely to be useful if at any time the opaque IID has to be > "predicted" remotely by an administrator > who is a "good guy" (and thus who knows the shared secret and PRF). > > > Future Innovation & Backwards Compatibility > =========================================== > > A possible future extension of this IID generation mechanism (which is > currently contentious) could be to allow > SLAAC with IID of lengths other than 64 bits, and thus allow coexistence > of full CIDR + autoconfigured IPv6, > which could potentially solve issues with mobile tethering and Homenet > using a single /64 delegation. > > Section 3 addresses backwards compatibility. > > Technical > ========= > > I have some doubts about the (lack of) specification of the PRF F(). > Achieving 64 bits of entropy is not trivial (especially on smaller > systems or those without many external inputs) > > /IPv6 implementations conforming to this specification MUST generate > Interface Identifiers using the algorithm specified in this section > in replacement of any other algorithms used for generating "stable" > addresses with SLAAC/ > > Is this MUST per interface or per IPv6 node? > > AFAICS there'd be no harm if a specialised LAN interface on a router > used MAC based SLAAC on one interface, but opaque addresses on another. > > > /Implementations conforming to this specification SHOULD provide the > means for a system administrator to enable or disable the use of this > algorithm for generating Interface Identifiers./ > > Again, per interface or per node? > > > Section 3 brushes aside likely IID collisions with older SLAAC > implementations but I still have doubts. > How about "An implementation of this algorithm MAY avoid using RIDs with > u=1 if the implementor is concerned about backwards compatibility with > older SLAAC implementations sharing the same L2 link." > > Section 4 /Resolving Duplicate Address Detection (DAD) conflicts/ > Should there be some words about random back-off / retry time to avoid > nodes lock-step incrementing the DAD counter? > > e.g. "Hosts SHOULD introduce some random delay before regenerating a new > temporary address when incrementing the DAD counter, to avoid lock-step > behavior of multiple hosts" ? > > Clarify that non-volatile memory is optional (in section 4) > e.g. "The use of non-volatile memory is optional, and hosts that do not > implement this feature are still compliant to the protocol specification." > > Editorial > ========= > > IMHO The intro is a long slog to read and could do with having some > information either culled or broken up or moved elsewhere. > > Specifically: The natural end of the introduction to me is the line > "Hence, there is a motivation to improve the properties of "stable" > addresses regardless of whether temporary addresses are employed or not." > > plus > > "This document specifies a method to generate Interface Identifiers > that are stable/constant for each network interface within each > subnet, but that change as hosts move from one network to another, > thus keeping the "stability" properties of the Interface Identifiers > specified in [RFC4291], while still mitigating address-scanning > attacks and preventing correlation of the activities of a node as it > moves from one network to another." > > > The information on "Relationship to Other standards" should probably be > separate from the Introduction, with subsections for "Temporary > Addresses", "SLAAC" and "DHCPv6" . > > Key Words (2119) is also usually a separate section from what I can > recall. > > There are references to 2464. How about adding 2467 and 2470 or 3572? > > > Nits > ==== > > indentation of /Cryptographically Generated / > > indentation of / It should be noted that temporary addresses/ > > I understand that the indentation had some meaning, but it's lost > without the WG context. > > > > s/ is a orthogonal to/ is orthogonal to/ > > s/replacing a Network Interface Card (NIC)/replacing a Network Interface > Card (NIC) or adding links dynamically to a Link Aggregation Group > (LAG)/ ? > > s/Including the optional Network_ID parameter when computing the RID > value above would cause the/ > Including the optional Network_ID parameter when computing the RID value > above causes the/ > > > Some pagination issues of the HTML version. > > ------------------------------------------------------------------------ -- Regards, RayH -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
