290 likes | 301 Views
Platypus system enables edge routing control, pooling of resources, and offers loose source routing for users while allowing ISPs to verify traffic compliance. It supports authenticated routing info and delegation of source routing rights by users.
E N D
A System for Authenticated Policy-Compliant Routing Barath 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 Local policy avoids customer route through C Default route ISP 1 ISP 2 20 10 H1 10 5 ISP 3 C 20 H2 5 Optimal route Ccould forward traffic
The challenge How can C provide forwarding service? H3 P ISP 1 ISP 2 P H1 Forwarding relationship ISP 3 C H2 BAD OK
Our system: Platypus Packet explicitly sent through C P ISP 1 H1 • Negotiate contract • Receive source routing info • Stamp + send packets 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 Requires asymmetry of information: H1 must know more than H3 H3 ISP 1 H1 Sniffer C Goal: Distinguish between valid and invalid packets
Waypoint ID Resource Principal ID 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 capability Waypoint key k Capability c MAC Secret s
Packet Stamping Capabilities IP Header Waypoint ID Waypoint ID Payload Platypus Header Resource Principal ID Auth Info (Binding) Auth Info (Binding) Secret s Invariant headers + payload MAC
Packet Verification Waypoint key k IP Header Capability c Platypus Header MAC Payload Temporal secret s Secret s Header+payload MAC Binding b Packet binding b’ = Forward
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 DNS query DNS reply containing temporal secret ISP 1 H1 Operates key server C
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 H1 Undesirable asymmetry ISP 3 C H2
Implementation • End-host based stamping/forwarding • User-level and kernel module versions 900 850 800 750 Output Rate (Kpps) 700 650 Linux native forwarding Platypus null forwarding 600 Platypus UMAC forwarding 550 500 500 600 700 800 900 1000 Input Rate (Kpps)
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 overhead
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 Nortel R Lulea R R R KAIST R ISP R R R R R R R Coloco UCSD
Waypoint effectiveness (MCI) 180 UCSD-Lulea 160 UCSD-Lulea opt UCSD-KAIST UCSD-KAIST opt 140 Coloco-Lulea Coloco-Lulea opt UCSD-Nortel 120 UCSD-Nortel opt 100 Latency (ms) 80 60 40 20 0 2 4 8 16 32 64 128 256 512 1024 # of waypoints
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 4 bytes Version Flags Capability List Length Capability List Pointer Encapsulated Protocol Original Source Address Final Destination Address Waypoint Address Resource Principal Key ID Flags Binding
Waypoint ID Resource Principal Key ID Flags 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 1
Measurement results (QWEST) 180 UCSD-Lulea 160 UCSD-Lulea opt UCSD-KAIST UCSD-KAIST opt Coloco-Lulea 140 Coloco-Lulea opt UCSD-Nortel UCSD-Nortel opt 120 100 Latency (ms) 80 60 40 20 0 2 4 8 16 32 64 128 256 512 1024 # of clusters
Measurement results (GBLX) 180 UCSD-Lulea 160 UCSD-Lulea opt UCSD-KAIST UCSD-KAIST opt Coloco-Lulea 140 Coloco-Lulea opt UCSD-Nortel UCSD-Nortel opt 120 100 Latency (ms) 80 60 40 20 0 2 4 8 16 32 64 128 256 512 1024 # of clusters
Measurement results (SPRINT) 180 UCSD-Lulea 160 UCSD-Lulea opt UCSD-KAIST UCSD-KAIST opt Coloco-Lulea 140 Coloco-Lulea opt UCSD-Nortel UCSD-Nortel opt 120 100 Latency (ms) 80 60 40 20 0 2 4 8 16 32 64 128 256 512 1024 # of clusters
Example: Virtual multihoming ISP 1 ISP 2 Using Platypus, C can virtually multihome with ISPs 1 and 3 ISP 3 Local ISP C
Example: Affecting Inbound Traffic ISP 1 ISP 2 Using Platypus, C can distribute delegated capabilities that are restricted to send to prefixes within C ISP 3 C