Subject: [6tisch-security] WGLC comments on 6tisch-security

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Feb 2015 23:19:57 -0500

My appologies for the lateness of this review.
One good point is that it's been 10 weeks since I read the document
From beginning to end, and some things stick out that did not bother me
before.

My tl;dr> conclusion is that the document is not ready to proceed as is.
If it is going to proceed in volumes (I suggest "editions" is the correct
term), then I think that most things which are speculation should
either be removed to a later edition, or something specific should be
said, with the understanding that it might change later.
Presciption rather than speculation should be the goal.

1) I find it odd that there is so much emphasis of the backbone router
   function... IN THE ABSTRACT.  I suggest that the last sentence:
          Backbone Routers perform proxy Neighbor Discovery
          operations over the backbone on behalf of the wireless
          devices, so they can share a same subnet and appear to be connected to the same
          backbone as classical devices.
   be removed from the abstract.
   Probably by the end of this review that I'll suggest a different thing
   that could be included.

2) end of section 1, what does it mean: "in the round of this document."?

3) I don't think that [I-D.ietf-roll-rpl-industrial-applicability] will ever
   get published. If there is terminology there that we still need, I think
   it should be extracted into the 6tisch-terminology document.  While it is
   an informative reference, the fewer references to IDs the better in my
   opinion.

4) section 4, seems to ignore the possibility to simply run RPL across the
   subnet backbone.  I understand why the ND mechanism are nice, because they
   permit the backbone to just be ethernet, but the case where the backbone
   is really dedicated (and given VLANs, it's hard to know why you'd do
   anything else), one can just run RPL across it.
   I think that this ultimately matters to any of the later architecture,
   but I wouldn't want to later argue with someone who might claim that
   the newer ND mechanisms are REQUIRED.

5) the security words include: "will be studied in the next round of this document."
   and I'm not sure what a reader should make of this.  Perhaps it should
   simply summarize section 13 in one sentence and say that PANA is a
   possibility, but that the choice of protocol is out of scope for this
   document.
   (well, 5.0 then explains about volumes.  So perhaps the explanation
   about volumes should go much earlier, most probably into the abstract as
   well.  Also, will the volumes build on the previous work, or will they
   replace it?  if they will replace it, then I think correct word is "edition")

6) I don't think that the Note: about DETNET really still belongs in
   a document that might be read in 5-10 years.  Maybe a reference to
   the charter for DETNET would make more sense.

7) I don't understand why PANA lives above ACE in figure 3.
   I think that ACE lives above CoAP/DICE (DTLS is missing, but perhaps
   understood by DICE).  I think that while technically PANA lives on top of
   UDP, there is of course a layer of EAP, and TLS above it, and perhaps
   a layer of ACE as well.  So I'm not saying that this picture needs to be
   changed, just to observe this.

8) I think remove:
   "COMI and the
   dependent specifications are still work in progress, but getting
   stable enough at the time of this writing."

9) I am happy with the paragraph on join security in section 5.

10) I think that this is confused (bottom of page 9, section 6):

   > This architecture expects that a 6LoWPAN node can connect as a leaf
   > to a RPL network, where the leaf support is the minimal functionality
   > to connect as a host to a RPL network without the need to participate
   > to the full routing protocol.  The support of leaf can be implemented
   > as a minor increment to 6LoWPAN ND, with the additional capability to
   > carry a sequence number that is used to track the movements of the
   > device, and optionally some information about the RPL topology that
   > this device will join.

I think that either a minimal RPL permits leaf attachment *OR*
the EARO 6lowPAN ND.   I don't think that both are needed?

I'm also think that some may confuse this with the join process
requirements, which maybe this started out describing, but I don't
think that does that.  It might describe how nodes which have already
joined (been imprinted upon the newtork) can form a network.

Figure 4 seems to do it all without RPL, even though RPL is mentioned,
and I don't understand that.

11) Reading section 6.1/6.2, I wonder if this just too much detail for
    an architecture.  I also don't see how VLANID is involved (we are
    talking 802.1q here, right?).  I am not saying that the TID and
    EARO aren't good things; I'm just finding that they just JUMP out
    here, and I'm not sure a read has any idea why they are here yet.
    I think that 6.3 should be far more specific: proxy-ND? LISP? or MIPv6?
    which is going to be used...  I think that reviewers will push
    back here a lot.

12) I think that 6.4 needs be prescriptive, not
    speculative/suggestive.
    6.5 needs to say, "the 6LBR and RPL root functionality are to be
        co-located in order that the address of the 6LBR be indicated
        by RPL DIO messages"

13) I think that 6.6 is saying that SEND can not be applied.  I think
    it should be clearer in saying something like:
       "The threats against IPv6 ND as described in RFC3971 apply
       as well, but the solution can not work as the route over
       network does not permit direct peer to peer communication.
       As can be seen in Figure 4..."

14) I think that the relevant parts of
    [I-D.ietf-roll-rpl-industrial-applicability]
    need to imported into this document, since this sure looks like
    a normative reference to me.

15) section 8 seems to be really the key aspects of the architecture.
    I think that rather than say, "if the scheduling entity
    explicitely..." => "hard".
    I think that it should instead say that there are hard cells
    and soft cells, and say that 6top can not move hard cells.
    (but, how would the PCE set them up, if 6top can't move them?)

   "6top contains a monitoring process which monitors the performance of
   cells, and can move a cell in the TSCH schedule when it performs bad."

   this seems pretty important an architectural thing, and I think it
   at least deserves it's own section number.

16) 8.2, insert something to the effect:
    Most RPL Objective Functions require metrics about reachability,
    such as the ETX.  6top creates and maintains an abstract neighbor
    table, and this may be leveraged.  ... This information ...

