tech-invite   World Map     

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

RFC 4306


Pages: 99
Top     in Index     Prev     Next
 

Internet Key Exchange (IKEv2) Protocol

Part 1 of 5, p. 1 to 12
None       Next RFC Part

Obsoleted by:    5996
Obsoletes:    2407    2408    2409
Updated by:    5282


Top       ToC       Page 1 
Network Working Group                                    C. Kaufman, Ed.
Request for Comments: 4306                                     Microsoft
Obsoletes: 2407, 2408, 2409                                December 2005
Category: Standards Track


                 Internet Key Exchange (IKEv2) Protocol

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes version 2 of the Internet Key Exchange (IKE)
   protocol.  IKE is a component of IPsec used for performing mutual
   authentication and establishing and maintaining security associations
   (SAs).

   This version of the IKE specification combines the contents of what
   were previously separate documents, including Internet Security
   Association and Key Management Protocol (ISAKMP, RFC 2408), IKE (RFC
   2409), the Internet Domain of Interpretation (DOI, RFC 2407), Network
   Address Translation (NAT) Traversal, Legacy authentication, and
   remote address acquisition.

   Version 2 of IKE does not interoperate with version 1, but it has
   enough of the header format in common that both versions can
   unambiguously run over the same UDP port.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................3
      1.1. Usage Scenarios ............................................5
      1.2. The Initial Exchanges ......................................7
      1.3. The CREATE_CHILD_SA Exchange ...............................9
      1.4. The INFORMATIONAL Exchange ................................11
      1.5. Informational Messages outside of an IKE_SA ...............12
   2. IKE Protocol Details and Variations ............................12
      2.1. Use of Retransmission Timers ..............................13
      2.2. Use of Sequence Numbers for Message ID ....................14
      2.3. Window Size for Overlapping Requests ......................14
      2.4. State Synchronization and Connection Timeouts .............15
      2.5. Version Numbers and Forward Compatibility .................17
      2.6. Cookies ...................................................18
      2.7. Cryptographic Algorithm Negotiation .......................21
      2.8. Rekeying ..................................................22
      2.9. Traffic Selector Negotiation ..............................24
      2.10. Nonces ...................................................26
      2.11. Address and Port Agility .................................26
      2.12. Reuse of Diffie-Hellman Exponentials .....................27
      2.13. Generating Keying Material ...............................27
      2.14. Generating Keying Material for the IKE_SA ................28
      2.15. Authentication of the IKE_SA .............................29
      2.16. Extensible Authentication Protocol Methods ...............31
      2.17. Generating Keying Material for CHILD_SAs .................33
      2.18. Rekeying IKE_SAs Using a CREATE_CHILD_SA exchange ........34
      2.19. Requesting an Internal Address on a Remote Network .......34
      2.20. Requesting the Peer's Version ............................35
      2.21. Error Handling ...........................................36
      2.22. IPComp ...................................................37
      2.23. NAT Traversal ............................................38
      2.24. Explicit Congestion Notification (ECN) ...................40
   3. Header and Payload Formats .....................................41
      3.1. The IKE Header ............................................41
      3.2. Generic Payload Header ....................................44
      3.3. Security Association Payload ..............................46
      3.4. Key Exchange Payload ......................................56
      3.5. Identification Payloads ...................................56
      3.6. Certificate Payload .......................................59
      3.7. Certificate Request Payload ...............................61
      3.8. Authentication Payload ....................................63
      3.9. Nonce Payload .............................................64
      3.10. Notify Payload ...........................................64
      3.11. Delete Payload ...........................................72
      3.12. Vendor ID Payload ........................................73
      3.13. Traffic Selector Payload .................................74
      3.14. Encrypted Payload ........................................77

Top      ToC       Page 3 
      3.15. Configuration Payload ....................................79
      3.16. Extensible Authentication Protocol (EAP) Payload .........84
   4. Conformance Requirements .......................................85
   5. Security Considerations ........................................88
   6. IANA Considerations ............................................90
   7. Acknowledgements ...............................................91
   8. References .....................................................91
      8.1. Normative References ......................................91
      8.2. Informative References ....................................92
   Appendix A: Summary of Changes from IKEv1 .........................96
   Appendix B: Diffie-Hellman Groups .................................97
      B.1. Group 1 - 768 Bit MODP ....................................97
      B.2. Group 2 - 1024 Bit MODP ...................................97

