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

"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Sat, 10 September 2016 02:59 UTC

Return-Path: <ncamwing@cisco.com>
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 A1DE112B2EE; Fri, 9 Sep 2016 19:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.029
X-Spam-Level:
X-Spam-Status: No, score=-16.029 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 5Ki1YuFn6_kX; Fri, 9 Sep 2016 19:59:42 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E6612B053; Fri, 9 Sep 2016 19:59:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9348; q=dns/txt; s=iport; t=1473476382; x=1474685982; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pF/V5ocbKm+jm+8/Lt6lSCJvw5N3bgJBvIFK9pMQMCI=; b=DwULEQKjeriaiLVxnBOqEtlq2QrHXctoMvIeB8qosZFyiv2jjiGzYPN0 p9E9pnBM8uY9U++6onrL6tsCaPF2Y7xCoWfxaLZHHCEA2REKJHtfkVJ6u cXDWPgVLDTuvqHZLAKawR0Kai7OBcWWcx3FXIWY5SIOr6kPo89qWeXNxg g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ByAQAXdtNX/51dJa1eGQEBAQEBAQEBAQEBgy0BAQEBAR5XfAEGjSypB4IPggMmhXcCHIEwOBQBAgEBAQEBAQFeJ4RiAQEEIxFFEAIBBgIYAgImAgICMBUQAgQBDQWISg6Xap0kjC8BAQEBAQEBAQEBAQEBAQEBAQEBHoEGiXmEQIMCgloBBIgwkTIBhiOJJYFuToQSgzaFXoZ3hV6DegEeNoJxGxiBNnCGVn8BAQE
X-IronPort-AV: E=Sophos;i="5.30,308,1470700800"; d="scan'208";a="319919695"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Sep 2016 02:59:41 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u8A2xeoi005100 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 10 Sep 2016 02:59:41 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 9 Sep 2016 22:59:40 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 9 Sep 2016 22:59:39 -0400
From: "Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, The IESG <iesg@ietf.org>
Thread-Topic: Stephen Farrell's Discuss on draft-ietf-roll-applicability-ami-13: (with DISCUSS and COMMENT)
Thread-Index: AQHRpXDFOxoYv8Y6ZU29iMagalJOn6ByoZAA
Date: Sat, 10 Sep 2016 02:59:39 +0000
Message-ID: <D3F8C102.18B7C2%ncamwing@cisco.com>
References: <20160503191946.8201.87854.idtracker@ietfa.amsl.com>
In-Reply-To: <20160503191946.8201.87854.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.6.160626
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.100.93]
Content-Type: text/plain; charset="utf-8"
Content-ID: <E070B8B79CB0D544AFDB285E641B3520@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/AfiXhTcGHFGHKM9oo7Ecs-kHNbw>
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: Sat, 10 Sep 2016 02:59:45 -0000

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?

>
>