Untangling the Web from DNS

1
Middleboxes No Longer Considered Harmful
Michael Walfish, Jeremy Stribling, Maxwell
Krohn, Hari Balakrishnan, Robert Morris, and
Scott Shenker
MIT Computer Science and AI Lab UC Berkeley and
ICSI
IRIS Project
7 December 2004
2
The Problem

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

Firewall
B
NAT
Host A
Host D
10.1.1.4
New traffic class
C

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

3
Reactions to the Problem

• Purist cant live with middleboxes
• Pragmatist cant live without middleboxes
• Pluralist (us) purist, pragmatist both right

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

4
DOA Delegation-Oriented Architecture
Firewall
B
NAT
Host A
Host D
10.1.1.4 0xf12312
0xf12312
C
Architectural extension to Internet. Core
properties 1. Restore globally unique
identifiers for hosts 2. Let receivers, senders
invoke (and revoke) off-path boxes delegation
primitive
5
Outline

1. DOA (Delegation-Oriented Architecture)
2. Uses of DOA
3. Related Work / Conclusion

6
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

body
source EID
IP hdr
transport hdr
destination EID
DOA hdr
7
Delegation Primitive
Let hosts invoke, revoke off-path boxes

• Receiver-invoked sender resolves receivers 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

body
source EID
IP hdr
transport hdr
destination EID stack
8
DOA in a Nutshell
Source EID es IP is
DHT
Delegate IP j
Process
lteh, jgt
LOOKUP(eh)
DOA
j
End-host EID eh IP ih
IP is j
transport
body
transport
DOA es eh
DOA es eh
DOA Packet

• End-host replies to source by resolving es
• Authenticity, performance discussed in the paper

9
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

10
Outline

• DOA (Delegation-Oriented Architecture)
• Uses of DOA
• Off-path firewall
• Reincarnated NAT
• Related Work / Conclusion

11
Off-path Firewall
Firewall
Source EID es IP is
eh ? (ih, Rules)
eFW
End-host
Sign (MAC)
Network Stack
eh
eFW
j
EID eFW
j
j
es
eFW eh
is
Verify
lteFW, jgt
lteh, eFWgt
DHT
es
eh
ih
j
EID eh
ih
12
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 doesnt mandate it.
13
Reincarnated NAT
es
ed
es
ed
is
is
5.1.9.9
10.1.1.3
ed ? 10.1.1.3
5.1.9.9
10.1.1.3
10.1.1.1
Source EID es IP is
5.1.9.9
Destination EID ed
ed
DHT
NAT
NATed network

• End-to-end communication
• Port fields not overloaded
• Especially useful when NATs are cascaded

14
Outline

• DOA (Delegation-Oriented Architecture)
• Uses of DOA
• Related Work / Conclusion

15
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

16
Summary and Conclusion

• DOAs goals architectural extension to
• Reduce middleboxes badness keep goodness
• DOAs 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

17
Appendix Slides
18
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

19
Why Doesnt 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

20
But NATs are Supposed to Hide Identity

• True (in some cases)
• But note EIDs topology-independent, potentially
  anonymous
• If you really dont want host identities
• You dont want DOA
• Youre willing to deal with the negative effects
  of NATs and firewalls

21
Cant 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

22
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

23
Security and Integrity, Contd

• Source EIDs can be spoofed
• But todays source IP addresses can be spoofed
• Detectable under two-way communication

Server EID f IP j
Host B EID eb IP ib
eb
j
ib
f
Host A EID ea IP ia
lteb, ibgt

• EID source routing does not inherit IP source
  routing difficulties b/c receivers dont reverse
  routes to reply to senders

24
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
• Beehives RS04 proactive, model-driven caching
• Cache e-record and EID in DNS
• Initiating host could send its e-record

25
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