Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route? -----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, March 11, 2003 11:22 AM To: Stephen J. Wilcox Cc: nanog@merit.edu Subject: Re: 69/8...this sucks
On Mon, 10 Mar 2003, Owen DeLong wrote:
It seems to me that it would be relatively simple to solve this problem by doing the following:
1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE.
Why not just one or private/reserved?
Because I think there is value in each RIR having their own AS to peer EBGP with the other RIR's. I have no problem with this comming from reserved ASN space (that would be up to ICANN where they pull it from). As to private, it would have two problems. One, it would violate the RFC for private ASNs, and, two, it would likely conflict with existing internal uses of private ASNs at some carriers.
2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions:
A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to <RIR>-BOGON.
B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP.
C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers.
Of course, configure it wrong and you would end up sending all the junk that you would have null routed to your RIR. Sounds messy.
I think there are ways for the RIR to protect themselves from this.
Whats more I can see potential whenever we start creating these kind of self propagating blackholes for hackers to introduce genuine address blocks to create a DDoS.
Only if the hacker manages to own one or more of the RIR routers providing the feed. Remember, they will be configured not to listen to _ANY_ advertisement from any routers other than the other RIR routers that are known to provide equivalant service for the other RIRs. As such, assuming the RIRs run the routers with reasonable security precautions, I don't see this as being any more of a DDoS risk than any large backbone provider you can name today.
3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers.
How many ebgp sessions do the RIRs need to maintain?? A lot.. and the maintenance would be a nightmare. Dont think this will work purely because of that overhead you create!!
Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't be full-table sessions. They'd be send-only with a small number of prefixes representing the bogon space. Also, it is possible to configure most routers to peer with "all comers" and assign the ones that don't have a specific configuration to a default peer group. That peer group would be configured to advertise-only the bogon list and accept nothing. With that configuration, the maintenance is near nil. Owen
Steve
Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date.
There are other ways that dont use BGP peering to create lists that are more suitable
Steve
On Tue, 11 Mar 2003, Ejay Hire wrote:
Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route?
Come on...clearly you haven't been paying attention. You need LDAP filters. LDAP filters and a South Vietnamese revolution against the IRRs for being fragmented and greedy. And if that doesn't poison your inverse arp, then multiplex a private bogon server with a centralized host scanner-based DNSBL. Don't forget the trailing dot! And don't forget to invert the subnet mask! Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
On Tue, 11 Mar 2003, Ejay Hire wrote:
Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route?
Come on...clearly you haven't been paying attention.
You need LDAP filters. LDAP filters and a South Vietnamese revolution against the IRRs for being fragmented and greedy.
Careful. We are watching and are prepared to ruthlessly squash any attempted rebellion.
And if that doesn't poison your inverse arp, then multiplex a private bogon server with a centralized host scanner-based DNSBL. Don't forget the trailing dot! And don't forget to invert the subnet mask!
Hey, I've already thought of all that and captured it in an XML schema (with ASN.1 encoding)! I will be presenting an Internet Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. Seriously... As has been suggested, I think we need to do a better job of identifying the population and type of devices that are filtering these prefixes. Are they really predominately BGP speaking routers, or largely some mishmash of non-BGP speaking firewalls/proxies/NAT's? If it's the former, then a BGP based solution has some merit. If the latter, I think it unreasonable to expect these firewalls to speak BGP. What's needed is a canonical represention of the bogon list and some tools to generate the filter list in the appropriate config format for a number target devices. There's already a canonical list maintained by Rob Thomas in the RADB (see fltr-martian, fltr-unallocated, and fltr-bogons). I've suggested to Rob that he may want to include a PGP signature in a remarks section of the object to provide a greater level of confidence (hopefully with a key that's escrowed somehow -- god forbid anything should happen to Rob). I should also note that some of the RIR's have indicated they will be providing more precise information on their unallocated space. As far as tools go, while IRRToolSet has extensive support for RPSL, it may be too complex for a novice Net admin. Perhaps some simple Perl scripts to generate filter configs from RPSL filter objects would be useful? Larry Blunk Merit
I've never posted to the list, just lurk, for over a year now, but this has to be said. Can we please take this discussion off-list to private conversation. It's gotten worse then spam. I see a nanog message and just start deleting them now. -rd -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Larry J. Blunk Sent: Tuesday, March 11, 2003 1:01 PM To: Andy Dills Cc: Ejay Hire; nanog@merit.edu Subject: Re: 69/8...this sucks
On Tue, 11 Mar 2003, Ejay Hire wrote:
Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route?
Come on...clearly you haven't been paying attention.
You need LDAP filters. LDAP filters and a South Vietnamese revolution against the IRRs for being fragmented and greedy.
Careful. We are watching and are prepared to ruthlessly squash any attempted rebellion.
And if that doesn't poison your inverse arp, then multiplex a private bogon server with a centralized host scanner-based DNSBL. Don't forget
the
trailing dot! And don't forget to invert the subnet mask!
Hey, I've already thought of all that and captured it in an XML schema (with ASN.1 encoding)! I will be presenting an Internet Draft next week at the IETF in the CRISP/RPSEC/GROW/IDR meetings. Seriously... As has been suggested, I think we need to do a better job of identifying the population and type of devices that are filtering these prefixes. Are they really predominately BGP speaking routers, or largely some mishmash of non-BGP speaking firewalls/proxies/NAT's? If it's the former, then a BGP based solution has some merit. If the latter, I think it unreasonable to expect these firewalls to speak BGP. What's needed is a canonical represention of the bogon list and some tools to generate the filter list in the appropriate config format for a number target devices. There's already a canonical list maintained by Rob Thomas in the RADB (see fltr-martian, fltr-unallocated, and fltr-bogons). I've suggested to Rob that he may want to include a PGP signature in a remarks section of the object to provide a greater level of confidence (hopefully with a key that's escrowed somehow -- god forbid anything should happen to Rob). I should also note that some of the RIR's have indicated they will be providing more precise information on their unallocated space. As far as tools go, while IRRToolSet has extensive support for RPSL, it may be too complex for a novice Net admin. Perhaps some simple Perl scripts to generate filter configs from RPSL filter objects would be useful? Larry Blunk Merit
On Tue, 11 Mar 2003, Rick Duff wrote:
I've never posted to the list, just lurk, for over a year now, but this has to be said. Can we please take this discussion off-list to private conversation. It's gotten worse then spam. I see a nanog message and just start deleting them now.
Come on...everybody takes turns being the nanog nazi, but it isn't your turn yet. Two suggestions: Number one, you'll probably find your list reading experience to be far more pleasurable if you filter. If nothing else, filter each mailing list you're on into its own box. It allows you to look at nanog mail only when you want to look at nanog mail. But then you can take it a step further, and plonk threads or individual posters into the bit bucket (whatever the Outlook Express equivalent of /dev/null is). I'm being nice; some would simply shout "man procmail" and stick YOU in their .procmailrc. Number two, don't complain about posts which are essentially complaints themselves (albeit with a sense of humor). My post wasn't just a silly gesture, it was an attempt to point out the ridiculous extremes and insane overlapping the threads have denegerated into, without falling into the "shut up and go away. why I can't ping sublimedirectory.com?" cliche. At the minute, the following concerns and ideas are being tossed about, which all overlap slightly but not totally, resulting in a ridiculous mishmash of ideas that have begun to feed on itself (note that these have all been brought up in different ways, and are not all parts of a single thread): sBGP bogon filtering centralized scanning for the prevention of abuse idealistic segmentation of the net into the "pure" and "impure" lack of reachibility from 69/8 If you step back on some high level, the threads are all about lazy and or nonexistent network administration, and ways to cope with the impact on the net we all have to run. But if you read every post, it has degenerated into an argument over whether or not everything is ready to be a nail for the LDAP hammer and whether or not people actually understand how sBGP is proposed to work. But at the same time, I can't think of a place this stuff would be more relevant. Which is why it's good to filter...so you still be subscribed to the list AND not be annoyed. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session. However, it's primarily intended to solve the non-malicious, but somewhat malignant problem of out-of-date bogon filters by people trying to do the right thing. Owen
Er, guys... How does this fix the problem of a Malicious user advertising a more specific bogon route?
-----Original Message----- From: Owen DeLong [mailto:owen@delong.com] Sent: Tuesday, March 11, 2003 11:22 AM To: Stephen J. Wilcox Cc: nanog@merit.edu Subject: Re: 69/8...this sucks
On Mon, 10 Mar 2003, Owen DeLong wrote:
It seems to me that it would be relatively simple to solve this problem by doing the following:
1. ICANN (or an ICANN designee, such as ARIN) shall issue an ASN range of 20 ASNs to be used as BOGON-ORIGINATE.
Why not just one or private/reserved?
Because I think there is value in each RIR having their own AS to peer EBGP with the other RIR's. I have no problem with this comming from reserved ASN space (that would be up to ICANN where they pull it from). As to private, it would have two problems. One, it would violate the RFC for private ASNs, and, two, it would likely conflict with existing internal uses of private ASNs at some carriers.
2. Each RIR should operate one or more routers with an open peering policy which will perform the following functions:
A. Advertise all unissued space allocated to the RIR as originating from an ASN allocated to <RIR>-BOGON.
B. Peer with the corresponding routers at each of the other RIRs and accept and readvertise their BOGON list through BGP.
C. Provide a full BOGON feed to any router that chooses to peer, but not accept any routes or non-BGP traffic from those routers.
Of course, configure it wrong and you would end up sending all the junk that you would have null routed to your RIR. Sounds messy.
I think there are ways for the RIR to protect themselves from this.
Whats more I can see potential whenever we start creating these kind of self propagating blackholes for hackers to introduce genuine address blocks to create a DDoS.
Only if the hacker manages to own one or more of the RIR routers providing the feed. Remember, they will be configured not to listen to _ANY_ advertisement from any routers other than the other RIR routers that are known to provide equivalant service for the other RIRs. As such, assuming the RIRs run the routers with reasonable security precautions, I don't see this as being any more of a DDoS risk than any large backbone provider you can name today.
3. Any provider which wishes to filter BOGONs could peer with the closest one or two of these and set up route maps that modify the next-hop for all BOGONs to be an address which is statically routed to NULL0 on each of their routers.
How many ebgp sessions do the RIRs need to maintain?? A lot.. and the maintenance would be a nightmare. Dont think this will work purely because of that overhead you create!!
Nope... Yes, there would be _ALOT_ of ebgp sessions, but they wouldn't be full-table sessions. They'd be send-only with a small number of prefixes representing the bogon space. Also, it is possible to configure most routers to peer with "all comers" and assign the ones that don't have a specific configuration to a default peer group. That peer group would be configured to advertise-only the bogon list and accept nothing. With that configuration, the maintenance is near nil.
Owen
Steve
Apologies if this has been discussed before, but, it seems to me that this is the easiest way to make the data readily available to the community directly from the maintainers of the databases in a fashion which is automatically up to date.
There are other ways that dont use BGP peering to create lists that are more suitable
Steve
On Tue, 11 Mar 2003, Owen DeLong wrote:
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session.
However, it's primarily intended to solve the non-malicious, but somewhat malignant problem of out-of-date bogon filters by people trying to do the right thing.
So why does it need to be done by somebody "official"? Why make organizations who don't have route servers do this? I've been peering with Rob's bogon server for a little while, and it works great. All of my customers get routes that point the bogons to a traffic sink on my network. If they were so inclined, they could sink that traffic before leaving their network. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
Great. If you can get _EVERYONE_ to listen to Rob's server, I'm all for it. Frankly, I was unaware of Rob's server. However, I think it makes more sense to have the people maintaining the data distribute the data directly from the source. Right now, I'm betting that Rob's server requires someone in Rob's organization to keep up to date on all the RIRs and manually tweak the contents of his list. What is the perceived advantage to the extra layer of indirection? Owen --On Tuesday, March 11, 2003 1:11 PM -0500 Andy Dills <andy@xecu.net> wrote:
On Tue, 11 Mar 2003, Owen DeLong wrote:
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session.
However, it's primarily intended to solve the non-malicious, but somewhat malignant problem of out-of-date bogon filters by people trying to do the right thing.
So why does it need to be done by somebody "official"? Why make organizations who don't have route servers do this?
I've been peering with Rob's bogon server for a little while, and it works great. All of my customers get routes that point the bogons to a traffic sink on my network. If they were so inclined, they could sink that traffic before leaving their network.
Andy
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
Hi again, Owen. ] Frankly, I was unaware of Rob's server. For everyone who hasn't received our copious spam. :) http://www.cymru.com/Bogons/ ] Right now, I'm betting that Rob's server requires someone in Rob's ] organization to keep up to date on all the RIRs and manually tweak ] the contents of his list. Actually it requires one server and the tireless service of cron for most of the work. :) However, two of us eyeball it before any changes are applied. Better safe than sorry. While I agree that an "authoritative body" would be best to host this service, I'm happy to provide it for as long as there is a need. This is a free service, and not at all cumbersome to the members of Team Cymru. Thanks, Rob. -- Rob Thomas http://www.cymru.com ASSERT(coffee != empty);
I think Rob's server scans all the registry web pages for announced changes and then either modifies the list automatically or sets off an alarm to have the pages and list modified. I may be corrected but I think the process is either entirely or mostly automated. On Tue, 11 Mar 2003, Owen DeLong wrote:
Great. If you can get _EVERYONE_ to listen to Rob's server, I'm all for it. Frankly, I was unaware of Rob's server. However, I think it makes more sense to have the people maintaining the data distribute the data directly from the source. Right now, I'm betting that Rob's server requires someone in Rob's organization to keep up to date on all the RIRs and manually tweak the contents of his list.
What is the perceived advantage to the extra layer of indirection?
Owen
--On Tuesday, March 11, 2003 1:11 PM -0500 Andy Dills <andy@xecu.net> wrote:
On Tue, 11 Mar 2003, Owen DeLong wrote:
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session.
However, it's primarily intended to solve the non-malicious, but somewhat malignant problem of out-of-date bogon filters by people trying to do the right thing.
So why does it need to be done by somebody "official"? Why make organizations who don't have route servers do this?
I've been peering with Rob's bogon server for a little while, and it works great. All of my customers get routes that point the bogons to a traffic sink on my network. If they were so inclined, they could sink that traffic before leaving their network.
Andy
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access
On Tue, 11 Mar 2003, Owen DeLong wrote:
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session.
How???
Iljitsch van Beijnum wrote:
On Tue, 11 Mar 2003, Owen DeLong wrote:
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session.
How???
There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of. Consider the connection between ISP X and ISP Y. ISP Y and is the provider who wants to null route any bogon traffic, even if ISP X advertises a more specific route for it. EBGP session between 192.168.0.1/30 and 192.168.0.2/30. ISP Y places 192.168.0.2 into VRF "X-Real". Also in VRF "X-Real" is 192.168.1.1 Now a VRF "X-Bogon" is created containing 192.168.1.2 and 192.168.2.1. And finally the ISP's Default-IP-Routing-Table or other general internet VRF contains 192.168.2.2. 192.168.1.1/192.168.1.2 and 192.168.2.1/192.168.2.2 are connected. (for example, create virtual interfaces on a GigE representing each side of a pair in the relevant VRFs and then loop the VLANs of each pair of virtual interfaces -- is there a way to create two "paired" loopback interfaces to interconnect VRFs rather than extending to a physical connection like I always have?) 192.168.1.1 (BGP router in VRF X-Real) and 192.168.2.2 (BGP router in Default-IP-Routing-Table) communicate via IBGP route reflection. Either dynamic or static routing can be used to ensure 192.158.1.1 and 192.168.2.2 know the way to reach each other. BGP router 192.168.2.1 (BGP router in X-Bogon) takes ONLY a bogon feed, and modifies the received routes to set the next hop either into oblivion (eg. out a loopback with no ip unreachables set and a deny ip any any ACL) or to a some kind of DoS/worm tracking server (since almost all of this traffic will be part of some kind of attack or worm, and you will quite probably want to know about it; you can also set your default route in your regular network to such a server that records all traffic received). Policy routing is applied on interface 192.168.1.2 saying "set IP default next hop 192.168.2.2" and on interface 192.168.2.1 saying "set IP default next hop 192.168.1.1". It would work. I've done things similar to this example in a lab to prove they work. I wouldn't want to let a configuration like this loose on the production internet, though, and anyone who would is probably a _Certifiable_ Cisco Internet Engineer. David.
On Wed, 12 Mar 2003, David Luyer wrote:
Iljitsch van Beijnum wrote:
On Tue, 11 Mar 2003, Owen DeLong wrote:
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session.
How???
There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of.
I think youre mixing up with ingress filtering by prefix list which you can specify prefix length on and hence ignore longer (or smaller) matches. Steve
Consider the connection between ISP X and ISP Y.
ISP Y and is the provider who wants to null route any bogon traffic, even if ISP X advertises a more specific route for it.
EBGP session between 192.168.0.1/30 and 192.168.0.2/30.
ISP Y places 192.168.0.2 into VRF "X-Real". Also in VRF "X-Real" is 192.168.1.1
Now a VRF "X-Bogon" is created containing 192.168.1.2 and 192.168.2.1.
And finally the ISP's Default-IP-Routing-Table or other general internet VRF contains 192.168.2.2.
192.168.1.1/192.168.1.2 and 192.168.2.1/192.168.2.2 are connected. (for example, create virtual interfaces on a GigE representing each side of a pair in the relevant VRFs and then loop the VLANs of each pair of virtual interfaces -- is there a way to create two "paired" loopback interfaces to interconnect VRFs rather than extending to a physical connection like I always have?)
192.168.1.1 (BGP router in VRF X-Real) and 192.168.2.2 (BGP router in Default-IP-Routing-Table) communicate via IBGP route reflection. Either dynamic or static routing can be used to ensure 192.158.1.1 and 192.168.2.2 know the way to reach each other.
BGP router 192.168.2.1 (BGP router in X-Bogon) takes ONLY a bogon feed, and modifies the received routes to set the next hop either into oblivion (eg. out a loopback with no ip unreachables set and a deny ip any any ACL) or to a some kind of DoS/worm tracking server (since almost all of this traffic will be part of some kind of attack or worm, and you will quite probably want to know about it; you can also set your default route in your regular network to such a server that records all traffic received).
Policy routing is applied on interface 192.168.1.2 saying "set IP default next hop 192.168.2.2" and on interface 192.168.2.1 saying "set IP default next hop 192.168.1.1".
It would work. I've done things similar to this example in a lab to prove they work. I wouldn't want to let a configuration like this loose on the production internet, though, and anyone who would is probably a _Certifiable_ Cisco Internet Engineer.
David.
Stephen J Wilcox wrote:
On Wed, 12 Mar 2003, David Luyer wrote:
Iljitsch van Beijnum wrote:
On Tue, 11 Mar 2003, Owen DeLong wrote:
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session.
How???
There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of.
I think youre mixing up with ingress filtering by prefix list which you can specify prefix length on and hence ignore longer (or smaller) matches.
The example I provided achieved both ingress and egress filtering based on routes in a bogon BGP feed, in a way which would even block when a more-specific route is in the provider's BGP table. While it didn't actually prevent the routes being in the routing table (as I said, it doesn't provide a way to stop receiving them), it does prevent traffic from and to the bogon locations, which is a significant part of the reason to use bogon lists. However, yes, it has some deficiencies[1] compared with using the static bogon lists for route filtering (and ingress/egress); it does not prevent routing table bloat, and it does not prevent traffic travelling across your WAN to the point of network egress only to be dropped. If you want to actually not receive into your network at all the BGP routes which match bogons, as I stated earlier, there is no way I know of to do this via a BGP feed. The only way to do it that I know of would be to use either a prefix list or a standard ACL (you can do anything you can do with a prefix list with a compiled extended ACL on BGP routes, it's just less clear to read as an extended ACL). Although, Owen DeLong has stated that it is possible, so maybe we should wait for his response :-) David. [1] Apart from simply being a completely twisted design.
I'm trying to get some time to actually put it in a router and test, but I believe there is a way to get similar functionality through a combination of route-map entries. When I have actual router config (I'll be testing on Cisco, but if anyone want's to provide me a Juniper testbed, I'll be happy to try that too), I'll post it. If I can't, I'll post a public apology and start beating on vendors to make it possible. :-) Owen --On Wednesday, March 12, 2003 11:41 PM +1100 David Luyer <david@luyer.net> wrote:
Stephen J Wilcox wrote:
On Wed, 12 Mar 2003, David Luyer wrote:
Iljitsch van Beijnum wrote:
On Tue, 11 Mar 2003, Owen DeLong wrote:
In short, it doesn't. Longer answer, if the ISP configures his router correctly, he can actually refuse to accept advertisements from other sessions that are longer versions of prefixes received through this session.
How???
There is a technically possible (but rather twisted) way you could not use the adverts, but not a way to refuse receiving them that I know of.
I think youre mixing up with ingress filtering by prefix list which you can specify prefix length on and hence ignore longer (or smaller) matches.
The example I provided achieved both ingress and egress filtering based on routes in a bogon BGP feed, in a way which would even block when a more-specific route is in the provider's BGP table. While it didn't actually prevent the routes being in the routing table (as I said, it doesn't provide a way to stop receiving them), it does prevent traffic from and to the bogon locations, which is a significant part of the reason to use bogon lists.
However, yes, it has some deficiencies[1] compared with using the static bogon lists for route filtering (and ingress/egress); it does not prevent routing table bloat, and it does not prevent traffic travelling across your WAN to the point of network egress only to be dropped.
If you want to actually not receive into your network at all the BGP routes which match bogons, as I stated earlier, there is no way I know of to do this via a BGP feed. The only way to do it that I know of would be to use either a prefix list or a standard ACL (you can do anything you can do with a prefix list with a compiled extended ACL on BGP routes, it's just less clear to read as an extended ACL).
Although, Owen DeLong has stated that it is possible, so maybe we should wait for his response :-)
David.
[1] Apart from simply being a completely twisted design.
participants (10)
-
Andy Dills -
David Luyer -
Ejay Hire -
Iljitsch van Beijnum -
Larry J. Blunk -
Owen DeLong -
Rick Duff -
Rob Thomas -
Scott Granados -
Stephen J. Wilcox