Internet DRAFT - draft-guerrero-manet-sdymo
draft-guerrero-manet-sdymo
Mobile Ad Hoc Networking Working Group Manel Guerrero Zapata
INTERNET DRAFT Technical University
7 February 2005 of Catalonia (UPC)
Secure Dynamic MANET On-Demand (SDYMO) Routing Protocol
draft-guerrero-manet-sdymo-00.txt
Intellectual Property Rights Statement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
The Secure Dynamic MANET On-Demand (SDYMO) Routing Protocol is an
extension of the DYMO routing protocol that can be used to protect
the route discovery mechanism providing security features like
integrity and authentication.
Guerrero Expires 7 August 2005 [Page 1]
Internet DRAFT SDYMO 7 February 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Routing Element (RE) Signature Extension . . . . . . . . . . . . 4
5. RERR Signature Extension . . . . . . . . . . . . . . . . . . . . 5
6. UERR Signature Extension . . . . . . . . . . . . . . . . . . . . 6
7. SDYMO Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. SDYMO Signatures . . . . . . . . . . . . . . . . . . . . . 6
7.2. SDYMO Hash Chains . . . . . . . . . . . . . . . . . . . . 7
8. Adaptations to DYMO that are needed . . . . . . . . . . . . . . . 8
9. Modifications of the draft . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8
Guerrero Expires 7 August 2005 [Page 2]
Internet DRAFT SDYMO 7 February 2005
1. Introduction
SDYMO is an extension of the DYMO[1] routing protocol that protects
the route discovery mechanism providing security features like
integrity and authentication. It uses digital signatures to
authenticate the non-mutable fields of the messages, and hash chains
to secure the hop count information contained in the Routing Block
Hop Count (RBHopCnt).
The way SDYMO secures DYMO is very similar compared to the way
SAODV[2] secures AODV[3]. The reader might find useful to read the
existing drafts and papers about SAODV.
SDYMO can use the Simple Ad hoc Key Management (SAKM)[4] as a key
management system.
2. Overview
The solution presented in this paper is an extension of the DYMO
protocol mainly by using new extension messages. In these extension
messages there is a signature of the DYMO packet with the private key
of the original sender of the Routing message (not of the
intermediate nodes that just forward it).
When RREQ is sent, the sender signs the message. Intermediate nodes
verify the signature before creating or updating a reverse route to
that host. And only if the signature is fine they store the reverse
route. The final destination node signs the RREP with its private
key. Intermediate and final nodes, again verify the signature before
creating or updating a route to that host, also storing the signature
with the route entry.
Every node, generating or forwarding a RERR message, uses digital
signatures to sign the whole message and any neighbor that receives
verifies the signature.
The hop counts are authentified by using a hash chain.
TTLs and 'I' flags are not signed.
3. Terminology
This memo uses the conventional meanings [5] for the capitalized
words MUST, SHOULD and MAY. It also uses terminology taken from the
DYMO specifications.
Guerrero Expires 7 August 2005 [Page 3]
Internet DRAFT SDYMO 7 February 2005
4. Routing Element (RE) Signature Extension
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 | Length | Hash Function | Max Hop Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Top Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sign Method |H| Reserved | Padd Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hash |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 64
Length The length of the type-specific data, not including the
Type and Length fields of the extension in bytes.
Hash Function
The hash function used to compute the Hash and Top Hash
fields.
Max Hop Count
The Maximum Hop Count supported by the hop count
authentication.
Top Hash The top hash for the hop count authentication. This
field has variable length, but it must be 32-bits
aligned.
Signature Method
The signature method used to compute the signatures.
H Half Identifier flag. If it is set to '1' indicates the
use of HID and if it is set to '0' the use of FID.
Guerrero Expires 7 August 2005 [Page 4]
Internet DRAFT SDYMO 7 February 2005
Reserved Sent as 0; ignored on reception.
Padding Length
Specifies the length of the padding field in 32-bit
units. If the padding length field is set to zero, there
will be no padding.
Public Key The public key of the originator of the message. This
field has variable length, but it must be 32-bits
aligned.
Padding Random padding. The size of this field is set in the
Padding Length field.
Signature The signature of the all the fields in the DYMO message
that are before this field but the Hop Count field. This
field has variable length, but it must be 32-bits
aligned.
Hash The hash corresponding to the actual hop count. This
field has variable length, but it must be 32-bits
aligned.
5. RERR Signature Extension
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 | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sign Method |H| Reserved | Padd Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 65
Length The length of the type-specific data, not including the
Type and Length fields of the extension in bytes.
Reserved Sent as 0; ignored on reception.
Guerrero Expires 7 August 2005 [Page 5]
Internet DRAFT SDYMO 7 February 2005
Signature Method ... Padding
The same than in RBlock Signature Extension.
Signature The signature of the all the fields in the DYMO message
that are before this field. This field has variable
length, but it must be 32-bits aligned.
6. UERR Signature Extension
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Reserved | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sign Method |H| Reserved | Padd Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Key |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (optional) |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signature |
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 66
Length The length of the type-specific data, not including the
Type and Length fields of the extension in bytes.
Signature Method ... Padding
The same than in RBlock Signature Extension.
Signature The signature of the all the fields in the DYMO message
that are before this field. This field has variable
length, but it must be 32-bits aligned.
7. SDYMO Operation
This section describes how SDYMO allows to authenticate the DYMO
routing data. Two mechanisms are used to achieve this: hash chains
and signatures.
7.1. SDYMO Signatures
When calculating signatures, Hop Count field is always zeroed,
because it is a mutable field.
Guerrero Expires 7 August 2005 [Page 6]
Internet DRAFT SDYMO 7 February 2005
When a node receives a RE, first verify the signature. Only if the
signature is verified, it process the message.If a node receives a RE
without a Signature Extension it SHOULD drop it.
Every node, generating or forwarding a RERR message, uses digital
signatures to sign the whole message and any neighbor that receives
verifies the signature. In this way it can verify that the sender of
the RERR message is really the one that claims to be. And, since
destination sequence numbers are not singed by the corresponding
node, a node SHOULD never update any destination sequence number of
its routing table based on a RRER message.
Although nodes will not trust destination sequence numbers in a RERR
message, they will use them to decide whether they should invalidate
a route or not.
UERR messages SHOULD be authentified by using the UERR Signature
Extension.
SAKM specifies the list of possible values of the Signature Method
field and how public keys and signatures are encoded en the extension
messages.
7.2. SDYMO Hash Chains
Hash chains are used in SDYMO to authenticate the hop count of the
RBlocks (not only by the end points, but by any node that receives
one of those messages).
Every time a node wants to send a RREQ or a RREP it generates a
random number (seed). Selects a Maximum Hop Count. Maximum Hop Count
SHOULD be set to the TTL value in the IP header, and it SHOULD never
exceed its configuration parameter NET_DIAMETER. The Hash field in
the Signature Extension is set to the seed. The Top Hash field is set
to the seed hashed Max Hop Count times.
Every time a node receives a RE it verifies the hop count by hashing
Max Hop Count - Hop Count times the Hash field, and checking that the
resultant value is the same than the Top Hash. If the check fails,
the node SHOULD drop the packet.
Before forwarding a RE, a node hashes one time the Hash field in the
Signature Extension.
The function used to compute the hash is set in the Hash Function
field. Since this field is signed, a forwarding node will only be
able to use the same hash function that the originator of the routing
message has selected. If an node cannot verify or forward a routing
Guerrero Expires 7 August 2005 [Page 7]
Internet DRAFT SDYMO 7 February 2005
message because it does not support the hash function that has been
used, then it drops the packet.
The list of possible values of the Hash Function field are the same
as the one for the hash functions used for the signature ('Hash F
Sign') that are specified in SAKM.
8. Adaptations to DYMO that are needed
Routing Elements (REs) MUST have only one Routing Block (RB).
DYMO does not let intermediate node to originate a RREP, which makes
things easier for SDYMO.
9. Modifications of the draft
Version 1
Not yet.
10. Acknowledgments
I want to thank to thank everybody who contributed to SAODV, since
SDYMO is based on it.
References
[1] I. Chakeres, E. Belding-Royer, C. Perkins: Dynamic MANET On-
demand (DYMO) Routing. draft-ietf-manet-dymo-03, October 2005.
[2] M. Guerrero Zapata: Secure Ad hoc On-Demand Distance Vector
(SAODV) Routing. draft-guerrero-manet-saodv-05.txt, February 2006.
[3] Charles E. Perkins, Elizabeth M. Belding Royer, Samir R. Das: Ad
hoc On-Demand Distance Vector (AODV) Routing. RFC 3561, November
2003.
[4] M. Guerrero Zapata: Simple Ad hoc Key Management (SAKM). draft-
guerrero-manet-sakm-00.txt, February 2006.
[5] S. Bradner: Key words for use in RFCs to Indicate Requirement
Levels. RFC 2119, March 1997.
Guerrero Expires 7 August 2005 [Page 8]
Internet DRAFT SDYMO 7 February 2005
Author's Address:
Questions about this memo can be directed to the author:
Manel Guerrero Zapata
Computer Architecture Department (DAC)
Technical University of Catalonia (UPC)
UPC-AC C6-123 Campus Nord
C. Jordi Girona 1-3
08034 Barcelona SPAIN
(+34) 93 4054044
guerrero@ac.upc.edu
Appendix A. Full Copyright Statement
Copyright (C) The Internet Society 2005. This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
(See RFC 3667 sections 5.4 and 5.5.)
Guerrero Expires 7 August 2005 [Page 9]
