ietf
[Top] [All Lists]

Re: Response to the Appeal by JFC Morfin dated 2006-02-17 - 2006-05-17.

2006-07-12 12:46:10
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf