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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 16 September 2016 12:35 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1197712B03F; Fri, 16 Sep 2016 05:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.809
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inaLh22bsXAZ; Fri, 16 Sep 2016 05:35:09 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3131D12B0F2; Fri, 16 Sep 2016 05:35:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id D9885BE79; Fri, 16 Sep 2016 13:35:07 +0100 (IST)
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NO8USwYI8PJa; Fri, 16 Sep 2016 13:35:07 +0100 (IST)
Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A4A93BE74; Fri, 16 Sep 2016 13:35:06 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; 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)" <ncamwing@cisco.com>, The IESG <iesg@ietf.org>
References: <20160503191946.8201.87854.idtracker@ietfa.amsl.com> <D3F8C102.18B7C2%ncamwing@cisco.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <24314264-bab0-0228-010a-dca00d574ac8@cs.tcd.ie>
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: <D3F8C102.18B7C2%ncamwing@cisco.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030605060404070400080906"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/QbjTFOjnP3ZPsd2ohBUXbyL6hxw>
Cc: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "roll@ietf.org" <roll@ietf.org>, "draft-ietf-roll-applicability-ami@ietf.org" <draft-ietf-roll-applicability-ami@ietf.org>, "mcr+ietf@sandelman.ca" <mcr+ietf@sandelman.ca>
Subject: Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-ami-13: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=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?

Cheers,
S.

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" <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>>
>>
>> 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”,
>   
> http://energy.gov/sites/prod/files/2015/01/f19/VCC%20Concepts%20and%20Princ
> 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.
> 
> 
> 
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>> - 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?
> 
>>
>>
>