Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 3 Feb 2020 18:05:10 +0000

Dear Benjamin

Many thanks for your in depth review!

Considering the amount of changes I published 16 just to make a statement of the current exchange.

https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-16

Hopefully this should make you validation of the proposed changes easier.

Please see below for the discussion:

> ----------------------------------------------------------------------
> 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.)

My bug, when I address Eric's review; the key length is expressed as 11 bits, so the max size for a key is 2K bytes. 
Beyond that it will not fit in the ND option format and we will need to fragment it.

> 
> 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?

Let us take this one separately in a thread with the co authors

> 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.

Suggest to add at the end of 4.1 
"
   At the time of this writing, a minimal size for the Crypto-ID of 128
   bits is RECOMMENDED.  This value is bound to augment in the future.
"

The ROVR is only a consequence I guess

> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for this well-written document!  

Thank *you*! Your reviews are always incredible. Really, really appreciated.

> It will be good to see this stuff getting deployed.

Indeed! It is much simpler to do than SEND, still it will take a bit of persuading needed to progress this into the products and stacks.

> 
> 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)?

Indeed an issue that implementation have to look as. 
Short addresses are a trick that 802.15.4 introduces to build shorter frames. I'd like to avoid mentioning them specifically since now 6Lo applies to a great many MACs and PHYs. I think your point is that using short addresses provides a hard 64K boundary for the pool of address. 

RFC 8505 has:

   The registration mechanism may be used by a rogue node to attack the
   6LR or 6LBR with a denial-of-service attack against the registry.  It
   may also happen that the registry of a 6LR or 6LBR is saturated and
   cannot take any more registrations; this scenario effectively denies
   the requesting node the capability to use a new address.

Suggestion to grow section 7.2 as follows:

7.2.  Related to 6LoWPAN ND

   The threats and mediations discussed in 6LoWPAN ND [RFC6775][RFC8505]
   also apply here, in particular denial-of-service attacks against the
   registry at the 6LR or 6LBR.

   Secure ND [RFC3971] forces the IPv6 address to be cryptographic since
   it integrates the CGA as the IID in the IPv6 address.  In contrast,
   this specification saves about 1Kbyte in every NS/NA message.  Also,
   this specification separates the cryptographic identifier from the
   registered IPv6 address so that a node can have more than one IPv6
   address protected by the same cryptographic identifier.

   With this specification the 6LN can freely form its IPv6 address(es)
   in any fashion, thereby enabling not only 6LoWPAN compression for
   IPv6 addresses that are derived from Layer-2 addresses, but also
   temporary addresses, e.g., formed pseudo-randomly and released in
   relatively short cycles for privacy reasons [RFC8064][RFC8065].  This
   specification provides added protection for addresses that are
   obtained following due procedure [RFC8505] but does not constrain the
   way the addresses are formed or the number of addresses that are used
   in parallel by a same entity.  A rogue may still perform denial-of-
   service attack against the registry at the 6LR or 6LBR, or attempt to
   deplete the pool of available addresses at Layer-2 or Layer-3.

> 
> 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]

Spot on. As you kept on reading you found that you analysis is exactly correct and that we explain that in section 7.6.
We are taking steps towards zerotrust in RPL and ND, one at a time. The thing you could not see there but will see next is https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-09#section-3.2.3 

From there we'll need to extend RPL to challenge along a path, and something for the 6LBR as well. It all appears quite doable, but yet to be designed : )

> 
>    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.

What about:
"
   The protected address registration protocol proposed in this document
   provides the same conceptual benefit as Source Address Validation
   (SAVI) [RFC7039] that only the owner of an IPv6 address may source
   packets with that address.  As opposed to [RFC7039], which relies on
   snooping protocols, the protection is based on a state that is
   installed and maintained in the network by the owner of the address.
   With this specification, a 6LN may use a 6LR for forwarding an IPv6
   packets if and only if it has registered the address used as source
   of the packet with that 6LR. 
"

> 
>    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?

Clarifying that this is a side note:

"
   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.  As a side note, 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 from cryptographic keys.
"

> 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).
> 

Changed "proof" to " overall mechanism". 
The point we want to make is that implementation cost and the code footprint, which is a typical concern in constrained IOT.

> 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.

Made the change

> 
>    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.

Clarifying questions: 
- This spec is authoritative for listing the elliptic curves and the hash functions that it supports, correct? 
- The registry is authoritative for the setting of values, which may change if this draft is obsoleted, is that your point?

From there I'm unsure what to do. The goal is to keep the focus on the bill of material of what needs to be implemented.
If that helps I can add (values to be confirmed by IANA) as follows?

"   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
   Crypto-Type (values to be confirmed by IANA) in a new IPv6 ND Crypto-
   ID Parameters Option (CIPO, see Section 4.3) that contains the
   parameters that are necessary for the proof, a Nonce option
   ([RFC3971]) and a NDP Signature option (Section 4.4).
"

> 
> 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...

The point is that the Crypto-ID remains in the 6LBR is its original form, size and value. A shorted Crypto-ID is a different Crypto-ID even if bits match. Truncated per se does not help vs. any other change.
Also, the attacker would have to be on path of the initial registration. If that is so, and it wants to update the ROVR, it can do that a lot more.
Now, the crypto-ID dictates the size of the ROVR not the other way around, so I fixed:
"
The leftmost bits of the resulting hash, up to the desired size, are used as the Crypto-ID.
"
Anything else I should consider doing?

> 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.

True, it was just a copy. Changed to 

   Length:  Defined in [RFC8505].

   Status:  Defined in [RFC8505].

> 
> 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")?

Certainly, the intention was not to imply that for the future, just a remark on the current.
Moved text from there into the presentation before the figure, as

"

   *  This specification uses signature schemes which target similar
      cryptographic strength but rely on different curves, hash
      functions, signature algorithms, and/or representation
      conventions.  Future specification may extend this for different
      cryptographic algorithms and longer keys, e.g., to provide a
      better security properties or a simpler implementation.

"

-----------------------------------------

>    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?   

No, to my best knowledge the crypto ID is not used elsewhere so far. 

>           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

But with the backbone router work everyone on the backbone will see it (see https://datatracker.ietf.org/doc/draft-ietf-6lo-backbone-router/). The goal here is to avoid an easy correlation between several addresses owned by a same node. Note that the Routing Proxy enable the 6BBR to provide its own SLLAO to the nodes on the backbone so many nodes may be hidden behind a same MAC address

> 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.

The CIPO for now does not circulate over the network but is contained between 6LR and 6LN.

> 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

But the point is that the attacker does not have the public key.

> 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

Yes but at the same time it makes it easier to brute-force forge a Crypto-ID that has the same value as the one of the owner from a different key by rotating the large Modifier on a same key, as opposed to forming new keys. 

> 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.

Open to change, but with the current balance with the CIPO local to the 6LN / 6LR I'm not convinced it's a good idea.
Please let me know if you want to continue on that topic and we'll make it a thread.

------------------

> 
>    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?)

Done

>    The implementation of multiple hash functions in a constrained
>    devices may consume excessive amounts of program memory.
> 
> But multiple signature algorithm implementations will not?

draft-ietf-lwig-curve-representations discussed in the next section enables to factorize code, if I understand well.
But to your point, what about the following clarification:

"
   The implementation of multiple hash functions in a constrained
   devices may consume excessive amounts of program memory.  This
   specification enables the use of SHA-256 [RFC6234] for all the
   supported ECC curves.

   Some code factorization is also possible for the ECC computation
   itself.  [CURVE-REPRESENTATIONS] provides information on how to
   represent Montgomery curves and (twisted) Edwards curves as curves in
   short-Weierstrass form and illustrates how this can be used to
   implement elliptic curve computations using existing implementations
   that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4]
   prime curves.

   For more details on representation conventions, we refer to
   Appendix B.

"

> 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?

Does not hurt to add it. The text in 4.4 would now look like

"
   As opposed to the RSA Signature Option (RSAO)  <...>

   Another difference is that the NDPSO signs a fixed set of fields as
   opposed to all options that appear prior to it in the that bears the
   signature.  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. "

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

Added:

"
   This specification defines the NDP Signature Option (NDPSO).  The
   NDPSO carries the signature that proves the ownership of the Crypto-ID.
"
  
>    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?)

Per your comment we recommend 128 bits minimum. Keeping it at 64 bits was not the intention. 
Not sure why you meant by sibling; the text would become

"
   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.
   Instead, the leftmost 128 bits of the ROVR field in the EARO are used
   to retrieve the CIPO that contains the key material used for signature
   verification, left-padded if needed.

"

> 
>    Pad Length:  8-bit unsigned integer.  The length of the Padding
>       field.
> 
> (In octets?)

Actually it's probably better for this field and the below to move to the way we did the previous option
More below:

>    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?
> 

You're right. It looks better to reuse the text in the previous option and we get:

"

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |Reserved1|  Signature Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            Reserved2                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      .                                                               .
      .                   Digital Signature                           .
      .                                                               .
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      .                                                               .
      .                           Padding                             .
      .                                                               .
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3: NDP signature Option

   Type:  to be assigned by IANA, see Table 1.

   Length:  8-bit unsigned integer.  The length of the option in units
      of 8 octets.

   Reserved1:  5-bit unsigned integer.  It MUST be set to zero by the
      sender and MUST be ignored by the receiver.

   Digital Signature Length:  11-bit unsigned integer.  The length of
      the Digital Signature field in bytes.

   Reserved2:  32-bit unsigned integer.  It MUST be set to zero by the
      sender and MUST be ignored by the receiver.

   Digital Signature:  A variable-length field containing a digital
      signature.  The computation of the digital signature depends on
      the Crypto-Type which is found in the associated CIPO.  For the
      values of the Crypto-Type that are defined in this specification,
      the signature is computed as detailed in Section 6.2.

   Padding:  A variable-length field completing the Digital Signature
      field to align to the next 8-bytes boundary.  It MUST be set to
      zero by the sender and MUST be ignored by the receiver.
"

> 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.

Applied

> 
>    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

Removed

> 
>    material avoids the constrained device to compute multiple keys for
> 
> nit: "avoids the need for"

done

> 
>    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.

"
   A node may use more than one IPv6 address at the same time.  The
   separation of the address and the cryptographic material avoids
   avoids the need for the constrained device to compute multiple keys
   for multiple addresses.  The 6LN MAY use the same Crypto-ID to prove
   the ownership of multiple IPv6 addresses.  The 6LN MAY also derive
   multiple Crypto-IDs from a same key.

"

> 
> 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?

That's a change introduced in RFC 8505. Added the reference.

> 
>    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".

Done

> 
>    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"?)

"

   The 6LR MUST store the information associated to a Crypto-ID on the
   first NS exchange where it appears in a fashion that the CIPO
   parameters can be retrieved from the Crypto-ID alone.

"

> 
>         |------- 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?)

The Crypto-ID is placed in the ROVR field of the EARO. 
There's text after the picture that reminds of this.
More interesting is that the CIPO can be omitted if the same Crypto-ID is used for more than one registration.

> 
>    *  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?

Changing the text in section 6 to be more specific on that:
"

   The 6LR/6LBR ensures first-come/first-serve by storing the ROVR
   associated to the address being registered upon the first
   registration and rejecting a registration with a different ROVR
   value.  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.
 
   This specification enables the 6LR to challenge the 6LN to verify its
   ownership of the binding by placing a Crypto-ID in the ROVR.  The
   challenge can happen at any time at the discretion of the 6LR.  The
   6LR MUST challenge the 6LN when it creates a binding and when a new
   registration attempts to change a parameter of the binding that
   identifies the 6LN, for instance its Source Link-Layer Address.  The
   verification protects against a rogue that would steal an address and
   attract its traffic, or use it as source address. 

"

This specification does not protect the MAC layer and if an attacker can impersonate the MAC address of the owner then it originate packets, but that does not change the binding, and the owner will still get its packet, cc the attacker. If the owner moves it will register elsewhere and the binding will move. Without the key,  the attacker cannot lock the state and it will lose access to the data.

> 
>    *  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.

Moved that text next to the one quoted above in 6. The text is not specific to the first registration.

"
   The challenge can also triggered by the 6LBR, e.g., to enforce a
   global policy.  In that 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.  A valid
   registration in the 6LR or the 6LBR MUST NOT be altered until the
   challenge is complete.
"

> 
>    *  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.

Another one that I'd rather take separately. Further talks are needed since I do not see a specific action to take right now, 

