Subject: Opsdir telechat review of draft-ietf-6lo-rfc6775-update-11

From: Jürgen Schönwälder <[email-masked]>
Date: Wed, 21 Feb 2018 10:07:00 -0800

Reviewer: Jürgen Schönwälder
Review result: Has Issues

As an outsider, I would also have preferred to see the message formats
before reading the details how protocol entities have to use the
message fields and react to messages received. But this may be
personal preference. Overall, I found the text to be clear, except
where noted below.

>From an operational point of view, I wonder whether there is work
planned to enable the network administrator to monitor registrations
and to identify routers that run out of registration capacity or to
detect high numbers of failing registrations (which could have
technical reasons but could also be caused by malicious activity).
The text says network administrators should make sure there is
sufficient registration capacity but without any way to monitor usage
of registration capacity, this may be difficult to achieve in
environments where the network administrator has not control over
devices getting deployed.

Section 2:

- What is the 'legacy 6LoWPAN ND specification'? I found out later
  that legacy is a defined term in Section 3. Perhaps it makes sense
  to first define the terminology, i.e., swapping sections 2 and 3.

- 'With this specification, a failed or useless registration can be
  detected...' - detected by whom? The entity registering or the
  entity managing the registrations?

- There is advice that network administrators should deploy 6LR/6LBRs
  matching the number and type of devices. Since it is usually
  difficult to know how many registrations a network will require, is
  there a way to find out when the 6LR/6LBRs run out of capacity or is
  there a way to monitor the usage of the registration capacity?

Section 3:

- The phrase 'to be a higher speed device speed' is odd; note that you
  are actually talking about a link and its datarate.

Section 4:

- Note sure I understand the sentence that includes 'is be
  saturated'. I guess you mean:

   If the registry in the 6LBR is saturated, then the LBR
   cannot decide whether a new address is a duplicate.

  But perhaps I have not understood the situation really. I understand
  that once saturated, registration requests are denied. Perhaps all
  you wanted to say is this:

   If the registry in the 6LBR is saturated, then the LBR
   replies to a EDAR message with a EDAC message
   that carries a Status code 9 indicating "6LBR Registry saturated",

Section 5:

- s/is a used as a/is used as a/

Section 7:

- Is there a verb missing in the first sentence of 7.1.2?

- s/in a registration flows/in a registration flow/

Section 8:

- RFC 6775 is not really a 'draft'

- s/requesting a node the/requesting node the/

- I wonder to what extend the expectation that the underlying network
  provides secure unicast and multicast services and that there is a
  trust model in place that ensures that only the right devices act as
  6LBR and 6BBR is wishful thinking. Should the document more clearly
  spell out how fragile things will be if this is not the case? Should
  the document provide concrete pointers how to satisfy these
  requirements? I know, this is a nasty question but deploying this
  technology without proper protection sounds like a real problem.
  Anyway, this is probably for the secdir reviewers to think about.

Section 9:

- s/section Section/Section/

- Should there be any discussion of the possibility to monitor
  movements? Should a device actually claim a different identity when
  moving?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 21 Feb 2018 10:38:22 -0800

> - What is the 'legacy 6LoWPAN ND specification'? I found out later

legacy | ˈlɛɡəsi | 
  noun (plural legacies) 
    an amount of money or property left to someone in a will. 
    • a thing handed down by a predecessor: the legacy of centuries of neglect. 
  adjective Computing 
    denoting or relating to software or hardware that has been superseded but is difficult to replace because of its wide use. 

The marketing term “legacy” is used a lot by people who want to sell you their newest snake oil.

If you find “legacy” in a technical document outside the above narrow technical sense, this generally raises warning flags in people that have been around for a while.

Since the updated 6LoWPAN-ND is not snake oil, we should avoid sending this signal of non-competence.

(It appears here this is just about “previous version of the present specification”.)

Grüße, Carsten

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 22 Feb 2018 08:45:25 +0000

Hello Jurgen and Carsten:

I'm fine with an alternate. Any suggestion? Would, say,  "original", work better?

Pascal

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: mercredi 21 février 2018 19:38
To: Juergen Schoenwaelder <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Opsdir telechat review of draft-ietf-6lo-rfc6775-update-11

legacy | ˈlɛɡəsi | 
  noun (plural legacies) 

Grüße, Carsten

---

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

Thanks a bunch, Jürgen, for your review. It seems overall that we could add a "management" section in the requirements. This specification does not cover the management though.

>> As an outsider, I would also have preferred to see the message formats before reading the details how protocol entities have to use the message fields and react to messages received. But this may be personal preference. Overall, I found the text to be clear, except where noted below.

>> From an operational point of view, I wonder whether there is work planned to enable the network administrator to monitor registrations and to identify routers that run out of registration capacity or to detect high numbers of failing registrations (which could have technical reasons but could also be caused by malicious activity).
>> The text says network administrators should make sure there is sufficient registration capacity but without any way to monitor usage of registration capacity, this may be difficult to achieve in environments where the network administrator has not control over devices getting deployed.

