Re: Policies: Routing a subset of another ISP's address block
I can say for sure, that we doesn't accept more specific announcements within our PA blocks, nor does we accept traffic with a source within these blocks.
So you might not allow a customer to break up your block, but you haven't said that you wouldn't allow a customer to announce a fragmented block belonging to someone else, supposing this other party does not share your policy.
I don't see the logic behind refusing the customer a request of this sort.
Exploding routing tables, and it makes it impossible to do anti-spoofing filters ...
You're going to have to exempt multihomed downstream customers from your anti spoofing filters anyway, whether they use your space, someone else's or their own. To put it another way, if you have clueful downstreams, you should delegate anti spoofing to them, they will do it closer to the edge where there is no asymetrical routing. -Phil
You're going to have to exempt multihomed downstream customers from your anti spoofing filters anyway, whether they use your space, someone else's or their own.
indeed this seems to be the case. which breaks the schemes for ingress filtering based on forwarding table entries <sigh>.
To put it another way, if you have clueful downstreams, you should delegate anti spoofing to them, they will do it closer to the edge where there is no asymetrical routing.
one of the rare bits of positive feedback here. multi-homed customers do tend to be a bit more clued. so, in this too rare instance, the pain is near some clue to fix it. randy
On Wed, Apr 05, 2000 at 07:10:30PM -0400, Phillip Vandry wrote:
I can say for sure, that we doesn't accept more specific announcements within our PA blocks, nor does we accept traffic with a source within these blocks.
So you might not allow a customer to break up your block, but you haven't said that you wouldn't allow a customer to announce a fragmented block belonging to someone else, supposing this other party does not share your policy.
But they will be unable to reach anything within our network (which is > 50% of the danish Internet).
I don't see the logic behind refusing the customer a request of this sort.
Exploding routing tables, and it makes it impossible to do anti-spoofing filters ...
You're going to have to exempt multihomed downstream customers from your anti spoofing filters anyway, whether they use your space, someone else's or their own. To put it another way, if you have clueful downstreams, you should delegate anti spoofing to them, they will do it closer to the edge where there is no asymetrical routing.
Yes, but this cannot ensure that someone on the other side of the planet, tried to connect to something within our network, with a souce in our blocks - which we cannot accept, as some of our customers (with multiple connections to our network) use the source address for authentication purposes. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
On Fri, Apr 07, 2000 at 08:13:25PM +0200, Jesper Skriver wrote:
On Wed, Apr 05, 2000 at 07:10:30PM -0400, Phillip Vandry wrote:
I can say for sure, that we doesn't accept more specific announcements within our PA blocks, nor does we accept traffic with a source within these blocks.
So you might not allow a customer to break up your block, but you haven't said that you wouldn't allow a customer to announce a fragmented block belonging to someone else, supposing this other party does not share your policy.
But they will be unable to reach anything within our network (which is > 50% of the danish Internet).
Sorry, I misread your mail - if a BGP connected customer announce a fragment of somebody else's block, it's a matter between them. But if they want us to announce such a fragment, we require the accept of the operator "owning" that block. /Jesper -- Jesper Skriver, jesper(at)skriver(dot)dk - CCIE #5456 Work: Network manager @ AS3292 (Tele Danmark DataNetworks) Private: Geek @ AS2109 (A much smaller network ;-) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.
participants (3)
-
Jesper Skriver -
Phillip Vandry -
Randy Bush