The security considerations covered in [RFC 6553
] and [RFC 6554
] apply when the packets are in the RPL Domain.
The IPv6-in-IPv6 mechanism described in this document is much more limited than the general mechanism described in [RFC 2473
]. The willingness of each node in the LLN to decapsulate packets and forward them could be exploited by nodes to disguise the origin of an attack.
While a typical LLN may be a very poor origin for attack traffic (as the networks tend to be very slow, and the nodes often have very low duty cycles), given enough nodes, LLNs could still have a significant impact, particularly if the attack is targeting another LLN. Additionally, some uses of RPL involve large-backbone, ISP-scale equipment [ACP
], which may be equipped with multiple 100 Gb/s interfaces.
Blocking or careful filtering of IPv6-in-IPv6 traffic entering the LLN as described above will make sure that any attack that is mounted must originate from compromised nodes within the LLN. The use of network ingress filtering [BCP38
] on egress traffic at the RPL root will 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, network ingress filtering [BCP38
] involves a single prefix comparison and should be trivial to automatically configure.
There are some scenarios where IPv6-in-IPv6 traffic should be allowed to pass through the RPL root, such as the IPv6-in-IPv6 mediated communications between a new pledge and the Join Registrar/Coordinator (JRC) when using [BRSKI
] and [ZEROTOUCH-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 IPv6-in-IPv6 tunnels can only 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 to amplify return traffic. Such an attack could also be done without the use of IPv6-in-IPv6 headers, by using forged source addresses instead. If the attack requires bidirectional communication, then IPv6-in-IPv6 provides no advantages.
Whenever IPv6-in-IPv6 headers are being proposed, there is a concern about creating security issues. In the Security Considerations section of [RFC 2473
] (Section 9
), it was suggested that tunnel entry and exit points can be secured by securing the IPv6 path between them. This recommendation is not practical for RPL networks. [RFC 5406
] provides guidance on what on what additional details are needed in order to "Use IPsec". While the use of Encapsulating Security Payload (ESP) would prevent source address forgeries, in order to use it with [RFC 8138
], compression would have to occur before encryption, as the [RFC 8138
] compression is lossy. Once encrypted, there would be no further redundancy to compress. These are minor issues. The major issue is how to establish trust enough such that Internet Key Exchange Protocol Version 2 (IKEv2) could be used. This would require a system of certificates to be present in every single node, including any Internet nodes that might need to communicate with the LLN. Thus, using IPsec requires a global PKI in the general case.
More significantly, the use of IPsec tunnels to protect the IPv6-in-IPv6 headers would, in the general case, scale with the square of the number of nodes. This is a lot of resources for a constrained nodes on a constrained network. In the end, the IPsec tunnels would be providing only BCP38-like origin authentication! That is, IPsec provides a transitive guarantee to the tunnel exit point that the tunnel entry point did network ingress filtering [BCP38
] on traffic going in. Just doing origin filtering per BCP 38 at the entry and exit of the LLN provides a similar level of security without all the scaling and trust problems related to IPv6 tunnels as discussed in [RFC 2473
]. IPsec is not recommended.
An LLN with hostile nodes within it would not be protected against impersonation within the LLN by entry/exit filtering.
The RH3 header usage described here can be abused in equivalent ways. An external attacker may form a packet with an RH3 that is not fully consumed and encapsulate it to hide the RH3 from intermediate nodes and disguise the origin of traffic. As such, the attacker's RH3 header will not be seen by the network until it reaches the destination, which will decapsulate it. As indicated in Section 4.2
of RFC 6554
, RPL routers are responsible for ensuring that an SRH is only used between RPL routers. As such, if there is an RH3 that is not fully consumed in the encapsulated packet, the node that decapsulates it MUST
ensure that the outer packet was originated in the RPL domain and drop the packet otherwise.
Also, as indicated by Section 2
of RFC 6554
, RPL Border Routers "do not allow datagrams carrying an SRH header to enter or exit a RPL routing domain." This sentence must be understood as concerning non-fully-consumed packets. A consumed (inert) RH3 header could be present in a packet that flows from one LLN, crosses the Internet, and enters another LLN. 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.
In short, a packet that crosses the border of the RPL domain MAY
carry an RH3, and if so, that RH3 MUST
be fully consumed.
The RPI, if permitted to enter the LLN, could be used by an attacker to change the priority of a packet by selecting a different RPLInstanceID, 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 RPLInstanceID, but a change of RPLInstanceID would permit an attacker to bypass such filtering. Like the RH3, an RPI is to be inserted by the RPL root on traffic entering the LLN by first inserting an IPv6-in-IPv6 header. The attacker's RPI therefore will not be seen by the network. Upon reaching the destination node, the RPI has no further meaning and is just skipped; the presence of a second RPI will have no meaning to the end node as the packet has already been identified as being at its final destination.
For traffic leaving a RUL, if the RUL adds an uninitialized RPI (e.g., with a value of zero), then the 6LR as a RPL Border Router SHOULD
rewrite the RPI to indicate the selected Instance and set the flags. This is done in order to avoid the following scenarios: 1) The leaf is an external router that passes a packet that it did not generate and that carries an unrelated RPI, and 2) The leaf is an attacker or presents misconfiguration and tries to inject traffic in a protected Instance. Also, this applies to the case where the leaf is aware of the RPL Instance and passes a correct RPI; the 6LR needs a configuration that allows that leaf to inject in that instance.
The RH3 and RPIs could be abused by an attacker inside of the network to route packets in nonobvious ways, perhaps eluding observation. This usage appears consistent with a normal operation of [RFC 6997
] and cannot be restricted at all. This is a feature, not a bug.
] deals with many other threats to LLNs not directly related to the use of IPv6-in-IPv6 headers, and this document does not change that analysis.
Nodes within the LLN can use the IPv6-in-IPv6 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 be used to mount a DDOS attack upon nodes elsewhere in the Internet. See [DDOS-KREBS
] for an example of such attacks already seen in the real world.
If an attack comes from inside of LLN, it can be alleviated with SAVI (Source Address Validation Improvement) using [RFC 8505
] with [RFC 8928
]. The attacker will not be able to source traffic with an address that is not registered, and the registration process checks for topological correctness. Notice that there is Layer 2 authentication in most of the cases. If an attack comes from outside LLN, IPv6-in-IPv6 can be used to hide inner routing headers, but by construction, the RH3 can typically only address nodes within the LLN. That is, an RH3 with a CmprI less than 8 should be considered an attack (see Section 3
of RFC 6554
Nodes outside of the LLN will need to pass IPv6-in-IPv6 traffic through the RPL root to perform this attack. To counter, the RPL root SHOULD
either restrict ingress of IPv6-in-IPv6 packets (the simpler solution), or it SHOULD
walk the IP header extension chain until it can inspect the upper-layer payload as described in [RFC 7045
]. In particular, the RPL root SHOULD
do network ingress filtering [BCP38
] on the source addresses of all 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 the one described in [RFC 8929
]. In this case, the network ingress filtering [BCP38
] needs to take this into account, either by exchanging detailed routing information on each LLN or by moving the network ingress filtering [BCP38
] further towards the Internet, so that the details of the multiple LLNs do not matter.