Boeing Research & Technology

P.O. Box 3707 Seattle WA 98124 USA fltemplin@acm.org

I-D Internet-Draft Enterprise networks provide a secured data communications infrastructure built for the purpose of information sharing and increased productivity for end users within the organization. Enterprise networks are often organized as private Internets unto themselves that connect to the global Internet either not at all or via firewalls, proxies, and/or other network securing devices. This document discusses an AERO enterprise network profile that outlines new and more flexible methods for connecting, tracking and managing mobile organizational assets.

Enterprise networks provide a secured data communications infrastructure built for the purpose of information sharing and increased productivity for end users within the organization. Enterprise networks are often organized as private Internets unto themselves that connect to the global Internet either not at all or via firewalls, proxies, and/or other network securing devices. It is assumed that enterprise networks use the Internet Protocols (IP) for interior routing and addressing services. Enterprise networks typically support two basic access methods. First, on-campus wired and wireless LANs allow mobile devices (e.g., phones, tablets, laptops, etc.) to connect to the infrastructure using the physical security of a wired link or wired-equivalent security over wireless LANs (e.g., using IEEE802.1x, etc.). Second, mobile devices that connect via the public Internet can enter the enterprise via a Virtual Private Network (VPN) tunnel connection to an enterprise border security gateway. In both cases, the device receives a Topologically-Fixed IP address (TFA) from the access link that would need to change if the device moves to a new link. Using Asymmetric Extended Route Optimization (AERO) , however, mobile devices can receive a Topology-Independent IP address or prefix (TIA) that remains stable even if the device's TFA changes frequently during its daily operations. The TIA can moreover be uniquely associated with the device so that the same TIA is received every time the device connects to the enterprise network. This document discusses an AERO enterprise network profile that outlines new and flexible methods for connecting, tracking and managing enterprise mobile devices.

The terminology in the normative references applies; the following terms are defined within the scope of this document: an IP address assigned to a mobile device's access technology interface for which the address has a fixed location within the enterprise network routing scheme. (For example, an IP address assigned to an Ethernet interface by an address provisioning service connected to the local link.) an IP address or prefix assigned to an enterprise mobile device independent of any underlying access technology interfaces. The IP address or prefix is maintained through the use of tunneling over available access technologies, and is kept separate from the enterprise topologically-fixed network routing scheme. The TIA is one and the same as an AERO Client Prefix (ACP) as defined below. a service for provisioning TIAs while accounting for device mobility and without exposing mobility events to the core enterprise network routing service. an enterprise mobile device (e.g., laptop computer, tablet, smart phone, etc) that acts as an AERO Client. a node that receives a TIA within the scope of the enterprise network that it can use continuously wherever it roams. a node that provides default forwarding services for AERO Clients and maintains a peering session with each AERO Relay to report its current roster of associated Clients. a node that keeps track of all Client/Server associations and also serves as a gateway between the TIA and TFA address spaces. a virtual topology over which AERO Clients, Servers and Relays can exchange packets as "neighbors" on the link. The AERO link spans the Enterprise network as a tunnel virtual non-broadcast, multiple access (NBMA) link. a TIA prefix associated with the AERO link and from which AERO Client Prefixes (ACPs) are derived (for example, the IPv6 ACP 2001:db8:1:2::/64 is derived from the IPv6 ASP 2001:db8::/32). The DHCPv6 server is responsible for secure management of the ASP and delegation of ACPs to Client. a more-specific TIA prefix taken from an ASP and delegated to a Client.

An enterprise network mobile device user ("Bill") begins his workday by seating his primary EUD (e.g., a laptop computer, a tablet, a smart phone, etc.) in a docking station at his office desk and turning the device on. The docking station connects Bill's EUD to the enterprise wired LAN, and the EUD receives a TFA from the infrastructure. Bill's EUD further discovers an AERO Server within the enterprise network and requests an AERO Client Prefix (ACP) delegation. Bill's EUD receives the same ACP delegation it gets every time it connects to the enterprise network, because the DHCPv6 server has an administratively set mapping between the ACP and Bill's EUD device ID. Bill's EUD can then access topologically-fixed enterprise services using its TFA directly, and can access AERO services by using an address from its ACP as the source address for tunneling over the enterprise network. As Bill's workday unfolds, his EUD uses the AERO service to interact with other EUDs in peer-to-peer sessions, join lengthy virtual conferencing sessions, access enterprise fileshares, etc. The AERO service ensures that optimal routes are maintained so that tunneled communications flow over direct paths and network infrastructure elements are not unnecessarily over-burdened. While communications sessions such as the video conference are still in progress, Bill leaves the office to attend a meeting in a nearby conference room. He disconnects his EUD from the docking station and in the process drops his connection to the wired LAN. The EUD quickly enables a WiFi interface that searches for a Service Set Identifier (SSID) that can provide wireless access within the enterprise network. The EUD authenticates itself to the network via the SSID using its pre-loaded certificates, and uses a securing mechanism such as IEEE 802.1x to assure Confidentiality, Integrity and Availability (CIA). The EUD receives a new TFA from the network, then communicates its new ACP-to-TFA association to its current AERO Server(s) and any correspondent AERO Clients. Any ongoing communications sessions will continue to see the same (stable) ACP. Bill then leaves the enterprise campus to attend an off-site customer meeting with his EUD still powered on and actively seeking to maintain network connectivity. As Bill departs from the building, the WiFi signal fades until it can no longer support communications, and the EUD quickly enables a 4G cellular wireless interface that connects Bill's EUD to a cellular service provider. The EUD then locates the Internet address of an enterprise network security gateway and initiates a VPN session with the gateway (which also acts as an AERO Server). The AERO service updates the AERO link routing system, and Bill can continue to use the same ACP that was assigned to him when he started his workday even though the EUD is now communicating over a VPN configured over the public Internet instead of over the secured campus LAN. Bill subsequently arrives at the customer meeting at a public restaurant with a WiFi hotspot. His EUD quickly powers up its WiFi interface and powers down the 4G interface. The EUD uses AERO signaling to communicate the new TFA to the AERO Server (i.e., the security gateway) and the VPN survives the mobility event. Moreover, the EUD can continue to use the same ACP it received at the beginning of the workday, and ongoing communication sessions can continue until Bill explicitly discontinues them. After the customer meeting, Bill leaves the restaurant and subsqeuntely passes through several additional transitions from WiFi hotspots to 4G wireless. Again, the AERO service keeps the VPN session alive, and the ACP assigned to the EUD remains in continuous use in active communication sessions as well as to allow Bill to receive notifications and process urgent requests. When Bill returns to his office, the EUD discontinues use of the VPN while keeping its ACP active after re-attaching to the campus LAN. Bill ends his workday, powers down his EUD and returns home. Bill powers on his EUD to check e-mails, and connects to the enterprise network via a VPN configured over his home ISP service. The EUD again receives the same ACP that it used within the enterprise network domain, and Bill can access AERO services the same as if he was in the office. Bill finally shuts down for the evening, and begins his next workday in the same fashion. Again, the EUD receives the same ACP as always regardless of the access network point of connection over which the EUD enters the enterprise. Note that the base AERO specification cannot ensure that no packet loss will occur during handovers between disparate media types, or during handovers between VPN and non-VPN connections. However, the ACP remains unchanged and can be used to reach Bill's EUD at all times during which it is connected to the enterprise network. Ongoing communications between Bill's EUD and correspondent nodes can also often (but not always) survive mobility events. While approaches exist for minimizing packet loss while a device is connected to the same campus LAN, there are currently no known methods for mitigating temporary outages when changing from a campus LAN connection to a VPN configured over the public Internet and vice-versa.

