Re-ECN: Adding Accountability for Causing Congestion to TCP/IP Bob Briscoe, BT & UCL Arnaud Jacquet, BT Alessandro Salvatori, BT CRN DoS w-g, Apr 2006.

Slides:



Advertisements
Similar presentations
Using Edge-To-Edge Feedback Control to Make Assured Service More Assured in DiffServ Networks K.R.R.Kumar, A.L.Ananda, Lillykutty Jacob Centre for Internet.
Advertisements

Tunnel congestion Feedback (draft-wei-tunnel-congestion-feedback-01) Xinpeng Wei Lei Zhu Lingli Deng Huawei Huawei China Mobile IETF 89 London, UK.
Using Self-interest to Prevent Malice Fixing the Denial of Service Flaw of the Internet Bob Briscoe Chief Researcher, BT Group Oct 2006 Credits: Martin.
Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-03 Bob Briscoe, BT & UCL Arnaud Jacquet, Alessandro Salvatori.
Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp draft-briscoe-tsvwg-re-ecn-tcp Bob Briscoe, BT & UCL Arnaud.
Philip Eardley, Bob Briscoe, Dave Songhurst - BT Francois Le Faucheur, Anna Charny, Vassilis Liatsos – Cisco Kwok-Ho Chan, Joe Babiarz, Stephen Dudley.
The cost of freedom Bob Briscoe Chief Researcher, BT Group and UCL Dec 2006.
Policing congestion response in an internetwork using re-feedback Bob Briscoe 1,2 Arnaud Jacquet 1, Carla Di Cairano- Gilfedder 1, Alessandro Salvatori.
Usage cases for Congestion Accounting Bob Briscoe Chief Researcher, BT Oct 2009 This work is partly funded by Trilogy, a research project supported by.
ConEx Abstract Protocol What’s the Credit marking for? draft-mathis-conex-abstract-mech-00.txt draft-mathis-conex-abstract-mech-00.txt apologies from Bob.
Explicit Congestion Notification (ECN) RFC 3168 Justin Yackoski DEGAS Networking Group CISC856 – TCP/IP Thanks to Namratha Hundigopal.
1 Congestion Control. Transport Layer3-2 Principles of Congestion Control Congestion: r informally: “too many sources sending too much data too fast for.
1 Internet Networking Spring 2003 Tutorial 11 Explicit Congestion Notification (RFC 3168) Limited Transmit (RFC 3042)
1 Internet Networking Spring 2003 Tutorial 11 Explicit Congestion Notification (RFC 3168)
DoS-resistant Internet - progress Bob Briscoe Jun 2005.
A Real-Time Video Multicast Architecture for Assured Forwarding Services Ashraf Matrawy, Ioannis Lambadaris IEEE TRANSACTIONS ON MULTIMEDIA, AUGUST 2005.
1 Spring Semester 2007, Dept. of Computer Science, Technion Internet Networking recitation #8 Explicit Congestion Notification (RFC 3168) Limited Transmit.
Jaehoon (Paul) Jeong, Hyoungshick Kim, and Jung-Soo Park
A broadband incentive solution re-feedback Bob Briscoe, BT Research Nov 2005 CFP broadband incentives w-g.
Using Routing and Tunnelling to Combat DoS Attacks Adam Greenhalgh, Mark Handley, Felipe Huici Dept. of Computer Science University College London
1 Multi-Protocol Label Switching (MPLS). 2 MPLS Overview A forwarding scheme designed to speed up IP packet forwarding (RFC 3031) Idea: use a fixed length.
Viability of Congestion Exposure. Framing the Discussion This discussion is about congestion exposure – not any specific solution Viability and tractability.
Distributed Denial of Service CRyptography Applications Bistro Presented by Lingxuan Hu April 15, 2004.
Tunnelling of Explicit Congestion Notification draft-briscoe-tsvwg-ecn-tunnel-08.txt draft-briscoe-tsvwg-ecn-tunnel-08.txt Bob Briscoe, BT IETF-77 tsvwg.
1 Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP draft-briscoe-tsvwg-ecn-encap-guidelines-01 Bob Briscoe IETF-85 Nov 2012.
ConEx Concepts and Uses Toby Moncaster John Leslie (JLC) Bob Briscoe (BT) Rich Woundy (ComCast) draft-moncaster-conex-concepts-uses-01.
Interest NACK Junxiao Shi, Introduction Interest NACK, aka "negative acknowledgement", is sent from upstream to downstream to inform that.
Datagram Congestion Control Protocol
PCN WG (Pre-Congestion Notification) – a brief status update Philip Eardley, BT TSVAREA, IETF-73 Minneapolis 18 Nov 08
Internet resource sharing: a way forward? Bob Briscoe Chief Researcher, BT May 2009 This work is partly funded by Trilogy, a research project supported.
Congestion marking for low delay (& admission control) Bob Briscoe BT Research Mar 2005.
Future Emergency Telecommunication Scenarios over the Internet Dr. Ken Carlberg Emergency Telecommunications Workshop 26’th-27’th,
Pushing Packet Processing to the Edge Scheduling in Optics is the Wrong Answer for Fine-Grained Resource Sharing Bob Briscoe Chief Researcher, BT Group.
1 Countering DoS Through Filtering Omar Bashir Communications Enabling Technologies
Byte and Packet Congestion Notification draft-briscoe-tsvwg-byte-pkt-mark-01.txt draft-briscoe-tsvwg-byte-pkt-mark-01.txt Bob Briscoe, BT & UCL IETF-70.
Re’Arch 2008 Policing Freedom… to use the Internet Resource Pool Arnaud.Jacquet, Bob.Briscoe, Toby.Moncaster December
Real-time Flow Management 2 BOF: Remote Packet Capture Extensions Jürgen Quittek NEC Europe Ltd, Heidelberg, Germany Georg Carle GMD.
Social & Economic Control of Networks Bob Briscoe Chief Researcher BT Networks Research Centre Jul 2007.
Congestion exposure BoF candidate protocol: re-ECN Bob Briscoe Chief Researcher, BT Nov 2009 This work is partly funded by Trilogy, a research project.
Re-ECN: Adding Accountability for Causing Congestion to TCP/IP Bob Briscoe, BT & UCL Arnaud Jacquet, BT Alessandro Salvatori, BT IETF-65 tsvwg Mar 2006.
Tunnelling of Explicit Congestion Notification draft-briscoe-tsvwg-ecn-tunnel-03.txt draft-briscoe-tsvwg-ecn-tunnel-03.txt Bob Briscoe, BT IETF-75 saag.
1 TCP/IP based TML (Transport Mapping Layer) for ForCES Protocol Hormuzd Khosravi Shuchi Chawla Furquan Ansari Jon Maloy 62 nd IETF Meeting, Minneapolis.
Tunnelling of Explicit Congestion Notification draft-briscoe-tsvwg-ecn-tunnel-02.txt draft-briscoe-tsvwg-ecn-tunnel-02.txt Bob Briscoe, BT IETF-74 tsvwg.
Downstream knowledge upstream re-feedback Bob Briscoe Arnaud Jacquet, Carla Di Cairano- Gilfedder, Andrea Soppera & Martin Koyabe BT Research.
Lecture 20 Page 1 Advanced Network Security Basic Approaches to DDoS Defense Advanced Network Security Peter Reiher August, 2014.
QoS interconnect best without effort Bob Briscoe Chief Researcher BT Sep 2009 This work is partly funded by Trilogy, a research project supported by the.
Guaranteed QoS Synthesiser (GQS) Bob Briscoe, Peter Hovell BT Research Jan 2005.
1 Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made.
Re-ECN: Adding Accountability for Causing Congestion to TCP/IP Bob Briscoe, BT & UCL Arnaud Jacquet, BT Alessandro Salvatori, BT IETF-64 tsvwg Nov 2005.
Making stuff real re-feedback Bob Briscoe, BT Research Nov 2005 CRN DoS resistant Internet w-g.
Solving this Internet resource sharing problem... and the next, and the next Bob Briscoe Chief Researcher BT Group (& UCL) Lou Burness, Toby Moncaster,
Interconnect QoS settlements & impairments Bob Briscoe BT Group CTO.
Network Performance Isolation in Data Centres using Congestion Policing draft-briscoe-conex-data-centre-01.txt draft-briscoe-conex-data-centre-01.txt Bob.
1 Note Well Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made.
Support for ECN and PCN in MPLS networks draft-davie-ecn-mpls-00.txt Bruce Davie Cisco Systems Bob Briscoe June Tay BT Research.
Byte and Packet Congestion Notification draft-briscoe-tsvwg-byte-pkt-mark-02.txt draft-briscoe-tsvwg-byte-pkt-mark-02.txt Bob Briscoe, BT & UCL IETF-71.
Congestion Notification Process for Real-Time Traffic draft-babiarz-tsvwg-rtecn-01.txt Jozef Babiarz Kwok Ho Chan Victor Firoiu 60 th IETF, Aug. 5 th,
Generic Aggregation of Resource Reservation Protocol (RSVP) for IPv4 and IPv6 Reservation over PCN domains Georgios Karagiannis, Anurag Bhargava draft-karagiannis-pcn-tsvwg-rsvp-pcn-01.
Congestion Notification Process for Real-Time Traffic draft-babiarz-tsvwg-rtecn-04.txt Jozef Babiarz Kwok Ho Chan
K. Salah1 Security Protocols in the Internet IPSec.
Philip Eardley, Bob Briscoe, Dave Songhurst - BT Francois Le Faucheur, Anna Charny, Vassilis Liatsos – Cisco Kwok-Ho Chan, Joe Babiarz, Stephen Dudley.
Layered Encapsulation of Congestion Notification draft-briscoe-tsvwg-ecn-tunnel-01.txt draft-briscoe-tsvwg-ecn-tunnel-01.txt Bob Briscoe, BT IETF-72 tsvwg.
Support for ECN and PCN in MPLS networks
Bob Briscoe, BT IETF-73 pcn Nov 2008
Internet Networking recitation #9
Bob Briscoe Simula Research Laboratory
Bob Briscoe, BT Murari Sridharan, Microsoft IETF-84 ConEx Jul 2012
Bob Briscoe, BT IETF-72 tsvwg Jul 2008
Internet Networking recitation #10
1 Multi-Protocol Label Switching (MPLS). 2 MPLS Overview A forwarding scheme designed to speed up IP packet forwarding (RFC 3031) Idea: use a fixed length.
Presentation transcript:

