Subject: Secdir last call review of draft-ietf-roll-useofrplinfo-25

From: Daniel Migault via Datatracker <[email-masked]>
Date: Wed, 10 Apr 2019 12:01:36 -0700

Reviewer: Daniel Migault
Review result: Ready

Hi,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

The summary of the review is READY

nits:

ROLL Working Group                                             M. Robles
Internet-Draft                                                     Aalto
Updates: 6553, 6550, 8138 (if approved)                    M. Richardson
Intended status: Standards Track                                     SSW
Expires: September 12, 2019                                   P. Thubert
                                                                   Cisco
                                                          March 11, 2019

Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6
                  encapsulation in the RPL Data Plane
                    draft-ietf-roll-useofrplinfo-25

Abstract

   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) is used to establish routing.  The document
   enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554
   (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
   required in data plane.  This analysis provides the basis on which to
   design efficient compression of these headers.
"""
s/on which//
s/.  /. /
"""
   This document updates
   RFC 6553 adding a change to the RPL Option Type.  Additionally, this
   document updates RFC 6550 to indicate about this change and updates
   RFC8138 as well to consider the new Option Type when RPL Option is
   decompressed.

1.  Introduction

   RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
   [RFC6550] is a routing protocol for constrained networks.  RFC 6553
   [RFC6553] defines the "RPL option" (RPI), carried within the IPv6
   Hop-by-Hop header to quickly identify inconsistencies (loops) in the
   routing topology.  RFC 6554 [RFC6554] defines the "RPL Source Route
   Header" (RH3), an IPv6 Extension Header to deliver datagrams within a

<mglt>
There is certainly a reason for the RH3 spelling, but from 6554 it seems
to me that the abbreviation of Source Routing Header is SRH. 
</mglt>

   RPL routing domain, particularly in non-storing mode.

<mglt>
For my personal knowledge, I do not understand why this is specific to
non-storing mode. Is the reason that in non-storing modes nodes S steer
datagram D via the root node R. The IPv6 packet (S,D) is tunneled from S
to R and then from R to D. The first tunnel from S to R does not need
SRH as nodes are able to steer this to the root (upward routing), while
downward routing needs SRH extension.

In a storing mode *regular* routing tables are able to steer the traffic
from S, to D. There is no need of tunnel and SRH extension. 

Am I correct, or I am missing something? I apology in advance for the
noise. 
</mglt>

3.  Updates to RFC6553, RFC6550 and RFC 8138

3.1.  Updates to RFC 6553

   This modification is required to be able to send, for example, IPv6
   packets from a RPL-aware-leaf to a not-RPL-aware node through
   Internet (see Section 6.2.1), without requiring IPv6-in-IPv6
   encapsulation.

   [RFC6553] states as shown below, that in the Option Type field of the
   RPL Option header, the two high order bits must be set to '01' and
   the third bit is equal to '1'.  The first two bits indicate that the
   IPv6 node must discard the packet if it doesn't recognize the option
   type, and the third bit indicates that the Option Data may change in
   route.  The remaining bits serve as the option type.

Robles, et al.         Expires September 12, 2019               [Page 5]
Internet-Draft               RPL-data-plane                   March 2019

          Hex Value     Binary Value
                        act  chg  rest     Description        Reference
          ---------     ---  ---  -------  -----------------  ----------
            0x63         01    1   00011   RPL Option         [RFC6553]

                   Figure 1: Option Type in RPL Option.

   Recent changes in [RFC8200] (section 4, page 8), states: "it is now
   expected that nodes along a packet's delivery path only examine and
   process the Hop-by-Hop Options header if explicitly configured to do
   so".  Processing of the Hop-by-Hop Options header (by IPv6
   intermediate nodes) is now optional, but if they are configured to
   process the header, and if such nodes encounter an option with the
   first two bits set to 01, they will drop the packet (if they conform
   to [RFC8200]).  Host systems should do the same, irrespective of the
   configuration.

   Based on that, if an IPv6 (intermediate) node (RPL-not-capable)
   receives a packet with an RPL Option, it should ignore the HBH RPL
   option (skip over this option and continue processing the header).
   This is relevant, as it was mentioned previously, in the case that
   there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1).

<mglt>
I might miss something, but it seems to me that 2460 would end up in the
discard of packets with the RPL Option. 8200 introduces some
instability. Typically, packets may reach their destination depending on
the configuration of the intermediary nodes. In both cases communication
between RPL-aware and not-RPL-aware nodes needs to relax the status of
the RPL Option. It seems independent to the update of 2460.    
</mglt>

   Thus, this document updates the Option Type field to: the two high
   order bits MUST be set to '00' and the third bit is equal to '1'.
   The first two bits indicate that the IPv6 node MUST skip over this
   option and continue processing the header ([RFC8200] Section 4.2) if
   it doesn't recognize the option type, and the third bit continues to
   be set to indicate that the Option Data may change en route.  The
   remaining bits serve as the option type and remain as 0x3.  This
   ensures that a packet that leaves the RPL domain of an LLN (or that
   leaves the LLN entirely) will not be discarded when it contains the
   [RFC6553] RPL Hop-by-Hop option known as RPI.

   This is a significant update to [RFC6553].  [RFCXXXX] represents this
   document.

          Hex Value     Binary Value
                        act  chg  rest     Description        Reference
          ---------     ---  ---  -------  -----------------  ----------
            0x23         00    1   00011   RPL Option         [RFCXXXX]

               Figure 2: Revised Option Type in RPL Option.

