< draft-richardson-6tisch--security-6top-03.txt		draft-richardson-6tisch--security-6top-04.txt >
	Network Working Group M. Richardson		Network Working Group M. Richardson
	Internet-Draft SSW		Internet-Draft SSW
	Intended status: Informational October 26, 2014		Intended status: Informational November 11, 2014
	Expires: April 29, 2015		Expires: May 15, 2015
	6tisch secure join using 6top		6tisch secure join using 6top
	draft-richardson-6tisch--security-6top-03		draft-richardson-6tisch--security-6top-04
	Abstract		Abstract
	This document details a security architecture that permits a new		This document details a security architecture that permits a new
	6tisch compliant node to join an 802.15.4e network. The process		6tisch compliant node to join an 802.15.4e network. The process
	bootstraps the new node authenticating the node to the network, and		bootstraps the new node authenticating the node to the network, and
	the network to the node, and configuring the new node with the		the network to the node, and configuring the new node with the
	required 6tisch schedule. Any resemblance to WirelessHART/IEC62591		required 6tisch schedule. Any resemblance to WirelessHART/IEC62591
	is entirely intentional.		is entirely intentional.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on April 29, 2015.		This Internet-Draft will expire on May 15, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology and Roles . . . . . . . . . . . . . . . . . . . . 4		2. Terminology and Roles . . . . . . . . . . . . . . . . . . . . 4
	3. Architectural requirements of join protocol . . . . . . . . . 6		3. Architectural requirements of join protocol . . . . . . . . . 6
	3.1. prefixes to use for join traffic . . . . . . . . . . . . 10		3.1. Entities involves in the join processions . . . . . . . . 6
	4. security requirements . . . . . . . . . . . . . . . . . . . . 10		3.2. Join Protocol deliverables . . . . . . . . . . . . . . . 6
	4.1. threat model . . . . . . . . . . . . . . . . . . . . . . 10		3.3. Join Protocol connection setup . . . . . . . . . . . . . 7
	4.1.1. threats to the joining node . . . . . . . . . . . . . 10		3.4. End to End considerations for Join Protocol . . . . . . . 8
	4.1.2. threats to the resources of the network . . . . . . . 11		3.4.1. Security Considerations: alternatives to source
	4.1.3. threats to other joining nodes . . . . . . . . . . . 11		routes . . . . . . . . . . . . . . . . . . . . . . . 9
	4.2. implementation cost . . . . . . . . . . . . . . . . . . . 12		3.5. Join node discovery mechanism . . . . . . . . . . . . . . 10
	4.3. denial of service . . . . . . . . . . . . . . . . . . . . 12		3.5.1. prefixes to use for join traffic . . . . . . . . . . 12
	5. protocol requirements/constraints/assumptions . . . . . . . . 12		4. security requirements . . . . . . . . . . . . . . . . . . . . 12
	5.1. inline/offline . . . . . . . . . . . . . . . . . . . . . 12		4.1. threat model . . . . . . . . . . . . . . . . . . . . . . 12
	6. time sequence diagram . . . . . . . . . . . . . . . . . . . . 12		4.1.1. threats to the joining node . . . . . . . . . . . . . 12
	6.1. explanation of each step . . . . . . . . . . . . . . . . 13		4.1.2. threats to the resources of the network . . . . . . . 13
	6.1.1. step (1): enhanced beacon . . . . . . . . . . . . . . 14		4.1.3. threats to other joining nodes . . . . . . . . . . . 14
	6.1.2. step (1B): send router solicitation . . . . . . . . . 14		4.2. implementation cost . . . . . . . . . . . . . . . . . . . 14
	6.1.3. step (1C): receive router advertisement . . . . . . . 14		4.3. denial of service . . . . . . . . . . . . . . . . . . . . 14
	6.1.4. step (2): certificate cache load . . . . . . . . . . 14		5. protocol requirements/constraints/assumptions . . . . . . . . 14
	6.1.5. step (3): receive certificate cache . . . . . . . . . 14		5.1. inline/offline . . . . . . . . . . . . . . . . . . . . . 14
	6.1.6. step (4): join request . . . . . . . . . . . . . . . 15		6. time sequence diagram . . . . . . . . . . . . . . . . . . . . 14
	6.1.7. step (5): NS duplicate address request (DAR) . . . . 15		6.1. explanation of each step . . . . . . . . . . . . . . . . 15
	6.1.8. step (7): 6LBR informs JCE of new node . . . . . . . 15		6.1.1. step (1): enhanced beacon . . . . . . . . . . . . . . 15
	6.1.9. step (8): JCE informs/acks to 6LBR of new node . . . 15		6.1.2. step (1B): send router solicitation . . . . . . . . . 16
	6.1.10. step (9): NS duplicate address confirmation (DAC) . . 15		6.1.3. step (1C): receive router advertisement . . . . . . . 16
	6.1.11. step (10): JCE initiates connection to joining node . 15		6.1.4. step (2): certificate cache load . . . . . . . . . . 16
			6.1.5. step (3): receive certificate cache . . . . . . . . . 16
			6.1.6. step (4): join request . . . . . . . . . . . . . . . 16
			6.1.7. step (5): NS duplicate address request (DAR) . . . . 16
			6.1.8. step (7): 6LBR informs JCE of new node . . . . . . . 17
			6.1.9. step (8): JCE informs/acks to 6LBR of new node . . . 17
			6.1.10. step (9): NS duplicate address confirmation (DAC) . . 17
			6.1.11. step (10): JCE initiates connection to joining node . 17
	6.1.12. step (11): Join Assistant forwards packet to joining		6.1.12. step (11): Join Assistant forwards packet to joining
	node . . . . . . . . . . . . . . . . . . . . . . . . 15		node . . . . . . . . . . . . . . . . . . . . . . . . 17
	6.1.13. step (12): Joining node replies . . . . . . . . . . . 15
	6.1.14. step (13): Join Assistant forwards reply to JCE . . . 15		6.1.13. step (12): Joining node replies . . . . . . . . . . . 17
	6.2. size of each packet . . . . . . . . . . . . . . . . . . . 16		6.1.14. step (13): Join Assistant forwards reply to JCE . . . 17
	7. resulting security properties obtained from this process . . 16		6.2. size of each packet . . . . . . . . . . . . . . . . . . . 18
	8. deployment scenarios underlying protocol requirements . . . . 16		7. resulting security properties obtained from this process . . 18
	9. device identification . . . . . . . . . . . . . . . . . . . . 16		8. deployment scenarios underlying protocol requirements . . . . 18
	9.1. PCE/Proxy vs Node identification . . . . . . . . . . . . 16		9. device identification . . . . . . . . . . . . . . . . . . . . 18
	9.2. Time source authentication / time validation . . . . . . 16		9.1. PCE/Proxy vs Node identification . . . . . . . . . . . . 18
	9.3. description of certificate contents . . . . . . . . . . . 16		9.2. Time source authentication / time validation . . . . . . 18
	9.4. privacy aspects . . . . . . . . . . . . . . . . . . . . . 16		9.3. description of certificate contents . . . . . . . . . . . 18
	10. slotframes to be used during join . . . . . . . . . . . . . . 17		9.4. privacy aspects . . . . . . . . . . . . . . . . . . . . . 18
	11. configuration aspects . . . . . . . . . . . . . . . . . . . . 17		10. slotframes to be used during join . . . . . . . . . . . . . . 18
	12. authorization aspects . . . . . . . . . . . . . . . . . . . . 17		11. configuration aspects . . . . . . . . . . . . . . . . . . . . 18
	12.1. how to determine a proxy/PCE from a end node . . . . . . 17		12. authorization aspects . . . . . . . . . . . . . . . . . . . . 19
	12.2. security considerations . . . . . . . . . . . . . . . . 17		12.1. how to determine a proxy/PCE from a end node . . . . . . 19
	13. security architecture . . . . . . . . . . . . . . . . . . . . 17		12.2. security considerations . . . . . . . . . . . . . . . . 19
	14. Posture Maintenance . . . . . . . . . . . . . . . . . . . . . 17		13. security architecture . . . . . . . . . . . . . . . . . . . . 19
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 17		14. Posture Maintenance . . . . . . . . . . . . . . . . . . . . . 19
	16. Other Related Protocols . . . . . . . . . . . . . . . . . . . 17		15. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		16. Other Related Protocols . . . . . . . . . . . . . . . . . . . 19
	18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	19. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		18. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	19.1. Normative references . . . . . . . . . . . . . . . . . . 17		19. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	19.2. Informative references . . . . . . . . . . . . . . . . . 19		19.1. Normative references . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20		19.2. Informative references . . . . . . . . . . . . . . . . . 21
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	A challenging part with constructing an LLN with nodes from multiple		A challenging part with constructing an LLN with nodes from multiple
	vendors is providing enough security context to each node such that		vendors is providing enough security context to each node such that
	the network communication can form and remain secure. Most LLNs are		the network communication can form and remain secure. Most LLNs are
	small and have no operator interfaces at all, and even if they have		small and have no operator interfaces at all, and even if they have
	debug interfaces (such as JTAG) with personnel trained to use that,		debug interfaces (such as JTAG) with personnel trained to use that,
	doing any kind of interaction involving electrical connections in a		doing any kind of interaction involving electrical connections in a
	dirty environment such as a factory or refinery is hopeless.		dirty environment such as a factory or refinery is hopeless.
	skipping to change at page 6, line 22 ¶		skipping to change at page 6, line 33 ¶
	protocol into a client/server process		protocol into a client/server process
	EARO [I-D.thubert-6lo-rfc6775-update-reqs]extends the		EARO [I-D.thubert-6lo-rfc6775-update-reqs]extends the
	ARO option to include some additional fields		ARO option to include some additional fields
	necessary to distinguish duplicate addresses from		necessary to distinguish duplicate addresses from
	nodes that have moved networks when there are		nodes that have moved networks when there are
	mulitple LLNs linked over a backbone.		mulitple LLNs linked over a backbone.
	3. Architectural requirements of join protocol		3. Architectural requirements of join protocol
			3.1. Entities involves in the join processions
			The following actors are involved: there is a new joining node. It
			is (radio) adjacent to the join assistant. The join assistant is
			part of the production network, and participates in one or more
			DODAGs, such that it is reachable from the 6LBR, and the JCE.
			3.2. Join Protocol deliverables
	This section works from the ultimate goal, and goes backwards to		This section works from the ultimate goal, and goes backwards to
	prerequisite actions. Section 6 presents the protocol from beginning		prerequisite actions. (Section 6 presents the protocol from
	to end order.		beginning to end order)
	The ultimate goal of the join protocol is to provide a new node with		The ultimate goal of the join protocol is to provide a new node with
	enough locally significant security credentials that it is able to		a locally significant security credentials that it is able to take
	take part in the network directly. The credentials may vary by		part in the network directly. The credentials may vary by
	deployment. They can be one of:		deployment. They can be one of:
	1) a network-wide shared symmetric key (this is the production		1) a network-wide shared symmetric key (this is the production
	network key, or MasterKey)		network key, or MasterKey)
	2) a locally significant (one-level only) 802.11AR type DevID		2) a locally significant (one-level only) 802.11AR type LDevID
	certificate (which allows it to negotiate a pair-wise key)		certificate (which allows it to negotiate a pair-wise keys)
	One of these items is communicated by the JCE to the joining node		One of these two items is delivered by JCE to the joining node using
	using the 6top protocol. The authentication of this communication		the 6top protocol. That is, the JCE provisions using a secure
	channel is the subject of the Join Protocol as explained below.		"northbound" interface. The authentication of this interface the
			subject of the Join Protocol as explained below.
	Given one of the the above, there are a number of possible protocols		The above credential are used for authentication to generate per-peer
	that can be used to generate layer-2 sessions keys for the node,		L2, using a key exchange protocol. The choice of key exchange
	including:		protocol, and what kind of link and multicast keying needs to be done
			is also provisioned by the JCE. There are a number of options for
			doing this, such as:
	1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment]		1) Mesh Link Exchange [I-D.kelsey-intarea-mesh-link-establishment]
	(IMPORTANT, a good option. Uses certificates from common CA)		(IMPORTANT, a good option. Uses certificates from common CA)
	2) work in 802.15.9 (uses certificates from common CA)		2) work in 802.15.9 (uses certificates from common CA)
	3) Security Framework and Key Management Protocol Requirements for		3) Security Framework and Key Management Protocol Requirements for
	6TiSCH [I-D.ohba-6tisch-security] (this document provides the		6TiSCH [I-D.ohba-6tisch-security] (this document provides the
	phase 0 required, using the network-wide shared key)		phase 0 required, using the network-wide shared key)
	4) Layer-2 security aspects for the IEEE 802.15.4e MAC		4) Layer-2 security aspects for the IEEE 802.15.4e MAC
	[I-D.piro-6tisch-security-issues]: the MasterKey is used to		[I-D.piro-6tisch-security-issues]: the MasterKey is used to
	derive per-peer L2 keys		derive per-peer L2 keys
	Per-peer L2 keying is critical when doing peer2peer schedule		Per-peer L2 keying is critical when doing peer-2-peer schedule
	negotiation over 15.4 Information Elements. Therefore a network-wide		negotiation over 15.4 Information Elements. Therefore a network-wide
	layer-2 key is inappropriate for the self-organizing networks, and a		layer-2 key is inappropriate for the self-organizing networks, and a
	protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys.		protocol (MLE, 802.15.9) SHOULD be used to derive per-peer L2 keys.
	For networks where there is a PCE present and will do all schedule		For networks where there is a PCE present and it will do all schedule
	computation, then the only trust relationship necessary is between		computation, then the only trust relationship necessary is between
	the individual node and the PCE, and it MAY be acceptable to have a		the individual node and the PCE, and it MAY be acceptable to have a
	network-wide L2 key derived in ways such as		network-wide L2 key derived in ways such as
	[I-D.piro-6tisch-security-issues] describes in section ?		[I-D.piro-6tisch-security-issues] describes in section ?. The trust
			relationship between the PCE and the joining node flows from the
			LDevID certificate loaded by the JCE. When the PCE and JCE are co-
			located, the existing 6top/DTLS security association could be reused.
	The intermediate goal of the join protocol is to enable a Join		3.3. Join Protocol connection setup
			The intermediate level goal of the join protocol is to enable a Join
	Coordination Entity (JCE) to reach out to the new node, and install		Coordination Entity (JCE) to reach out to the new node, and install
	the credentials detailed above. The JCE must authenticate itself to		the credentials detailed above. The JCE must authenticate itself to
	the joining node so that the joining node will know that it has		the joining node so that the joining node will know that it has
	joined the correct network, and the joining node must authenticate		joined the correct network, and the joining node must authenticate
	itself to the JCE so that the JCE will know that this node belongs in		itself to the JCE so that the JCE will know that this node belongs in
	the network. This two way authentication occurs in the 6top/CoAP/		the network. This two way authentication occurs in the 6top/CoAP/
	DTLS session that is established between the JCE and the joining		DTLS session that is established between the JCE and the joining
	node.		node.
	[I-D.ietf-6tisch-6top-interface] presents a way to interface to a		[I-D.ietf-6tisch-6top-interface] presents a way to interface to a
	6top information model (defined in YANG). [I-D.ietf-6tisch-coap]		6top information model (defined in YANG). [I-D.ietf-6tisch-coap]
	explains how to access that information model using CoAP. That model		explains how to access that information model using CoAP. This
	is to be extended to include security attributes for the network.		information model will include security attributes for the network.
	The JCE would therefore reach out to the joining node and simply		The JCE would therefore reach out to the joining node and simply
	provision appropriate security properties into the joining node, much		provision appropriate security properties into the joining node, much
	like the PCE will provision schedules.		like the PCE will provision schedules.
	This 6top-based secure join protocol has defined a push model for		This 6top-based secure join protocol has defined a push model for
	security provisioning by the JCE. This has been done for three		security provisioning by the JCE. This has been done for three
	reasons:		reasons:
	1) 6tisch nodes already have to have a 6top CoAP server for schedule		1) 6tisch nodes already have to have a 6top CoAP server for schedule
	provising		provising
	skipping to change at page 8, line 11 ¶		skipping to change at page 8, line 42 ¶
	3) making the JCE initiate the DTLS connection significantly		3) making the JCE initiate the DTLS connection significantly
	simplies the certificate chains that must be exchanged as the		simplies the certificate chains that must be exchanged as the
	most constrained side (the joining node) provides it's		most constrained side (the joining node) provides it's
	credentials first, and lets the less constrained JCE figure out		credentials first, and lets the less constrained JCE figure out
	what kind of certificate chain will be required to authenticate		what kind of certificate chain will be required to authenticate
	the JCE to the joining node. In EAP-TLS/802.1x situations, the		the JCE to the joining node. In EAP-TLS/802.1x situations, the
	TLS channel is created in the opposite direction, and it would		TLS channel is created in the opposite direction, and it would
	have to complete in a tentative way, and then further		have to complete in a tentative way, and then further
	authorization occur in-band.		authorization occur in-band.
			3.4. End to End considerations for Join Protocol
	In order for a 6top/DTLS/CoAP connection to occur between the JCE and		In order for a 6top/DTLS/CoAP connection to occur between the JCE and
	the joining node, there needs to be end-to-end IPv6 connectivity		the joining node, there needs to be end-to-end IPv6 connectivity
	between those two entities. The joining node will not participate in		between those two entities. The joining node will not participate in
	the route-over RPL mesh, but rather will be seen by the network as		the route-over RPL mesh, but rather will be seen by the network as
	being a 6lowpan only leaf-node.		being a 6lowpan only leaf-node.
			The joining node sends traffic to the join assistant, which forwards
			it using the normal RPL DODAG upwards routes, and which will reach
			the JCE using regular routing.
			The challenge is getting connectivity from the JCE to the joining
			node, as the DODAG will have no information about this node.
			Instead, the JCE will use loose-source routes to address packets
			first to the Join Assistant, which will then forward to the joining
			node. This has an interaction with the (strict) source routes used
			by non-storing DODAGs which would be used by the 6LBR to reach the
			Join Assistant.
	There are some alternatives to having full end to end connectivity		There are some alternatives to having full end to end connectivity
	which are discussed in the security considerations section.		which are discussed in the security considerations section.
	The specific mechanism to enable end to end connectivity with the JCE		3.4.1. Security Considerations: alternatives to source routes
	are still open but will consist of one of:
	(1) IPIP tunnel between Join Assistant and JCE (least preferred)		This goes into security-considerations section
			A number of alternatives were considered for creating end to end
			connectivity between the joining node and the JCE, but were rejected.
			(1) IPIP tunnel between Join Assistant and JCE
	(2) using straight RPL routing: the Join Assistant sends a DAO		(2) using straight RPL routing: the Join Assistant sends a DAO
	(moderate preference)
	(3) using a separate RPL DODAG for join traffic (could be a non-		(3) using a separate RPL DODAG for join traffic
	storing, best practice)
	(4) establishing a specific multi-hop 6tisch track for join traffic		(4) establishing a specific multi-hop 6tisch track for join traffic
	for each Join Assistant (not always practical)		for each Join Assistant
	Of these mechanisms, the only one which does not require additional		3.4.1.1. IPIP tunnel
	state on the Join Assistant (which is also a constrained device) is
	(1) and (2). Mechanism (2) additionally requires no specific state
	on the Join Assistant. Mechanism (2), in a non-storing DODAG
	requires additional state on the DODAG root (6LBR) only; while
	mechanism (1) requires a similar amount of state on the JCE. For
	deployments where the JCE is part of the 6LBR, the amount of state is
	similar, but in any case, the 6LBR is assumed to be a non-constrained
	node.
	As long as the Join Assistant does not do any kind of stateful		This mechanism requires 40 bytes overhead per packet, and may require
	firewalling, the IPIP tunnel and the DAO (2) method can be done by		specific state to be created on the Join Assistant, or may open the
	the Join Assistant statelessly. Upward traffic from the Join Network		network up to a resource exhaustion by malicious join nodes.
	must be restricted to a 6tisch slotframe(s) to which join traffic is
	welcome, no tunnelling is necessary as the upwards routes are all in
	place. A destination address ACL on traffic from the Join Network
	restricts the Joining Nodes to sending traffic only to the address of
	the JCE. (If JCE and 6LBR are colocated, then this is the address in
	the ABRO, if they are not colocated, then this address needs to have
	been provisioning in the Join Assistant when it joined, or could be
	carried in a new RA option)
	When using option (2), networks that have storing mode DODAGs will		This mechanism was rejected on due to byte count, because it would
	consume routing resources on all intermediate nodes between the Join		require code only needed for join, and because doing it securely may
	Assistant and the DODAG root. This resource will be depleted without		require a per-tunnel state to be maintained on the join assistant.
	any authentication, and this threat is detailed below.
			3.4.1.2. join existing DODAG
			This mechanism is to just have the new node join the DODAG as a leaf
			node. The join assistant would issue a DAO for the new node. If a
			storing DODAG was used, this would directly cost state in all parent
			nodes of the Join Assistant, subjecting the lower-rank parts of the
			network to significant denial of service attacks.
			On a non-storing DODAG the situation is significantly better: no
			state is created by the presence of the leaf node except in the 6LBR,
			where available resources may be higher.
			This mechanism was rejected in favour of the loose source routed
			option as this the loose source routed option always works even for
			storing DODAGs, and is otherwise exactly equivalent in terms of
			network bandwidth cost.
			3.4.1.3. join a DODOAG for joining
			One option to deal with the problem of resource consumption in the
			storing DODAG case is to use a second DODAG.
			This mechanism was rejected as it consumes resources in all nodes for
			the second DODAG, and many implementations support on a single DODAG.
			While storing DODAGs have a lighter network impact than non-storing
			ones (due to the lack of source routes), the PCE can control how much
			network bandwidth can be wasted by malicious join nodes using the
			regular 6tisch mechanisms, and this can be tuned. A second DODAG
			would be a sunk cost with no tuning possible.
			3.4.1.4. create 6tisch track to form mesh-under
			This mechanism would use 6tisch tracks so that traffic from the JCE
			would be switched from 6LBR to join node. A track would be required
			to each join assistant. This is an optimized form of source routing.
			This mechanism was not rejected, rather it was observed that it may
			be applied to any mechanism that uses source routing, and is an
			optimization; it has a certain cost in the form of intermediary node
			state, but that this state is not created by a malicious join node,
			rather it is created by the PCE.
			3.5. Join node discovery mechanism
	Continuing to work backwards, in order the JCE reach out to provision		Continuing to work backwards, in order the JCE reach out to provision
	the Joining Node, it needs to know that the new node is present.		the Joining Node, it needs to know that the new node is present.
	This is done by taking advantage of the 6lowPAN Address Resolution		This is done by taking advantage of the 6lowPAN Address Resolution
	Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address		Option (ARO) (section 4.1 [RFC6775]). The ARO causes the new address
	to also be sent up to the 6LBR for duplicate detection using the DAR/		to also be sent up to the 6LBR for duplicate detection using the DAR/
	DAC mechanism. The 6LBR simply needs to tell the JCE about this		DAC mechanism. The 6LBR simply needs to tell the JCE about this. A
	using a protocol that needs to be defined, but could be either DAR or		new protocol may be required for the situation where the JCE, PCE and
	NS.		6LBR are not co-located; it may be that this protocol could be simply
			a DAR in some encapsulation. The details of this are currently out
			of scope for the architecture, as they affect interoperability
			between different vendors of JCE/6LBR/PCE rather than
			interoperability between the assistance/offload infrastructure, and
			the contrained nodes. Future work may specify this part.
	In addition to needing to know the joining devices address from the		In addition to needing to know the joining devices address from the
	DAR/NS, the JCE also needs to know the joining node' IDevID. If the		DAR/NS, the JCE also needs to know the joining node's IDevID. This
	serialNumber attribute of the IDevID is less than 64 bits, then it is		is to determine if the node should even get any attention. At this
	possible that it could be placed into the EUI-64 option of the ARO,		point, the IDevID can be forged, it will be authenticated during the
	or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs] EARO. The		setup of the 6top control protocol in the DTLS certificate exchange.
	JCE needs to know the joining node's serialNumber to know if this is		If the serialNumber attribute of the IDevID is less than 64 bits,
	device that it should even attempt to provision; and if so, it may		then it is possible that it could be placed into the EUI-64 option of
	need to retrieve an appropriate certificate chain (see		the ARO, or the OUI of the [I-D.thubert-6lo-rfc6775-update-reqs]
			EARO. The JCE needs to know the joining node's serialNumber to know
			if this is device that it should even attempt to provision; and if
			so, it may need to retrieve an appropriate certificate chain (see
	[I-D.richardson-6tisch-idevid-cert]) from the Factory in order for		[I-D.richardson-6tisch-idevid-cert]) from the Factory in order for
	the JCE to prove it is the legitimate owner of the joining node.		the JCE to prove it is the legitimate owner of the joining node.
	Neither 802.1AR nor [RFC5280] provide any structure for the		Neither 802.1AR nor [RFC5280] provide any structure for the
	serialNumber, except that they are positive integers of up-to 20		serialNumber, except that they are positive integers of up-to 20
	octets in size (numbers up to 2^160). This specification would		octets in size (numbers up to 2^160). This specification would
	require that the serialNumber encoded in the IDevID is the same as		require that the serialNumber encoded in the IDevID be the same as
	the EUI-64 used by the device. Some consideration needs to be given		the EUI-64 used by the device. Some consideration needs to be given
	as to whether there are privacy considerations to doing this: any		as to whether there are privacy considerations to doing this: any
	observer that can see the join traffic, can also see the source MAC		observer that can see the join traffic, can also see the source MAC
	address of the node as well.		address of the node as well.
	Prior to being able to announce itself in a NS, the joining node		Prior to being able to announce itself in a NS, the joining node
	needs to find the Join Network. This is done by listening to an		needs to find the Join Network. This is done by listening to an
	extended beacon which are broadcast in designated slotframes by Join		extended beacon which are broadcast in designated slotframes by Join
	Assistants. The Extended Beacon provides a way for the Joining Node		Assistants. The Extended Beacon provides a way for the Joining Node
	to synchronize itself to the overall timeslot schedule and provides		to synchronize itself to the overall timeslot schedule and provides
	an Aloha period in which the Joining Node can send a Router		an Aloha period in which the Joining Node can send a Router
	Soliticiation, and receive an appropriate Router Advertisement giving		Soliticiation, and receive an appropriate Router Advertisement giving
	the Joining Node a prefix and default route to which to send join		the Joining Node a prefix and default route to which to send join
	traffic.		traffic.
	It may be possible to eliminate a message exchange if space for a		It may be possible to eliminate a message exchange if space for a
	Router Advertisement can be found as part of the Join Network		Router Advertisement can be found as part of the Join Network
	Extended Beacon. This Enhanced Beacon would be distinct to the Join		Extended Beacon. This Enhanced Beacon would be distinct to the Join
	Network, and would be encrypted with the well-known Join Network key.		Network, and would be encrypted with the well-known Join Network key.
	3.1. prefixes to use for join traffic		3.5.1. prefixes to use for join traffic
	What prefix would the joining node for communication? There are		What prefix would the joining node for communication? There are
	three options:		three options:
	(1) just use link-local addresses (requires all traffic be tunneled)		(1) just use link-local addresses (this may require that some
			traffic between 6LBR and JCE be IPIP tunneled)
	(2) use a prefix specifically for join traffic (may be easier with a		(2) use a prefix specifically for join traffic (may be easier with a
	join-only DODAG)		join-only DODAG)
	(3) use the same prefix as the rest of the traffic (may require more		(3) use the same prefix as the rest of the traffic (may require more
	complex ACLs, and leaks information to attackers)		complex ACLs, and leaks information to attackers)
			The simplest method is to use the link-local addresses for the 6top
			connection, and the cost of an IPIP tunnel between the unconstrained
			6LBR and the JCE is not considered significant.
	4. security requirements		4. security requirements
	4.1. threat model		4.1. threat model
	There are three kinds of threats that a join process must deal with:		There are three kinds of threats that a join process must deal with:
	threats to the joining node, threats to the resources of the network,		threats to the joining node, threats to the resources of the network,
	and threats to other joining nodes.		and threats to other joining nodes.
	4.1.1. threats to the joining node		4.1.1. threats to the joining node
	skipping to change at page 18, line 22 ¶		skipping to change at page 20, line 12 ¶
	Wireless Personal Area Networks (6LoWPANs)", RFC 6775,		Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
	November 2012.		November 2012.
	[IEEE.802.1AR]		[IEEE.802.1AR]
	Institute of Electrical and Electronics Engineers, "Secure		Institute of Electrical and Electronics Engineers, "Secure
	Device Identity", IEEE 802.1AR, 2009,		Device Identity", IEEE 802.1AR, 2009,
	<http://www.ieee802.org/1/pages/802.1ar.html>.		<http://www.ieee802.org/1/pages/802.1ar.html>.
	[I-D.ietf-6tisch-coap]		[I-D.ietf-6tisch-coap]
	Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and		Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and
	Interaction using CoAP", draft-ietf-6tisch-coap-00 (work		Interaction using CoAP", draft-ietf-6tisch-coap-01 (work
	in progress), May 2014.		in progress), July 2014.
	[I-D.ietf-6tisch-6top-interface]		[I-D.ietf-6tisch-6top-interface]
	Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH		Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
	Operation Sublayer (6top) Interface", draft-ietf-6tisch-		Operation Sublayer (6top) Interface", draft-ietf-6tisch-
	6top-interface-00 (work in progress), March 2014.		6top-interface-01 (work in progress), July 2014.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., Watteyne, T., and R. Assimiti, "An		Thubert, P., Watteyne, T., and R. Assimiti, "An
	Architecture for IPv6 over the TSCH mode of IEEE		Architecture for IPv6 over the TSCH mode of IEEE
	802.15.4e", draft-ietf-6tisch-architecture-01 (work in		802.15.4e", draft-ietf-6tisch-architecture-01 (work in
	progress), February 2014.		progress), February 2014.
	[I-D.irtf-nmrg-autonomic-network-definitions]		[I-D.irtf-nmrg-autonomic-network-definitions]
	Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,		Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
	Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic		Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
	Networking - Definitions and Design Goals", draft-irtf-		Networking - Definitions and Design Goals", draft-irtf-
	nmrg-autonomic-network-definitions-00 (work in progress),		nmrg-autonomic-network-definitions-00 (work in progress),
	December 2013.		December 2013.
	[I-D.seitz-ace-problem-description]		[I-D.seitz-ace-problem-description]
	Seitz, L. and G. Selander, "Problem Description for		Seitz, L. and G. Selander, "Problem Description for
	Authorization in Constrained Environments", draft-seitz-		Authorization in Constrained Environments", draft-seitz-
	ace-problem-description-00 (work in progress), May 2014.		ace-problem-description-01 (work in progress), July 2014.
	[I-D.richardson-6tisch-idevid-cert]		[I-D.richardson-6tisch-idevid-cert]
	Richardson, M., "X509.v3 certificate extension for		Richardson, M., "X509.v3 certificate extension for
	authorization of device ownership", draft-richardson-		authorization of device ownership", draft-richardson-
	6tisch-idevid-cert-00 (work in progress), May 2014.		6tisch-idevid-cert-00 (work in progress), May 2014.
	[I-D.wang-6tisch-6top-sublayer]		[I-D.wang-6tisch-6top-sublayer]
	Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH		Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH
	Operation Sublayer (6top)", draft-wang-6tisch-6top-		Operation Sublayer (6top)", draft-wang-6tisch-6top-
	sublayer-00 (work in progress), February 2014.		sublayer-00 (work in progress), February 2014.
	[I-D.thubert-6lo-rfc6775-update-reqs]		[I-D.thubert-6lo-rfc6775-update-reqs]
	Thubert, P., "Requirements for an update to 6LoWPAN ND",		Thubert, P., "Requirements for an update to 6LoWPAN ND",
	draft-thubert-6lo-rfc6775-update-reqs-04 (work in		draft-thubert-6lo-rfc6775-update-reqs-01 (work in
	progress), August 2014.		progress), June 2014.
	19.2. Informative references		19.2. Informative references
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained		[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
	Application Protocol (CoAP)", RFC 7252, June 2014.		Application Protocol (CoAP)", RFC 7252, June 2014.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, January 2012.
	[I-D.thubert-6lowpan-backbone-router]		[I-D.thubert-6lowpan-backbone-router]
	Thubert, P., "LoWPAN Backbone Router", draft-thubert-		Thubert, P., "6LoWPAN Backbone Router", draft-thubert-
	6lowpan-backbone-router-00 (work in progress), March 2008.		6lowpan-backbone-router-03 (work in progress), February
			2013.
	[I-D.ietf-netconf-zerotouch]		[I-D.ietf-netconf-zerotouch]
	Watsen, K., Hanna, S., Clarke, J., and M. Abrahamsson,		Watsen, K., Hanna, S., Clarke, J., and M. Abrahamsson,
	"Zero Touch Provisioning for NETCONF Call Home		"Zero Touch Provisioning for NETCONF Call Home
	(ZeroTouch)", draft-ietf-netconf-zerotouch-00 (work in		(ZeroTouch)", draft-ietf-netconf-zerotouch-00 (work in
	progress), July 2014.		progress), July 2014.
	[I-D.kelsey-intarea-mesh-link-establishment]		[I-D.kelsey-intarea-mesh-link-establishment]
	Kelsey, R., "Mesh Link Establishment", draft-kelsey-		Kelsey, R., "Mesh Link Establishment", draft-kelsey-
	intarea-mesh-link-establishment-05 (work in progress),		intarea-mesh-link-establishment-05 (work in progress),
End of changes. 40 change blocks.
	126 lines changed or deleted		207 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/