1.  Introduction

   IP Security (IPsec) provides confidentiality, data integrity, access
   control, and data source authentication to IP datagrams.  These
   services are provided by maintaining shared state between the source
   and the sink of an IP datagram.  This state defines, among other
   things, the specific services provided to the datagram, which
   cryptographic algorithms will be used to provide the services, and
   the keys used as input to the cryptographic algorithms.

   Establishing this shared state in a manual fashion does not scale
   well.  Therefore, a protocol to establish this state dynamically is
   needed.  This memo describes such a protocol -- the Internet Key
   Exchange (IKE).  This is version 2 of IKE.  Version 1 of IKE was
   defined in RFCs 2407, 2408, and 2409 [Pip98, MSST98, HC98].  This
   single document is intended to replace all three of those RFCs.

   Definitions of the primitive terms in this document (such as Security
   Association or SA) can be found in [RFC4301].

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [Bra97].

   The term "Expert Review" is to be interpreted as defined in
   [RFC2434].

   IKE performs mutual authentication between two parties and
   establishes an IKE security association (SA) that includes shared
   secret information that can be used to efficiently establish SAs for
   Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication
   Header (AH) [RFC4302] and a set of cryptographic algorithms to be
   used by the SAs to protect the traffic that they carry.  In this
   document, the term "suite" or "cryptographic suite" refers to a

Top      ToC       Page 4 
   complete set of algorithms used to protect an SA.  An initiator
   proposes one or more suites by listing supported algorithms that can
   be combined into suites in a mix-and-match fashion.  IKE can also
   negotiate use of IP Compression (IPComp) [IPCOMP] in connection with
   an ESP and/or AH SA.  We call the IKE SA an "IKE_SA".  The SAs for
   ESP and/or AH that get set up through that IKE_SA we call
   "CHILD_SAs".

   All IKE communications consist of pairs of messages: a request and a
   response.  The pair is called an "exchange".  We call the first
   messages establishing an IKE_SA IKE_SA_INIT and IKE_AUTH exchanges
   and subsequent IKE exchanges CREATE_CHILD_SA or INFORMATIONAL
   exchanges.  In the common case, there is a single IKE_SA_INIT
   exchange and a single IKE_AUTH exchange (a total of four messages) to
   establish the IKE_SA and the first CHILD_SA.  In exceptional cases,
   there may be more than one of each of these exchanges.  In all cases,
   all IKE_SA_INIT exchanges MUST complete before any other exchange
   type, then all IKE_AUTH exchanges MUST complete, and following that
   any number of CREATE_CHILD_SA and INFORMATIONAL exchanges may occur
   in any order.  In some scenarios, only a single CHILD_SA is needed
   between the IPsec endpoints, and therefore there would be no
   additional exchanges.  Subsequent exchanges MAY be used to establish
   additional CHILD_SAs between the same authenticated pair of endpoints
   and to perform housekeeping functions.

   IKE message flow always consists of a request followed by a response.
   It is the responsibility of the requester to ensure reliability.  If
   the response is not received within a timeout interval, the requester
   needs to retransmit the request (or abandon the connection).

   The first request/response of an IKE session (IKE_SA_INIT) negotiates
   security parameters for the IKE_SA, sends nonces, and sends Diffie-
   Hellman values.

   The second request/response (IKE_AUTH) transmits identities, proves
   knowledge of the secrets corresponding to the two identities, and
   sets up an SA for the first (and often only) AH and/or ESP CHILD_SA.

   The types of subsequent exchanges are CREATE_CHILD_SA (which creates
   a CHILD_SA) and INFORMATIONAL (which deletes an SA, reports error
   conditions, or does other housekeeping).  Every request requires a
   response.  An INFORMATIONAL request with no payloads (other than the
   empty Encrypted payload required by the syntax) is commonly used as a
   check for liveness.  These subsequent exchanges cannot be used until
   the initial exchanges have completed.

Top      ToC       Page 5 
   In the description that follows, we assume that no errors occur.
   Modifications to the flow should errors occur are described in
   section 2.21.

