Internet DRAFT - draft-zhang-btns-icmp-sec-extension

draft-zhang-btns-icmp-sec-extension






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]