tech-invite   World Map     

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

RFC 5996

 
 
 

Internet Key Exchange Protocol Version 2 (IKEv2)

Part 4 of 6, p. 75 to 101
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 75 
3.3.  Security Association Payload

   The Security Association payload, denoted SA in this document, is
   used to negotiate attributes of a Security Association.  Assembly of
   Security Association payloads requires great peace of mind.  An SA
   payload MAY contain multiple proposals.  If there is more than one,
   they MUST be ordered from most preferred to least preferred.  Each
   proposal contains a single IPsec protocol (where a protocol is IKE,
   ESP, or AH), each protocol MAY contain multiple transforms, and each
   transform MAY contain multiple attributes.  When parsing an SA, an
   implementation MUST check that the total Payload Length is consistent
   with the payload's internal lengths and counts.  Proposals,
   Transforms, and Attributes each have their own variable-length
   encodings.  They are nested such that the Payload Length of an SA
   includes the combined contents of the SA, Proposal, Transform, and
   Attribute information.  The length of a Proposal includes the lengths
   of all Transforms and Attributes it contains.  The length of a
   Transform includes the lengths of all Attributes it contains.

   The syntax of Security Associations, Proposals, Transforms, and
   Attributes is based on ISAKMP; however, the semantics are somewhat
   different.  The reason for the complexity and the hierarchy is to
   allow for multiple possible combinations of algorithms to be encoded
   in a single SA.  Sometimes there is a choice of multiple algorithms,
   whereas other times there is a combination of algorithms.  For
   example, an initiator might want to propose using ESP with either
   (3DES and HMAC_MD5) or (AES and HMAC_SHA1).

   One of the reasons the semantics of the SA payload have changed from
   ISAKMP and IKEv1 is to make the encodings more compact in common
   cases.

   The Proposal structure contains within it a Proposal Num and an IPsec
   protocol ID.  Each structure MUST have a proposal number one (1)
   greater than the previous structure.  The first Proposal in the
   initiator's SA payload MUST have a Proposal Num of one (1).  One
   reason to use multiple proposals is to propose both standard crypto
   ciphers and combined-mode ciphers.  Combined-mode ciphers include
   both integrity and encryption in a single encryption algorithm, and
   MUST either offer no integrity algorithm or a single integrity
   algorithm of "none", with no integrity algorithm being the
   RECOMMENDED method.  If an initiator wants to propose both combined-
   mode ciphers and normal ciphers, it must include two proposals: one
   will have all the combined-mode ciphers, and the other will have all

Top      Up      ToC       Page 76 
   the normal ciphers with the integrity algorithms.  For example, one
   such proposal would have two proposal structures.  Proposal 1 is ESP
   with AES-128, AES-192, and AES-256 bits in Cipher Block Chaining
   (CBC) mode, with either HMAC-SHA1-96 or XCBC-96 as the integrity
   algorithm; Proposal 2 is AES-128 or AES-256 in GCM mode with an
   8-octet Integrity Check Value (ICV).  Both proposals allow but do not
   require the use of ESNs (Extended Sequence Numbers).  This can be
   illustrated as:

   SA Payload
      |
      +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
      |     |            7 transforms,      SPI = 0x052357bb )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 128 )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 192 )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 256 )
      |     |
      |     +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
      |     +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
      |     +-- Transform ESN ( Name = ESNs )
      |     +-- Transform ESN ( Name = No ESNs )
      |
      +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
            |            4 transforms,      SPI = 0x35a1d6f2 )
            |
            +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
            |     +-- Attribute ( Key Length = 128 )
            |
            +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
            |     +-- Attribute ( Key Length = 256 )
            |
            +-- Transform ESN ( Name = ESNs )
            +-- Transform ESN ( Name = No ESNs )

   Each Proposal/Protocol structure is followed by one or more transform
   structures.  The number of different transforms is generally
   determined by the Protocol.  AH generally has two transforms:
   Extended Sequence Numbers (ESNs) and an integrity check algorithm.
   ESP generally has three: ESN, an encryption algorithm, and an
   integrity check algorithm.  IKE generally has four transforms: a
   Diffie-Hellman group, an integrity check algorithm, a PRF algorithm,

