Can the End-to-End Principle Survive? - AUUG 2003, Sydney
- Phil Karn
- karn@qualcomm.com
Disclaimer - This talk includes my personal opinions.
- I am not speaking for Qualcomm.
- Qualcomm may or may not agree with me.
- (But they should.)
Intro This talk is adapted and extended from my Mobicom '99 talk - IPv6 and IPsec more widely deployed
- worms, viruses, spam much worse
The End-to-End (E2E) Principle Seminal 1981 Saltzer, Reed & Clark paper: End-to-End Arguments in System Design - IMHO, the most important network paper ever written
Many functions in a computer system are best done on an end-to-end basis A function can sometimes be justified at a lower layer as a performance enhancement - e.g., link level acks on a radio channel
Some Natural E2E Functions Reliability - end-to-end check still required even if subnet provides per-hop acks
Security Mobility - more flexible and efficient at application layer
Origins of the E2E Principle In the mid 1970s, the microprocessor created diseconomies of scale in computing that would clearly only grow - distributed became a buzzword
The telephone system: unduly monolithic, complex, inflexible and expensive - precisely because it did too much; telcos still haven't learned from AIN fiasco
- VoIP will be sweet revenge...someday...
E2E and the Internet The Internet architecture was originally conceived, designed, built, operated, tested and actually used by the same people, who were sponsored by other prospective end-users (the DoD) - "Every good work of software starts by scratching a developer's personal itch" (Eric S. Raymond)
Bogus Arguments Against E2E "How will we bill for our service?" - e.g., in VoIP; persistent "free Internet" myth
"No real person will ever want/need to ---- - run a server
- have a home LAN
- use the Internet
- own a computer
- (your excuse here)
Some Real Threats to E2E IP address space exhaustion - more specifically, kludges like NAT
Pervasive host security problems - thanks, Microsoft!
- firewalls: packet filters, proxies, gateways, spam & virus filters, etc
More Threats - "ack-spoofing" gateways (e.g., TCP over sat)
- "lightweight" protocols
- e.g., WAP, Unwired Planet (R.I.P)
New layers on existing E2E mechanisms - no true E2E check in relayed email; TCP becomes by-hop between relays
A More Ominous Threat to E2E Carriers creeping up the stack - controlling address and name spaces
- Cable modem, DSL providers charging for extra or static IP addresses "because they can"
- restricting/modifying content
- Port blocking
- inserting ads, censoring content, transparent proxies
Raw pipes aren't glamorous enough US regulation of wire owners has failed
Even More Ominous Threats Legal persecution of P2P networks - The Internet was designed to be "P2P"!
Spam, worms, viruses, DoS attacks - endemic and rapidly getting worse
Used to justify all sorts of anti-E2E violence: - outbound port 25 blocking
- MAPS DUL blocking
- AUP server prohibitions
- mandatory spam/virus filters
The Real Issue
Defending E2E Tunneling (e.g., IPv6 6to4 and IPsec) - Encryption nicely thwarts content restrictions
QoS support - cleaner way to differentiate service offerings
- a rare low-level feature that should exist, but doesn't
Open source software - powerful way to meet users' (vs vendors') needs
IPv6 - will become very popular when implemented in consumer routers
Hosts will be dual stack (many already are) - Non-global IPv4 address behind NAT
- common current practice
- fine for existing web & email clients
- Global IPv6 address in 6to4 block
- ideal for new P2P applications, e.g., VoIP
Will IPv6 succeed? Who will "own" the v6 address space? - Many complaints already about cost & difficulty of getting v6 address space
- implicit /48 assignment big advantage of 6to4
Requires host, app and router upgrades - already in most host OSes
- older applications don't have to have it
- not yet in consumer-grade gateways
Will worsen host security problems
Security Threats Many distinct security problems, e.g., - Spam
- Worms/viruses
- DoS attacks
- User eyeballs
- Host resources
- Network resources
IMHO, Biggest single threat to E2E
Preserving E2E Against Security Threats Security Placement Principle: Place security mechanisms as close as possible to the resources being protected Ergo, - must distinguish between host and network attacks
- host attacks best prevented by host mechanisms
- with net mechanisms as performance enhancement
- net attacks only prevented by net mechanisms
Security Philosophy Humans are more valuable than machines End users must retain ultimate control - any filtering functions performed by ISPs as performance enhancement must be under end-user control
Our #1 Security Problem: Microsoft! Two kinds of worms & viruses endemic: - trojans (e.g., SoBig.F)
- bug exploiters (e.g., Slammer, Blaster)
Primary damage to infected hosts, but ubiquity clogs network Despite many promises, problem worsening rapidly
Fun & Games with SoBig.F
Example: DoS in Cellular Networks We'd like to give every phone a global IPv6 address and make it a server (VoIP, text etc) - any host anywhere can send it packets
Wireless is inherently slower than wired Denial-of-service attacks would be too easy - already pandemic in the wired Internet
- excess capacity keeps them from being more destructive than they already are
Filters in the phone won't work - the damage is to the wireless link, not the phone
I.e., filters have to be in the network This problem isn't unique to wireless hosts - they are simply the most vulnerable
- we need a general solution for all hosts if IPv6 is to restore the end-to-end model
Blocking Spam Special class of denial-of-service attack - attacked resource is user's eyes, not his link
- already a serious problem with SMS in some areas
Best solution so far: content-based filtering, e.g., Bayesian analysis, performed upstream under user control
Conclusions - but Microsoft is highly problematic
Will still need filtering to protect the net Challenge is to preserve the E2E model Needed: standard filtering mechanisms under end-user control
References Saltzer, Reed, Clark: End to End Arguments in System Design - http://people.qualcomm.com/karn/library.html
Raymond, The Cathedral and the Bazaar - http://www.tuxedo.org/~esr/writings/cathedral-bazaar/
Karn, Why I Hate Microsoft: Part 1, Worms and Viruses
Dostları ilə paylaş: |