RFC 7296

两种初始交换，再往后才是 Child / INFORMATIONAL

   The SAs for ESP 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", and is sometimes called
   a "request/response pair".  The first two exchanges of messages
   establishing an IKE SA are called the IKE_SA_INIT exchange and the
   IKE_AUTH exchange; subsequent IKE exchanges are called either
   CREATE_CHILD_SA exchanges 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.

四条消息：先 DH，再认证并建立第一条 Child SA

   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.

[……下接两对消息各自做什么]

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

[……下接载荷记号]

   Notation    Payload
   -----------------------------------------
   AUTH        Authentication
   CERT        Certificate
   CERTREQ     Certificate Request
   CP          Configuration
   D           Delete
   EAP         Extensible Authentication
   HDR         IKE header (not a payload)
   IDi         Identification - Initiator
   IDr         Identification - Responder
   KE          Key Exchange
   Ni, Nr      Nonce
   N           Notify
   SA          Security Association
   SK          Encrypted and Authenticated

[……下接 IKE_SA_INIT 发起方]

   The initial exchanges are as follows:

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

   HDR contains the Security Parameter Indexes (SPIs), version numbers,
   Exchange Type, Message ID, 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.

[……下接 IKE_SA_INIT 响应]

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

[……下接 SKEYSEED 与 SK { }]

   At this point in the negotiation, each party can generate a quantity
   called SKEYSEED (see Section 2.14), from which all keys are derived
   for that IKE SA.  The messages that follow are encrypted and
   integrity protected in their entirety, with the exception of the
   message headers.  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);
   see Sections 2.13 and 2.14 for details on the key derivation.  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 Diffie-Hellman 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.

[……下接 IKE_AUTH 请求]

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

[……下接 IKE_AUTH 响应]

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

固定头 + 通用载荷头串起来

   IKE messages use UDP ports 500 and/or 4500, with one IKE message per
   UDP datagram.  Information from the beginning of the packet through
   the UDP header is largely ignored except that the IP addresses and
   UDP ports from the headers are reversed and used for return packets.
   When sent on UDP port 500, IKE messages begin immediately following
   the UDP header.  When sent on UDP port 4500, IKE messages have
   prepended four octets of zeros.  These four octets of zeros are not
   part of the IKE message and are not included in any of the length
   fields or checksums defined by IKE.  Each IKE message begins with the
   IKE header, denoted HDR in this document.  Following the header are

[……下接 Figure 4]

   The format of the IKE header is shown in Figure 4.

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Initiator's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Responder's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Payload | MjVer | MnVer | Exchange Type |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Length                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 4: IKE Header Format

[……下接 Exchange Type]

   o  Exchange Type (1 octet) - Indicates the type of exchange being
      used.  This constrains the payloads sent in each message in an
      exchange.  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.

      Exchange Type             Value
      ----------------------------------
      IKE_SA_INIT               34
      IKE_AUTH                  35
      CREATE_CHILD_SA           36
      INFORMATIONAL             37

[……下接通用载荷头 Figure 5]

   Each IKE payload defined in Sections 3.3 through 3.16 begins with a
   generic payload header, shown in Figure 5.  Figures for each payload
   below will include the generic payload header, but for brevity, the
   description of each field will be omitted.

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

                     Figure 5: Generic Payload Header

第一条 Child SA 在 IKE_AUTH 里；再要新的走这条交换

   The CREATE_CHILD_SA exchange is used to create new Child SAs and to
   rekey both IKE SAs and Child SAs.  This exchange consists of a single
   request/response pair, and some of its function 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.

[……下接创建新 Child SA 的报文]

   A Child SA may be created by sending a CREATE_CHILD_SA request.  The
   CREATE_CHILD_SA request for creating a new Child SA is:

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {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 for the proposed Child SA in the TSi
   and TSr payloads.

检测用哈希，发现 NAT 就改走 4500

   Port 4500 is reserved for UDP-encapsulated ESP and IKE.  An IPsec
   endpoint that discovers a NAT between it and its correspondent (as
   described below) MUST send all subsequent traffic from port 4500,
   which NATs should not treat specially (as they might with port 500).

   An initiator can use port 4500 for both IKE and ESP, regardless of
   whether or not there is a NAT, even at the beginning of IKE.  When
   either side is using port 4500, sending ESP with UDP encapsulation is
   not required, but understanding received UDP-encapsulated ESP packets
   is required.  UDP encapsulation MUST NOT be done on port 500.  If
   Network Address Translation Traversal (NAT-T) is supported (that is,
   if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT),
   all devices MUST be able to receive and process both UDP-encapsulated
   ESP and non-UDP-encapsulated ESP packets at any time.  Either side
   can decide whether or not to use UDP encapsulation for ESP
   irrespective of the choice made by the other side.  However, if a NAT
   is detected, both devices MUST use UDP encapsulation for ESP.

[……下接 IKE_SA_INIT 里的检测载荷]

   o  Both the IKE initiator and responder MUST include in their
      IKE_SA_INIT packets Notify payloads of type
      NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP.  Those
      payloads can be used to detect if there is NAT between the hosts,
      and which end is behind the NAT.  The location of the payloads in
      the IKE_SA_INIT packets is just after the Ni and Nr payloads
      (before the optional CERTREQ payload).

[……下接 4500 上如何区分 IKE 和 ESP]

   o  To tunnel IKE packets over UDP port 4500, the IKE header has
      four octets of zeros prepended and the result immediately follows
      the UDP header.  To tunnel ESP packets over UDP port 4500, the ESP
      header immediately follows the UDP header.  Since the first
      four octets of the ESP header contain the SPI, and the SPI cannot
      validly be zero, it is always possible to distinguish ESP and IKE
      messages.