The core functions of the network—case studies

David ClarkMIT

July, 2012

What a network does… Forwards packets.

All the previous discussions have related to the peripheral issues that surround the core purpose.

Forwarding implies: Some information in the packet (address or

locator). Some information in the router.

Lots of ways to manage both of these.

Our previous discussion “Forwarding” describes the most basic

version of what a router does. Earlier, I generalized this to arbitrary per-hop

behaviors (PHBs). Look at the basic case now.

When a router gets a packet, it can: Drop it. Forward it immediately. Queue it for later forwarding.

The Internet today. Information in packet: 32 bit address field.

Primarily derived from DNS lookup. Network Address Translation allows rewriting.

Information in router: forwarding table derived from routing algorithm. Routing, in the background, computes a

forwarding entry for every possible address. Perhaps 300k entries today?

It’s not that simple We recursively apply the idea of using an

address to drive forwarding. Many different kinds of addresses and router state.

MPLS: Address is a “label” in the packet, rewritten at each

hop. Router state results from setup protocol.

Ethernet: Address is a flat identifier Delivery by broadcast or spanning tree algorithm

Courtesy of Pamela Zave, AT&T

Many schemes I did a literature search to find the

documented schemes for addressing/forwarding. I am at 54 schemes and I am still finding

them. Why so many?

Remember my list of requirements. A huge design space. A dose of academic cynicism may help…

Different scopes IP is a “sort of” global address, used

across the wide area Internet. MPLS is (mostly) used to carry IP packets

internal to an ISP. IP packets are “inside” an MPLS packet.

Ethernet is used in local contexts. IP can be used recursively.

IP inside IP.

9

Addressing Old view: designed for efficient forwarding. New view: take into account

Security issues. Accountability, deterrence, availability, privacy, hiding.

Balance of control. User or network control forwarding?

Management issues. Do you really want to address physical nodes?

How about services? Information? Anycast? But consider lower-layer management issues.

Multi-homing. Mobility.

General categories Source routes: all the state in the packet.

Internet version was a failure, but popular again in academic research.

Flow setup: flow-specific state in routers. MPLS is most common example

Stateless or “datagram”: pre-computed routes. IP, Ethernet, etc.

11

Routing Old view:

Find the lowest cost route Load-based dynamics lead to instability.

New ideas: Random route selection.

Avoids DoS on link Avoids traffic engineering.

User route selection Multi-path routing. Machine learning to achieve

high-level policies

Move route computation out of forwarders.

Multiple simultaneous routing schemes.

Routing regions that do not match facilities ownership.

Four schemes from FIA eXpressive Internet Architecture (XIA) Nebula Mobility First Named Data Networking (NDN)

Previously known as Content Centric Networking or CCN.

And one scheme from EU PSIRP/Pursuit.

Another example of Information Centric Networking (ICN).

Several others, but I just don’t understand them well enough to dare explain them.

XIA High-level goals:

Trustworthy: security, broadly defined. Evolvable usage model: hosts, services,

content, ??? Supports technology evolution. Effective operation of all actors.

Even with different goals and incentives.

XIA forwarding XIA has classes of “locators”, which they call

“identifiers”, or XIDs. CID: identifier for content C

Hash of the content. SID: identifier for service S

Hash of public key of the service. HID: identifier for host H

Hash of public key of the host. NID: identifier of a network N

XIA: core novelty Routers have a distinct PHB for each kind

of ID. Put more than one kind of XID in the

packet. Put them in an ordered list (actually a DAG). Each router starts with the first one, and if it

does not have a matching PHB (or the PHB fails), “falls back” to the next one in the DAG.

They call the first one the “intent”.

Some examples CID, NID

If the router knows where the content is, send it there, otherwise route toward the network N.

CID must be known within the scope of network N. CID, SID, HID

Forward toward the content, else to a service that can find the content, else to a host where the service is located.

HID, NID: Forward to the network where the host is to be found.

Think of the NID as like an AS number in today’s Internet.