Re-ECN: Adding Accountability for Causing Congestion to TCP/IP Bob Briscoe, BT & UCL Arnaud Jacquet, BT Alessandro Salvatori, BT CRN DoS w-g, Apr 2006

2 intro solution statement re-ECN allows networks to police congestion control at network layer on short and long time-scales if attackers can disguise their traffic perfectly by evading any attempt to distinguish it from a flash crowd re-ECN can ensure attackers cause no more damage than legit users and persistent attackers (incl. zombies) become much less potent than legit users conservative networks that want to protect against attacks can make their own users control congestion correctly can make other networks feel the pain they allow their users to cause –using penalties (typically financial) liberal networks may choose to pay the penalties rather than tightly control their own users (thus attracting the world’s attackers) re-ECN doesn’t aim to control such attackers (it could, but not scalably) just moves money from networks harbouring attackers to networks harbouring victims

3 intro status Apr 06 personal draft in IETF Transport Area draft-briscoe-tsvwg-re-ecn-tcp-01 draft-briscoe-tsvwg-re-ecn-tcp-01 presented twice (Oct 05 & Mar 06) draft-01 fixed vulnerability found in draft-00 protocol encoding interest and positive encouragement (mainly off-list) considerable interest from other operators including ‘official’ interest channelled through BT a/c mgmt net neutrality solution can be used to prevent apps helping themselves to QoS (or account for its use) –VoIP, video, p2p file-sharing –but not because of what they are, just by their congestion behaviour getting swept into debate around US congressional committee looking for partner(s) to take through standards IETF first, later: 3GPP, ETSI TISPAN, etc ideally endpoint OS vendor/policing box vendor, but hits other buttons too

