< draft-ietf-roll-useofrplinfo-10.txt		draft-ietf-roll-useofrplinfo-11.txt >
	ROLL Working Group M. Robles		ROLL Working Group M. Robles
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 6550 (if approved) M. Richardson		Updates: 6550 (if approved) M. Richardson
	Intended status: Standards Track SSW		Intended status: Standards Track SSW
	Expires: June 15, 2017 P. Thubert		Expires: September 4, 2017 P. Thubert
	Cisco		Cisco
	December 12, 2016		March 3, 2017
	When to use RFC 6553, 6554 and IPv6-in-IPv6		When to use RFC 6553, 6554 and IPv6-in-IPv6
	draft-ietf-roll-useofrplinfo-10		draft-ietf-roll-useofrplinfo-11
	Abstract		Abstract
	This document looks at different data flows through LLN (Low-Power		This document looks at different data flows through LLN (Low-Power
	and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power		and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
	and Lossy Networks) is used to establish routing. The document		and Lossy Networks) is used to establish routing. The document
	enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6		enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
	encapsulation is required. This analysis provides the basis on which		encapsulation is required. This analysis provides the basis on which
	to design efficient compression of these headers.		to design efficient compression of these headers.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	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 June 15, 2017.		This Internet-Draft will expire on September 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 2, line 50 ¶		skipping to change at page 2, line 50 ¶
	6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 28		6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 28
	6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 29		6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 29
	6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-		6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
	leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 30		leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 30
	7. Observations about the cases . . . . . . . . . . . . . . . . 31		7. Observations about the cases . . . . . . . . . . . . . . . . 31
	7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 31		7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 31
	7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 32		7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 32
	8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 32		8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 32
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 33		10. Security Considerations . . . . . . . . . . . . . . . . . . . 33
	11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33		11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 33		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
	12.1. Normative References . . . . . . . . . . . . . . . . . . 33		12.1. Normative References . . . . . . . . . . . . . . . . . . 35
	12.2. Informative References . . . . . . . . . . . . . . . . . 34		12.2. Informative References . . . . . . . . . . . . . . . . . 36
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
	1. Introduction		1. Introduction
	RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)		RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
	[RFC6550] is a routing protocol for constrained networks. RFC 6553		[RFC6550] is a routing protocol for constrained networks. RFC 6553
	[RFC6553] defines the "RPL option" (RPI), carried within the IPv6		[RFC6553] defines the "RPL option" (RPI), carried within the IPv6
	Hop-by-Hop header to quickly identify inconsistencies (loops) in the		Hop-by-Hop header to quickly identify inconsistencies (loops) in the
	routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route		routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route
	Header" (RH3), an IPv6 Extension Header to deliver datagrams within a		Header" (RH3), an IPv6 Extension Header to deliver datagrams within a
	RPL routing domain, particularly in non-storing mode.		RPL routing domain, particularly in non-storing mode.
	skipping to change at page 33, line 10 ¶		skipping to change at page 33, line 10 ¶
	9. IANA Considerations		9. IANA Considerations
	There are no IANA considerations related to this document.		There are no IANA considerations related to this document.
	10. Security Considerations		10. Security Considerations
	The security considerations covering of [RFC6553] and [RFC6554] apply		The security considerations covering of [RFC6553] and [RFC6554] apply
	when the packets get into RPL Domain.		when the packets get into RPL Domain.
			The IPIP mechanism described in this document is much more limited
			than the general mechanism described in [RFC2473]. The willingness
			of each node in the LLN to decapsulate traffic and forward it could
			be exploited by nodes to disguise the origin of an attack.
			Nodes outside of the LLN will need to pass IPIP traffic through the
			RPL root in order to exploit perform this attack, so the RPL root
			SHOULD either restrict ingress of IPIP packets (the simpler
			solution), or it SHOULD do a deep packet inspection wherein it walks
			the IP header extension chain until it can inspect the upper-layer-
			payload as described in [RFC7045]. In particular, the RPL root
			SHOULD do BCP38 ([RFC2827]) processing on the source addresses of all
			IP headers that it examines in both directions.
			Nodes with the LLN are able to use the IPIP mechanism to mount an
			attack on another part of the LLN, while disguising the origin of the
			attack. The mechanism can even be abused to make it appear that the
			attack is coming from outside the LLN, and unless countered, this
			could also be to mount a Distributed Denial of Service attack upon
			nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of
			this.
			While a typical LLN may be a very poor origin for attack traffic, as
			the networks tend to very slow, and the nodes often have very low
			duty cycles, given enough of them, they could still have a
			significant impact, particularly on another LLN. Additionally, not
			all uses of RPL involve large backbone ISP scale equipment
			[I-D.ietf-anima-autonomic-control-plane].
			Blocking or careful filtering of IPIP traffic entering the LLN as
			described above will make sure that any attack that is mounted must
			be originated from compromised nodes within the LLN. The use of
			BCP38 filtering at the RPL root on egress traffic will both alert the
			operator to the existence of the attack, as well as drop the attack
			traffic. As the RPL network is typically numbered from a single
			prefix, which is itself assigned by RPL, BCP38 filtering involves a
			single prefix comparison and should be trivial to automatically
			configure.
			There are some scenarios where IPIP traffic SHOULD be allowed to pass
			through the RPL root, such as the IPIP mediated communications
			between a new Pledge and the Join Coordinator when using
			[I-D.ietf-anima-bootstrapping-keyinfra] and
			[I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the
			RPL root to do careful filtering: it occurs only when the Join
			Coordinator is not co-located inside the RPL root.
			With the above precautions, an attack using IPIP tunnels will be by a
			node within the LLN on another node within the LLN. Such an attack
			could, of course, be done directly. An attack of this kind is
			meaningful only if the source addresses are either fake or if the
			point is for return traffic to be the attack. Such an attack, could
			also be done without the use of IPIP headers using forged source
			addresses. If the attack requires bi-directional communication, then
			IPIP provides no advantages.
			[RFC2473] suggests that tunnel entry and exit points can be secured,
			via the "Use IPsec". This solution has all the problems that
			[RFC5406] goes into. In an LLN such a solution would degenerate into
			every node having a tunnel with every other node. It would provide a
			small amount of origin address authentication at a very high cost;
			doing BCP38 at every node (linking layer-3 addresses to layer-2
			addresses, and to already present layer-2 cryptographic mechanisms)
			would be cheaper should RPL be run in an environment where hostile
			nodes are likely to be a part of the LLN.
			The RH3 header usage described here can be abused in equivalent ways
			to the IPIP header. In non-storing networks where an RH3 may be
			acted upon, packets arriving into the LLN will be encapsulated with
			an IPIP header in order to add the needed RH3 header. As such, the
			attacker's RH3 header will not be seen by the network until it
			reaches the end host, which will decapsulate it. An end-host SHOULD
			be suspicious about a RH3 header which has additional hops which have
			not yet been processed, and SHOULD ignore such a second RH3 header.
			In addition, the LLN will likely use [I-D.ietf-roll-routing-dispatch]
			to compress the IPIP and RH3 headers. As such, the compressor at the
			RPL-root will see the second RH3 header and MAY choose to discard the
			packet if the RH3 header has not been completely consumed. A
			consumed (inert) RH3 header could be present in a packet that flows
			from one LLN, crosses the Internet, and enters another LLN. As per
			the discussion in this document, such headers do not need to be
			removed. However, there is no case described in this document where
			an RH3 is inserted in a non-storing network on traffic that is
			leaving the LLN, but this document SHOULD NOT preclude such a future
			innovation. It should just be noted that an incoming RH3 must be
			fully consumed, or very carefully inspected.
			The RPI header, if permitted to enter the LLN, could be used by an
			attacker to change the priority of a packet by selecting a different
			RPL instanceID, perhaps one with a higher energy cost, for instance.
			It could also be that not all nodes are reachable in an LLN using the
			default instanceID, but a change of instanceID would permit an
			attacker to bypass such filtering. Like the RH3, an RPI header is to
			be inserted by the RPL root on traffic entering the LLN by first
			inserting an IPIP header. The attacker's RPI header therefore will
			not be seen by the network. Upon reaching the destination node the
			RPI header has no further meaning and is just skipped; the presence
			of a second RPI header will have no meaning to the end node as the
			packet has already been identified as being at it's final
			destination.
			The RH3 and RPI headers could be abused by an attacker inside of the
			network to route packets on non-obvious ways, perhaps eluding
			observation. This usage is in fact part of [RFC6997] and can not be
			restricted at all. This is a feature, not a bug.
			[RFC7416] deals with many other threats to LLNs not directly related
			to the use of IPIP headers, and this document does not change that
			analysis.
	11. Acknowledgments		11. Acknowledgments
	This work is partially funded by the FP7 Marie Curie Initial Training		This work is partially funded by the FP7 Marie Curie Initial Training
	Network (ITN) METRICS project (grant agreement No. 607728).		Network (ITN) METRICS project (grant agreement No. 607728).
	The authors would like to acknowledge the review, feedback, and		The authors would like to acknowledge the review, feedback, and
	comments of Robert Cragie, Simon Duquennoy, Cenk Guendogan, Peter van		comments of Robert Cragie, Simon Duquennoy, Cenk Guendogan, Peter van
	der Stok, Xavier Vilajosana and Thomas Watteyne.		der Stok, Xavier Vilajosana and Thomas Watteyne.
	12. References		12. References
	skipping to change at page 33, line 37 ¶		skipping to change at page 36, line 5 ¶
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.		December 1998, <http://www.rfc-editor.org/info/rfc2460>.
			[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
			IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
			December 1998, <http://www.rfc-editor.org/info/rfc2473>.
			[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
			Defeating Denial of Service Attacks which employ IP Source
			Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
			May 2000, <http://www.rfc-editor.org/info/rfc2827>.
			[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
			Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,
			February 2009, <http://www.rfc-editor.org/info/rfc5406>.
	[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,		[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
	Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,		Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
	JP., and R. Alexander, "RPL: IPv6 Routing Protocol for		JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
	Low-Power and Lossy Networks", RFC 6550,		Low-Power and Lossy Networks", RFC 6550,
	DOI 10.17487/RFC6550, March 2012,		DOI 10.17487/RFC6550, March 2012,
	<http://www.rfc-editor.org/info/rfc6550>.		<http://www.rfc-editor.org/info/rfc6550>.
	[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-		[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
	Power and Lossy Networks (RPL) Option for Carrying RPL		Power and Lossy Networks (RPL) Option for Carrying RPL
	Information in Data-Plane Datagrams", RFC 6553,		Information in Data-Plane Datagrams", RFC 6553,
	DOI 10.17487/RFC6553, March 2012,		DOI 10.17487/RFC6553, March 2012,
	<http://www.rfc-editor.org/info/rfc6553>.		<http://www.rfc-editor.org/info/rfc6553>.
	[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6		[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
	Routing Header for Source Routes with the Routing Protocol		Routing Header for Source Routes with the Routing Protocol
	for Low-Power and Lossy Networks (RPL)", RFC 6554,		for Low-Power and Lossy Networks (RPL)", RFC 6554,
	DOI 10.17487/RFC6554, March 2012,		DOI 10.17487/RFC6554, March 2012,
	<http://www.rfc-editor.org/info/rfc6554>.		<http://www.rfc-editor.org/info/rfc6554>.
			[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
			of IPv6 Extension Headers", RFC 7045,
			DOI 10.17487/RFC7045, December 2013,
			<http://www.rfc-editor.org/info/rfc7045>.
			[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
			and M. Richardson, Ed., "A Security Threat Analysis for
			the Routing Protocol for Low-Power and Lossy Networks
			(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
			<http://www.rfc-editor.org/info/rfc7416>.
	12.2. Informative References		12.2. Informative References
			[DDOS-KREBS]
			Goodin, D., "Record-breaking DDoS reportedly delivered by
			>145k hacked cameras", September 2016,
			<http://arstechnica.com/security/2016/09/botnet-of-145k-
			cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
	[I-D.ietf-6tisch-architecture]		[I-D.ietf-6tisch-architecture]
	Thubert, P., "An Architecture for IPv6 over the TSCH mode		Thubert, P., "An Architecture for IPv6 over the TSCH mode
	of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work
	in progress), June 2016.		in progress), January 2017.
			[I-D.ietf-6tisch-dtsecurity-secure-join]
			Richardson, M., "6tisch Secure Join protocol", draft-ietf-
			6tisch-dtsecurity-secure-join-01 (work in progress),
			February 2017.
			[I-D.ietf-anima-autonomic-control-plane]
			Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
			Control Plane", draft-ietf-anima-autonomic-control-
			plane-05 (work in progress), January 2017.
			[I-D.ietf-anima-bootstrapping-keyinfra]
			Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
			S., and K. Watsen, "Bootstrapping Remote Secure Key
			Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
			keyinfra-04 (work in progress), October 2016.
	[I-D.ietf-roll-routing-dispatch]		[I-D.ietf-roll-routing-dispatch]
	Thubert, P., Bormann, C., Toutain, L., and R. Cragie,		Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
	"6LoWPAN Routing Header", draft-ietf-roll-routing-		"6LoWPAN Routing Header", draft-ietf-roll-routing-
	dispatch-05 (work in progress), October 2016.		dispatch-05 (work in progress), October 2016.
	[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet		[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
	Control Message Protocol (ICMPv6) for the Internet		Control Message Protocol (ICMPv6) for the Internet
	Protocol Version 6 (IPv6) Specification", RFC 4443,		Protocol Version 6 (IPv6) Specification", RFC 4443,
	DOI 10.17487/RFC4443, March 2006,		DOI 10.17487/RFC4443, March 2006,
End of changes. 11 change blocks.
	12 lines changed or deleted		171 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/