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
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.
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
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
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
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.
I'm afraid reality disagrees with you - there already are networks doing it.
Being big does not guarantee you ability to do Bad Things.
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.
> 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:
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
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.
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.htmlSeems 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
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
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>
Patrick W. Gilmore 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.
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".
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.
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
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,