RE: [spoofing-tf] Source Address Validation Architecture (SAVA), BOF proposal @ IETF
-
To: "Rob Beverly" rbeverly@localhost
-
From: "Barry Greene \(bgreene\)" bgreene@localhost
-
Date: Thu, 14 Sep 2006 08:13:43 -0700
-
Authentication-results: sj-dkim-3.cisco.com; header.From=bgreene@localhost dkim=pass ( sig from cisco.com verified; );
-
Cc: "Jaap Akkerhuis" jaap@localhost, spoofing-tf@localhost, sava@localhost
-
Dkim-signature: a=rsa-sha1; q=dns; l=4318; t=1158246835; x=1159110835; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bgreene@localhost z=From:=22Barry=20Greene=20\(bgreene\)=22=20bgreene@localhost |Subject:RE=3A=20[spoofing-tf]=20Source=20Address=20Validation=20Architecture=20( SAVA),=20BOF=20proposal=20@localhost X=v=3Dcisco.com=3B=20h=3DTuCDdE2/FO9Kl5NtTbo7ovR7CaU=3D; b=NymYs0iJRkR2vFcZsIYP1rIy9uZvYzW9YtnLvYjng7jJ0kk3b6S5TNAJa2fdsWx7BkOMZKZe 31vfYjSrC0GEFtUamzGl2/YsSV16osUtfSb0zIz2FRhIY4juzH4OSyMw;
[Breaking the reply apart for easier conversation.]
> > > b) uRPF does not work well in places where
> asymmetric routing
> > > happens. This constitutes a large part of the Internet
> >
> > Not true. uRPF Strict Mode together with RFC1998++ covers
> 80% - 95% of
> > your lease line customer base. The deployments in major
> carriers have
> > validated these figures for uRPF Strict + RFC1998++ over
> and over again.
>
> I find this surprising and would be interested in any further
> data you have. In the core of any reasonably complex network
> topology, particularly those of backbone providers, uRPF
> doesn't work because of routing asymmetry. Even at the edge,
> customer multihoming is becoming more prevalent. Our
> measurements - and the success of the recent DNS amplifier
> attacks for example - indicates that a fraction of ISPs do
> not block spoofing (whether through uRPF or ACLs or radius
> ACLs). Finally, uRPF is not going to prevent spoofing
> addresses within the same subnetwork as the routing advertisement.
RTFM BCP 38. Please point out the phase where it says BCP 38 checks are
done in the core of a network.
Honestly I find this convoluted excuse for not using uRPF Strict mode as
a tool for BCP 38 really lame. Read the doc and understand how it work.
1. BCP38 uRPF Strict Mode with RFC1998++ style of multihoming (a BCP for
multihoming) WORKS WITH ASYMMETRICAL ROUTING. It is operationally
deployed and working since 2002. So cut the nonsense about "uRPF doesn't
work because of routing asymmetry." This was all documented back in 2001
in the ISP Essentials whitepaper (Google for version 2.9) and the book.
2. Know that there are four algorithms for uRPF - Strict Mode (check
source IP and adjacency), Loose Mode (check only source IP), Feasible
Path (check source IP with the FIB's alternatives), and VRF Mode
(permit/deny check on source in a separate table from the FIB). So when
you say "uRPF," please be explicit in which mode and how you plan on
using them.
-> uRPF Strict Mode - BCP38 on the edge and sRTBH (Source Remote
Trigger Black Hole)
-> uRPF Loose Mode - sRTBH anywhere in the network
-> uRPF Feasible Path - sRTBH anywhere in the network
-> uRPF VRF Mode - BGP based Peering Policy Enforcement or more
granular sRTBH
(NOTE VRF Mode might be used as BCP38, but is has not been
operationally proven)
3. "Even at the edge, multihoming is becoming more prevalent" is a
statement that was true when BCP 38 was written. This is why so much
work went into figuring out how to deploy uRPF Strict mode in a
multihoming environment. All source based checks need to assume
multihoming. IPv6 has a general expectation of multihoming (which leads
to FIB overload - but that is another problem).
4. "uRPF is not going to prevent spoofing addresses within the same
subnetwork as the routing advertisement" is a statement I don't get.
Strict mode works perfectly fine for BCP38. The original code even
blocked self pings from the PE router - which we later added a knob so
SPs can troubleshoot.
5. Finally - you do not have to do BCP38 everywhere to have an impact on
cyber criminal psychology. The few deployments of BCP38 done in 2002
(ACL and uRPF Strict Mode based) had an impact. Principle #2 for the
Miscreant Economy is "Don't work too hard." So deploying just enough
BCP38 has the miscreants sending out non-spoofed packets. This concept
of attacking the "criminal psychology" is one of the core principles to
crime prevention. It applies to BCP38 just as pulling police on every
street corner is not a universal practice in the world. The cost of
deployment do not out weight the benefits.
I've been helping SPs deploy BCP 38 (all the techniques) since 2001,
created several of the techniques, encourage other to innovate BCP38 and
pushed that innovation to deployment, and one of the strongest advocates
of checking the validity of a packet entering a SP's network (source IP,
source MAC, and prec/DSCP). But I'm also a realist. You do not need it
everywhere to impact day to day criminal activities. The cost and time
it takes to engineer and deploy BCP38 do not out weight the benefits
gained.
