On Mon, Aug 6, 2012 at 9:18 AM, Jiazi YI
<ietf <at> jiaziyi.com> wrote:
Dear John,
Thanks for your comments, please check inline:
Some comments on NHDP-sec-threats.
The quality of the implementation is outside of the scope of this document, but here will be some variables in how robustly the protocol has been implemented.
It's probably hard to consider the quality of the implementation, but misconfiguration of certain parameters of the protocol is worth to think about.
I agree with Jiazi. This document investigates security threats to the protocol itself, not to a specific implementation. A bad implementation can always lead to security flaws, even if the specification of the protocol has no vulnerabilities.
A simple implementation will be considerably less robust than one with comprehensive error and failed state detection.
Maybe we have a different definition of *simple*, but I kind of like simple implementation :-P . Of course, those with more consideration of error handling will be more robust.
I also agree with Jiazi; simple code often entails much less risk of security flaws of the implementation (such as buffer overflows etc) than long, complex code. But again, the scope of the draft is the protocol, not implementations.
Links with high bit error rates are particularly difficult to cater for, since implementations may simply crash when there are too many simultaneous error conditions.
From the view of a routing protocol, I would rather say "packet loss"? The bit error should be handled at phy/link layer. For the routing protocol, the packet is either successfully received, or lost. I think in that case, for NHDP, it's the parameters related to interval that handles the holding time in the information base.
NHDP is supposed to work on very lossy channels when using a suitable link quality mechanism (and I have tried that myself with very high loss rates). As such, there is no error condition issued, but rather it is the normal expected behavior of NHDP. Using timers and link quality, NHDP will simply change the status of a link if too many packets are lost. Using hysteresis functions, it is assured that the link does not frequently flip between LOST/HEARD status. If the implementation crashes in these situations, it is not a security flaw of the protocol, but rather a sign that the implementation has issues.
However, some specifics relating to sequence numbers.
If the attacking node sent control packets with random sequence numbers,
Do you talk about packet sequence numbers or message sequence numbers (using RFC5444 terminology)?
and the receiving node was expecting linearly increasing sequence numbers,
NHDP does not expect linearly increasing sequence numbers. In fact, NHDP does not even require that HELLO messages contain sequence numbers. They may be used for link quality mechanisms, but that is out of scope of the specification of NHDP.
would an implementation ignore packets sent with lower sequence numbers than the highest sequence number sent?
For the above reasons: no (both for packet sequence numbers and message sequence numbers)
An example: say a node was expecting to receive packets 1, 2, 3, 4, 5 and actually received packets 10, 15, 12, 7, 20, 11, then the receiver would process packets 10, 15 and 20 and discard 12, 7 and 11, but will waste processing time doing so.
Note that RFC5444 allows for parsing a message only partially, e.g. first the message header containing a sequence number, and only later the message body.
The implementation may decide on supplementary action if the sequence numbers are spread so far apart, as that may give the illusion that this link has a higher packet loss than is actually the case.
We currently just consider an attacker generates HELLOs with increased sequence numbers that blank out the legitimate HELLOs. In the cases of high packet loss you mentioned (for example, receive 10, 15, 12, 7, 20, 11 from a legitimate router), my first reflection is that it's not a security issue, but an issue of parameter setting of the routers. In your example, message 7, 11, 12 will be dropped, of course. In the meantime, it's the routing protocol which decides the routing information base, based on REFRESH_INTERVAL, L_HOLD_TIME, etc.
Actually, I think that section 4.5 is incorrect for NHDP; it seems to belong into an OLSRv2-sec-threats document, since sequence numbers are used in TC messages only (not in HELLOs), and TCs checked for possible duplicate processing/forwarding only in OLSRv2, not in NHDP. I will discuss that with my co-authors.
Regards
Ulrich
I apologize to Jiazi and co-authors as we accidentally skipped one of the slide sets at this afternoon's meeting.
Please review the slides for NHDP-sec-threats located athttp://tools.ietf.org/wg/manet/agenda
and see draft-ietf-manet-nhdp-sec-threats-00
The authors are asking for consideration of WG LAST CALL on this document so please comment.
-Joe
_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet
RSS Feed