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

[Ballot comment]
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.

[Ballot discuss]
We need to indicate somehow that the needed codepoints will be registered in the JOSE
registries to use ECDSA25519 (crypto-type 2), whether by doing it ourself or by
depending on another doc that does so.

[Ballot comment]
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.

[Ballot comment]
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/

[Ballot comment]
(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

[Ballot comment]
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.

[Ballot discuss]
Why do we need to allow ambiguity/flexibility as to the point representation
within a given Crypto-Type value (as opposed to fixing the representation as
a parameter of the Crypto-Type)?  Alternately, what does "(un)compressed"
mean, as it's not really clarified directly?  Furthermore, Table 2 lists an
"(un)compressed" representation for type 0 (over P-256), but RFC 7518 notes
that the compressed representation is not supported for P-256 (Section
6.2.1.1).  I also am not finding the needed codepoints registered in the JOSE
registries to use ECDSA25519 (crypto-type 2) -- do we need to register
anything there?

[Ballot comment]
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/ ?

[Ballot discuss]
The CIPO description specifies that a 5-bit Reserved1 field and a 13-bit
Public Key Length field are combined to fit into a 16 (not 18)-bit space.
(The Figure shows the Public Key Length field as 11 bits.)

Why do we need to allow ambiguity/flexibility as to the point representation
within a given Crypto-Type value (as opposed to fixing the representation as
a parameter of the Crypto-Type)?  Alternately, what does "(un)compressed"
mean, as it's not really clarified directly?  Furthermore, Table 2 lists an
"(un)compressed" representation for type 0 (over P-256), but RFC 7518 notes
that the compressed representation is not supported for P-256 (Section
6.2.1.1).  I also am not finding the needed codepoints registered in the JOSE
registries to use ECDSA25519 (crypto-type 2) -- do we need to register
anything there?

Per my comment on Section 4.4, there may be some implicit
expectation/requirement of 128+-bit ROVRs for AP-ND, but I didn't find where
such a requirement was stated.

[Ballot comment]
Thanks for this well-written document!  It will be good to see this stuff
getting deployed.

What's the risk of DoS via (short) address exhaustion in terms of 6LBR
resources (as distinct from 6LR resources mentioned at the end of Section
7.1)?

Section 1

  In this specification, a 6LN generates a cryptographic ID (Crypto-ID)
  and places it in the ROVR field during the registration of one (or
  more) of its addresses with the 6LR(s).  Proof of ownership of the
  Crypto-ID is passed with the first registration exchange to a new
  6LR, and enforced at the 6LR.  The 6LR validates ownership of the
  cryptographic ID before it creates any new registration state, or
  changes existing information.

I'll read on and see, but how much trust does this imply that we require of
all 6LRs (as opposed to the 6LBR, which is kind of required to be pretty
trusted)?  [ed.: basically complete trust is required]

  The protected address registration protocol proposed in this document
  enables Source Address Validation (SAVI) [RFC7039].  This ensures
  that only the actual owner uses a registered address in the IPv6
  source address field.  A 6LN can only use a 6LR for forwarding
  packets only if it has previously registered the address used in the
  source field of the IPv6 packet.

nit: this last sentence is written as if we not only enable, but also
require, SAVI.

  The 6lo adaptation layer in [RFC4944] and [RFC6282] requires a device
  to form its IPv6 addresses based on its Layer-2 address to enable a
  better compression.  This is incompatible with Secure Neighbor
  Discovery (SeND) [RFC3971] and Cryptographically Generated Addresses
  (CGAs) [RFC3972], since they derive the Interface ID (IID) in IPv6
  addresses with cryptographic keys.

Are we going to have some further discussion of the scope of that loss of
functionality and/or alternative mechanisms to achieve those goals, or is
this statement just intended to note the incompatibility?

Section 3

  The proof requires the support of Elliptic Curve Cryptography (ECC)
  and that of a hash function as detailed in Section 6.2.  To enable
  the verification of the proof, the registering node needs to supply
  certain parameters including a Nonce and a signature that will
  demonstrate that the node has the private-key corresponding to the
  public-key used to build the Crypto-ID.

nit: the proof itself may only indirectly involve a hash, since we use
non-prehash Ed25519 (but the hash function is still needed to generate the
Crypto-ID itself).

nit(?): I think we tend to see "possesses the private key" more often than "has
the private-key", for parallelism with the "proof of possession" term of
art.

  The elliptic curves and the hash functions that can be used with this
  specification are listed in Table 2 in Section 8.3.  The signature
  scheme that specifies which combination is used is signaled by a

nit: this could be misread as saying that the Table is authoritative, not
the registry.

Section 4.1

  The Crypto-ID is derived from the public key and a modifier as
  follows:

  1.  The hash function indicated by the Crypto-Type is applied to the
      CIPO.  Note that all the reserved and padding bits MUST be set to
      zero.
  2.  The leftmost bits of the resulting hash, up to the size of the
      ROVR field, are used as the Crypto-ID.

This construction seems to allow for some malleability, in that an attacker
who observes a given Crypto-ID and CIPO could produce a related, valid,
Crypto-ID by reducing the ROVR length and truncating what was received.  I
haven't attempted to explore what (if any) potential consequences there are
of such malleability, and would like to know if anyone else has already done
so.  It looks like the NDPSO construction includes the length of the
Crypto-ID, so it would be hard for an attacker to do much with such a
truncated Crypto-ID, but attacks only get better...

Section 4.2

nit: I confess I'm missing what compels us to produce a de novo definition
of the "Status" field (and Length field) as opposed to deferring to the RFC
8505 definition, as we do for most of the other fields.

Section 4.3

  Crypto-Type:  8-bit unsigned integer.  The type of cryptographic
      algorithm used in calculation Crypto-ID (see Table 2 in
      Section 8.3).  Although the different signature schemes target
      similar cryptographic strength, they rely on different curves,
      hash functions, signature algorithms, and/or representation
      conventions.

While the currently-defined signature schemes target similar cryptographic
strength, do we need to imply that all future ones will also target a
similar strength (especially since Section 8.3 admits the possibility of
"better security")?

  Modifier:  8-bit unsigned integer.  Set to an arbitrary value by the
      creator of the Crypto-ID.  The role of the modifier is to enable
      the formation of multiple Crypto-IDs from a same key pair, which
      reduces the traceability and thus improves the privacy of a
      constrained node that could not maintain many key-pairs.

It may be worth digging in a little further to the threat model being
addressed here -- while I laud the ability to have multiple Crypto-IDs from
a single keypair, it seems that the tracking-prevention this affords implies
an attacker who can observe Crypto-IDs, most likely at multiple points in
the network.  Are Crypto-IDs used for anything other than EAROs?  I don't
have a great sense for how likely it is that an attacker in position to
observe (a subset of) EAROs would not also be in a position to observe at
least one associated CIPO, which includes all the information needed to
generate the Crypto-ID other than the Modifier.  With only an 8-bit Modifier
space, brute-forcing the other possible Crypto-IDs for that keypair is not
terribly strenuous, whereas allowing for a (potentially variable length?)
larger Modifier, say 64 bits, would substantially increase the work-factor
needed to predict (and store!) other Crypto-IDs that might be used for this
keypair.  Given that the CIPO already carries the public key itself, it's
not entirely clear how space-constrained we are so as to limit this to just
8 bits of modifier.

  Padding:  A variable-length field completing the Public Key field to
      align to the next 8-bytes boundary.

(MUST be set to zero by sender and ignored by receiver, as well?)

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

But multiple signature algorithm implementations will not?

Section 4.4

Is there some more discussion to have about how NDPSO includes only a
specific fixed set of information under the signature but RSAO signs all
options that appear prior to it in the message?

nit: style suggests parallelism between the Section 4.3 and 4.4 introductory
remarks (e.g., "this specification defines the NDP Signature Option
(NDPSO)").

  As opposed to the RSA Signature Option (RSAO) defined in section 5.2.
  of SEND [RFC3971], the NDPSO does not have a key hash field.  The
  hash that can be used as index is the 128 leftmost bits of the ROVR
  field in the EARO.

nit: this last sentence perhaps leaves more context implicit than the reader
might like; I suggest "Instead, the leftmost 128 bits of the ROVR field in
the sibling EARO are used to lookup the key used for signature verification,
[left-padded with zeros if needed]".  (I added the part in square brackets
because I'm not sure that anything guarantees the ROVR will actually contain
128 bits -- when AP-ND is not in use its typically just 64 bits, right?)

  Pad Length:  8-bit unsigned integer.  The length of the Padding
      field.

(In octets?)

  Padding:  A variable-length field making the option length a multiple
      of 8, containing as many octets as specified in the Pad Length
      field.  Typically there is no need of a padding and the field is
      NULL.

Just to check: nothing requires the use of minimal-length padding to achieve
the required alignment, and padding of 200+ bytes is permitted by the spec,
albeit silly?

Section 6

  This specification enables the 6LR to verify the ownership of the
  binding at any time assuming that the "C" flag is set.  The
  verification prevents other nodes from stealing the address and
  trying to attract traffic for that address or use it as their source
  address.

nit: I think that the verification cannot be done unilaterally by the 6LR,
so maybe "enables the 6LR to challenge the node to verify its ownership of
the binding at any time" is better.

  A node may use multiple IPv6 addresses at the same time.  The node
  MAY use the same Crypto-ID, to prove the ownership of multiple IPv6
  addresses.  The separation of the address and the cryptographic

nit: no comma

  material avoids the constrained device to compute multiple keys for

nit: "avoids the need for"

  multiple addresses.  The registration process allows the node to use
  the same Crypto-ID for all of its addresses.

nit(?): We could potentially mention again the ability to use different
Crypto-IDs with a single keypair, though there's not any clear need to do
so.

Section 6.1

Mostly just for my own elucidation, where is it first specified to put the
address being registered in the Target Address field of the NS message?

  detrimental to the battery lifetime.  Alternatively, the device may
  use an always-incrementing value saved in the same stable storage as
  the key, so they are lost together, and starting at a best effort
  random value, either as Nonce value or as a component to its
  computation.

nit: "as the Nonce value".

  and the NDPSO containing the signature.  The information associated
  to a Crypto-ID stored by the 6LR on the first NS exchange where it
  appears.  The 6LR MUST store the CIPO parameters associated with the

nit: I think there's a verb missing in this sentence ("MUST be"?)

        |------- NS with EARO, CIPO, NonceLN and NDPSO -------->|

(This still includes the Crypto-ID, even if there's not room in the figure
to explicition indicate that, right?)

  *  Upon the first exchange with a 6LR, a 6LN will be challenged to
      prove ownership of the Crypto-ID and the Target Address being

How is the "first exchange" tracked?  Just whether the 6LR knows about the
registered IPv6 address, or the L2 address, or something else?  In
particular, if a 6LR has cached an IP address/ROVR binding, and an attacker
tries to join that 6LR with that address/ROVR, what controls whether the 6LR
will challenge the attacker's 6LN?  Is it purely at the 6LR's discretion?

  *  The challenge is triggered when the registration for a Source
      Link-Layer Address is not verifiable either at the 6LR or the
      6LBR.  In the latter case, the 6LBR returns a status of
      "Validation Requested" in the DAR/DAC exchange, which is echoed by
      the 6LR in the NA (EARO) back to the registering node.  The
      challenge MUST NOT alter a valid registration in the 6LR or the
      6LBR.

nit(?): the previous bullet describes a case where the 6LR MUST issue a
challenge; my understanding is that this bullet describes an additional way
in which challenges can occur (i.e., when the 6LBR doesn't know about the
address registration either).  Stylistically, it might be more clear to
reword this as being an "additional case" on top of the previous one, as
opposed to the current wording which tries to be very general about when a
challenge can happen, which is neither a parallel construction to the
previous bullet nor particularly clear about what new information is being
conveyed by this bullet.

  *  In order to validate the ownership, the 6LR performs the same
      steps as the 6LN and rebuilds the Crypto-ID based on the
      parameters in the CIPO.  If the rebuilt Crypto-ID matches the
      ROVR, the 6LN also verifies the signature contained in the NDPSO
      option.  If at that point the signature in the NDPSO option can be
      verified, then the validation succeeds.  Otherwise the validation
      fails.

I worry a little bit that we haven't fully specified the entire list of
steps the 6LR takes to follow the cryptographic chain and validate that the
6LN holds the key in question and registers the address in question to the
Crypto-ID in question.  I don't have a specific thing in mind that the 6LR
might forget, but if we explicitly state what things are bound to what other
things, the 6LR is less likely to make a security-relevant mistake.

Section 6.2

Might we want to include the Modifier or the Crypto-ID itself in the signed
data, in addition to the public key, to avoid any potential misbinding?

  2.  JWK-encoded public key

[just to check: JWK-encoding means that we have an injective map and aren't
subject to some sort of extension attack?  Not that such a thing would be
easy to pull off, with a strict registry of Crypto-Types, of course]

  6.  The length of the ROVR field in the NS message containing the
      Crypto-ID that was sent.

nit: is this really the NS "that was sent" as opposed to the NS under
construction that contains the NDPSO?  (This is related to my question up in
Section 6.1.)  Tying the initial NS to the followup one requires more state
on the 6LR (though the 6LR probably already had to keep state for the Nonce)
and makes some of the verification steps a bit tougher to implement
correctly.

  7.  1-byte (in network byte order) Crypto-Type value sent in the CIPO
      option.

nit: Is there any byte order with distinct representation from network byte
order, for a 1-byte quantity?  ;)

  *  Depending on the Crypto-Type, apply the hash function on this
      concatenation.