1.1.  Usage Scenarios

   IKE is expected to be used to negotiate ESP and/or AH SAs in a number
   of different scenarios, each with its own special requirements.

1.1.1.  Security Gateway to Security Gateway Tunnel

                    +-+-+-+-+-+            +-+-+-+-+-+
                    !         ! IPsec      !         !
       Protected    !Tunnel   ! tunnel     !Tunnel   !     Protected
       Subnet   <-->!Endpoint !<---------->!Endpoint !<--> Subnet
                    !         !            !         !
                    +-+-+-+-+-+            +-+-+-+-+-+

             Figure 1:  Security Gateway to Security Gateway Tunnel

   In this scenario, neither endpoint of the IP connection implements
   IPsec, but network nodes between them protect traffic for part of the
   way.  Protection is transparent to the endpoints, and depends on
   ordinary routing to send packets through the tunnel endpoints for
   processing.  Each endpoint would announce the set of addresses
   "behind" it, and packets would be sent in tunnel mode where the inner
   IP header would contain the IP addresses of the actual endpoints.

1.1.2.  Endpoint-to-Endpoint Transport

       +-+-+-+-+-+                                          +-+-+-+-+-+
       !         !                 IPsec transport          !         !
       !Protected!                or tunnel mode SA         !Protected!
       !Endpoint !<---------------------------------------->!Endpoint !
       !         !                                          !         !
       +-+-+-+-+-+                                          +-+-+-+-+-+

                       Figure 2:  Endpoint to Endpoint

   In this scenario, both endpoints of the IP connection implement
   IPsec, as required of hosts in [RFC4301].  Transport mode will
   commonly be used with no inner IP header.  If there is an inner IP
   header, the inner addresses will be the same as the outer addresses.
   A single pair of addresses will be negotiated for packets to be
   protected by this SA.  These endpoints MAY implement application
   layer access controls based on the IPsec authenticated identities of
   the participants.  This scenario enables the end-to-end security that
   has been a guiding principle for the Internet since [RFC1958],

Top      ToC       Page 6 
   [RFC2775], and a method of limiting the inherent problems with
   complexity in networks noted by [RFC3439].  Although this scenario
   may not be fully applicable to the IPv4 Internet, it has been
   deployed successfully in specific scenarios within intranets using
   IKEv1.  It should be more broadly enabled during the transition to
   IPv6 and with the adoption of IKEv2.

   It is possible in this scenario that one or both of the protected
   endpoints will be behind a network address translation (NAT) node, in
   which case the tunneled packets will have to be UDP encapsulated so
   that port numbers in the UDP headers can be used to identify
   individual endpoints "behind" the NAT (see section 2.23).

1.1.3.  Endpoint to Security Gateway Tunnel

       +-+-+-+-+-+                          +-+-+-+-+-+
       !         !         IPsec            !         !     Protected
       !Protected!         tunnel           !Tunnel   !     Subnet
       !Endpoint !<------------------------>!Endpoint !<--- and/or
       !         !                          !         !     Internet
       +-+-+-+-+-+                          +-+-+-+-+-+

                 Figure 3:  Endpoint to Security Gateway Tunnel

   In this scenario, a protected endpoint (typically a portable roaming
   computer) connects back to its corporate network through an IPsec-
   protected tunnel.  It might use this tunnel only to access
   information on the corporate network, or it might tunnel all of its
   traffic back through the corporate network in order to take advantage
   of protection provided by a corporate firewall against Internet-based
   attacks.  In either case, the protected endpoint will want an IP
   address associated with the security gateway so that packets returned
   to it will go to the security gateway and be tunneled back.  This IP
   address may be static or may be dynamically allocated by the security
   gateway.  In support of the latter case, IKEv2 includes a mechanism
   for the initiator to request an IP address owned by the security
   gateway for use for the duration of its SA.

   In this scenario, packets will use tunnel mode.  On each packet from
   the protected endpoint, the outer IP header will contain the source
   IP address associated with its current location (i.e., the address
   that will get traffic routed to the endpoint directly), while the
   inner IP header will contain the source IP address assigned by the
   security gateway (i.e., the address that will get traffic routed to
   the security gateway for forwarding to the endpoint).  The outer
   destination address will always be that of the security gateway,
   while the inner destination address will be the ultimate destination
   for the packet.

