One document matched: draft-perkins-manet-aodv-e2esec-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="yes" ?>
<!-- ?rfc subcompact="no" ? -->
<!-- keep one blank line between list items -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!--
==================================== 80 ========================================
==================================== 72 ================================
-->
<rfc category="std" ipr="trust200902"
docName='draft-perkins-manet-aodv-e2esec-01.txt'>
<!-- category values: std, bcp, info, exp, and historichttp://umeeting.huawei.com/Portal/business.action?BMECID=1474233&BMETimestamp=1426658395147
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<front>
<title abbrev="E2E authentication for AODV">
Endpoint Message Authentication for AODV Route Messages</title>
<author fullname="Charles E. Perkins" initials="C.E." surname="Perkins">
<organization abbrev="Futurewei">Futurewei Inc. </organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<code>95050</code>
<region>CA</region>
<country>USA</country>
</postal>
<phone>+1-408-330-4586</phone>
<email>charliep@computer.org</email>
</address>
</author>
<date/> <!-- day="25" month="October" year="2010" /> -->
<area>Routing</area>
<workgroup>Mobile Ad Hoc Networks [manet]</workgroup>
<keyword>Mobility</keyword>
<keyword>E2E security</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section anchor='intro' title='Introduction'>
<t>
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.
</t>
</section>
<section title="Terminology">
<t> 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 <xref target="RFC2119" />.</t>
<t> This document also uses some terminology from
<xref target="RFC5444" />, <xref target="RFC7182" /> and
AODVv2 <xref target="I-D.ietf-manet-aodvv2"/>.</t>
<!--
<t>This document defines the following terminology:</t>
<t><list style="hanging">
<t hangText="Forwarding Node"><vspace /> A node that
currently forwards incoming multicast messages to its neighbors, based
on the results of running a multicast suppression algorithm.</t>
<t><vspace /></t>
<t hangText="Multicast Suppression Algorithm"><vspace /> An algorithm
that determines which multicast routers are required for complete
coverage of a multicast group; retransmission by other multicast
routers for the multicast group is unnecessary.
Some layer 3 multicast suppression algorithms are specified
in RFC 6621.</t>
<t><vspace /></t>
<t hangText="Regeneration"><vspace />Transmission of a message
formed by processing and modification of an incoming
message for an operation requiring the attention of
members of a multicast group.</t>
</list></t>
-->
<!-- <t><vspace blankLines="19" /></t> -->
</section>
<section anchor='content' title="ICV Message Extensions for AODVv2">
<t>
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 <xref target="I-D.ietf-manet-aodvv2"/> message,
in this order:
</t>
<t>
<list style="symbols">
<t> OrigAddr </t>
<t> TargAddr </t>
<t> PrefixLengthList if present in the message</t>
<t> OrigSeqNum if present in the message</t>
<t> TargSeqNum if present in the message</t>
<t> MetricType </t>
</list>
</t>
</section> <!-- title="Authentication Extensions for AODVv2" -->
<section anchor='rfc7182-type'
title='RFC 7182 method for computing Message TLV ICV-data'>
<t>
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 <xref target="RFC7182"/> for a new
type extension, this document specifies the following details.
</t>
<t>
The input data for the computation is as specified in
<xref target="content"/>, 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.
</t>
</section>
<section anchor='rfc4868_method'
title='RFC 4868 method computing Message TLV ICV-data'>
<t>
The authentication algorithm uses HMAC-SHA-256-128
<xref target="RFC4868"/> to compute authentication data.
</t>
<t>
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.
</t>
<!--
</section>
<section anchor='msgtlv-format'
title='Format for the E2E Message TLV ICV-data'>
-->
<t>
The format for the E2E Message TLV ICV-data is shown in
<xref target="figauth"/>.
</t>
<t>
<figure anchor="figauth" title="Format for E2E Message TLV ICV-data">
<artwork><![CDATA[
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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t><list style="hanging">
<t hangText="Type"><vspace />The E2E Message TLV ICV-data type</t>
<t><vspace /></t>
<t hangText="Flags"><vspace />MUST be transmitted as zero
and ignored on reception.</t>
<t><vspace /></t>
<t hangText="Authenticator"><vspace />128 bits authentication data
computed as described in <xref target="RFC4868"/>.</t>
</list></t>
</section> <!-- title='RFC 4868 method computing Message TLV ...' -->
<!--
<t>
<list style="symbols">
<t> IPv6 Address <xref target="RFC2373"/> </t>
</list>
</t>
</section>
-->
<section anchor='sec' title='Security Considerations'>
<t>
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.
</t>
</section>
<section anchor='iana' title='IANA Considerations'>
<t>
This document specifies the designation of a new type extension
to be allocated from the "ICV Message TLV Type Extensions" registry
defined in <xref target="RFC7182"/>. The specification for the
use of the new type extension is contained in
<xref target="rfc7182-type"/>.
</t>
<t>
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 <xref target="RFC5444"/>.
</t>
</section>
<section anchor='ack' title='Acknowledgement'>
<t>
This document has benefitted from comments by Vicky Mercieca and
from other discussion with the AODVv2 author team.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4868'?>
<?rfc include='reference.RFC.5444'?>
<?rfc include='reference.RFC.7182'?>
<?rfc include="reference.I-D.ietf-manet-aodvv2" ?>
<!--
</references>
-->
<!--
<references title="Informative References">
<?rfc include='reference.RFC.5498.xml'?>
<?rfc include='reference.RFC.3588.xml'?>
<reference anchor="ThreeGPP-IDS">
<front>
<title>3GPP Technical Specification 23.003 V8.4.0: Technical
Specification Group Core Network and Terminals; Numbering,
addressing and identification (Release 8)</title>
<author surname="3rd Generation Partnership Project">
<organization>
</organization>
</author>
<date month="March" year="2009"/>
</front>
</reference>
<reference anchor="EPC-Tag-Data">
<front>
<title>
EPC(TM) Generation 1 Tag Data Standards Version 1.1 Rev.1.27
http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_1_rev_1_27-standard-20050510.pdf
</title>
<author surname="EPCglobal Inc.">
<organization>
</organization>
</author>
<date day='10' month="January" year="2005"/>
</front>
</reference>
<reference anchor="RFID-DoD-96">
<front>
<title>United States Department of Defense Suppliers Passive RFID
Information Guide (Version 15.0)</title>
<author surname="Department of Defense">
<organization>
</organization>
</author>
<date month="January" year="2010"/>
</front>
</reference>
<reference anchor="IEEE802">
<front>
<title>IEEE Std 802: IEEE Standards for Local and
Metropolitan Networks: Overview and Architecture</title>
<author surname="IEEE">
<organization>
</organization>
</author>
<date year="2001"/>
</front>
</reference>
-->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:06:32 |