The AERO service consists of AERO Relays, AERO Servers and AERO Clients. AERO Relays include one or more routers distributed within the enterprise network that each advertise the AERO Service Prefix (ASP) into the enterprise network topologically-fixed routing system. The AERO Relays also maintain a topology-independent routing protocol instance over the AERO link that associates each AERO Client with one or more AERO Servers. The routing protocol instance is an enterprise-internal BGP instance in which each Server communicates its Client constituency to each Relay in a unidirectional fashion (i.e., Relays receive routing updates from each Server, but Servers do not receive routing updates from Relays). Since each Relay peers with each Server within the BGP routing protocol instance, there is no need for Relays to peer with each other. AERO Servers are topologically distributed throughout the enterprise network so that AERO Clients can discover one or more "topologically-close" Server. Each Server configues a DHCPv6 server and maintains one or more default routes that list an AERO Relay as the next hop on the AERO link. Each Server maintains state for each of its active Clients which were discovered through the Client's DHCPv6 prefix delegation exchanges . When the AERO Server delegates an ACP to the Client, it creates a neighbor cache entry for the Client that it maintains for up to the DHCPv6 lease lifetime. AERO Servers that service Clients connecting directly through the enterprise network campus LAN are typically distributed within the enterprise network and need not be co-resident with any (campus LAN-facing) access network routers, access points, etc. AERO Servers that service Clients entering the network via VPN connections across the Internet are also configured as enterprise border security gateways and are necessarily distributed along the (Internet-facing) enterprise perimeter. AERO Clients include both EUDs and any enterprise network service agents that are configured for access over the AERO service. When a Client connects to the enterprise network, it contacts one or more AERO Servers to receive an ACP via a DHCPv6 prefix delegation exchange. The Client then configures a default route for each Server it associates with over the AERO link, and can then access any AERO services via tunneling to the AERO Server as the first-hop gateway. If the AERO Client moves, it receives a new TFA from its enterprise network connection point and informs its Server(s) and any correspondents of the new TFA via IPv6 Neighbor Discovery (ND) exchanges. However, the Client maintains the same stable ACP regardless of any mobility events.

When an AERO Client needs to communicate with another AERO Client, the source Client has to depend on AERO Servers to acquire forwarding information for the destination Client. The source Client therefore sends a route optimization request to one of its AERO Servers. If the destination Client is also associated with the same Server, the Server forwards the request directly to the destination Client; otherwise, the Server forwards the request to an AERO Relay. Since the Relay has full topology knowledge of all Client/Server associations, the Relay therefore has enough information to forward the request to a Server associated with the destination Client. The destination Client can then send a route optimization response back to the source Client as the final leg of the route optimization procedure. When a source Client enters the enterprise via a security gateway, the gateway serves as the Client's sole point of entry to the enterprise. Direct route optimization from the source Client to a destination Client within the enterprise is therefore not possible. However, the security gateway itself can serve as a route optimization proxy for the source Client so that packets can travel from the source Client, through the security gateway, then directly to the destination Client without involving any additional AERO Relays or Servers. When a source Client that enters the enterprise via a VPN connection to a security gateway communicates with a destination Client that also enters the enterprise via a security gateway, a direct Client-to-Client route optimization could be supported if the Clients have a way to set up a private security tunnel between themselves., e.g., via a dynamic key exchange protocol. In that case, however, the (route-optimized) path between the Clients would be carried over the Internet without first passing through the enterprise network and hence not subject to enterprise network inspection. The enterprise network must therefore establish policy as to whether such external Client-to-Client route optimizations are permitted.

When an AERO Client moves from a first TFA to a second TFA, it must inform its Server(s) and any correspondent Clients of the new TFA. To do so, the Client uses DHCPv6 and IPv6 ND messaging to update its Server(s) and correspondents. As long as the Client remains associated with the same Server(s), however, there is no need for mobility events to be exposed to the Relays. When an AERO Client moves from a former set of Servers to a new set of Servers (e.g., when the Client drops its connection to the enterprise campus LAN and sets up a VPN link to an enterprise border security gateway) it must tell its old Servers "goodbye" and associate with the new Servers. This movement between Servers is then reported to the Relays via BGP updates which track all current Client/Server associations. When a Client changes rapidly from an old set of Servers to a new set of Servers, it may be seen by the BGP routing system as a "flapping" route that should be dampened. Clients should therefore remain with their associated Servers as long as possible unless and until moving to a new set of Servers would result in an appreciable performance advantage. Note that when an AERO Client moves to a new Server it need not inform its corespondents of the change unless the Client's TFA also changes. In that case, the Client uses IPv6 ND messaging to update its correspondents the same as describe above.

A typical AERO service infrastructure in large-scale deployments would include O(10) AERO Relays, O(10^2) AERO Servers, and O(10^5) AERO Clients. This would give a manageable distribution, and could be pushed to even greater scale when the numbers of Servers and number of Clients per Server are increased, with perhaps O(10^6) AERO Clients as a practical upper bound. Based on limitations of modern day enterprise-grade routers, the AERO Relays would need to maintain at least one forwarding table entry per AERO Client so that the size of the Forwarding Information Base (FIB) can be managed within the AERO router's resource limitations. The size of the AERO Relay FIB therefore becomes the limiting factor for scalability. By distributing the AERO Server function across many Servers, each Server maintains only a small subset of the overall total Client load and ensures that most mobility events are kept out of the AERO link routing system. AERO Servers further have no requirement to communicate directly with each other, so that each Server only needs to discover a small fraction of the total Client population for the AERO link.

