Methods for Prevention, Detection and Mitigation of BGP Route Leaks ietf-idr-route-leak-detection-mitigation-06 (Route leak definition: RFC 7908) K. Sriram, D. Montgomery, B. Dickson, K. Patel, and A. Robachevsky IDR Working Group Meeting, IETF-98 March 2018 Acknowledgements: The authors are grateful to many folks in various IETF WGs for commenting, critiquing, and offering very helpful suggestions (see acknowledgements section in the draft.) 1
Route Leak: The Tale of Two Culprits route-leak propagated (P) prefix (P) peer ISP1 ISP2 (AS1) (AS2) prefix (P) route-leak update propagated (P) prefix (P) route-leak (P) update Customer (AS3) • Intra-AS and Inter-AS solutions are necessary. 2
Building Blocks ietf-idr-route-leak-detection-mitigation-06 Secure RLP fields with BGPsec Intra-AS route leak Inter-AS route leak prevention (iBGP detection/mitigation messaging) • Optional transitive • COMMUNITY, or attribute (RLP fields) • Attribute Configure peering relation for each peer (per prefix) OOB communication between operators: Peering relation, ASN, interface IP RLP = Route Leak Protection fields OOB = Out of Band (in Optional transitive attribute) 3
Configuration Process Flow OOB communication Provider Customer Lat. Peer Complex OOB: Prefix sets with different relations Configure 4
Inter-AS Solution: RLP Attribute Optional Transitive Attribute ASN: N Most Recently Added RLP: N ……. ASN: N Least Recently Added RLP: N 5
No Single Point of Failure & Large ISPs’ Ring of Security More robust in partial Customer Major ISP deployment cone (AS7, AS8, AS9 not upgraded) Small ISP / Customer AS4 Customer Customer AS3 cone cone AS5 AS15 RLP(5) = 1 p AS1 AS2 Leak RLP(1) = 1 Stopped Leak at AS2 AS7 AS8 Leak AS9 Customer cone Customer 6 cone
Building Blocks (with BGP Role negotiation) Secure RLP fields with BGPsec Intra-AS route leak Inter-AS route leak prevention (iBGP detection/mitigation messaging) • Optional transitive • COMMUNITY, or attribute • Attribute Configure peering relation for each peer (per prefix) BGP OPEN / BGP Role Capability negotiations – re- confirming the role stated in OOB communication OOB communication between operators: Peering relation, ASN, interface IP ymbk-idr-bgp-open-policy 7
Configuration Process Flow (with BGP Role negotiation) OOB communication Provider Customer Lat. Peer Complex OOB: Prefix sets with different Configure relations BGP Role Capability negotiations (re-confirming the role stated in OOB communication) Neighbor does Mismatch Configuration Re-confirmed not send Role Actions? Set RLP per ISP’s own knowledge? 8
Merging of the Efforts Option A: Two drafts that complement each other • Separate draft exclusively dealing with BGP Open Policy / Role capability Has other applications (e.g. draft-ymbk-idr-isp-border) Keyur and Sriram have offered good feedback and very happy to continue working with the authors • ietf-idr-route-leak-detection-mitigation describes the other building blocks (intra-AS, inter-AS) Captures nicely the distilled/refined ideas that reflect five years of WG efforts in SIDR, GROW, and IDR Option B: Merge BGP Open Policy / Role capability into ietf-idr-route-leak-detection-mitigation (sort out authorship issues amicably) 9
Recommend
More recommend
