ION Belfast - Securing BGP - David Freedman
•
0 likes•1,300 views
Presentation at ION Belfast: "Securing BGP" by David Freedman. Why do so many network operators fail to put basic technologies into practice when it comes to securing BGP? In this session, we’ll examine route filtering and BGP session security – the practical basics of securing BGP.
More Related Content
What's hot
What's hot (20)
Similar to ION Belfast - Securing BGP - David Freedman
Similar to ION Belfast - Securing BGP - David Freedman (20)
More from Deploy360 Programme (Internet Society)
More from Deploy360 Programme (Internet Society) (20)
Recently uploaded
Recently uploaded (20)
ION Belfast - Securing BGP - David Freedman
- 1. Securing BGP Why not? David Freedman – Claranet – ION Belfast 2014
- 2. Only two things to talk about • draH-‐ieJ-‐opsec-‐bgp-‐security (BGP security) • CCRSR / MANRS (The “Manifesto”)
- 3. Why session security? • Internet protocol, using BGP, signals in-‐band. • BGP in many cases is a simple TCP session between TCP peers usually you can reach both (modern IXPs excepted). • If I can disrupt session, I can cause you pain. • If I can hijack session, I can cause you more. Peer Peer
- 4. draH-‐ieJ-‐opsec-‐bgp-‐security • An internet draH in the IETF, not a current standard. • Part of the OPSEC working group, “Opera[onal security capabili[es for IP Network Infrastructure”. • Concerning BGP security. • Wrien by vendors and operators, for the use of operators. • Aims to become IETF BCP (Best current prac[se).
- 5. Key topics covered Session Protec[on BGP Security Prefix Filtering Aribute Filtering Flap Control Plane Dampening
- 6. Overlapping work • RIPE Documents (Rou[ng-‐WG). • BCOP Documents (ARIN and now RIPE Region BCOP ini[a[ve). • Industry fora presenta[ons (NANOG etc..) • CCRSR / MANRS • Vendor recommenda[ons. Much consulta[on undertaken to avoid conflic[ng informa[on.
- 7. Control Plane • Recommenda[on to use iACLs and CoPP. • Pointer to RFC6192 “Protec[ng the Router Control Plane”. • The above RFC published in 2011 and is en[rely vendor led (Juniper / Cisco). • Worth no[ng, Lack of good CoPP used to be responsible for many operators shueng down their peering ports when there is an ‘event’ on the exchange.
- 8. Session Protec[on • MD5 as minimum, but considered ‘weak’. • TCP-‐AO (RFC5925) and IPSEC preferred. • TTL Security (GTSM) also preferred. • Block your own address space on ingress, don’t leave this (spoofing) vector open.
- 9. Prefix Filtering • Filter Bogons – Special addresses, now a published registry for these • hp://www.iana.org/assignments/iana-‐ipv4-‐special-‐registry/iana-‐ipv4-‐special-‐registry.xml • hp://www.iana.org/assignments/iana-‐ipv6-‐special-‐registry/iana-‐ipv6-‐special-‐registry.xml – Not allocated (important s[ll in IPv6 terms) – The above from your friendly Bogon feed provider (SpaceNet / Team Cymru). • Set a sensible MaxPrefix (on peers and upstreams). • Filter ‘too specific’ (e.g ge 25/49). • Filter your own prefixes. • Filter the IXP LAN if the IXP wants you to. • Some addi[onal scenarios for your topology (and a discussion about uRPF implica[ons). • Oh, and (for the future), perhaps do some SIDR origin valida[on.
- 10. Flap Dampening • Ini[ally a good thing (RIPE-‐178, 1998). • Then a bad thing (RIPE-‐378, 2006). • Then, a good thing again (RFC7196, 2014). • Now RIPE community agree it may be a good thing with some tweaks (RIPE-‐580, 2013). • Let’s all agree it’s a good thing again, and follow the RFC and RIPE. • Its possible your vendor will do the ‘legwork’.
- 11. Aribute Filtering • AS_PATH filtering – Careful what you send and receive. – Try not to accept your own unless you know what you are doing. • NEXT_HOP filtering – Do you trust en[rely what your peers state? – Be aware of RTBH (Blackholing) though. • COMMUNITIES scrubbing (of your own) – Do you want peers/upstreams to control your rou[ng policy?
- 12. So for this I-‐D, what next? • In last call for BCP as of yesterday. • Open for ‘substan[ve’ comments: – On the OPSEC mailing list • hps://www.ieJ.org/mailman/lis[nfo/opsec – Or directly to the authors • draH-‐ieJ-‐opsec-‐bgp-‐security@tools.ieJ.org • Expect to see vendors take beer light of this and produce more helpful documenta[on/defaults.
- 13. And now for CCRSR / MANRS • Originally “Code of Conduct for Rou[ng Security and Resilience” (CCRSR), but now called “Collec[ve Responsibility and Collabora[on for Rou[ng Resilience and Security” (CRCRRS)! • Originally a group of large operators got together and proposed a ‘code’ to follow, to clean up issues with poor filtering , rou[ng and forwarding hygiene. • Now using ISOC as a neutral plaJorm (convener and promoter).
- 14. MANRS • “Mutually Agreed Norms for Rou[ng Security”, our document, which explains our objec[ves: • Raise awareness and encourage actions by demonstrating commitment of the growing group of supporters • Demonstrate industry ability to address complex issues • Clear and tangible message: “We do at least this and expect you to do the same”
- 15. MANRS • Really it translates into three ac[ons: 1. Prevent propaga[on of incorrect rou[ng informa[on. 2. Prevent egress of traffic with spoofed source IP addresses. 3. Facilitate global opera[onal communica[on and coordina[on between the network operators.
- 17. What next? • We had extensive feedback collec[on through industry mailing lists. • Now moving to promote the material, and operators to ‘sign up’ to the principles in the document. • Hopefully minimal effort vs. gain, posi[ve public rela[ons exercise for your network as well.
- 18. Ques[ons