Top      ToC       Page 7 
   In this scenario, it is possible that the protected endpoint will be
   behind a NAT.  In that case, the IP address as seen by the security
   gateway will not be the same as the IP address sent by the protected
   endpoint, and packets will have to be UDP encapsulated in order to be
   routed properly.

1.1.4.  Other Scenarios

   Other scenarios are possible, as are nested combinations of the
   above.  One notable example combines aspects of 1.1.1 and 1.1.3. A
   subnet may make all external accesses through a remote security
   gateway using an IPsec tunnel, where the addresses on the subnet are
   routed to the security gateway by the rest of the Internet.  An
   example would be someone's home network being virtually on the
   Internet with static IP addresses even though connectivity is
   provided by an ISP that assigns a single dynamically assigned IP
   address to the user's security gateway (where the static IP addresses
   and an IPsec relay are provided by a third party located elsewhere).

1.2.  The Initial Exchanges

   Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH
   exchanges (known in IKEv1 as Phase 1).  These initial exchanges
   normally consist of four messages, though in some scenarios that
   number can grow.  All communications using IKE consist of
   request/response pairs.  We'll describe the base exchange first,
   followed by variations.  The first pair of messages (IKE_SA_INIT)
   negotiate cryptographic algorithms, exchange nonces, and do a
   Diffie-Hellman exchange [DH].

   The second pair of messages (IKE_AUTH) authenticate the previous
   messages, exchange identities and certificates, and establish the
   first CHILD_SA.  Parts of these messages are encrypted and integrity
   protected with keys established through the IKE_SA_INIT exchange, so
   the identities are hidden from eavesdroppers and all fields in all
   the messages are authenticated.

   In the following descriptions, the payloads contained in the message
   are indicated by names as listed below.

   Notation    Payload

   AUTH      Authentication
   CERT      Certificate
   CERTREQ   Certificate Request
   CP        Configuration
   D         Delete
   E         Encrypted

Top      ToC       Page 8 
   EAP       Extensible Authentication
   HDR       IKE Header
   IDi       Identification - Initiator
   IDr       Identification - Responder
   KE        Key Exchange
   Ni, Nr    Nonce
   N         Notify
   SA        Security Association
   TSi       Traffic Selector - Initiator
   TSr       Traffic Selector - Responder
   V         Vendor ID

   The details of the contents of each payload are described in section
   3.  Payloads that may optionally appear will be shown in brackets,
   such as [CERTREQ], indicate that optionally a certificate request
   payload can be included.

   The initial exchanges are as follows:

       Initiator                          Responder
      -----------                        -----------
       HDR, SAi1, KEi, Ni   -->

   HDR contains the Security Parameter Indexes (SPIs), version numbers,
   and flags of various sorts.  The SAi1 payload states the
   cryptographic algorithms the initiator supports for the IKE_SA.  The
   KE payload sends the initiator's Diffie-Hellman value.  Ni is the
   initiator's nonce.

                            <--    HDR, SAr1, KEr, Nr, [CERTREQ]

   The responder chooses a cryptographic suite from the initiator's
   offered choices and expresses that choice in the SAr1 payload,
   completes the Diffie-Hellman exchange with the KEr payload, and sends
   its nonce in the Nr payload.

   At this point in the negotiation, each party can generate SKEYSEED,
   from which all keys are derived for that IKE_SA.  All but the headers
   of all the messages that follow are encrypted and integrity
   protected.  The keys used for the encryption and integrity protection
   are derived from SKEYSEED and are known as SK_e (encryption) and SK_a
   (authentication, a.k.a.  integrity protection).  A separate SK_e and
   SK_a is computed for each direction.  In addition to the keys SK_e
   and SK_a derived from the DH value for protection of the IKE_SA,
   another quantity SK_d is derived and used for derivation of further
   keying material for CHILD_SAs.  The notation SK { ... } indicates
   that these payloads are encrypted and integrity protected using that
   direction's SK_e and SK_a.

