Subject: Call For Participation and Interest: Source Address Validation Architecture (SAVA)

From: Mark Williams <[email-masked]>
Date: Tue, 12 Sep 2006 15:47:13 +0800

All,

We are calling for interest and participation in a project to devise a 
framework architecture and solutions to the problem of validation of 
source addresses in IPv6 networks in order to protect network 
infrastructure from address spoofing attacks.

The effort is based on the current situation that it would seem that, at 
least as things currently stand, it is unlikely that spoofed source 
addresses will be able to be excluded from the Internet backbones unless 
some further solutions and practices are put into place.

The SAVA effort has roots in research and development to that end for 
IPv6 networks currently being undertaken at Tsinghua University in 
Beijing. A number of papers have been published and code has been 
written, which will be going into test on the CERNET-II backbone in the  
not-too-distant future. We seek the participation and assistance of the 
wider Internet community in order to create a framework of practices and 
solutions which will be deployable on a much wider basis.

A (condensed) draft problem statement is included inline below, and a 
framework document is in early draft.

We will be proposing a BoF session at the upcoming San Diego meeting.

A document repository for drafts and other documents is available at:
http://narl.tsinghua.edu.cn/sava/

An interim mailing list
[email-masked] <mailto:[email-masked]>
has been created and can be joined by going to:
http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava
an archive is also available at the same address.

cheers,

Mark
-----------------------------------------------------------------------------------------------------------------------------------
----------------------------------------------------------------------------------------------------------------------------------

    Problem Description:

      Introduction

In the MIT Spoofer Project, the authors found that approximately 
one-quarter of the observed addresses, netblocks and autonomous systems 
(AS) permit full or partial spoofing.  And they suggested that a large 
portion of the Internet is vulnerable to spoofing. Concerted attacks 
employing spoofing remain a serious concern.

The current method of avoiding packets with spoofed source addresses 
entering and being propagated on the Internet relies on two methods:

a)       Ingress Filtering as per BCP0038 [RFC2827].  This method 
requires    ISPs and organisations at the edge to apply filters limiting 
the    source addresses allowed on incoming packets to those    
specifically allowed in the stub networks.  If BCP0038 were    followed 
at all ingress points to the Internet, then there would    be no spoofed 
packets on the Internet.

b)       Unicast Reverse Path Forwarding (uRPF) filtering.  This is a 
feature available on routers that can be used to block incoming packets 
if, in the case a packet were constructed with the incoming packet's 
source address as its destination address, the constructed packet would 
NOT be routed back along the ingress link for the incoming packet.

Ingress filtering is definitely to be recommended, and uRPF filtering 
certainly does have its uses, but, at least in the current state of the 
Internet, they are insufficient as a protection for the routing 
infrastructure.

a)       Ingress filtering works, but it only works if all, or at least 
the vast majority of ingress points apply ingress filtering.  As can be 
seen in the Internet today, even when 25% of the Internet is unsecured, 
those elements that want access to "spoofable" connections simply move 
their connection to unsecured attachment points.

b)       uRPF does not work well in places where asymmetric routing 
happens.  This constitutes a large part of the Internet

There are many proposed  mechanisms related to the validation of source 
IP addresses, but few of them are widely deployed by the current 
Internet. While it is possibly too late to introduce adequate source 
address checking in the current IPv4-based Internet, the development of 
the next generation Internet using IPv6 gives us the opportunity to 
implement an architecture for effective source address checking.

      Why IPSEC is not the Solution to This Problem

IPSEC is a solution to many problems, and it is not the intention of the 
authors to suggest that it should not be deployed.  It is just not the 
solution to this particular problem.

Whereas IPSEC solves end-end security problems and allows endpoints in a 
connection to verify the identity of other connected endpoints, there is 
also a need for the infrastructure of the Internet to be able to protect 
itself. Many attacks employ spoofed IP addresses either to conceal the 
source of an infrastructure attack or to cause the network 
infrastructure to, in effect, attack itself.

The network must be able to secure itself from poorly-secured 
endpoints.  The goal of the solution to the problem must be to discard 
spoofed traffic as close to the source of the attack as possible. (i.e. 
within the infrastructure rather than at the other endpoint(s).

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Sep 2006 15:49:24 +0200

On 12-sep-2006, at 11:25, Pekka Savola wrote:

>> Ingress filtering is definitely to be recommended, and uRPF  
>> filtering certainly does have its uses, but, at least in the  
>> current state of the Internet, they are insufficient as a  
>> protection for the routing infrastructure.

> If this refers to ensuring that your own routing infrastructure is  
> secure, I argue this can already be achieved by appropriate edge  
> filtering at your own borders.

All of this assumes that it's a good idea to authenticate  
correspondents in interactions such as routing protocols solely based  
on the IP address they present. The fact that this "authentication"  
is trivially subverted by source address spoofing which is something  
that's easy to do in today's internet, suggests to me that this is a  
fundamentally broken approach.

Even if we assume that all ISPs do source address validation on  
packets that they receive from their customers, there are many ways  
to work around this. You'd basically have to require SEND for ALL  
subnets connected to the internet, but since this is something that's  
handled locally there is no way an ISP or a real authority would be  
able to know for sure this is done correctly. And obviously it's  
possible to subvert ISP infrastructure. There are so many ISPs that  
this alone is enough of a risk to invalidate the assumption that  
source addresses can be trusted.

> On the other hand, if this refers to generic routing infrastructure  
> security, it isn't obvious how a source address validation proposal  
> would significantly improve the current situation.

Routing protocols and the like are generally run within  
administrative boundaries where it's possible to filter out unwanted  
packets coming from elsewhere so source address spoofing shouldn't be  
an issue today.

The exception is BGP, which is used to talk to external networks.  
Although there are some weak areas in implementations here that allow  
an attacker to run up CPU usage on most routers, techniques such as  
the BGP TCP MD5 password and GTSM should be sufficient to thwart  
spoofing attacks.

>> b)       uRPF does not work well in places where asymmetric  
>> routing happens. This constitutes a large part of the Internet

> This is a common misconception.  Maybe you haven't seen RFC 3704  
> (BCP 84) which describes how to do it. For more detail, also look  
> at draft-savola-bcp84-urpf-experiences-01.txt.

Current uRPF allows you to reject traffic that doesn't come from a  
single known "good" source, which isn't useful if legitimate traffic  
can come from more than one source (= interface), which is the most  
common situation in larger networks for non-customer sources. An  
alternative is "loose" uRPF which only rejects packets witch sources  
that don't appear in the routing table, which doesn't apply to  
attacks where the address of a working host is spoofed. I understand  
that there is work underway to allow uRPF with multiple sources but  
we'll have to see how well that works in practice. (One issue would  
be that it requires additional FIBs that could grow quite large.)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 14 Sep 2006 15:55:54 +0200

On 12-sep-2006, at 16:31, Jun Bi wrote:

> DDoS attacks is a cross-layer problems, so the DDoS prevention is  
> out of SAVA's scope.

So what's the use then? Non-DoS related source address spoofing is  
easily thwarted by doing a return routability check that contains a  
hard-to-guess nonce.

The way it looks here, the focus of SAVA is so narrow that I can't  
see how it's worth the effort.