tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7296

 
 
 

Internet Key Exchange Protocol Version 2 (IKEv2)

Part 5 of 6, p. 99 to 124
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 99 
3.10.  Notify Payload

   The Notify payload, denoted N in this document, is used to transmit
   informational data, such as error conditions and state transitions,
   to an IKE peer.  A Notify payload may appear in a response message
   (usually specifying why a request was rejected), in an INFORMATIONAL
   exchange (to report an error not in an IKE request), or in any other
   message to indicate sender capabilities or to modify the meaning of
   the request.

Top      Up      ToC       Page 100 
   The Notify payload is defined as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Protocol ID  |   SPI Size    |      Notify Message Type      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                Security Parameter Index (SPI)                 ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Notification Data                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 16: Notify Payload Format

   o  Protocol ID (1 octet) - If this notification concerns an existing
      SA whose SPI is given in the SPI field, this field indicates the
      type of that SA.  For notifications concerning Child SAs, this
      field MUST contain either (2) to indicate AH or (3) to indicate
      ESP.  Of the notifications defined in this document, the SPI is
      included only with INVALID_SELECTORS, REKEY_SA, and
      CHILD_SA_NOT_FOUND.  If the SPI field is empty, this field MUST be
      sent as zero and MUST be ignored on receipt.

   o  SPI Size (1 octet) - Length in octets of the SPI as defined by the
      IPsec protocol ID or zero if no SPI is applicable.  For a
      notification concerning the IKE SA, the SPI Size MUST be zero and
      the field must be empty.

   o  Notify Message Type (2 octets) - Specifies the type of
      notification message.

   o  SPI (variable length) - Security Parameter Index.

   o  Notification Data (variable length) - Status or error data
      transmitted in addition to the Notify Message Type.  Values for
      this field are type specific (see below).

   The payload type for the Notify payload is forty-one (41).

Top      Up      ToC       Page 101 
3.10.1.  Notify Message Types

   Notification information can be error messages specifying why an SA
   could not be established.  It can also be status data that a process
   managing an SA database wishes to communicate with a peer process.

   The table below lists the notification messages and their
   corresponding values.  The number of different error statuses was
   greatly reduced from IKEv1 both for simplification and to avoid
   giving configuration information to probers.

   Types in the range 0 - 16383 are intended for reporting errors.  An
   implementation receiving a Notify payload with one of these types
   that it does not recognize in a response MUST assume that the
   corresponding request has failed entirely.  Unrecognized error types
   in a request and status types in a request or response MUST be
   ignored, and they should be logged.

   Notify payloads with status types MAY be added to any message and
   MUST be ignored if not recognized.  They are intended to indicate
   capabilities, and as part of SA negotiation, are used to negotiate
   non-cryptographic parameters.

   More information on error handling can be found in Section 2.21.

   The values in the following table are only current as of the
   publication date of RFC 4306, plus two error types added in this
   document.  Other values may have been added since then or will be
   added after the publication of this document.  Readers should refer
   to [IKEV2IANA] for the latest values.

   NOTIFY messages: error types              Value
   -------------------------------------------------------------------
   UNSUPPORTED_CRITICAL_PAYLOAD              1
       See Section 2.5.

   INVALID_IKE_SPI                           4
       See Section 2.21.

   INVALID_MAJOR_VERSION                     5
       See Section 2.5.

   INVALID_SYNTAX                            7
       Indicates the IKE message that was received was invalid because
       some type, length, or value was out of range or because the
       request was rejected for policy reasons.  To avoid a DoS
       attack using forged messages, this status may only be
       returned for and in an encrypted packet if the Message ID and

Top      Up      ToC       Page 102 
       cryptographic checksum were valid.  To avoid leaking information
       to someone probing a node, this status MUST be sent in response
       to any error not covered by one of the other status types.
       To aid debugging, more detailed error information should be
       written to a console or log.

   INVALID_MESSAGE_ID                        9
       See Section 2.3.

   INVALID_SPI                              11
       See Section 1.5.

   NO_PROPOSAL_CHOSEN                       14
       None of the proposed crypto suites was acceptable.  This can be
       sent in any case where the offered proposals (including but not
       limited to SA payload values, USE_TRANSPORT_MODE notify,
       IPCOMP_SUPPORTED notify) are not acceptable for the responder.
       This can also be used as "generic" Child SA error when Child SA
       cannot be created for some other reason.  See also Section 2.7.

   INVALID_KE_PAYLOAD                       17
       See Sections 1.2 and 1.3.

   AUTHENTICATION_FAILED                    24
       Sent in the response to an IKE_AUTH message when, for some
       reason, the authentication failed.  There is no associated
       data.  See also Section 2.21.2.

   SINGLE_PAIR_REQUIRED                     34
       See Section 2.9.

   NO_ADDITIONAL_SAS                        35
       See Section 1.3.

   INTERNAL_ADDRESS_FAILURE                 36
       See Section 3.15.4.

   FAILED_CP_REQUIRED                       37
       See Section 2.19.

   TS_UNACCEPTABLE                          38
       See Section 2.9.