...specific link & tunnel (non-)issues re-ECN in IP... border policing for admission control accountability/control/policing (e2e QoS, DDoS damping, cong’n ctrl policing) stack positioning Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-01 intent §3: overview in TCP/IP §4: in TCP & othersstds §5: in IP §6: accountability appsinform’l Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-01 intent §3: overview in TCP/IP §4: in TCP & othersstds §5: in IP §6: accountability appsinform’l netwk host cc netwk cc link Emulating Border Flow Policing using Re-ECN on Bulk Data draft-briscoe-tsvwg-re-ecn-border-cheat-00 intent: informational Emulating Border Flow Policing using Re-ECN on Bulk Data draft-briscoe-tsvwg-re-ecn-border-cheat-00 intent: informational RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification draft-lefaucheur-rsvp-ecn-00 intent adds congestion f/b to RSVPstds RSVP Extensions for Admission Control over Diffserv using Pre-congestion Notification draft-lefaucheur-rsvp-ecn-00 intent adds congestion f/b to RSVPstds dynamicsluggish... QoS signalling (RSVP/NSLP) UDPTCPDCCP hi speed cc

5 proposed change to IP header re-ECN Extension (RE) flag using last unused bit in IP header once flow established sender re-inserts ECN feedback into forward data (“re-ECN”) as follows re-ECN sender usually sends grey packets on transport layer (e.g. TCP) feedback of every red packet (network layer congestion) sendersends black elsesends grey conceptually, ‘ worth ’ of packet as shown in matrix aim for zero balance of worth in flow re-ECN RE ECN ECT(1) 01 CE 11 sender (credit) [RFC3168] ECN markingRFC3168 router (debit) worth Diffserv ECN RE protocol

