One document matched: draft-perkins-manet-aodv-e2esec-00.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-00.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 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 message TLV for AODVv2 and, potentially,
other reactive protocols. The new message TLV allows 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>
Hop-by-hop security for AODV relies on transitive trust between
the nodes during route discovery. In case that some of the nodes
may become compromised, it would be useful for the source and
destination nodes for the discovered routes to be assured that
they both participated 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" /> 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='alg'
title='Algorithm for computing the Message TLV authenticator data'>
<t>
The authentication algorithm uses HMAC-SHA-256-128
<xref target="RFC4868"/> to compute authentication data.
The input data for the computation is the
the concatenation of the following information contained in
an AODVv2 <xref target="I-D.ietf-manet-aodvv2"/> message:
</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>
<t>
The output of the computation is a 128-bit authenticator value which
is used for the value field of the E2E Authenticator Message TLV.
</t>
</section>
<section anchor='format'
title='Format for the E2E Authenticator Message TLV'>
<t>
The format for the E2E Authenticator Message TLV is shown in
<xref target="figauth"/>.
</t>
<t>
<figure anchor="figauth" title="Format for E2E Authenticator Message TLV">
<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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authenticator (128 bits) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
</t>
<t><list style="hanging">
<t hangText="Type"><vspace />The E2E Authenticator Message TLV 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="alg"/>.</t>
</list></t>
</section>
<!--
<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 should provide additional security to protect against creation
of routes to a destination when no such route exists.
</t>
</section>
<section anchor='iana' title='IANA Considerations'>
<t>
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 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>
</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.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:07:25 |