|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: filtering 1918 (was Re: Summary with...: Domain Name System ...)
> > > > Is it really enough traffic that you, as a root server operator, > > > > can't just suck it up and deal? Sure there are going to be a few > > > > folks who are misconfigured, but I can't imagine that it is enough > > > > to cause operational issues. a few folks? no. if it was a few packets now and then i'd say no problem. in the example i posted earlier, i included some numbers from one member of the "f troop", which showed ~21M packets from rfc1918 space over the course of ~106 days. that's 241 queries per second. on only one host of many. granted it's not much as a percentage of the total, but it's not "a few". furthermore, leaking rfc1918 is evidence that a network would also allow ip spoofing, and probably is being used as a spoofed-source attack vector. if we clean up the problems we can prove we're having, then it will make the remaining problems stand out a little better against an uncluttered background. (but i'm sure that a community as robustly steeped in operations philosophy as NANOG doesn't need me to tell them something so elementary-- sorry to "preach to the choir" as it were.) > Let me put it the ultimate way: > ... > We (AS2914) attempt to insure that packets our customers pass > to our network are from address space they are registered/authorized > to pass. thank you! > I know that AT&T (AS7018) does this as well with their customers. thank you at&t! > Anyone that isn't working on this (even slowly) is helping > contribute to part of the problem/mess of rfc1918 sourced packets leaking > to the internet. yes. > While there is a cost on operators of services (eg: Paul/ISC in > f.root ops), it's not just the 1918 sourced packets you should be worried > about, it's the people spoofing others ips... While enabling u-rpf in > one of our pops, i was watching what sources were coming in on the links > to insure that we were not dropping the wrong packets, or the customers > didn't need to really source packets from those ranges.. a lot of > machines were spewing packets from random ips on the other side of the > world (europe, asia) that should not have been coming from machines in > the US behind some random T1 customer.. encore, encore! if BCP38 is too long and complicated for your management to understand when you ask for additional staff or equipment to turn on u-rpf, there's a shorter (4 pages) executive-compatible document that you should print out and staple to your requisition, at <http://www.icann.org/committees/security/sac004.txt>, from which i shall hum a few bars since the "icann" might be a turnoff: SECSAC Paul Vixie, ISC SAC 004 October 17, 2002 Securing the Edge Abstract At every edge of the global Internet are the hosts who generate and consume the packet flows which, together, form the overall Internet traffic load. By number, most of these hosts are not secure, leading to dangerous, untraceable traffic flows which can be used to attack other hosts. This memo describes some of the security problems "at the edge" and makes some recommendations for improvement. ... yes, this really was published four days before a widely publicized global DDoS against the root name server system, which was documented at <http://d.root-servers.org/october21.txt>. this was just a coincidence, but as long as i'm humming songs for y'all, here's the top of this one: ISC/UMD/Cogent Paul Vixie, ISC OCTOBER21.TXT Gerry Sneeringer, UMD November 24, 2002 Mark Schleifer, Cogent Events of 21-Oct-2002 Abstract On October 21, 2002, the Internet Domain Name System's root name servers sustained a denial of service attack. This report explains the nature and impact of the attack, based on previously and publically available information. ... happy homework! and please keep those rfc1918-related / u-rpf related cards and letters coming. -- Paul Vixie
|