1 / 57

Virtual Internet Research at the Postel Center

Virtual Internet Research at the Postel Center. Joe Touch Postel Center Computer Networks Division USC/ISI. Outline:. VIs: definition & architecture Using VIs : X-Bone – deploying VIs DynaBone – multilayer VIs for fault tolerance, security, and performance Supporting VIs :

judah
Télécharger la présentation

Virtual Internet Research at the Postel Center

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. Virtual Internet Research at the Postel Center Joe Touch Postel Center Computer Networks Division USC/ISI

  2. Outline: • VIs: definition & architecture • Using VIs: • X-Bone – deploying VIs • DynaBone – multilayer VIs for fault tolerance, security, and performance • Supporting VIs: • NetFS – OS support for VIs • DataRouter – app.-directed net-layer forwarding

  3. VI Definition • VI is a network composed of: • Virt. hosts, virt. routers, virt. links (tunnels) • Provides at least the same services as IA • In a virtual context • First-principles extension • More than a patch • More than interim

  4. Motivation • Unified, consistent virtual architecture • VPNs, overlay nets, peer nets • Incremental deployment of new services • Ongoing experiments • Topology-based services • DHTs, geographic forwarding [GeoNet], string-rewriter forwarding [DataRouter] • Layer-based services • Contained dynamic routing, fault tolerance (FEC), security (traffic hiding), multi-algorithm [DynaBone], Plutarch’s subnet composition

  5. Extra Constraints • Internet-like • Routing (link up) vs. provisioning (link add) • …one header to bind them all… (use IP, provide IP  recursion) • Complete E2E system • All VNs are E2E • VN “Turing Test” • A net can’t tell it’s virtual • Use existing protocols, OSs, apps.

  6. Principles • TENET 1. Internet-like • VIs = VRs + VHs + tunnels • Emulating the Internet • TENET 2. All-Virtual • Decoupled from their base network • TENET 3. Recursion-as-router • Some of VRs are VI networks

  7. Recursion-as-Router • Hierarchy w/connected sub-overlays • Sub-overlays look like routers Primary overlay Sub-2 Sub-1 Base network

  8. Corollaries • Behavior: • VH adds/deletes headers • VRs transit (constant # headers) • Structure: • VIs support concurrence • VIs support revisitation • Each VI has own names, addresses • Address indicates overlay context

  9. Detailed Architecture • Components: • VH  hidden router • VL  2 layers (strong link, weak net) • VR  partitioned forwarding • Capabilities: • Revisitation multihoming • Recursion  router as network, BARP RUNNING CODE (FreeBSD, Linux, Cisco)

  10. Network Control / deployment Architecture Use:New Concepts • Recursion, revisitation • BARP • Service to deploy & manage VIs • Language for describing VIs

  11. Primary overlay Outerlay Sub-2 Sub-1 Sub-1 Sub-2 Base network Sub-3 Base network More Concepts:Service composition • Compose: • X-Bone, DTN, Plutarch • Alternate: • DynaBone,Control Plane,FEC, Boosters

  12. More Architecture Uses:Correct/explain anomalies • Multihoming • Phantom router in all hosts • Input context for forwarding/binding • Revisitation • Two-level tunnels • Input context sets • IPsec tunnel mode & dynamic routing

  13. Typical Q’s • Why not VPNs/Peer, etc.? • Most net-level are incremental, partial, etc. • App. Level recapitulates network & won’t compose • Isn’t this more complex? • AS-like management encapsulation (multi-level) • Can make application view simpler (per-app. networks) • Isn’t this suboptimal/non-diverse? • So is VM; like VM, OOB info. & direct measurements can help • Layering implies increasing coarseness • Wasn’t this done in (X) before? • VIA is uniform, consistent, & implemented • What’s so hard? • See “uses” & “anomalies”

  14. 1/N performance Performance Impact

  15. Prior & Related Work • Service/new protocols • Cronus, M/6/Q/A-Bone • Multi/other layer • Cronus, Supranet, MorphNet, VANs • Partial • VPN, VNS, RON, Detour, PPVPN, SOS • Virtualization, Revistation, Recursion • X-Bone, Spawning, DynaBone, NetFS, Netlab

  16. VI analogy to VM • Protection • For concurrency, separation • Simpler configuration • Run over simpler topologies • Decouple from physical • Emulate larger/different nets • Automation • Generic, external mechanism

  17. X X Y Y to Y to Y   Strong Weak Why 2 layers? • Network • E2E IDs, routing • Link • ICMP, ARP, forwarding • Reasons: • Revisitation • Separate link-layer IPsec keys • Allows separate interfaces – thus dynamic routing • Issues • Overlap for efficiency • Strong vs. weak

  18. Web GUI Multiple views IP Base Star Overlay B A D C ring-ovl star-ovl B B A A Ring Overlay D D C C xd GUI Resource Daemon Overlay Manager Resource Daemon Base IPv4 Network Resource Daemon Automated monitoring link host router X-Bone X-Bone system

  19. The X-Bone is… • A system for automated overlay deployment • Among a closed set of trusted hosts and routers • Pprovide coordination, configuration, management • Many details are plug-replaceable • New tricks for overlays (use of overlays) • Overlays on overlays on overlays on … • Fault tolerance, service deployment • Member in multiple overlays, in single multiple times • New tricks for old dogs (extend net arch.) • Use existing stacks and applications

  20. What We Don’t Do… • Optimize the overlay topology • We use a plug-in module (AI folk can provide) • It requires network status (emerging now) • Fault tolerance only via ground truth (admin. issue) • X-Bone is capability more than performance (now) • Non-IP overlays • IP is the interoperability layer • IP recurses / stacks nicely

  21. Result sin eql cos div udel sec isipc2 bbn Creating a Ring Ovl. Request OM Ring Ovl. Internet

  22. Potential Uses • Test new protocols • Test denial-of-service solutions • Deploy new services incrementally • Dynamic routing, proxylets, security • Increase lab & testbed utility • Overlapping nets, add delay & loss • Scale to 10,000 nodes • Simplify view of topology • Support fault tolerance • Added level of recovery

  23. Features • Secure • X.509 certs, SSL control, ACLs • Resilient • Heartbeats with auto-dismantle • Crash recovery/restore • Detects/avoids replays; idempotent actions w/rollback • Overlay features • Dummynet, IPsec • Application deployment • ABone • Squid proxy system (U. Catalonia) • PlanetLab-like slice of vservers

  24. Recent Additions • In 3.0 (1/2004): • IPv6 • Dynamic DNS/DNSsec • Cisco via buddy host • Zebra dynamic routing • User-specified topology • XML-based API • Coming soon • Revisitation (using network stacks) • Recursion

  25. Architecture issues • Core (PP) VPNs need stub assistance • All transport is E2E • Inject routes via BGP/RIP or redirect default • Often assumes one VPN • Boundary control • Typical VPN • O(N) tunnels & routes / O(N) firewall rules • Separate routing and firewalls • O(1) routes / O(N) firewall rules • Firewall via groups • O(1) routes / O(1) firewall rules

  26. Relation to: • NetLab (net EmuLab) • Focuses on L2-VPNs • Incorporating X-Bone concepts • Revisitation, IPsec tun over IPIP/GRE • PlanetLab • Focuses on OS • Primitive networking • Reinventing net. configuration mech.

  27. Availability (and not)… • http://www.isi.edu/xbone • Platforms • FreeBSD 4.x/5.x (IPv4/6 IPsec) • Linux RedHat (IPv4/IPsec only) • Cisco via buddy host (IPv4 IPsec, IPv6) • Under development/test: • NetBSD (tested only) • MacOS X (prelim. testing) • Platforms not capable of VIs: • Windows 2K/XP • Linux FreeS/WAN • Vxworks, Janos • PlanetLab inside vserver

  28. Innerlays Outerlay P R M P R M X MD5 auth / static DynaBone Spread-Spectrum Multilayer Internet Overlays 3DES encrypt / Linkstate RC5 encrypt / RIP MD5 auth / static Base network

  29. Goals • Auto platform for spread-spectrum • Architecture in which to use … (see BASF) • Closed-group communication • E2E, E2(gateway), etc. • Enable multilayer defense (IP addr, SPI, decrypts) • Platform for muggles • Transparent to applications, protocols, OS’s • Auto-deploy

  30. Sub-1 Sub-2 Sub-3 DynaBone via X-Bones • Parallel innerlays • Coordinate use via PRMs Outerlay Base network

  31. Layered Overlays • Innerlays • A network you can gracefully disconnect • Attacker-like parallelsim as a defense • Outerlay • Hides the Innerlays from OS, applications • Allows transparent restoration • Automated deployment via X-Bone • User deployed, trans-AS, no new protocols • Integrates heterogeneous net-level security

  32. DDOS Attack Detection Performance Metrics (pathchar) PRM Detail Mux per packet? per TCP? P R M Monitor inject measure M Demux reorder? drop dups?

  33. Monitor & Control GUI

  34. NetGraph PRM Module /data [format] /policy(?value) /stop?innerlay /go?innerlay

  35. PRM Performance

  36. 255.255.0.0 255.0.0.0 10.3.0.0 NetFS File System /netfs iface route proto ipfw ipsec default 10.0.0.1 tcp udp lo fxp0 ether ip 0 1 25 26 addr mask default alias1 alias2 mask addr

  37. Goals • Simple, standard interface • Across different OS’s • File system API and semantics • Fine-grained security • User, group, world, etc. • Per instance of each resource • Context-dependent views • Limits “ifconfig –a” response

  38. NetFS File API Socket API sockopt ioctl sysctl In-band API Intertwined Vontrol interfaces routes communication channels

  39. Process A Process B ~netfs ~netfs iface route iface route /netfs iface route X Y Z A B Per-process Context

  40. Related Work • Linux’s /procfs • Processes • Jail(fbsd) & vserver(linux) • Limits root access to 1 IP addr per partition • Plan 9’s /net • Sockets • FreeBSD extensions (underway) • Add naming (kernel hack) to interfaces

  41. s/(bird)(.*)(isi.edu)/(D2)($2)(usc.edu)/ D1 D2 DataRouter S D1 P #55fea3 isi.edu bird D1 S D2 P D1 #55fea3 usc.edu

  42. Motivation • Application-level networks are ‘bad’ • Recapitulate the network layer • Require additional E2E transport protocols • Hard to compose • Network-level overlays not enough • Application-level info. is hidden • IP forwarding is not sufficient

  43. Goal = peer/DHT support: • Useful: • Supports application-directed forwarding • Enables composition/integration of app. svcs. • Clean: • Avoids reinventing the network layer • Avoids reinventing the transport layer • Appropriate: • Forwards fast • Supports IPsec • Is somewhat safe

  44. DataRouter IS: • Header = IP Loose Source Route • Network layer option • Works as an encapsulation header (ala IPsec) • Entry = string • Explicit application context • Forwarding via string rewriting • String (IP address, string’) pair

  45. DataRouter ISN’T: • Routing protocol • IP doesn’t force OSPF, BGP, etc. • Overlay configuration • IP doesn’t force particular topology

  46. Enabled Capabilities • App. forwarding via network svc. • Late-binding integration • One packet: TCP/SYN w/ Google as DR • Google  DNS  IP • Anycast services • First DR hop = anycast server • Further hops added by appending

  47. Quick FAQ: • This is forwarding; who does routing? • Application that would have done forwarding (Chord, CAN, Napster, Google, DNS) • Can transport handle unbound dests? • Use HIP to decouple TCP/UDP from IP • What is the API? • DR strings via SOCKOPT • Forwarding entries via droute command • Why use REs? • Sufficient, efficient, complete • How does it avoid breaking E2E? • By allowing E2E TCP • Why use a LSR IP option? • Integrates w/existing ICMP, IPsec; allows ‘overlays’; transparent

  48. Example Uses • All in a parsed string: • Class:string  metric:string • Escape “:” • Select largest metric

  49. Related Work • Application-directed forwarding • DHTs, web proxies… • Google, DNS • Alternate network forwarding • Dbase index [Carzaniga03] • Linda [Carriero86] • Data manipilation lang. [Chandranmenon95] • Catanet, TRIAD, I3, IPNL, Heaps, Net Ptrs… Electronic control

  50. Performance

More Related