Subject: [6tisch] Benjamin Kaduk's No Objection on draft-ietf-6tisch-enrollment-enhanced-beacon-13: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 18 Feb 2020 15:12:31 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6tisch-enrollment-enhanced-beacon-13: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-enrollment-enhanced-beacon/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Where is PAN/PANID defined?  I did not find it in RFC 6550, 8180, or
draft-ietf-6tisch-architecture, nor in the RFC Editor's list
(https://www.rfc-editor.org/materials/abbrev.expansion.txt).

Thank you for discussing the security considerations of each field
throughout!

Section 1.3

   Although However, even in this case, a unicast RS may be transmitted
   in response[RFC6775] reduces the amount of multicast necessary to do
   address resolution via Neighbor Solicitation (NS) messages, it still
   requires multicast of either RAs or RS.  This is an expensive

nits: two capitalized words in a row, also some further rewording is
needed (and maybe s/unicast RS/unicast RA/?).

Section 2

We should probably say something about the 'res' bits being reserved,
set to zero, and ignored by recipients.

      In most cases, every node sending a beacon will set this flag, and
      in a typical mesh, this will be every single node.  When this bit
      is not set, it indicates that this node may be under provisioned,
      or may have no additional slots for additional nodes.  This could
      make this node more interesting to an attacker.

nit: this phrasing suggests that the list is an exhaustive list of
reasons why the flag could be unset; I'd suggest "it might indicate"
instead.

      This value MUST be ignored by pledges, it is to help enrolled
      devices only to compare different connection points.

nit: comma splice.  Maybe also reword to "It is only to help enrolled
devices to compare different connection points"?

      This field communicates an Interface ID bits that should be used
      for this nodes' layer-3 address, if it should not be derived from

nit: singular/plural mistmatch in "an Interface ID bits"
nit: s/nodes'/node's/

      the layer-2 address.  Communication with the Join Proxy occurs in
      the clear, this field avoids the need for an additional service
      discovery process for the case where the L3 address is not derived
      from the L2 address.  An attacker will see both L2 and L3

nit: comma splice.  I'd also hyphenate "service-discovery".

      once.  That is just a suggestion for a default algorithm: it may
      be set in any convenience way that results in a non-identifing
      value.  In some LLNs where multiple PANIDs may lead to the same

nits: I suggest "Per [RFC6550], that is just a suggestion",
s/convenience/convenient/, and s/identifing/identifying/ (though what
exactly it is that is not being identified might be worth clarifying,
too).

      management device (the JRC), then a common value that is the same
      across all PANs MUST be configured so that pledges that attempt to

nit: I think "all the PANs" is more appropriate, since we only care
about the ones that lead to the same JRC (and there may be other PANIDs
in play).

      enroll do not waste time attempting multiple times with the same
      network that has multiple attachment points.

nit: I'd consider expanding (again) what is being attempted.

      If the network ID is derived as suggested, then it will an opaque,

nit: s/will/will be/

      seemingly random value, and will reveal nothing in of itself.  An

I suggest "will not directly reveal any information about the network".

Section 3

   The sensitivity of each field is describe within the description of
   each field.

nit: s/describe/described/

   visible.  Encrypting the schedule does not prevent an attacker from
   jamming, but rather increases the energy cost of doing that jamming.

Perhaps also the side effects/collateral damage of the jamming.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 20 Feb 2020 20:22:59 +0100

> (https://www.rfc-editor.org/materials/abbrev.expansion.txt).

PAN/PANID is an IEEE thing, and I've added a reference and explanation:

          These are called Personal Area Networks (PAN).
          Each instance will have a separate Layer-2 security profile, and
          will be distinguished by a different PANID.

          The PANID is part of the {{ieee802154}} layer-2 header: it is a
          16-bit value which is chosen to be unique, and it contributes context to the
          layer-2 security.

          The PANID provides a context similar to the ESSID does in 802.11
          networking, and can be conceived of in a similar fashion as the
          802.3 ethernet VLAN tag in that it provides context for all layer-2
          addresses.

    > needed (and maybe s/unicast RS/unicast RA/?).

fixed.

    > set to zero, and ignored by recipients.

done.

    >       In most cases, every node sending a beacon will set this flag,
    > and in a typical mesh, this will be every single node.  When this bit
    > is not set, it indicates that this node may be under provisioned, or
    > may have no additional slots for additional nodes.  This could make
    > this node more interesting to an attacker.

    > reasons why the flag could be unset; I'd suggest "it might indicate"

agreed.

    > devices to compare different connection points"?

fixed.

    > nit: singular/plural mistmatch in "an Interface ID bits" nit:
    > s/nodes'/node's/

done.

    > discovery process for the case where the L3 address is not derived from
    > the L2 address.  An attacker will see both L2 and L3

    > nit: comma splice.  I'd also hyphenate "service-discovery".

fixed.

    > be set in any convenience way that results in a non-identifing value.
    > In some LLNs where multiple PANIDs may lead to the same

    > exactly it is that is not being identified might be worth clarifying,

network ID is new, it's not in RFC6550.
DODAGID is though.

    > about the ones that lead to the same JRC (and there may be other PANIDs

okay.

    > nit: I'd consider expanding (again) what is being attempted.

Rewritten to:

In some LLNs where multiple PANIDs may lead to the same management device
(the Join Registrar/Coordinator - JRC), then a common value that is the same across all the PANs MUST be
configured.
Pledges that see the same networkID will not waste time
attempting to enroll multiple times with the same network that when the network has multiple attachment points.

    > nit: s/will/will be/

okay

    > I suggest "will not directly reveal any information about the network".

edited.

    > Perhaps also the side effects/collateral damage of the jamming.

I'm not sure what you are saying/suggesting here.

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 Feb 2020 21:11:55 -0800

Thanks for these updates!  I see you had one question at the end...

> I'm not sure what you are saying/suggesting here.

If the attacker doesn't know the schedule, they use more power ("energy
cost") to jam all the time, in some sort of always-on broadband jamming
technique.  This broadband jamming could end up blocking traffic the
attacker doesn't care about, in addition to the target of the jamming;
that in turn might make the fact that the attacker is jamming at all easier
to detect.  I'm suggesting that the attacker's decision process about
whether/how to jam is much more complicated if they don't have the schedule
available, and there are additional factors that would come into play that
might discourage the attacker from jamming even though (as is already
noted) it does not "prevent" the attacker from jamming.

-Ben

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Feb 2020 19:31:25 -0500

> noted) it does not "prevent" the attacker from jamming.

So, just to be clear, the schedule is happening thanks to RFC8180, section 4.5.
What this document adds is the ability to determine which EB are from the
same network, even if they have different PANID.

There is a very good discussion about the jamming costs in:
      https://datatracker.ietf.org/doc/draft-tiloca-6tisch-robust-scheduling/

Unfortunately, it isn't clear if this work can go ahead in the IETF as it
apparently makes changes that the IEEE is responsible for.  At the same time,
it must coordinate with (re-)keying , which the IEEE is not responsible for.

I don't know what else I could say in enhanced beacon about this.
The topic of selective jamming is a bit distant from this document.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 27 Feb 2020 11:22:58 -0800

> The topic of selective jamming is a bit distant from this document.

Okay, I see your point.

Thanks for the extra reference!

-Ben