Re: [spoofing-tf] Source Address Validation Architecture (SAVA), BOF proposal @ IETF

[Rob Beverly rbeverly@localhost]

On Wed, Sep 13, 2006 at 04:15:18PM -0700, Barry Greene (bgreene) wrote:
> Serious concern to whom? I'm not seeing demonstration that it is a
> concern to people who operate backbones. All we needed was a couple of
> backbones in 2001/2002 to deploy uRPF Strict and ACL based BCP 38 to
> shift the miscreants to primarily use valid IP addresses. 

Spoofing is certainly a concern of the operational network
backbone community; as recently as June of this year, Verisign
presented at NANOG on a particular spoofing-based attack: DNS
amplification.  See:
  http://www.nanog.org/mtg-0606/pdf/frank-scalzo.pdf

for the presentation.  Also see the NANOG archives for a variety
of attacks that rely on spoofing, some very recent and not
limited to denial of service (e.g. spoofing to circumvent
provider filtering in order to send unsolicited email).

> Third, you are ignoring the other BCP 38 tool - DHCP Lease Query, IP
> Source Verify, etc. Please look at documents like
> http://www.cablemodem.com/downloads/specs/CM-SP-SECv3.0-I01-060804.pdf
> DOCSIS 3.0 Specifications which cover Source Address Validation at L2
> and L3.

Yep - we explicitly test for this via our "neighbor spoofing" test
and report the results on our summary web page:
  http://spoofer.csail.mit.edu

> Again, not true. Look at the studies for the sources of DOS attacks.
> Spoofed source addresses are not currently (nor have they been) the core
> contributor. 

Sure, but again, consider the recent DNS amplifier attacks and
filter circumvention attacks (using spoofing to send UCE).  

> > 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.
 
> The same factors that impeded BCP38 deployment on IPv4 are
> going to be the same with IPv6. It is not about technology, it
> is about time and money inside the SP to deploy the capability.
> If there isn't new revenue to pay for the OPEX time, then the
> 'security widget' will not get turned on.

Yes, but IPv6 is perhaps more troubling because the range of
potential neighbor spoofing is much larger - likely on the order
of the space of the entire IPv4 space - given the IPv6 provider
allocation.

Regards,

rob