IKEv2--2

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],

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

   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].【第一对消息协商加密算法，交换随机数，
   并交换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.【第二对消息认证之前的消息，交换身份
   和证书，并建立第一个SA。消息的部分内容被加密和完整性认证，使用的密钥是
   第一对消息所生成的】

   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

   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.

       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.
   【TSi,TSr用来描述一些在CREATE_CHILD_SA交换中使用的描述符】

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