Top      ToC       Page 9 
       HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,]
                  AUTH, SAi2, TSi, TSr}     -->

   The initiator asserts its identity with the IDi payload, proves
   knowledge of the secret corresponding to IDi and integrity protects
   the contents of the first message using the AUTH payload (see section
   2.15).  It might also send its certificate(s) in CERT payload(s) and
   a list of its trust anchors in CERTREQ payload(s).  If any CERT
   payloads are included, the first certificate provided MUST contain
   the public key used to verify the AUTH field.  The optional payload
   IDr enables the initiator to specify which of the responder's
   identities it wants to talk to.  This is useful when the machine on
   which the responder is running is hosting multiple identities at the
   same IP address.  The initiator begins negotiation of a CHILD_SA
   using the SAi2 payload.  The final fields (starting with SAi2) are
   described in the description of the CREATE_CHILD_SA exchange.

                                   <--    HDR, SK {IDr, [CERT,] AUTH,
                                                SAr2, TSi, TSr}

   The responder asserts its identity with the IDr payload, optionally
   sends one or more certificates (again with the certificate containing
   the public key used to verify AUTH listed first), authenticates its
   identity and protects the integrity of the second message with the
   AUTH payload, and completes negotiation of a CHILD_SA with the
   additional fields described below in the CREATE_CHILD_SA exchange.

   The recipients of messages 3 and 4 MUST verify that all signatures
   and MACs are computed correctly and that the names in the ID payloads
   correspond to the keys used to generate the AUTH payload.

1.3.  The CREATE_CHILD_SA Exchange

   This exchange consists of a single request/response pair, and was
   referred to as a phase 2 exchange in IKEv1.  It MAY be initiated by
   either end of the IKE_SA after the initial exchanges are completed.

   All messages following the initial exchange are cryptographically
   protected using the cryptographic algorithms and keys negotiated in
   the first two messages of the IKE exchange.  These subsequent
   messages use the syntax of the Encrypted Payload described in section
   3.14.  All subsequent messages included an Encrypted Payload, even if
   they are referred to in the text as "empty".

   Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
   section the term "initiator" refers to the endpoint initiating this
   exchange.

Top      ToC       Page 10 
   A CHILD_SA is created by sending a CREATE_CHILD_SA request.  The
   CREATE_CHILD_SA request MAY optionally contain a KE payload for an
   additional Diffie-Hellman exchange to enable stronger guarantees of
   forward secrecy for the CHILD_SA.  The keying material for the
   CHILD_SA is a function of SK_d established during the establishment
   of the IKE_SA, the nonces exchanged during the CREATE_CHILD_SA
   exchange, and the Diffie-Hellman value (if KE payloads are included
   in the CREATE_CHILD_SA exchange).

   In the CHILD_SA created as part of the initial exchange, a second KE
   payload and nonce MUST NOT be sent.  The nonces from the initial
   exchange are used in computing the keys for the CHILD_SA.

   The CREATE_CHILD_SA request contains:

       Initiator                                 Responder
      -----------                               -----------
       HDR, SK {[N], SA, Ni, [KEi],
           [TSi, TSr]}             -->

   The initiator sends SA offer(s) in the SA payload, a nonce in the Ni
   payload, optionally a Diffie-Hellman value in the KEi payload, and
   the proposed traffic selectors in the TSi and TSr payloads.  If this
   CREATE_CHILD_SA exchange is rekeying an existing SA other than the
   IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA
   being rekeyed.  If this CREATE_CHILD_SA exchange is not rekeying an
   existing SA, the N payload MUST be omitted.  If the SA offers include
   different Diffie-Hellman groups, KEi MUST be an element of the group
   the initiator expects the responder to accept.  If it guesses wrong,
   the CREATE_CHILD_SA exchange will fail, and it will have to retry
   with a different KEi.

   The message following the header is encrypted and the message
   including the header is integrity protected using the cryptographic
   algorithms negotiated for the IKE_SA.

   The CREATE_CHILD_SA response contains:

                                  <--    HDR, SK {SA, Nr, [KEr],
                                               [TSi, TSr]}

   The responder replies (using the same Message ID to respond) with the
   accepted offer in an SA payload, and a Diffie-Hellman value in the
   KEr payload if KEi was included in the request and the selected
   cryptographic suite includes that group.  If the responder chooses a
   cryptographic suite with a different group, it MUST reject the
   request.  The initiator SHOULD repeat the request, but now with a KEi
   payload from the group the responder selected.

