A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)

Note: This ballot was opened for revision 01 and is now closed.

(Stewart Bryant) Discuss

Discuss (2013-03-27 for -01)
From a routing point of view I thought that this was well written, but I am concerned that the security reviewer had considerable comments which appear to be currently unresolved.

Adrian points to:


However this indirectly refers to a larger body of issues posted here:


and the security reviewer only re-lists a subset  of these in note 03848 noting that only the typos were addressed in the -01 version of the text.
Comment (2013-03-27 for -01)
No email
send info
It would be useful if the CIA model were defined (by value or by reference) much earlier in the document.

(Stephen Farrell) Discuss

Discuss (2013-03-28 for -01)
I think this will be a hugely useful RFC but does have a
few things that could be improved.  My discuss points are
small, and perhaps easily fixed, but also I think
important since they relate to why we're still here after
a couple of years.

(1) 6.4 says that consistency with BCP107 is a SHOULD.
That's a MUST, (regardless of how you define MUST:-) Note
that BCP107 does say when you do not need automated key
managment, and when you do. So if you really don't need
AKM then you are still consistent with the BCP. It is not
however ok to be inconsistent with BCP107.

(2) 6.5.1 says: "This protocol-specific security
mechanism SHOULD be made optional within the protocol
allowing it to be invoked according to the given routing
protocol and application domain and as selected by the
system user. " If you mean optional-to-use, that's ok,
but please say so. If you mean optional-to-implement,
that's not clearly ok and I have more questions. Do you
mean optional-to-use? If not, then BCP61 comes into play
for me unless the quoted text only relates to some
mechanisms that counter Byzantine attacks, in which case
you need to be clear that you're not saying that all
integrity mechanisms are optional-to-implement.
Comment (2013-03-28 for -01)
No email
send info
I support Sean and Stweart's discuss points. 

Note that all my comments below are non-blocking. I'd
be happy to chat about 'em and happier if we ended up
agreeing but that's not needed for this document to
progress as far as I'm concerned.

Some general points first:

- section 6: This says a lot of good things about what
MUST/SHOULD/MAY be used to get better security. But it
seems to say nothing about what MUST be implemented. I
think you really need to make that distinction since the
IETF is mainly concerned with the latter. If you don't
make that distinction, then I fear we'll have to have
that discussion on a case-by-case basis for each of
the applicability statements and some of the value
of this document will be lost. (But the case-by-case
discussion is a viable way to do it too.)

- I was a bit disappointed that this didn't go into more
detail about RPL. The term "DAG" for example doesn't
occur at all. However, its still useful enough as-is I

- Cryptographic protocols and implementations can
suffer from side-channel attacks, many of those require
the attacker to send 10's or 100's of thousands of
messages in order to recover a piece of plaintext. That
probably needs to be noted somewhere, and maybe have a
recommendation that LLN nodes ought to react if they see
many many errors in any cryptographic operation.  That
does however need to be balanced against the potential
for DoS that might be created should a bad actor send
many packets spoofing the source address of a victim node
- we don't want the attacker in that case to be able to
take the victim node off the network. Its just a hard
problem, but one that this document probably ought
bring to the attention of RPL implementers who care
about security.

and some specifics....