Top      Up      ToC       Page 103 
   INVALID_SELECTORS                        39
       MAY be sent in an IKE INFORMATIONAL exchange when a node receives
       an ESP or AH packet whose selectors do not match those of the SA
       on which it was delivered (and that caused the packet to be
       dropped).  The Notification Data contains the start of the
       offending packet (as in ICMP messages) and the SPI field of the
       notification is set to match the SPI of the Child SA.

   TEMPORARY_FAILURE                        43
       See Section 2.25.

   CHILD_SA_NOT_FOUND                       44
       See Section 2.25.


   NOTIFY messages: status types            Value
   -------------------------------------------------------------------
   INITIAL_CONTACT                          16384
       See Section 2.4.

   SET_WINDOW_SIZE                          16385
       See Section 2.3.

   ADDITIONAL_TS_POSSIBLE                   16386
       See Section 2.9.

   IPCOMP_SUPPORTED                         16387
       See Section 2.22.

   NAT_DETECTION_SOURCE_IP                  16388
       See Section 2.23.

   NAT_DETECTION_DESTINATION_IP             16389
       See Section 2.23.

   COOKIE                                   16390
       See Section 2.6.

   USE_TRANSPORT_MODE                       16391
       See Section 1.3.1.

   HTTP_CERT_LOOKUP_SUPPORTED               16392
       See Section 3.6.

   REKEY_SA                                 16393
       See Section 1.3.3.

Top      Up      ToC       Page 104 
   ESP_TFC_PADDING_NOT_SUPPORTED            16394
       See Section 1.3.1.

   NON_FIRST_FRAGMENTS_ALSO                 16395
       See Section 1.3.1.

3.11.  Delete Payload

   The Delete payload, denoted D in this document, contains a
   protocol-specific Security Association identifier that the sender has
   removed from its Security Association database and is, therefore, no
   longer valid.  Figure 17 shows the format of the Delete payload.  It
   is possible to send multiple SPIs in a Delete payload; however, each
   SPI MUST be for the same protocol.  Mixing of protocol identifiers
   MUST NOT be performed in the Delete payload.  It is permitted,
   however, to include multiple Delete payloads in a single
   INFORMATIONAL exchange where each Delete payload lists SPIs for a
   different protocol.

   Deletion of the IKE SA is indicated by a protocol ID of 1 (IKE) but
   no SPIs.  Deletion of a Child SA, such as ESP or AH, will contain the
   IPsec protocol ID of that protocol (2 for AH, 3 for ESP), and the SPI
   is the SPI the sending endpoint would expect in inbound ESP or AH
   packets.

   The Delete payload is defined as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Protocol ID   |   SPI Size    |          Num of SPIs          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~               Security Parameter Index(es) (SPI)              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 17: Delete Payload Format

   o  Protocol ID (1 octet) - Must be 1 for an IKE SA, 2 for AH, or 3
      for ESP.

   o  SPI Size (1 octet) - Length in octets of the SPI as defined by the
      protocol ID.  It MUST be zero for IKE (SPI is in message header)
      or four for AH and ESP.

Top      Up      ToC       Page 105 
   o  Num of SPIs (2 octets, unsigned integer) - The number of SPIs
      contained in the Delete payload.  The size of each SPI is defined
      by the SPI Size field.

   o  Security Parameter Index(es) (variable length) - Identifies the
      specific Security Association(s) to delete.  The length of this
      field is determined by the SPI Size and Num of SPIs fields.

   The payload type for the Delete payload is forty-two (42).

3.12.  Vendor ID Payload

   The Vendor ID payload, denoted V in this document, contains a vendor-
   defined constant.  The constant is used by vendors to identify and
   recognize remote instances of their implementations.  This mechanism
   allows a vendor to experiment with new features while maintaining
   backward compatibility.

   A Vendor ID payload MAY announce that the sender is capable of
   accepting certain extensions to the protocol, or it MAY simply
   identify the implementation as an aid in debugging.  A Vendor ID
   payload MUST NOT change the interpretation of any information defined
   in this specification (i.e., the critical bit MUST be set to 0).
   Multiple Vendor ID payloads MAY be sent.  An implementation is not
   required to send any Vendor ID payload at all.

   A Vendor ID payload may be sent as part of any message.  Reception of
   a familiar Vendor ID payload allows an implementation to make use of
   private use numbers described throughout this document, such as
   private payloads, private exchanges, private notifications, etc.
   Unfamiliar Vendor IDs MUST be ignored.

   Writers of documents who wish to extend this protocol MUST define a
   Vendor ID payload to announce the ability to implement the extension
   in the document.  It is expected that documents that gain acceptance
   and are standardized will be given "magic numbers" out of the Future
   Use range by IANA, and the requirement to use a Vendor ID will go
   away.

Top      Up      ToC       Page 106 
   The Vendor ID payload fields are defined as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        Vendor ID (VID)                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 18: Vendor ID Payload Format

   o  Vendor ID (variable length) - It is the responsibility of the
      person choosing the Vendor ID to assure its uniqueness in spite of
      the absence of any central registry for IDs.  Good practice is to
      include a company name, a person name, or some such information.
      If you want to show off, you might include the latitude and
      longitude and time where you were when you chose the ID and some
      random input.  A message digest of a long unique string is
      preferable to the long unique string itself.

   The payload type for the Vendor ID payload is forty-three (43).

