Feb. 4, 2005 QoSIP - Catania 1
QoS and security - using QoS and security - using traditional services for new traditional services for new endsends
Henning SchulzrinneDept. of Computer Science
Columbia University
Feb. 4, 2005 QoSIP - Catania 2
OverviewOverview
Some impolite remarks about network research and QoS
QoS challenges in real networks: NATs and firewalls DOS reliability
Permission-based networking GIMPS: next steps in signaling
Feb. 4, 2005 QoSIP - Catania 3
Impolite remarks on Impolite remarks on QoS and network QoS and network researchresearch
Feb. 4, 2005 QoSIP - Catania 4
Lifecycle of technologiesLifecycle of technologies
military corporate consumer
traditional technology propagation:
opex/capex
doesn’t matter;expert support
capex/opex
sensitive, but
amortized;expert support
capex sensitive;amateur
Can it be done? Can I afford it? Can my mother use it?
Feb. 4, 2005 QoSIP - Catania 5
Networking research is Networking research is fashion-drivenfashion-driven
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 Impact of network researchresearch What’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, compression
typical performance improvements in queueing: 20-50%
Networking research impact
on 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 research Old 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: IPv6 Layer-3 multicast QoS Security
Network research community has dismal track record for new applications
web, IM, P2P (Gnutella, BitTorrent), … vs. video-on-demand Niche applications get disproportionate attention
active networks, ad-hoc networks, (structured) P2P successful 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 bodies Standards 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 Cause of death for the next big thingbig thing
QoS multi-cast
mobile IP
active networks
IPsec
IPv6
not manageable across competing domains
not configurable by normal users (or apps writers)
no business model for ISPs
no initial gain 80% solution in existing system
(NAT)
increase system vulnerability
Feb. 4, 2005 QoSIP - Catania 11
QoSQoS QoS 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-
protection DiffServ on access routers and NAT boxes
care about service availability reliability but most commercial service is good enough for
VoIP/video/… most of the time charging model problem users will arbitrage and
buy basic quality except during congestion periods see 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 abstract
IEEE: 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 others
reminds you of your mom: no, you can’t have that 10 Mb/s now
socialist: administer scarcity - we like SUVs (or to drive 100 mph)!
“risky scheme”: security only displacement
applications (such as telephony) need QoS
requires cooperation: edge-ISP, transit ISPs, end systems
snake oil: add QoS, lose half your bandwidth
Feb. 4, 2005 QoSIP - Catania 13
Why did QoS fail? (con’td)Why did QoS fail? (con’td) dishonesty: we only talk
about the beneficiaries network has become
harder to evolve: network address
translation firewalls high 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 deal
new Internet service model: TCP client (inside) – server (outside)
exception: peer-to-peer on college campuses
network to host: you first, no, you first
failure 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 prioritization 802.11e MAC layer priority IP TOS byte (not quite DiffServ) –
known since 1980s… Docsis/PacketCable application-
initiated Mostly deals with self-interference No admission control No authorization (except Docsis)
Feb. 4, 2005 QoSIP - Catania 15
Network reliabilityNetwork reliability we don’t know precisely why network
applications fails components and backbones appear to pretty reliable but we measured at 99.5% of usable time far
below 99.999% in telecom networks lots of possible culprits, including DNS and carrier
interconnects temporary overloads reduce operator errors
e.g., XCONF effort in IETF inherently safe or fail-safe protocols?
faster convergence in routing protocols BGP up to 20-30 minutes!
Feb. 4, 2005 QoSIP - Catania 16
New applications – need for New applications – need for QoS?QoS? New bandwidth-intensive applications
Reality-based networking (security) cameras
Distributed games often require only low-bandwidth control information
current game traffic ~ VoIP Computation vs. storage vs. communications
communications cost has decreased less rapidly than storage costs
Emphasis on user control of communications from anywhere, anytime, any media to where
appropriate, my time, my media Guess: #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 architectures for securitysecurity
Feb. 4, 2005 QoSIP - Catania 18
Security challengesSecurity challenges DOS, security attacks permissions-
based communications only allow modest rates without asking effectively, 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
Trustability: Internet decayTrustability: Internet decay Decay of inner cities: small number of bad
elements + lack of social controls and law enforcement
Small 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 users with increasing firepower
Feb. 4, 2005 QoSIP - Catania 20
Trustability problemsTrustability problems Traditional 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 safe email usability rapidly decreasing
most spam proposals unlikely to work notion of “global village” is an oxymoron
in a village, you know your neighbors on-going approaches useful, but limited
conversion of protocols to secured versions (e.g., via TLS) prevent source address spoofing OS and application robustness against buffer overflow
attacks IETF MARID (SenderID, SPF, …) for email sender
identification DOS traceback
thus, may need to rethink network architecture
Feb. 4, 2005 QoSIP - Catania 21
Trustability: A more polite Trustability: 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 Restoring the village part of the global villagethe global village It’s not what you know, it’s who you know Authentication works only if addresses can
be recognized by policy or human Doesn’t work well for first-time contacts
much of communications won’t be fixed by SPF and SenderID
Need to leverage indirect knowledge our approach: social networks for recognizing
users in SIP systems leverage knowledge across media: visiting web
page enables receipt of email from related address make phishing more difficult
Feb. 4, 2005 QoSIP - Catania 23
GIMPS – a modular GIMPS – a modular data plane signaling data plane signaling protocolprotocol
(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
plane Resource control
DiffServ vs. IntServ What’s wrong with RSVP? Components of a general solution NSIS = NTLP (GIMPS) + {NSLP}+
Route change detection
Feb. 4, 2005 QoSIP - Catania 25
Signaling – the big pictureSignaling – the 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 packets
QoS firewall (loss = 100% vs. loss = 0%)
Mapping state network address translation (NAT)
Counting packets accounting
Other state establishment setting up active network capsules MPLS paths pseudo-wire emulation (PWE) – T1 over IP
Related: visit subset of data path nodes, but don’t leave state behind
diagnostics better traceroute link speeds, load, loss, packet treatment, …
Feb. 4, 2005 QoSIP - Catania 27
On-path vs. off-path On-path vs. off-path signalingsignaling On-path (path-coupled): visit subset of
routers on data path Off-path (path-decoupled): anything else,
but presumably roughly along data path one proposal: one “touch point” for each AS bandwidth broker difficult 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 Differentiated packet handlinghandling Not just QOS, but also
firewall network address translation accounting and measurement
filtermanagement
trafficfiltering
traffic shaping,handling & measurement
IntServ
DiffServ
Feb. 4, 2005 QoSIP - Catania 29
DiffServ DiffServ IntServ IntServ Filter always uses packet
characteristic 5-tuple (protocol, source/destination
address + port) + global label (TOS) multiple “flows” can be mapped to one
treatment mechanism
DiffServ
IntServ in-band
identification
TOS5-tuple?
5-tuple 5-tuple
mapping
fixed signaled TCP SYN
Feb. 4, 2005 QoSIP - Catania 30
The scaling bogeymanThe scaling bogeyman Networks routinely handle large-scale per-
flow state firewalls NATs
scaling = cost per flow is constant (or decreasing)
flow numbers are modest: OC-48 can handle 31,875 DS-0 voice calls Mean call duration = 9 min 60
requests/second probably 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
refreshed two-pass signaling = path discovery
+ reservation receiver-based resource reservation separation of QoS signaling from
routing with some router feedback
Feb. 4, 2005 QoSIP - Catania 32
The problem with RSVPThe problem with RSVP Designed 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 IP addresses)
no support for NATs security mostly bolted on – non-standard mechanisms single-purpose, with no clear extensibility model very primitive transport mechanism
either refresh or exponential decay (refresh reduction, RFC 2961)
Feb. 4, 2005 QoSIP - Catania 33
The cost of multicast for The cost of multicast for RSVPRSVP reservation styles
multiple senders in same group: shared vs. distinct
sender selection: explicit vs. wildcard receiver-oriented
motivated by heterogeneous can do leaf-initiated join rather than
root-initiated but still need periodic PATH to visit new
sub-tree three different flow specs
Sender_TSpec, ADSpec, (TSpec, RSpec) fairly tightly woven into core protocol
state merging and management killer 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 group chartered in Dec. 2001, after BOF in March
2001 Motivated by Braden’s two-layer model
(draft-lindell-waypoint, draft-braden-2level-signal-arch)
Active participation from Roke Manor, Siemens, NEC Europe, Nokia, Samsung, Columbia
Based 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 resources open firewall ports …
messaging layer: establishes and tears down state negotiates features and capabilities
transport layer: reliable transport
NSLP
(C)
NTLP
(GIMPS)
transport layer
QoS, NAT/FW, …
UDP, TCP, SCTP
IP router alert
GIMPS
Feb. 4, 2005 QoSIP - Catania 36
NSIS propertiesNSIS properties Network friendly
congestion-controlled re-use of state across
applications application-neutral
add more applications later transport neutral
any reliable protocol initially, TCP and SCTP also, UDP for initial probing
policy neutral no particular AAA policy or
protocol interaction with COPS,
DIAMETER needs work
soft state per-node time-out explicit removal of state
extensible data format negotiation
Feb. 4, 2005 QoSIP - Catania 37
NSIS properties, cont'd.NSIS properties, cont'd. Topology hiding
not recommended, but possible
Light weight implementation
complexity security 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 data one sender, typically one receiver
can be multiple receivers multicast (not in initial version) can be used for QoS per-flow or per-class reservation but not restricted to that
avoid restricting users of protocol (and religious arguments): sender vs. receiver orientation more 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 – path-NSIS network model – path-coupledcoupled
NTLP nodes form NTLP chain not every node processes all client protocols:
non-NTLP node: regular router omnivorous: processes all NTLP messages selective: bypassed by NTLP messages with unknown client protocols
QoS
midcom
QoS QoS
selective
omnivorous
NTLP chain
Feb. 4, 2005 QoSIP - Catania 40
Network model – path-Network model – path-decoupleddecoupled
Also route network-by-network can combine router-by-router with
out-of-path messaging
AS 1249 AS15465 AS17
Bandwidth broker
NAC NTLP
data
Feb. 4, 2005 QoSIP - Catania 41
GIMPS messagesGIMPS messages
Regular NTLP messages establish or tear down state carry client protocol datagram (“D”) or connection (“C”)
mode Hop-by-hop reliability Generated by any node along the
chain
Feb. 4, 2005 QoSIP - Catania 42
NSIS transport protocol NSIS transport protocol usageusage Most signaling messages are small and
infrequent but:
not all applications e.g., mobile code for active networks
digital signatures re-"dialing" when resources are busy
Need: reliability to avoid long setup delays flow control avoid overloading
signaling server congestion control avoid overloading
network fragmentation of long signaling
messages in-sequence delivery avoid race
conditions transport-layer security integrity,
privacy
This defines standard reliable transport protocols:
TCP SCTP
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
sessions may use multiple TCP/SCTP ports can use TLS for transport-layer security
compared to IPsec, well-exercised key establishment not quite clear what the principal is
re-use of transport no overhead of TCP and SCTP session establishment avoid TLS session setup better timer estimates SCTP avoids HOL blocking
Feb. 4, 2005 QoSIP - Catania 44
Message forwardingMessage forwarding Route stateless or state-full:
stateless: record route and retrace state-full: based on next-hop information in ‘C’ node
Destination: address look at destination address address + record record route route based on recorded route state forward based on next-hop state state backward based on previous-hop state
State: no-op leave state as is ADD add message (and maybe client) state DEL delete message state
Feb. 4, 2005 QoSIP - Catania 45
Message formatMessage format
No GIMPS distinction between requests and responses just routed in different directions client protocol may define requests and responses
Common header defines: destination flag state flag session identifier traffic selector: identify traffic "covered" by this session message sequence number response sequence number message cookie avoid IP address impersonation origin address may not be data source or sink destination address or scope
common header extensions client protocol data
Feb. 4, 2005 QoSIP - Catania 46
Message format, cont'dMessage format, cont'd Limit session lifetime Avoid loops hop counter Mobility:
dead branch removal flag branch identifier
Record route: gathers up addresses of NSIS nodes visited
Route: addresses that NSIS message should visit
Feb. 4, 2005 QoSIP - Catania 47
Capability negotiationCapability negotiation NSIS 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 node require: for scout message, only stop once node
supports all capabilities (or-of-and) avoid protocol versioning
Feb. 4, 2005 QoSIP - Catania 48
Next-hop discoveryNext-hop discovery scout
messages are special NSIS messages
limited < MTU size
addressed to session destination
UDP with router alert option get looked at by each router
reflected when matching NSIS node found
next IP hop
NSIS-aware?
existing transport
connection?
use D mode to find
next NSIS hop
establish
transport
connection
N
Y
N
Y done
Feb. 4, 2005 QoSIP - Catania 49
Mobility and route Mobility and route changeschanges
avoids session identification by end point addresses
avoid use of traffic selector as session identifier
remove dead branch
discovers new route
on refresh
ADD
B=2
DEL (B=2)
B=1
Feb. 4, 2005 QoSIP - Catania 50
QoS-NSLP: resource QoS-NSLP: resource reservationreservation NSLP for signaling QoS reservations in
the Internet both sender- and receiver-initiated
reservations soft-state peer-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
QoS-NSLP: sender-initiated QoS-NSLP: sender-initiated reservationreservation
RESERVERESERVE
RESERVE
RESPONSERESPONSE
RESPONSE
QNI QNE QNE QNR
(RSN #3)(RSN #17)
(RSN #4)
Feb. 4, 2005 QoSIP - Catania 52
QoS-NSLP: receiver-initiated QoS-NSLP: receiver-initiated reservationreservation
QUERYQUERY
QUERY
RESERVERESERVE
RESERVE
QNI QNE QNE QNR
RESPONSERESPONSE
RESPONSE
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 detection Don’t want to wait for periodic
rediscovery – delay of 30s+ Not all route changes matter
e.g., only changes between NSIS routers Data plane detection
TTL change of arriving data packets propagation delay change for data packets monitoring propagation delay (~ min(e2e
delay)) increases in packet loss or jitter
Feb. 4, 2005 QoSIP - Catania 55
Route change Route change measurementsmeasurements 12 measurement sites (looking glass) one traceroute every 15’ 2.75 hours
per pair availability: 99.8% 0.1% repeated IP addresses 4.4% single hop with multiple IP
addresses 422 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
Fre
qu
ency
-8 -6 -4 -2 0 2 4 6
TTL change
0
5
10
15
20
25
30
35
40
-2 -1 0 1 2
AS count change
Feb. 4, 2005 QoSIP - Catania 57
On-going and planned On-going and planned workwork
Finish NTLP (GIMPS) and NSIS clients (NAT-FW and QoS)
Longer term: off-path signaling (new WG?)
New applications: diagnostics Mobility support