Dear Authors, I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Document Reviewed - Security Threats for the Optimized Link State Routing Protocol version 2 Link to Document - https://tools.ietf.org/html/draft-ietf-manet-olsrv2-sec-threats-03 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