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 (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.

Table of Contents

• 1. Introduction
• 2. IRON Conceptual Model
• 3. MOBIKE Conceptual Model
• 4. IRON and MOBIKE Comparison
• 5. IRON Extensions for MOBIKE
• 6. IANA Considerations
• 7. Security Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Author's Address

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 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 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 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 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 ---------->

                           .-.
                        ,-(  _)-.
                     .-(_    (_  )-.
                    (__ Internet   _)
                       `-(______)-'

       <-------   Firewalls/Proxies/etc.  ------->
                 ________________________
                (::::::::::::::::::::::::)-.
            .-(:::::::::::::::::::::::::::::)
         .-(:::::::::::::::::::::::::::::::::)-.
        (::::: Protected Enterprise Network ::::)
         `-(:::::::::::::::::::::::::::::::::)-'
            `-(::::::::::::::::::::::::::::)-'

       <----------    VPN gateways    ------------>
       .-.                .-.                     .-.
    ,-(  _)-.          ,-(  _)-.               ,-(  _)-.
 .-(_    (_  )-.    .-(_    (_  )-.         .-(_    (_  )-.
(__   ISP A    _)  (__   ISP B    _)  ...  (__   ISP x    _)
   `-(______)-'       `-(______)-'            `-(______)-'
        <-----------      NATs        ------------>

        <-------- VPN Clients and EUNs ----------->

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, 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)|
     +--------+                                         +--------+

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 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

9.2. Informative References

Author's Address