nit: is this clearer as "Apply the hash function (if any) specified by the
Crypto-Type to the concatenated data"?

  *  Depending on the Crypto-Type, sign the hash output with ECDSA (if
      curve P-256 is used) or sign the hash with EdDSA (if curve Ed25519
      (PureEdDSA)).

nit: this text is not very consistent with the idea of an extensible
registry of Crypto-Types; similar "apply the signature algorithm specified
by the Crypto-Type" language to what I suggested above may be appropriate.

  The 6LR on receiving the NDPSO and CIPO options first regenerates the
  Crypto-ID based on the CIPO option to make sure that the leftmost
  bits up to the size of the ROVR match.  If and only if the check is

In the vein of my previous questions about where the Crypto-ID appears and
truncation/malleability, this text seems to leave some room for confusion
about how many bits of output are being compared, and compared to what.

  *  Depending on the Crypto-Type indicated by the (6LN) in the CIPO,
      apply the hash function on this concatenation.

[similar comment as above]

  *  Verify the signature with the public-key received and the locally
      computed values.  If the verification succeeds, the 6LR and 6LBR
      add the state information about the Crypto-ID, public-key and
      Target Address being registered to their database.

This might be a place to reiterate the FCFS nature of address registration,
though it's hardly necessary.

Section 6.3

  In a multihop 6LoWPAN, a 6LBR sends RAs with prefixes downstream and
  the 6LR receives and relays them to the nodes. 6LR and 6LBR
  communicate using ICMPv6 Duplicate Address Request (DAR) and
  Duplicate Address Confirmation (DAC) messages.  The DAR and DAC use
  the same message format as NS and NA, but have different ICMPv6 type
  values.

  In AP-ND we extend DAR/DAC messages to carry cryptographically
  generated ROVR.  In a multihop 6LoWPAN, the node exchanges the
  messages shown in Figure 6.  The 6LBR must identify who owns an
  address (EUI-64) to defend it, if there is an attacker on another
  6LR.

This description feels a little vague to me -- I'm interested in knowing how
the 6LBR gains confidence that a proof-of-possession was provided to the
6LR, and how the ROVR gets validated at 6LBR and 6LR when the 6LN in
question moves to a new 6LR.  What information remains local to (each) 6LR
and what is communicated between 6LR and 6LBR?
This also relates to the "how trusted are 6LRs?" question I mentioned
earlier.

Section 7

It might be appropriate to talk about how the NonceLR and NonceLN combine to
ensure contributory behavior from both 6LR and 6LN, and that each protects
against a different type of replay attack.

Section 7.1

  Duplicate Address Detection DoS Attack:  Inside the LLN, Duplicate
      Addresses are sorted out using the ROVR, which differentiates it
      from a movement.  DAD coming from the backbone are not forwarded
      over the LLN, which provides some protection against DoS attacks
      inside the resource-constrained part of the network.  Over the
      backbone, the EARO option is present in NS/NA messages.  This
      protects against misinterpreting a movement for a duplication, and
      enables the backbone routers to determine which one has the
      freshest registration and is thus the best candidate to validate
      the registration for the device attached to it.  But this
      specification does not guarantee that the backbone router claiming
      an address over the backbone is not an attacker.

Where do we specify the behavior of the 6LBR to reject EAROs when the 6LBR
is not the one with the freshest registration?  Or do I misunderstand the
discussion of "freshest registration"?

  Replay Attacks  Using Nonces (NonceLR and NonceLN) generated by both
      the 6LR and 6LN provides an efficient protection against replay
      attacks of challenge response flow.  The quality of the protection
      still depends on the quality of the Nonce, in particular of a
      random generator if they are computed that way.

It's probably worth noting explicitly that we do not require unpredictable
nonces, just non-repeating ones.

  Neighbor Discovery DoS Attack:  A rogue node that managed to access
      the L2 network may form many addresses and register them using AP-
      ND.  The perimeter of the attack is all the 6LRs in range of the
      attacker.  The 6LR MUST protect itself against overflows and
      reject excessive registration with a status 2 "Neighbor Cache
      Full".  This effectively blocks another (honest) 6LN from
      registering to the same 6LR, but the 6LN may register to other
      6LRs that are in its range but not in that of the rogue.

Are there L2 technologies where L2 media keys are tied to L2 address, so a
rogue node might be rate-limited or given a quota based on L2 address?

Section 7.2

  address.  This specification frees the device to form its addresses
  in any fashion, thereby enabling not only 6LoWPAN compression which
  derives IPv6 addresses from Layer-2 addresses but also privacy
  addresses.

