Network Working Group Srinivasa Murthy Internet-Draft intoto Intended status: Standard Track May 18, 2008 Expires: November 18, 2008 Simple Mobility Solution for IPsec Clients draft-intoto-simple-mobility-ipsec-clients-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Forcing NAT Traversal . . . . . . . . . . . . . . . . . . . . 3 3. Forcing UDP Encapsulation . . . . . . . . . . . . . . . . . . 4 4. Gateway adaptation . . . . . . . . . . . . . . . . . . . . . 4 5. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . .6 Intellectual Property Statement . . . . . . . . . . . . . . . . . . 6 Srinivasa Murthy Expires November 18, 2008 [Page 1] INTERNET-DRAFT Simple Mobility Solution for IPsec Clients. 18 May 2008 Requirements Language 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 RFC 2119. Abstract One very popular use of VPNs is to provide telecommuter access to the corporate Intranet. Remote clients that are behind NAT boxes can also access the corporate intranet with the help of the standard NAT Traversal feature. But this access may be disturbed in scenarios where a mobile user roams across different points of attachment and there by getting assigned with different IP Addresses. The access also fails in cases where the client roams across environments with NAT to environments without NAT and vice versa. In both the cases the tunnel may get re-established but it induces jitter in voice sessions. This draft proposes the following measures to solve the above problems. It proposes that the NAT-Traversal MUST always be enabled even when NAT is not detected. It also proposes that the client and the remote Gateway to dynamically update the change in clients IP Address. The advantage with this solution is that, it works for both IKEv1 and [IKEv2] deployments and is much simpler than [MOBIKE]. 1. Introduction IPsec protocol is being increasingly used by many Enterprises to provide secure remote connectivity to internal networks so that the tele-commuters or 'on road' employees have a secure access to these internal networks. Applications on the remote clients use the private IP Address assigned by the IPsec Gateway to communicate with the Enterprise servers and ISP provided IP Address is used as the outer IP Address to tunnel the traffic securely to the Enterprise Gateway. Since Applications on client use private IP Address, any change in the ISP provided IP Address does not destroy the IP connections to Enterprise networks. This is particularly helpful to mobile users. The mobile users may get different IP Addresses across different points of attachment to different networks. As long as the private IP Address does not change; there is no disconnection of voice calls or data sessions. Srinivasa Murthy Expires November 18, 2008 [Page 2] INTERNET-DRAFT Simple Mobility Solution for IPsec Clients. 18 May 2008 When the outer IP Address (ISP provided address) changes,the IPsec client creates a new tunnel to the IPsec Gateway. For voice and other real time multi-media applications, this re-establishment of tunnel introduces unacceptable jitter. With the proposed solution, both IPsec Gateway and IPsec Client adopt to the change in clients IP Address and change the tunnel address securely, thus avoiding expensive tunnel creation and thereby providing smooth transition. This solution proposes that NAT-Traversal MUST always be enabled as the client may move from a network with NAT to a Network without NAT and vice versa. 2. Forcing NAT Traversal NAT-Traversal MUST be enabled always even if no NAT activity is detected during IKE negotiations. Alternately NAT-T can be enforced by sending a NAT-D payload with 0. In any case both the parties switch to port 4500. 2.1 IKEv2 In case of IKEv2,both the IKE initiator and the responder include Notify payloads of type NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP in their IKE_SA_INIT packets to detect the presence of NAT between them, and to know which end is behind the NAT. Both the initiator and the responder MUST set the Notification data fields of the above two Notify Payloads to zero to enforce the receiving side to enable NAT-Traversal as the checksums won't match. 2.2 IKEv1 In case of IKEv1,both the initiator and the responder MUST send the vendor ID payload in the first two messages of Phase1 negotiation to declare their support for NAT-Traversal. The actual payload is explained in section 3.1 of RFC 3947. The NAT-D payloads are then exchanged to detect the presence of NAT between the two IKE peers, and to detect where the NAT is. The NAT-D payloads are included in the third and fourth packets of Main Mode, and in the second and third packets in the Aggressive Mode. Both the initiator and the responder MUST set the data part of the NAT-D payloads to zero to enforce the receiving side to enable NAT-Traversal as the checksums won't match. Srinivasa Murthy Expires November 18, 2008 [Page 3] INTERNET-DRAFT Simple Mobility Solution for IPsec Clients. 18 May 2008 3.Forcing UDP Encapsulation Both the IKE and the ESP packets are to be encapsulated/decapsulated using the UDP protocol as explained in RFC 3947 and RFC 4306.Tunnel mode UDP encapsulation MUST be enforced for both IKE and ESP packets. In case of IKEv1,encapsulation mode is negotiated in Quick mode using the SA payloads.The negotiation MUST include only the option "UDP-Encapsulated-Tunnel 3" to enforce Tunnel based UDP encapsulation of ESP packets. 4.Gateway adaptation The clients IP Address may change due to its mobility. It may move from behind NAT to NAT free networks and vice versa. The IP Address of the client (local Gateway) as seen by remote Gateway may also change due to expiry of NAT mappings as explained in RFC 3947. This change in clients IP Address, which is used as the outer IP Address for the IPsec tunnel, results in re-establishment of IPsec tunnel. This may not be acceptable to networks carrying voice. This method proposes that both the client and the remote Gateway shall dynamically update their IPsec and IKE SAs with the change in IP Address of the client to avoid the break up and re-establishment of the tunnel. The local Gateway i.e. the client MUST update its IPsec and IKE SAs with the change in its IP Address. The remote Gateway shall use all the authenticated IKE and the UDP-encapsulated ESP packets received to adapt to the changes in IP Address and port as explained in RFC 3947 and RFC 4306. The remote Gateway shall decrypt such packets and verify the SA Policy and perform the replay attack check. Subsequently it MUST update the remote IP Address in its outbound SA with the new IP Address. This allows the outbound packets to be sent to the correct remote peer. Similarly IKE shall also update its SA with the new IP Address. 5.Limitations and Assumptions Tunnel mode UDP encapsulation is always assumed to be enabled. It may result in extra bandwidth consumption in deployments where NAT is not present. Srinivasa Murthy Expires November 18, 2008 [Page 4] INTERNET-DRAFT Simple Mobility Solution for IPsec Clients. 18 May 2008 As NAT-Traversal is always enabled, AH protocol will not work even when the client is not behind NAT. Only client can initiate the first time tunnel establishment. When client IP or NAT gateway address is changed, the packets from remote gateway get dropped by NAT device until the remote gateway adapts to the change and update the destination IP address in its outbound SA. 6. Security Considerations Updating the IKE SA/ESP UDP encapsulation IP addresses and ports for each valid authenticated packet can cause DoS if an attacker can listen to all traffic in the network, change the order of the packets, and inject new packets before the packet he has already seen. In other words, the attacker can take an authenticated packet from the host behind NAT, change the packet UDP source or destination ports or IP addresses and send it out to the other end before the real packet reaches it. The host not behind the NAT will update its IP address and port mapping and send further traffic to the wrong host or port. This situation is fixed immediately when the attacker stops modifying the packets, as the first real packet will fix the situation. Implementations should AUDIT the event every time the mapping is changed, as it should not happen that often. 7. IANA Considerations This document has no actions for IANA. 8. References 8.1. Normative References [IKEv2] C. Kaufman, "Internet Key Exchange (IKEv2) Protocol", RFC4306 [MOBIKE] P. Eronen, "IKEv2 Mobility and Multihoming Protocol", RFC 4555 Acknowledgments Thanks to Addepalli Srinivasa Rao and GNVV Raghava Rao for useful discussions of this problem space. Srinivasa Murthy Expires November 18, 2008 [Page 5] INTERNET-DRAFT Simple Mobility Solution for IPsec Clients. 18 May 2008 Author's Address Srinivasa Murthy Intoto Software India Private Ltd. UMA Plaza - Nagarjuna Circle, Punjagutta Hyderabad-500038, India. Email: nsmurthy@intoto.com Comments are solicited and should be addressed to the working group's mailing list at ipsec@ietf.org and/or the author(s). Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Srinivasa Murthy Expires November 18, 2008 [Page 6] INTERNET-DRAFT Simple Mobility Solution for IPsec Clients. 18 May 2008 Expiration Date This memo is filed as , and expires on November 18, 2008. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity(IASA). Srinivasa Murthy Expires November 18, 2008 [Page 7]