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.
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
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
* william elan net:
For those doing similar exercise, you might want to look at rephrased
version of rfc330 listed blocks:
completewhois.com steht zum Verkauf - Sedo GmbH
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.
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:
completewhois.com steht zum Verkauf - Sedo GmbH
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 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. 
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.
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.
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!)
* 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,
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.
> 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
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.
>> 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
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
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.
...
> 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.]