We noted in Section 1 that the 6lo adaptation layer requires use of
L2-address-based IPv6 address selection, so it's not clear how it would be
valid to use privacy addresses with this specification.

Section 7.3

We seem to be assuming for these calculations/discussion that the hash used
for calculating the Crypto-ID is a well-behaved cryptographic hash and thus
that random collisions are the only ones possible.  It would be worth
mentioning that weaknesses in the hashes associated with a given Crypto-Type
could allow attackers to make more targetted collision attempts.

  The formula for calculating the probability of a collision is 1 -
  e^{-k^2/(2n)} where n is the maximum population size (2^64 here,
  1.84E19) and K is the actual population (number of nodes).  If the

nit: minuscule vs. majuscule 'k'/'K'

Section 7.4

  The signature schemes referenced in this specification comply with
  NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards
  [RFC8032] and offer strong algorithmic security at roughly 128-bit
  security level.  These signature schemes use elliptic curves that

Do we want to make any forward-looking statement about the expected strength
of future-defined Crypto-Types?  ("No" is a fine answer...)

Section 7.5

The text here is more about cross-algorithm attacks than cross-protocol
ones.  It would be great to see some text about cross-protocol attacks
added, too (e.g., prohibiting use of the keypair for anything other than
AP-ND).

Section 7.6

  This specification distributes the challenge and its validation at
  the edge of the network, between the 6LN and its 6LR.  The central
  6LBR is offloaded, which avoids DOS attacks targeted at that central
  entity.  This also saves back and forth exchanges across a

nit: "the central 6LBR is offloaded" reads very oddly, as the offloading is
of work from the 6LBR, but the 6LBR itself remains in place.

  The downside is that the 6LBR needs to trust the 6LR for performing
  the checking adequately, and the communication between the 6LR and
  the 6LBR must be protected to avoid tempering with the result of the
  test.

I'd prefer to see some more details about the nature of the required
protection for 6LR/6LBR communications.

  If a 6LR is compromised, it may pretend that it owns any address and
  defeat the protection.  It may also admit any rogue and let it take
  ownership of any address in the network, provided that the 6LR knows
  the ROVR field used by the real owner of the address.

nit: this language could probably be tightened up to be more precise about
the hazards.

Section 8.3

  New Crypto-Type values providing similar or better security (with
  less code) may be defined in the future.

I'm not sure what purpose the "with less code" requirement serves.  It seems
to needlessly constrain future actions.

Section 11

Curve25519 support is a MAY, so I think RFC 7748 belongs as normative;
likewise for RFCs 8032 and 6234.

It's probably better to cite RFC 7696 as BCP 201 directly.

Section B.3

It would be great if the document shepherd could diff the paramters listed
here against [CURVE-REPRESENTATIONS].

[Ballot comment]
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)?

[Ballot discuss]
Thank you for the work put into this document. I found the document easy to read. Please find below a trivial-to-fix DISCUSS (and I am requesting a reply and/or action on this one) plus some non-blocking COMMENTs and NITs.


I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 4.4 --
The length of the reserved field is not specified. Or am I missing something obvious ?

[Ballot comment]
== COMMENTS ==

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

-- Section 4.3 and 4.4 --
Why is the Pad Length field a 8-bit field while the actual padding will always be less than 8 bytes. Suggest to make it a 3 or 4 bits field and extend the reserved field.

-- Section 6.1 --
About "Nonce option MUST contain a random Nonce value that was never used with this device", how can it be done? Keeping a local history? Giving some operational hints would bee welcome. Especially, when there are multiple 6LR in the LLN: how can they synchronize the nonce?

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

== NITS ==

-- Section 2.2 --
To be honest, I am not a big fan of simply announcing concepts and referring to many other RFCs. Suggest to mention which terms and concepts are defined in each document. Else, the current section 2.2 mostly forces the readers to read all the references.

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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-6lo-ap-nd-12. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the CGA Extension Type Tags registry on the Cryptographically Generated Addresses (CGA) Message Type Name Space registry page located at:

https://www.iana.org/assignments/cga-message-types/

a single, new registration is to be made as follows:

CGA Type Flag: 8701 55c8 0cca dd32 6ab7 e415 f148 84d0
Reference: [ RFC-to-be ]

Second, in the IPv6 Neighbor Discovery Option Formats registry on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

https://www.iana.org/assignments/icmpv6-parameters/

two, new option formats are to be registered as follows:

Type: [ TBD-at-Registration ]
Description: Crypto-ID Parameters Option (CIPO)
Reference: [ RFC-to-be; Section 4.3 ]

Type: [ TBD-at-Registration ]
Description: NDP Signature Option (NDPSO)
Reference: [ RFC-to-be; Section 4.4 ]

IANA understands that the authors have suggested values 39 and 38, respectively, for these registrations.

Third, a new registry is to be created called the Crypto-Type Subregistry. The new registry will be located on the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry page located at:

https://www.iana.org/assignments/icmpv6-parameters/

The new registry will be managed via Specification Required and IESG Approval as defined by RFC 8126. The registry has values between 0-255. There are initial values in the registry as follows:

Crypto Type Value: 0 (ECDSA256)
Elliptic Curve: NIST P-256 (FIPS186-4)
Hash Functions: SHA-256 (RFC6234)
Signature Algorithm: ECDSA (FIPS186-4)
Representation Conventions: Weierstrass, (un)compressed, MSB/msb first
Reference: [ RFC-to-be ]

Crypto Type Value: 1 (Ed25519)
Elliptic Curve: Curve25519 (RFC7748)
Hash Functions: SHA-512 (RFC6234)
Signature Algorithm: Ed25519 (RFC8032)
Representation Conventions: Edwards, compressed, LSB/lsb first
Reference: [ RFC-to-be ]

Crypto Type Value: 2 (ECDSA25519)
Elliptic Curve: Curve25519 (RFC7748)
Hash Functions: SHA-256 (RFC6234)
Signature Algorithm: ECDSA (FIPS186-4)
Representation Conventions: Weierstrass, (un)compressed, MSB/msb first
Reference: [ RFC-to-be ]

Crypto Type Values 3-255 will be marked unassigned.

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-01-09):

