Subject: Re: [6tisch-security] Comments on draft-richardson-6tisch--security-6top-04.txt

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Dec 2014 14:33:28 -0500

re: https://mailarchive.ietf.org/arch/msg/secdir/qxT9Cx6mue0UhlPd4dUJU3A8IX8

Hilarie Orman <[email-masked]> wrote:
    > A minor issue with the protocol is the encryption with a well-known
    > key.  This serves no security purpose, but it allows traffic filtering
    > to keep the traffic on the special Join Network separate from the
    > regular network.  That confuses me --- surely some packet marker would
    > be better for filtering than encryption would?

sadly, 802.15.4 lacks both the SNAP header, and even such a thing as an
ethertype.  But, we have decided to dispense with this in a new revision.

    > Another confusing point is step 1B "send router solicitation".  I'm
    > not sure what destination address is in this.  Perhaps the beacon
    > provides the information for use by the joining node.

IPv6 router solicitations are multicast, so it does not need to know a place
to send it.

    > It seems clear that the initial communication must have mutual
    > authentication.  I'd expect the joining node to start with a signed
    > join request, and nothing would proceed further until the JCE found
    > the device ID in its access list and decided to proceed with
    > further authentication.  The joining node should not communicate
    > further until it has some reason to believe it is on the correct
    > network.

The intent is that the device ID travels up the network to the JCE, just as
you said, and that the device stays silent until the JCE see it.  You are
suggesting that the new device sign it's ID.  Can you explain the value of
that?
(The exact way in which the device ID travels up has changed several
times. We believed that we could use an extended ARO in the IPv6 Neighbour
discovery which is part of 6lowpan, but we are having some doubts)

    > Even with that change, there is always the possibility of a malicious
    > relay node-in-the-middle.  It could cause the joining node to
    > communicate with a very distant instance of the correct network, for
    > example.  This might violate some proximity assumptions.  The
    > malicious node could arbitrarily block communication and cause
    > unintended behavior of the network.

Yes, so in draft-ietf-roll-security-threats (in AUTH48) this is called a
wormhole attack.  It's unclear how this situation is different than
(intentionally) having a really good antenna, but I agree it is a concern.

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