idnits 2.17.1 draft-simpson-icmp-ipsec-fail-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 83: '.... For future use; MUST be set to zero...' RFC 2119 keyword, line 84: '...transmitted, and MUST be ignored when ...' RFC 2119 keyword, line 153: '... SHOULD provide the capability of lo...' RFC 2119 keyword, line 154: '...carded datagram, and SHOULD record the...' RFC 2119 keyword, line 157: '...pt, special care MUST be taken that th...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1996) is 10236 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) Summary: 12 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group P Karn 2 Internet Draft Qualcomm 3 W A Simpson 4 DayDreamer 5 expires in six months April 1996 7 ICMP Security Failures Messages 8 draft-simpson-icmp-ipsec-fail-02.txt 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 This document is an Internet-Draft. Internet Drafts are working doc- 15 uments of the Internet Engineering Task Force (IETF), its Areas, and 16 its Working Groups. Note that other groups may also distribute work- 17 ing documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months, and may be updated, replaced, or obsoleted by other documents 21 at any time. It is not appropriate to use Internet Drafts as refer- 22 ence material, or to cite them other than as a ``working draft'' or 23 ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow 27 Directories on: 29 ftp.is.co.za (Africa) 30 nic.nordu.net (Europe) 31 ds.internic.net (US East Coast) 32 ftp.isi.edu (US West Coast) 33 munnari.oz.au (Pacific Rim) 35 Abstract 37 This document specifies ICMP messages for indicating failures when 38 using IP Security Protocols (AH and ESP). 40 1. Introduction 42 This mechanism is intended for use with the Internet Security Proto- 43 cols [RFC-1825] for authentication and privacy. For statically con- 44 figured Security Associations, these messages indicate that the oper- 45 ator needs to manually reconfigure, or is attempting an unauthorized 46 operation. These messages may also be used to trigger automated ses- 47 sion-key management. 49 The datagram format and basic facilities are already defined for ICMP 50 [RFC-792]. 52 Up-to-date values of the ICMP Type field are specified in the most 53 recent "Assigned Numbers" [RFC-1700]. This document concerns the 54 following values: 56 40 Security Failures 58 2. Message Formats 60 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 61 | Type | Code | Checksum | 62 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 63 | Reserved | Pointer | 64 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 65 | | 66 ~ Original Internet Headers + 64 bits of Payload ~ 67 | | 68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 Type 40 72 Code Indicates the kind of failure: 74 0 = Bad SPI 75 1 = Authentication Failed 76 2 = Decompression Failed 77 3 = Decryption Failed 78 4 = Need Authentication 79 5 = Need Authorization 81 Checksum Two octets. The ICMP Checksum. 83 Reserved Two octets. For future use; MUST be set to zero 84 when transmitted, and MUST be ignored when received. 86 Pointer Two octets. An offset into the Original Internet 87 Headers that locates the most significant octet of 88 the offending SPI. Will be zero when no SPI is pre- 89 sent. 91 Original Internet Headers ... 92 The original Internet Protocol header, any interven- 93 ing headers up to and including the offending SPI 94 (if any), plus the first 64 bits (8 octets) of the 95 remaining payload data. 97 This data is used by the host to match the message 98 to the appropriate process. If a payload protocol 99 uses port numbers, they are assumed to be in the 100 first 64-bits of the original datagram's payload. 102 Usage of this message is elaborated in the following sections. 104 2.1. Bad SPI 106 Indicates that a received datagram includes a Security Parameters 107 Index (SPI) that is invalid or has expired. 109 2.2. Authentication Failed 111 Indicates that a received datagram failed the authenticity or 112 integrity check for a given SPI. 114 Note that the SPI may indicate an outer Encapsulating Security Proto- 115 col when a separate Authentication Header SPI is hidden inside. 117 2.3. Decompression Failed 119 Indicates that a received datagram failed a decompression check for a 120 given SPI. 122 2.4. Decryption Failed 124 Indicates that a received datagram failed a decryption check for a 125 given SPI. 127 2.5. Need Authentication 129 Indicates that a received datagram will not be accepted without addi- 130 tional authentication. 132 In this case, either no SPI is present, or an unsuitable SPI is pre- 133 sent. For example, an encryption SPI without integrity arrives from 134 a secure operating system with mutually hostile users. 136 2.6. Need Authorization 138 Indicates that a received datagram will not be accepted because it 139 has insufficient authorization. 141 In this case, an authentication SPI is present that is inappropriate 142 for the target transport or application. The principle party denoted 143 by the SPI does not have proper authorization for the facilities used 144 by the datagram. For example, the party is authorized for Telnet 145 access, but not for FTP access. 147 3. Error Procedures 149 As is usual with ICMP messages, upon receipt of one of these error 150 messages that is uninterpretable or otherwise contains an error, no 151 ICMP error message is sent in response. Instead, the message is 152 silently discarded. However, for diagnosis of problems, a node 153 SHOULD provide the capability of logging the error, including the 154 contents of the silently discarded datagram, and SHOULD record the 155 event in a statistics counter. 157 On receipt, special care MUST be taken that the ICMP message actually 158 includes information that matches a previously sent IP datagram. 159 Otherwise, this might provide an opportunity for a denial of service 160 attack. 162 The sending implementation MUST be able to limit the rate at which 163 these messages are generated. The rate limit parameters SHOULD be 164 configurable. How the limits are applied (such as, by destination or 165 per interface) is left to the implementor's discretion. 167 Security Considerations 169 When a prior Security Association between the parties has not 170 expired, these messages SHOULD be sent with authenticatation. 172 However, the node MUST NOT dynamically establish a new Security Asso- 173 ciation for the sole purpose of authenticating these messages. Auto- 174 mated key management is computationally intensive. This could be 175 used for a very serious denial of service attack. It would be very 176 easy to swamp a target with bogus SPIs from random IP Sources, and 177 have it start up numerous useless key management sessions to authen- 178 tically inform the putative sender. 180 In the event of loss of state (such as a system crash), the node will 181 need to send failure messages to all parties that attempt subsequent 182 communication. In this case, the node may have lost the key manage- 183 ment technique that was used to establish the Security Association. 185 Much better to simply let the peers know that there was a failure, 186 and let them request key management as needed (at their staggered 187 timeouts). They'll remember the previous key management technique, 188 and restart gracefully. This distributes the restart burden among 189 systems, and helps allow the recently failed node to manage its com- 190 putational resources. 192 In addition, these messages inform the recipient when the ICMP sender 193 is under attack. Unlike other ICMP error messages, the messages pro- 194 vide sufficient data to determine that these messages are in response 195 to previously sent messages. 197 Therefore, it is imperative that the recipient accept both authenti- 198 cated and unathenticated failure messages. The recipient's log 199 SHOULD indicate when the ICMP messages are not validated, and when 200 the ICMP messages are not in response to a valid previous message. 202 There is some concern that sending these messages may result in the 203 leak of security information. For example, an attacker might use 204 these messages to test or verify potential forged keys. However, 205 this information is already available through the simple expedient of 206 using Echo facilities, or waiting for a TCP 3-way handshake. 208 The rate limiting mechanism also limits this form of leak, as many 209 messages will not result in an error indication. At the very least, 210 this will lengthen the time factor for verifying such information. 212 Acknowledgements 214 Some of the text of this specification was derived from "Requirements 215 for Internet Hosts -- Communication Layers" [RFC-1122] and "Require- 216 ments for IP Version 4 Routers" [RFC-1812]. 218 Naganand Doraswamy and Hilarie Orman provided useful critiques of 219 earlier versions of this document. 221 Stimulating comments were also received from Jeffrey Schiller. 223 References 225 [RFC-792] 226 Postel, J., "Internet Control Message Protocol", STD 5, 227 September 1981. 229 [RFC-1122] 230 Braden, R., Editor, "Requirements for Internet Hosts -- Com- 231 munication Layers", USC/Information Sciences Institute, 232 October 1989. 234 [RFC-1700] 235 Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, 236 USC/Information Sciences Institute, October 1994. 238 [RFC-1812] 239 Baker, F., Editor, "Requirements for IP Version 4 Routers", 240 Cisco Systems, June 1995. 242 [RFC-1825] 243 Atkinson, R., "Security Architecture for the Internet Proto- 244 col", Naval Research Laboratory, July 1995. 246 Contacts 248 Comments about this document should be discussed on the ipsec- 249 dev@terisa.com mailing list. 251 Questions about this document can also be directed to: 253 Phil Karn 254 Qualcomm, Inc. 255 6455 Lusk Blvd. 256 San Diego, California 92121-2779 258 karn@qualcomm.com 259 karn@unix.ka9q.ampr.org (preferred) 261 William Allen Simpson 262 Daydreamer 263 Computer Systems Consulting Services 264 1384 Fontaine 265 Madison Heights, Michigan 48071 267 wsimpson@UMich.edu 268 wsimpson@GreenDragon.com (preferred) 269 bsimpson@MorningStar.com