Security Threats to the Optimized Link State Routing Protocol Version 2 (OLSRv2)
draft-ietf-manet-olsrv2-sec-threats-04

[Ballot discuss]

I have two things I'd like to discuss to see if
changes are needed or not:

(1) Neither this nor RFC7186 seem to consider battery
depletion attacks. Why is that ok?

(2) 6.2: HMAC is *not* a digital signature mechanism.
While loose terminology may be ok elsewhere, in this
case, you shouldn't do that as it can lead to wrong
conclusions. Digital signatures do provide origin
authentication of sorts, but MACs do not, especially
if keys are shared. It is not clear to me that some of
the claims in 6.2.x of attacks being mitigated are in
fact correct, given shared secrets. (Note: It could be
that the claims are correct, I didn't have time to
check back on all the vulnerability definitions,
sorry. But I'd like to check, given the defective
terminology.)

[Ballot comment]
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.

[Ballot comment]
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

operating with the assumption, that participants can

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



operating with the assumption, that participants can

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


P4

  A first step towards hardening against attacks disrupting the

  connectivity of a network, is to understand the vulnerabilities of

  routing protocol,

  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

They are described in the below with sufficient..

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

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


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

[Ballot comment]
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.

[Ballot comment]
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."

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-manet-olsrv2-sec-threats-03.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: "Justin Dean" , draft-ietf-manet-olsrv2-sec-threats@ietf.org, manet-chairs@ietf.org, manet@ietf.org, bebemaster@gmail.com, aretana@cisco.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Security Threats for the Optimized Link State Routing Protocol version 2 (OLSRv2)) to Informational RFC


The IESG has received a request from the Mobile Ad-hoc Networks WG
(manet) to consider the following document:
- 'Security Threats for the Optimized Link State Routing Protocol version
  2 (OLSRv2)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-12-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document analyzes common security threats of the Optimized Link
  State Routing Protocol version 2 (OLSRv2) and describes their
  potential impacts on Mobile Ad Hoc Network (MANET) operations.  It
  then analyzes which of these security vulnerabilities can be
  mitigated when using the mandatory-to-implement security mechanisms
  for OLSRv2, and how the vulnerabilities are mitigated.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/ballot/


No IPR declarations have been submitted directly on this I-D.

=== AD Review of draft-ietf-manet-olsrv2-sec-threats-03 ===

Dear authors:

I just finished reading this document.  I have some minor comments (mostly nits) below; please consider them along with any other Last Call comments you might get.

I am starting the IETF Last Call and will schedule this document in the next available IESG Telechat.

Thanks!

Alvaro.


C1. Do we really need all the references in the Introduction to describe OSLRv2?  I think that a reference to RFC7181 is enough.  Trying to be exhaustive has the risk of missing other potential references; for example, RFC7466 Updates RFC7181, but it isn’t mentioned anywhere.  I’m not suggesting that you add a reference to RFC7466, but that you only use RFC7181 when describing OLSRv2 (in this part of the Introduction).

C2. s/RFC6779/RFC7939

C3. s/the the/the

C4. s/TCs to not being delivered/TCs not being delivered

C5. Section 3.1: "…and the legitimate message will be discarded as a duplicate message."  I think that a little more qualification may be needed here: the phrase above seems to assume spoofing of the ID or a topology as shown in Figure 1 -- please clarify and/or point at Figure 1.

C6. s/when a receives a TC from F/when A receives a TC from F

C7. s/E will have a choice…as illustrated in Figure 9(b)./E will have a choice…as illustrated in Figure 9(c).

C8. s/presented in Section 5.2.1/presented in Section 5.1

C9. The Security Considerations Section basically says nothing.  It would be nice to say in it that this whole document is about security considerations – and maybe include a summary (couple of sentences).  FWIW, what stuck with me is that most of the threats can be mitigated, but many depend on RFC7183, which is not effective if the compromised router is one with valid credentials – this fact was mentioned, but brushed over fairly quickly.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?


    The intended status is “Informational”. The title page header indicates Informational.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:
Technical Summary: This document analyzes security threats of OLSRv2 (RFC 7181) and associated RFCs (RFC5148, RFC5444, RFC5497, RFC6130, RFC7182, RFC7183, RFC7187, RFC7188)

Working Group Summary: There was not much discussion of this document on the WG list, but some support was received, and no dissent was expressed.

Document Quality: The document describes the key security issues for the protcol it considers (OLSRv2).  The information is presented clearly and is easy to digest.

Personnel

Justin Dean (bebemaster@gmail.com) is the document shepherd for this document. 
Alvaro Retana (aretana@cisco.com) is the responsible AD.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
The Shepherd did a detailed review of the document and presented the comments to the list the same time this writeup is being written.  Comments were mostly editorial the review was posted to the MANET list.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
The document shepherd is satisfied that suitable reviews, and in sufficient detail, have been performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.


The document shepherd believes that no additional reviews are required or beneficial.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

The document shepherd believes that there are no such concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP

Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.


No.



(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?


While there wasn't much feedback on list about the document the shepherd has no concerns with consensus behind this document.  It's my assumption that the lack of feedback was due to lack of consern with the document rather than lack of interest in having it published.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)


No.



(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.
idnits reports one error
** The document seems to lack a both a reference to RFC 2119 and the
    recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
    keywords.
    RFC 2119 keyword, line 146: '...oyment of OLSRv2 SHOULD use the securi...'
    RFC 2119 keyword, line 147: '...      specified in [RFC7183] but MAY use another mechanism if more...'
    RFC 2119 keyword, line 150: '...      rekeying) SHOULD be considered."...'
  but these instances are included in quotes from RFC7181 so are not true errors.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as either normative or informative?


Yes.



(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?


No.



(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.


There are no downrefs.



(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


No.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).


This document does not create any registries, nor does it request any allocations from existing IANA registries.



(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.



This document does not create any registries, nor does it request any allocations from existing IANA registries.



(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.


NA