Re: Securing the BGP or controlling it?

[Danny McPherson <danny () tcb net>]

On May 10, 2010, at 10:48 AM, Nick Hilliard wrote:

> There are a lot of problems associated with using IRRDB filters for inbound
> prefix filtering.

We used them over 15 years ago near ubiquitously and stopped 
mostly because:

1) there was nothing akin to route refresh so you had to bounce 
best routes or reset sessions to trigger readvertisement after
policy updates.  This made unscheduled a pain and required some
turning of the steam valves.

2) traditional ACLs were used for routing policy specification and 
weren't incrementally updatable, which was a huge pita.

3) IRRs were insecure to update, no one ever deletes anything from
IRRs, and some folks even proxy register IRR objects based on BGP
routing table entries.

4) customers complained they had to maintain them (ohh, wait, we
told them if they wanted to be routed they had no choice)

Regarding 1, we have route refresh and inherent soft-reconfig
today.  Regarding 2, pretty much all implementations support this
today (although it will be a pita to maintain near exact prefix 
list and ACL entries for a customer down the road when used for
both routing policies and ingress anti-spoofing).  Regarding 3, 
RPKI should help here quite a bit, either used directly, or 
enabling IRR object population - the RIRs that run IRRs and 
other other folks are helping with secure update mechanisms as
well.  Regarding 4 - they didn't scream as loud about the policy 
as they did when things broke because of the absence of it, that
I know firsthand.
 
> - some clients announce lots of prefixes.  This can make inbound prefix
> filtering difficult in some situations.
>
> pixiedust:/home/nick> grep '>' pakistani-telecom.bgpdump.txt | wc -l
>     967

Yes, this needs to be automated, clearly.

> - there are some endemic data reliability problems with the IRRDBs,
> exacerbated by the fact that on most of the widely-used IRRDBs, there is no
> link between the RIR and the IRRDB, which means that anyone can register
> any address space.  whois.ripe.net doesn't allow this, but lots of other
> IRRDBs do.

See 3 above.

> - the ripe whois server software does not support server-side as-set
> expansion.  This is a really serious problem if you're expanding large ASNs.

Do it yourself for now and file a feature request..

> - there is very little client software.  At least irrtoolset compiles these
> days, but its front-end is very primitive.  rpsltool provides some really
> nice templating functionality, but doesn't implement large sections of the
> rpsl standards.


Agreed, we need to do work here.

-danny