A Security Framework for Routing over Low Power and Lossy Networks
draft-ietf-roll-security-framework-07

Summary: Needs a YES.

Alvaro Retana No Record

Benjamin Kaduk No Record

Erik Kline No Record

Francesca Palombini No Record

John Scudder No Record

Lars Eggert No Record

Martin Duke No Record

Martin Vigoureux No Record

Murray Kucherawy No Record

Robert Wilton No Record

Roman Danyliw No Record

Warren Kumari No Record

Zaheduzzaman Sarker No Record

Éric Vyncke No Record

(Stephen Farrell; former steering group member) Discuss

Discuss [Treat as non-blocking comment] (2011-05-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Since I've taken over Tim's discuss, I've just had a read to
ensure I understand this. I read this document and section 10
of roll-rpl.

I believe that the core of Tim's discuss is that there is no
specification for how the authenticated mode of roll-rpl is to
be done, and specifically using public key based mechanisms
for key distribution.

That seems to still be the case, so if I'm right there, then
the discuss should remain. If not, (Tim?) then I may be
misunderstanding, and should clear. I don't see anything in
this document, the charter milestones or the set of WG docs
that looks like it will address this.

I'd be happy to clear were there to be a good specification
of how to do e.g. a signature based authenticated mode, or
a public key based way to distribute keys for an
authenticated mode, or even a kerberos-like way to
distribute secret keys for an authenticated mode. While this
will all be optional to implement, its absence is really
not consistent with bcp107.

Having read the thing, I also have a bunch of comments (below)
and one additional question about RPL to which I'd love to know
the answer. (It may be that the answer is in roll-rpl already
but I didn't read all 163 pages;-).

My question: with pre-shared keys, what prevents reflection or
re-direction attacks where a MACed message is captured and
either reflected back to the sender or else sent to another
node using the same pre-shared secret? In order to avoid having
to exhaustively analyse the protocol, its normal to try to
prevent such attacks inside the crypto mechanism.

[Tim's original discuss text is below]

I think this is a really good document, and support its publication.

However, I think some of the issues I was persuaded to remove from my discuss on
roll-rpl because they would be
more appropriate in this document were omitted.
I am specifically concerned about punting the details on public key
distribution, then finding they are not covered here either.

Did I get the wrong document?  Where are those issues going to be addressed?

I will hold this discuss while we sort out the best place to address these
issues...

(Tim Polk; former steering group member) (was No Objection) Discuss

Discuss [Treat as non-blocking comment] (2011-01-20 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think this is a really good document, and support its publication.

However, I think some of the issues I was persuaded to remove from my discuss on roll-rpl because they would be
more appropriate in this document were omitted.  I am specifically concerned about punting the details on public key
distribution, then finding they are not covered here either.

Did I get the wrong document?  Where are those issues going to be addressed?

I will hold this discuss while we sort out the best place to address these issues...

(Adrian Farrel; former steering group member) Yes

Yes (2011-05-02 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Additional nit per David Black
Section 6.1
 I would have used the word "confidentiality" instead of "privacy" in stating the second requirement

(Alexey Melnikov; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Dan Romascanu; former steering group member) No Objection

No Objection (2011-01-20 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I support the position expressed by Russ in his DISCUSS. 

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Peter Saint-Andre; former steering group member) No Objection

No Objection (2011-01-19 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Overall this is a fine document. Several infelicities in the text might cause confusion:

1. In Section 3.2, "the service of non-repudiation implies after-the-fact" sounds like it should be "the service of non-repudiation applies after-the-fact" but instead the authors seem to mean that "the service of non-repudiation implies that the attack occurs after the fact" or somesuch.

2. In Section 3.3, "can all contribute to key management issues" could be construed as contributing to important or critical ("key") issues related to network management, not as "complicating the operations of key management" as in the previous paragraph; I suggest repeating the previously-used phrasing.

There are also several unfortunate typographical errors (e.g., "fundament" instead of "fundamental" in Section 3.4, "undue utilization of exhaustion" instead of "undue utilization or exhaustion" in Section 4.3.4, "any device local or remote" instead of "any local or remote device" in Section 5.1.5, "compliment" instead of "complement" in Section 6.1, "aimed the manipulation" instead of "aimed at the manipulation" in Section 6.5).

With regard to Denial of Service (DoS) in Section 4.3.3, please add a reference to RFC 4732.

Please provide informative references for OSPF and ISIS in Section 5.2.5.

In Section 6.1, is uppercase "MAY" meant in the text "new ciphering key may therefore be concurrently generated or updated"?

In Section 6.4, is uppercase "MUST" meant in the text "a LLN must include a process for key and credential distribution"?

In Section 6.4, is uppercase "SHOULD" meant in the text Correspondingly, the routing protocol(s) specified by the ROLL Working Group should assume that the system affords key management mechanisms consistent with the guidelines given in [RFC4107]"?

In Section 6.5, is uppercase "SHOULD" meant in the text "   As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy"?

(And so on; in general, I suggest that the authors check all lowercase keywords throughout Section 6.)




(Robert Sparks; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2011-05-06)
No email
send info

(Stewart Bryant; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info