As per Relevance of the word failures, we have this rfc below:
Network Working Group P.
Request for Comments: 2521
Category: Experimental W.
March 1999
ICMP Security Failures
Status of this
This document defines an Experimental Protocol for the
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
Copyright (C) The Internet Society (1999). Copyright (C) Philip
and William Allen Simpson (1994-1999). All Rights Reserved
This document specifies ICMP messages for indicating failures
using IP Security Protocols (AH and ESP).
Karn & Simpson Experimental [Page i
RFC 2521 ICMP Security Failures March 1999
Table of
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.
This mechanism is intended for use with the Internet
Protocols [RFC-1825 et sequitur] for authentication and privacy.
statically configured Security Associations, these messages
that the operator needs to manually reconfigure, or is attempting
unauthorized operation. These messages may also be used to
automated session-key management
The datagram format and basic facilities are already defined for
[RFC-792].
Up-to-date values of the ICMP Type field are specified in the
recent "Assigned Numbers" [RFC-1700]. This document concerns
following values
40 Security
2. Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Original Internet Headers + 64 bits of Payload ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 40
Code Indicates the kind of failure
0 = Bad
1 = Authentication
2 = Decompression
3 = Decryption
4 = Need
5 = Need
Checksum Two octets. The ICMP Checksum
Reserved Two octets. For future use; MUST be set to
Karn & Simpson Experimental [Page 1]
RFC 2521 ICMP Security Failures March 1999
when transmitted, and MUST be ignored when received
Pointer Two octets. An offset into the Original
Headers that locates the most significant octet
the offending SPI. Will be zero when no SPI
present
Original Internet Headers ...
The original Internet Protocol header,
intervening headers up to and including
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
to the appropriate process. If a payload
uses port numbers, they are assumed to be in
first 64-bits of the original datagram's payload
Usage of this message is elaborated in the following sections
2.1. Bad
Indicates that a received datagram includes a Security
Index (SPI) that is invalid or has expired
2.2. Authentication
Indicates that a received datagram failed the authenticity
integrity check for a given SPI
Note that the SPI may indicate an outer Encapsulating
Protocol when a separate Authentication Header SPI is hidden inside
2.3. Decompression
Indicates that a received datagram failed a decompression check for
given SPI
2.4. Decryption
Indicates that a received datagram failed a decryption check for
given SPI
Karn & Simpson Experimental [Page 2]
RFC 2521 ICMP Security Failures March 1999
2.5. Need
Indicates that a received datagram will not be accepted
additional authentication
In this case, either no SPI is present, or an unsuitable SPI
present. For example, an encryption SPI without integrity
from a secure operating system with mutually suspicious users
2.6. Need
Indicates that a received datagram will not be accepted because
has insufficient authorization
In this case, an authentication SPI is present that is
for the target transport or application. The principle party
by the SPI does not have proper authorization for the facilities
by the datagram. For example, the party is authorized for
access, but not for FTP access
3. Error
As is usual with ICMP messages, upon receipt of one of these
messages that is uninterpretable or otherwise contains an error,
ICMP error message is sent in response. Instead, the message
silently discarded. However, for diagnosis of problems, a
SHOULD provide the capability of logging the error, including
contents of the silently discarded datagram, and SHOULD record
event in a statistics counter
On receipt, special care MUST be taken that the ICMP message
includes information that matches a previously sent IP datagram
Otherwise, this might provide an opportunity for a denial of
attack
The sending implementation MUST be able to limit the rate at
these messages are generated. The rate limit parameters SHOULD
configurable. How the limits are applied (such as, by destination
per interface) is left to the implementor's discretion
Karn & Simpson Experimental [Page 3]
RFC 2521 ICMP Security Failures March 1999
Security
When a prior Security Association between the parties has
expired, these messages SHOULD be sent with authentication
However, the node MUST NOT dynamically establish a new
Association for the sole purpose of authenticating these messages
Automated key management is computationally intensive. This could
used for a very serious denial of service attack. It would be
easy to swamp a target with bogus SPIs from random IP Sources,
have it start up numerous useless key management sessions
authentically inform the putative sender
In the event of loss of state (such as a system crash), the node
need to send failure messages to all parties that attempt
communication. In this case, the node may have lost the
management technique that was used to establish the
Association
Much better to simply let the peers know that there was a failure
and let them request key management as needed (at their
timeouts). They'll remember the previous key management technique
and restart gracefully. This distributes the restart burden
systems, and helps allow the recently failed node to manage
computational resources
In addition, these messages inform the recipient when the ICMP
is under attack. Unlike other ICMP error messages, the
provide sufficient data to determine that these messages are
response to previously sent messages
Therefore, it is imperative that the recipient accept
authenticated and unauthenticated failure messages. The recipient'
log SHOULD indicate when the ICMP messages are not validated,
when the ICMP messages are not in response to a valid
message
There is some concern that sending these messages may result in
leak of security information. For example, an attacker might
these messages to test or verify potential forged keys. However
this information is already available through the simple expedient
using Echo facilities, or waiting for a TCP 3-way handshake
The rate limiting mechanism also limits this form of leak, as
messages will not result in an error indication. At the very least
this will lengthen the time factor for verifying such information
Karn & Simpson Experimental [Page 4]
RFC 2521 ICMP Security Failures March 1999
The text has been extensively reviewed on the IP Security
list, in January and February of 1995 and again in December 1995.
The specification is stable, and was forwarded to the IESG by
authors for IETF Last Call as a Proposed Standard in March 1996.
There have been several implementations
Some of the text of this specification was derived from "
for Internet Hosts -- Communication Layers" [RFC-1122]
"Requirements for IP Version 4 Routers" [RFC-1812].
Naganand Doraswamy and Hilarie Orman provided useful critiques
earlier versions of this document
Stimulating comments were also received from Jeffrey Schiller
Special thanks to the Center for Information Technology
(CITI) for providing computing resources
[RFC-792] Postel, J., "Internet Control Message Protocol", STD 5,
September 1981.
[RFC-1122] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, USC/Information
Institute, October 1989.
[RFC-1700] Reynolds, J., and Postel, J., "Assigned Numbers", STD 2,
USC/Information Sciences Institute, October 1994.
[RFC-1812] Baker, F., Editor, "Requirements for IP Version 4
Routers", Cisco Systems, June 1995.
[RFC-1825] Atkinson, R., "Security Architecture for the
Protocol", Naval Research Laboratory, July 1995.
Karn & Simpson Experimental [Page 5]
RFC 2521 ICMP Security Failures March 1999
Comments about this document should be discussed on
photuris@adk.gr mailing list
Questions about this document can also be directed to
Phil
Qualcomm, Inc
6455 Lusk Blvd
San Diego, California 92121-2779
karn@qualcomm.
karn@unix.ka9q.ampr.org (preferred
William Allen
Computer Systems Consulting
1384
Madison Heights, Michigan 48071
wsimpson@UMich.
wsimpson@GreenDragon.com (preferred
Karn & Simpson Experimental [Page 6]
RFC 2521 ICMP Security Failures March 1999
Full Copyright
Copyright (C) The Internet Society (1999). Copyright (C)
Karn and William Allen Simpson (1994-1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise
it or assist in its implementation may be prepared, copied
published and distributed, in whole or in part, without
of any kind, provided that the above copyright notice and
paragraph are included on all such copies and derivative works
However, this document itself may not be modified in any way,
as by removing the copyright notice or references to the
Society or other Internet organizations, except as needed for
purpose of developing Internet standards (in which case
procedures for copyrights defined in the Internet Standards
must be followed), or as required to translate it into
other than English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
(BUT NOT LIMITED TO) ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Karn & Simpson Experimental [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
