Re: [GROW] call for feedback on draft-ietf-grow-route-leak-detection-mitigation

[Brian Dickson <[e-mail]>]

On Mon, Jun 17, 2019 at 11:21 AM Sriram, Kotikalapudi (Fed) <
[e-mail]> 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 <[e-mail]> on behalf of Nick Hilliard <
> [e-mail]>
> Sent: Saturday, June 15, 2019 6:22 AM
> To: Brian Dickson
> Cc: [e-mail]
> 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
>