Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-ami-13: (with DISCUSS and COMMENT)

Stephen Farrell <> Fri, 16 September 2016 12:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1197712B03F; Fri, 16 Sep 2016 05:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.809
X-Spam-Status: No, score=-5.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, SPF_PASS=-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 inaLh22bsXAZ; Fri, 16 Sep 2016 05:35:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3131D12B0F2; Fri, 16 Sep 2016 05:35:09 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D9885BE79; Fri, 16 Sep 2016 13:35:07 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NO8USwYI8PJa; Fri, 16 Sep 2016 13:35:07 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id A4A93BE74; Fri, 16 Sep 2016 13:35:06 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1474029307; bh=vcsQ88weGjz8D7ePxqvuKn9XWAkt3phsoIwp6hkxLzY=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=4TcTvjNGhjokzCpVS/JpMezLA7JS6+0ELeT9C5rsCKASpbKnZv9UXFPFhTOjm10cX DgmxfV1wx9d3Jel5YRRHIC6QLRFO5ayZIz7kBIUOwaLpFtonqW0ltLIfjCbF1QQWxB dWHleAcJSF8MGGFd/vvre9qFutBu7Oj25KqMBbqI=
To: "Nancy Cam-Winget (ncamwing)" <>, The IESG <>
References: <> <>
From: Stephen Farrell <>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <>
Date: Fri, 16 Sep 2016 13:35:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030605060404070400080906"
Archived-At: <>
Cc: "" <>, "" <>, "" <>, "" <>
Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-ami-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <>
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Sep 2016 12:35:12 -0000

Hi Nancy,

Most of those changes look good. Given the elapsed time it
may be best to shoot out a new revision and then I can go
back and check if there's more to be done. That sound ok?


On 10/09/16 03:59, Nancy Cam-Winget (ncamwing) wrote:
> Hi Stephen,
> Apologies for taking way too long to get to this; I had met with the
> authors in hopes to try to get all responses but given that too long has
> passed, I’m now putting what I have to the full audience:
> On 5/3/16, 12:19 PM, "Stephen Farrell" <> wrote:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> I have two things I'd like to chat about, given that these
>> applicability documents are where the roll WG has iirc
>> said it'd address security and privacy issues with RPL:
>> (1) 7.1.7: Don't you need to turn that "may not need"
>> around and say that AMI deployments of RPL REQUIRE
>> implementation (and maybe use) of link layer and higher
>> layer security features? (You almost say that in 9.3 I
>> think, so it'd maybe be good to be crystal clear.
> [NCW] You are correct, the intent is to ensure that link and
> higher layer security be used.  We can modify the sentence to read:
> “As a result, while AMI deployments may not need to implement RPL's
> security mechanisms they
>    MUST include at minimum, link layer security such as that defined by
> IEEE 1901.2 and IEEE 802.15.4.”
>> (2) Why are there no privacy considerations? I think this
>> document needs that. For example, an AMI mesh based purely
>> on link layer security could be a total privacy nightmare.
>> And part of that is down to RPL - if I can cause lots of
>> folks' traffic to be sent to me, that is RPL's issue.
>> That I can then see the application layer content is not
>> RPL's fault, but is still relevant.  I think this section
>> is important to include because the authors here are
>> presumably the ones who know the application layer
>> information. And the sensitive information might not only
>> be readings, it could include packet size, if larger
>> packets are caused by activity such as turning on heating,
>> then larger packets indicate presence and smaller ones
>> absence, depending on weather. I am also concerned that
>> there may be privacy issues arising from the various
>> identifiers in use here.  Did the WG consider these issues
>> and their potential impact on how it is or is not safe to
>> use RPL? (While the analysis might sound complex, I'd bet
>> that not much new text would be needed, but who knows
>> until the analysis has been done.)
> [NCW] As I was not an active participant of the group then, I can’t answer
> to whether this was discussed in the group or not.  However, as this
> draft is more focused on RPL’s applicability in the AMI, I think we
> can add a short section to perhaps address privacy in the context of
> the draft’s focus.
> I can add a privacy consideration section as a subsection (or do you
> prefer it be its own section?) of Security Considerations.
> Here’s some proposed text:
> X.X Privacy Considerations
> Privacy of information flowing through smart grid networks are also subject
> to consideration and is evolving a set of recommendations and requirements.
> For example, the U.S. Department of Energy issued a document [DOEVCC]
> defining 
> a process and set of recommendations to address privacy issues.  As this
> document
> describes the applicability of RPL, the privacy considerations as defined
> in
> [RFC6550] and [I-D.6lo-privacy-considerations] apply to this document and
> to AMI deployments.
> — References ----
> [DOEVCC] U.S. Department of Energy, “Voluntary Code of Conduct (VCC) Final
> Conepts and Principles”,
> iples%202015_01_08%20FINAL.pdf, Jan. 2015
> [I-D.6lo-privacy-considerations]  Thaler D., “Privacy Considerations for
> IPv6 over Networks of Resource-Constrained Nodes”, July 2016.
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> - 1.3: what's the 3rd bullet mean? It's worded very
>> ambiguously. With s/(vs. non-storing)// it'd be clear.
> [NCW] Done….updated in the next rev
>> - section 3: "a potentially significant portion of which
>> is taken up by protocol and encryption overhead" seems
>> overstated to me - are there numbers to back that up?
> [NCW] The challenge is that providing numbers can raise more questions as
> to the validity of the actual numbers.
> If you need a deeper response, I will need to rely on Daniel to provide
> more rationale on the inclusion of this content.
>> - 5.1, last sentence: why is it important to note that?
>> explaining would be good
> [NCW] The comment was to state that while there was a new amendment, it
> did not affect the security mechanisms or properties.
> We can remove the sentence if you believe it adds no value.
>> - 7.2.3: I don't get what you're telling me here that
>> assists in security or interop?
> [NCW with DP] This was a result of the working group’s comments requesting
> that we provide information about how and what security features were used
> from the link layer.
>> - section 9: please provide references to back up the
>> assertion that "many available security mechanisms are not
>> practical for use in such networks" for some relevant
>> security mechanisms. The problem is that such assertions
>> are used to justify doing nothing at all so they ought not
>> be blithely made.
> [NCW] It may be simpler to remove the sentence.  Alternately, we can
> modify the sentence to:
> “…..for example, the use of asymmetric cryptography such as a 2048bit RSA
> for such constrained environments are not practical.”
>> - 9.1: "are unique per device" etc is the only sensible
>> thing and would be nice if always true, but that is often
>> not the case - why state what's known to not be true? Or
>> are you trying to say something else?
> [NCW] Actually, the credentials are unique per device, so perhaps noting
> that is redundant.
> The uniqueness is a requirements regardless, but perhaps you challenge who
> knows the credential….which can be implementation specific.
> Given the confusion, perhaps its better if we just remove the sentence.
>> - 9.2: "it is replaced" - again that's not true, only
>> devices known to be compromised would be replaced, which
>> is by no means all compromised devices
> [NCW] True that we may not know all compromised devices; we can update the
> sentence to read:
> “If during the system operation a device fails or is known to be
> compromised, it
>    is replaced with a new device.:”
>> - 9.3: "already existing" - you really should have a
>> reference there.
> [NCW] We would have to reference product specific links (i.e. NDES, LDAP)
> which we typically don’t do in IETF documents?  Perhaps its better if we
> remove the sentence, OK?