3.13.  Traffic Selector Payload

   The Traffic Selector payload, denoted TS in this document, allows
   peers to identify packet flows for processing by IPsec security
   services.  The Traffic Selector payload consists of the IKE generic
   payload header followed by individual Traffic Selectors as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Number of TSs |                 RESERVED                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       <Traffic Selectors>                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 19: Traffic Selectors Payload Format

   o  Number of TSs (1 octet) - Number of Traffic Selectors being
      provided.

Top      Up      ToC       Page 107 
   o  RESERVED - This field MUST be sent as zero and MUST be ignored on
      receipt.

   o  Traffic Selectors (variable length) - One or more individual
      Traffic Selectors.

   The length of the Traffic Selector payload includes the TS header and
   all the Traffic Selectors.

   The payload type for the Traffic Selector payload is forty-four (44)
   for addresses at the initiator's end of the SA and forty-five (45)
   for addresses at the responder's end.

   There is no requirement that TSi and TSr contain the same number of
   individual Traffic Selectors.  Thus, they are interpreted as follows:
   a packet matches a given TSi/TSr if it matches at least one of the
   individual selectors in TSi, and at least one of the individual
   selectors in TSr.

   For instance, the following Traffic Selectors:

   TSi = ((17, 100, 198.51.100.66-198.51.100.66),
          (17, 200, 198.51.100.66-198.51.100.66))
   TSr = ((17, 300, 0.0.0.0-255.255.255.255),
          (17, 400, 0.0.0.0-255.255.255.255))

   would match UDP packets from 198.51.100.66 to anywhere, with any of
   the four combinations of source/destination ports (100,300),
   (100,400), (200,300), and (200, 400).

   Thus, some types of policies may require several Child SA pairs.  For
   instance, a policy matching only source/destination ports (100,300)
   and (200,400), but not the other two combinations, cannot be
   negotiated as a single Child SA pair.

Top      Up      ToC       Page 108 
3.13.1.  Traffic Selector

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   TS Type     |IP Protocol ID*|       Selector Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Start Port*         |           End Port*           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Starting Address*                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                         Ending Address*                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 20: Traffic Selector

   *Note: All fields other than TS Type and Selector Length depend on
   the TS Type.  The fields shown are for TS Types 7 and 8, the only two
   values currently defined.

   o  TS Type (one octet) - Specifies the type of Traffic Selector.

   o  IP protocol ID (1 octet) - Value specifying an associated IP
      protocol ID (such as UDP, TCP, and ICMP).  A value of zero means
      that the protocol ID is not relevant to this Traffic Selector --
      the SA can carry all protocols.

   o  Selector Length (2 octets, unsigned integer) - Specifies the
      length of this Traffic Selector substructure including the header.

   o  Start Port (2 octets, unsigned integer) - Value specifying the
      smallest port number allowed by this Traffic Selector.  For
      protocols for which port is undefined (including protocol 0), or
      if all ports are allowed, this field MUST be zero.  ICMP and
      ICMPv6 Type and Code values, as well as Mobile IP version 6
      (MIPv6) mobility header (MH) Type values, are represented in this
      field as specified in Section 4.4.1.1 of [IPSECARCH].  ICMP Type
      and Code values are treated as a single 16-bit integer port
      number, with Type in the most significant eight bits and Code in
      the least significant eight bits.  MIPv6 MH Type values are
      treated as a single 16-bit integer port number, with Type in the
      most significant eight bits and the least significant eight bits
      set to zero.

Top      Up      ToC       Page 109 
   o  End Port (2 octets, unsigned integer) - Value specifying the
      largest port number allowed by this Traffic Selector.  For
      protocols for which port is undefined (including protocol 0), or
      if all ports are allowed, this field MUST be 65535.  ICMP and
      ICMPv6 Type and Code values, as well as MIPv6 MH Type values, are
      represented in this field as specified in Section 4.4.1.1 of
      [IPSECARCH].  ICMP Type and Code values are treated as a single
      16-bit integer port number, with Type in the most significant
      eight bits and Code in the least significant eight bits.  MIPv6 MH
      Type values are treated as a single 16-bit integer port number,
      with Type in the most significant eight bits and the least
      significant eight bits set to zero.

   o  Starting Address - The smallest address included in this Traffic
      Selector (length determined by TS Type).

   o  Ending Address - The largest address included in this Traffic
      Selector (length determined by TS Type).

   Systems that are complying with [IPSECARCH] that wish to indicate
   "ANY" ports MUST set the start port to 0 and the end port to 65535;
   note that according to [IPSECARCH], "ANY" includes "OPAQUE".  Systems
   working with [IPSECARCH] that wish to indicate "OPAQUE" ports, but
   not "ANY" ports, MUST set the start port to 65535 and the end port
   to 0.

   The Traffic Selector types 7 and 8 can also refer to ICMP or ICMPv6
   type and code fields, as well as MH Type fields for the IPv6 mobility
   header [MIPV6].  Note, however, that neither ICMP nor MIPv6 packets
   have separate source and destination fields.  The method for
   specifying the Traffic Selectors for ICMP and MIPv6 is shown by
   example in Section 4.4.1.3 of [IPSECARCH].

