draft-ietf-manet-smf-sec-threats-00.txt   draft-ietf-manet-smf-sec-threats-01.txt 
Mobile Ad hoc Networking (MANET) J. Yi Mobile Ad hoc Networking (MANET) J. Yi
Internet-Draft T. Clausen Internet-Draft T. Clausen
Intended status: Informational LIX, Ecole Polytechnique Intended status: Informational LIX, Ecole Polytechnique
Expires: February 14, 2015 U. Herberg Expires: March 18, 2015 U. Herberg
Fujitsu Laboratories of America Fujitsu Laboratories of America
August 13, 2014 September 14, 2014
Security Threats for Simplified Multicast Forwarding (SMF) Security Threats for Simplified Multicast Forwarding (SMF)
draft-ietf-manet-smf-sec-threats-00 draft-ietf-manet-smf-sec-threats-01
Abstract Abstract
This document analyzes security threats of the Simplified Multicast This document analyzes security threats of the Simplified Multicast
Forwarding (SMF), including the vulnerabilities of duplicate packet Forwarding (SMF), including the vulnerabilities of duplicate packet
detection and relay set selection mechanisms. This document is not detection and relay set selection mechanisms. This document is not
intended to propose solutions to the threats described. intended to 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 35
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 February 14, 2015. This Internet-Draft will expire on March 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SMF Threats Overview . . . . . . . . . . . . . . . . . . . . . 4 3. SMF Threats Overview . . . . . . . . . . . . . . . . . . . . . 4
4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5 4. Threats to Duplicate Packet Detection . . . . . . . . . . . . 5
4.1. Threats to Identification-based Duplicate Packet 4.1. Threats to Identification-based Duplicate Packet
Detection . . . . . . . . . . . . . . . . . . . . . . . . 5 Detection . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Pre-activation Attacks (Pre-Play) . . . . . . . . . . 6 4.1.1. Pre-activation Attacks (Pre-Play) . . . . . . . . . . 6
4.1.2. De-activation Attacks (Sequence Number wrangling) . . 6 4.1.2. De-activation Attacks (Sequence Number wrangling) . . 6
4.2. Threats to Hash-based Duplicate Packet Detection . . . . . 7 4.2. Threats to Hash-based Duplicate Packet Detection . . . . . 7
4.2.1. Replay Attack . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Replay Attack . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Attack on Hash-Assistant Value . . . . . . . . . . . . 8 4.2.2. Attack on Hash-Assistant Value . . . . . . . . . . . . 8
5. Threats to Relay Set Selection . . . . . . . . . . . . . . . . 8 5. Threats to Relay Set Selection . . . . . . . . . . . . . . . . 9
5.1. Relay Set Selection Common Threats . . . . . . . . . . . . 9 5.1. Relay Set Selection Common Threats . . . . . . . . . . . . 9
5.2. Threats to E-CDS Algorithm . . . . . . . . . . . . . . . . 9 5.2. Threats to E-CDS Algorithm . . . . . . . . . . . . . . . . 9
5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Link Spoofing . . . . . . . . . . . . . . . . . . . . 10
5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 9 5.2.2. Identity Spoofing . . . . . . . . . . . . . . . . . . 10
5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 10 5.3. Threats to S-MPR Algorithm . . . . . . . . . . . . . . . . 10
5.4. Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 10 5.4. Threats to MPR-CDS Algorithm . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document analyzes security threats of the Simplified Multicast This document analyzes security threats of the Simplified Multicast
Forwarding (SMF) mechanism [RFC6621]. SMF aims at providing basic Forwarding (SMF) mechanism [RFC6621]. SMF aims at providing basic
Internet Protocol (IP) multicast forwarding, in a way which is Internet Protocol (IP) multicast forwarding, in a way which is
suitable for limited wireless mesh and Mobile Ad hoc NETworks suitable for limited wireless mesh and Mobile Ad hoc NETworks
(MANET). SMF is constituted of two major functional components: (MANET). SMF is constituted of two major functional components:
Duplicate Packet Detection and Relay Set Selection. Duplicate Packet Detection and Relay Set Selection.
skipping to change at page 3, line 27 skipping to change at page 3, line 27
significance as compared to wired networks. In [RFC6621], SMF does significance as compared to wired networks. In [RFC6621], SMF does
not define any explicit security measures for protecting the not define any explicit security measures for protecting the
integrity of the protocol. 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 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 on and mis- IPsec stack). The document analyzes possible attacks on and mis-
configurations of SMF and outlines the consequences of such attacks/ configurations of SMF and outlines the consequences of such attacks/
mis-configurations to the state maintained by SMF in each router mis-configurations to the state maintained by SMF in each router.
(and, thus, made available to protocols using this state).
This document aims at analyzing and describing the potential This document aims at analyzing and describing the potential
vulnerabilities of and attack vecors for SMF. While completeness in vulnerabilities of and attack vecors for SMF. While completeness in
such an analysis always is a goal, no claims of being complete are such an analysis always is a goal, no claims of being complete are
made. The goal of this document is to be helpful for when deploying made. The goal of this document is to be helpful for when deploying
SMF in a network and needing to understand the risks thereby incurred SMF in a network and needing to understand the risks thereby incurred
- as wll as for providing a reference and documented experience with - as wll as for providing a reference and documented experience with
SMF as input for possibly future developments of SMF. SMF as input for possibly 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, which can be used with described. [RFC7183] provides a framework, which can be used with
SMF, and which - depending on how it is used - may offer some degree SMF, and which - depending on how it is used - may offer some degree
of protection against the threats described in this document related of protection against the threats described in this document related
to identity spoofing. to identity spoofing.
2. Terminology 2. Terminology
This document uses the terminology and notation defined in [RFC2119], This document uses the terminology and notation defined in [RFC2119],
[RFC5444], [RFC6621] and [RFC4949]. [RFC5444], [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. seeks to compromise the information bases in SMF routers.
Compromised SMF router: An attacker, present in the network and Compromised SMF router: An attacker, present in the network and
which generates syntactically correct SMF control messages. which generates syntactically correct SMF control messages.
Control messages emitted by a compromised SMF router may contain Control messages emitted by a compromised SMF 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 SMF router located control message generated by a non-compromised SMF router located
in the same topological position in the network. in the same topological position in the network.
Legitimate SMF router: An SMF router, which is not a compromised SMF Legitimate SMF router: An SMF router, which is not a compromised SMF
Router. Router.
3. SMF Threats Overview 3. SMF Threats Overview
SMF requires an external dynamic neighborhood discovery mechanism in SMF requires an external dynamic neighborhood discovery mechanism in
orde to maintain suitable topological information describing its orde to maintain suitable topological information describing its
immediate neighborhood, and thereby allowing it to select reduced immediate neighborhood, and thereby allowing it to select reduced
skipping to change at page 6, line 10 skipping to change at page 6, line 10
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 packet, and determine the coming packet has been recently received packet, and determine the coming packet has been
received or not. received or not.
4.1.1. Pre-activation Attacks (Pre-Play) 4.1.1. Pre-activation Attacks (Pre-Play)
In a wireless environment, or across any other shared channel, a In a wireless environment, or across any other shared channel, a
compromised SMF router can perceive the identification tuple [source compromised SMF router can perceive the identification tuple [source
IP, sequence number] of a packet. If sequence number progression is IP, sequence number] of a packet. If sequence number progression is
predictable, then it is trivial to generate aand inject invalid predictable, then it is trivial to generate and inject invalid
packets with "future" identification information into the network. packets with "future" identification information into the network.
If these invalid packets arrive before the legitimate packets that If these invalid packets arrive before the legitimate packets that
they're spoofing, the latter will be treated as a duplicates and they're spoofing, the latter will be treated as a duplicates and
discarded. This can prevent multicast packets from reaching parts of discarded. This can prevent multicast packets from reaching parts of
the network. the network.
Figure 1 gives an example of pre-activation attack. A, B, and C are Figure 1 gives an example of pre-activation attack. A, B, and C are
legitimate SMF routers, and X is the compromised SMF router. The legitimate SMF routers, and X is the compromised SMF router. The
line between the routers presents the packet forwarding. Router A is line between the routers presents the packet forwarding. Router A is
the source and originates a multicast packet with sequence number n. the source and originates a multicast packet with sequence number n.
skipping to change at page 7, line 45 skipping to change at page 7, line 45
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. the same time, or in the same region at a different time.
One possible replay attack is based on the Time-to-Live (TTL, for One possible replay attack is based on the Time-to-Live (TTL, for
IPv4) or hop limit (for IPv6) field. As routers only forward packets IPv4) or hop limit (for IPv6) field. As routers only forward packets
with TTL > 1, a compromised SMF router can forward an otherwise valid with TTL > 1, a compromised SMF router can forward an otherwise valid
packet, while drastically reducing the TTL hereof. This will inhibit packet, while drastically reducing the TTL hereof. This will inhibit
recipient routers from later forwarding the same multicast packet, recipient routers from later forwarding the same multicast packet,
even if received with a different TTL - essentially a compromised SMF even if received with a different TTL - essentially a compromised SMF
router thus can instruct its neighbors to block forwarding of valid router thus can instruct its neighbors to block forwarding of valid
multicast packets. As the TTL of a packet is intended to be multicast packets.
manipulated by intermediaries forwarding it, classic methods such as
integrity check values (e.g., digital signatures) are typically For example, given the example in Figure 2, router A forwards a
calculated with setting TTL fields to some pre-determined value multicast packet with a TTL of 64 to the network. A, B, and C are
(e.g., 0) - such is for example the case for IPsec Authentication legitimate SMF routers, and X is the compromised SMF router. Router
Headers - rendering such an attack more difficult to both detect and X forwards the packet without jittering, and reduces the TTL to 1.
counter. If the compromised SMF router has access to a "wormhole" Router C thus records the hash value of the packets, but stops
through the network (a directional antenna, a tunnel to a forwarding it to the next hops because of the TTL value. When the
collaborator or a wired connection, allowing it to bridge parts of a same packet with normal TTL value (63 in this case) arrives from
network otherwise distant) it can make sure that the packets with router B, it will be discarded as duplicate packet.
such an artificially reduced TTL arrive before their unmodified
counterparts. .---.
| X |
--'---' __
packet with TTL=64 / \ packet with TTL=1
/ \
.---. .---.
| A | | C |
'---' '---'
packet with TTL=64 \ .---. /
\-- | B |__/ packet with TTL=63
'---'
Figure 2
As the TTL of a packet is intended to be manipulated by
intermediaries forwarding it, classic methods such as integrity check
values (e.g., digital signatures) are typically calculated with
setting TTL fields to some pre-determined value (e.g., 0) - such is
for example the case for IPsec Authentication Headers - rendering
such an attack more difficult to both detect and counter. If the
compromised SMF router has access to a "wormhole" through the network
(a directional antenna, a tunnel to a collaborator or a wired
connection, allowing it to bridge parts of a network otherwise
distant) it can make sure that the packets with such an artificially
reduced TTL arrive before their unmodified counterparts.
4.2.2. Attack on Hash-Assistant Value 4.2.2. Attack on 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 ingressing SMF router detects that only added when the source or the ingressing SMF router detects that
the coming packet has digest collision with previously generated the coming packet has digest collision with previously generated
packets, it actually can be regarded as a "flag" of potential digest packets, it actually can be regarded as a "flag" of potential digest
collision. A compromised SMF router can discover the HAV header, and collision. A compromised SMF router can discover the HAV header, and
be able to conclude a hash collision is possible if the HAV header is be able to conclude a hash collision is possible if the HAV header is
removed. By doing so, other SMF routers receiving the modified removed. By doing so, other SMF routers receiving the modified
packet will be treated as duplicate packet, and be dropped because it packet will be treated as duplicate packet, and be dropped because it
has the same hash value with precedent packet. has the same hash value with precedent packet.
In the example of Figure Figure 2, Router A and B are legitimate SMF In the example of Figure Figure 3, Router A and B are legitimate SMF
routers, X is a compromised SMF router. A generate two packets P1 routers, X is a compromised SMF router. A generate two packets P1
and P2, with the same hash value h(P1)=h(P2)=x. Based on SMF and P2, with the same hash value h(P1)=h(P2)=x. Based on SMF
specification, a hash-assistant value (HAV) is added to the latter specification, a hash-assistant value (HAV) is added to the latter
packet P2, so that h(P2+HAV)=x', to avoid digest collision. When the packet P2, so that h(P2+HAV)=x', to avoid digest collision. When the
attacker X detects the HAV of P2, it is able to conclude that a attacker X detects the HAV of P2, it is able to conclude that a
collision is possible by removing the HAV header. By doing so, collision is possible by removing the HAV header. By doing so,
packet P2 will be treated as duplicate packet by router B, and be packet P2 will be treated as duplicate packet by router B, and be
dropped. 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 2 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 RSS mechanism, rather than a specific RSS algorithm
is provided by SMF. It is normally achieved by distributed is provided by SMF. It is normally achieved by distributed
algorithms that can dynamically generate a topological Connected algorithms that can dynamically generate a topological Connected
Dominating Set based on 1-hop and 2-hop neighborhood information. In Dominating Set based on 1-hop and 2-hop neighborhood information. In
this section, the common threats to the RSS framework are first this section, the common threats to the RSS framework are first
discussed. Then the three commonly used algorithms: Essential discussed. Then the three commonly used algorithms: Essential
Connection Dominating Set (E-CDS) algorithm, Source-based Multipoint Connection Dominating Set (E-CDS) algorithm, Source-based Multipoint
skipping to change at page 10, line 47 skipping to change at page 11, line 26
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, the vulnerabilities of E-CDS and As MPR-CDS combines E-CDS and S-MPR, the vulnerabilities of E-CDS and
S-MPR that discussed in Section 5.2 and Section 5.3 apply to MPR-CDS S-MPR that discussed in Section 5.2 and Section 5.3 apply to MPR-CDS
also. also.
6. Security Considerations 6. Future Work
Neither [RFC6621] nor this document propose mechanisms to secure the
SMF protocol. However, this section aims at discussing possibilities
to secure the protocol in the future and driving new work by
suggesting which threats discussed in the previous sections could be
addressed.
If NHDP is used as the neighborhood discovery protocol, [RFC7183] is
recommended to be implemented to enable integrity protection to NHDP,
which can help mitigating the threats related to identity spoofing
through the exchange of HELLO messages.
[RFC7183] provides certain protection against identity spoofing by
admitting only trusted routers to the network using Integrity Check
Values (ICVs) in HELLO messages. However, using ICVs does not
address the problem of compromised routers that can generate valid
ICVs. Detecting such compromised routers could be studied in new
work. [RFC7183] mandates implementation of a security mechanism that
is based on shared keys and makes excluding single compromised
routers difficult. Work could be done to facilitate revocation
mechanisms in certain MANET use cases where routers have sufficient
capabilities to support asymmetric keys.
As [RFC7183] does not protect the integrity of the datagram, and no
mechanism is specified to do that for SMF yet, the duplicate packet
detection is still vulnerable to the threats introduced in Section 4.
If pre-activation/de-activation attacks and attack on hash-assistant
value are to be mitigated, a datagram-level integrity protection
mechanism is desired, by taking consideration of the identity field
or hash-assistant value. However, this would not be helpful for the
attacks on the TTL (or hop limit for IPv6) field, because the mutable
fields are generally not considered when ICV is calculated.
7. Security Considerations
This document does not specify a protocol or a procedure. The This document does not specify a protocol or a procedure. The
document, however, reflects on security considerations for SMF for document, however, reflects on security considerations for SMF for
packet dissemination in MANETs. packet dissemination in MANETs.
7. IANA Considerations 8. IANA Considerations
This document contains no actions for IANA. This document contains no actions for IANA.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, August 2009.
[RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621, [RFC6621] Macker, J., "Simplified Multicast Forwarding", RFC 6621,
May 2012. May 2012.
[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. April 2014.
8.2. Informative References 9.2. Informative References
[RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State [RFC3626] Clausen, T. and P. Jacquet, "The Optimized Link State
Routing Protocol", RFC 3626, October 2003. Routing Protocol", RFC 3626, October 2003.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[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, February 2008.
skipping to change at page 12, line 6 skipping to change at page 13, line 21
February 2009. February 2009.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol (NHDP)", Network (MANET) Neighborhood Discovery Protocol (NHDP)",
RFC 6130, April 2011. RFC 6130, April 2011.
[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, April 2014.
[RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity [RFC7183] Herberg, U., Dearlove, C., and T. Clausen, "Integrity
Check Value and Timestamp TLV Definitions for Mobile Ad Protection for the Neighborhood Discovery Protocol (NHDP)
Hoc Networks (MANETs)", RFC 7182, April 2014. and Optimized Link State Routing Protocol Version 2
(OLSRv2)", RFC 7183, April 2014.
Authors' Addresses Authors' Addresses
Jiazi Yi Jiazi Yi
LIX, Ecole Polytechnique LIX, 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
 End of changes. 20 change blocks. 
41 lines changed or deleted 101 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/