> 
> 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]

Another thing to pull on a separate thread : )

> 
>    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.

The ROVR size should not change, otherwise it is a different ROVR altogether.
Whanged to 
"
The length of the ROVR field containing the Crypto-ID
"

> 
>    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?  ;)

Removed (in network byte order) twice since there's the 6LR side too

>    *  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"?

Done

> 
>    *  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.

Proposed result:
"
   *  Apply the hash function (if any) specified by the Crypto-Type to
      the concatenated data, e.g., hash the resulting data using SHA-
      256.

   *  Apply the signature algorithm specified by the Crypto-Type, e.g.,
      sign the hash output with ECDSA (if curve P-256 is used) or sign
      the hash with EdDSA (if curve Ed25519 (PureEdDSA)).

"

> 
>    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.

I'm unsure what you mean here. Based on my response above, can you please reopen is needed, with some clarification?

>    *  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.

There was a typo there, the public key Is not stored there and is only available to the 6LR. Remove "public-key".
The text becomes

"

   *  Apply the hash function (if any) specified by the Crypto-Type
      indicated by the 6LN in the CIPO to the concatenated data.

   *  Verify the signature with the public-key in the CIPO and the
      locally computed values using the signature algorithm specified by
      the Crypto-Type.  If the verification succeeds, the 6LR propagates
      the information to the 6LBR using a EDAR/EDAC flow.  Due to the
      first-come/first-serve nature of the registration, if the address
      is not registered to the 6LBR, then flow succeeds and both the 6LR
      and 6LBR add the state information about the Crypto-ID and Target
      Address being registered to their respective abstract database.

"

> 
> 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.

This is really old text that should have been remassaged since.

6.3 is now one page as follows, please met me know if this still misses your point.
The EDAR contains the registered address and the ROVR. With that the 

"
6.3.  Multihop Operation

   A new 6LN that joins the network auto-configures an address and
   performs an initial registration to a neighboring 6LR with an NS
   message that carries an Address Registration Option (EARO) [RFC8505].

   In a multihop 6LoWPAN, the registration with Crypto-ID is propagated
   to 6LBR as shown in Figure 6, which illustrates the registration flow
   all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER].

   The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate
   Address Request (EDAR) and Extended Duplicate Address Confirmation
   (EDAC) messages [RFC8505] as shown in Figure 6.  This specification
   extends EDAR/EDAC messages to carry cryptographically generated ROVR.

   The assumption is that the 6LR and the 6LBR maintain a security
   association, so there is no need to propagate the proof of ownership
   to the 6LBR.  The 6LBR implicitly trusts that the 6LR performs the
   verification when the 6LBR requires it, and if there is no further
   exchange from the 6LR to remove the state, that the verification
   succeeded.

        6LN              6LR             6LBR            6BBR
         |                |               |                |
         |   NS(EARO)     |               |                |
         |--------------->|               |                |
         |                | Extended DAR  |                |
         |                |-------------->|                |
         |                |               |                |
         |                |               | proxy NS(EARO) |
         |                |               |--------------->|
         |                |               |                | NS(DAD)
         |                |               |                | ------>
         |                |               |                |
         |                |               |                | <wait>
         |                |               |                |
         |                |               | proxy NA(EARO) |
         |                |               |<---------------|
         |                | Extended DAC  |                |
         |                |<--------------|                |
         |   NA(EARO)     |               |                |
         |<---------------|               |                |
         |                |               |                |

                      Figure 6: (Re-)Registration Flow

"

> 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.

I added text that you suggested earlier in the spec.
Also changed 7.1, see below

> 
> 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"?

This is the backbone router draft based on freshness computation from RFC 8505.
Added references.

> 
>    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.

All together we get:
"
   Replay Attacks  Using Nonces (NonceLR and NonceLN) generated by both
      the 6LR and 6LN ensure a contributory behavior that provides an
      efficient protection against replay attacks of the challenge/
      response flow.  A nonce should never repeat for a same key.  The
      protection depends on the quality of the Nonce computation, e.g.,
      of a random number generator when used to compute the Nonce.
"

> 
>    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?

It can be done, even with 802.15.4. But sadly that's uncommon in practical deployments.

> 
> 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.

Only the optimal compression requires it. Privacy defeats that compression, meaning that both L2 and L3 addresses need to be passed in full.

Twisted the text to 
"
   With this specification the 6LN can freely form its IPv6 address(es)
   in any fashion, thereby enabling either 6LoWPAN compression for IPv6
   addresses that are derived from Layer-2 addresses, or temporary
   addresses, e.g., formed pseudo-randomly and released in relatively
   short cycles for privacy reasons [RFC8064][RFC8065], that cannot be
   compressed.

"

> 
> 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.

True, but is there such a problem with SHA-256 and SHA-512? 

I'd rather avoid discussing "bad hash" that we do not use, but retiain your point.
Proposal to change the text to 
"
   A collision of Registration Ownership Verifiers (ROVR) (i.e., the
   Crypto-ID in this specification) is possible, but it is a rare event.
   Assuming in the calculations/discussion below 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, the formula
   (birthday paradox) 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, assuming
   one Crypto-ID per node).

   If the Crypto-ID is 64-bits (the least possible size allowed), the
   chance of a collision is 0.01% for network of 66 million nodes.
   Moreover, the collision is only relevant when this happens within one
   stub network (6LBR).  In the case of such a collision, a third party
   node would be able to claim the registered address of an another
   legitimate node, provided that it wishes to use the same address.  To
   prevent address disclosure and avoid the chances of collision on both
   the RIVR and the address, it is RECOMMENDED that nodes do not derive
   the address being registered from the ROVR. "

> 
>    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'

Fixed

> 
> 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...)

Hum ... 
Deferring answer but not too keen in having forward looking stuff that's not needed to implement in a std track.
My ball in that space is a particularly obscure dark cristal. But I'm open to proposals.

> 
> 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).

Agreed. What about: 

"
7.5.  Cross-Algorithm and Cross-Protocol Attacks

   The keypair used in this specification can be self-generated and the
   public key does not need to be exchanged, e.g., through certificates,
   with a third party before it is used.  New keypairs can be formed for
   new registration as the node desires.  On the other hand, it is safer
   to allocate a keypair that is used only for the address protection
   and only for one signature scheme.  The same private key MUST NOT be
   reused with more than one signature scheme in this specification.
   The same private key MUST NOT be used for anything other than
   computing NDPSO signatures per this specification.

