idnits 2.17.1 draft-ietf-ipsec-notifymsg-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([RFC2408,RFC2407]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 105 has weird spacing: '... of the messa...' == Line 252 has weird spacing: '...of 0 is detec...' == Line 706 has weird spacing: '...ype. It would...' == Line 707 has weird spacing: '...y using this ...' == Line 708 has weird spacing: '...fier to this ...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Values 131-16383 are reserved to IANA. Values 16384-32767 are for private use among mutually consenting parties. Values 0, 1, and 2 are reserved for backwards compatibility, and MUST not be used in any other notifications than RESPONDER-LIFETIME and REPLAY-STATUS. The RESPONDER-LIFETIME notification data is an attributes list containing attributes of class 1 and 2. The REPLAY-STATUS notification data is a 32-bit integer containing the values 0 or 1 (meaning the first 2 bytes are 0, thus decoding as an attribute class of 0). Note that when the attribute class of 0 is detected, the rest of the data does not conform to format of an attribute list. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2026' is mentioned on line 11, but not defined == Missing Reference: 'RFC2119' is mentioned on line 141, but not defined == Unused Reference: 'RFC-2119' is defined on line 1241, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2408 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) Summary: 13 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSEC Working Group Scott Kelly, RedCreek 3 INTERNET-DRAFT Tero Kivinen, SSH 4 draft-ietf-ipsec-notifymsg-04.txt November, 2000 6 Content Requirements for ISAKMP Notify Messages 8 Status of This Memo 10 This document is an Internet Draft and is in full conformance with 11 all provisions of Section 10 of [RFC2026]. Internet Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and working groups. Note that other groups may also distribute 14 working documents as Internet Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Comments on this document should be sent to the IETF IPsec WG 28 discussion list (ipsec@lists.tislabs.com). 30 Abstract 32 The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status 33 message types for use in ISAKMP NOTIFY messages, but in some cases do 34 not specify that any additional clarifying data be carried in the 35 messages. In these cases, it is difficult to determine which SA 36 corresponds to the received NOTIFY message. While the DOI RFC 37 specifies content and formats for additional data in the currently 38 defined IPSEC status messages, no such requirements are currently 39 specified for ISAKMP NOTIFY messages. This document provides content 40 and format recommendations for those messages. 42 Table of Contents 44 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 45 1.1 Requirements Terminology . . . . . . . . . . . . . . . . . . . . 3 46 1.2 Reader Prerequisites . . . . . . . . . . . . . . . . . . . . . . 4 47 1.3 Document Organization . . . . . . . . . . . . . . . . . . . . . 4 48 1.4 Backwards Compatibility . . . . . . . . . . . . . . . . . . . . 4 49 2. General Formatting Considerations . . . . . . . . . . . . . . . . 4 50 3. ISAKMP NOTIFY Error Messages . . . . . . . . . . . . . . . . . . 7 51 3.1 INVALID-PAYLOAD-TYPE . . . . . . . . . . . . . . . . . . . . . . 7 52 3.2 DOI-NOT-SUPPORTED . . . . . . . . . . . . . . . . . . . . . . . 8 53 3.3 SITUATION-NOT-SUPPORTED . . . . . . . . . . . . . . . . . . . . 9 54 3.4 INVALID-COOKIE . . . . . . . . . . . . . . . . . . . . . . . . . 9 55 3.5 INVALID-MAJOR-VERSION . . . . . . . . . . . . . . . . . . . . . 10 56 3.6 INVALID-MINOR-VERSION . . . . . . . . . . . . . . . . . . . . . 10 57 3.7 INVALID-EXCHANGE-TYPE . . . . . . . . . . . . . . . . . . . . . 11 58 3.8 INVALID-FLAGS . . . . . . . . . . . . . . . . . . . . . . . . . 11 59 3.9 INVALID-MESSAGE-ID . . . . . . . . . . . . . . . . . . . . . . . 12 60 3.10 INVALID-PROTOCOL-ID . . . . . . . . . . . . . . . . . . . . . . 12 61 3.11 INVALID-SPI . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 3.12 INVALID-TRANSFORM-ID . . . . . . . . . . . . . . . . . . . . . 13 63 3.13 ATTRIBUTES-NOT-SUPPORTED . . . . . . . . . . . . . . . . . . . 14 64 3.14 NO-PROPOSAL-CHOSEN . . . . . . . . . . . . . . . . . . . . . . 15 65 3.15 BAD-PROPOSAL-SYNTAX . . . . . . . . . . . . . . . . . . . . . . 15 66 3.16 PAYLOAD-MALFORMED . . . . . . . . . . . . . . . . . . . . . . . 16 67 3.17 INVALID-KEY-INFORMATION . . . . . . . . . . . . . . . . . . . . 16 68 3.18 INVALID-ID-INFORMATION . . . . . . . . . . . . . . . . . . . . 17 69 3.19 INVALID-CERT-ENCODING . . . . . . . . . . . . . . . . . . . . . 17 70 3.20 INVALID-CERTIFICATE . . . . . . . . . . . . . . . . . . . . . . 18 71 3.21 CERT-TYPE-UNSUPPORTED . . . . . . . . . . . . . . . . . . . . . 18 72 3.22 INVALID-CERT-AUTHORITY . . . . . . . . . . . . . . . . . . . . 19 73 3.23 INVALID-HASH-INFORMATION . . . . . . . . . . . . . . . . . . . 19 74 3.24 AUTHENTICATION-FAILED . . . . . . . . . . . . . . . . . . . . . 20 75 3.25 INVALID-SIGNATURE . . . . . . . . . . . . . . . . . . . . . . . 20 76 3.26 ADDRESS-NOTIFICATION . . . . . . . . . . . . . . . . . . . . . 21 77 3.27 NOTIFY-SA-LIFETIME . . . . . . . . . . . . . . . . . . . . . . 21 78 3.28 CERTIFICATE-UNAVAILABLE . . . . . . . . . . . . . . . . . . . . 22 79 3.29 UNSUPPORTED-EXCHANGE-TYPE . . . . . . . . . . . . . . . . . . . 22 80 3.30 UNEQUAL-PAYLOAD-LENGTHS . . . . . . . . . . . . . . . . . . . . 23 81 4. ISAKMP Notify Status messages . . . . . . . . . . . . . . . . . . 23 82 4.1 CONNECTED . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 4.2 RESPONDER-LIFETIME . . . . . . . . . . . . . . . . . . . . . . . 24 84 4.3 REPLAY-STATUS . . . . . . . . . . . . . . . . . . . . . . . . . 25 85 4.4 INITIAL-CONTACT . . . . . . . . . . . . . . . . . . . . . . . . 25 86 5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 26 87 6. Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 88 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27 90 9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 27 91 1. Overview 93 The ISAKMP and DOI RFCs [RFC2408, RFC2407] specify error and status 94 message types for use in ISAKMP NOTIFY messages, but in some cases do 95 not specify that any additional clarifying data be carried in the 96 messages. In many cases, it is difficult to determine which SA 97 corresponds to the received NOTIFY message. Such determination 98 requires that additional information be placed in the notification 99 data section of the NOTIFY payload. While the DOI RFC specifies 100 content and formats for additional data in the currently defined 101 IPSEC status messages, no content or formatting requirements are 102 currently specified for ISAKMP NOTIFY messages. 104 Many of the ISAKMP NOTIFY messages may apply to either phase 1 or 105 phase 2 negotiations. In some cases, the context of the message 106 makes clear what transaction it refers to, e.g. if the NOTIFY message 107 pertains to the ISAKMP (phase 1) SA upon which it is received. 108 However, there are cases in which ambiguities may arise. For example, 109 there may be multiple phase 2 SAs negotiated using a single phase 1 110 SA, and these may be simultaneously under negotiation. A NOTIFY 111 message received via the parent phase 1 SA may apply to any of the 112 phase 2 SAs, but the receiver may not be able to determine which. 114 In order to be truly useful, NOTIFY messages must, at minimum, allow 115 the receiver to determine which transaction the message corresponds 116 to. As indicated above, in some cases this information may be 117 entirely derived from information contained in the ISAKMP header 118 (cookies and message ID). However, in many cases, and in particular 119 with respect to phase 2 negotiations, the correct context cannot be 120 ascertained without additional information. In some of those cases, 121 the relevant information may be carried in the predefined notify 122 payload fields. In others, this is not enough, and in such cases 123 additional information may be carried in the notify payload data 124 field. 126 In addition to the need to determine which SA a NOTIFY message 127 corresponds to, it would also be useful to know more precisely what 128 problem was encountered. For example, an INVALID-PAYLOAD message 129 would be far more useful if one could determine exactly which payload 130 was at issue. Such additional data would be very useful when 131 diagnosing error conditions, and also would provide useful 132 information for auditing purposes. This document provides content and 133 format recommendations for ISAKMP NOTIFY messages which are aimed at 134 providing the additional granularity required to make these messages 135 truly useful. 137 1.1 Requirements Terminology 138 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 139 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 140 document, are to be interpreted as described in [RFC2119]. 142 1.2 Reader Prerequisites 144 [RFC2407], [RFC2408], and [RFC2409] are prerequisites to 145 understanding the material presented here. While not strictly 146 necessary, reader familiarity with [RFC2401], [RFC2402], [RFC2406], 147 and with general IP security concepts will further facilitate 148 understanding. 150 1.3 Document Organization 152 In the following section is a discussion of general format 153 considerations for all notify messages. Following that, the NOTIFY 154 messages are presented in 2 sections: ISAKMP error messages, and 155 ISAKMP status messages. It is possible that a later revision of this 156 document will address IPSEC error/status messages, but some of those 157 NOTIFY message types are currently addressed in [RFC2407]. 159 Within each section, messages are detailed in individual subsections. 160 Following the example of [RFC2407], each message payload is detailed 161 field-by-field. Where appropriate, additional information regarding 162 the circumstances under which each message arises, along with 163 relative payload variations under those circumstances, is included. 165 1.4 Backwards Compatibility 167 The IPsec DOI [RFC2407] document defines some notification types, 168 along with the data contained in the associated notification data 169 fields. Those definitions do not conform with the definitions in this 170 document. In the interest of backwards compatibility, pains have been 171 taken to accommodate these differences in the definitions offered in 172 this document. 174 When new use of notification data is defined in any document that 175 uses the IPsec DOI (RFC 2407), regardless of the key exchange 176 protocol the usage MUST follow the generic format described in this 177 document (i.e. the attribute list encoding of the notification data). 178 These new types may be either allocated from IANA or from the private 179 use range. 181 2. General Formatting Considerations 183 The ISAKMP notify payload contains a number of fields meant to convey 184 contextual information regarding the event precipitating the message. 185 Following is an enumeration of the notify payload fields: 187 (payload type/length fields omitted) 189 o Domain of Interpretation (4 octets) - Identifies the DOI 190 under which this notification is taking place. 192 o Protocol-Id (1 octet) - Specifies the protocol identifier 193 for the current notification. Examples might include ISAKMP, 194 IPSEC ESP, IPSEC AH, OSPF, TLS, etc. 196 o SPI Size (1 octet) - Length in octets of the SPI as defined by 197 the Protocol-Id. 199 o Notify Message Type (2 octets) - Specifies the type of 200 notification message. 202 o SPI (variable length) - Security Parameter Index. The 203 receiving entity's SPI. The length of this field is 204 determined by the SPI Size field. 206 o Notification Data (variable length) - Informational or error 207 data transmitted in addition to the Notify Message Type. 209 In many cases, the information contained in the notify payload is 210 insufficient to fully identify the session or transaction for which 211 the error(s) occurred, and in these cases the Notification Data field 212 MAY be used to convey additional information. In order to provide for 213 uniform processing of the notification data field, class attributes 214 are defined below for ISAKMP NOTIFY messages, and notification data 215 MUST be encoded using these attributes. 217 Attribute encoding is discussed in [RFC2408], and that discussion is 218 not repeated here, except for the following notes. Attribute encoding 219 types are either Basic (B) or Variable-length (V). Encoding of these 220 attributes is defined in the [RFC2408] as Type/Value (Basic) and 221 Type/Length/Value (Variable-length). Attributes described as Basic 222 MUST NOT be encoded as Variable. Variable attributes MAY be encoded 223 as basic attributes if their value can fit into two octets. 225 Attribute Classes 227 Encoding 228 Type Description Value Type 229 -------------------------------------------------------- 230 Type of Offending Payload 3 B 231 Offending Payload Data 4 V 232 Error Position Offset 5 B 233 Error Text Describing 234 the Problem 6 V 235 Error Text Language 7 V 236 Message Id of the Offending 237 Negotiation 8 V 238 Exchange Type of Negotiation 9 B 239 Invalid Flag Bits 10 B 240 Suggested Proposal 11 V 241 Notification Attribute Version 12 B 242 ------------------------------------------------------- 244 Values 131-16383 are reserved to IANA. Values 16384-32767 245 are for private use among mutually consenting parties. Values 0, 1, 246 and 2 are reserved for backwards compatibility, and MUST not be 247 used in any other notifications than RESPONDER-LIFETIME and REPLAY- 248 STATUS. The RESPONDER-LIFETIME notification data is an attributes 249 list containing attributes of class 1 and 2. The REPLAY-STATUS 250 notification data is a 32-bit integer containing the values 0 or 1 251 (meaning the first 2 bytes are 0, thus decoding as an attribute 252 class of 0). Note that when the attribute class of 0 is detected, 253 the rest of the data does not conform to format of an attribute 254 list. 256 Attribute Type Descriptions 258 Type of Offending Payload 259 Payload type of the offending payload encoded as a 16 260 bit integer. 262 Offending Payload Data 263 Offending payload data including the generic header. Note 264 that next payload type in the notify payload itself points 265 to the next payload beyond the notification data. Likewise, 266 the next payload type in the offending payload contains 267 the value placed there by the original sender, and does 268 not reference any payloads within the notify message. 270 Error Position Offset 271 Byte offset of the error position from the beginning of the 272 offending payload. Presence of this attribute implies the 273 presence of the offending payload data attribute. That is, 274 when this attribute is present, there MUST also be a 275 corresponding offending payload attribute. 277 Error Text Describing the Problem 278 Text describing the problem. (ISO-10646 UTF-8 encoding). 280 Error Text Language 281 Error text language tag (as defined in RFC 1766). When this 282 attribute is present, there MUST also be a corresponding 283 error text attribute. 285 Message Id of the Offending Negotiation 286 Message id of the offending negotiation encoded has 4 byte 287 value. 289 Exchange Type of Negotiation 290 Exchange type of the offending negotiation. Encoded as 16 291 bit integer. 293 Invalid Flag Bits 294 Invalid flags (valid flags are masked out) Encoded as 16 295 bit integer. 297 Suggested Proposal 298 Optional proposal suggestion to be used in case of failed 299 negotiation due to policy mismatch. 301 Notification Attribute Version 302 Indicates the version of this document from which encodings 303 were derived. MUST be the first attribute in the notification 304 data if notification data is included, and MUST contain the 305 value 0x0001. Because this attribute is always first, it can 306 be used as a magic cookie, i.e. if the notification data 307 begins with bytes 0x80, 0x0C, 0x00, 0x01, then it most likely 308 follows the formatting guidelines described in this document. 310 Note that implementations may not recognize some or all of these 311 attributes, and in some cases, inclusion of some attributes within 312 specific notify messages will be optional. In such cases, 313 implementations MUST ignore unrecognized attributes. 315 3. ISAKMP NOTIFY Error Messages 317 This section contains NOTIFY error messages which are usually 318 specific to ISAKMP (phase 1) Security Associations (SAs). Some of 319 these messages may also apply to the negotiation of IPSec (phase 2) 320 SAs. In such cases, provision is made for use of the appropriate SPI 321 (and other) values. These NOTIFY message types are defined in 322 [RFC2408]. 324 3.1 INVALID-PAYLOAD-TYPE 325 The INVALID-PAYLOAD-TYPE error message may be used to communicate 326 that an unrecognized or invalid payload type was received. 328 Phase: 1 or 2 330 Differentiators: Cookies vs SPI, 331 Subject payload (and/or type) 332 Message ID 334 Payloads: All 336 When present, the Notification Payload MUST have the following 337 format: 339 o Payload Length - set to length of payload + size of data (var) 340 o DOI - set to the current DOI if available, or set to zero (0) 341 to indicate ISAKMP DOI. 342 o Protocol ID - set to selected Protocol ID from chosen SA 343 if available; set to zero (0) to indicate ISAKMP SA. 344 o SPI Size - set to either zero (0) or sixteen (16) 345 o Notify Message Type - set to INVALID-PAYLOAD-TYPE 346 o SPI - set to empty or to the ISAKMP cookies for the failed 347 negotiation. 348 o Notification Data - SHOULD contain the type of the offending 349 payload, and MAY contain the offending payload, the message ID 350 associated with the payload, and error text describing the 351 problem. 353 3.2 DOI-NOT-SUPPORTED 355 The DOI-NOT-SUPPORTED error message may be used to communicate that 356 an unrecognized or unsupported DOI value was received. 358 Phase: 1 or 2 359 Differentiators: Cookies vs SPI, Protocol ID, 360 subject DOI, message ID 361 Payloads: SA 363 When present, the Notification Payload MUST have the following 364 format: 366 o Payload Length - set to length of payload + size of data 367 o DOI - set to 0 (ISAKMP DOI) 368 o Protocol ID - set to PROTO_ISAKMP 369 o SPI Size - set to either zero (0) or sixteen (16) 370 o Notify Message Type - set to DOI-NOT-SUPPORTED 371 o SPI - set to empty or to the ISAKMP cookies for the failed 372 negotiation. 374 o Notification Data - SHOULD contain the offending payload 375 and the message ID associated with the payload. It MAY also 376 contain the error position offset, and error text describing 377 the problem. 379 3.3 SITUATION-NOT-SUPPORTED 381 The SITUATION-NOT-SUPPORTED error message may be used to communicate 382 that an unrecognized or unsupported situation value was received. 384 Phase: 1 or 2 385 Differentiator: Cookies vs SPI, Protocol ID, 386 offending payload, message ID 387 Payloads: SA 389 When present, the Notification Payload MUST have the following 390 format: 392 o Payload Length - set to length of payload + size of data 393 o DOI - set to ISAKMP DOI 394 o Protocol ID - set to zero (0) 395 o SPI Size - set to either zero (0) or sixteen (16) 396 o Notify Message Type - set to SITUATION-NOT-SUPPORTED 397 o SPI - set to empty or to the ISAKMP cookies for the failed 398 negotiation. 399 o Notification Data - SHOULD contain the offending payload 400 and the message ID associated with the payload. It MAY also 401 contain the error position offset, and error text describing 402 the problem. 404 3.4 INVALID-COOKIE 406 The INVALID-COOKIE error message may be used to communicate that an 407 invalid ISAKMP cookie was received. Invalid cookies are those cookies 408 for which there is no matching SA. This message applies to a few 409 different situations: 411 o one of the cookies in the pair is not valid 412 o neither of the cookies in the pair are valid 414 Phase: 1 or 2 415 Differentiator: Cookies, message ID 416 invalid cookie(s) in SPI field 417 Payloads: ISAKMP header 419 When present, the Notification Payload MUST have the following 420 format: 422 o Payload Length - set to length of payload + size of data 423 o DOI - set to 0 (ISAKMP DOI) 424 o Protocol ID - set to PROTO_ISAKMP 425 o SPI Size - set to sixteen (16) 426 o Notify Message Type - set to INVALID-COOKIE 427 o SPI - set to the ISAKMP cookies for the failed negotiation. 428 o Notification Data - SHOULD contain the message ID of the 429 offending negotiation, and MAY contain error text describing 430 the problem. 432 3.5 INVALID-MAJOR-VERSION 434 The INVALID-MAJOR-VERSION error message may be used to communicate 435 that this portion of the ISAKMP version is invalid or unsupported. 437 Phase: 1 or 2 438 Differentiator: Cookies, message ID 439 invalid version 440 Payloads: ISAKMP header 442 When present, the Notification Payload MUST have the following 443 format: 445 o Payload Length - set to length of payload + size of data 446 o DOI - set to 0 (ISAKMP DOI) 447 o Protocol ID - set to PROTO_ISAKMP 448 o SPI Size - set to sixteen (16) 449 o Notify Message Type - set to INVALID-MAJOR-VERSION 450 o SPI - set to the ISAKMP cookies for the failed negotiation. 451 o Notification Data - SHOULD contain the message ID of the 452 offending negotiation, and MAY contain error text describing 453 the problem. 455 3.6 INVALID-MINOR-VERSION 457 The INVALID-MINOR-VERSION error message may be used to communicate 458 that this portion of the ISAKMP version is invalid or unsupported. 460 Phase: 1 or 2 461 Differentiator: Cookies, message ID, 462 invalid version 463 Payloads: ISAKMP header 465 When present, the Notification Payload MUST have the following 466 format: 468 o Payload Length - set to length of payload + size of data 469 o DOI - set to 0 (ISAKMP DOI) 470 o Protocol ID - set to PROTO_ISAKMP 471 o SPI Size - set to sixteen (16) 472 o Notify Message Type - set to INVALID-MINOR-VERSION 473 o SPI - set to the ISAKMP cookies for the failed negotiation. 474 o Notification Data - SHOULD contain the message ID of the 475 offending negotiation, and MAY contain error text describing 476 the problem. 478 3.7 INVALID-EXCHANGE-TYPE 480 The INVALID-EXCHANGE-TYPE error message may be used to communicate 481 that that an unrecognized or invalid ISAKMP exchange type was 482 received. 484 Phase: 1 or 2 485 Differentiator: Cookies, message ID 486 invalid exchange type in notify data 487 Payloads: ISAKMP header 489 When present, the Notification Payload MUST have the following 490 format: 492 o Payload Length - set to length of payload + size of data 493 o DOI - set to 0 (ISAKMP DOI) 494 o Protocol ID - set to PROTO_ISAKMP 495 o SPI Size - set to sixteen (16) 496 o Notify Message Type - set to INVALID-EXCHANGE-TYPE 497 o SPI - set to the ISAKMP cookies for the failed negotiation. 498 o Notification Data - SHOULD contain the message ID of the 499 offending negotiation and the invalid exchange type, and MAY 500 contain error text describing the problem. 502 3.8 INVALID-FLAGS 504 The INVALID-FLAGS error message may be used to communicate that one 505 or more of the received ISAKMP header flags were unrecognized or 506 invalid. Cases where flags are invalid include the following: 508 o The encryption bit is unset/set when it should/shouldn't be 509 o The commit bit is unset/set when it should/shouldn't be 510 o The auth-only bit is unset/set when it should/shouldn't be 511 Phase: 1 or 2 512 Differentiator: Cookies, message ID 513 invalid flags 514 Payloads: ISAKMP header 516 When present, the Notification Payload MUST have the following 517 format: 519 o Payload Length - set to length of payload + size of data 520 o DOI - set to 0 (ISAKMP DOI) 521 o Protocol ID - set to PROTO_ISAKMP 522 o SPI Size - set to sixteen (16) 523 o Notify Message Type - set to INVALID-FLAGS 524 o SPI - set to the ISAKMP cookies for the failed negotiation. 525 o Notification Data - SHOULD contain the message ID of the 526 offending negotiation and the invalid exchange type, invalid 527 flags attribute having only the invalid flags bits set (i.e 528 valid bits are masked off), and MAY contain error text 529 describing the problem. 531 3.9 INVALID-MESSAGE-ID 533 The INVALID-MESSAGE-ID error message may be used to communicate that 534 the message ID in the received message is unrecognized or invalid. 536 Phase: 1 or 2 537 Differentiator: Cookies, message ID 538 Payloads: ISAKMP header 540 When present, the Notification Payload MUST have the following 541 format: 543 o Payload Length - set to length of payload + size of data 544 o DOI - set to 0 (ISAKMP DOI) 545 o Protocol ID - set to PROTO_ISAKMP 546 o SPI Size - set to sixteen (16) 547 o Notify Message Type - set to INVALID-MESSAGE-ID 548 o SPI - set to the ISAKMP cookies for the failed negotiation. 549 o Notification Data - SHOULD contain the message ID of the 550 offending negotiation, and MAY contain error text describing 551 the problem. 553 3.10 INVALID-PROTOCOL-ID 555 The INVALID-PROTOCOL-ID error message may be used to communicate that 556 an invalid or unsupported protocol ID was received as part of a 557 proposal payload. 559 Phase: 1 or 2 560 Differentiator: message ID, proposal payload 561 Payloads: Proposal 563 When present, the Notification Payload MUST have the following 564 format: 566 o Payload Length - set to length of payload + size of data 567 o DOI - set to DOI of received packet 568 o Protocol ID - set to PROTO_ISAKMP 569 o SPI Size - set to zero (0) 570 o Notify Message Type - set to INVALID-PROTOCOL-ID 571 o SPI - empty 572 o Notification Data - SHOULD contain the offending SA payload, 573 error offset position, and the message ID from the offending 574 negotiation. It MAY contain error text describing the problem. 576 3.11 INVALID-SPI 578 The INVALID-SPI error message may be used to communicate that an 579 invalid SPI was received as part of a proposal payload. 581 Phase: 1 or 2 582 Differentiator: Cookies, message ID, offending payload, protocol ID 583 Payloads: Proposal 585 When present, the Notification Payload MUST have the following 586 format: 588 o Payload Length - set to length of payload + size of data 589 o DOI - set to DOI of received packet 590 o Protocol ID - set to PROTO_ISAKMP, PROTO_IPSEC_ESP, 591 or PROTO_IPSEC_AH 592 o SPI Size - set to size of subject SPI 593 o Notify Message Type - set to INVALID-SPI 594 o SPI - set to the invalid SPI 595 o Notification Data - SHOULD contain the offending SA payload, 596 error offset position, and the message ID from the offending 597 negotiation. It MAY contain error text describing the problem. 599 3.12 INVALID-TRANSFORM-ID 601 The INVALID-TRANSFORM-ID error message may be used to communicate 602 that an invalid or unrecognized (unimplemented?) transform was 603 received as part of a proposal. 605 Phase: 1 or 2 606 Differentiator: Cookies, message ID, SPI 607 Payloads: Transform 609 When present, the Notification Payload MUST have the following 610 format: 612 o Payload Length - set to length of payload + size of data 613 o DOI - set to DOI of received packet 614 o Protocol ID - set to PROTO_ISAKMP 615 o SPI Size - set to zero (0) 616 o Notify Message Type - set to INVALID-TRANSFORM-ID 617 o SPI - empty 618 o Notification Data - SHOULD contain the offending SA payload, 619 error offset position, and the message ID from the offending 620 negotiation. It MAY contain error text describing the problem. 622 3.13 ATTRIBUTES-NOT-SUPPORTED 624 The ATTRIBUTES-NOT-SUPPORTED error message may be used to communicate 625 that unrecognized or unsupported attributes were received as part of 626 a proposal. Currently, this message may result from one of the 627 following events: 629 o unacceptable group in IKE new-group-mode negotiation 630 o conflicting lifetime attributes are detected 631 o invalid or unsupported SA attributes are received 633 Phase: 1 or 2 634 Differentiator: Cookies, message ID, SPI, attributes 635 Payloads: SA 637 When present, the Notification Payload MUST have the following 638 format: 640 o Payload Length - set to length of payload + size of data 641 o DOI - set to DOI of received packet 642 o Protocol ID - set to selected Protocol ID from subject SA 643 o SPI Size - set to either zero (0) or four (4)(one IPSEC SPI) 644 o Notify Message Type - set to ATTRIBUTES-NOT-SUPPORTED 645 o SPI - set to empty or to the target entity's IPSec SPI; 646 if present, the SPI MUST be from the same proposal payload 647 contains the offending transform. 648 o Notification Data - SHOULD contain the offending SA payload, 649 error offset position, and the message ID from the offending 650 negotiation. It MAY contain error text describing the problem. 652 3.14 NO-PROPOSAL-CHOSEN 654 The NO-PROPOSAL-CHOSEN error message may be used to communicate that 655 none of the received proposals are acceptable to the responder. 657 Phase: 1 or 2 658 Differentiator: Cookies, message ID 659 Payloads: SA 661 When present, the Notification Payload MUST have the following 662 format: 663 o Payload Length - set to length of payload + size of data (4) 664 o DOI - set to DOI of received packet 665 o Protocol ID - set to selected Protocol ID from subject SA 666 o SPI Size - set to sixteen (16) 667 o Notify Message Type - set to NO-PROPOSAL-CHOSEN 668 o SPI - set to ISAKMP cookies 669 o Notification Data - SHOULD contain the message ID of the 670 offending negotiation, and MAY contain error text describing 671 the problem. MAY also contain a proposal suggestion. 673 3.15 BAD-PROPOSAL-SYNTAX 675 The BAD-PROPOSAL-SYNTAX error message may be used to communicate that 676 a received proposal is improperly formed. This message may be 677 precipitated by the following events (among others): 679 o a reserved field in a proposal payload does not 680 contain zero (0) 681 o a reserved field in a transform payload does not 682 contain zero (0) 683 o responder returns SA payload containing multiple proposals 684 o responder returns multiple (or no) transforms 685 o initiator attempts to negotiate multiple quick mode SAs 686 but responder only answers to one of them. 688 Phase: 1 or 2 689 Differentiator: Cookies, message ID, proposal/transform payload 690 Payloads: Generic Payload Header, Proposal, Transform 692 When present, the Notification Payload MUST have the following 693 format: 695 o Payload Length - set to length of payload + size of data 696 o DOI - set to DOI of received packet 697 o Protocol ID - set to PROTO_ISAKMP 698 o SPI Size - set to zero (0) or sixteen (16) 699 o Notify Message Type - set to BAD-PROPOSAL-SYNTAX 700 o SPI - empty or ISAKMP cookies 701 o Notification Data - SHOULD contain the offending SA payload, 702 error offset position, and the message ID from the offending 703 negotiation. It MAY contain error text describing the problem. 705 [Note: There's an ambiguity here due to overloading this error 706 type. It would be resolved by adding a BAD-TRANSFORM-SYNTAX 707 error, and only using this one for proposals. Alternatively, 708 we could add an identifier to this message to distinguish 709 between the two cases] 711 3.16 PAYLOAD-MALFORMED 713 The PAYLOAD-MALFORMED error message may be used to communicate that a 714 malformed payload was received. This includes proposals, transforms, 715 or attributes that are syntactically incorrect. 717 Phase: 1 or 2 718 Differentiator: Cookies, message ID, malformed payload 719 Payloads: Generic Payload Header, Proposal, Transform 721 When present, the Notification Payload MUST have the following 722 format: 724 o Payload Length - set to length of payload + size of data 725 o DOI - set to ISAKMP DOI (0) 726 o Protocol ID - set to selected Protocol ID from subject SA if 727 available, else set to protocol PROTO_ISAKMP 728 o SPI Size - set to zero (0), two (2), four (4) or sixteen (16) 729 o Notify Message Type - set to PAYLOAD-MALFORMED 730 o SPI - If protocol ID is PROTO_ISAKMP, contains the cookies; 731 otherwise, contains SPI associated with Protocol ID if 732 applicable, or nothing. 733 o Notification Data - SHOULD contain the type of the offending 734 payload, the payload data, the error position offset, and the 735 message ID of the offending negotiation. It MAY contain error 736 text describing the problem. 738 [Note: This overlaps with BAD-PROPOSAL-SYNTAX...] 740 3.17 INVALID-KEY-INFORMATION 742 The INVALID-KEY-INFORMATION error message may be used to communicate 743 that the key exchange payload is not the correct size. 745 Phase: 1 or 2 746 Differentiator: Cookies, message ID, KE payload 747 Payloads: Key Exchange 749 When present, the Notification Payload MUST have the following 750 format: 752 o Payload Length - set to length of payload + size of data 753 o DOI - set to ISAKMP DOI (0) 754 o Protocol ID - set to selected Protocol ID from subject SA if 755 available, else set to protocol PROTO_ISAKMP 756 o SPI Size - set to zero (0), two (2), four (4) or sixteen (16) 757 o Notify Message Type - set to INVALID-KEY-INFORMATION 758 o SPI - If protocol ID is PROTO_ISAKMP, contains the cookies; 759 otherwise, contains SPI associated with Protocol ID if 760 applicable, or nothing. 761 o Notification Data - SHOULD contain the offending payload, the 762 error position offset, and the message ID of the offending 763 negotiation. It MAY contain error text describing the problem. 765 3.18 INVALID-ID-INFORMATION 767 The INVALID-ID-INFORMATION error message may be used to communicate 768 that the identification type of the ID payload is not supported. 770 Phase: 1 or 2 771 Differentiator: Cookies, message ID, SPI, ID payload 772 Payloads: ID 774 When present, the Notification Payload MUST have the following 775 format: 777 o Payload Length - set to length of payload + size of data 778 o DOI - set to DOI of received packet 779 o Protocol ID - set to selected Protocol ID from subject SA if 780 phase 2, else set to protocol PROTO_ISAKMP 781 o SPI Size - set to zero (0), two (2), four (4) or sixteen (16) 782 o Notify Message Type - set to INVALID-ID-INFORMATION 783 o SPI - If protocol ID is PROTO_ISAKMP, contains the cookies; 784 otherwise, contains SPI associated with Protocol ID if 785 applicable, or nothing. 786 o Notification Data - SHOULD contain the offending payload, the 787 error position offset, and the message ID of the offending 788 negotiation. It MAY contain error text describing the problem. 790 3.19 INVALID-CERT-ENCODING 791 The INVALID-CERT-ENCODING error message may be used to communicate 792 that the encoding of a received certificate payload is not valid. 794 Phase: 1 or 2 795 Differentiator: Cookies, message ID, SPI, CERT payload 796 Payloads: Certificate, Certificate Request 798 When present, the Notification Payload MUST have the following 799 format: 801 o Payload Length - set to length of payload + size of data 802 o DOI - set to DOI of received packet 803 o Protocol ID - set to PROTO_ISAKMP 804 o SPI Size - set to either zero (0) or sixteen (16) 805 o Notify Message Type - set to INVALID-CERT-ENCODING 806 o SPI - set to empty or to the ISAKMP cookies 807 o Notification Data - SHOULD contain the offending certificate 808 payload, error position offset, and Message ID. It MAY contain 809 error text describing the problem. 811 3.20 INVALID-CERTIFICATE 813 The INVALID-CERTIFICATE error message may be used to communicate that 814 the data in a certificate payload is invalid or improperly formatted. 816 Phase: 1 or 2 817 Differentiator: Cookies, message ID, SPI, CERT payload 818 Payloads: Certificate 820 When present, the Notification Payload MUST have the following 821 format: 823 o Payload Length - set to length of payload + size of data 824 o DOI - set to DOI of received packet 825 o Protocol ID - set to PROTO_ISAKMP 826 o SPI Size - set to either zero (0) or sixteen (16) 827 o Notify Message Type - set to INVALID-CERTIFICATE 828 o SPI - set to empty or to the ISAKMP cookies 829 o Notification Data - SHOULD contain the offending certificate 830 payload, error position offset, and Message ID. It MAY contain 831 error text describing the problem. 833 3.21 CERT-TYPE-UNSUPPORTED 835 The CERT-TYPE-UNSUPPORTED error message may be used to communicate 836 that the encoding of a received certificate payload is not supported. 838 Phase: 1 or 2 839 Differentiator: Cookies, message ID, SPI, CERT payload 840 Payloads: Certificate Request 842 When present, the Notification Payload MUST have the following 843 format: 845 o Payload Length - set to length of payload + size of data 846 o DOI - set to DOI of received packet 847 o Protocol ID - set to PROTO_ISAKMP 848 o SPI Size - set to either zero (0) or sixteen (16) 849 o Notify Message Type - set to CERT-TYPE-UNSUPPORTED 850 o SPI - set to empty or to the ISAKMP cookies 851 o Notification Data - SHOULD contain the offending certificate 852 request payload, error position offset, and Message ID. It 853 MAY contain error text describing the problem. 855 3.22 INVALID-CERT-AUTHORITY 857 The INVALID-CERT-AUTHORITY error message may be used to communicate 858 that the Certificate Authority in a certificate request payload is 859 invalid or improperly formatted. 861 Phase: 1 862 Differentiator: Cookies, message ID, SPI, CERT-REQ payload 863 Payloads: Certificate Request 865 When present, the Notification Payload MUST have the following 866 format: 868 o Payload Length - set to length of payload + size of data 869 o DOI - set to DOI of received packet 870 o Protocol ID - set to PROTO_ISAKMP 871 o SPI Size - set to either zero (0) or sixteen (16) 872 o Notify Message Type - set to INVALID-CERT-AUTHORITY 873 o SPI - set to empty or to the ISAKMP cookies 874 o Notification Data - SHOULD contain the offending certificate 875 request payload, error position offset, and Message ID. It 876 MAY contain error text describing the problem. 878 3.23 INVALID-HASH-INFORMATION 880 The INVALID-HASH-INFORMATION error message may be used to communicate 881 that that the hash size is incorrect. 883 Phase: 1 or 2 884 Differentiator: Cookies, message ID, SPI, hash payload 885 Payloads: Hash 887 When present, the Notification Payload MUST have the following 888 format: 890 o Payload Length - set to length of payload + size of data 891 o DOI - set to DOI of received packet 892 o Protocol ID - set to selected Protocol ID from chosen SA or 893 PROTO_ISAKMP 894 o SPI Size - set to either zero (0), four (4), or sixteen (16) 895 o Notify Message Type - set to INVALID-HASH-INFORMATION 896 o SPI - set to empty, the target entity's IPSec SPI, or the 897 ISAKMP cookies 898 o Notification Data - SHOULD contain the offending hash payload 899 error position offset, and Message ID. It MAY contain error 900 text describing the problem. 902 3.24 AUTHENTICATION-FAILED 904 The AUTHENTICATION-FAILED error message may be used to communicate 905 that that the authentication operation (hash) produced an incorrect 906 result. 908 Phase: 1 or 2 909 Differentiator: Cookies, message ID, SPI 910 Payloads: Hash, Signature 912 When present, the Notification Payload MUST have the following 913 format: 915 o Payload Length - set to length of payload + size of data 916 o DOI - set to DOI of received packet 917 o Protocol ID - set to selected Protocol ID from chosen SA or 918 PROTO_ISAKMP 919 o SPI Size - set to either zero (0), four (4), or sixteen (16) 920 o Notify Message Type - set to AUTHENTICATION-FAILED 921 o SPI - set to empty, the target entity's IPSec SPI, or the 922 ISAKMP cookies 923 o Notification Data - SHOULD contain the Message ID of the 924 offending payload. It MAY contain error text describing the 925 problem. 927 3.25 INVALID-SIGNATURE 929 The INVALID-SIGNATURE error message may be used to communicate that 930 the signature is the wrong size. 932 NOTE: If signature verification fails, AUTHENTICATION-FAILED is sent. 934 Phase: 1 935 Differentiator: Cookies 936 Payloads: Signature 938 When present, the Notification Payload MUST have the following 939 format: 940 o Payload Length - set to length of payload + size of data 941 o DOI - set to DOI of received packet 942 o Protocol ID - set to PROTO_ISAKMP 943 o SPI Size - set to sixteen (16) 944 o Notify Message Type - set to INVALID-SIGNATURE 945 o SPI - set to the ISAKMP cookies 946 o Notification Data - SHOULD contain the offending ID payload and 947 the associated message ID. It MAY contain error text describing 948 the problem. 950 3.26 ADDRESS-NOTIFICATION 952 The ADDRESS-NOTIFICATION error message may be used to communicate 953 that an invalid address was received in the ID payload. 955 Phase: 1 or 2 956 Differentiator: Cookies, message ID, SPI, address info? 957 Payloads: ID 959 When present, the Notification Payload MUST have the following 960 format: 962 o Payload Length - set to length of payload + size of data 963 o DOI - set to DOI of received packet 964 o Protocol ID - set to selected Protocol ID from chosen SA or 965 PROTO_ISAKMP 966 o SPI Size - set to either zero (0), four (4), or sixteen (16) 967 o Notify Message Type - set to ADDRESS-NOTIFICATION 968 o SPI - set to empty, the target entity's IPSec SPI, or the 969 ISAKMP cookies 970 o Notification Data - SHOULD contain the offending ID payload and 971 the associated message ID. It MAY contain error text describing 972 the problem. 974 3.27 NOTIFY-SA-LIFETIME 975 The NOTIFY-SA-LIFETIME message may be used to communicate that a 976 lifetime attribute list is incorrectly formatted. I.e. only life type 977 attribute but no life duration etc. 979 Phase: 1 980 Differentiator: Cookies, message ID 981 Payloads: Transform 983 When present, the Notification Payload MUST have the following 984 format: 986 o Payload Length - set to length of payload + size of data 987 o DOI - set to DOI of received packet 988 o Protocol ID - set to selected Protocol ID from chosen SA 989 o SPI Size - set to four (4) or sixteen (16) 990 o Notify Message Type - set to NOTIFY-SA-LIFETIME 991 o SPI - set to the target entity's IPSec SPI, or the 992 ISAKMP cookies 993 o Notification Data - SHOULD contain the offending payload 994 and the message ID associated with the payload. It MAY also 995 contain the error position offset, and error text describing 996 the problem. 998 3.28 CERTIFICATE-UNAVAILABLE 1000 The CERTIFICATE-UNAVAILABLE error message may be used to communicate 1001 that the requested certificate is unavailable. 1003 Phase: 1 or 2 1004 Differentiator: Cookies, message ID, SPI, CERT-REQ payload 1005 Payloads: Certificate Request 1007 When present, the Notification Payload MUST have the following 1008 format: 1010 o Payload Length - set to length of payload + size of data 1011 o DOI - set to DOI of received packet 1012 o Protocol ID - set to PROTO_ISAKMP 1013 o SPI Size - set to zero (0) or sixteen (16) 1014 o Notify Message Type - set to CERTIFICATE-UNAVAILABLE 1015 o SPI - set to empty or to the ISAKMP cookies 1016 o Notification Data - SHOULD contain the subject certificate 1017 request payload and the associated message ID. MAY contain 1018 error text describing the problem. 1020 3.29 UNSUPPORTED-EXCHANGE-TYPE 1021 The UNSUPPORTED-EXCHANGE-TYPE error message may be used to 1022 communicate that the requested exchange type is not supported. 1024 Phase: 1 or 2 1025 Differentiator: Cookies, message ID, SPI, exchange type 1026 Payloads: ISAKMP header 1028 When present, the Notification Payload MUST have the following 1029 format: 1031 o Payload Length - set to length of payload + size of data 1032 o DOI - set to 0 1033 o Protocol ID - set to PROTO_ISAKMP 1034 o SPI Size - set to sixteen (16) 1035 o Notify Message Type - set to UNSUPPORTED-EXCHANGE-TYPE 1036 o SPI - set to ISAKMP cookies 1037 o Notification Data - SHOULD contain the message ID of the 1038 offending negotiation and the offending exchange type. MAY 1039 contain error text describing the problem. 1041 3.30 UNEQUAL-PAYLOAD-LENGTHS 1043 The UNEQUAL-PAYLOAD-LENGTHS error message may be used to communicate 1044 that the message length in the ISAKMP header does not match the sum 1045 of the actual payload lengths. It may also be used when data 1046 attributes overflow their encapsulating payload boundaries. 1048 Phase: 1 or 2 1049 Differentiator: Cookies, message ID, SPI 1051 When present, the Notification Payload MUST have the following 1052 format: 1054 o Payload Length - set to length of payload + size of data 1055 o DOI - set to DOI of received packet or zero (0) 1056 o Protocol ID - set to PROTO_ISAKMP or selected Protocol ID 1057 from chosen SA 1058 o SPI Size - set to four (4) or (16) 1059 o Notify Message Type - set to UNEQUAL-PAYLOAD-LENGTHS 1060 o SPI - set to the target entity's IPSec SPI or the ISAKMP cookies 1061 o Notification Data - SHOULD contain the type of the offending 1062 payload. It MAY contain the offending payload, the associated 1063 message ID, the error position offset, and error text describing 1064 the problem. 1066 4. ISAKMP Notify Status messages 1067 This section contains NOTIFY status messages which are specific to 1068 ISAKMP, or phase 1 Security Associations (SAs). These NOTIFY message 1069 types are defined in [RFC2408]. 1071 4.1 CONNECTED 1073 The CONNECTED status message may be used to communicate that the 1074 IPSEC protocol (phase 2) SA has been established. 1076 When present, the Notification Payload MUST have the following 1077 format: 1079 o Payload Length - set to length of payload + size of data 1080 o DOI - set to DOI of received packet 1081 o Protocol ID - set to PROTO_ISAKMP or selected Protocol ID 1082 from chosen SA 1083 o SPI Size - set to zero (0), four (4) or sixteen (16) 1084 o Notify Message Type - set to CONNECTED 1085 o SPI - set to the selected SPI 1086 o Notification Data - empty 1088 4.2 RESPONDER-LIFETIME 1090 The RESPONDER-LIFETIME message may be used to communicate that a 1091 lifetime which is shorter than the one requested will be enforced. 1092 This notification is defined in the DOI, and is included here only 1093 because it does NOT follow the notification data formatting 1094 specifications defined in this document. 1096 Phase: 1 or 2 1097 Differentiator: Cookies, message ID, 1098 Payloads: Transform 1100 When present, the Notification Payload MUST have the following 1101 format: 1103 o Payload Length - set to length of payload + size of data 1104 o DOI - set to DOI of received packet 1105 o Protocol ID - set to selected Protocol ID from chosen SA 1106 o SPI Size - set to four (4) or sixteen (16) 1107 o Notify Message Type - set to RESPONDER-LIFETIME 1108 o SPI - set to the target entity's IPSec SPI, or the 1109 ISAKMP cookies 1110 o Notification Data - contains an ISAKMP attribute list with the 1111 responder's actual SA lifetime 1113 WARNING: the attribute classes for the ISAKMP attribute list are 1114 defined in the ISAKMP DOI document (RFC2407). This message type is 1115 included here for completeness. 1117 4.3 REPLAY-STATUS 1119 The REPLAY-STATUS message may be used for positive confirmation of 1120 the responder's election on whether or not he is to perform anti- 1121 replay detection. This notification is defined in the DOI, and is 1122 included here only because it does NOT follow the notification data 1123 formatting specifications defined in this document. 1125 Phase: 2 1126 Differentiator: Cookies vs SPI 1127 Payloads: Transform 1129 When present, the Notification Payload MUST have the following 1130 format: 1132 o Payload Length - set to length of payload + size of data 1133 o DOI - set to DOI of received packet 1134 o Protocol ID - set to selected Protocol ID from chosen SA 1135 o SPI Size - set to four (4) or sixteen (16) 1136 o Notify Message Type - set to REPLAY-STATUS 1137 o SPI - set to the target entity's IPSec SPI, or the 1138 ISAKMP cookies 1139 o Notification Data - a 4 octet value: 1140 0 = replay detection disabled 1141 1 = replay detection enabled 1143 WARNING: This message type is defined in the ISAKMP DOI document 1144 (RFC2407). This message type is included here for completeness. 1146 4.4 INITIAL-CONTACT 1148 The INITIAL-CONTACT status message may be used when one side wishes 1149 to inform the other that this is the first SA being established with 1150 the remote system. This notification is defined in the DOI, and is 1151 included here only because it does NOT follow the notification data 1152 formatting specifications defined in this document. 1154 Phase: 1 1155 Differentiator: Cookies 1156 Payloads: None 1158 When present, the Notification Payload MUST have the following 1159 format: 1161 o Payload Length - set to length of payload + size of data 1162 o DOI - set to DOI of received packet 1163 o Protocol ID - set to selected Protocol ID from chosen SA 1164 o SPI Size - sixteen (16) 1165 o Notify Message Type - set to INITIAL-CONTACT 1166 o SPI - set to ISAKMP cookies 1167 o Notification Data - 1169 WARNING: This message type is defined in the ISAKMP DOI document 1170 (RFC2407). This message type is included here for completeness. 1172 5. Security Considerations 1174 In general, accepting unauthenticated NOTIFY messages renders an 1175 implementation susceptible to numerous attacks, both passive and 1176 active. In such cases, there is no assurance whatsoever that these 1177 messages are not being sent by an attacker intent upon mounting a 1178 simple denial of service attack, or perhaps a more sophisticated 1179 attack. Hence, applications MUST NOT rely upon information provided 1180 by such unprotected exchanges. 1182 Furthermore, the inclusion of variable notification payloads within 1183 unprotected messages presents a significant denial of service 1184 opportunity to a hostile adversary. Thus, implementations which 1185 choose to inspect unprotected notification data are well advised to 1186 limit the amount of processing expended upon such packets. 1188 In cases where received payloads are copied into notification data, 1189 if the original payload was encrypted, the resulting notify message 1190 MUST be encrypted with at least the same level of protection that the 1191 original payload had. Otherwise, numerous attacks are possible. 1193 6. Editors' Addresses 1195 Scott Kelly 1196 RedCreek Communications 1197 3900 Newpark Mall Road 1198 Newark, CA 94560 1199 USA 1200 email: skelly@redcreek.com 1201 Telephone: +1 (510) 745-3969 1203 Tero Kivinen 1204 SSH Communications Security Corp 1205 Fredrikinkatu 42 1206 FIN-00100 HELSINKI 1207 Finland 1208 E-mail: kivinen@ssh.fi 1209 The IPSec working group can be contacted via the IPSec working 1210 group's mailing list (ipsec@lists.tislabs.com) or through its chairs: 1212 Robert Moskowitz 1213 rgm@icsa.net 1214 International Computer Security Association 1216 Theodore Y. Ts'o 1217 tytso@MIT.EDU 1218 Massachusetts Institute of Technology 1220 7. References 1222 [RFC2401] Kent, S., and R. Atkinson, "Security Architecture for the 1223 Internet Protocol", RFC 2401, November 1998. 1225 [RFC2402] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 1226 2402, November 1998. 1228 [RFC2406] Kent, S., and R. Atkinson, "IP Encapsulating Security 1229 Payload (ESP)", RFC 2406, November 1998. 1231 [RFC2407] Piper, D., "The Internet IP Security Domain of 1232 Interpretation for ISAKMP", RFC 2407, November 1998. 1234 [RFC2408] Maughhan, D., Schertler, M., Schneider, M., and J. Turner, 1235 "Internet Security Association and Key Management Protocol 1236 (ISAKMP)", RFC 2408, November 1998. 1238 [RFC2409] Harkins, D., and D. Carrel, "The Internet Key Exchange 1239 (IKE)", RFC 2409, November 1998. 1241 [RFC-2119] Bradner, S., "Key Words for use in RFCs to Indicate 1242 Requirement Levels", BCP 14, RFC 2119, March 1997. 1244 8. Acknowledgements 1246 The editors would like to acknowledge all the helpful comments received 1247 from numerous members of the IPSec working group, including S. Frankel 1248 of NIST, T. Zegman of Checkpoint, D. Mason of Network Associates, V. 1249 Smyslov of Trustworks, and A. Potluri of TRI. 1251 9. Full Copyright Statement 1253 Copyright (C) The Internet Society (1998). All Rights Reserved. 1255 This document and translations of it may be copied and furnished to 1256 others, and derivative works that comment on or otherwise explain it 1257 or assist in its implementation may be prepared, copied, published 1258 and distributed, in whole or in part, without restriction of any 1259 kind, provided that the above copyright notice and this paragraph 1260 are included on all such copies and derivative works. However, this 1261 document itself may not be modified in any way, such as by removing 1262 the copyright notice or references to the Internet Society or other 1263 Internet organizations, except as needed for the purpose of 1264 developing Internet standards in which case the procedures for 1265 copyrights defined in the Internet Standards process must be 1266 followed, or as required to translate it into languages other than 1267 English. 1269 The limited permissions granted above are perpetual and will not be 1270 revoked by the Internet Society or its successors or assigns. 1272 This document and the information contained herein is provided on an 1273 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1274 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1275 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1276 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1277 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.