Disclaimer: I have a dog in this fight, since ThreatSTOP is dependent on
DNS/TCP.
>From: Mark Andrews [mailto:Mark_Andrews@isc.org]
>Sent: Thursday, May 14, 2009 4:59 PM
>To: John Levine
>Cc: nanog@nanog.org; rs@seastrom.com
>Subject: Re: you're not interesting,was Re: another brick in the
wall[ed
>garden]
>
>
>> >Dear Sprint EVDO people,
>> >
>> >Your man-in-the-middle hijacking of UDP/53 DNS queries against
>> >nameservers that I choose to query from my laptop on Sprint EVDO is
>> >not appreciated. Even less appreciated is your complete blocking of
>> >TCP/53 DNS queries.
>>
>> If I were an ISP, and I knew that approximately 99.9% of customer
>> queries to random name servers was malware doing fake site phishing
or
>> misconfigured PCs that will work OK and avoid a support call if they
>> answer the DNS query, with 0.1% being old weenies like us, I'd do
what
>> Sprint's doing, too.
>
> And what's the next protocol that is going to be stomped on?
>
>> If you're aware of a mechanical way for them to tell the difference,
>> we're all ears.
>
> Well you can't answer a TSIG message without knowing the
> shared secret so you might as well just let it go through
> and avoid some percentage of support calls. Intercepting
> TSIG messages is guaranteed to generate a support call.
>
> Similarly intercepting "rd=3D0" is also guaranteed to generate
> a support call. You almost certainly have a interative
> resolver making the query which will not handle the "aa=3D0"
> responses.
>
> Similarly there is no sane reason to block DNS/TCP other than
> they can do it.
>
[TLB:] I can think of an argument they might make: that it is/could be
used by bots as a fallback. However, redirecting DNS/UDP fits the model
of "providing a better service for the average user";
blocking/redirecting TCP is more likely to break things a savvy user
needs.
There is still no sane reason to block TCP. If they are
intercepting DNS/UDP then they need to also intercept DNS/TCP
as they will break all sites that cause "tc=1" to be set
in the DNS/UDP reply.
Maybe someone with clue at Sprint can be persuaded that doing their own
"OpenDNS" for UDP is probably a good thing for most uses, but doing it
for TCP is a bad thing for those users who need TCP.
You can also add to the list of queries that you need to
provide a clean path for any with DO=1, CD=1 or AD=1.
First, since when does it require a "sane" reason to do something?
Second, and more importantly, John is right. Sprint is a for-profit business. If blocking UDP - or TCP or HTTP or whatever - makes them more money than not blocking it, they will do it. And rightly so.
Of course, it is entirely possible management figured out blocking "DNS" was more profitable because the cost savings in lower call center volume more than offset the 4 people who dropped Sprint because of the block. So they told engineers to 'block DNS' and the engineers did that without knowing that blocking TCP port 53 was not more profitable, and perhaps was less profitable. Miscommunications abound between Engineering and Management. This should surprise few, and hopefully no one on NANOG.
Assuming something like that happened, will a post to NANOG fix it? I don't know. Certainly has a non-zero chance. But trying to get Sprint, or any provider, to change because _you_ think what they are doing is not sane is, well, not sane.
"Never appeal to a man's 'better nature,' he may not have one. Invoking his self-interest gives you more leverage."
In '02, I had a similar issue with Comcast, when they silently fired up transparent proxy servers. It became apparent when, while working on a remote web server, I was served up cached copies of the pages I was editing.
My approach was two-pronged. First, I bitched loud and long on some security lists about the MITM attack. Not only was it abusive as it was, the potential for further abuse (tracking, ad insertion, theft of sensitive data and intellectual property...) was significant. Eventually, Ted Bridis of Associated Press picked it up and ran a story. The next day, the issue was on the front page of nearly every newspaper in the english speaking world, and then some, as well as network TV news.
Comcast has a large customer base, particularly in the DC area, and a lot of very influential people (like federal judges) were not fond of having their research and recreational web surfing intercepted.
The proxies went away within a few days, and several jurisdictions passed laws prohibiting this. I'd suspect Sprint is violating some of these laws.
The other approach was; I sent exploit code addressed to one of my machines. Comcast's servers stole this code and choked on it. It's probably not illegal to send malicious code to a machine you own. If they stole it and choked on it, it's their problem. But with the legal system the way it is, you'll just have to use your imagination until the statute of limitations expires.
Assuming something like that happened, will a post to NANOG fix it? I don't know. Certainly has a non-zero chance. But trying to get Sprint, or any provider, to change because _you_ think what they are doing is not sane is, well, not sane.
In '02, I had a similar issue with Comcast, when they silently fired up transparent proxy servers. It became apparent when, while working on a remote web server, I was served up cached copies of the pages I was editing.
My approach was two-pronged. First, I bitched loud and long on some security lists about the MITM attack. Not only was it abusive as it was, the potential for further abuse (tracking, ad insertion, theft of sensitive data and intellectual property...) was significant. Eventually, Ted Bridis of Associated Press picked it up and ran a story. The next day, the issue was on the front page of nearly every newspaper in the english speaking world, and then some, as well as network TV news.
Comcast has a large customer base, particularly in the DC area, and a lot of very influential people (like federal judges) were not fond of having their research and recreational web surfing intercepted.
Then they were silly to think turning off the transparent proxies somehow allowed them not to be tracked.
But then, most "influential people" are, at the very least, ignorant of technology.
The proxies went away within a few days, and several jurisdictions passed laws prohibiting this. I'd suspect Sprint is violating some of these laws.
You gave them a business reason (cost more to keep them then turn them off) to change their mind. Good for you. I doubt the same is true for Sprint modulo the laws you mention. And I'm wondering what laws these are, since intercepting port 43 is an extremely common practice.