Re: [Roll] home-building-requirements section 7.2

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

Hi Rene,

I think you got most requirements right.
Sandeep and I will prepare an I-D for 6lo in which we will motivate the 
order of joining in more detail.
We think that the joining operation as explained in 
draft-richardson-6tisch--security-6top-04 covers already many aspects.

Concerning routing:
I expect that separating routing protocol operation from the joining 
process is beneficial.
e.g. Routing is started up before network is secured,
or use an inefficient nd-related routing during joining, etc.

Hope this helps,

Greetings,

Peter

Rene Struik schreef op 2014-12-16 17:08:
> Hi Peter:
> 
> When contemplating some joining protocol details, I was wondering
> about incremental deployment (as mentioned in clause 7.2 of your
> draft). This was also one of the scenarios that came up with hallway
> discussions with Sandeep Kumar during IETF-91.
> 
> From your email below, it seems that you would like to have the join
> protocol have the following features:
> a) the order of joining should be orthogonal to routing protocol
> topology considerations, if it all possible.
> b) in particular, not all installations follow the pattern where one
> has an operational network and where all non-local communications
> during the join protocol not of the type {joining node - neighbor
> router} are within the operational network (case in point: tree-like
> structure, where network is built from tree root up onwards).
> 
> The joining process consists of various stages, including
> authentication, authorization, and configuration, where configuration
> and possibly authentication and authorization may require a
> communication path between joining node and a network management node
> that may be multiple hops away, where the latter typically takes place
> via the neighbor router.
> 
> If the joining process is aimed to provide security services, the main
> requirement on the communication path between neighbor node and
> network management node(s) is "that it is there" (i.e., there is
> connectivity) although there may be additional requirement to counter,
> e.g., denial of service attacks on communications related to the
> joining process emanating from the neighbor node.
> 
> Do you think that designing the join process so as to minimize
> dependencies between joining process and routing protocol would be
> beneficial for your use case of facilitating "random" installation
> process flows? (An alternative would be to intertwine routing and
> joining processes, but it seems to conflict item #b above.)
> 
> Obviously, once a node is part of the network, it should be able to
> route packets (but that is not part of the join protocol itself, but
> next-stage phase).
> 
> Any insights on incremental deployment scenarios appreciated.
> 
> Best regards, Rene
> 
> On 12/9/2014 2:55 AM, peter van der Stok wrote:
>> Probably we are not going the EAP-PANA route because EAP PANA imposes 
>> an order of joining determined by the network topology.
>> Today, that order will not, cannot, is unlikely to, be respected by 
>> the installation protocol.
>> 
>> Consequently, I like to keep the uncertainty in the document.
>> 
>> 
>> 
>> Michael Richardson schreef op 2014-12-08 19:47:
>>> You ask:     > What are enrollment tools?
>>> 
>>> By this, I mean that the combination of protocols and/or provisioning
>>> equipment that allows an installer to make a lightbulb join a 
>>> particular
>>> network.
>>> 
>>> That's why I want to know, if you are going the EAP-PANA route, that 
>>> one
>>> needs to know what EAP methods ought to be supported.
>>> 
>>> 
>>> peter van der Stok <[e-mail]> wrote:
>>>     > thanks for the encouragement.
>>>     > Concerning bootstrap and security in general. Many things are 
>>> going on and
>>>     > there are two approaches to this document:
>>>     > 1) a conservative one; restrict to what exists and is is proven 
>>> to work
>>>     > 2) leaving the doubt that exists today.
>>> 
>>>     > For the moment I like to leave the doubt, because in 5 years, 
>>> what is sure
>>>     > today will not be implemented is my conviction
>>> 
>>>     > Concerning switching on/off:
>>>     > That is SDO stuff; KNX , BACnet , etc... are preparing
>>> additional standards.
>>> 
>>>     > What are enrollment tools?
>>> 
>>>     > Peter
>>> 
>>> 
>>>     > Michael Richardson schreef op 2014-11-23 22:16:
>>>     >> I am very pleased with the document; I hope the WG is reading 
>>> it, and is
>>>     >> also happy with it.
>>>     >>
>>>     >> In secton 7.1 you mention use of PANA to secure new nodes.
>>>     >> The reference seems very hesistant, and the DTLS relay is just 
>>> kind of
>>>     >> thrown in.   Can you make this recommendation more concrete? 
>>> Or
>>> remove it.
>>>     >>
>>>     >> If it's PANA, I assume EAP is involved, and so what what EAP
>>> methods should
>>>     >> be used?
>>>     >>
>>>     >> I think that, having read this document, I ought to be able to 
>>> create a
>>>     >> light-bulb or light switch --- I think that I can make it 
>>> function in the
>>>     >> network, but I don't think it will use the same enrollment 
>>> tools at all,
>>>     >> and
>>>     >> I'd sure like to change that.  I don't mind being really 
>>> really specific
>>>     >> here: I encourage it.
>>>     >>
>>>     >> I also don't know what protocol to use for turning lights 
>>> on/off, but I
>>>     >> acknowledge that is out of scope for the ROLL WG to specify.
>>> Perhaps there
>>>     >> is an informative reference I missed.
>>>     >>
>>>     >> I think that unless you have a specific way to use the DTLS 
>>> relay, you
>>>     >> should
>>>     >> remove the reference -- it doesn't help anyone trying to 
>>> implement an
>>>     >> interoperable device.
>> 
>> _______________________________________________
>> Roll mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll