do bogon filters still help?
Every time IANA allocates new prefixes, we're treated to complaints about sites that are not reachable because they're in the new space and some places haven't updated their bogon filters. My question is this: have we reached a point where the bogon filters are causing more pain than they're worth? The Team Cymru web page (http://www.cymru.com/Bogons/index.html) gives some justification, but I think the question should be revisited. First, as the page (and the associated presentation) note, most of the benefit comes from filtering obvious stuff -- 0/8, 127/8, and "class" D and E source addresses. Second, the study is about 5 years old, maybe more; attack patterns have changed since then. Third, considerably more address space has been allocated; this means that the percentage of address space that can be considered bogus is significantly smaller. Possibly, there are more sites doing edge filtering, but I'd hate to count on that. So -- I'd like people to re-examine the question. Does anyone have more recent data on the frequency of bogons as a percentage of attack packets? What would that number look like if you filtered just the obvious -- the ranges given above, plus the RFC 1918 prefixes? Are your defenses against non-spoofed attacks really helped by the extra filtering? --Steven M. Bellovin, http://www.cs.columbia.edu/~smb
Hi, Steve. ] So -- I'd like people to re-examine the question. Does anyone have more ] recent data on the frequency of bogons as a percentage of attack ] packets? What would that number look like if you filtered just the ] obvious -- the ranges given above, plus the RFC 1918 prefixes? Are ] your defenses against non-spoofed attacks really helped by the extra ] filtering? Great question, and we're eager to hear the results as well. Our study is well past its prime, to be sure. Thanks, Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ ASSERT(coffee != empty);
No data, but I thought I should add...RFC 3330 "Special-Use IPv4 Addresses" lists the "obvious stuff." I just went through an exercise in de-bogonizing and needed that reference. [http://www.ietf.org/rfc/rfc3330.txt] Be careful though. It lists 24.0.0.0/8 as "special," explaining that this went to cable operators (and eventually administered via ARIN). So don't just use the Summary Table in section 3 blindly. At 13:03 -0500 1/11/06, Steven M. Bellovin wrote:
Every time IANA allocates new prefixes, we're treated to complaints about sites that are not reachable because they're in the new space and some places haven't updated their bogon filters. My question is this: have we reached a point where the bogon filters are causing more pain than they're worth?
The Team Cymru web page (http://www.cymru.com/Bogons/index.html) gives some justification, but I think the question should be revisited. First, as the page (and the associated presentation) note, most of the benefit comes from filtering obvious stuff -- 0/8, 127/8, and "class" D and E source addresses. Second, the study is about 5 years old, maybe more; attack patterns have changed since then. Third, considerably more address space has been allocated; this means that the percentage of address space that can be considered bogus is significantly smaller. Possibly, there are more sites doing edge filtering, but I'd hate to count on that.
So -- I'd like people to re-examine the question. Does anyone have more recent data on the frequency of bogons as a percentage of attack packets? What would that number look like if you filtered just the obvious -- the ranges given above, plus the RFC 1918 prefixes? Are your defenses against non-spoofed attacks really helped by the extra filtering?
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Inactionable unintelligence is bliss.
On Wed, 11 Jan 2006, Edward Lewis wrote:
No data, but I thought I should add...RFC 3330 "Special-Use IPv4 Addresses" lists the "obvious stuff." I just went through an exercise in de-bogonizing and needed that reference. [http://www.ietf.org/rfc/rfc3330.txt]
Be careful though. It lists 24.0.0.0/8 as "special," explaining that this went to cable operators (and eventually administered via ARIN). So don't just use the Summary Table in section 3 blindly.
For those doing similar exercise, you might want to look at rephrased version of rfc330 listed blocks: http://www.completewhois.com/iana-ipv4-specialuse.txt -- William Leibzon Elan Networks william@elan.net
* william elan net:
For those doing similar exercise, you might want to look at rephrased version of rfc330 listed blocks: http://www.completewhois.com/iana-ipv4-specialuse.txt
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local). to make the list more future-proof, listing 128.0.0.0/16, 191.255.0.0/16, 192.0.0.0/24 and 223.255.255.0/24 as YES might be a good idea. I'm not sure what to do with 39/8. I haven't looked at RFC 3330, but another RFC reserves 192.0.2.0/24 for examples in documentation. In practice, this prefix is used for distributing fake null routes over BGP, so it's a rather strong NO.
* william elan net:
For those doing similar exercise, you might want to look at rephrased version of rfc330 listed blocks: http://www.completewhois.com/iana-ipv4-specialuse.txt
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local).
Good example as to why to use authoratative sources only. Completewhois is far from that. (it's a good effort though.. so thanks william). -M<
* Martin Hannigan:
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local).
Good example as to why to use authoratative sources only.
But most authoritative sources are too shy to make explicit operational recommendations. 8-)
At 20:28 +0100 1/11/06, Florian Weimer wrote:
* Martin Hannigan:
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local).
Good example as to why to use authoratative sources only.
But most authoritative sources are too shy to make explicit operational recommendations. 8-)
The authoritative sources put the data out there. What more can you ask of them? What more do you want? It's been said that the neutral parties (the authorities are supposed to be neutral) should not make business decisions for the industry. Recommending route filters is a business decision. Operational recommendations in general are business decisions. Consider it lucky you have a choice here. The plain official version, William's marked up copy, and edits to William's on the list. You have a choice here, you can't beat that. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Inactionable unintelligence is bliss.
On Wed, 11 Jan 2006, Edward Lewis wrote:
At 20:28 +0100 1/11/06, Florian Weimer wrote:
* Martin Hannigan:
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local).
Good example as to why to use authoratative sources only.
But most authoritative sources are too shy to make explicit operational recommendations. 8-)
The authoritative sources put the data out there. What more can you ask of them? What more do you want? It's been said that the neutral parties (the authorities are supposed to be neutral) should not make business decisions for the industry. Recommending route filters is a business decision. Operational recommendations in general are business decisions.
Nevertheless I'd prefer to see authoritative source (i.e. ICANN & IANA) be more involved then just text file on a website. For example IETF does more both in terms of notifications (which they sent to multiple lists for each published RFC - with lists being different depending on what RFC its on-topic for) and in terms of information for operational use (i.e. published BCPs and separate OPS area). Ultimately of course IANA is closely related to activities of IETF but I think it does have its own role to play and notifications of changes to its indexes is within its area of responsibility. -- William Leibzon Elan Networks william@elan.net
On Wed, 11 Jan 2006, Florian Weimer wrote: Thank you for your suggestions.
* william elan net:
For those doing similar exercise, you might want to look at rephrased version of rfc330 listed blocks: http://www.completewhois.com/iana-ipv4-specialuse.txt
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local).
I think you just explained it yourself why this is "SPECIAL", i.e. routing of it depends on local policies and setup. Anything where it is not clear from RFCs if it should be routable or not and where it depends on local decisions & policy is what I called SPECIAL. Perhaps better documentation is needed to explain each case, which I'll likely do some point way in the future when html version of the same page also becomes available. It is on the TODO list.
to make the list more future-proof, listing 128.0.0.0/16, 191.255.0.0/16, 192.0.0.0/24 and 223.255.255.0/24 as YES might be a good idea. I'm not sure what to do with 39/8.
Yes, I considered that. Ultimately these blocks might well become routed. It should be pointed out though that the file is not set in stone and was intended to be updated when some block's status changes just like this is done with iana-ipv4-allocations.txt It is however possible that I'll change it to YES with special comment because the data does seem more of something that people are going to configure and left alone rather then expect changes as with bogon data.
I haven't looked at RFC 3330, but another RFC reserves 192.0.2.0/24 for examples in documentation. In practice, this prefix is used for distributing fake null routes over BGP, so it's a rather strong NO.
If you know which RFC it is, I'll update the reference table. -- William Leibzon Elan Networks william@elan.net
* william elan net:
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local).
I think you just explained it yourself why this is "SPECIAL", i.e. routing of it depends on local policies and setup. Anything where it is not clear from RFCs if it should be routable or not and where it depends on local decisions & policy is what I called SPECIAL.
Uhm, no. 6to4 anycast only works without hickups when the prefix is NOT treated in any special way. 8-) That's part of its charm. If operators start to install special filters, they break this functionality for no real gain.
I haven't looked at RFC 3330, but another RFC reserves 192.0.2.0/24 for examples in documentation. In practice, this prefix is used for distributing fake null routes over BGP, so it's a rather strong NO.
If you know which RFC it is, I'll update the reference table.
Uhm, looks like I was mistaken. Each time the topic comes up, I confuse this with RFC 2606 (domain names). No such RFC exists for IPv4 addresses.
On Wed, 11 Jan 2006, Florian Weimer wrote:
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it wouldn't be link-local).
I think you just explained it yourself why this is "SPECIAL", i.e. routing of it depends on local policies and setup. Anything where it is not clear from RFCs if it should be routable or not and where it depends on local decisions & policy is what I called SPECIAL.
Uhm, no. 6to4 anycast only works without hickups when the prefix is NOT treated in any special way. 8-) That's part of its charm. If operators start to install special filters, they break this functionality for no real gain.
I think this is still quite a bit of a special case as opposed to for example 24/8 block which is ultimately used same as regular RIR blocks. Nevertheless I changed routing to "YES" and leave explanation for future. I also did update and listed comment for reserved blocks with explanation that either regularly updated filters should be used or blocks should be left fully routable. -- William Leibzon Elan Networks william@elan.net
I haven't looked at RFC 3330, but another RFC reserves 192.0.2.0/24 for examples in documentation. In practice, this prefix is used for distributing fake null routes over BGP, so it's a rather strong NO.
If you know which RFC it is, I'll update the reference table.
Uhm, looks like I was mistaken. Each time the topic comes up, I confuse this with RFC 2606 (domain names). No such RFC exists for IPv4 addresses.
I HAVE looked at RFC 3330 and I noticed the following text in it: 192.0.2.0/24 - This block is assigned as "TEST-NET" for use in documentation and example code. It is often used in conjunction with domain names example.com or example.net in vendor and protocol documentation. Addresses within this block should not appear on the public Internet. In fact the title of the RFC is "Special-Use IPv4 Addresses" so I'm not sure what you mean when you say that no such RFC exists for IPv4 addresses. --Michael Dillon
Hi Florian, others, | You should move 192.88.99.0/24 from SPECIAL to YES (although you | shouldn't see source addresses from that prefix, no matter what the | folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it | wouldn't be link-local). Hi, here's a member of 'the folks at bit.nl'. Just a quick note to say that we have been sourcing IPv4 packets from 192.88.99.1 at a rate of 2.000 to 10.000 packets per second since early 2003, so I'm guessing we have sent some 750.000 billion packets by now. I have accounted for some 850.000 IPv4 addresses speaking to and from our 6to4 relay in Q4/2005 alone, so one might argue that there are the proverbial "One Million people can't be wrong". Groet, Pim (keeping the myth alive!) -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)
* Pim van Pelt:
Hi Florian, others,
| You should move 192.88.99.0/24 from SPECIAL to YES (although you | shouldn't see source addresses from that prefix, no matter what the | folks at bit.nl think). 169.254.0.0/16 should be NO (otherwise it | wouldn't be link-local).
Hi, here's a member of 'the folks at bit.nl'. Just a quick note to say that we have been sourcing IPv4 packets from 192.88.99.1 at a rate of 2.000 to 10.000 packets per second since early 2003, so I'm guessing we have sent some 750.000 billion packets by now.
And this is just so wrong. You should use an address you own as a source address. Otherwise, packets tend to get dropped by filters. And no, "anyone should be able to spoof from 192.88.99.0/24" is not the answer to this kind of problem.
Florian, On Thu, Jan 12, 2006 at 12:21:30AM +0100, Florian Weimer wrote: | And this is just so wrong. You should use an address you own as a | source address. Otherwise, packets tend to get dropped by filters. Who says so? It's anycasted, and operators source from it after making note of this in the proper routing registries. RIPE NCC would confirm that AS12859 can source from 192.88.99.0/24, just like the other operators in RFC3068-MNT can. If anybody marks this prefix as a bogon and filters it, that's their absolute right as a network operator. Their customers might not appreciate it that much though, if they would like to use 6to4. | And no, "anyone should be able to spoof from 192.88.99.0/24" is not | the answer to this kind of problem. I didn't say, type, or even think this. -- Met vriendelijke groet, BIT BV / Ing P.B. van Pelt PBVP1-RIPE (PGPKEY-4DCA7E5E)
On Thu, Jan 12, 2006 at 12:21:30AM +0100, Florian Weimer wrote:
Hi, here's a member of 'the folks at bit.nl'. Just a quick note to say that we have been sourcing IPv4 packets from 192.88.99.1 at a rate of 2.000 to 10.000 packets per second since early 2003, so I'm guessing we have sent some 750.000 billion packets by now.
And this is just so wrong. You should use an address you own as a source address.
You may want to review the discussion there: http://dict.regex.info/ipv6/ngtrans/2002-01.mail/0083.html I'm undecided wether it's The Right Thing to do, so I just want to provide this pointer.
Otherwise, packets tend to get dropped by filters.
By which ones? Folks with too much time feeding their paranoia, or is there any actual realistic attack to prevent by filtering packets with source 192.88.99.1? Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Thu, Jan 12, 2006 at 04:08:00AM +0100, Daniel Roesen wrote: ...
Otherwise, packets tend to get dropped by filters.
By which ones? Folks with too much time feeding their paranoia, or is there any actual realistic attack to prevent by filtering packets with source 192.88.99.1? ...
As Bill pointed out, filters that contain too much actually harm the network - longer than actual attacks, perhaps. I have no quantitative evidence to say "more", and perhaps it's one of those opinion things. [Currently trying to fix a problem with same.] -- Joe Yao ----------------------------------------------------------------------- This message is not an official statement of OSIS Center policies.
Florian Weimer wrote:
* Pim van Pelt:
Hi, here's a member of 'the folks at bit.nl'. Just a quick note to say that we have been sourcing IPv4 packets from 192.88.99.1 at a rate of 2.000 to 10.000 packets per second since early 2003, so I'm guessing we have sent some 750.000 billion packets by now.
And this is just so wrong. You should use an address you own as a source address. Otherwise, packets tend to get dropped by filters.
Wouldn't you expect to see packets return from the same address you send them to? ICMP and stateful firewalls work much better that way. Our 6to4 relay also soucres packets from 192.88.99.1, it seems to work best that way. Don't filter 192.88.99.1 in any direction unless you want to break 6to4. If you want to limit your exposure you could allow only proto 41 and icmp packets and not break it. If you have native IPv6 on your network you could run a local 6to4 relay for your customers and filter 192.88.99.0/24 to/from your peers. - Kevin
On Thu, 12 Jan 2006, Kevin Loch wrote:
If you have native IPv6 on your network you could run a local 6to4 relay for your customers and filter 192.88.99.0/24 to/from your peers.
This is only true if you're absolutely, positively sure that no one in your network needs to use 6to4. Otherwise, packets coming from other native networks, encapsulated by their relays with src=192.88.99.1 coming towards your 6to4-using customers would get blocked. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Wed, 11 Jan 2006, Florian Weimer wrote:
For those doing similar exercise, you might want to look at rephrased version of rfc330 listed blocks: http://www.completewhois.com/iana-ipv4-specialuse.txt
You should move 192.88.99.0/24 from SPECIAL to YES (although you shouldn't see source addresses from that prefix, no matter what the folks at bit.nl think).
This is not correct. It's perfectly fine to source packets from 192.88.99.0/24. Please show a citation if you think different. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
On Wed, 11 Jan 2006 13:03:51 -0500 "Steven M. Bellovin" <smb@cs.columbia.edu> wrote:
Every time IANA allocates new prefixes, we're treated to complaints about sites that are not reachable because they're in the new space and some places haven't updated their bogon filters. My question is this: have we reached a point where the bogon filters are causing more pain than they're worth?
Perhaps operators can be convinced that the only best practice implementation of bogon filtering is through the use of a well maintained bogon route server service, be it from Team Cymru or some other well regarded 3rd party. All static, manual config management of bogon routes should be strongly discouraged. Now if router vendors could figure out ways to use a bogon route server for multicast protocols, that would be of a great help to niche community that has to run that service. There the pain is arguably worth it (dig about multicast being painful with or without them here :-) John
participants (13)
-
Daniel Roesen
-
Edward Lewis
-
Florian Weimer
-
John Kristoff
-
Joseph S D Yao
-
Kevin Loch
-
Martin Hannigan
-
Michael.Dillonļ¼ btradianz.com
-
Pekka Savola
-
Pim van Pelt
-
Rob Thomas
-
Steven M. Bellovin
-
william(at)elan.net