Re: [Int-dir] [6lo] Intdir early review of draft-ietf-6lo-rfc6775-update-11

Reviewer: Tim Chown

Thanks a bunch Tim!

I answered with a prefix > 

There are specific questions back to you down there. Please feel free to remove all Q/As for which we found an agreement already.

General comments:
--------------------------------------

The document could use a glossary of terms: LLN, 6LN, 6LBR, 6LR, BBR, etc.

> Done in appendix

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

The introduction could talk of other new added features, like avoiding DAD for link locals.

> You'll note that it is not avoided. But it is scoped in the relationship between the 6LN and the 6LR. One 6LR may accept to talk to a 6LN LN_A seen as LLA Addr_A and then later another 6LR may refuse that same Addr_A because from its standpoint Addr_A duplicates a LLA used by another device that is also talking to. The draft does not change what a LLA can be used for in route over, that is one radio hop; mostly, it reduces the illusion that a link local address can be DAD'ed in a network that is not fully and permanently connected. 

>  Added:
"
    <t> Simplify the registration flow for link-local addresses </t>
"   
    as a clarification instead of: 
"    
    <t> Reduce requirement of registration for link-local addresses </t>
"

The document includes RFC 7217 in the references, but doesn't include discussion of it in the main body of the text.  Shouldn't RFC 7217 be considered the norm here rather than address generation as per RFC 4862? 

> added:

"
    <t> <xref target="RFC7217">"A Method for Generating Semantically Opaque
    Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"
    </xref> is the recommended method for generating Interface Identifiers to 
    be used in SLAAC at the time of this writing.
    </t>
"

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

Related, RFC 8064 "recommends against embedding stable link-layer addresses in
IPv6 Interface Identifiers".  The document is inconsistent - it talks of using EUI64, then in Section 9 not using EUI64.

> fact is, a typical IEEE802.15.4-based network will compress the IPv6 address based on the MAC address. But it does not have to be so, and it does not apply to all types of networks.

> new updated proposed text:

"
    <t> The IPv6 address of the 6LN in the IPv6 header can be compressed
    statelessly Interface Identifier in the IPv6 address can be derived from
    the Lower Layer address. When it is not critical to benefit from that 
    compression, e.g. the address can be compressed statefully, or it is rarely
    used and/or it is used only over one hop, then the best practice of forming
    privacy addresses should be considered:
    </t>
    <t> <xref target="RFC7217">"A Method for Generating Semantically Opaque
    Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)"
    </xref> is the recommended method for generating Interface Identifiers to 
    be used in SLAAC at the time of this writing.
    </t>
"
    this is followed by existing text:
"    
    <t>
	<xref target="RFC8065">
	"Privacy Considerations for IPv6 Adaptation-Layer Mechanisms"</xref>
	explains why privacy is important and how to form such addresses.  All
	implementations and deployment must consider the option of privacy
	addresses in their own environment.  Also future specifications
	involving 6LoWPAN Neighbor Discovery should consult
	<xref target="RFC8064">
	"Recommendation on Stable IPv6 Interface Identifiers"</xref>
	for default interface identification.
    </t>
"

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

Specific comments:
--------------------------------------

p.3
Section 2, para 2 - should ND cache exhaustion attacks be included in the list here?