Top      Up      ToC       Page 77 
   and an encryption algorithm.  For each Protocol, the set of
   permissible transforms is assigned Transform ID numbers, which appear
   in the header of each transform.

   If there are multiple transforms with the same Transform Type, the
   proposal is an OR of those transforms.  If there are multiple
   transforms with different Transform Types, the proposal is an AND of
   the different groups.  For example, to propose ESP with (3DES or AES-
   CBC) and (HMAC_MD5 or HMAC_SHA), the ESP proposal would contain two
   Transform Type 1 candidates (one for 3DES and one for AEC-CBC) and
   two Transform Type 3 candidates (one for HMAC_MD5 and one for
   HMAC_SHA).  This effectively proposes four combinations of
   algorithms.  If the initiator wanted to propose only a subset of
   those, for example (3DES and HMAC_MD5) or (IDEA and HMAC_SHA), there
   is no way to encode that as multiple transforms within a single
   Proposal.  Instead, the initiator would have to construct two
   different Proposals, each with two transforms.

   A given transform MAY have one or more Attributes.  Attributes are
   necessary when the transform can be used in more than one way, as
   when an encryption algorithm has a variable key size.  The transform
   would specify the algorithm and the attribute would specify the key
   size.  Most transforms do not have attributes.  A transform MUST NOT
   have multiple attributes of the same type.  To propose alternate
   values for an attribute (for example, multiple key sizes for the AES
   encryption algorithm), an implementation MUST include multiple
   transforms with the same Transform Type each with a single Attribute.

   Note that the semantics of Transforms and Attributes are quite
   different from those in IKEv1.  In IKEv1, a single Transform carried
   multiple algorithms for a protocol with one carried in the Transform
   and the others carried in the 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                          <Proposals>                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 6:  Security Association Payload

   o  Proposals (variable) - One or more proposal substructures.

Top      Up      ToC       Page 78 
   The payload type for the Security Association payload is thirty-three
   (33).

3.3.1.  Proposal Substructure

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0 (last) or 2 |   RESERVED    |         Proposal Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Proposal Num  |  Protocol ID  |    SPI Size   |Num  Transforms|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   ~                        SPI (variable)                         ~
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                        <Transforms>                           ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 7:  Proposal Substructure

   o  0 (last) or 2 (more) (1 octet) - Specifies whether this is the
      last Proposal Substructure in the SA.  This syntax is inherited
      from ISAKMP, but is unnecessary because the last Proposal could be
      identified from the length of the SA.  The value (2) corresponds
      to a payload type of Proposal in IKEv1, and the first four octets
      of the Proposal structure are designed to look somewhat like the
      header of a payload.

   o  RESERVED (1 octet) - MUST be sent as zero; MUST be ignored on
      receipt.

   o  Proposal Length (2 octets, unsigned integer) - Length of this
      proposal, including all transforms and attributes that follow.

   o  Proposal Num (1 octet) - When a proposal is made, the first
      proposal in an SA payload MUST be 1, and subsequent proposals MUST
      be one more than the previous proposal (indicating an OR of the
      two proposals).  When a proposal is accepted, the proposal number
      in the SA payload MUST match the number on the proposal sent that
      was accepted.

   o  Protocol ID (1 octet) - Specifies the IPsec protocol identifier
      for the current negotiation.  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.

Top      Up      ToC       Page 79 
      Protocol                Protocol ID
      -----------------------------------
      IKE                     1
      AH                      2
      ESP                     3

   o  SPI Size (1 octet) - For an initial IKE SA negotiation, this field
      MUST be zero; the SPI is obtained from the outer header.  During
      subsequent negotiations, it is equal to the size, in octets, of
      the SPI of the corresponding protocol (8 for IKE, 4 for ESP and
      AH).

   o  Num Transforms (1 octet) - Specifies the number of transforms in
      this proposal.

   o  SPI (variable) - The sending entity's SPI.  Even if the SPI Size
      is not a multiple of 4 octets, there is no padding applied to the
      payload.  When the SPI Size field is zero, this field is not
      present in the Security Association payload.

   o  Transforms (variable) - One or more transform substructures.

3.3.2.  Transform Substructure

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 0 (last) or 3 |   RESERVED    |        Transform Length       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Transform Type |   RESERVED    |          Transform ID         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Transform Attributes                     ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 8:  Transform Substructure

   o  0 (last) or 3 (more) (1 octet) - Specifies whether this is the
      last Transform Substructure in the Proposal.  This syntax is
      inherited from ISAKMP, but is unnecessary because the last
      transform could be identified from the length of the proposal.
      The value (3) corresponds to a payload type of Transform in IKEv1,
      and the first four octets of the Transform structure are designed
      to look somewhat like the header of a payload.

   o  RESERVED - MUST be sent as zero; MUST be ignored on receipt.

