|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: dsl providers that will route /24
I won't play your name calling game. > WHAT? If something comes from a customer that doesn't match your filters > for that customer you DROP IT! IT'S THAT SIMPLE! Inconvenience for ONE > customer or ONE customer's customers is MUCH less or a problem than your > customer (or customer's customer) sending traffic from unauthorized > address space! What the heck does that have to do with anything we're discussing? We weren't talking about what you do with it, we were talking about whether you could tell if it was spoofed or not. > (1)You use address space provided by (your company) or: ( > > 2)You use address space that you have PROOF (whois.arin.net, etc) that you > are authorized to use. > > (3)Any packets sourced from address space not fitting the above two > critiria will be DROPPED! Okay, so you have a filter that checks with ARIN? Or does your filter, *surprise* have no way to tell whether a packet is spoofed or not. > It's that simple. Believe it or not, MOST _REAL_ providers use police > very close to what I have outlined. I'm not talking about that. I'm talking about whether it's possible for a filter to tell whether a packet is spoofed or not. > > Regardless of whether I filter or not, the fact remains that a > > filter can't tell a spoofed packet from an unspoofed packet. > Yes you can. You know what the customer is assigned and what they have > told you they will be sourcing from. It's EASY to build a filter to > match. Yes, it's easy to build a filter to match. I never said it wasn't. However, the filter will simply determine whether a packet matches the list of IP address you know the customer is authorized to use. It can't actually tell if a packet is spoofed or not. Get it? A spoofed packet is one that's introduced to the Internet and didn't originate from a machine whose administration is authorized to source that IP on the global Internet. No filter can establish where a packet actually originated, so no filter can tell that. Okay? Get it? A filter cannot determine whether or not a packet is spoofed. Believe me, if a filter really could tell whether a packet was spoofed or not, the problem of ending spoofing would be much, much simpler. > > Here's another misunderstanding: > > > > >> Again, no. A unicast UDP flood can do just as much damage. So > > >> filters do not reduce the damage. > > > > >How's that? The last time I checked, my "are you a customer" filters > > >worked against both TCP and UDP. > > > > Obviously, I was talking about an unspoofed flood. I mention UDP > > because most unspoofed floods (at least, that I've seen) are UDP. It's > > the easiest flood to launch if you haven't root compromised a box. > > David, the only obvious thing here is that you're either clueless or > criminally negligent. (Both may be true.) The above example has no > bearing on this discussion. We're talking (at least those of us with > clue) about filtering packets sourced from address space that is not > assigned to or OK'd to be used by "customer X". And the point I'm trying to make is that an unspoofed attack can do just as much damage as a spoofed attack. So stopping spoofing may or may not reduce the damage an attack does. It all depends upon how long it takes you to stop the attack at its source. > 14649 eh? Why doesn't the high number surprise me? > > 161.211.0.0/16 > > How did you fall into a /16 being so clueless? That's the provider for the particular machine I'm sitting at at 2 in the morning. I have no connection to them (except that I'm a customer). DS
|