Re: [ga] On Its Way: One of the Biggest Changes to the Internet

[Karl Auerbach <karl@xxxxxxxxxxxx>]

Prophet Partners Inc. wrote:

> With the potential problems from long IDN names, could poorly configured 
> DNS applications possibly create situations of DNS instability? Could 
> criminal or terrorist organizations launch DoS attacks in this manner?
Well, that's a tricky question.

In most cases, people who create long nasty names, as I did in the 
examples I put on the list a few minutes ago, tend to end up hurting 
themselves by making themselves unreachable by others.
But not always.

Of course there are the look-alike issues - 0.tld versus O.tld; which 
one is the real Overstuck?
I've been playing a lot in the world of SIP based VoIP.  SIP, like DNS, 
tends to allow a lot of hidden interactions - DNS uses a hierarchy of 
hand-offs of resolutions while SIP tends to operate via a sequence of 
relays.
A difficult attack using DNS would be to answer a DNS query for a SIP 
target with the address of a sort-of-stealthy proxy that forwards the 
SIP traffic, but monitors or manipulates it or causes the RTP voice 
packets to also go to a sort-of-stealthy monitoring relay.  This would 
be hard to do, but with the right juggling it is actually feasible, but 
just barely, even at the DNS root level.  (And consider that some of our 
root servers are operated by US governmental agencies that might have a 
reason to want to spy on certain VoIP calls.)  This attack is, as I 
said, very hard because you need to know which query to give a bad reply 
to, and the monitoring proxy isn't really all that stealthy to anyone 
who is really watching.
But on the other hand, denial of service is a wonderful attack method 
when one is trying to cause confusion while engaging in another form of 
attack.  But again, DNS attacks often require one to get a toehold into 
a privileged place in order to have an affect.  But then again, there 
are so many places to get toeholds - from DHCP to ARP to unprotected 
routing protocols, etc.
IDN names in and of themselves do pose a risk of increased buffer 
overrun issues - code will be seeing longer names than has frequently 
been the case.
Another issue caused by length of IDN names is that query interactions 
may have to shift from UDP to TCP - that's from two packets/one round 
trip time to about 10 packets and somewhere from two to four round trip 
times, a substantial increase in net load, not to mention the fact that 
a DNS server's TCP stack will have to maintain state for those TCP 
connections, including the dreaded close-wait state.
In other words, IDN's could push a DNS server or its links into overload 
by causing queries to move from UDP to TCP.  What's the degree of that 
risk? I dunno.  Again it's a denial of service thing rather than a 
direct attack.
IDN's have an indirect affect on those of us who have to repair networks 
- we tend to see the world through packet captures and other low level 
tools.  IDN's are going to add one more layer of complexity.  Whereas 
today I can look at a traceroute printout and kinda grok the meaning of 
the host names on the path, in an IDN world, it will look like 
gibberish.  Problem isolation might take longer until the tools evolve. 
 And given that most people are still using primitive ping as their 
primary tool, my hopes for tool improvement are not high.  (I founded a 
company about 12 years ago to build better tools, and we did good things 
technically, but other bad things trumped those; long live Empirical 
Tools and Toys [ETNT] and Dr. Watson the Network Detective's Assistant!)
                --karl--