Top      Up      ToC       Page 110 
   The following table lists values for the Traffic Selector Type field
   and the corresponding Address Selector Data.  The values in the
   following table are only current as of the publication date of
   RFC 4306.  Other values may have been added since then or will be
   added after the publication of this document.  Readers should refer
   to [IKEV2IANA] for the latest values.

   TS Type                            Value
   -------------------------------------------------------------------
   TS_IPV4_ADDR_RANGE                  7

       A range of IPv4 addresses, represented by two four-octet
       values.  The first value is the beginning IPv4 address
       (inclusive) and the second value is the ending IPv4 address
       (inclusive).  All addresses falling between the two specified
       addresses are considered to be within the list.

   TS_IPV6_ADDR_RANGE                  8

       A range of IPv6 addresses, represented by two sixteen-octet
       values.  The first value is the beginning IPv6 address
       (inclusive) and the second value is the ending IPv6 address
       (inclusive).  All addresses falling between the two specified
       addresses are considered to be within the list.

3.14.  Encrypted Payload

   The Encrypted payload, denoted SK {...} in this document, contains
   other payloads in encrypted form.  The Encrypted payload, if present
   in a message, MUST be the last payload in the message.  Often, it is
   the only payload in the message.  This payload is also called the
   "Encrypted and Authenticated" payload.

   The algorithms for encryption and integrity protection are negotiated
   during IKE SA setup, and the keys are computed as specified in
   Sections 2.14 and 2.18.

   This document specifies the cryptographic processing of Encrypted
   payloads using a block cipher in CBC mode and an integrity check
   algorithm that computes a fixed-length checksum over a variable size
   message.  The design is modeled after the ESP algorithms described in
   RFCs 2104 [HMAC], 4303 [ESP], and 2451 [ESPCBC].  This document
   completely specifies the cryptographic processing of IKE data, but
   those documents should be consulted for design rationale.  Future
   documents may specify the processing of Encrypted payloads for other
   types of transforms, such as counter mode encryption and
   authenticated encryption algorithms.  Peers MUST NOT negotiate
   transforms for which no such specification exists.

Top      Up      ToC       Page 111 
   When an authenticated encryption algorithm is used to protect the IKE
   SA, the construction of the Encrypted payload is different than what
   is described here.  See [AEAD] for more information on authenticated
   encryption algorithms and their use in IKEv2.

   The payload type for an Encrypted payload is forty-six (46).  The
   Encrypted payload consists of the IKE generic payload header followed
   by individual fields as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Initialization Vector                     |
   |         (length is block size for encryption algorithm)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Encrypted IKE Payloads                     ~
   +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               |             Padding (0-255 octets)            |
   +-+-+-+-+-+-+-+-+                               +-+-+-+-+-+-+-+-+
   |                                               |  Pad Length   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                    Integrity Checksum Data                    ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 21: Encrypted Payload Format

   o  Next Payload - The payload type of the first embedded payload.
      Note that this is an exception in the standard header format,
      since the Encrypted payload is the last payload in the message and
      therefore the Next Payload field would normally be zero.  But
      because the content of this payload is embedded payloads and there
      was no natural place to put the type of the first one, that type
      is placed here.

   o  Payload Length - Includes the lengths of the header,
      initialization vector (IV), Encrypted IKE payloads, Padding, Pad
      Length, and Integrity Checksum Data.

   o  Initialization Vector - For CBC mode ciphers, the length of the
      initialization vector (IV) is equal to the block length of the
      underlying encryption algorithm.  Senders MUST select a new
      unpredictable IV for every message; recipients MUST accept any
      value.  The reader is encouraged to consult [MODES] for advice on
      IV generation.  In particular, using the final ciphertext block of

Top      Up      ToC       Page 112 
      the previous message is not considered unpredictable.  For modes
      other than CBC, the IV format and processing is specified in the
      document specifying the encryption algorithm and mode.

   o  IKE payloads are as specified earlier in this section.  This field
      is encrypted with the negotiated cipher.

   o  Padding MAY contain any value chosen by the sender, and MUST have
      a length that makes the combination of the payloads, the Padding,
      and the Pad Length to be a multiple of the encryption block size.
      This field is encrypted with the negotiated cipher.

   o  Pad Length is the length of the Padding field.  The sender SHOULD
      set the Pad Length to the minimum value that makes the combination
      of the payloads, the Padding, and the Pad Length a multiple of the
      block size, but the recipient MUST accept any length that results
      in proper alignment.  This field is encrypted with the negotiated
      cipher.

   o  Integrity Checksum Data is the cryptographic checksum of the
      entire message starting with the Fixed IKE header through the Pad
      Length.  The checksum MUST be computed over the encrypted message.
      Its length is determined by the integrity algorithm negotiated.

3.15.  Configuration Payload

   The Configuration payload, denoted CP in this document, is used to
   exchange configuration information between IKE peers.  The exchange
   is for an IRAC to request an internal IP address from an IRAS and to
   exchange other information of the sort that one would acquire with
   Dynamic Host Configuration Protocol (DHCP) if the IRAC were directly
   connected to a LAN.

   The Configuration payload is defined as follows:

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C| RESERVED    |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   CFG Type    |                    RESERVED                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Configuration Attributes                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 22: Configuration Payload Format

Top      Up      ToC       Page 113 
   The payload type for the Configuration payload is forty-seven (47).

   o  CFG Type (1 octet) - The type of exchange represented by the
      Configuration Attributes.  The values in the following table are
      only current as of the publication date of RFC 4306.  Other values
      may have been added since then or will be added after the
      publication of this document.  Readers should refer to [IKEV2IANA]
      for the latest values.

      CFG Type           Value
      --------------------------
      CFG_REQUEST        1
      CFG_REPLY          2
      CFG_SET            3
      CFG_ACK            4

   o  RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on
      receipt.

   o  Configuration Attributes (variable length) - These are type length
      value (TLV) structures specific to the Configuration payload and
      are defined below.  There may be zero or more Configuration
      Attributes in this payload.

3.15.1.  Configuration Attributes

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |R|         Attribute Type      |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                             Value                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 23: Configuration Attribute Format

   o  Reserved (1 bit) - This bit MUST be set to zero and MUST be
      ignored on receipt.

   o  Attribute Type (15 bits) - A unique identifier for each of the
      Configuration Attribute Types.

   o  Length (2 octets, unsigned integer) - Length in octets of value.

   o  Value (0 or more octets) - The variable-length value of this
      Configuration Attribute.  The following lists the attribute types.

Top      Up      ToC       Page 114 
   The values in the following table are only current as of the
   publication date of RFC 4306 (except INTERNAL_ADDRESS_EXPIRY and
   INTERNAL_IP6_NBNS, which were removed by RFC 5996).  Other values may
   have been added since then or will be added after the publication of
   this document.  Readers should refer to [IKEV2IANA] for the latest
   values.

      Attribute Type           Value  Multi-Valued  Length
      ------------------------------------------------------------
      INTERNAL_IP4_ADDRESS     1      YES*          0 or 4 octets
      INTERNAL_IP4_NETMASK     2      NO            0 or 4 octets
      INTERNAL_IP4_DNS         3      YES           0 or 4 octets
      INTERNAL_IP4_NBNS        4      YES           0 or 4 octets
      INTERNAL_IP4_DHCP        6      YES           0 or 4 octets
      APPLICATION_VERSION      7      NO            0 or more
      INTERNAL_IP6_ADDRESS     8      YES*          0 or 17 octets
      INTERNAL_IP6_DNS         10     YES           0 or 16 octets
      INTERNAL_IP6_DHCP        12     YES           0 or 16 octets
      INTERNAL_IP4_SUBNET      13     YES           0 or 8 octets
      SUPPORTED_ATTRIBUTES     14     NO            Multiple of 2
      INTERNAL_IP6_SUBNET      15     YES           17 octets

      * These attributes may be multi-valued on return only if
        multiple values were requested.

   o  INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
      internal network, sometimes called a red node address or private
      address, and it MAY be a private address on the Internet.  In a
      request message, the address specified is a requested address (or
      a zero-length address if no specific address is requested).  If a
      specific address is requested, it likely indicates that a previous
      connection existed with this address and the requestor would like
      to reuse that address.  With IPv6, a requestor MAY supply the low-
      order address octets it wants to use.  Multiple internal addresses
      MAY be requested by requesting multiple internal address
      attributes.  The responder MAY only send up to the number of
      addresses requested.  The INTERNAL_IP6_ADDRESS is made up of two
      fields: the first is a 16-octet IPv6 address, and the second is a
      one-octet prefix-length as defined in [ADDRIPV6].  The requested
      address is valid as long as this IKE SA (or its rekeyed
      successors) requesting the address is valid.  This is described in
      more detail in Section 3.15.3.

   o  INTERNAL_IP4_NETMASK - The internal network's netmask.  Only one
      netmask is allowed in the request and response messages (e.g.,
      255.255.255.0), and it MUST be used only with an
      INTERNAL_IP4_ADDRESS attribute.  INTERNAL_IP4_NETMASK in a
      CFG_REPLY means roughly the same thing as INTERNAL_IP4_SUBNET

