Address-Protected Neighbor Discovery for Low-Power and Lossy Networks
draft-ietf-6lo-ap-nd-23

I support Ben Kaduk’s DISCUSS position.

Thank you for this well written document.  

A few nits as the key issues already appear to be covered in other ballots:

** Section 4.1.  Typo. s/acertained/ascertained/

** Section 4.3.  Per “The type of cryptographic algorithm used in calculation Crypto-ID (see Table 2 in     Section 8.3 ).”, why not reference the sub-registry – “subregistry "Crypto-Type Subregistry" in the  Internet Control Message Protocol version 6 (ICMPv6) Parameters"?

** Section 4.4.  In the description of the Digital Signature field, consider adding that the length of this variable length field is determined by the algorithm:
OLD: 
The computation of the digital signature depends on
      the Crypto-Type which is found in the associated CIPO.  

NEW:
The length and computation of the digital signature depends on
      the Crypto-Type which is found in the associated CIPO.  

** Section 4.4. Typo. s/ths/this/

Thanks to Al Morton for the OpsDir review.
Also, thank for the good / comprehensive Shepherd writeup.

Thank you for the work put into this document. I found the document easy to read. I am clearing my previous DISCUSS and removing some COMMENTs based on proposed text by the authors.

I hope that this helps to improve the document,

Regards,

-éric

-- Section 4.2 --
While status is set to 0 when sending a NS, what is the expected behavior of a receiver ?

-- References --
Is there a reason why the crypto algorithms RFC 7748 and 8032 are not normative?

== NITS ==

-- Section 6 --
s/may use a same Crypto-ID/may use the same Crypto-ID/ ?

Section 4.4: 

"If it is
   not present, it can be found in an abstract table that was created by
   a previous message and indexed by the hash."
   
Reading the document top to bottom, I was confused about what this was referencing when I first came across it. Given that this is explained later, a forward section reference might help.

Section 7:

I think somewhere in here there should be a brief discussion about how use of this specification could facilitate correlation attacks by providing an identifier that allows traffic from multiple source addresses to be tied back to the same node via the Crypto-ID. That is, if a node intends to use multiple addresses to defend against the 6LR or being able to correlate traffic originating with each address, it should not use the mechanism specified in this document. (I'm assuming this is a corner case for these kinds of deployments but it's worth saying anyway. Also, if there is some other cross-address identifier that the 6LR always has anyway, this isn't actually a problem.)

Section 8.3:

Are there protocol-specific reasons why "IESG Approval" is a valid registration policy for this registry? Specification Required on its own seems appropriate to me.

(1) The first sentence in the Abstract reads: "This document updates the 6LoWPAN Neighbor Discovery (ND) protocol defined in RFC 6775 and RFC 8505."  It gives the impression that both RFCs are formally Updated, but document itself (and the header) make it clear that only rfc8505 is in fact Updated.  IOW, the Abstract is a little confusing.

Suggestion>
   The 6LoWPAN Neighbor Discovery (ND) protocol is defined in RFC 6775 and RFC 
   8505.  This document updates RFC 8505 by defining a new extension called 
   Address Protected Neighbor Discovery (AP-ND) which protects...


(2) §5.3 of rfc8505 has the following text related to collisions:

   Note regarding ROVR collisions: Different techniques for forming the
   ROVR will operate in different namespaces.  [RFC6775] specifies the
   use of EUI-64 addresses.  [AP-ND] specifies the generation of
   cryptographic tokens.  While collisions are not expected in the
   EUI-64 namespace only, they may happen if [AP-ND] is implemented by
   at least one of the nodes.  An implementation that understands the
   namespace MUST consider that ROVRs from different namespaces are
   different even if they have the same value.  An

Even if this document updates rfc8505 to specify "the RECOMMENDED method for building a ROVR field", there may be nodes in the LLN that don't support it.  I would like to not only see text about explicitly recognizing the possibility of collisions in mixed networks, but also deployment considerations related to the incremental implementation of the extension.


(3) Nits:

s/allow the an attacker/allow an attacker
s/forwarding an IPv6 packets/forwarding IPv6 packets

Wow: Thanks, Ben, for the VERY thorough review, which leaves little left to comment on.  Beyond what others have sait, I just have a minor thing or two to add:

— Section 1 —
The second paragraph begins as though the first paragraph werent there.  You can (and should) just begin it with, “The registration mechanism in 6LoWPAN ND prevents”, as the definition and citation are already in the paragraph before.

   This would allow the an
   attacker to steal the address

Remove the spurious “the”.

   [RFC8505] defines an Extended Address Registration Option (EARO)
   option that allows to transport alternate forms of ROVRs

The word “option” on the second line is extra, and “allows to transport” is poor English.  This works:

NEW
   [RFC8505] defines an Extended Address Registration Option (EARO)
   that allows the transport of alternate forms of ROVRs
END

— Section 4.3 —

   The implementation of multiple hash functions in a constrained
   devices may consume excessive amounts of program memory.  This

Make it “device” for number agreement.

— Section 4.4 —

   This allows to elide a CIPO that the 6LR
   already received, at the expense of the capability to add arbitrary
   options that would signed with a RSAO.

“This allows to elide” is poor English (“to elide” needs a subject).  You can say, “This allows the elision of a CIPO”.  You also need “would be signed” later in the sentence.

— Section 6 —

   A 6LN can claim any address as long as it is the first to
   make that claim.  After a successful registration, the 6LN becomes
   the owner of the registered address and the address is bound to the
   ROVR value in the 6LR/6LBR registry.

Bound for how long?  Forever?  Are unused entries ever cleaned from the registry?  Can problems arise if stale bindings stay in the registry indefinitely?

— Section 8.3 —
I agree with Alissa that you need to remove ‘either’ and ‘or "IESG Approval"’ from the registration policy, and just leave it as Specification Required.  “IESG Approval” is meant to be a special case, and, in general, the IESG can always approve a registration if needed in an exceptional circumstance.  I’ll make that clearer in the next update to BCP 26, which I’m working on with IANA.

Thanks for addressing my last Discuss point!

It's interesting that COSE has us say what key type to use with
a given curve but JOSE doesn't have that in the registry, even though
it is still a relevant question.  I think we can trust [CURVE-REPRESENTATIONS]
to cover that topic, though.

I gave some brief thought to whether the usage of [CURVE-REPRESENTATIONS]
as the reference for the registry entries requires listing it as a normative reference
for this document, and decided that the current (informative) status is tolerable.

A couple of small comments:

1) Sec 2.2: If actually all terms from all the RFC listed in section 2.2 are used, all the reference would need to be normative. Maybe double-check this!

2) Sec 3: I would have expected that section 3 says something about backward compatibility (what if not all nodes in a network are updated?) and gives a strong recommend to use this scheme (or even obsolete the old one?)

3) Nit sec 4.4: s/it an be found/it can be found/

4) Sce 6: Use of normative language: s/The node may use a same Crypto-ID/The node MAY use a same Crypto-ID/

5) Security Consideration Section: Is there a new risk/possible attack because computational complexity of the proposed scheme is higher than the one in RFC8505? Could that be used as an attack against a central node? Would it be necessary to rate limit requests somehow? Or is there already a rate limit (that should be mentioned here)?