Kill Verisign Routes :: A Dynamic BGP solution

Mailman List Mirror (Read Only)
1

I wanted to discuss the merits of the following:

I have written a proof of concept solution to nuke a route to sitefinder.
Code to those who care or to the list if anyone cares. Perl is your friend
:slight_smile:

Basic concept: Use Net::BGP to set up a peering session with my route
server. Query DNS for *.com and *.net on x interval. Then take the answers
(if they are valid A records) and inject them into the route server (which
in our case is used solely to feed a blackhole network to sink traffic from
APNIC space, etc).

If an address no longer appears in the DNS (i.e. the idiots switched hosts),
withdraw the route. If they set up multiple hosts, it will catch each one
of them. You can set the polling interval as you please.

Thoughts?

Eric

2

I wanted to discuss the merits of the following:

I have written a proof of concept solution to nuke a route to sitefinder.
Code to those who care or to the list if anyone cares. Perl is
your friend
:slight_smile:

Basic concept: Use Net::BGP to set up a peering session with my route
server. Query DNS for *.com and *.net on x interval. Then take
the answers
(if they are valid A records) and inject them into the route server (which
in our case is used solely to feed a blackhole network to sink
traffic from
APNIC space, etc).

If an address no longer appears in the DNS (i.e. the idiots
switched hosts),
withdraw the route. If they set up multiple hosts, it will catch each one
of them. You can set the polling interval as you please.

Thoughts?

  I think the whole idea of getting into an escalating technical war with
Verisign is extremely bad. Your suggestion only makes sense if you expect
Verisign to make changes to evade technical solutions. Each such change by
Verisign will cause more breakage. Verisign will either provide a way to
definitively, quickly, and easily tell that a domain is not registered or
Verisign will badly break COM and NET.

  DS

3

So totallymadeupdomain.com now resolves but is unreachable. That will prevent
you from bouncing emails to non-existent domains immediately..

Steve

4

Thus spake Stephen J. Wilcox (steve@telecomplete.co.uk) [18/09/03 18:54]:

So totallymadeupdomain.com now resolves but is unreachable. That will prevent
you from bouncing emails to non-existent domains immediately..

FWIW, the latest versions of postfix have code in them to block connects
from explicitly listed hosts:

    New check_{helo,sender,recipient}_{ns,mx}_access maptype:mapname
    restriction that applies the specified access table to the NS or
    MX hosts of the host/domain given in HELO, EHLO, MAIL FROM or RCPT
    TO commands.
            
    This can be used to block mail from so-called spammer havens, or
    from sender addresses that resolve to Verisign's wild-card mail
    responder, currently at IP address 64.94.110.11.

  - Damian

5

Which is fine with me/my client base. Since what they are doing is
essentially a MITM attack, the client base I serve and I would rather have
the mail sit in OUR spools for a couple of days, vs. bouncing immediately
with the potential of the mail addresses being harvested. Also, from the
perspective of our "sensitive clients", they would like mistyped URL's with
parameters to be errored out on the browser side, vs being dumped to a
Verisign server with the parameters (potentially usernames/passwords, etc)
possibly ending up in their logs.

Also, whats to keep Verisign from changing the behavior of their mail spool?
Right now, its questionable how it rejects. It would make a neat project to
make a server that accepted the whole message, and THEN bounced it after it
was all spooled/logged. Verisign do something like that? Nahhh, not our
beloved Verisign ....

Eric

From: Stephen J. Wilcox [mailto:steve@telecomplete.co.uk]
Sent: Thursday, September 18, 2003 6:51 PM
To: Eric Germann
Cc: nanog@nanog.org
Subject: Re: Kill Verisign Routes :: A Dynamic BGP solution

<snip>

6

From: David Schwartz [mailto:davids@webmaster.com]
Sent: Thursday, September 18, 2003 6:38 PM
To: ekgermann@cctec.com; nanog@nanog.org
Subject: RE: Kill Verisign Routes :: A Dynamic BGP solution
Sensitivity: Confidential

<snip>

  I think the whole idea of getting into an escalating
technical war with
Verisign is extremely bad. Your suggestion only makes sense if you expect
Verisign to make changes to evade technical solutions. Each such change by
Verisign will cause more breakage. Verisign will either provide a way to
definitively, quickly, and easily tell that a domain is not registered or
Verisign will badly break COM and NET.

  DS

Who said they're logical in their decision making process. While they
experiment with .com/.net, countermeasures are called for. And they have
badly broken .com/.net.

This is just an evolution of the blackhole solution, doing it dynamically.
Keeps us from having to find out they changed it/moved it/etc. And, if
*.com goes away, so does the route :).

7

> I think the whole idea of getting into an escalating
> technical war with
> Verisign is extremely bad. Your suggestion only makes sense if
> you expect
> Verisign to make changes to evade technical solutions. Each
> such change by
> Verisign will cause more breakage. Verisign will either provide a way to
> definitively, quickly, and easily tell that a domain is not
> registered or
> Verisign will badly break COM and NET.

Who said they're logical in their decision making process. While they
experiment with .com/.net, countermeasures are called for. And they have
badly broken .com/.net.

  It's precisely because they may not be logical that I don't think it's wise
to get into an escalation battle with them. Mutually assured destruction
works well when your adversary is logical and very badly when they're not.

This is just an evolution of the blackhole solution, doing it dynamically.

  And if Verisign escalates, do you escalate again? Now you've indirectly
caused a second wave of breakage. And then what? You escalate again for a
third wave of breakage?

Keeps us from having to find out they changed it/moved it/etc. And, if
*.com goes away, so does the route :).

  It would be a major escalation for Verisign to use technological means to
dupe people into again getting to SiteFinder despite their clear, explicit
configuration to the contrary. If you really think such an escalation is
inevitable, then the escalation will be sufficient to defeat whatever
mechanism is deployed at that time. So deploying more complex mechanisms
before that point is pointless.

  If you're hoping to push Verisign into an escalation to use that escalation
for a lawsuit or PR angle, a number of small escalations is better than one
big one. People are already employing means to avoid sitefinder, so if they
think it's worth escalating to get around that, they already have to.

  In any event, Verisign's policy descisions will likely be driven primarily
by actions taken by Microsoft, AOL, and perhaps ICANN and the DOC. The plain
and simple truth is that if you want to use .COM and .NET, you have to trust
Verisign. Sad, but true.

  DS