6 extended ECN codepoints: summary and new Feedback-Established (FE) flag extra semantics backward compatible with previous ECN codepoint semantics ECN code- point ECN [RFC3168] codepointRFC3168 RE flag Extended ECN codepoint re-ECN meaning`worth’ 00not-ECT 0Not-RECT Not re-ECN capable transport 1FNE Feedback not established +1 01ECT(1) 0Re-Echo Re-echo congestion event +1 1RECT Re-ECN capable transport 0 10ECT(0) 0--- ‘Legacy’ ECN use 1--CU-- Currently unused 11CE 0CE(0) Congestion experienced with Re-Echo 0 1CE(-1) Congestion experienced protocol

7 flow bootstrap feedback not established ( FNE ) codepoint; RE=1, ECN=00 sent when don’t know which way to set RE flag, due to lack of feedback ‘worth’ +1, so builds up credit when sent at flow start after idle >1sec next packet MUST be green enables deterministic flow state mgmt (policers, droppers, firewalls, servers) green packets are ECN-capable routers MAY ECN mark, rather than drop strong condition on deployment (see draft) green also serves as state setup bit [Clark, Handley & Greenhalgh] protocol-independent identification of flow state set-up for servers, firewalls, tag switching, etc don’t create state if not set may drop packet if not set but matching state not found firewalls can permit protocol evolution without knowing semantics some validation of encrypted traffic, independent of transport can limit outgoing rate of state setup considering I-D [Handley & Greenhalgh] state-setup codepoint independent of, but compatible with, re-ECN green is ‘soft-state set-up codepoint’ (idempotent), to be precise protocol

8 brief romp through re-ECN draft (65pp) easter egg added :) re-ECN in TCP fully spec’d (§4) network layer (§5) OPTIONAL router forwarding changes → next slide control and management section added accountability/policing applications (§6) incentive framework –example ingress policers & egress dropper, pseudo-code TBA DDoS mitigation explained enables simpler ways to do e2e QoS, traffic eng, inter-domain SLAs incremental deployment (§7) → next slide but one architectural rationale (§8) security considerations (§10) → next slide but two

9 incremental deployment (§7: 5½pp) brings together reasoning for wire protocol choices during deployment period networks can throttle down goodput for legacy hosts can’t attack by using legacy behaviours deployment scenarios & incentives everyone who needs to act, must have strong incentive to act and incentives must arise in the order of required deployment main messages first step to break ECN deployment deadlock –edge-edge PCN for end-to-end controlled load (CL) QoS next step: greed and fear motivators –help TCP (naively friendly) against greedy (streaming) apps –probably vertically integrated (conservative) operators first –3GPP devices leak deployment to other networks by roaming unilateral deployment per network... deployment

10 deployment how to allow some networks to police - NGN and Internet conservative networks might want to throttle if unresponsive to congestion (VoIP, video, DDoS) middle ground might want to cap congestion caused per user (e.g. 24x7 heavy sources) liberal networks open access, no restrictions evolution of hi-speed/different congestion control,... new worms many believe Internet is broken not IETF role to pre-judge which is right answer to these socio-economic issues Internet needs all these answers – balance to be determined by natural selection ‘do-nothing’ doesn’t maintain liberal status quo, we just get more walls re-ECN goals just enough support for conservative policies without breaking ‘net neutrality’ manage evolution of new congestion control, even for liberal → conservative flows nets that allow their users to cause congestion in other nets, can be held accountable

11 deployment re-ECN partial deployment on every congestion event from TCP, sender sends black, else sets grey at any point on path, diff betw fractions of black & red is downstream congestion routers unchanged Echo in TCP RE ECN ECT(1) 01 CE 11 worth 0% re-ECN fraction, v i 3% v i  RE – CE resource index RE NANA NBNB R1R1 S1S1 2.6% 0.4% CE CE S2S2 dropper policer interconnect penalties unpoliced (liberal) network policed (conservative) network 3%

12 defences incentive framework NANA NBNB R1R1 S1S1 dropper policer interconnect penalties 0% 2% downstream congestion  black – red resource index 3% malicious sender re-echoes 2% black (understatement) packets carry view of downstream path congestion to each router using path congestion declared by sender –can police rate response –or enforce congestion quotas won’t sender or rcvr just understate congestion? –egress drops negative balance (next slide )

13 defences egress dropper (sketch) drop enough traffic to make fraction of red = black understatement allows gain through policer, but dropper always fully cancels it out goodput best if rcvr & sender honest about feedback & re-feedback understate congestion to attack routers? given overloaded routers, honest senders will be sending nearly all black overloaded routers preferentially drop grey and red (next slide) important principle: attack traffic does no harm until it congests a router re-ECN drops attack at first congested router (no push-back, no new attack vector) 2% code-point rate 3% 98% 2% 95% cheating sender or receiver understates black = = egress dropper NANA NBNB NDND R1R1 S1S1 policer dropper x 2/3

14 defences OPTIONAL router forwarding changes and new Feedback-Established (FE) flag preferential drop: improves robustness against DDoS green can be ECN marked rather than dropped (with caveat) ECN code- point ECN [RFC3168] codepointRFC3168 RE flag Extended ECN codepoint re-ECN meaning`worth’pref drop (1=drop 1 st ) 00not-ECT 0Not-RECT Not re-ECN capable transport 1 1FNE Feedback not established ECT(1) 0Re-Echo Re-echo congestion event +13 1RECT Re-ECN capable transport 02 10ECT(0) 0--- ‘Legacy’ ECN use 1 1--CU-- Currently unused 1 11CE 0CE(0) CE with Re-Echo 02 1CE(-1) Congestion experienced 2

