1 / 12

Decoupling Policy from Mechanism in Internet Routing

Decoupling Policy from Mechanism in Internet Routing. Alex C. Snoeren and Barath Raghavan University of California, San Diego. Mechanism vs. Policy. Routing Mechanism Path discovery for end-to-end connectivity Hop-by-hop forwarding along a path Routing Policy

nona
Download Presentation

Decoupling Policy from Mechanism in Internet 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. Decoupling Policy from Mechanism in Internet Routing Alex C. Snoeren and Barath Raghavan University of California, San Diego

  2. Mechanism vs. Policy • Routing Mechanism • Path discovery for end-to-end connectivity • Hop-by-hop forwarding along a path • Routing Policy • Deciding which routes to advertise • For which destinations, to whom? • Determining which packets to forward • Over what links, at what rate, for whom?

  3. Wide-Area Routing • Control Plane • Each AS computes paths to destinations using received advertisements • Actual path selection based upon tuning parameters • Selectively exports routes to neighbors based upon business relationships • Often changes/removes/rewrites tuningparameters • Data Plane • Next hop selected according to local information • Destination addresses, current router, arrival link, etc. • Possibly filter inappropriate traffic • Drop traffic that “shouldn’t” be here

  4. Some Current Frustrations • BGP is extremely difficult to configure • Forced to use ‘assembly language’ to express mechanism and local business policy • Poor performance • Recovery from failure can take a long time • Despite the existence of workable routes • Poor flexibility • ASes can’t control routing outside of their network • Special-case modifications on human time-scales All symptoms of policy-mechanism link

  5. The Goal • Enforce all policies (only) while forwarding • We need some amount of filtering anyway • Removes complexity from control plane • Route discovery becomes policy neutral • Could need lots of information at each router • Need descriptions of all applicable policies • Information required as input to policy decision • Instead, compute policy decisions offline • Stamp each packet with a proof of compliance • Forwarding check reduces to stamp verification

  6. Network Capabilities • Verifiable attestation of policy compliance • Valid for a particular portion of the network • “Signed” by an authorized party • Designates a resource (billable) principal • Capabilities are composable & transferable • Capabilities can be exchanged between entities • To use, need to bind to a particular packet • Packets can carry more than one capability

  7. Capability Binding • Authorization agent has a secret symmetric key, k, shared with routers in the region • Define a per-capability secret, issued with c • s = MACk(c) • Compute a per-packet binding • B = MACs(p) • Routers can verify packet bindings • B’ = MACMACk(c)(p)

  8. Platypus • For now, loose source routing is an out • Capabilities to attest to policy compliance • (We don’t handle route discovery) • Allow Intra-AS traffic engineering • Each ISP engineers its own network • ISPs can decide granularity of control • Support accountability & (gasp!) billing • Capabilities identify a resource principal

  9. Efficient Overlay Construction R1 R2 R3 R4 B A R5 R6 R7 R8 C

  10. Intra-AS Router Variation 120 West Coast 110 Mid West East Coast Western Europe 100 90 80 AS3549 (GBLX)  Lulea, Sweden, delay (msec) 70 60 50 40 30 20 0 10 20 30 40 50 60 70 80 90 Anaheim, CA  AS3549 (GBLX), delay (msec)

  11. Intra-AS Router Variation 100 West Coast 90 Mid West East Coast Western Europe 80 70 60 AS3549 (GBLX)  Intel Berkeley, delay (msec) 50 40 30 20 10 0 0 10 20 30 40 50 60 70 80 90 100 UCSD  AS3549 (GBLX), delay (msec)

  12. Ongoing work • Capability Distribution • Broadcast encryption • Lightweight capability revocation • Performance • Flow-based authentication • Probabilistic verification • Accounting • Hierarchical resource principal naming • Distributed token buckets • Windowed Bloom filters?

More Related