5.  Use cases

   NOTE: There is some possible security risk when the RPI information
   is released to the Internet.  At this point this is a theoretical
   situation; no clear attack has been described.  At worst, it is clear
   that the RPI option would waste some network bandwidth when it
   escapes.  This is traded off against the savings in the LLN by not
   having to encapsulate the packet in order to remove the artifact.

<mglt>
I believe that worst means minimal here. One of the risk is at least
marking the packet as originating to/from a LLN. It may reveal the type
of the information carried by the packet in addition to the information
contained in the RPI. Possible information leaked may be related to the
topology of the LLN, but I am not familiar enough to define clearly how
this could be exploited. The information may also reveals information
about the stability of the LLN by observing the rate. IF that is correct
this could eventually provide indication an attack is effective or not.    

My understanding is that with 63 the packet is dropped after the first
non aware router, while this is not the case with 23.

Now that I have been through the security consideration section, 
I believe a sinple reference to the security consideration woudl be
sufficient. 
</mglt>

11.  Security Considerations

   The security considerations covered in [RFC6553] and [RFC6554] 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 [RFC2473].  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, they could still have a significant
   impact, particularly if the attack was on another LLN! 
<mglt>
maybe it might be clearer - at least to me, but I am not English native.
s/was on another LLN!/is targeting another LLN!/   
</mglt>

