1 / 8

Architectural Considerations for Protecting End Hosts

Architectural Considerations for Protecting End Hosts. Vern Paxson International Computer Science Institute and Lawrence Berkeley National Laboratory vern@icir.org June 28, 2007. Overview. Previous session looked at architectural issues for the network securing its own infrastructure

kumiko
Download Presentation

Architectural Considerations for Protecting End Hosts

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. Architectural Considerations for Protecting End Hosts Vern Paxson International Computer Science Institute and Lawrence Berkeley National Laboratory vern@icir.org June 28, 2007

  2. Overview • Previous session looked at architectural issues for the network securing its own infrastructure • Now, we consider the network’s role (if any) in protecting end systems • Two parts: • What should its role be? • Architectural approaches for DoS defense

  3. Agenda, Part 1 • What should the network’s role be? • It’s inevitable that the network will be intrusive with end system traffic, let’s architect for it (Vern Paxson) • No let’s not, #1 (Paul Syverson) • No let’s not, #2 (Nick Weaver) • Discussion

  4. Agenda, Part 2 • How should the network protect against DoS? • Framing of problem space (Stefan Savage) • The role of identifiers (Stefan Savage) • The role of indirection (Angelos Keromytis) • The role of capabilities (Xiaowei Yang) • Discussion

  5. A Glum Vision ThatWe Had Better Plan For • Network operators want to control traffic • Control = inspect, modify, tune, censor, confine • … for a large variety of reasons: • Policy enforcement • Endhost security • Wiretap / legal intercept • Censorship • Walled gardens / business reasons • Performance engineering

  6. Glum Vision, con’t • Furthermore, they have the power to do so since they hold the fundamental property of connectivity … • … unless they are constrained: • By law • Unpredictably difficult to shape in a useful fashion • By competitive concerns • But these are trumped by law and sole-sourcing

  7. Glum Vision, con’t • We have existence proofs that network operators will go to significant lengths to shoehorn in such control • Question: would we like this stuff shoehorned into our future Internet, or directly recognized as a tussle? • (Q: will end-to-end crypto save us? A: No, reduces to steganography.)

  8. How to Architect for this Tussle? • One approach (w/ S. Shenker, M. Allman): • When instantiating communication, end nodes negotiate with network regarding degree of inspection/meddling • What will be revealed, what can be modified • How to express range of semantics? • If unacceptable, seek alternate paths • Both parties require mechanisms to police for adherence • Already today for SIP proxies, P3P

More Related