Re: [dnsop] [dean@av8.com: Mismanagement of the DNSOP list]

Dean Anderson <dean@av8.com> Wed, 28 September 2005 06:21 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKVK0-00010j-W7; Wed, 28 Sep 2005 02:21:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKVJy-0000zW-IV for ietf@megatron.ietf.org; Wed, 28 Sep 2005 02:21:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04097 for <ietf@ietf.org>; Wed, 28 Sep 2005 02:21:37 -0400 (EDT)
Received: from cirrus.av8.net ([130.105.36.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKVRN-0001zW-3H for ietf@ietf.org; Wed, 28 Sep 2005 02:29:17 -0400
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id j8S6LQTH006976 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 Sep 2005 02:21:28 -0400
Date: Wed, 28 Sep 2005 02:21:26 -0400
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@cirrus.av8.net
To: Stephen Sprunk <stephen@sprunk.org>
In-Reply-To: <009901c5c3c9$3624ee80$efc511ac@ssprunk>
Message-ID: <Pine.LNX.4.44.0509272321440.2370-100000@cirrus.av8.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Spam-Score: 2.7 (++)
X-Scan-Signature: d008c19e97860b8641c1851f84665a75
Cc: ietf@ietf.org, wayne <wayne@schlitt.net>
Subject: Re: [dnsop] [dean@av8.com: Mismanagement of the DNSOP list]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Tue, 27 Sep 2005, Stephen Sprunk wrote:

> Anycast in the face of PPLB has been accepted (by most of us, at least)
> specifically for the root servers because current queries to the roots do
> not need to be fragmented and do not use TCP.

Right. But all DNS in the past (and most in the present) is small, stateless UDP
packets.  RFC1546 Anycast allows PPLB on diverse links.  But future DNS will use
large UDP packets, fragments, and more TCP.

> It appears that Dean is alleging that DNSSEC will cause queries to the roots
> to be fragmented or to be transmitted over TCP, thus invalidating the
> exception which allows root server operators to use anycast.  While I admit
> to not having followed the DNSOP list, I've seen no substantiated claims so
> far that indicate DNSSEC will cause queries to exceed the minimum MTUs for
> IPv4 and/or for IPv6 [2].

Plainly, TCP isn't going to work. Do you agree? 

But, its not merely the size of the request that is important. Its the fact that
a transaction may involve several packets and state on the server, even if that
state isn't explicitly maintained by DNS.  ENDSO will try to send large or
multiple UDP packets back to the client. This may result in PMTUD packets back
to the anycast root server. There is no guarentee that this ICMP packet will get
to the correct anycasted root server.  Result: client does not get a response.

There is a bit of history here: At first, it was assumed the DNSSEC would
require TCP. By requiring ENSDO support in the security-aware resolvers, TCP is
not necessary for DNSSEC.  So, for a while, I thought this might be a non issue
for root servers, but still an issue for servers that had to support TCP. Then
Iljitsch van Beijnum (an expert on BGP) noted that fragments would have a
terrible problem with Anycast and PPLB. This makes root servers problematic. At
about this same time, ISC submitted the anycast extension to the GROW working
group. So, discussion has moved there. No one on the GROW list asserts that the
Anycast Extension can work with fine grained load splitting as described with
TCP or with Large UDP Packets and fragments. 

> If Dean (or someone else) shows that the above problem case will indeed
> occur in real-world situations, the criticism of DNSSEC and/or anycasting is
> valid and one of the two needs to be fixed.

I've tested that TCP does not work with Anycast and PPLB.  Not that this is any
surprise. RFC1546 indicates this.

Also, as I tried to point out to Phillip Hallam-Baker, but he didn't seem to get
it: There is nothing in the problem specific to DNSSEC, nor is DNSSEC itself
broken. There is no way to fix DNSSEC to work with Anycast.  The problem occurs
with any protocol that uses TCP, or large UDP packets or fragments.  DNSSEC is a
protocol that uses either TCP or large UDP packets or fragments. It is not
possible to make DNSSEC work exclusively with small, stateless UDP packets. This
is why EDNSO is required for DNSSEC.

> > This looks like a tempest in a teapot to me.
> 
> Based on the messages to the IETF list so far, it appears so.


> For the record, I support a PR action against Dean due to his consistent
> provocation of flame wars,

Note that Stephen Sprunk has disagreed vehemently with me on non-IETF issues on
Nanog. 

I have been involved in a number of controversial or unpopular issues. And on a 
great number of these, I have been vindicated over time. I've said things like:

 	Anti-trust law will apply to blacklists. It did.
	The First Amendment isn't a defense against anti-trust. It wasn't
	Electr. Comm. Privacy laws prevent unauthorized boycotts. They did.
	Electr. Comm. Privacy laws prohibit reading email. They did.
	That the IEMCC was a good compromise. It was.
	That a complete ban on commercial email was unreasonable. It was.
	etc

Many of these things were absolute heresy to the anti-spam crowd at the time
they were said.  Some of them still are.  But as President of the League for
Programming Freedom, I knew a lot about boycotts and anti-trust law. I had
supervised boycotts and I had been involved in organizing protest marches with
proper permits.  I had supervised court cases through to the US Supreme Court. I
talked with a lot of lawyers, and asked a lot of questions.  I wanted to know
how the law worked. As a result, I had read a lot of law, and knew a little
about things like statutory construction.  This prepared me to analyze the ECPA
when people on Nanog suggested reading customers' email to see if was
commercial. People on Nanog said the ECPA didn't apply to email. They were
plainly wrong, but hated me for saying so.  When Nanog'ers were fired for
conducting abuse, they blamed me.

The above issues are all supposed to be outside of the IETF. But I've been
harrassed by the people who engaged in these arguments ever since, including at
the IETF.  You can frequently identify them by their participation in Nanog and
anti-spam issues.

Just recently, people wanted the IETF to associate with counterfeit
anti-spammers who were also 3-time court-proven liars. This was really
remarkable, since many on the IETF are academic or research scientists.  
Associating with such dishonesty would discredit them in their professional
life. I've never seen people try so hard to associate with the dishonest, and
try so hard to suppress facts that are easilly checked, like that fact of being
a court-proven liar, twice lying on the subject of open relays, which was what
the IETF people wanted to associate and trust them on.  This provoked a very
strong response in personal harrassment.

But that was truly remarkable, so much so, I'll digree here for a moment. I've
worked in research environments (Charles Stark Draper Lab), and attended MIT,
I've had a little experience with this community.  My GF teaches at MIT. She's
had a couple students plagarize over the years.  This is a very serious academic
offense. It is grounds for expulsion. Years of work is lost. What good school
wants to admit a plagarist?  I know what "professional dishonesty" means to an
academic or researcher.

Academic and research professionals have great concern for things that go under
the heading of "professional dishonesty".  Professionals don't associate with
liars, particularly when those lies are established by a court, and on the same
topic. Honest people seek truth, not lies. No professinal wants to be associated
with dishonesty. Security clearances are denied for dishonesty. Professional
credibility, established over a lifetime, is lost.  And by "professional", I
don't mean "someone who does something for a living", as in "Professional
car-mechanic". I mean academic and research professionals, who have standards to
meet, and a career at risk.  

Back to controversies:  Just recently, the DNSEXT chairs also tried to violate
the patent policy of the IETF by suppressing discussion, and failing to obtain
disclosure statements.  This is another valid complaint, which is also under the
supervision of David Kessens. Plainly, the DNSEXT WG Chair doesn't really
appreciate my contribution to adhering to IETF policy.  Kessens' has so far
ignored the complaint, except to try to prevent me from posting, on a frivolous 
claim.

Another controversy: Certain IETF WG Chairs think they can do IETF work
according to their own terms, and according to their own policies.  Ususally
employees that refuse to adhere to company policies are shown the door. Usually,
the sooner this is done, the better.

These things make me unpopular with some people. These things don't justify the
harrassment that has been directed at me. The policies of the IETF are meant to
protect me from this harrassment.  The management of the IETF has the authority,
responsibility, and obligation to protect me from this harrassment, and from
defamation by IETF officials.  It is a scandal that the IETF management is
involved in conducting the abuse, and has failed to stop the abuse and the
defamation. 

> particularly as they form a long-term pattern of harassment of a particular
> company or persons.

I have not harrassed anyone.  I have been harrassed, as evidenced by the
numerous school-yard name-calling, defamation, disparagement, etc. I have not
engaged in this behavior. Mostly, this behavior is motivated for my positions on
the above (many not IETF relevant) issues. But the harrassment isn't limited to
harrassing Dean Anderson or Av8 Internet. There are a small number of abusers.
They abuse many people, and their abuse is unchecked by IETF management.

In the case of instant criticism of ISC, several people have raised the same
objections, and have been similarly attacked.  Attacks for genuine ISC criticism
are not limited to me personally.

But Non-IETF conflict should be kept out of IETF business. There are policies to
disclose conflicts of interest.  This does not mean that ISC should be immune
from criticism for improper root server operation on the DNSOP list. That topic
is specifically listed in the DNSOP charter. It does mean that ISC employees
should be prevented from using their official IETF position to defame Av8
Internet. It means that people should be prevented from disparaging Dean
Anderson and Av8 Internet, as well as a number of other people. 

> Note that I consider it irrelevant whether his position in this or any past
> instance turns out to be correct: it's the form, not the content, of his
> efforts that is the problem.

Note that Stephen Sprunk has disagreed vehemently with the above listed non-IETF
issues on Nanog.  There is plainly nothing wrong with the form of my messages.  
The attacks are personally motivated.

> [1] Many modern routers, particularly ones used in the Internet core, do not
> even have the ability to enable PPLB, and the places where I've seen it used

This is a false statement.  Many small ISPs still use Cisco 7200 and 7500 series
Cisco routers. These routers are capable of PPLB.  Further, PPLB does not need
to be done in the core, or on core routers. It can be done on a CPE Cisco 2600
that has 2 T1s which have diverse paths. Many ISPs large and small offer
multiple T1 services to different ISP sites. Many ISPs do hot-potato routing.  
PPLB does not require BGP. It can be done with multiple default routes on the
just described 2600.

> in the last five years have exclusively been topologies that will always
> re-merge the balanced traffic further upstream.

This also isn't true. Not "exclusively" by a longshot. Many small ISPs have
multiple sites with different upstream connections at each site. Some such ISPs
use default egress routes. Even with BGP, the different sites frequently do
hot-potato routing. Packets that go to one site, go to one upstream. Packets
that go to the other site, go to a different upstream.  Remember that CPE 2600
that is doing fine grained load balancing between these sites.

> [2] I have seen misguided operators set MTUs below 200 bytes, but my
> position is that these people deserve what they get in such cases.  We
> cannot cater to deliberately broken implementations.

Your opinion of "deliberately broken" may not be shared by everyone. This is why
we have standards that set things like minimum MTU.  But your attitude and
disregard for standards reveals a lot.

Fortunately, we realized long ago that people like Stephen Sprunk couldn't be
trusted to run root DNS servers however they thought right, to the detriment of
those they thought "broken". So we've had standards (RFC2870) for operation of
root DNS servers.  This may be the only IETF RFC that someone actually MUST
comply with, and can't ignore if they please.

-- 
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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf