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

Summary: Needs a YES.

(Stephen Farrell) Discuss

Discuss (2011-05-05 for -)
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...
Comment (2011-05-05 for -)
No email
send info
#1 The document uses terminology very slightly differently when
compared to others in e.g. the security area. It might be worth
going throuh rfc4949 and trying to change terminology here to
match that. (Or maybe you did, and 4949 is wrong - 4949 is so
long its hard to know;-) 

#2 Non-repudiation is a nonsense (as a network service) and is
better omitted from documents like this entirely. In this case
you might be able to s/non-repudiation/evidence gathering/ with
a few edits to fix this.

#3 I don't understand "routing in LLNs needs to bootstrap the
authentication process" - I guess I'm not sure who's
authentication to whom is being discussed.

#4 "Only when a validated and authenticated node association is
completed will routing exchange be allowed to proceed using
established session confidentiality keys and an agreed
confidentiality algorithm. " You can have confidentiality to
counter sniffing without authentication, but at the expense of
remaining vulnerable to MITM attacks. Might be too big a
change, but sniffing and MITM are different attacks really.

#5 "This session key shall be applied in conjunction" should
that be a 2119 SHALL?

#6 A reference for JTAG might be useful for some readers

#7 s/it associated external memory/its associated external
memory/

#8 I can't parse this: "Since remote access is not invoked as
part of a routing protocol security of routing information
stored on the node against remote access will not be
addressable as part of the routing protocol." Maybe it just
needs rephrasing.

#9 5.2 says that it won't include physical attacks, but the
title of 5.2.1 includes the word "tampering" which is usually
used in the context of physical attacks.  In 5.2.1 tampering
can be replaced with the more common "message modification" or
"message insertion" etc. as appropriate.

#10 5.2.2 says "...while there is not necessarily tampering"
which needs rephrasing.

#11 5.2.5 could also note that replay-caches are usually needed
to counter clock-skew (esp in LLN devices where you may need 24
hour wide windows) and that those can be problematic on the
kind of device considered here.

#12 There's either a missing reference or better explanation of
byzantine attacks. A reference would be better.

#13 5.2.5 talks about "routing principals" being authenticated
- is that a well defined term for roll/RPL? (It could be a
machine, a process, a thing in the context of a dodag...) The
very next paragraph says "routing entities" - are those the
same?

#14 5.2.5 - without a reference or explanation its not
sufficiently obvious that ospf or isis can directly detect
these attacks by comparing different messages - adding a
reference would be best.

#15 5.3.2 - you don't really drain an engrgy budget, but rather
an energy store

#16 5.3.2 - not sure that saying verify certs before signatures
is always right - that might involve CRL retrievals that could
amplify an attack if an attacker just presents a highly complex
cert path with a bogus signature - where's the evidence this
way is better?  If you have it, it should be
included/referenced.

#17 5.3.2 - I don't get the relevance of s/mime at the end of
5.3.2 - what part of (the 45 pages of) rfc5751 is relevant?

#18 5.3.4 - a reference would be good

#19 5.3.5 - a reference would be good

#20 6.1 - privacy isn't right here, it appears to be a
confidentiality service that's being required

#21 6.1 - it'd be better to be clear about what's mandatory to
implement vs. mandatory to use, 6.1's "MUST provide privacy..."
seems to be calling for mandatory-to-use. (A question on that,
are there really no LLN's where all geographic information is
obvious? e.g.  a very small scale network, or a network where
node position is inherently public, say a node on each bus-stop
- maybe a SHOULD is more correct here?)

#22 6.1 - asking that key lengths (strengths really) be "in
accordance" with requirements is a bit optimistic - how is one
supposed to know that 67bit strength is ok or not? We usually
do this in a gross manner, currently 80/128 bits of strength.
Its also typical to say that commensurate strength is at least
a SHOULD requirement. Its also quite unlikely that e.g. FIPS
accredited interfaces for 67bit strength ciphers will be
developed, so I'm very unsure that this is worthwhile. I also
think its less likely that you'd be able to justify 40bit
strength (maybe worth a try, not sure) in which case choices
other than 80bit and 128 equivalent strength seem wrong.

#23 6.1 has MAY requirements for tunnelling and load-balancing
without any explanation or reference - I don't get what that's
for anyway.

