Network Working Group Qingshan. Zhang Internet-Draft Alcatel Shanghai Bell Intended status: Standards Track September 2006 Expires: March 5, 2007 Extension of ICMP Security Failures Messages draft-zhang-btns-icmp-sec-extension-00.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 March 5, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Zhang Expires March 5, 2007 [Page 1] Internet-Draft Ext of ICMP Security Failures Messages September 2006 Abstract RFC2521 defines ICMP security failures messages for indicating failures when using IP Security Protocols (AH and ESP). This document presents extension of those messages, which make use of some reserved field to specify sub types of failures. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Message formats . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Not Classified . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Name Unauthorized . . . . . . . . . . . . . . . . . . . . 6 3.3. Data Sensitivity Level Unauthorized . . . . . . . . . . . 6 3.4. Transport Layer Protocol Unauthorized . . . . . . . . . . 7 3.5. Source Port Unauthorized . . . . . . . . . . . . . . . . . 7 3.6. Destination Port Unauthorized . . . . . . . . . . . . . . 7 4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 8 4.1. Processing Order . . . . . . . . . . . . . . . . . . . . . 8 4.2. Cooperation between New and Old Systems . . . . . . . . . 8 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 6. Normative References . . . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Zhang Expires March 5, 2007 [Page 2] Internet-Draft Ext of ICMP Security Failures Messages September 2006 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 [RFC2119]. Zhang Expires March 5, 2007 [Page 3] Internet-Draft Ext of ICMP Security Failures Messages September 2006 2. Introduction [RFC2521] is intended for use with the Internet Security Protocols ([RFC2401] etc.) for authentication and privacy. These messages covers all the failure types of IPSec traffic, but the granularity of some failures specified in the failure messages is larger than that provided by IPSec protocol suite. In order to make full use of the IPSec traffic granularity, 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 [RFC2521]. The ICMP type of these messages is 40 (Security Failures). Zhang Expires March 5, 2007 [Page 4] Internet-Draft Ext of ICMP Security Failures Messages September 2006 3. Message formats Below is the format of ICMP security failures messages with the subcode extension. It is different from the original format ([RFC2521]) at the reserved field. The first half of the reserved field is used as the "Subcode" field, which indicates sub types of security failures specified by the "Code" field. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subcode | Reserved | Pointer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Original Internet Headers + 64 bits of Payload ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 40 Code: Indicates the kind of failure: 0 = Bad SPI 1 = Authentication Failed 2 = Decompression Failed 3 = Decryption Failed 4 = Need Authentication 5 = Need Authorization Subcode: Indicates the sub kind of failure: 0 = Not Classified If Code = 0~4, values of the subcode MAY be defined in future if necessary. If Code = 5, the subcode is defined as below: 1 = Name Unauthorized 2 = Data Sensitivity Level Unauthorized 3 = Transport Layer Protocol Unauthorized Zhang Expires March 5, 2007 [Page 5] Internet-Draft Ext of ICMP Security Failures Messages September 2006 4 = Source Port Unauthorized 5 = Destination Port 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 [RFC2521]. The values of the "Code" field have the same meanings as defined in [RFC2521]. The values of subcode for "Need Authorization" are defined according to different selectors provided by IPSec, which determine the granularity of IPSec traffics. 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 sub types of this failure. 3.2. Name Unauthorized Indicates that a received datagram will not be accepted because either no name information, or inappropriate name information is presented. (There are 2 cases of name information supported in IPSec DOI - User ID and System Name.) In the case of receipt of a datagram with an ESP header, the name information is "OPAQUE" before decryption. The receptor SHOULD check the name information in this datagram after decryption, and generate a "Name Unauthorized" message if the name information of the datagram mismatches the name selector. 3.3. Data Sensitivity Level Unauthorized Indicates that a received datagram will not be accepted because either no data sensitivity information, or inappropriate data sensitivity level is presented. Zhang Expires March 5, 2007 [Page 6] Internet-Draft Ext of ICMP Security Failures Messages September 2006 3.4. Transport 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 transport protocol in the datagram. If the transport protocol in a datagram is "OPAQUE" (in ESP format), the receptor SHOULD check the transport protocol in this datagram after decryption, and generate a "Transport Protocol Unauthorized" message if the transport protocol of the datagram mismatches the transport protocol selector. 3.5. Source Port Unauthorized Indicates that a received datagram will not be accepted because the party is not allowed to access the destination through the source port. If the source port information in a datagram is "OPAQUE" (in ESP format), the receptor SHOULD check it in this datagram after decryption, and generate a "Source Port Unauthorized" message if the source port of the datagram is beyond the corresponding selector. 3.6. Destination Port Unauthorized Indicates that a received datagram will not be accepted because the party is not allowed to access the destination port. If the destination port information in a datagram is "OPAQUE" (in ESP format), the receptor SHOULD check it in this datagram after decryption, and generate a "Destination Port Unauthorized" message if the destination port of the datagram mismatches the corresponding selector. Zhang Expires March 5, 2007 [Page 7] Internet-Draft Ext of ICMP Security Failures Messages September 2006 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 "Name Unauthorized" failure happens, then comes to the next one - "Data Sensitivity Level 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 [RFC2521], 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 ([RFC2521]) 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 March 5, 2007 [Page 8] Internet-Draft Ext of ICMP Security Failures Messages September 2006 5. Acknowledgements Members of our research group provided help and suggestions to this document. Zhang Expires March 5, 2007 [Page 9] Internet-Draft Ext of ICMP Security Failures Messages September 2006 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [RFC2521] Karn, P. and W. Simpson, "ICMP Security Failures Messages", RFC 2521, March 1999. [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", RFC 3232, January 2002. Zhang Expires March 5, 2007 [Page 10] Internet-Draft Ext of ICMP Security Failures Messages September 2006 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 March 5, 2007 [Page 11] Internet-Draft Ext of ICMP Security Failures Messages September 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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 March 5, 2007 [Page 12]