ah-ha! but seriously, is this something an NSP/ISP should be doing? or is
this an enterprise function? or MSSP function? Are there standard tools
available to notify folks when changes occur? (aside from: "go check
iana.org website" or "golly traffic's not flowing anymore")
-Chris
I absolutely agree, but without some tool or process to follow... we get
stuck acls/filters and no idea that there is a problem until it's far into
the problem 
Such updates get posted to various places like nanog, cisco-nsp, probably other -nsp lists, and such...but for the large number of ASNs not represented at all on those lists, I don't know how they're supposed to "get notified" every time a bogon ceases to be. My own experience with this was that its very diffifcult to find your way to the clue at organizations with such filter issues...and even when you find such breakage, its hard to tell from the outside which end of a connection has the filter issue.
Hey, Chris.
ah-ha! but seriously, is this something an NSP/ISP should be doing? or is
this an enterprise function? or MSSP function? Are there standard tools
available to notify folks when changes occur? (aside from: "go check
iana.org website" or "golly traffic's not flowing anymore")
We have two ways to notify folks:
1. bogon-announce list, <http://puck.nether.net/mailman/listinfo/bogon-announce>
2. Automated updates with the bogon route-servers, <http://www.cymru.com/BGP/bogon-rs.html>
Thanks,
Rob.
right, so often the acls/filters/policies get setup at install time, the
installer leaves/changes-jobs/blah and 2 years later the noc/net-admin at
the smaller-isp or hosting company or enterprise ends up not knowing what
this portion of the config might be doing, so it doesn't get touched...
The challenge for folks on the far side of this problem
(69box.atlantech.net for instance or midco) is finding a way to get this
adjusted.
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours) The cisco auto-secure feature sure showed some fun
effects for this too, eh?
The challenge for folks on the far side of this problem
(69box.atlantech.net for instance or midco) is finding a way to get this
adjusted.
69box.atlantic.net
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours) The cisco auto-secure feature sure showed some fun
effects for this too, eh?
If by core you mean the "tier 1's" where in theory there are people with enable keeping up with the community mailing lists, then sure, bogon filters there sure beat bogon filters at every enterprise where they 'set it and forget it.'
We managed to fix that mis-application in later releases, but it has human dependency for that set of releases.
http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_field_notice09186a00803e13e9.shtml
Like security "experts" the recommend blocking calls in the North American numbering plan to area code 809, or listing individual area codes in PBXs,
its not a good idea unless you have full-time telephone LERG engineers.
My rule of thumb is networks which use the "default" route probably should not implement bogon filters of reserved for future allocation addresses. Of course, they should still implement postive outbound traffic controls (i.e. BCP38++) on their own traffic. Even if the current engineers are
careful, people change, but the new people may not know or forget about
updating miscellanous routers especially in networks with "default" routing.
Most RFC3330 Special Use Addresses which should not appear on the public Internet probably should be dropped crossing Internet provider boundaries unless specifically allowed, i.e. RFC1918, 127/8, 169.254/16, 224/4, 240/4, etc. That does not include other addresses mentioned in RFC3330
like 14/8, 24/8, 223.255.255.0/24 which are/will be routable on the
public Internet. Most backbones already apply some filter like this to
their BGP sessions and it can be optimized for hardware support even on
very high traffic links. This is pretty low-risk, low-change traffic
hygiene.
So what about filtering reserved for future use "unallocated" IP addresses between "default-free" backbones? Is it enough of a real problem to overcome the other hurdle of making operational changes/errors in major
backbone interconnects. Or is the current practice of whacking the
traffic when it causes a problem, whether its from allocated or unallocated space sufficient?
Personally, I think the current practice of whacking problem traffic from
unallocated IP addresses seems sufficient. If people decide its enough of
a problem that backbones must take the operational risk to change filters, then I think IANA must adopt a more predictable schedule. For example, IANA announces future allocations at each IETF meeting which will become allocated for use after the next IETF meeting to give backbones 3-4 months to schedule the change.
There are canonical email lists on which these changes are announced, and Team Cymru maintain examples which are updated regularly.
But, of course, you know this, so I suspect somehow you're trying to make a different kind of point.
;>
Antispoofing is 'static' and therefore brittle in nature, people change jobs, etc. - so, we shouldn't do antispoofing, either?
Enterprises typically don't do this stuff. They should, and we work to educate them, but it's even more difficult in that space than in the SP space.
A question I have is whether or not this class of problems is more of a 'need the vendors to come up with better/easier functionality' type of problem, a 'need the SPs to do a better job with this' kind of problem, or is it more in the realm of a 'TCP/IP in its current incarnation(s) lends itself these kinds of issues' type of problem?
Well, not all of us advocate that; see
http://www.merit.edu/mail.archives/nanog/2006-01/msg00150.html
--Steve Bellovin, http://www.cs.columbia.edu/~smb
Well Steve, it's like this: There are (a) security experts, (b) "security
experts", and (c) guys that spend their day making things usable in spite of
what the rest of the net throws in their AS's direction. You're an example of
one, I'm an example of another, and the advocates of static bogon filters are
an example of the third. Figuring out which is which is left as an exercise
for the reader...
As stuff like Ironport shows - you'll probably have better market penetration
by making a little knob labelled "filter unknown and unallocated IP prefixes
(default on)" on a nice shiny firewall appliance/blade and charge the
enterprise $150pm to keep this up to date.
(Then another for "filter hosts actively involved in hacking attempts" for
another $300 pm.)
(And, finally, "check active IP(s) that I'm transiting against the various
list(s) of botnet and CERT related activities, send SNMP trap when
matches are found" for even more.)
Adrian
Roland Dobbins <rdobbins@cisco.com> writes:
So... again, are bogon filters 'in the core' useful? (call 'core' some
network not yours)Antispoofing is 'static' and therefore brittle in nature, people
change jobs, etc. - so, we shouldn't do antispoofing, either?
Unicast RPF is neither static nor brittle, and we should do it.
I agree with smb though in somewhat less diplomatic terms - bogon
filtering by end sites is the sort of thing that is recommended by
"experts" for whom "security" is an end in and of itself, rather than
a component of the arsenal you bring forth (backups, DR, spares,
multihoming, etc) to improve uptime and business availability and
decrease potential risk.
For people who recommend cures that are as bad as the disease, we
recommend one of these: Consulting - Despair, Inc.
---Rob
uRPF isn't always adequate for all antispoofing cases, as you know. What about iACLs?
bogon
filtering by end sites is the sort of thing that is recommended by
"experts" for whom "security" is an end in and of itself, rather than
a component of the arsenal you bring forth (backups, DR, spares,
multihoming, etc) to improve uptime and business availability and
decrease potential risk.
I don't claim to be an 'expert' at anything, but I most certainly -do- recommend bogon filtering, along with multihoming, infrastructure self-protection measures (iACLs, rACLs, CoPP, core-hiding, et. al.), various antispoofing techniques (all the way down to layer-2 where possible), instrumentation and telemetry, anomaly-detection, reaction tools, layer-7 things like backup and DR, layer-8 things like sparing, and so forth. And my goal isn't 'security', it's a resilient Internet infrastructure which keeps the packets flowing so that the users can access the applications which are the point of the whole exercise.
I'm not the only one who thinks like that, either. So, painting us all with the same broad brush hardly seems fair, does it?
Rejecting bogon filtering out of hand because it isn't effortless to maintain doesn't make much sense to me. After all, if one's being a good Internet neighbor, one's doing ingress filtering (routes and packets) from one's customers and egress filtering (routes and packets) to one's peers/transits/customers, anyways; one will see more churn there than in the bogon lists.
It's also part of the very basic protections which ought to be provided to one's customers. No, the SP can't be the 'Internet firewall' for customers, and, no, the SP can't be expected to keep the customer magically protected from all the Bad Things which can happen to him (and for free, naturally), but protecting one's customers from being spammed/packeted from purported source addresses which are by definition nonsensical (as well as protecting everyone else's customers from same) doesn't seem much to ask.
What's needed here are better/easier/less brittle mechanisms for same. Until such time as they're invented and deployed, let's not make the perfect the enemy of the merely good, yes?
[Thoenen seems to have clipped the attribution]
> Perhaps,
> bogon acls are helpful when they are configured on backbone, but not
>
> everywhere.And if ever major backbones (read tier 2/3) would do so all us little
guys wouldn't have to (yet for some reason I keep getting the odd hit
in my acl logs from bogon space daily).Yes I know they will defend this with "we sell unfiltered service"
(which of course isn't true); I am just not convinced filtering bogon's
would invalidate this any more than their MPLS QoS clouds do.
There are smaller internets that are large enough that one person is not
managing all of the routers, but small enough that policy can be
"MANAGED" across all of them. Some of these required implementation of
the bogon lists. As they are small, this rarely changes - so when a
change to the bogon list comes, some resist this as if an article of
their faith were being challenged. Even within the group managing the
backbone.
As I'm STILL fighting skirmishes on this front, I'm less happy about
bogon lists than I once was.
"Leaf" networks should perform egress filtering, everyone knows that now
[;-} we wish]. Service provider networks should probably filter on
connections to the "customer" networks to allow only that customer's
IPs, but on connections to "transit" networks to only eliminate the
truly "unroutable" IP addresses such as RFC 1918.
However, since it is not possible to require this or anything else on
the public Internet, except by making sure that all routers are run by
clueful people who have entered into mutual agreement to do this [sorry,
dreaming again], this is not likely to happen.
Agreed. This "security experts copying each other - without knowing what
they are really talking about" started to happen 4 years ago. Which is
why some people working with SP all over moved evolving work of
Bogon/DUSA prefix filtering to two places, CYMRU's sponsored "Bogon"
project and RIPE (work like
http://www.ripe.net/ripe/docs/ripe-351.html). Both places allow for
policy practice suggestions to evolve. And they have evolved - working
with operators who are working to institute policies and practices in
their organization which is resistant to operational entropy.
For example, http://www.cymru.com/Bogons/index.html describes the static
policies for people to get started. Static is not the way to go.
Operators who understand the impact of "operational entropy" (OPEX
growth) want dynamic tools. Hence, they spend time find a tool which is
a multipurpose dynamic prefix policy system (i.e. something that does
their customer's prefixes, anti-spoofing, DUSA, Bogon, Black Hole, and
Hijack). This is why the Bogon reference page has grown over the years
adding tricks and tools to build prefix filters dynamically:
-> The Bogon Route Server Project
(http://www.cymru.com/BGP/bogon-rs.html) allows SPs to take a feed or
build their own.
-> RADb
-> RIPE NCC
-> DNS Bogon Tracking
-> E-mail Bogon Tracking
To 'globally' monitor, we have
http://www.cymru.com/BGP/robbgp-bogon.html and
http://www.cymru.com/BGP/asnbogusrep.html and
http://www.cidr-report.org/ and http://www.routeviews.org/ and
http://www.completewhois.com/bogons/active_bogons.htm.
(Steve B, you were looking for data, here are your sources. I'm sure
Geoff might be persuaded to do a historical graph on the 'Possible
Bogons.')
To organizationally monitor, J & C both have the ability to count the
prefix drops. It was operators who taught me both of these tricks -
which allow them to put in prefix filters which included bogons, then
count the packets originating from those filters prefixes get dropped --
one pulling all that data via SNMP and plugged it into MRTG so they know
the count of packets coming from their peers whose source is in the
Bogon/DUSA list.
Just remember the real reason we do this. 7007 demonstrated an
operational risk to networks. That risk is a cascading risk (prefix
advertisements moving from one network to another). Jump on a miscreant
shopping mall, buy a bunch of BGP speaking "owned" routers, check out
which ones do not have any upstream prefix filters, and have fun. The
two reasons why this has not happened is 1) enough SPs do ingress prefix
filters with their peers to disrupt this attack vector and 2) there is
no way to 'extort' money from the Internet (Miscreant principle #3 -
never to anything for free).
Has this risk gone away? When it has been demonstrated to NOT be a risk,
organizations will change their prefix filter policies. In the mean
time, each organization on the Internet who have perceived operational
risk mitigation benefits from ingress prefix filtering will keep on
doing it.
I'd love to see a paper based such data. And I'll suggest that SRUTI
-- http://www.usenix.org/events/sruti07/cfp and yes, I'm the program
chair -- would be a perfect venue for the analysis.
--Steve Bellovin, http://www.cs.columbia.edu/~smb