1 / 12

Network Support for Sharing

Network Support for Sharing. CABO: Concurrent Architectures are Better than One. No single set of protocols or functions Different applications with different needs Multiple parties offering end-to-end services Instead, multiple networks in parallel Virtual networks on a common substrate

andrew-buckner
Download Presentation

Network Support for Sharing

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. Network Support for Sharing

  2. CABO: Concurrent Architectures are Better than One • No single set of protocols or functions • Different applications with different needs • Multiple parties offering end-to-end services • Instead, multiple networks in parallel • Virtual networks on a common substrate • Customization of the network functions

  3. Separate Infrastructure from Service • Infrastructure: physical infrastructure needed to build networks • Service: “slices” of physical infrastructure from one or more providers The same entity may sometimes play these two roles.

  4. CABO as a New Architecture • Virtualization • Multiple logical routers on shared hardware • Resource isolation in CPU, FIBs, and bandwidth • Programmability • General-purpose CPUs for control & manipulation • Network processors & FPGAs for fast forwarding • Economic refactoring • Infrastructure provider: manage routers and links • Service provider: offer end-to-end services

  5. VINI/Trellis Deployment Platform • Lightweight containers on a single OS • Each virtual host sees virtual Ethernet links • Packet forwarding and traffic shaping remain outside of the container

  6. Network Support for Accountability

  7. Internet Accountability What is it? • Mechanisms to identify, isolate, punish “bad behavior” • Distinct from accounting (cf. original Clark design goals) Why might the network need to support it? • Attacks on the routing system • Control over traffic • Tracking and mitigating malice • Spam • Botnets • Phishing

  8. Facets of Internet Accountability • Source: defense against address forgery • Data-plane: identify faulty network elements • Control-plane: identify forged routing messages • Recourse to avoid faulty or malicious elements • Scalable network support for path diversity • Better mechanisms to curtail unwanted traffic

  9. AIP: Accountable IP Globally valid endpoint identifier(cf. IPv6 CGA, HIP, etc.) Hash of autonomous domain’s public key • Refactoring of Internet addresses: AD:EID • AD: The autonomous domain of the host • EID: A globally unique endpoint identifier • Addresses are self-certifying • Why change addressing? • Forms the cornerstone of routing, forwarding, identity • Current address structure makes existing mechanisms clumsy • New structure retains simplicity at the network layer and above AD EID

  10. Source Accountability • Problem: Sources can forge IP addresses • Can complete three-way handshakes (LAN spoofing) • Why it matters: Complicates filtering, blacklisting. • Spam campaigns regularly have 70% “fresh” IP addresses • Solution:Self-certification + Challenge/Response

  11. Control-Plane Accountability • Problem:Routing messages can be forged • Why it matters: • Misconfiguration: AS 7007, ConEdison route leak • Malice: Spammers stealing address space • Solution:S-BGP-style attestations + self-cert • Interdomain routing and forwarding is on Ads • The AD is the public key and the address • Eliminates the need for a mapping between IP address space and organizations

  12. Problem:Network elements drop packets, fail, and otherwise give rise to poor performance One Solution: In-Band Path Diagnosis Routers keep track of number of packets seen per flow Each router stamps each packet with current flow counter value If current counter value does not equal router’s expected packet count for that flow, router marks packet New Shim Header IP Header Data-Plane Accountability Method Overview Transport header

More Related