Change:
An LLN with hostile nodes within it would not be protected against impersonation with the LLN by entry/exit filtering. <del> The RH3 header usage described here can be abused in equivalent ways (to disguise the origin of traffic and attack other nodes) with an IPv6-in-IPv6 header 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 an 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 RFC8138 to compress the IPv6-in- IPv6 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 to match a policy that applies to this network and is correctly processed by the leaves. </del> <ins> 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 RFC6554, 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 RFC6554, 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.  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. In short, a packet that crosses the border of the RPL domain MAY carry and RH3, and if so, that RH3 MUST be fully consumed. </ins> 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

Discussion:
…linfo-42 What about : 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 , 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 , 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. 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. In short, a packet that crosses the border of the RPL domain MAY carry and RH3, and if so, that RH3 MUST be fully consumed. From: Pascal Thubert (pthubert) Sent: jeudi 14 janvier 2021 14:12 To: Ines Robles Cc: Michael Richardson ; Pascal Thubert Subject: RE: Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-42: (with COMMENT) We must do that, for sure.

I’m reviewing the text that’s really hard to understand… From: Ines Robles Sent: jeudi 14 janvier 2021 13:53 To: Pascal Thubert (pthubert) Cc: Michael Richardson ; Pascal Thubert Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-roll-useofrplinfo-42: (with COMMENT) Thank you very much Pascal and Michael, I am available tomorrow after 3pm UTC. Ok, from the discussion: " Erik recommend referring to RFC 6554 S4.2 for how to handle RH3's if the node is also a RPL-aware router and say it MUST drop the packet if segments left is non-zero and it's not a RPL-aware router." maybe we should do just that, would it be ok? thanks, ines. Pascal Thubert (pthubert) wrote: I had a chat with Alvaro; he's waiting for the DISCUSS from Erik. Sadlt 43 does not address that DISCUSS. The offending text is " The RH3 header usage described here can be abused in equivalent ways (to disguise the origin of traffic and attack other nodes) with an IPv6-in-IPv6 header 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 an 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 [RFC8138] to compress the IPv6- in-IPv6 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 to match a policy that applies to this network and is correctly processed by the leaves. " This text is hard to read and makes little sense for the most part since the incoming packet from the Internet will be encapsulated so there will not be 2 RH2 even if the incoming packet has one. I'm on it, will propose a pull, but happy to discuss what we really want to say. My answer is to indicate that there is encaps and that the inner packet MUST be consumed as Erik says when processed by a Host. Since the root does not know whether the leaf is a host or an external router, there's little we can do beyond applying a policy. Thoughts? Call? Pascal