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

From: rbeverly at MIT.EDU (Rob Beverly)
Date: Thu Sep 14 21:34:38 2006

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

---

From: pekkas at netcore.fi (Pekka Savola)
Date: Thu Sep 14 23:01:31 2006

> filter circumvention attacks (using spoofing to send UCE).

I'd be interested in seeing more references on the SPAM-spoofing.  I 
assume you refer to hijacking an address space (possibly a bogon, 
possibly in use), sending spam, and switching the prefix continously. 
This is quite different than 'traditional' spoofing because above also 
requires propagation of false routing information instead of simply 
sending bogus packets.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: rbeverly at MIT.EDU (Rob Beverly)
Date: Thu Sep 14 23:55:21 2006

> requires propagation of false routing information instead of simply 

Actually, I wasn't referring to prefix hijacking.  Spammers like
to use botnets.  To combat botnets, providers started filtering
outbound port 25 SYN to everywhere but the provider's MTA(s).  To
combat these filtered hosts, spammers are now doing the following:
  1. find a connection that allows spoofing (e.g. dialup).  Assume
     a host D is on that dialup and under control of spammer.
  2. control a compromised host H on a network that filters outbound tcp 25 SYN
  3. Use the dialup host D to send a SYN to a victim MTA with the source
     address of H
  4. D communicate the initial sequence number to H so that H can
     properly ACK the incoming SYN-ACK (and complete the 3-way
     handshake).

There are other variations of such triangular routing (and attacks)
There have been a few conversations on NANOG about this; the first
one I can find readily is:
  http://www.cctec.com/maillists/nanog/current/msg09179.html

Regards,

rob