A detailed description of the AERO DHCPv6 and IPv6 ND messaging exchanges is given in the based AERO specification .

This document introduces no IANA considerations.

Security considerations are discussed in the base AERO specification .

This work has been encouraged and supported by Boeing colleagues including Ed King, Kent Shuey, Brian Skeen, Mike Slane, Yueli Yang, and other members of the BR&T and BIT mobile networking teams.

When an enterprise mobile device moves from a campus LAN connection to a public Internet link, it must re-enter the enterprise via a security gateway. This most often entails the establishment of a Virtual Private Network (VPN) link from the mobile device to the security gateway. During this process, the mobile device acting as a Client supplies the security gateway with its public Internet topologically-fixed address as the link-layer address for the VPN (call it TFA(CLLA)). The security gateway then supplies the mobile device with a topologically-fixed enterprise network-layer address (call it TFA(CNLA)) to be used within the enterprise. The mobile device can then use TFA(CNLA) in any of its communications that need to speak with correspondents within the enterprise. However, if the VPN session is disrupted TFA(CNLA) could be lost and a new address assigned the next time the VPN is established. This prevents the mobile device from having a well-known enterprise-interior address that never changes even as the device moves. The AERO virtual link is configured over the enterprise and allows mobile devices within the campus LAN to keep the same Topology-Independent network layer address (TIA(CNLA)) as long as they remain within the campus. It would be strongly desired to also allow use of the TIA(CNLA) outside of the campus when the mobile connects via a VPN to a security gateway, however existing security gateways have no way of extending the AERO virtual link through the security gateway. In order to satisfy this need, the security gateway can be configured to also operate as an AERO Server with support for AERO Client proxying. In particular, when a mobile node that acts as an AERO Client connects via an AERO server security gateway, and the Client initiates the AERO messaging procedures specified in , the Server replaces the Client's TFA(CLLA) address with the Server's own TFA(SLLA) address in all AERO messages. The AERO messages are then delivered to other devices on the AERO link as if they were originated by the AERO Server instead of by the AERO Client. In the reverse direction, the AERO messages sourced by devices within the enterprise network can be forwarded to the AERO Server, which then replaces the Server's TFA(SLLA) address with the Client's TFA(CLLA) address. The Client can then receive its TIA(CNLA) address the same as if it were attached to the enterprise campus LAN even though it is entering from a public Internet connection. After receiving the TIA(CNLA) address, the Client can send IP packets that use TIA(CNLA) as the network layer source address and TFA(CLLA) as the link-layer source address. The security gateway (acting as an AERO Server) will then rewrite TFA(CLLA) with TFA(SLLA), and the packets will enter the enterprise network as though they were sourced from a device located within the enterprise. In the reverse direction, when a packet sourced by a node within the enterprise network uses a destination address of TIA(CNLA), the packet will be delivered to the security gateway with link-layer destination address TFA(SLLA). The security gateway then rewrites TFA(SLLA) to TFA(CLLA) and delivers the packet across the VPN to the AERO Client. In this way, the AERO virtual link is essentially extended *through* the security gateway to the point at which the VPN link and AERO link are effectively grafted together by the link-layer address rewriting performed by the security gateway. All AERO messaging services (including route optimization and mobility signaling) are therefore extended to the Client. In order to support this virtual link grafting, the security gateway (acting as an AERO Server) must keep state information about all of its associated Clients located on the public Internet. This state information (often called neighbor cache entries) is keyed by the AERO Client's AERO address, which is derived directly from TIA(CNLA). In this way, the AERO address used for AERO messaging is algorithmically mapped to the TIA(CNLA) so that neighbor cache information is statelessly mapped to IP routing information. The neighbor cache is then managed in all ways as though the Client were an ordinary AERO Client. Note that the main difference between a security gateway acting as an AERO Server and an enterprise-internal AERO Server is that the security gateway has at least one enterprise-internal physical interface and at least one public Internet physical interface. Conversely, the enterprise-internal AERO Server has only enterprise-internal physical interfaces. For this reason security gateway proxying is needed to ensure that the public Internet link-layer addressing space is kept separate from the enterprise-internal link-layer addressing space. This is afforded through a natural extension of the security association caching already performed for each VPN client by the security gateway.