Internet DRAFT - draft-yegin-dmm-cnet-homing
draft-yegin-dmm-cnet-homing
DMM Working Group A. Yegin
Internet-Draft K. Kweon
Intended status: Standards Track J. Lee
Expires: January 4, 2015 J. Park
Samsung
July 3, 2014
Corresponding Network Homing
draft-yegin-dmm-cnet-homing-02
Abstract
Mobile IP protocols provide IP session continuity to Mobile Nodes at
the expense of creating triangular routes via a centralized Home
Agent. Increased latency and network resource use, introduction of a
single point of failure and a network choke point are among the
undesirable side effects of the current protocols. This document
describes an alternative approach where the Mobile Node makes use of
dynamically-assigned Home Agent that is located close to the
Corresponding Node.
Status of This Memo
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 January 4, 2015.
Copyright Notice
Copyright (c) 2014 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
Yegin, et al. Expires January 4, 2015 [Page 1]
Internet-Draft CNet-Homing July 2014
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 3
3. Solution in a Nutshell . . . . . . . . . . . . . . . . . . . 3
4. Details . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Handover . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Teardown . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Variation . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
In the context of Mobile IP [RFC5563][RFC6275][RFC5213][RFC5944]
following two attributes are defined for the IP service provided to
the mobile hosts:
IP session continuity: The ability to maintain an ongoing IP session
by keeping the same local end-point IP address throughout the session
despite the host moving among different IP networks. The IP address
of the host may differ among independent IP sessions (e.g., host
using IP1 for its session with CN1, and IP2 for its session with
CN2), but that does not jeopardize the IP session continuity. IP
session continuity is essential for mobile hosts to maintain ongoing
flows without any interruption.
IP address reachability: The ability to maintain the same IP address
for an extended period of time. The IP address shall stay the same
across independent IP sessions, and even in the absence of any IP
session. The IP address may be published in a long-term registry
(e.g., DNS), and it shall be available for serving incoming
connections. IP address reachability is essential for mobile hosts
to use specific/fixed/published IP addresses.
Yegin, et al. Expires January 4, 2015 [Page 2]
Internet-Draft CNet-Homing July 2014
Mobile IP is designed to provide both IP session continuity and IP
address reachability to mobile hosts. The basic operation of Mobile
IP involves the following: Network assigning a fixed IP address to
the Mobile Node (the Home Address, HoA) from a fixed node (the Home
Agent, HA), the HA receiving location updates from the Mobile Node
(MN), and the HA intercepting IP packets on behalf of the MN and
tunneling them to the MN. That way the MN ensures that it can keep
receiving IP packets irrespective of its movement and location within
the IP network topology.
One obvious side effect of this approach is the creation of sub-
optimal routing paths between the MN and the other nodes it is
communicating with (the Corresponding Nodes, CN). The routing path
between the MN and a CN has to traverse the HA. Unless the HA is
already located on the path between the MN and the CN, the path
traversing the HA would create a so-called triangular route which is
longer than the direct path between the two end-points. Longer path
yields additional transmission latency and use of network resources
[I-D.ietf-dmm-requirements].
Furthermore, forcing all MN traffic via the HA would also create a
bottleneck in the network by overloading a single network element.
The cost of building and operating such a network would increase,
whereas the overall network reliability would decrease
[I-D.ietf-dmm-requirements].
The objective of the solution described in this document is to
provide IP session continuity to MNs without creating the
aforementioned side effects.
The solution does not cover support for IP address reachability.
This is considered to be acceptable, because only a very small set of
applications really need IP address reachability. Those are the
applications that are running as servers. Such applications cannot
avoid using standard Mobile IP since they need to accept incoming
connections at a specific/published IP address.
2. Notational Conventions
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].
3. Solution in a Nutshell
The triangular routing side effect of Mobile IP can be remedied if
the HA were positioned on the direct path between the MN and the CN.
That way the IP packets would naturally flow thru the HA and not
Yegin, et al. Expires January 4, 2015 [Page 3]
Internet-Draft CNet-Homing July 2014
follow a triangular route. But, this is not possible when a single/
fixed IP address is assigned to the MN and it is served by a single
HA at a fixed location [RFC5563][RFC6275][RFC5213][RFC5944] while the
MN is communicating with CNs that are located in multiple different
locations in the Internet.
The solution proposed in this document utilizes HAs located near CNs
(Corresponding Home Agent, CHA) to dynamically allocate a HoA to the
MN (Corresponding Home Address, CHoA). Such an address will be used
throughout the IP session between the MN and the CN. Given the
topological proximity of the CHA to the direct path between the MN
and the CN, it is expected that this solution would not have the
negative side effects of providing IP session continuity.
CHA may be co-located with the CN (the original content server or the
CDN server), or located in the same site as the CN (e.g., on the load
balancer, or a dedicated node), or located in an ISP serving the CN
site. Not all CNs may be served by a CHA. In case there is no CHA
serving the CN, the MN and the CN may communicate using the HoA via
the HA.
It is expected that CHAs would be deployed for the heavily-used
content sites on the Internet (e.g., YouTube, Facebook, Netflix,
etc.). CHA deployment is beneficial to the Mobile Network Operator
(MNO) of the MN as the operator offloads the mobility management and
data transmission via its core network, and enhances the user
experience through transmission latency reduction. For that reason
it is expected that the MNO would enter a business agreement with
other entities taking over a slice of its mobility management
responsibility. Depending on the location of the CHAs, types of
other entities include the owner of the CN, the data center provider
hosting the CN, the ISP or a CDN provider serving the CN. Note that
the owner of the CN already benefits from the use of CHA thanks to
the transmission latency reduction. Furthermore, there are MNOs that
also own data center and ISP, in which case the offloading agreement
would take place between the different business units of the same
company.
The MN may be using multiple applications at the same time, and each
application may be using a different CHA. For example, the MN may be
configured to use CHoA1 for App1 with CN1 via CHA1, and use CHoA2 for
App2 with CN2 via CHA2 at the same time.
Figure 1 depicts the high-level message flow for setting up data path
between the MN and the CN using a CHA.
Yegin, et al. Expires January 4, 2015 [Page 4]
Internet-Draft CNet-Homing July 2014
MN
+------+
| |
App Stack DNS CHA CN
| | | | |
|-[1]->| | | |
| |<--[2]-->| | |
| | | | |
| |<----------[3]--->| |
| | | | |
| |===========[4]====| |
| | | | |
|<-----============[5]====------->|
| | | | |
Figure 1. Data path setup.
Assume that the MN is already configured with an IP address allocated
from the access network it is attached to. Let this IP address be
called IPxs.
Step 1:
An application on the MN attempts to initiate communication with the
CN.
Step 2:
Network stack on the MN resolves the CN_hostname to the IP address of
CN. In parallel with that, the stack also tries to resolve the
cha.CN_hostname in order to discover the CHA serving the CN, if there
is any.
Step 3:
If a CHA is discovered at Step 2, then the network stack sends a
Binding Update to the CHA. The HoA in the Binding Update is set to
unspecified IP address (0.0.0.0/::) in order to request a
dynamically-allocated CHoA from the CHA.
Step 4:
A tunnel is setup between the MN and the CHA as a result of Step 3.
The tunnel end-points are IPxs and IP address of CHA (IPcha).
Step 5:
Yegin, et al. Expires January 4, 2015 [Page 5]
Internet-Draft CNet-Homing July 2014
The socket used by the application is bound to the CHoA. The end-to-
end communication between the App and the CN uses CHoA and IP address
of CN (IPcn). Those IP packets are tunneled between the MN and the
CHA.
Figure 2 depicts the high-level message flow for re-establishing the
MN-CHA tunnel when the MN performs an IP handover.
MN
+------+
| |
App Stack CHA CN
| | | |
| [1] | |
| | | |
| |<----------[2]--->| |
| | | |
| |===========[3]====| |
| | | |
|<-----============[4]====------->|
| | | |
Figure 2. IP handover.
Step 1:
IP stack of MN configures a new IP address from the new access
network (IPxs2).
Step 2:
MN sends a Binding Update to the CHA, binding CHoA to IPxs2.
Step 3:
A new tunnel is setup between the MN and the CHA (between the IPxs2
and IPcha).
Step 4:
The application and the CN continue their end-to-end communication
using the new tunnel. The end point IP addresses stay the same (CHoA
and IPcn), therefore the underlying routing change is transparent to
the communication end-points (CN, and the transport layer and above
on MN).
Yegin, et al. Expires January 4, 2015 [Page 6]
Internet-Draft CNet-Homing July 2014
Figure 3 depicts the high-level message flow for tearing down the MN-
CHA tunnel when the application closes the connection.
MN
+------+
| |
App Stack CHA CN
| | | |
|-[1]->| | |
| | | |
| |<-=========[2]====------->|
| | | |
| |<----------[3]--->| |
| | | |
Figure 3. Tear down.
Step 1:
The application attempts to close the session with the CN.
Step 2:
The network stack closes the connection with the CN (e.g., TCP FIN).
Step 3:
The MN sends a Binding Update to the CHA in order to de-register the
binding between the IPxs and the CHoA. Dynamically-allocated CHoA
and the tunnel between the MN and the CHA are released at this step.
4. Details
This section provides a more detailed description of the proposed
solution. The solution utilizes the standard Mobile IP protocol
signaling. Unless otherwise stated, the protocol details in
[RFC6275][RFC5944] apply to the Mobile IP processing described in the
following sections.
4.1. Setup
Figure 4 depicts the detailed message flow for setting up data path
between the MN and the CN using a CHA.
Yegin, et al. Expires January 4, 2015 [Page 7]
Internet-Draft CNet-Homing July 2014
MN
+------+
| |
App Stack DNS CHA CN AAA
| | | | | |
|-[1]->| | | | |
| |--[2a]-->| | | |
| | | | | |
| |--[2b]-->| | | |
| | | | | |
|<-----|<-[3a]---| | | |
| | | | | |
| |<-[3b]---| | | |
|-[4]->| | | | |
| |-----------[5]--->| | |
| | | |--------[6]->|
| | | | | |
| | | |<-------[7]--|
| |<----------[8]----| | |
| | | | | |
| |===========[9]====| | |
| | | | | |
| |<-=========[10]===------->| |
| | | | | |
|<-[11]-===================------>| |
Figure 4. Detailed setup.
Step 1:
An application attempts to resolve the IP address of the CN by
issuing a Socket API call (e.g., gethostbyname, getaddrinfo).
Step 2a:
DNS client on the MN sends a DNS request to the DNS server in order
to resolve the IP address of the CN.
Step 2b:
In parallel with Step 2a, DNS client on the MN should also send a DNS
request to the DNS server in order to resolve the IP address of
cha.CN_hostname.
Steps 3a and 3b:
Yegin, et al. Expires January 4, 2015 [Page 8]
Internet-Draft CNet-Homing July 2014
DNS server returns the results.
Step 4:
The application attempts to send its first packet to the CN by
issuing a Socket API call (e.g., connect, sendto).
Step 5:
If Step 3b has produced an IP address for the CHA (which indicates
availability of a CHA for the CN), then the MN shall send a Binding
Update to the CHA. The Binding Update shall include a HoA that is
set to the unspecified IP address (0.0.0.0 for IPv4, :: for IPv6).
Steps 6 and 7:
The CHA may need to authenticate the incoming Binding Update in order
to authorize it. This step may require AAA [RFC2865][RFC3588]
between the CHA and a AAA server.
Step 8:
The CHA shall return a Binding Acknowledgement to the MN. This
message should contain a dynamically-allocated HoA. This HoA is
regarded as a CHoA.
Step 9:
The MN shall configure the received CHoA on its stack. The MN and
the CHA shall also setup a tunnel between the care-of address in the
Binding Update (the IPxs) and IPcha. The MN shall setup a routing
table entry to forward any IP packet whose destination address is the
IP address of the CN to the CHA via the tunnel. The CHA shall setup
a routing table entry to forward any IP packet whose destination
address is CHoA to the MN via the tunnel.
Step 10:
The MN shall assign the newly-configured CHoA as the source address
for the socket used by the application. If a connection-oriented
transport protocol is used, then a connection shall be established
(e.g., via TCP 3-way handshake) between the CHoA and the IPcn (as
obtained in Step 3a) via the tunnel between the MN and the CHA.
Step 11:
Yegin, et al. Expires January 4, 2015 [Page 9]
Internet-Draft CNet-Homing July 2014
The communication between the application and the CN shall use CHoA
and the IPcn as the end-points, and go via the tunnel between the MN
and the CHA.
The MN stack shall prevent use of CHoA and the associated tunnel for
any IP sesssion other than the ones between the MN and the CNs served
by the CHA. The source address selection mechanism on the MN should
select CHoA for any CN whose discovered CHA matches the CHA
associated with the CHoA, and shall not select CHoA for any other
communication.
4.2. Handover
Figure 5 depicts the detailed message flow for re-establishing the
MN-CHA tunnel when the MN performs an IP handover.
MN
+------+
| |
App Stack CHA
| | |
| [1] |
| | |
| |-----------[2]--->|
| | |
| |<----------[3]----|
| | |
| |===========[4]====|
Figure 5. Detailed handover.
Step 1:
The MN configures a new IP address from the new access network
(IPxs2).
Step 2:
When the IP address of the MN changes, the MN shall send a Binding
Update to the CHA for informing the CHA about this change and binding
the CHoA to the new IP address. The Binding Update shall include a
CoA set to the IPxs2 and the HoA set to the CHoA.
Step 3:
The CHA shall process the incoming Binding Update according to
[RFC6275][RFC5944] and return a Binding Acknowledgement.
Yegin, et al. Expires January 4, 2015 [Page 10]
Internet-Draft CNet-Homing July 2014
Step 4:
The MN and the CHA shall setup a new tunnel with each other upon
successful execution of Steps 3 and 4. The tunnel end-points shall
be set to IPxs2 and IPcha. The CHA shall forward any incoming packet
whose destination is CHoA towards the MN via the tunnel. The MN
shall forward any outgoing packet whose source address is CHoA
towards the CN via the tunnel.
4.3. Teardown
Figure 6 depicts the detailed message flow for tearing down the MN-
CHA tunnel when the application closes the connection.
MN
+------+
| |
App Stack CHA CN
| | | |
|-[1]->| | |
| | | |
| |<-=========[2]====------->|
| | | |
| |-----------[3]--->| |
| | | |
| |<----------[4]----| |
| | | |
Figure 6. Detailed tear down.
Step 1:
The application attempts to close the session with the CN.
Step 2:
The MN shall close the connection with the CN, if a connection-
oriented transport is used (e.g., TCP, SCTP).
Step 3:
The MN should send a Binding Update to CHA with lifetime set to 0.
Note that the MN may choose not to tear down the tunnel immediately
after the IP session terminates. The MN may put a grace period on
this action and keep both the tunnel and the CHoA for a while in case
they get used for a subsequent IP session with the same CN or another
Yegin, et al. Expires January 4, 2015 [Page 11]
Internet-Draft CNet-Homing July 2014
CN using the same CHA. The amount of grace period is a configurable
parameter.
Step 4:
The CHA shall send a Binding Acknowledgement back to the MN. The CHA
and the MN shall release the tunnel, remove the forwarding entries
for the CHoA. The CHA shall return the CHoA to the pool of available
IP addresses. The MN shall unconfigure the CHoA on its stack.
If a connectionless protocol is used (e.g., UDP) between the MN and
the CN, then the tear down may be triggered based on an inactivity
timer or other indications.
5. Variation
A PMIP-based variation of this solution is under construction and
will appear in a future version of this document.
6. Security Considerations
If the Binding Update message is not origin authenticated, then it
may be leveraged for a DoS attack depleting the CHoA pool on the CHA.
This threat may be mitigated by allocating the CHoA from a very large
address pool, such as 10.0.0.0/8 for IPv4, or a /64 prefix for IPv6
that is not trivial to deplete. Depleting such a large address pool
requires a significant brute-force attack. At that point the type of
attack and its mitigations change and fall outside the scope of this
document. Such attacks trigger CN and serving ISP/data center's
defense against brute force attacks.
Another mitigation is to use origin authentication, replay and
integrity protection on the Mobile IP messages
[RFC6275][RFC5944][RFC4285] .
The tunnel between the MN and the CHA is created for the sole purpose
of carrying IP packets between the MN and the CN. It is not meant to
be used for carrying IP packets between the MN and arbitrary nodes on
the Internet. In order to prevent abuse of this tunnel the CHA shall
setup firewall rules to drop any packets that are sent by the MN and
that do not have a valid destination IP address (i.e., IP address of
one of the CNs served by the CHA).
Yegin, et al. Expires January 4, 2015 [Page 12]
Internet-Draft CNet-Homing July 2014
7. IANA Considerations
TBD
8. Acknowledgements
The authors would like to thank Alexandru Petrescu, Ali Ahmad Hassan,
Carlos Jesus Bernardos Cano, Charles Perkins, Danny Moses, Hassnaa
Moustafa, Kostas Pentikousis, Marco Liebsch, Ryuji Wakikawa, Tiago
Condeixa, Wu-chi Feng for their valuable comments and input on this
document.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", RFC
5944, November 2010.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
9.2. Informative References
[I-D.ietf-dmm-requirements]
Chan, A., Liu, D., Seite, P., Yokota, H., and J. Korhonen,
"Requirements for Distributed Mobility Management", draft-
ietf-dmm-requirements-17 (work in progress), June 2014.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[RFC4285] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Authentication Protocol for Mobile IPv6", RFC
4285, January 2006.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
Yegin, et al. Expires January 4, 2015 [Page 13]
Internet-Draft CNet-Homing July 2014
[RFC5563] Leung, K., Dommety, G., Yegani, P., and K. Chowdhury,
"WiMAX Forum / 3GPP2 Proxy Mobile IPv4", RFC 5563,
February 2010.
Authors' Addresses
Alper Yegin
Samsung
Istanbul
Turkey
Email: alper.yegin@partner.samsung.com
Kisuk Kweon
Samsung
Suwon
South Korea
Email: kisuk.kweon@samsung.com
Jinsung Lee
Samsung
Suwon
South Korea
Email: js81.lee@samsung.com
Jungshin Park
Samsung
Suwon
South Korea
Email: shin02.park@samsung.com
Yegin, et al. Expires January 4, 2015 [Page 14]
