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? > >
- [Roll] Stephen Farrell's Discuss on draft-ietf-ro… Stephen Farrell
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Nancy Cam-Winget (ncamwing)
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Stephen Farrell
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Nancy Cam-Winget (ncamwing)
- Re: [Roll] Stephen Farrell's Discuss on draft-iet… Nancy Cam-Winget (ncamwing)