qos and security - using traditional services for new ends · qos and security - using traditional...
TRANSCRIPT
Feb. 4, 2005 QoSIP - Catania 1
QoS and security QoS and security -- using traditional using traditional services for new endsservices for new ends
Henning SchulzrinneDept. of Computer Science
Columbia University
Feb. 4, 2005 QoSIP - Catania 2
OverviewOverview
Some impolite remarks about network research and QoSQoS challenges in real networks:
NATs and firewallsDOSreliability
Permission-based networkingGIMPS: next steps in signaling
Feb. 4, 2005 QoSIP - Catania 3
Impolite remarks on QoS Impolite remarks on QoS and network researchand network research
Feb. 4, 2005 QoSIP - Catania 4
Lifecycle of technologiesLifecycle of technologies
military corporate consumer
traditional technology propagation:
opex/capexdoesn’t matter;expert support
capex/opexsensitive,
but amortized;
expert support
capexsensitive;amateur
Can it be done? Can I afford it? Can my mother use it?
Feb. 4, 2005 QoSIP - Catania 5
Networking research is fashionNetworking research is fashion--drivendriven
networking coursesFirst (European) workshop
on X --YAP on X
workshopwhite paper
DARPA, NSF$$
secondaryconferences
EUNth framework
SigcommInfocomMobicom
ICNP
ATMDQDBQoS
mobile networkswirelessad-hoc, sensor
active networks
trailing-edgeresearch
Feb. 4, 2005 QoSIP - Catania 6
Impact of network researchImpact of network researchWhat’s promising/interesting – two different axes:
Intellectual merit interesting analysis, broadly applicable, …Satisfies practical needs may not be a scientific breakthrough
Field has few grand challenges and metrics
cf., speech understanding or face recognition
Depends largely on external technology inputs
faster CPUs, better optical gear, compressiontypical performance improvements in queueing: 20-50%
Networking research impacton deployed systems and protocols?on understanding network behavior?on other papers?
Which of the 10,000 QoS papers had real impact?What papers were responsible for most important networking advances?
TCP , web?, email?
Feb. 4, 2005 QoSIP - Catania 7
Maturing network researchMaturing network researchOld questions:
Can we make X work over packet networks?All major dedicated network applications (flight reservations, embedded systems, radio, TV, telephone, fax, messaging, …) are now available on IP
Can we get M/G/T bits to the end user?Raw bits everywhere: “any media, anytime, anywhere”
New questions:Dependency on communications Can we make the network reliable?Can non-technical users use networks without becoming amateur sys-admins? auto/zeroconfiguration, autonomous computing, self-healing networks, …Can we prevent social and financial damage inflicted through networks (viruses, spam, DOS, identity theft, privacy violations, …)?
Feb. 4, 2005 QoSIP - Catania 8
Observations on network Observations on network researchresearch
Frustration with inability to change network infrastructure in less than 10 -- 20 year horizons:
IPv6Layer-3 multicastQoSSecurity
Network research community has dismal track record for new applications
web, IM, P2P (Gnutella, BitTorrent), … vs. video-on-demandNiche applications get disproportionate attention
active networks, ad-hoc networks, (structured) P2Psuccessful applications don’t care if they don’t scale
centralized IM & search, unstructured P2P, …Disconnect from standardization
Few attempts to bring research work into standards bodiesStandards bodies slow to catch up (e.g., P2P)
Feb. 4, 2005 QoSIP - Catania 9
Why do good ideas fail?Why do good ideas fail?Research: O(.), CPU overhead
“per-flow reservation (RSVP) doesn’t scale” not the problem
at least now -- routinely handle O(50,000) routing states
Reality:deployment costs of any new L3 technology is probably billions of $
Cost of failure:conservative estimate (1 grad student year = 2 papers)10,000 QoS papers @ $20,000/paper $200 million
Feb. 4, 2005 QoSIP - Catania 10
Cause of death for the next big Cause of death for the next big thingthing
(NAT)
80% solution in existing system
no initial gain
IPsecactive networks
not manageable across competing domains
not configurable by normal users (or apps writers)
no business model for ISPs
increase system vulnerability
IPv6mobile IP
multi-cast
QoS
Feb. 4, 2005 QoSIP - Catania 11
QoSQoSQoS is meaningless to users
difficult to engineer service that is consistently poor, but usable
common QoS models now:scavenger service (worse-than-best-effort) self-protectionDiffServ on access routers and NAT boxes
care about service availability reliabilitybut most commercial service is good enough for VoIP/video/… most of the timecharging model problem users will arbitrage and buy basic quality except during congestion periodssee multi-homing vs. high-end providers
as more and more value depends on network services, can't afford random downtimes
Feb. 4, 2005 QoSIP - Catania 12
Why did QoS (mostly) fail?Why did QoS (mostly) fail?hypothesis: “The success of a technology is inversely proportional to the number of papers published before its popularity.”
ACM: 10,158 papers with QoS or “quality of service” in abstractIEEE: 7,297 papers
real-time streaming video-on-demand DVD via Netflix or TCP onto 200 GB hard disk
bandwidth “too cheap to meter”undemocratic – some traffic is more equal than othersreminds you of your mom: no, you can’t have that 10 Mb/s nowsocialist: administer scarcity -we like SUVs (or to drive 100 mph)!“risky scheme”: securityonly displacement applications (such as telephony) need QoSrequires cooperation: edge-ISP, transit ISPs, end systemssnake oil: add QoS, lose half your bandwidth
Feb. 4, 2005 QoSIP - Catania 13
Why did QoS fail? (Why did QoS fail? (con’tdcon’td))dishonesty: we only talk about the beneficiariesnetwork has become harder to evolve:
network address translationfirewallshigh packetization overhead (VPNs, IPv6)
to be useful, has to be nearly universally supported (“no, you can’t make calls to AS 123”)network QoS vs. business class model: “coach is empty, please refund fare”
currently, the ISP interface is IP and BGP – adding a third one is a big dealnew Internet service model: TCP client (inside) – server (outside)
exception: peer-to-peer on college campuses
network to host: you first, no, you firstfailure of IP QoS success of MPLS
more TE than QoS
Feb. 4, 2005 QoSIP - Catania 14
Where did QoS technology Where did QoS technology succeed?succeed?
Edge network:VLAN prioritization802.11e MAC layer priorityIP TOS byte (not quite DiffServ) – known since 1980s…Docsis/PacketCable application-initiated
Mostly deals with self-interferenceNo admission controlNo authorization (except Docsis)
Feb. 4, 2005 QoSIP - Catania 15
Network reliabilityNetwork reliabilitywe don’t know precisely why network applications fails
components and backbones appear to pretty reliablebut we measured at 99.5% of usable time far below 99.999% in telecom networkslots of possible culprits, including DNS and carrier interconnects
temporary overloadsreduce operator errors
e.g., XCONF effort in IETFinherently safe or fail-safe protocols?
faster convergence in routing protocolsBGP up to 20-30 minutes!
Feb. 4, 2005 QoSIP - Catania 16
New applications New applications –– need for QoS?need for QoS?New bandwidth-intensive applications
Reality-based networking(security) cameras
Distributed games often require only low-bandwidth control information
current game traffic ~ VoIPComputation vs. storage vs. communications
communications cost has decreased less rapidly than storage costs
Emphasis on user control of communicationsfrom anywhere, anytime, any media to where appropriate, my time, my mediaGuess: #1 user-selected research problem: fix spam#2: keep cell phone from ringing in the movie theater
Feb. 4, 2005 QoSIP - Catania 17
New network New network architectures for securityarchitectures for security
Feb. 4, 2005 QoSIP - Catania 18
Security challengesSecurity challengesDOS, security attacks permissions-based communications
only allow modest rates without askingeffectively, back to circuit-switched
Higher-level security services more application-layer access via gateways, proxies, …User identity
problem is not availability, but rather over-abundance
Feb. 4, 2005 QoSIP - Catania 19
TrustabilityTrustability: Internet decay: Internet decayDecay of inner cities: small number of bad elements + lack of social controls and law enforcementSmall number of miscreants
“The bulk of U.S. spam is coming from a very limited set of IPs with high-bandwidth connections," said Alperovitch, who estimated that the high-volume spamming addresses number fewer than 10,000 and the number of spammers at less than 200.” (Informationweek, Aug. 2004)
Naïve userswith increasing firepower
Feb. 4, 2005 QoSIP - Catania 20
TrustabilityTrustability problemsproblemsTraditional security didn’t solve user interface problem
is citi-bank.com my bank or phishing?traditional firewall (crunchy outside, squishy inside)
fails with any content – even JPEGs aren’t safeemail usability rapidly decreasing
most spam proposals unlikely to worknotion of “global village” is an oxymoron
in a village, you know your neighborson-going approaches useful, but limited
conversion of protocols to secured versions (e.g., via TLS)prevent source address spoofingOS and application robustness against buffer overflow attacksIETF MARID (SenderID, SPF, …) for email sender identificationDOS traceback
thus, may need to rethink network architecture
Feb. 4, 2005 QoSIP - Catania 21
TrustabilityTrustability: A more polite : A more polite InternetInternet
introduce yourself first“shoot first, ask later” (Bush)“ask first, shoot later” (Kerry)
yes, up to 10 kb/smay I send?
limits large-scale DDOSmore circuit-orientedmay get permission slip for future use
Feb. 4, 2005 QoSIP - Catania 22
Restoring the village part of the Restoring the village part of the global villageglobal village
It’s not what you know, it’s who you knowAuthentication works only if addresses can be recognized by policy or humanDoesn’t work well for first-time contacts much of communications
won’t be fixed by SPF and SenderIDNeed to leverage indirect knowledge
our approach: social networks for recognizing users in SIP systemsleverage knowledge across media: visiting web page enables receipt of email from related address
make phishing more difficult
Feb. 4, 2005 QoSIP - Catania 23
GIMPS GIMPS –– a modular data a modular data plane signaling protocolplane signaling protocol
(with Robert Hancock, Hannes Tschofenig, S. van den Bosch, G. Karagiannis, A. McDonald, X. Fu and others)
Feb. 4, 2005 QoSIP - Catania 24
OverviewOverview
Signaling: application vs. data planeResource control
DiffServ vs. IntServWhat’s wrong with RSVP?Components of a general solutionNSIS = NTLP (GIMPS) + {NSLP}+
Route change detection
Feb. 4, 2005 QoSIP - Catania 25
Signaling Signaling –– the big picturethe big picturesession signaling
datapath signaling
AS#1 AS#2
off-path NE
SIP proxyserver
off-path signaling
on-path signaling
data
Feb. 4, 2005 QoSIP - Catania 26
Need for data plane state Need for data plane state establishmentestablishment
Differentiated treatment of packetsQoSfirewall (loss = 100% vs. loss = 0%)
Mapping statenetwork address translation (NAT)
Counting packetsaccounting
Other state establishmentsetting up active network capsulesMPLS pathspseudo-wire emulation (PWE) – T1 over IP
Related: visit subset of data path nodes, but don’t leave state behinddiagnostics better traceroutelink speeds, load, loss, packet treatment, …
Feb. 4, 2005 QoSIP - Catania 27
OnOn--path vs. offpath vs. off--path signalingpath signalingOn-path (path-coupled): visit subset of routers on data pathOff-path (path-decoupled): anything else, but presumably roughly along data path
one proposal: one “touch point” for each ASbandwidth brokerdifficult part is resource tracking, not signaling
No fundamental differences in protocol separate out next-hop discovery to allow re-use
Feb. 4, 2005 QoSIP - Catania 28
Differentiated packet handlingDifferentiated packet handlingNot just QOS, but also
firewallnetwork address translationaccounting and measurement
filtermanagement
trafficfiltering
traffic shaping,handling & measurement
IntServ
DiffServ
Feb. 4, 2005 QoSIP - Catania 29
DiffServDiffServ ≅≅ IntServIntServFilter always uses packet characteristic
5-tuple (protocol, source/destination address + port) + global label (TOS)multiple “flows” can be mapped to one treatment mechanism
signaled
5-tuple
IntServ
TCP SYNfixedmapping
5-tupleTOS5-tuple?
identification
in-bandDiffServ
Feb. 4, 2005 QoSIP - Catania 30
The scaling bogeymanThe scaling bogeymanNetworks routinely handle large-scale per-flow state
firewallsNATs
scaling = cost per flow is constant (or decreasing)flow numbers are modest:
OC-48 can handle 31,875 DS-0 voice callsMean call duration = 9 min 60 requests/secondprobably about 3 MB of data
partially explained by poor initial RSVP explanations
where flow search time ~ O(N) rather than O(1)likely limitations are in AAA, not router signaling
It doesn’t scale!
Feb. 4, 2005 QoSIP - Catania 31
RSVP characteristicsRSVP characteristics
soft-state = state vanishes if not refreshedtwo-pass signaling = path discovery + reservationreceiver-based resource reservationseparation of QoS signaling from routing
with some router feedback
Feb. 4, 2005 QoSIP - Catania 32
The problem with RSVPThe problem with RSVPDesigned for QoS establishment, used mostly for other things (RSVP-TE)Designed for large-scale IP multicast customer never materialized
adds significant complexity:receiver-based PATH + RESV
designed for ASM (any-source) rather than SSM (source-specific)receiver-based motivated by receiver diversity – not very useful in practice
Designed in simpler days (1997):does not work well with mobile nodes (IP mobility or changing IPaddresses)no support for NATssecurity mostly bolted on – non-standard mechanismssingle-purpose, with no clear extensibility modelvery primitive transport mechanism
either refresh or exponential decay (refresh reduction, RFC 2961)
Feb. 4, 2005 QoSIP - Catania 33
The cost of multicast for RSVPThe cost of multicast for RSVPreservation styles
multiple senders in same group: shared vs. distinctsender selection: explicit vs. wildcard
receiver-orientedmotivated by heterogeneous can do leaf-initiated join rather than root-initiated
but still need periodic PATH to visit new sub-tree
three different flow specsSender_TSpec, ADSpec, (TSpec, RSpec)fairly tightly woven into core protocol
state merging and managementkiller reservation (KR-II)
generally, error handling problematic
draft-fu-rsvp-multicast-analysis
1020
20
40 60
60
60
1020
20
40 60
60
20
30
ResvErr!
Feb. 4, 2005 QoSIP - Catania 34
IETF NSIS working groupIETF NSIS working groupchartered in Dec. 2001, after BOF in March 2001Motivated by Braden’s two-layer model (draft-lindell-waypoint, draft-braden-2level-signal-arch)Active participation from Roke Manor, Siemens, NEC Europe, Nokia, Samsung, ColumbiaBased partially on CASP protocol designed by Columbia/Siemens group and prototyped at UKy
Feb. 4, 2005 QoSIP - Catania 35
NSIS protocol structureNSIS protocol structure
client layer does the real work:reserve resourcesopen firewall ports…
messaging layer:establishes and tears down statenegotiates features and capabilities
transport layer:reliable transport
NSLP(C)
NTLP(GIMPS)
transport layer
QoS, NAT/FW, …
UDP, TCP, SCTPIP router alert
GIMPS
Feb. 4, 2005 QoSIP - Catania 36
NSIS propertiesNSIS propertiesNetwork friendly
congestion-controlledre-use of state across applications
application-neutraladd more applications later
transport neutralany reliable protocolinitially, TCP and SCTPalso, UDP for initial probing
policy neutralno particular AAA policy or protocolinteraction with COPS, DIAMETER needs work
soft stateper-node time-outexplicit removal of state
extensibledata formatnegotiation
Feb. 4, 2005 QoSIP - Catania 37
NSIS properties, cont'd.NSIS properties, cont'd.Topology hiding
not recommended, but possible
Light weightimplementation complexitysecurity associations (re-use)may not need kernel implementation
Feb. 4, 2005 QoSIP - Catania 38
What is GIMPS?What is GIMPS?Generic signaling transport service
establishes state along path of dataone sender, typically one receiver
can be multiple receivers multicast (not in initial version)
can be used for QoS per-flow or per-class reservationbut not restricted to that
avoid restricting users of protocol (and religious arguments):sender vs. receiver orientationmore or less closely tied to data path
initially, router-by-router (path-coupled)later, network (AS) path (path-decoupled)
Feb. 4, 2005 QoSIP - Catania 39
NSIS network model NSIS network model –– pathpath--coupledcoupled
NTLP nodes form NTLP chainnot every node processes all client protocols:
non-NTLP node: regular routeromnivorous: processes all NTLP messagesselective: bypassed by NTLP messages with unknown client protocols
QoSmidcom
QoS QoS
selective
omnivorous
NTLP chain
Feb. 4, 2005 QoSIP - Catania 40
Network model Network model –– pathpath--decoupleddecoupled
Also route network-by-networkcan combine router-by-router with out-of-path messaging
AS 1249 AS15465 AS17
Bandwidth brokerNAC NTLP
data
Feb. 4, 2005 QoSIP - Catania 41
GIMPS messagesGIMPS messages
Regular NTLP messagesestablish or tear down statecarry client protocoldatagram (“D”) or connection (“C”) mode
Hop-by-hop reliabilityGenerated by any node along the chain
Feb. 4, 2005 QoSIP - Catania 42
NSIS transport protocol usageNSIS transport protocol usageMost signaling messages are small and infrequentbut:
not all applications e.g., mobile code for active networksdigital signaturesre-"dialing" when resources are busy
Need:reliability to avoid long setup delaysflow control avoid overloading signaling servercongestion control avoid overloading networkfragmentation of long signaling messagesin-sequence delivery avoid race conditionstransport-layer security integrity, privacy
This defines standard reliable transport protocols:
TCPSCTP
Avoid re-inventing wheel see SIP experience
Feb. 4, 2005 QoSIP - Catania 43
GIMPS transport protocol GIMPS transport protocol usageusage
One transport connection many NSLP sessionsmay use multiple TCP/SCTP portscan use TLS for transport-layer security
compared to IPsec, well-exercised key establishmentnot quite clear what the principal is
re-use of transport no overhead of TCP and SCTP session establishmentavoid TLS session setupbetter timer estimatesSCTP avoids HOL blocking
Feb. 4, 2005 QoSIP - Catania 44
Message forwardingMessage forwardingRoute stateless or state-full:
stateless: record route and retracestate-full: based on next-hop information in ‘C’ node
Destination:address look at destination addressaddress + record record routeroute based on recorded routestate forward based on next-hop statestate backward based on previous-hop state
State:no-op leave state as isADD add message (and maybe client) stateDEL delete message state
Feb. 4, 2005 QoSIP - Catania 45
Message formatMessage format
No GIMPS distinction between requests and responsesjust routed in different directionsclient protocol may define requests and responses
Common header defines:destination flagstate flagsession identifiertraffic selector: identify traffic "covered" by this sessionmessage sequence numberresponse sequence numbermessage cookie avoid IP address impersonationorigin address may not be data source or sinkdestination address or scope
common header extensions client protocol data
Feb. 4, 2005 QoSIP - Catania 46
Message format, cont'dMessage format, cont'dLimit session lifetimeAvoid loops hop counterMobility:
dead branch removal flagbranch identifier
Record route: gathers up addresses of NSIS nodes visitedRoute: addresses that NSIS message should visit
Feb. 4, 2005 QoSIP - Catania 47
Capability negotiationCapability negotiationNSIS has named capabilities
including client protocols
Three mechanisms:discovery: count capabilities along a path
"10 out of 15 can do QoS"
record: record capabilities for each noderequire: for scout message, only stop once node supports all capabilities (or-of-and)
avoid protocol versioning
Feb. 4, 2005 QoSIP - Catania 48
NextNext--hop discoveryhop discoveryscout messages are special NSIS messageslimited < MTU sizeaddressed to session destinationUDP with router alert option get looked at by each routerreflected when matching NSIS node found
next IP hop
NSIS-aware?
existing transport
connection?
use D mode to findnext NSIS hop
establishtransport
connection
N
Y
N
Y done
Feb. 4, 2005 QoSIP - Catania 49
Mobility and route changesMobility and route changes
avoids session identification by end point addressesavoid use of traffic selector as session identifierremove dead branch
discovers new routeon refresh
ADDB=2
DEL (B=2)
B=1
Feb. 4, 2005 QoSIP - Catania 50
QoSQoS--NSLP: resource reservationNSLP: resource reservationNSLP for signaling QoS reservations in the Internetboth sender- and receiver-initiated reservationssoft-statepeer-to-peer signaling and refresh (rather than end-to-end)bundled sessions (e.g., video + audio)agnostic about QoS models (IntServ, DiffServ, RMD, …)
Feb. 4, 2005 QoSIP - Catania 51
QoSQoS--NSLP: senderNSLP: sender--initiated initiated reservationreservation
RESERVERESERVE
RESERVE
RESPONSERESPONSE
RESPONSE
QNI QNE QNE QNR
(RSN #3)(RSN #17)
(RSN #4)
Feb. 4, 2005 QoSIP - Catania 52
QoSQoS--NSLP: receiverNSLP: receiver--initiated initiated reservationreservation
QUERYQUERY
QUERY
RESERVERESERVE
RESERVE
QNI QNE QNE QNR
RESPONSE RESPONSERESPONSE
Feb. 4, 2005 QoSIP - Catania 53
QoS flow aggregationQoS flow aggregation
aggregate
QoS-NSLP style(RFC 3175)
trafficsink
(LAN)
sinktree style(BGRP)
Feb. 4, 2005 QoSIP - Catania 54
Route change detectionRoute change detectionDon’t want to wait for periodic rediscovery –delay of 30s+Not all route changes matter
e.g., only changes between NSIS routersData plane detection
TTL change of arriving data packetspropagation delay change for data packetsmonitoring propagation delay (~ min(e2e delay))increases in packet loss or jitter
Feb. 4, 2005 QoSIP - Catania 55
Route change measurementsRoute change measurements12 measurement sites (looking glass)one traceroute every 15’ 2.75 hours per pairavailability: 99.8%0.1% repeated IP addresses4.4% single hop with multiple IP addresses422 route changes observed after data cleanup (13,074 records)67 out of 422 also showed AS changes
often, indicates multi-homing
Feb. 4, 2005 QoSIP - Catania 56
Route changes Route changes
0
50
100
150
200
250
Freq
uenc
y
-8 -6 -4 -2 0 2 4 6TTL change
0
5
10
15
20
25
30
35
40
-2 -1 0 1 2
A S co unt change
Feb. 4, 2005 QoSIP - Catania 57
OnOn--going and planned workgoing and planned work
Finish NTLP (GIMPS) and NSIS clients (NAT-FW and QoS)Longer term: off-path signaling (new WG?)New applications: diagnosticsMobility support