< draft-ietf-mip4-vpn-problem-solution-04.txt   draft-ietf-mip4-vpn-problem-solution-05.txt >
Mobile IP S. Vaarala Mobile IP S. Vaarala
Internet-Draft Codebay Internet-Draft Codebay
Intended status: Best Current E. Klovning Intended status: Standards Track E. Klovning
Practice Birdstep Expires: September 15, 2008 Birdstep
Expires: June 14, 2008 December 12, 2007 March 14, 2008
Mobile IPv4 Traversal Across IPsec-based VPN Gateways Mobile IPv4 Traversal Across IPsec-based VPN Gateways
draft-ietf-mip4-vpn-problem-solution-04 draft-ietf-mip4-vpn-problem-solution-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 14, 2008. This Internet-Draft will expire on September 15, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document outlines a solution for the Mobile IPv4 and IPsec This document outlines a solution for the Mobile IPv4 and IPsec
coexistence problem for enterprise users. The solution consists of coexistence problem for enterprise users. The solution consists of
an applicability statement for using Mobile IPv4 and IPsec for an applicability statement for using Mobile IPv4 and IPsec for
session mobility in corporate remote access scenarios, and a required session mobility in corporate remote access scenarios, and a required
mechanism for detecting the trusted internal network securely. mechanism for detecting the trusted internal network securely.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Related work . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Related work . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Terms and abbreviations . . . . . . . . . . . . . . . . . 6 1.4. Terms and abbreviations . . . . . . . . . . . . . . . . . 6
1.5. Requirement levels . . . . . . . . . . . . . . . . . . . . 7 1.5. Requirement levels . . . . . . . . . . . . . . . . . . . . 7
1.6. Assumptions and rationale . . . . . . . . . . . . . . . . 7 1.6. Assumptions and rationale . . . . . . . . . . . . . . . . 8
1.7. Why IPsec lacks mobility . . . . . . . . . . . . . . . . . 9 1.7. Why IPsec lacks mobility . . . . . . . . . . . . . . . . . 9
2. The network environment . . . . . . . . . . . . . . . . . . . 11 2. The network environment . . . . . . . . . . . . . . . . . . . 11
2.1. Access mode: 'c' . . . . . . . . . . . . . . . . . . . . . 13 2.1. Access mode: 'c' . . . . . . . . . . . . . . . . . . . . . 13
2.2. Access mode: 'f' . . . . . . . . . . . . . . . . . . . . . 14 2.2. Access mode: 'f' . . . . . . . . . . . . . . . . . . . . . 14
2.3. Access mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 14 2.3. Access mode: 'cvc' . . . . . . . . . . . . . . . . . . . . 14
2.4. Access mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 15 2.4. Access mode: 'fvc' . . . . . . . . . . . . . . . . . . . . 15
2.5. NAT traversal . . . . . . . . . . . . . . . . . . . . . . 15 2.5. NAT traversal . . . . . . . . . . . . . . . . . . . . . . 15
3. Internal network detection . . . . . . . . . . . . . . . . . . 17 3. Internal network detection . . . . . . . . . . . . . . . . . . 17
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 18 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Implementation requirements . . . . . . . . . . . . . . . 18 3.2. Implementation requirements . . . . . . . . . . . . . . . 18
skipping to change at page 4, line 10 skipping to change at page 4, line 10
A.1. Connection setup for access mode 'cvc' . . . . . . . . . . 39 A.1. Connection setup for access mode 'cvc' . . . . . . . . . . 39
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 44 Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 49
Intellectual Property and Copyright Statements . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . . . . . 50
1. Introduction 1. Introduction
The Mobile IP working group set out to explore the problem and The Mobile IP working group set out to explore the problem and
solution spaces of IPsec and Mobile IP coexistence. The problem solution spaces of IPsec and Mobile IP coexistence. The problem
statement and solution requirements for Mobile IPv4 case was first statement and solution requirements for Mobile IPv4 case was first
documented in [9]. This document outlines the proposed solution for documented in [ref.rfc4093]. This document outlines the proposed
IPv4. solution for IPv4.
The document contains two parts: The document contains two parts:
o a basic solution which is an applicability statement of Mobile o a basic solution which is an applicability statement of Mobile
IPv4 and IPsec to provide session mobility between enterprise IPv4 and IPsec to provide session mobility between enterprise
Intranets and other external networks, intended for enterprise Intranets and other external networks, intended for enterprise
mobile users; and mobile users; and
o a technical specification and a set of requirements for secure o a technical specification and a set of requirements for secure
detection of the internal and the external networks, including a detection of the internal and the external networks, including a
new extension which must be implemented by a mobile node and a new extension which must be implemented by a mobile node and a
home agent situated inside the enterprise network. home agent situated inside the enterprise network.
There are many useful ways to combine Mobile IPv4 and IPsec. The There are many useful ways to combine Mobile IPv4 and IPsec. The
solution specified in this document is most applicable when the solution specified in this document is most applicable when the
assumption documented in the problem statement [9] are valid; among assumption documented in the problem statement [ref.rfc4093] are
others that the solution: valid; among others that the solution:
o must minimize changes to existing firewall/VPN/DMZ deployments; o must minimize changes to existing firewall/VPN/DMZ deployments;
o must ensure that traffic is not routed through the DMZ when the o must ensure that traffic is not routed through the DMZ when the
mobile node is inside (to avoid scalability and management mobile node is inside (to avoid scalability and management
issues); issues);
o must support foreign networks with only foreign agent access; o must support foreign networks with only foreign agent access;
o should not require changes to existing IPsec or key exchange o should not require changes to existing IPsec or key exchange
skipping to change at page 5, line 11 skipping to change at page 5, line 11
Internet (untrusted external network), the intranet (trusted internal Internet (untrusted external network), the intranet (trusted internal
network), and the DMZ, which connects the two networks. Access to network), and the DMZ, which connects the two networks. Access to
the internal network is guarded both by a firewall and a VPN device; the internal network is guarded both by a firewall and a VPN device;
access is only allowed if both firewall and VPN security policies are access is only allowed if both firewall and VPN security policies are
respected. respected.
Enterprise mobile users benefit from unrestricted seamless session Enterprise mobile users benefit from unrestricted seamless session
mobility between subnets, regardless of whether the subnets are part mobility between subnets, regardless of whether the subnets are part
of the internal or the external network. Unfortunately the current of the internal or the external network. Unfortunately the current
Mobile IPv4 and IPsec standards alone do not provide such a service Mobile IPv4 and IPsec standards alone do not provide such a service
[12]. [ref.tessier].
The proposed solution is to use standard Mobile IPv4 (except for a The proposed solution is to use standard Mobile IPv4 (except for a
new extension used by the home agent in the internal network to aid new extension used by the home agent in the internal network to aid
in network detection) when the mobile node is in the internal in network detection) when the mobile node is in the internal
network, and to use the VPN tunnel endpoint address for the Mobile network, and to use the VPN tunnel endpoint address for the Mobile
IPv4 registration when outside. IPsec-based VPN tunnels require re- IPv4 registration when outside. IPsec-based VPN tunnels require re-
negotiation after movement. To overcome this limitation, another negotiation after movement. To overcome this limitation, another
layer of Mobile IPv4 is used underneath IPsec, in effect making IPsec layer of Mobile IPv4 is used underneath IPsec, in effect making IPsec
unaware of movement. Thus, the mobile node can freely move in the unaware of movement. Thus, the mobile node can freely move in the
external network without disrupting the VPN connection. external network without disrupting the VPN connection.
skipping to change at page 6, line 5 skipping to change at page 5, line 49
outside in a secure fashion, and (2) control the protocol layers outside in a secure fashion, and (2) control the protocol layers
accordingly. For instance, if the mobile node is inside, the IPsec accordingly. For instance, if the mobile node is inside, the IPsec
layer needs to become dormant. layer needs to become dormant.
Except for the new Mobile IPv4 extension to improve security of Except for the new Mobile IPv4 extension to improve security of
internal network detection, current Mobile IPv4 and IPsec standards, internal network detection, current Mobile IPv4 and IPsec standards,
when used in a suitable combination, are sufficient to implement the when used in a suitable combination, are sufficient to implement the
solution; no changes are required to existing VPN devices or foreign solution; no changes are required to existing VPN devices or foreign
agents. agents.
The solution described is compatible with different kinds of IPsec-
based VPNs, and no particular kind of VPN is required. Because the
appropriate security policy database (SPD) entries and other IKE and
IPsec specifics differ between deployed IPsec-based VPN products,
these details are not discussed in the document.
1.2. Scope 1.2. Scope
This document describes a solution for IPv4 only. The downside of This document describes a solution for IPv4 only. The downside of
the described approach is that an external home agent is required, the described approach is that an external home agent is required,
and that the packet overhead (see Section 5) and overall complexity and that the packet overhead (see Section 5) and overall complexity
increase. Optimizations would require significant changes to Mobile increase. Optimizations would require significant changes to Mobile
IPv4 and/or IPsec, and are out of scope of this document. IPv4 and/or IPsec, and are out of scope of this document.
VPN, in this document, refers to an IPsec-based remote access VPN. VPN, in this document, refers to an IPsec-based remote access VPN.
Other types of VPNs are out of scope. Other types of VPNs are out of scope.
1.3. Related work 1.3. Related work
Related work has been done on Mobile IPv6 in [13] which discusses the Related work has been done on Mobile IPv6 in [ref.rfc3776] which
interaction of IPsec and Mobile IPv6 in protecting Mobile IPv6 discusses the interaction of IPsec and Mobile IPv6 in protecting
signaling. The document also discusses dynamic updating of the IPsec Mobile IPv6 signaling. The document also discusses dynamic updating
endpoint based on Mobile IP signaling packets. of the IPsec endpoint based on Mobile IP signaling packets.
The "transient pseudo-NAT" attack, described in [15] and [4], affects The "transient pseudo-NAT" attack, described in [ref.pseudonat] and
any approach which attempts to provide security of mobility signaling [ref.mipnat], affects any approach which attempts to provide security
in conjunction with NAT devices. In many cases, one cannot assume of mobility signaling in conjunction with NAT devices. In many
any co-operation from NAT devices which thus have to be treated as cases, one cannot assume any co-operation from NAT devices which thus
any other networking entity. have to be treated as any other networking entity.
The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [11] provides The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [ref.rfc4555]
better mobility for IPsec. This would allow the external Mobile IPv4 provides better mobility for IPsec. This would allow the external
layer described in this specification to be removed. However, Mobile IPv4 layer described in this specification to be removed.
deploying MOBIKE requires changes to VPN devices, and is thus out of However, deploying MOBIKE requires changes to VPN devices, and is
scope of this specification. thus out of scope of this specification.
1.4. Terms and abbreviations 1.4. Terms and abbreviations
co-CoA: co-located care-of address. co-CoA: co-located care-of address.
DMZ: (DeMilitarized Zone) A small network inserted as a "neutral DMZ: (DeMilitarized Zone) A small network inserted as a "neutral
zone" between a company's private network and the outside public zone" between a company's private network and the outside public
network to prevent outside users from getting direct access to the network to prevent outside users from getting direct access to the
company's private network. company's private network.
skipping to change at page 7, line 15 skipping to change at page 7, line 17
FA-CoA: foreign agent care-of address. FA-CoA: foreign agent care-of address.
FW: Firewall. FW: Firewall.
internal network: the trusted network; for instance, a physically internal network: the trusted network; for instance, a physically
secure corporate network where the i-HA is located. secure corporate network where the i-HA is located.
i-FA: Mobile IPv4 foreign agent residing in the internal network. i-FA: Mobile IPv4 foreign agent residing in the internal network.
i-HA: Mobile IPv4 home agent residing in the internal network; i-HA: Mobile IPv4 home agent residing in the internal network;
typically has a private address [5]. typically has a private address [ref.privaddr].
i-HoA: home address of the mobile node in the internal home agent. i-HoA: home address of the mobile node in the internal home agent.
MN: Mobile Node. MN: Mobile Node.
NAI: Network Access Identifier [10]. NAI: Network Access Identifier [ref.rfc4282].
R: Router. R: Router.
VPN: Virtual Private Network based on IPsec. VPN: Virtual Private Network based on IPsec.
VPN-TIA: VPN tunnel inner address, the address(es) negotiated VPN-TIA: VPN tunnel inner address, the address(es) negotiated
during IKE phase 2 (quick mode), assigned manually, using IPsec- during IKE phase 2 (quick mode), assigned manually, using IPsec-
DHCP [14], using the "de facto" standard ISAKMP configuration DHCP [ref.rfc3456], using the "de facto" standard ISAKMP
mode, or by some other means. Some VPN clients use their current configuration mode, or by some other means. Some VPN clients use
care-of address as their TIA for architectural reasons. their current care-of address as their TIA for architectural
reasons.
VPN tunnel: an IPsec-based tunnel; for instance, IPsec tunnel mode VPN tunnel: an IPsec-based tunnel; for instance, IPsec tunnel mode
IPsec connection, or L2TP combined with IPsec transport IPsec connection, or L2TP combined with IPsec transport
connection. connection.
x-FA: Mobile IPv4 foreign agent residing in the external network. x-FA: Mobile IPv4 foreign agent residing in the external network.
x-HA: Mobile IPv4 home agent residing in the external network. x-HA: Mobile IPv4 home agent residing in the external network.
x-HoA: home address of the mobile node in the external home agent. x-HoA: home address of the mobile node in the external home agent.
1.5. Requirement levels 1.5. Requirement levels
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119
[ref.rfc2119].
1.6. Assumptions and rationale 1.6. Assumptions and rationale
The proposed solution is an attempt to solve the problem described in The proposed solution is an attempt to solve the problem described in
[9]. The major assumptions and their rationale is summarized below. [ref.rfc4093]. The major assumptions and their rationale is
summarized below.
Changes to existing firewall and VPN deployments should be minimized: Changes to existing firewall and VPN deployments should be minimized:
o The current deployment of firewalls and IPsec-based VPNs is much o The current deployment of firewalls and IPsec-based VPNs is much
larger than corresponding Mobile IPv4 elements. Thus, a solution larger than corresponding Mobile IPv4 elements. Thus, a solution
should work within the existing VPN infrastructure. should work within the existing VPN infrastructure.
o Current enterprise network deployments typically centralize o Current enterprise network deployments typically centralize
management of security and network access into a compact DMZ. management of security and network access into a compact DMZ.
skipping to change at page 9, line 26 skipping to change at page 9, line 32
assume zero or minimal changes to existing Mobile IPv4 nodes. assume zero or minimal changes to existing Mobile IPv4 nodes.
o Note, however, that the assumption (no encryption when inside) o Note, however, that the assumption (no encryption when inside)
does not necessarily apply to all solutions in the solution space; does not necessarily apply to all solutions in the solution space;
if the abovementioned problems were resolved there is no if the abovementioned problems were resolved there is no
fundamental reason why encryption could not be applied when fundamental reason why encryption could not be applied when
inside. inside.
1.7. Why IPsec lacks mobility 1.7. Why IPsec lacks mobility
IPsec, as currently specified [2] requires that a new IKE negotiation IPsec, as currently specified [ref.rfc4301] requires that a new IKE
be done whenever an IPsec peer moves, i.e. changes care-of address. negotiation be done whenever an IPsec peer moves, i.e. changes
The main reason is that a security association is uni-directional and care-of address. The main reason is that a security association is
identified by a triplet consisting of (1) the destination address uni-directional and identified by a triplet consisting of (1) the
(which is the outer address when tunnel mode is used), (2) the destination address (which is the outer address when tunnel mode is
security protocol (ESP or AH), and (3) the Security Parameter Index used), (2) the security protocol (ESP or AH), and (3) the Security
(SPI) ([2], Section 4.1). Although an implementation is not required Parameter Index (SPI) ([ref.rfc4301], Section 4.1). Although an
to use all of these for its own SAs, an implementation cannot assume implementation is not required to use all of these for its own SAs,
that a peer does not. an implementation cannot assume that a peer does not.
When a mobile IPsec peer sends packets to a stationary IPsec peer, When a mobile IPsec peer sends packets to a stationary IPsec peer,
there is no problem; the SA is "owned" by the stationary IPsec peer, there is no problem; the SA is "owned" by the stationary IPsec peer,
and therefore the destination address does not need to change. The and therefore the destination address does not need to change. The
(outer) source address should be ignored by the stationary peer (outer) source address should be ignored by the stationary peer
(although some implementations do check the source address as well). (although some implementations do check the source address as well).
The problem arises when packets are sent from the stationary peer to The problem arises when packets are sent from the stationary peer to
the mobile peer. The destination address of this SA (SAs are the mobile peer. The destination address of this SA (SAs are
unidirectional) is established during IKE negotiation, and is unidirectional) is established during IKE negotiation, and is
effectively the care-of address of the mobile peer at time of effectively the care-of address of the mobile peer at time of
negotiation. Therefore the packets will be sent to the original negotiation. Therefore the packets will be sent to the original
care-of address, not a changed care-of address. care-of address, not a changed care-of address.
The IPsec NAT traversal mechanism can also be used for limited The IPsec NAT traversal mechanism can also be used for limited
mobility, but UDP tunneling needs to be used even when there is no mobility, but UDP tunneling needs to be used even when there is no
NAT in the route between the mobile and the stationary peers. NAT in the route between the mobile and the stationary peers.
Furthermore, support for changes in current NAT mapping is not Furthermore, support for changes in current NAT mapping is not
required by the NAT traversal specification [6]. required by the NAT traversal specification [ref.rfc3947].
In summary, although the IPsec standard does not as such prevent In summary, although the IPsec standard does not as such prevent
mobility (in the sense of updating security associations on-the-fly), mobility (in the sense of updating security associations on-the-fly),
the standard does not include a built-in mechanism (explicit or the standard does not include a built-in mechanism (explicit or
implicit) for doing so. Therefore it is assumed throughout this implicit) for doing so. Therefore it is assumed throughout this
document that any change in the addresses comprising the identity of document that any change in the addresses comprising the identity of
an SA requires IKE re-negotiation, which implies too heavy an SA requires IKE re-negotiation, which implies too heavy
computation and too large latency for useful mobility. computation and too large latency for useful mobility.
The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [11] provides The IKEv2 Mobility and Multihoming Protocol (MOBIKE) [ref.rfc4555]
better mobility for IPsec. This would allow the external Mobile IPv4 provides better mobility for IPsec. This would allow the external
layer described in this specification to be removed. However, Mobile IPv4 layer described in this specification to be removed.
deploying MOBIKE requires changes to VPN devices, and is thus out of However, deploying MOBIKE requires changes to VPN devices, and is
scope of this specification. thus out of scope of this specification.
2. The network environment 2. The network environment
Enterprise users will access both the internal and external networks Enterprise users will access both the internal and external networks
using different networking technologies. In some networks, the MN using different networking technologies. In some networks, the MN
will use FAs and in others it will anchor at the HA using co-located will use FAs and in others it will anchor at the HA using co-located
mode. The following figure describes an example network topology mode. The following figure describes an example network topology
illustrating the relationship between the internal and external illustrating the relationship between the internal and external
networks, the possible locations of the mobile node (i.e. (MN)). networks, the possible locations of the mobile node (i.e. (MN)).
skipping to change at page 12, line 27 skipping to change at page 12, line 27
c: i-MIP w/ co-CoA c: i-MIP w/ co-CoA
f: i-MIP w/ FA-CoA f: i-MIP w/ FA-CoA
cvc: x-MIP w/ co-CoA, VPN-TIA as i-MIP co-CoA cvc: x-MIP w/ co-CoA, VPN-TIA as i-MIP co-CoA
fvc: x-MIP w/ FA-CoA, VPN-TIA as i-MIP co-CoA fvc: x-MIP w/ FA-CoA, VPN-TIA as i-MIP co-CoA
This notation is more useful when optimizations to protocol layers This notation is more useful when optimizations to protocol layers
are considered. The notation is preserved here so that work on the are considered. The notation is preserved here so that work on the
optimizations can refer to a common notation. optimizations can refer to a common notation.
The internal network is typically a multi-subnetted network using The internal network is typically a multi-subnetted network using
private addressing [5]. Subnets may contain internal home agent(s), private addressing [ref.privaddr]. Subnets may contain internal home
DHCP server(s), and/or foreign agent(s). Current IEEE 802.11 agent(s), DHCP server(s), and/or foreign agent(s). Current IEEE
wireless LANs are typically deployed in the external network or the 802.11 wireless LANs are typically deployed in the external network
DMZ because of security concerns. or the DMZ because of security concerns.
The figure leaves out a few details worth noticing: The figure leaves out a few details worth noticing:
o There may be multiple NAT devices anywhere in the diagram. o There may be multiple NAT devices anywhere in the diagram.
* When the MN is outside, the NAT devices may be placed between * When the MN is outside, the NAT devices may be placed between
the MN and the x-HA or the x-HA and the VPN. the MN and the x-HA or the x-HA and the VPN.
* There may be also be NAT(s) between the VPN and the i-HA, or a * There may be also be NAT(s) between the VPN and the i-HA, or a
NAT integrated into the VPN. In essence, any router in the NAT integrated into the VPN. In essence, any router in the
skipping to change at page 13, line 48 skipping to change at page 13, line 48
of the internal network results in a successful registration to the of the internal network results in a successful registration to the
i-HA using the proposed network detection algorithm. An improved i-HA using the proposed network detection algorithm. An improved
network detection mechanism not based on Mobile IPv4 registration network detection mechanism not based on Mobile IPv4 registration
messages might not have this side-effect. messages might not have this side-effect.
The following subsections describe the different access modes and the The following subsections describe the different access modes and the
requirements for registration and connection setup phase. requirements for registration and connection setup phase.
2.1. Access mode: 'c' 2.1. Access mode: 'c'
This access mode is standard Mobile IPv4 [3] with a co-located This access mode is standard Mobile IPv4 [ref.rfc3344] with a co-
address, except that: located address, except that:
o the mobile node MUST detect that it is in the internal network; o the mobile node MUST detect that it is in the internal network;
and and
o the mobile node MUST re-register periodically (with a configurable o the mobile node MUST re-register periodically (with a configurable
interval) to ensure it is still inside the internal network (see interval) to ensure it is still inside the internal network (see
Section 4). Section 4).
2.2. Access mode: 'f' 2.2. Access mode: 'f'
This access mode is standard Mobile IPv4 [3] with a foreign agent This access mode is standard Mobile IPv4 [ref.rfc3344] with a foreign
care-of address, except that agent care-of address, except that
o the mobile node MUST detect that it is in the internal network; o the mobile node MUST detect that it is in the internal network;
and and
o the mobile node MUST re-register periodically (with a configurable o the mobile node MUST re-register periodically (with a configurable
interval) to ensure it is still inside the internal network (see interval) to ensure it is still inside the internal network (see
Section 4). Section 4).
2.3. Access mode: 'cvc' 2.3. Access mode: 'cvc'
skipping to change at page 15, line 47 skipping to change at page 15, line 47
* T-bit SHOULD be set (reverse tunneling) (see discussion in * T-bit SHOULD be set (reverse tunneling) (see discussion in
Section 2.3) Section 2.3)
Note that although the MN can use triangular routing, i.e. skip the Note that although the MN can use triangular routing, i.e. skip the
inner MIPv4 layer, it MUST NOT skip the VPN layer for security inner MIPv4 layer, it MUST NOT skip the VPN layer for security
reasons. reasons.
2.5. NAT traversal 2.5. NAT traversal
NAT devices may affect each layer independently. Mobile IPv4 NAT NAT devices may affect each layer independently. Mobile IPv4 NAT
traversal [4] SHOULD be supported for x-MIP and i-MIP layers, while traversal [ref.mipnat] SHOULD be supported for x-MIP and i-MIP
IPsec NAT traversal [6][7] SHOULD be supported for the VPN layer. layers, while IPsec NAT traversal [ref.rfc3947][ref.rfc3948] SHOULD
be supported for the VPN layer.
Note that NAT traversal for the internal MIPv4 layer may be necessary Note that NAT traversal for the internal MIPv4 layer may be necessary
even when there is no separate NAT device between the VPN gateway and even when there is no separate NAT device between the VPN gateway and
the internal network. Some VPN implementations NAT VPN tunnel inner the internal network. Some VPN implementations NAT VPN tunnel inner
addresses before routing traffic to the intranet. Sometimes this is addresses before routing traffic to the intranet. Sometimes this is
done to make a deployment easier, but in some cases this approach done to make a deployment easier, but in some cases this approach
makes VPN client implementation easier. Mobile IPv4 NAT traversal is makes VPN client implementation easier. Mobile IPv4 NAT traversal is
required to establish a MIPv4 session in this case. required to establish a MIPv4 session in this case.
3. Internal network detection 3. Internal network detection
skipping to change at page 21, line 52 skipping to change at page 21, line 52
Should the assumption have been invalid and a response from the i-HA Should the assumption have been invalid and a response from the i-HA
received after a response from the x-HA, the MN SHOULD re-register received after a response from the x-HA, the MN SHOULD re-register
with the i-HA directly. with the i-HA directly.
3.4. Trusted Networks Configured (TNC) extension 3.4. Trusted Networks Configured (TNC) extension
This extension is a skippable extension. An i-HA sending the This extension is a skippable extension. An i-HA sending the
extension must fulfill the requirements described in Section 4.3 extension must fulfill the requirements described in Section 4.3
while an MN processing the extension must fulfill the requirements while an MN processing the extension must fulfill the requirements
described in Section 4.1. The format of the extension is described described in Section 4.1. The format of the extension is described
below. It adheres to the short extension format described in [3]: below. It adheres to the short extension format described in
[ref.rfc3344]:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | Reserved | | Type | Length | Sub-Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type TBD:IANA Type TBD:IANA
Length 2 Length 2
skipping to change at page 25, line 21 skipping to change at page 25, line 21
new configurable MN parameter, T_MONITOR, is required. The value of new configurable MN parameter, T_MONITOR, is required. The value of
this parameter reflects a balance between security and the amount of this parameter reflects a balance between security and the amount of
signaling overhead, and thus needs to be configurable. In addition, signaling overhead, and thus needs to be configurable. In addition,
when doing internal network detection, the MN MUST NOT disable IPsec when doing internal network detection, the MN MUST NOT disable IPsec
protection unless the registration reply from the i-HA contains a protection unless the registration reply from the i-HA contains a
Trusted Networks Configured extension (Section 3.4). Trusted Networks Configured extension (Section 3.4).
The mobile node MUST support access modes: c, f, cvc, fvc The mobile node MUST support access modes: c, f, cvc, fvc
(Section 2). (Section 2).
The mobile node SHOULD support Mobile IPv4 NAT traversal [4] for both The mobile node SHOULD support Mobile IPv4 NAT traversal [ref.mipnat]
internal and external Mobile IP. for both internal and external Mobile IP.
The mobile node SHOULD support IPsec NAT traversal [6][7]. The mobile node SHOULD support IPsec NAT traversal
[ref.rfc3947][ref.rfc3948].
When the mobile node has direct access to the i-HA, it SHOULD use When the mobile node has direct access to the i-HA, it SHOULD use
only the inner Mobile IPv4 layer to minimize firewall and VPN impact. only the inner Mobile IPv4 layer to minimize firewall and VPN impact.
When the mobile node is outside and using the VPN connection, IPsec When the mobile node is outside and using the VPN connection, IPsec
policies MUST be configured to encrypt all traffic sent to and from policies MUST be configured to encrypt all traffic sent to and from
the enterprise network. The particular Security Policy Database the enterprise network. The particular Security Policy Database
(SPD) entries depend on the type and configuration of the particular (SPD) entries depend on the type and configuration of the particular
VPN (e.g. plain IPsec vs. L2TP/IPsec, full tunneling or split VPN (e.g. plain IPsec vs. L2TP/IPsec, full tunneling or split
tunneling). tunneling).
4.2. VPN device requirements 4.2. VPN device requirements
The VPN security policy MUST allow communication using UDP to the The VPN security policy MUST allow communication using UDP to the
internal home agent(s), with home agent port 434 and any remote port. internal home agent(s), with home agent port 434 and any remote port.
The security policy SHOULD allow IP-IP to internal home agent(s) in The security policy SHOULD allow IP-IP to internal home agent(s) in
addition to UDP port 434. addition to UDP port 434.
The VPN device SHOULD implement the IPsec NAT traversal mechanism The VPN device SHOULD implement the IPsec NAT traversal mechanism
described in [6] [7]. described in [ref.rfc3947] [ref.rfc3948].
4.3. Home agent requirements 4.3. Home agent requirements
The home agent SHOULD implement the Mobile IPv4 NAT traversal The home agent SHOULD implement the Mobile IPv4 NAT traversal
mechanism described in [4]. (This also refers to the i-HA: NAT mechanism described in [ref.mipnat]. (This also refers to the i-HA:
traversal is required to support VPNs that NAT VPN tunnel addresses NAT traversal is required to support VPNs that NAT VPN tunnel
or block IP-IP traffic.) addresses or block IP-IP traffic.)
To protect user data confidentiality against firewall configuration To protect user data confidentiality against firewall configuration
errors, the i-HA: errors, the i-HA:
o MUST be configured with a list of trusted IP subnets (containing o MUST be configured with a list of trusted IP subnets (containing
only addresses from the internal network), with no subnets being only addresses from the internal network), with no subnets being
trusted by default. trusted by default.
o MUST reject (drop silently) any registration request coming from a o MUST reject (drop silently) any registration request coming from a
source address which is not inside any of the configured trusted source address which is not inside any of the configured trusted
subnets. These dropped registration requests SHOULD be logged. subnets. These dropped registration requests SHOULD be logged.
o MUST include a Trusted Networks Configured extension (Section 3.4) o MUST include a Trusted Networks Configured extension (Section 3.4)
in a registration reply sent in response to a registration request in a registration reply sent in response to a registration request
coming from a trusted address. coming from a trusted address.
5. Analysis 5. Analysis
This section provides a comparison against guidelines described in This section provides a comparison against guidelines described in
Section 6 of the problem statement [9] and additional analysis of Section 6 of the problem statement [ref.rfc4093] and additional
packet overhead with and without the optional mechanisms. analysis of packet overhead with and without the optional mechanisms.
5.1. Comparison against guidelines 5.1. Comparison against guidelines
Preservation of existing VPN infrastructure Preservation of existing VPN infrastructure
o The proposed solution does not mandate any changes to existing VPN o The proposed solution does not mandate any changes to existing VPN
infrastructure, other than possibly changes in configuration to infrastructure, other than possibly changes in configuration to
avoid stateful filtering of traffic. avoid stateful filtering of traffic.
Software upgrades to existing VPN clients and gateways Software upgrades to existing VPN clients and gateways
skipping to change at page 28, line 22 skipping to change at page 28, line 22
o Additional overhead is imposed by the solution. o Additional overhead is imposed by the solution.
Functional entities Functional entities
o The solution does not impose any new types of functional entities o The solution does not impose any new types of functional entities
or required changes to existing entities. However, an external HA or required changes to existing entities. However, an external HA
device is required. device is required.
Implications of intervening NAT gateways Implications of intervening NAT gateways
o The solution leverages existing MIPv4 NAT traversal [4] and IPsec o The solution leverages existing MIPv4 NAT traversal [ref.mipnat]
NAT traversal [6] [7] solutions and does not require any new and IPsec NAT traversal [ref.rfc3947] [ref.rfc3948] solutions and
functionality to deal with NATs. does not require any new functionality to deal with NATs.
Security implications Security implications
o The solution requires a new mechanism to detect whether the mobile o The solution requires a new mechanism to detect whether the mobile
node is in the internal or the external network. The security of node is in the internal or the external network. The security of
this mechanism is critical in ensuring that the security level this mechanism is critical in ensuring that the security level
provided by IPsec is not compromised by a faulty detection provided by IPsec is not compromised by a faulty detection
mechanism. mechanism.
o When the mobile node is outside, the external Mobile IPv4 layer o When the mobile node is outside, the external Mobile IPv4 layer
skipping to change at page 29, line 18 skipping to change at page 29, line 18
o IPsec ESP: 57 octets total, consisting of: 20 (new IP header), o IPsec ESP: 57 octets total, consisting of: 20 (new IP header),
4+4+8 = 16 (SPI, sequence number, cipher initialization vector), 4+4+8 = 16 (SPI, sequence number, cipher initialization vector),
7+2 = 9 (padding, padding length field, next header field), 12 7+2 = 9 (padding, padding length field, next header field), 12
(ESP authentication trailer) (ESP authentication trailer)
o IP-IP for x-MIPv4: 20 octets o IP-IP for x-MIPv4: 20 octets
When IPsec is used, a variable amount of padding is present in each When IPsec is used, a variable amount of padding is present in each
ESP packet. The figures were computed for a cipher with 64-bit block ESP packet. The figures were computed for a cipher with 64-bit block
size, padding overhead of 9 octets (next header field, padding length size, padding overhead of 9 octets (next header field, padding length
field, and 7 octets of padding, see Section 2.4 of [8]), and ESP field, and 7 octets of padding, see Section 2.4 of [ref.rfc4303]),
authentication field of 12 octets (HMAC-SHA1-96 or HMAC-MD5-96). and ESP authentication field of 12 octets (HMAC-SHA1-96 or
Note that an IPsec implementation MAY pad with more than a minimum HMAC-MD5-96). Note that an IPsec implementation MAY pad with more
amount of octets. than a minimum amount of octets.
NAT traversal overhead is not included, and adds 8 octets when IPsec NAT traversal overhead is not included, and adds 8 octets when IPsec
NAT traversal [6] [7] is used and 12 octets when MIP NAT traversal NAT traversal [ref.rfc3947] [ref.rfc3948] is used and 12 octets when
[4] is used. For instance, when using access mode cvc, the maximum MIP NAT traversal [ref.mipnat] is used. For instance, when using
NAT traversal overhead is 12+8+12 = 32 octets. Thus, the worst case access mode cvc, the maximum NAT traversal overhead is 12+8+12 = 32
scenario (with the abovementioned ESP assumptions) is 129 octets for octets. Thus, the worst case scenario (with the abovementioned ESP
cvc. assumptions) is 129 octets for cvc.
5.3. Latency considerations 5.3. Latency considerations
When the MN is inside, connection setup latency does not increase When the MN is inside, connection setup latency does not increase
compared to standard MIPv4 if the MN implements the suggested compared to standard MIPv4 if the MN implements the suggested
parallel registration sequence (see Section 3.3). Exchange of RRQ/ parallel registration sequence (see Section 3.3). Exchange of RRQ/
RRP messages with the i-HA confirms the MN is inside, and the MN may RRP messages with the i-HA confirms the MN is inside, and the MN may
start sending and receiving user traffic immediately. For the same start sending and receiving user traffic immediately. For the same
reason, handovers in the internal network have no overhead relative reason, handovers in the internal network have no overhead relative
to standard MIPv4. to standard MIPv4.
skipping to change at page 32, line 16 skipping to change at page 32, line 16
6.1. Internal network detection 6.1. Internal network detection
If the mobile node by mistake believes it is in the internal network If the mobile node by mistake believes it is in the internal network
and sends plaintext packets, it compromises IPsec security. For this and sends plaintext packets, it compromises IPsec security. For this
reason, the overall security (confidentiality and integrity) of user reason, the overall security (confidentiality and integrity) of user
data is a minimum of (1) IPsec security, and (2) security of the data is a minimum of (1) IPsec security, and (2) security of the
internal network detection mechanism. internal network detection mechanism.
Security of the internal network detection relies on a successful Security of the internal network detection relies on a successful
registration with the i-HA. For standard Mobile IPv4 [3] this means registration with the i-HA. For standard Mobile IPv4 [ref.rfc3344]
HMAC-MD5 and Mobile IPv4 replay protection. The solution also this means HMAC-MD5 and Mobile IPv4 replay protection. The solution
assumes that the i-HA is not directly reachable from the external also assumes that the i-HA is not directly reachable from the
network, requiring careful enterprise firewall configuration. To external network, requiring careful enterprise firewall
minimize the impact of a firewall configuration problem, the i-HA is configuration. To minimize the impact of a firewall configuration
separately required to be configured with trusted source addresses problem, the i-HA is separately required to be configured with
(i.e., addresses belonging to the internal network), and to include trusted source addresses (i.e., addresses belonging to the internal
an indication of this in a new Trusted Networks Configured extension. network), and to include an indication of this in a new Trusted
The MN is required not to trust a registration as an indication of Networks Configured extension. The MN is required not to trust a
being connected to the internal network, unless this extension is registration as an indication of being connected to the internal
present in the registration reply. Thus, to actually compromise user network, unless this extension is present in the registration reply.
data confidentiality, both the enterprise firewall and the i-HA have Thus, to actually compromise user data confidentiality, both the
to be configured incorrectly, which reduces the likelihood of the enterprise firewall and the i-HA have to be configured incorrectly,
scenario. which reduces the likelihood of the scenario.
When the mobile node sends a registration request to the i-HA from an When the mobile node sends a registration request to the i-HA from an
untrusted network that does not go through the IPsec tunnel, it will untrusted network that does not go through the IPsec tunnel, it will
reveal the i-HA's address, its own identity including the NAI and the reveal the i-HA's address, its own identity including the NAI and the
home address, and the Authenticator value in the authentication home address, and the Authenticator value in the authentication
extensions to the untrusted network. This may be a concern in some extensions to the untrusted network. This may be a concern in some
deployments. deployments.
When the connection status of an interface changes, an interface When the connection status of an interface changes, an interface
previously connected to the trusted internal network may suddenly be previously connected to the trusted internal network may suddenly be
skipping to change at page 33, line 33 skipping to change at page 33, line 33
may be weak if easily memorizable secrets are chosen, thus opening up may be weak if easily memorizable secrets are chosen, thus opening up
redirection attacks described above. Note especially that a weak redirection attacks described above. Note especially that a weak
secret in the i-HA is fatal to security, as the mobile node can be secret in the i-HA is fatal to security, as the mobile node can be
fooled into dropping encryption if the i-HA secret is broken. fooled into dropping encryption if the i-HA secret is broken.
Assuming the MIPv4 shared secrets have sufficient entropy, there are Assuming the MIPv4 shared secrets have sufficient entropy, there are
still at least the following differences and similarities between still at least the following differences and similarities between
MIPv4 and IPsec worth considering: MIPv4 and IPsec worth considering:
o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT" o Both IPsec and MIPv4 are susceptible to the "transient pseudo NAT"
attack described in [15] and [4], assuming that NAT traversal is attack described in [ref.pseudonat] and [ref.mipnat], assuming
enabled (which is typically the case). "Pseudo NAT" attacks allow that NAT traversal is enabled (which is typically the case).
an attacker to redirect traffic flows, resulting in resource "Pseudo NAT" attacks allow an attacker to redirect traffic flows,
consumption, lack of connectivity, and denial-of-service. resulting in resource consumption, lack of connectivity, and
However, such attacks cannot compromise the confidentiality of denial-of-service. However, such attacks cannot compromise the
user data protected using IPsec. confidentiality of user data protected using IPsec.
o When considering a "pseudo NAT" attack against standard IPsec and o When considering a "pseudo NAT" attack against standard IPsec and
standard MIP (with NAT traversal), redirection attacks against MIP standard MIP (with NAT traversal), redirection attacks against MIP
may be easier because: may be easier because:
* MIPv4 re-registrations typically occur more frequently than * MIPv4 re-registrations typically occur more frequently than
IPsec SA setups (although this may not be the case for mobile IPsec SA setups (although this may not be the case for mobile
hosts). hosts).
* It suffices to catch and modify a single registration request, * It suffices to catch and modify a single registration request,
skipping to change at page 37, line 9 skipping to change at page 37, line 9
giving the document a thorough read and a security review. Tom giving the document a thorough read and a security review. Tom
Hiller pointed out issues with battery powered devices. We would Hiller pointed out issues with battery powered devices. We would
also like to thank the previous Mobile IP working group chairs also like to thank the previous Mobile IP working group chairs
(Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important (Gabriel Montenegro, Basavaraj Patil, and Phil Roberts) for important
feedback and guidance. feedback and guidance.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [ref.rfc2119]
Levels", RFC 2119, March 1997. Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[2] Kent, S. and K. Seo, "Security Architecture for the Internet [ref.rfc4301]
Protocol", RFC 4301, December 2005. Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[3] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, [ref.rfc3344]
August 2002. Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[4] Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of Network [ref.mipnat]
Address Translation (NAT) Devices", RFC 3519, April 2003. Levkowetz, H. and S. Vaarala, "Mobile IP Traversal of
Network Address Translation (NAT) Devices", RFC 3519,
April 2003.
[5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and [ref.privaddr]
E. Lear, "Address Allocation for Private Internets", RFC 1918, Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
BCP 5, February 1996. and E. Lear, "Address Allocation for Private Internets",
RFC 1918, BCP 5, February 1996.
[6] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [ref.rfc3947]
"Negotiation of NAT-Traversal in the IKE", RFC 3947, Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
January 2005. "Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005.
[7] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [ref.rfc3948]
Stenberg, "UDP Encapsulation of IPsec packets", RFC 3948, Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
January 2005. Stenberg, "UDP Encapsulation of IPsec packets", RFC 3948,
January 2005.
[8] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, [ref.rfc4303]
December 2005. Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
9.2. Informative References 9.2. Informative References
[9] Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile IPv4 [ref.rfc4093]
Traversal of Virtual Private Network (VPN) Gateways", RFC 4093, Adrangi, F. and H. Levkowetz, "Problem Statement: Mobile
August 2005. IPv4 Traversal of Virtual Private Network (VPN) Gateways",
RFC 4093, August 2005.
[10] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network [ref.rfc4282]
Access Identifier", RFC 4282, December 2005. Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
Network Access Identifier", RFC 4282, December 2005.
[11] Eronen, P., "IKEv2 Mobility and Multihoming Protocol (MOBIKE)", [ref.rfc4555]
RFC 4555, June 2006. Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[12] Tessier, S., "Guidelines for Mobile IP and IPsec VPN Usage", [ref.tessier]
December 2002. Tessier, S., "Guidelines for Mobile IP and IPsec VPN
Usage", December 2002.
[13] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to [ref.rfc3776]
Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to
Agents", RFC 3776, June 2004. Protect Mobile IPv6 Signaling Between Mobile Nodes and
Home Agents", RFC 3776, June 2004.
[14] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic Host [ref.rfc3456]
Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic
Mode", RFC 3456, January 2003. Host Configuration Protocol (DHCPv4) Configuration of
IPsec Tunnel Mode", RFC 3456, January 2003.
[15] Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks or how [ref.pseudonat]
NATs are even more evil than you believed Dupont, F. and J. Bernard, "Transient pseudo-NAT attacks
(draft-dupont-transient-pseudonat-04, work in progress)", or how NATs are even more evil than you believed
June 2004. (draft-dupont-transient-pseudonat-04, work in progress)",
June 2004.
Appendix A. Packet flow examples Appendix A. Packet flow examples
A.1. Connection setup for access mode 'cvc' A.1. Connection setup for access mode 'cvc'
The following figure illustrates connection setup when the mobile The following figure illustrates connection setup when the mobile
node is outside and using a co-located care-of address. IKE node is outside and using a co-located care-of address. IKE
connection setup is not shown in full, and involves multiple round connection setup is not shown in full, and involves multiple round
trips (4.5 round trips when using main mode followed by quick mode). trips (4.5 round trips when using main mode followed by quick mode).
skipping to change at page 44, line 7 skipping to change at page 44, line 7
- - -----------------. - - -----------------.
\..user ! ESP ! \..user ! ESP !
/ protocol ! trailer ! / protocol ! trailer !
\ ! ! \ ! !
- - -----------------' - - -----------------'
= = ======> <= ESP => = = ======> <= ESP =>
Appendix B. Changes Appendix B. Changes
Changes from draft-ietf-mip4-vpn-problem-solution-04 to
draft-ietf-mip4-vpn-problem-solution-05:
o Clarification of why IPsec and IKE specifics related to "useipsec"
are not discussed: added text to Overview.
o Document category changed from BCP to STD, because new protocol
elements are now introduced for network detection.
Changes from draft-ietf-mip4-vpn-problem-solution-03 to Changes from draft-ietf-mip4-vpn-problem-solution-03 to
draft-ietf-mip4-vpn-problem-solution-04: draft-ietf-mip4-vpn-problem-solution-04:
o Minor corrections and editorial changes: o Minor corrections and editorial changes:
* Intended status explicit. * Intended status explicit.
* Remove "no MIPv4 changes" from abstract and Introduction. * Remove "no MIPv4 changes" from abstract and Introduction.
* Firewall assumptions for i-HA and network detection security * Firewall assumptions for i-HA and network detection security
skipping to change at page 50, line 7 skipping to change at page 50, line 7
Birdstep Birdstep
Bryggegata 7 Bryggegata 7
Oslo 0250 Oslo 0250
NORWAY NORWAY
Phone: +47 95 20 26 29 Phone: +47 95 20 26 29
Email: espen@birdstep.com Email: espen@birdstep.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 50, line 44 skipping to change at line 1972
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 52 change blocks. 
142 lines changed or deleted 176 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/