Internet DRAFT - draft-intoto-simple-mobility-ipsec-clients
draft-intoto-simple-mobility-ipsec-clients
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 <draft-intoto-simple-mobility-ipsec-clients-00>,
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]
