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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/