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

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 5 May 2017 22:09:20 +0000

Even if violating router-os's are updated, leaks will continue for a long time.
I hope I can help on the filtering side. No RFC or vendor code change required.

I wrote an app in C that takes the output of "show bgp" and creates
a set of route-policies that will prevent the leaks.
It looks at the as-paths, finds your neighbors and then all their upstreams.
Then it writes as-path policies to allow only those upstreams for your neighbors.
You then use the policy in your neighbor inbound policies to either drop
or set a low localpref. There is a way to show the routes that are disallowed.
Sorry, it only works with Cisco.
The source is free for anyone to do whatever they want.
Other vendors can adapt it at will.

Compile it at a Linux command line; "cc showbgp2policy.c".
Sorry about the C, but python is not my mother tongue.
Start with num_policies of 30 and see how it looks.

Thanks,
Jakob.

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 6 May 2017 00:27:08 +0200

Hi Jakob,

This is really great and exactly what I had in mind when proposed
auto-policy based on AS_PATH check. Can you commit it to IOS so it is
build-in with a knob to use ?

Cheers,
R.

On Sat, May 6, 2017 at 12:09 AM, Jakob Heitz (jheitz) <[email-masked]>
wrote:

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Fri, 5 May 2017 22:51:41 +0000

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.

Jakob.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Friday, May 05, 2017 3:27 PM
To: Jakob Heitz (jheitz) <[email-masked]>
Cc: [email-masked]
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

Hi Jakob,

This is really great and exactly what I had in mind when proposed auto-policy based on AS_PATH check. Can you commit it to IOS so it is build-in with a knob to use ?

Cheers,
R.

On Sat, May 6, 2017 at 12:09 AM, Jakob Heitz (jheitz) <[email-masked]<mailto:[email-masked]>> wrote:
Even if violating router-os's are updated, leaks will continue for a long time.
I hope I can help on the filtering side. No RFC or vendor code change required.

Thanks,
Jakob.

_______________________________________________
GROW mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/grow

---

From: Richard A Steenbergen <[email-masked]>
Date: Sat, 6 May 2017 15:17:20 -0500

> 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 <[email-masked]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 10 May 2017 00:46:17 +0000

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:[email-masked]]
> Sent: Saturday, May 06, 2017 1:17 PM
> Cc: Robert Raszuk <[email-masked]>; [email-masked]
> 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
>