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

Daniel Migault <> Thu, 11 April 2019 01:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D7B7A120465; Wed, 10 Apr 2019 18:11:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lDiyK80ZsWGI; Wed, 10 Apr 2019 18:11:57 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C463E120125; Wed, 10 Apr 2019 18:11:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GCh32v/atE0NwLDyVGZLnpgdDRoG42OiWTdLKuwK6hM=; b=jEKvTk/QFhTDsm6raRhIN2zrbafoFRE3Sw6L40Ri/1r5Gre8ZyBWepkSh3XfUhVvqT6TPLws5FQM0SJoggGpZR7Rjxp8+y8TpLi38jUCO59CltZ7TYgf1eWtwUcDJBivb39DiOjO607tf8/DsMvt0K1W2XOlzRteC8HSM+Z5QfM=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Thu, 11 Apr 2019 01:11:54 +0000
Received: from ([fe80::3568:7582:3c7d:6f18]) by ([fe80::3568:7582:3c7d:6f18%2]) with mapi id 15.20.1771.016; Thu, 11 Apr 2019 01:11:54 +0000
From: Daniel Migault <>
To: Michael Richardson <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: Secdir last call review of draft-ietf-roll-useofrplinfo-25
Thread-Index: AQHU7/0VC3CEKOMN4UKr1zrsdJOI3aY2IUHA
Date: Thu, 11 Apr 2019 01:11:53 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: becde922-ddec-41f5-be94-08d6be1aaf6c
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR15MB2735;
x-ms-traffictypediagnostic: MN2PR15MB2735:
x-microsoft-antispam-prvs: <>
x-forefront-prvs: 00046D390F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(39860400002)(366004)(51914003)(13464003)(51444003)(199004)(189003)(106356001)(33656002)(102836004)(4326008)(486006)(7736002)(7696005)(53936002)(6436002)(66066001)(105586002)(9686003)(476003)(305945005)(55016002)(229853002)(99286004)(186003)(446003)(86362001)(74316002)(25786009)(6246003)(44832011)(52536014)(11346002)(5660300002)(316002)(54906003)(81156014)(81166006)(2906002)(3846002)(53546011)(8676002)(14444005)(71200400001)(256004)(71190400001)(8936002)(26005)(97736004)(478600001)(6506007)(68736007)(76176011)(14454004)(6116002)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR15MB2735;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: LHwZzHV3nsMYzIOMdxIFokKdn1FknRms8J3CpcLArt/6h2eJUluIvGGgADU5LBF8bHxle87OnsireiQXGAh2dszp98ywVouucnbO3YdeSvr6nGufTSV0gADqyY5UQnc6e0pyOsvyQsmLu/8Dk85/RuD0dj3a85zBZj4Jxt9vShWiXlzEH0PLyBMAiGZf4eCurZxYurNAHz70zARSEmxx6FddQ9gHaMt3Hbvn/rCUCpa+yvYxGPNY3BIu/VkmwsmyvjDEvrTWEuWgdUq+2Dzvcru4LbWpiOWgHBhk26kvFM0l/dM4NT0vqgE/VR5BVki4Qnk9Gps/RkL0Xwe7JXET9/Of5Ci3b8gic3bFK9WrLWxyE2s8GJBpcn0FDLxgr7YKtsLv0qR5BbJmuFYeSgWpiftjsXQ+Eg9AqpagqYXjlI4=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: becde922-ddec-41f5-be94-08d6be1aaf6c
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 01:11:53.9139 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB2735
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: Thu, 11 Apr 2019 01:12:00 -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. 

-----Original Message-----
From: Michael Richardson <> 
Sent: Wednesday, April 10, 2019 7:31 PM
To: Daniel Migault <>
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.

Daniel Migault via Datatracker <> wrote:
    >    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>

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.

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

Yes, that's correct.

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

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.

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

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.

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

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 <>ca>, Sandelman Software Works  -= IPv6 IoT consulting =-