- 3.2: Non-repudiation is so the wrong term, but don't
feel bad - that's true for almost all uses of the term;-)
I think you ought get rid of that term entirely and maybe
talk about evidence preservation or something (before you
say its not much use in an LLN because of storage

- 3.2: Same topic. I don't think its correct to say that
you can't do logging. It is fair to say that you can't do
comprehensive or complete logging, but I'd bet almost all
devices that can do RPL could keep a medium sized
circular log at least and many could (e.g. via SD card)
actually keep quite extensive logs, which in my
experience compress excellently. I do agree that log
retrieval via the LLN is not so likely so if a device
will never be visited or hasn't any other interface but
the LLN, then it might not be worth logging, but you
don't say that. Even if you need to get the log via a
serial connection or JTAG its still very valuable in my
experience if you need to investigate some
(mis)behaviour. So overall, I'd suggest you don't write
off logging as much as you currently do.

- 3.4: I'm not sure what "misappropriated" is meant to
mean. Please clarify. I interpreted it as "leaked out"

- 3.4: I don't think "legitimacy" is a useful term here
and authenticity applies to messages more than

- 3.4: "faithfully" means what? 

- 3.4: I was surprised you didn't say that battery
depletion attacks are a potential issue for LBRs in the
last set of bullets here.

- 4.1.1: sniffing is an odd phrase here, maybe better to
say eavesdropping

- 4.2.1: you say attacks can affect convergence of the
routing protocol - that might be worth elaborating on as
its not clear to this (security geek) reader whether
slow/no-convergence is really an attack or (just) an
example of ineffecient routing. If you consider the more
important audience for this draft to be routing folk, then
maybe its ok and they know already. But to put it another
way, I'm not sure that causing convergence to be slower 
by a number of seconds is so much of a threat except
in a tiny proportion of LLNs.

- 4.3.1: There's a gap between the text and the bullet
list, its not clear that or how "HELLO flood attacks and
ACK spoofing" with RPL can lead to the threat described.
I don't doubt you're right, but the text doesn't explain
it in a way I can get.

- 4.3.3: Couldn't the routing protocol offer resilience
features that act to help mitigate DoS attacks at other
(lower or higher) layers? I don't see why not in principle
but you appear to dismiss this.

- 5.2.2: I don't get how comparison with historical data
helps in practice, but I guess it could. Might be useful
if there are some papers that could be referenced to help
the reader figure out if they could use this kind of

- 5.3.1: I don't think "coerce" is right, maybe
"convince" is better.

- 5.3.1: Do ACKs really reduce the probability of attack
success or rather reduce the impact? Seems more like the
latter to me.

- 5.3.4: Wouldn't limiting the capability of nodes to
accept assertions about link or path quality be a 
counter to sinkhole attacks? That might be something to
consider at protocol design time, but might also be
something to consider when deploying, e.g. to disallow
any peer from claiming to be an awful lot better than
all other peers?

- 5.3.5: It would have been great to see if there is any
evidence as to the reality of wormhole attacks. I do
sometimes wonder if these are more theoretical than
practical (in terms of offering a real advantage to an

- 6.1: s/improve vulnerability/reduce vulnerability/

- 6.1: It might be worth saying that one needs to be
careful in deriving new confidentiality keys from
new integrity keys. 

- 6.2: Just to make life more difficult, sorry;-) Logging
of integrity check failures, if done at the wrong place
could actually make a timing side-channel attack more

- 6.4: I don't agree that key managment is not directly
a ROLL security requirement. If you need some crypto
then its a requirement, full stop. The question that
arises is whether (and if so how) to meet that requirement
for RPL, or since we are where we are, for specific
RPL applicabililty statements.

- 6.5: When you say that conforming to the system's
target level of security is a MUST, I think you're mixing
up what's mandatory to implement vs. mandatory to use.
Some security mechanisms might well (and are often) MTI
even though there are deployments where they do not need
to be used (at present). And yes, that does lead to
sometimes unused code paths, which is a pain. But being
able to turn that on without e.g. updating firmware might
still be the right answer. (And requiring a secured
firmware update is probably more onerous anyway, though
should also be done.)

(Sean Turner) Discuss

Discuss (2013-03-27 for -01)
I have a whole bunch of problems with this draft, but understand that this is part of way to get out of the current not so great situation.  Many of my comments lined up with the secdir review, but since Stewart called it out in his discuss I'll support him.  Here's some of my own:

0) This draft boils down to this paragraph if I'm not mistaken:

   A ROLL protocol MUST be made flexible by a design that offers the
   configuration facility so that the user (network administrator) can
   choose the security settings that match the application's needs.
   Furthermore, in the case of LLNs, that flexibility SHOULD extend to
   allowing the routing protocol security requirements to be met by
   measures applied at different protocol layers, provided the
   identified requirements are collectively met.

