RE: On-going Internet Emergency and Domain Names

Mailman List Mirror (Read Only)
1

[In the message entitled "RE: On-going Internet Emergency and Domain Names" on Mar 31, 15:26, Matt Ghali writes:]

> So very clever.
>
> If you're not part of the solution... etc.

I feel so worthless standing next to you, the Solver.

Guys.

We *all* (everyone reading this) have a role to play in dealing with problems
on the Internet. There is *no* "one true solution" to what amounts to
criminal activity - not on the Internet, and not in real life.

We, collectively, have enabled a new frontier of civilization. The Internet
is ever growing and changing, and we, collectively, need to address problems
as they come up.

The dominant OS vendor is currently part of the issue, certainly. But if that
dominant OS vendor were (insert your favorite UNIX OS vendor), the same
problems would exist.

We are not fighting technology. We are dealing with very well organized,
smart, and well-funded people.

We need to focus on solutions that we can deploy, which will address the
problems at hand, as we discover them. That means we will deploy things that
do not solve underlying prolems, but address the symptoms as best we can, to
prevent the entire mess from falling down.

That means that we must look at short-range solutions to address things
in near-real-time, and we need to look at changing the legal system
to catch up. We also need to look at the policies which enable people
to abuse the systems we have deployed. And we need to look at user education.
And fixing the operating systems. And improving infrastructure, so we
can deal with 15 Gbps attacks. And...

There is no "one true solution" to this. That means you, as network
operators, need to look at what makes sense *today*, and *DEPLOY IT*.

"Someone else" isn't going to solve these issues, and waiting for them is
folly. Do what you can, today, to address the problems you know about. Do
what you can, today, to protect your users. Do what you can, today, to stop
malicious behaviour from leaving your network. Do what you can, today, to
improve your internal organization to ensure that these task can be done
without a 6 month delay.

Please - we all need to work on this together. But we need to do it now.

2

From: dlr@bungi.com (Dave Rand)

...

We are not fighting technology. We are dealing with very well organized,
smart, and well-funded people.

We need to focus on solutions that we can deploy, which will address the
problems at hand, as we discover them. That means we will deploy things
that do not solve underlying prolems, but address the symptoms as best we
can, to prevent the entire mess from falling down.

That means that we must look at short-range solutions to address things in
near-real-time, ...

There is no "one true solution" to this. That means you, as network
operators, need to look at what makes sense *today*, and *DEPLOY IT*.

...

As Dave is certainly aware (as CTO of Trend Micro, which bought MAPS/Kelkea),
his daytime employer has a product (called ICSS, and which I had a hand in
building) that proposes to let enterprises or ISP's use recursive DNS as a
delivery mechanism for security policy (like, "poison this malware domain").

I've got no heartburn about deploying these technologies at a customer level,
but my experience with both BIND's "check-names" facilty and VeriSign's
sitefinder wildcard (*.COM) have taught me that it's best to creatively
rulebreak at the edge, and keep the core pristine. I helped Dave build ICSS
and I know that customers of that technology could easily white-out domains
used for Gadi's 0-day and that it would be a good thing for them to do so.

But, that's the DNS "edge", I'm not ready to see the DNS "core" gain features
like this. Or if they do come, I'd like them to come as a result of consensus
driven protocol engineering (like inside the IETF) and take longer than "this
week" to be defined. I hope this clarifies the incompatibility between me
helping dave build ICSS (an edge solution) and me saying that whiting out
malware domain names as a way to stop malware isn't a real (core) solution.

Some references to ICSS, in case you all missed it. (Note that I am not an
employee, shareholder, representative, or agent of Trend Micro and I have no
financial stake in ICSS at this point.)

http://www.trendmicro.com/en/products/nss/icss/evaluate/overview.htm
http://www.eweek.com/article2/0,1895,2020286,00.asp
http://www.vnunet.com/itweek/news/2164897/trend-appliance-sniffs-bot-nets
http://www.computerwire.com/industries/research/?pid=2E16BA11-5976-42B0-9C13-EC19B10DB2F3

3

I've got no heartburn about deploying these technologies at a customer level,
but my experience with both BIND's "check-names" facilty and VeriSign's
sitefinder wildcard (*.COM) have taught me that it's best to creatively
rulebreak at the edge, and keep the core pristine. I helped Dave build ICSS
and I know that customers of that technology could easily white-out domains
used for Gadi's 0-day and that it would be a good thing for them to do so.

