----- Original Message -----

From: "Roland Dobbins" <rdobbins@arbor.net>

On Jun 11, 2012, at 10:13 PM, Jay Ashworth wrote:

...

Or are spoofed-source-address attacks not, as Vix suggests, significant and trending upwards?

They're enjoying a renaissance because of attackers leveraging spoofing in order to enable DNS, SNMP, and ntp reflection/amplification DDoS attacks.

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 -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274

There are plenty of 'knobs', but I doubt any read this list.... Ken Matlock Network Engineer 303-467-4671 matlockk@exempla.org -----Original Message----- From: Dobbins, Roland [mailto:rdobbins@arbor.net] Sent: Monday, June 11, 2012 10:32 AM To: NANOG Gripes List Subject: Re: Whither Cometh BCP38? On Jun 11, 2012, at 11:09 PM, Jay Ashworth wrote:

So, are the knobs actually on? (I'm guessing "clearly, not")

In many cases, no, or we wouldn't be seeing many spoofed packets, would we? ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton *** SCLHS Confidentiality Notice *** The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any other dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately by replying to the message and deleting it from your computer. Thank you. *** SCLHS Confidentiality Notice ***

On Mon, 11 Jun 2012, Mikael Abrahamsson wrote:

This is for IPv4, for IPv6 we're back 10 years again with very lacking support.

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