Draft: roll-useofrplinfo

Commentary: …  What about : < tThe 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 . < /t < tAlso , as indicated by section 2 of < xref target="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 . < /t < tIn short , a packet that crosses the border of the RPL domain MAY carry and RH3 , and if so , that RH3 MUST be fully consumed . < /tFrom :   ( pthubert ) Sent : jeudi 14 janvier 2021 14:12 To : Ines Robles < :   ;   < : RE :    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 < : jeudi 14 janvier 2021 13:53 To :   ( pthubert ) < :   ;   < : Re :    No Objection on draft - ietf - roll - useofrplinfo-42 : ( with COMMENT ) Thank you very much  and  , I am available tomorrow after 3 pm UTC . Ok , from the discussion : "  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 .   ( pthubert ) < : I had a chat with  ; he 's waiting for the DISCUSS from  . 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  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
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.
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.