Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing
draft-perkins-manet-aodvv2-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Charles E. Perkins , Stan Ratliff , John Dowdell , Lotte Steenbrink , Victoria Mercieca | ||
| Last updated | 2018-12-20 (Latest revision 2017-10-30) | ||
| Replaces | draft-ietf-manet-aodvv2 | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Formats | |||
| Reviews | |||
| Additional resources | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Sri Gundavelli | ||
| IESG | IESG state | AD Evaluation::Revised I-D Needed | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | Alvaro Retana | ||
| Send notices to | Sri Gundavelli <sgundave@cisco.com>, aretana.ietf@gmail.com |
draft-perkins-manet-aodvv2-02
Perkins, et al. Expires May 3, 2018 [Page 69] Internet-Draft AODVv2 October 2017 MAX_SEQNUM_LIFETIME. This would delay route discovery from and to the re-initializing router. o Routers with lower values for ACTIVE_INTERVAL + MAX_IDLETIME will invalidate routes more quickly and free resources used to maintain them. This can affect bursty traffic flows which have quiet periods longer than ACTIVE_INTERVAL + MAX_IDLETIME. A route which has timed out due to perceived inactivity is not reported. When the bursty traffic resumes, it would cause a RERR to be generated, and the traffic itself would be dropped. This route would be removed from all upstream routers, even if those upstream routers had larger ACTIVE_INTERVAL or MAX_IDLETIME values. A new route discovery would be required to re-establish the route, causing extra routing protocol traffic and disturbance to the bursty traffic. o Routers with lower values for MAX_BLACKLIST_TIME would allow neighboring routers to participate in route discovery sooner than routers with higher values. This could result in failed route discoveries if un-blacklisted links are still uni-directional. Since RREQs are retried, this would not affect success of route discovery unless this value was so small as to un-blacklist the router before the RREQ is retried. This value need not be consistent across the network since it is used for maintaining a 1-hop blacklist. However it MUST be greater than RREQ_WAIT_TIME; the default value is much larger. o Routers with lower values for RERR_TIMEOUT may create more RERR messages than routers with higher values. This value should be large enough that a RERR will reach all routers using the route reported within it before the timer expires, so that no further data traffic will arrive, and no duplicated RERR messages will be generated. o Routers with lower values for RteMsg_ENTRY_TIME may not consider received redundant multicast route messages as redundant, and may forward these messages unnecessarily. o Routers with lower values for RREQ_WAIT_TIME may send more frequent RREQ messages and wrongly determine that a route does not exist, if the delay in receiving an RREP is greater than this interval. o Routers with lower values for RREP_Ack_SENT_TIMEOUT may wrongly determine links to neighbors to be unidirectional if an RREP_Ack is delayed longer than this timeout. Perkins, et al. Expires May 3, 2018 [Page 70] Internet-Draft AODVv2 October 2017 o Routers with lower values for RREQ_HOLDDOWN_TIME will retry failed route discoveries sooner than routers with higher values. This may be an advantage if the network topology is frequently changing, or may unnecessarily cause more routing protocol traffic. MAX_SEQNUM_LIFETIME MUST be configured to have the same values for all AODVv2 routers in the network. 12.2. Protocol Constants AODVv2 protocol constants typically do not require changes. The following table lists these constants, along with their values and a reference to the section describing their use. +------------------------+-------------+----------------------------+ | Name | Default | Description | +------------------------+-------------+----------------------------+ | DISCOVERY_ATTEMPTS_MAX | 3 | Section 6.6 | | RREP_RETRIES | 2 | Section 7.2.1 | | MAX_METRIC[MetricType] | [see below] | Section 5 | | MAX_METRIC[HopCount] | 255 | Section 5 and Section 7 | | MAX_HOPCOUNT | 20 | Limit to number of hops an | | | | RREQ or RREP message can | | | | traverse | | INFINITY_TIME | [see below] | Maximum expressible clock | | | | time (Section 6.7.2) | +------------------------+-------------+----------------------------+ Table 3: AODVv2 Constants MAX_HOPCOUNT cannot be larger than 255. MAX_METRIC[MetricType] MUST always be the maximum expressible metric value of type MetricType. Field lengths associated with metric values are found in Section 13.4. These protocol constants MUST have the same values for all AODVv2 routers in the ad hoc network. If the values were configured differently, the following consequences may be observed: o DISCOVERY_ATTEMPTS_MAX: Routers with higher values are likely to be more successful at finding routes, at the cost of additional control traffic. o RREP_RETRIES: Routers with lower values are more likely to blacklist neighbors when there is a temporary fluctuation in link quality. Perkins, et al. Expires May 3, 2018 [Page 71] Internet-Draft AODVv2 October 2017 o MAX_METRIC[MetricType]: No interoperability problems due to variations on different routers, but routers with lower values may exhibit overly restrictive behavior during route comparisons. o MAX_HOPCOUNT: Routers with a value too small would not be able to discover routes to distant addresses. o INFINITY_TIME: No interoperability problems due to variations on different routers, but if a lower value is used, route state management may exhibit overly restrictive behavior. 12.3. Local Settings The following table lists AODVv2 parameters which SHOULD be administratively configured for each router: +------------------------+---------------------------+--------------+ | Name | Default Value | Description | +------------------------+---------------------------+--------------+ | Interface Set | | Section 4.1 | | Router Client Set | | Section 4.2 | | BUFFER_SIZE_PACKETS | 2 | Section 6.6 | | BUFFER_SIZE_BYTES | MAX_PACKET_SIZE [TBD] | Section 6.6 | | CONTROL_TRAFFIC_LIMIT | [Adjust for 10% capacity] | Section 7 | +------------------------+---------------------------+--------------+ Table 4: Configuration for Local Settings 12.4. Network-Wide Settings The following administrative controls MAY be used to change the operation of the network. The same settings SHOULD be used across the network. Inconsistent settings at different routers in the network will not result in protocol errors. +----------------------+-----------+----------------+ | Name | Default | Description | +----------------------+-----------+----------------+ | ENABLE_IDLE_IN_RERR | Disabled | Section 7.4.1 | +----------------------+-----------+----------------+ Table 5: Configuration for Network-Wide Settings 13. IANA Considerations This section specifies several [RFC5444] message types and address tlv-types required for AODVv2, as well as a new Code value for ICMP Destination Unreachable. Perkins, et al. Expires May 3, 2018 [Page 72] Internet-Draft AODVv2 October 2017 13.1. RFC 5444 Message Type Allocation This specification defines four Message Types, to be allocated from the 0-223 range of the "Message Types" namespace defined in [RFC5444]. +-----------------------------------------+-----------+ | Name of Message | Type | +-----------------------------------------+-----------+ | Route Request (RREQ) | 10 (TBD) | | Route Reply (RREP) | 11 (TBD) | | Route Error (RERR) | 12 (TBD) | | Route Reply Acknowledgement (RREP_Ack) | 13 (TBD) | +-----------------------------------------+-----------+ 13.2. RFC 5444 Message TLV Types This specification defines one Message TLV Type, to be allocated from the Message-Type-specific "Message TLV Types" namespace defined in [RFC5444], as specified in Table 6. +------------------------+----------+---------------+---------------+ | Name of TLV | Type | Length | Reference | | | | (octets) | | +------------------------+----------+---------------+---------------+ | ACK_REQ | 128 | 0 | Section 6.2 | | | (TBD) | | | +------------------------+----------+---------------+---------------+ Table 6: AODVv2 Message TLV Types 13.3. RFC 5444 Address Block TLV Type Allocation This specification defines three Address Block TLV Types, to be allocated from the Message-Type-specific "Address Block TLV Types" namespace defined in [RFC5444], as specified in Table 7. Perkins, et al. Expires May 3, 2018 [Page 73] Internet-Draft AODVv2 October 2017 +------------------------+----------+---------------+---------------+ | Name of TLV | Type | Length | Reference | | | | (octets) | | +------------------------+----------+---------------+---------------+ | PATH_METRIC | 129 | depends on | Section 7 | | | (TBD) | MetricType | | | SEQ_NUM | 130 | 2 | Section 7 | | | (TBD) | | | | ADDRESS_TYPE | 131 | 1 | Section 8 | | | (TBD) | | | +------------------------+----------+---------------+---------------+ Table 7: AODVv2 Address Block TLV Types 13.4. MetricType Allocation The metric types used by AODVv2 are identified according to Table 8. All implementations MUST use these values. +---------------------+----------+--------------------+ | Name of MetricType | Type | Metric Value Size | +---------------------+----------+--------------------+ | Unassigned | 0 | Undefined | | Hop Count | 1 | 1 octet | | Unallocated | 2 - 254 | TBD | | Reserved | 255 | Undefined | +---------------------+----------+--------------------+ Table 8: AODVv2 Metric Types 13.5. ADDRESS_TYPE TLV Values These values are used in the [RFC5444] Address Type TLV discussed in Section 8. All implementations MUST use these values. +---------------+--------+ | Address Type | Value | +---------------+--------+ | ORIGPREFIX | 0 | | TARGPREFIX | 1 | | UNREACHABLE | 2 | | PKTSOURCE | 3 | | UNSPECIFIED | 255 | +---------------+--------+ Table 9: AODVv2 Address Types Perkins, et al. Expires May 3, 2018 [Page 74] Internet-Draft AODVv2 October 2017 13.6. ICMPv6 Code Field for ICMP Destination Unreachable A new Code Value is defined for ICMP Destination Unreachable messages (see Section 7.1.2). +-----------------------+----------+ | Code Value | Value | +-----------------------+----------+ | Metric Type Mismatch | 8 (TBD) | +-----------------------+----------+ Table 10: AODVv2 ICMPv6 Code Field value 14. Security Considerations This section describes various security considerations and potential avenues to secure AODVv2 routing. The main objective of the AODVv2 protocol is for each router to communicate reachability information about addresses for which it is responsible, and for routes it has discovered from other AODVv2 routers. Networks using AODVv2 to maintain connectivity and establish routes on demand may be vulnerable to certain well-known types of threats, which will be detailed in this section. Some of the threats described can be mitigated or eliminated. Tools to do so will be described. With the exception of metric values, AODVv2 assures the integrity of all RteMsg data end-to-end though the use of ICVs (see Section 14.4.2. AODVv2 implementations support ICV and TIMESTAMP TLVs, unless the implementation is intended for an environment in which security is unnecessary; otherwise, AODVv2 deployments are configured to use these TLVs to secure messages. The on-demand nature of AODVv2 route discovery automatically reduces the vulnerability to route disruption. Since control traffic for updating route tables is diminished, there is less opportunity for attack and failure. 14.1. Availability Threats to AODVv2 which reduce availability are considered below. 14.1.1. Denial of Service Flooding attacks using RREQ amount to a (BLIND) denial of service for route discovery: By issuing RREQ messages for targets that don't exist, an attacker can flood the network, blocking resources and Perkins, et al. Expires May 3, 2018 [Page 75] Internet-Draft AODVv2 October 2017 drowning out legitimate traffic. By triggering the generation of CONTROL_TRAFFIC_LIMIT amount of messages (for example by sending RREQs for many non-existent destinations), an attacker can prevent legitimate messages from being generated. The effect of this attack is dampened by the fact that duplicate RREQ messages are dropped (preventing the network from DDoSing itself). Processing requirements for AODVv2 messages are typically quite small, however AODVv2 routers receiving RREQs do allocate resources in the form of Neighbor Set, Local Route Set and Multicast Route Message Set entries. The attacker can maximize their impact on set growth by changing OrigPrefix or OrigPrefixLen for each RREQ. If a specific node is to be targeted, this attack may be carried out in a DISTRIBUTED fashion, either by compromising its direct neighbors or by specifying the target's address with TargPrefix and TargPrefixLen. Note that it might be more economical for the attacker to simply jam the medium; an attack which AODVv2 cannot defend itself against. Mitigation: o If AODVv2 routers always verify that the sender of the RERR message is trusted, this threat is reduced. Processing requirements would typically be dominated by calculations to verify integrity. This has the effect of reducing (but by no means eliminating) AODVv2's vulnerability to denial of service attacks. o Authentication of senders can prevent unauthenticated routers from launching a Denial of Service attack on another AODVv2 router. However, this does not protect the network if an attacker has access to an already authenticated router. 14.1.2. Malicious RERR messages RERR messages are designed to cause removal of installed routes. A malicious node could send an RERR message with false information to attempt to get other routers to remove a route to one or more specific destinations, therefore disrupting traffic to the advertised destinations. Routes will be deleted if an RERR is received, withdrawing a route for which the sender is the receiver's next hop, if both of the following conditions are met: o the RERR includes the MetricType of the installed route, o the RERR includes either no sequence number for the route, or includes a greater sequence number than the sequence number stored with that route in the receiver's Local Route Set. Perkins, et al. Expires May 3, 2018 [Page 76] Internet-Draft AODVv2 October 2017 Routes will also be deleted if a received RERR contains a PktSource address corresponding to a Router Client. The information necessary to construct a malicious RERR could be discovered by eavesdropping, either by listening to AODVv2 messages or by watching data packet flows. When the RERR is multicast, it can be received by many routers in the ad hoc network, and will be regenerated when processing results in an active route being removed. This threat could have serious impact on applications communicating by way of the sender of the RERR message. o The set of routers which use the malicious router as a next hop may be targeted with a malicious RERR with no PktSource address included, if the RERR contains routes for which the malicious router is a next hop from the receiving router. However, since the sender of the RERR message is either malicious or broken, it is better that it is not used as a next hop for these routes anyway. o A single router which does not use the malicious router as part of its route may be targeted with a malicious RERR with a PktSource address included. o Replayed RERR messages could be used to disrupt active routes. Mitigation: o Protection against eavesdropping of AODVv2 messages would mitigate this attack to some extent, but eavesdropping of data packets can also be used to deduce the information about which routes could be targeted. o Protection against a malicious router becoming part of a route will mitigate the attack where a set of routers are targeted. This will not protect against the attack if a PktSource address is included. o By only regenerating RERR messages where active routes are removed, the spread of the malicious RERR is limited. o Including sequence numbers in RERR messages offers protection against attacks using replays of these RERR messages. o If AODVv2 routers always verify that the sender of the RERR message is trusted, this threat is reduced. Perkins, et al. Expires May 3, 2018 [Page 77] Internet-Draft AODVv2 October 2017 14.1.3. False Confirmation of Link Bidirectionality Links could be erroneously treated as bidirectional if malicious unsolicited or spoofed RREP messages were to be accepted. This would result in a route being installed which could not in fact be used to forward data to the destination, and may divert data packets away from the intended destination. There is a window of RREQ_WAIT_TIME after an RREQ is sent, in which any malicious router could send an RREP in response, in order for the link to the malicious router to be deemed as bidirectional. Mitigation: o Ignoring unsolicited RREP and RREP_Ack messages partially mitigates against this threat. o If AODVv2 routers always verify that the sender of the RREP message is trusted, this threat is reduced. 14.1.4. Message Deletion A malicious router could decide not to forward an RREQ or RREP or RERR message. Not forwarding a RERR or RREP message would disrupt route discovery. Not regenerating a RERR message would result in the source of data packets continuing to maintain and use the route, and further RERR messages being generated by the sender of the non- regenerated RERR. A malicious router could intentionally disrupt traffic flows by not allowing the source of data traffic to re- discover a new route when one breaks. Failing to send an RREP_Ack would also disrupt route establishment, by not allowing the reverse route to be validated. Return traffic which needs that route will prompt a new route discovery, wasting resources and incurring a slight delay but not disrupting the ability for applications to communicate. Mitigation: o None. Note that malicious router would have to wait for a route to break before it could perform this attack. 14.2. Confidentiality Passive inspection (eavesdropping) of AODVv2 control messages could enable unauthorized devices to gain information about the network topology, since exchanging such information is the main purpose of AODVv2. Perkins, et al. Expires May 3, 2018 [Page 78] Internet-Draft AODVv2 October 2017 Eavesdropping of data traffic could allow a malicious device to obtain information about how data traffic is being routed. With knowledge of source and destination addresses, malicious messages could be constructed to disrupt normal operation. 14.3. Integrity of Routes Integrity of route information can be compromised in the following types of attack: 14.3.1. Message Insertion Valid route set entries can be replaced or modified by maliciously constructed AODVv2 messages, destroying existing routes and the network's integrity. Any router may pose as another router by sending RREQ, RREP, RREP_Ack and RERR messages in its name. o Sending an RREQ message with false information can disrupt traffic to OrigPrefix, if the sequence number attached is not stale compared to any existing information about OrigPrefix. Since RREQ is multicast and likely to be received by all routers in the ad hoc network, this threat could have serious impact on applications communicating with OrigPrefix. o The actual threat to disrupt routes to OrigPrefix is reduced by the AODVv2 mechanism of marking RREQ-derived routes as "Unconfirmed" until the route to OrigAddr can be confirmed. o Sending an RREP message with false information can disrupt traffic to TargPrefix. Since RREP is unicast, and ignored if a corresponding RREQ was not recently sent, this threat is minimized, and is restricted to receivers along the path from OrigAddr to TargAddr. o Sending an RREP_Ack response message with false information can cause the route to an originator address to be erroneously accepted even though the route would contain a unidirectional link and thus not be suitable for most traffic. Since the RREP_Ack response is unicast, and ignored if an RREP_Ack was not sent recently to the sender of this RREP_Ack response, this threat is minimized and is strictly local to the RREP transmitter expecting the acknowledgement. Unsolicited RREP_Acks are ignored. o Sending an RERR message with false information is discussed in Section 14.1.2. Mitigation: Perkins, et al. Expires May 3, 2018 [Page 79] Internet-Draft AODVv2 October 2017 o If AODVv2 routers always verify that the sender of a message is trusted, this threat is reduced. 14.3.2. Message Modification - Man in the Middle Any AODVv2 router can forward messages with modified data. Mitigation: o If AODVv2 routers verify the integrity of AODVv2 messages, then the threat of disruption is minimized. A man in the middle with no knowledge of the key used to calculate an integrity check value may modify a message but the message will be rejected when it fails an integrity check. 14.3.3. Replay Attacks Replaying of RREQ or RREP messages would be of less use to an attacker, since they would be dropped immediately due to their stale sequence number. RERR messages may or may not include sequence numbers and are therefore susceptible to replay attacks. RREP_Ack messages do not include sequence numbers and are therefore susceptible to replay attacks. Mitigation: o Use of timestamps or sequence numbers prevents replay attacks. 14.4. Protection Mechanisms 14.4.1. Confidentiality and Authentication Encryption MAY be used for AODVv2 messages. If the routers share a packet-level security association, the message data can be encrypted prior to message transmission. The establishment of such security associations is outside the scope of this specification. Encryption will not only protect against unauthorized devices obtaining information about network topology (eavesdropping) but will ensure that only trusted routers participate in routing operations. 14.4.2. Message Integrity using ICVs Cryptographic Integrity Check Values (ICVs) can be used to ensure integrity of received messages, protecting against man in the middle attacks. Further, by using ICVs, only those routers with knowledge of a shared secret key are allowed to participate in routing information exchanges. [RFC7182] defines ICV TLVs for use with [RFC5444]. Perkins, et al. Expires May 3, 2018 [Page 80] Internet-Draft AODVv2 October 2017 The data contained in AODVv2 routing protocol messages MUST be verified using Integrity Check Values, to avoid accepting tampered messages. 14.4.3. Replay Protection using Timestamps [RFC7182] defines a TIMESTAMP TLV for use with [RFC5444] which can be used to prevent replay attacks when sequence numbers are not already included. The data contained in AODVv2 routing protocol messages can be protected with a TIMESTAMP value to ensure the protection against replaying of the message. Sequence numbers can be used in place of timestamps, since they are known to be strictly increasing. 14.5. Key Management The method of distribution of shared secret keys is out of the scope of this protocol. Key management is not specified for the following reasons: Against [RFC4107], an analysis as to whether automated or manual key management should be used shows a compelling case for automated management. In particular: o a potentially large number of routers may have to be managed, belonging to several organisations, for example in vehicular applications. o a stream cipher is likely to be used, such as an AES variant. o long term session keys might be used by more than two parties, including multicast operations. AODVv2 makes extensive use of multicast. o there may be frequent turnover of devices. On reviewing the case for manual key management against the same document, it can be seen that manual management might be advantageous in environments with limited bandwidth or high round trip times. AODVv2 lends itself to sparse ad hoc networks where transmission conditions may indeed be limited, depending on the bearers selected for use. However, [RFC4107] assumes that the connectivity between endpoints is already available. In AODVv2, no route is available to a given destination until a router client requests that user traffic be transmitted. It is required to secure the signalling path of the Perkins, et al. Expires May 3, 2018 [Page 81] Internet-Draft AODVv2 October 2017 routing protocol that will establish the path across which key exchange functions might subsequently be applied, which is clearly the reverse of the expected functionality. A different strategy is therefore required. There are two possible solutions. In each case, it is assumed that a defence in depth security posture is being adopted by the system integrator, such that each function in the network as a whole is appropriately secured or defended as necessary, and that there is not complete reliance on security mechanisms built in to AODVv2. Such additional mechanisms could include a suitable wireless device security technology, so that wireless devices are authenticated and secured by their peers prior to exchanging user data, which in this case would include AODVV2 signalling traffic as a payload, and mechanisms which verify the authenticity and/or integrity of application-layer user data transported once a route has been established. 1. In the case that no AODVv2 routers have any detailed prior knowledge of any other AODVv2 router, but does have knowledge of the credentials of other organisations in which the router has been previously configured to trust, it is possible for an AODVv2 router to send an initialisation vector as part of an exchange, which could be verified against such credentials. Such an exchange could make use of Identity-Based Signatures ([I-D.ietf-manet-ibs]), based on Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption [RFC6507], which eliminate the need for a handshake process to establish trust. 2. If it is impossible to use Identity-Based Signatures, and the risk to the AODVv2 signalling traffic is considered to be low due to the use of security countermeasures elsewhere in the system, a simple pre-placed shared secret could be used between routers, which is used as-is or is used to generate some ephemeral secret based on another known variable, such as time of day if that is universally available at a level of accuracy sufficient to make such a system viable. 15. Acknowledgments AODVv2 is a descendant of the design of previous MANET on-demand protocols, especially AODV [RFC3561] and DSR [RFC4728]. Changes to previous MANET on-demand protocols stem from research and implementation experiences. Thanks to Elizabeth Belding and Ian Chakeres for their long time authorship of AODV. Additional thanks to Derek Atkins, Emmanuel Baccelli, Abdussalam Baryun, Ramon Caceres, Justin Dean, Christopher Dearlove, Fatemeh Ghassemi, Ulrich Herberg, Perkins, et al. Expires May 3, 2018 [Page 82] Internet-Draft AODVv2 October 2017 Henner Jakob, Ramtin Khosravi, Luke Klein-Berndt, Lars Kristensen, Tronje Krop, Koojana Kuladinithi, Kedar Namjoshi, Keyur Patel, Alexandru Petrescu, Henning Rogge, Fransisco Ros, Pedro Ruiz, Christoph Sommer, Romain Thouvenin, Richard Trefler, Jiazi Yi, Seung Yi, Behnaz Yousefi, and Cong Yuan, for their reviews of AODVv2 and DYMO, as well as numerous specification suggestions. 16. References 16.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- Demand Distance Vector (AODV) Routing", RFC 3561, DOI 10.17487/RFC3561, July 2003, <https://www.rfc-editor.org/info/rfc3561>. [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, "Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format", RFC 5444, DOI 10.17487/RFC5444, February 2009, <https://www.rfc-editor.org/info/rfc5444>. [RFC5498] Chakeres, I., "IANA Allocations for Mobile Ad Hoc Network (MANET) Protocols", RFC 5498, DOI 10.17487/RFC5498, March 2009, <https://www.rfc-editor.org/info/rfc5498>. [RFC7182] Herberg, U., Clausen, T., and C. Dearlove, "Integrity Check Value and Timestamp TLV Definitions for Mobile Ad Hoc Networks (MANETs)", RFC 7182, DOI 10.17487/RFC7182, April 2014, <https://www.rfc-editor.org/info/rfc7182>. 16.2. Informative References [I-D.ietf-manet-ibs] Dearlove, C., "Identity-Based Signatures for MANET Routing Protocols", draft-ietf-manet-ibs-05 (work in progress), March 2016. [I-D.ietf-roll-aodv-rpl] Anamalamudi, S., Zhang, M., Sangi, A., Perkins, C., and S. Anand, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy Networks (LLNs)", draft-ietf-roll-aodv-rpl-02 (work in progress), September 2017. Perkins, et al. Expires May 3, 2018 [Page 83] Internet-Draft AODVv2 October 2017 [Koodli01] Koodli, R. and C. Perkins, "Fast handovers and context transfers in mobile networks", Proceedings of the ACM SIGCOMM Computer Communication Review 2001, Volume 31 Issue 5, 37-47, October 2001. [Perkins94] Perkins, C. and P. Bhagwat, "Highly Dynamic Destination- Sequenced Distance-Vector Routing (DSDV) for Mobile Computers", Proceedings of the ACM SIGCOMM '94 Conference on Communications Architectures, Protocols and Applications, London, UK, pp. 234-244, August 1994. [RFC2501] Corson, S. and J. Macker, "Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Considerations", RFC 2501, DOI 10.17487/RFC2501, January 1999, <https://www.rfc-editor.org/info/rfc2501>. [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <https://www.rfc-editor.org/info/rfc4107>. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, <https://www.rfc-editor.org/info/rfc4193>. [RFC4728] Johnson, D., Hu, Y., and D. Maltz, "The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4", RFC 4728, DOI 10.17487/RFC4728, February 2007, <https://www.rfc-editor.org/info/rfc4728>. [RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)", RFC 6130, DOI 10.17487/RFC6130, April 2011, <https://www.rfc-editor.org/info/rfc6130>. [RFC6507] Groves, M., "Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)", RFC 6507, DOI 10.17487/RFC6507, February 2012, <https://www.rfc-editor.org/info/rfc6507>. [RFC7251] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS", RFC 7251, DOI 10.17487/RFC7251, June 2014, <https://www.rfc-editor.org/info/rfc7251>. Perkins, et al. Expires May 3, 2018 [Page 84] Internet-Draft AODVv2 October 2017 Appendix A. Most Recent AODVv2 Draft Updates This section lists the changes between recent AODVv2 revisions ...-01.txt and ...-02.txt. o Changed notation for entries in Multicast Route Message table from RteMsg to McMsg {for Multicast Message} (see Table 1, Section 4.6, and Section 6.8). o Sharpened description of suppressing multicast messages to apply only to RREQs (see Section 6.8). o Supplied AES-CCM as the default choice for HASH_FUNCTION and CRYPTOGRAPHIC_FUNCTION (see Section 11). o Changed the names of the Neighbor.State to be capitalized: CONFIRMED, HEARD, and BLACKLISTED (see Section 4.3). o Created a new Code field value for ICMP Destination Unreachable messages (see Section 13.6). This allows the target of a RREQ to inform RREQ_Gen that the requested Metric Type is not available (see Section 7.1.2). This will prevent continued flooding for a Route Discovery that can never be satisfied. o Corrected various typos and made some stylistic improvements and clarifications. Appendix B. Previous AODVv2 Draft Updates This section lists the changes between recent AODVv2 revisions ...-00.txt and ...-01.txt. o Add RerrMsg as a Notational Convenience Table 1 o Wordsmithing, reduce repeated text o Restore optional Precursor feature (see Section 10) o Correct misuse of RFC 2119 language o Revise the method by which a multi-hop path is deemed to be Confirmed o Remove technical specification details from definitions o Move security operational mandates from Security Considerations into a new section Section 11 Perkins, et al. Expires May 3, 2018 [Page 85] Internet-Draft AODVv2 October 2017 o Sharpen language related to assuring that routing must follow paths appropriate to the metric type for which the route was established (see Section 5). o Replace rambling paragraphs by itemized lists to improve readability o Allow use of MAC-layer hints about bidirectionality (see Section 6.2). o Define concepts of compatibility and comparability for Multicast Route Message entries (see Section 6.8). This is needed to enable proper comparisons in case multihomed nodes have route discoveries from multiple routers o Sharpen language related to multihoming o Suggest a proper default for CONTROL_TRAFFIC_LIMIT (see Section 12.3). o Sharpen Security Considerations Section according to suggestions from Bob Moskowitz Authors' Addresses Charles E. Perkins Futurewei Inc. 2330 Central Expressway Santa Clara, CA 95050 USA Phone: +1-408-330-4586 Email: charliep@computer.org Stan Ratliff Idirect 13861 Sunrise Valley Drive, Suite 300 Herndon, VA 20171 USA Email: ratliffstan@gmail.com Perkins, et al. Expires May 3, 2018 [Page 86] Internet-Draft AODVv2 October 2017 John Dowdell Airbus Defence and Space Celtic Springs Newport, Wales NP10 8FZ United Kingdom Email: john.dowdell@airbus.com Lotte Steenbrink HAW Hamburg, Dept. Informatik Berliner Tor 7 D-20099 Hamburg Germany Email: lotte.steenbrink@haw-hamburg.de Victoria Mercieca Airbus Defence and Space Celtic Springs Newport, Wales NP10 8FZ United Kingdom Email: victoria.mercieca@airbus.com Perkins, et al. Expires May 3, 2018 [Page 87]