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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 9 Dec 2014 16:37:10 +0000

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: Thomas Watteyne <[email-masked]>
Date: Fri, 19 Dec 2014 12:48:26 +0100

Pascal,

How does this compare (both in contents and purpose) to the text sent out
by Michael in
http://www.ietf.org/mail-archive/web/6tisch/current/msg02690.html?

Supersedes? Side-by-side? Different purpose?

Thanks,
Thomas

On Tue, Dec 9, 2014 at 5:37 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:
>
>  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 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.
>
>
>
> “
>
>
>
> _______________________________________________
> 6tisch-security mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch-security
>
>