Network Working Group P Karn Internet Draft Qualcomm W A Simpson DayDreamer expires in six months November 1995 ICMP Security Failures Messages draft-ietf-ipsec-icmp-fail-00.txt Status of this Memo This document is a submission to the IP Security Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ipsec@ans.net mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft. 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 not appropriate to use Internet Drafts as reference material, or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on: ftp.is.co.za (Africa) nic.nordu.net (Europe) ds.internic.net (US East Coast) ftp.isi.edu (US West Coast) munnari.oz.au (Pacific Rim) Abstract This document specifies ICMP messages for indicating failures when using IP Security Protocols (AH, ESP, and Photuris). Karn & Simpson expires in six months [Page i] DRAFT ICMP Security Failures November 1995 1. Introduction The datagram format and basic facilities are already defined for ICMP [RFC-792]. Up-to-date values of the ICMP Type field are specified in the most recent "Assigned Numbers" [RFC-1700]. This document concerns the following values: 40 Security Failures 2. Message Formats +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 Checksum Two octets. The ICMP Checksum. Reserved Two octets. For future use; MUST be set to zero when transmitted, and MUST be ignored when received. Pointer Two octets. An offset into the Original Internet Headers which locates most significant octet of the offending SPI. Will be zero when no SPI is present. Original Internet Headers ... Karn & Simpson expires in six months [Page 1] DRAFT ICMP Security Failures November 1995 The original Internet Protocol header, any intervening headers up to and including the offending SPI (if any), plus the first 64 bits (8 octets) of the remaining payload data. This data is used by the host to match the message to the appropriate process. If a higher level protocol uses port numbers, they are assumed to be in the first 64-bits of the original datagram's payload. 2.1. Bad SPI Indicates when a received datagram includes a Security Parameters Index (SPI) that is invalid or has expired. 2.2. Authentication Failed Indicates when a received datagram fails the authenticity or integrity check for a given SPI. Note that in "transport-mode", the SPI indicated will be of the outer Encapsulating Security Protocol. The separate Authentication Header SPI will be hidden inside. 2.3. Decompression Failed Indicates when a received datagram fails the decompression check for a given SPI. 2.4. Decryption Failed Indicates when a received datagram fails the decryption check for a given SPI. 2.5. Need Authentication Indicates when a received datagram will not be accepted without additional authentication. In this case, either no SPI is present, or an unsuitable SPI is present, such as an encryption SPI without integrity. Karn & Simpson expires in six months [Page 2] DRAFT ICMP Security Failures November 1995 2.6. Need Authorization Indicates when a received datagram will not be accepted because it has insufficient authorization. In this case, another authentication SPI is present which is inappropriate for the target transport or application. Security Considerations This mechanism is amenable to use of the Internet Security Protocols for authentication and privacy. ??? References [RFC-792] Postel, J., "Internet Control Message Protocol", STD 5, September 1981. [RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, USC/Information Sciences Institute, October 1994. Author's Address(es) Questions about this memo can also be directed to: Phil Karn Qualcomm, Inc. 6455 Lusk Blvd. San Diego, California 92121-2779 karn@qualcomm.com karn@unix.ka9q.ampr.org (prefered) William Allen Simpson Daydreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071 Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com (prefered) Karn & Simpson expires in six months [Page 3]