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

[Kerry Lynn <[e-mail]>]

Hi Tim,

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

On Thu, Aug 18, 2016 at 10:57 AM, Tim Chown <[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?

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?

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.


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

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

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

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)

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

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

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

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

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

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

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

Regards, Kerry

>
> Tim
>
>
>
>