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

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

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