Re: [doable?] peer filtering (was Re: Trusting BGP sessions)
No I'm not suggesting basing it on what a provider is currently advertising. But rather on what the provider has registered and is authorized to announce. The set of authorized routes may be the same or a superset of what the routes the provider is currently announcing. If you want asymetric routes, you can register and authorize traffic via either route; and then dynamically announce which route you want to use moment to moment. On Wed, 15 November 2000, "Bora Akyol" wrote:
If I understand you correctly, you want to filter inbound traffic from a service provider to another based on what that service provider is advertising and based on the decision process that we run.
How do you suggest we handle asymmetric routes?
Bora
----- Original Message ----- From: "Sean Donelan" <sean@donelan.com> To: <heas@shrubbery.net> Cc: <nanog@merit.edu> Sent: Wednesday, November 15, 2000 2:05 PM Subject: Re: [doable?] peer filtering (was Re: Trusting BGP sessions)
On Wed, 15 November 2000, john heasley wrote:
great, that must be why these problems dont occur. which solution are you using? i'm not flinging s*!@ over the fence; i'm truely interested.
If the problem is truely no router vendor make a router capable of holding a fully filtered route table we need to tell the router vendors this is a mandatory requirement or we won't buy their routers. Remember, once upon a time when no router could handle more than 30,000 routes or 64,000 routes. Once the router vendors were told what was needed, they built a box to meet that need.
It is not a given that no router will never support filtering a full tier-1 ISP's route table. Its just no one has made it a requirement.
Lets make it a requirement of the router vendors.
Hi, On Wed, Nov 15, 2000 at 02:50:37PM -0800, Sean Donelan wrote:
No I'm not suggesting basing it on what a provider is currently advertising. But rather on what the provider has registered and is authorized to announce. The set of authorized routes may be the same or a superset of what the routes the provider is currently announcing.
If you want asymetric routes, you can register and authorize traffic via either route; and then dynamically announce which route you want to use moment to moment.
How about not storing filter-information in configuration space, rather do dynamic lookup via directory-lookups (that could driven by RPSL via LDAP ) ? Since a BGP-update is done just near-real-time a split-second lookup would certainly not delay the routing-table calculation, but rather provide a centralized method to maintain policy information. These things change anyway so fast that accuracy is difficult on daily update basis. It would also allow very fast elimination of networks that do harmful things (spam, DOS, etc..) Kurt Kayser -- noris network AG / Kilianstrasse 142 \ 90425 Nuernberg Tel. (0911) 9352-0 / Fax (0911) 9352-100 \ info@noris.net
On Thu, 16 Nov 2000, Kurt Kayser wrote:
Hi,
On Wed, Nov 15, 2000 at 02:50:37PM -0800, Sean Donelan wrote:
No I'm not suggesting basing it on what a provider is currently advertising. But rather on what the provider has registered and is authorized to announce. The set of authorized routes may be the same or a superset of what the routes the provider is currently announcing.
If you want asymetric routes, you can register and authorize traffic via either route; and then dynamically announce which route you want to use moment to moment.
How about not storing filter-information in configuration space, rather do dynamic lookup via directory-lookups (that could driven by RPSL via LDAP ) ? Since a BGP-update is done just near-real-time a split-second lookup would certainly not delay the routing-table calculation, but rather provide a centralized method to maintain policy information.
These things change anyway so fast that accuracy is difficult on daily update basis. It would also allow very fast elimination of networks that do harmful things (spam, DOS, etc..)
Kurt Kayser -- noris network AG / Kilianstrasse 142 \ 90425 Nuernberg Tel. (0911) 9352-0 / Fax (0911) 9352-100 \ info@noris.net
How do you suppose the router is going to be able to get to the database server? It has to have a route to the database server and until it does, it can not even verify that it should accept that route. --- John Fraizer EnterZone, Inc
John, On Thu, Nov 16, 2000 at 04:38:33AM -0500, John Fraizer wrote:
How do you suppose the router is going to be able to get to the database server? It has to have a route to the database server and until it does, it can not even verify that it should accept that route.
--- John Fraizer EnterZone, Inc
In case of a cold-start, I would give the box a base config that tells how to build the IGP and iBGP topology. Then a DB-server within the ISPs network should be within reach. There is more information stored how to connect the external world (peers, upstreams) and basic filters (martians, own blocks, prefix length) After that the database links into the IRR-System to get 'live' external information that passes local policy adjustments (communities, prepends, etc.) and new updates always get through the database-system. In this case you also have a kind of BGP-trail (basically http://abcoude.ripe.net/ris/risalpha.cgi) that can be used in many ways after something went wrong with routing. I believe not many networks keep what has been happening in their routing tables. Or even are able to reconstruct a specific situation that lead to some erradic situation. Kurt -- noris network AG / Kilianstrasse 142 \ 90425 Nuernberg Tel. (0911) 9352-0 / Fax (0911) 9352-100 \ info@noris.net
That sounds doable. It might be painful to implement though because there are loads of nets that don't update to any IRR. I like the RIS Query site. Slick. --- John Fraizer EnterZone, Inc On Thu, 16 Nov 2000, Kurt Kayser wrote:
John,
On Thu, Nov 16, 2000 at 04:38:33AM -0500, John Fraizer wrote:
How do you suppose the router is going to be able to get to the database server? It has to have a route to the database server and until it does, it can not even verify that it should accept that route.
--- John Fraizer EnterZone, Inc
In case of a cold-start, I would give the box a base config that tells how to build the IGP and iBGP topology. Then a DB-server within the ISPs network should be within reach. There is more information stored how to connect the external world (peers, upstreams) and basic filters (martians, own blocks, prefix length)
After that the database links into the IRR-System to get 'live' external information that passes local policy adjustments (communities, prepends, etc.) and new updates always get through the database-system. In this case you also have a kind of BGP-trail (basically http://abcoude.ripe.net/ris/risalpha.cgi) that can be used in many ways after something went wrong with routing.
I believe not many networks keep what has been happening in their routing tables. Or even are able to reconstruct a specific situation that lead to some erradic situation.
Kurt -- noris network AG / Kilianstrasse 142 \ 90425 Nuernberg Tel. (0911) 9352-0 / Fax (0911) 9352-100 \ info@noris.net
participants (3)
-
John Fraizer -
Kurt Kayser -
Sean Donelan