Re: [secdir] Secdir last call review of draft-ietf-roll-useofrplinfo-25

Ines Robles <> Fri, 17 May 2019 09:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2D4EC1200C5; Fri, 17 May 2019 02:28:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dBFM-ATbDofz; Fri, 17 May 2019 02:28:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9BAD1120059; Fri, 17 May 2019 02:28:49 -0700 (PDT)
Received: by with SMTP id g16so4941436iom.9; Fri, 17 May 2019 02:28:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LlIUystNDxQaEemV0dClkVRH4aqUMQEBtyEJE2+6HVk=; b=fLdrgpzQJiGAvAWcNgdOgP2/hgFxGOBb0am2EydMQXpSD3ogtw1cQOUls5Vr5cKl7H ZR7RC/m9r33NHROAeEfO5EDusJTjg6qD9cZUs8ID2vXR+g5feamUnVnfh/1qLmw0i3bd eANpVSRwhmb3KlLs6ZcQ3nof0Kew8hKoez1MA7ctWn02M4UD3kvsbjmPl19TLo1wHTN0 tPehE+Kwb0mwrSvJD7vC+jz29+sOrKR6YBMNwOnP+hcdJbcM1d0yIEGALHh++T+BGliC Wra8uK3nL5Y5L5s+ROSa4858WM5b5U6vpflVAK3kQ1QfPbFyoWLgXeKKb95akLlY9tgW Et9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LlIUystNDxQaEemV0dClkVRH4aqUMQEBtyEJE2+6HVk=; b=PIIHx825iakub7i18vJAcPNU9PI/PNZMSG7mgjNEI/76L5EJGjhYXA0RSM26KVD0ad YGMFgcVSomylDVNLEVjvAua8nxxgebnBxIs67hL1lvINLU3TstY72b5cR1cV+OjCt/nw H99wXzwmD7S4pwDx/DPH1UVLaY2QhrakunudtNqCDw5X5qIdNYx8wXQZWMFZ4wzG4iux 8zvNQPQRB9t4IvGEup6VIFi+Gaaf3GFgVXWPNct/pwpl+lsjCs41Bi4ptdORMfBVeQWE Xqgi4SlvCTtsFxNMMOFjyQ0yaZ2LK3p78z0s14Vus/IoUxo0ZJwQe7Wgi2OPg5Z69/uh wN4g==
X-Gm-Message-State: APjAAAUgZrYXySv9lo+KSxbPp89qN7/1miXq3WAxbO+Jv9nZueP4kkqw jTu7pS6QuFPPz1l2C1SBSdt4O9jnkFAmbJ6DCuw=
X-Google-Smtp-Source: APXvYqy7cGYAcyNyWUo5Tr3Q8JQZqRApm9Aw4jzeaGpP3C4eTGI/mhden1e5FYZTVA3Qo1xLO8eT3YNRkJIhA2tas2g=
X-Received: by 2002:a5d:9a11:: with SMTP id s17mr3866194iol.267.1558085328507; Fri, 17 May 2019 02:28:48 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Ines Robles <>
Date: Fri, 17 May 2019 12:28:37 +0300
Message-ID: <>
To: Daniel Migault <>
Cc:, roll <>, ietf <>,
Content-Type: multipart/alternative; boundary="000000000000891967058912022d"
Archived-At: <>
Subject: Re: [secdir] Secdir last call review of draft-ietf-roll-useofrplinfo-25
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 May 2019 09:28:53 -0000

Hi Daniel,

Thank you for your review and comments. We have submitted a new version
with corrections. Please find answer in-line

On Wed, Apr 10, 2019 at 10:01 PM Daniel Migault via Datatracker <> wrote:

> 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>

<author> [RFC6554 <>] defines the type 3
Routing Header for IPv6

  (RH3)  </author>

>    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>

<author> Yes, you are correct </author>

> 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>

<author> new text was added for clarification:”When unclear about the
travel of a packet, it becomes preferable for a source not to encapsulate,
accepting the fact that the packet may leave the RPL domain on its way to
its destination. In that event, the packet should reach its destination and
should not be discarded by the first node that does not recognize the RPL
option. But with the current value of the Option Type, if a node in the
Internet is configured to process the HbH header, and if such node
encounters an option with the first two bits set to 01 and conforms to
<xref target="RFC8200"/>, it will drop the packet. Host systems should do
the same, irrespective of the configuration.” </author>

>    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>

<author> paragraph deleted in version 28 </author>

> 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>

<author>fixed </author>

> 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>

New text added:
"Whenever IPv6-in-IPv6 headers are being proposed, there is a concern about
creating security issues. In the security section of [RFC2473], it was
suggested that tunnel entry and exit points can be secured, via "Use
IPsec". This recommendation is not practical for RPL networks. [RFC5406]
goes into some detail on what additional details would be needed in order
to "Use IPsec". Use of ESP would prevent RFC8183 compression (compression
must occur before encryption), and RFC8183 compression is lossy in a way
that prevents use of AH. These are minor issues. The major issue is how to
establish trust enough such that 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, "Use
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 resource for a constrained nodes on a constrained
network. In the end, the IPsec tunnels would be providing only BCP38-like
origin authentication! Just doing BCP38 origin filtering at the entry and
exit of the LLN provides a similar level amount of security without all the
scaling and trust problems of using IPsec as RFC2473 suggested. IPsec is
not recommended."

Have a nice day,

Ines, Michael and Pascal.