Re: [6lo] Eric Rescorla's No Objection on draft-ietf-6lo-rfc6775-update-17: (with COMMENT)

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Eric:



Many thanks for your in depth review, including going through AP ND.

Please see below



> -----Original Message-----

> From: 6lo <[e-mail]> On Behalf Of Eric Rescorla

> Sent: jeudi 5 avril 2018 05:47

> To: The IESG <[e-mail]>

> Cc: [e-mail]; [e-mail]; draft-ietf-6lo-

> [e-mail]; [e-mail]

> Subject: [6lo] Eric Rescorla's No Objection on draft-ietf-6lo-rfc6775-update-17:

> (with COMMENT)

>

> Eric Rescorla has entered the following ballot position for

> draft-ietf-6lo-rfc6775-update-17: No Objection

>

> 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-rfc6775-update/

>

>

>

> ----------------------------------------------------------------------

> COMMENT:

> ----------------------------------------------------------------------

>

>

> I found this document quite challenging to read. It would be very helpful if it

> started with a description of the failings of 6775 and a brief overview of how it

> solves those. At the risk of self-citing, the techniques of RFC 4101 might be

> helpful here.

>

[PT>]



Sorry for the hassle!

Since this is an update, there is an implicit expectation that the reader is used to the updated RFC helps a lot the reader.

Yet, I agree with your point.

We can probably achieve that in a concise fashion with a summary that points at the requirements in appendix.

I do like section 2 of 4101. We have a whole section on updating RFC 6775 but that's too wide and too late.

A proposal is to change the introduction has follows:



"



   The scope of this draft is an IPv6 Low-Power Network including star

   and mesh topologies.  In that context, "Neighbor Discovery

   Optimization for IPv6 over Low-Power Wireless Personal Area Networks"

   (6LoWPAN ND) [RFC6775] defines a registration mechanism that

   leverages a central registrar for the main purpose of Duplicate

   Address Detection (DAD), with the intention to reduce the dependency

   of the IPv6 Neighbor Discovery Protocol (IPv6 ND) [RFC4861][RFC4862]

   on network-layer multicast and link-layer broadcast operations.



   This specification updates 6LoWPAN ND to simplify the registration

   operation in 6LoWPAN routers and to extend the protocol as a more

   generic registration technique.  The specified updates enable other

   specifications to define new services such as Source Address

   Validation (SAVI) with [I-D.ietf-6lo-ap-nd], participation as an

   unaware leaf to an abstract routing protocol such as the "Routing

   Protocol for Low Power and Lossy Networks" [RFC6550] (RPL) with

   [I-D.thubert-roll-unaware-leaves], and registration to a backbone

   routers performing proxy Neighbor Discovery in a Low-Power and Lossy

   Network (LLN) with [I-D.ietf-6lo-backbone-router].



   In more details, this specification modifies and extends the behavior

   and protocol elements of 6LoWPAN ND to enable the following new

   capabilities:



   o  determining the freshest location in case of mobility (TID)



   o  Simplifying the registration flow for Link-Local Addresses



   o  Support of a Leaf Node in a Route-Over network



   o  Proxy registration in a Route-Over network

   o  Associating the registration with a variable-length Registration

      Ownership Verifier (ROVR)



   o  Registration to a IPv6 ND proxy over a Backbone Link (6BBR)



   o  Clarification of support for privacy and temporary addresses



   A more comprehensive set of requirements is provided in Appendix B.



"





> In addition, I recognize that some of the guarantees here depend on draft-ietf-

> 6lo-ap-nd. I have not yet thoroughly reviewed that document, but it is not yet

> clear to me precisely what guarantees it in fact provides.

>

>    This specification introduces the Extended Address Registration

>    Option (EARO) based on the ARO as defined [RFC6775].  A 'T' flag is

>

> Can you describe here the problem that ARO has that this solves?

[PT>]



Based on a recent IESG review, sections 4 and 6 were swapped, so the formats now come first. Section 5 is gone, merged in backward compatibility.

So ex section 4 in now 5. We agreed that this should help the reader and it seems to serve your purpose as well.

This also means that the text we want to change here is now located in the format section.

So there will be a bit of churn... let's see.



Section 4 would now starts as follows:

"

4.  Extended ND Options and Messages



   This specification does not introduce new options, but it modifies

   existing ones and updates the associated behaviors as specified in

   the following subsections.



4.1.  Extended Address Registration Option (EARO)



   The Address Registration Option (ARO) is defined in section 4.1 of

   [RFC6775].  This specification introduces the Extended Address

   Registration Option (EARO) based on the ARO for use in NS and NA

   messages.  The EARO conveys additional information such as a sequence

   counter called Transaction ID (TID) that is used to determine the

   latest location of a registering mobile device.  A 'T' flag is added

   to indicate that the TID field is populated.



   The EARO also signals whether the 6LN expects routing or proxy

   services from the 6LR using a new 'R' flag.



  The EUI-64 field is overloaded and renamed ROVR in order to carry

   different types of information, e.g., cryptographic information of

   variable size.  A larger ROVR size may be used if and only if

   backward compatibility is not an issue in the particular deployment.



   Section 5.1 discusses those changes in depth.



   An NS message with an EARO is a registration if and only if it also

   carries an SLLA Option [RFC6775].  The EARO is also used in NS and NA

   messages between Backbone Routers [I-D.ietf-6lo-backbone-router] over

   the Backbone Link to sort out the distributed registration state; in

   that case, it does not carry the SLLA Option and is not confused with

   a registration.



   When using the EARO, the address being registered is found in the

   Target Address field of the NS and NA messages.



   The EARO extends the ARO and is indicated by the 'T' flag being set.

