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

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-roll-applicability-ami-13: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-ami/



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

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


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


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