North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: [doable?] peer filtering (was Re: Trusting BGP sessions)

  • From: john heasley
  • Date: Mon Nov 20 22:21:01 2000

On Mon, Nov 20, 2000 at 01:55:41PM -0500, Howard C. Berkowitz darkened my spool with the following:
> At 11:24 AM -0800 11/15/2000, john heasley wrote:
> >i think all agree that filtering large/teir 1 peers (let's assume teir 1 is
> >defined as a peer who sends a large number of routes, ie: ignore the
> >business BS) the way customers are/should be filtered (by exact match prefix)
> >is impossible with the hardware (and/or implementations) available today.
> Are we truly talking about full route filtering alone as adequate at 

route filtering (or limiting the number of prefixes) is one possible
solution (even if only a temporary stepping-stone) to limit the
effects of
	- oops, isp X just redistributed bgp into rip into bgp
	- leaking transit AS A's routes to transit AS B (an the like)

definitely not a complete solution.

> this level, or is there a requirement for reverse path verification 
> on the traffic between large peers?  Or can it be assumed that RPF 
> and other traffic filtering is adequately handled at the customer to 
> provider edge?

rpf verification does not solve the above.  it is an excellent solution
for limiting spoof.  yes, folks should be using this when possible.

> >[here's the beef]
> >it should be possible to have an [daily] automated process (such as we
> >have for building customer prefix filters) which for a set of teir 1
> >peers, queries the IRR for a peer's as-set reducing it to a number of
> >routes * .NN (where NN is say 10%, or graduated or whatever - allowing
> >for some flux between runs of the collector) and applies this number
> >as the maximum-prefix for that peer.
> >
> >the only drawback i can think of is that if the advertised prefixes
> >from a peer ligitimately exceeds the estimation (eg: add a customer
> >advertising a large number routes) the peering would have to be reset,
> >the peer would have to soft-clear outbound, or see
> >draft-ramachandra-bgp-restart-04.
> Sounds as if there might be a need for an authenticated "RPSL alert" 
> between large providers, signaling that there is a significant 
> increase in the number of expected prefixes.  For that matter, unless 

or folks can plan ahead to meet the time frame of daily collections.
but, if .NN is chosen wisely, the daily average gain can be accounted
for.  no?  can tony's data help derive .NN?

but, for the most part, unless ISP X sees registration as an advantage
to _them_, they're just going to sit on their hands.  who is registering?
abovenet/mfn?  exodus?  i know verio does.  if i recall correctly, its
a requirement for LINX membership, or was that just for autnums.

> I've missed it, there's no RPSL construct for maximum prefixes.

i dont believe there is, but the number of registered prefixes can be
easily counted.  expand their as-set recursively (!ias-foo,1 - i think
that's right) and expand each AS to routes (!gasNNNN); count the result.

> >this doesnt protect one from prefix hijacking, but it does reduce the
> >affects of redistribution accidents and the like and is doable.