Subject: Re: [manet] NHDP-sec-threats feedback

From: Jiazi YI <[email-masked]>
Date: Mon, 6 Aug 2012 18:18:54 +0200

Dear John, 

Thanks for your comments, please check inline:

On Jul 31, 2012, at 3:39 PM, John Dowdell <[email-masked]> wrote:

> 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. 

> 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. 

> 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. 

>  
> However, some specifics relating to sequence numbers.
>  
> If the attacking node sent control packets with random sequence numbers, and the receiving node was expecting linearly increasing sequence numbers, would an implementation ignore packets sent with lower sequence numbers than the highest sequence number sent? 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. 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.

An attack vector related to sequence numbers has been addressed in section 4.5 Sequence Number Attack. http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-00#section-4.5

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. 

best 

Jiazi

>  
> John
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph Macker
> Sent: 31 July 2012 01:09
> To: [email-masked]
> Subject: [manet] NHDP-sec-threats feedback
>  
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: Ulrich Herberg <[email-masked]>
Date: Wed, 22 Aug 2012 13:50:16 -0700

Dear John,

some additional comments:

On Mon, Aug 6, 2012 at 9:18 AM, Jiazi YI <[email-masked]> wrote:

> 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.
>
>
>
> An attack vector related to sequence numbers has been addressed in section
> 4.5 Sequence Number Attack.
> http://tools.ietf.org/html/draft-ietf-manet-nhdp-sec-threats-00#section-4.5
>
> 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

****

John****
------------------------------
*From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
 *Joseph Macker
*Sent:* 31 July 2012 01:09
*To:* [email-masked]
*Subject:* [manet] NHDP-sec-threats feedback****

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 at
http://tools.ietf.org/wg/manet/agenda

The authors are asking for consideration of WG LAST CALL on this document
so please comment.

-Joe****