15 defences £ $ inter-domain accountability for congestion metric for inter-domain SLAs or usage charges N B applies penalty to N A in proportion to bulk volume of black less bulk volume of red over, say, a month could be tiered penalties, directly proportionate usage charge, etc. flows de-aggregate precisely to responsible networks 0% downstream congestion 3% NANA NBNB NDND R1R1 S1S1 2.6% 2.1%

16 defences incentive framework at any point on path, diff betw fractions of black & red is downstream congestion routers unchanged Echo in TCP 0% re-ECN fraction 3% black – red resource index NANA NBNB R1R1 S1S1 2.6% 0.4% red dropper policer interconnect penalties 3% RE ECN ECT(1) 01 CE 11 worth

17 defences re-ECN security considerations ( §10 ) and incentive framework limitations (§6.3) egress dropper –robust against attack that plays-off against ingress policing –robust against state exhaustion attacks (by design of green ) –write-up of state aggregation implementation TBA –believe new protocol allows dropper to be robust against dynamic attacks collateral damage attack still possible → next slide re-ECN deliberately designed not to rely on crypto

18 summary independence from identifiers controls congestion crossing any physical interface user-network, network-network congestion from network layer down to physical not from a source address does have a dependency on source addresses not to identify sources, merely to treat each flow separately outstanding vulnerability –attacker spoofs another source’s flow –deliberately brings down their joint average causing high drop

19 re-ECN summary neutralises attacks indistinguishable from flash crowd or bankrupts (?) networks that harbour attackers simple architectural fix generic accountability hook per datagram requires one bit in IP header can separate out feedback not est’d flag (≡ state set-up) driven by big greed buttons, not just fear (DoS) enables ‘net neutral’ policing of causes of congestion fixed vulnerabilities so far by making it simpler working on robustness to new attacks detailed incremental deployment story liberal networks can choose not to police, but still accountable summary

Re-ECN: Adding Accountability for Causing Congestion to TCP/IP draft-briscoe-tsvwg-re-ecn-tcp-01.txt draft-briscoe-tsvwg-re-ecn-tcp-01.txt Q&A

21 previous re-ECN protocol (IP layer) Feedback-Established (FE) flag sender re-inserts congestion feedback into forward data: “re-feedback” on every Echo-CE from transport (e.g. TCP) sendersets ECT(0) elsesets ECT(1) ECN code- point standard designation 00not-ECT 10ECT(0) 01ECT(1) 11CE protocol IPv4 control flags FEDFMF

22 accountability for congestion other applications congestion-history-based policer (congestion cap) throttles causes of past heavy congestion (zombies, 24x7 p2p) DDoS mitigation QoS & DCCP profile flexibility ingress can unilaterally allow different rate responses to congestion load sharing, traffic engineering multipath routers can compare downstream congestion bulk metric for inter-domain SLAs or charges bulk volume of ECT(0) less bulk volume of CE upstream networks that do nothing about policing, DoS, zombies etc will break SLA or get charged more security aps £ £ 0% re-ECN, v i 3% NANA NBNB NDND R1R1 S1S1

23 security aps congestion competition – inter-domain routing if congestion → profit for a network, why not fake it? upstream networks will route round more highly congested paths N A can see relative costs of paths to R 1 thru N B & N C the issue of monopoly paths incentivise new provision collusion issues require market regulation NANA NBNB NCNC NDND R1R1 S1S1 ? down- stream route cost, Q i resource sequence index, i faked congestio n ? routin g choice