RFC 2521 (rfc2521) - Page 1 of 7
ICMP Security Failures Messages
Alternative Format: Original Text Document
Network Working Group P. Karn
Request for Comments: 2521 Qualcomm
Category: Experimental W. Simpson
DayDreamer
March 1999
ICMP Security Failures Messages
Status of this Memo
This document defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1999). Copyright (C) Philip Karn
and William Allen Simpson (1994-1999). All Rights Reserved.
Abstract
This document specifies ICMP messages for indicating failures when
using IP Security Protocols (AH and ESP).
Karn & Simpson Experimental [Page i]
RFC 2521 ICMP Security Failures March 1999
Table of Contents
1. Introduction .......................................... 1
2. Message Formats ....................................... 1
2.1 Bad SPI ......................................... 2
2.2 Authentication Failed ........................... 2
2.3 Decompression Failed ............................ 2
2.4 Decryption Failed ............................... 2
2.5 Need Authentication ............................. 3
2.6 Need Authorization .............................. 3
3. Error Procedures ...................................... 3
SECURITY CONSIDERATIONS ...................................... 4
HISTORY ...................................................... 5
ACKNOWLEDGEMENTS ............................................. 5
REFERENCES ................................................... 5
CONTACTS ..................................................... 6
COPYRIGHT .................................................... 7
Karn & Simpson Experimental [Page ii]
RFC 2521 ICMP Security Failures March 1999
1. Introduction
This mechanism is intended for use with the Internet Security
Protocols [RFC-1825 et sequitur] for authentication and privacy. For
statically configured Security Associations, these messages indicate
that the operator needs to manually reconfigure, or is attempting an
unauthorized operation. These messages may also be used to trigger
automated session-key management.
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
Karn & Simpson Experimental