|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: dsl providers that will route /24
On Fri, 30 Mar 2001, David Schwartz wrote: > I don't know if you're just not reading what I'm writing or if we're > speaking different languages or what. We're totally talking past each other. I'm not misreading anything. I'm reading what you have written which is (reading between the lines) "I'm too lazy to keeo track of what IP space my customers use or will be originating traffic from..." > > Here's one misunderstanding. I wrote: > > > > ... the problem is there's no good way to tell a spoofed > > > packet from an unspoofed packet. > > You wrote: > > > Um, David... Do you actually READ the list or do you just randomly > > reply? Here's a clue for you. > > > > 1) Require that your customers notify you of any source addresses that > > they'll be using *PRIOR* to allowing them through. Tunneling is MUCH > > more rare than spoofing. > > > > 2) Require that your customers (BGP speakers) register their networks in > > RADB or whichever database you choose. (Don't worry. From the sounds of > > it, NONE of us want your customers...the spoofing [email protected]$tard$...and as such, > > we're not really interested in who they are beyond filtering them.) > > Now, I think you considered what I quoted from you above as replying to > what I quoted from me above. However, neither of the two things you stated > makes it any easier for me to tell if a packet is spoofed or not. 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! > The statement of mine that you were attempting to reply to was, > "there's no good way to tell a spoofed packet from an unspoofed > packet". And I've already made it clear that by "spoofed", I mean a > packet that didn't originate on a machine administered by someone > authorized to use that IP address on the public Internet. > > I get a packet with the origin IP address '206.4.2.1'. How do I tell > whether the packet is spoofed or whether it actually originated at the > machine authorized to use the IP address '206.4.2.1'? Perhaps a dialup > machine on my customer's LAN was assigned that IP address from another > provider. > OK. It's apparent from your arguement that you are not a transit > AS. Here's the simple answer for you: (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! It's that simple. Believe it or not, MOST _REAL_ providers use police very close to what I have outlined. > 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. > 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". > This is rapidly degenerating from a discussion of network > operations into a series of personal attacks. I agree. I've already wasted too much of my time on you. You're obviously too arrogant/clueless to effect the changes necessary to remove your network from the ever growing list of connected networks that make up the Internet. I reply only in hope that others will see the error of your ways and not be pointed out a myself and many others have done to you. 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? > DS Coming closer but, still not going there... --- John Fraizer EnterZone, Inc
|