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

[Stephen Farrell <[e-mail]>]

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" <[e-mail]> 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?
> 
>>
>>
>