XIA: Benefits Fallback allows the incremental deployment of

new classes of PHB. Achieves goal of evolvable usage model.

Hash of public keys allows “self-certification” of communication. Did I get where I meant to get: my “clean failure”

approach. NIDs provide routing at level of AD, like internet

today. Since flat identifiers make routing hard.

Secondary specification Name services to map from user-

meaningful names to XIDs. These must be trustworthy. More than one: avoid “root of trust” problems?

XIA: Location and identity XIDs function as identifiers, but also as

locators. Use nesting of IDs to make routing efficient.

Getting an ID from the name service is an excellent idea. We could do that with a modified DNS today. But why use the ID as the locator?

What is missing? Fault isolation and user-driven re-routing.

They have a scheme called SCION to do this. Privacy of intent.

Lots of discussion about this. Routing:

They take this as solved. Vertical interfaces.

Not their priority—someone can sort this out.

Mobility First High-level goals:

Host and network mobility at scale. Exploit intrinsic properties of wireless. Secure and trustworthy operation. Support requirement of mobile apps.

Context, locality, etc.

MF: forwarding MF has classes of identifiers, like XIA.

Content, service, host, network. Called Global unique ids, or GUIDs

Routers have separate PHB for each class.

Fixed format address: GUID:NID The GUID must be routable within the

network N (e.g. two-level flat addresses).

MF: novelty Sender gets GUID from a name service.

Like XID. Global name resolution service

(GNRS)maps GUID to current NID. Receiver must keep this mapping current.

As the packet is forwarded, if network N does not know about the GUID, it can re-query the GNRS to get updated location.

MF: the challenge Build a global system that can map perhaps

100B GUIDs to NAs in 100 ms. 100B is their number—I think it is much too low, since

they claim to deal with services and content. Massively scaled “late binding”.

The recurring vision of routing on flat names. XID assumed the correct NID was in the higher-level

naming system.

MF: other features Routers at boundaries of wireless regions can

hold content if connectivity is poor. Storage-aware routing.

Support for other sorts of PHBs (caching, computation). Multicast, anycast, multi-homing.

Region-by-region transport. Tricky…

Self-certification (similar to XIA).

Digression: flat name spaces A recurring idea: can we route on flat identifiers?

Matthew Caesar, Tyson Condie, Jayanthkumar Kannan, Karthik Lakshminarayanan, and Ion Stoica. 2006. ROFL: routing on flat labels. SIGCOMM Comput. Commun. Rev. 36, 4 (August 2006)

One approach: distributed hash tables (DHTs). Mobility First is exploring this approach.

Another approach: nested addresses XIA uses this approach. How many levels? Fixed or variable?

Why do this? IP addresses have structure to make forwarding

(and route computation) simple. Seems like a good idea. But using address as identifier was bad idea.

But is a “poor man’s” security. Advantages of flat addresses.

Better support for mobility. I am not convinced.

Eliminates a lookup (round trip delay) I am not convinced.

Nebula High-level goals:

High reliability router for cloud operation. Not part of what I am going to discuss.

Fine-grain control of forwarding path By all actors. Availability (end-nodes can avoid regions). Extensibility of forwarding policy (forwarding

supports any policy). Policy enforcement.

Nebula: defining policy Each potential actor is represented by a

domain. Each domain has a behavior (PDB):

Forwarding, computation, validation, etc. A policy is a sequence of domains through

which the packet must flow, such that all the actors agree that the sequence of PDBs is acceptable. Must specify what that PDB is.

Nebula: two layer architecture Nebula data plane (NDP) forwards

packets according to a pre-set policy. Nebula Virtual And Extensible Network

Techniques (NVENT) computes policies. A global, distributed multi-agent system in

which all relevant actors can specify service offerings and service constraints, to result in an acceptable sequence of PDBs.

NVENT and Nebula data plane Before a sender can send a packet, it consults the

NVENT system. NVENT computes and returns to the sender a source