Top      Up      ToC       Page 115 
      containing the same information ("send traffic to these addresses
      through me"), but also implies a link boundary.  For instance, the
      client could use its own address and the netmask to calculate the
      broadcast address of the link.  An empty INTERNAL_IP4_NETMASK
      attribute can be included in a CFG_REQUEST to request this
      information (although the gateway can send the information even
      when not requested).  Non-empty values for this attribute in a
      CFG_REQUEST do not make sense and thus MUST NOT be included.

   o  INTERNAL_IP4_DNS, INTERNAL_IP6_DNS - Specifies an address of a DNS
      server within the network.  Multiple DNS servers MAY be requested.
      The responder MAY respond with zero or more DNS server attributes.

   o  INTERNAL_IP4_NBNS - Specifies an address of a NetBios Name Server
      (WINS) within the network.  Multiple NBNS servers MAY be
      requested.  The responder MAY respond with zero or more NBNS
      server attributes.

   o  INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send
      any internal DHCP requests to the address contained within the
      attribute.  Multiple DHCP servers MAY be requested.  The responder
      MAY respond with zero or more DHCP server attributes.

   o  APPLICATION_VERSION - The version or application information of
      the IPsec host.  This is a string of printable ASCII characters
      that is NOT null terminated.

   o  INTERNAL_IP4_SUBNET - The protected sub-networks that this edge-
      device protects.  This attribute is made up of two fields: the
      first being an IP address and the second being a netmask.
      Multiple sub-networks MAY be requested.  The responder MAY respond
      with zero or more sub-network attributes.  This is discussed in
      more detail in Section 3.15.2.

   o  SUPPORTED_ATTRIBUTES - When used within a Request, this attribute
      MUST be zero-length and specifies a query to the responder to
      reply back with all of the attributes that it supports.  The
      response contains an attribute that contains a set of attribute
      identifiers each in 2 octets.  The length divided by 2 (octets)
      would state the number of supported attributes contained in the
      response.

   o  INTERNAL_IP6_SUBNET - The protected sub-networks that this
      edge-device protects.  This attribute is made up of two fields:
      the first is a 16-octet IPv6 address, and the second is a
      one-octet prefix-length as defined in [ADDRIPV6].  Multiple

Top      Up      ToC       Page 116 
      sub-networks MAY be requested.  The responder MAY respond with
      zero or more sub-network attributes.  This is discussed in more
      detail in Section 3.15.2.

   Note that no recommendations are made in this document as to how an
   implementation actually figures out what information to send in a
   response.  That is, we do not recommend any specific method of an
   IRAS determining which DNS server should be returned to a requesting
   IRAC.

   The CFG_REQUEST and CFG_REPLY pair allows an IKE endpoint to request
   information from its peer.  If an attribute in the CFG_REQUEST
   Configuration payload is not zero-length, it is taken as a suggestion
   for that attribute.  The CFG_REPLY Configuration payload MAY return
   that value, or a new one.  It MAY also add new attributes and not
   include some requested ones.  Unrecognized or unsupported attributes
   MUST be ignored in both requests and responses.

   The CFG_SET and CFG_ACK pair allows an IKE endpoint to push
   configuration data to its peer.  In this case, the CFG_SET
   Configuration payload contains attributes the initiator wants its
   peer to alter.  The responder MUST return a Configuration payload if
   it accepted any of the configuration data, and the Configuration
   payload MUST contain the attributes that the responder accepted with
   zero-length data.  Those attributes that it did not accept MUST NOT
   be in the CFG_ACK Configuration payload.  If no attributes were
   accepted, the responder MUST return either an empty CFG_ACK payload
   or a response message without a CFG_ACK payload.  There are currently
   no defined uses for the CFG_SET/CFG_ACK exchange, though they may be
   used in connection with extensions based on Vendor IDs.  An
   implementation of this specification MAY ignore CFG_SET payloads.

3.15.2.  Meaning of INTERNAL_IP4_SUBNET and INTERNAL_IP6_SUBNET

   INTERNAL_IP4/6_SUBNET attributes can indicate additional subnets,
   ones that need one or more separate SAs, that can be reached through
   the gateway that announces the attributes.  INTERNAL_IP4/6_SUBNET
   attributes may also express the gateway's policy about what traffic
   should be sent through the gateway; the client can choose whether
   other traffic (covered by TSr, but not in INTERNAL_IP4/6_SUBNET) is
   sent through the gateway or directly to the destination.  Thus,
   traffic to the addresses listed in the INTERNAL_IP4/6_SUBNET
   attributes should be sent through the gateway that announces the
   attributes.  If there are no existing Child SAs whose Traffic
   Selectors cover the address in question, new SAs need to be created.

Top      Up      ToC       Page 117 
   For instance, if there are two subnets, 198.51.100.0/26 and
   192.0.2.0/24, and the client's request contains the following:

   CP(CFG_REQUEST) =
     INTERNAL_IP4_ADDRESS()
   TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
   TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

   then a valid response could be the following (in which TSr and
   INTERNAL_IP4_SUBNET contain the same information):

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = ((0, 0-65535, 198.51.100.0-198.51.100.63),
          (0, 0-65535, 192.0.2.0-192.0.2.255))

   In these cases, the INTERNAL_IP4_SUBNET does not really carry any
   useful information.

   A different possible response would have been this:

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = (0, 0-65535, 0.0.0.0-255.255.255.255)

   That response would mean that the client can send all its traffic
   through the gateway, but the gateway does not mind if the client
   sends traffic not included by INTERNAL_IP4_SUBNET directly to the
   destination (without going through the gateway).

   A different situation arises if the gateway has a policy that
   requires the traffic for the two subnets to be carried in separate
   SAs.  Then a response like this would indicate to the client that
   if it wants access to the second subnet, it needs to create a
   separate SA:

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = (0, 0-65535, 198.51.100.0-198.51.100.63)

Top      Up      ToC       Page 118 
   INTERNAL_IP4_SUBNET can also be useful if the client's TSr included
   only part of the address space.  For instance, if the client requests
   the following:

   CP(CFG_REQUEST) =
     INTERNAL_IP4_ADDRESS()
   TSi = (0, 0-65535, 0.0.0.0-255.255.255.255)
   TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

   then the gateway's response might be:

   CP(CFG_REPLY) =
     INTERNAL_IP4_ADDRESS(198.51.100.234)
     INTERNAL_IP4_SUBNET(198.51.100.0/255.255.255.192)
     INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0)
   TSi = (0, 0-65535, 198.51.100.234-198.51.100.234)
   TSr = (0, 0-65535, 192.0.2.155-192.0.2.155)

   Because the meaning of INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in
   CFG_REQUESTs is unclear, they cannot be used reliably in
   CFG_REQUESTs.

