On Tue, 11 Jul 2006, Joe Abley wrote: > > On 11-Jul-2006, at 05:32, Dean Anderson wrote: > > > BTW, the IESG response implied that the allegations of scientific > > fraud > > were (somehow) not substantiated. > > I haven't seen these specific complaints voiced with this clarity > before (maybe I overlooked some mail). Perhaps this is a good > opportunity to dispense some additional perspective. Abley's claims are again not true. Abley's claim of not having seen the "specific complaints with this clarity", is entirely false. While the information I just presented may be somewhat new to the main IETF list, there was nothing new that hasn't been discussed on DNSOP and elsewhere, with Mr. Abley, and the IESG. Abley and the IESG are well aware of the precise details, in greater detail and clarity than the summary I just presented. Abley is very well aware of these issues, in even greater detail. Indeed, most of my recent message was copied from a message I sent to DNSOP, which Abley certainly saw. Abley has almost certainly also seen the DNSMON source code. But few others have seen the DNSMON source code. (more below) > > [...] > > > > What the full community may not know, [but ISC, RIPE, Joe Abley, David > > Kessens, Brian Carpenter, and the IESG do know], is that the report > > claiming that stateful anycast was stable was fabricated, and that no > > stateful testing was performed by the DNSMON program. Contrary to > > assurances given by Karrenberg, there is no data which supports the > > notion that stateful DNS Anycast is safe, nor any data that disputes > > data and assertions that show DNS Anycast is unsafe. > > I don't believe the fact that DNSMON sends all its probe queries > using UDP transport is news to anybody. It's certainly not a secret, > as you have aptly illustrated by looking at the source code, which is > freely available. The code is copyrighted free, but is not freely available. RIPE does not distribute the DNSMON code to the general public. The source code I posted is not accessible by the general public. When RIPE gave it to me, they asked me not to redistribute it---but they indicated an intention to give away the code, and my limited quote is fair use. > It is possible to identify oscillations in node selection from > individual probes without using TCP transport. The oscillation issue is orthogonal and unrelated to the anycast issue. While both Verisign may have been originally looking to find oscillation issues when the data was collected, the implications of the findings to stateful anycast was an unexpected discovery. The implications of this discovery were made clear by Verisign. > However, from what I could tell from Daniel's presentation, the fact > that UDP transport was used by DNSMON was a simple result of the fact > that UDP measurement data is what was already stored, and hence that > was the data that was available for analysis. This is false or complete nonsense. There is no prior data "already stored". The data was collected by DNSMON. A tool like DNSMON could collect stateful data. But DNSMON didn't do that. Karrenberg didn't report that he only measured stateless UDP data. Karrenberg presented his results to refute specific claims of stateful (TCP) problems raised by Anderson and Verisign. If Karrenberg had reported the truth at the time, no one would have treated his data as having any relevance to stateful anycast. An honest person in Karrenberg's position would have reported that his data had no relevance to the TCP question. But Karrenberg didn't do what an honest researcher would have done. > I can find no example of Daniel (or anybody else) claiming that > DNSMON in general, or the data which formed the basis of Daniel's > NANOG presentation in particular, resulted from DNS queries made > using TCP transport. The only person suggesting otherwise is you. This is also not true. While Karrenberg didn't explicitly say that he made TCP queries (indeed Karrenberg didn't say anything at all about this very important detail--this is a dishonest omission), Karrenberg __did__ say was that his results refuted the "false rumor" that anycast was somehow unsafe--this is a dishonest statement. An honest statement would have said that his data had no bearing on the question of whether stateful anycast was safe. > Surely this whole issue is a red herring. We have heard nothing but false assurances for several years. "Surely" is definitely not "certainly". > > Now put this in context along with repeated assertions from Joe Abley > > and others associated with ISC and RIPE that stateful anycast is safe > > and even non-controversial. More history is found at > > http://www.av8.net/IETF-watch/DNSRootAnycast/History.html > > I fully support continued measurement of services which have been > distributed using anycast. With spoofed NSID (draft now before the IESG in Last Call), no such measurement is possible. Or is at least made very, very difficult. It is plain that you do not actually support this, anymore than Clinton supported the investigation into the Lewinsky affair. > I make no claims that anycast is definitively safe for protocols and > services which don't involve trivial, stateless transactions. Really? That's a big change. > However, I also don't presume to say that (for example) protocols > based on TCP are always unsafe for deployment using anycast in all > possible networks. This is a very fine point. People following this discussion should really pay attention here. Read carefully what Abley has said. I do make the claim that stateful Anycast is unsafe in networks which are allowed under RFC1812. Specifically, networks which implement fast load switching--Such networks currently exist in practice, and their existence is confirmed by Verisign's data. Anycast is absolutely unsafe for such networks. [Nanog participants originally claimed that no existing hardware implemented such load switching, and that widely used Cisco GSR routers were architectually incapable of implementing fast load switching. This claim also turned out to be entirely false.] I do make the claim that Root DNS nameservers have to (are obligated to) provide service to these networks. Therefore, Root DNS operators cannot use Anycast. The use of stateful anycast by root DNS operators presents a serious stability issue to the global network. This is made plain by Verisign's data,which showed that nearly 4 percent of the IP addresses show up at more than 2 anycast instances in less than 2 minutes. This is important because that implies that approximately 4 percent of the root DNS queries would fail if they were stateful. Such a failure rate is abysmally high: Internet connections that drop 3 percent of their packets are generally unusable. If 3 or 4 percent of Root DNS queries failed, we would see an significant interruption in global service. Root DNS is a critical service: When root DNS fails, nothing works. > For example, there are people using anycast to distribute services > using very long-held sessions (e.g. internet radio, HTTP) with great > success, and to ignore their experience and success would be idiotic > and arbitrary. There are no such http services using stateful anycast (though this is the first I've heard of internet radio being anycast---I'd have to question what protocol he means. I think RTP streams may be stateless, but I'm not certain). The http protocol is definitely stateful, however. The http claim has been made and debunked previously. The http claim turned out to be another myth originated by Randy Bush and Paul Vixie as far as I can tell. Vixie "warned" Akamai not to do this--Patrick Gilmore of Akamai eventually responded that Akamai never did this. Bush asserted vaguely that someone had did that, once, somewhere, sometime, but without any specifics of who, where, or when. No specifics were found other than a vague reference to a one time "speed test" conducted in the early 1990's that turned out to be rigged with a scheme similar to anycast. Dean Anderson Av8 Internet, Inc -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf