draft-ietf-manet-packetbb-sec-04.txt   draft-ietf-manet-packetbb-sec-05.txt 
Mobile Ad hoc Networking (MANET) U. Herberg Mobile Ad hoc Networking (MANET) U. Herberg
Internet-Draft T. Clausen Internet-Draft T. Clausen
Intended status: Standards Track LIX, Ecole Polytechnique Intended status: Standards Track LIX, Ecole Polytechnique
Expires: January 12, 2012 July 11, 2011 Expires: January 30, 2012 July 29, 2011
MANET Cryptographical Signature TLV Definition MANET Cryptographical Signature TLV Definition
draft-ietf-manet-packetbb-sec-04 draft-ietf-manet-packetbb-sec-05
Abstract Abstract
This document describes general and flexible TLVs (type-length-value This document describes general and flexible TLVs (type-length-value
structure) for representing cryptographic signatures as well as structure) for representing cryptographic signatures as well as
timestamps, using the generalized MANET packet/message format timestamps, using the generalized MANET packet/message format
[RFC5444]. It defines two Packet TLVs, two Message TLVs, and two [RFC5444]. It defines two Packet TLVs, two Message TLVs, and two
Address Block TLVs, for affixing cryptographic signatures and Address Block TLVs, for affixing cryptographic signatures and
timestamps to a packet, message and address, respectively. timestamps to a packet, message and address, respectively.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on January 30, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
4. Security Architecture . . . . . . . . . . . . . . . . . . . . 4 4. Security Architecture . . . . . . . . . . . . . . . . . . . . 4
5. Protocol Overview and Functioning . . . . . . . . . . . . . . 5 5. Protocol Overview and Functioning . . . . . . . . . . . . . . 5
6. Imported TLV Fields . . . . . . . . . . . . . . . . . . . . . 5 6. Imported TLV Fields . . . . . . . . . . . . . . . . . . . . . 5
7. General Signature TLV Structure . . . . . . . . . . . . . . . 5 7. General Signature TLV Structure . . . . . . . . . . . . . . . 5
8. General Timestamp TLV Structure . . . . . . . . . . . . . . . 6 8. General Timestamp TLV Structure . . . . . . . . . . . . . . . 6
9. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 6 9. Packet TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 6
9.1. Packet SIGNATURE TLV . . . . . . . . . . . . . . . . . . . 6 9.1. Packet SIGNATURE TLV . . . . . . . . . . . . . . . . . . . 6
9.2. Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . . 7 9.2. Packet TIMESTAMP TLV . . . . . . . . . . . . . . . . . . . 7
10. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. Message TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Message SIGNATURE TLV . . . . . . . . . . . . . . . . . . 7 10.1. Message SIGNATURE TLV . . . . . . . . . . . . . . . . . . 7
10.2. Message TIMESTAMP TLV . . . . . . . . . . . . . . . . . . 7 10.2. Message TIMESTAMP TLV . . . . . . . . . . . . . . . . . . 8
11. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 8 11. Address Block TLVs . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Address Block SIGNATURE TLV . . . . . . . . . . . . . . . 8 11.1. Address Block SIGNATURE TLV . . . . . . . . . . . . . . . 8
11.2. Address Block TIMESTAMP TLV . . . . . . . . . . . . . . . 8 11.2. Address Block TIMESTAMP TLV . . . . . . . . . . . . . . . 8
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
12.1. TLV Registrations . . . . . . . . . . . . . . . . . . . . 8 12.1. TLV Registrations . . . . . . . . . . . . . . . . . . . . 8
12.1.1. Expert Review: Evaluation Guidelines . . . . . . . . 9 12.1.1. Expert Review: Evaluation Guidelines . . . . . . . . 9
12.1.2. Packet TLV Type Registrations . . . . . . . . . . . . 9 12.1.2. Packet TLV Type Registrations . . . . . . . . . . . . 9
12.1.3. Message TLV Type Registrations . . . . . . . . . . . 9 12.1.3. Message TLV Type Registrations . . . . . . . . . . . 10
12.1.4. Address Block TLV Type Registrations . . . . . . . . 10 12.1.4. Address Block TLV Type Registrations . . . . . . . . 10
12.2. New IANA Registries . . . . . . . . . . . . . . . . . . . 11 12.2. New IANA Registries . . . . . . . . . . . . . . . . . . . 11
12.2.1. Expert Review: Evaluation Guidelines . . . . . . . . 11 12.2.1. Expert Review: Evaluation Guidelines . . . . . . . . 11
12.2.2. Hash Function . . . . . . . . . . . . . . . . . . . . 11 12.2.2. Hash Function . . . . . . . . . . . . . . . . . . . . 11
12.2.3. Cryptographic Algorithm . . . . . . . . . . . . . . . 11 12.2.3. Cryptographic Algorithm . . . . . . . . . . . . . . . 12
13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . . . 13 15.1. Normative References . . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . . 13 15.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Signature Decomposition into Cryptographic Appendix A. Signature Decomposition into Cryptographic
Function of a Hash Value . . . . . . . . . . . . . . 13 Function of a Hash Value . . . . . . . . . . . . . . 13
A.1. General Signature TLV Structure . . . . . . . . . . . . . 13 A.1. General Signature TLV Structure . . . . . . . . . . . . . 13
A.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 14 A.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 14
A.2. Considerations for Calculating the Signature . . . . . . . 15 A.2. Considerations for Calculating the Signature . . . . . . . 15
A.2.1. Packet SIGNATURE TLV . . . . . . . . . . . . . . . . 15 A.2.1. Packet SIGNATURE TLV . . . . . . . . . . . . . . . . 15
A.2.2. Message SIGNATURE TLV . . . . . . . . . . . . . . . . 15 A.2.2. Message SIGNATURE TLV . . . . . . . . . . . . . . . . 15
A.2.3. Address Block SIGNATURE TLV . . . . . . . . . . . . . 15 A.2.3. Address Block SIGNATURE TLV . . . . . . . . . . . . . 15
A.3. Example of a Signed Message . . . . . . . . . . . . . . . 15 A.3. Example of a Signed Message . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document specifies: This document specifies:
o two TLVs for carrying cryptographic signatures and timestamps in o two TLVs for carrying cryptographic signatures and timestamps in
packets, messages and address blocks as defined by [RFC5444], packets, messages and address blocks as defined by [RFC5444],
o a generic framework for calculating cryptographic signatures, o a generic framework for calculating cryptographic signatures,
taking (for Message TLVs) into account the mutable message header taking (for Message TLVs) into account the mutable message header
fields (<msg-hop-limit> and <msg-hop-count>) where these fields fields (<msg-hop-limit> and <msg-hop-count>) where these fields
are present in messages, are present in messages,
o a specific calculation of signatures, decomposed as a o a specific calculation of signatures in the Appendix A of this
cryptographic function over the hash value of the content to be document. The signature is decomposed into a cryptographic
signed, in the Appendix A of this document. function over the hash value of the content to be signed.
This document requests from IANA: This document requests from IANA:
o allocations for these Packet, Message, and Address Block TLVs from o allocations for these Packet, Message, and Address Block TLVs from
the 0-223 Packet TLV range, the 0-127 Message TLV range and the the 0-223 Packet TLV range, the 0-127 Message TLV range and the
0-127 Address Block TLV range from [RFC5444], 0-127 Address Block TLV range from [RFC5444],
o creation of two IANA registries for recording code points for hash o creation of two IANA registries for recording code points for hash
function and signature calculation, respectively. function and signature calculation, respectively.
skipping to change at page 4, line 7 skipping to change at page 4, line 7
included MAY be used by a routing protocol, or by an extension of a included MAY be used by a routing protocol, or by an extension of a
routing protocol, according to its specification. routing protocol, according to its specification.
This document specifies how to include a cryptographic signature for This document specifies how to include a cryptographic signature for
a packet, message or address by way of such TLVs. This document also a packet, message or address by way of such TLVs. This document also
specifies how to treat "mutable" fields (<msg-hop-count> and <msg- specifies how to treat "mutable" fields (<msg-hop-count> and <msg-
hop-limit>), if present, in the message header when calculating hop-limit>), if present, in the message header when calculating
signatures, such that the resulting signature can be correctly signatures, such that the resulting signature can be correctly
verified by any recipient, and how to include this signature. verified by any recipient, and how to include this signature.
This document is split into two parts: (i) a generic framework of This document describes a generic framework of creating signatures in
creating signatures in the presence of mutable fields, and how to the presence of mutable fields, and how to include these signatures
include these signatures in TLVs, (ii) a specific description of how in TLVs. In the Appendix A, one example of how to calculate a
to calculate a signature, using a cryptographic function over the signature is specified, using a cryptographic function over the hash
hash value of the content to be signed, in the Appendix A of this value of the content to be signed.
document. Note that (ii) is a possible and widely-used way of
calculating a signature, but other means may exist. Such other means
of calculating a signature have to be specified in another document.
That new document MUST use the TLV structures specified in this
document, as well as the described considerations when calculating
the signatures.
4. Security Architecture 4. Security Architecture
Basic MANET routing protocol specifications are often "oblivious to Basic MANET routing protocol specifications are often "oblivious to
security", however have a clause allowing a control message to be security", however have a clause allowing a control message to be
rejected as "badly formed" prior to it being processed or forwarded. rejected as "badly formed" prior to it being processed or forwarded.
Protocols such as [RFC6130] and [OLSRv2] recognize external reasons Protocols such as [RFC6130] and [OLSRv2] recognize external reasons
(such as failure to verify a signature) for rejecting a message as (such as failure to verify a signature) for rejecting a message as
"badly formed", and therefore "invalid for processing". This "badly formed", and therefore "invalid for processing". This
architecture is a result of the observation that with respect to architecture is a result of the observation that with respect to
skipping to change at page 5, line 24 skipping to change at page 5, line 18
With respect to [RFC5444], this document: With respect to [RFC5444], this document:
o is intended to be used in the non-normative, but intended, mode of o is intended to be used in the non-normative, but intended, mode of
use of [RFC5444] as described in its Appendix B. use of [RFC5444] as described in its Appendix B.
o is a specific example of the Security Considerations section of o is a specific example of the Security Considerations section of
[RFC5444] (the authentication part). [RFC5444] (the authentication part).
5. Protocol Overview and Functioning 5. Protocol Overview and Functioning
This specification does not describe a protocol, nor does it mandate This document specifies a syntactical representation of security
specific router or protocol behavior. It represents a purely related information for use with [RFC5444] addresses, messages and
syntactical representation of security related information for use packets, as well as establishes IANA registrations and registries.
with [RFC5444] addresses, messages and packets, as well as
establishes IANA registrations and registries. Moreover, this document provides guidelines how protocols using this
specification should treat Signature and Timestamp TLVs, and mutable
fields in messages. This specification, however, does not represent
a stand-alone protocol; protocols using this specification have to
provide instructions how to handle packets, messages and addresses
with associated security information, as specified in this document.
6. Imported TLV Fields 6. Imported TLV Fields
In this specification, the following TLV fields from [RFC5444] are In this specification, the following TLV fields from [RFC5444] are
used: used:
<msg-hop-limit> - hop limit of a message, as specified in Section <msg-hop-limit> - hop limit of a message, as specified in Section
5.2 of [RFC5444]. 5.2 of [RFC5444].
<msg-hop-count> - hop count of a message, as specified in Section <msg-hop-count> - hop count of a message, as specified in Section
5.2 of [RFC5444]. 5.2 of [RFC5444].
<length> - length of a TLV in octets, as specified in Section 5.4.1 <length> - length of a TLV in octets, as specified in Section 5.4.1
of [RFC5444]. of [RFC5444].
7. General Signature TLV Structure 7. General Signature TLV Structure
The following data structure allows a generic representation of a The following data structure, which is the value of the Signature
cryptographic signature. This <signature> data structure is TLV, allows a generic representation of a cryptographic signature.
specified, using the regular expression syntax of [RFC5444], as: This <signature> data structure is specified, using the regular
expression syntax of [RFC5444], as:
<signature> := <signature-value> <signature> := <signature-value>
<signature-value> is an integer field, whose length is <length>, and
which contains the signature. The value of this variable is to be
interpreted by the routing protocol as specified by the type
extension of the Signature TLV, see Section 12.
This generic specification allows for adding a signature in a TLV, This generic specification allows for adding a signature in a TLV,
using TLV type extension 0, and does not stipulate how to calculate using TLV type extension 0, and does not stipulate how to calculate
the signature-value. Appendix A specifies a concrete calculation of the signature-value. Appendix A specifies a concrete calculation of
the signature-value, using a cryptographic function over a hash the signature-value, using a cryptographic function over a hash
function of the content to be signed. Other methods of how to function of the content to be signed. Other methods of how to
calculate the signature-value may be specified in future documents. calculate the signature-value may be specified in future documents.
8. General Timestamp TLV Structure 8. General Timestamp TLV Structure
The following data structure allows the representation of a The following data structure, which is the value of the Timestamp
timestamp. This <timestamp> data structure is specified as: TLV, allows the representation of a timestamp. This <timestamp> data
structure is specified as:
<timestamp> := <time-value> <timestamp> := <time-value>
where: where:
<time-value> is an unsigned integer field, whose length is <length>, <time-value> is an unsigned integer field, whose length is <length>,
and which contains the timestamp. The value of this variable is and which contains the timestamp. The value of this variable is
to be interpreted by the routing protocol as specified by the type to be interpreted by the routing protocol as specified by the type
extension of the Timestamp TLV, see Section 12. extension of the Timestamp TLV, see Section 12.
skipping to change at page 9, line 7 skipping to change at page 9, line 15
o two Message TLV types which must be allocated from the 0-127 range o two Message TLV types which must be allocated from the 0-127 range
of the "Assigned Message TLV Types" repository of [RFC5444] as of the "Assigned Message TLV Types" repository of [RFC5444] as
specified in Table 2, specified in Table 2,
o and two Address Block TLV types which must be allocated from the o and two Address Block TLV types which must be allocated from the
0-127 range of the "Assigned Address Block TLV Types" repository 0-127 range of the "Assigned Address Block TLV Types" repository
of [RFC5444] as specified in Table 3. of [RFC5444] as specified in Table 3.
This specification requests: This specification requests:
o set up of type extension registries for these TLV types. o set up of type extension registries for these TLV types with
initial values as in Table 1 to Table 3.
IANA is requested to assign the same numerical value to the Packet IANA is requested to assign the same numerical value to the Packet
TLV, Message TLV and Address Block TLV types with the same name. TLV, Message TLV and Address Block TLV types with the same name.
12.1.1. Expert Review: Evaluation Guidelines 12.1.1. Expert Review: Evaluation Guidelines
For the registries for TLV type extensions where an Expert Review is For the registries for TLV type extensions where an Expert Review is
required, the designated expert SHOULD take the same general required, the designated expert SHOULD take the same general
recommendations into consideration as are specified by [RFC5444]. recommendations into consideration as are specified by [RFC5444].
skipping to change at page 12, line 41 skipping to change at page 12, line 48
As an example, a routing protocol that uses this component to reject As an example, a routing protocol that uses this component to reject
"badly formed" messages if a control message does not contain a valid "badly formed" messages if a control message does not contain a valid
signature, should indicate the security assumption that if the signature, should indicate the security assumption that if the
signature is valid, the message is considered valid. It also should signature is valid, the message is considered valid. It also should
indicate the security issues that are counteracted by this measure indicate the security issues that are counteracted by this measure
(e.g. link or identity spoofing) as well as the issues that are not (e.g. link or identity spoofing) as well as the issues that are not
counteracted (e.g. compromised keys). counteracted (e.g. compromised keys).
14. Acknowledgements 14. Acknowledgements
The authors would like to thank Jerome Milan (Ecole Polytechnique) The authors would like to thank Bo Berry (Cisco), Alan Cullen (BAE),
for his advice as cryptographer. In addition, many thanks to Bo Justin Dean (NRL), Christopher Dearlove (BAE), Paul Lambert
Berry (Cisco), Alan Cullen (BAE), Justin Dean (NRL), Christopher (Marvell), Jerome Milan (Ecole Polytechnique) and Henning Rogge
Dearlove (BAE), Paul Lambert (Marvell), and Henning Rogge (FGAN) for (FGAN) for their constructive comments on the document.
their constructive comments on the document.
15. References 15. References
15.1. Normative References 15.1. Normative References
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226, BCP 26, IANA Considerations Section in RFCs", RFC 5226, BCP 26,
May 2008. May 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
skipping to change at page 13, line 21 skipping to change at page 13, line 26
Requirement Levels", RFC 2119, BCP 14, March 1997. Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, [RFC5444] Clausen, T., Dearlove, C., Dean, J., and C. Adjih,
"Generalized MANET Packet/Message Format", RFC 5444, "Generalized MANET Packet/Message Format", RFC 5444,
February 2009. February 2009.
15.2. Informative References 15.2. Informative References
[OLSRv2] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized [OLSRv2] Clausen, T., Dearlove, C., and P. Jacquet, "The Optimized
Link State Routing Protocol version 2", work in Link State Routing Protocol version 2", work in
progress draft-ietf-manet-olsrv2-11.txt, April 2010. progress draft-ietf-manet-olsrv2-12.txt, July 2011.
[RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET [RFC6130] Clausen, T., Dean, J., and C. Dearlove, "MANET
Neighborhood Discovery Protocol (NHDP)", RFC 6130, Neighborhood Discovery Protocol (NHDP)", RFC 6130,
March 2011. March 2011.
Appendix A. Signature Decomposition into Cryptographic Function of a Appendix A. Signature Decomposition into Cryptographic Function of a
Hash Value Hash Value
This section specifies how to calculate the signature-value in a This section specifies how to calculate the signature-value in a
Signature TLV, as described in Section 7. A common way of Signature TLV, as described in Section 7. A common way of
skipping to change at page 15, line 42 skipping to change at page 15, line 45
address, concatenated with any other values, for example, any other address, concatenated with any other values, for example, any other
TLV value that is associated with that address. A routing protocol TLV value that is associated with that address. A routing protocol
or routing protocol extension using Address Block SIGNATURE TLVs MUST or routing protocol extension using Address Block SIGNATURE TLVs MUST
specify how to include any such concatenated attribute of the address specify how to include any such concatenated attribute of the address
in the verification process of the signature. in the verification process of the signature.
A.3. Example of a Signed Message A.3. Example of a Signed Message
The sample message depicted in Figure 1 is derived from the appendix The sample message depicted in Figure 1 is derived from the appendix
of [RFC5444]. A SIGNATURE Message TLV has been added, with the value of [RFC5444]. A SIGNATURE Message TLV has been added, with the value
representing a 14 octet long signature of the whole message. The representing a 16 octet long signature of the whole message. The
type extension of the Message TLV is 1, for the specific type extension of the Message TLV is 1, for the specific
decomposition of a signature into a cryptographic function over a decomposition of a signature into a cryptographic function over a
hash value, as specified in Appendix A. hash value, as specified in Appendix A.
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 1 0 0 0| Packet Sequence Number | Message Type | | PV=0 | PF=8 | Packet Sequence Number | Message Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 0 0 1 1|0 0 0 0 0 0 0 0 0 1 0 0 1 1 0 0| Orig Addr | | MF=15 | MAL=3 | Message Length = 40 | Msg. Orig Addr|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator Address (cont) | Hop Limit | | Message Originator Address (cont) | Hop Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Message Sequence Number |0 0 0 0 0 0 0 0| | Hop Count | Message Sequence Number | Msg. TLV Block|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 1 1 1 0| SIGNATURE |1 0 0 1 0 0 0 0|0 0 0 0 0 0 0 1| | Length = 30 | SIGNATURE | MTLVF = 144 | MTLVExt = 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1 0 0 1 0| Hash Func | Crypto Func | Key Index | |Value Len = 19 | Hash Func | Crypto Func | Key Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Value | | Signature Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Value (cont) | | Signature Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Value (cont) | | Signature Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature Value (cont) | TLV Type |0 0 0 1 0 0 0 0| | Signature Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 1 1 0| Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (cont) |0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 1 0 0 0 0|0 0 0 0 0 0 1 0| Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Prefix Length |0 0 0 0 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0|0 0 0 0 0 0 1 1|1 0 0 0 0 0 0 0|0 0 0 0 0 0 1 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mid | Mid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1| TLV Type |0 0 0 1 0 0 0 0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0 0 0 1 0| Value | TLV Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 1 0 0 0 0 0| Index Start | Index Stop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Example message with signature Figure 1: Example message with signature
Authors' Addresses Authors' Addresses
Ulrich Herberg Ulrich Herberg
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Phone: +33 1 6933 4126
Email: ulrich@herberg.name Email: ulrich@herberg.name
URI: http://www.herberg.name/ URI: http://www.herberg.name/
Thomas Heide Clausen Thomas Heide Clausen
LIX, Ecole Polytechnique LIX, Ecole Polytechnique
91128 Palaiseau Cedex, 91128 Palaiseau Cedex,
France France
Phone: +33 6 6058 9349 Phone: +33 6 6058 9349
Email: T.Clausen@computer.org Email: T.Clausen@computer.org
 End of changes. 27 change blocks. 
67 lines changed or deleted 53 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/