Subject: Re: [Roll] home-building-requirements section 7.1

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Dec 2014 13:47:34 -0500

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 <[email-masked]> 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.

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

---

From: peter van der Stok <[email-masked]>
Date: Tue, 09 Dec 2014 08:55:31 +0100

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.

---

From: <[email-masked]>
Date: Wed, 10 Dec 2014 23:24:00 +0000

It depends on the requirements on the target system.  If the target system is formed in a totally ad-hoc fashon, then the joining order is not determined by network topology.  

But in home and building networks where some a central management entity typically exists, there will be a connectivity issue if the joining order is not determined by network topology. In such a managed network, the application in a node should be ready to work when the node successfully connected to the network, which happens when the node successfully connected to its neighbor that is "already" connected to the network (that's why joining order comes).

Having said that I think it is OK to mention PANA in section 7.1.  For EAP methods, EAP-TLS is used for ZigBee IP and EAP-PSK is used for Wi-SUN HAN, AFAIK.   On the other hand, I do not mind having DTLS-relay and ongoing 6tisch security work.

Regards,
Yoshihiro Ohba

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Tuesday, December 9, 2014 4:56 PM
To: Michael Richardson
Cc: [email-masked]; [email-masked]; Anders Brandt
Subject: Re: [Roll] home-building-requirements section 7.1

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.

Michael Richardson schreef op 2014-12-08 19:47:
> 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.
> 
> 

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Rene Struik <[email-masked]>
Date: Tue, 16 Dec 2014 11:08:09 -0500

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.

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: peter van der Stok <[email-masked]>
Date: Wed, 17 Dec 2014 08:39:59 +0100

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.
> 
> 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).
> 
> 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.
> 
>>> particular
>>> one
>>>     >> thrown in.   Can you make this recommendation more concrete? 
>>> Or
>>> remove it.
>>>     >>