> If the method is used as a full replacement of reactive ND, then there can be some control. e.g. we'd be immune from NCE DOS attack from a remote party. But it's a touchy space. In the one hand, we never block from using both, IOW classical (reactive) ND in conjunction with the new (proactive) registration. Also a local node could still attack the cache by performing tons of registrations, forging MAC addresses as it goes if need be.  It will take separate work to address all the security requirements (AP-ND https://tools.ietf.org/html/draft-ietf-6lo-ap-nd and more).

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

p.4
Section 3 - Add RFC 7217 to RFC 4862?  It's recommended by RFC 8064.

> This is a terminology section. Are there terms we need from RFC 7217? Note that this specification does not dictate how to form address, just manages them. Still it places recommendation to the protocol developers coming next (e.g. for a particular link layer) to consider privacy. Text related to RFC 7217 is added in section 9 per your other comment.

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

p.6
Section 4 - for a node to prefer registering to a 6LR that supports the spec, it would need to enumerate all available 6LRs; should the process for this be described here, or is it included in sufficient detail in RFC 6775?

> You are correct. There is no enumeration process; 6LRs are discovered as described in RFC 6775 sections 5.2 and 5.3. by sending out mcast RS. This document updates RFC 6775 but we avoided paraphrasing it as much as we could, considering that this doc is already quite thick. 
Still I added the first line of the text below:
"
    <t> Section 5 of <xref target="RFC6775"/> specifies how a 6LN bootstraps an
    interface and locates available 6LRs; a Registering Node SHOULD prefer
	registering to a 6LR that is found to support this specification, as
	discussed in <xref target="dsc"/>, over a legacy one.
    </t>
"

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

p.7
Section 4.1 - "not required to be a MAC address" - as per my general comment above, with current IETF thinking, should this not be stronger, e.g. "SHOULD NOT be a MAC address"?  Section 9 says this?

> I see where you're coming from and htat makes sense to me. But the WG never went that far. Note that this is not a subfield in an address; as it goes the message is not not supposed to leak outside. RFC 6775 forced the UID to be a MAC address in the EUI-64 form. This specification does not deprecate the legacy behavior and it allows for something else.  But it recommends (section 8) to use a privacy technique such as AP-ND instead. Once AP-ND is standard, we can deprecate the legacy behavior if the WG finds it relevant, e.g. when we apply it to networks that are more sensitive to privacy.

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

p.9
Section 4.2, point 4 - I find this quite para quite hard to read.

> Agreed, it is inlined from RFC 6550 as opposed to referenced per WG and shepherd decision. I simplified to:
"		
		If two sequence numbers are determined to be not comparable,
		i.e. the results of the comparison are not defined, then a node
		should give precedence to the sequence number that was most recently
        incremented. Failing this, the node should select the sequence number 
        in order to minimize the resulting changes to its own state.

"

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

p.9
Section 4.3, para 1 - again, is using EUI-64 desirable?  Is the point to allow header compression as per RFC4944?  Discuss the tradeoff? Section 4.3 para 2 - so a different type of identifier could be an RFC 7217 generated identifier?

> It could be many things but collisions should be avoided. It should not be an interface ID since this is to complement the DAD of the IID. AP-ND builds it on cryptography. Your point is excellent, unsure if this doc should be the vessel for it. At this stage, we never argued deprecation before, just extension. It will take WG work to define possible replacements and this doc may be too advanced for that I guess, but I'll ask.

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

p.11
Section 4.6 - in the case of two 6LRs with the same link-layer addresses, does it matter which a 6LN chooses?  Is the choice algorithmic? Section 4.6 - the last para on p.11 seems to be repeated in the first para on p.12?

> This specification (including RFC 6775) does not have a router preference (whether they have a same or different LLA) beyond RFC 4191. RPL does, based on Rank and the upcoming enrollment specification will also hint on that. And apparently yes to your other point, cleaning up.

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

p.12
Section 4.6 - again, is the recommendation to use an (expected to be) unique LL address in keeping with RFC 8064?

> There is a chicken and an egg problem with the first registration of the first LLA. It is better that it does not fail. RFC6775 stipulates that MAC-derived LLA do not need DAD. This message flies over one hop, between a node and its nearby router. The node may then form as many privacy LL and GUA as it likes. 

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

p.13
Para 4 - a Moved message SHOULD be used, yet elsewhere a node MUST clean up its stale state?  Consistent? What about MIPv6-like spoofing security issues? You say "an alternate protocol" - isn't this a little hand-wavy; shouldn't a single mechanism be defined rather than multiple (undefined) mechanisms?

> Agreed. That single mechanism is DAR/DAC. I removed the "an alternate protocol"; what was meant is now separately drafted in draft-thubert-roll-unaware-leaves. This is where using RPL to proxy the registration is described. Unsure about which MIP attack you have in mind?

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

p.15
OUI is a confusing choice of term, given OUIs in MAC addresses; I guess this is now baked into RFC 6775 though.

> Actually no. RFC 6775 uses EUI-64 throughout. We picked that term to generalize the EUI-64, so I guess we can still change that name. I changed it to Registration Unique ID (RUID) but that does not sound so right; would you have suggestions?
> I'll take that question to the WG separately.

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

p.16
I don't think codes 5 and 10 are explained/defined in any detail here?  How is the challenge made?

> This is used in a freference spec. I clarified that by adding 3 lines at the end of the text in the RUID (ex OUID) section which now reads:

"	The Registration Unique ID in <xref target="RFC6775"/>
	is a EUI-64 globally unique address configured at a Lower Layer,
	under the assumption that duplicate EUI-64 addresses are avoided.
	With this specification, the Registration Unique ID is allowed to be
    extended to different types of identifier, as long as the type is clearly
	indicated. For instance, the type can be a cryptographic string and
	used to prove the ownership of the registration as discussed in
	<xref target="I-D.ietf-6lo-ap-nd">
	"Address Protected Neighbor Discovery for Low-power and Lossy Networks"
	</xref>. In order to support the flows related to the proof of ownership,
    this specification introduces new status codes "Validation Requested" and
    "Validation Failed" in the EARO. 

"

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

p.16
The registration lifetime is in minutes; why not in seconds?

> RFC 6775 is missing a way to express the time unit (RPL has one). 
We used minutes because a typical LLN operates at a very slow pace, and a typical device is like a three-toed sloth that would sleep more than a cat. We even had a requirement to produce an 'infinite' lifetime for the likes of light bulbs but never took it that slow. We could change the format but that would not be backward compatible.
> I'll take that question to the WG separately 

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

p.18
Section 6.3 - SHOULD set the E flag; why not a MUST?  Why would you support the spec, but not advertise that you do?  In contrast, on the next page in Section
7.1.1 you say nodes MUST set it.

> fixed, it was a MUST :)

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

p.19
Section 7.1.2 para 2 - would a LL address generally be used here as source? 
Should that be a SHOULD?  Using a temporary address is probably not ideal.

> RFC 6775 used the registered address (LL or GUA) as source and the target was not really important. With this specification, register the target of the NS, and there is no point remembering the source address of the registration NS after the NA was sent back. A 6LR can talk to the registered address using the registered address.

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

p.20
Section 7.3 para 4 - is this consistent with p.19 last para saying a 6LN MUST use the updated spec once it knows it's supported? The last two paras here are a bit vague/loose.

> I turned the text into:

"	    After detecting a legacy 6LR, an updated 6LN SHOULD attempt to find an
	    alternate 6LR that is updated for a reasonable time that depends on the
        type of device and the expected deployment.
"

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

p.21
Section 8, para 3 - recommends using privacy techniques, but uses EUI64?

> RFC 6775 uses EUI. AP-ND uses a cryptographically generated token instead. This section effectively recommends AP-ND or whatever else cmes next that has privacy concerns.

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

p.22
Limit the number of addresses?  What about RFC 7934?
The type of algorithm described here might be better defined generically for 6LoWPAN and 'real' IPv6?  I don't think anything has been defined for ND cache exhaustion attack mitigation - would a separate draft be beneficial? I suspect current solutions are vendor specific?

> We applied wisdom from RFC9734 and removed text that indicated that an administrator could be on the path of accepting an address or not. I know for having coded it that yes, (at least some) vendors provide a protection in the number of addresses that can be registered or snooped from a given device wen there is a limit for the overall resources to serve the network. A classical NCE is a cache but a 6LR NCE is really a hard state that the registrar guarantees to maintain for a given lifetime. The fact that a protection can be configured does not force a user in a particular deployment  to use that protection. I agree that there is a need for NCE attack mitigation for both classical ND and 6LoWPAN ND. But till that spec exists, we cannot force the 6LR device to drop all protection against a misbehaving 6LN. A 6LR is an IOT device and it might easily be pushed beyond capacity. 

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

p.22
What trust model?

> Should I add words? Those networks are always protected at Layer 2. But really, we'd like to see a draft that enables a 6LBR to prove it has that capacity and is entitled to play the role for the network. This is beyond the scope of this particular draft and should be done in a security related 6LoWPAN draft.

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

p.22
Section 9 - EUI64, or not EUI64?  Inconsistent.
Does anyone really use SeND?  Especially in 6LoWPAN networks?

> There are 2 uses of EUI that must be differentiated. The OUID (now RUID) is a unique ID for the device to correlate registrations for DAD between honest people. This section ere talks about IID in the IPv6 address. The text explains that no, SEND cannot be used in that space. This is why we do AP-ND instead. With AP-ND, the OUID is used to prove cryptographically the ownership of the registered address a bit like CGA does, but it is not part of the address. It is stored upon the first registration f an address and used later to validate that the new registration comes from the same guy.

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

