tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4306

 
 
 

Internet Key Exchange (IKEv2) Protocol

Part 4 of 5, p. 64 to 87
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 64 
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 65 
   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, this field indicates the type of that SA.  For IKE_SA
      notifications, this field MUST be one (1).  For notifications
      concerning IPsec SAs this field MUST contain either (2) to
      indicate AH or (3) to indicate ESP.  For notifications that do not
      relate to an existing SA, this field MUST be sent as zero and MUST
      be ignored on receipt.  All other values for this field are
      reserved to IANA for future assignment.

   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.

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

   o  SPI (variable length) - Security Parameter Index.

   o  Notification Data (variable length) - Informational 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 66 
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 except that 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.

        NOTIFY MESSAGES - ERROR TYPES           Value
        -----------------------------           -----
        RESERVED                                  0

        UNSUPPORTED_CRITICAL_PAYLOAD              1

            Sent if the payload has the "critical" bit set and the
            payload type is not recognized.  Notification Data contains
            the one-octet payload type.

        INVALID_IKE_SPI                           4

            Indicates an IKE message was received with an unrecognized
            destination SPI.  This usually indicates that the recipient
            has rebooted and forgotten the existence of an IKE_SA.

        INVALID_MAJOR_VERSION                     5

            Indicates the recipient cannot handle the version of IKE
            specified in the header.  The closest version number that
            the recipient can support will be in the reply header.

        INVALID_SYNTAX                            7

            Indicates the IKE message that was received was invalid
            because some type, length, or value was out of range or

Top      Up      ToC       Page 67 
            because the request was rejected for policy reasons.  To
            avoid a denial of service attack using forged messages, this
            status may only be returned for and in an encrypted packet
            if the message ID and 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

            Sent when an IKE message ID outside the supported window is
            received.  This Notify MUST NOT be sent in a response; the
            invalid request MUST NOT be acknowledged.  Instead, inform
            the other side by initiating an INFORMATIONAL exchange with
            Notification data containing the four octet invalid message
            ID.  Sending this notification is optional, and
            notifications of this type MUST be rate limited.

        INVALID_SPI                              11

            MAY be sent in an IKE INFORMATIONAL exchange when a node
            receives an ESP or AH packet with an invalid SPI.  The
            Notification Data contains the SPI of the invalid packet.
            This usually indicates a node has rebooted and forgotten an
            SA.  If this Informational Message is sent outside the
            context of an IKE_SA, it should be used by the recipient
            only as a "hint" that something might be wrong (because it
            could easily be forged).

        NO_PROPOSAL_CHOSEN                       14

            None of the proposed crypto suites was acceptable.

        INVALID_KE_PAYLOAD                       17

            The D-H Group # field in the KE payload is not the group #
            selected by the responder for this exchange.  There are two
            octets of data associated with this notification: the
            accepted D-H Group # in big endian order.

        AUTHENTICATION_FAILED                    24

            Sent in the response to an IKE_AUTH message when for some
            reason the authentication failed.  There is no associated
            data.

