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@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/