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. > 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. > 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? > 5. Add random delay before regenerating temporary addresses when > incrementing the DAD counter to avoid lock step behavior (section > 4). Next question is... "In what range"? 0..1 seconds? > 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"? > 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. > 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. > /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. > 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. > 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. > 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? -- 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! -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