p.24
Section 10.3 - statuses 5 and 10 are not detailed in the draft?

> Added text upon your point earlier 

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

p.30
The multicast issues text could cite the new mboned draft on this topic.
"Plague" is maybe strong!

> done the ref. Added draft-perkins as well. replaced "plague" with "affect the operation of"

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

p.30
Appendix B - can we have a table showing WHICH requirements have been met by the draft?

> added

<t>
Note to RFC Editor: please replace "This" by the RFC number for this specification once it is attributed.
<t>

	<texttable anchor="reqadd" title="Addressing requirements">
	<preamble>I-drafts/RFCs addressing requirements</preamble>
	  			<ttcol align="left"> Requirement</ttcol>
	  			<ttcol align="left"> Document </ttcol>

	  <c>Req1.1</c>		<c><xref target="I-D.ietf-6lo-backbone-router"/></c>
	  <c>Req1.2</c>		<c><xref target="RFC6775"/></c>
	  <c>Req1.3</c>		<c><xref target="RFC6775"/></c>
	  <c>Req1.4</c>		<c>This</c>

	  <c>Req2.1</c>		<c>This</c>
	  <c>Req2.2</c>		<c>This</c>
	  <c>Req2.3</c>		<c></c>

	  <c>Req3.1</c>		<c>Technology Dependant</c>
	  <c>Req3.2</c>		<c>Technology Dependant</c>
	  <c>Req3.3</c>		<c>Technology Dependant</c>
	  <c>Req3.4</c>		<c>Technology Dependant</c>

	  <c>Req4.1</c>		<c>This</c>
	  <c>Req4.2</c>		<c>This</c>
	  <c>Req4.3</c>		<c><xref target="RFC6775"/></c>

	  <c>Req5.1</c>		<c></c>
	  <c>Req5.2</c>		<c><xref target="I-D.ietf-6lo-ap-nd"/></c>
	  <c>Req5.3</c>		<c></c>
	  <c>Req5.4</c>		<c></c>
	  <c>Req5.5</c>		<c><xref target="I-D.ietf-6lo-ap-nd"/></c>
	  <c>Req5.6</c>		<c><xref target="I-D.struik-lwip-curve-representations"/></c>
	  <c>Req5.7</c>		<c><xref target="I-D.ietf-6lo-ap-nd"/></c>
	  <c>Req5.8</c>		<c> </c>
	  <c>Req5.9</c>		<c><xref target="I-D.ietf-6lo-ap-nd"/></c>

	  <c>Req6.1</c>		<c>This</c>
	  <c>Req6.2</c>		<c>This</c>

	</texttable>	<!-- end table "Addressing requirements" -->

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

Nits:
--------------------------------------

p.4
Section 2 - "form and use multiple addresses" (add multiple)

> done

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

p.4
Section 2 last para - "their" rather than "his"

> sorry I do not see this ? the "his" refers to the network admin.

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

p.6
"provides new" -> "provide new"

> done

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

p.10
"route-over mesh" - add to definitions section

> added reference to RFC 6606 in the terminology section

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

p.12
First line of last para needs rewriting - "If the registry in the 6LBR is be saturated, in which case the LBR".

> I had spoted that one too : ) fixed as

"
	If the registry in the 6LBR is saturated, the
	LBR cannot guarantee that a new address is effectively not a duplicate.
"

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

p.13
Could forward reference the summary of error codes in 6.1 or 10.3 here?

> done

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

p.14
"removes silently" -> "silently removes"
"LLNs meshes" -> "LLN meshes"

> done

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

p.15
Code 3; change tense to past tense, e.g. "fails" to "failed"

> done

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

p.19
"capabilities" -> "capabilities is"
"such address" -> "such an address"
"in a" -> "in"
"6LB" -> "6LN" ?

> done. 

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

p.21
"amlways" -> "always"
"to using" -> "using"
Missing close bracket for See Section 9.

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

p.30
Do you mean "sequence"?
"serves" -> "serves the"

> changed to
" 	This specification extends 6LoWPAN ND to provide a sequence number to the
    registration and ...
"

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

p.31
"timely" -> "in a timely fashion" ?
B.1 last req - reword this.
The BIER Architecture is now an RFC I think?