Top      ToC       Page 11 
   The traffic selectors for traffic to be sent on that SA are specified
   in the TS payloads, which may be a subset of what the initiator of
   the CHILD_SA proposed.  Traffic selectors are omitted if this
   CREATE_CHILD_SA request is being used to change the key of the
   IKE_SA.

1.4.  The INFORMATIONAL Exchange

   At various points during the operation of an IKE_SA, peers may desire
   to convey control messages to each other regarding errors or
   notifications of certain events.  To accomplish this, IKE defines an
   INFORMATIONAL exchange.  INFORMATIONAL exchanges MUST ONLY occur
   after the initial exchanges and are cryptographically protected with
   the negotiated keys.

   Control messages that pertain to an IKE_SA MUST be sent under that
   IKE_SA.  Control messages that pertain to CHILD_SAs MUST be sent
   under the protection of the IKE_SA which generated them (or its
   successor if the IKE_SA was replaced for the purpose of rekeying).

   Messages in an INFORMATIONAL exchange contain zero or more
   Notification, Delete, and Configuration payloads.  The Recipient of
   an INFORMATIONAL exchange request MUST send some response (else the
   Sender will assume the message was lost in the network and will
   retransmit it).  That response MAY be a message with no payloads.
   The request message in an INFORMATIONAL exchange MAY also contain no
   payloads.  This is the expected way an endpoint can ask the other
   endpoint to verify that it is alive.

   ESP and AH SAs always exist in pairs, with one SA in each direction.
   When an SA is closed, both members of the pair MUST be closed.  When
   SAs are nested, as when data (and IP headers if in tunnel mode) are
   encapsulated first with IPComp, then with ESP, and finally with AH
   between the same pair of endpoints, all of the SAs MUST be deleted
   together.  Each endpoint MUST close its incoming SAs and allow the
   other endpoint to close the other SA in each pair.  To delete an SA,
   an INFORMATIONAL exchange with one or more delete payloads is sent
   listing the SPIs (as they would be expected in the headers of inbound
   packets) of the SAs to be deleted.  The recipient MUST close the
   designated SAs.  Normally, the reply in the INFORMATIONAL exchange
   will contain delete payloads for the paired SAs going in the other
   direction.  There is one exception.  If by chance both ends of a set
   of SAs independently decide to close them, each may send a delete
   payload and the two requests may cross in the network.  If a node
   receives a delete request for SAs for which it has already issued a
   delete request, it MUST delete the outgoing SAs while processing the
   request and the incoming SAs while processing the response.  In that

Top      ToC       Page 12 
   case, the responses MUST NOT include delete payloads for the deleted
   SAs, since that would result in duplicate deletion and could in
   theory delete the wrong SA.

   A node SHOULD regard half-closed connections as anomalous and audit
   their existence should they persist.  Note that this specification
   nowhere specifies time periods, so it is up to individual endpoints
   to decide how long to wait.  A node MAY refuse to accept incoming
   data on half-closed connections but MUST NOT unilaterally close them
   and reuse the SPIs.  If connection state becomes sufficiently messed
   up, a node MAY close the IKE_SA; doing so will implicitly close all
   SAs negotiated under it.  It can then rebuild the SAs it needs on a
   clean base under a new IKE_SA.

   The INFORMATIONAL exchange is defined as:

       Initiator                        Responder
      -----------                      -----------
       HDR, SK {[N,] [D,] [CP,] ...} -->
                                   <-- HDR, SK {[N,] [D,] [CP], ...}

   The processing of an INFORMATIONAL exchange is determined by its
   component payloads.

1.5.  Informational Messages outside of an IKE_SA

   If an encrypted IKE packet arrives on port 500 or 4500 with an
   unrecognized SPI, it could be because the receiving node has recently
   crashed and lost state or because of some other system malfunction or
   attack.  If the receiving node has an active IKE_SA to the IP address
   from whence the packet came, it MAY send a notification of the
   wayward packet over that IKE_SA in an INFORMATIONAL exchange.  If it
   does not have such an IKE_SA, it MAY send an Informational message
   without cryptographic protection to the source IP address.  Such a
   message is not part of an informational exchange, and the receiving
   node MUST NOT respond to it.  Doing so could cause a message loop.



(page 12 continued on part 2)

Next RFC Part