Off a comment Vix made in another thread this weekend, what is the current
status, to the degree to which anyone knows and is permitted to say, of
the deployment of RFC 3704, BCP 38, to block IP address spoofing at the
ingress edge of large consumer eyeball networks?
When the BCP was first release, as I recall it, much noise was made to
suggest that it was cost-ineffective and impractical to deploy it because
the current state of edge devices was such that it wasn't a simple knob-turn.
Is that still true (or not, as I expect), and if common edge concentrators
do now support easy filtering to drop packets with improper or invalid
source addresses, is this being utilized in the wide area...
and if not, why the hell not?
Or are spoofed-source-address attacks not, as Vix suggests, significant
and trending upwards?
Cheers,
-- jra
They're enjoying a renaissance because of attackers leveraging spoofing in order to enable DNS, SNMP, and ntp reflection/amplification DDoS attacks.
I'd say most supports it, and if anyone buys one that isn't, they're doing something seriously wrong in their purchasing process.
This is for IPv4, for IPv6 we're back 10 years again with very lacking support.
Some statistics are available at http://spoofer.csail.mit.edu/
Ron
Ok, so your comment confirms that there's still a problem, and Mikael's,
that the tools to stop it from actually being a problem can *reasonably*
be expected to be in place in a reasonably large number of places where
they're needed.
So, are the knobs actually on? (I'm guessing "clearly, not")
Why?
Cheers,
-- jra
In many cases, no, or we wouldn't be seeing many spoofed packets, would we?
;>
There are plenty of 'knobs', but I doubt any read this list....
Ken Matlock
Network Engineer
303-467-4671
matlockk@exempla.org
Amen to that. At first glance, building IPv6 ACLs/firewall rules/filters isn't much different from building IPv4 equivalents in many environments, but there are lots of vendor-specific 'gotcha's out there that make for more work to get to a point of sanity with IPv6. To be fair, at the application level, things are still pretty similar - the sun still rises in the east, HTTP still normally works on well-known destination port tcp/80, etc.
Examples:
1. Junos firewall filters can be bypassed in some cases with appropriately crafted extension headers, depending on how the filter is built. In the case of border ingress/egress filters, which are often written in a "deny specific types of traffic, but permit everything else" fashion, re-working the order of the filter elements is often not practical.
2. Cisco's handling of ICMPv6 on the ASA platform still seems a bit 'green' to me. Hopefully the kinks will get worked out as everyone (vendors included) get more operational experience with IPv6. I'm basing this on my efforts to develop a set of basic firewall rules for our IPv6 deployment templates, with the goal being to allow necessary ICMPv6 traffic through, while limiting the exposure of the hosts behind the firewall. A lot of this has been based on RFC 4890 as a starting point.
3. Some devices leak link-local traffic beyond the link, in violation of RFC 4192, sec 2.5.6. This can have implications for filter/acl/ruleset design, since the assumption that devices will always 'do the right thing' with link-local traffic is not valid.
jms