
A Simple BGP: BGP protocol fixed from route leaks - hkr_mag
https://radar.qrator.net/tools/simple-bgp
======
namecast
Neat idea!

Some technical details from clicking through to the github repo for their fork
of BIRD, detailing the config and protocol changes you'd need to make for
interoperability:

Change in BGP Configuration: In each BGP protocol section you must set a role
option. Currently, there are 4 possible values for this option: 1) "provider"
\- neighbor is your upstream provider; 2) "customer" \- neighbor is your
customer; 3) "peer" \- neighbor is your peer; 4) "internal" \- neighbor is
part of your AS or company (in case of multiple AS). Without setting a role in
BGP protocol section you will receive error message from config parser. Also
you could set strict_mode option in BGP protocol section. In this scenario BGP
session with your neighbor will be established only if your neighbor also
support Roles and corresponding Role is correct.

BGP Protocol modification: There are two main changes in BGP protocol
behaviour: 1\. BGP Update modification: to routes that were learned from
upstreams or peers add special non-transitive attribute “Local Announce” (BGP
Path attribute code 19). On links with upstreams and peers filter out routes
with determined attribute; 2\. BGP Open modification: to OPEN messages add new
capability option "Role" (Capability code 38), in which broadcast value of
Role configuration option. Establish connection only if speaker and its
neighbor have appropriate pair of Roles: (provider, customer), (customer,
provider), (peer, peer), (internal, internal).

------
mattzito
Shouldn't this be something that's proposed and implemented by the IETF, since
BGP is an IETF standard?

[http://datatracker.ietf.org/wg/idr/charter/](http://datatracker.ietf.org/wg/idr/charter/)

~~~
wmf
Invention and prototyping come before IETF submission. But some people think
the IETF process is kind of broken, especially when it comes to open source.

~~~
112233
I don't know what kind of broken you are reffering to, but it's painful to see
what "they" (the idr wg) are doing with BGP. Most RFC contain something like:
"since BGP is such a widely used and stable protocol, let's add more stuff to
it!" And the go on changing semantic of existing encodings in a way that
forces unimaginably hairy hack unto any reasonable existing implementation
(see flowspec, see multiprotocol, see add-path, ...)

I'd rather have tens of tiny protocols running on network, that one such BGP
bug-carrier.

------
melanor9
Hi guys,

I am one of the guys responsible for this development. We do mean to (at
least) try to do draft with IETF. We do realize that IETF process might feel
funny and painful, but running the bgp the way it is even more painful.

Sort of trying to scratch our own itch..... Wish us some luck, we will need it
in quantities.

