Michael Walfish, Jeremy Stribling, Maxwell Krohn,

Hari Balakrishnan, Robert Morris, and Scott Shenker*

7 December 2004

MIT Computer Science and AI Lab

*UC Berkeley and ICSI

IRIS Project

Middleboxes No Longer Considered Harmful

The Problem• Middlebox: interposed entity doing more than IP forwarding (NAT, firewall, cache, …)• Not in harmony with the Internet architecture

• No unique identifiers and on-path blocking: Barrier to innovation Workarounds add complexity

10.1.1.4

NAT BHost A

New traffic class

Firewall Host D

C

Reactions to the Problem

Our goal: Architectural extension in which:• Middleboxes first-class Internet citizens• Harmful effects reduced, good effects kept• New functions arise

• Purist: can’t live with middleboxes• Pragmatist: can’t live without middleboxes• Pluralist (us): purist, pragmatist both right

DOA: Delegation-Oriented Architecture

Architectural extension to Internet. Core properties:1. Restore globally unique identifiers for hosts2. Let receivers, senders invoke (and revoke) off-path boxes: delegation primitive

NATHost A

Firewall

Host D

10.1.1.40xf12312

0xf12312

B

C

Outline

I. DOA (Delegation-Oriented Architecture)

II. Uses of DOA

III. Related Work / Conclusion

Globally Unique Identifiers for Hosts

• Location-independent, flat, big namespace

• Hash of a public key

• These are called EIDs (e.g., 0xf12abc…)

• Carried in packets

DOA hdr

IPhdr

transport hdr bodysource EID

destination EID

Delegation Primitive

Let hosts invoke, revoke off-path boxes• Receiver-invoked: sender resolves receiver’s EID to

An IP address or An EID or sequence of EIDs

• DOA header has destination stack of EIDs

• Sender-invoked: push EID onto this stack

IPhdr

transport hdr bodysource EID

destination EID stack

DOA in a Nutshell

DelegateIP: j

<eh, j>

End-hostEID: eh

IP: ih

j

DHT

LOOKUP(eh)

ProcessSourceEID: es

IP: is

• End-host replies to source by resolving es

• Authenticity, performance: discussed in the paper

DOA Packet

IPis j

transport bodyDOAes eh

DOA

transportDOAes eh

A Bit More About DOA• Incrementally deployable. Requires:

Changes to hosts and middleboxes No changes to IP routers (design requirement) Global resolution infrastructure for flat IDs

• Recall core properties: Topology-independent, globally unique identifiers Let end-hosts invoke and revoke middleboxes

• Recall goals: reduce harmful effects, permit new functions

I. DOA (Delegation-Oriented Architecture)

II. Uses of DOA

• Off-path firewall

• Reincarnated NAT

III. Related Work / Conclusion

Outline:

Off-path Firewall

eh (ih, Rules)

Network Stack

is j es [eFW eh]

ihj es eh

eh

<eh, eFW><eFW, j>

eFW

eFW

j

DHT

SourceEID: es

IP: is

Firewall

End-host

ih

j EID: eFW

EID: eh

Sign (MAC)

Verify

Off-path Firewall: Benefits• Simplification for end-users who want it

Instead of a set of rules, one rule: “Was this packet vetted by my FW provider?”

• Firewall can be anywhere, leading to: Third-party service providers Possible market for such services Providers keeping abreast of new applications

DOA enables this; doesn’t mandate it.

Reincarnated NAT

• End-to-end communication• Port fields not overloaded

Especially useful when NATs are cascaded

is 5.1.9.9 es ed

ed

5.1.9.9

NATed networkDHT

SourceEID: es

IP: is

DestinationEID: ed

is 10.1.1.3 es ed

5.1.9.9 10.1.1.1 10.1.1.3

NAT

ed 10.1.1.3

Outline:

I. DOA (Delegation-Oriented Architecture)

II. Uses of DOA

III. Related Work / Conclusion

Related Work

• Location/identity split HIP, FARA, Nimrod, and others

• Problems from private address realms IPv6 IPNL, IETF activity (STUN), and others

• Both of the above TRIAD, UIP, i3

Summary and Conclusion• DOA’s goals: architectural extension to:

Reduce middleboxes’ badness + keep goodness

• DOA’s properties: Topology-independent, globally unique host ids Let end-hosts invoke off-path boxes

• DOA lets users, admins outsource functions Competitive market in managed services Can reconcile the purist and the pragmatist

• Delegation: new property, not new philosophy

Appendix Slides

Why Does DOA Use . . .• Topology-independent identifiers?

Delegation required So EIDs need to be “resolvable” So topology-independence natural

• Flat identifiers? Hash of a public key is useful

• DHTs? Opportunism; DHTs not fundamental

Why Doesn’t DOA Use . . .1. IPv6 addresses instead of EIDs?

IPv6 addresses encode attachment point For delegation to work, EID must be resolved

2. IPv6 addresses and EIDs? It could But we think some IPv4 networks will persist So our focus here was on IPv4 networks

3. Human-friendly DNS names instead of EIDs? Hash of a public key is useful

But NATs are Supposed to Hide Identity

• True (in some cases)

• But note: EIDs topology-independent, potentially anonymous

• If you really don’t want host identities: You don’t want DOA You’re willing to deal with the negative effects of NATs

and firewalls

Can’t Off-Path Boxes Also Be Intolerant?

• Yes. But under DOA:• Intolerance no longer part of physical path

End-host/admin can revoke box End-host/admin can change boxes

• Third-party providers can specialize Which helps avoid unwarranted intolerance

• Application-specific functions can be moved out of the network

Security and Integrity• Terminology: EID resolves to e-record• Requirements:

Only EID owner can update e-record Given e-record and EID, anyone must be able to check that the EID owner created the e-record

• To achieve these properties: EID = hash(pubkey) e-record holds pubkey and signature

Security and Integrity, Cont’d

• EID source routing: does not inherit IP source routing difficulties b/c receivers don’t reverse routes to reply to senders

• Source EIDs can be spoofed But today’s source IP addresses can be spoofed Detectable under two-way communication:

Host AEID: ea

IP: ia

ServerEID: fIP: j

Host BEID: eb

IP: ib

ib j eb f

<eb, ib>

Latency• Terminology: EID resolves to e-record• DOA adds RTTs:

DNS lookup: hostname EID DHT lookup: EID e-record lookup required for receiver to reply to sender

• To deal with the extra latency: TTL-based e-record caching by senders Beehive’s [RS04] proactive, model-driven caching Cache e-record and EID in DNS Initiating host could send its e-record

Incremental Deployment• Host can see if prospective peer is DOA-enabled via DNS lookup on EID_RR• If DOA host is behind a non-DOA NAT:

The host delegates its EID to a waypoint on the global Internet The waypoint sends packets destined to the end-host over UDP or over TCP through the NAT Might require a new port namespace, as in UIP

• Applications need to be relinked or ported