Subject: [Roll] Stephen Farrell's Discuss on draft-ietf-roll-applicability-home-building-09: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 08 Apr 2015 16:34:08 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-roll-applicability-home-building-09: 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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Please correct me if I'm getting this wrong, I honestly may
have forgotten the plan. My understanding was that RPL and RFC
7416 etc. were approved on the basis that you needed to get to
specific applications of RPL before you could sensibly specify
interoperable security with automated key management (AKM) as
is clearly required by BCP107 and as has been discussed
between security ADs and the ROLL WG numerous times. This is
going back to the 2010 discuss from Tim Polk that I inherited
in 2011, hence me being uncertain if I remember the plan for
sure;-) In any case it seems to me that this draft also
doesn't get us to the point where we have a defined way to do
AKM (Again, sigh.) I also have a set of comments on that below
that I won't make into specific discuss points (at least until
we figure out or re-discover the plan).

So, with that context, and with real regrets for sounding like
an old and broken record, the discuss point: why is this not
the ROLL WG draft where we finally get to specify AKM for RPL?
If your answer is that this is just an applicablilty statement
then I'll ask why it's going for proposed standard, and when
to finally expect the AKM spec for RPL (for this application).

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

- I don't get how there's an IPR disclosure for this, but
whatever.

- The non-security parts of this were quite a good read.

- 4.1.8: 1st sentence makes no sense. It says RPL does X or
not-X in order to Y. There is no choice but for RPL to do X or
not-X.

- 4.1.8 seems to me to imply that link layer security is
always needed since there can always be some node that will
send an unsecured RPL messsage. If you agree, then I think
that should be made more clear. If you disagree, I'd like to
understand how.

- 4.1.8, I am surprised not to see a recommendation that
separate group keys SHOULD be used for different applications
in the same bulding network. But that may be too fine grained
a recommendation for this document perhaps.

- 5.1.2.1, I think it'd be clearer to say Imin should be
between 10 and 50 ms. The "10 - 50 ms" notation can be
confusing. (Same elsewhere.)

- section 7, 3rd para, "can rely on" is sales language, please
strike that or s/rely on/depend upon/ 

- section 7, 3rd para, last sentence: this is sales language
and should be deleted. Or perhaps s/is/SHOULD be/ would turn
it back into a piece of specification language.

- 7.1 - this is odd text to see in a proposed standard, but I
think it's accurately describing the level of interop to
expect in RPL security, so is probably the right thing to say.
I'd argue that it'd be even better to bluntly admit/say that
there is currently no interoperable automated key management
for RPL. (Same for 7.3) Or, and better, to fix that lack. (See
my discuss point.)

- 7.2, 1st sentence: this is meaningless as I read it - what
are you trying to say?

- 7.2, when a node is stolen, the chances are that any keys
contained in the node are at significant risk of being leaked.

- 7.3, I do not believe that [I-D.keoh-dice-multicast-security] 
is necessarily going to proceed via the DICE WG. Depending 
on it would be fairly high-risk in any case.

- 7.4, last sentence: more sales talk

- 7.5, what is this specifying? I don't get it. Does 7416 set
out what to implement to get interop? (I didn't think so, but
nor does this seem to.)

---

From: peter van der Stok <[email-masked]>
Date: Thu, 09 Apr 2015 10:42:20 +0200

Hi Stephen,

thanks for the comments.

> on it would be fairly high-risk in any case.

I have the same fear. BUT multicast will be used and having a secure 
protocol is an urgent wish.
I understand the reasons why the current draft will not make it. 
However, I know that other people are working on better sequels.
I think this multicast security is important.
Do you think I should add text to emphasize my opinion and encourage 
sequels to [I-D.keoh-dice-multicast-security] ?

Peter

Stephen Farrell schreef op 2015-04-09 01:34:
> Please refer to 
> http://www.ietf.org/iesg/statement/discuss-criteria.html
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Apr 2015 10:59:12 +0100

Hiya,

> protocol is an urgent wish.

That's clear. What's not clear is whether or not there is a way
to meet that wish at the TLS layer. Seems that there may not be
is my guess at the DICE WG current thinking.

> sequels to [I-D.keoh-dice-multicast-security] ?

That could be fine, but if you do, please consider that the
solution may need to use security primitives above the
transport layer, e.g. perhaps in CoAP payload.

Cheers,
S.

---

From: peter van der Stok <[email-masked]>
Date: Mon, 13 Apr 2015 09:23:20 +0200

Hi Stephen,

I leave the AKM discussion out in the reactions below. Michael intends 
to start it.
My reactions below within <peter> </peter>
I am sure Robert will improve on my suggestions.

Greetings,

Peter

