Network Working Group Qingshan. Zhang Internet-Draft Alcatel Shanghai Bell Intended status: Standards Track March 1, 2007 Expires: September 2, 2007 Extension of ICMP Security Failures Messages draft-zhang-btns-icmp-sec-extension-01.txt Status of this Memo 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. 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 September 2, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Zhang Expires September 2, 2007 [Page 1] Internet-Draft Ext of ICMP Security Failures Messages March 2007 Abstract [RFC 2521] defines ICMP security failures messages for indicating failures when using IP Security Protocols (AH and ESP). This document presents extension of those messages, that make use of some reserved field to specify subtypes of failures. Table of Contents 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Not Classified . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Remote IP Address Unauthorized . . . . . . . . . . . . . . 6 3.3. Local IP Address Unauthorized . . . . . . . . . . . . . . 7 3.4. Next Layer Protocol Unauthorized . . . . . . . . . . . . . 7 3.5. Name Unauthorized . . . . . . . . . . . . . . . . . . . . 7 3.6. Remote Port Unauthorized . . . . . . . . . . . . . . . . . 7 3.7. Local Port Unauthorized . . . . . . . . . . . . . . . . . 8 3.8. Mobility Header Type Unauthorized . . . . . . . . . . . . 8 3.9. ICMP Message Type and Code Unauthorized . . . . . . . . . 8 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 9 4.1. Processing Order . . . . . . . . . . . . . . . . . . . . . 9 4.2. Cooperation between New and Old Systems . . . . . . . . . 9 5. IPv6 Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Normative References . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Zhang Expires September 2, 2007 [Page 2] Internet-Draft Ext of ICMP Security Failures Messages March 2007 1. Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. Zhang Expires September 2, 2007 [Page 3] Internet-Draft Ext of ICMP Security Failures Messages March 2007 2. Introduction [RFC 2521] is intended for use with the Internet Security Protocols ([RFC 4301] etc.) for authentication and privacy. These messages cover all the failure types of IPSec traffic, but the granularity of some failures specified in the failure messages is larger than that provided by the IPSec protocol suite. In order to make full use of the IPSec traffic granularity, an extension of the failure messages is introduced in this document, which subdivides some failure types according to the minimum granularity of IPSec traffic. The format of ICMP security failure messages are defined in [RFC 2521]. The ICMP type of these messages is 40 (Security Failures). Zhang Expires September 2, 2007 [Page 4] Internet-Draft Ext of ICMP Security Failures Messages March 2007 3. Message Formats Below is the format of ICMP security failures messages with the subcode extension. It is different from the original format ([RFC 2521]) at the reserved field. The first half of the reserved field is used as the "Subcode" field, which indicates subtypes of security failures specified by the "Code" field. 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 | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subcode | Reserved | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Original Internet Headers + 64 bits of Payload (or more) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 40 Code: Indicates the type of failure, as specified in [RFC 2521]: 0 = Bad SPI 1 = Authentication Failed 2 = Decompression Failed 3 = Decryption Failed 4 = Need Authentication 5 = Need Authorization Subcode: Indicates the subtype of failure: There is a distinct namespace for subcode values, per Code. For all values of Code, the following is defined: 0x00 (0) = Not Classified If Code = 0..4, values of the subcode MAY be defined in the future if necessary. If Code = 5, the following subcode values are defined: Zhang Expires September 2, 2007 [Page 5] Internet-Draft Ext of ICMP Security Failures Messages March 2007 0x01 (1) = Remote IP Address Unauthorized 0x02 (2) = Local IP Address Unauthorized 0x03 (3) = Next Layer Protocol Unauthorized 0x04 (4) = Name Unauthorized 0x10 (16) = Remote Port Unauthorized 0x11 (17) = Local Port Unauthorized 0x20 (32) = Mobility Header Type Unauthorized 0x30 (48) = ICMP Message Type and Code Unauthorized Otherwise, the subcode MUST be set to zero. Reserved: 1 octet. For future use; MUST be set to zero when transmitted, and MUST be ignored when received. Other fields such as "Checksum", "Pointer", "Original Internet Headers ..." are right the same as those of [RFC 2521]. The values of the "Code" field have the same meanings as defined in [RFC 2521]. The values of subcode for "Need Authorization" are defined according to different selectors provided by IPSec, which determine the granularity of IPSec traffics. The meanings of these values are elaborated as below. 3.1. Not Classified This value is used for all failure types (Code=0~5). It indicates that a received datagram will not be accepted because there is a failure with the datagram, but the receptor does not specify subtypes of this failure. 3.2. Remote IP Address Unauthorized Indicates that a received datagram will not be accepted because the party (remote IP address) is not authorized to access the destination host. If the remote IP address in a datagram is "OPAQUE" (tunneled packet in ESP format), the receptor SHOULD check the remote IP address in this datagram after decryption, and generate a "Remote IP Address Zhang Expires September 2, 2007 [Page 6] Internet-Draft Ext of ICMP Security Failures Messages March 2007 Unauthorized" message if the remote IP address of the datagram mismatches the corresponding selector. 3.3. Local IP Address Unauthorized Indicates that a received datagram will not be accepted because the party is not authorized to access the destination host (local IP address). If the local IP address in a datagram is "OPAQUE" (such as a tunneled packet in ESP format), the receptor SHOULD check the local IP address in this datagram after decryption, and generate a "Local IP Address Unauthorized" message if the local IP address of the datagram mismatches the corresponding selector. 3.4. Next Layer Protocol Unauthorized Indicates that a received datagram will not be accepted because the party is not authorized to access the destination host with the next layer protocol in the datagram. If the next layer protocol in a datagram is "OPAQUE", the receptor SHOULD check the next layer protocol in this datagram after decryption, and generate a "Next Layer Protocol Unauthorized" message if the next layer protocol of the datagram mismatches the corresponding selector. 3.5. Name Unauthorized Indicates that a received datagram will not be accepted because the remote IP address in the datagram mismatches the IP address indicated by the name selector. The name employed in named SPD entries corresponds to ID_RFC822_ADDR, ID_FQDN, ID_DER_ASN1_DN, or Key_ID in IKEv2. 3.6. Remote Port Unauthorized Indicates that a received datagram will not be accepted because the party is not allowed to access the destination host through the remote port. If the remote port information in a datagram is "OPAQUE", the receptor SHOULD check it in this datagram after decryption, and generate a "Remote Port Unauthorized" message if the remote port of the datagram is beyond the corresponding selector. Zhang Expires September 2, 2007 [Page 7] Internet-Draft Ext of ICMP Security Failures Messages March 2007 3.7. Local Port Unauthorized Indicates that a received datagram will not be accepted because the party is not allowed to access the local port. If the local port information in a datagram is "OPAQUE", the receptor SHOULD check it in this datagram after decryption, and generate a "Local Port Unauthorized" message if the local port of the datagram mismatches the corresponding selector. 3.8. Mobility Header Type Unauthorized Indicates that a received datagram will not be accepted because the party is not allowed to access the destination host with the mobility header type. If the MH type information in a datagram is "OPAQUE", the receptor SHOULD check it in this datagram after decryption, and generate a "Mobility Header Type Unauthorized" message if the MH type the datagram mismatches the corresponding selector. 3.9. ICMP Message Type and Code Unauthorized Indicates that a received datagram will not be accepted because such type of the ICMP message in the datagram is not allowed to be sent to the destination host. If the ICMP message type and code information in a datagram is "OPAQUE", the receptor SHOULD check it in this datagram after decryption, and generate a "ICMP Message Type and Code Unauthorized" message if the type and code of the ICMP message mismatches the corresponding selector. Zhang Expires September 2, 2007 [Page 8] Internet-Draft Ext of ICMP Security Failures Messages March 2007 4. Processing Procedures 4.1. Processing Order When a datagram with the failure of "Need Authorization" arrives, the receptor checks it in turn to find out what is the subtype of the failure happening in the datagram. That means the receptor checks whether the "Remote IP Address Unauthorized" failure happens, then comes to the next one - "Local IP Address Unauthorized", and so on. The receptor takes the first failure it figures out as the subtype of the "Need Authorization" failure and feeds it back in an ICMP message to the party. 4.2. Cooperation between New and Old Systems If the receptor implements the standard of [RFC 2521], while the party implements this one, the receptor does not specify the subtype of the failure happening in the datagram from the party, but fills the reserved field with zero. When the party gets the ICMP security failure message from the receptor, it finds out the type of the failure from the "Code" field. Since the "Subcode" field is filled up with zero, the party takes the subtype of the failure as "Not Classified". On the contrary, if the party implements the old standard ([RFC 2521]) while the receptor implements the new one, the party just ignores the "Subcode" field in which the receptor specifies the subtype of the failure in the datagram it receives from the party. Zhang Expires September 2, 2007 [Page 9] Internet-Draft Ext of ICMP Security Failures Messages March 2007 5. IPv6 Considerations These subtypes defined in this document are applicable for both ICMP [RFC 0792] and ICMPv6 [RFC 4443]. They are especially important for ICMPv6, since IPSec is a necessary component of IPv6. Zhang Expires September 2, 2007 [Page 10] Internet-Draft Ext of ICMP Security Failures Messages March 2007 6. IANA Considerations This document calls for registration of subtypes of ICMP security failure messages [RFC 3232], according to their definitions in Section 3. The number of ICMP security failure message subtypes can be easily expand with the development of IPSec protocols. New top level subtypes can be assigned subcodes in turn, whose first 4 bits are ZERO. Different 2nd level subtypes will be assigned subcodes with different first 4 bits from 0x1 to 0xf. The 2nd level subtypes in a same set will be assigned subcodes with different last 4 bits from 0x1 to 0xf. For exampel, if there is a new top level subtypes of "Need Authorization" should be added, it will be assigned the subcode of 0x05 (5) following that of "Name Unauthorized". If there are some subtypes should be defined for a new next layer protocol, the first one of them will be assigned the subcode of 0x40 (64), and the next one 0x41 (65), and so on. If a new subtype is required for the ICMP protocol in the future, the subcode of 0x31 (49) will be assigned for it. Zhang Expires September 2, 2007 [Page 11] Internet-Draft Ext of ICMP Security Failures Messages March 2007 7. Acknowledgements Members of our research group provided help and suggestions to this document. Zhang Expires September 2, 2007 [Page 12] Internet-Draft Ext of ICMP Security Failures Messages March 2007 8. Normative References [RFC 0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 0792, September 1981. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2521] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999. [RFC 3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. [RFC 4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC 4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC 4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC 4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC 4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. Zhang Expires September 2, 2007 [Page 13] Internet-Draft Ext of ICMP Security Failures Messages March 2007 Author's Address Qingshan Zhang Alcatel Shanghai Bell 388#, Ningqiao Road, Pudong District Shanghai China Phone: +86 21 28978285 Email: Qingshan.ZHANG@alcatel-sbell.com.cn Zhang Expires September 2, 2007 [Page 14] Internet-Draft Ext of ICMP Security Failures Messages March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Zhang Expires September 2, 2007 [Page 15]