Subject: Re: [6tisch-security] Proposed text for archie

From: <[email-masked]>
Date: Fri, 9 Jan 2015 05:32:05 +0000

In the last 6tisch security call, I promised to send my comments on the proposed text, and here is my try.

I think describing the 3 logical elements (JN, JA and JCE) is the key work in the security architecture.

On the other hand, I think the following specific parts (and I commented about these before) need more investigation and I don’t think we can include them in the architecture draft:

-          Use of ULA prefix for joining.

-          Use of RH2 for communicating between JN and JCE via JA.

-          Use of DTLS for joining purpose, including JCE-initiated DTLS.

This is a solution, but there are multiple other solutions being discussed as well.  I think the architecture should be described in a general way to cover possible solutions not just a single specific solution with protocol names, and designing/choosing a solution or solutions  should be started only after we agree with the general architecture.

Regards,
Yoshihiro Ohba

From: 6tisch-security [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, December 10, 2014 1:37 AM
To: Michael Richardson; Rene Struik
Cc: [email-masked]
Subject: [6tisch-security] Proposed text for archie

Dear all:

Please find my summary of our recent discussions with the sort of level I would expect for the archi spec at this stage.

“

The join process is the process by which a node, virtually out of the box, will discover a network, get authenticated and authorized in the network, obtain credentials to participate to the network, and obatin reachability through the network.

The architecture specifies 3 logical elements to describe the join process:
- a Joining Node (JN), that is yet not authenticated to participate to the network,
- a Join Assistant (JA), that is already participating to the network, and is reachable over the network
- a Join Coordination Entity, that is the front end for authentication and authorization for the JA.

The text below makes a difference between a join IPv6 link and other IPv6 links in the production network. With 6TiSCH, an IPv6 link is associated in each node with a particular bundle of cells for multicast transmissions. The production network can be a multilink subnet of such IPv6 links. In some networks, the join process may happen on that bundle, using the production prefix, but this exposes production information and may not be desirable. In a more secure mode, a separate IPv6 link, and associated bundle is defined in each individual JA. A particular ULA prefix t is locally assigned by the JA for use in that IPv6 link and is not exposed to the routing fabric in the production network. The ULA prefix uniquely indicates the particular join link on which it is exposed.

At the beginning of times, the JA exposes a joining set of information in a beacon. This information includes link information for the bundle that can be used to join (schedule IE…) and routing information (RA message). The JN scans the network till it gets such message. The message is signed and may be encrypted with a well-known key, but for all practical purpose it is considered in the clear. The prefix in the RA exposes the ULA prefix when that mode is used, as opposed to the production prefix.

Upon reception of the beacon, the JN forms an address from the prefix in the RA. This address is not injected in the routing fabric, and no state is formed in the network for that particular address. The JN contacts the JA to join the network using that address, and the JA relays the request to the JCE by encapsulating it in a JA-to-JCE message. At this stage, a DoS attack by a rogue JN can only be local to the JA. The JA may throttle join requests or perform additional checks to defeat such attacks. The size of the join bundle for that particular JA is another constraint that limits DoS attack. The JN may store an ND cache mapping the ULA address of the JN with the MAC address of the JN, but it does not need to.

Upon reception of the join request from the JA, the JCE stores the request to be processed asynchronously or dropped. When the JCE decides to respond, it contacts the JN directly and establishes an end-to-end JCE-to-JN DTLS connection. At that point of time, the JA can reach the JN’s address over the join bundle, but the JN address is not advertised over the routing fabric, so it cannot be reached directly from the JCE. To reach the JN, the JCE sets the destination address in the IP packet as the JA, and inserts a RH type 2 indicating the address of the JN, which only the JA can route to. The JA receives the packet, processes the RH2. The prefix (e.g. a ULA) indicates which IPv6 link (which bundle) can be used to reach the JN. The JA resolves the MAC address of the JN (either using an NS/NA exchange or implicitly if the IID is based on MAC-64), and forwards the packet to the JN.

When the exchange between the JN and the JCE is completed, the JN owns a network key that it can use in the production network. The JN contacts the JA again using an encrypted RS message. The JA responds with an encrypted RA message with information on the production network. The relevant IEs are passed with the RA message so the JN may now form an address in the production network. At that point, the JN uses efficient ND to validate its address, and the 6LR -typically but not necessarily the JA) injects that address in the LLN using RPL, as discussed earlier in the architecture.

“

Does this reflect a common consensus?

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Jan 2015 07:39:25 +0000

Hello Yoshi:

The goal of Archie is to explain how things work as soon as we get a WG consensus that we can build upon and progress upon and beyond.

In the case of the security, all this is still DT work, not WG consensus, so all the section will be presented as an envisioned approach anyway, not a committed milestone.
My intent for the whole security section is to prefix the DT text with a warning that this is only a direction for work that will be done after re-chartering, and that the consensus that the text represents is a DT consensus.

>From there, the effective text is 1) up to you guys and 2) not a cast in stone anyway.
It is up to the DT to define whether there is already DT consensus on the points that you wish to elide. If there is no consensus, then it should not pop up in Archie.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]]
Sent: vendredi 9 janvier 2015 06:32
To: Pascal Thubert (pthubert); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Proposed text for archie

On the other hand, I think the following specific parts (and I commented about these before) need more investigation and I don't think we can include them in the architecture draft:

Regards,
Yoshihiro Ohba

Cc: [email-masked]<mailto:[email-masked]>

Dear all:

"

At the beginning of times, the JA exposes a joining set of information in a beacon. This information includes link information for the bundle that can be used to join (schedule IE...) and routing information (RA message). The JN scans the network till it gets such message. The message is signed and may be encrypted with a well-known key, but for all practical purpose it is considered in the clear. The prefix in the RA exposes the ULA prefix when that mode is used, as opposed to the production prefix.

Upon reception of the join request from the JA, the JCE stores the request to be processed asynchronously or dropped. When the JCE decides to respond, it contacts the JN directly and establishes an end-to-end JCE-to-JN DTLS connection. At that point of time, the JA can reach the JN's address over the join bundle, but the JN address is not advertised over the routing fabric, so it cannot be reached directly from the JCE. To reach the JN, the JCE sets the destination address in the IP packet as the JA, and inserts a RH type 2 indicating the address of the JN, which only the JA can route to. The JA receives the packet, processes the RH2. The prefix (e.g. a ULA) indicates which IPv6 link (which bundle) can be used to reach the JN. The JA resolves the MAC address of the JN (either using an NS/NA exchange or implicitly if the IID is based on MAC-64), and forwards the packet to the JN.

"

Pascal

---

From: <[email-masked]>
Date: Fri, 9 Jan 2015 12:34:01 +0000

Hi Pascal.

Thank you for your clarification.

Yoshihiro Ohba

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Friday, January 9, 2015 4:39 PM
To: ohba yoshihiro(大場 義洋 ○ＲＤＣ□ＮＳＬ); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Proposed text for archie

Hello Yoshi:

Cheers,

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: vendredi 9 janvier 2015 06:32
To: Pascal Thubert (pthubert); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Proposed text for archie

Regards,
Yoshihiro Ohba

Dear all:

“

“

Pascal