QoS and security - using traditional services for new ends · QoS and security - using traditional services for new ends ... research and QoS ... failure of IP QoS Æsuccess of MPLS

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


OverviewOverview

Some impolite remarks about network research and QoSQoS challenges in real networks:

NATs and firewallsDOSreliability

Permission-based networkingGIMPS: next steps in signaling


Impolite remarks on QoS Impolite remarks on QoS and network researchand network research


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?


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


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?


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, …)?


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)


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


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


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


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


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


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)


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!


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


New network New network architectures for securityarchitectures for security


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


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


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


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


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


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)


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


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


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, …


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


Differentiated packet handlingDifferentiated packet handlingNot just QOS, but also

firewallnetwork address translationaccounting and measurement

filtermanagement

trafficfiltering

traffic shaping,handling & measurement

IntServ

DiffServ


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


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!


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


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)


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!


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


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


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


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


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)


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


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


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


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


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


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


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


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


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


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


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


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, …)


QoSQoS--NSLP: senderNSLP: sender--initiated initiated reservationreservation

RESERVERESERVE

RESERVE

RESPONSERESPONSE

RESPONSE

QNI QNE QNE QNR

(RSN #3)(RSN #17)

(RSN #4)


QoSQoS--NSLP: receiverNSLP: receiver--initiated initiated reservationreservation

QUERYQUERY

QUERY

RESERVERESERVE

RESERVE

QNI QNE QNE QNR

RESPONSE RESPONSERESPONSE


QoS flow aggregationQoS flow aggregation

aggregate

QoS-NSLP style(RFC 3175)

trafficsink

(LAN)

sinktree style(BGRP)


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


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


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


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


ConclusionConclusion

QoS deployment: 25 year old technology at edge only

can do 95% with 5% complexitySecurity concerns trump utilization optimization

prioritize user traffic deny resources to attacker

GIMPS: a re-engineered generic signaling mechanism

Documents

QoS and security - using traditional services for new ends · QoS and security - using traditional services for new ends ... research and QoS ... failure of IP QoS Æsuccess of MPLS