[6tisch-security] Proposed text for archie

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Tue, 09 December 2014 16:37 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch-security@ietfa.amsl.com
Delivered-To: 6tisch-security@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B511A8986 for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 08:37:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwPQT-eolgpu for <6tisch-security@ietfa.amsl.com>; Tue, 9 Dec 2014 08:37:12 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A3001A894F for <6tisch-security@ietf.org>; Tue, 9 Dec 2014 08:37:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12605; q=dns/txt; s=iport; t=1418143033; x=1419352633; h=from:to:cc:subject:date:message-id:mime-version; bh=s8ZIMi977H1U+Qv/9IbEL6vwNPlboi/bVYRvL643yCI=; b=YJ/XUbtt90hWbRlYH9W3wrqnahsVd3Vj522zzKF91sLZVwvo7rpWtpyr Ppv6Xqs3MeR/rMOr+IFpDKFCkvsvQVgX8uZxNzee1xa72e26HIzce1FNv PAKVtMoDuOOHYm499rjSEKrVRtKXs9saP4eUDc76FANOTSr9ueSuZjZ/k Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhAFAIkkh1StJA2E/2dsb2JhbABZgkNDUlzDeIgvAoEmFgEBAQEBfYQEAQQtRwUSARoQVhcPAQQBDQ2IMNceAQEBAQEBAQEBAQEBAQEBAQEBAQEBF5ALMYMogRUFjg2KIoJfjX6DboF0JBx+AQEB
X-IronPort-AV: E=Sophos;i="5.07,546,1413244800"; d="scan'208,217";a="104087824"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 09 Dec 2014 16:37:12 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sB9GbBcU022314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Dec 2014 16:37:11 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.39]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 9 Dec 2014 10:37:10 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, Rene Struik <rstruik.ext@gmail.com>
Thread-Topic: Proposed text for archie
Thread-Index: AdATzjmZJHu11c8wSquZ34lo47VkwQ==
Date: Tue, 09 Dec 2014 16:37:10 +0000
Deferred-Delivery: Tue, 9 Dec 2014 16:37:00 +0000
Message-ID: <E045AECD98228444A58C61C200AE1BD848AB3927@xmb-rcd-x01.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.61.196.91]
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD848AB3927xmbrcdx01ciscoc_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/6tisch-security/8vM0cnWvx9sMfYdg756PRrqUDjM
Cc: "6tisch-security@ietf.org" <6tisch-security@ietf.org>
Subject: [6tisch-security] Proposed text for archie
X-BeenThere: 6tisch-security@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Extended Design Team for 6TiSCH security architecture <6tisch-security.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tisch-security/>
List-Post: <mailto:6tisch-security@ietf.org>
List-Help: <mailto:6tisch-security-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch-security>, <mailto:6tisch-security-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Dec 2014 16:37:19 -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