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.
<quote who="Richard A Steenbergen">
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.
No, no operational issues at all from RFC1918 space....
http://www.as112.net/ (just to drop the most well documented example...)
-davidu
That looks like a 1918 issue to me... Lets be clear about the difference
between a DNS query for 1918 space and a DNS query sources from 1918 space
which can never be returned too.
Yes I'm sure it is annoying, but the questions are:
How much EXTRA load does it really place on the rootservers?
Is it really so much load that you can't just chalk it up to a normal
part of the service being provided?
Or to put it another way:
How much computing power would I need to buy you so that I never have to
hear complaints about queries from 1918 space on a mailing list again? 
Let me put it the ultimate way:
How many routers, linecards, configs, etc.. need to be
upgraded to insure that there is source address validation.
I want to insure that every packet I deliver to my
end-customers is from a real host on the other side. Even if it's
0wned, i want to pass that packet until such time as our
security team is notified and works to mitigate it.
We (AS2914) attempt to insure that packets our customers pass
to our network are from address space they are registered/authorized
to pass.
I know that AT&T (AS7018) does this as well with their
customers.
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.
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..
Router#deb ip cef drops ?
rpf Packets dropped by CEF Unicast RPF
- jared
Tell it to the unfortunate number of people manufacturing customer edge
aggregation boxes which still don't support uRPF.
> > > 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.
I think he just did.
And, perhaps more importantly, he is telling the people who are considering buying such hardware.
And, perhaps most importantly, people should tell transit providers they are considering purchasing transit from that this is unacceptable. (You can consider this my personal notice to all transit providers.)
vixie@vix.com (Paul Vixie) writes:
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".
sorry, i mixed up my numbers. it's only a trickle of queries per second at
any given f-root node. but it sure adds up when you look at all f-root nodes
together, or when you look at all root servers together.