...

"



Section 5 now starts as:

"

5.  Updating RFC 6775



   The Extended Address Registration Option (EARO) (see Section 4.1)

   replaces the ARO used within Neighbor Discovery NS and NA messages

   between a 6LN and its 6LR.  Similarly, the EDA messages, EDAR and

   EDAC, replace the DAR and DAC messages so as to transport the new

   information between 6LRs and 6LBRs across an LLN mesh such as a

   6TiSCH network.

...

"



And section 5.1:

"

5.1.  Extending the Address Registration Option



   The Extended ARO (EARO) replaces the ARO and is backward compatible

   with the ARO if and only if the Length of the option is set to 2.

   Its format is presented in Section 4.1.  More details on backward

   compatibility can be found in Section 6.



   The semantics of the Neighbor Solicitation (NS) and the ARO are

   modified as follows:

...

"







>

>    that this specification avoids the Duplicate Address message flow for

>    Link-Local Addresses in a Route-Over [RFC6606] topology.

>

> This sentence is not really maximally clear. Why does it avoid it?

[PT>]

I love your wording ; ) Adding a link to section 5.6 where this is discussed.



>

>    o  The address that is being registered with an NS with an EARO is

>       now the Target Address, as opposed to the Source Address as

>

> This would read better, I think if you said

>

> "The address that is being registered is set to the target address in the NS

> containing the EARO,as opposed to..."

[PT>]

Actually that is the target field that is set to the address being registered : )

Or is it my Frenglish? What about:

"

   o  The Target Address in the NS containing the EARO is now the field

      that indicates the address that is being registered, as opposed to

      the Source Address field as specified in [RFC6775] (see

      Section 5.5).



"



>

>                    denoting a ROVR size of 128, 192 and 256 bits

>                    respectively.

>    Status:         8-bit unsigned integer.  Indicates the status of a

>

> It took me a minute to realize that this is the length of the *entire* option and

> so it's 1 larger than the length of the ROVR. Some text might help here.

[PT>]

What about:

<

   Length:         8-bit unsigned integer.  The length of the whole

                   option in units of 8 bytes.  It MUST be 2 when

                   operating in a backward-compatible mode with a ROVR

                   size of 64 bits.  It MAY be 3, 4 or 5, denoting a

                   ROVR size of 128, 192 and 256 bits respectively.



<



>

>                    registration of a particular IPv6 Address and it

>                    cannot be used to correlate registrations of

>                    different addresses.

>

> "cannot" doesn't seem quite right. I.e., if you use the same EUI-64, someone

> could use it for that. Perhaps you mean "must not"

[PT>]

Agreed and changed



>

>    rightmost bit and place the result in the EDAR message to maintain

>    compatibility.  This way, the support of DAD is preserved.

>

> Is there a reason for the rightmost bits? I see that

> https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-06 uses the leftmost bits for

> Crypto-ID.

[PT>]

No reason ; good catch : ) Let's unify. Since in AP ND is a hash I expect it makes no difference but if it was an address rightmost appears better. So let's pick rightmost everywhere then? I'll change AP ND.

>    Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the

>    Registered Address using a cryptographic ROVR.

>

> I'm a little unsure how to read this text. It seems like the techniques you are

> discussing are about whether a node behaves incorrectly, but 6775 says that

> the first trust model of 3756 applies, and *that* says:

>

> A model where all authenticated nodes trust each other to behave

>        correctly at the IP layer and not to send any ND or RD messages

>        that contain false information.  This model is thought to

>        represent a situation where the nodes are under a single

>        administration and form a closed or semi-closed group.  A

>        corporate intranet is a good example.

>

> So in that setting why do you need ownership guarantees? Is this just belt and

> suspenders?

[PT>]

It can be seen as this. The idea is to limit the perimeter of an attacker that gets L2 access to the network, e.g., by compromising a device. SAVI (and SEND RFC 3971) protect the ownership of the address and prevents misuse. Maybe we should add text in AP-ND that indicates that it applies when the model in RFC 3756 wan not be strictly guaranteed (e.g., my home, or any network where you connect IOT devices bought on the net that need your Wi-Fi key, e.g., those neat IP cameras).

>

>       address, but a stronger identification (e.g., by security

>       credentials) is RECOMMENDED.  When that maximum is reached, the

>       router should use a Least-Recently-Used (LRU) algorithm to clean

>

> What would these security credentials be?

[PT>]

I guess the question is for you : ) I expected some authenticated ID that is used to join the network and may be validated by some certificate. E.g., something like a SUDI such that the rogue does not go around and forms tons of them cheaply. A well-behaved device, for privacy reasons, may change its MAC address over time. If there is a cryptographic way to find the ID behind the MAC, then it's useful.

If the node really cares for his privacy even with the first hop router, then we may not be able to do anything, but it may not join a secured network either.

Would you have a reference that we could use?



Take  care,



Pascal