A list of frequently asked questions and short answers to questions about MobilityFirst is below. For more detailed answers, please refer to [3].
-
How in a nutshell is MobilityFirst different from the current Internet?
The MobilityFirst architecture is driven by two primary concerns: mobility and trustworthiness. A key component of the architecture that helps achieve these goals is a global name service, a logically centralized, distributed service that enhances and simplifies a number of network-layer functions.
- How exactly is the current Internet not mobility-friendly or not secure?
The short answer is IP addresses! An IP address acts both as an identifier of an interface as well the network location of that interface. This so-called identity-location conflict complicates mobility (same identity, changing network locations), mutlihoming (single identity, multiple network locations), and security. IP addresses can be be easily hijacked or spoofed. Verifying an identity is straightforward, however verifying a node's network location especially when it changes many times a day is nontrivial. All of these problems can be alleviated by a clean separation of identity and location.
- How does MobilityFirst's naming scheme enhance mobility and security?
MobilityFirst separates identity and location and relies on the global name service to quickly resolve identities to locations. MobilityFirst uses a self-certifying representation for both identity and location, i.e., the representation makes it simple to authenticate the identity or location. The self-certifying property is achieved by representing the identity and location as one-way hashes of public-keys. The name service explicitly maintains an active map of identities to network locations.
- What are the design goals underlying MobilityFirst?
- How do the design goals compare to those underlying the current Internet?
- Why is it a good idea to rely on a logically centralized name service for network-layer tasks?
- How are end-hosts identified and addressed in MobilityFirst (analogous to IP addresses in the current Internet)?
An IP address in MobilityFirst is replaced by the two-tuple [GUID, NA]. The GUID is a globally unique identifier for a principal and NA is the network domain to which it is attached. Both the GUID and NA are one-way hashes of public keys. A GUID could be assigned to a variety of principals such as an interface, a device, a human user, content, and (recursively) a collection of other GUIDs. An NA is assigned to an autonomous network but may also be used to identify smaller regions of the network (e.g., a subnet, a base station or access point) or larger regions such as an ISP or a virtual collection of NAs.
- What do self-certifying identifiers mean?
Self-certifying means that a principal X can verify that another principal Y has the identity it claims using a simple, bilateral procedure that does not require third-party certification. If the identities, X and Y in this example, are one-way hashes of public key, this property is easy to achieve. X can authenticate Yas follows. (1) X sends Y a random, one-time nonce n. (2) Y responds with [K+, K-(n)], where K+ is Y's public key and K-(n) is the nonce encrypted with the corresponding private key. (3) X verifies that Y=H(K+) and that K+(K-(n)) = n, where H(.) is a well-known one-way hash function. If both checks succeed, X has successfully authenticated Y.
Self-certifying identifiers as above do not completely obviate trusted certification authorities (CA).
A CA is still need just like today to map human-readable names, e.g., www.google.com, to a public key. Human-readable names are strictly an application concern and network-layer principals do not deal with them. Network principals in MobilityFirst rely only on self-certifying identifiers.
- How is end-to-end routing accomplished?
Packet headers contain information about the destination GUID and NA. An interdomain routing protocol routes the packet to the destination NA. Routers in networks other than the destination NA ignore the GUID. Once the packet arrives at a router in the destination NA, an intradomain routing protocol delivers the packet to the destination GUID. The interdomain routing protocol could at the simplest level be a BGP-like protocol with IP prefixes replaced by NAs. The intradomain routing protocol needs to be able to route on flat identifiers (like a switched Ethernet) as opposed to structured IP addresses.
- How do multi-homed hosts communicate?
- How is content retrieval supported?
Content is assigned a self-certifying GUID just like other principals with the difference that the GUID is the hash of the content (as opposed to an associated public key). The global name service resolves content GUIDs to network locations or NAs where a replica of the content is available. The name service typically only stores locations of the primary replicas of the content served by the content producer or its delegates (not cached copies anywhere and everywhere). However, any network intermediary can opportunistically intercept a content GUID request and return the corresponding content if it possesses a cached copy.
- How is multicast supported?
Multicast GUIDs (MGUIDs) identify a group of users subscribed to a multicast group. The creator of the group maintains a map of the MGUID to its members D_1, D_2, ..., D_k and their corresponding terminal networks in the global name service. Each member is typically subscribed to the multicast stream via a single network (even if it is otherwise multihomed). To send a packet to the MGUID, a principal queries the name service for the MGUID and obtains the union of all of the member terminal networks, say, T_1, T_2, ..., T_m, where m is at most k. The sender then individually sends packets addressed to [MGUID, T_i] to each terminal network. The terminal network internally fans out a copy of the packet to the GUIDs in its network that belong to the MGUID via another lookup to the name service.
The above scheme is rather basic and can be optimized further to reduce the number of redundant copies traversing interdomain path segments.
- How does the name service help in building new network-layer primitives that we do not know of yet?
The short answer is "indirection and grouping". The name service can map a GUID to another set of one or more GUIDs before resolving to network locations. The multicast scenario above is an example. The name service can easily support context-aware transmissions, e.g., "send a message to all yellow cabs near Times Square", by creating groups based on geolocation or other context attributes in addition to just the network location attribute.
- What do forwarding tables look like in MobilityFirst routers?
A router maintains interdomain entries of the form [NA, interface] for a subset of NAs other than the network to which it belongs. A router maintains intradomain entries of the form [GUID, interface] for a subset of GUIDs attached to its network.
- What information is carried in packet headers?
Packet headers typically contain two tuples of the form [GUID, NA], one each for the destination and source. The length of NA is variable as it may consist of either a single self-certifying identifier for a core network or one each for a core network and an edge network. NAs with path lengths greater than two are possible, it is unclear if the overhead justifies the benefit. The packet header also contains a service identifier that specifies how the destination GUID should be interpreted and how the packet should be processed by a router, e.g., a multicast GUID needs to be treated differently from an end-host interface GUID by a router in the terminal network.
The source may leave the destination NA unspecified in which case the first-hop router handling the packet is implicitly delegated the task of querying the name service for the destination GUID's network location.
- How does storage-aware routing and transport work?
Storage-ware routing and transport can store blocks at routers for longer durations than typical packet forwarding. Blocks are large units of contiguous data, or large packets, and may be several megabytes or gigabytes in size. Storage-aware routing is useful for disruption-tolerant routing, e.g., when a destination GUID becomes intermittently disconnected, a router in the terminal network to which the GUID was most recently connected may store the block until the GUID connects again to that network or a different network, and then re-route the block to the GUID's current location. Segmented transport in MobilityFirst is a block transport protocol that forwards blocks in a segment-by-segment manner. A segment is simply a sequence of contiguous network links and segmented transport is a generalization of the Hop protocol [4], a hop-by-hop alternative to TCP proposed originally for wireless networks.
- How can multiple name certification services co-exist?
Multiple certification authorities (CAs) exist even today. If there is a conflict between certificates from two different trusted CAs, then it is up to end-user to decide how to resolve the conflict. Today, these conflicts do not happen because web services return only one certificate while initiating a SSL session to a client and certificates contain sufficiently detailed information about the assignee that reputable CAs are unlikely to disagree. However, if domain name ownership is certified by multiple name certification services (NCSs), then it is possible that different NCSs bind the same human-readable name to different GUIDs. If so, it is the end-host's responsibility to decide how to resolve the conflict (e.g., by maintaining a trust order of NCSs; or using quorums of NCSs, etc.) or choose not to initiate communication. In practice, we expect that NCSs will include and display sufficient information in the returned certificates (e.g., ["apple.com", "A computer company", GUID_1] and ["apple.com", "A gourmet apple retailer", GUID_2]) to enable end-hosts to disambiguate human-readable name conflicts.
- How do multiple name resolution services coordinate?
Each name resolution service is responsible for resolving all GUIDs to their NAs for their customers. If a name resolution service is not directly responnsible for maintaining consistent resource records of a GUID, it maintains a pointer to the name resolution service that is directly responsible. Resolution is accomplished either iteratively or recursively similar in spirit to DNS today.
The authenticity of resource records returned by the name resolution service is easily verifiable as they are signed by the corresponding principals (GUIDs or NAs).
- How does the name service defend against denial-of-service attacks?
- How does the name service defend against malicious users creating an unlimited number of bogus GUIDs?
We expect insertion of GUIDs into the name service to not be "free" (just like obtaining domain names or IP address blocks is not free today). So, although a malicious user can "create" any number of GUIDs, they can not get the name service or routers to maintain state on their behalf in an unaccountable manner.
- How does the name service defend against resolution requests for bogus GUIDs from malicious users?
See the answer to the question about denial-of-service attacks above.
- Can a malicious GUID insert the tuple [GUID, NA] in the name service without consent of the NA?
No, by default, both GUID and NA must sign the tuple. However, an NA may assign a GUID the ability to insert or remove the tuple [GUID,NA] by itself for a coarse-grainedd duration, e.g., a month.
- Can a malicious host send packets to any destination [GUID, NA] even if the GUID is not present at the NA?
Yes, by default, the packet will be forwarded to the destination NA and then dropped.
- Under what circumstances does a router lookup the name service and re-route the packet? What prevents a stub network from being abused to transit traffic to provider networks?
By default, only the first-hop router at the source network looks up the name service if the destination network location is left unspecified; all other routers drop the packet if the destination network is unspecified or the destination network is the current network but the destination GUID is not currently attached to the network. The two end-hosts and the name service in conjunction are responsible for ensuring seamless mobility during the lifetime of a connection. Storage-aware re-routing is enabled only for blocks above a threshold size. Blocks requiring storage-aware routing explicitly specify it in the service identifier in the packet header. A router in a terminal network NA activates storage-aware routing for a packet destined to [GUID, NA] based on (1) local policies, e.g., if the[GUID, NA] binding has expired no earlier than a threshold duration; or (2) the GUID has moved to a different network that is a peer or customer of NA or within a threshold geographic radius; or (3) the GUID is directly or indirectly subscribed to NA's disruption-tolerant delivery service. The indirect subscription option presupposes that there exists a market where either the name service or third-party re-sellers purchase storage and routing from a large number of networks and re-sell them as a package to end-users.
- How does an end-host defend against unwanted traffic?
References
[1] MobilityFirst: A Robust and Trustworthy Mobility-Centric Architecture for the Future Internet
[2] Design of Global Name Service for a Mobility-Centric, Trustworthy Internetwork
[3] MobilityFirst overview material
[4] Block-Switched Networks: A New Paradigm for Wireless Transport, USENIX NSDI 2009.