Mobile Ad Hoc Networks [manet] | C. Perkins |
Internet-Draft | Futurewei |
Intended status: Standards Track | May 3, 2016 |
Expires: November 4, 2016 |
Endpoint Message Authentication for AODV Route Messages
draft-perkins-manet-aodv-e2esec-01.txt
This document specifies a new type extension to enable RFC 7182 authentication mechanism to be used for authenticating AODVv2 route messages. The document also specifies a new message TLV for AODVv2 and, potentially, other reactive protocols. Both mechanisms allow the endpoints of a newly discovered route to be assured that they were the originator of the RREQ and responder producing the RREP respectively.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 4, 2016.
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
In certain cases during route discovery, it would be useful for the source and destination nodes for the discovered routes to verify each others' participation in the route discovery process, and thus that a route was indeed established between them. This does not guarantee a functioning route because malicious intermediate nodes might still misdirect or drop traffic.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
This document also uses some terminology from [RFC5444], [RFC7182] and AODVv2 [I-D.ietf-manet-aodvv2].
For the computations specified in this document, the input data (i.e., content) is the the concatenation of the following data contained in the AODVv2 [I-D.ietf-manet-aodvv2] message, in this order:
The authentication algorithm uses a new type extension to allow AODVv2 to compute the ICV-data on the selected input data. In order to conform to the specification within RFC 7182 [RFC7182] for a new type extension, this document specifies the following details.
The input data for the computation is as specified in Section 3, padded up to the nearest multiple of 16 bytes. The output of the computation is truncated to a 128-bit authenticator value which is used for the ICV-data field of the ICV Message TLV. Every AODVv2 conforming to this specification MUST support AES-CMAC as the cryptographic algorithm.
The authentication algorithm uses HMAC-SHA-256-128 [RFC4868] to compute authentication data.
The output of the computation is a 128-bit authenticator value which is used for the value field of the E2E Message TLV ICV-data.
The format for the E2E Message TLV ICV-data is shown in Figure 1.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Message TLV ICV-data (128 bits) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for E2E Message TLV ICV-data
This document introduces a security mechanism to enable the two endpoints of a route discovery operation to verify that they are using the same immutable data elements as were supplied by the node generating the Route Discovery message (i.e., RREQ or RREP). This allows rejection of malicious false routes for OrigAddr or TargAddr of AODVv2 route discovery operations.
This document specifies the designation of a new type extension to be allocated from the "ICV Message TLV Type Extensions" registry defined in [RFC7182]. The specification for the use of the new type extension is contained in Section 4.
For the Message TLV ICV-data TLV, this document specifies the designation of a new Message TLV Type to be allocated from the "Message TLV Types" namespace defined in [RFC5444].
This document has benefitted from comments by Vicky Mercieca and from other discussion with the AODVv2 author team.
[I-D.ietf-manet-aodvv2] | Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L. and V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing", Internet-Draft draft-ietf-manet-aodvv2-15, April 2016. |
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
[RFC4868] | Kelly, S. and S. Frankel, "Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec", RFC 4868, DOI 10.17487/RFC4868, May 2007. |
[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. |
[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. |