<peter> thanks </peter>
> not-X in order to Y. There is no choice but for RPL to do X or
<peter>
RPL MAY use unsecured messages to reduce message size.
</peter>

> that should be made more clear. If you disagree, I'd like to
<peter>
If there is a single node that uses unsecured RPL messages, link-layer 
security MUST be present.
</peter>
> a recommendation for this document perhaps.
<peter>
What is an application?
Different keys per group? But what about two overlapping groups of 5 
nodes within a single home?
I prefer to avoid these discussions.
</peter>

> confusing. (Same elsewhere.)

<peter> done </peter>
> strike that or s/rely on/depend upon/

<peter>
back to an earlier version:
Both MAY be done using:
</peter>
> it back into a piece of specification language.
<peter> returned to original specification language, as suggested 
</peter>
> - 7.2, 1st sentence: this is meaningless as I read it - what
<peter>
fixed in earlier GEN Art e_mail exchange
</peter>
> on it would be fairly high-risk in any case.
<peter>
Concerning multicast security, the first light-weight attempt <xref 
target="I-D.keoh-dice-multicast-security"/> will probably be succeeded 
by more generally employable solutions.
</peter>
> - 7.4, last sentence: more sales talk
<peter>
Remove it? It leaves the earlier phrase in the air
</peter>
> out what to implement to get interop? (I didn't think so, but
<peter>
Specifies relation with 7416.
</peter>

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Apr 2015 16:31:05 -0400

Stephen Farrell asked:
> Please correct me if I'm getting this wrong, I honestly may have forgotten
> the plan. My understanding was that RPL and RFC 7416 etc. were approved on
> the basis that you needed to get to specific applications of RPL before you
> could sensibly specify interoperable security with automated key management
> (AKM) as is clearly required by BCP107 and as has been discussed between
> security ADs and the ROLL WG numerous times. This is going back to the 2010
> discuss from Tim Polk that I inherited in 2011, hence me being uncertain if
> I remember the plan for sure;-) In any case it seems to me that this draft
> also doesn't get us to the point where we have a defined way to do AKM
> (Again, sigh.) I also have a set of comments on that below that I won't
> make into specific discuss points (at least until we figure out or
> re-discover the plan).

> So, with that context, and with real regrets for sounding like an old and
> broken record, the discuss point: why is this not the ROLL WG draft where
> we finally get to specify AKM for RPL? If your answer is that this is just
> an applicablilty statement then I'll ask why it's going for proposed
> standard, and when to finally expect the AKM spec for RPL (for this
> application).

BCP107 certainly does ask for automatic key management when keys are going to
be used.  The part of the plan that is perhaps not so clear is that we have
yet to have anyone say that they intend to use layer-3 keying in for RPL.

The intention of having the security being precisely specified in the
applicability statements was so that we would know if layer-2 security was
being used, or if there was a layer-3 security being used.
If there is layer-3 security, then BCP107 would demand that we have an AKM for it.

In reading section 7 again just now, I see how things went wrong... Some text
seems to have snuck into section 7(.0) that tries to sit on the fence, so I
propose to remove paragraphs 3 and 4 of that section and say instead:
    "This document mandates that a layer-2 mechanism be used during initial
     and incremental deployment. Please see the following sections."

Section 7.1, is quite clear that PANA is being specified to carry EAP
messages for a 1x bootstrap into layer-2 security.    That this is the
default position of this document.  I have tried to persuade the authors to
be clearer and less speculative. While I'm thrilled that they like the
methods 6tisch is considering, I'd prefer to remove the paragraph "New
approaches...".

I would like prefer that this document was even more precisely about what
kind of 15.4 security is being used, either directly profiling the relevant
parts of the 802.15.4 specification, or by indirect reference to something
that does.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Apr 2015 00:03:47 +0100

> parts of the 802.15.4 specification, or by indirect reference to something

Thanks Michael. I agree that a profile or applicability statement can
certainly go for all security "below" the IP layer in which case we
don't have a direct application of BCP107. It does of course raise
some other issues about interop (making precise refs as you say) and
about how or whether you can authenticate RPL routers as such. I guess
that latter is via PANA, which I'd need to read up on.

Anyway, seems like the best thing here is for the fixes you've spotted
above to be done along with any others from the IESG review and then
for me to go over it again in the light of your mail. But do say if
there's a better plan.

Cheers,
S.

---

From: peter van der Stok <[email-masked]>
Date: Wed, 15 Apr 2015 09:24:48 +0200

HI Michael and Stephen,

> methods 6tisch is considering, I'd prefer to remove the paragraph "New

In principle the removal of paragraphs can be quite satisfactory because 
in the restraint one recognizes the master (my translation from German).
But, it makes me wonder for whom we write this applicability draft.

