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 -- 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
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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Luck is the residue of opportunity and design. -- John Milton
----- 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
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
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, Jay Ashworth wrote:
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...
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. -- Mikael Abrahamsson email: swmike@swm.pp.se
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
-----Original Message----- From: Jay Ashworth [mailto:jra@baylink.com] Sent: Monday, June 11, 2012 11:13 AM To: NANOG Subject: Whither Cometh BCP38?
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?
Some statistics are available at http://spoofer.csail.mit.edu/ Ron
participants (6)
-
Dobbins, Roland
-
Jay Ashworth
-
Justin M. Streiner
-
Matlock, Kenneth L
-
Mikael Abrahamsson
-
Ronald Bonica