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

[Benjamin Kaduk <[e-mail]>]

Hi Pascal,

(Top-posting since I only have general comments.)

What you describe sounds reasonable to me from the description, though I
did not go back and refresh my memory of how it would fit into the rest of
the system (I trust you to get it right).
The only thing that comes to mind as potentially noteworthy is the
availability of authentication/integrity-protection for the 6CIO that
carries the new A and J flags (i.e., a MITM attacker that can rewrite the
6CIO would be able to block use of AP-ND).  That said, I don't expect these
flags to have particularly different needs for provenance verification than
the other flags, and I do expect external constraints to be the main factor in
what protection (if any) can be applied here, so in some sense this remark
is just a formality.

Thanks for checking back,

Ben

On Wed, Apr 15, 2020 at 12:04:02PM +0000, Pascal Thubert (pthubert) wrote:
> 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 <[e-mail]>
> > Sent: vendredi 7 février 2020 01:10
> > To: Rene Struik <[e-mail]>
> > Cc: Pascal Thubert (pthubert) <[e-mail]>; The IESG
> > <[e-mail]>; [e-mail]; Shwetha Bhandari (shwethab)
> > <[e-mail]>; [e-mail]
> > 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-representatio
> > > 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 <[e-mail]>
> > > >>> Sent: mercredi 5 février 2020 22:20
> > > >>> To: Pascal Thubert (pthubert) <[e-mail]>
> > > >>> Cc: The IESG <[e-mail]>; [e-mail];
> > > >>> Shwetha Bhandari
> > > >>> (shwethab) <[e-mail]>; [e-mail]; [e-mail]
> > > >>> 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: [e-mail] | Skype: rstruik
> > > cell: [phone] | US: [phone]
> > >