One document matched: draft-templin-ironmike-00.txt
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational November 23, 2010
Expires: May 27, 2011
IRON and MOBIKE
draft-templin-ironmike-00.txt
Abstract
The Internet Routing Overlay Network (IRON) is a new routing and
addressing architecture based on encapsulation of inner network layer
packets within outer network layer headers using a non-broadcast,
multiple access (NBMA) virtual interface model. The IKEv2 Mobility
and Multihoming Protocol (MOBIKE) allows a Virtual Private Network
(VPN) client to keep a connection to a VPN gateway active across
multiple network points of attachment or while moving from one
network point of attachment to another. This document examines the
similarities between IRON and MOBIKE, and observes that they are
addressing the same fundamental networking objectives but with
differing signaling mechanisms and differing security properties. It
further proposes ways in which the basic MOBIKE model could be
extended through adoption of IRON architectural constructs.
Status of this Memo
This Internet-Draft is submitted to IETF 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 May 27, 2011.
Copyright Notice
Copyright (c) 2010 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
Templin Expires May 27, 2011 [Page 1]
Internet-Draft IRON November 2010
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IRON Conceptual Model . . . . . . . . . . . . . . . . . . . . 3
3. MOBIKE Conceptual Model . . . . . . . . . . . . . . . . . . . 5
4. IRON and MOBIKE Comparison . . . . . . . . . . . . . . . . . . 6
5. IRON Extensions for MOBIKE . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Templin Expires May 27, 2011 [Page 2]
Internet-Draft IRON November 2010
1. Introduction
The Internet Routing Overlay Network (IRON) [I-D.templin-iron] is a
new routing and addressing architecture based on encapsulation of
inner network layer packets within outer network layer headers using
a non-broadcast, multiple access (NBMA) virtual interface model. It
allows client routers to keep a connection to a serving router active
across multiple network points of attachment or while moving from one
network point of attachment to another. IRON provides end user
networks (EUN) with stable IP prefixes taken from a home virtual
overlay network aggregated prefix that can be used across multiple
ISP connections with support for mobility and multihoming. IRON uses
bidirectional tunnels to connect mobile and/or multihomed clients to
servers in a home virtual overlay network, and uses unidirectional
tunnels to forward packets to virtual overlay network elements beyond
the server. In this arrangement, the clients can access resources in
the virtual overlay network and/or Internet as well as connect to
other clients using the virtual overlay network as a transit.
The Internet Key Exchange (IKEv2) Protocol [RFC4306] and its
associated IKEv2 Mobility and Multihoming Protocol (MOBIKE) [RFC4555]
provide a Virtual Private Network (VPN) management system for
managing IPsec tunnels [RFC4301]. As an adjunct to IKEv2, MOBIKE
allows client routers to keep a connection to a serving router active
across multiple network points of attachment or while moving from one
network point of attachment to another. MOBIKE establishes and
maintains VPN tunnels to connect mobile and/or multihomed clients and
their EUNs to servers in a home enterprise network. The EUNs can
then use stable IP prefixes taken from the home enterprise network's
address space even if the tunnels connect across multiple ISP
connections. In this arrangement, the clients can access resources
in the enterprise network and/or Internet as well as connect to other
clients using the enterprise network as a transit.
This document examines the similarities between IRON and MOBIKE, and
observes that they are addressing the same fundamental networking
objectives but with differing signaling mechanisms and differing
security properties. It further proposes ways in which the basic
MOBIKE model could be extended through adoption of IRON architectural
constructs.
2. IRON Conceptual Model
IRON is descended from the RANGER architecture
[RFC5720][I-D.russert-rangers]; it uses Virtual Enterprise Traversal
(VET) [I-D.templin-intarea-vet] and the Subnetwork Encapsulation and
Adaptation Layer (SEAL) [I-D.templin-intarea-seal] as its functional
Templin Expires May 27, 2011 [Page 3]
Internet-Draft IRON November 2010
building blocks. IRON uses the VET NBMA virtual interface model for
coordination between neighboring routers in a virtual overlay
network. It also uses SEAL as an IP-in-IP encapsulation sublayer,
and uses the SEAL Control Message Protocol (SCMP) for signaling
between tunnel endpoints. In particular, IRON clients use SEAL and
SCMP to establish bidirectional tunnels with IRON servers and to
inform the servers of any outer network layer address changes. IRON
also uses unidirectional tunnels to forward packets to routers beyond
the server that are closer to the final destination.
IRON clients connect End User Networks (EUNs) which are assigned EUN
prefixes (EPs) taken from highly-aggregated IP prefixes known as
Virtual Prefixes (VPs). IRON servers connect their clients to a
virtual overlay network configured over an internetwork such as the
global Internet. IRON relays in turn connect the virtual overlay
network to the native (i.e., non-IRON) Internet. The IRON relays in
the virtual overlay network belong to a single Autonomous System (AS)
and use eBGP to advertise the VPs externally into the native Internet
default-free routing system. IRON relays and servers further use an
interior routing protocol such as iBGP to track the EPs assigned to
clients.
To provide better service to clients, sufficient numbers of IRON
relays and servers should be uniformly distributed throughout the
internetwork over which the virtual overlay network is configured.
Since the number of IRON servers needed may be very large, each
server is required only to keep track of its own set of clients and
to convey its client constituency to each of the relays. The
interior routing between servers and relays is therefore arranged as
a partial mesh in which servers have partial topology information and
relays have full topology information. In this partial topology
arrangement, routing within the virtual overlay network may direct
the initial packets in a flow through a suboptimal path that involves
extraneous relays and servers as intermediate hops, but redirect
messages will quickly inform the client of a better route.
The three basic packet flow archetypes supported by this model
include:
1. From a host A in IRON EUN A to a host B in IRON EUN B
2. From a host A in IRON EUN A to a host C in the Internet
3. From a host C in the Internet to a host A in IRON EUN A
In case 1, the initial packets in the flow sourced from host A are
forwarded through the bidirectional tunnel between the client and
server connecting EUN A to the virtual overlay network. The server
Templin Expires May 27, 2011 [Page 4]
Internet-Draft IRON November 2010
then forwards the packets to a relay, which returns redirect messages
and forwards the packets further to the server that serves EUN B. The
EUN B server then forwards the packets via the bidirectional tunnel
to the client connecting EUN B to the virtual overlay network, where
they are delivered to host B. Following the redirect messages,
subsequent packets flow directly via a unidirectional tunnel from the
EUN A client to the EUN B server with the relay and EUN A server
removed from the path.
In case 2, packets sourced from host A are forwarded through the
bidirectional tunnel between the client and server, then forwarded to
a relay that connects the virtual overlay network to the rest of the
Internet. The packets are then forwarded via normal Internet routing
until they reach host C.
In case 3, packets sourced from host C are forwarded through normal
Internet routing until they reach a relay that connects the virtual
overlay network to the rest of the Internet. The relay then forwards
the packets to the correct server, where they are forwarded through
the bidirectional tunnel to the client then delivered to host A.
These fundamental packet flow archetypes apply to the case of IRON
virtual overlay networks which connect tunnel endpoints that do not
use authentication, integrity and/or confidentiality protection
mechanisms. However, the same archetypes apply when the virtual
overlay network consists of a system tunnels that use symmetric
securing mechanisms such as in the MOBIKE conceptual model described
in the next section.
3. MOBIKE Conceptual Model
Virtual Private Network (VPN) clients use the Internet Key Exchange
(IKEv2) protocol [RFC4306] to set up IP Security Protocol (IPsec)
[RFC4301] security associations with VPN servers. The client then
uses the security association to create a bidirectional VPN tunnel to
the server, which in turn connects the VPN to a protected enterprise
network. Using MOBIKE, the client can then register multiple tunnel
endpoint locator addresses with the server (e.g., one address per
access technology link) and can change its set of locator addresses
as it breaks connections with old access technology links and forms
connections with new ones. Hence, multihoming and mobility are
naturally supported.
The VPN client and all of the devices in its associated EUN then
receive IP address/prefix configurations as though they were a
virtual extension of the protected enterprise network ,and can access
any available services and resources within the enterprise network.
Templin Expires May 27, 2011 [Page 5]
Internet-Draft IRON November 2010
This could include services and resources both inside the protected
enterprise network and within other EUNs connected by other VPN
tunnels. For example, hosts behind a VPN client router located in
Phoenix could connect to hosts behind a VPN client router located in
Miami using a protected enterprise network that spans the continental
United States as a secure transit network. This model is seen in
common practice today for large corporate enterprise networks with
their associated branch offices and nomadic laptop users.
The protected enterprise network may be completely isolated, or it
may further connect to the public Internet via firewalls, proxies
and/or packet filtering gateways of some form. These secure gateway
devices in the MOBIKE conceptual model correspond directly to the
relay function found in the IRON conceptual model. Indeed, the same
three packet flow archetypes described above for the IRON conceptual
model apply also to the MOBIKE conceptual model. When the protected
enterprise network comprises native links and ordinary IP routing
(i.e., as opposed to a strict full./partial mesh of tunnels), a
fourth packet flow archetype is enabled in which simple hosts within
the protected enterprise network can participate.
4. IRON and MOBIKE Comparison
The obvious fundamental distinction between the IRON and MOBIKE
conceptual models lies in the nature of their respective tunneling
models. In the basic IRON model, tunnels are created using the SCMP,
and tunneled packets are identified by a tunnel ID nonce that can be
used to defeat off-path attacks. Unlike the VPN tunnels used by
MOBIKE, however, the basic IRON tunnel model does not provide for
authentication, integrity and confidentiality; hence, it is open to
on-path attacks and/or eavesdropping. The basic IRON security model
may be sufficient for certain scenarios (e.g., open Internet access
for ISP customers) while the VPN tunnel model used by MOBIKE may be
required for others (e.g., nomadic user access to protected corporate
IT infrastructure resources).
Aside from the fundamental tunneling model distinction, the IRON and
MOBIKE conceptual models share striking similarities in their
networking models. First, IRON and MOBIKE clients locate nearby
servers through some form of service discovery and use the SCMP and
MOBIKE signaling mechanisms (respectively) to coordinate their tunnel
endpoint locator addresses with the servers to support mobility and
multihoming. Moreover, the IRON virtual overlay network and the
MOBIKE protected enterprise network models fulfill the same roles
from the viewpoint of the clients - both networking abstractions
provide transit service allowing hosts behind clients to participate
in the communication flow archetypes discussed in Section 2 above.
Templin Expires May 27, 2011 [Page 6]
Internet-Draft IRON November 2010
Finally, the IRON relays and MOBIKE enterprise network firewalls/
proxies/packet filtering gateways provide the means for hosts to
access resources in the public Internet. Figure 1 and Figure 2
depict the IRON and MOBIKE network architectural models:
.-.
,-( _)-.
.-(_ (_ )-.
(__ Internet _)
`-(______)-'
<------------ Relays ------------>
________________________
(::::::::::::::::::::::::)-.
.-(:::::::::::::::::::::::::::::)
.-(:::::::::::::::::::::::::::::::::)-.
(:::: IRON Virtual Overlay Network :::::)
`-(:::::::::::::::::::::::::::::::::)-'
`-(::::::::::::::::::::::::::::)-'
<----------- IRON Servers ---------->
.-. .-. .-.
,-( _)-. ,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-.
(__ ISP A _) (__ ISP B _) ... (__ ISP x _)
`-(______)-' `-(______)-' `-(______)-'
<----------- NATs ------------>
<-------- IRON Clients and EUNs ---------->
Figure 1: IRON Network Architectural Model
Templin Expires May 27, 2011 [Page 7]
Internet-Draft IRON November 2010
.-.
,-( _)-.
.-(_ (_ )-.
(__ Internet _)
`-(______)-'
<------- Firewalls/Proxies/etc. ------->
________________________
(::::::::::::::::::::::::)-.
.-(:::::::::::::::::::::::::::::)
.-(:::::::::::::::::::::::::::::::::)-.
(::::: Protected Enterprise Network ::::)
`-(:::::::::::::::::::::::::::::::::)-'
`-(::::::::::::::::::::::::::::)-'
<---------- VPN gateways ------------>
.-. .-. .-.
,-( _)-. ,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-.
(__ ISP A _) (__ ISP B _) ... (__ ISP x _)
`-(______)-' `-(______)-' `-(______)-'
<----------- NATs ------------>
<-------- VPN Clients and EUNs ----------->
Figure 2: MOBIKE Network Architectural Model
5. IRON Extensions for MOBIKE
The basic MOBIKE model is agnostic to the routing architecture of the
protected enterprise network. As long as the enterprise network
routing system ensures reachability for any desired resources or
services, the basic service requirements for MOBIKE clients are
satisfied. However, the basic MOBIKE model does not address the
requirement for a mobile VPN client to maintain generally shortest-
path routes which can be maintained only if the mobile client has a
means for transporting its VPN endpoint from a former serving gateway
to one that is topologically closer. In the IRON model, this tunnel
endpoint mobility is naturally supported by the SCMP signaling
protocol in a manner that could be applied equally to MOBIKE.
If MOBIKE VPN clients were allowed to change between serving VPN
gateways, however, these changes would need to be disseminated as
updates in the protected enterprise network routing system.
Depending on the number of mobile clients and the nature of the
enterprise network routing system, such mobility could impart
unacceptable routing churn. In order to address this routing churn,
Templin Expires May 27, 2011 [Page 8]
Internet-Draft IRON November 2010
the MOBIKE enterprise network could adopt the IRON routing model of
using a dynamic routing protocol over a partial mesh of tunnels
between relays and servers to prevent localized mobility events from
imparting churn to the entire routing system.
________________________________________
.-( )-.
.-( . . . . . . . . . . . . )-.
.-( . +========+ +=====+ . )-.
.( . || || || || . ).
.( . || || || vv . ).
.( +--------++--+ || || +------------+ ).
( +==>| Server(A) | vv || | Server(C) |====+ )
( // +---------|\-+ +--++----++--+ +------------+ \\ )
( // .-. . | \ | Relay(B) | . .-. \\ )
( //,-( _)-. . | \ +-v----------+ . ,-( _)-\\ )
( .||_ (_ )-. .| \____| Protected Net. . .-(_ (_ ||. )
( _|| ISP A .) | . . . . . . . . (__ ISP C ||_))
( ||-(______)-' | (redirect) `-(______)|| )
( || | | | vv )
( +-----+-----+ | +-----+-----+ )
| Client(A) | <--+ | Client(C) |
+-----+-----+ Unprotected Network +-----+-----+
| ( (e.g., the public Internet) ) |
.-. .-( .-) .-.
,-( _)-. .-(________________________)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-.
(_ IRON EUN(A) ) (_ IRON EUN(C) )
`-(______)-' `-(______)-'
| |
+---+----+ +---+----+
| Host(A)| | Host(C)|
+--------+ +--------+
Figure 3: IRON and MOBIKE Route Optimization
IRON further provides a secure redirection capability so that
unnecessary forwarding hops through servers and relays can be
eliminated. With reference to Figure 3, in the IRON model when
Host(A) sends a packet to Host(C), the packet flows through the
bidirectional tunnel between Client(A) and Server(A). Server(A) then
forwards the packet through Relay(B), which forwards the packet to
Server(C) and also returns a redirect message. Server(A) in turn
forwards the redirect to Client(A) which can then forward future
packets via a unidirectional tunnel directly to Server(C) thus
effectively bypassing the unnecessary hops through Server(A) and
Relay(B). In the MOBIKE model, however, this form of route
optimization could only be supported if Client(A) and Server(C)
either shared a security association or were willing to engage in the
Templin Expires May 27, 2011 [Page 9]
Internet-Draft IRON November 2010
necessary IKEv2 transactions to establish a security association.
The latter scenario may be wasteful if Host(A) will only send a small
number of packets to Host(C), and there may be no way of knowing a
priori whether this will be true.
MOBIKE deployments could therefore benefit from using either a full
or partial route optimization capability modeled after IRON depending
on the particular deployment scenario. For example, in scenarios in
which all VPN clients and gateways either share a full set of
security associations or can establish security associations quickly,
the full IRON route optimization model can be used. Otherwise, a
protected enterprise network servicing MOBIKE clients could support a
partial route optimization in which a Server(A) would process the
redirect message sent by Relay(B) without forwarding it on to
Client(A). Server(A) could then forward packets directly to
Server(C) while bypassing Relay(B) in order to provide a shorter
path. However, this approach may require Server(A) to maintain
considerable dynamic routing state due to route optimization if it
services many clients and/or those clients connect to many
correspondents.
6. IANA Considerations
There are no IANA considerations for this document.
7. Security Considerations
Security considerations for IRON and MOBIKE appear in their
respective documents.
8. Acknowledgements
Dave Thaler and Gabriel Montenegro mentioned that MOBIKE addresses
mobility and multihoming, and therefore may be related to the IRON
tradespace.
9. References
9.1. Normative References
[I-D.templin-iron]
Templin, F., "The Internet Routing Overlay Network
(IRON)", draft-templin-iron-13 (work in progress),
October 2010.
Templin Expires May 27, 2011 [Page 10]
Internet-Draft IRON November 2010
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
9.2. Informative References
[I-D.russert-rangers]
Russert, S., Fleischman, E., and F. Templin, "RANGER
Scenarios", draft-russert-rangers-05 (work in progress),
July 2010.
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-23 (work in
progress), October 2010.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-16 (work in progress),
July 2010.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC5720] Templin, F., "Routing and Addressing in Networks with
Global Enterprise Recursion (RANGER)", RFC 5720,
February 2010.
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires May 27, 2011 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 14:00:27 |