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

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Sat, 10 Sep 2016 02:59:39 +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" <[email-masked]> 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?

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Sep 2016 13:35:06 +0100

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.

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Fri, 16 Sep 2016 12:36:37 +0000

Hi Stephen,

Yes, that sounds good….I’ll try to put another rev up in the next couple
days….

Thanks!  Nancy

---

From: "Nancy Cam-Winget (ncamwing)" <[email-masked]>
Date: Mon, 26 Sep 2016 20:30:44 +0000

All,

Version 14 has just been uploaded with suggested updates to all comments
received thus far the
Draft can be found in :
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/

Thanks, Nancy