I'm absolutely fine with the first sentence.  I'm even okay with the second sentence it gets done at the application layer all the time, but at the application layer they can all point to something that's all specified up and has MTI etc (think TLS).  If we end up doing that here then something similar needs to end up happening.  If use cases are so broad that they can't possibly pick an underlying security mechanism then you need to try again but with a  smaller net.

1) s3.2: Adding "misuse" in the integrity strikes me as wrong.  It's about determining whether data has changed.  The examples used are about delayed or replayed messages which seem to be better characterized as availability.

2) s3.2: How on is non-repudiation going to apply to these tiny little assets?  I see how I, a person, can repudiate that I sent a message and I can see how you, as a person, can repudiate something else.  Are two nodes going to be claiming one sent something while the other will say no I didn't?  I hear all the time we can't do this and we can't do that because these are so constrained but you're going to log and capture on-going messages - color me confused?  I think you should say non-repudiation applies to people not to device-to-device/automated communications.

4) s3.4: Not this one is likely to be cleared after an email exchange or two because there's not much for the authors to do…

This made my head pop because I thought the only security defined in the RFC 6550 has confidentiality baked in.  So are we dumping the security solution in rpl?
 With regard to confidentiality, protecting
 the routing/topology information from eavesdropping or unauthorized
 exposure may be desirable in certain cases but is in itself less
 pertinent in general to the routing function.
Comment (2013-03-27 for -01)
No email
send info
1) s1/s3/3.1/3.2: The CIA model is one that's great, but in s3 your list security services list starts off with "proper authorization for actions" and then talk about authentication next.  Clearly authorization and authentication need to be added in to s3.2 -no?  Any chance of just changing to the 5 (confidentiality, integrity, authentication, access control, and non-repudiation) listed in ISO 7498-2?  You ever get a stable international reference.  You don't need to have that awkward lead-in about non-repudiation in s3.2. and you'd only need to add one availability?  If you're going to stick with CIA then please add authorization and authentication in s3.2.

2) s3: After reading the first paragraph in s3 and comparing it to the output of the IAB workshop (RFC1636) I'm left wondering if it's doing the same thing.  RFC 1636 says:

  Securing the routing protocols seems to be a straightforward
  engineering task.  The workshop concluded the following.

   a)   All routing information exchanges should be
        authenticated between neighboring routers.

   b)   The sources of all route information should be

   c)   Although authenticating the authority of an injector of
        route information is feasible, authentication of
        operations on that routing information (e.g.,
        aggregation) requires further consideration.

S3 closes with:

  In the case of routing security the focus is directed
  towards the elements associated with the establishment and
  maintenance of network connectivity.

The word focus kind of threw me and later in s3.4 you list the fundamental functions of a routing protocol.  Is the threats or the things you're trying to secure.  And, as Steve pointed out in the secdir review most think of routing security is ensuring the proper functioning of the routing protocol.  And, you say you're using definitions from RFC 4949 but the one for "security".

Later in the paragraph you have "authentication, and potentially integrity, and confidentiality" kind of hangs there after authorization.  Authentication, integrity, and confidentiality of what?  Also if you're going to do authentication I guess you might not need integrity, but I'd sure like to know how that happens.

Maybe some tweaks could solve all this: 

Routing security, in essence, is about ensuring the routing protocol operates correctly [insert reference if there is one].  It entails measures to ensure ...

and then (injectors was the IAB's word and maybe we can come up with a better one - or we define a new term in the definitions section)

State changes would thereby involve not only authorization of injector's actions, authentication of injectors, authentication, integrity, and potentially confidentiality of routing data, but also proper order of state changes through timeliness, since seriously delayed state changes, such as commands or updates of routing tables, may negatively impact system operation.

3) s3/3.1: in s3 you say:

 A security assessment can
 therefore begin with a focus on the assets or elements of information
 that may be the target of the state changes and the access points in...