"
> 
> 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.

What about
"
This protects against DOS attacks targeted at that central 6LBR.
"

> 
>    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.

Text in the main spec has 
"
  The assumption is that the 6LR and the 6LBR maintain a security association, so there is no need to propagate the proof of ownership to the 6LBR.
"
But I'm not aware of people using anything beyond Layer-2 security. The EDAR/EDAC are unicast ICMPv6 messages; what would be your recommendation to protect them at L3?

> 
>    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.
> 

"

7.6.  Compromised 6LR

   This specification distributes the challenge and its validation at
   the edge of the network, between the 6LN and its 6LR.  This protects
   against DOS attacks targeted at that central 6LBR.  This also saves
   back and forth exchanges across a potentially large and constrained
   network.  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.

   If a 6LR is compromised, and provided that it knows the ROVR field
   used by the real owner of the address, the 6LR may pretend that the
   owner has moved, is now attached to it and has successfully passed the
   Crypto-ID validation.  The 6LR may then attract and inject traffic at
   will on behalf of that address.  Similarly, the 6LR may admit any
   rogue and let it take ownership of any address in the network for
   which it knows the value of ROVR.
"
> 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.

Removed 
> 
> 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.

Done

> 
> Section B.3
> 
> It would be great if the document shepherd could diff the paramters listed here
> against [CURVE-REPRESENTATIONS].
> 
Actually we have a co author in common : )

So many thanks!

As I said I published 16 for just the above, because the amount of changes inline in the mail becomes hard to swallow. 
Still please let me know which items require more attention  and more changes; we still have a nimber of open items (3) for which I launched separate threads

All the best

Pascal

---

From: Rene Struik <[email-masked]>
Date: Mon, 3 Feb 2020 15:53:31 -0500

As to Ben's comment below:
I registered COSE and JOSE code points for ECDSA25519 and for Wei25519 
in the lwig document. See: 
https://tools.ietf.org/html/draft-ietf-lwig-curve-representations-08#page-13

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 3 Feb 2020 19:01:43 -0800

> Hopefully this should make you validation of the proposed changes easier.

It is easier to see many of them; thanks.
Lots of good stuff in here; if I don't comment it looks good.

>    bits is RECOMMENDED.  This value is bound to augment in the future.

Sounds good.

> Short addresses are a trick that 802.15.4 introduces to build shorter frames. I'd like to avoid mentioning them specifically since now 6Lo applies to a great many MACs and PHYs. I think your point…

That's probably what I meant, yes, though I would have had to look up the
actual number :)

>    deplete the pool of available addresses at Layer-2 or Layer-3.

Very nice!

> From there we'll need to extend RPL to challenge along a path, and something for the 6LBR as well. It all appears quite doable, but yet to be designed : )

I'll just say "keep up the good work!"

> - The registry is authoritative for the setting of values, which may change if this draft is obsoleted, is that your point?

I think we have different interpertations.
I was assuming (based more on general practices than the specific text in
this document, to be clear) that the idea is that new Crypto-Types could be
specified and added to the registry, and implementations incorporate them,
without needing to revise or update this specification: the registered
Crypto-Type would contain all the information needed to integrate with the
mechanisms specified here.  In that mindset, any list of algorithms in this
document becomes out of date once the first additional Crypto-Type is
registered, and the question of what algorithms the specification supports
is more open-ended than just the literal words on the page.

>    ([RFC3971]) and a NDP Signature option (Section 4.4).

To make a more concrete question: suppose I wanted to use SHAKE256/256 as a
hash function paired with ECDSA on curve25519.  What would need to happen
to enable that?  The text above implies that, since SHAKE256/256 is not
listed in the table, it's not allowed for use with this specification, and
thus that I'd need to Update this specification in order to allow its use.

> Anything else I should consider doing?

The only other thing I would *consider* doing (which is not to say that
it's clear it should be done) is to include the desired size as input to
the hash.  But I don't have any specific reason to do that or attack that
would be stymied by doing so.

>       better security properties or a simpler implementation.

Okay, thanks for explaining.

> Please let me know if you want to continue on that topic and we'll make it a thread.

Your explanation of the topology suffices to convince me that the mechanism
as specified does add value; I don't think we need to have a broader
discussion of potential alternate constructions at this time.

Hmm, but Table 2 lists SHA-512 (not SHA-256) for crypto-type 1 (though I
guess type 2 is SHA-256 on the same curve).

>    For more details on representation conventions, we refer to

That looks good (assuming that I understand correctly about the SHA-256
bit).

>    that would signed with a RSAO. "

Well said!

>    verification, left-padded if needed.

I think "sibling" was intended to be the case when the EARO and the CIPO
appear in the same NS as "sibling options" within the NS.  (Though as you
note the CIPO could have been previously received in a different message.)
This text is probably okay, though I guess the reader has to know that
there's an EARO associated with the NDPSO.

> You're right. It looks better to reuse the text in the previous option and we get:

Thanks!

> That's a change introduced in RFC 8505. Added the reference.

Ah, I think I was looking for it (and failing to find it) in some of the
earlier documents.

> This specification does not protect the MAC layer and if an attacker can impersonate the MAC address of the owner then it originate packets, but that does not change the binding, and the owner will…

Understood, and this new text looks good.

> I'm unsure what you mean here. Based on my response above, can you please reopen is needed, with some clarification?

I was trying to get at how the NDPSO includes the Crypto-ID length in the
signed data, but the 6LR has to determine what length to use from the
length of the ROVR in the NS.  This is in general not terribly interesting
since an on-path attacker could change "anything" that would be input to the
signature validation, but seemed a little more interesting to me because of
the way that an attacker could truncate the Crypto-ID, and the truncation
would not be directly detectable in the EARO/ROVR but would only be
detected during signature validation.  That is, the 6LR would replicate the
Crypto-ID calculation from the CIPO, and the Crypto-ID would *appear* to
match up, but the signature in the NDPSO would fail to validate.  I have in
general a preference to make the reason for failure apparent closer to the
error, if possible, but in this specific case the system as a whole seems
to work okay even though the error is detected "one step later" than it
could be.  (Adding the target output length into the hash input for
Crypto-ID calculation as I mentioned above as an option would make this
error detected at the first possible point, when validating the Crypto-ID
calculation.)

>    exchange from the 6LR to remove the state, that the verification

Perhaps it goes without saying (as part of DAD), but the 6LBR has to
consult its database of ROVR/IP address to determine what response to give
in the DAC.  Part of my question above was about what state the 6LBR needs
and what verifciation the 6LBR does as part of the process -- am I correct
that it's just checking whether (1) the requested address is already
registered and (if so) (2) that the ROVR in the EARO matches the one
registered with the requested address?

>          |   NS(EARO)     |               |                |

I'd consider "A nonce should never repeat for a single key, but nonces do
not need to be unpredictable for secure operation".

> It can be done, even with 802.15.4. But sadly that's uncommon in practical deployments.

I'll trust your judgment on whether it's common enough to be worth
mentioning.

>    short cycles for privacy reasons [RFC8064][RFC8065], that cannot be

This text is good.  I would suggest changing the Section-1 text, though, as
the current "requires a device [...] to enable a better compression" reads
as if the requirement is always present, and that the reason for the
requirement is to get the compression; instead, the situation is (IIUC)
that in order to get that compression, the node is required to choose its
address based on the L2 address.

> True, but is there such a problem with SHA-256 and SHA-512? 

None known at this time :)
If one develops in the future, we'd have to worry about it (and no doubt a
flood of other, more urgent, things...)