PT>  Added a requirement section as follows

    <section anchor='Req7'
	title="Requirements Related to Operations and Management">
	<t> Section 3.8 of
        <xref target="RFC1558">"Architectural Principles of the Internet"</xref>
        recommends to : "Avoid options and parameters whenever possible.
        Any options and parameters should be configured or negotiated
        dynamically rather than manually". 
        This is especially true in LLNs where the number of devices may be large
        and manual configuration is infeasible. 
        Capabilities for a dynamic configuration of LLN devices can also be 
        constrained by the network and power limitation. 
    </t><t>
        A Network Administrator should be able to validate that the network
        is operating within capacity, and that in particular a 6LBR does not
        get overloaded with an excessive amount of registration, so he can take 
        actions such as adding a backbone link with additional 6LBRs and 6BBRs
        to his network.
        
	</t>
	<t>
	    Related requirements are:
	</t>
	<t>
	    Req7.1: A management model SHOULD be provided providing access to the
        6LBR and its capacity. It is recommended that the 6LBR be reachable over
        a non-LLN link.        
        
	</t>
	<t>
	    Req7.2: A management model SHOULD be provided providing access to the
        6LR and its capacity to host additional NCE. This management model 
        SHOULD avoid polling individual 6LRs n a way that could disrupt the
        operation of the LLN.
	</t>
	<t>
	    Req7.3: information on successful and failed registration SHOULD be
        provided, including information such as the RUID of the 6LN, the 
        Registered Address, the Address of the 6LR and the duration of the 
        registration flow. 
	</t>
	<t>
	    Req7.4: In case of a failed registration, information on the failure
        including the identification of the node that rejected the registration
        and the status in the EARO SHOULD be provided
	</t>

    </section>	<!-- end section
	      "Requirements Related to Operations and Management" -->

******************

>> - What is the 'legacy 6LoWPAN ND specification'? I found out later   that legacy is a defined term in Section 3. Perhaps it makes sense to first define the terminology, i.e., swapping sections 2 and 3.

PT> Done; I changed "legacy" to "RFC6775-only" per a comment by Carsten on this thread

*************************

>> - 'With this specification, a failed or useless registration can be detected...' - detected by whom? The entity registering or the

PT> Both; usually the entity taking the registration, but it can be a time out on the registering node as well. This section deals with the former so I changed the text to:

"
    With this specification, a failed or useless registration can be detected
    by a 6LR or a 6LBR for reasons other than address duplication.
" 

********************

PT > Not through this protocol. But I added requirements in the requirements section that lists them all and points at the drafts that cover them.  

*************************

>> - The phrase 'to be a higher speed device speed' is odd; note that you are actually talking about a link and its datarate.

PT > Something went wrong with that sentence, thanks for spotting it. It now reads:

"   
    An IPv6 transit link that interconnects two or more Backbone Routers.
	It is expected to be of high speed compared to the LLN in order to carry ...

"

*************************

>> - Note sure I understand the sentence that includes 'is be  saturated'. I guess you mean:

>>   If the registry in the 6LBR is saturated, then the LBR cannot decide whether a new address is a duplicate.

PT > I used your words : )

 >> But perhaps I have not understood the situation really. I understand   that once saturated, registration requests are denied. Perhaps all you wanted to say is this:

 >>  If the registry in the 6LBR is saturated, then the LBR replies to a EDAR message with a EDAC message   that carries a Status code 9 indicating "6LBR Registry saturated",
 
 PT> Both actually. The previous sentence indicates that the condition prevents a normal DAD operation.

*************************

>> - s/is a used as a/is used as a/

PT> fixed

*************************

>> - Is there a verb missing in the first sentence of 7.1.2?

PT> Unsure; I fixed to:
"
 	    One alternate way for a 6LN to discover the router's capabilities is to
	    start by registering a Link Local address, placing the same address in
	    the Source and Target Address fields of the NS message, and setting
	    the "T" Flag.  
"
Does that read better?

*************************

>> - s/in a registration flows/in a registration flow/

PT> fixed

*************************

>> - RFC 6775 is not really a 'draft'

PT> changed to "standard"

*************************

PT> done

*************************

>> - I wonder to what extend the expectation that the underlying network   provides secure unicast and multicast services and that there is a  trust model in place that ensures that only the right devices act as   6LBR and 6BBR is wishful thinking. Should the document more clearly   spell out how fragile things will be if this is not the case? Should   the document provide concrete pointers how to satisfy these   requirements? I know, this is a nasty question but deploying this   technology without proper protection sounds like a real problem.   Anyway, this is probably for the secdir reviewers to think about.

PT> Yes, SEC DIR recommended to add text in -12 that I just published (you reviewed -11) on that point exactly, see the last sentence of the security section.

*************************

>> - s/section Section/Section/

PT> done

*************************

>> - Should there be any discussion of the possibility to monitor   movements? Should a device actually claim a different identity when   moving?

PT> The WG did not discuss that point for all I know. The node is always free to move and form new addresses with different unique IDs now that we do not force to base it on EUI-64. But if a node needs to conserve its address then it needs the same unique ID in the ARO.

Thanks real much Juergen, this was a great review! The changes above, if you agree with them, will be published in -13 soon. Please let me know.

Take care;

Pascal

-----Original Message-----
From: Jürgen Schönwälder [mailto:[email-masked]] 
Sent: mercredi 21 février 2018 19:07
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Opsdir telechat review of draft-ietf-6lo-rfc6775-update-11

As an outsider, I would also have preferred to see the message formats before reading the details how protocol entities have to use the message fields and react to messages received. But this may be personal preference. Overall, I found the text to be clear, except where noted below.

>From an operational point of view, I wonder whether there is work
planned to enable the network administrator to monitor registrations and to identify routers that run out of registration capacity or to detect high numbers of failing registrations (which could have technical reasons but could also be caused by malicious activity).
The text says network administrators should make sure there is sufficient registration capacity but without any way to monitor usage of registration capacity, this may be difficult to achieve in environments where the network administrator has not control over devices getting deployed.

Section 2:

Section 3:

Section 4:

Section 5:

Section 7:

Section 8:

Section 9: