Re: soBGP deployment

[Jeroen Massar <jeroen () unfix org>]

On Wed, 2005-05-25 at 16:24 -0700, Tony Li wrote:

> For example, an operator can begin by enabling authentication on a BGP
> speaker that is wholly outside of the traffic path.  Instability of this
> one speaker would have no effect on production traffic.  Authentication
> alarms generated by this speaker could be set up to do nothing more than
> send a syslog message to operations personnel who would need to
> intervene manually to actually change production BGP path selection.
> For testing authentication, a host behind this speaker could monitor
> reachability.

In short, you mean setting up, eg a Quagga box behind the existing core
infra that one has, feeding it a full feed, which matches the current
best paths one has in it's RIB and verifying the paths.

This is somewhat similar how the detection of GRH (*1) works already for
IPv6 tables, that is it nightly fetches the route6 objects from various
registries(*1) and checks if a AS is registered to be allowed to
announce a certain prefix, if not it marks it in the looking glass as
being a bad route which is supposed to be routed from the registered AS.

Now, if BGP would have some signature over the the path, one could
verify this in the same method and have the exact thing happening above.
GRH sends out mailings every day, though one could of course implement
the above in realtime. If one would mirror the full table, one could
even analyze the alternative paths to see if those are valid.

What you mention, does indeed not break current operations and would be
quite transparent.

Greets,
 Jeroen

*1 = http://www.sixxs.net/tools/grh/
*2 = http://www.sixxs.net/tools/grh/how/

Attachment: signature.asc
Description: This is a digitally signed message part