From: The IESG
To: IETF-Announce
CC: 6lo-chairs@ietf.org, shwethab@cisco.com, draft-ietf-6lo-ap-nd@ietf.org, Shwetha Bhandari , 6lo@ietf.org, suresh@kaloom.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Address Protected Neighbor Discovery for Low-power and Lossy Networks) to Proposed Standard


The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document: -
'Address Protected Neighbor Discovery for Low-power and Lossy Networks'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-01-09. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document specifies an extension to 6LoWPAN Neighbor Discovery
  (ND) protocol defined in RFC6775 and updated in RFC8505.  The new
  extension is called Address Protected Neighbor Discovery (AP-ND) and
  it protects the owner of an address against address theft and
  impersonation attacks in a low-power and lossy network (LLN).  Nodes
  supporting this extension compute a cryptographic identifier (Crypto-
  ID) and use it with one or more of their Registered Addresses.  The
  Crypto-ID identifies the owner of the Registered Address and can be
  used to provide proof of ownership of the Registered Addresses.  Once
  an address is registered with the Crypto-ID and a proof-of-ownership
  is provided, only the owner of that address can modify the
  registration information, thereby enforcing Source Address
  Validation.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Shepherd response:  Proposed Standard.
This enhances IPv6 ND for  address protection by updating ND options and messages.
It is indicated in the title.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Shepherd response:
Technical Summary

  This document specifies an extension to 6LoWPAN Neighbor Discovery
  (ND) protocol defined in RFC6775 and updated in RFC8505.  The new
  extension is called Address Protected Neighbor Discovery (AP-ND) and
  it protects the owner of an address against address theft and
  impersonation attacks in a low-power and lossy network (LLN).  Nodes
  supporting this extension compute a cryptographic identifier (Crypto-
  ID) and use it with one or more of their Registered Addresses.  The
  Crypto-ID identifies the owner of the Registered Address and can be
  used to provide proof of ownership of the Registered Addresses.  Once
  an address is registered with the Crypto-ID and a proof-of-ownership
  is provided, only the owner of that address can modify the
  registration information, thereby enforcing Source Address
  Validation.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Shepherd response:
This draft has been extensively discussed in 6lo and some of the crypto experts. Following a workgroup discussion on crypto in the draft and given the nature of crypto expertise required :
- Rene Struik joined as an author in -08 to help with the crypto details.
- Russ Housley reviewed -08 and suggested following directions for removing HashEdDSA  based on the decisions in RFC 8410 and RFC 8419 and curdle wg discussion.
- version 09 of the draft was updated to reference PureEdDSA (instead of earlier EdDSA25519ph). Additional sub-section  Implementation Attacks was added to the Security consideration.
- version 10 additional updates on the security processing, new security considerations, and organized  3 different schemes for the crypto computation : mixing  NIST P-256  and  Curve25519 (for the curves and  ECDSA and Ed25519) for the signature algorithms, associated with either SHA-256 or SHA-512 for the hash function.
- version 11 as part of shepherd review found that ND option definition can be made explicit, this resulted in the latest version 12.

With these reviews and discussions -12 is ready for IESG review.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
Shepherd response:
There are no implementations, but there are vendors have indicated plans to build 6lo defined backbone router as a product that would lead to adoption of this ND extensions.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

Shepherd response:
Charlie Perkins, Robert Moskowitz and Russ Housley have reviewed and found no substantive issues.

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
N/A

Personnel

Document Shepherd: Shwetha Bhandari
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
Shepherd response:
I have reviewed the document and my comments are addressed in version 12 that I think is ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Shepherd response:
No concerns


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Shepherd response:
As described above Security/Crypto expertise was needed, Rene Struik was added as an author to improve the quality of the document in terms of crypto related processing.
The document needs a detailed review from Security directorate as part of the IESG processing.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
Shepherd response: No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Shepherd response: All the authors have confirmed, no IPRs found.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Shepherd response: No IPRs found

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
Shepherd response: There have been discussions and consensus on its current state within the work group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Shepherd response: No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Shepherd response: No idnits found.
  -- The draft header indicates that this document updates RFC8505, but the
    abstract doesn't seem to directly say this.  It does mention RFC8505
    though, so this could be OK.
  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1'
  == Outdated reference: A later version (-04) exists of draft-ietf-lwig-curve-representations-03
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Shepherd response: N/A

(13) Have all references within this document been identified as
either normative or informative?
Shepherd response: Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
Shepherd response: None

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Shepherd response: There is a later version (-04) of
draft-ietf-lwig-curve-representations referenced in the Informative section.
I-D.ietf-6lo-backbone-router is in the informative section that may get updated based on reviews from 6man.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Shepherd response: updates RFC8505, it has been mentioned in the Abstract and discussed in the document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Shepherd response: Yes
Allocation of one new value for CGA Message Type[RFC 3972] name space is recorded.
New IANA registry  "Crypto-Type Subregistry" in the "Internet Control Message Protocol version 6 (ICMPv6) Parameter" with "Specification Required" and "IESG Approval" for extension is defined.
Request for 2 new IPv6 ND options is recorded.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Shepherd response: N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Shepherd response: Not applicable as there are no formal language constructs in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Shepherd response:  Proposed Standard.
This enhances IPv6 ND for  address protection by updating ND options and messages.
It is indicated in the title.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Shepherd response:
Technical Summary

  This document specifies an extension to 6LoWPAN Neighbor Discovery
  (ND) protocol defined in RFC6775 and updated in RFC8505.  The new
  extension is called Address Protected Neighbor Discovery (AP-ND) and
  it protects the owner of an address against address theft and
  impersonation attacks in a low-power and lossy network (LLN).  Nodes
  supporting this extension compute a cryptographic identifier (Crypto-
  ID) and use it with one or more of their Registered Addresses.  The
  Crypto-ID identifies the owner of the Registered Address and can be
  used to provide proof of ownership of the Registered Addresses.  Once
  an address is registered with the Crypto-ID and a proof-of-ownership
  is provided, only the owner of that address can modify the
  registration information, thereby enforcing Source Address
  Validation.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Shepherd response:
This draft has been extensively discussed in 6lo and some of the crypto experts. Following a workgroup discussion on crypto in the draft and given the nature of crypto expertise required :
- Rene Struik joined as an author in -08 to help with the crypto details.
- Russ Housley reviewed -08 and suggested following directions for removing HashEdDSA  based on the decisions in RFC 8410 and RFC 8419 and curdle wg discussion.
- version 09 of the draft was updated to reference PureEdDSA (instead of earlier EdDSA25519ph). Additional sub-section  Implementation Attacks was added to the Security consideration.
- version 10 additional updates on the security processing, new security considerations, and organized  3 different schemes for the crypto computation : mixing  NIST P-256  and  Curve25519 (for the curves and  ECDSA and Ed25519) for the signature algorithms, associated with either SHA-256 or SHA-512 for the hash function.
- version 11 as part of shepherd review found that ND option definition can be made explicit, this resulted in the latest version 12.

With these reviews and discussions -12 is ready for IESG review.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
Shepherd response:
There are no implementations, but there are vendors have indicated plans to build 6lo defined backbone router as a product that would lead to adoption of this ND extensions.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

Shepherd response:
Charlie Perkins, Robert Moskowitz and Russ Housley have reviewed and found no substantive issues.

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
N/A

Personnel

Document Shepherd: Shwetha Bhandari
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
Shepherd response:
I have reviewed the document and my comments are addressed in version 12 that I think is ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Shepherd response:
No concerns


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Shepherd response:
As described above Security/Crypto expertise was needed, Rene Struik was added as an author to improve the quality of the document in terms of crypto related processing.
The document needs a detailed review from Security directorate as part of the IESG processing.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
Shepherd response: No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Shepherd response: All the authors have confirmed, no IPRs found.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Shepherd response: No IPRs found

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
Shepherd response: There have been discussions and consensus on its current state within the work group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Shepherd response: No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Shepherd response: No idnits found.
  -- The draft header indicates that this document updates RFC8505, but the
    abstract doesn't seem to directly say this.  It does mention RFC8505
    though, so this could be OK.
  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1'
  == Outdated reference: A later version (-04) exists of draft-ietf-lwig-curve-representations-03
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Shepherd response: N/A

(13) Have all references within this document been identified as
either normative or informative?
Shepherd response: Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
Shepherd response: None

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Shepherd response: There is a later version (-04) of
draft-ietf-lwig-curve-representations referenced in the Informative section.
I-D.ietf-6lo-backbone-router is in the informative section that may get updated based on reviews from 6man.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Shepherd response: updates RFC8505, it has been mentioned in the Abstract and discussed in the document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Shepherd response: Yes
Allocation of one new value for CGA Message Type[RFC 3972] name space is recorded.
New IANA registry  "Crypto-Type Subregistry" in the "Internet Control Message Protocol version 6 (ICMPv6) Parameter" with "Specification Required" and "IESG Approval" for extension is defined.
Request for 2 new IPv6 ND options is recorded.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Shepherd response: N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Shepherd response: Not applicable as there are no formal language constructs in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Shepherd response:  Proposed Standard.
This enhances IPv6 ND for  address protection by updating ND options and messages.
It is indicated in the title.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Shepherd response:
Technical Summary

  This document specifies an extension to 6LoWPAN Neighbor Discovery
  (ND) protocol defined in RFC6775 and updated in RFC8505.  The new
  extension is called Address Protected Neighbor Discovery (AP-ND) and
  it protects the owner of an address against address theft and
  impersonation attacks in a low-power and lossy network (LLN).  Nodes
  supporting this extension compute a cryptographic identifier (Crypto-
  ID) and use it with one or more of their Registered Addresses.  The
  Crypto-ID identifies the owner of the Registered Address and can be
  used to provide proof of ownership of the Registered Addresses.  Once
  an address is registered with the Crypto-ID and a proof-of-ownership
  is provided, only the owner of that address can modify the
  registration information, thereby enforcing Source Address
  Validation.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Shepherd response:
This draft has been extensively discussed in 6lo and some of the crypto experts. Following a workgroup discussion on crypto in the draft and given the nature of crypto expertise required :
- Rene Struik joined as an author in -08 to help with the crypto details.
- Russ Housley reviewed -08 and suggested following directions for removing HashEdDSA  based on the decisions in RFC 8410 and RFC 8419 and curdle wg discussion.
- version 09 of the draft was updated to reference PureEdDSA (instead of earlier EdDSA25519ph). Additional sub-section  Implementation Attacks was added to the Security consideration.
- version 10 additional updates on the security processing, new security considerations, and organized  3 different schemes for the crypto computation : mixing  NIST P-256  and  Curve25519 (for the curves and  ECDSA and Ed25519) for the signature algorithms, associated with either SHA-256 or SHA-512 for the hash function.
- version 11 as part of shepherd review found that ND option definition can be made explicit, this resulted in the latest version 12.

With these reviews and discussions -12 is ready for IESG review.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
Shepherd response:
There are no implementations, but there are vendors have indicated plans to build 6lo defined backbone router as a product that would lead to adoption of this ND extensions.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

Shepherd response:
Charlie Perkins, Robert Moskowitz and Russ Housley have reviewed and found no substantive issues.

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
N/A

Personnel

Document Shepherd: Shwetha Bhandari
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
Shepherd response:
I have reviewed the document and my comments are addressed in version 12 that I think is ready for IESG review.


