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]