Hello folks,
Leaving off the boilerplate and references, here's what I have:
-----------------------------------------------------------------------------------------
1. Introduction
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.
2. Terminology
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] and AODVv2
[I-D.ietf-manet-aodvv2].
3. Algorithm for computing the Message TLV authenticator data
The authentication algorithm uses HMAC-SHA-256-128 [RFC4868] to
compute authentication data. The input data for the computation is
the the concatenation of the following information contained in an
AODVv2 [I-D.ietf-manet-aodvv2] message:
o OrigAddr
o TargAddr
o PrefixLengthList if present in the message
o OrigSeqNum if present in the message
o TargSeqNum if present in the message
o MetricType
The output of the computation is a 128-bit authenticator value which
is used for the value field of the E2E Authenticator Message TLV.
4. Format for the E2E Authenticator Message TLV
The format for the E2E Authenticator Message TLV 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Authenticator (128 bits) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Format for E2E Authenticator Message TLV
Type
The E2E Authenticator Message TLV type
Flags
MUST be transmitted as zero and ignored on reception.
Authenticator
128 bits authentication data computed as described in Section 3.
5. Security Considerations
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.
6. IANA Considerations
This document specifies the designation of a new Message TLV Type to
be allocated from the "Message TLV Types" namespace defined in
[RFC5444].
-----------------------------------------------------------------------------------------
Comments, please -- or suggestions to go ahead and post?
We might want to use it for source-bound RERR messages as well. Comments?
Regards,
Charlie P.
