Subject: [6tisch] secure join bootstrap

From: peter van der Stok <[email-masked]>
Date: Wed, 08 Feb 2017 10:10:20 +0100

Hi 6tisch security,

Having re-read RPLinfo and reading the secure-join draft, I do have a 
suggestion about the traffic from pledge to registrar. The draft already 
mentions the IP-in-IP encapsulation specified in RPLinfo draft. Why not 
rely on the RPLinfo draft for the pledge to Registrar communication 
completely?

The pledge can be considered a non-RPL aware node, one hop away from a 
DODAG node.

The pledge may receive (allocate itself) a "temporary" routable IPv6 
address.
When it sends requests to the Registrar the join-proxy (first 6lri in 
RPLinfo) will add the necessary IP-in-IP headers. Also for the message 
from Registrar to pledge the same RPLinfo specification will be used.
The Registrar does not need to be part of the DODAG, because RPLinfo 
prescribes what to do.

I don't think allocating a temporary routable address will make the 
network more vulnerable.
Communication between pledge and assistant is still over an insecure 
link with a permission to allow traffic from this one routable address 
(instead of link-local address) to the registrar.

Once the pledge is accepted and the link is secured, I assume that 
neighbour discovery takes place, prefixes are distributed, routable 
addresses are allocated, and the temporary address disappears.

Using RPLinfo makes the protocol less ad-hoc and relies on other 
established (RPLinfo) specifications.

Greetings,

Peter
-- 
Peter van der Stok
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Feb 2017 07:23:01 -0500

see inline.

> rely on the RPLinfo draft for the pledge to Registrar communication

This was always my intention: leverage the IPIP compression mechanism
and source route forwarding... no new code!  I'm glad you came up with
the idea too, which means it must be a good one!

I had a number of thoughts about how to do this.
a) have the Join Proxy send a DAO about the pledge.  This is simplest in
many ways, and for non-storing networks, this has no impact on the mesh.
 For storing networks, this would be an issue, and I'd suggest having
another non-storing instance for joining... (but, mixed mode)
b) use another signal from Join Proxy to JRC/root.  This is what I'm
currently proposing, although I used GRASP which may demand TCP. The DAO
mechanism has the downside of not providing any ACK.

> The pledge may receive (allocate itself) a "temporary" routable IPv6

I'm not convinced the pledge *needs* that routable address if all the
traffic is IPIP encapsulated.  I'm pretty sure that I'd rather not
expose the prefix of the network to the unauthenticated pledge if we can
avoid that.  It also implies that the pledge needs to hear a RA.

> (instead of link-local address) to the registrar.

I agree with you: it can be made to work.  Are you thinking that the
temporary address would not be from the network's prefix, but entirely
different?  Why do we even need that, I wonder.

Do you think there is any increased risk of one pledge attacking another
one?