BGP Optimizers (Was: Validating possible BGP MITM attack)

Thu May 17 11:13:52 UTC 2018

Dear Francois,

On Thu, May 17, 2018 at 10:14:19AM +0000, Francois Devienne wrote:
> The examples you mention confirm the issues are mainly due to poorly
> configured networks where routes are leaked out although they
> shouldn’t be. Adequate routers are able to filter out prefixes based
> on attributes like communities, which we set by default.

Question: is your implementation setting NO_EXPORT by default, or some
other communities? Not all BGP "Optimizers" set NO_EXPORT by default...
in that context I am not sure it is fair to say "the network is poorly
configured" - when an "optimizer" doesn't set NO_EXPORT it is the
"optimizer" that is comes with poor defaults.

And there is another challenge: NO_EXPORT does not always work
correctly. Software defects happen, and are unpredictable. All major
routing platforms have seen bugs where for one reason or another
NO_EXPORT does not (or no longer) work correctly. Heavy reliance on
NO_EXPORT can be a weakness in network architecture.

> There actually is a reason for operating BGP optimizers. The BGP
> protocol, while robust and scalable, doesn't know anything about link
> capacity, doesn’t apply performance analytics and can easily drive
> links into saturation, introducing packet loss. Also, it is not aware
> of commercial agreements like CDR, generating costs that could be
> prevented. It also, of course, ignores the performance of available
> paths.  All of the above actually impacts customer traffic and
> business performance.  Since a few years we see our Customers take
> more care of quality and capacity management… and stop relying on BGP
> « blindly ».

You are correct that there is a need (and a market) for BGP optimizers.
BGP is terrible for routing around problematic parts of the topology if
we look at metrics such as latency or packetloss.

In my opinion, what the "optimizer" vendors _should_ have done (years
ago), is go to IETF to the IDR working group and help standardize a safe
and robust way to extend the BGP protocol to allow for better traffic
engineering. Think along the lines what flowspec is for firewalls,
perhaps there should be a "traffic engineering spec (tespec)" for
routers. This should happen in a different Subsequent AFI to avoid the
extremely risky behaviour we now see in the Unicast SAFI.

I have no problem with software that automatically interacts with
routers to manipulate LOCALPREF, there is no issue if software supresses
more-specifics, prepends of the own ASN is no issue either,  but what
_is_ an issue is any software that generates fake routes and distributes
those fake routes in the IPv4/IPv6 Unicast AFI/SAFI on boxes connected
to the BGP DFZ.

To phrase and summarize the isuse, using the terminology you provided:

The "optimized" paths MUST NEVER be distributed in the same AFI/SAFI as
the "natural" paths. Overloading the "natural" AFI/SAFI with fake
generated more-specifics, which only exist for the purpose of outbound
traffic engineering (even with communities) is a very dangerous thing.

Yes, this will be a bit of work, but that is the cost of doing business.

> (I’m a product engineer at Border 6 - Expereo, a BGP optimization
> software company.)

I appreciate your outreach in this public forum and the disclosure.

Kind regards,

Job