#24 6.2's 1st MUST parenthetically implies that integrity has
to be applied after confidentiality. Sign-then-encrypt is more
common, though in LLNs there can be reasons to do
encrypt-then-sign (or both). However, I'm surprised that you're
mandating something like that here - is that deliberate?

#24 6.2's 2nd MUST requires verifying "authenticity and
liveliness" - what are those?o

#25 6.2 - another weird bit of terminology; "MAY use security
auditing mechanisms that are external to routing to verify the
validity..." Auditing is not a run-time decision making
mechanism in all cases of which I'm aware. 

#26 6.3 - I don't understand the impact of this section which
contains only MAY requirements. This also needs rephrasing
since there's no antecedent for the MAY statements, and
the last one is hard to understand - what's an "insight"?

#27 title of 6.4 is odd - it reads like an add-on

#28 6.4 - does "MUST secure these mechanisms" mean "MUST use"?
If so, what's special about multi-/any-cast? (vs.  unicast that
is)

#29 6.4 - it makes no sense to me that a node MUST have
physical security countermeasures just because it doesn't only
use unicast. Is that what it really says here? (Sentence
starting "Furthermore, the nodes MUST provide...")

#30 6.4 "will assume" isn't 2119 language esp. when quoting
bcp107 here it seems odd, suggest adding some 2119 statement.

#31 6.4 "public certificates" is wrong, you mean "public key
certificates"

#32 6.4 - rfc3029 is a *very* odd citation - why that
experimental non-repudiation related protocol? I am unaware of
any LLN related experimental deployment of 3029 which is just
not designed for challenged environments, never mind anything
better. (Such as real deployment.)

#33 6.4 "must support means for secure config..." s/must/MUST/
probably?

#34 6.4 - One sentence has a *lot* of MUSTs in it - "secure
configuration, device authentication, and adherence to secure
key wrapping" and that's for cases where PKI it too
heavyweight?  I don't think we'll benefit from more security
fig-leaves for the Internet and this sounds like one. I think
this aspect needs more real thought - for an LLN that cannot
support the complexity of PKI what do we think is reasonably
required? (I'm ok to help try figure that out, but I do not
believe we know the answer right now.)

#35 6.4 - I like the idea of using IKE/IPsec where
useful/possible.  However, (presumably transport mode) IPsec
will only supply security services for moving roll/RPL messages
between nodes, so what about the other services needed? E.g. I
can't see how the 2nd bullet from 6.2 could be satisfied by
IPsec.

#36 6.4 - It seems a tall order for roll to "adapt" things like
mikey in order to make progress. Is that really what you think 
is needed? If so, what kind of adaptation and where might that
be done?

#37 6.5.1 - is this what you meant to say: "On the other hand,
providing four individual domain designs that attempt to a
priori match each individual domain is also very likely to
provide a suitable answer given the degree of network
variability even within a given domain; furthermore, the type
of link layers in use within each domain also influences the
overall security." It reads like it ought to say "is also very
unlikely" but it says "likely," which is also not that easy to
believe.

#38 6.5.1: "Instead, the framework implementation approach
recommended for optional, routing protocol-specific measures
that can be applied separate from or together with flexible
transport network mechanisms." Should that be "recommended is
for"? (Couple more typos in that paragraph as well.)

#39 6.5.2: typo: "and allow for flexible expiration scheme of
authentication credentials" s/for flexible/for a flexible/

#40 6.5.2: typo: "There and other.." (and more typos in that
paragraph)


(Tim Polk) (was No Objection) Discuss

Discuss (2011-01-20 for -)
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) Yes

Comment (2011-05-02 for -)
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

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Russ Housley) (was Discuss) No Objection

Alexey Melnikov No Objection

(Dan Romascanu) No Objection

Comment (2011-01-20 for -)
No email
send info
I support the position expressed by Russ in his DISCUSS. 

(Peter Saint-Andre) No Objection

Comment (2011-01-19 for -)
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) No Objection

(Sean Turner) (was Discuss) No Objection

Ignas Bagdonas No Record

Deborah Brungard No Record

Alissa Cooper No Record

Roman Danyliw No Record

Benjamin Kaduk No Record

Suresh Krishnan No Record

Warren Kumari No Record

Mirja Kühlewind No Record

Barry Leiba No Record

Alvaro Retana No Record

Adam Roach No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record