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

From: "Barry Greene \(bgreene\)" <[email-masked]>
Date: Thu, 14 Sep 2006 11:43:32 -0700

> > E) There isn't any perceived new revenue to the network 
> generated from 
> > turning on sources address policing.
> >
> > "E" is the #1 reason I've run into with SPs for not 
> deploying source 
> > address policing.
> >
> Agreed. In fact, if there was some way to make the 
> application of source address policing in some way a /sine 
> qua non/ for any ISP with end customer connections, then I 
> think we would be most, if not all  of the way there. Indeed 
> one of the goals of SAVA would be to significantly increase 
> the incentive to apply source address filtering.

The SPs who do this do have it as part of their default config for new
customers. But that would not get it turned on the interface by default.
How do you know POS 0/0 is a customer interface? You don't. Even if you
could solve that, SPs who dive into BCP38 often have to get their AUPs
changed with their customer contracts. 

BCP 38 techniques for IPv4 translate to IPv6. ACLs, uRPF Strict Mode,
DHCP Lease Query, and IP Source Verify all work with IPv6 addressing (it
is just a matter of coding priority). Hence, you will not get any faster
deployment of BCP38 than you have today.

Now Prec/DSCP recoloring - that is a different issue. As soon as a
miscreant figures out how to extort an SP's IPTV service cause a BOTNET
is configured to blow the pay per view away during the superbowl, then
you will get an incentive to do BCP38++ (source IP, MAC, and Prec/DSCP
recoloring).

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area