route through the domains called a “proof of consent”, (PoC).

As the packet is forwarded by the NDP, each domain computes a proof that is has performed its service, which goes into the packet as a “proof of path” (PoP).

Through the use of cunning crypto, each domain can inspect the PoP to that point and confirm that the previous steps actually happened.

Icing The data plane scheme in Nebula is

based on a scheme called Icing. Jad Naous, Michael Walfish, Antonio Nicolosi, David Mazières,

Michael Miller, and Arun Seehra, Verifying and enforcing network paths with ICING, CoNEXT 2011, Tokyo, Japan, December 2011.

Take a look if you want to see how the crypto works, and a traditional, performance-oriented discussion.

Nebula: what is tricky? What distributed algorithm can be used to

compute arbitrary policies? Are there algorithms to compute classes

of policies For example, routing protocols?

What is the overhead of computing a policy to send a packet? Is it feasible to pre-compute policies. Like routes, for example?

Named Data Network High-level goal:

Rethink the fundamental paradigm of what networks do.

Old idea: communicate among nodes. New idea: disseminate information.

Names for stuff, not endpoints. Both memory and communication explicit in

design. Security focus on the stuff, not the

connection.

Getting your head around this Spoon boy: There is no spoon.

Neo: There is no spoon? Spoon boy: Then you'll see, that it is not the spoon that bends, it is only yourself.

There are no addresses (or locators), only the identifiers of packets of stuff.

NDN: the basics Two kinds of packets: interests and data.

NDNI and NDND NDNI: contains a content name CN. NDND: contains the CN, the actual

content, and a signature. CNs are hierarchical (NOT FLAT).

/parc/videos/WidgetA.mpg /parc/videos/WidgetA.mpg/1/3

NDN forwarding (Ignore routing for the moment…) To get a data item, send a NDNI. As an NDNI arrives at a router:

Look up the NDNI to see if the content (THE NDND) is there. If so, return it.

In a local table, store the NDNI and the path it came in on.

Forward the NDNI. As an NDND arrives at a router.

See if there is a matching NDNI stored. If so, forward along the path, if not drop.

NDN: what is tricky? Making routing work—sending the NDNI in

the right direction to find the data. Profoundly tricky if there are no addresses.

Per packet state in every packet. Not per flow, per packet. Every NDNI is stored

at each step. That is why there are no addresses. The NDNI lay down a trail, the NDND follow it.

NDN: benefits Highly efficient delivery of popular content.

Cache the NDND packets along the path. Most forms of DDoS eliminated.

Cannot flood a site with unwanted NDND. Just get dropped.

Cannot demand content over and over again. Caching will diffuse the attack.

Traffic analysis degraded. No addresses, remember?

NDN routing Every NDN forwarder has a strategy

component, that tries to find an effective way to forward a NDNI. Could be driven by the name:

/parc/videos/WidgetA.mpg/1/3 But how???

Could just flood. Storage of NDNI prevents loops.

A rich topic for research.

NDN security The authoritative creator of an NDND signs it

with its private key. Public keys are widely known.

Forwarders remember popular public keys. Any node with the public key can verify:

The content is not corrupted. The name matches the content. Who owned the public key.

Same old problem: how to get the key reliably?

NDN: warning This discussion is very incomplete

There is another kind of packet, the sync. NDNI can be used to control things.

In which case, they must be signed.

Information Centric Networks ICNs are all the rage these days.

Workshops, conferences, etc. NDN gets a lot of attention, but there are

other variants. XIA is (to some extent) is ICN.

Others: PSIRP/Pursuit NetInf (part of 4ward) Dona

PSIRP/Pursuit High-level goals:

Security Mobility Scalability Evolvability Quality of Service Viable economics Multi-dimensionality

Specfics Media-independent

information access Information

governance Tussle mediation

Privacy and accountability

Information scarcity

Components Publishers, subscribers, brokers. Rendezvous point (RP) Recursive information semantics Scopes Trust-to-trust

