RE: Atrivo/Intercage: Now Only 1 Upstream
Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting. - S -----Original Message----- From: Lamar Owen <lowen@pari.edu> Sent: Wednesday, September 17, 2008 09:26 To: nanog@nanog.org <nanog@nanog.org> Subject: Re: Atrivo/Intercage: Now Only 1 Upstream On Tuesday 16 September 2008 23:36:20 *Hobbit* wrote:
you expect them to apply a null route?
Well, I *have* been talking somewhat idealistically here and there with this crop of questions, but frankly I thought in the 2 or 3 years I was ignoring the list that the NETWORK OPERATORS ostensibly in custody of the intertubes would have pulled things together a little better and grown enough of a pair to firmly state "this crap stops here and now" and make it happen.
:-) Speaking as an observer only, and not as someone who, other than at my own edge, could make a significant impact on the result. Seems to me getting that IP space on a bogon list could be enough to make a serious dent.
On Wed, 17 Sep 2008, Skywing wrote:
Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting.
We all want a "really really bad stuff" BGP feed for anyone who wants it, but the Internet is not ready for that. Gadi.
- S
-----Original Message----- From: Lamar Owen <lowen@pari.edu> Sent: Wednesday, September 17, 2008 09:26 To: nanog@nanog.org <nanog@nanog.org> Subject: Re: Atrivo/Intercage: Now Only 1 Upstream
On Tuesday 16 September 2008 23:36:20 *Hobbit* wrote:
you expect them to apply a null route?
Well, I *have* been talking somewhat idealistically here and there with this crop of questions, but frankly I thought in the 2 or 3 years I was ignoring the list that the NETWORK OPERATORS ostensibly in custody of the intertubes would have pulled things together a little better and grown enough of a pair to firmly state "this crap stops here and now" and make it happen.
:-) Speaking as an observer only, and not as someone who, other than at my own edge, could make a significant impact on the result.
Seems to me getting that IP space on a bogon list could be enough to make a serious dent.
On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron <ge@linuxbox.org> wrote:
On Wed, 17 Sep 2008, Skywing wrote:
Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting.
We all want a "really really bad stuff" BGP feed for anyone who wants it, but the Internet is not ready for that.
hrm, so actually there's a lot of supporting infrastructure that is necessary (or could be necessary) to implement something of that sort in any decent sized network. Provided you wanted to sinkhole the trafffic off somewhere to 'do the right thing' not just null0 the traffic, of course. There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from "someone else" whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens. Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ... How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made? -Chris
On Wed, Sep 17, 2008 at 1:07 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron <ge@linuxbox.org> wrote:
On Wed, 17 Sep 2008, Skywing wrote:
Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting.
We all want a "really really bad stuff" BGP feed for anyone who wants it, but the Internet is not ready for that.
hrm, so actually there's a lot of supporting infrastructure that is necessary (or could be necessary) to implement something of that sort in any decent sized network. Provided you wanted to sinkhole the trafffic off somewhere to 'do the right thing' not just null0 the traffic, of course.
right on.
There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from "someone else" whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens.
and this is the exact reason i will not implement any of these auto-bgp feeds or drop lists in my network. now not only do i have internal operation folks fat fingers to worry about,but what if one of these third parties, as you pointed out, with no money changing hands or formal agreements,has fat fingers one day, and now adds a legitimate allocation to the feed/list? then what?
Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ...
How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made?
-Chris
Christian
Christopher Morrow wrote:
How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made?
Reputation based on src_addr is /so/ 2005. ASN has a few more legs perhaps... but... All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, etc.) makes any system based around IP reputation decidedly less useful. At the end of the day, nobody is going to drop packets for amazon's IP space. -David
On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote:
Christopher Morrow wrote:
How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made?
Reputation based on src_addr is /so/ 2005. ASN has a few more legs perhaps... but...
All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, etc.) makes any system based around IP reputation decidedly less useful.
At the end of the day, nobody is going to drop packets for amazon's IP space.
I'm afraid reality disagrees with you - there already are networks doing it. Being big does not guarantee you ability to do Bad Things. -- TTFN, patrick
On Wednesday 17 September 2008 13:34:22 Patrick W. Gilmore wrote:
On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote:
At the end of the day, nobody is going to drop packets for amazon's IP space.
I'm afraid reality disagrees with you - there already are networks doing it.
Indeed. Google's e-mail servers get on the various DNSBL's frequently.
Being big does not guarantee you ability to do Bad Things.
Might even provide incentive for the grid computing providers to keep tabs on what their uses are doing. Imagine that! Accountability, using the only 'stick' available.
Lamar Owen wrote:
On Wednesday 17 September 2008 13:34:22 Patrick W. Gilmore wrote:
On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote:
At the end of the day, nobody is going to drop packets for amazon's IP space.
I'm afraid reality disagrees with you - there already are networks doing it.
Indeed. Google's e-mail servers get on the various DNSBL's frequently.
I occasionally get in to an argument with a customer who is trying to get mail from someone after a spam run came out of a google mail server and landed it on a DNSBL. The argument presented to me always boils down to "Google could never do anything wrong" or "Google is too big to do anything wrong" and I should immediately stop recommending any DNSBL that would dare to block Google. ~Seth
I occasionally get in to an argument with a customer who is trying to get mail from someone after a spam run came out of a google mail server and landed it on a DNSBL. The argument presented to me always boils down to "Google could never do anything wrong" or "Google is too big to do anything wrong" and I should immediately stop recommending any DNSBL that would dare to block Google.
~Seth
A more rational version of this argument would be that blocking Google's mail servers will obviously have large amounts of collatarel damage. Any DNSBL that blocks Google's mail servers, other than perhaps in sufficiently serious situations to justify this level of collatarel damage, shouldn't be recommended. You should provide a way for customers to opt out of your blacklists. Many people are perfectly happy to run their own spam filtering software and retain the capability to skim (or analyze) their spam. If you provide a way for your customer to do this, point them to it. If not, that is a failing on your part. (Though of course it's always possible you have cost/benefit arguments that justify not providing that service.) Some people would really like email to be as reliable as possible, even if that means they have to wade through a lot of spam. At least this gives them ability to whitelist sources that are important to them personally. David Schwartz <davids@webmaster.com>
David Schwartz wrote:
I occasionally get in to an argument with a customer who is trying to get mail from someone after a spam run came out of a google mail server and landed it on a DNSBL. The argument presented to me always boils down to "Google could never do anything wrong" or "Google is too big to do anything wrong" and I should immediately stop recommending any DNSBL that would dare to block Google.
~Seth
A more rational version of this argument would be that blocking Google's mail servers will obviously have large amounts of collatarel damage. Any DNSBL that blocks Google's mail servers, other than perhaps in sufficiently serious situations to justify this level of collatarel damage, shouldn't be recommended.
You should provide a way for customers to opt out of your blacklists. Many people are perfectly happy to run their own spam filtering software and retain the capability to skim (or analyze) their spam.
If you provide a way for your customer to do this, point them to it. If not, that is a failing on your part. (Though of course it's always possible you have cost/benefit arguments that justify not providing that service.)
Some people would really like email to be as reliable as possible, even if that means they have to wade through a lot of spam. At least this gives them ability to whitelist sources that are important to them personally.
Oh, they can. They have full control of everything hardcore filtering to nothing at all and anything in between. They could prune out the DNSBL they didn't like, turn off DNSBL completely, whitelist the source CIDR range (which I gave them), whitelist the sender's address/domain, etc. There was 15 different ways they could have fixed it, but didn't want to. I can't really say why. All they would say is "it's Google." ~Seth
Some people would really like email to be as reliable as possible, even if that means they have to wade through a lot of spam.
By what twisted logic can a system where desired email is found when " they have to wade through a lot of spam"? Have you ever inadvertently deleted a desired item in the middle of a delete-yes-delete-yes-delete-yes-delete-yes-delete-yes-delete-yes sequence that went on for "a lot of spam"? How many times? Did you recover all of the desired items? How do you know that? To me a reliable system is one that delivers what I want and only what I want every time. And having to pick the pepper out of the flysh*t is not my idea of "reliable".
On Wednesday 17 September 2008 16:53:35 Laurence F. Sheldon, Jr. wrote:
Some people would really like email to be as reliable as possible, even if that means they have to wade through a lot of spam.
By what twisted logic can a system where desired email is found when " they have to wade through a lot of spam"?
When our spam rate here is 90% (27,000 or more spam per week for 3,000 good messages) 'wading through spam' translates to 'finding real messages is like finding a needle in a pr0n haystack'. It's amazing how many false positives and annoyances I get with greylisting, though.
Welcome the Internet version of "Too big to fail". I like the corollary: If it's too big to fail, it's too big, and needs to be broken up. Otherwise, we get an oligarchy,
-----Original Message----- From: Seth Mattinen [mailto:sethm@rollernet.us] Sent: Wednesday, September 17, 2008 11:27 AM To: nanog@nanog.org Subject: Re: Atrivo/Intercage: Now Only 1 Upstream
Lamar Owen wrote:
On Wednesday 17 September 2008 13:34:22 Patrick W. Gilmore wrote:
On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote:
At the end of the day, nobody is going to drop packets for amazon's IP space.
I'm afraid reality disagrees with you - there already are networks doing it.
Indeed. Google's e-mail servers get on the various DNSBL's frequently.
I occasionally get in to an argument with a customer who is trying to get mail from someone after a spam run came out of a google mail server and landed it on a DNSBL. The argument presented to me always boils down to "Google could never do anything wrong" or "Google is too big to do anything wrong" and I should immediately stop recommending any DNSBL that would dare to block Google.
~Seth
Patrick W. Gilmore wrote:
On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote:
At the end of the day, nobody is going to drop packets for amazon's IP space.
I'm afraid reality disagrees with you - there already are networks doing it.
Being big does not guarantee you ability to do Bad Things.
I didn't imply that it did. But the ability to block without causing significant collateral damage becomes more and more difficult as IPs become less tied to the organization using them. That said, you're right that people are doing it now. Consensus from friends running their apps on EC2 is that you can't expect to be able to send any email from EC2 and hope for a high deliverability rate.
On Sep 17, 2008, at 4:07 PM, David Ulevitch wrote:
Patrick W. Gilmore wrote:
On Sep 17, 2008, at 1:32 PM, David Ulevitch wrote:
At the end of the day, nobody is going to drop packets for amazon's IP space. I'm afraid reality disagrees with you - there already are networks doing it. Being big does not guarantee you ability to do Bad Things.
I didn't imply that it did.
Actually, that is exactly what you did.
But the ability to block without causing significant collateral damage becomes more and more difficult as IPs become less tied to the organization using them.
True (and rather obvious). Here's another obviously true statement: As more & more spam comes from a set of IP addresses, it becomes less & less likely you should accept e-mail from that space.
That said, you're right that people are doing it now. Consensus from friends running their apps on EC2 is that you can't expect to be able to send any email from EC2 and hope for a high deliverability rate.
Not news to anyone who works on anti-spam or e-mail deliverability. Perhaps the collateral damage will force Amazon to get things fixed faster. Or maybe not, but either way I don't see how you can blame someone for not wanting to accept e-mail from EC2. -- TTFN, patrick
Hi folks... We're working on some plans to peer in the Seattle area. Choices so far considered are SIX and PAIX Seattle pretty much.... I was of the impression that if you get a port on one of these exchanges, you can connect to the other one as well? Just looking for clarification from folks who are connected out there..;) Any charges to go between the exchanges or it just included? Thanks, Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
Hello Paul: On 9/18/08 8:01 AM, "Paul Stewart" <pstewart@nexicomgroup.net> wrote:
Hi folks...
We're working on some plans to peer in the Seattle area. Choices so far considered are SIX and PAIX Seattle pretty much....
I was of the impression that if you get a port on one of these exchanges, you can connect to the other one as well? Just looking for clarification from folks who are connected out there..;) Any charges to go between the exchanges or it just included?
Speaking from the SIX side, there is no charge to connect to the fabric if you supply the optics, and there is a one-time fiber cross connect charge of $200.00 US. The SIX and PAIX are directly connected and you can peer across the fabric. The SIX page is http://www.seattleix.net for more info or you can email me directly. I have no idea about charges related to PAIX. Mike SIX Tech Guy Hat On
On Thu, 18 Sep 2008, Michael K. Smith wrote:
Hello Paul:
On 9/18/08 8:01 AM, "Paul Stewart" <pstewart@nexicomgroup.net> wrote:
Hi folks...
We're working on some plans to peer in the Seattle area. Choices so far considered are SIX and PAIX Seattle pretty much....
I was of the impression that if you get a port on one of these exchanges, you can connect to the other one as well? Just looking for clarification from folks who are connected out there..;) Any charges to go between the exchanges or it just included?
Speaking from the SIX side, there is no charge to connect to the fabric if you supply the optics, and there is a one-time fiber cross connect charge of $200.00 US. The SIX and PAIX are directly connected and you can peer across the fabric. The SIX page is http://www.seattleix.net for more info or you can email me directly.
And keep in mind that while the SIX and PAIX-SEA are directly connected, the exchanges are on different VLANs from the perspective of a PAIX-SEA connection. If you connect on the SIX side, you can only reach the SIX fabric. No MRC. If you connect on the PAIX-SEA side, you can reach both the SIX fabric and the PAIX-SEA fabric via a single router port. For MRC talk to an S&D rep. Chris
Thanks very much... we have a price from S&D for the x-connect. If we connect on the PAIX side (most likely) do we need multiple VLAN's? I had planned on a single VLAN on the port for there - just need to understand ;) Thanks, Paul -----Original Message----- From: Chris Caputo [mailto:ccaputo@alt.net] Sent: September 23, 2008 6:13 PM To: Paul Stewart; Michael K. Smith Cc: NANOG list Subject: Re: Seattle Peering On Thu, 18 Sep 2008, Michael K. Smith wrote:
Hello Paul:
On 9/18/08 8:01 AM, "Paul Stewart" <pstewart@nexicomgroup.net> wrote:
Hi folks...
We're working on some plans to peer in the Seattle area. Choices so far considered are SIX and PAIX Seattle pretty much....
I was of the impression that if you get a port on one of these exchanges, you can connect to the other one as well? Just looking for clarification from folks who are connected out there..;) Any charges to go between the exchanges or it just included?
Speaking from the SIX side, there is no charge to connect to the fabric if you supply the optics, and there is a one-time fiber cross connect charge of $200.00 US. The SIX and PAIX are directly connected and you can peer across the fabric. The SIX page is http://www.seattleix.net for more info or you can email me directly.
And keep in mind that while the SIX and PAIX-SEA are directly connected, the exchanges are on different VLANs from the perspective of a PAIX-SEA connection. If you connect on the SIX side, you can only reach the SIX fabric. No MRC. If you connect on the PAIX-SEA side, you can reach both the SIX fabric and the PAIX-SEA fabric via a single router port. For MRC talk to an S&D rep. Chris ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
If you are in S&D/PAIX's facility, you have two options for connecting to the SIX: - direct to the SIX core via the fiber-meet-me-room, thus no VLAN. You won't get access to the PAIX-SEA fabric with this method, but if what you really want is the SIX, this is the way to go. - direct to the PAIX-SEA switch, in which case you'll need to instruct S&D to enable your port to also have access to the SIX fabric. Your router will have two VLAN interfaces on the port, one for PAIX-SEA and one for the SIX. Feel free to direct further questions to info@seattleix.net if you like. Chris On Tue, 23 Sep 2008, Paul Stewart wrote:
Thanks very much... we have a price from S&D for the x-connect. If we connect on the PAIX side (most likely) do we need multiple VLAN's? I had planned on a single VLAN on the port for there - just need to understand ;)
Thanks,
Paul
-----Original Message----- From: Chris Caputo [mailto:ccaputo@alt.net] Sent: September 23, 2008 6:13 PM To: Paul Stewart; Michael K. Smith Cc: NANOG list Subject: Re: Seattle Peering
On Thu, 18 Sep 2008, Michael K. Smith wrote:
Hello Paul:
On 9/18/08 8:01 AM, "Paul Stewart" <pstewart@nexicomgroup.net> wrote:
Hi folks...
We're working on some plans to peer in the Seattle area. Choices so far considered are SIX and PAIX Seattle pretty much....
I was of the impression that if you get a port on one of these exchanges, you can connect to the other one as well? Just looking for clarification from folks who are connected out there..;) Any charges to go between the exchanges or it just included?
Speaking from the SIX side, there is no charge to connect to the fabric if you supply the optics, and there is a one-time fiber cross connect charge of $200.00 US. The SIX and PAIX are directly connected and you can peer across the fabric. The SIX page is http://www.seattleix.net for more info or you can email me directly.
And keep in mind that while the SIX and PAIX-SEA are directly connected,
the exchanges are on different VLANs from the perspective of a PAIX-SEA connection.
If you connect on the SIX side, you can only reach the SIX fabric. No MRC.
If you connect on the PAIX-SEA side, you can reach both the SIX fabric and the PAIX-SEA fabric via a single router port. For MRC talk to an S&D rep.
Chris
On Wed, Sep 17, 2008 at 1:32 PM, David Ulevitch <davidu@everydns.net> wrote:
Christopher Morrow wrote:
How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made?
Reputation based on src_addr is /so/ 2005. ASN has a few more legs perhaps... but...
All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, etc.) makes any system based around IP reputation decidedly less useful.
there is more than 'srcip' you can use to judge reputation on... if you have something 'not a router' you can even implement other options... Adding things like ttl's to the entries, sliding the reputation on that as well. It's not just 'src ip'. ASN is a really big hammer....
At the end of the day, nobody is going to drop packets for amazon's IP space.
nope, but amazon can/may-be-able-to do some protections on their side, or individuals could choose to block bits/pieces of amazon, and they have already.
-David
On Wed, 17 Sep 2008, David Ulevitch wrote:
Reputation based on src_addr is /so/ 2005. ASN has a few more legs perhaps... but...
All the growth in Internet-connected compute clouds (EC2, AppNexus, GoGrid, etc.) makes any system based around IP reputation decidedly less useful.
At the end of the day, nobody is going to drop packets for amazon's IP space.
While I can't speak for the others on your list, we have been putting a fair amount of thought into abuse detection and mitigation at GoGrid. We are well aware of the problems we would have if our address space were to end up with a bad reputation. If stuff does get through that shouldn't, please contact abuse@gogrid.com and we'll take care of it. -Steve
On 17 Sep 2008, at 18:32, David Ulevitch wrote:
At the end of the day, nobody is going to drop packets for amazon's IP space.
I have a customer that sells online, and is dropping stuff from ec2 today due to abuse. Andy
Hmmm Seems Pacific bit the bullett around 2:25 est all annoucements were dropped. http://cidr-report.org/cgi-bin/as-report?as=AS27595&v=4&view=2.0 I would ask for comment by Intercage staff but they don't have email. Emil is unresponsive via phone, James
On Wed, 17 Sep 2008, Christopher Morrow wrote:
On Wed, Sep 17, 2008 at 1:01 PM, Gadi Evron <ge@linuxbox.org> wrote:
On Wed, 17 Sep 2008, Skywing wrote:
Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting.
We all want a "really really bad stuff" BGP feed for anyone who wants it, but the Internet is not ready for that.
hrm, so actually there's a lot of supporting infrastructure that is necessary (or could be necessary) to implement something of that sort in any decent sized network. Provided you wanted to sinkhole the trafffic off somewhere to 'do the right thing' not just null0 the traffic, of course.
There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from "someone else" whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens.
Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ...
How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made?
Chris, that does not solve the one issue you did not mention: liability. Gadi.
-Chris
On Wed, Sep 17, 2008 at 1:40 PM, Gadi Evron <ge@linuxbox.org> wrote:
On Wed, 17 Sep 2008, Christopher Morrow wrote:
How about providing some open-source intelligence in a centralized and machine-parsable fashion (perhaps with community input of intel even) which would allow better decsions to be made?
Chris, that does not solve the one issue you did not mention: liability.
if you can provide sourcing info and src tagging you could potentially limit some of the liability... but yes that's still an issue, the same issue as using any other existing BL though. 'oops jimbob@blplace.bl added www.amazon.com to the bl by mistake!' with some scoring system to set the reputation and associated query logic to pull out things over/under/around a threshold at least the users have some flexibility... if it's open sourced (how to make the list/content) then you can do that for yourself and the liability is all yours :) -Chris
It exists but not in bgp form - http://www.spamhaus.org/drop/ Dont Route Or Peer srs On Wed, Sep 17, 2008 at 7:01 PM, Gadi Evron <ge@linuxbox.org> wrote:
On Wed, 17 Sep 2008, Skywing wrote:
Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting.
We all want a "really really bad stuff" BGP feed for anyone who wants it, but the Internet is not ready for that.
On Wednesday 17 September 2008 12:55:49 Skywing wrote:
Lamar Owen Wrote: Seems to me getting that IP space on a bogon list could be enough to make a serious dent.
Putting things in the automated bogon feeds (e.g. Team Cymru) that are not strictly bogons (unallocated addresses) is likely to very quickly erode trust in those services, if that is what you are suggesting.
Seems a similar topic has been here before... hrm... Yep, back around the first of August the subject came up of "Is it time to abandon bogon prefix filters?" in which thread you (among many others) were a participant. I don't have an archive link, sorry, since I used my personal archive of NANOG to find. Seems there are already trust, DoS, etc issues out there, in spades. But if someone wanted to do a 'badon' list and distribute in a similar fashion nothing is preventing folks for subscribing. The various antispam DNSBL's have multiple feeds of different kinds; some enterprising soul could do the same for routing. Will everyone do that? Of course not; some will choose to not, others will simply not care, and others will just ignore. Perhaps it could be called the wish-they-were-bogons list. Then a I-really-wish-they-were-bogons list for just the more severe block. The point made by Christopher Morrow is well taken:
There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from "someone else" whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens.
Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ...
Folks who use a DNSBL are already letting people in their network, in the e-mail sense at least (and some firewall interfaces to these lists). Those same people would likely not have a problem with a wish-they-were-bogons list. But, yeah, it's like chasing a weasel with an M134 with someone else aiming while you hold down the trigger. For infrastructure notes, see Team Cymru's description page at http://www.team-cymru.org/Services/Bogons/routeserver.html Seems easy enough to duplicate (of course, the devil is in the details, and nothing is as easy as it seems); and making the 'thing' 'do the right thing' is a matter of what routes are actually served by your route-servers. Perhaps a good use for that old Internet backbone router (or wannabe) that can no longer take a full BGP feed.
On Wed, Sep 17, 2008 at 1:34 PM, Lamar Owen <lowen@pari.edu> wrote:
The point made by Christopher Morrow is well taken:
There's the additional issue of allowing a third party to manage/traffic-engineer inside your network which might upset some operations folks. If you can build a list on your own in a reasonable fashion with supporting information and high confidence level that's one story, if this list comes from "someone else" whom you don't even have a billing-relationship with... it's hard to sell that when something bad happens.
Certainly not everyone feels this way (see 'popularity' of the existing RBL/xbl lists) but in a larger network, or one that makes money ...
Folks who use a DNSBL are already letting people in their network, in the e-mail sense at least (and some firewall interfaces to these lists). Those same people would likely not have a problem with a wish-they-were-bogons list.
dropping email or port scans to known-vulnerable ports is very different from dropping all traffic from an ip/asn ... There have been cases of large content folks (MS comes to mind) being infected with badness, dropping that for a time is going to hurt more than dropping email from it only.
For infrastructure notes, see Team Cymru's description page at http://www.team-cymru.org/Services/Bogons/routeserver.html
Seems easy enough to duplicate (of course, the devil is in the details, and
Sorry not just the route-server is necessary, if you want to do something aside from 'drop traffic on the floor'. Take, for instance the DNS Pinning attacks. If you have a large consumer base (or other base dependent up on recursive resolvers) discarding traffic towards the pinned resolvers is going to increase your costs... Prior to accepting the routing change if you setup some infrastructure to sinkhole the traffic and provide proper services out of that sinkhole you'd at least avoid that issue. where in your network can you sink a few gbps of traffic? regionally? locally? centrally? never? always? planning that out is necessary. -chris
participants (19)
-
Andy Davidson -
Chris Caputo -
Christian Koch -
Christopher Morrow -
Christopher Morrow -
David Schwartz -
David Ulevitch -
Gadi Evron -
James Thomas -
Lamar Owen -
Laurence F. Sheldon, Jr. -
Michael K. Smith -
Patrick W. Gilmore -
Paul Stewart -
Seth Mattinen -
Skywing -
Steve Gibbard -
Suresh Ramasubramanian -
Tomas L. Byrnes