draft-ietf-manet-nhdp-sec-threats-05.txt   draft-ietf-manet-nhdp-sec-threats-06.txt 
Mobile Ad hoc Networking (MANET) U. Herberg Mobile Ad hoc Networking (MANET) J. Yi
Internet-Draft Fujitsu Laboratories of America Internet-Draft LIX, Ecole Polytechnique
Intended status: Informational J. Yi Intended status: Informational U. Herberg
Expires: December 12, 2013 T. Clausen Expires: December 19, 2013 Fujitsu Laboratories of America
T. Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
June 10, 2013 June 17, 2013
Security Threats for NHDP Security Threats for NHDP
draft-ietf-manet-nhdp-sec-threats-05 draft-ietf-manet-nhdp-sec-threats-06
Abstract Abstract
This document analyzes common security threats of the Neighborhood This document analyzes common security threats of the Neighborhood
Discovery Protocol (NHDP), and describes their potential impacts on Discovery Protocol (NHDP), and describes their potential impacts on
MANET routing protocols using NHDP. This document is not intended to MANET routing protocols using NHDP. This document is not intended to
propose solutions to the threats described. propose solutions to the threats described.
Status of this Memo Status of this Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 12, 2013. This Internet-Draft will expire on December 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. NHDP Threat Overview . . . . . . . . . . . . . . . . . . . . . 4 3. NHDP Threat Overview . . . . . . . . . . . . . . . . . . . . . 4
4. Detailed Threat Description . . . . . . . . . . . . . . . . . 4 4. Detailed Threat Description . . . . . . . . . . . . . . . . . 5
4.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Jamming . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Denial of Service Attack . . . . . . . . . . . . . . . . . 5 4.2. Denial of Service Attack . . . . . . . . . . . . . . . . . 5
4.3. Eavesdropping . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Eavesdropping and Traffic Analysis . . . . . . . . . . . . 6
4.4. Incorrect HELLO Message Generation . . . . . . . . . . . . 6 4.4. Incorrect HELLO Message Generation . . . . . . . . . . . . 7
4.4.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 6 4.4.1. Identity Spoofing . . . . . . . . . . . . . . . . . . 7
4.4.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 7 4.4.2. Link Spoofing . . . . . . . . . . . . . . . . . . . . 8
4.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 9
4.6. Message Timing Attacks . . . . . . . . . . . . . . . . . . 8 4.6. Message Timing Attacks . . . . . . . . . . . . . . . . . . 9
4.6.1. Interval Time Attack . . . . . . . . . . . . . . . . . 8 4.6.1. Interval Time Attack . . . . . . . . . . . . . . . . . 9
4.6.2. Validity Time Attack . . . . . . . . . . . . . . . . . 9 4.6.2. Validity Time Attack . . . . . . . . . . . . . . . . . 10
4.7. Indirect Channel Overloading . . . . . . . . . . . . . . . 9 4.7. Indirect Channel Overloading . . . . . . . . . . . . . . . 10
4.8. Attack on Link Quality Update . . . . . . . . . . . . . . 10 4.8. Attack on Link Quality Update . . . . . . . . . . . . . . 11
5. Impact of inconsistent Information Bases on Protocols 5. Impact of inconsistent Information Bases on Protocols
using NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 using NHDP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 11 5.1. MPR Calculation . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. Flooding Disruption due to Identity Spoofing . . . . . 11 5.1.1. Flooding Disruption due to Identity Spoofing . . . . . 12
5.1.2. Flooding Disruption due to Link Spoofing . . . . . . . 12 5.1.2. Flooding Disruption due to Link Spoofing . . . . . . . 13
5.1.3. Broadcast Storm . . . . . . . . . . . . . . . . . . . 13 5.1.3. Broadcast Storm . . . . . . . . . . . . . . . . . . . 14
5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Routing Loops . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Invalid or Non-Existing Paths to Destinations . . . . . . 14 5.3. Invalid or Non-Existing Paths to Destinations . . . . . . 15
5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Data Sinkhole . . . . . . . . . . . . . . . . . . . . . . 16
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers The Neighborhood Discovery Protocol (NHDP) [RFC6130] allows routers
to acquire topological information up to two hops away from to acquire topological information up to two hops away from
themselves, by way of periodic HELLO message exchanges. The themselves, by way of periodic HELLO message exchanges. The
information acquired by NHDP is used by other protocols, such as information acquired by NHDP is used by other protocols, such as
OLSRv2 [I-D.ietf-manet-olsrv2] and SMF [RFC6621]. The topology OLSRv2 [I-D.ietf-manet-olsrv2] and SMF [RFC6621]. The topology
information, acquired by way of NHDP, serves these routing protocols information, acquired by way of NHDP, serves these routing protocols
by detecting and maintaining local 1-hop and 2-hop neighborhood by detecting and maintaining local 1-hop and 2-hop neighborhood
information. information.
As NHDP is typically used in wireless environments, it is potentially As NHDP is typically used in wireless environments, it is potentially
exposed to different kinds of security threats, some of which are of exposed to different kinds of security threats, some of which are of
particular significance as compared to wired networks. As radio particular significance as compared to wired networks. As radio
signals can be received as well as transmitted by any compatible signals can be received as well as transmitted by any compatible
wireless device within radio range, there is commonly no physical wireless device within radio range, there is commonly no physical
protection as otherwise known for wired networks. NHDP does not protection as otherwise known for wired networks. NHDP does not
define any explicit security measures for protecting the integrity of define any explicit security measures for protecting the integrity of
the information it acquires, however suggests that this be addressed the information it acquires, however suggests that the integrity
in a fashion appropriate to the deployment of the network. protection be addressed in a fashion appropriate to the deployment of
the network.
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 suitable to deploy common IP protection mechanisms
(e.g., because of limited resources of MANET routers to support the (e.g., because of limited resources of MANET routers to support the
IPsec stack). The document analyzes possible attacks and mis- IPsec stack). The document analyzes possible attacks on and mis-
configurations on NHDP and outlines the consequences of such attacks/ configurations of NHDP and outlines the consequences of such attacks/
mis-configurations to the state maintained by NHDP in each router mis-configurations to the state maintained by NHDP in each router
(and, thus, made available to protocols using this state). This (and, thus, made available to protocols using this state).
document is not intended to propose solutions to the threats
This document is not intended to propose solutions to the threats
described. [I-D.ietf-manet-nhdp-olsrv2-sec] provides further described. [I-D.ietf-manet-nhdp-olsrv2-sec] provides further
information on how to enable integrity protection to NHDP, which can information on how to enable integrity protection to NHDP, which can
help mitigating the threats described related to identity spoofing. help mitigating the threats described related to identity spoofing.
2. Terminology It should be noted that many NHDP implementations are configurable
and so an attack on the configuration system (such as [RFC6779]) can
be used to adversely affect the operation of an NHDP implementation.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The NHDP MIB module [RFC6779] might help monitoring some of the
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and security attacks mentioned in this document. Note that,
"OPTIONAL" in this document are to be interpreted as described in [I-D.nguyen-manet-management] contains specific guidelines on MANET
[RFC2119]. network management, taking into account the specific nature of
MANETs.
2. Terminology
This document uses the terminology and notation defined in [RFC5444], This document uses the terminology and notation defined in [RFC5444],
NHDP [RFC6130] and [RFC4949]. NHDP [RFC6130] and [RFC4949].
Additionally, this document introduces the following terminology: Additionally, this document introduces the following terminology:
NHDP Router: A MANET router, running NHDP as specified in [RFC6130]. NHDP Router: A MANET router, running NHDP as specified in [RFC6130].
Attacker: A device, present in the network and which intentionally Attacker: A device, present in the network and which intentionally
seeks to compromise the information bases in NHDP routers. seeks to compromise the information bases in NHDP routers.
skipping to change at page 4, line 22 skipping to change at page 4, line 29
Control messages emitted by a Compromised NHDP router may contain Control messages emitted by a Compromised NHDP router may contain
additional information, or omit information, as compared to a additional information, or omit information, as compared to a
control message generated by a non-compromized NHDP router located control message generated by a non-compromized NHDP router located
in the same topological position in the network. in the same topological position in the network.
Legitimate NHDP Router: An NHDP router, which is not a Compromised Legitimate NHDP Router: An NHDP router, which is not a Compromised
NHDP Router. NHDP Router.
3. NHDP Threat Overview 3. NHDP Threat Overview
NHDP defines a HELLO messages exchange, enabling each NHDP router to NHDP defines a HELLO messages exchange, enabling each NHDP Router to
acquire topological information describing its 1-hop and 2-hop acquire topological information describing its 1-hop and 2-hop
neighbors, and specifies information bases for recording this neighbors, and specifies information bases for recording this
information. information.
An NHDP router periodically transmits HELLO messages using a link- An NHDP Router periodically transmits HELLO messages using a link-
local multicast on each of its interfaces with a hop-limit of 1 local multicast on each of its interfaces with a hop-limit of 1
(i.e., HELLOs are never forwarded). In these HELLO messages, an NHDP (i.e., HELLOs are never forwarded). In these HELLO messages, an NHDP
router announces the IP addresses as heard, symmetric or lost Router announces the IP addresses as heard, symmetric or lost
neighbor interface addresses. neighbor interface addresses.
An Attacker has several ways of harming this neighbor discovery An Attacker has several ways of harming this neighbor discovery
process: It can announce "wrong" information about its identity, process: It can announce "wrong" information about its identity,
postulate non-existent links, and replay HELLO messages. These postulate non-existent links, and replay HELLO messages. These
attacks are presented in detail in Section 4. attacks are presented in detail in Section 4.
The different ways of attacking an NHDP deployment may eventually The different ways of attacking an NHDP deployment may eventually
lead to inconsistent information bases, not accurately reflecting the lead to inconsistent information bases, not accurately reflecting the
correct topology of the MANET. The consequence hereof is that correct topology of the MANET. The consequence hereof is that
skipping to change at page 5, line 8 skipping to change at page 5, line 14
protocols using NHDP are described in detail in Section 5. protocols using NHDP are described in detail in Section 5.
4. Detailed Threat Description 4. Detailed Threat Description
For each threat, described in the below, a description of the For each threat, described in the below, a description of the
mechanism of the corresponding attack is given, followed by a mechanism of the corresponding attack is given, followed by a
description of how the attack affects NHDP. The impacts from each description of how the attack affects NHDP. The impacts from each
attack on protocols using NHDP are given in Section 5. attack on protocols using NHDP are given in Section 5.
For simplicity in the description, examples given assume that NHDP For simplicity in the description, examples given assume that NHDP
routers have a single interface with a single IP address configured. Routers have a single interface with a single IP address configured.
All the attacks apply, however, for NHDP routers with multiple All the attacks apply, however, for NHDP Routers with multiple
interfaces and multiple addresses as well. interfaces and multiple addresses as well.
4.1. Jamming 4.1. Jamming
One vulnerability, common for all protocols operating a wireless ad One vulnerability, common for all protocols operating a wireless ad
hoc network, is that of "jamming", i.e., that a device generates hoc network, is that of "jamming", i.e., that a device generates
massive amounts of interfering radio transmissions, which will massive amounts of interfering radio transmissions, which will
prevent legitimate traffic (e.g.,control traffic as well as data prevent legitimate traffic (e.g.,control traffic as well as data
traffic) on part of a network. traffic) on part of a network. Jamming is a form of Interference and
Overload with threat consequences of Disruption [RFC4593].
Depending on lower layers, this may not affect transmissions: HELLO Depending on lower layers, this may not affect transmissions: HELLO
messages from an NHDP router with "jammed" interfaces may be received messages from an NHDP Router with "jammed" interfaces may be received
by other NHDP routers. As NHDP identifies whether a link to a by other NHDP Routers. As NHDP identifies whether a link to a
neighbor is uni-directional or bi-directional, a routing protocol neighbor is uni-directional or bi-directional, a routing protocol
that uses NHDP for neighborhood discovery may ignore a link from a that uses NHDP for neighborhood discovery may ignore a link from a
jammed NHDP router to a non-jammed NHDP router. The jammed router (a jammed NHDP Router to a non-jammed NHDP Router. The jammed router (a
router with jammed carrier) would appear simply as "disconnected" for router with jammed carrier) would appear simply as "disconnected" for
the un-jammed part of the network - which is able to maintain the un-jammed part of the network - which is able to maintain
accurate topology maps. accurate topology maps.
If, due to a jamming attack, a considerable amount of HELLO messages If, due to a jamming attack, a considerable amount of HELLO messages
are lost or corrupted due to collisions, neighbor NHDP routers are are lost or corrupted due to collisions, neighbor NHDP Routers are
not able to establish links between them any more. Thus, NHDP will not able to establish links between themselves any more. Thus, NHDP
present empty information bases to the protocols using it. will present empty information bases to the protocols using it.
4.2. Denial of Service Attack 4.2. Denial of Service Attack
A Denial of Service (DoS) attack can be a result of misconfiguration A Denial of Service (DoS) attack can be a result of misconfiguration
of Legitimate NHDP Routers (e.g., very short HELLO transmission of Legitimate NHDP Routers (e.g., very short HELLO transmission
interval) or malicious behavior of Compromised NHDP Routers. interval) or malicious behavior of Compromised NHDP Routers
[ACCT2012], so called byzantine routers [RFC4593]. DoS is a form of
Interference and Overload with threat consequences of Disruption
[RFC4593].
By transmitting a huge amount of HELLO messages in a short period of By transmitting a huge amount of HELLO messages in a short period of
time, NHDP Routers can increase the channel occupancy as introduced time, NHDP Routers can increase channel occupation as introduced in
in Section 4.1. Furthermore, a Compromised NHDP Router can spoof a Section 4.1. Furthermore, a Compromised NHDP Router can spoof a
large amount of different IP addresses, and send HELLOs to its large amount of different IP addresses, and send HELLOs to its
neighbors to fill their Link/Neighbor Sets. This may result in neighbors to fill their Link/Neighbor Sets. This may result in
memory overflow, and makes the processing of legitimate HELLO memory overflow, and makes the processing of legitimate HELLO
messages impossible. A Compromised NHDP Router can also use link messages impossible. A Compromised NHDP Router can also use link
spoofing in its HELLO messages, generating huge 2-hop Sets in spoofing in its HELLO messages, generating huge 2-hop Sets in
adjacent NHDP Routers and therefore potentially a memory overflow. adjacent NHDP Routers and therefore potentially a memory overflow.
Moreover, protocols such as SMF and OLSRv2, using the 2-hop Moreover, protocols such as SMF and OLSRv2, using the 2-hop
information for MPR calculation, may exhaust the available information for MPR calculation, may exhaust the available
computational resources of the router if the Neighbor Set and 2-hop computational resources of the router if the Neighbor Set and 2-hop
Sets have too many entries. Sets have too many entries.
By exhausting the memory, CPU, or (and) channel resources of a router By exhausting the memory, CPU, or (and) channel resources of a router
in a DoS attack or a misconfiguration, NHDP Routers may not be able in a DoS attack or a misconfiguration, NHDP Routers may not be able
to accomplish their specified tasks of exchanging 1-hop and 2-hop to accomplish their specified tasks of exchanging 1-hop and 2-hop
neighborhood information, and thereby disturbing the operation of neighborhood information, and thereby disturbing the operation of
routing protocols using NHDP. routing protocols using NHDP.
4.3. Eavesdropping In some MANETs, the routers are powered by battery. Another
consequence of DoS attack in such networks is that the power will be
drained quickly by unnecessary message processing, transmission and
receiving.
Eavesdropping is a common and easy passive attack in a wireless 4.3. Eavesdropping and Traffic Analysis
environment. Once a packet is transmitted, any adjacent NHDP router
can potentially obtain a copy, for immediate or later processing. Eavesdropping, sometimes referred as sniffing, is a common and easy
Neither the source nor the intended destination can detect this. A passive attack in a wireless environment. Once a packet is
malicious NHDP router can eavesdrop on the NHDP message exchange and transmitted, any adjacent NHDP Router can potentially obtain a copy,
thus learn the local topology. It may also eavesdrop on data traffic for immediate or later processing. Neither the source nor the
to learn source and destination addresses of data packets, or other intended destination can detect this. A malicious NHDP Router can
header information, as well as the packet payload. eavesdrop on the NHDP message exchange and thus learn the local
topology. It may also eavesdrop on data traffic to learn source and
destination addresses of data packets, or other header information,
as well as the packet payload.
Eavesdropping does not pose a direct threat to the network nor to Eavesdropping does not pose a direct threat to the network nor to
NHDP, in as much as that it does not alter the information recorded NHDP, in as much as that it does not alter the information recorded
by NHDP in its information bases and presented to other protocols by NHDP in its information bases and presented to other protocols
using it, but it can provide network information required for using it, but it can provide network information required for
enabling other attacks, such as the identity of communicating NHDP enabling other attacks, such as the identity of communicating NHDP
routers, detection of link characteristic, and NHDP router Routers, detection of link characteristic, and NHDP Router
configuration. configuration. The compromised NHDP Routers may use the obtained
information to launch subsequent attacks, and they may also share
NHDP routing information with other NHDP or non-NHDP entities.
[RFC4593] would categorize the threat consequence as Disclosure.
Traffic analysis normally comes along with eavesdropping, which is
the process of intercepting messages in order to deduce information
from communication patterns. It can be performed even HELLO messages
are encrypted (encryption is not a part of NHDP), for example:
o Triggered HELLO messages: an attacker could figure out that
messages are triggered and determine that there was a change of
symmetric neighbors of an NHDP Router sending the HELLO (as well
get the frequency).
o Message size: the message grows exactly by x bytes per neighbor.
Depending on which cipher is used for the encryption, some
information about the size could be inferred and thus the number
of neighbors guessed.
[RFC4593] would categorize the threat consequence as Disclosure.
4.4. Incorrect HELLO Message Generation 4.4. Incorrect HELLO Message Generation
An NHDP router performs two distinct tasks: it periodically generates An NHDP Router performs two distinct tasks: it periodically generates
HELLO messages, and it processes incoming HELLO messages from HELLO messages, and it processes incoming HELLO messages from
neighbor NHDP routers. This section describes security attacks neighbor NHDP Routers. This section describes security attacks
involving the HELLO generation. involving the HELLO generation.
4.4.1. Identity Spoofing 4.4.1. Identity Spoofing
Identity spoofing implies that a Compromised NHDP router sends HELLO Identity spoofing implies that a Compromised NHDP Router sends HELLO
messages, pretending to have the identity of another NHDP router, or messages, pretending to have the identity of another NHDP Router, or
even a router that does not exist in the networks. A Compromised even a router that does not exist in the networks. A Compromised
NHDP router can accomplish this by using another IP address in an NHDP Router can accomplish this by using another IP address in an
address block of a HELLO message, and associating this address with a address block of a HELLO message, and associating this address with a
LOCAL_IF Address Block TLV. LOCAL_IF Address Block TLV [IJNSIA2010].
An NHDP router receiving the HELLO message from a neighbor, will An NHDP Router receiving the HELLO message from a neighbor, will
assume that it originated from the NHDP router with the spoofed assume that it originated from the NHDP Router with the spoofed
interface address. As a consequence, it will add a Link Tuple to interface address. As a consequence, it will add a Link Tuple to
that neighbor with the spoofed address, and include it in its next that neighbor with the spoofed address, and include it in its next
HELLO messages as a heard neighbor (and possibly as symmetric HELLO messages as a heard neighbor (and possibly as symmetric
neighbor after another HELLO exchange). neighbor after another HELLO exchange).
Identity spoofing is particular harmful if a Compromised NHDP router Identity spoofing is particular harmful if a Compromised NHDP Router
spoofs the identity of another NHDP router that exists in the same spoofs the identity of another NHDP Router that exists in the same
routing domain. With respect to NHDP, such a duplicated, spoofed routing domain. With respect to NHDP, such a duplicated, spoofed
address can lead to an inconsistent state up to two hops from an NHDP address can lead to an inconsistent state up to two hops from an NHDP
router. Figure 1 depicts a simple example. In that example, NHDP Router. [RFC4593] would categorize the threat consequence as
router A is in radio range of C, but not of the Compromised NHDP Disclosure and Deception.
router X. If X spoofs the address of A, that can lead to conflicts
for routing protocol that uses NHDP, and therefore for wrong path Figure 1 depicts a simple example. In that example, NHDP Router A is
calculations as well as incorrect data traffic forwarding. in radio range of C, but not of the Compromised NHDP Router X. If X
spoofs the address of A, that can lead to conflicts for routing
protocol that uses NHDP, and therefore for wrong path calculations as
well as incorrect data traffic forwarding.
.---. .---. .---. .---. .---. .---.
| A |----| C |----| X | | A |----| C |----| X |
'---' '---' '---' '---' '---' '---'
Figure 1 Figure 1
Figure 2 depicts another example. In this example, A is two hops Figure 2 depicts another example. In this example, A is two hops
away from NHDP router C, reachable through NHDP router B. If the away from NHDP Router C, reachable through NHDP Router B. If the
Compromised NHDP router X spoofs the address of A, D will take A as Compromised NHDP Router X spoofs the address of A, D will take A as
its one hop neighbor, and C may think that A is indeed reachable its one hop neighbor, and C may think that A is indeed reachable
through NHDP router D. through NHDP Router D.
.---. .---. .---. .---. .---. .---. .---. .---. .---. .---.
| A |----| B |----| C |----| D |----| X | | A |----| B |----| C |----| D |----| X |
'---' '---' '---' '---' '---' '---' '---' '---' '---' '---'
Figure 2 Figure 2
4.4.2. Link Spoofing 4.4.2. Link Spoofing
Similar to identity spoofing, link spoofing implies that a Similar to identity spoofing, link spoofing implies that a
Compromised NHDP router sends HELLO messages, signaling an incorrect Compromised NHDP Router sends HELLO messages, signaling an incorrect
set of neighbors. This may take either of two forms: set of neighbors, sometimes referred to as Falsification [RFC4593].
This may take either of two forms:
o A Compromised NHDP Router can postulate addresses of non-present o A Compromised NHDP Router can postulate addresses of non-present
neighbor NHDP routers in an address block of a HELLO, associated neighbor NHDP Routers in an address block of a HELLO, associated
with LINK_STATUS TLVs. with LINK_STATUS TLVs.
o A Compromised NHDP router can "ignore" otherwise existing o A Compromised NHDP Router can "ignore" otherwise existing
neighbors by not advertising them in its HELLO messages. neighbors by not advertising them in its HELLO messages.
The effect of link spoofing with respect to NHDP are twofold, The effect of link spoofing with respect to NHDP are twofold,
depending on the two cases mentioned above: If the Compromised NHDP depending on the two cases mentioned above: If the Compromised NHDP
router ignores existing neighbors in its advertisements, links will Router ignores existing neighbors in its advertisements, links will
be missing in the information bases maintained by other routers, and be missing in the information bases maintained by other routers, and
there may not be any connectivity to or from these NHDP routers to there may not be any connectivity to or from these NHDP Routers to
others NHDP routers in the MANET. If, on the other hand, the others NHDP Routers in the MANET. If, on the other hand, the
Compromised NHDP router advertises non-existing links, this will lead Compromised NHDP Router advertises non-existing links, this will lead
to inclusion of topological information in the information base, to inclusion of topological information in the information base,
describing non-existing links in the network (which, then, may be describing non-existing links in the network (which, then, may be
used by other protocols using NHDP in place of other, existing, used by other protocols using NHDP in place of other, existing,
links). links). [RFC4593] would categorize the threat consequence as
Usurpation, Deception and Disruption.
4.5. Replay Attack 4.5. Replay Attack
A replay attack implies that control traffic from one region of the A replay attack implies that control traffic from one region of the
network is recorded and replayed in a different region at (almost) network is recorded and replayed in a different region at (almost)
the same time, or in the same region at a different time. This may, the same time, or in the same region at a different time. This may,
for example, happen when two Compromised NHDP routers collaborate on for example, happen when two Compromised NHDP Routers collaborate on
an attack, one recording traffic in its proximity and tunneling it to an attack, one recording traffic in its proximity and tunneling it to
the other Compromised NHDP router, which replays the traffic. In a the other Compromised NHDP Router, which replays the traffic. In a
protocol where links are discovered by testing reception, this will protocol where links are discovered by testing reception, this will
result in extraneous link creation (basically, a "virtual" link result in extraneous link creation (basically, a "virtual" link
between the two Compromised NHDP routers will appear in the between the two Compromised NHDP Routers will appear in the
information bases of neighboring NHDP routers). information bases of neighboring NHDP Routers). [RFC4593] would
categorize this as a Falsification and Interference threat with a
threat consequence of Usurpation, Deception, and Disruption.
While this situation may result from an attack, it may also be While this situation may result from an attack, it may also be
intentional: if data-traffic also is relayed over the "virtual" link, intentional: if data-traffic also is relayed over the "virtual" link,
the link being detected is indeed valid for use. This is, for the link being detected is indeed valid for use. This is, for
instance, used in wireless repeaters. If data traffic is not carried instance, used in wireless repeaters. If data traffic is not carried
over the virtual link, an imaginary, useless, link between the two over the virtual link, an imaginary, useless, link between the two
Compromised NHDP routers, has been advertised, and is being recorded Compromised NHDP Routers, has been advertised, and is being recorded
in the information bases of their neighboring NHDP routers. in the information bases of their neighboring NHDP Routers.
Compared to Incorrect HELLO Message attacks described in Section 4.4,
the messages used in Replay attack are legitimate messages sent out
by (non-malicious) NHDP Routers and replayed at a later time or
different locality by malicious routers. This makes this kind of
attack harder to be detect and to counteract: integrity checks cannot
help in this case as the original message ICV (Integrity Check
Values) was correctly calculated.
4.6. Message Timing Attacks 4.6. Message Timing Attacks
In NHDP, each HELLO message contains a "validity time" and may In NHDP, each HELLO message contains a "validity time" and may
contain an "interval time" field, identifying the time for which contain an "interval time" field, identifying the time for which
information in that control message should be considered valid until information in that control message should be considered valid until
discarded, and the time until the next control message of the same discarded, and the time until the next control message of the same
type should be expected [RFC5497]. type should be expected [RFC5497].
4.6.1. Interval Time Attack 4.6.1. Interval Time Attack
A use of the expected interval between two successive HELLO messages A use of the expected interval between two successive HELLO messages
is for determining the link quality in NHDP: if messages are not is for determining the link quality in NHDP: if messages are not
received within the expected intervals (e.g., a certain fraction of received within the expected intervals (e.g., a certain fraction of
messages are missing), then this may be used to exclude a link from messages are missing), then this may be used to exclude a link from
being considered as useful, even if (some) bi-directional being considered as useful, even if (some) bi-directional
communication has been verified. If a Compromised NHDP router X communication has been verified. If a Compromised NHDP Router X
spoofs the identity of an existing NHDP router A, and sends HELLOs spoofs the identity of an existing NHDP Router A, and sends HELLOs
indicating a low interval time, an NHDP router B receiving this HELLO indicating a low interval time, an NHDP Router B receiving this HELLO
will expect the following HELLO to arrive within the interval time will expect the following HELLO to arrive within the interval time
indicated - or otherwise, decrease the link quality for the link A-B. indicated - or otherwise, decrease the link quality for the link A-B.
Thus, X may cause NHDP router B's estimate of the link quality for Thus, X may cause NHDP Router B's estimate of the link quality for
the link A-B to fall below the limit, where it is no longer the link A-B to fall below the limit, where it is no longer
considered as useful and, thus, not used. considered as useful and, thus, not used [CPSCOM2011]. [RFC4593]
would categorize the threat consequence as Usurpation.
4.6.2. Validity Time Attack 4.6.2. Validity Time Attack
A Compromised NHDP router X can spoof the identity of an NHDP router A Compromised NHDP Router X can spoof the identity of an NHDP Router
A and send a HELLO using a low validity time (e.g.,1 ms). A A and send a HELLO using a low validity time (e.g.,1 ms). A
receiving NHDP router B will discard the information upon expiration receiving NHDP Router B will discard the information upon expiration
of that interval, i.e., a link between NHDP router A and B will be of that interval, i.e., a link between NHDP Router A and B will be
"torn down" by X. It can be caused by intended malicious behaviors, "torn down" by X. It can be caused by intended malicious behaviors,
or simply mis-configuration in the NHDP routers. or simply mis-configuration in the NHDP Routers. [RFC4593] would
categorize the threat consequence as Usurpation.
4.7. Indirect Channel Overloading 4.7. Indirect Channel Overloading
Indirect Channel Overloading is when a Compromised NHDP router X by Indirect Channel Overloading is when a Compromised NHDP Router X by
its actions causes other legitimate NHDP routers to generate its actions causes other legitimate NHDP Routers to generate
inordinate amounts of control traffic. This increases channel inordinate amounts of control traffic. This increases channel
occupation, and the overhead in each receiving NHDP router processing occupation, and the overhead in each receiving NHDP Router processing
this control traffic. With this traffic originating from Legitimate this control traffic. With this traffic originating from Legitimate
NHDP routers, the malicious device may remain undetected to the wider NHDP Routers, the malicious device may remain undetected to the wider
network. network. It is a form of Interference and Overload with threat
consequences of Disruption [RFC4593].
Figure 3 illustrates Indirect Channel Overloading with NHDP. A Figure 3 illustrates Indirect Channel Overloading with NHDP. A
Compromised NHDP router X advertises a symmetric spoofed link to the Compromised NHDP Router X advertises a symmetric spoofed link to the
non-existing NHDP router B (at time t0). Router A selects X as MPR non-existing NHDP Router B (at time t0). Router A selects X as MPR
upon reception of the HELLO, and will trigger a HELLO at t1. upon reception of the HELLO, and will trigger a HELLO at t1.
Overhearing this triggered HELLO, the attacker sends another HELLO at Overhearing this triggered HELLO, the attacker sends another HELLO at
t2, advertising the link to B as lost, which leads to NHDP router A t2, advertising the link to B as lost, which leads to NHDP Router A
deselecting the attacker as MPR, and another triggered message at t3. deselecting the attacker as MPR, and another triggered message at t3.
The cycle may be repeated, alternating advertising the link X-B as The cycle may be repeated, alternating advertising the link X-B as
LOST and SYM. LOST and SYM.
MPRs(X) MPRs() MPRs(X) MPRs()
.---. .---. .---. .---. .---. .---. .---. .---.
| A | | A | | A | | A | | A | | A | | A | | A |
'---' '---' '---' '---' '---' '---' '---' '---'
| | | | | | | |
| SYM(B) | | LOST(B) | | SYM(B) | | LOST(B) |
skipping to change at page 11, line 19 skipping to change at page 12, line 19
consequence of the attacks described in Section 4. This description consequence of the attacks described in Section 4. This description
emphasizes the impacts on the MANET protocols OLSRv2 emphasizes the impacts on the MANET protocols OLSRv2
[I-D.ietf-manet-olsrv2], and SMF [RFC6621]. [I-D.ietf-manet-olsrv2], and SMF [RFC6621].
5.1. MPR Calculation 5.1. MPR Calculation
MPR selection (as used in e.g., [I-D.ietf-manet-olsrv2] and MPR selection (as used in e.g., [I-D.ietf-manet-olsrv2] and
[RFC6621]) uses information about a router's 1-hop and 2-hop [RFC6621]) uses information about a router's 1-hop and 2-hop
neighborhood, assuming that (i) this information is accurate, and neighborhood, assuming that (i) this information is accurate, and
(ii) all 1-hop neighbors are apt to act as as MPR, depending on the (ii) all 1-hop neighbors are apt to act as as MPR, depending on the
willingness they report. Thus, a Compromised NHDP router will seek willingness they report. Thus, a Compromised NHDP router may seek to
to manipulate the 1-hop and 2-hop neighborhood information in a manipulate the 1-hop and 2-hop neighborhood information in a router
router such as to cause the MPR selection to fail, leading to a such as to cause the MPR selection to fail, leading to a flooding
flooding disruption of TC messages. disruption of TC messages, which can result in incomplete topology
advertisement, or degrade the optimized flooding to classical
flooding.
5.1.1. Flooding Disruption due to Identity Spoofing 5.1.1. Flooding Disruption due to Identity Spoofing
A Compromised NHDP router can spoof the identify of other routers, to A Compromised NHDP router can spoof the identify of other routers, to
disrupt the MPR selection, so as to cache certain parts of the disrupt the MPR selection, so as to cache certain parts of the
network from the flooding traffic. network from the flooding traffic [IJNSIA2010].
In Figure 4, a Compromised NHDP router X spoofs the identity of B. In Figure 4, a Compromised NHDP router X spoofs the identity of B.
The link between X and C is correctly detected and listed in X's The link between X and C is correctly detected and listed in X's
HELLOs. Router A will receive HELLOs indicating links from, HELLOs. Router A will receive HELLOs indicating links from,
respectively B:{B-E}, X:{X-C, X-E}, and D:{D-E, D-C}. For router A, respectively B:{B-E}, X:{X-C, X-E}, and D:{D-E, D-C}. For router A,
X and D are equal candidates for MPR selection. To make sure the X X and D are equal candidates for MPR selection. To make sure the X
can be selected as MPR for router A, X can set its willingness to the can be selected as MPR for router A, X can set its willingness to the
maximum value. maximum value.
.---. .---. .---. .---. .---. .---.
skipping to change at page 13, line 34 skipping to change at page 14, line 34
or transiting NHDP router A (e.g., a message originating from S). or transiting NHDP router A (e.g., a message originating from S).
5.1.3. Broadcast Storm 5.1.3. Broadcast Storm
Compromised NHDP router may attack the network by attempting to Compromised NHDP router may attack the network by attempting to
degrade the performance of optimized flooding algorithms so as to be degrade the performance of optimized flooding algorithms so as to be
equivalent to classic flooding. This can be achieved by forcing an equivalent to classic flooding. This can be achieved by forcing an
NHDP router into choosing all its 1-hop neighbors as MPRs. In NHDP router into choosing all its 1-hop neighbors as MPRs. In
MANETs, a broadcast storm caused by classic flooding is a serious MANETs, a broadcast storm caused by classic flooding is a serious
problem which can result in redundancy, contention and collisions problem which can result in redundancy, contention and collisions
[broadcast-storm]. [MOBICOM99].
As shown in Figure 7, the Compromised NHDP router X spoofs the As shown in Figure 7, the Compromised NHDP router X spoofs the
identity of NHDP router B and, spoofs a link to router Y {B-Y} (Y identity of NHDP router B and, spoofs a link to router Y {B-Y} (Y
does not have to be exist). By doing so, the legitimate NHDP router does not have to be exist). By doing so, the legitimate NHDP router
A has to select the legitimate NHDP router B as its MPR, in order for A has to select the legitimate NHDP router B as its MPR, in order for
it to reach all its 2-hop neighbors. The Compromised NHDP router Y it to reach all its 2-hop neighbors. The Compromised NHDP router Y
can perform this identity+link spoofing for all of NHDP router A's can perform this identity+link spoofing for all of NHDP router A's
1-hop neighbors, thereby forcing NHDP router A to select all its 1-hop neighbors, thereby forcing NHDP router A to select all its
neighbors as MPR - disabling the optimization sought by the MPR neighbors as MPR - disabling the optimization sought by the MPR
mechanism. mechanism.
skipping to change at page 15, line 37 skipping to change at page 16, line 37
MANET is jammed, protocols could be specified that increase link MANET is jammed, protocols could be specified that increase link
metrics in NHDP for the jammed links. When a routing protocol, metrics in NHDP for the jammed links. When a routing protocol,
such as OLSRv2, uses NHDP for neighborhood discovery, other paths such as OLSRv2, uses NHDP for neighborhood discovery, other paths
leading "around" the jammed area would be preferred, and therefore leading "around" the jammed area would be preferred, and therefore
mitigate the threat to some extent. mitigate the threat to some extent.
o Section 4.2: DoS - DoS using a massive amount of HELLO messages o Section 4.2: DoS - DoS using a massive amount of HELLO messages
can be mitigated by admitting only trusted routers to the network. can be mitigated by admitting only trusted routers to the network.
[I-D.ietf-manet-nhdp-olsrv2-sec] specifies a mechanism for adding [I-D.ietf-manet-nhdp-olsrv2-sec] specifies a mechanism for adding
Integrity Check Values (ICVs) to HELLO messages and therefore Integrity Check Values (ICVs) to HELLO messages and therefore
providing an admittance mechanism for NHDP routers to a MANET. providing an admittance mechanism for NHDP Routers to a MANET.
(Note that adding ICVs adds itself a new DoS attack vector, as ICV (Note that adding ICVs adds itself a new DoS attack vector, as ICV
verification requires CPU and memory resources.) Using ICVs does verification requires CPU and memory resources.) Using ICVs does
however not address the problem of compromised routers. Detecting however not address the problem of compromised routers. Detecting
compromised routers could be addressed in new work. compromised routers could be addressed in new work.
[I-D.ietf-manet-nhdp-olsrv2-sec] mandates to implement a security [I-D.ietf-manet-nhdp-olsrv2-sec] mandates to implement a security
mechanism based on shared keys, which makes excluding single mechanism based on shared keys, which makes excluding single
compromised routers difficult; work could be done to facilitate compromised routers difficult; work could be done to facilitate
revocation mechanisms in certain MANET use cases where routers revocation mechanisms in certain MANET use cases where routers
have sufficient capabilities to support asymmetric keys. have sufficient capabilities to support asymmetric keys.
o Section 4.3: Eavesdropping - [I-D.ietf-manet-nhdp-olsrv2-sec] adds o Section 4.3: Eavesdropping - [I-D.ietf-manet-nhdp-olsrv2-sec] adds
ICVs to HELLO messages, but does not encrypt them. Therefore, ICVs to HELLO messages, but does not encrypt them. Therefore,
eavesdropping of control traffic is not mitigated. Future work eavesdropping of control traffic is not mitigated. Future work
could provide encryption of control traffic for sensitive MANET could provide encryption of control traffic for sensitive MANET
topologies. Note that, other than using a single shared secret topologies. Note that, other than using a single shared secret
key, encryption to a potentially a priori unknown set of key, encryption to a potentially a priori unknown set of
neighbors, especially without multiplying overheads, is non- neighbors, especially without multiplying overheads, is non-
trivial. trivial. By traffic analyzing, attackers could still deduce the
network information like HELLO message triggering, and HELLO
message size, even HELLO messages are encrypted.
o Section 4.4.2: Link spoofing - [I-D.ietf-manet-nhdp-olsrv2-sec] o Section 4.4.2: Link spoofing - [I-D.ietf-manet-nhdp-olsrv2-sec]
provides certain protection against link spoofing, but an NHDP provides certain protection against link spoofing, but an NHDP
Router has to "trust" the originator of a HELLO that the Router has to "trust" the originator of a HELLO that the
advertized links are correct. For example, if a router A reports advertized links are correct. For example, if a router A reports
a link to B, routers receiving HELLOs from A have to trust that B a link to B, routers receiving HELLOs from A have to trust that B
is actually a (symmetric) neighbor of A. New protocol work could is actually a (symmetric) neighbor of A. New protocol work could
address protection of links without overly increasing space and address protection of links without overly increasing space and
time overheads. An immediate suggestion for deployments is to time overheads. An immediate suggestion for deployments is to
protect routers against being compromised and distributing keys protect routers against being compromised and distributing keys
skipping to change at page 16, line 48 skipping to change at page 18, line 5
MANET routing protocols using NHDP for neighborhood discovery. MANET routing protocols using NHDP for neighborhood discovery.
8. IANA Considerations 8. IANA Considerations
This document contains no actions for IANA. This document contains no actions for IANA.
9. Acknowledgments 9. Acknowledgments
The authors would like to gratefully acknowledge the following people The authors would like to gratefully acknowledge the following people
for valuable comments and technical discussions: Teco Boot, Henning for valuable comments and technical discussions: Teco Boot, Henning
Rogge, Christopher Dearlove, John Dowdell, and the all the other Rogge, Christopher Dearlove, John Dowdell, Joseph Macker, and the all
participants of IETF MANET working group. the other participants of IETF MANET working group.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized Mobile Ad Hoc Network (MANET) Packet/Message "Generalized Mobile Ad Hoc Network (MANET) Packet/Message
Format", RFC 5444, February 2009. Format", RFC 5444, February 2009.
[RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value [RFC5497] Clausen, T. and C. Dearlove, "Representing Multi-Value
Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497, Time in Mobile Ad Hoc Networks (MANETs)", RFC 5497,
March 2009. March 2009.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "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, April 2011.
10.2. Informative References 10.2. Informative References
[ACCT2012]
Jhaveri, R. and S. Patel, "DoS Attacks in Mobile Ad Hoc
Networks: A Survey", Second International Conference
on Advanced Computing & Communication Technologies (ACCT),
Jan 2012.
[CPSCOM2011]
Yi, J., Clausen, T., and U. Herberg, "Vulnerability
Analysis of the Simple Multicast Forwarding (SMF) Protocol
for Mobile Ad Hoc Networks", Proceedings of the IEEE
International Conference on Cyber, Physical, and Social
Computing (CPSCom), October 2011.
[I-D.ietf-manet-nhdp-olsrv2-sec] [I-D.ietf-manet-nhdp-olsrv2-sec]
Herberg, U., Dearlove, C., and T. Clausen, "Integrity Herberg, U., Dearlove, C., and T. Clausen, "Integrity
Protection for Control Messages in NHDP and OLSRv2", Protection for Control Messages in NHDP and OLSRv2",
draft-ietf-manet-nhdp-olsrv2-sec-02 (work in progress), draft-ietf-manet-nhdp-olsrv2-sec-02 (work in progress),
April 2013. April 2013.
[I-D.ietf-manet-olsrv2] [I-D.ietf-manet-olsrv2]
Clausen, T., Dearlove, C., Jacquet, P., and U. Herberg, 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",
draft-ietf-manet-olsrv2-19 (work in progress), March 2013. draft-ietf-manet-olsrv2-19 (work in progress), March 2013.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [I-D.nguyen-manet-management]
RFC 4949, August 2007. Nguyen, J., Cole, R., Herberg, U., Yi, J., and J. Dean,
"Network Management of Mobile Ad hoc Networks (MANET):
Architecture, Use Cases, and Applicability",
draft-nguyen-manet-management-00 (work in progress),
February 2013.
[RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, [IJNSIA2010]
May 2012. Herberg, U. and T. Clausen, "Security Issues in the
Optimized Link State Routing Protocol version 2",
International Journal of Network Security & Its
Applications, April 2010.
[broadcast-storm] [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", Proceedings of
the 5th annual ACM/IEEE international conference on Mobile the 5th annual ACM/IEEE international conference on Mobile
computing and networking, 1999. computing and networking, 1999.
Authors' Addresses [RFC4593] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 4593, October 2006.
Ulrich Herberg [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
Fujitsu Laboratories of America RFC 4949, August 2007.
1240 E Arques Ave
Sunnyvale, CA 94085
USA
Email: ulrich@herberg.name [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621,
URI: http://www.herberg.name/ May 2012.
[RFC6779] Herberg, U., Cole, R., and I. Chakeres, "Definition of
Managed Objects for the Neighborhood Discovery Protocol",
RFC 6779, October 2012.
Authors' Addresses
Jiazi Yi Jiazi Yi
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Phone: +33 1 69 33 40 31 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/
Ulrich Herberg
Fujitsu Laboratories of America
1240 E Arques Ave
Sunnyvale, CA 94085
USA
Email: ulrich@herberg.name
URI: http://www.herberg.name/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, 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/
 End of changes. 73 change blocks. 
149 lines changed or deleted 238 lines changed or added

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