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