In message <[EMAIL PROTECTED]> Fred Baker writes: > > On Sep 20, 2006, at 9:02 AM, James Kempf wrote: > > Here's an idea (which, BTW, I'm not adovocating). ISPs agree that > > if they detect spoofed packets from someone they cut off forwarding > > to/from that AS until the problem is fixed. Really simple and > > modestly straightforward to deploy, but not a technical solution. > > It requires the RIRs and operator associations to issue a policy, > > and the operators to agree to it. > > well, there's the rub. > > If the source address is spoofed, it's pretty hard to say what AS the > packet arrived from. If you can detect the spoofed packet on a link > to a neighboring AS, you could cut off that AS, but you won't know > whether that AS actually allowed it in or whether it has some other > customer that allowed it in. You only know it got to you.
Back to the future. The NSFNET used to collect src/dst network pairs on all outfacing core interfaces. This was easier with classfull routing but doable with classless routing. If the set of source addresses started to vary greatly there was a spoofing attack coming from that interface and the peer provider (or customer) was notified (with threats to shut down peering if no action was taken - the incentive). Rarely making good on that threat, but ready to do so. If it was a customer, they were simply shut down if they didn't respond right away which generally did not draw complaints from the customer (acknowledged to be their fault). Spoofing attacks through the NSFNET could be traced back to the source if reported within 48 hours of the attack. Most spoofed attacks could be detected automatically due to a noticable change in the set of source addresses in the collected data and then dealt with proactively (no customer complaint needed before taking action). This even worked for intermittent senders intending to make it harder to trace. This was in the pre-RPF days. The NSFNET didn't block this traffic, just made it very traceable to the upstream. RPF seems to have been a response to all the NOC overtime resulting from upstream providers without this data collection capability having a difficult time tracing the source further upstream. This was also before widespread DDoS. UUNET used to advocate and practice a similar approach, identifying the target of spoofed traffic and temporarily blackholing traffic to affected destination(s) from offending peers. Again the peer was notified, but not as forcefully. Data collection suitable for this use is still available on many core routers but apparenly it is rarely if ever collected. The only incentive to doing something like this is that clued in customers want something done by their provider when they are experiencing an attack. Lack of response might mean loss of customer. Initially there was good motivation for RPF. What may have changed is that no one in a decade has taken the same hard line approach that NSFNET took in insisting that their peers trace each the problem further upstream and fix it or fix it more permanently with RPF. Those who don't bother with RPF are those that don't have the large customers who are often the target of DDoS attacks. Lack of RPF is tough for providers with these sort of customers if those without them don't bother to do RPF. Its made worse if the problem can't easily be traced to the upstream though that may be for lack of applying an available solution. Curtis _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
