Subject: [6lo] Attracting attention on a last minute change in AP-ND

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 17 Apr 2020 08:04:33 +0000

Dear WG:

Since we do not meet this IETF, there's no chance to present the proposed update to Ap ND in person.
The below changes 2 things in AP ND and asks an additional question.

ADDITIONAL QUESTION:
- The representation of the key is from the JSON space (JWK). Since LLNs are in scope, should we all the COSE Key object as an alternative?

CHANGE 1
- The full CIPO is included to the signed material, instead of the tuple ( JWK key , crypto ID ) both fields being taken from the CIPO as is in the current spec. This is done to enable other formats than JWK in the future by removing the term JWK from the text on the signature. Other fields may be added to the CIPO in the future, the signature would now protect those automagically. Note that this change was already done for the Crypto-ID during Benjamin's review.

CHANGE 2
- We add the way for the 6LR to signal its support JWK encoding. We use only a bit and do not advertise the list of Crypto-types that the 6LR supports, leaving the 6LN to trial and error, with a fall back to Crypto ID 0 that MUST be supported. 

SIDE question

About CHANGE 2, Should we do more? We could at an extreme list the supported Crypto IDs, or at the other support only Crypto ID 0 for now.

Please let us know what think, and the rationale associated

Many thanks

Pascal
-----Original Message-----
From: 6lo <[email-masked]> On Behalf Of Pascal Thubert (pthubert)
Sent: mercredi 15 avril 2020 14:04
To: Benjamin Kaduk <[email-masked]>; [email-masked]; Mohit Sethi M <[email-masked]>; Rene Struik <[email-masked]>
Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; Shwetha Bhandari (shwethab) <[email-masked]>
Subject: Re: [6lo] Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: (with DISCUSS and COMMENT)

Hello Benjamin and 6lo:

Just to let you know and the group that we are still chewing the IANA section on this draft.
Doing that we found 2 important things.

1) JWK may not be the favored format for the key representation in LLNs (vs.. COSE's Key Object)
2) We are lacking the signal to tell the 6LN that the 6LR supports AP-ND.

For 1)

We'll poll the list if we can live with JWK only for this version. We have prepared candidate text if not.

In the meantime, and to be opened to the future where more key representations come in, I believe we should extend a change we made for your review in the crypto-id computation and add the whole CIPO to the signed material, as opposed to selected fields from the CIPO (JWK-encoded public key and Crypto-Type value). Doing that, we'll be able to add different encodings, new flags that signal it, and have all that protected in the signature.

The text in "6.2.  NDPSO generation and verification" becomes:
"
*  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).
      2.  the CIPO
      3.  the 16-byte Target Address (in network byte order) sent in the
          Neighbor Solicitation (NS) message.  It is the address which
          the 6LN is registering with the 6LR and 6LBR.
      4.  NonceLR received from the 6LR (in network byte order) in the
          Neighbor Advertisement (NA) message.  The nonce is at least 6
          bytes long as defined in [RFC3971].
      5.  NonceLN sent from the 6LN (in network byte order).  The nonce
          is at least 6 bytes long as defined in [RFC3971].
      6.  1-byte Option Length of the EARO containing the Crypto-ID.
"
Which is echoed in the signature validation "
it tries to verify the
   signature in the NDPSO option using the following:

   *  Concatenate the following in the order listed:

      1.  The 128-bit Message Type tag specified above (in network byte
          order)
      2.  the CIPO
      3.  the 16-byte Target Address (in network byte order) received in
          the Neighbor Solicitation (NS) message.  It is the address
          which the 6LN is registering with the 6LR and 6LBR.
      4.  NonceLR sent in the Neighbor Advertisement (NA) message.  The
          nonce is at least 6 bytes long as defined in [RFC3971].
      5.  NonceLN received from the 6LN (in network byte order) in the
          NS message.  The nonce is at least 6 bytes long as defined in
          [RFC3971].
      6.  1-byte EARO Length received in the CIPO.
"
Is that OK?

2) is an easy change, we can extend the 6CIO as we do in RFC 8505 already:

"
4.5.  Extensions to the Capability Indication Option

   This specification defines 2 new capability bits in the 6CIO, defined
   by [RFC7400] for use by the 6LR and 6LBR in IPv6 ND RA messages.

   The "A" flag indicates that AP-ND is enabled in the network.  It is
   set by the 6LBR that serves the network and propagated by the 6LRs.

   The "J" flag indicates that the 6LR supports JWK-encoded keys in the
   CIPO option.

       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 = 1  |   Reserved    |J|A|D|L|B|P|E|G|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Reserved                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 4: New Capability Bits in the 6CIO

   New Option Fields:

   J:  1-bit flag.  This 6LR supports AP-ND with JWK encoding

   A:  1-bit flag.  This network supports AP-ND "
