|
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)
At 11:24 AM -0800 11/15/2000, john heasley wrote: Are we truly talking about full route filtering alone as adequate at 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?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. 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 I've missed it, there's no RPSL construct for maximum prefixes.[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. this doesnt protect one from prefix hijacking, but it does reduce the affects of redistribution accidents and the like and is doable.
|