Last Call Review of draft-ietf-roll-security-threats-09
review-ietf-roll-security-threats-09-rtgdir-lc-bhatia-2014-08-26-00
Request | Review of | draft-ietf-roll-security-threats |
---|---|---|
Requested revision | No specific revision (document currently at 11) | |
Type | Last Call Review | |
Team | Routing Area Directorate (rtgdir) | |
Deadline | 2014-08-28 | |
Requested | 2014-08-18 | |
Authors | Tzeta Tsao , Roger Alexander , Mischa Dohler , Vanesa Daza , Angel Lozano , Michael Richardson | |
I-D last updated | 2014-08-26 | |
Completed reviews |
Genart Last Call review of -00
by Peter E. Yee
(diff)
Genart Last Call review of -09 by Peter E. Yee (diff) Genart Telechat review of -10 by Peter E. Yee (diff) Secdir Last Call review of -00 by Stephen Kent (diff) Secdir Telechat review of -01 by Stephen Kent (diff) Rtgdir Last Call review of -09 by Manav Bhatia (diff) |
|
Assignment | Reviewer | Manav Bhatia |
State | Completed | |
Request | Last Call review on draft-ietf-roll-security-threats by Routing Area Directorate Assigned | |
Reviewed revision | 09 (document currently at 11) | |
Result | Not ready | |
Completed | 2014-08-26 |
review-ietf-roll-security-threats-09-rtgdir-lc-bhatia-2014-08-26-00
Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-roll-security-threats-09 Reviewer: Manav Bhatia Review Date: 25-08-14 IETF LC End Date: 28-08-14 Intended Status: Informational Summary: I have some concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: This document presents a threat analysis for securing the routing protocols used in LLNs which are more prone to packet losses and other vulnerabilities. It then discusses how those attacks/threats can be mitigated. Major Issues: (1) Sec 7.2.2. "Countering Overclaiming and Misclaiming Attacks" says that " counter to overclaiming and misclaiming may employ: comparison with historical routing/topology data;" I don't understand how this will work. Assume node A was always a leaf node and was never attached to any routing device. Later, a new router gets attached to this node. The node A now starts advertising this new router. How will the peers know whether it's a legitimate advertisement or an "overclaim" from node A? I don't agree with notion that somebody could look at the historical data to figure out if a router is over/under claiming. I also don't think it's a good idea to suggest that we "restrict realizable network topologies" to counter overclaim/misclaim attacks. (2) Sec 7.3.2 "Countering Overload Attacks" suggests that "overload attacks" can be countered by "isolate nodes which send traffic above a certain threshold based on system operation characteristics;". Has this been adequately discussed in the WG? It's certainly possible that in an event of reroute/reconvergence a certain node can momentarily get more traffic than the threshold. Ordinarily, such nodes only drop the additional traffic. However, this document recommends "isolating" such nodes. Doing this imo can actually worsen the problem and will have a cascading effect where a different node now becomes overloaded. I would suggest that a better way to avoid the overload attack is by treating such routers/nodes as leaf nodes in their graph. This would mean that we use this router/node for only reaching the directly connected devices and is never placed on the transit path to reach other nodes/routers. Minor Issues: (1) A common threat in routing protocols is that there is some unauthorized entity that somehow manages to gain access to keying material. Using this material, the attacker can send packets that pass the authenticity checks based on Message Authentication Codes (MACs). The most obvious way to mitigate such threat is by periodically changing the keys currently in use by the legitimate routing peers. Hence routing protocols designed for LLN must provide provision to easily change their keying material. Additionally security mechanisms designed for RPL must be such that the operators can quickly change keys without disrupting the routing system (data loss) and with minimal operational overhead/expense. If there is a significant overhead than this can lead to the keys not being changed often enough. I don't think this aspect is covered in the document. (2) Nodes in this environment can be installed but not switched on for quite some time. How would such devices get the updated keying material if it has changed by the time these get turned on? On a related note, what happens if these nodes support an authentication/encryption algorithm that gets deprecated by the time these nodes get switched on -- can happen if this particular node lies dormant for a few years before its turned on (refer to sec 4.3) (3) An automated key management protocol is a very important component of the security framework. Do all nodes in the LLN need to be manually configured? This may not be possible if there are large number of nodes in the routing domain. Wouldn't it make sense to actually discuss this (4) Sec 4.4. "RPL Security Objectives". Are we interested in message contents validation? Lest there is any doubt let me clarify that I am not talking about message integrity. I am talking about ensuring that a claim made in the route advertisement is indeed correct before accepting it (like SIDR). If we're not doing this, then it might help to explicitly state that message content validation is out of scope. If you're adding this, then a note or two on why would be extremely helpful. (5) Sec 4.4 says " Hence, routing in LLNs needs to bootstrap the authentication process and allow for flexible expiration scheme of authentication credentials." Can you explain this a bit more? Will this not lead to a circular dependency where routing bootstraps security, but you need security already in place for routing to work (to ensure we're speaking to an authorized node)? (6) Sec 7.3.3 "Countering Selective Forwarding Attacks". Are you really suggesting that RPL should redundantly flood protocol messages over multiple paths in the hope that at least one will make it to the destination. Given the delicate energy and network utilization constraints this just doesn't look right. Shouldn't we focus more on ensuring that we don't get an insider malicious node than on what we can do once we have one inside our routing domain? (7) Sec 7.3.3 suggests "dynamically selecting the next hop from a set of candidates." to counter selective forwarding attacks. I am not sure i completely understand the point. Are you suggesting that we should consider multiple paths when constructing the shortest path tree? This will only work when you have ECMP because its only then that you have a set of nexthops that you can use without affecting the total cost to reach the destination. Without ECMP, how can you have a set of nexthops to choose from? I don't think you're alluding to pinning the path here? (8)7.3.4 "Countering Sinkhole Attacks" suggests "isolate nodes which receive traffic above a certain threshold;". I disagree doing this without further qualifying on what's meant by a "certain threshold" for the same reason as i cited above in (4). Nits: (1) There are several instances where RFC 2119 keywords are used. While I personally don't have an issue with using those keywords in an Informational draft, I was grilled in the IESG review on this and went through the pain of removing those at the last minute. (2) Sec 6 describes the threats and the possible attacks on RPL. In this context the title of Sec 6.1 is very clear and the reader understands the threat/attack being discussed in the following subsection. However the title of Sec 6.2 is very vague. I had to read the entire subsection to understand what the subsection was about. I think what you want to cover are the threats you get exposed to if your system *lacks* confidentiality. Cheers, Manav