and in s3.1 you say:

 An asset implies an important system component (including
 information, process, or physical resource),

But asset is also defined in RFC 4949 as:

  $ asset
    (I) A system resource that is (a) required to be protected by an
    information system's security policy, (b) intended to be protected
    by a countermeasure, or (c) required for a system's mission.

resource is better than component in my mind (see definition in RFC 4949) so how about the following in s3:

 A security assessment can
 therefore begin with a focus on the assets [RFC4949]
 that may be the target of the state changes and the access points in…

and in s3.1:

 An asset is an important system resource (including
 information, process, or physical resource),

4) Please provide a pointer to the concept of "control plane".  Would RFC 6192 do as a pointer or maybe add definitions in the definitions section:

control plane: Supports routing and management functions.

forward plane: Responsible for receiving a packet on an incoming interface, performing a lookup to identify the packet's next hop and determine the best outgoing interface towards the destination, and forwarding the packet out through the appropriate outgoing interface.

Also, are we just talking about control plane security here?  If that's true can we say way, way sooner - like in the abstract/introduction?

  A systematic approach is used in defining and evaluating the security
  threats for the control plane.

and then else where as appropriate

5) s3.1: r/components and mechanisms/assets, points of access, and process

6) s3.1: It's worth reiterating that the Figure is just about the control plane:

  All of this is done on the control plane. (assuming it is)

7) s3.1: The "route generation" process is missing from the Asset/PoA lists shouldn't it be there?.  Also there's a database but it's not listed is that part of "memory"?  Isn't "node" without a qualifier missing too?

8) s3.2: I thought this was about the control plane?  Why does the availability paragraph talk about forwarding "services"?

9) s3.2: The last paragraph has to be more tightly coupled to ROLL.  I'm afraid of a food fight between the various routing security groups that are doing work in this space because they're not all implementing enforcement mechanisms for the services described in s3.2.

10) s3.3: Please add sleepy node to the definitions section: maybe:

  sleepy node: A node that is not functional, but immediately available.

11) s3.3: What does this mean and why:

  In addition, the choices of security mechanisms are more stringent.

12) s3.3: Highly directional traffic: Are you trying to say that the LBRs are higher valued targets and warrant something different than the regular nodes?

13) s3.4: misappropriated seems like the wrong word based on later sections.  Masquerade seems like what you're trying to protect against, but that's covered by the peer authentication process.

14) s3.4: How about:

In conjunction, it is necessary to be assured of

 o  the authenticity and legitimacy of the participants of the routing
    neighbor discovery process;


In conjunction, it is necessary to be assured that

   o  authorized peers authenticate themselves during the routing
      neighbor discovery process;

15) s3.4: I think you could drop eavesdropping and just say unauthorized exposure

16) s4: We need to either define the threat sources or point to RFC 4953.  There's really only two outsiders and byzantine.

17) s4.1.1: r/sniffing (passive/passive wiretapping (reading
            r/(evaluation/(e.g., evaluation

18) 4.2.2: identity misappropriation is really about peer authentication and masquerading

19) s4.3.2: nice ascii art

20) s5.1.1: encryption does not counter deliberate exposure attacks.

21) s5.1.2: Passive wiretapping (“sniffing” to the authors) does not include device compromise.

22) s5.1.3: TA is always a passive attack, so the description here “… may be passive…” is wrong.  Just strike may be passive.

23) s5.2.3: r/liveliness/liveness

24) s5.3.2: r/ energy store quicker/ energy store more quickly

25) s6: difficult to parse: The assessments and analysis in Section 4 examined all areas of threats and attacks that could impact routing, and the countermeasures presented in Section 5 were reached without confining the consideration to means only available to routing.

26) s6.1: r/and improve vulnerability against other more direct attacks/and reduce vulnerabilities relative to other attacks

