Re: [GROW] [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route Propagation Behavior Without Policies) to Proposed Standard

["Jakob Heitz (jheitz)" <[e-mail]>]

My program to create filters does not care about customer/peer/transit.
It does not care about tier-1 or tier-2.
It looks at your BGP table and finds your largest neighbors,
sized by the number of routes it sends you.
Then for each of those neighbors, it examines as-paths in all other routes
to find all other ASNs between you and adjacent to that neigbor.
Then it builds an as-path filter that allows only those ASNs as upstreams
from that neighbor.

For example, AS-2914 and AS-209 are both tier-1 ISPs.
AS-2914 receives some routes from AS-17676 that passed through AS-209. (routeviews)
The simple rule "no peer routes from customers" would drop those routes.

All the filters are collected together into a single route-policy or route-map.
Then you apply the policy to all your ebgp sessions.

Here is an example of how to apply the policy:
route-policy your_neighbor_in
  if apply allow_as then
    pass
  else
    set community (65000:666)
    set local-preference 0
  endif
end-policy

You may list all the routes that were disallowed like this:
show bgp community 65000:666


Thanks,
Jakob.


> -----Original Message-----
> From: Richard A Steenbergen [mailto:[e-mail]]
> Sent: Saturday, May 06, 2017 1:17 PM
> To: Jakob Heitz (jheitz) <[e-mail]>
> Cc: Robert Raszuk <[e-mail]>; [e-mail]
> Subject: Re: [GROW] [Idr] IETF LC for IDR-ish document <draft-ietf-grow-bgp-reject-05.txt> (Default EBGP Route
> Propagation Behavior Without Policies) to Proposed Standard
> 
> On Fri, May 05, 2017 at 10:51:41PM +0000, Jakob Heitz (jheitz) wrote:
> > Thanks Robert.
> >
> > I did it without using ios-regex or other time consuming string conversion stuff.
> > Still, this method cannot scale to cover every one of several thousand AS neighbors that some ISPs have.
> > IOS cannot handle that many as-path access-lists.
> > I can see that the simple rule of "do not allow peer routes from a customer"
> > doesn't cut it, because some tier-1's have a lot of customers with over 10000 routes each.
> > My filters will certainly cover all the major peers as well as major customers of ISPs.
> > I included a limit on the number of policies to write:
> > so that it will just get the major ones.
> > Also, if a routing table includes leaks, then the resulting policies will
> > continue to allow the leaks.
> > Also, some of the filters may need to add some upstreams that are not in the table of the day.
> > Basically, it is a start that may require a bit of tweaking.
> > I have a better idea of what to commit to the IOS.
> > It will be far more efficient, but I want to gauge interest first.
> 
> I built something very similar using Juniper commit scripts many years
> ago, and used it at GTT, a very large Tier 1 network.
> 
> It was fairly straight forward, all you had to do was feed it an ASN
> list of your "tier 1" peers (ASNs which should never be heard behind
> anyone other than ^asn.*), and "tier 2" peers (ASNs which can be heard
> as ^asn.* as well as ^(tier1|list|here) asn.*). It would then
> automatically create custom as-path filters for each BGP peer, based on
> the individual session and where it found the neighbor asn on the list.
> For customer sessions, it was also easy to incorporate simple as-path
> filters for the most common leaks, e.g. you should never here anything
> on the tier 1 list from any of your customers under any circumstances.
> I'd be happy to release the code if anyone is interested.
> 
> For a well-connected well-peered network, this was absurdly effective at
> preventing huge numbers of the most common routing leaks. In my
> experience, the VAST majority of leaks are caused by simple human typos,
> and/or mistakes caused by things like the (IMHO incredibly poor) default
> behavior to announce everything on a new BGP session with no configured
> policy.
> 
> That said, I have great difficulty imagining how you would successfully
> create any kind of 100% automated as-path filter system based on
> observed behavior in the routing table, based on my many years of
> experience running some of the largest Tier 1 networks on the planet.
> It's simply not practical in the real world. I WOULD highly encourage
> you to pursue building better as-path filtering tools similar to the
> scenario I described above though. It would be great if you could easily
> feed your router some as-path-lists, and configure your policy to build
> the filters described above without needing a script to create a per-as
> as-path filter expression. I wouldn't recommend trying to turn it on
> automatically, but you'd probably help a large number of ISPs by giving
> them the ability to build these filters without requiring complex
> scripting, of offline config automation tooling.
> 
> But the one thing I think every vendor COULD do to vastly improve the
> accidental route leak situation is precisely what this draft suggests,
> default to reject for EBGP neighbors with no configured policy. That's
> one of the very first things I've baked into every one of my configs, a
> default DENY-ALL policy for all BGP neighbors (which was easy to do at
> the top level "protocols bgp" with Juniper), and I have no doubt that it
> saved ME from making countless mistakes over the years. To err is human
> (just look at our routing protocols :P), and a default policy of
> "announce everything, and hope the other side is doing perfect
> filtering" simply has no place in THE global routing protocol.
> 
> I certainly understand the need for caution when making such a major
> change in default behaviors, and would absolutely suggest a multi-year
> phased approach with large numbers of warnings for neighbors which lack
> configured policies leading up to the default knob switch. I'd also
> suggest that every router vendor start by adding a simple knob which can
> change the default behavior globally, and then encourage everyone to
> turn that on as a best practice starting immediately. But I'd also argue
> that none of this should get in the way of trying. Yes it will take many
> many years, and it won't solve anything, but the sooner we start the
> sooner the change can happen.
> 
> I'd also argue that this change will be vastly more beneficial than many
> of the other more dubious efforts we've collectively wasted FAR more
> time and energy, such as RPKI. Accidental origination almost NEVER
> happens in the real world, but accidental leaks due to default allow
> policies happen every day. That makes this one of the most practical and
> sensible changes I've seen proposed to BGP in a long, long time.
> 
> --
> Richard A Steenbergen <[e-mail]>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)