1. Feb. 4, 2005QoSIP - Catania1 QoS and security - using traditional services for new ends Henning Schulzrinne Dept. of Computer Science Columbia University

2. Feb. 4, 2005 QoSIP - Catania2 Overview 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

3. Feb. 4, 2005 QoSIP - Catania3 Impolite remarks on QoS and network research

4. Feb. 4, 2005 QoSIP - Catania4 Lifecycle of technologies militarycorporateconsumer 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?

5. Feb. 4, 2005 QoSIP - Catania5 Networking research is fashion- driven networking courses First (European) workshop on X -- YAP on X workshop white paper DARPA, NSF  $$ secondary conferences EU N th framework Sigcomm Infocom Mobicom ICNP ATM DQDB QoS mobile networks wireless ad-hoc, sensor active networks trailing-edge research

6. Feb. 4, 2005 QoSIP - Catania6 Impact of network research 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?

7. Feb. 4, 2005 QoSIP - Catania7 Maturing 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, …)?

8. Feb. 4, 2005 QoSIP - Catania8 Observations on network research 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)

9. Feb. 4, 2005 QoSIP - Catania9 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

10. Feb. 4, 2005 QoSIP - Catania10 Cause of death for the next big thing QoSmulti- cast mobile IP active networks IPsecIPv6 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 

11. Feb. 4, 2005 QoSIP - Catania11 QoS 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

12. Feb. 4, 2005 QoSIP - Catania12 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

13. Feb. 4, 2005 QoSIP - Catania13 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

14. Feb. 4, 2005 QoSIP - Catania14 Where did QoS technology 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)

15. Feb. 4, 2005 QoSIP - Catania15 Network 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!

16. Feb. 4, 2005 QoSIP - Catania16 New applications – need for 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

17. Feb. 4, 2005 QoSIP - Catania17 New network architectures for security

18. Feb. 4, 2005 QoSIP - Catania18 Security 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

19. Feb. 4, 2005 QoSIP - Catania19 Trustability: 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

20. Feb. 4, 2005 QoSIP - Catania20 Trustability 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

21. Feb. 4, 2005 QoSIP - Catania21 Trustability: A more polite Internet introduce yourself first “shoot first, ask later” (Bush) “ask first, shoot later” (Kerry) yes, up to 10 kb/s may I send?  limits large-scale DDOS  more circuit-oriented  may get permission slip for future use

22. Feb. 4, 2005 QoSIP - Catania22 Restoring the village part of the 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

23. Feb. 4, 2005 QoSIP - Catania23 GIMPS – a modular data plane signaling protocol (with Robert Hancock, Hannes Tschofenig, S. van den Bosch, G. Karagiannis, A. McDonald, X. Fu and others)

24. Feb. 4, 2005 QoSIP - Catania24 Overview 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

25. Feb. 4, 2005 QoSIP - Catania25 Signaling – the big picture session signaling datapath signaling AS#1 AS#2 off-path NE SIP proxy server off-path signaling on-path signaling data

26. Feb. 4, 2005 QoSIP - Catania26 Need for data plane state establishment 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, …

27. Feb. 4, 2005 QoSIP - Catania27 On-path vs. off-path signaling 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

28. Feb. 4, 2005 QoSIP - Catania28 Differentiated packet handling Not just QOS, but also firewall network address translation accounting and measurement filter management traffic filtering traffic shaping, handling & measurement IntServ DiffServ

29. Feb. 4, 2005 QoSIP - Catania29 DiffServ  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 DiffServIntServin-band identificatio n TOS 5-tuple? 5-tuple mappingfixedsignaledTCP SYN

30. Feb. 4, 2005 QoSIP - Catania30 The 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!

31. Feb. 4, 2005 QoSIP - Catania31 RSVP 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

32. Feb. 4, 2005 QoSIP - Catania32 The 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)

33. Feb. 4, 2005 QoSIP - Catania33 The cost of multicast for RSVP 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 4060 1020 4060 20 3030 ResvErr!

34. Feb. 4, 2005 QoSIP - Catania34 IETF 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

35. Feb. 4, 2005 QoSIP - Catania35 NSIS 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

36. Feb. 4, 2005 QoSIP - Catania36 NSIS 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

37. Feb. 4, 2005 QoSIP - Catania37 NSIS properties, cont'd. Topology hiding not recommended, but possible Light weight implementation complexity security associations (re-use) may not need kernel implementation

38. Feb. 4, 2005 QoSIP - Catania38 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)

39. Feb. 4, 2005 QoSIP - Catania39 NSIS network model – path- coupled 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 selective omnivorous NTLP chain

40. Feb. 4, 2005 QoSIP - Catania40 Network model – path- decoupled Network model – path- decoupled Also route network-by-network can combine router-by-router with out- of-path messaging AS 1249 AS15465 AS17 Bandwidth broker NAC NTLP data

41. Feb. 4, 2005 QoSIP - Catania41 GIMPS 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

42. Feb. 4, 2005 QoSIP - Catania42 NSIS transport protocol usage 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

43. Feb. 4, 2005 QoSIP - Catania43 GIMPS transport protocol usage 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

44. Feb. 4, 2005 QoSIP - Catania44 Message 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

45. Feb. 4, 2005 QoSIP - Catania45 Message 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 headerextensionsclient protocol data

46. Feb. 4, 2005 QoSIP - Catania46 Message 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

47. Feb. 4, 2005 QoSIP - Catania47 Capability 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

48. Feb. 4, 2005 QoSIP - Catania48 Next-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

49. Feb. 4, 2005 QoSIP - Catania49 Mobility and route changes 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

50. Feb. 4, 2005 QoSIP - Catania50 QoS-NSLP: resource reservation 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, …)

51. Feb. 4, 2005 QoSIP - Catania51 QoS-NSLP: sender-initiated reservation RESERVE RESPONSE QNIQNE QNR ( RSN #3) ( RSN #17) ( RSN #4)

52. Feb. 4, 2005 QoSIP - Catania52 QoS-NSLP: receiver-initiated reservation QUERY RESERVE QNIQNE QNR RESPONSE

53. Feb. 4, 2005 QoSIP - Catania53 QoS flow aggregation aggregate QoS-NSLP style (RFC 3175) traffic sink (LAN) sinktree style (BGRP)

54. Feb. 4, 2005 QoSIP - Catania54 Route 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

55. Feb. 4, 2005 QoSIP - Catania55 Route change measurements 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

56. Feb. 4, 2005 QoSIP - Catania56 Route changes

57. Feb. 4, 2005 QoSIP - Catania57 On-going and planned work Finish NTLP (GIMPS) and NSIS clients (NAT-FW and QoS) Longer term: off-path signaling (new WG?) New applications: diagnostics Mobility support

58. Feb. 4, 2005 QoSIP - Catania58 Conclusion QoS deployment: 25 year old technology at edge only can do 95% with 5% complexity Security concerns trump utilization optimization prioritize user traffic  deny resources to attacker GIMPS: a re-engineered generic signaling mechanism