Network Working Group D. Zhang Internet-Draft Huawei Symantec Intended status: Standards Track P. Nallur Expires: November 13, 2009 Futurewei Technologies May 12, 2009 CGA Extension Header of IPv6 draft-dong-savi-cga-header-01.txt Status of This Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 13, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang & Nallur Expires November 13, 2009 [Page 1] Internet-Draft CGA Extension Header of IPv6 May 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies a method based on Cryptographically Generated Addresses (CGA) for protecting the IPv6 network from address spoofing. The basic idea is to define a new IPv6 extension header which is called CGA header. Three new options of CGA header are introduced to satisfy the need of verification between all CGA-aware nodes. This document also illustrates the proposed verification procedure under several different situations. Additionally, a possible alternative way using destination options header to take CGA information is described. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Extension Header Order . . . . . . . . . . . . . . . . . . . . 3 3. CGA Extension Header Format . . . . . . . . . . . . . . . . . 4 3.1. CGA Request . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. CGA Params . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3. CGA Signature . . . . . . . . . . . . . . . . . . . . . . 7 4. Packet Processing . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Processing Outgoing Packet . . . . . . . . . . . . . . . . 8 4.2. Processing Incoming Packet . . . . . . . . . . . . . . . . 9 5. ICMP Message . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Verification Failure . . . . . . . . . . . . . . . . . . . 10 5.2. Option Errors . . . . . . . . . . . . . . . . . . . . . . 10 6. Source Address Verification . . . . . . . . . . . . . . . . . 10 6.1. Initiator Verifying Resopnder's Address . . . . . . . . . 11 6.2. Responder Verifying Initiator's Address . . . . . . . . . 11 6.3. Bidirectional Verification . . . . . . . . . . . . . . . . 11 7. An Alternative Way to Take CGA Information . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 Zhang & Nallur Expires November 13, 2009 [Page 2] Internet-Draft CGA Extension Header of IPv6 May 2009 1. Introduction The CGA specifies a new method of generating an IPv6 address with a cryptographic public key [RFC3972]. This CGA is designed for SEcure Neighbor Discovery (SEND) protocol [RFC3971]. The original purpose of using CGA is to verify the messages of the SEND protocol signed by the address owners without additional security infrastructure. This document specifies a method based on CGA for protecting IPv6 network from address spoofing. The basic idea is to define a new IPv6 extension header which is called CGA header. Three new options which belong to CGA header are introduced to satisfy the need of verification between all CGA-aware nodes. This document also illustrates proposed procedure of verification under several different situations. This document includes: o Format of the CGA header definition; o Formats of options definition; o Way of processing both outgoing and incoming packets which contain the CGA header; o Proposed procedures of source address verification with the CGA header. Note that the procedure of verification is not strictly required but proposed with the consideration of compatibility with higher layer protocols. In other words, higher layer protocols MAY make use of CGA header to protect the communication whenever they need. Then the scope of CGA is no longer restricted to a specific protocol but a general solution for network infrastructure. In this document, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC2119]. 2. Extension Header Order According to [RFC2460], the extension headers of IPv6 are subject to the ordering recommendations. Of all of the extension headers, the ones which are handled by network equipments SHOULD occur before those handled by end-points. After the CGA header is added, a full implementation of IPv6 includes the following extension headers: Zhang & Nallur Expires November 13, 2009 [Page 3] Internet-Draft CGA Extension Header of IPv6 May 2009 Hop-by-Hop Options header Destination Options header Routing header Fragment header CGA header Authentication header Encapsulating Security Payload header Destination Options header upper-layer header The CGA header MUST NOT be displayed in the extension header of a packet more than once. 3. CGA Extension Header Format The CGA header is used to carry optional information. A responder either authenticates the address of the initiator based on the CGA information or sends his own CGA options to the initiator. The CGA header is identified by a Next Header value of TBD1 in IPv6 header. The format of the CGA header is described as follows: Zhang & Nallur Expires November 13, 2009 [Page 4] Internet-Draft CGA Extension Header of IPv6 May 2009 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Header | Hdr Ext Len | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Next Header 8-bit selector. Identifies the type of header immediately following the CGA header. Hdr Ext Len 8-bit unsigned integer. Length of the CGA header in 8-octet units, excluding the first 8 octets. When the value of Hdr Ext Len is zero, it means that this information is for CGA initialization. If one host wants to protect the communication, it will send the CGA header of which Hdr Ext Len is zero. After receiving the preceding type of the CGA header, an end-point sends a CGA Request as a response. Reserved An 16-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver. Options Variable-length field, of length such that the complete CGA header is an integer multiple of 8 octets long. Contains one or more TLV-encoded options, as described in section 4.2 of [RFC2460]. The Options field contains three types of data: CGA Request, CGA Params and CGA Signature. CGA Request is used to ask the counterpart for CGA Params; CGA Params is used to carry a CGA parameters data structure; CGA Signature contains the signature produced by the host using its private key. CGA Params MUST be accompanied with CGA Signature. Otherwise the receiver SHOULD respond with an ICMP message. The packets MAY include CGA Signature only when CGA Params is sent. How the node handles the CGA Params in the packet before receiving CGA Request depends on the host's policy. 3.1. CGA Request Any node can ask its peer for CGA Params by sending CGA Request in the packet. The node that receives the packet with CGA Request, MAY respond with its own CGA Params and CGA Signature. CGA Request is of the following format: Zhang & Nallur Expires November 13, 2009 [Page 5] Internet-Draft CGA Extension Header of IPv6 May 2009 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit unsigned integer. Type code for CGA Request. The value is TBD2. Reserved An 24-bit field reserved for future use. The value MUST be initialized to zero. Sequence Number 32-bit unsigned integer. Random-number. It contains a counter value that increases by one for each packet sent. It may enable the anti-replay service. 3.2. CGA Params This type data of the options carries CGA parameters according to which the receiver validates the address. The format of the CGA Params is described in the following diagram: Zhang & Nallur Expires November 13, 2009 [Page 6] Internet-Draft CGA Extension Header of IPv6 May 2009 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 | Pad Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . CGA Parameters . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Padding . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit unsigned integer. Type code for CGA Params. The value is TBD3. Length 8-bit unsigned integer. The length of the option (including the Type, Length, Pad Length, Reserved, Sequence Number, CGA Parameters, and Padding fields) in 8-octec units of byte. Pad Length 8-bit unsigned integer. The number of padding octets beyond the end of the CGA Parameters field but within the length specified by the Length field in byte. Padding octets MUST be set to zero by senders and ignored by receivers. Reserved An 8-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver. Sequence Number 32-bit unsigned integer. As a response, its value is to add one to the Sequence Number which belongs to CGA Request. Otherwise it is zero. CGA Parameters A variable-length field containing the CGA Parameters data structure described in Section 2 of [RFC3972]. Padding A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field. The contents of padding MUST be zero. 3.3. CGA Signature This type data of the options is responsible for carrying the signature. In particular, the following illustration shows the format of CGA Signature: Zhang & Nallur Expires November 13, 2009 [Page 7] Internet-Draft CGA Extension Header of IPv6 May 2009 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 | Pad Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Digital Signature . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Padding . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8-bit unsigned integer. Type code for CGA Signature. The value is TBD4. Length The length of the option (including the Type, Length, Pad Length, Reserved, Sequence Number, CGA Signature, and Padding fields) in units of byte. Pad Length 8-bit unsigned integer. The number of padding octets beyond the end of the CGA Signature field but within the length specified by the Length field in byte. Padding octets MUST be set to zero by senders and ignored by receivers. Reserved 8-bit unsigned integer. An 8-bit field reserved for future use. The value MUST be initialized to zero by the sender and MUST be ignored by the receiver. Digital Signature A variable-length field containing the signature which is produced by the private-key. Padding A variable-length field making the option length a multiple of 8, containing as many octets as specified in the Pad Length field. 4. Packet Processing To send a CGA Request packet, the host generates a 32-bit random Sequence Number, and formats the packet as described in section 3.1. Once a host receives the packet with CGA Request, it MAY either respond with a CGA Params or ignore the packet according to the host's policy. 4.1. Processing Outgoing Packet When a host finds CGA Request in the extension header of the packet, it MAY send CGA Params and CGA Signature to its peer as a response. In addition, the host also MAY send CGA Params and CGA Signature, which depends on the higher layer protocols. Zhang & Nallur Expires November 13, 2009 [Page 8] Internet-Draft CGA Extension Header of IPv6 May 2009 If the host responds to CGA Request, its Sequence Number MUST be equal to the Sequence Number of the CGA request plus one. When the host sends CGA Params and CGA Signature actively, the Sequence Number SHOULD be set to zero in CGA Params. CGA parameters generation is illustrated in Section 4 of [RFC3972]. The private key used to make the Digital Signature part in CGA Signature MUST correspond to the public key carried in the CGA parameters part of CGA Params. The contents to be signed contain the following parts concatenated from left to right: 1. 128-bit source address in the IP header; 2. 128-bit destination address in the IP header; 3. All parts of CGA header except CGA Signature; 4. Payload of the packet (transport and higher layers). The data obtained is signed through the RSA method and the signature is placed in the Digital Signature field. 4.2. Processing Incoming Packet After the host receives the packet with CGA Params and CGA Signature, either can it make an authentication with parameters and signature or ignore them, which depends on the higher layers. If the host need authentication, the procedure is as follows: 1. If a host receives a responding packet to CGA Request, it subtracts one from the Sequence Number in CGA Params, and then compares the subtracted number with the Sequence Number in CGA Request sent earlier. If the two values are the same, go to the next step. Otherwise, the host MUST drop the packet, which leads to the generation of an ICMP message. 2. On the basis of CGA parameters, the host MAY verify the source address in IP header. The verification procedure is given in Section 5 of [RFC3972]. If the verification succeeds, go to the next step. Otherwise, the host MUST drop the packet, which leads to the generation of an ICMP message. 3. The inputs of the signature verification operation are the public key, which is a part of the CGA parameters data structure, the concatenation created in Section 3.1 and the signature. If the signature verification does not succeed, then the host MUST drop the packet which leads to the generation of an ICMP message. Zhang & Nallur Expires November 13, 2009 [Page 9] Internet-Draft CGA Extension Header of IPv6 May 2009 Certain errors also MAY result in dropping the packet and sending ICMP messages: 1. The CGA header contains only CGA Params rather than CGA Signature; 2. The CGA header contains only CGA Signature rather than CGA Params; 3. The host sends the CGA Request, however, the returned packet does not contain CGA Params and CGA Signature return. 5. ICMP Message When the CGA header of IPv6 is deployed and certain errors occur, ICMP messages are required to report errors to the source host. Except the problems described in [RFC2463], CGA header has other types of errors. 5.1. Verification Failure Verification failure MAY be caused by the following: 1. Sequence Number error; 2. CGA verification error; 3. Signature verification error. 5.2. Option Errors The three type option errors described at the end of Section 4.2 also MAY generate ICMP messages. 6. Source Address Verification Sometimes it is appreciated to do one-way authentication. For example, host A intends to build a connection with host B. If host A suspects the identity of the responder, host A MAY ask for verification. Perhaps this scenario occurs in the Client/Server model. When both hosts of one connection need to confirm the identities of each other, they do bidirectional verification. In this section, the processes of three types of verification applications are presented. In the connection of two hosts, one is denoted with Initiator and the other with Responder. Zhang & Nallur Expires November 13, 2009 [Page 10] Internet-Draft CGA Extension Header of IPv6 May 2009 6.1. Initiator Verifying Resopnder's Address The following picture shows a typical exchange when the initiator verifies the address of the responder. Initiator Responder CGA Request --------------------------> CGA Params, CGA Sig <------------------------- The initiator sends CGA Request in the message to require the CGA parameters of the responder. After receiving the request, the responder returns its own CGA Params and CGA Signature to the initiator. The processing rules and verification process are given in Section 4.1 and Section 4.2 respectively. 6.2. Responder Verifying Initiator's Address The responder can also verify the address of the initiator. Conceptually, the process can be represented by the following message sequence. Initiator Responder NULL CGA HEADER --------------------------> CGA Request <------------------------- CGA Params, CGA Sig --------------------------> A packet with null CGA header coming from the initiator implicates that there may be a CGA verification process. After receiving this kind of special CGA header in the message, the responder sends CGA Request to the initiator. Then the initiator transfers its CGA Params and CGA Signature as response, which is used to verify the initiator's address by the responder. 6.3. Bidirectional Verification In certain cases, the hosts need to verify the address of each other. The figure below illustrates the basic exchange. Zhang & Nallur Expires November 13, 2009 [Page 11] Internet-Draft CGA Extension Header of IPv6 May 2009 Initiator Responder NULL CGA HEADER --------------------------> CGA Request <------------------------- CGA Params, CGA Sig, CGA Request --------------------------> CGA Params, CGA Sig, <------------------------- A packet with null CGA header coming from the initiator implicate that there may be a CGA verification process. After receiving this kind of special CGA header in the message, the responder sends CGA Request to the initiator. Then the initiator transfers the message containing its CGA Params, CGA Signature and accessional CGA Request. The last message with CGA Params and CGA Signature of the responder is to allow the initiator to verify the responder address. 7. An Alternative Way to Take CGA Information Since creating a new extension header MAY be a big change to IPv6 protocol, another implementation way to take CGA information in the packet is using the existing extension header. It is articulated that a full implementation of IPv6 includes six types of extension header in [RFC2460]. From the definition of the extension headers, it can be easily infered that the destination options header is the optimal choice. The three types of options defined in section 3, including CGA Request, CGA Params and CGA Signature, SHOULD be put in the options field of the destination options header within the packets wherever the source address protection is need. In the implementation of IPv6, destination options header is able to occur in different place and twice (once before a routing header and once before the upper-layer header) in one packet. 1. The destination header before the routing header is used for options to be processed by the first destination that appears in the IPv6 Destination Address field plus subsequent destinations listed in the routing header. 2. The destination header before the upper-layer header is used for options to be processed only by the final destination of the Zhang & Nallur Expires November 13, 2009 [Page 12] Internet-Draft CGA Extension Header of IPv6 May 2009 packet. The above feature of destination options header provides the convenience of the solution using CGA to protect the source address. If the end host validates the CGA, put the destination options header with the CGA information options before the upper-layer header. This usage of the destination options header has the same effect with CGA extension header. Otherwise, in case 1, any node whose address must be put in the first place of the routing header can make the validation of CGA. For instance, put the address of the first-hop router or gateway in the first place of the routing header, so the first-hop router or gateway would validate the CGA, which prevents the forged packets form getting out of their LAN environment. This way that carries the CGA information in destination options header also avoids the problem of modifying the current protocols. 8. Security Considerations Address verification and signature verification by the CGA header is to validate the identity of the host. At the same time, the CGA header can limit the exposure of the host to man-in-the-middle (MitM) and some denial-of-service (DoS) attacks. Because the CGA header is an application in Network Layer, the higher layer protocols MAY choose this way to protect communication. The CGA header can prevents MitM attack. MitM forges packets with great difficulty. Because of the features of CGA, it is impossible for MitM to make a spoofed private key based on the address [RFC3972]. Or, at present, the private key cannot be generated through the corresponding public key. On the other hand, the Sequence Number and signature in the CGA header are able to prevent replay attack. The CGA header can prevent some DoS attacks as well. Since CGA can not be forged, attackers cannot launch DoS attack with many spoofed source addresses. If making DoS attack with the real address, the attacker is easy to be exposed. In the implement of the CGA header, signing packets consumes a large amount of resources. When one host receives packets with CGA Request from a same source address repeatedly, it MUST refuse to return the CGA Params and CGA Signature. The form of DoS attack using CGA verification process can also be avoided by ignoring the packets. To avoid the DoS attack of CGA Request, the host MAY choose to ignore the packets with CGA Request before sending the CGA initial message whose CGA header length is zero or verifying its peer's CGA Params Zhang & Nallur Expires November 13, 2009 [Page 13] Internet-Draft CGA Extension Header of IPv6 May 2009 and CGA Signature. The choice depends on the policy of the host. If a host receives CGA Params and CGA Signature from a source address that does not send the CGA Request, the host cannot trust the source address. Because there is no Sequence Number preventing replay attack. In this case, how to handle the packet depends on the local policy. 9. IANA Considerations This document specifies a new type of IPv6 extension header, whose value is to be allocated: Value Next Header Name Reference ------ ------------------------------- --------- TBD1 CGA Header [this doc] This document defines three new options in the CGA Header. A new namespace is required to be assigned by IANA and the values of these options are to be allocated: Value Option Name Reference ------ ------------------------------- --------- TBD2 CGA Request [this doc] TBD3 CGA Params [this doc] TBD4 CGA Signature [this doc] The above assignation of the three CGA options SHOULD also be used in destination extension header and identified by the any host. This document also defines two new types of ICMP messages whose values are to be allocated from the namespace of ICMP Type Numbers: Value Name Reference ------ ------------------------------- --------- TBD5 Verification Failure [this doc] TBD6 Option Errors [this doc] 10. Acknowledgements 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 Zhang & Nallur Expires November 13, 2009 [Page 14] Internet-Draft CGA Extension Header of IPv6 May 2009 (IPv6) Specification", RFC 2460, December 1998. [RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. 11.2. Informative References [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. Authors' Addresses Dong Zhang Huawei Symantec 3rd Floor,Section D, Keshi Building, No.28, Xinxi Rd., Shangdi HaiDian district, Beijing China Phone: 86-10-62721287 EMail: zhangdong_rh@huaweisymantec.com Padmanabha Nallur Futurewei Technologies 3255-4, Scott Blvd Santa Clara, California USA EMail: pnallur@huawei.com Zhang & Nallur Expires November 13, 2009 [Page 15]