27) s6.2: Can't do security but can keep logs ;)

28) s6.4: r/Security Key Management/Key Management

29) s6.5.1: r/diversified needs/diverse needs

30) I have to admit that I fully expect a consideration about sleep nodes' friend grumpy node.  He's likely to cause all the problems.

(Adrian Farrel) Yes

Comment (2013-03-12 for -01)
No email
send info
The authors are working on the SecDir review by Stephen Kent and expect to address the issues before the document appears on a telechat.

(Jari Arkko) No Objection

Comment (2013-03-27 for -01)
No email
send info
Thanks for a well written and important document. I particularly liked the fact that you treated byzantine attacks and key management as a part of the analysis.

A couple of small comments, however:

Section 6.5.1 (Architecture) misses a few aspects on the comparison lower layer vs. routing protocol layer security. Everything that you say about it is correct, but one thing you do not talk about are the problems of providing the exact security services to upper layers that they need. Some of the typical issues include the need to access security information at the routing layer that may be unaware of the exact security parameters, peer identifiers, and other aspects that happened at a lower layer. Similarly, some applications may need security policies that are not easily expressed in crude lower-layer policy models (such as packet filter patterns). A lower-layer mechanism may be run hop-by-hop, whereas the routing layer mechanism may be end-to-end or even secure data objects rather than packets.

The document also touches very little on deployment aspects of the potential security models. In my view, those are often the hardest to solve in a satisfactory manner. I liked the few words that Section 6.4 said about credential configuration, however.

(Richard Barnes) No Objection

(Gonzalo Camarillo) No Objection

(Brian Haberman) No Objection

Comment (2013-03-26 for -01)
No email
send info
This is strictly a non-blocking comment... I am not a fan of the way that 2119 keywords are cannibalized in sections 6.x.

(Joel Jaeggli) No Objection

Comment (2013-03-26 for -01)
No email
send info
while the disclaimer on 2119 language in section six is fairly clear I'd rather see it simply not use it. e.g. switch to lower case leave the disclaimer more or less intanct.

Barry Leiba No Objection

Comment (2013-03-27 for -01)
No email
send info
This is one of those "I trust others" ballots: I trust the Sec ADs to be especially thorough on this document, and on a quick run-through I'm happy to let them handle the main issues.

I also have to agree with Brian that using SHOULD and MAY in Section 6 in a way that varies from the meaning in RFC 2119 is, though it's explained, likely to lead to some level of confusion.  That said, given what this document is describing and the fact that strict interpretation according to 2119 doesn't make sense, I think it will work well enough, and, in the end, I'm OK with it.

(Ted Lemon) No Objection

(Pete Resnick) No Objection

Comment (2013-03-27 for -01)
No email
send info
History is sometimes amusing: I see that all of the capitalized words in section 6 were due to a comment made by Peter Saint Andre during evaluation of draft-ietf-roll-security-framework saying that things should be capitalized. Now you have ADs saying they shouldn't be. Isn't that wonderful? I don't think you need to go back to lowercase, but I think you do need to make one change:

One way or the other, you need to remove the reference to 2119 at the top of the document. What you're doing in section 6 is not 2119 usage, and you've explained in section 6 what you are doing with those capitalized terms, so the reference to 2119 (and the template text at the top of the document) are just wrong. Yes, the idnits checker will complain. There is no requirement that your document pass idnits. You just tell the RFC Editor that this document is not using 2119 and you intended not to include the reference; end of story. I'm not going to bother putting a DISCUSS on the document for this unless Adrian really insists; I trust that you all can just take care of it.

Now, that leaves Barry, Brian, and Joel's question about whether to capitalize it all. Like Barry, I'm not convinced it matters. You explained how you're using the terms, and I think that's fine. It may reduce confusion if you lowercase or choose other "magic" words, but I think that choice is entirely up to the WG.

(Martin Stiemerling) No Objection