[145260] in North American Network Operators' Group
Re: F.ROOT-SERVERS.NET moved to Beijing?
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Sun Oct 2 19:06:57 2011
Date: Sun, 2 Oct 2011 16:06:44 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <CAB2RJyhH5HcWqR1aPDYLKohQgjzWEKeVKNzZ4ZuQC_UBmXXGDg@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Sun, Oct 02, 2011 at 05:30:37PM -0400, Todd Underwo=
od wrote:
> i guess my questions now are:
>=20
> 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.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBTojuhLN3O8aJIdTMAQJZgQ//RGfg+syEAy5ltP9BoAM/NB7xPRybIuLR
A0bsbKGEpJJMITZ1YnJV/rdG9X4AQHsR0xT+5X9Y6XU/lMWeddXgGM8sWhLYt1BE
hm1SdaIOwSt6L/Xtl7bJBVt9V/VQiOjj8m827oxh8PNa1wreUQZusMHsjTrIqHx1
FApO2cnRTlVWL/MXBNogoIkKKCqf4yRMEnCCwYrw5+wZIo2Kv8jum4V1KwaAYGId
rdVn2z6unhKXFbEpsNgffY6/WxOK6tdaKXAxo3vANmngeNL0DDHjwic44p2iuSKE
6UK+M9zDprVQ8prfRJHtJW2hFiXzfCScJiIf/KUl+TQ+JxPOIk8PD85yJgKrbw61
EZ9CRCErV93Mp0XD7vppVGX/XQDDbSVOneKFPR2q4vbpaG/EY9fRCALfr2fRHh6k
cs/bxYHksDNrXuVVa/D8ETsv1J9AOK+5sF6G5ue1m9U912GGg4fsLEHmKNWq8lim
0AMTXUJXaz5srkLAlMgLfzGgU2KVUNOGGwfjzPL3CweF4PN/mi9Baw5RipgvKXxo
WrVm9VoSlnL4q+TLj+AugVrjsyXbid1BX3bh943tMk1msSgjU8EGs50FPxkw2nn4
iPVkTI2VDwfsdDXu8WOJHnd96DtdB5ZIF+mku7M64jZehWom1vqGlBp+8quIppKC
SpxGcKsJf2E=
=sYQU
-----END PGP SIGNATURE-----
--u3/rZRmxL6MmkK24--