(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Shepherd response:
No concerns


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Shepherd response:
As described above Security/Crypto expertise was needed, Rene Struik was added as an author to improve the quality of the document in terms of crypto related processing.
The document needs a detailed review from Security directorate as part of the IESG processing.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
Shepherd response: No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Shepherd response: All the authors except B. Sarikaya have confirmed.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Shepherd response: No IPRs found

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
Shepherd response: There have been discussions and consensus on its current state within the work group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Shepherd response: No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Shepherd response: No idnits found.
  -- The draft header indicates that this document updates RFC8505, but the
    abstract doesn't seem to directly say this.  It does mention RFC8505
    though, so this could be OK.
  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'
  -- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1'
  == Outdated reference: A later version (-04) exists of draft-ietf-lwig-curve-representations-03
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Shepherd response: N/A

(13) Have all references within this document been identified as
either normative or informative?
Shepherd response: Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
Shepherd response: None

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Shepherd response: There is a later version (-04) of
draft-ietf-lwig-curve-representations referenced in the Informative section.
I-D.ietf-6lo-backbone-router is in the informative section that may get updated based on reviews from 6man.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Shepherd response: updates RFC8505, it has been mentioned in the Abstract and discussed in the document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Shepherd response: Yes
Allocation of one new value for CGA Message Type[RFC 3972] name space is recorded.
New IANA registry  "Crypto-Type Subregistry" in the "Internet Control Message Protocol version 6 (ICMPv6) Parameter" with "Specification Required" and "IESG Approval" for extension is defined.
Request for 2 new IPv6 ND options is recorded.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Shepherd response: N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Shepherd response: Not applicable as there are no formal language constructs in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Shepherd response:  Proposed Standard.
This enhances IPv6 ND for  address protection by updating ND options and messages.
It is indicated in the title.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Shepherd response:
Technical Summary

  This document specifies an extension to 6LoWPAN Neighbor Discovery
  (ND) protocol defined in RFC6775 and updated in RFC8505.  The new
  extension is called Address Protected Neighbor Discovery (AP-ND) and
  it protects the owner of an address against address theft and
  impersonation attacks in a low-power and lossy network (LLN).  Nodes
  supporting this extension compute a cryptographic identifier (Crypto-
  ID) and use it with one or more of their Registered Addresses.  The
  Crypto-ID identifies the owner of the Registered Address and can be
  used to provide proof of ownership of the Registered Addresses.  Once
  an address is registered with the Crypto-ID and a proof-of-ownership
  is provided, only the owner of that address can modify the
  registration information, thereby enforcing Source Address
  Validation.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Shepherd response:
This draft has been extensively discussed in 6lo and some of the crypto experts. Following a workgroup discussion on crypto in the draft and given the nature of crypto expertise required :
- Rene Struik joined as an author in -08 to help with the crypto details.
- Russ Housley reviewed -08 and suggested following directions for removing HashEdDSA  based on the decisions in RFC 8410 and RFC 8419 and curdle wg discussion.
- version 09 of the draft was updated to reference PureEdDSA (instead of earlier EdDSA25519ph). Additional sub-section  Implementation Attacks was added to the Security consideration.
- version 10 additional updates on the security processing, new security considerations, and organized  3 different schemes for the crypto computation : mixing  NIST P-256  and  Curve25519 (for the curves and  ECDSA and Ed25519) for the signature algorithms, associated with either SHA-256 or SHA-512 for the hash function.

With these reviews and discussions -11 is almost ready for IESG review.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
Shepherd response:
There are no implementations, but  there are vendors have indicated plans to build 6lo defined backbone router as a product that would lead to adoption of this ND extensions.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

Shepherd response:
Charlie Perkins, Robert Moskowitz and Russ Housley have reviewed and found no substantive issues.

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
N/A

Personnel

Document Shepherd: Shwetha Bhandari
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
Shepherd response:
I have reviewed -11 of the document.
One open question being discussed with the authors.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Shepherd response:
No concerns


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Shepherd response:
As described above Security/Crypto expertise was needed, Rene Struik was added as an author to improve the quality of the document in terms of crypto related processing.
The document needs a detailed review from Security directorate as part of the IESG processing.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
Shepherd response: Discussion in progress on redefinition of IPv6 ND option 11.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Shepherd response: In progress

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Shepherd response: No IPRs found

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
Shepherd response: There have been discussions and consensus on its current state within the work group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Shepherd response: No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Shepherd response: No idnits found. Following warnings/comments were found in -11 version:
  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'
-- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1'
== Outdated reference: A later version (-03) exists of
    draft-ietf-lwig-curve-representations-01
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Shepherd response: N/A

(13) Have all references within this document been identified as
either normative or informative?
Shepherd response: Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
Shepherd response: NO

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Shepherd response: There is a later version (-03) of
draft-ietf-lwig-curve-representations-01 referenced in the Informative section.
I-D.ietf-6lo-backbone-router is in the informative section that may get updated based on reviews from 6man.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Shepherd response: updates RFC8505, it has been mentioned in the Abstract and discussed in the document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Shepherd response: Yes
Allocation of one new value for CGA Message Type[RFC 3972] name space is recorded.
New IANA registry  "Crypto-Type Subregistry" in the "Internet Control Message Protocol version 6 (ICMPv6) Parameter" with "Specification Required" and "IESG Approval" for extension is defined.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Shepherd response: N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Shepherd response: Not applicable as there are not formal language constructs in the document.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Shepherd response:  Proposed Standard.
This enhances IPv6 ND for  address protection by updating ND options and messages.
It is indicated in the title.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Shepherd response:
Technical Summary

  This document specifies an extension to 6LoWPAN Neighbor Discovery
  (ND) protocol defined in RFC6775 and updated in RFC8505.  The new
  extension is called Address Protected Neighbor Discovery (AP-ND) and
  it protects the owner of an address against address theft and
  impersonation attacks in a low-power and lossy network (LLN).  Nodes
  supporting this extension compute a cryptographic identifier (Crypto-
  ID) and use it with one or more of their Registered Addresses.  The
  Crypto-ID identifies the owner of the Registered Address and can be
  used to provide proof of ownership of the Registered Addresses.  Once
  an address is registered with the Crypto-ID and a proof-of-ownership
  is provided, only the owner of that address can modify the
  registration information, thereby enforcing Source Address
  Validation.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Shepherd response:
This draft has been extensively discussed in 6lo and some of the crypto experts. Following a workgroup discussion on crypto in the draft and given the nature of crypto expertise required :
- Rene Struik joined as an author in -08 to help with the crypto details.
- Russ Housley reviewed -08 and suggested following directions for removing HashEdDSA  based on the decisions in RFC 8410 and RFC 8419 and curdle wg discussion.
- version 09 of the draft was updated to reference PureEdDSA (instead of earlier EdDSA25519ph). Additional sub-section  Implementation Attacks was added to the Security consideration.
- version 10 additional updates on the security processing, new security considerations, and organized  3 different schemes for the crypto computation : mixing  NIST P-256  and  Curve25519 (for the curves and  ECDSA and Ed25519) for the signature algorithms, associated with either SHA-256 or SHA-512 for the hash function.

With these reviews and discussions -11 is almost ready for IESG review.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
Shepherd response:
There are no implementations, but  there are vendors have indicated plans to build 6lo defined backbone router as a product that would lead to adoption of this ND extensions.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

Shepherd response:
Charlie Perkins, Robert Moskowitz and Russ Housley have reviewed and found no substantive issues.

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
N/A

Personnel

Document Shepherd: Shwetha Bhandari
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
Shepherd response:
I have reviewed -11 of the document.
One open question being discussed with the authors.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Shepherd response:
No concerns


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Shepherd response:
As described above Security/Crypto expertise was needed, Rene Struik was added as an author to improve the quality of the document in terms of crypto related processing.
The document needs a detailed review from Security directorate as part of the IESG processing.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
Shepherd response: Discussion in progress on redefinition of IPv6 ND option 11.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Shepherd response: In progress

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Shepherd response: No IPRs found

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
Shepherd response: There have been discussions and consensus on its current state within the work group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Shepherd response: No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Shepherd response: No idnits found. Following warnings/comments were found in -11 version:
  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'
-- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1'
== Outdated reference: A later version (-03) exists of
    draft-ietf-lwig-curve-representations-01
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Shepherd response: N/A

(13) Have all references within this document been identified as
either normative or informative?
Shepherd response: Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
Shepherd response: NO

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Shepherd response: There is a later version (-03) of
draft-ietf-lwig-curve-representations-01 referenced in the Informative section.
I-D.ietf-6lo-backbone-router is in the informative section that may get updated based on reviews from 6man.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Shepherd response: updates RFC8505, it has been mentioned in the Abstract and discussed in the document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Shepherd response: Yes
Allocation of one new value for CGA Message Type[RFC 3972] name space is recorded.
New IANA registry  "Crypto-Type Subregistry" in the "Internet Control Message Protocol version 6 (ICMPv6) Parameter" with "Specification Required" and "IESG Approval" for extension is defined.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Shepherd response: N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Shepherd response: Yes

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?
Shepherd response:  Proposed Standard.
This enhances IPv6 ND for  address protection by updating ND options and messages.
It is indicated in the title.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Shepherd response:
Technical Summary

  This document specifies an extension to 6LoWPAN Neighbor Discovery
  (ND) protocol defined in RFC6775 and updated in RFC8505.  The new
  extension is called Address Protected Neighbor Discovery (AP-ND) and
  it protects the owner of an address against address theft and
  impersonation attacks in a low-power and lossy network (LLN).  Nodes
  supporting this extension compute a cryptographic identifier (Crypto-
  ID) and use it with one or more of their Registered Addresses.  The
  Crypto-ID identifies the owner of the Registered Address and can be
  used to provide proof of ownership of the Registered Addresses.  Once
  an address is registered with the Crypto-ID and a proof-of-ownership
  is provided, only the owner of that address can modify the
  registration information, thereby enforcing Source Address
  Validation.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Shepherd response:
This draft has been extensively discussed in 6lo and some of the crypto experts. Following a workgroup discussion on crypto in the draft and given the nature of crypto expertise required :
- Rene Struik joined as an author in -08 to help with the crypto details.
- Russ Housley reviewed -08 and suggested following directions for removing HashEdDSA  based on the decisions in RFC 8410 and RFC 8419 and curdle wg discussion.
- version 09 of the draft was updated to reference PureEdDSA (instead of earlier EdDSA25519ph). Additional sub-section  Implementation Attacks was added to the Security consideration.
- version 10 additional updates on the security processing, new security considerations, and organized 3 different schemes for the crypto computation : ECDSA256, Ed25519, ECDSA25519
With these reviews and discussions -11 is almost ready for IESG review.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification?
Shepherd response:
There are no implementations, but  there are vendors have indicated plans to build 6lo defined backbone router as a product that would lead to adoption of this ND extensions.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

Shepherd response:
Charlie Perkins, Robert Moskowitz and Russ Housley have reviewed and found no substantive issues.

If  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?
N/A

Personnel

Document Shepherd: Shwetha Bhandari
Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.
Shepherd response:
I have reviewed -11 of the document.
One open question being discussed with the authors.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
Shepherd response:
No concerns


(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
Shepherd response:
As described above Security/Crypto expertise was needed, Rene Struik was added as an author to improve the quality of the document in terms of crypto related processing.
The document needs a detailed review from Security directorate as part of the IESG processing.


(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.
Shepherd response: Discussion in progress on redefinition of IPv6 ND option 11.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.
Shepherd response: In progress

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Shepherd response: No IPRs found

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 
Shepherd response: There have been discussions and consensus on its current state within the work group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
Shepherd response: No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
Shepherd response: No idnits found. Following warnings/comments were found in -11 version:
  -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-4'
-- Possible downref: Non-RFC (?) normative reference: ref. 'SEC1'
== Outdated reference: A later version (-03) exists of
    draft-ietf-lwig-curve-representations-01
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
Shepherd response: N/A

(13) Have all references within this document been identified as
either normative or informative?
Shepherd response: Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
Shepherd response: NO

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
Shepherd response: There is a later version (-03) of
draft-ietf-lwig-curve-representations-01 referenced in the Informative section.
I-D.ietf-6lo-backbone-router is in the informative section that may get updated based on reviews from 6man.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
Shepherd response: updates RFC8505, it has been mentioned in the Abstract and discussed in the document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
Shepherd response: Yes
Allocation of one new value for CGA Message Type[RFC 3972] name space is recorded.
New IANA registry  "Crypto-Type Subregistry" in the "Internet Control Message Protocol version 6 (ICMPv6) Parameter" with "Specification Required" and "IESG Approval" for extension is defined.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
Shepherd response: N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
Shepherd response: Yes

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  Relevant content can frequently be found in the abstract
  and/or introduction of the document. If not, this may be
  an indication that there are deficiencies in the abstract
  or introduction.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?



(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as
either normative or informative?

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.