Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2)
RFC 8116

Note: This ballot was opened for revision 03 and is now closed.

(Spencer Dawkins) Yes

Comment (2017-01-04 for -03)
No email
send info
I'm no expert on OLSRv2, and this may be the clearest security threats doc I've seen. Thanks for that!

Alvaro Retana Yes

(Jari Arkko) No Objection

Comment (2017-01-05 for -03)
No email
send info
I found Elwyn Davies' Gen-ART review very useful (and in-depth). Have the authors seen it, and have they drawn conclusions from it or the discussion that ensued on the list? I found some of the answers enlightening.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Comment (2017-01-05 for -03)
No email
send info
Below is cut/pasted Victor Kuarsingh's OPS DIR review.

Summary:

The document analyzes currently assessed (known) security threats for the OLSRv2 protocol and how these threats may impact a Mobile Ad Hoc Network (MANET).  The document points to reference documents such as RFC7186, RFC7183, RFC7188 and RFC7181 and expands on the explanation of security vulnerabilities and how such vulnerabilities can be mitigated by currently documented security mechanisms.

Text updates (suggestions / recommendations) are provided below the general feedback.

General Comments and Feedback:

Overall the document does cover the intention described per the abstract (summarized above).   Descriptions of the vulnerabilities seem consistent with documents such as RFC7186 and RFC8183 which already cover detailed explanation of similar material.  

A few comments are noted in the in-line text overview below (some NITs / suggestions on wording), and a preference for avoiding such conventions which use taxonomy like "fresh", "lie" with preference for other options like "recent", "incorrect/ erroneous " may be better suited for such a document.

Given this document is attempting to provide a incremental analysis of the security threats vs. how such threats fair with known security mechanisms in place, I would recommend that the a slight incremental bit of text (in-line or separate table) to show which mechanisms are purely related to implementation level protection (i.e. software written to enable protocol function) vs. deployment level options.  It appears most of the protections are implementation level, but there seems to (at least) two examples of mitigations which may be deployment level (e.g. it was noted about IP forwarding on Linux boxes as well as wormholes which create [potentially undesirable] direct comm paths between participating nodes.). I think noting surveillance related activity for compromised hosts may also be useful to discuss in section 6 (hard to detect, but a potential threat).

Other then that, I find the document useful as an analysis which discusses how the known threats are potentially mitigated by known mitigations.   There are a few more editing items that can be found, but that can be addressed by the RFC editor.

Section Review of -  Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2)


Abstract - ok


Introduction 


1. P2 

<old> operating with the assumption, that participants can

   be "trusted" to behave in a non-destructive way, is utopia.

<suggested>

operating with the assumption, that participants can

   be "trusted" to behave in a non-destructive way, is utopian.


P4

<old>  A first step towards hardening against attacks disrupting the

   connectivity of a network, is to understand the vulnerabilities of

   routing protocol,

<suggested>  A first step towards hardening against attacks disrupting the

   connectivity of a network, is to understand the vulnerabilities of the

   routing protocol,


1.1. OSLRv2 Overview


P1

<old> They are described in the below with sufficient..

<suggested> They are described in the sections below with sufficient..


1.1.1. Neighbour Discovery


Good


1.1.2 MPR Selection


Good


1.2 Link State Advertisement 


OK


1.3 OLSRv2 Attack Vectors


** use of honestly, lie, etc **.


2. Terminology


** for compromised router, it’s possible that only surveillance is the goal (may not actually send erroneous or incorrect information) ** . This may not be detectable, but dangerous none-the-less.


3. Topology Map Acquisition


OK


3.1 Attack on Jittering


OK


3.2 Hop-Count and Hop-limit Attacks


OK


3.2.1 Modifying the Hop Limit


OK


3.2.2 Modifying the Hop Count


OK


4. Effective Topology


OK


4.1 Incorrect Forwarding


** IP forwarding can also be turned of on commercial routers as well via config - quite easily **  Likely ops level mitigation needed.


4.2 Wormholes


** comment on section above.  **


4.3 Sequence Number Attacks


P1

<comment> Not sure the word “fresher” in the sentence “long paths or other delays, is not allowed to

   overwrite fresher information” is the best choice.  Technically, the latter arriving message due to delay/etc is fresher from the receivers point of view, but less desirable given the delay or path.


4.3.1 Message Sequence Number


<comment> similar to above comment, perhaps “recent” is a better word to use vs. “Fresh” in the sentence “”Routers will retain this larger ANSN as "the most fresh information" and …””


4.4 Indirect Jamming 


OK


5. Inconsistent Topologies


OK


5.1 Identity Spoofing


OK


5.2 Link Spoofing


OK


5.2.1 Inconsistent Topology Maps due to Link State Advertisements 


6. Mitigation of Security Vulnerabilities for OLSRv2


OK


6.1 Inherent OLSRv2 Resilience


OK


6.2 Resilience by using RFC7183 with OLSRv2


OK


6.2.1 Topology Map Acquisition


OK


6.2.2 Effective Topology


OK


6.2.3 Inconsistent Topology

Alissa Cooper No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2017-01-16)
No email
send info
Thanks for addressing my discuss points. I'm happy to chat further if
that's useful.

(Joel Jaeggli) No Objection

Comment (2017-01-04 for -03)
No email
send info
it's worth noting that inconsistent topology through Identity spoofing is actually a common enough misconfiguration in addtion to something that can be done deliberately. as for example when a configuration is copied repeatedly.

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2017-01-04 for -03)
No email
send info
The SecDir reviewer makes a good point on the draft not covering delays and that replay mechanisms will defend against the attack described in different ways.  The review is linked off the draft.  Please ket me know if there is a reason to not add this threat or if you have text to propose to address it.

Full review:
https://www.ietf.org/mail-archive/web/secdir/current/msg07028.html

Relevant section for convenience:
"One issue that I did not see discussed in the draft would be for the attacker to effectively delay packets.  For example, the attacker captures packets while jamming to prevent some stations from receiving packets.  The attacker can collect a sequence of traffic and replay at a later time, with different timing and in a different location.  Not all replay mechanisms will defend against this attack int he same way.  Sequence number validation (which appears to be allowed  in 7183) may not be as effective as timestamps, depending upon the time skew allowed.  The document does discuss timestamps , but I think it should probably make the following clearer:

There are several places in sections 4 and 5 where the document says something like "This kind of attack can be mitigated using integrity check mechanisms".  I think in most of these instances replay protection is also important.  One solution would be to remove these instances and just relay on section 6.2 which has a better description of the available protections.   Since it seems that the integrity check could be deployed with just sequence number instead of timestamps it might be good to mention that it is important to include and verify timestamps for replay protection."