A Simple BGP: BGP protocol fixed from route leaks | Hacker News Reader

A Simple BGP: BGP protocol fixed from route leaks

radar.qrator.net

30 pointshkr_mag5 comments

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).

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/

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.

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.

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.

Reply on news.ycombinator.com