< draft-ietf-roll-useofrplinfo-12.txt		draft-ietf-roll-useofrplinfo-13.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: September 14, 2017 P. Thubert		Expires: October 5, 2017 P. Thubert
	Cisco		Cisco
	March 13, 2017		April 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-12		draft-ietf-roll-useofrplinfo-13
	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 September 14, 2017.		This Internet-Draft will expire on October 5, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	skipping to change at page 33, line 8 ¶		skipping to change at page 33, line 8 ¶
	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		The IPIP mechanism described in this document is much more limited
	than the general mechanism described in [RFC2473]. The willingness		than the general mechanism described in [RFC2473]. The willingness
	of each node in the LLN to decapsulate traffic and forward it could		of each node in the LLN to decapsulate traffic and forward it could
	be exploited by nodes to disguise the origin of an attack.		be exploited by nodes to disguise the origin of an attack.
	Nodes outside of the LLN will need to pass IPIP traffic through the		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		RPL root in order to perform this attack. To counter the RPL root
	SHOULD either restrict ingress of IPIP packets (the simpler		SHOULD either restrict ingress of IPIP packets (the simpler
	solution), or it SHOULD do a deep packet inspection wherein it walks		solution), or it SHOULD do a deep packet inspection wherein it walks
	the IP header extension chain until it can inspect the upper-layer-		the IP header extension chain until it can inspect the upper-layer-
	payload as described in [RFC7045]. In particular, the RPL root		payload as described in [RFC7045]. In particular, the RPL root
	SHOULD do BCP38 ([RFC2827]) processing on the source addresses of all		SHOULD do BCP38 ([RFC2827]) processing on the source addresses of all
	IP headers that it examines in both directions.		IP headers that it examines in both directions.
			Note: there are some situations where a prefix will spread across
			multiple LLNs via mechanisms such as [I-D.ietf-6lo-backbone-router].
			In this case the BCP38 filtering needs to take this into account.
	Nodes with the LLN are able to use the IPIP mechanism to mount an		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 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. The mechanism can even be abused to make it appear that the
	attack is coming from outside the LLN, and unless countered, this		attack is coming from outside the LLN, and unless countered, this
	could also be to mount a Distributed Denial of Service attack upon		could be used to mount a Distributed Denial of Service attack upon
	nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of		nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of
	this.		such attacks already seen in the real world.
	While a typical LLN may be a very poor origin for attack traffic, as		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		the networks tend to very slow, and the nodes often have very low
	duty cycles, given enough of them, they could still have a		duty cycles, given enough of them, they could still have a
	significant impact, particularly on another LLN. Additionally, not		significant impact, particularly if the attack was on another LLN!
	all uses of RPL involve large backbone ISP scale equipment		Additionally, some uses of RPL involve large backbone ISP scale
	[I-D.ietf-anima-autonomic-control-plane].		equipment [I-D.ietf-anima-autonomic-control-plane], which may be
			equipped with multiple 100Gb/s interfaces.
	Blocking or careful filtering of IPIP traffic entering the LLN as		Blocking or careful filtering of IPIP traffic entering the LLN as
	described above will make sure that any attack that is mounted must		described above will make sure that any attack that is mounted must
	be originated from compromised nodes within the LLN. The use of		be originated from compromised nodes within the LLN. The use of
	BCP38 filtering at the RPL root on egress traffic will both alert the		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		operator to the existence of the attack, as well as drop the attack
	traffic. As the RPL network is typically numbered from a single		traffic. As the RPL network is typically numbered from a single
	prefix, which is itself assigned by RPL, BCP38 filtering involves a		prefix, which is itself assigned by RPL, BCP38 filtering involves a
	single prefix comparison and should be trivial to automatically		single prefix comparison and should be trivial to automatically
	configure.		configure.
	skipping to change at page 34, line 5 ¶		skipping to change at page 34, line 11 ¶
	between a new Pledge and the Join Coordinator when using		between a new Pledge and the Join Coordinator when using
	[I-D.ietf-anima-bootstrapping-keyinfra] and		[I-D.ietf-anima-bootstrapping-keyinfra] and
	[I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the		[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		RPL root to do careful filtering: it occurs only when the Join
	Coordinator is not co-located inside the RPL root.		Coordinator is not co-located inside the RPL root.
	With the above precautions, an attack using IPIP tunnels will be by a		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		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		could, of course, be done directly. An attack of this kind is
	meaningful only if the source addresses are either fake or if the		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		point is for (amplified) return traffic to be the attack. Such an
	also be done without the use of IPIP headers using forged source		attack, could also be done without the use of IPIP headers using
	addresses. If the attack requires bi-directional communication, then		forged source addresses. If the attack requires bi-directional
	IPIP provides no advantages.		communication, then IPIP provides no advantages.
	[RFC2473] suggests that tunnel entry and exit points can be secured,		[RFC2473] suggests that tunnel entry and exit points can be secured,
	via the "Use IPsec". This solution has all the problems that		via the "Use IPsec". This solution has all the problems that
	[RFC5406] goes into. In an LLN such a solution would degenerate into		[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		every node having a tunnel with every other node. It would provide a
	small amount of origin address authentication at a very high cost;		small amount of origin address authentication at a very high cost;
	doing BCP38 at every node (linking layer-3 addresses to layer-2		doing BCP38 at every node (linking layer-3 addresses to layer-2
	addresses, and to already present layer-2 cryptographic mechanisms)		addresses, and to already present layer-2 cryptographic mechanisms)
	would be cheaper should RPL be run in an environment where hostile		would be cheaper should RPL be run in an environment where hostile
	nodes are likely to be a part of the LLN.		nodes are likely to be a part of the LLN.
	skipping to change at page 35, line 32 ¶		skipping to change at page 35, line 38 ¶
	The authors would like to acknowledge the review, feedback, and		The authors would like to acknowledge the review, feedback, and
	comments of (alphabetical order): Robert Cragie, Simon Duquennoy,		comments of (alphabetical order): Robert Cragie, Simon Duquennoy,
	Cenk Guendogan, Rahul Jadhav, Peter van der Stok, Xavier Vilajosana		Cenk Guendogan, Rahul Jadhav, Peter van der Stok, Xavier Vilajosana
	and Thomas Watteyne.		and Thomas Watteyne.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[I-D.ietf-6man-rfc2460bis]		[I-D.ietf-6man-rfc2460bis]
	Deering, S. and R. Hinden, "Internet Protocol, Version 6		<>, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
	(IPv6) Specification", draft-ietf-6man-rfc2460bis-08 (work		Specification", draft-ietf-6man-rfc2460bis-09 (work in
	in progress), November 2016.		progress), March 2017.
	[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, December 1998.
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.
	[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in		[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
	IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,		IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
	December 1998, <http://www.rfc-editor.org/info/rfc2473>.		December 1998, <http://www.rfc-editor.org/info/rfc2473>.
	[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,		Address Spoofing", BCP 38, RFC 2827, May 2000.
	May 2000, <http://www.rfc-editor.org/info/rfc2827>.
	[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec		[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
	Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,		Version 2", BCP 146, RFC 5406, February 2009.
	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
	skipping to change at page 37, line 5 ¶		skipping to change at page 37, line 5 ¶
	<http://www.rfc-editor.org/info/rfc7416>.		<http://www.rfc-editor.org/info/rfc7416>.
	12.2. Informative References		12.2. Informative References
	[DDOS-KREBS]		[DDOS-KREBS]
	Goodin, D., "Record-breaking DDoS reportedly delivered by		Goodin, D., "Record-breaking DDoS reportedly delivered by
	>145k hacked cameras", September 2016,		>145k hacked cameras", September 2016,
	<http://arstechnica.com/security/2016/09/botnet-of-145k-		<http://arstechnica.com/security/2016/09/botnet-of-145k-
	cameras-reportedly-deliver-internets-biggest-ddos-ever/>.		cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
			[I-D.ietf-6lo-backbone-router]
			Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
			backbone-router-03 (work in progress), January 2017.
	[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-11 (work		of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work
	in progress), January 2017.		in progress), January 2017.
	[I-D.ietf-6tisch-dtsecurity-secure-join]		[I-D.ietf-6tisch-dtsecurity-secure-join]
	Richardson, M., "6tisch Secure Join protocol", draft-ietf-		Richardson, M., "6tisch Secure Join protocol", draft-ietf-
	6tisch-dtsecurity-secure-join-01 (work in progress),		6tisch-dtsecurity-secure-join-01 (work in progress),
	February 2017.		February 2017.
	[I-D.ietf-anima-autonomic-control-plane]		[I-D.ietf-anima-autonomic-control-plane]
	Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic		Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
	Control Plane", draft-ietf-anima-autonomic-control-		Control Plane", draft-ietf-anima-autonomic-control-
	plane-05 (work in progress), January 2017.		plane-06 (work in progress), March 2017.
	[I-D.ietf-anima-bootstrapping-keyinfra]		[I-D.ietf-anima-bootstrapping-keyinfra]
	Pritikin, M., Richardson, M., Behringer, M., Bjarnason,		Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
	S., and K. Watsen, "Bootstrapping Remote Secure Key		S., and K. Watsen, "Bootstrapping Remote Secure Key
	Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-		Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
	keyinfra-04 (work in progress), October 2016.		keyinfra-05 (work in progress), March 2017.
	[I-D.ietf-roll-dao-projection]		[I-D.ietf-roll-dao-projection]
	Thubert, P. and J. Pylakutty, "Root initiated routing		Thubert, P. and J. Pylakutty, "Root initiated routing
	state in RPL", draft-ietf-roll-dao-projection-01 (work in		state in RPL", draft-ietf-roll-dao-projection-01 (work in
	progress), March 2017.		progress), March 2017.
	[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.
End of changes. 17 change blocks.
	25 lines changed or deleted		31 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/