draft-ietf-roll-useofrplinfo-13.txt   draft-ietf-roll-useofrplinfo-14.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: October 5, 2017 P. Thubert Expires: October 7, 2017 P. Thubert
Cisco Cisco
April 3, 2017 April 5, 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-13 draft-ietf-roll-useofrplinfo-14
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 October 5, 2017. This Internet-Draft will expire on October 7, 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 4, line 18 skipping to change at page 4, line 18
RPL-node: It is device which implements RPL, thus we can say that the RPL-node: It is device which implements RPL, thus we can say that the
device is RPL-capable or RPL-aware. Please note that the device can device is RPL-capable or RPL-aware. Please note that the device can
be found inside the LLN or outside LLN. In this document a RPL-node be found inside the LLN or outside LLN. In this document a RPL-node
which is a leaf of a DODAG is called RPL-aware-leaf. which is a leaf of a DODAG is called RPL-aware-leaf.
RPL-not-capable: It is device which do not implement RPL, thus we can RPL-not-capable: It is device which do not implement RPL, thus we can
say that the device is not-RPL-aware. Please note that the device say that the device is not-RPL-aware. Please note that the device
can be found inside the LLN. In this document a not-RPL-node which can be found inside the LLN. In this document a not-RPL-node which
is a leaf of a DODAG is called not-RPL-aware-leaf. is a leaf of a DODAG is called not-RPL-aware-leaf.
pledge: a new device which seeks admission to a network. (from
[I-D.ietf-anima-bootstrapping-keyinfra])
Join Registrar and Coordinator (JRC): a device which brings new nodes
(pledges) into a network. (from
[I-D.ietf-anima-bootstrapping-keyinfra])
2.1. hop-by-hop IPv6-in-IPv6 headers 2.1. hop-by-hop IPv6-in-IPv6 headers
The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header
that originates from a node to an adjacent node, using the addresses that originates from a node to an adjacent node, using the addresses
(usually the GUA or ULA, but could use the link-local addresses) of (usually the GUA or ULA, but could use the link-local addresses) of
each node. If the packet must traverse multiple hops, then it must each node. If the packet must traverse multiple hops, then it must
be decapsulated at each hop, and then re-encapsulated again in a be decapsulated at each hop, and then re-encapsulated again in a
similar fashion. similar fashion.
3. Sample/reference topology 3. Sample/reference topology
skipping to change at page 33, line 4 skipping to change at page 33, line 4
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 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 packets and forward them 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 perform this attack. To counter the RPL root RPL root to perform this attack. To counter, the RPL root SHOULD
SHOULD either restrict ingress of IPIP packets (the simpler either restrict ingress of IPIP packets (the simpler solution), or it
solution), or it SHOULD do a deep packet inspection wherein it walks SHOULD do a deep packet inspection wherein it walks the IP header
the IP header extension chain until it can inspect the upper-layer- extension chain until it can inspect the upper-layer-payload as
payload as described in [RFC7045]. In particular, the RPL root described in [RFC7045]. In particular, the RPL root SHOULD do BCP38
SHOULD do BCP38 ([RFC2827]) processing on the source addresses of all ([RFC2827]) processing on the source addresses of all IP headers that
IP headers that it examines in both directions. it examines in both directions.
Note: there are some situations where a prefix will spread across Note: there are some situations where a prefix will spread across
multiple LLNs via mechanisms such as [I-D.ietf-6lo-backbone-router]. multiple LLNs via mechanisms such as described in
In this case the BCP38 filtering needs to take this into account. [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 can use the IPIP mechanism to mount an attack on
attack on another part of the LLN, while disguising the origin of the another part of the LLN, while disguising the origin of the attack.
attack. The mechanism can even be abused to make it appear that the The mechanism can even be abused to make it appear that the attack is
attack is coming from outside the LLN, and unless countered, this coming from outside the LLN, and unless countered, this could be used
could be used to mount a Distributed Denial of Service attack upon to mount a Distributed Denial Of Service attack upon nodes elsewhere
nodes elsewhere in the Internet. See [DDOS-KREBS] for an example of in the Internet. See [DDOS-KREBS] for an example of such attacks
such attacks already seen in the real world. 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 be very slow, and the nodes often have very low
duty cycles, given enough of them, they could still have a duty cycles) given enough nodes, they could still have a significant
significant impact, particularly if the attack was on another LLN! impact, particularly if the attack was on another LLN! Additionally,
Additionally, some uses of RPL involve large backbone ISP scale some uses of RPL involve large backbone ISP scale equipment
equipment [I-D.ietf-anima-autonomic-control-plane], which may be [I-D.ietf-anima-autonomic-control-plane], which may be equipped with
equipped with multiple 100Gb/s interfaces. 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 originate compromised nodes within the LLN. The use of BCP38
BCP38 filtering at the RPL root on egress traffic will both alert the 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.
There are some scenarios where IPIP traffic SHOULD be allowed to pass There are some scenarios where IPIP traffic SHOULD be allowed to pass
through the RPL root, such as the IPIP mediated communications through the RPL root, such as the IPIP mediated communications
between a new Pledge and the Join Coordinator when using between a new Pledge and the Join Registrar/Coordinator (JRC) when
[I-D.ietf-anima-bootstrapping-keyinfra] and using [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 (amplified) return traffic to be the attack. Such an point is to amplify return traffic. Such an attack, could also be
attack, could also be done without the use of IPIP headers using done without the use of IPIP headers using forged source addresses.
forged source addresses. If the attack requires bi-directional If the attack requires bi-directional communication, then IPIP
communication, then IPIP provides no advantages. 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.
The RH3 header usage described here can be abused in equivalent ways 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 to the IPIP header. In non-storing networks where an RH3 may be
acted upon, packets arriving into the LLN will be encapsulated with 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 an IPIP header to add the needed RH3 header. As such, the attacker's
attacker's RH3 header will not be seen by the network until it RH3 header will not be seen by the network until it reaches the end
reaches the end host, which will decapsulate it. An end-host SHOULD host, which will decapsulate it. An end-host SHOULD be suspicious
be suspicious about a RH3 header which has additional hops which have about a RH3 header which has additional hops which have not yet been
not yet been processed, and SHOULD ignore such a second RH3 header. processed, and SHOULD ignore such a second RH3 header.
In addition, the LLN will likely use [I-D.ietf-roll-routing-dispatch] 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 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 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 packet if the RH3 header has not been completely consumed. A
consumed (inert) RH3 header could be present in a packet that flows consumed (inert) RH3 header could be present in a packet that flows
from one LLN, crosses the Internet, and enters another LLN. As per from one LLN, crosses the Internet, and enters another LLN. As per
the discussion in this document, such headers do not need to be the discussion in this document, such headers do not need to be
removed. However, there is no case described in this document where removed. However, there is no case described in this document where
an RH3 is inserted in a non-storing network on traffic that is an RH3 is inserted in a non-storing network on traffic that is
 End of changes. 14 change blocks. 
41 lines changed or deleted 49 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/