| ipsecme | A. Antony |
| Internet-Draft | Phenome Networks |
| Intended status: Informational | J. Gilmore |
| Expires: September 10, 2015 | |
| P. Wouters | |
| Red Hat | |
| March 9, 2015 |
NAT-Traversal support for Opportunistic IPsec
draft-antony-ipsecme-oppo-nat-00
This document specifies how to support NATed IPsec peers for use with Opportunistic IPsec.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 10, 2015.
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The Internet Key Exchange Protocol version 2 (IKEv2), specified in [RFC7296], provides a way to negotiate tunnel mode IPsec SA's for peers behind NAT. It does not provide guidance on how to resolve the problem of multiple peers using the same pre-NAT IP address.
Responder assigned IP addresses for NATed peers also do not fully resolve the address conflict when the NATed peers are deploying opportunistic IPsec to many remote endpoints. Additional complexity of configuring many source IP addresses on the NATed peers is undesirable.
This problem is expected to be a significant issue for large scale Opportunistic IPsec deployments.
The goal of this draft is to put the burden of the additional effort required for NAT onto the host that is NAT'ed. In a hypothetical future with no NAT, no residual protocol changes would remain.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
A peer that is behind NAT is only aware of its own native IP address. While the IKEv2 NATD payloads allow the peer to find out it is behind NAT, it either has to use its own native IP address or a remote peer assigned IP address to build IPsec SA's.
Two initiators behind different NAT routers can have the same pre-NAT IP address. When these initiators attempt to setup an IPsec SA to the same responder, there will be a conflict on the responder. When the first initiator connects, the responder will install an IPsec SA for for the specific pre-NAT IP. For the second initiator, the responder cannot install an IPsec SA with the same source and destination selectors without creating a conflict. Even if it could install two identical IPsec SAs, it still needs a mechanism to decide between these two IPsec SA's. While connection tracking might be used to distinguish reply packets, there is no method for initiating a connection from the responder to one of the initiators without somehow specifying for which of the initiators the packet is meant.
When initiators behind NAT let the remote peer assign their IP to use for building the IPsec SA, the problem reverses. Initiators behind NAT can setup many IPsec SA's to different remote peers, and those remote peers might use the conflicting IP addresses. Additionally, using many IP addresses requires that the host or applications need to be aware of which source IP to use for which remote peer.
In the below workflow, the following example IP addresses are used:
Tunnel mode is used for all IPsec SA's.
In IKEv2, the IKE_INIT exchange allows the initiator and responder to detect the presense of a NAT. In this case both "road" and "east" become aware of the NAT in front of "road".
In IKEv2, the initiator can signal via the TSi payload that it is willing to receive a responder-assigned IP address for use in the IPsec SA. The responder needs to be configured with an addresspool from which it assigns unique IP addresses to the connecting initiators.
"road" sends a TSi(0.0.0.0/0) and TSr(192.1.2.42/32) request to "east" in the IKE_AUTH Exchange.
"east" assigns the first free IP address from its pool - 10.1.2.1 - to this prospective client and sends a TSI(10.1.2.1/32) and TSr(192.1.2.42/32) back to "road".
The IKE_AUTH Exchange completes as normal. This could be an authenticated exchange or an exchange without authentication using AUTH_NULL as specified in [IKE-AUTH-NULL].
"road", upon receiving east's TSi/TSr - and a successfull completion of the IKE_AUTH Exchange - two tasks:
It ensures that the destination based NAT rule is processed before IPsec processing begins.
The responder has no specific handling it needs to perform apart from a willingness to assign IP addresses if an initiator requests one via the special TSi(0.0.0.0/0). If the initiator sends a TSi() that matches the IP address of the IKE message, the responder should agree to use that address instead of assigning one from its addresspool.
The NAT rule can be implemented in the Networking subsystem of the host kernel, but this specific IPsec-NAT rule could also be implemented as part of the IPsec subsystem.
The initiator host and any application running on the initiator should not need to be aware of this construct. The responder assigned IP address does not need to be configured on the host. It only needs to exist in the NAT rule and the IPsec SA.
[placeholder]
This NAT mapping method MUST only be used for host-to-host IPsec tunnels. It MUST NOT be used for net-to-net IPsec tunnels.
An address from the addresspool should not be re-used quickly to avoid sending traffic meant for one initiator to another initiator.
None so far
This Internet Draft includes no request to IANA.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4301] | Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. |
| [RFC7296] | Kaufman, C., Hoffman, P., Nir, Y., Eronen, P. and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, October 2014. |
| [IKE-AUTH-NULL] | Smyslov, Valery. and Paul. Wouters, "The NULL Authentication Method in IKEv2 Protocol", Internet-Draft draft-ietf-ipsecme-ikev2-null-auth, February 2015. |
| [RFC7258] | Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014. |
| [RFC7435] | Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, December 2014. |