Re: [manet] Review of draft-ietf-manet-olsrv2-sec-threats-03

[Abdussalam Baryun <[e-mail]>]

I recommend that if a reviewer did not find the answer to the simple
security question then the answer should be clear in the document. Please
note that this protocol has many RFCs involved but still this draft needs
to answer clearly the security threat questions. I think maybe
the confusion is that the draft refers to many drafts and does not clarify
the differences between packets and messages, not sure but the reviewer can
help with his observations. The main issues of threats is always about
packets and messages, so why not clarify those differences rather than
referring to other documents.

- We may understand from the below answer is that the question answer is
YES, and  NO if using ICVs or signatures. It states in the draft in page 4,
as OLSRv2 SHOULD use 7183 and MAY use other ....... (it is better not to
use MAY if you don't define/determine the other alternative).

- Section 3.2 page 7,  mentions the attacks threats of modify hop-limit. It
also mentions that hop-limit is not protected by integrity check,,, ( which
is  7183).

Recommend to clarify in draft:
The manet packet has no longer than one hop, it's messages that have
the hop-limit that may be attacked. So the attacker to manet using 7183,
 just can change the hop-limits of messages if has the keys.


AB

On Mon, Dec 19, 2016 at 12:40 PM, Dearlove, Christopher (UK) <
[e-mail]> wrote:

> Elwyn Davies
> > s3.2:  I do not know enough about the details of NHDP and OLSRv2 to know
> if this is a silly question:  Would it be possible for a compromised node
> to perform hop-limit or hop-count modification attacks even with RFC 6183
> security in place just by modifying these fields and reforwarding the
> packet even if it wasn't actually in the network topology?   If so, it
> would be desirable to mention this if it can do any harm.
>
> No, not a silly question at all. But there are details that make the
> answer longer than yes or no.
>
> (Typo: RFC 6183 is RFC 7183.)
>
> You need to distinguish packets from messages (this is RFC 5444
> territory). And NHDP doesn't matter here, as its message (HELLO) is not
> forwarded and any hop count or limit is either ignored or possibly used as
> a reason to reject.
>
> So OLSRv2 messages (TC) are forwarded, but at each hop they are put into a
> packet. That packet is assembled from one or more messages, and at each hop
> it is broken apart and a new packet formed. So the TC message may share a
> packet with different other messages at each hop.
>
> RFC 7183, which forwards to RFC 7182 where the actual work is defined,
> allows you to protect either messages, or packets (or both). Packet
> protection protects hop count and hop limit, but has other limitations (it
> is not end to end). Message protection is applied to each message, and is
> end to end (or rather, originator to each processing/forwarding router) but
> does not protect hop count and hop limit.
>
> So if using RFC 7183/7182 just to protect messages (it also covers sender
> addresses) then there is an attack. Attacker receives packet, sends new
> packet that resets hop count and limit in those messages it includes in a
> new packet to only one more hop before end of life. Sends quickly (normal
> forwarding may be delayed, especially if using RFC 5148) and possibly even
> elsewhere in network (wormhole attack). This "penultimate hop" message
> poisons the real message, if it arrives later, as it is seen before, and
> not forwarded, while the penultimate hop message will go one hop and stop.
> (Can we do this with a "last hop" message to poison even more successfully?
> That I would need to check some details in RFC 7181 to determine.)
>
> Could this be prevented? I can imagine a revision of RFC 7181's forwarding
> rules that recorded hop count/limit, and if seeing a longer range message
> decided to forward that even if seen before with a lower range. But that
> introduces a new attack of creating a sequence of increasing range messages
> to add to the traffic load. Or you could use both packet and message ICVs,
> which does prevent this attack but increases overhead. Or (potential future
> that I know someone is working on, but is not a solution now as far as I
> know) find a form of aggregating signature that overcomes this problem
> efficiently.
> ********************************************************************
> This email and any attachments are confidential to the intended
> recipient and may also be privileged. If you are not the intended
> recipient please delete it from your system and notify the sender.
> You should not copy it or use it for any purpose nor disclose or
> distribute its contents to any other person.
> ********************************************************************
> _______________________________________________
> manet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/manet
>