It is quite clear that protocols exist and are used for the 
initialization of the layer-2 security.
On the other hand, many new protocols are suggested and not from an 
academic point of view but because there is a need.
Removing the speculation means removing the recognition of this state of 
affairs.

My suggestion is that with the removal of the speculation, a caveat is 
introduced that current text does not cover all known building and home 
deployment cases.
Especially in connection to multicast I should like to indicate that 
work on multicast security is needed because far from solved.

An alternative conclusion is that current state of affairs suggests an 
Information document.

> parts of the 802.15.4 specification, or by indirect reference to 
The draft mentions ZigBee and Wi-SUN HAN. Any additional suggestions?

Peter

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 Apr 2015 12:02:20 -0400

peter van der Stok <[email-masked]> wrote:
    > In principle the removal of paragraphs can be quite satisfactory
    > because in the restraint one recognizes the master (my translation from
    > German).  But, it makes me wonder for whom we write this applicability
    > draft.

It's written for two entities:
     1) people procuring networking (who write Requests For Proposals: RFP)
     2) people who create networking solutions (who answer RFPs)

You can't tell those groups that they need to specify some unknown, not yet
defined protocol.   It's actually against international trade agreements to
do so!

I realize at this point that it is rare to see an RFP like this, that mostly
the RFP says something like: "please provide lights for our building", and
that given that almost all solutions to date have been proprietary, that
it's not the building owner's job to decide upon a standard... but that will
change. 

    > initialization of the layer-2 security.  On the other hand, many new
    > protocols are suggested and not from an academic point of view but
    > because there is a need.  Removing the speculation means removing the
    > recognition of this state of affairs.

Of course, we can revise the document to specify new things, but that means
a new set of requirements.

    > deployment cases.  Especially in connection to multicast I should like
    > to indicate that work on multicast security is needed because far from
    > solved.

The document has to specify solutions that exist;  that the current solutions
do not cover all deployment cases may be acceptable to document.  In this
specific case, we could write:
         "This document does not specify a multicast security solution.
         Networks deployed with this specification will depend upon layer-2
         security to prevent outsiders from sending multicast traffic.
         It is recognized that this does not protect this control traffic
         from impersonation by already trusted devices.  This is an area
         for a future specification."

At least we recognize and document the limitations.

    >> I would like prefer that this document was even more precisely about
    >> what kind of 15.4 security is being used, either directly profiling
    >> the relevant parts of the 802.15.4 specification, or by indirect
    >> reference to something that does.
    >> 

Yes, it does.  Can we specify them more clearly?  I think that it would be
either Zigbee IP (-2013? is it?) *OR* Wi-SUN HAN (I have no clue about this
one).

---

From: peter van der Stok <[email-masked]>
Date: Thu, 16 Apr 2015 09:01:31 +0200

HI Michael,

> At least we recognize and document the limitations.
<peter>
OK, this is perfectly acceptable for multicast. When there are no other 
suggestions or objection, the draft is changed accordingly

However, concerning alinea 3 in section 7.1 references to dtls-relay and 
security-6top are informational references and do not influence the 
specification part.
On the mailing list there was at least support for mentioning 
dtls-relay.
So, I like to keep them.
</peter>
> either Zigbee IP (-2013? is it?) *OR* Wi-SUN HAN (I have no clue about 
<peter>
I don't understand what you mean.
You want references to documents? Explaining the standards seems not 
really called for here.
</peter>

Peter

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Apr 2015 14:43:04 -0400

> You want references to documents? Explaining the standards seems not really
    > called for here.
    > </peter>

I'm just suggesting a more definite, chapter/section, reference.

---

From: peter van der Stok <[email-masked]>
Date: Mon, 27 Apr 2015 09:05:24 +0200

Dear all,

This new draft includes the return to the RFC2119 text.
It includes all comments answered during the security evaluation.
It includes suggestions by Michael to answer the DISCUSS raised by 
Stephen Farrell.
It maintains some of the text on the aspects of security in buildings 
that need additional work.

Greetings,

Peter

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
  This draft is a work item of the Routing Over Low power and Lossy 
networks Working Group of the IETF.

         Title           : Applicability Statement: The use of the RPL 
protocol suite in Home Automation and Building Control
         Authors         : Anders Brandt
                           Emmanuel Baccelli
                           Robert Cragie
                           Peter van der Stok
	Filename        : draft-ietf-roll-applicability-home-building-10.txt
	Pages           : 32
	Date            : 2015-04-26
2
Abstract:
    The purpose of this document is to provide guidance in the selection
    and use of protocols from the RPL protocol suite to implement the
    features required for control in building and home environments.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-applicability-home-building/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-applicability-home-building-10

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-applicability-home-building-10

Please note that it may take a couple of minutes from the time of 
submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/