Re: [6tisch-security] secure join bootstrap

[peter van der Stok <[e-mail]>]

Hi Michael,

thanks for your answer; below some requests for additional information.
-- changed 6tisch to 6tisch-security --

Michael Richardson schreef op 2017-02-10 13:23:
> see inline.
> 
> On 02/08/17 04:10, peter van der Stok wrote:
>> 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?
> 
> 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!

My hope is making the protocol general and leave details to local 
routing protocol.

> 
> I had a number of thoughts about how to do this.

Thanks for the thoughts, but let me ask some questions such that I am 
sure to understand the reasons for the thoughts.

Suppose the pledge has address P6 and the join proxy has address J6.
When the encapsulated packet arrives at a RPL aware registrar, first the 
the encapsulating header is removed;
losing address J6 or losing the LL address of the last router. 
(correct?)
and then the Registrar receives the packet with address P6.
The main question to be solved is how can RPL route a packet to P6 which 
is unknown.
Therefore you suggest the two thoughts below?  (correct?)
> 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)

The above looks efficient to me for non-storing mode.
For storing networks, Creating a new DODAG instance sounds work 
intensive for every pledge.
Instead, Encapsulating at Join Proxy with source address P6 instead of 
J6 might work?

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

This I do not understand completely; GRASP is anima oriented at L3, and 
only comes after securing L2, I thought.
> 
>> 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.
> 
> 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.

IMO, a routable address is needed when other routing protocols (not RPL) 
need to fill in their routing tables for the return messages from 
Registrar to Pledge.

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

Equally not sure about what prefix to use. Most routing protocols do not 
care about prefixes, do they?
They only care about routes to IPv6 addresses expressed in L2 addresses.
> 
> Do you think there is any increased risk of one pledge attacking 
> another
> one?
> 
In general, an attacker will use a routable address or an LL address 
depending on its purpose.
In the 6tisch case, the acceptance of packets is independent of the 
address but depends on the link being secured. So I don't see any 
preferences for LL or global addresses.

Then we come to a malicious node taking over the IP address of the 
bona-fide pledge.
The malicious node needs the identity information of the bona fide 
pledge to be effective.
Why bother stealing the IP address when this identity information is 
already stolen?

Do you know of other opportunities?
> 

Peter