Additionally,
   some uses of RPL involve large backbone ISP scale equipment
   [I-D.ietf-anima-autonomic-control-plane], which may be equipped with
   multiple 100Gb/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
   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
   traffic.  As the RPL network is typically numbered from a single
   prefix, which is itself assigned by RPL, BCP38 filtering 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 [I-D.ietf-anima-bootstrapping-keyinfra]
   and [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
   Coordinator is not co-located inside the RPL root.

Robles, et al.         Expires September 12, 2019              [Page 45]
Internet-Draft               RPL-data-plane                   March 2019

   With the above precautions, an attack using IPv6-in-IPv6 tunnels will
   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 using forged source
   addresses.  If the attack requires bi-directional communication, then
   IPv6-in-IPv6 provides no advantages.

   [RFC2473] suggests that tunnel entry and exit points can be secured,
   via the "Use IPsec".  The suggested solution has all the problems
   that [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 small amount of origin address authentication at a very
   high cost; doing BCP38 at every node (linking layer-3 addresses to
   layer-2 addresses, and to already present layer-2 cryptographic
   mechanisms) would be cheaper should RPL be run in an environment
   where hostile nodes are likely to be a part of the LLN.

<mglt>
My understanding is that IPsec SA will be needed between each parent -
children and that a hop-by-hop decapsulation/encapsulation is happening.
If that is correct, we may avoid the situation where each node deals
with 2 * n *(n-1) SA. However without any transit devices IPsec provides
no obvious advantages over L2 security. It might be god to recommend
that one or the other layer implements security.     
In addition, I am also wondering if the use of IPsec would not be
recommended as an alternative when LLN are involving communication over
the Internet. 
<mglt>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Apr 2019 19:31:13 -0400

Thank you for the review Daniel.
I'm unclear if there are any changes you want, given that you've given it a
"ready"
Some replies/clarifications to your comments.

    > <mglt> There is certainly a reason for the RH3 spelling, but from 6554
    > it seems to me that the abbreviation of Source Routing Header is SRH.
    > </mglt>

It's SRH type 3.  The use of "RHx" is common in many documents, including
6554, so it would be wrong for us to change that, I think.

    > <mglt> For my personal knowledge, I do not understand why this is
    > specific to non-storing mode. Is the reason that in non-storing modes
    > nodes S steer datagram D via the root node R. The IPv6 packet (S,D) is
    > tunneled from S to R and then from R to D. The first tunnel from S to R
    > does not need SRH as nodes are able to steer this to the root (upward
    > routing), while downward routing needs SRH extension.

    > In a storing mode *regular* routing tables are able to steer the
    > traffic from S, to D. There is no need of tunnel and SRH extension.

    > noise.  </mglt>

Yes, that's correct.

    > <mglt> I might miss something, but it seems to me that 2460 would end
    > up in the discard of packets with the RPL Option. 8200 introduces some
    > instability. Typically, packets may reach their destination depending
    > on the configuration of the intermediary nodes. In both cases
    > communication between RPL-aware and not-RPL-aware nodes needs to relax
    > the status of the RPL Option. It seems independent to the update of
    > 2460.  </mglt>

2460 says that you have to examine all options, and discard if you do not
understand. 8200 says that you examine options you are configured to examine.
8200 gives us additional options and removes the need for some IPIP tunnels,
as we do not need to remove the option.

    > that the RPI option would waste some network bandwidth when it escapes.
    > This is traded off against the savings in the LLN by not having to
    > encapsulate the packet in order to remove the artifact.

    > <mglt> I believe that worst means minimal here. One of the risk is at
    > least marking the packet as originating to/from a LLN. It may reveal
    > the type of the information carried by the packet in addition to the
    > information contained in the RPI. Possible information leaked may be
    > related to the topology of the LLN, but I am not familiar enough to
    > define clearly how this could be exploited. The information may also
    > reveals information about the stability of the LLN by observing the
    > rate. IF that is correct this could eventually provide indication an
    > attack is effective or not.

    > non aware router, while this is not the case with 23.

Correct.  We picked 63 back in the day, so that packets that "escaped" would
never reveal anything.  But that was just too restrictive, and basically many
assumed that they could just add/remove extension headers whenever they wanted.

    > Now that I have been through the security consideration section, I
    > believe a sinple reference to the security consideration woudl be
    > sufficient.  </mglt>

I personally do not like writing text in SC that is new, I prefer to refer
back to normative text in the Security Considerations, because non-security
people do not read Security Considerations.

    > via the "Use IPsec".  The suggested solution has all the problems that
    > [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
    > small amount of origin address authentication at a very high cost;
    > doing BCP38 at every node (linking layer-3 addresses to layer-2
    > addresses, and to already present layer-2 cryptographic mechanisms)
    > would be cheaper should RPL be run in an environment where hostile
    > nodes are likely to be a part of the LLN.

    > <mglt> My understanding is that IPsec SA will be needed between each
    > parent - children and that a hop-by-hop decapsulation/encapsulation is
    > happening.  If that is correct, we may avoid the situation where each
    > node deals with 2 * n *(n-1) SA. However without any transit devices
    > IPsec provides no obvious advantages over L2 security. It might be god
    > to recommend that one or the other layer implements security.  In
    > addition, I am also wondering if the use of IPsec would not be
    > the Internet.  <mglt>

A recommendation for End to End IPsec or End to End OSCORE/EDHOC or End to
End DTLS for application data is certainly reasonably, but seems out of scope
for this document.

There are cases where we insert IPIP headers between nodes which are not
parent-child.  For instance, from root to leaf in the non-storing downward
direction (because we add RH3).  If we were to "Use IPsec", then we'd need
more tunnels.

In the cases where an RPL-aware 6LR adds an RPI header (in storing mode),
for an RPL-unaware-leaf, and then sends it to some other leaf, we'd need an
IPsec tunnel from two random nodes in order to secure the IPIP.
So while we don't need 2*n*(n-1) SAs in every case, that is the worst case
scenario.
(btw: I think that there are some non-constrained, non-LLN uses of RPL where
that actually might be worth doing)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Daniel Migault <[email-masked]>
Date: Thu, 11 Apr 2019 01:11:53 +0000

Thanks for the responses. I am not requesting any changes. My comments mostly reflected some personal interests/questions. I found pretty much what I needed in the text and let you decide if my comments may lead to some changes in the text. In any case that seems nits and I find the document ready. 
Yours, 
Daniel

-----Original Message-----
From: Michael Richardson <[email-masked]> 
Sent: Wednesday, April 10, 2019 7:31 PM
To: Daniel Migault <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Secdir last call review of draft-ietf-roll-useofrplinfo-25

Thank you for the review Daniel.
I'm unclear if there are any changes you want, given that you've given it a "ready"
Some replies/clarifications to your comments.

    > it seems to me that the abbreviation of Source Routing Header is SRH.

It's SRH type 3.  The use of "RHx" is common in many documents, including 6554, so it would be wrong for us to change that, I think.

Yes, that's correct.

    > the status of the RPL Option. It seems independent to the update of

2460 says that you have to examine all options, and discard if you do not understand. 8200 says that you examine options you are configured to examine.
8200 gives us additional options and removes the need for some IPIP tunnels, as we do not need to remove the option.

    > non aware router, while this is not the case with 23.

Correct.  We picked 63 back in the day, so that packets that "escaped" would never reveal anything.  But that was just too restrictive, and basically many assumed that they could just add/remove extension headers whenever they wanted.

    > believe a sinple reference to the security consideration woudl be

I personally do not like writing text in SC that is new, I prefer to refer back to normative text in the Security Considerations, because non-security people do not read Security Considerations.

    > recommended as an alternative when LLN are involving communication over

A recommendation for End to End IPsec or End to End OSCORE/EDHOC or End to End DTLS for application data is certainly reasonably, but seems out of scope for this document.

There are cases where we insert IPIP headers between nodes which are not parent-child.  For instance, from root to leaf in the non-storing downward direction (because we add RH3).  If we were to "Use IPsec", then we'd need more tunnels.

In the cases where an RPL-aware 6LR adds an RPI header (in storing mode), for an RPL-unaware-leaf, and then sends it to some other leaf, we'd need an IPsec tunnel from two random nodes in order to secure the IPIP.
So while we don't need 2*n*(n-1) SAs in every case, that is the worst case scenario.
(btw: I think that there are some non-constrained, non-LLN uses of RPL where that actually might be worth doing)

--
Michael Richardson <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-