The problem that I think you fear is that DNS is 'basic plumbing' (the
ICANN-SSAC had some term like this, which sticks in my head as 'basic
plumbing'...) and that messing with it where there is low confidence of
knowing WHY it's being used is not smart, or hazardous, or probably going
to cause larger problems.

On this I too agree, unless you can clearly scope your userbase and
clearly be accountable for the problems that may arise, messing with basic
plumbing is a bad, bad plan. The 'dns core' could be 'provider recursive
servers' or 'TLD servers' or 'root servers' or some combination of these.
As you move closer to the 'core' the userbase gets wider and more varied,
their intent is not divinable in their requests and there's likely a
higher chance you'll be doing something 'wrong' with their request if you
dont' stick to the 'standards compliant' answer.

But, that's the DNS "edge", I'm not ready to see the DNS "core" gain features
like this. Or if they do come, I'd like them to come as a result of consensus
driven protocol engineering (like inside the IETF) and take longer than "this
week" to be defined. I hope this clarifies the incompatibility between me
helping dave build ICSS (an edge solution) and me saying that whiting out
malware domain names as a way to stop malware isn't a real (core) solution.

Right, ICSS should be used (in your example) as close to the 'edge' as
possible... or that's the intent of it, right? Let enterprise folks use
these things, they have attentive helpdesk/admin folks to unscrew what the
changes in basic plumbing have screwed up :slight_smile:

4

I agree with everything else you said, and being the guy who made up the
term I believe in using DNS for detecting botnets in enterprise networks,
etc.

But building a wall to protect your port from attacks by pirates will not
make the pirates go away, and unfortunately, we can't convince everybody
to build walls and our security is nwoadays dependent on others'.

  Gadi.

5

If you consider the possibility that you can never make the pirates go away, building walls sounds like sensible advice.

Joe

6

> But building a wall to protect your port from attacks by pirates
> will not
> make the pirates go away, and unfortunately, we can't convince
> everybody
> to build walls and our security is nwoadays dependent on others'.

If you consider the possibility that you can never make the pirates
go away, building walls sounds like sensible advice.

You got me there. I will add:
"You can NEVER make the Pirates go away" but;
"You can make sure they never enter your seas"

Enough analogies though. :slight_smile:

7

You got me there. I will add:
"You can NEVER make the Pirates go away" but;
"You can make sure they never enter your seas"

At which point, they take to land. The real issue at heart here is that some
people wish to pursue evil means, and will change tactics and seek out
weaknesses wherever they may find them. Today it might be weak verification
of domain registry infrastructure, tomorrow it might be exploiting some p2p
network.

As has been repeated already, creating a fix in one technology will just
force the would-be criminal to use another. The only real solution here is
to make fewer criminals, and your only chances of that are to have more
effective means of prosecuting them. In that aspect, I'm afraid we are quite
a long way off, and will still always be a reactive process as opposed to a
proactive process. The only hope is that it would deter future riffraff
(though you could argue, such as with the pirate analogy, they will just
find new avenues of attack).

8

so, what exactly is the problem with registrations? One of the problems I
see is with a seeming lack of follow-through on fraudulently purchased
domains. Another is a seemingly long time to remove domains that are 'up
to no good'.

Taking out of this problem space the 'domain tasting' or 'domain kiting'
issue (which is really a use of loopholes there for consumer
protection...)

If you look at the domain registration system as a legacy process, what
would you do differently if re-inventing it? That, it seems to me, is
likely the best path forward. Take your opinions/options and get them
codified into new policy for registries/registrars to follow. With every
relatively static and relatively open set of policies eventually
bad-actors will find a set of loopholes or vulnerabilities to get their
job done. It seems that re-evaulating the polcies/procedures/requirements
would be useful in this matter.

-Chris

9

so, what exactly is the problem with registrations? One of the problems I
see is with a seeming lack of follow-through on fraudulently purchased
domains. Another is a seemingly long time to remove domains that are 'up
to no good'.

Agreed with on both points. See below for view of the problem.

If you look at the domain registration system as a legacy process, what
would you do differently if re-inventing it? That, it seems to me, is
likely the best path forward. Take your opinions/options and get them
codified into new policy for registries/registrars to follow. With every
relatively static and relatively open set of policies eventually
bad-actors will find a set of loopholes or vulnerabilities to get their
job done. It seems that re-evaulating the polcies/procedures/requirements
would be useful in this matter.

Absolutely, we should always be re-evaluating our policies to verify they
are up to meeting todays demands. The unfortunate side of this is, it may
end up increasing costs. If we cut down on the automation of domains, and
had more respect for what ends up in the TLD/root servers, perhaps it would
cut down (note: cut down does not imply eradicate) DNS abuse. The process
should be more akin to requesting more IP space. If we treat DNS space as an
unlimited resource, and give it away for a couple of bucks per year, its
much easier to abuse. However, if you had to justify your usage and naming,
and have a human actually process that request, perhaps it would cut down on
bogus registrations. Though, as I've mentioned already, once DNS becomes
sufficiently difficult to abuse, said bad-actors will just pursue other
methods, and we will be left with an overzealous registration process that
costs entirely too much.

10

You got me there. I will add:
"You can NEVER make the Pirates go away" but;
"You can make sure they never enter your seas"

Enough analogies though. :slight_smile:

The Flying Spaghetti Monster is not at all happy about this talk of stopping pirates. He will likely smite you all with his noodly appendage.

RAmen.

-Don