1 / 29

A System for Authenticated Policy-Compliant Routing

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

claus
Download Presentation

A System for Authenticated Policy-Compliant Routing

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. 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

  4. 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

  5. The challenge How can C provide forwarding service? H3 P ISP 1 ISP 2 P H1 Forwarding relationship ISP 3 C H2 BAD OK

  6. 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

  7. Key building blocks • Routing system providing basic connectivity • Path discovery mechanisms / services • Negotiation of business relationships • Mechanism for authenticated loose source routing

  8. 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

  9. Authentication Requires asymmetry of information: H1 must know more than H3 H3 ISP 1 H1 Sniffer C Goal: Distinguish between valid and invalid packets

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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)

  17. 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

  18. 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?

  19. Measurement study Nortel R Lulea R R R KAIST R ISP R R R R R R R Coloco UCSD

  20. 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

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

  22. 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]

  23. 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

  24. 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

  25. 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

  26. 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

  27. 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

  28. Example: Virtual multihoming ISP 1 ISP 2 Using Platypus, C can virtually multihome with ISPs 1 and 3 ISP 3 Local ISP C

  29. 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

More Related