Information ids Every information item identified by a pair:

Rendezvous ID (RId) and (nested) Scope (SId) RId is like CID in XIA, except…

RId must be unique with the scope, and scopes can be nested. IDs are flat (mostly) in the scope of meaning.

But nested, and not globally unique. Within any scope, names must resolved to a

lower-level locator (e.g. an IP address). Scopes are not necessarily topological. But they are represented by lower-level locators.

Publish To publish an item:

Pick a scope. Generate a RId unique in that scope. Determine a physical location to host the

item. “Register” the item with the scope.

E.g. send a message to the machine representing the scope, with the RId and the location(s) of the item.

Decide how to advertise the name. Not all scopes are globally known.

Subscribe Send a message that is routed through the

nested sequence of scopes until it reaches the machine in the final scope that can resolve the RId into a lower-level rendezvous location. The content can be in many places, not topologically

bounded. The source address and the item location are

handed to a topology manager that sets up a path along with the item is returned. If PSIRP is an overlay on IP, could just use normal

routing, but this is more general.

Compare to NDN Subscribe = Interest. No Publish in NDN. In PSIRP, routing of the “subscribe” is explicitly

driven by the scopes. Lower-level addresses are necessary and explicit.

In NDN, the name can implicitly guide the routing, but no explicit binding.

In PSIRP, content caching is managed. In NDN, all routers can be caches. PSIRP caches items. NDN caches packets.

Compare to XIA /MobilityFirst IDs are hash of content, so presumably

globally unique. XIA uses a form of scoping, but it is

topologically constrained (NID). Mobility First assumes the ability to map from

ID to location at global scale. NetInf also assumes this. Updating this is sort of like a PSIRP publish.

XIA uses higher-level name system as the mechanism to “publish”.

Same ideas, different words. What is the difference between PSIRP scopes

and a hierarchical naming system like DNS, but with multiple roots? PSIRP gives names to the parts (e.g. “scopes”).

Names do not have human meaning. But they could have those kinds of names as well.

XIA says naming is outside the architecture, but has to resolve names to IDs.

NDN assumes higher-level naming.

Summary thoughts All these schemes address the “locator-

identity split”. Separate what I am trying to get from where it

is. All these schemes address the idea that

most applications don’t want to get to a node, but a higher-level abstraction. But should the network or the application

control that?

Differences XIA is “easiest”. No killer challenge.

Does not completely deal with mobility Which leads to the GNRS, the killer

component of Mobility First. XIA, Mobility First presume a classic

approach to routing. Can the user route around problems?

Nebula is a very expressive scheme. Can it be used in practice?

Relate to previous material A selection of slides from the earlier

segments, to consider in light of these specific proposals.

57

Issues to consider Security—see next slide Availability and resilience—see next slide Economic viability—tomorrow Better management—mostly ignored Meet society’s needs—some attention to privacy Longevity—tomorrow Support for tomorrow’s computing—Nebula: cloud Exploit tomorrow’s networking--mobility Support tomorrow’s applications—not much explicit Fit for purpose (it works…)

58

A different modularity Attacks on the network

Routing, supply chain—no attention. A solved problem? Attacks on communication

Confidentiality and integrity addressed with encryption. All agree. Availability. All use certifying IDs. My “clean failure” approach. Traffic analysis. Only NDN has any novelty. Always tunnel.

Attacks on the host—No attention. Someone else’s job. Denial of service—NDN has insight.

A special case of availability. Information assurance.

Sign the information, not the connection. They all do this. National security—No attention. See traffic analysis.

Summary of minimalist view Agreement on the service model. Inter-region interface specifications

Routing Resource allocation

Tools to support availability Tools to support anti-availability (DDoS)

The actual semantics of IP The IP address field, at each end of the connection,

must remain constant for a given connection. But the TCP pseudo-header was a bad idea.

But see discussion of security. The IP address field can be rewritten anywhere in the

network, so long as: The rewriting complies with rule 1. There is matching routing state in the region routers.

