IKEv2-3

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