F.ROOT-SERVERS.NET moved to Beijing?

Sun Oct 2 23:06:44 UTC 2011

In a message written on Sun, Oct 02, 2011 at 05:30:37PM -0400, Todd Underwood wrote:
> i guess my questions now are:
> 
> 1) how long was this happening?
> 2) can any root server operator who serves data inside of china verify
> that the data that they serve have not been rewritten by the great
> firewall?
> 3) does ISC (or <Insert Root Operator Here>) have a plan for
> monitoring route distribution to ensure that this doesn't happen again
> (without prompt detection and mitigation)?

I can't answer #1 with precision yet, but will attempt to get a
precise answer soon.

I'd like to partially address #2 and #3.  ISC can verify that the
responses sent from F-Root boxes are always the same, regardless
of which server returns the answer.  That is, there is no filtering
or rewriting on any ISC root servers.

We do know there are a number of locations around the world that
have various rewriting and blocking systems employed.  We have found
networks where a query sent to F-Root never reaches an ISC run
server.  As a root operator we hate this, and believe the best way
to solve the problem is DNSSEC.  Short of providing a method like
DNSSEC to verify the answer is legitimate, we know of no other
countermeasure.  There are in fact networks in the world that
impersonate all 13 root servers, and we don't know of a lever to
make them stop (short of local empowerment).

In the case of transparent re-writers or blockers between us and
the end users there is no practical way for us to detect that the
modifications are happening, and thus I don't think anyone could
answer your second question with precision.  DNSSEC will at least
let every user do the verification from their own vantage point,
which is part of why it is so important.

Regarding #3, ISC does monitor for leaked routes.  Unfortunately
these monitors are only as good as the vantage points they occupy,
and so with upwards of 40,000 ASN's I don't know of any way to cover
them all with any certianty.  In this case it was even harder, as
the leak (appears to have been) IPv6 only.  There are a lot fewer
IPv6 monitors, and folks are generally sloppy with their IPv6 configs
so there is more leaking.  The situation is improving rapidly.

> i'm not really singling out ISC here--this is a serious problem for
> anyone who chooses to operate a root server node on untrustworthy or
> malicious network infrastructure (which is one appropriate way of
> thinking of a rewriting firewall from the perspective of a root server
> operator).

I think the problem goes a lot further than root operators.  The
fact of the matter is that there are networks that tamper with your
packets.  From the benign NAT, to the full on transparent content
filter/blocker.  Most places that tamper with root queries also
tamper with lots of other things.  Without sort of reliable end to
end crypto you really have no way of knowing.

The root zone is signed.  You can enable DNSSEC validation in your
caching resolvers.  There are plugins for popular browsers that
attempt to do DNSSEC validation and show the results to the end
user in some pleasing way.  Much more work needs to be done in this
area, but the technology is usable today.  If you care about authentic
responses, use it.

Lastly, for some reason a ton of people always jump to the conclusion
that these sort of events are the plot of $insert_bad_guy.  I've
chased down many leaks of F-Root during my time, and 100% of them
to date have been an accident.  The clueless NOC monkey.  The poorly
written route map.  Someone not reading the documentation.  Even
if $insert_bad_guy wanted to hijack F-Root (or any other root),
doing it in this way is very visable and easy to work around.  It
just doesn't make sense to even try.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20111002/454c98ec/attachment.sig>