Top      Up      ToC       Page 80 
   o  Transform Length - The length (in octets) of the Transform
      Substructure including Header and Attributes.

   o  Transform Type (1 octet) - The type of transform being specified
      in this transform.  Different protocols support different
      Transform Types.  For some protocols, some of the transforms may
      be optional.  If a transform is optional and the initiator wishes
      to propose that the transform be omitted, no transform of the
      given type is included in the proposal.  If the initiator wishes
      to make use of the transform optional to the responder, it
      includes a transform substructure with Transform ID = 0 as one of
      the options.

   o  Transform ID (2 octets) - The specific instance of the Transform
      Type being proposed.

   The Transform Type values are listed below.  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.

   Description                     Trans.  Used In
                                   Type
   ------------------------------------------------------------------
   Encryption Algorithm (ENCR)     1       IKE and ESP
   Pseudorandom Function (PRF)     2       IKE
   Integrity Algorithm (INTEG)     3       IKE*, AH, optional in ESP
   Diffie-Hellman group (D-H)      4       IKE, optional in AH & ESP
   Extended Sequence Numbers (ESN) 5       AH and ESP

   (*) Negotiating an integrity algorithm is mandatory for the
   Encrypted payload format specified in this document.  For example,
   [AEAD] specifies additional formats based on authenticated
   encryption, in which a separate integrity algorithm is not
   negotiated.

   For Transform Type 1 (Encryption Algorithm), the Transform IDs are
   listed below.  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.

Top      Up      ToC       Page 81 
   Name                 Number      Defined In
   ---------------------------------------------------
   ENCR_DES_IV64        1           (UNSPECIFIED)
   ENCR_DES             2           (RFC2405), [DES]
   ENCR_3DES            3           (RFC2451)
   ENCR_RC5             4           (RFC2451)
   ENCR_IDEA            5           (RFC2451), [IDEA]
   ENCR_CAST            6           (RFC2451)
   ENCR_BLOWFISH        7           (RFC2451)
   ENCR_3IDEA           8           (UNSPECIFIED)
   ENCR_DES_IV32        9           (UNSPECIFIED)
   ENCR_NULL            11          (RFC2410)
   ENCR_AES_CBC         12          (RFC3602)
   ENCR_AES_CTR         13          (RFC3686)

   For Transform Type 2 (Pseudorandom Function), the Transform IDs are
   listed below.  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.

   Name                        Number    Defined In
   ------------------------------------------------------
   PRF_HMAC_MD5                1         (RFC2104), [MD5]
   PRF_HMAC_SHA1               2         (RFC2104), [SHA]
   PRF_HMAC_TIGER              3         (UNSPECIFIED)

   For Transform Type 3 (Integrity Algorithm), defined Transform IDs are
   listed below.  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.

   Name                 Number   Defined In
   ----------------------------------------
   NONE                 0
   AUTH_HMAC_MD5_96     1        (RFC2403)
   AUTH_HMAC_SHA1_96    2        (RFC2404)
   AUTH_DES_MAC         3        (UNSPECIFIED)
   AUTH_KPDK_MD5        4        (UNSPECIFIED)
   AUTH_AES_XCBC_96     5        (RFC3566)

   For Transform Type 4 (Diffie-Hellman group), defined Transform IDs
   are listed below.  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.

Top      Up      ToC       Page 82 
   Name               Number     Defined In
   ----------------------------------------
   NONE               0
   768-bit MODP       1          Appendix B
   1024-bit MODP      2          Appendix B
   1536-bit MODP      5          [ADDGROUP]
   2048-bit MODP      14         [ADDGROUP]
   3072-bit MODP      15         [ADDGROUP]
   4096-bit MODP      16         [ADDGROUP]
   6144-bit MODP      17         [ADDGROUP]
   8192-bit MODP      18         [ADDGROUP]

   Although ESP and AH do not directly include a Diffie-Hellman
   exchange, a Diffie-Hellman group MAY be negotiated for the Child SA.
   This allows the peers to employ Diffie-Hellman in the CREATE_CHILD_SA
   exchange, providing perfect forward secrecy for the generated Child
   SA keys.

   For Transform Type 5 (Extended Sequence Numbers), defined Transform
   IDs are listed below.  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.

   Name                               Number
   --------------------------------------------
   No Extended Sequence Numbers       0
   Extended Sequence Numbers          1

   Note that an initiator who supports ESNs will usually include two ESN
   transforms, with values "0" and "1", in its proposals.  A proposal
   containing a single ESN transform with value "1" means that using
   normal (non-extended) sequence numbers is not acceptable.

   Numerous additional Transform Types have been defined since the
   publication of RFC 4306.  Please refer to the IANA IKEv2 registry for
   details.

3.3.3.  Valid Transform Types by Protocol

   The number and type of transforms that accompany an SA payload are
   dependent on the protocol in the SA itself.  An SA payload proposing
   the establishment of an SA has the following mandatory and optional
   Transform Types.  A compliant implementation MUST understand all
   mandatory and optional types for each protocol it supports (though it

Top      Up      ToC       Page 83 
   need not accept proposals with unacceptable suites).  A proposal MAY
   omit the optional types if the only value for them it will accept is
   NONE.

   Protocol    Mandatory Types          Optional Types
   ---------------------------------------------------
   IKE         ENCR, PRF, INTEG*, D-H
   ESP         ENCR, ESN                INTEG, D-H
   AH          INTEG, ESN               D-H

   (*) Negotiating an integrity algorithm is mandatory for the
   Encrypted payload format specified in this document.  For example,
   [AEAD] specifies additional formats based on authenticated
   encryption, in which a separate integrity algorithm is not
   negotiated.

3.3.4.  Mandatory Transform IDs

   The specification of suites that MUST and SHOULD be supported for
   interoperability has been removed from this document because they are
   likely to change more rapidly than this document evolves.  At the
   time of publication of this document, [RFC4307] specifies these
   suites, but note that it might be updated in the future, and other
   RFCs might specify different sets of suites.

   An important lesson learned from IKEv1 is that no system should only
   implement the mandatory algorithms and expect them to be the best
   choice for all customers.

   It is likely that IANA will add additional transforms in the future,
   and some users may want to use private suites, especially for IKE
   where implementations should be capable of supporting different
   parameters, up to certain size limits.  In support of this goal, all
   implementations of IKEv2 SHOULD include a management facility that
   allows specification (by a user or system administrator) of Diffie-
   Hellman parameters (the generator, modulus, and exponent lengths and
   values) for new Diffie-Hellman groups.  Implementations SHOULD
   provide a management interface through which these parameters and the
   associated Transform IDs may be entered (by a user or system
   administrator), to enable negotiating such groups.

   All implementations of IKEv2 MUST include a management facility that
   enables a user or system administrator to specify the suites that are
   acceptable for use with IKE.  Upon receipt of a payload with a set of
   Transform IDs, the implementation MUST compare the transmitted
   Transform IDs against those locally configured via the management
   controls, to verify that the proposed suite is acceptable based on
   local policy.  The implementation MUST reject SA proposals that are

Top      Up      ToC       Page 84 
   not authorized by these IKE suite controls.  Note that cryptographic
   suites that MUST be implemented need not be configured as acceptable
   to local policy.

3.3.5.  Transform Attributes

   Each transform in a Security Association payload may include
   attributes that modify or complete the specification of the
   transform.  The set of valid attributes depends on the transform.
   Currently, only a single attribute type is defined: the Key Length
   attribute is used by certain encryption transforms with variable-
   length keys (see below for details).

   The attributes are type/value pairs and are defined below.
   Attributes can have a value with a fixed two-octet length or a
   variable-length value.  For the latter, the attribute is encoded as
   type/length/value.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|       Attribute Type        |    AF=0  Attribute Length     |
   |F|                             |    AF=1  Attribute Value      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   AF=0  Attribute Value                       |
   |                   AF=1  Not Transmitted                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 9:  Data Attributes

   o  Attribute Format (AF) (1 bit) - Indicates whether the data
      attribute follows the Type/Length/Value (TLV) format or a
      shortened Type/Value (TV) format.  If the AF bit is zero (0), then
      the attribute uses TLV format; if the AF bit is one (1), the TV
      format (with two-byte value) is used.

   o  Attribute Type (15 bits) - Unique identifier for each type of
      attribute (see below).

   o  Attribute Value (variable length) - Value of the attribute
      associated with the attribute type.  If the AF bit is a zero (0),
      this field has a variable length defined by the Attribute Length
      field.  If the AF bit is a one (1), the Attribute Value has a
      length of 2 octets.

   The only currently defined attribute type (Key Length) is fixed
   length; the variable-length encoding specification is included only
   for future extensions.  Attributes described as fixed length MUST NOT

Top      Up      ToC       Page 85 
   be encoded using the variable-length encoding unless that length
   exceeds two bytes.  Variable-length attributes MUST NOT be encoded as
   fixed-length even if their value can fit into two octets.  Note: This
   is a change from IKEv1, where increased flexibility may have
   simplified the composer of messages but certainly complicated the
   parser.

   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.

   Attribute Type         Value         Attribute Format
   ------------------------------------------------------------
   Key Length (in bits)   14            TV

   Values 0-13 and 15-17 were used in a similar context in IKEv1, and
   should not be assigned except to matching values.

   The Key Length attribute specifies the key length in bits (MUST use
   network byte order) for certain transforms as follows:

   o  The Key Length attribute MUST NOT be used with transforms that use
      a fixed-length key.  For example, this includes ENCR_DES,
      ENCR_IDEA, and all the Type 2 (Pseudorandom function) and Type 3
      (Integrity Algorithm) transforms specified in this document.  It
      is recommended that future Type 2 or 3 transforms do not use this
      attribute.

   o  Some transforms specify that the Key Length attribute MUST be
      always included (omitting the attribute is not allowed, and
      proposals not containing it MUST be rejected).  For example, this
      includes ENCR_AES_CBC and ENCR_AES_CTR.

   o  Some transforms allow variable-length keys, but also specify a
      default key length if the attribute is not included.  For example,
      these transforms include ENCR_RC5 and ENCR_BLOWFISH.

   Implementation note: To further interoperability and to support
   upgrading endpoints independently, implementers of this protocol
   SHOULD accept values that they deem to supply greater security.  For
   instance, if a peer is configured to accept a variable-length cipher
   with a key length of X bits and is offered that cipher with a larger
   key length, the implementation SHOULD accept the offer if it supports
   use of the longer key.

