Subject: [Gen-art] Review of draft-ietf-manet-olsrv2-sec-threats-03

From: Elwyn Davies <[email-masked]>
Date: Sun, 18 Dec 2016 11:56:03 -0800

Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;.

Document: draft-ietf-manet-olsrv2-sec-threats-03.txt
Reviewer: Elwyn Davies
Review Date: 2016/12/18
IETF LC End Date: 2016/12/20
IESG Telechat date: 2017/01/05

Summary: Ready with nits

Major issues: 

None.

Minor issues:

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.

s6:  I am unclear whether the RFC 6183 security mitigates all the
threats mentioned  here and in RFC 7186.  It would be useful to list
any that remain unmitigated at the end of s9 as items for further
study (or say that all of these are covered).   

Nits/editorial comments:

idnits indicates that RFC 6779 has been obsoleted by RFC 7939.  I
think this ref ought to be updated.

I noticed that Ian Chakeres' affiliation is out of date.

Abstract: s/threats of/threats that might apply to/

s1, para 2: s/requirements presented/requirements that need to be
addressed /

s1, para 2: s/utopia/utopian/

s1, para 2:
OLD:
   For the
   Internet, with an increase in users, an increase in attacks and
   abuses followed necessitating a change in recommended practices.
NEW:
   With deployent in the wider 
   Internet, with a resultant increase in user numbers, an increase in
attacks and
   abuses has followed necessitating a change in recommended
practices.
ENDS

s1, para 3: s/often is/is often/

s1, para 3: s/particular/greater/

 s1, para 3:
OLD:
there is commonly no physical
   protection as otherwise known for wired networks.
NEW:
there are commonly no physical constraints on the conformation of
nodes and 
   communication links that make up the network as could be expected
for
   wired networks.
ENDS

s1, para 4: s/secured/well-secured/

s1, para 2: s/to OLSRv2/of OLSRv2

s1,next to last para: It would be good to reference RFC 6130 for NHDP
here.

s1.1, para 1:
OLD:
Link State Advertisements, They are described in the
   below with sufficient details for elaborating the analyses in this
   document.
NEW:
Link State Advertisements. They are described in the sections
   below with sufficient details to allow elaboration of the analyses
in this
   document.
ENDS

s1.3: s/correctly looking/apparently correct/

s1.4; s/henceforth/henceforth identified as/

s1.3: s/disrupt the the LSA process,/disrupt the LSA process,/

s3, para 1: s/TCs to not being delivered to/TCs not being delivered
to/

s3.1, para 1: s/a jittering/a jittering mechanism/

s3.2.1, para 1: s/forwarding the message/forwarding for the message/

s3.2.1, para 2: s/transmissions arrives/transmissions arrive/

s4.3.1, s4.3.2 and s5.1:  The statements that 'this threat can be
mitigated...' are premature and belong to s6.  Suggest removing the
sentences.

s4.4, para 6: 
OLD:
The compromised OLSRv2 router will indicate its willingness to be zero
(thus, avoid being selected as MPR)
NEW:
The compromised OLSRv2 router will indicate its willingness to be
selected as an MPR as zero (thus, avoid being selected as MPR)
ENDS

s5.1, para 1:
OLD:
The inconsistent topology maps due to neighborhood discovery has been
NEW:
The creation of inconsistent topology maps due to neighborhood
discovery has been
ENDS

s6.2.1, "Modifying the hop limit/count": I think you mean "mutable"
rather than "mutual" (2 places)!

s6.2.3, "Identity Spoofing": s/may further allow to revoke/may give
the possibility of revoking/

s9: There is some discussion as to whether an Informational RFC can
have Normative References.  I think it shouldn't, but if it does then
I would argue that RFC 6130 and RFC 7183 are also normative.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 19 Dec 2016 10:40:10 +0000

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 19 Dec 2016 21:39:21 +0200

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) <
[email-masked]> 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.
>
> 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.
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: Christopher Dearlove <[email-masked]>
Date: Mon, 19 Dec 2016 20:06:22 +0000

On 19 Dec 2016, at 19:39, Abdussalam Baryun <[email-masked]> wrote:
> 
> 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).
> 
> 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.

There are a number of errors in the above, which I’m afraid I lack the patience to spell out in detail.

But it does correctly point out that section 3.2 discusses the impact of attacks on hop count/limit - in fact in more detail than I did. And that this is not protected against by 7183 is indicated in section 6.2.1. (The keys are not required.)

However there is a weakness in section 6, which is that it seems to only be considering message ICV use. But, as I had forgotten in my previous comment, although RFC 7182 defines packet and message level protections, RFC 7183 only discusses the message protection. (That will be because packets are RFC 5444 constructs, not limited to carrying OLSRv2 and NHDP.) Packet level protection therefore is correctly excluded if only considering RFC 7183, however I think a mention of packet protection using RFC 7182 would not be out of place. (Protecting hop count and limit is the main gain from packet protection over message protection, the other is some processing gain if using something more expensive like RFC 7859 - an RFC 7182 addition. The main losses are in trust model and the impact of key loss when not using a single shared key - as for RFC 7859 but not RFC 7183’s chosen option from RFC 7182.)