3.15.3.  Configuration Payloads for IPv6

   The Configuration payloads for IPv6 are based on the corresponding
   IPv4 payloads, and do not fully follow the "normal IPv6 way of doing
   things".  In particular, IPv6 stateless autoconfiguration or router
   advertisement messages are not used, neither is neighbor discovery.
   Note that there is an additional document that discusses IPv6
   configuration in IKEv2, [IPV6CONFIG].  At the present time, it is an
   experimental document, but there is a hope that with more
   implementation experience, it will gain the same standards treatment
   as this document.

Top      Up      ToC       Page 119 
   A client can be assigned an IPv6 address using the
   INTERNAL_IP6_ADDRESS Configuration payload.  A minimal exchange might
   look like this:

   CP(CFG_REQUEST) =
     INTERNAL_IP6_ADDRESS()
     INTERNAL_IP6_DNS()
   TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)
   TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

   CP(CFG_REPLY) =
     INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64)
     INTERNAL_IP6_DNS(2001:DB8:99:88:77:66:55:44)
   TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5)
   TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF)

   The client MAY send a non-empty INTERNAL_IP6_ADDRESS attribute in the
   CFG_REQUEST to request a specific address or interface identifier.
   The gateway first checks if the specified address is acceptable, and
   if it is, returns that one.  If the address was not acceptable, the
   gateway attempts to use the interface identifier with some other
   prefix; if even that fails, the gateway selects another interface
   identifier.

   The INTERNAL_IP6_ADDRESS attribute also contains a prefix length
   field.  When used in a CFG_REPLY, this corresponds to the
   INTERNAL_IP4_NETMASK attribute in the IPv4 case.

   Although this approach to configuring IPv6 addresses is reasonably
   simple, it has some limitations.  IPsec tunnels configured using
   IKEv2 are not fully featured "interfaces" in the IPv6 addressing
   architecture sense [ADDRIPV6].  In particular, they do not
   necessarily have link-local addresses, and this may complicate the
   use of protocols that assume them, such as [MLDV2].

3.15.4.  Address Assignment Failures

   If the responder encounters an error while attempting to assign an IP
   address to the initiator during the processing of a Configuration
   payload, it responds with an INTERNAL_ADDRESS_FAILURE notification.
   The IKE SA is still created even if the initial Child SA cannot be
   created because of this failure.  If this error is generated within
   an IKE_AUTH exchange, no Child SA will be created.  However, there
   are some more complex error cases.

   If the responder does not support Configuration payloads at all, it
   can simply ignore all Configuration payloads.  This type of
   implementation never sends INTERNAL_ADDRESS_FAILURE notifications.

Top      Up      ToC       Page 120 
   If the initiator requires the assignment of an IP address, it will
   treat a response without CFG_REPLY as an error.

   The initiator may request a particular type of address (IPv4 or IPv6)
   that the responder does not support, even though the responder
   supports Configuration payloads.  In this case, the responder simply
   ignores the type of address it does not support and processes the
   rest of the request as usual.

   If the initiator requests multiple addresses of a type that the
   responder supports, and some (but not all) of the requests fail, the
   responder replies with the successful addresses only.  The responder
   sends INTERNAL_ADDRESS_FAILURE only if no addresses can be assigned.

   If the initiator does not receive the IP address(es) required by its
   policy, it MAY keep the IKE SA up and retry the Configuration payload
   as separate INFORMATIONAL exchange after suitable timeout, or it MAY
   tear down the IKE SA by sending a Delete payload inside a separate
   INFORMATIONAL exchange and later retry IKE SA from the beginning
   after some timeout.  Such a timeout should not be too short
   (especially if the IKE SA is started from the beginning) because
   these error situations may not be able to be fixed quickly; the
   timeout should likely be several minutes.  For example, an address
   shortage problem on the responder will probably only be fixed when
   more entries are returned to the address pool when other clients
   disconnect or when responder is reconfigured with larger address
   pool.

3.16.  Extensible Authentication Protocol (EAP) Payload

   The Extensible Authentication Protocol payload, denoted EAP in this
   document, allows IKE SAs to be authenticated using the protocol
   defined in RFC 3748 [EAP] and subsequent extensions to that protocol.
   When using EAP, an appropriate EAP method needs to be selected.  Many
   of these methods have been defined, specifying the protocol's use
   with various authentication mechanisms.  EAP method types are listed
   in [EAP-IANA].  A short summary of the EAP format is included here
   for clarity.

