[Roll] [roll] #176 (applicability-ami): Security items to consider for applicability-ami draft - IESG Evaluation-

["roll issue tracker" <[e-mail]>]

#176: Security items to consider for applicability-ami draft - IESG Evaluation-

 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.

 (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.)

 - 1.3: what's the 3rd bullet mean? It's worded very
 ambiguously. With s/(vs. non-storing)// it'd be clear.

 - 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?

 - 5.1, last sentence: why is it important to note that?
 explaining would be good

 - 7.2.3: I don't get what you're telling me here that
 assists in security or interop?

 - 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.

 - 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?

 - 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

 - 9.3: "already existing" - you really should have a
 reference there.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-roll-
  [e-mail]          |  [e-mail]
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  applicability-ami        |    Version:
 Severity:  In WG Last Call          |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <https://tools.ietf.org/wg/roll/trac/ticket/176>
roll <https://tools.ietf.org/wg/roll/>