Top      Up      ToC       Page 86 
   Support for this capability allows a responder to express a concept
   of "at least" a certain level of security -- "a key length of _at
   least_ X bits for cipher Y".  However, as the attribute is always
   returned unchanged (see the next section), an initiator willing to
   accept multiple key lengths has to include multiple transforms with
   the same Transform Type, each with a different Key Length attribute.

3.3.6.  Attribute Negotiation

   During Security Association negotiation initiators present offers to
   responders.  Responders MUST select a single complete set of
   parameters from the offers (or reject all offers if none are
   acceptable).  If there are multiple proposals, the responder MUST
   choose a single proposal.  If the selected proposal has multiple
   transforms with the same type, the responder MUST choose a single
   one.  Any attributes of a selected transform MUST be returned
   unmodified.  The initiator of an exchange MUST check that the
   accepted offer is consistent with one of its proposals, and if not
   MUST terminate the exchange.

   If the responder receives a proposal that contains a Transform Type
   it does not understand, or a proposal that is missing a mandatory
   Transform Type, it MUST consider this proposal unacceptable; however,
   other proposals in the same SA payload are processed as usual.
   Similarly, if the responder receives a transform that it does not
   understand, or one that contains a Transform Attribute it does not
   understand, it MUST consider this transform unacceptable; other
   transforms with the same Transform Type are processed as usual.  This
   allows new Transform Types and Transform Attributes to be defined in
   the future.

   Negotiating Diffie-Hellman groups presents some special challenges.
   SA offers include proposed attributes and a Diffie-Hellman public
   number (KE) in the same message.  If in the initial exchange the
   initiator offers to use one of several Diffie-Hellman groups, it
   SHOULD pick the one the responder is most likely to accept and
   include a KE corresponding to that group.  If the responder selects a
   proposal using a different Diffie-Hellman group (other than NONE),
   the responder will indicate the correct group in the response and the
   initiator SHOULD pick an element of that group for its KE value when
   retrying the first message.  It SHOULD, however, continue to propose
   its full supported set of groups in order to prevent a man-in-the-
   middle downgrade attack.  If one of the proposals offered is for the
   Diffie-Hellman group of NONE, and the responder selects that Diffie-
   Hellman group, then it MUST ignore the initiator's KE payload and
   omit the KE payload from the response.

Top      Up      ToC       Page 87 
3.4.  Key Exchange Payload

   The Key Exchange payload, denoted KE in this document, is used to
   exchange Diffie-Hellman public numbers as part of a Diffie-Hellman
   key exchange.  The Key Exchange payload consists of the IKE generic
   payload header followed by the Diffie-Hellman public value itself.

                        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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Diffie-Hellman Group Num    |           RESERVED            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Key Exchange Data                       ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 10:  Key Exchange Payload Format

   A Key Exchange payload is constructed by copying one's Diffie-Hellman
   public value into the "Key Exchange Data" portion of the payload.
   The length of the Diffie-Hellman public value for modular
   exponentiation group (MODP) groups MUST be equal to the length of the
   prime modulus over which the exponentiation was performed, prepending
   zero bits to the value if necessary.

   The Diffie-Hellman Group Num identifies the Diffie-Hellman group in
   which the Key Exchange Data was computed (see Section 3.3.2).  This
   Diffie-Hellman Group Num MUST match a Diffie-Hellman group specified
   in a proposal in the SA payload that is sent in the same message, and
   SHOULD match the Diffie-Hellman group in the first group in the first
   proposal, if such exists.  If none of the proposals in that SA
   payload specifies a Diffie-Hellman group, the KE payload MUST NOT be
   present.  If the selected proposal uses a different Diffie-Hellman
   group (other than NONE), the message MUST be rejected with a Notify
   payload of type INVALID_KE_PAYLOAD.  See also Sections 1.2 and 2.7.

   The payload type for the Key Exchange payload is thirty-four (34).

3.5.  Identification Payloads

   The Identification payloads, denoted IDi and IDr in this document,
   allow peers to assert an identity to one another.  This identity may
   be used for policy lookup, but does not necessarily have to match
   anything in the CERT payload; both fields may be used by an
   implementation to perform access control decisions.  When using the

Top      Up      ToC       Page 88 
   ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2
   does not require this address to match the address in the IP header
   of IKEv2 packets, or anything in the TSi/TSr payloads.  The contents
   of IDi/IDr are used purely to fetch the policy and authentication
   data related to the other party.

   NOTE: In IKEv1, two ID payloads were used in each direction to hold
   Traffic Selector (TS) information for data passing over the SA.  In
   IKEv2, this information is carried in TS payloads (see Section 3.13).

   The Peer Authorization Database (PAD) as described in RFC 4301
   [IPSECARCH] describes the use of the ID payload in IKEv2 and provides
   a formal model for the binding of identity to policy in addition to
   providing services that deal more specifically with the details of
   policy enforcement.  The PAD is intended to provide a link between
   the SPD and the IKE Security Association management.  See Section
   4.4.3 of RFC 4301 for more details.

   The Identification payload consists of the IKE generic payload header
   followed by identification 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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   ID Type     |                 RESERVED                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                   Identification Data                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 11:  Identification Payload Format

   o  ID Type (1 octet) - Specifies the type of Identification being
      used.

   o  RESERVED - MUST be sent as zero; MUST be ignored on receipt.

   o  Identification Data (variable length) - Value, as indicated by the
      Identification Type.  The length of the Identification Data is
      computed from the size in the ID payload header.

   The payload types for the Identification payload are thirty-five (35)
   for IDi and thirty-six (36) for IDr.

Top      Up      ToC       Page 89 
   The following table lists the assigned semantics for the
   Identification Type field.  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.

   ID Type                           Value
   -------------------------------------------------------------------
   ID_IPV4_ADDR                        1
      A single four (4) octet IPv4 address.

   ID_FQDN                             2
      A fully-qualified domain name string.  An example of an ID_FQDN
      is "example.com".  The string MUST NOT contain any terminators
      (e.g., NULL, CR, etc.). All characters in the ID_FQDN are ASCII;
      for an "internationalized domain name", the syntax is as defined
      in [IDNA], for example "xn--tmonesimerkki-bfbb.example.net".

   ID_RFC822_ADDR                      3
      A fully-qualified RFC 822 email address string.  An example of a
      ID_RFC822_ADDR is "jsmith@example.com".  The string MUST NOT
      contain any terminators.  Because of [EAI], implementations would
      be wise to treat this field as UTF-8 encoded text, not as
      pure ASCII.

   ID_IPV6_ADDR                        5
      A single sixteen (16) octet IPv6 address.

   ID_DER_ASN1_DN                      9
      The binary Distinguished Encoding Rules (DER) encoding of an
      ASN.1 X.500 Distinguished Name [PKIX].

   ID_DER_ASN1_GN                      10
      The binary DER encoding of an ASN.1 X.509 GeneralName [PKIX].

   ID_KEY_ID                           11
      An opaque octet stream that may be used to pass vendor-
      specific information necessary to do certain proprietary
      types of identification.

   Two implementations will interoperate only if each can generate a
   type of ID acceptable to the other.  To assure maximum
   interoperability, implementations MUST be configurable to send at
   least one of ID_IPV4_ADDR, ID_FQDN, ID_RFC822_ADDR, or ID_KEY_ID, and
   MUST be configurable to accept all of these four types.
   Implementations SHOULD be capable of generating and accepting all of
   these types.  IPv6-capable implementations MUST additionally be

Top      Up      ToC       Page 90 
   configurable to accept ID_IPV6_ADDR.  IPv6-only implementations MAY
   be configurable to send only ID_IPV6_ADDR instead of ID_IPV4_ADDR for
   IP addresses.

   EAP [EAP] does not mandate the use of any particular type of
   identifier, but often EAP is used with Network Access Identifiers
   (NAIs) defined in [NAI].  Although NAIs look a bit like email
   addresses (e.g., "joe@example.com"), the syntax is not exactly the
   same as the syntax of email address in [MAILFORMAT].  For those NAIs
   that include the realm component, the ID_RFC822_ADDR identification
   type SHOULD be used.  Responder implementations should not attempt to
   verify that the contents actually conform to the exact syntax given
   in [MAILFORMAT], but instead should accept any reasonable-looking
   NAI.  For NAIs that do not include the realm component, the ID_KEY_ID
   identification type SHOULD be used.

3.6.  Certificate Payload

   The Certificate payload, denoted CERT in this document, provides a
   means to transport certificates or other authentication-related
   information via IKE.  Certificate payloads SHOULD be included in an
   exchange if certificates are available to the sender.  The Hash and
   URL formats of the Certificate payloads should be used in case the
   peer has indicated an ability to retrieve this information from
   elsewhere using an HTTP_CERT_LOOKUP_SUPPORTED Notify payload.  Note
   that the term "Certificate payload" is somewhat misleading, because
   not all authentication mechanisms use certificates and data other
   than certificates may be passed in this payload.

   The Certificate 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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cert Encoding |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   ~                       Certificate Data                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 12:  Certificate Payload Format

   o  Certificate Encoding (1 octet) - This field indicates the type of
      certificate or certificate-related information contained in the
      Certificate Data field.  The values in the following table are
      only current as of the publication date of RFC 4306.  Other values

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

      Certificate Encoding                 Value
      ----------------------------------------------------
      PKCS #7 wrapped X.509 certificate    1   UNSPECIFIED
      PGP Certificate                      2   UNSPECIFIED
      DNS Signed Key                       3   UNSPECIFIED
      X.509 Certificate - Signature        4
      Kerberos Token                       6   UNSPECIFIED
      Certificate Revocation List (CRL)    7
      Authority Revocation List (ARL)      8   UNSPECIFIED
      SPKI Certificate                     9   UNSPECIFIED
      X.509 Certificate - Attribute        10  UNSPECIFIED
      Raw RSA Key                          11
      Hash and URL of X.509 certificate    12
      Hash and URL of X.509 bundle         13

   o  Certificate Data (variable length) - Actual encoding of
      certificate data.  The type of certificate is indicated by the
      Certificate Encoding field.

   The payload type for the Certificate payload is thirty-seven (37).

   Specific syntax for some of the certificate type codes above is not
   defined in this document.  The types whose syntax is defined in this
   document are:

   o  "X.509 Certificate - Signature" contains a DER-encoded X.509
      certificate whose public key is used to validate the sender's AUTH
      payload.  Note that with this encoding, if a chain of certificates
      needs to be sent, multiple CERT payloads are used, only the first
      of which holds the public key used to validate the sender's AUTH
      payload.

   o  "Certificate Revocation List" contains a DER-encoded X.509
      certificate revocation list.

   o  "Raw RSA Key" contains a PKCS #1 encoded RSA key, that is, a DER-
      encoded RSAPublicKey structure (see [RSA] and [PKCS1]).

   o  Hash and URL encodings allow IKE messages to remain short by
      replacing long data structures with a 20-octet SHA-1 hash (see
      [SHA]) of the replaced value followed by a variable-length URL
      that resolves to the DER-encoded data structure itself.  This
      improves efficiency when the endpoints have certificate data

Top      Up      ToC       Page 92 
      cached and makes IKE less subject to DoS attacks that become
      easier to mount when IKE messages are large enough to require IP
      fragmentation [DOSUDPPROT].

   The "Hash and URL of a bundle" type uses the following ASN.1
   definition for the X.509 bundle:

   CertBundle
     { iso(1) identified-organization(3) dod(6) internet(1)
       security(5) mechanisms(5) pkix(7) id-mod(0)
       id-mod-cert-bundle(34) }

   DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   IMPORTS
     Certificate, CertificateList
     FROM PKIX1Explicit88
        { iso(1) identified-organization(3) dod(6)
          internet(1) security(5) mechanisms(5) pkix(7)
          id-mod(0) id-pkix1-explicit(18) } ;

   CertificateOrCRL ::= CHOICE {
     cert [0] Certificate,
     crl  [1] CertificateList }

   CertificateBundle ::= SEQUENCE OF CertificateOrCRL

   END

   Implementations MUST be capable of being configured to send and
   accept up to four X.509 certificates in support of authentication,
   and also MUST be capable of being configured to send and accept the
   Hash and URL format (with HTTP URLs).  Implementations SHOULD be
   capable of being configured to send and accept Raw RSA keys.  If
   multiple certificates are sent, the first certificate MUST contain
   the public key used to sign the AUTH payload.  The other certificates
   may be sent in any order.

   Implementations MUST support the HTTP [HTTP] method for hash-and-URL
   lookup.  The behavior of other URL methods [URLS] is not currently
   specified, and such methods SHOULD NOT be used in the absence of a
   document specifying them.

Top      Up      ToC       Page 93 
3.7.  Certificate Request Payload

   The Certificate Request payload, denoted CERTREQ in this document,
   provides a means to request preferred certificates via IKE and can
   appear in the IKE_INIT_SA response and/or the IKE_AUTH request.
   Certificate Request payloads MAY be included in an exchange when the
   sender needs to get the certificate of the receiver.

   The Certificate Request 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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cert Encoding |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   ~                    Certification Authority                    ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

         Figure 13:  Certificate Request Payload Format

   o  Certificate Encoding (1 octet) - Contains an encoding of the type
      or format of certificate requested.  Values are listed in
      Section 3.6.

   o  Certification Authority (variable length) - Contains an encoding
      of an acceptable certification authority for the type of
      certificate requested.

   The payload type for the Certificate Request payload is thirty-eight
   (38).

   The Certificate Encoding field has the same values as those defined
   in Section 3.6.  The Certification Authority field contains an
   indicator of trusted authorities for this certificate type.  The
   Certification Authority value is a concatenated list of SHA-1 hashes
   of the public keys of trusted Certification Authorities (CAs).  Each
   is encoded as the SHA-1 hash of the Subject Public Key Info element
   (see section 4.1.2.7 of [PKIX]) from each Trust Anchor certificate.
   The 20-octet hashes are concatenated and included with no other
   formatting.

   The contents of the "Certification Authority" field are defined only
   for X.509 certificates, which are types 4, 12, and 13.  Other values
   SHOULD NOT be used until Standards-Track specifications that specify
   their use are published.

