Subject: [Int-dir] INT-DIR review of draft-ietf-6lo-6lobac-05

From: Tim Chown <[email-masked]>
Date: Thu, 18 Aug 2016 14:57:43 +0000

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.

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

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.

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.”

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.

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).

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?).

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.

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.

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.

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.

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?

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… :)

Tim