Re: [6lo] INT-DIR review of draft-ietf-6lo-6lobac-05

[Tim Chown <[e-mail]>]

Hi Kerry,

On 13 Sep 2016, at 23:23, Kerry Lynn <[e-mail]<mailto:[e-mail]>> wrote:

Hi Tim,

Thanks very much for the review; sorry for the delayed response.
Comments inline…

And for the delayed response to the response, but I don’t see the 6lobac draft having been updated as yet…

On Thu, Aug 18, 2016 at 10:57 AM, Tim Chown <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I am an assigned INT directorate reviewer for this draft. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherds should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details of the INT directorate, see <http://www.ietf.org/iesg/directorate.html>.

Summary

This document defines the mechanisms for delivering IPv6 over Master-Slave/Token Passing (MS/TP), which is a MAC protocol commonly used in building automation networks. It includes the frame format for transmitting IPv6 packets,  as well as the method for forming link-local and statelessly auto-configured IPv6 addresses.

I was not familiar with the work prior to reading it, but found the text to be well-written and easy to read, with it following a similar structure to other IETF IPv6-over-foo documents.

Some specific points of note regards MS/TP are that it has 8-bit MAC addresses, it has no multicast (so multicast packets are sent to the 8-bit broadcast destination address (255), it can support MTUs of 1280-1500 (and above), and, as a wired protocol, it runs at around 115Kbit/s up to 1000m.

Comments:

The introduction says that the “general approach is to adapt elements of the 6LoWPAN specifications, RFC4944, RFC6282 and RFC6775”.  This is understandable given the constrained nature of nodes in building automation scenarios. There are however places in the document where it’s not clear where specifically these specifications are being drawn upon and are to be used. Some more explicit pointers might be helpful.  An example of this lies in Section 8, which says unicast address mapping follows Section 7.2 of RFC4861, but one might expect RFC6775 (on ND optimisation) to be used, e.g. wrt solicited node multicast.

This seems like a two-parter.  Are you saying there are sections of the I-D that are
adapted from the 6LoWPAN RFCs but aren't referenced?  If so, what sections need
fixing?

It’s a general comment. You say broadly that the "general approach is to adapt elements of the 6LoWPAN specifications, RFC4944, RFC6282 and RFC6775”, but then it’s unclear throughout which elements are adapted.

Or are you saying you feel that some parts of the RFCs SHOULD be incorporated
into this I-D, but aren't?  If so, what text needs to changed?

The problem is that I don’t know what’s missing, from the adaptation. If you’re saying that the 6lobac draft is a complete, standalone spec, and there’s nothing implied from those RFCs, then that’s fine, in which case I’d suggest deleting the last sentence of the first paragraph, as it’s not needed and may make others like me think “so what’s implied from those that I need to know?”.

Re: RFC 6775, it appears to be mainly targeted at networks that don't have a multicast
capability, which doesn't apply to 6LoBAC.  The draft does call out use of ARO in section 6.

OK, well there’s an example wrt RFC6775.

Section 2 has some “musts” that might be MUSTs, given RFC2119 language is defined in Section 1.1.

OK.
In Section 3 it says that all multicast packets SHOULD be broadcast at the MAC layer. Why is this a SHOULD, and not a MUST? One would assume unicasting multicast messages would be expensive in this type of constrained network and given the token passing mechanism where the token is passed after sending so many packets.

This was also called out by Brian Haberman.  This used to be a MUST, but was changed
to a SHOULD after comments from two WG reviewers.  For the record, I agree with you
but I think we need to revisit the topic in the WG to make sure there's a rough consensus.

OK, it would be interesting to know the rationale for a SHOULD here; it implies they have at least one exception in mind.

The introduction says header compression support as per RFC6282 is REQUIRED, but Section 5 does not explicitly say that the compression mechanism described there MUST be implemented. I’d suggest rewriting the first sentence of Section 5 to say something like “Due to the relatively low data rates of MS/TP, the header compression mechanism described in this section MUST be implemented on all nodes.”

It used to be that both compressed and uncompressed headers were supported. I
understand you're asking for an additional MUST and I'll figure out a way to word it.
Section 5 defines the adaptation header.  Is it clear that this MUST be implemented
by all 6LoBAC nodes?  The only header type defined is for LOWPAN_IPHC (which
is described in section 10).  Can one not draw the inference that IPHC is required on
all nodes?

You say in the first sentence of Section 5 “indicate”, where perhaps “require” is a better word?

Perhaps before Section 6, or at the start of it, there should be text stating which addresses are formed, and which multicast groups are joined. Further, perhaps we can draw on draft-ietf-6man-default-iids-13, which is now very close to publication, and refer to the recommendations in Section 3 there, e.g. that RFC7217 SHOULD be used, and that you SHOULD NOT embed a stable link-layer address in the IID.

 I do not want to be over-proscriptive.  This I-D attempts to draw attention to cases
where privacy addresses should be used.  draft-ietf-6man-default-iids has thus far
NOT been applied to 6lo specifications, and I don't want to set the precedent.  In
particular, that I-D currently reads:


In some network technologies and adaptation layers, the use of an IID
based on a link-layer address may offer some advantages.  For
example, the IP-over-IEEE802.15.4 standard in [RFC6775<https://tools.ietf.org/html/rfc6775>] allows for
compression of IPv6 addresses when the IID is based on the underlying
link-layer address.

Given the push elsewhere to get link layer identifiers out of L3 addresses, this may be contentious.  You do make the distinction between LL and non-LL though.  Anyway, I guess this will be picked up by the security area review, so will be resolved through that, one way or the other.

It seems the text is saying that RFC7217 is not to be used for link-local IIDs; rather the text suggests using a SLAAC-style address (with the last 8 bits being the MAC address) to allow for efficient header compression. Perhaps some explicit text here would help (i.e. SHOULD use RFC7217 for global scope addresses, but RECOMMENDED that you use the SLAAC-a-like mechanism for link-local addresses for header compression efficiency).

Section 6 seems to be clear that it's recommending (but not mandating) link-local
addresses based on MAC ID.  By the same token, it recommends privacy IIDs for
globally scoped addresses.  (Brian H. asked for s/forwardable/globally scoped)

OK, and this is in your Security Considerations.  But this text implies 7217 is a privacy address, but I then think of only 4941, where 7217 is a replacement for MAC-based SLAAC.  Perhaps the issue here is the word “privacy”… maybe an “obfuscated IID” is a better phrase?

I agree “forwardable” is not the best word here; global scope is better (so ULA and regular globals).

The text RECOMMENDING use of a privacy IID does not mention RFC4941, presumably because RFC4941 targets IIDs with embedded IEEE MAC addresses, but the principle for generating the privacy address is the same.  As it stands, the text does not define how a 64-bit privacy address is generated (I think we assume it’s as per RFC4941, but be specific?).

Section 6 says:


A 64-bit privacy IID is RECOMMENDED for each globally scoped address
and SHOULD be locally generated according to one of the methods cited

in Section 12.

Section 12 calls out RFCs 3315, 3972, 4941, 5535, and 7217.

Same comment on the word “privacy”.

One assumes RFC6724-based address selection is followed, in which case privacy addresses would be preferred over public addresses, and thus for all communications initiated by the device, it would be using non-compression friendly addresses. Is this a concern?  Or might you explicitly say here only use privacy addresses for global scope prefixes, again for efficiency.

I think this has been answered.

Yes, thanks.

Section 8 should clarify which elements of RFC6775 are used. As it’s written, I assume none, but that’s at odds with the introduction text.

I think this has been answered.

Yes and no.  If other reviewers aren’t raising it, I veer towards yes :)

Section 12 (like Section 6, now I notice it) refers to “forwardable addresses”. Do you mean global scope addresses (which would include ULAs, if used)? If so, I’d suggest using that terminology.

As I said, Brian has already requested s/forwardable/globally scoped.
When I wrote this, I was trying to use the RFC 6890 terminology, in
which "forwardable" includes ULAs.

OK.

Scanning attacks where embedded 8-bit MAC addresses are used for the last 8-bits would be quite trivial.  I think the text here that basically says “you SHOULD use RFC7217" (for local scope addresses) should be emphasised in Section 6; it doesn’t need to be here, or if it is mentioned, refer to Section 6.  I’m not sure of the relevance of DHCPv6 here(?), while CGAs and hash-based addresses are not (I believe) in common use.

Scanning attacks are mitigated by the use of privacy IIDs for globally scoped
addresses RECOMMENDED in section 6.  The rationale is given in the first
sentence of section 12.  I don't see anything magic about RFC 7217; any
method that can give a good approximation of a random 64-bit number is
sufficient.  My preference for 6lo networks would be to offload this to a service
(e.g. DHCPv6) that could hand out random IIDs.

RFC7217’s “magic” is you get the same “privacy” IID each time you visit the same prefix.

I guess you may not want 6lo devices having to do HBA (RFC5535) or RFC7217 computation?

Are such wired networks not liable to casual snopping? What happens if I unplug a device and plug my own in, using a master node MAC? Presumably the MS/TP protocol defines mechanisms for protection against such attacks, that you could cite?

I've heard many voice concerns about being tracked through airports or in
coffee shops by proximate attackers snooping on wireless links.  I think it is a
step beyond "casual" to get up into the ceiling tiles and install a promiscuous
listener on a wired link.  The mitigation for this is out of scope for an IP-over-
foo specification, right?

Fair enough.

You might add in Section 12 that ULAs may be appropriate for building management systems where the communications are all intra-site.  If external communications are needed, an additional ISP-based prefix could be used. Though I appreciate ULAs can be a contentious subject, so if you want to publish quickly you might choose to not say anything on the subject (but it will come up… :)

I guess I don't feel that an IP-over-foo spec should be a compleat treatise on
how to correctly deploy IPv6, but others may disagree ;-)

OK :)

Tim


Regards, Kerry

Tim