Top      Up      ToC       Page 68 
        SINGLE_PAIR_REQUIRED                     34

        This error indicates that a CREATE_CHILD_SA request is
        unacceptable because its sender is only willing to accept
        traffic selectors specifying a single pair of addresses.  The
        requestor is expected to respond by requesting an SA for only
        the specific traffic it is trying to forward.

        NO_ADDITIONAL_SAS                        35

        This error indicates that a CREATE_CHILD_SA request is
        unacceptable because the responder is unwilling to accept any
        more CHILD_SAs on this IKE_SA.  Some minimal implementations may
        only accept a single CHILD_SA setup in the context of an initial
        IKE exchange and reject any subsequent attempts to add more.

        INTERNAL_ADDRESS_FAILURE                 36

        Indicates an error assigning an internal address (i.e.,
        INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the
        processing of a Configuration Payload by a responder.  If this
        error is generated within an IKE_AUTH exchange, no CHILD_SA will
        be created.

        FAILED_CP_REQUIRED                       37

        Sent by responder in the case where CP(CFG_REQUEST) was expected
        but not received, and so is a conflict with locally configured
        policy.  There is no associated data.

        TS_UNACCEPTABLE                          38

        Indicates that none of the addresses/protocols/ports in the
        supplied traffic selectors is acceptable.

        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 IPsec SA.

        RESERVED TO IANA - Error types         40 - 8191

        Private Use - Errors                8192 - 16383

Top      Up      ToC       Page 69 
        NOTIFY MESSAGES - STATUS TYPES           Value
        ------------------------------           -----

        INITIAL_CONTACT                          16384

            This notification asserts that this IKE_SA is the only
            IKE_SA currently active between the authenticated
            identities.  It MAY be sent when an IKE_SA is established
            after a crash, and the recipient MAY use this information to
            delete any other IKE_SAs it has to the same authenticated
            identity without waiting for a timeout.  This notification
            MUST NOT be sent by an entity that may be replicated (e.g.,
            a roaming user's credentials where the user is allowed to
            connect to the corporate firewall from two remote systems at
            the same time).

        SET_WINDOW_SIZE                          16385

            This notification asserts that the sending endpoint is
            capable of keeping state for multiple outstanding exchanges,
            permitting the recipient to send multiple requests before
            getting a response to the first.  The data associated with a
            SET_WINDOW_SIZE notification MUST be 4 octets long and
            contain the big endian representation of the number of
            messages the sender promises to keep.  Window size is always
            one until the initial exchanges complete.

        ADDITIONAL_TS_POSSIBLE                   16386

            This notification asserts that the sending endpoint narrowed
            the proposed traffic selectors but that other traffic
            selectors would also have been acceptable, though only in a
            separate SA (see section 2.9).  There is no data associated
            with this Notify type.  It may be sent only as an additional
            payload in a message including accepted TSs.

        IPCOMP_SUPPORTED                         16387

            This notification may be included only in a message
            containing an SA payload negotiating a CHILD_SA and
            indicates a willingness by its sender to use IPComp on this
            SA.  The data associated with this notification includes a
            two-octet IPComp CPI followed by a one-octet transform ID
            optionally followed by attributes whose length and format
            are defined by that transform ID.  A message proposing an SA
            may contain multiple IPCOMP_SUPPORTED notifications to
            indicate multiple supported algorithms.  A message accepting
            an SA may contain at most one.

Top      Up      ToC       Page 70 
            The transform IDs currently defined are:

                 NAME         NUMBER  DEFINED IN
                 -----------  ------  -----------
                 RESERVED       0
                 IPCOMP_OUI     1
                 IPCOMP_DEFLATE 2     RFC 2394
                 IPCOMP_LZS     3     RFC 2395
                 IPCOMP_LZJH    4     RFC 3051

                 values 5-240 are reserved to IANA.  Values 241-255 are
                 for private use among mutually consenting parties.

        NAT_DETECTION_SOURCE_IP                  16388

            This notification is used by its recipient to determine
            whether the source is behind a NAT box.  The data associated
            with this notification is a SHA-1 digest of the SPIs (in the
            order they appear in the header), IP address, and port on
            which this packet was sent.  There MAY be multiple Notify
            payloads of this type in a message if the sender does not
            know which of several network attachments will be used to
            send the packet.  The recipient of this notification MAY
            compare the supplied value to a SHA-1 hash of the SPIs,
            source IP address, and port, and if they don't match it
            SHOULD enable NAT traversal (see section 2.23).
            Alternately, it MAY reject the connection attempt if NAT
            traversal is not supported.

        NAT_DETECTION_DESTINATION_IP             16389

            This notification is used by its recipient to determine
            whether it is behind a NAT box.  The data associated with
            this notification is a SHA-1 digest of the SPIs (in the
            order they appear in the header), IP address, and port to
            which this packet was sent.  The recipient of this
            notification MAY compare the supplied value to a hash of the
            SPIs, destination IP address, and port, and if they don't
            match it SHOULD invoke NAT traversal (see section 2.23).  If
            they don't match, it means that this end is behind a NAT and
            this end SHOULD start sending keepalive packets as defined
            in [Hutt05].  Alternately, it MAY reject the connection
            attempt if NAT traversal is not supported.

Top      Up      ToC       Page 71 
        COOKIE                                   16390

            This notification MAY be included in an IKE_SA_INIT
            response.  It indicates that the request should be retried
            with a copy of this notification as the first payload.  This
            notification MUST be included in an IKE_SA_INIT request
            retry if a COOKIE notification was included in the initial
            response.  The data associated with this notification MUST
            be between 1 and 64 octets in length (inclusive).

        USE_TRANSPORT_MODE                       16391

            This notification MAY be included in a request message that
            also includes an SA payload requesting a CHILD_SA.  It
            requests that the CHILD_SA use transport mode rather than
            tunnel mode for the SA created.  If the request is accepted,
            the response MUST also include a notification of type
            USE_TRANSPORT_MODE.  If the responder declines the request,
            the CHILD_SA will be established in tunnel mode.  If this is
            unacceptable to the initiator, the initiator MUST delete the
            SA.  Note: Except when using this option to negotiate
            transport mode, all CHILD_SAs will use tunnel mode.

            Note: The ECN decapsulation modifications specified in
            [RFC4301] MUST be performed for every tunnel mode SA created
            by IKEv2.

        HTTP_CERT_LOOKUP_SUPPORTED               16392

            This notification MAY be included in any message that can
            include a CERTREQ payload and indicates that the sender is
            capable of looking up certificates based on an HTTP-based
            URL (and hence presumably would prefer to receive
            certificate specifications in that format).

        REKEY_SA                                 16393

            This notification MUST be included in a CREATE_CHILD_SA
            exchange if the purpose of the exchange is to replace an
            existing ESP or AH SA.  The SPI field identifies the SA
            being rekeyed.  There is no data.

        ESP_TFC_PADDING_NOT_SUPPORTED            16394

            This notification asserts that the sending endpoint will NOT
            accept packets that contain Flow Confidentiality (TFC)
            padding.

Top      Up      ToC       Page 72 
        NON_FIRST_FRAGMENTS_ALSO                 16395

            Used for fragmentation control.  See [RFC4301] for
            explanation.

        RESERVED TO IANA - STATUS TYPES      16396 - 40959

        Private Use - STATUS TYPES           40960 - 65535

3.11.  Delete Payload

   The Delete Payload, denoted D in this memo, 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 a 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    !           # 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.

Top      Up      ToC       Page 73 
   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.

   o  # of SPIs (2 octets) - 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 # 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 memo, 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 to
   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 memo -- private
   payloads, private exchanges, private notifications, etc.  Unfamiliar
   Vendor IDs MUST be ignored.

   Writers of Internet-Drafts who wish to extend this protocol MUST
   define a Vendor ID payload to announce the ability to implement the
   extension in the Internet-Draft.  It is expected that Internet-Drafts
   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 74 
   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.  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 memo, 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 75 
   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.

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 (e.g., UDP/TCP/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 - Specifies the length of this Traffic Selector
      Substructure including the header.

Top      Up      ToC       Page 76 
   o  Start Port (2 octets) - Value specifying the smallest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined, or if all ports are allowed, this field MUST be zero.
      For the ICMP protocol, the two one-octet fields Type and Code are
      treated as a single 16-bit integer (with Type in the most
      significant eight bits and Code in the least significant eight
      bits) port number for the purposes of filtering based on this
      field.

   o  End Port (2 octets) - Value specifying the largest port number
      allowed by this Traffic Selector.  For protocols for which port is
      undefined, or if all ports are allowed, this field MUST be 65535.
      For the ICMP protocol, the two one-octet fields Type and Code are
      treated as a single 16-bit integer (with Type in the most
      significant eight bits and Code in the least significant eight
      bits) port number for the purposed of filtering based on this
      field.

   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 [RFC4301] that wish to indicate "ANY"
   ports MUST set the start port to 0 and the end port to 65535; note
   that according to [RFC4301], "ANY" includes "OPAQUE".  Systems
   working with [RFC4301] that wish to indicate "OPAQUE" ports, but not
   "ANY" ports, MUST set the start port to 65535 and the end port to 0.

   The following table lists the assigned values for the Traffic
   Selector Type field and the corresponding Address Selector Data.

      TS Type                           Value
      -------                           -----
      RESERVED                           0-6

      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.

Top      Up      ToC       Page 77 
      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.

      RESERVED TO IANA                    9-240
      PRIVATE USE                         241-255

3.14.  Encrypted Payload

   The Encrypted Payload, denoted SK{...} or E in this memo, 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.

   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.

   The encryption and integrity protection algorithms are modeled after
   the ESP algorithms described in RFCs 2104 [KBC96], 4303 [RFC4303],
   and 2451 [ESPCBC].  This document completely specifies the
   cryptographic processing of IKE data, but those documents should be
   consulted for design rationale.  We require a block cipher with a
   fixed block size and an integrity check algorithm that computes a
   fixed-length checksum over a variable size message.

   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:

Top      Up      ToC       Page 78 

                           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, IV, Encrypted
      IKE Payloads, Padding, Pad Length, and Integrity Checksum Data.

   o  Initialization Vector - A randomly chosen value whose length is
      equal to the block length of the underlying encryption algorithm.
      Recipients MUST accept any value.  Senders SHOULD either pick this
      value pseudo-randomly and independently for each message or use
      the final ciphertext block of the previous message sent.  Senders
      MUST NOT use the same value for each message, use a sequence of
      values with low hamming distance (e.g., a sequence number), or use
      ciphertext from a received message.

   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.

Top      Up      ToC       Page 79 
   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.

   Configuration payloads are of type CFG_REQUEST/CFG_REPLY or
   CFG_SET/CFG_ACK (see CFG Type in the payload description below).
   CFG_REQUEST and CFG_SET payloads may optionally be added to any IKE
   request.  The IKE response MUST include either a corresponding
   CFG_REPLY or CFG_ACK or a Notify payload with an error type
   indicating why the request could not be honored.  An exception is
   that a minimal implementation MAY ignore all CFG_REQUEST and CFG_SET
   payloads, so a response message without a corresponding CFG_REPLY or
   CFG_ACK MUST be accepted as an indication that the request was not
   supported.

   "CFG_REQUEST/CFG_REPLY" 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.  Requestors MUST ignore returned attributes that
   they do not recognize.

   Some attributes MAY be multi-valued, in which case multiple attribute
   values of the same type are sent and/or returned.  Generally, all
   values of an attribute are returned when the attribute is requested.
   For some attributes (in this version of the specification only
   internal addresses), multiple requests indicates a request that
   multiple values be assigned.  For these attributes, the number of
   values returned SHOULD NOT exceed the number requested.

Top      Up      ToC       Page 80 
   If the data type requested in a CFG_REQUEST is not recognized or not
   supported, the responder MUST NOT return an error type but rather
   MUST either send a CFG_REPLY that MAY be empty or a reply not
   containing a CFG_REPLY payload at all.  Error returns are reserved
   for cases where the request is recognized but cannot be performed as
   requested or the request is badly formatted.

   "CFG_SET/CFG_ACK" 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 it 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 minimal implementation of this specification MAY
   ignore CFG_SET payloads.

   Extensions via the CP payload SHOULD NOT be used for general purpose
   management.  Its main intent is to provide a bootstrap mechanism to
   exchange information within IPsec from IRAS to IRAC.  While it MAY be
   useful to use such a method to exchange information between some
   Security Gateways (SGW) or small networks, existing management
   protocols such as DHCP [DHCP], RADIUS [RADIUS], SNMP, or LDAP [LDAP]
   should be preferred for enterprise management as well as subsequent
   information exchanges.

   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

   The payload type for the Configuration Payload is forty seven (47).

Top      Up      ToC       Page 81 
   o  CFG Type (1 octet) - The type of exchange represented by the
      Configuration Attributes.

             CFG Type       Value
             ===========    =====
             RESERVED         0
             CFG_REQUEST      1
             CFG_REPLY        2
             CFG_SET          3
             CFG_ACK          4

      values 5-127 are reserved to IANA.  Values 128-255 are for private
      use among mutually consenting parties.

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

   o  Configuration Attributes (variable length) - These are type length
      values 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) - Length in octets of Value.

   o  Value (0 or more octets) - The variable-length value of this
      Configuration Attribute.

Top      Up      ToC       Page 82 
   The following attribute types have been defined:

                                      Multi-
        Attribute Type          Value Valued Length
        ======================= ===== ====== ==================
         RESERVED                 0
         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_ADDRESS_EXPIRY  5    NO    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
         RESERVED                 9
         INTERNAL_IP6_DNS        10    YES   0 or 16 octets
         INTERNAL_IP6_NBNS       11    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.

      Types 16-16383 are reserved to IANA.  Values 16384-32767 are for
      private use among mutually consenting parties.

      o  INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the
         internal network, sometimes called a red node address or
         private address and MAY be a private address on the Internet.
         In a request message, the address specified is a requested
         address (or zero 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 bytes 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 sixteen-octet IPv6
         address and the second is a one-octet prefix-length as defined
         in [ADDRIPV6].

         The requested address is valid until the expiry time defined
         with the INTERNAL_ADDRESS EXPIRY attribute or there are no
         IKE_SAs between the peers.

Top      Up      ToC       Page 83 
      o  INTERNAL_IP4_NETMASK - The internal network's netmask.  Only
         one netmask is allowed in the request and reply messages (e.g.,
         255.255.255.0), and it MUST be used only with an
         INTERNAL_IP4_ADDRESS attribute.

      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, INTERNAL_IP6_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_ADDRESS_EXPIRY - Specifies the number of seconds that
         the host can use the internal IP address.  The host MUST renew
         the IP address before this expiry time.  Only one of these
         attributes MAY be present in the reply.

      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 is an IP address and the second is a netmask.
         Multiple sub-networks MAY be requested.  The responder MAY
         respond with zero or more sub-network attributes.

      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.

Top      Up      ToC       Page 84 
      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 sixteen-octet IPv6 address and the second is a
         one-octet prefix-length as defined in [ADDRIPV6].  Multiple
         sub-networks MAY be requested.  The responder MAY respond with
         zero or more sub-network attributes.

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

3.16.  Extensible Authentication Protocol (EAP) Payload

   The Extensible Authentication Protocol Payload, denoted EAP in this
   memo, allows IKE_SAs to be authenticated using the protocol defined
   in RFC 3748 [EAP] and subsequent extensions to that protocol.  The
   full set of acceptable values for the payload is defined elsewhere,
   but a short summary of RFC 3748 is included here to make this
   document stand alone in the common cases.

                            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).

Top      Up      ToC       Page 85 
   o  Identifier (1 octet) is used in PPP to distinguish replayed
      messages from repeated ones.  Since in IKE, EAP runs over a
      reliable protocol, it serves no function here.  In a response
      message, this octet MUST be set to match the identifier in the
      corresponding request.  In other messages, this field MAY be set
      to any value.

   o  Length (2 octets) is the length of the EAP message and MUST be
      four less than the Payload Length of the encapsulating payload.

   o  Type (1 octet) is 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.  The following types are defined in
      RFC 3748:

      1  Identity
      2  Notification
      3  Nak (Response Only)
      4  MD5-Challenge
      5  One-Time Password (OTP)
      6  Generic Token Card

   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
   message 3 of the protocol, the responder SHOULD NOT send EAP Identity
   requests.  The initiator SHOULD, 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.

Top      Up      ToC       Page 86 
   IKEv2 is designed to permit minimal implementations that can
   interoperate with all compliant implementations.  There are a series
   of optional features that can easily be ignored by a particular
   implementation if it does not support that feature.  Those features
   include:

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

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

      Ability to support various types of legacy authentication.

      Ability to support window sizes greater than one.

      Ability to establish multiple ESP and/or AH SAs within a single
      IKE_SA.

      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.

   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 and/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 INFORMATIONAL message with
   an empty INFORMATIONAL reply (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), and 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 closing the old SA and creating a new one.

Top      Up      ToC       Page 87 
   Implementations are not required to support requesting temporary IP
   addresses or responding to such requests.  If an implementation does
   support issuing such requests, it MUST include a CP payload in
   message 3 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 message 3 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 SHOULD include all of the other related
   attributes if it has them.

   A minimal IPv4 responder implementation will ignore the contents of
   the CP payload except to determine that it includes an
   INTERNAL_IP4_ADDRESS attribute and will respond with the address and
   other related attributes regardless of whether the initiator
   requested them.

   A minimal IPv4 initiator will generate a CP payload containing only
   an INTERNAL_IP4_ADDRESS attribute and will parse the response
   ignoring attributes it does not know how to use.  The only attribute
   it MUST be able to process is INTERNAL_ADDRESS_EXPIRY, which it must
   use to bound the lifetime of the SA unless it successfully renews the
   lease before it expires.  Minimal initiators need not be able to
   request lease renewals and minimal responders need not respond to
   them.

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

   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.

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

   Authentication where the responder is authenticated using PKIX
   Certificates and the initiator is authenticated using shared key
   authentication.


Next RFC Part