>    the address being registered from the ROVR. "

Thanks.

> This protects against DOS attacks targeted at that central 6LBR.

Works for me.

> But I'm not aware of people using anything beyond Layer-2 security. The EDAR/EDAC are unicast ICMPv6 messages; what would be your recommendation to protect them at L3?

At L3?  I don't know of much other than IPsec (or some tunneling solution).
But by "details" I meant more about whether confidentiality protection is
required or "merely" integrity protection and source-authentication.

>    which it knows the value of ROVR.

Thanks!

> Still please let me know which items require more attention  and more changes; we still have a nimber of open items (3) for which I launched separate threads

Thanks for all these (and the -16)!

-Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Feb 2020 14:14:21 +0000

Hello Benjamin

Whao, that was quick. Many thanks again!

I got a comment on the change to BCP201 and looked it up. Seems there was a confusion, BCP 201 is RFC 7696 not RFC 7748. So I rolled back the overload. Did you expect something else?

I'm publishing 17 for the delta below, we still have the 3 open points. Please check the diffs at 
https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-17.txt

> > Let us take this one separately in a thread with the co authors

I keep this item in the thread, to track that it's progressing separately

> > - The registry is authoritative for the setting of values, which may change if
> this draft is obsoleted, is that your point?
> 
> I think we have different interpretations.

Makes sense to me

> > From there I'm unsure what to do. The goal is to keep the focus on the bill
> of material of what needs to be implemented.

The registry has "Specification Required" or "IESG Approval". The "IESG Approval" path is for the case where the IES approves using the new hash with the draft as is. 
So yes, the spirit is that if the IESG determines that your case can happen without a change in the spec, the registry could be extended and the spec applied.
In that context, how does the following work:

"
   The elliptic curves and the hash functions listed in Table 2 in
   Section 8.3 can be used with this specification; more may be added in
   the future to the IANA registry.  The signature scheme that specifies
   which combination is used (including the curve and the representation
   conventions) is signaled by a Crypto-Type in a new IPv6 ND Crypto-ID
   Parameters Option (CIPO, see Section 4.3) that contains the
   parameters that are necessary for the proof, a Nonce option
   ([RFC3971]) and a NDP Signature option (Section 4.4).  The NA(EARO)
   is modified to enable a challenge and transport a Nonce option.
"

Note that this incorporate text to cover the discussion between Rene and Jim that different representation conventions imply different crypto-ids and cannot reuse the same keypair

> > The point is that the Crypto-ID remains in the 6LBR is its original form, size
> and value. A shorted Crypto-ID is a different Crypto-ID even if bits match.
> Truncated per se does not help vs. any other change.
> > Also, the attacker would have to be on path of the initial registration. If
> that is so, and it wants to update the ROVR, it can do that a lot more.

With RFC 8505 the 6LN decides the parameters of the registration without an indication from the router. So at the moment I cannot figure how to do that apart from config. We  are missing a mechanism to signal the expected format of the ROVR and other parameters such as recommended lifetimes for types of addresses, etc..., in the RA messages. That's also in the long term plan and I'm considering whether to do that at 6lo or 6MAN. 6MAN would be better but it is slow/reluctant to adopt RFC 8505 for general purpose.

> guess type 2 is SHA-256 on the same curve).
 
Yes, I understand that type 2 is less classical but enables the reuse of the SHA 256 hash.
I defer to Rene on this.

> there's an EARO associated with the NDPSO.

You right, does not hurt to be more specific. In section 4.4:

"
   An ND message that carries an NDPSO MUST have one and only one EARO.
   The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto-
   ID MUST be associated with the keypair used for the Digital Signature
   in the NDPSO.

"

> > I'm unsure what you mean here. Based on my response above, can you
> please reopen is needed, with some clarification?
> 

This could be achieved by placing the length of the ROVR in the CIPO. Making this change.
We already had the ROVR size in the signature. Note that in the signature the format of that size is not given. Would need 2 bytes if expressed in bytes.
I'd reword to use the option length of the EARO, which is expressed in units of 8 bytes and is stored in one octet. 
Works?

This leads to sparse changes, but mostly:

"

The signature generated by the 6LN to provide proof-of-ownership of
   the private-key is carried in the NDP Signature Option (NDPSO).  It
   is generated by the 6LN in a fashion that depends on the Crypto-Type
   (see Table 2 in Section 8.3) chosen by the 6LN as follows:

   *  Concatenate the following in the order listed:

   1.  The 128-bit Message Type tag [RFC3972] (in network byte order).
       For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415
       f148 84d0.  (The tag value has been generated by the editor of
       this specification on random.org).

<snip>

  6.  1-byte Option Length of the EARO containing the Crypto-ID.
  7.  1-byte Crypto-Type value sent in the CIPO.

