One document matched: draft-templin-ironmike-01.txt
Differences from draft-templin-ironmike-00.txt
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational May 16, 2011
Expires: November 17, 2011
IRON and MOBIKE
draft-templin-ironmike-01.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. 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 November 17, 2011.
Copyright Notice
Copyright (c) 2011 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
Templin Expires November 17, 2011 [Page 1]
Internet-Draft IRON May 2011
(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 November 17, 2011 [Page 2]
Internet-Draft IRON May 2011
1. Introduction
The Internet Routing Overlay Network (IRON) [RFC6179] 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 their serving routers 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
clients use bidirectional tunnels to connect to their home servers,
and use unidirectional tunnels to forward packets to servers that are
closer to the final destination. 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 IP Security Protocol (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 bidirectional 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. 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][RFC6139]; 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 building blocks. IRON
uses the VET NBMA virtual interface model for coordination between
Templin Expires November 17, 2011 [Page 3]
Internet-Draft IRON May 2011
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 their home servers and to inform the servers of any
outer network layer address changes. IRON also uses unidirectional
tunnels to forward packets to servers 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 substantial, 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 redirection
messages will quickly inform the client of a better route
[I-D.templin-aero].
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 November 17, 2011 [Page 4]
Internet-Draft IRON May 2011
then forwards the packets to a relay, which returns redirection
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
redirection, subsequent packets flow directly via a unidirectional
tunnel from the EUN A client to the EUN B server while bypassing the
relay and EUN A server.
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 symmetric securing mechanisms. However, the same archetypes
apply when the virtual overlay network consists of a system of VPN
tunnels such as in the MOBIKE conceptual model described in the next
section.
3. MOBIKE Conceptual Model
VPN clients use the Internet Key Exchange (IKEv2) protocol [RFC4306]
to set up 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.
This could include services and resources both inside the protected
enterprise network and within other EUNs connected by other VPN
Templin Expires November 17, 2011 [Page 5]
Internet-Draft IRON May 2011
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.
Finally, the IRON relays and MOBIKE enterprise network firewalls/
proxies/packet filtering gateways provide the means for hosts to
Templin Expires November 17, 2011 [Page 6]
Internet-Draft IRON May 2011
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 November 17, 2011 [Page 7]
Internet-Draft IRON May 2011
.-.
,-( _)-.
.-(_ (_ )-.
(__ 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 November 17, 2011 [Page 8]
Internet-Draft IRON May 2011
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 enterprise network 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 uses the AERO redirection capability [I-D.templin-aero]
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 redirection 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 November 17, 2011 [Page 9]
Internet-Draft IRON May 2011
necessary IKEv2 transactions to establish a security association.
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
solution space.
9. References
9.1. Normative References
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, June 2006.
[RFC6179] Templin, F., "The Internet Routing Overlay Network
(IRON)", RFC 6179, March 2011.
Templin Expires November 17, 2011 [Page 10]
Internet-Draft IRON May 2011
9.2. Informative References
[I-D.templin-aero]
Templin, F., "Asymmetric Extended Route Optimization
(AERO)", draft-templin-aero-00 (work in progress),
March 2011.
[I-D.templin-intarea-seal]
Templin, F., "The Subnetwork Encapsulation and Adaptation
Layer (SEAL)", draft-templin-intarea-seal-29 (work in
progress), March 2011.
[I-D.templin-intarea-vet]
Templin, F., "Virtual Enterprise Traversal (VET)",
draft-templin-intarea-vet-24 (work in progress),
March 2011.
[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.
[RFC6139] Russert, S., Fleischman, E., and F. Templin, "Routing and
Addressing in Networks with Global Enterprise Recursion
(RANGER) Scenarios", RFC 6139, February 2011.
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 November 17, 2011 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 13:59:09 |