One document matched: draft-templin-ironmike-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict='yes'?>
<?rfc iprnotified='no'?>
<rfc category="info" docName="draft-templin-ironmike-01.txt" ipr="trust200811">
<front>
<title abbrev="IRON">IRON and MOBIKE</title>
<author fullname="Fred L. Templin" initials="F." role="editor"
surname="Templin">
<organization>Boeing Research & Technology</organization>
<address>
<postal>
<street>P.O. Box 3707 MC 7L-49</street>
<city>Seattle</city>
<region>WA</region>
<code>98124</code>
<country>USA</country>
</postal>
<email>fltemplin@acm.org</email>
</address>
</author>
<date day="16" month="May" year="2011" />
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Internet Routing Overlay Network (IRON) <xref
target="RFC6179"></xref> 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.</t>
<t>The Internet Key Exchange (IKEv2) Protocol <xref
target="RFC4306"></xref> and its associated IKEv2 Mobility and
Multihoming Protocol (MOBIKE) <xref target="RFC4555"></xref> provide a
Virtual Private Network (VPN) management system for managing IP Security
Protocol (IPsec) tunnels <xref target="RFC4301"></xref>. 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.</t>
<t>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.</t>
</section>
<section anchor="iron" title="IRON Conceptual Model">
<t>IRON is descended from the RANGER architecture <xref
target="RFC5720"></xref><xref target="RFC6139"></xref>; it uses Virtual
Enterprise Traversal (VET) <xref
target="I-D.templin-intarea-vet"></xref> and the Subnetwork
Encapsulation and Adaptation Layer (SEAL) <xref
target="I-D.templin-intarea-seal"></xref> as its functional 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 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.</t>
<t>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.</t>
<t>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 <xref target="I-D.templin-aero"></xref>.</t>
<t>The three basic packet flow archetypes supported by this model
include:</t>
<t><list style="numbers">
<t>From a host A in IRON EUN A to a host B in IRON EUN B</t>
<t>From a host A in IRON EUN A to a host C in the Internet</t>
<t>From a host C in the Internet to a host A in IRON EUN A</t>
</list>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 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="mobike" title="MOBIKE Conceptual Model">
<t>VPN clients use the Internet Key Exchange (IKEv2) protocol <xref
target="RFC4306"></xref> to set up IPsec <xref target="RFC4301"></xref>
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.</t>
<t>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 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.</t>
<t>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.</t>
</section>
<section title="IRON and MOBIKE Comparison">
<t>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).</t>
<t>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 access resources in the public Internet.
<xref target="IRON"></xref> and <xref target="MOBIKE"></xref> depict the
IRON and MOBIKE network architectural models:</t>
<t><figure anchor="IRON" title="IRON Network Architectural Model">
<artwork><![CDATA[ .-.
,-( _)-.
.-(_ (_ )-.
(__ Internet _)
`-(______)-'
<------------ Relays ------------>
________________________
(::::::::::::::::::::::::)-.
.-(:::::::::::::::::::::::::::::)
.-(:::::::::::::::::::::::::::::::::)-.
(:::: IRON Virtual Overlay Network :::::)
`-(:::::::::::::::::::::::::::::::::)-'
`-(::::::::::::::::::::::::::::)-'
<----------- IRON Servers ---------->
.-. .-. .-.
,-( _)-. ,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-.
(__ ISP A _) (__ ISP B _) ... (__ ISP x _)
`-(______)-' `-(______)-' `-(______)-'
<----------- NATs ------------>
<-------- IRON Clients and EUNs ---------->]]></artwork>
</figure></t>
<t><figure anchor="MOBIKE" title="MOBIKE Network Architectural Model">
<artwork><![CDATA[ .-.
,-( _)-.
.-(_ (_ )-.
(__ Internet _)
`-(______)-'
<------- Firewalls/Proxies/etc. ------->
________________________
(::::::::::::::::::::::::)-.
.-(:::::::::::::::::::::::::::::)
.-(:::::::::::::::::::::::::::::::::)-.
(::::: Protected Enterprise Network ::::)
`-(:::::::::::::::::::::::::::::::::)-'
`-(::::::::::::::::::::::::::::)-'
<---------- VPN gateways ------------>
.-. .-. .-.
,-( _)-. ,-( _)-. ,-( _)-.
.-(_ (_ )-. .-(_ (_ )-. .-(_ (_ )-.
(__ ISP A _) (__ ISP B _) ... (__ ISP x _)
`-(______)-' `-(______)-' `-(______)-'
<----------- NATs ------------>
<-------- VPN Clients and EUNs ----------->]]></artwork>
</figure></t>
</section>
<section title="IRON Extensions for MOBIKE">
<t>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.</t>
<t>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, 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.</t>
<figure anchor="OPT" title="IRON and MOBIKE Route Optimization">
<artwork><![CDATA[ ________________________________________
.-( )-.
.-( . . . . . . . . . . . . )-.
.-( . +========+ +=====+ . )-.
.( . || || || || . ).
.( . || || || 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)|
+--------+ +--------+]]></artwork>
</figure>
<t></t>
<t>IRON further uses the AERO redirection capability <xref
target="I-D.templin-aero"></xref> so that unnecessary forwarding hops
through servers and relays can be eliminated. With reference to <xref
target="OPT"></xref>, 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 necessary IKEv2 transactions to establish a security
association.</t>
<t>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.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>There are no IANA considerations for this document.</t>
</section>
<section anchor="secure" title="Security Considerations">
<t>Security considerations for IRON and MOBIKE appear in their
respective documents.</t>
</section>
<section anchor="ack" title="Acknowledgements">
<t>Dave Thaler and Gabriel Montenegro mentioned that MOBIKE addresses
mobility and multihoming, and therefore may be related to the IRON
solution space.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.6179"?>
<?rfc include="reference.RFC.4555"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4301"?>
<?rfc include="reference.RFC.4306"?>
<?rfc include="reference.I-D.templin-intarea-seal"?>
<?rfc include="reference.I-D.templin-intarea-vet"?>
<?rfc include="reference.I-D.templin-aero"?>
<?rfc include="reference.RFC.5720"?>
<?rfc include="reference.RFC.6139"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 15:50:18 |