<snap>

   The 6LR on receiving the NDPSO and CIPO options first checks that the
   EARO Length in the CIPO matches the length of the EARO.  If so it
   regenerates the Crypto-ID based on the CIPO to make sure that the
   leftmost bits up to the size of the ROVR match.

   If and only if the check is successful, it tries to verify the
   signature in the NDPSO option using the following:

   *  Concatenate the following in the order listed:

   1.  128-bit type tag (in network byte order)

<snoop>

  6.  1-byte EARO Length received in the CIPO.
  7.  1-byte Crypto-Type value received in the CIPO.

"

> and what verification the 6LBR does as part of the process -- am I correct

Yes, per RFC 8505, inherited from RFC 6775. I'd say that DAD expressed as you did is the core function of RFC 6775.
This draft does not really change the 6LBR, just adds the capability to stimulate a revalidation by the 6LR.

> not need to be unpredictable for secure operation".
Which leads to:
"

   Replay Attacks  A nonce should never repeat for a single key, but
      nonces do not need to be unpredictable for secure operation.
      Using nonces (NonceLR and NonceLN) generated by both the 6LR and
      6LN ensure a contributory behavior that provides an efficient
      protection against replay attacks of the challenge/response flow.
      The quality of the protection by a random nonce depends on the
      random number generator and its parameters (e.g., sense of time).
"

> address based on the L2 address.
Which  gives

"
   With the 6lo adaptation layer in [RFC4944] and [RFC6282], a 6LN can
   obtain a better compression for an IPv6 address with an Interface ID
   (IID) that is derived from a Layer-2 address.  As a side note, this
   is incompatible with Secure Neighbor Discovery (SeND) [RFC3971] and
   Cryptographically Generated Addresses (CGAs) [RFC3972], since they
   derive the IID from cryptographic keys, whereas this specification
   separates the IID and the key material. 
"

> association, so there is no need to propagate the proof of ownership to the
> 6LBR.
> > "
> > But I'm not aware of people using anything beyond Layer-2 security. The
> EDAR/EDAC are unicast ICMPv6 messages; what would be your
> recommendation to protect them at L3?
> 

In this case the merely is enough. The EDAR has the ROVR and the registered address. Those will appear later in ND flows anyway.
In the main text, :

"
   The assumption is that the 6LR and the 6LBR maintain a security
   association to authenticate and protect the integrity of the EDAR and
   EDAC messages, so there is no need to propagate the proof of
   ownership to the 6LBR.  The 6LBR implicitly trusts that the 6LR
   performs the verification when the 6LBR requires it, and if there is
   no further exchange from the 6LR to remove the state, that the
   verification succeeded.
"

Many more thanks!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 4 Feb 2020 14:22:23 +0000

This was truncated when I received the echo, retrying...

> -----Original Message-----
> From: Pascal Thubert (pthubert)
> Sent: mardi 4 février 2020 15:14
> To: Benjamin Kaduk <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; Shwetha
> Bhandari (shwethab) <[email-masked]>; [email-masked];
> [email-masked]
> Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with
> DISCUSS and COMMENT)
> 
> Hello Benjamin
> 
> I got a comment on the change to BCP201 and looked it up. Seems there was
> a confusion, BCP 201 is RFC 7696 not RFC 7748. So I rolled back the
> overload. Did you expect something else?
> 
> I'm publishing 17 for the delta below, we still have the 3 open points. Please
> check the diffs at https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-
> 17.txt
> 
> More below:
> 
> > > > within a given Crypto-Type value (as opposed to fixing the
> > > > representation
> > as a
> > > > 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?
> > >
> > > - This spec is authoritative for listing the elliptic curves and the
> > > hash
> > functions that it supports, correct?
> > I was assuming (based more on general practices than the specific text
> > in this document, to be clear) that the idea is that new Crypto-Types
> > could be specified and added to the registry, and implementations
> > incorporate them, without needing to revise or update this
> > specification: the registered Crypto-Type would contain all the
> > information needed to integrate with the mechanisms specified here.
> > In that mindset, any list of algorithms in this document becomes out
> > of date once the first additional Crypto-Type is registered, and the
> > question of what algorithms the specification supports is more open-ended
> than just the literal words on the page.
> 
> Makes sense to me
> 
> 
> > To make a more concrete question: suppose I wanted to use
> SHAKE256/256
> > as a hash function paired with ECDSA on curve25519.  What would need
> > to happen to enable that?  The text above implies that, since
> > SHAKE256/256 is not listed in the table, it's not allowed for use with
> > this specification, and thus that I'd need to Update this
> > specification in order to allow its use.
> 
> The registry has "Specification Required" or "IESG Approval". The "IESG
> Approval" path is for the case where the IES approves using the new hash
> with the draft as is.
> So yes, the spirit is that if the IESG determines that your case can happen
> without a change in the spec, the registry could be extended and the spec
> applied.
> Note that this incorporate text to cover the discussion between Rene and Jim
> that different representation conventions imply different crypto-ids and
> cannot reuse the same keypair
> 
> 
> > > >
> > > > Section 4.1
> > > >
> > > > 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
> > > > 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
> > > The leftmost bits of the resulting hash, up to the desired size, are
> > > used as
> > the Crypto-ID.
> > > "
> > The only other thing I would *consider* doing (which is not to say
> > that it's clear it should be done) is to include the desired size as
> > input to the hash.  But I don't have any specific reason to do that or
> > attack that would be stymied by doing so.
> >
> 
> With RFC 8505 the 6LN decides the parameters of the registration without an
> indication from the router. So at the moment I cannot figure how to do that
> apart from config. We  are missing a mechanism to signal the expected
> format of the ROVR and other parameters such as recommended lifetimes
> for types of addresses, etc..., in the RA messages. That's also in the long
> term plan and I'm considering whether to do that at 6lo or 6MAN. 6MAN
> would be better but it is slow/reluctant to adopt RFC 8505 for general
> purpose.
> 
> > > draft-ietf-lwig-curve-representations discussed in the next section
> > > enables
> > to factorize code, if I understand well.
> > Hmm, but Table 2 lists SHA-512 (not SHA-256) for crypto-type 1 (though
> > I guess type 2 is SHA-256 on the same curve).
> 
> > > Per your comment we recommend 128 bits minimum. Keeping it at 64
> > > bits
> > was not the intention.
> > I think "sibling" was intended to be the case when the EARO and the
> > CIPO appear in the same NS as "sibling options" within the NS.
> > (Though as you note the CIPO could have been previously received in a
> > different message.) This text is probably okay, though I guess the
> > reader has to know that there's an EARO associated with the NDPSO.
> >
> 
> > > > In the vein of my previous questions about where the Crypto-ID
> > > > appears
> > and
> > I was trying to get at how the NDPSO includes the Crypto-ID length in
> > the signed data, but the 6LR has to determine what length to use from
> > the length of the ROVR in the NS.  This is in general not terribly
> > interesting since an on-path attacker could change "anything" that
> > would be input to the signature validation, but seemed a little more
> > interesting to me because of the way that an attacker could truncate
> > the Crypto-ID, and the truncation would not be directly detectable in
> > the EARO/ROVR but would only be detected during signature validation.
> > That is, the 6LR would replicate the Crypto-ID calculation from the
> > CIPO, and the Crypto-ID would *appear* to match up, but the signature
> > in the NDPSO would fail to validate.  I have in general a preference
> > to make the reason for failure apparent closer to the error, if
> > possible, but in this specific case the system as a whole seems to
> > work okay even though the error is detected "one step later" than it
> > Crypto-ID calculation as I mentioned above as an option would make
> > this error detected at the first possible point, when validating the
> > Crypto-ID
> > calculation.)
> 
> We already had the ROVR size in the signature. Note that in the signature the
> format of that size is not given. Would need 2 bytes if expressed in bytes.
> > consult its database of ROVR/IP address to determine what response to
> > give in the DAC.  Part of my question above was about what state the
> > 6LBR needs and what verification the 6LBR does as part of the process
> > -- am I correct that it's just checking whether (1) the requested
> > address is already registered and (if so) (2) that the ROVR in the
> > EARO matches the one registered with the requested address?
> 
> Yes, per RFC 8505, inherited from RFC 6775. I'd say that DAD expressed as
> you did is the core function of RFC 6775.
> > I'd consider "A nonce should never repeat for a single key, but nonces
> > do not need to be unpredictable for secure operation".
> >
> Which leads to:
> "
> 
> > This text is good.  I would suggest changing the Section-1 text,
> > though, as the current "requires a device [...] to enable a better
> > compression" reads as if the requirement is always present, and that
> > the reason for the requirement is to get the compression; instead, the
> > situation is (IIUC) that in order to get that compression, the node is
> > required to choose its address based on the L2 address.
> >
> Which  gives
> 
> "
> > to the 6LBR.
> > But by "details" I meant more about whether confidentiality protection
> > is required or "merely" integrity protection and source-authentication.
> 
> In this case the merely is enough. The EDAR has the ROVR and the registered
> address. Those will appear later in ND flows anyway.
> In the main text, :
> 
> "

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 5 Feb 2020 13:15:43 +0000

Hello again Benjamin:

About your discuss below we published -18 that has text from Rene that removes the uncertainty on compression.
Please have a look at https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18 and let us know if the diffs correct the issue properly.

Many thanks again

Pascal

> From: Benjamin Kaduk via Datatracker <[email-masked]>
> Sent: samedi 1 février 2020 00:19
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Shwetha Bhandari (shwethab)
> <[email-masked]>; [email-masked]; Shwetha Bhandari (shwethab)
> <[email-masked]>; [email-masked]
> Subject: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS
> and COMMENT)
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-6lo-ap-nd-15: Discuss
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/
> 
> 
> 
> Thanks for this well-written document!  It will be good to see this stuff getting
> deployed.
> 
> IDs used for anything other than EAROs?  I don't have a great sense for how

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 5 Feb 2020 13:20:15 -0800

