[manet] Fwd: New Version Notification for draft-ietf-manet-olsrv2-sec-threats-04.txt

[Jiazi Yi <[e-mail]>]

Dear all, 

We just submitted a new revision of draft-ietf-manet-olsrv2-sec-threats. During the IETF LC of draft-ietf-manet-olsrv2-sec-threats-03, we have received valuable comments from Alvaro, Elwyn and Joseph. Thanks very much! Based on the comments provided, we updated the draft. Other than the editorial modifications, here is our reply to some of the comments and how the ID is updated:

From Alvaro (https://mailarchive.ietf.org/arch/msg/manet/K5QhTvHztC36YEU06PjbSFA0-ZA <https://mailarchive.ietf.org/arch/msg/manet/K5QhTvHztC36YEU06PjbSFA0-ZA>):

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


It’s true that it’s a bit overwhelming to put so many references in the first sentence. On the other hand,  every component of OLSRv2 contribute (positively or negatively) to security. E.g., 5444 is the container for ICV TLVs, but has mutable fields (TC messages) ; 5148 opens up for timer attacks (or, not …vtime/htime constraints, which are retained in 7181?) etc. It’d be incomplete to neglect those. So we rearranged the paragraph a bit:

The Optimized Link State Routing Protocol version 2 (OLSRv2) [RFC7181] is a successor to OLSR [RFC3626] as a routing protocol for MANETs (Mobile Ad hoc NETworks). OLSRv2 retains the same basic algorithms as its predecessor, however offers various improvements, e.g., a modular and flexible architecture allowing extensions, such as for security, to be developed as add-ons to the basic protocol. Such building-blocks and modules include [RFC5148], [RFC5444], [RFC5497], [RFC6130],  [RFC7182], [RFC7183], [RFC7187], [RFC7188], [RFC7466], etc.

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


A summary of the whole document is provided as suggested: 

This document does not specify a protocol or a procedure, but reflects on security considerations for OLSRv2, and for its constituent parts, including NHDP. The document initially analyses threats to topology map acquisition, with the assumption that no security mechanism (including the mandatory-to-implement mechanisms from [RFC7182], [RFC7183]) is in use - then, proceeds to discuss how the use of [RFC7182] and [RFC7183] mitigate the identified threats. 

When  [RFC7183] is used with routers using a single shared key, the protection offered is not effective if a compromised router has valid credentials.

From Elwyn (https://mailarchive.ietf.org/arch/msg/manet/A3-pw1iVKIqEaHwSVat0xhx7Xp4 <https://mailarchive.ietf.org/arch/msg/manet/A3-pw1iVKIqEaHwSVat0xhx7Xp4>)

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

Following the discussion in the thread https://mailarchive.ietf.org/arch/search/?email_list=manet&gbt=1&index=A3-pw1iVKIqEaHwSVat0xhx7Xp4 <https://mailarchive.ietf.org/arch/search/?email_list=manet&gbt=1&index=A3-pw1iVKIqEaHwSVat0xhx7Xp4>

We now have the following text in section 6.2.1: 

Modifying the Hop Limit and the Hop Count -
As the hop limit and hop count are not protected by [RFC7183] (since it is a mutable field, changing at every hop), this attack is still feasible. It is possible to apply [RFC5444] packet-level protection by using ICV Packet TLV defined in [RFC7182].  However, in such case, the hop-by-hop verification requires trust between each pair of neighbor routers .  

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

We added a summary in the last section (security considerations). 

From Joseph Salowey

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

We have removed related sentences and relayed to section 6.2. 

Again, thanks very much for your review!

cheers

Jiazi


> Begin forwarded message:
> 
> From: [e-mail]
> Subject: New Version Notification for draft-ietf-manet-olsrv2-sec-threats-04.txt
> Date: 12 January 2017 at 00:15:54 GMT+1
> To: "Thomas Clausen" <[e-mail]>, "Thomas Clausen" <[e-mail]>, "Jiazi Yi" <[e-mail]>, "Ulrich Herberg" <[e-mail]>, <[e-mail]>
> 
> 
> A new version of I-D, draft-ietf-manet-olsrv2-sec-threats-04.txt
> has been successfully submitted by Jiazi Yi and posted to the
> IETF repository.
> 
> Name:		draft-ietf-manet-olsrv2-sec-threats
> Revision:	04
> Title:		Security Threats to the Optimized Link State Routing Protocol version 2 (OLSRv2)
> Document date:	2017-01-12
> Group:		manet
> Pages:		24
> URL:            https://www.ietf.org/internet-drafts/draft-ietf-manet-olsrv2-sec-threats-04.txt
> Status:         https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/
> Htmlized:       https://tools.ietf.org/html/draft-ietf-manet-olsrv2-sec-threats-04
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-manet-olsrv2-sec-threats-04
> 
> Abstract:
>   This document analyzes common security threats that might apply to
>   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.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>