1 / 12

Forensics and Attribution in Ethane

Forensics and Attribution in Ethane. Martin Casado Stanford University With: Michael Freedman, Justin Pettit, Jianying Luo, Natasha Gude, David Goubad, Aditya Akella, Dan Boneh, Scott Shenker, Nick McKeown. Ethane Overview. Centralized, Flow-based architecture

rendor
Download Presentation

Forensics and Attribution in Ethane

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. Forensics and Attributionin Ethane Martin Casado Stanford University With: Michael Freedman, Justin Pettit, Jianying Luo, Natasha Gude, David Goubad, Aditya Akella, Dan Boneh, Scott Shenker, Nick McKeown NSF Find

  2. Ethane Overview • Centralized, Flow-based architecture • Connectivity dictated by global policy file • For the Enterprise • Single administration domain (someone everyone has to trust) • Known principle roles (users, hosts) • Bounded in size NSF Find

  3. Credentials Payroll XXXX Nancy YYYY • Assumptions • Physical ingress port ofall packets is known • Controller knows networktopology Bindings Payroll→ x → m → sw4 Nancy → y → n → sw4 Ethane Operation Authenticate controller Payroll Host: a IP: x MAC: m Authenticate Nancy Host:b IP:y MAC:n NSF Find

  4. Ethane:First Packet = Path Setup POLICY FILE Controller Payroll Nancy NSF Find

  5. Ethane Switch = Flow Tables • FlowID = Hash over relevant header fields • Ethernet = H(inport,ethsrc|ethdst|ethprot) • IP = H(eth,ipsrc|ipdst|ipproto) • TCP/UDP = H(ip|srcport|dstport) • Flow-Table & Lookup FlowID Header Values Action 0xcf32 Fwd port1 01|ffee|… 0xdf32 01|ddee|… Fwd port1, Swap MAC 0xef32 02|ddef|… Fwd port2, Rate limit NSF Find

  6. Preventing Address Forging • Principles bound to addresses/physical port at authentication time • Packet addresses checked against bindings at Controller • (e.g. MAC/port pair matches known bindings) • Flow definition includes ingress port • Forged packets will never match a flow and will be dropped at first hop switch NSF Find

  7. Forensic Support User Login User → host Host → IP IP → MAC MAC → switch port Switch port → switch port Replay Log Host Join Switch Join Link Change Controller Bindings • All bindings logged • Current bindings + packet + timestamp + log = bindings at time packet was sent NSF Find

  8. Forensics • Given a packet can determine • Which user/host sent and received it • Physical port it was sent/received from • What the topology looked like when it was sent • Access control bind state and log(only admin access) NSF Find

  9. Anonymity • IP addresses allocated dynamically • Source MAC can be swapped by switches(use IP during forensics) • End-hosts perform encryption NSF Find

  10. Source Address? • Doesn’t matter • “Addresses” are virtual and multiplexed among physical ports • Address allocations are enforced by network • Address + bind log = source NSF Find

  11. Mechanism Issues • Requires bind state and log • Function assumes global trust • Minor compared to flow state • Encryption off datapath = good • Simple switches at Gig speeds NSF Find

  12. Questions? NSF Find

More Related