> This was truncated when I received the echo, retrying...

It appears different here as well; interesting.
I will remove a layer of quoting to make it easier for me to write a reply.

> overload. Did you expect something else?

I think I did expect something else; I thought I wrote:

% It's probably better to cite RFC 7696 as BCP 201 directly.                          
I guess maybe there was a copy/paste glitch.

> cannot reuse the same keypair

Understood; this looks good.

> would be better but it is slow/reluctant to adopt RFC 8505 for general

I was just thinking a field in the CIPO to indicate the length to truncate
the hash output at, which would still be chosen by the 6LN.  Which I see
you already did per below; great :)

> Yes, I understand that type 2 is less classical but enables the reuse of the SHA

I was just commenting about "enables the use of SHA-256" since it also
allows other hashes.  But the words as written are true, so I have no real
objection.

Thanks!

>   6.  1-byte Option Length of the EARO containing the Crypto-ID.

I think just having this length in the CIPO suffices; we would not
necessarily need to also include it in the signature input separtaely.
(But it does no harm to do so.)

> stimulate a revalidation by the 6LR.

It sounds like it does go without saying :)
Thanks for confirming.

Thanks!

-Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Feb 2020 09:50:05 +0000

Hello Benjamin

We're getting there.  I snipped the places were we appear to have converged.

Please let me know if the DISCUSS is now solved (we removed all ambiguity on the crypto-ID and forced that a key is employed uniquely for the purpose of this draft and for one crypto-ID).

More below:

> From: Benjamin Kaduk <[email-masked]>
> Sent: mercredi 5 février 2020 22:20
> To: Pascal Thubert (pthubert) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; Shwetha Bhandari
> (shwethab) <[email-masked]>; [email-masked]; [email-masked]
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with
> DISCUSS and COMMENT)
> 
> > I got a comment on the change to BCP201 and looked it up. Seems there
> > was a confusion, BCP 201 is RFC 7696 not RFC 7748. So I rolled back
> > the overload. Did you expect something else?
> 

Oups then : ) I changed the reference, also for BCP 26.

> > > > > 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

Please consider the changes in  https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18.txt 
Did we clear the DISCUSS?

> > > consult its database of ROVR/IP address to determine what response
> > > to give in the DAC.  Part of my question above was about what state
> > > the 6LBR needs and what verification the 6LBR does as part of the
> > > process
> > Yes, per RFC 8505, inherited from RFC 6775. I'd say that DAD expressed
> > as you did is the core function of RFC 6775.
> It sounds like it does go without saying :) Thanks for confirming.

