I used the ones Cisco outlined in their document IOS Essentials every ISP
Should Know. Here is a copy of the list I use for out clients:
deny ip host 0.0.0.0 any log
deny ip 127.0.0.0 0.255.255.255 any log
deny ip 10.0.0.0 0.255.255.255 any log
deny ip 172.16.0.0 0.15.255.255 any log
deny ip 192.168.0.0 0.0.255.255 any log
deny ip xxx.xxx.xxx.0 0.0.0.255 any log
deny ip 224.0.0.0 31.255.255.255 any log
We are denyingy anyone that claims that their IP address is 0.0.0.0,
Loopback addresses, all of the RFC 1918 addresses, address coming into us
claiming they belong to our subnet, and multicast addresses. It seems to
work for us. I also turn of ip directed broadcasts to minimize smurf/DoS
attacks. If you would like a copy of the document I used, let me know and
I'll e-mail a copy to you.
Ron Fuller, CCDP, CCNP-ATM, CCNP-Security, MCNE, MCP
3X Corporation rfuller@3x.com
deny ip host 0.0.0.0 any log
deny ip 127.0.0.0 0.255.255.255 any log
deny ip 10.0.0.0 0.255.255.255 any log
deny ip 172.16.0.0 0.15.255.255 any log
deny ip 192.168.0.0 0.0.255.255 any log
deny ip xxx.xxx.xxx.0 0.0.0.255 any log
deny ip 224.0.0.0 31.255.255.255 any log
Routing those networks to nul0 and turning 'ip verify unicast reverse-path'
on CEF-enabled Cisco routers does this without CPU load or does not ?
These three clauses will block things like ICMP would-fragment and
ttl-expired messages, in the event that some transitory bit of network
between your customer and someone else's customer is numbered using
RFC1918 address space (and causes such messages to be sent).
I know of several networks which use RFC1918 addresses like this,
in the belief that since the elements with these numbers never
need to receive a packet from anybody outside the operator's network,
there is no need for the numbers to be globally unique.
In my opinion, such RFC1918 visibility in the public network is
misguided, and half of the disruption to service caused by rules
like those above could be considered just punishment.
Trouble is, the other half of the disruption is for your customers,
and you know who they're going to blame if they can't reach their
favourite repository of huge flesh-tone jpegs.
Operational content: does anybody actually block packets inbound
from off-net, in the case where they are sourced from an RFC1918
address? If so, do your customers complain?
> deny ip 10.0.0.0 0.255.255.255 any log
> deny ip 172.16.0.0 0.15.255.255 any log
> deny ip 192.168.0.0 0.0.255.255 any log
These three clauses will block things like ICMP would-fragment and
ttl-expired messages, in the event that some transitory bit of network
between your customer and someone else's customer is numbered using
RFC1918 address space (and causes such messages to be sent).
I know of several networks which use RFC1918 addresses like this,
in the belief that since the elements with these numbers never
need to receive a packet from anybody outside the operator's network,
there is no need for the numbers to be globally unique.
Unfortunately, they're wrong.
In my opinion, such RFC1918 visibility in the public network is
misguided, and half of the disruption to service caused by rules
like those above could be considered just punishment.
Agreed.
Trouble is, the other half of the disruption is for your customers,
and you know who they're going to blame if they can't reach their
favourite repository of huge flesh-tone jpegs.
Operational content: does anybody actually block packets inbound
from off-net, in the case where they are sourced from an RFC1918
address? If so, do your customers complain?
We (UNINETT, AS224) block RFC 1918 source addresses on our border
routers, and have been doing so for a couple of years now. We have
had zero complaints about this. We certainly intend to continue.
Operational content: does anybody actually block packets inbound
from off-net, in the case where they are sourced from an RFC1918
address? If so, do your customers complain?
AUCS (As3300) blocks incoming RFC 1918 addresses together with our own
address space , to avoid spoofed ospf updates, at all our borders with
other networks and have not received complaints of customers ever.