"
    6top also enables the RPL
   OF to influence the MAC behaviour, for instance by configuring the
   periodicity of IEEE802.15.4e Extended Beacons (EB's).  By augmenting
   the EB periodicity, it is possible to change the network dynamics so
   as to improve the support of devices that may change their point of
   attachment in the 6TiSCH network.
"

   But, we aren't using the Enhanced Beacons (they are enhanced, not
   extended, aren't they? or did I get that backwards again?) for
   production network use...

I would write:
   Consideration was given towards finding a way to embed the Route
   Advertisements and the RPL DIO messages (both of which are
   multicast) into the IEEE802.15.4e Enhanced Beacons.  It was
   determined that this produced undue timer coupling among layers,
   that the resulting packet size was potentially too large, and
   required it is not yet clear that there is any need for Enhanced
   Beacons in a production network.

   [and then go on to explain how to configure the LinkType, however,
   I think that this is too much detail for the architecture, and
   it needs to say something like:
      The 6TISCH adaptation document will explain the details of
      confuring a broadcast channel that can accomodate EB,
      RPL DIOs and Router Advertisements
      ]

but, maybe I mis-understand the entire section.

17) I think that 8.3 should actually say how the TSGI should be
    created, and also how the various layers can be synchronized such
    that the RPL management traffic can provide for the needed
    frame-based synchronization.   I expect that this simply
    means that 6top needs to be able to trigger(override) the trickle
    timer if no other traffic has occured in "too long" a time.

   "After consultation with
   IEEE authors, it was asserted that 6TiSCH can make a full use of the
   octet to carry an integer value up to 0xFF."

   -> does this need some kind of clear liason statement?

I think that the concepts introduced in section 6.4 and 6.5 should
perhaps be more clearly.  While not trying to duplicate the terminology
document, I found the way that the CDU concept is introduced was
awkward.  Perhaps this isn't very important.
Maybe moving figure 5 earlier?

18) I think that the 4 scheduling paradigms should be mentioned in
    the introduction as well!  To first order, I think that is perhaps
    the most important thing in the document.

"   If the size of a bundle is configured to fit an average amount of
   bandwidth, peak emissions will be destroyed."

(I don't think the word you want is "destroyed".  I think that it
means that packets will be dropped, but I don't think that describing
the dropped packets as destroyed is the correct IETF idiom here, even
though it might be grammatically correct)

19)    6TiSCH supports three different forwarding model, G-MPLS Track
   Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding
   (6F).

   also should be mentioned in the introduction...

20) last comment on section 13.
    (the bullet (*) has become an ASCII "A", the high bit was likely
    removed)

   Device Authentication:  The JN and the JA mutually authenticate each
         other and establish a shared key, so as to ensure on-going
         authenticated communications.  This may involve a server as a
         third party.

   I again say that this is incorrect, the JA will never be able to
   authenticate *itself* to the JN.  It may be able to present some
   *authorization* from the *network owner*, that the JA is authorized
   to act on behalf of the network owner.

   Unless you consider un-authenticated DH exchange "authentication",
   or you decide that it's okay for the JA to just not accept any
   public (some kind of leap of faith), the JA will not have an
   identity that a JN will accept.

   I have also repeatedly complained that figure 10 is inaccurate,
   because it fails to depict that authorization begins before
   authentication finishes.  Perhaps the second two unidirectional
   arrows are part of the authentication phase, I don't know.

   I suggest that the sentence:

   "The join protocol consists of three phases:"

be replaced with:

   "The join protocol has three major activities:"
   ("phases" implies some ordering such that one phase might finish
   before the next begins, while activities implies no such ordering)

   I suggest that figure 10 be omitted.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 23 Feb 2015 17:01:53 +0200

>    production network use...

They are Enhanced Beacons, and yes you DO need them on the production
network (unless your network is completely statically configured).

The TSCH PAN formation requires that device (usually PAN coordinator)
sends enhanced beacons which contain following information:

	- Time information so new devices can synchronize to the
	  network, as described in 7.4.3.2.
  
	— Channel hopping information, as described in 6.2.10 and
	  7.4.3.31.

	— Timeslot information describing when to expect a frame to be
	  transmitted and when to send an acknowledgment, as described
	  in 7.4.3.4.

	— Initial link and slotframe information so new devices know
	  when to listen for transmissions from the advertising device
	  and when they can transmit to the advertising device, as
	  described in 7.4.3.3.

(this is from P802.15.4-REVc-DF3 draft, so section numbers do not
match with old versions).

If your network stays same, then there is no need to update any of
that but if new devices join and you want to change for example the
slotframe information, I think the enhanced beacons are the way to
transmit that information from coordinator to the devices.

If you check the IE table description:

https://mentor.ieee.org/802.15/dcn/15/15-15-0090-01-0mag-ie-table.docx

you will see that TSCH Slotframe and Link IE is supposed to be sent
only in Enhanced beacons.

Also note, as most of that information is in the Payload IEs that mean
that enhanced beacons cannot really be encrypted, they can only be
authenticated (i.e. security levels 1-3), so new devices can also read
the information even without knowing the encryption keys. 
  
>    Beacons in a production network.

So I think it is incorrect to claim that we do not need enhanced
beacons in production network, as I do think it is still needed unless
we manage the slotframes using some upper layer protocol.
-- 
[email-masked]