Top      Up      ToC       Page 121 
                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       EAP Message                             ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 24: EAP Payload Format

   The payload type for an EAP payload is forty-eight (48).

                        1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      | Identifier    |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      | Type_Data...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

                       Figure 25: EAP Message Format

   o  Code (1 octet) - Indicates whether this message is a Request (1),
      Response (2), Success (3), or Failure (4).

   o  Identifier (1 octet) - Used in PPP to distinguish replayed
      messages from repeated ones.  Since in IKE, EAP runs over a
      reliable protocol, the Identifier serves no function here.  In a
      response message, this octet MUST be set to match the identifier
      in the corresponding request.

   o  Length (2 octets, unsigned integer) - The length of the EAP
      message.  MUST be four less than the Payload Length of the
      encapsulating payload.

   o  Type (1 octet) - Present only if the Code field is Request (1) or
      Response (2).  For other codes, the EAP message length MUST be
      four octets and the Type and Type_Data fields MUST NOT be present.
      In a Request (1) message, Type indicates the data being requested.
      In a Response (2) message, Type MUST either be Nak or match the
      type of the data requested.  Note that since IKE passes an
      indication of initiator identity in the first message in the
      IKE_AUTH exchange, the responder SHOULD NOT send EAP Identity
      requests (type 1).  The initiator MAY, however, respond to such
      requests if it receives them.

Top      Up      ToC       Page 122 
   o  Type_Data (variable length) - Varies with the Type of Request and
      the associated Response.  For the documentation of the EAP
      methods, see [EAP].

   Note that since IKE passes an indication of initiator identity in the
   first message in the IKE_AUTH exchange, the responder SHOULD NOT send
   EAP Identity requests.  The initiator MAY, however, respond to such
   requests if it receives them.

4.  Conformance Requirements

   In order to assure that all implementations of IKEv2 can
   interoperate, there are "MUST support" requirements in addition to
   those listed elsewhere.  Of course, IKEv2 is a security protocol, and
   one of its major functions is to allow only authorized parties to
   successfully complete establishment of SAs.  So a particular
   implementation may be configured with any of a number of restrictions
   concerning algorithms and trusted authorities that will prevent
   universal interoperability.

   IKEv2 is designed to permit minimal implementations that can
   interoperate with all compliant implementations.  The following are
   features that can be omitted in a minimal implementation:

   o  Ability to negotiate SAs through a NAT and tunnel the resulting
      ESP SA over UDP.

   o  Ability to request (and respond to a request for) a temporary IP
      address on the remote end of a tunnel.

   o  Ability to support EAP-based authentication.

   o  Ability to support window sizes greater than one.

   o  Ability to establish multiple ESP or AH SAs within a single
      IKE SA.

   o  Ability to rekey SAs.

   To assure interoperability, all implementations MUST be capable of
   parsing all payload types (if only to skip over them) and to ignore
   payload types that it does not support unless the critical bit is set
   in the payload header.  If the critical bit is set in an unsupported
   payload header, all implementations MUST reject the messages
   containing those payloads.

Top      Up      ToC       Page 123 
   Every implementation MUST be capable of doing four-message
   IKE_SA_INIT and IKE_AUTH exchanges establishing two SAs (one for IKE,
   one for ESP or AH).  Implementations MAY be initiate-only or respond-
   only if appropriate for their platform.  Every implementation MUST be
   capable of responding to an INFORMATIONAL exchange, but a minimal
   implementation MAY respond to any request in the INFORMATIONAL
   exchange with an empty response (note that within the context of an
   IKE SA, an "empty" message consists of an IKE header followed by an
   Encrypted payload with no payloads contained in it).  A minimal
   implementation MAY support the CREATE_CHILD_SA exchange only in so
   far as to recognize requests and reject them with a Notify payload of
   type NO_ADDITIONAL_SAS.  A minimal implementation need not be able to
   initiate CREATE_CHILD_SA or INFORMATIONAL exchanges.  When an SA
   expires (based on locally configured values of either lifetime or
   octets passed), an implementation MAY either try to renew it with a
   CREATE_CHILD_SA exchange or it MAY delete (close) the old SA and
   create a new one.  If the responder rejects the CREATE_CHILD_SA
   request with a NO_ADDITIONAL_SAS notification, the implementation
   MUST be capable of instead deleting the old SA and creating a
   new one.

   Implementations are not required to support requesting temporary IP
   addresses or responding to such requests.  If an implementation does
   support issuing such requests and its policy requires using temporary
   IP addresses, it MUST include a CP payload in the first message in
   the IKE_AUTH exchange containing at least a field of type
   INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS.  All other fields are
   optional.  If an implementation supports responding to such requests,
   it MUST parse the CP payload of type CFG_REQUEST in the first message
   in the IKE_AUTH exchange and recognize a field of type
   INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS.  If it supports leasing
   an address of the appropriate type, it MUST return a CP payload of
   type CFG_REPLY containing an address of the requested type.  The
   responder may include any other related attributes.

   For an implementation to be called conforming to this specification,
   it MUST be possible to configure it to accept the following:

   o  Public Key Infrastructure using X.509 (PKIX) Certificates
      containing and signed by RSA keys of size 1024 or 2048 bits, where
      the ID passed is any of ID_KEY_ID, ID_FQDN, ID_RFC822_ADDR, or
      ID_DER_ASN1_DN.

   o  Shared key authentication where the ID passed is any of ID_KEY_ID,
      ID_FQDN, or ID_RFC822_ADDR.

Top      Up      ToC       Page 124 
   o  Authentication where the responder is authenticated using PKIX
      Certificates and the initiator is authenticated using shared key
      authentication.



(page 124 continued on part 6)

Next RFC Part