This draft is really an extension of RFC 8505 and cannot be implemented separately.
But I guess it does not hurt to clarify a little bit. Maybe by changing the first paragraph of section 3 as
"
   Section 5.3 of [RFC8505] introduces the ROVR that is used to detect
   and reject duplicate registrations in the DAD process.  The ROVR is a
   generic object that is designed for backward compatibility with the
   capability to introduce new computation methods in the future.  Using
   a Crypto-ID per this specification is the RECOMMENDED method.
   Section 7.3 discusses collisions when heterogeneous methods to
   compute the ROVR field coexist inside a same network.
"
Is that readable?

I'll publish this with the changes suggested by Roman

Thanks a million!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Feb 2020 12:13:43 +0000

Hello Benjamin 

<truncated again, retrying>

More below:

> Bhandari
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: 
> (with DISCUSS and COMMENT)
> 
> > I got a comment on the change to BCP201 and looked it up. Seems 
> > there was a confusion, BCP 201 is RFC 7696 not RFC 7748. So I rolled 
> > back the overload. Did you expect something else?
> 

> > > > > (Section 6.2.1.1).  I also am not finding the needed 
> > > > > codepoints registered in the
> > > JOSE

Thanks a million!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Feb 2020 12:59:45 +0000

Maybe like this?

Regards,

Pascal

> Le 6 févr. 2020 à 10:48, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Hello Benjamin
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Feb 2020 09:30:42 -0800

Hi Pascal,

> Please let me know if the DISCUSS is now solved (we removed all ambiguity on the crypto-ID and forced that a key is employed uniquely for the purpose of this draft and for one crypto-ID).

I think the technical aspects are all resolved and there just remains the
tiniest of process nits.  Specifically, in order to use some of the
algorithms we define in the protocol we define, we rely on the IANA
codepoints currently requested to be registered by [CURVE-REPRESENTATIONS].
So we have a normative dependency on those registrations being made, but
right now [CURVE-REPRESENTATIONS] is listed as only an informative
reference, so there's not anything that will enforce the sequencing of
publication.  It's probably easiest to promote that reference to being
normative and make a note (either near Table 2 or in the IANA
considerations) that we rely on the codepoints being registered by
[CURVE-REPRESENTATIONS].

Sorry to be so picky!

Thanks!

> Did we clear the DISCUSS?

[covered above]

>    generic object that is designed for backward compatibility with the

"backward compatibility with" is easy to misparse, so maybe add a comma, or
go with "backward compatibility but adds the capability"?

-Ben

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Feb 2020 18:09:18 +0000

Hello Benjamin

> > Please let me know if the DISCUSS is now solved (we removed all ambiguity
> on the crypto-ID and forced that a key is employed uniquely for the purpose of
> this draft and for one crypto-ID).
> 
> I think the technical aspects are all resolved and there just remains the tiniest
> of process nits.  Specifically, in order to use some of the algorithms we define
> in the protocol we define, we rely on the IANA codepoints currently requested
> to be registered by [CURVE-REPRESENTATIONS].
> publication.  It's probably easiest to promote that reference to being normative
> and make a note (either near Table 2 or in the IANA
> considerations) that we rely on the codepoints being registered by [CURVE-
> REPRESENTATIONS].
> 
> Sorry to be so picky!
> 

I'm happy to do the changes though it will delay a spec that 802.11 is waiting for.
But I fail to understand why we depend on a COSE or a JOSE registry to compute our signature.

What do I miss?

> > But I guess it does not hurt to clarify a little bit. Maybe by
> > changing the first paragraph of section 3 as "

I favor the comma over the "but" since it is not antagonistic (maybe my French?).
What about

"
   Section 5.3 of [RFC8505] introduces the ROVR that is used to detect
   and reject duplicate registrations in the DAD process.  The ROVR is a
   generic object that is designed for both backward compatibility and
   the capability to introduce new computation methods in the future.
"

?

: )

Pascal
> _______________________________________________
> 6lo mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Feb 2020 18:13:36 +0000

Hello again Benjamin

Provided we make the change, would a sentence like

"
   This specification depends on [CURVE-REPRESENTATIONS] to install the
   necessary codepoints in IANA registries for some of the listed curves
   above.

"

Work for you?

Many thanks again and again!

Pascal

> From: 6lo <[email-masked]> On Behalf Of Benjamin Kaduk
> Sent: jeudi 6 février 2020 18:31
> Cc: [email-masked]; [email-masked]; The IESG
> <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>;
> [email-masked]
> Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with
> DISCUSS and COMMENT)
> 
> Hi Pascal,
> 
> > > > there was a confusion, BCP 201 is RFC 7696 not RFC 7748. So I
> > > > rolled back the overload. Did you expect something else?
> > >
> > > > > > > that the compressed representation is not supported for
> > > > > > > P-256 (Section 6.2.1.1).  I also am not finding the needed
> > > > > > > registries to use ECDSA25519 (crypto-type 2) -- do we need
> > > > > > > to register anything there?
> > > > > >
> > Please consider the changes in
> > https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18.txt
> > > > > Perhaps it goes without saying (as part of DAD), but the 6LBR
> > > > > has to consult its database of ROVR/IP address to determine what
> > > > > response to give in the DAC.  Part of my question above was
> > > > > about what state the 6LBR needs and what verification the 6LBR
> > > > > does as part of the process
> > > > > -- am I correct that it's just checking whether (1) the
> > > > > requested address is already registered and (if so) (2) that the
> > > > > ROVR in the EARO matches the one registered with the requested
> address?
> > > >
> > > > Yes, per RFC 8505, inherited from RFC 6775. I'd say that DAD
> > > > expressed as you did is the core function of RFC 6775.
> > > > This draft does not really change the 6LBR, just adds the
> > > > capability to stimulate a revalidation by the 6LR.
> > >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 6 Feb 2020 18:32:04 +0000

Oh it’s the JWK encoding, right?

Would we speed things up if we just imported the IANA section from the LWIG draft?

Regards,

Pascal

> Le 6 févr. 2020 à 19:09, Pascal Thubert (pthubert) <[email-masked]> a écrit :
> 
> Hello Benjamin
> 
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 6 Feb 2020 13:05:15 -0800

Yes, just for the JWK encoding (so, the Wei25519 curve, IIUC).

Moving that IANA registration from the LWIG doc to here would keep us from
blocking on that document, yes -- I forgot that it was only in "AD
Evaluation" state and thought it was further along.

-Ben