Early Review of draft-ietf-6lo-6lobac-05
review-ietf-6lo-6lobac-05-intdir-early-chown-2016-09-15-00

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