1 / 12

DoS-resistant Internet - progress

DoS-resistant Internet - progress. Bob Briscoe Jun 2005. BT activity. Research 2020 Communications Architecture project DoS-resistant Internet Architecture task Network Security project BGP security control plane separation intrusion detection systems Engineering Network design

vonda
Télécharger la présentation

DoS-resistant Internet - progress

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. DoS-resistant Internet- progress Bob Briscoe Jun 2005

  2. BT activity • Research • 2020 Communications Architecture project • DoS-resistant Internet Architecture task • Network Security project • BGP security • control plane separation • intrusion detection systems • Engineering • Network design • Second line support for operations • Operations • Deployment and operation of attack mitigation technology

  3. CRN DoS-resistant Internet w-g task Registry ofattacks Operatorco-ord Registry ofdefences DoS-resistantarchitecture Grandstrategy DoS resistant Internet architectureBT 0506 deliverables legend M4.1 Industry co-ordination BT DoS-resistant Internet Architecture task D1.1 Taxonomyof attacks M2.1 Focused literature study M4.2 BT co-ordination D1.2 Taxonomyof defences M2.2? [Place-holder]: Testingarchitectural uncertainties D3.x [Place-holder]: Newarchitectural ideas D2.1 Agenda for arch change D2.1.1? [Placeholder]: System demonstrator D2.2 Roadmapping strategic options

  4. DoS-resistant Internet Architecture • approach • cherry pick the ideas of others • sprinkle in a few ideas of our own • stress-test • propose a target architecture of complementary solutions • describe incremental deployment

  5. architectural component ideascandidate list • Symmetric paths, address separation, RPF checks, state set-up bit, nonce exchange, middlewalls • M Handley and A Greenhalgh “Steps towards a DoS-resistant Internet architecture” FDNA (2004) • Secure Internet Indirection Infrastructure • D Adkins et al “Towards a More Functional and Secure Network Infrastructure” UC Berkeley TR-CSD-03-1242 (2003) • Re-feedback • B Briscoe et al “Policing Congestion Response in an Internetwork using Re-feedback” SIGCOMM (2005) • Receiver-driven Capabilities • X Yang et al, “DoS-limiting Internet architecture” SIGCOMM (2005) • tactical approaches • ingress filtering, filter pushback…

  6. symmetric paths • powerful approach • loss of Internet flexibility acknowledged • extended to preserve data in flight during reroutes • stress-testing with authors • big question: would it significantly reduce worm attacks? NB NA R1 ND S1 NC

  7. Secure Internet Indirection Infrastructure Secure i3 • rough analogy: receiver-driven multicast • receiver creates channel (trigger) in infrastructure • senders send to channel • unlike IP multicast, overlay infrastructure (Chord) • highly redundant • essentially, allow more, less efficient routes • choice of routes under receiver control • if some routes used for attack, drop them • efficient route could be norm, then less efficient routes when under attack • inherent weakness for servers: must advertise triggers • so attackers on dropped triggers just re-start • authors offer some mitigation

  8. N2 N1 N4 N3 N5 re-feedback incentive architecture downstreampathcongest-ion, ρi 0 i bulk congestion charging bulk congestion pricing shaper/policer dropper R1 S1 routing traffic eng congestion control

  9. receiver-driven capabilities • yet to fully analyse (only just published) • sent traffic picks up time-bounded tags • tags from each network (router) • and byte permission from destination • collectively termed a capability • routers store tags • subsequent traffic authorised using capability • detail devils • bootstrapping • bounded router state • incremental deployment

  10. Grand Strategy: some questions • if upstream network doesn’t filter/throttle • once attackers identified, what do we do? • continue to add more and more filters at borders? • disconnect their network? • throttle their network? • sue them (under what law – tort, criminal)? • can the network help identify persistent attackers? • unenforceable due to numerous weak legal systems? • pair-wise network agreements, or source identification? • inter-domain charging • congestion-based • would it slowly mitigate persistent attacks? • filter-based • would it encourage push-back? • incremental deployment • new, clean Internet? • gradually clean up the one we’ve got

  11. in summary • multiple answers, defence in depth • pair-wise network agreements AND source identification • complementary approaches • identify attackers (networks) by address • routers filter traffic from identified attacks/attackers • inter-domain charge to congestion-causing networks • police congestion-causing traffic

  12. more info • Bob Briscoe • bob.briscoe@bt.com • http://www.cs.ucl.ac.uk/staff/B.Briscoe/

More Related