> will fix the reference to RFC 8279

Thanks a bunch again for your deep review Tim!

Pascal

-----Original Message-----
From: 6lo [mailto:6lo-bounces@ietf.org] On Behalf Of Tim Chown
Sent: vendredi 16 février 2018 20:03
To: int-dir@ietf.org
Cc: draft-ietf-6lo-rfc6775-update.all@ietf.org; 6lo@ietf.org
Subject: [6lo] Intdir early review of draft-ietf-6lo-rfc6775-update-11

Reviewer: Tim Chown
Review result: Almost Ready

Hi,

I have performed an early review of draft-ietf-6lo-rfc6775-update-11.

This draft updates and enhances the mechanisms defined in RFC6775 to support
IPv6 operation over low power networks (6LoWPAN ND).

Overall the draft is well-written and structured.

General comments:
--------------------------------------

The document could use a glossary of terms: LLN, 6LN, 6LBR, 6LR, BBR, etc.

The introduction could talk of other new added features, like avoiding DAD for
link locals.

The document includes RFC 7217 in the references, but doesn't include
discussion of it in the main body of the text.  Shouldn't RFC 7217 be
considered the norm here rather than address generation as per RFC 4862? 
Related, RFC 8064 "recommends against embedding stable link-layer addresses in
IPv6 Interface Identifiers".  The document is inconsistent - it talks of using
EUI64, then in Section 9 not using EUI64.

Specific comments:
--------------------------------------

p.3
Section 2, para 2 - should ND cache exhaustion attacks be included in the list
here?

p.4
Section 3 - Add RFC 7217 to RFC 4862?  It's recommended by RFC 8064.

p.6
Section 4 - for a node to prefer registering to a 6LR that supports the spec,
it would need to enumerate all available 6LRs; should the process for this be
described here, or is it included in sufficient detail in RFC 6775?

p.7
Section 4.1 - "not required to be a MAC address" - as per my general comment
above, with current IETF thinking, should this not be stronger, e.g. "SHOULD
NOT be a MAC address"?  Section 9 says this?

p.9
Section 4.2, point 4 - I find this quite para quite hard to read.

p.9
Section 4.3, para 1 - again, is using EUI-64 desirable?  Is the point to allow
header compression as per RFC4944?  Discuss the tradeoff? Section 4.3 para 2 -
so a different type of identifier could be an RFC 7217 generated identifier?

p.11
Section 4.6 - in the case of two 6LRs with the same link-layer addresses, does
it matter which a 6LN chooses?  Is the choice algorithmic? Section 4.6 - the
last para on p.11 seems to be repeated in the first para on p.12?

p.12
Section 4.6 - again, is the recommendation to use an (expected to be) unique LL
address in keeping with RFC 8064?

p.13
Para 4 - a Moved message SHOULD be used, yet elsewhere a node MUST clean up its
stale state?  Consistent? What about MIPv6-like spoofing security issues? You
say "an alternate protocol" - isn't this a little hand-wavy; shouldn't a single
mechanism be defined rather than multiple (undefined) mechanisms?

p.15
OUI is a confusing choice of term, given OUIs in MAC addresses; I guess this is
now baked into RFC 6775 though.

p.16
I don't think codes 5 and 10 are explained/defined in any detail here?  How is
the challenge made?

p.16
The registration lifetime is in minutes; why not in seconds?

p.18
Section 6.3 - SHOULD set the E flag; why not a MUST?  Why would you support the
spec, but not advertise that you do?  In contrast, on the next page in Section
7.1.1 you say nodes MUST set it.

p.19
Section 7.1.2 para 2 - would a LL address generally be used here as source? 
Should that be a SHOULD?  Using a temporary address is probably not ideal.

p.20
Section 7.3 para 4 - is this consistent with p.19 last para saying a 6LN MUST
use the updated spec once it knows it's supported? The last two paras here are
a bit vague/loose.

p.21
Section 8, para 3 - recommends using privacy techniques, but uses EUI64?

p.22
Limit the number of addresses?  What about RFC 7934?
The type of algorithm described here might be better defined generically for
6LoWPAN and 'real' IPv6?  I don't think anything has been defined for ND cache
exhaustion attack mitigation - would a separate draft be beneficial? I suspect
current solutions are vendor specific?