That is the core of the Internet: the primary specification. A painful discovery.

These schemes? XIA

ID format. (PHBs are secondary.) Little discussion of service model or global routing. SCION to control routing.

MobilityFirst ID format. GNRS API. No discussion of service model or global routing.

Little user control of routing. Nebula

Complex locator format. NVENT API? Little discussion of service model. NVENT does routing, with user input.

NDN Routers must store per-packet state. Explicit service model.Must

depend on strategy module to route around failures. PSIRP

ID format. Routing by topology manager.

Generalize/formalize Generalize what a router does:

Per-hop behavior (PHB). Simple forwarding Authorization (indirection, capabilities) Encryption Overlay/tunnel (e.g. TOR) Inspection/blocking (e.g. firewall) Resource management Redirection (e.g. mobility)

Successful operation (but what does that mean?) occurs when the forwarding mechanisms have connected the intended set of PHBs in the right order.

Composing PHBs Each PHB:

Executes its internal operation Compute the correct forwarding to the next PHB.

If a PHB can compute “anything”, is this some sort of generalized processor? Perhaps, but composed out of steps that are

adversarial. Ross Anderson: “Programming Satan’s

computer”.

These schemes? XIA

Different XIDs trigger different PHBs MobilityFirst

Different classes of IDs triger different PHBs. Nebula

Arbitrary PDBs. NDN

Fixed internal function, variable forwarding. PSIRP

Topology manager might include various PHBs.

Tussle Network delivery is a adversarial game. Sender, receiver, ISPs, third parties all

have preferred outcomes. Sender and receiver may be aligned (normal)

or not (attack). ISPs may be aligned with users (normal) or

not (blocking content, etc.) Third parties (e.g. governments, rights-

holders, employers) may attempt to intervene.

How to use forwarding tools Sender picks the PHBs

Source routing, TOR, etc. The PHB (the network) picks the next PHB

Normal IP routing (explicit L2 addresses) MPLS (explicit labels)

The topology picks the next PHB Firewall (representing the interests of the receiver).

The receiver coerces the sender to pick Indirection, capabilities.

And my conclusion? If “forwarding” is all a network does,

forwarding is a complex process. Many goals, many actors.

We have a choice of incorporating this complexity inside the design, or having the design be only part of the larger outcome that addresses the complexity.

Zave again…

These schemes? XIA

Not clear how they balance interests. MobilityFirst

Not clear how they balance interests. Nebula

All actors represented in NVENT. What is revealed? Can verify the forwarding—catch cheating.

NDN Operators of routers have much power.

PSIRP Not sure what to say

Two quotes from the E2E paper“In a system that includes communications, one

usually draws a modular boundary around the communication subsystem and defines a firm interface between it and the rest of the system.”

“The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system.”

Conclusions for applications These patterns transcend specific application objectives.

They apply to broad classes of applications. Most application designers will benefit from guidance as

to how to think about and implement them. What I have been calling design patterns.

In many cases, the factor that will determine which pattern is preferred is assessment of which actors are most trustworthy. So management of trust, and by extension identity, must be a

first order capability, at least inside the application. Trust assumptions will span applications.

Relate to network How does this relate to the network and the abstraction

of its services? I discussed the performance aspects of the service. Consider the problem of finding a component.

Many of the FIA proposals include an anycast feature. Anycast to a service or a unit of information. But should the network be picking the preferred component?

Must be in an equivalence class with respect to trust, and who defines that class?

NDN takes the position that “the network” must be able to detect a forgery. How bypass a failed component using anycast addresses?

Application design The function itself:

The “purpose” of the application Performance

Classic parameters Correct operation

Perhaps in the face of attack Availability

Dealing with failures as well as attacks. Power and balance of control

Economics

These schemes In general, no discussion of application

design. Any insights are implicit. Often assume that network should resolve

service IDs (e.g. anycast). No discussion of trust or reliability. Is the network doing too much or not enough?