Internet DRAFT - draft-templin-aeroent
draft-templin-aeroent
Network Working Group F. Templin, Ed.
Internet-Draft Boeing Research & Technology
Intended status: Informational September 02, 2014
Expires: March 6, 2015
AERO Enterprise Network Profile
draft-templin-aeroent-00.txt
Abstract
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.
Status of This Memo
This Internet-Draft is submitted 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 March 6, 2015.
Copyright Notice
Copyright (c) 2014 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
Templin Expires March 6, 2015 [Page 1]
Internet-Draft AERO Enterprise September 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. A Day in the Life of an AERO Eud User . . . . . . . . . . . . 4
4. AERO Network Organizational Principles . . . . . . . . . . . 6
5. AERO Route Optimization . . . . . . . . . . . . . . . . . . . 7
6. AERO Mobility Management . . . . . . . . . . . . . . . . . . 8
7. AERO Service Distribution . . . . . . . . . . . . . . . . . . 8
8. Further Details . . . . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 10
Appendix A. Extending AERO Links Through Security Gateways . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
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)
[RFC0791][RFC2460] 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)
[I-D.templin-aerolink], however, mobile devices can receive a
Templin Expires March 6, 2015 [Page 2]
Internet-Draft AERO Enterprise September 2014
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.
2. Terminology
The terminology in the normative references applies; the following
terms are defined within the scope of this document:
Topologically-Fixed Address (TFA)
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.)
Topology-Independent Address/Prefix (TIA)
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.
Asymmetrict Extended Route Optimization (AERO)
a service for provisioning TIAs while accounting for device
mobility and without exposing mobility events to the core
enterprise network routing service.
End User Device (EUD)
an enterprise mobile device (e.g., laptop computer, tablet, smart
phone, etc) that acts as an AERO Client.
AERO Client ("Client")
a node that receives a TIA within the scope of the enterprise
network that it can use continuously wherever it roams.
AERO Server ("Server")
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.
AERO Relay ("Relay")
Templin Expires March 6, 2015 [Page 3]
Internet-Draft AERO Enterprise September 2014
a node that keeps track of all Client/Server associations and also
serves as a gateway between the TIA and TFA address spaces.
AERO Link
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.
AERO Service Prefix (ASP)
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.
AERO Client Prefix (ACP)
a more-specific TIA prefix taken from an ASP and delegated to a
Client.
3. A Day in the Life of an AERO Eud User
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
Templin Expires March 6, 2015 [Page 4]
Internet-Draft AERO Enterprise September 2014
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
Templin Expires March 6, 2015 [Page 5]
Internet-Draft AERO Enterprise September 2014
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.
4. AERO Network Organizational Principles
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 [RFC3315][RFC3633]. 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
Templin Expires March 6, 2015 [Page 6]
Internet-Draft AERO Enterprise September 2014
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)
[RFC4861] exchanges. However, the Client maintains the same stable
ACP regardless of any mobility events.
5. AERO Route Optimization
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
Templin Expires March 6, 2015 [Page 7]
Internet-Draft AERO Enterprise September 2014
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.
6. AERO Mobility Management
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.
7. AERO Service Distribution
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.
Templin Expires March 6, 2015 [Page 8]
Internet-Draft AERO Enterprise September 2014
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.
8. Further Details
A detailed description of the AERO DHCPv6 and IPv6 ND messaging
exchanges is given in the based AERO specification
[I-D.templin-aerolink].
9. IANA Considerations
This document introduces no IANA considerations.
10. Security Considerations
Security considerations are discussed in the base AERO specification
[I-D.templin-aerolink].
11. Acknowledgements
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.
12. References
12.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
Templin Expires March 6, 2015 [Page 9]
Internet-Draft AERO Enterprise September 2014
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
12.2. Informative References
[I-D.templin-aerolink]
Templin, F., "Transmission of IP Packets over AERO Links",
draft-templin-aerolink-32 (work in progress), August 2014.
Appendix A. Extending AERO Links Through Security Gateways
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
[I-D.templin-aerolink], 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
Templin Expires March 6, 2015 [Page 10]
Internet-Draft AERO Enterprise September 2014
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.
Templin Expires March 6, 2015 [Page 11]
Internet-Draft AERO Enterprise September 2014
Author's Address
Fred L. Templin (editor)
Boeing Research & Technology
P.O. Box 3707
Seattle, WA 98124
USA
Email: fltemplin@acm.org
Templin Expires March 6, 2015 [Page 12]
