draft-ietf-manet-smf-sec-threats-06.txt   rfc7985.txt 
Mobile Ad hoc Networking (MANET) J. Yi Internet Engineering Task Force (IETF) J. Yi
Internet-Draft T. Clausen Request for Comments: 7985 T. Clausen
Updates: 7186 (if approved) Ecole Polytechnique Updates: 7186 Ecole Polytechnique
Intended status: Informational U. Herberg Category: Informational U. Herberg
Expires: February 28, 2017 August 27, 2016 ISSN: 2070-1721 November 2016
Security Threats for Simplified Multicast Forwarding (SMF) Security Threats to Simplified Multicast Forwarding (SMF)
draft-ietf-manet-smf-sec-threats-06
Abstract Abstract
This document analyzes security threats of the Simplified Multicast This document analyzes security threats to Simplified Multicast
Forwarding (SMF) mechanism, including the vulnerabilities of Forwarding (SMF), including vulnerabilities of duplicate packet
duplicate packet detection and relay set selection mechanisms. This detection and relay set selection mechanisms. This document is not
document is not intended to propose solutions to the threats intended to propose solutions to the threats described.
described.
This document also updates RFC7186 regarding the threats to relay set
selection mechanisms using RFC6130.
Status of this Memo In addition, this document updates RFC 7186 regarding threats to the
relay set selection mechanisms using the Mobile Ad Hoc Network
(MANET) Neighborhood Discovery Protocol (NHDP) (RFC 6130).
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It has been approved for publication by the Internet
time. It is inappropriate to use Internet-Drafts as reference Engineering Steering Group (IESG). Not all documents approved by the
material or to cite them other than as "work in progress." IESG are a candidate for any level of Internet Standard; see
Section 2 of RFC 7841.
This Internet-Draft will expire on February 28, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7985.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SMF Threats Overview . . . . . . . . . . . . . . . . . . . . . 4 3. SMF Threat Overview . . . . . . . . . . . . . . . . . . . . . 4
4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5 4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5
4.1. Attack to The Hop Limit Field . . . . . . . . . . . . . . 6 4.1. Attack on the Hop Limit Field . . . . . . . . . . . . . . 6
4.2. Threats to Identification-based Duplicate Packet 4.2. Threats to Identification-Based Duplicate Packet
Detection . . . . . . . . . . . . . . . . . . . . . . . . 7 Detection . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Pre-activation Attacks (Pre-Play) . . . . . . . . . . 7 4.2.1. Pre-Activation Attacks (Pre-Play) . . . . . . . . . . 7
4.2.2. De-activation Attacks (Sequence Number wrangling) . . 8 4.2.2. De-activation Attacks (Sequence Number Wrangling) . . 8
4.3. Threats to Hash-based Duplicate Packet Detection . . . . . 9 4.3. Threats to Hash-Based Duplicate Packet Detection . . . . 9
4.3.1. Attack on Hash-Assistant Value . . . . . . . . . . . . 9 4.3.1. Attack on the Hash-Assistant Value . . . . . . . . . 9
5. Threats to Relay Set Selection . . . . . . . . . . . . . . . . 10 5. Threats to Relay Set Selection . . . . . . . . . . . . . . . 10
5.1. Relay Set Selection Common Threats . . . . . . . . . . . . 10 5.1. Common Threats to Relay Set Selection . . . . . . . . . . 10
5.2. Threats to E-CDS Algorithm . . . . . . . . . . . . . . . . 10 5.2. Threats to the E-CDS Algorithm . . . . . . . . . . . . . 10
5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11 5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 11
5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 11 5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 11
5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 11 5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . 11
5.4. Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 12 5.4. Threats to the MPR-CDS Algorithm . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document analyzes security threats to the Simplified Multicast This document analyzes security threats to Simplified Multicast
Forwarding (SMF) mechanism [RFC6621]. SMF aims at providing basic Forwarding (SMF) [RFC6621]. SMF aims at providing basic Internet
Internet Protocol (IP) multicast forwarding, in a way that is Protocol (IP) multicast forwarding in a way that is suitable for
suitable for limited wireless mesh and Mobile Ad hoc NETworks wireless mesh and Mobile Ad Hoc Networks (MANET). SMF consists of
(MANET). SMF is constituted of two major functional components: two major functional components: duplicate packet detection (DPD) and
Duplicate Packet Detection and Relay Set Selection. relay set selection (RSS).
SMF is typically used in decentralized wireless environments, and is SMF is typically used in decentralized wireless environments and is
potentially exposed to various attacks and misconfigurations. Some potentially exposed to various attacks and misconfigurations. In a
of these attacks and misconfigurtions, in a wireless enviroment, wireless environment, some of these attacks and misconfigurations
represent threats of particular significance as compared to what they represent threats of particular significance as compared to what they
would do in wired networks. [RFC6621] briefly discusses several of would do in wired networks. [RFC6621] briefly discusses several of
these, but does not define any explicit security measures for these, but does not define any explicit security measures for
protecting the integrity of the protocol. protecting the integrity of the protocol.
This document is based on the assumption that no additional security This document is based on the assumption that no additional security
mechanism such as IPsec is used in the IP layer, as not all MANET mechanism, such as IPsec, is used in the IP layer, as not all MANET
deployments may be suitable to deploy common IP protection mechanisms deployments may be able to support deployment of such common IP
(e.g., because of limited resources of MANET routers to support the protection mechanisms (e.g., because MANET routers may have limited
IPsec stack). It assumes that there is no lower-layer protection resources for supporting the IPsec stack). It also assumes that
either. The document analyzes possible attacks on and mis- there is no lower-layer protection. The document analyzes possible
configurations of SMF and outlines the consequences of such attacks/ attacks on, and misconfigurations of, SMF and outlines the
mis-configurations to the state maintained by SMF in each router. consequences of such attacks/misconfigurations to the state
maintained by SMF in each router.
In the Security Considerations section of [RFC6621], denial-of- In the Security Considerations section of [RFC6621], denial-of-
service attack scenarios are briefly discussed. This document service-attack scenarios are briefly discussed. This document
further analyzes and describes the potential vulnerabilities of and further analyzes and describes the potential vulnerabilities of, and
attack vectors for SMF. While completeness in such analysis is attack vectors for, SMF. While completeness in such analysis is
always a goal, no claims of being complete are made. The goal of always a goal, no claims of being complete are made. The goal of
this document is to be helpful for when deploying SMF in a network this document is to be helpful when deploying SMF in a network and
and needing to understand the risks thereby incurred - as well as for for understanding the risks incurred, as well as for providing a
providing a reference and documented experience with SMF as input for reference to and documented experience with SMF as input for possible
possibly future developments of SMF. future developments of SMF.
This document is not intended to propose solutions to the threats This document is not intended to propose solutions to the threats
described. [RFC7182] provides a framework that can be used with SMF, described. [RFC7182] provides a framework that can be used with SMF,
and depending on how it is used - may offer some degree of protection and depending on how it is used, may offer some degree of protection
against the threats described in this document related to identity against the threats related to identity spoofing described in this
spoofing. document.
This document also updates [RFC7186], specifically with respect to This document also updates [RFC7186], specifically with respect to
threats to relay set selection mechanisms which are using [RFC6130]. threats to relay set selection (RSS) mechanisms that are using MANET
NHDP [RFC6130].
2. Terminology 2. Terminology
This document uses the terminology and notation defined in [RFC5444], This document uses the terminology and notation defined in [RFC5444],
[RFC6130], [RFC6621] and [RFC4949]. [RFC6130], [RFC6621], and [RFC4949].
Additionally, this document introduces the following terminology: Additionally, this document introduces the following terminology:
SMF router: A MANET router, running SMF as specified in [RFC6621]. SMF router: A MANET router, running SMF as specified in [RFC6621].
Attacker: A device that is present in the network and intentionally Attacker: A device that is present in the network and intentionally
seeks to compromise the information bases in SMF routers. It may seeks to compromise the information bases in SMF routers. It may
generate syntactically correct SMF control messages. generate syntactically correct SMF control messages.
Legitimate SMF router: An SMF router that is correctly configured Legitimate SMF router: An SMF router that is correctly configured
and not compromised by an attacker. and not compromised by an attacker.
3. SMF Threats Overview 3. SMF Threat Overview
SMF requires an external dynamic neighborhood discovery mechanism in An SMF router requires an external dynamic neighborhood discovery
order to maintain suitable topological information describing its mechanism in order to maintain suitable topological information
immediate neighborhood, and thereby allowing it to select reduced describing its immediate neighborhood, and thereby allowing it to
relay sets for forwarding multicast data traffic. Such an external select reduced relay sets for forwarding multicast data traffic.
dynamic neighborhood discovery mechanism may be provided by lower- Such an external dynamic neighborhood discovery mechanism may be
layer interface information, by a concurrently operating MANET provided by lower-layer interface information, by a concurrently
routing protocol that already maintains such information such as operating MANET routing protocol that already maintains such
[RFC7181], or by explicitly using MANET Neighborhood Discovery information (e.g., [RFC7181]) or by explicitly using the MANET
Protocol (NHDP) [RFC6130]. If NHDP is used for both 1-hop and 2-hop Neighborhood Discovery Protocol (NHDP) [RFC6130]. If NHDP is used
neighborhood discovery by SMF, SMF implicitly inherits the for both 1-hop and 2-hop neighborhood discovery by SMF, SMF
vulnerabilities of NHDP discussed in [RFC7186]. As SMF relies on implicitly inherits the vulnerabilities of NHDP discussed in
NHDP to assist in network layer 2-hop neighborhood discovery (no [RFC7186]. As SMF relies on NHDP to assist in network-layer 2-hop
matter if other lower-layer mechanisms are used for 1-hop neighborhood discovery (no matter if other lower-layer mechanisms are
neighborhood discovery), this document assumes that NHDP is used in used for 1-hop neighborhood discovery), this document assumes that
SMF. The threats that are NHDP-specific are indicated explicitly. NHDP is used in SMF. The threats that are NHDP specific are
indicated explicitly.
Based on neighborhood discovery mechanisms, [RFC6621] specifies two Based on neighborhood discovery mechanisms, [RFC6621] specifies two
principal functional components: Duplicate Packet Detection (DPD) and principal functional components: duplicate packet detection (DPD) and
Relay Set Selection (RSS). relay set selection (RSS).
DPD is required by SMF in order to be able to detect duplicate DPD is required by SMF in order to be able to detect duplicate
packets and eliminate their redundant forwarding. An Attacker has packets and eliminate their redundant forwarding. An attacker has
two ways in which to harm the DPD mechanisms, specifically it can: two ways in which to harm the DPD mechanisms. Specifically, it can:
o "deactivate" DPD, so as to make it such that duplicate packets are o "deactivate" DPD, making it such that duplicate packets are not
not correctly detected, and that as a consequence they are correctly detected. As a consequence, they are (redundantly)
(redundantly) transmitted, increasing the load on the network, transmitted, which increases the load on the network, drains the
draining the batteries of the routers involved, etc. batteries of the routers involved, etc.
o "pre-activate" DPD, so as to make DPD detect a later arriving o "pre-activate" DPD, making DPD detect a later arriving (valid)
(valid) packet as being a duplicate, which therefore won't be packet as being a duplicate and will, therefore, not be forwarded.
forwarded.
Attacks on DPD can be achieved by replaying existing packets, by Attacks on DPD can be achieved by replaying existing packets,
wrangling sequence numbers, by manipulating hash values, etc., and wrangling sequence numbers, manipulating hash values, etc.; these are
are detailed in Section 4. detailed in Section 4.
RSS produces a reduced relay set for forwarding multicast data RSS produces a reduced relay set for forwarding multicast data
packets across the MANET. [RFC6621] specifies several relay set packets across a MANET. For use in SMF, [RFC6621] specifies several
algorithms, including E-CDS (Essential Connected Dominating Set) relay set algorithms including E-CDS (Essential Connected Dominating
[RFC5614], S-MPR (Source-based Multi-point Relay, as known from Set) [RFC5614], S-MPR (Source-Based Multipoint Relay, as known from
[RFC3626] and [RFC7181]), or MPR-CDS [MPR-CDS], for use in SMF. An [RFC3626] and [RFC7181]), and MPR-CDS (Multipoint Relay Connected
Attacker can disrupt the RSS algorithm, and thereby SMF operation, by Dominating Set) [MPR-CDS]. An attacker can disrupt the RSS
degrading it to classical flooding, or by "masking" certain parts of algorithm, and thereby the SMF operation, by degrading it to
the network from the multicasting domain. Attacks on RSS algorithms classical flooding or by "masking" certain parts of the network from
are detailed in Section 5. the multicasting domain. Attacks on RSS algorithms are detailed in
Section 5.
Other than the attacks on DPD and RSS, a common vulnerability of Other than the attacks on DPD and RSS, a common vulnerability of
MANETs is "jamming", i.e., a device generates massive amounts of MANETs is "jamming", i.e., a device generates massive amounts of
interfering radio transmissions, which will prevent legitimate interfering radio transmissions, which will prevent legitimate
traffic (e.g., control traffic as well as data traffic) on part of a traffic (e.g., control traffic as well as data traffic) on part of a
network. The attacks on DPD and RSS can be further enhanced by network. The attacks on DPD and RSS can be further enhanced by
jamming. jamming.
4. Threats to Duplicate Packet Detection 4. Threats to Duplicate Packet Detection
Duplicate Packet Detection (DPD) is required for packet dissemination Duplicate packet detection (DPD) is required for packet dissemination
in MANETs because: (1) packets may be transmitted via the same in MANETs because: (1) packets may be retransmitted via the same
physical interface as the one over which they were received, and (2) physical interface as the one over which they were received, and (2)
a router may receive multiple copies of the same packet (on the same, a router may receive multiple copies of the same packet (on the same
or on different interfaces) from different neighbors. DPD is thus or on different interfaces) from different neighbors. DPD is thus
used to check if an incoming packet has been previously received or used to check whether or not an incoming packet has been previously
not. received.
DPD is achieved by maintaining a record of recently processed DPD is achieved by maintaining a record of recently processed
multicast packets, and comparing later received multicast packets multicast packets, and comparing later received multicast packets
herewith. A duplicate packet detected is silently dropped and is not herewith. A duplicate packet detected is silently dropped and is not
inserted into the forwarding path of that router, nor is it delivered inserted into the forwarding path of that router, nor is it delivered
to an application. DPD, as proposed by SMF, supports both IPv4 and to an application. DPD, as proposed by SMF, supports both IPv4 and
IPv6 and for each suggests two duplicate packet detection mechanisms: IPv6 and suggests two duplicate packet detection mechanisms for each:
1) header content identification-based DPD (I-DPD), using packet 1) IP packet header content identification-based DPD (I-DPD), in
headers, in combination with flow state, to estimate temporal combination with flow state, to estimate temporal uniqueness of a
uniqueness of a packet, and 2) hash-based DPD (H-DPD), employing packet, and 2) hash-based DPD (H-DPD), employing hashing of selected
hashing of selected header fields and payload for the same effect. IP packet header fields and payload for the same effect.
In the Security Considerations section of [RFC6621], a selection of In the Security Considerations section of [RFC6621], a selection of
threats to DPD are briefly introduced. This section expands on that threats to DPD are briefly introduced. This section expands on that
discussion, and describes how to effectively launch the attacks on discussion and describes how to effectively launch the attacks on DPD
DPD - for example, by way of manipulating jitter and/or the Hash- -- for example, by way of manipulating jitter and/or the Hash-
Assistant Value. In the remainder of this section, common threats to Assistant Value. In the remainder of this section, common threats to
packet detection mechanisms are first discussed. Then the threats to packet detection mechanisms are discussed first; then, the threats to
I-DPD and H-DPD are introduced separately. The threats described in I-DPD and H-DPD are introduced separately. The threats described in
this section are applicable to general SMF implementations, no matter this section are applicable to general SMF implementations,
if NHDP is used or not. regardless of whether NHDP is used.
4.1. Attack to The Hop Limit Field 4.1. Attack on the Hop Limit Field
One immediate DoS attack is based on manipulating the Time-to-Live One immediate Denial-of-Service (DoS) attack is based on manipulating
(TTL, for IPv4) or hop limit (for IPv6) field. As routers only the Time-to-Live (TTL, for IPv4) or Hop Limit (for IPv6) field. As
forward packets with TTL > 1, an attacker can forward an otherwise routers only forward packets with TTL > 1, an attacker can forward an
valid packet, while drastically reducing the TTL hereof. This will otherwise valid packet while drastically reducing the TTL hereof.
inhibit recipient routers from later forwarding the same multicast This will inhibit recipient routers from later forwarding the same
packet, even if received with a different TTL - essentially an multicast packet, even if received with a different TTL --
attacker thus can instruct its neighbors to block forwarding of valid essentially, an attacker can thus instruct its neighbors to block the
multicast packets. forwarding of valid multicast packets.
For example, in Figure 1, router A forwards a multicast packet with a For example, in Figure 1, router A forwards a multicast packet with a
TTL of 64 to the network. A, B, and C are legitimate SMF routers, TTL of 64 to the network. A, B, and C are legitimate SMF routers,
and X is an attacker. In a wireless environment, jitter is commonly and X is an attacker. In a wireless environment, jitter is commonly
used to avoid systematic collisions in MAC protocols [RFC5148]. An used to avoid systematic collisions in Media Access Control (MAC)
attacker can thus increase the probability that its invalid packets protocols [RFC5148]. An attacker can thus increase the probability
arrive first by retransmitting them without applying jitter. In this that its invalid packets arrive first by retransmitting them without
example, router X forwards the packet without applying jitter and applying jitter. In this example, router X forwards the packet
reduces the TTL to 1. Router C thus records the duplicate detection without applying jitter and reduces the TTL to 1. Router C thus
value (hash value for H-DPD, or the header content of the packets for records the duplicate detection value (hash value for H-DPD or the
I-DPD) but does (due to TTL == 1) not forward. When a second copy header content of the packets for I-DPD) but does not forward the
the same packet, with a non-maliciously manipulated TTL value (63 in packet (due to TTL == 1). When a second copy of the same packet,
this case), arrives from router B, it will be discarded as duplicate with a non-maliciously manipulated TTL value (63 in this case),
packet. arrives from router B, it will be discarded as a duplicate packet.
.---. .---.
| X | | X |
--'---' __ --'---' __
packet with TTL=64 / \ packet with TTL=1 packet with TTL=64 / \ packet with TTL=1
/ \ / \
.---. .---. .---. .---.
| A | | C | | A | | C |
'---' '---' '---' '---'
packet with TTL=64 \ .---. / packet with TTL=64 \ .---. /
\-- | B |__/ packet with TTL=63 \-- | B |__/ packet with TTL=63
'---' '---'
Figure 1 Figure 1
As the TTL of a packet is intended to be manipulated by As the TTL of a packet is intended to be manipulated by
intermediaries forwarding it, classic methods such as integrity check intermediaries forwarding it, classic methods such as integrity check
values (e.g., digital signatures) are typically calculated with values (e.g., digital signatures) are typically calculated by setting
setting TTL fields to some pre-determined value (e.g., 0) - such is TTL fields to some predetermined value (e.g., 0) -- for example, the
for example the case for IPsec Authentication Headers - rendering case for IPsec Authentication Headers -- rendering such an attack
such an attack more difficult to both detect and counter. more difficult to both detect and counter.
If the attacker has access to a "wormhole" through the network (a If the attacker has access to a "wormhole" through the network (a
directional antenna, a tunnel to a collaborator or a wired directional antenna, a tunnel to a collaborator, or a wired
connection, allowing it to bridge parts of a network otherwise connection, allowing it to bridge parts of a network otherwise
distant), it can make sure that the packets with such an artificially distant), it can make sure that the packets with such an artificially
reduced TTL arrive before their unmodified counterparts. reduced TTL arrive before their unmodified counterparts.
4.2. Threats to Identification-based Duplicate Packet Detection 4.2. Threats to Identification-Based Duplicate Packet Detection
I-DPD uses a specific DPD identifier in the packet header to identify I-DPD uses a specific DPD identifier in the packet header to identify
a packet. By default, such packet identification is not provided by a packet. By default, such packet identification is not provided by
the IP packet header (for both IPv4 and IPv6). Therefore, additional the IP packet header (for both IPv4 and IPv6). Therefore, additional
identification headers, such as the fragment header, a hop-by-hop identification headers, such as the fragment header, a hop-by-hop
header option, or IPSec sequencing, must be employed in order to header option, or IPsec sequencing, must be employed in order to
support I-DPD. The uniqueness of a packet can then be identified by support I-DPD. The uniqueness of a packet can then be identified by
the source IP address of the packet originator and the sequence the source IP address of the packet originator and the sequence
number (from the fragment header, hop-by-hop header option, or number (from the fragment header, hop-by-hop header option, or
IPsec). By doing so, each intermediate router can keep a record of IPsec). By doing so, each intermediate router can keep a record of
recently received packets and determine whether the incoming packet recently received packets and determine whether or not the incoming
has been received or not. packet has been received.
4.2.1. Pre-activation Attacks (Pre-Play) 4.2.1. Pre-Activation Attacks (Pre-Play)
In a wireless environment, or across any other shared channel, an In a wireless environment, or across any other shared channel, an
attacker can perceive the identification tuple (source IP address, attacker can perceive the identification tuple (source IP address,
sequence number) of a packet. It is possible to generate a packet sequence number) of a packet. It is possible to generate a packet
with the same (source IP address, sequence number) pair with invalid with the same (source IP address, sequence number) pair with invalid
content. If sequence number progression is predictable, then it is content. If the sequence number progression is predictable, then it
trivial to generate and inject invalid packets with "future" is trivial to generate and inject invalid packets with "future"
identification information into the network. If these invalid identification information into the network. If these invalid
packets arrive before the legitimate packets that they are spoofing, packets arrive before the legitimate packets that they are spoofing,
the latter will be treated as a duplicate and discarded. This can the latter will be treated as a duplicate and will be discarded.
prevent multicast packets from reaching parts of the network. This can prevent multicast packets from reaching parts of the
network.
Figure 2 gives an example of pre-activation attack. A, B and C are Figure 2 gives an example of a pre-activation attack. A, B, and C
legitimate SMF routers, and X is the attacker. The line between the are legitimate SMF routers, and X is the attacker. The line between
routers presents the packet forwarding. Router A is the source and the routers presents the packet forwarding. Router A is the source
originates a multicast packet with sequence number n. When router X and originates a multicast packet with sequence number n. When
receives the packet, it generates an invalid packet with the source router X receives the packet, it generates an invalid packet with the
address of A and sequence number n. If the invalid packet arrives at source address of A and sequence number n. If the invalid packet
router C before the forwarding of router B, the valid packet will be arrives at router C before the forwarding of router B, the valid
dropped by C as a duplicate packet. An attacker can manipulate packet will be dropped by C as a duplicate packet. An attacker can
jitter to make sure that the invalid packets arrive first. Router X manipulate jitter to make sure that the invalid packets arrive first.
can even generate packets with future sequence numbers (if they are Router X can even generate packets with future sequence numbers (if
predictable), so that the future legitimate packets with the same they are predictable), so that the future legitimate packets with the
sequence numbers will be dropped as duplicate ones. same sequence numbers will be dropped as duplicate ones.
.---. .---.
| X | | X |
--'---' __ --'---' __
packet with seq=n / \ invalid packet with seq=n packet with seq=n / \ invalid packet with seq=n
/ \ / \
.---. .---. .---. .---.
| A | | C | | A | | C |
'---' '---' '---' '---'
packet with seq=n \ .---. / packet with seq=n \ .---. /
\-- | B |__/ valid packet with seq=n \-- | B |__/ valid packet with seq=n
'---' '---'
Figure 2 Figure 2
As SMF currently does not have any timestamp mechanisms to protect As SMF does not currently have any timestamp mechanisms to protect
data packets, there is no viable way to detect such pre-play attacks data packets, there is no viable way to detect such pre-play attacks
by way of timestamps. Especially, if the attack is based on by way of timestamps. Especially, if the attack is based on
manipulation of jitter, the validation of timestamp would not be manipulation of jitter, the validation of the timestamp would not be
helpful because the timing is still valid (but with much less value). helpful because the timing is still valid (but, much less valuable).
4.2.2. De-activation Attacks (Sequence Number wrangling) 4.2.2. De-activation Attacks (Sequence Number Wrangling)
An attacker can also seek to de-activate DPD, by modifying the An attacker can also seek to de-activate DPD by modifying the
sequence number in packets that it forwards. Thus, routers will not sequence number in packets that it forwards. Thus, routers will not
be able to detect an actual duplicate packet as a duplicate - rather, be able to detect an actual duplicate packet as a duplicate --
they will treat them as new packets, i.e., process and forward them. rather, they will treat them as new packets, i.e., process and
This is similar to DoS attacks, as each packet that is considered forward them. This is similar to DoS attacks, as each packet that is
unique will be multicasted: for a network with n routers, there will considered unique will be multicasted: for a network with n routers,
be n-1 retransmissions. This can easily cause the "broadcast storm" there will be n-1 retransmissions. This can easily cause the
problem discussed in [MOBICOM99]. The consequence of this attack is "broadcast storm" problem discussed in [MOBICOM99]. The consequence
an increased channel load, the origin of which appears to be a router of this attack is an increased channel load, the origin of which
other than the attacker. appears to be a router other than the attacker.
Given the topology shown in Figure 2, on receiving a packet with Given the topology shown in Figure 2, on receiving a packet with
seq=n, the attacker X can forward the packet with modified sequence seq=n, the attacker X can forward the packet with a modified sequence
number n+i. This has two consequences: firstly, router C will not be number n+i. This has two consequences: firstly, router C will not be
able to detect the packet forwarded by X is a duplicate packet; able to detect that the packet forwarded by X is a duplicate packet;
secondly, the consequent packet with seq=n+i generated by router A secondly, the consequent packet with seq=n+i generated by router A
probably will be treated as duplicate packet, and dropped by router will probably be treated as a duplicate packet and will be dropped by
C. router C.
4.3. Threats to Hash-based Duplicate Packet Detection 4.3. Threats to Hash-Based Duplicate Packet Detection
When explicit sequence numbers in packet headers is undesired, hash- When explicit sequence numbers in packet headers is undesired, hash-
based DPD can be used. A hash of the non-mutable fields in the based DPD can be used. A hash of the non-mutable fields in the
header of and the data payload can be generated, and recorded at the header of the data payload can be generated and recorded at the
intermediate routers. A packet can thus be uniquely identified by intermediate routers. A packet can thus be uniquely identified by
the source IP address of the packet and its hash-value. the source IP address of the packet and its hash-value.
The hash algorithm used by SMF is being applied only to provide a The hash algorithm used by SMF is being applied only to provide a
reduced probability of collision and is not being used for reduced probability of collision and is not being used for
cryptographic or authentication purposes. Consequently, a digest cryptographic or authentication purposes. Consequently, a digest
collision is still possible. In case the source router or gateway collision is still possible. In case the source router or gateway
identifies that it recently has generated or injected a packet with identifies that it has recently generated or injected a packet with
the same hash-value, it inserts a "Hash-Assist Value (HAV)" IPv6 the same hash-value, it inserts a "Hash-Assist Value (HAV)" IPv6
header option into the packet, such that calculating the hash also header option into the packet, such that also calculating the hash
over this HAV will render the resulting value unique. over this HAV will render the resulting value unique.
4.3.1. Attack on Hash-Assistant Value 4.3.1. Attack on the Hash-Assistant Value
The HAV header is helpful when a digest collision happens. However, The HAV header is helpful when a digest collision happens. However,
it also introduces a potential vulnerability. As the HAV option is it also introduces a potential vulnerability. As the HAV option is
only added when the source or the ingress SMF router detects that the only added when the source or the ingress SMF router detects that the
coming packet has digest collision with previously generated packets, incoming packet has digest collision with previously generated
it actually can be regarded as a "flag" of potential digest packets, it can actually be regarded as a "flag" of potential digest
collision. An attacker can discover the HAV header, and be able to collision. An attacker can discover the HAV header and be able to
conclude that a hash collision is possible if the HAV header is conclude that a hash collision is possible if the HAV header is
removed. By doing so, the modified packet received by other SMF removed. By doing so, the modified packet received by other SMF
routers will be treated as duplicate packets, and be dropped because routers will be treated as duplicate packets and will be dropped
they have the same hash value with the precedent packet. because they have the same hash value as previously received packets.
In the example of Figure 3, Router A and B are legitimate SMF In the example shown in Figure 3, routers A and B are legitimate SMF
routers; X is an attacker. A generates two packets P1 and P2, with routers; X is an attacker. Router A generates two packets, P1 and
the same hash value h(P1)=h(P2)=x. Based on the SMF specification, a P2, with the same hash value h(P1)=h(P2)=x. Based on the SMF
hash-assistant value (HAV) is added to the latter packet P2, so that specification, a HAV is added to the latter packet P2, so that
h(P2+HAV)=x', to avoid digest collision. When the attacker X detects h(P2+HAV)=x' avoids digest collision. When the attacker X detects
the HAV of P2, it is able to conclude that a collision is possible by the HAV of P2, it is able to conclude that a collision is possible by
removing the HAV header. By doing so, packet P2 will be treated as removing the HAV header. By doing so, packet P2 will be treated as a
duplicate packet by router B, and be dropped. duplicate packet by router B and will be dropped.
P2 P1 P2 P1 P2 P1 P2 P1
.---. h(P2+HAV)=x' h(P1)=x .---. h(P2)=x h(P1)=x .---. .---. h(P2+HAV)=x' h(P1)=x .---. h(P2)=x h(P1)=x .---.
| A |---------------------------> | X | ----------------------> | B | | A |---------------------------> | X | ----------------------> | B |
`---' `---' `---' `---' `---' `---'
Figure 3 Figure 3
5. Threats to Relay Set Selection 5. Threats to Relay Set Selection
A framework for RSS mechanism, rather than a specific RSS algorithm A framework for an RSS mechanism, rather than a specific RSS
is provided by SMF. It is normally achieved by distributed algorithm, is provided by SMF. Relay Set Selection is normally
algorithms that can dynamically generate a topological Connected achieved by distributed algorithms that can dynamically generate a
Dominating Set based on 1-hop and 2-hop neighborhood information. In topological Connected Dominating Set based on 1-hop and 2-hop
this section, the common threats to the RSS framework are first neighborhood information. In this section, common threats to the RSS
discussed. Then the three commonly used algorithms: Essential framework are first discussed. Then specific threats to the three
Connection Dominating Set (E-CDS) algorithm, Source-based Multipoint algorithms (Essential Connection Dominating Set (E-CDS), Source-Based
Relay (S-MPR) and Multipoint Relay Connected Dominating Set (MPR-CDS) Multipoint Relay (S-MPR), and Multipoint Relay Connected Dominating
are analyzed. As the relay set selection is based on 1-hop and 2-hop Set (MPR-CDS)) explicitly enumerated by [RFC6621] are analyzed. As
neighborhood information, which rely on NHDP, the threats described the relay set selection is based on 1-hop and 2-hop neighborhood
in this section are NHDP-specific. information, which rely on NHDP, the threats described in this
section are NHDP specific.
5.1. Relay Set Selection Common Threats 5.1. Common Threats to Relay Set Selection
Common (i.e., non algorithm specific) threats to RSS algorithms, Non-algorithm-specific threats to RSS algorithms, including DoS
including Denial of Service attack, eavesdropping, message timing attacks, eavesdropping, message timing attacks, and broadcast storm,
attack and broadcast storm have been discussed in [RFC7186]. are discussed in [RFC7186].
5.2. Threats to E-CDS Algorithm 5.2. Threats to the E-CDS Algorithm
The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614] The "Essential Connected Dominating Set" (E-CDS) algorithm [RFC5614]
forms a single CDS mesh for the SMF operating region. It requires forms a single CDS mesh for an SMF operating region. This algorithm
2-hop neighborhood information (the identify of the neighbors, the requires 2-hop neighborhood information (the identity of the
link to the neighbors and neighbors' priority information) collected neighbors, the link to the neighbors, and the neighbors' priority
through NHDP or another process. information), as collected through NHDP or another process.
An SMF Router will select itself as a relay, if: An SMF router will select itself as a relay, if:
o The SMF Router has a higher priority than all of its symmetric o The SMF router has a higher priority than all of its symmetric
neighbors, or neighbors, or
o There does not exist a path from the neighbor with largest o A path from the neighbor with the largest priority to any other
priority to any other neighbor, via neighbors with greater neighbor via neighbors with greater priority than the current
priority. router does not exist.
An attacker can disrupt the E-CDS algorithm by link spoofing or An attacker can disrupt the E-CDS algorithm by link spoofing or
identity spoofing. identity spoofing.
5.2.1. Link Spoofing 5.2.1. Link Spoofing
Link spoofing implies that an attacker advertises non-existing links Link spoofing implies that an attacker advertises non-existing links
to another router (present in the network or not). to another router (which may or may not be present in the network).
An attacker can declare itself with high route priority, and spoofs An attacker can declare itself to have high route priority and spoof
the links to as many legitimate SMF Routers as possible to declare the links to as many legitimate SMF routers as possible to declare
high connectivity. By doing so, it can prevent legitimate SMF high connectivity. By doing so, it can prevent legitimate SMF
Routers from self-selecting as relays. As the "super" relay in the routers from selecting themselves as relays. As the "super" relay in
network, the attacker can manipulate the traffic relayed by it. the network, the attacker can manipulate the traffic it relays.
5.2.2. Identity Spoofing 5.2.2. Identity Spoofing
Identity spoofing implies that an attacker determines and makes use Identity spoofing implies that an attacker determines and makes use
of the identity of other legitimate routers, without being authorized of the identity of other legitimate routers, without being authorized
to do so. The identity of other routers can be obtained by to do so. The identity of other routers can be obtained by
overhearing the control messages or the source/destination address eavesdropping the control messages or the source/destination address
from datagrams. The attacker can then generate control or datagram from datagrams. The attacker can then generate control or datagram
traffic, pretending to be a legitimate router. traffic by pretending to be a legitimate router.
Because E-CDS self-selection is based on the router priority value, Because E-CDS self-selection is based on the router priority value,
an attacker can spoof the identity of other legitimate routers, and an attacker can spoof the identity of other legitimate routers and
declares a different router priority value. If it declares a higher declare a different router priority value. If it declares that a
priority of a spoofed router, it can prevent other routers from spoofed router has a higher priority, it can prevent other routers
selecting themselves as relays. On the other hand, if the attacker from selecting themselves as relays. On the other hand, if the
declares lower priority of a spoofed router, it can force other attacker declares that a spoofed router has a lower priority, it can
routers to selecting themselves as relays, to degrade the multicast force other routers to select themselves as relays to degrade the
forwarding to classical flooding. multicast forwarding to classical flooding.
5.3. Threats to S-MPR Algorithm 5.3. Threats to S-MPR Algorithm
The source-based multipoint relay (S-MPR) set selection algorithm The S-MPR set selection algorithm enables individual routers, using
enables individual routers, using 2-hop topology information, to 2-hop topology information, to select relays from among their set of
select relays from their set of neighboring routers. MPRs are neighboring routers. MPRs are selected by each router such that a
selected so that forwarding to the router's complete 2-hop neighbor message generated by it, and relayed only by its MPRs, will reach all
set is covered. of its 2-hop neighbors.
An SMF router forwards a multicast packet if and only if: An SMF router forwards a multicast packet if and only if:
o the packet has not been received before, and o the packet has not been received before, and
o the neighbor from which the packet was received has selected the o the neighbor from which the packet was received has selected the
router as MPR. router as MPR.
Because MPR calculation is based on the willingness declared by the Because MPR calculation is based on the willingness declared by the
SMF routers, and the connectivity of the routers, it can be disrupted SMF routers and the connectivity of the routers, it can be disrupted
by both link spoofing and identity spoofing. The threats and its by both link spoofing and identity spoofing. These threats and their
impacts have been illustrated in section 5.1 of [RFC7186]. impacts have been illustrated in Section 5.1 of [RFC7186].
5.4. Threats to MPR-CDS Algorithm 5.4. Threats to the MPR-CDS Algorithm
MPR-CDS is a derivative from S-MPR. The main difference between MPR-CDS is a derivative from S-MPR. The main difference between
S-MPR and MPR-CDS is that while S-MPR forms a different broadcast S-MPR and MPR-CDS is that while S-MPR forms a different broadcast
tree for each source in the network, MPR-CDS forms a unique broadcast tree for each source in the network, MPR-CDS forms a unique broadcast
tree for all sources in the network. tree for all sources in the network.
As MPR-CDS combines E-CDS and S-MPR and the simple combination of the As MPR-CDS combines E-CDS and S-MPR and the simple combination of the
two algorithms does not address the weakness, the vulnerabilities of two algorithms does not address the weaknesses; the vulnerabilities
E-CDS and S-MPR that discussed in Section 5.2 and Section 5.3 apply of E-CDS and S-MPR that are discussed in Sections 5.2 and 5.3 apply
to MPR-CDS also. to MPR-CDS also.
6. Security Considerations 6. Security Considerations
This document does not specify a protocol or a procedure. The whole This document does not specify a protocol or a procedure. The whole
document, however, reflects on security considerations for SMF for document, however, reflects on security considerations for SMF
packet dissemination in MANETs. Possible attacks to the two main regarding packet dissemination in MANETs. Possible attacks to the
functional components of SMF, duplicate packet detection and relay two main functional components of SMF, duplicate packet detection,
set selection, are analyzed and documented. and relay set selection are analyzed and documented.
Although [RFC6621] nor this document propose mechanisms to secure the Although neither [RFC6621] nor this document propose mechanisms to
SMF protocol, there are several possibilities to secure the protocol secure the SMF protocol, there are several possibilities to secure
in the future and driving new work by suggesting which threats the protocol in the future and drive new work by suggesting which
discussed in the previous sections could be addressed. threats discussed in the previous sections could be addressed.
For the I-DPD mechanism, employing randomized packet sequence numbers For the I-DPD mechanism, employing randomized packet sequence numbers
can avoid some pre-activation attacks based on sequence number can avoid some pre-activation attacks based on sequence number
prediction. If predicable sequence numbers have to be used, applying prediction. If predicable sequence numbers have to be used, applying
timestamps can mitigate pre-activation attacks. timestamps can mitigate pre-activation attacks.
For the H-DPD mechanism, applying cryptographically strong hashes can For the H-DPD mechanism, applying cryptographically strong hashes can
make the digest collisions effectively impossible, and avoid the use make the digest collisions effectively impossible, and it can avoid
of hash-assistant value. the use of a HAV.
[RFC7182] specifies a framework for representing cryptographic [RFC7182] specifies a framework for representing cryptographic
Integrity Check Values (ICVs) and timestamps in MANETs. Based on Integrity Check Values (ICVs) and timestamps in MANETs. Based on
[RFC7182], [RFC7183] specifies integrity and replay protection for [RFC7182], [RFC7183] specifies integrity and replay protection for
NHDP using shared keys, as a mandatory-to-implement security NHDP using shared keys as a mandatory-to-implement security
mechanism. If SMF is using NHDP as neighborhood discovery protocol, mechanism. If SMF is using NHDP as the neighborhood discovery
implementing [RFC7183] remains advisable so as to enable integrity protocol, implementing [RFC7183] remains advisable so as to enable
protection for NHDP control messages. This can help mitigating integrity protection for NHDP control messages. This can help
threats related to identity spoofing through the exchange of HELLO mitigate threats related to identity spoofing through the exchange of
messages, and provides some general protection against identity HELLO messages and provide some general protection against identity
spoofing by admitting only trusted routers to the network using ICVs spoofing by admitting only trusted routers to the network using ICVs
in HELLO messages. in HELLO messages.
Using ICVs does, of course, not address the problem of attackers, Using ICVs does not, of course, address the problem of attackers able
able to also generate valid ICVs. Detection and exclusion of such to also generate valid ICVs. Detection and exclusion of such
attackers is, in general, a challenge, which is not unrelated to how attackers is, in general, a challenge that is not unrelated to how
[RFC7182] is used. If, for example, it is used with a shared key (as [RFC7182] is used. If, for example, it is used with a shared key (as
per [RFC7183]), excluding single attackers generally is not aided by per [RFC7183]), excluding single attackers generally is not aided by
the use of ICVs. However if routers have sufficient capabilities to the use of ICVs. However, if routers have sufficient capabilities to
support the use of asymmetric keys (as per [RFC7859]), part of support the use of asymmetric keys (as per [RFC7859]), part of
addressing this challenge becomes one of providing key revocation, in addressing this challenge becomes one of providing key revocation in
a way that does not in itself introduce additional vulnerabilities. a way that does not in itself introduce additional vulnerabilities.
As [RFC7183] does not protect the integrity of the multicast user As [RFC7183] does not protect the integrity of the multicast user
datagram, and as no mechanism is specified by SMF for doing so, datagram, and as no mechanism is specified by SMF for doing so,
duplicate packet detection remains vulnerable to the threats duplicate packet detection remains vulnerable to the threats
introduced in Section 4. introduced in Section 4.
If pre-activation/de-activation attacks and attack on hash-assistant If pre-activation/de-activation attacks and attacks on the HAV of the
value of the multicast datagrams are to be mitigated, a datagram- multicast datagrams are to be mitigated, a datagram-level integrity
level integrity protection mechanism is desired, by taking protection mechanism is desired, by taking consideration of the
consideration of the identity field or hash-assistant value. identity field or HAV. However, this would not be helpful for the
However, this would not be helpful for the attacks on the TTL (or hop attacks on the TTL (or Hop Limit for IPv6) field, because the mutable
limit for IPv6) field, because the mutable fields are generally not fields are generally not considered when ICV is calculated.
considered when ICV is calculated.
7. IANA Considerations
This document contains no actions for IANA.
[RFC Editor: please remove this section prior to publication.]
8. Acknowledgments
The authors would like to thank Christopher Dearlove (BAE Systems 7. References
ATC) who provided detailed review and valuable comments.
9. References 7.1. Normative References
9.1. Normative References
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, DOI 10.17487/RFC6130, April 2011,
<http://www.rfc-editor.org/info/rfc6130>.
[RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, [RFC6621] Macker, J., Ed., "Simplified Multicast Forwarding",
May 2012. RFC 6621, DOI 10.17487/RFC6621, May 2012,
<http://www.rfc-editor.org/info/rfc6621>.
[RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for [RFC7186] Yi, J., Herberg, U., and T. Clausen, "Security Threats for
the Neighborhood Discovery Protocol (NHDP)", RFC 7186, the Neighborhood Discovery Protocol (NHDP)", RFC 7186,
April 2014. DOI 10.17487/RFC7186, April 2014,
<http://www.rfc-editor.org/info/rfc7186>.
9.2. Informative References 7.2. Informative References
[MOBICOM99] [MOBICOM99]
Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The Broadcast Ni, S., Tseng, Y., Chen, Y., and J. Sheu, "The broadcast
Storm Problem in a Mobile Ad Hoc Network", Proceedings of storm problem in a mobile ad hoc network", MobiCom
the 5th annual ACM/IEEE international conference on Mobile '99 Proceedings of the 5th annual ACM/IEEE international
computing and networking, 1999. conference on Mobile computing and networking,
DOI 10.1145/313451.313525, 1999.
[MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing [MPR-CDS] Adjih, C., Jacquet, P., and L. Viennot, "Computing
Connected Dominating Sets with Multipoint Relays", Journal Connected Dominating Sets with Multipoint Relays", Journal
of Ad Hoc and Sensor Wireless Networks 2002, January 2002. of Ad Hoc and Sensor Wireless Networks 2002, January 2002.
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T., Ed. and P. Jacquet, Ed., "Optimized Link
Routing Protocol", RFC 3626, October 2003. State Routing Protocol (OLSR)", RFC 3626,
DOI 10.17487/RFC3626, October 2003,
<http://www.rfc-editor.org/info/rfc3626>.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>.
[RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter [RFC5148] Clausen, T., Dearlove, C., and B. Adamson, "Jitter
Considerations in Mobile Ad Hoc Networks (MANETs)", Considerations in Mobile Ad Hoc Networks (MANETs)",
RFC 5148, February 2008. RFC 5148, DOI 10.17487/RFC5148, February 2008,
<http://www.rfc-editor.org/info/rfc5148>.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
February 2009. Format", RFC 5444, DOI 10.17487/RFC5444, February 2009,
<http://www.rfc-editor.org/info/rfc5444>.
[RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET) [RFC5614] Ogier, R. and P. Spagnolo, "Mobile Ad Hoc Network (MANET)
Extension of OSPF Using Connected Dominating Set (CDS) Extension of OSPF Using Connected Dominating Set (CDS)
Flooding", RFC 5614, August 2009. Flooding", RFC 5614, DOI 10.17487/RFC5614, August 2009,
<http://www.rfc-editor.org/info/rfc5614>.
[RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, [RFC7181] Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg,
"The Optimized Link State Routing Protocol version 2", "The Optimized Link State Routing Protocol Version 2",
RFC 7181, April 2014. RFC 7181, DOI 10.17487/RFC7181, April 2014,
<http://www.rfc-editor.org/info/rfc7181>.
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad Check Value and Timestamp TLV Definitions for Mobile Ad
Hoc Networks (MANETs)", RFC 7182, April 2014. Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182,
April 2014, <http://www.rfc-editor.org/info/rfc7182>.
[RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity
Protection for the Neighborhood Discovery Protocol (NHDP) Protection for the Neighborhood Discovery Protocol (NHDP)
and Optimized Link State Routing Protocol Version 2 and Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7183, April 2014. (OLSRv2)", RFC 7183, DOI 10.17487/RFC7183, April 2014,
<http://www.rfc-editor.org/info/rfc7183>.
[RFC7859] Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc [RFC7859] Dearlove, C., "Identity-Based Signatures for Mobile Ad Hoc
Network (MANET) Routing Protocols", RFC 7859, Network (MANET) Routing Protocols", RFC 7859,
DOI 10.17487/RFC7859, May 2016, DOI 10.17487/RFC7859, May 2016,
<http://www.rfc-editor.org/info/rfc7859>. <http://www.rfc-editor.org/info/rfc7859>.
Acknowledgments
The authors would like to thank Christopher Dearlove (BAE Systems
ATC) who provided detailed review and valuable comments.
Authors' Addresses Authors' Addresses
Jiazi Yi Jiazi Yi
Ecole Polytechnique Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex
France France
Phone: +33 1 77 57 80 85 Phone: +33 1 77 57 80 85
Email: jiazi@jiaziyi.com Email: jiazi@jiaziyi.com
URI: http://www.jiaziyi.com/ URI: http://www.jiaziyi.com/
Thomas Heide Clausen Thomas Heide Clausen
Ecole Polytechnique Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex
France France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
URI: http://www.thomasclausen.org/ URI: http://www.thomasclausen.org/
Ulrich Herberg Ulrich Herberg
Email: ulrich@herberg.name Email: ulrich@herberg.name
URI: http://www.herberg.name/ URI: http://www.herberg.name/
 End of changes. 109 change blocks. 
347 lines changed or deleted 356 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/