its legal values. Section 4.5 of this document provides an example
of such a description.
The values 32001-32767 are reserved for private use amongst
cooperating systems.
6.8 IPSEC Labeled Domain Identifiers
The IPSEC Labeled Domain Identifier is a 32-bit value which
identifies a namespace in which the Secrecy and Integrity levels and
categories values are said to exist. Requests for assignments of new
IPSEC Labeled Domain Identifiers should be granted on demand. No
accompanying documentation is required, though Internet Drafts are
encouraged when appropriate.
The values 0x80000000-0xffffffff are reserved for private use amongst
cooperating systems.
6.9 IPSEC Identification Type
The IPSEC Identification Type is an 8-bit value which is used as a
discriminant for interpretation of the variable-length Identification
Payload. Requests for assignments of new IPSEC Identification Types
must be accompanied by an RFCwhich describes how to use the
identification type within IPSEC.
If the RFCis not on the standards-track (i.e., it is an
informational or experimental RFC), it must be explicitly reviewed
and approved by the IESG before the RFCis published and the
transform identifier is assigned.
The values 249-255 are reserved for private use amongst cooperating
systems.
6.10 IPSEC Notify Message Types
The IPSEC Notify Message Type is a 16-bit value taken from the range
of values reserved by ISAKMP for each DOI. There is one range for
error messages (8192-16383) and a different range for status messages
(24576-32767). Requests for assignments of new Notify Message Types
must be accompanied by an Internet Draft which describes how to use
the identification type within IPSEC.
The values 16001-16383 and the values 32001-32767 are reserved for
private use amongst cooperating systems.
7. Change Log
7.1 Changes from V9
o add explicit reference to [IPCOMP], [DEFLATE], and [LZS]
o allow RESPONDER-LIFETIME and REPLAY-STATUS to be directed
at an IPSEC SPI in addition to the ISAKMP "SPI"
o added padding exclusion to Secrecy and Integrity Length text
o added forward reference to Section 4.5 in Section 4.4.4
o update document references
7.2 Changes from V8
o update IPCOMP identifier range to better reflect IPCOMP draft
o update IANA considerations per Jeff/Ted's suggested text
o eliminate references to DES-MAC ID ([DESMAC])
o correct bug in Notify section; ISAKMP Notify values are 16-bits
7.3 Changes from V7
o corrected name of IPCOMP (IP Payload Compression)
o corrected references to [ESPCBC]
o added missing Secrecy Level and Integrity Level to Figure 1
o removed ID references to PF_KEY and ARCFOUR
o updated Basic/Variable text to align with [IKE]
o updated document references and add intro pointer to [ARCH]
o updated Notification requirements; remove aggressive reference
o added clarification about protection for Notify payloads
o restored RESERVED to ESP transform ID namespace; moved ESP_NULL
o added requirement for ESP_NULL support and [ESPNULL] reference
o added clarification on Auth Alg use with AH/ESP
o added restriction against using conflicting AH/Auth combinations
7.4 Changes from V6
The following changes were made relative to the IPSEC DOI V6:
o added IANA Considerations section
o moved most IANA numbers to IANA Considerations section
o added prohibition on sending (V) encoding for (B) attributes
o added prohibition on sending Key Length attribute for fixed
length ciphers (e.g. DES)
o replaced references to ISAKMP/Oakley with IKE
o renamed ESP_ARCFOUR to ESP_RC4
o updated Security Considerations section
o updated document references
7.5 Changes from V5
The following changes were made relative to the IPSEC DOI V5:
o changed SPI size in Lifetime Notification text
o changed REPLAY-ENABLED to REPLAY-STATUS
o moved RESPONDER-LIFETIME payload definition from Section 4.5.4
to Section 4.6.3.1
o added explicit payload layout for 4.6.3.3
o added Implementation Note to Section 4.6.3 introduction
o changed AH_SHA text to require SHA-1 in addition to MD5
o updated document references
7.6 Changes from V4
The following changes were made relative to the IPSEC DOI V4:
o moved compatibility AH KPDK authentication method from AH
transform ID to Authentication Algorithm identifier
o added REPLAY-ENABLED notification message type per Architecture
o added INITIAL-CONTACT notification message type per list
o added text to ensure protection for Notify Status messages
o added Lifetime qualification to attribute parsing section
o added clarification that Lifetime notification is optional
o removed private Group Description list (now points at [IKE])
o replaced Terminology with pointer to RFC-2119
o updated HMAC MD5 and SHA-1 ID references
o updated Section 1 (Abstract)
o updated Section 4.4 (IPSEC Assigned Numbers)
o added restriction for ID port/protocol values for Phase I
7.7 Changes from V3 to V4
The following changes were made relative to the IPSEC DOI V3, that
was posted to the IPSEC mailing list prior to the Munich IETF:
o added ESP transform identifiers for NULL and ARCFOUR
o renamed HMAC Algorithm to Auth Algorithm to accommodate
DES-MAC and optional authentication/integrity for ESP
o added AH and ESP DES-MAC algorithm identifiers
o removed KEY_MANUAL and KEY_KDC identifier definitions
o added lifetime duration MUST follow lifetype attribute to
SA Life Type and SA Life Duration attribute definition
o added lifetime notification and IPSEC DOI message type table
o added optional authentication and confidentiality
restrictions to MAC Algorithm attribute definition
o corrected attribute parsing example (used obsolete attribute)
o corrected several Internet Draft document references
o added ID_KEY_ID per ipsec list discussion (18-Mar-97)
o removed Group Description default for PFS QM ([IKE] MUST)
Acknowledgments
This document is derived, in part, from previous works by Douglas
Maughan, Mark Schertler, Mark Schneider, Jeff Turner, Dan Harkins,
and Dave Carrel. Matt Thomas, Roy Pereira, Greg Carter, and Ran
Atkinson also contributed suggestions and, in many cases, text.
References
[AH] Kent, S., and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
[ARCH] Kent, S., and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC2401, November 1998.
[DEFLATE] Pereira, R., "IP Payload Compression Using DEFLATE", RFC
2394, August 1998.
[ESP] Kent, S., and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC2406, November 1998.
[ESPCBC] Pereira, R., and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC2451, November 1998.
[ESPNULL] Glenn, R., and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC2410, November 1998.
[DES] Madson, C., and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC2405, November 1998.
[HMACMD5] Madson, C., and R. Glenn, "The Use of HMAC-MD5 within ESP
and AH", RFC2403, November 1998.
[HMACSHA] Madson, C., and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC2404, November 1998.
[IKE] Harkins, D., and D. Carrel, D., "The Internet Key Exchange
(IKE)", RFC2409, November 1998.
[IPCOMP] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC2393, August
1998.
[ISAKMP] Maughan, D., Schertler, M., Schneider, M., and J. Turner,
"Internet Security Association and Key Management Protocol
(ISAKMP)", RFC2408, November 1998.
[LZS] Friend, R., and R. Monsour, "IP Payload Compression Using
LZS", RFC2395, August 1998.
[OAKLEY] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[X.501] ISO/IEC 9594-2, "Information Technology - Open Systems
Interconnection - The Directory: Models", CCITT/ITU
Recommendation X.501, 1993.
[X.509] ISO/IEC 9594-8, "Information Technology - Open Systems
Interconnection - The Directory: Authentication
Framework", CCITT/ITU Recommendation X.509, 1993.
Author's Address
Derrell Piper
Network Alchemy
1521.5 Pacific Ave
Santa Cruz, California, 95060
United States of America
Phone: +1 408 460-3822
EMail: ddp@network-alchemy.com
Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.