Top      Up      ToC       Page 94 
   Note that the term "Certificate Request" is somewhat misleading, in
   that values other than certificates are defined in a "Certificate"
   payload and requests for those values can be present in a Certificate
   Request payload.  The syntax of the Certificate Request payload in
   such cases is not defined in this document.

   The Certificate Request payload is processed by inspecting the "Cert
   Encoding" field to determine whether the processor has any
   certificates of this type.  If so, the "Certification Authority"
   field is inspected to determine if the processor has any certificates
   that can be validated up to one of the specified certification
   authorities.  This can be a chain of certificates.

   If an end-entity certificate exists that satisfies the criteria
   specified in the CERTREQ, a certificate or certificate chain SHOULD
   be sent back to the certificate requestor if the recipient of the
   CERTREQ:

   o  is configured to use certificate authentication,

   o  is allowed to send a CERT payload,

   o  has matching CA trust policy governing the current negotiation,
      and

   o  has at least one time-wise and usage-appropriate end-entity
      certificate chaining to a CA provided in the CERTREQ.

   Certificate revocation checking must be considered during the
   chaining process used to select a certificate.  Note that even if two
   peers are configured to use two different CAs, cross-certification
   relationships should be supported by appropriate selection logic.

   The intent is not to prevent communication through the strict
   adherence of selection of a certificate based on CERTREQ, when an
   alternate certificate could be selected by the sender that would
   still enable the recipient to successfully validate and trust it
   through trust conveyed by cross-certification, CRLs, or other out-of-
   band configured means.  Thus, the processing of a CERTREQ should be
   seen as a suggestion for a certificate to select, not a mandated one.
   If no certificates exist, then the CERTREQ is ignored.  This is not
   an error condition of the protocol.  There may be cases where there
   is a preferred CA sent in the CERTREQ, but an alternate might be
   acceptable (perhaps after prompting a human operator).

Top      Up      ToC       Page 95 
   The HTTP_CERT_LOOKUP_SUPPORTED 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).

3.8.  Authentication Payload

   The Authentication payload, denoted AUTH in this document, contains
   data used for authentication purposes.  The syntax of the
   Authentication data varies according to the Auth Method as specified
   below.

   The Authentication 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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Auth Method   |                RESERVED                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                      Authentication Data                      ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 14:  Authentication Payload Format

   o  Auth Method (1 octet) - Specifies the method of authentication
      used.  The types of signatures are listed here.  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.

   Mechanism                              Value
   -----------------------------------------------------------------
   RSA Digital Signature                  1
      Computed as specified in Section 2.15 using an RSA private key
      with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1]
      (implementers should note that IKEv1 used a different method for
      RSA signatures).  To promote interoperability, implementations
      that support this type SHOULD support signatures that use SHA-1
      as the hash function and SHOULD use SHA-1 as the default hash
      function when generating signatures.  Implementations can use the
      certificates received from a given peer as a hint for selecting a
      mutually understood hash function for the AUTH payload signature.

Top      Up      ToC       Page 96 
      Note, however, that the hash algorithm used in the AUTH payload
      signature doesn't have to be the same as any hash algorithm(s)
      used in the certificate(s).

   Shared Key Message Integrity Code      2
      Computed as specified in Section 2.15 using the shared key
      associated with the identity in the ID payload and the negotiated
      PRF.

   DSS Digital Signature                  3
      Computed as specified in Section 2.15 using a DSS private key
      (see [DSS]) over a SHA-1 hash.

   o  Authentication Data (variable length) - see Section 2.15.

   The payload type for the Authentication payload is thirty-nine (39).

3.9.  Nonce Payload

   The Nonce payload, denoted as Ni and Nr in this document for the
   initiator's and responder's nonce, respectively, contains random data
   used to guarantee liveness during an exchange and protect against
   replay attacks.

   The Nonce 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        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                            Nonce Data                         ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 15:  Nonce Payload Format

   o  Nonce Data (variable length) - Contains the random data generated
      by the transmitting entity.

   The payload type for the Nonce payload is forty (40).

   The size of the Nonce Data MUST be between 16 and 256 octets,
   inclusive.  Nonce values MUST NOT be reused.

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

   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 and REKEY_SA.  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.

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

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.

Top      Up      ToC       Page 99 
  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
      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 100 
  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 101 
   ESP_TFC_PADDING_NOT_SUPPORTED            16394
       See Section 1.3.1.

   NON_FIRST_FRAGMENTS_ALSO                 16395
       See Section 1.3.1.



(page 101 continued on part 5)

Next RFC Part