Subject: [SAVA] Re: [Int-area] Call For Participation and Interest:SourceAddress Validation Architecture (SAVA)

From: junbi at tsinghua.edu.cn (Jun Bi)
Date: Thu Sep 14 23:05:18 2006

Hi Ijitsch and Gunter,

I fully agree that DDoS avoidance is a very important issue,
if SAVA can successfully resolve the problem of source address 
(based on existing mechanisms and some new mechanisms)
then other WG can work on top of SAVA to resolve DDoS, to design trust identifier
 (based on trust/traceable infurstrucre) and resolve SPAM. 

I just wonder how many goals we should put into a single WG. 

Regards,
Jun

----- Original Message ----- 
From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>; "Jun Bi" <[email-masked]>
Cc: "IETF IPv6 Mailing List" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Thursday, September 14, 2006 10:01 PM
Subject: RE: [SAVA] Re: [Int-area] Call For Participation and Interest:SourceAddress Validation Architecture (SAVA)

> DDOS avoidance is quite high up my list of priority also... I would be
> additionally interrested in a mechanism that would identify the attacker
> or identify sources of SPAM.
> 
> G/
> 
> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Thursday, September 14, 2006 3:56 PM
> To: Jun Bi
> Cc: [email-masked]; Pekka Savola; [email-masked]; IETF
> IPv6 Mailing List; [email-masked]
> Subject: Re: [SAVA] Re: [Int-area] Call For Participation and
> Interest:Source Address Validation Architecture (SAVA)
> 
> 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.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> 
> _______________________________________________
> SAVA mailing list
> [email-masked]
> http://www.nrc.tsinghua.edu.cn/mailman/listinfo/sava

---

From: curtis at occnc.com (Curtis Villamizar)
Date: Mon Oct 9 17:36:52 2006

In message <[email-masked]>
Per Heldal writes:
>  
>  
> On Wed, 2006-09-27 at 12:41 -0400, Curtis Villamizar wrote:
> > In message <[email-masked]>
> > Iljitsch van Beijnum writes:
> > > =20
> > > Now if this proposed wg can find a way for me to recognized spoofed =20
> > > packets when they enter my networks without cooperation from the =20
> > > source and intermediate networks, I'm all ears.
> >=20
> >=20
> > Create a filter at each ingress to your network taking unassigned (and
> > optionally also unreachable) address space.  The minimal data
> > collection is incrementing a counter.  You may also want to blackhole
> > the traffic with invalid source address but you don't need to do that
> > to do the data collection.  Just counting the filter hits may be all
> > you want to do.  If you see a spike in that traffic, notify the peer.
> > If they do the same, it leads back toward the source of spoofed
> > attacks.=20
>  
> That's not the universal method Iljitsch asked for. What about attacks
> spoofing the victim (valid address), using reflection and/or
> amplification through services like e.g. DNS?
>  
> Methods like the detection and peer notification you describe involve
> manual operations. That's nowhere near the sub-second response-times
> you'd expect from modern network services.
>  
> //per

OK.  You are looking for a test that can be made at forwarding time -
sort of a "perfect RPF".  Unfortunately assymetric routes may make a
perfect RPF infeasible.

For the above cases, for your single homed direct customers you can
not accept traffic with their source addresses but soon this becomes a
rather large and hard to maintain filter.  Maybe if you had a "single
homed customer" BGP community you could install RPF-like filters
blocking traffic with source addresses for each prefix with this
community and protecting your own single homed customers.

Does that help?

Curtis