Re: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-ami-13: (with DISCUSS and COMMENT)
"Nancy Cam-Winget (ncamwing)" <ncamwing@cisco.com> Fri, 16 September 2016 12:36 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 D90DB127A91; Fri, 16 Sep 2016 05:36:43 -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_H4=-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 gpdkRXAeK4jh; Fri, 16 Sep 2016 05:36:40 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C9E212B123; Fri, 16 Sep 2016 05:36:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10740; q=dns/txt; s=iport; t=1474029400; x=1475239000; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=dgNTkWWU00qzqv8WMFfV2Fe1i0A4eDt7NLEeJt3Sdl0=; b=iWImoKyjcCFV9ubZ+XJT0nwe6DUajajwBapRng+EUtGsBcY2xC4XgRFn FCsk43JSX6MX/RUDjEv1WyqcaZR+wEjcCHgiLUB5A9XgfeCgNy8rZ3jIB 1135uqACc/SusrICCJeGJFqh2Z2bKkl9Wp3SLzOMxXwxxHV426asdTuTy Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CeAQBR5ttX/4kNJK1dGQEBAQEBAQEBAQEBBwEBAQEBgzoBAQEBAR5XfAEGjSypHoIPggMmhXgCHIE4OBQBAgEBAQEBAQFeJ4RiAQEEIxFFEAIBBgIYAgImAgICMBUQAgQBDQWISg6Wc50kjDoBAQEBAQEBAQEBAQEBAQEBAQEfgQaIf4EFhEQXgmuCWgEEiDSROQGGJIk2gW5OhBWDNoVhhn+FYoN6AR42gn8bGIE4cocUfwEBAQ
X-IronPort-AV: E=Sophos;i="5.30,344,1470700800"; d="scan'208";a="147891691"
Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Sep 2016 12:36:39 +0000
Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u8GCacLC005014 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 16 Sep 2016 12:36:39 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 16 Sep 2016 08:36:38 -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, 16 Sep 2016 08:36:37 -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: AQHRpXDFOxoYv8Y6ZU29iMagalJOn6ByoZAAgAqEHgD//4sTAA==
Date: Fri, 16 Sep 2016 12:36:37 +0000
Message-ID: <D401354F.18C227%ncamwing@cisco.com>
References: <20160503191946.8201.87854.idtracker@ietfa.amsl.com> <D3F8C102.18B7C2%ncamwing@cisco.com> <24314264-bab0-0228-010a-dca00d574ac8@cs.tcd.ie>
In-Reply-To: <24314264-bab0-0228-010a-dca00d574ac8@cs.tcd.ie>
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.4.33]
Content-Type: text/plain; charset="utf-8"
Content-ID: <16F4192BE1F9D04F96E30D2628DEB740@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/upS1PcG_xzbXPRZvd8ufw-80JzM>
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:36:44 -0000
Hi Stephen, Yes, that sounds good….I’ll try to put another rev up in the next couple days…. Thanks! Nancy On 9/16/16, 5:35 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie> wrote: > >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%20Pri >>nc >> 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)