跳到主要内容

1.1.2. Endpoint-to-Endpoint Transport Mode

1.1.2. Endpoint-to-Endpoint Transport Mode

+-+-+-+-+-+ +-+-+-+-+-+ | | 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 [IPSECARCH]. Transport mode will commonly be used with no inner IP header. 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 [ARCHPRINC], [TRANSPARENCY], and a method of limiting the inherent problems with complexity in networks noted by [ARCHGUIDEPHIL]. 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.

Kaufman, et al. Standards Track [Page 7] RFC 5996 IKEv2bis September 2010

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