On Mon, Jun 17, 2019 at 11:21 AM Sriram, Kotikalapudi (Fed) < [email protected]> wrote:
> Nick, > > Thank you for your thoughts on this. > > This work has been in GROW / IDR since 2014. > Initially in GROW where we published a route leak problem definition RFC: > https://tools.ietf.org/html/rfc7908 > > The work then moved to IDR for the route leak solution based on BGP > Attribute. > It was moved back to GROW lately because IDR Chairs and others (authors + > Ruediger) > felt that a solution based on Community would be deployable a lot faster > -- in months as opposed to years. > > First, if you care you may offer your thoughts on Attribute vs. Community. > My own (bpd) view on the attribute vs community is: - This is a canonical perfect vs good comparison - Deployment experience on Community would allow operators to reap the benefits with no required code changes - Follow-up work on a corresponding Attribute would be preferred - IFF/when sufficient vendor implementation and operator deployment of the Attribute exists, the Community can (should) be deprecated - Long-term, Attribute has better attributes - Mandatory propagation even if a given AS does not "speak" the Attribute - Distinct prefix attribute (vs overloading Community) - Avoid hitting limits within Community attribute (max number) - Orthogonality enables better/easier tool integration (automation stuff) Second, I would appreciate if you can offer concrete examples of the > scenarios > that you mention -- some examples where one saw those types of leaks occur > in the real world. > As for the basic principles on which the solution is based, we essentially > decided that we could readily address route-leak Types 1 through 4 of RFC > 7908. > That is what the draft does. I don't think addressing route-leak Types 1 > through 4 > is narrow pigeon holing. As illustrated in RFC 7908, most real-world route > leak > incidents seem to fall in the six types identified in the RFC. > The RFC lists many observed route-leak incidents and categorizes them. > (Note: Types 5 and 6 are addressed by other solutions such as route > filtering, RPKI, max prefix, etc.) > The subnet leak that you mention (AS path intact or AS path removed) was > discussed in GROW > and it was decided that was NOT a route leak type -- OTOH subnet leak is > only addressable with ROAs > and/or BGPsec path validation. GROW WG decided not to include it in RFC > 7908 > (although it was included in earlier versions of the definition draft). > > More specifically (pun intended): Type 6 (leaks of more-specifics) are technically possible to handle, with very minor modifications to an AS's advertisement policy for those prefixes. (The assumption here is the more-specifics are advertised to an upstream ISP for traffic-engineering purposes, but are not intended for distribution beyond that ISP.) The ISP's BGP session can be, for the purposes of ONLY THOSE prefixes, as a "peer-only" connection, and the appropriate community ( RPL:DO=MY_ASN:NULL). The ISP would need to have a policy of allowing prefixes from customers whose community set included RLP:CUST_ASN:NULL, but not any other values of RLP:*:*. This would allow the ISP to send the more-specifics only to the ISPs customers, but would block transmission of the more-specifics to peers or transit providers, assuming the ISP implements this draft. Further away than the upstream ISP, any third party receiving these marked prefixes from a customer or peer would detect them as a leak. A third party might be able to detect (and block) reception of leaked prefixes from its own upstream ISP, depending on a variety of factors. The main take-aways are: - The party implementing this on the receive-side (blocking prefixes based on the received community) benefits the receiving party (since it blocks leaks). - The party implementing this on the send-side (towards customers) benefits if/when any of their customers leak (or customers' customers, etc.), and the leak recipient (or upstream thereof) blocks the leak - The marking is a trivial policy: mark all outbound prefixes sent to customers and peers, with a single global (for your ASN) community - You do not mark prefixes sent to transit providers (upstream ISPs), or to "special" neighbors. - The presumption is that any marking that exists is preserved, allowing for treatment of a "cluster" of "special neighbors" as a single entity. - A marked prefix will generally come from an upstream ISP or a peer. - If any "member" of this "cluster" of "special neighbors" announces a marked prefix to an upstream ISP or a peer, that would be detected by the recipient as a leak -- and legitimately so. - No extra logic is required for these "special" connections, beyond whatever is currently in place - The detection policy is equally trivial: don't accept marked prefixes from customers (with the caveat regarding the customer adding RPL:CUST_ASN:NULL, so the prefix can only be sent to your customers), or peers (except required RPL:PEER_ASN:NULL). - This is incrementally deployable, and those deploying gain immediate benefit (when deployed_count >1, obviously) - This is extremely compatible with automated build scripts and the like: a single outbound policy toward customers and peers; a simple two-entry inbound policy towards customers and peers tied to the neighbor ASN. It might be helpful to white-board this, if anyone is interested, we can do some kind of side meeting in Montreal. (We authors have done extensive analysis, too much to present on-list, IMHO.) Brian > ________________________________________ > From: GROW <[email protected]> on behalf of Nick Hilliard < > [email protected]> > Sent: Saturday, June 15, 2019 6:22 AM > To: Brian Dickson > Cc: [email protected] > Subject: Re: [GROW] call for feedback on > draft-ietf-grow-route-leak-detection-mitigation > > Brian Dickson wrote on 15/06/2019 00:42: > > Please take a look and, if you think this is an important problem to fix > > (route leaks), add your voice here. > > there are two things here: route leaks (important), and the proposal in > draft-ietf-grow-route-leak-detection-mitigation. We can probably all > agree that route leaks are a persistent threat. > > What concerns me about this draft is that it takes an over-simplified > view of real-life networks and there's not a small amount of implied > pigeon-holing going on. The difficult with the draft is that many > networks don't fall into these neatly defined categories. There are > back-doors, partial transit configs, PNI arrangements, subnet leaks and > all sorts of weird things out there, none of which are easy to > categorise, but which nevertheless make up an important part of the > routing ecosystem. > > Characterisation of these edge cases is a difficult problem. I'm not > convinced this can be done adequately without an expressive grammar > (note: not rpsl). I'm also not convinced that the approach taken in > draft-ietf-grow-route-leak-detection-mitigation is generic enough to be > worth deploying. > > Nick >
_______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