And
"
   This specification protects the ownership of the address.  Its use in
   a network is signaled by the 6LBR by setting the 'A' flag in the
   6CIO.  This is echoed by the 6LRs, that also indicate the key
   encoding format that they support in another 6CIO flag, currently the
   'J' flag for JWK.

   When using a ROVR that is a Crypto-ID, a 6LN MUST use a 6LR that
   supports the key encoding used in the CIPO.  If the 6LR does not
   support the Crypto-Type, it MUST reply with an EARO Status 10
   "Validation Failed" without a challenge.  In that case, the 6LN may
   try another Crypto-Type until it falls back to Crypto-Type 0 that
   MUST be supported by all 6LRs.
"

Does that work for you?

You all keep safe;

Pascal

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: vendredi 7 février 2020 01:10
> To: Rene Struik <[email-masked]>
> Cc: Pascal Thubert (pthubert) <[email-masked]>; The IESG 
> <[email-masked]>; [email-masked]; Shwetha Bhandari 
> (shwethab) <[email-masked]>; [email-masked]
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-6lo-ap-nd-15: 
> (with DISCUSS and COMMENT)
> 
> Hi Rene,
> 
> As implied by the later exchange with Pascal, it may be more expedient 
> to move the registration from the LWIG document into the AP-ND one, in 
> which case this question becomes moot.  But, for completeness, there 
> is not a strict need to change the intended status of the LWIG 
> document in order to use it as a normative reference from a proposed 
> standard -- we can run through a bit of an exception-handling process to do such a "downref"
> (which in many cases is not an exception, as there's now a list of 
> ones that are deemed to be acceptable without additional review:
> https://datatracker.ietf.org/doc/downref/).
> 
> -Ben
> 
> On Thu, Feb 06, 2020 at 12:49:18PM -0500, Rene Struik wrote:
> > Hi Ben:
> >
> > I just read your note below. Does this mean I should simply change 
> > the intended status of the next rev 
> > ofhttps://datatracker.ietf.org/doc/draft-ietf-lwig-curve-representat
> > io ns/ to Standards Track? Are there any procedural hoops that this 
> > would imply or can I just simply change the category field in
> >
> > 	<rfc category="std" ipr="trust200902" docName="draft-ietf-lwig-
> curve-representations-09">? (well, Rev-09 is not out yet, but almost...).
> >
> > BTW - the Rev-09 version will not change any of the existing 
> > technical
> content, so does not impact the IANA request section in the published 
> version (Rev-08).
> >
> > Best regards, Rene
> >
> > On 2/6/2020 12:30 PM, Benjamin Kaduk wrote:
> > > Hi Pascal,
> > >
> > > On Thu, Feb 06, 2020 at 12:13:43PM +0000, Pascal Thubert 
> > > (pthubert)
> wrote:
> > >> Hello Benjamin
> > >>
> > >> <truncated again, retrying>
> > >>
> > >> 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).
> > > 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!
> > >
> > >> More below:
> > >>
> > >>> -----Original Message-----
> > >>> 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)
> > >>>
> > >>> On Tue, Feb 04, 2020 at 02:22:23PM +0000, Pascal Thubert 
> > >>> (pthubert)
> wrote:
> > >>>> 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.
> > >>>
> > >>>> 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 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.
> > >> Oups then : ) I changed the reference, also for BCP 26.
> > > Thanks!
> > >
> > >>>> 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:
> > >>>>
> > >>>>>> 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
> > >>>> I keep this item in the thread, to track that it's progressing 
> > >>>> separately
> > >> Please consider the changes in
> > >> https://tools.ietf.org/rfcdiff?url2=draft-ietf-6lo-ap-nd-18.txt
> > >> Did we clear the DISCUSS?
> > > [covered above]
> > >
> > >>
> > >>>>
> > >>>>> 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.
> > >>> 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
> > > "backward compatibility with" is easy to misparse, so maybe add a 
> > > comma, or go with "backward compatibility but adds the capability"?
> > >
> > > -Ben
> > >
> > >>     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
> >
> >
> > --
> > email: [email-masked] | Skype: rstruik
> > cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
> >

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