RFC 2521

ICMP Security Failures Messages

📅 published March 1999, from ietf

RFC 2521: ICMP Security Failures Messages 🎀

okay bestie, let's get into it 💅 this one's an Experimental doc from March 1999, and the title block has all the deets:

  • Network Working Group 🌸
  • Authors: P. Karn (Qualcomm) and W. Simpson (DayDreamer) ✨
  • Category: Experimental 🧪
  • Date: March 1999 📅
  • Obsoletes / Updates: the header doesn't list either one, so this doc doesn't replace or patch anything else 🙅‍♀️

Status of This Memo 📜

This document defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind. They want discussion and suggestions for improvement, and distribution of this memo is unlimited 💖

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). So basically, it's the "something went wrong with your security stuff" messages 🔐

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

1. Introduction ✨

okay so this mechanism is made to work with the Internet Security Protocols [RFC-1825 et sequitur] for authentication and privacy 🔐 With statically configured Security Associations, these messages basically tell you that the operator needs to reconfigure things by hand, or that someone is trying something they aren't allowed to do 👀 They can also be used to kick off automated session-key management 🔑

The datagram format and basic facilities are already defined for ICMP [RFC-792] 🧚 so we're not reinventing the wheel here

Up-to-date values of the ICMP Type field are listed in the most recent "Assigned Numbers" [RFC-1700] 📋 This doc is about this one value:

       40  Security Failures

2. Message Formats 💌

Here's the header layout, so you can see exactly what's going on 👇

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |     Code      |          Checksum             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved            |          Pointer              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~     Original Internet Headers + 64 bits of Payload            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Now the fields, one by one 🍓

  • Type: it's always 40 💖
  • Code: tells you what kind of failure happened 😤
0 = Bad SPI
1 = Authentication Failed
2 = Decompression Failed
3 = Decryption Failed
4 = Need Authentication
5 = Need Authorization
  • Checksum: two octets, and it's the ICMP Checksum 🧮
  • Reserved: two octets, reserved for future use. It MUST be set to zero when transmitted, and it MUST be ignored when received 🫶
  • Pointer: two octets, and it's an offset into the Original Internet Headers that points at the most significant octet of the offending SPI. It'll be zero when no SPI is present 🎯
  • Original Internet Headers ...: this is the original Internet Protocol header, any intervening headers up to and including the offending SPI (if there is one), plus the first 64 bits (8 octets) of the remaining payload data 📦

This data is how the host matches the message to the right process 🕵️‍♀️ If a payload protocol uses port numbers, they're assumed to be in the first 64 bits of the original datagram's payload 🔎

Okay, now the specifics for each message type 👀

2.1. Bad SPI

Bad SPI means a received datagram has a Security Parameters Index (SPI) that's either invalid or expired. Bye bye, old key 🗑️

2.2. Authentication Failed

Authentication Failed means a received datagram didn't pass the authenticity or integrity check for a given SPI 🚫

Note that the SPI might point to an outer Encapsulating Security Protocol when a separate Authentication Header SPI is hidden inside 🪆

2.3. Decompression Failed

Decompression Failed means a received datagram didn't pass a decompression check for a given SPI 🗜️

2.4. Decryption Failed

Decryption Failed means a received datagram didn't pass a decryption check for a given SPI 🔓❌

2.5. Need Authentication

Need Authentication means a received datagram won't be accepted without extra authentication 🙅‍♀️

In this case, either there's no SPI at all, or the SPI that's there isn't suitable. For example, an encryption SPI without integrity shows up from a secure operating system with mutually suspicious users 🥸

2.6. Need Authorization

Need Authorization means a received datagram won't be accepted because it doesn't have enough authorization 💅

In this case, there's an authentication SPI that just isn't right for the target transport or application. The principle party denoted by the SPI doesn't have proper authorization for the facilities the datagram is using. For example, the party is authorized for Telnet access but not for FTP access 🚪

3. Error Procedures 🚨

As usual with ICMP messages, if you get one of these error messages and it's uninterpretable or otherwise contains an error, you don't send an ICMP error message back. The message just gets silently discarded 🤫 BUT for diagnosing problems, a node SHOULD provide the capability of logging the error, including the contents of the silently discarded datagram, and SHOULD record the event in a statistics counter 📊

On receipt, special care MUST be taken that the ICMP message actually includes information that matches a previously sent IP datagram 🔍 Otherwise, it could be an opening for a denial of service attack, and nobody wants that 😭

The sending implementation MUST be able to limit the rate at which these messages are generated ⏱️ The rate limit parameters SHOULD be configurable ⚙️ How the limits get applied (like by destination or per interface) is up to the implementor's discretion 🧑‍💻

okay bestie, this is the legal part, but make it cute 🎀 The Internet Society owns the copyright (1999) 💅 and Philip Karn and William Allen Simpson have their own copyright from 1994-1999 🫶 All Rights Reserved, obviously.

Okay so the good news is you can share this doc and translations of it 🦋 You can also make derivative works that comment on or explain it or help people implement it, and you can prepare, copy, publish, and distribute those, in whole or in part, with no restrictions of any kind 🌈 The only catch is that the copyright notice and this paragraph have to be included on all of those copies and derivative works 🍓

BUT the document itself can't be modified in any way 🙈 That means no removing the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when it's needed for developing Internet standards (then you have to follow the copyright procedures in the Internet Standards process 📜) or when you need to translate it into a language other than English 🌸

These permissions are perpetual, and the Internet Society or its successors or assigns can't revoke them 💜

The whole document and the info in it come "AS IS," and 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. 💀
📦 where this page comes from