|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: dsl providers that will route /24
> But the *unspoofed* packets are traceable. The victim can pick > up the phone > and call your operations and alert them. If they were spoofed, they wouldn't have to because we'd already be investigating. And even if they're not spoofed, you can't know they're not spoofed, so there's no way to know you got the right person. > > Odds are, an attacker will used spoofed packets if he can. > > potentially > > spoofed packets will trigger an investigation on my network. An > > unspoofed > > UDP flood probably won't (especially if it hops from victim to victim). > Some of us that have been flooded don't appreciate playing the > odds that the provider of the flooder will notice. Right, that's why every provider has to come up with some reasonable way to deal with this problem. Filtering is one, but it doesn't solve the whole problem. Monitoring is one, but it doesn't solve the whole problem either. > > So if the attacker uses spoofed packets, he may get cut off > > at the source > > (and the problem actually solved) sooner. On the other hand, unspoofed > > packets will probably trigger a call to the administration of the > > source > > network faster. Of course, you don't know that attack is > > unspoofed, so you > > really can't be sure what the source is. > > No, but it gives a good indication. And your NOC can find out if > the packets > are actually coming from your customer (unspoofed) or not > (spoofed). If its > unspoofed then we're on the phone to the right people. If its > spoofed, we're SOL. Well that's the real problem. Every attack is potentially spoofed and there are no good tools for dealing with spoofed attacks. Filtering doesn't solve either of those two problems. > > The important thing to realize is that neither of these > > situations is > > ideal. That is, filters don't solve the problem. We need to > > acknowledge that > > we have a problem and don't have a solution to it. Only then will the > > problem be analyzed, solutions proposed, and implemented. > > Filters mean "least damage". Again, no. A unicast UDP flood can do just as much damage. So filters do not reduce the damage. > > I don't know, I'm not smart enough to solve the problem by > > myself. All I > > can do is keep yelling as loudly as I can that there is a > > problem and that > > we do need a really good solution. > > And until we get a really good solution, a really good workaround is not > letting spoofed packets into your network from your customers. Exactly -- the problem is there's no good way to tell a spoofed packet from an unspoofed packet. Some form of source authentication would solve that. DS
|