A System for Authenticated Policy-Compliant Routing Barath Raghavan and Alex C. Snoeren UC San Diego.

A System for Authenticated Policy-

Compliant RoutingBarath Raghavan and Alex C. Snoeren

UC San Diego

Routing Today

• ISPs perform wide-area routing through BGP– Used to express local policy and traffic eng.– Problem: users can’t express routing

preferences

• Overlay routing / IP source routing– Enables edge routing control– Allows pooling of resources– Problem: may interfere with ISP policy and

traffic engineering

Our system: Platypus

• Loose source routing in which…– Users can pick their routes– ISPs control placement of indirection points

• … and authentication which enables…– ISPs to verify the policy-compliance of traffic– Is easily accountable– Delegation of source routing rights by users

An example

ISP 1 ISP 2

C ISP 3

H1

H2

20

20

5

5

10

10

Local policy avoids customer route through CDefault route

Optimal routeC could forward traffic

The challenge

How can C provide forwarding service?

ISP 1 ISP 2H1

H2ISP 3

Forwarding relationship

P

H3 P

OKBAD C

Our system: Platypus

ISP 1

C

H1

1. Negotiate contract2. Receive source routing info3. Stamp + send packets

P

Packet explicitly sent through C

Indirection point to route through

Key building blocks

• Routing system providing basic connectivity

• Path discovery mechanisms / services• Negotiation of business relationships• Mechanism for authenticated loose source

routing

Network Capabilities

• Specify a hop of the source route, including:– Point of indirection, called a waypoint– The responsible party, called the resource

principal

• Waypoints are:– Chosen by ISPs– Specified by a routable IP address

Waypoint ID

Resource Principal ID

Authentication

Sniffer

Requires asymmetry of information:H1 must know more than H3

Goal: Distinguish between valid and invalid packets

ISP 1H1

C

H3

Authentication keys

• Each waypoint has one waypoint key k

• Each resource principal has a secret key s– Derived from waypoint key using a keyed

MAC– Unique given a waypoint and a capabilityMAC

Waypoint key kCapability c

Secret s

Waypoint ID

Resource Principal ID

Waypoint ID

Packet Stamping

IP Header Waypoint ID

Resource Principal ID

Auth Info (Binding)Auth Info (Binding)

MAC

Secret sInvariant headers+ payload

Payload

Platypus Header

Capabilities

Packet Verification

Payload

IP Header

Platypus Header MAC

Waypoint key k

Capability c

MAC

Secret sHeader+payload

Binding b

=Packet binding b’

Forward

Temporal secret s

Temporal secrets

• Temporal secret keys expire periodically– Expiration allows for changing policies

• No time sync required– Secret computation includes Key ID/time– Enables expiration on order of clock drift

• Requires lookup of temporal secrets

Key lookup

• DNS-based key lookup– DNS reply contains encrypted secret– No key distribution infrastructure

required– Key lookup as fast as DNS lookup

ISP 1

C

H1

Operates key server

DNS queryDNS reply containing temporal secret

Delegation

• Users may pass out their capabilities– How might they restrict others’ use?

• Capability delegation:– Principals can restrict capabilities– Limits holder to destinations within an IP

prefix– Useful to ensure similar reverse paths

ISP 1 ISP 2

C ISP 3

H1

H2

Undesirable asymmetry

Implementation

• End-host based stamping/forwarding• User-level and kernel module

versions

500

550

600

650

700

750

800

850

900

500 600 700 800 900 1000

Outp

ut

Rate

(K

pps)

Input Rate (Kpps)

Linux native forwardingPlatypus null forwarding

Platypus UMAC forwarding

Per-packet latency

• Total per-packet time = I/O time + header processing

• I/O time ~ 2 µs• Worst-case header processing time < 2 µs

Header processing overhead68 byte 348 byte

1500 byte

Null 172 ns 173 ns 181 ns

UMAC 695 ns 998 ns 1908 ns

Deployment

• Incrementally deployable– Does not require inter-ISP cooperation– Loose source-routing based

• How might ISPs deploy Platypus?– Where should they be placed?– How many Platypus waypoints are

needed?

Measurement study

UCSD

KAIST

Nortel

Coloco

Lulea

R

R

R

RR

R

R

R

R

ISP

RR

R

Waypoint effectiveness (MCI)

0

20

40

60

80

100

120

140

160

180

2 4 8 16 32 64 128 256 512 1024

Late

ncy

(m

s)

# of waypoints

UCSD-LuleaUCSD-Lulea optUCSD-KAISTUCSD-KAIST optColoco-Lulea Coloco-Lulea optUCSD-Nortel UCSD-Nortel opt

Summary and future work

• Platypus provides:– Source routing with ISP control of waypoints– Means for authenticating source routed

packets

• Incremental deployment– Flow-based Platypus with existing hardware

• New forwarding business model– Anyone can sell/resell forwarding service– Real-time pricing of capabilities

Scalability

• Forwarding state– Waypoints only need O(1) state

• Key lookup– Lookup overhead is small (3 crypto

operations)– One key server ~ 500,000 lookups / sec

• Per-principal accounting– High speed approx. per-flow counters

[Kumar ’04]

Platypus header format

FlagsCapability List

LengthCapability List

PointerEncapsulated

Protocol

Original Source Address

Final Destination Address

Waypoint Address

Resource Principal FlagsKey ID

Binding

4 bytes

Version

Temporal secret computation

• For a capability c and waypoint key k:s = MACk(c.way||c.rp||(((t>>n) & 0xFFFFFFF0) |

c.id))

• The exception to this is at key ID wraparound– (t>>n) is either incremented or

decremented by 1Waypoint ID

Resource PrincipalKey IDFlags

Measurement results (QWEST)

0

20

40

60

80

100

120

140

160

180

2 4 8 16 32 64 128 256 512 1024

Late

ncy

(m

s)

# of clusters

UCSD-LuleaUCSD-Lulea optUCSD-KAISTUCSD-KAIST optColoco-Lulea Coloco-Lulea optUCSD-Nortel UCSD-Nortel opt

Measurement results (GBLX)

0

20

40

60

80

100

120

140

160

180

2 4 8 16 32 64 128 256 512 1024

Late

ncy

(m

s)

# of clusters

UCSD-LuleaUCSD-Lulea optUCSD-KAISTUCSD-KAIST optColoco-Lulea Coloco-Lulea optUCSD-Nortel UCSD-Nortel opt

Measurement results (SPRINT)

0

20

40

60

80

100

120

140

160

180

2 4 8 16 32 64 128 256 512 1024

Late

ncy

(m

s)

# of clusters

UCSD-LuleaUCSD-Lulea optUCSD-KAISTUCSD-KAIST optColoco-Lulea Coloco-Lulea optUCSD-Nortel UCSD-Nortel opt

Example: Virtual multihoming

ISP 1 ISP 2

ISP 3LocalISP

Using Platypus, C can virtually

multihome with ISPs 1 and 3 C

Example: Affecting Inbound Traffic

ISP 1 ISP 2

ISP 3C

Using Platypus, C can distribute

delegated capabilities that are

restricted to send to prefixes within C