Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00

Andrew Sullivan <ajs@anvilwalrusden.com> Wed, 31 August 2011 03:11 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0061921F8B73 for <dnsext@ietfa.amsl.com>; Tue, 30 Aug 2011 20:11:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHeFA4GBK2Dt for <dnsext@ietfa.amsl.com>; Tue, 30 Aug 2011 20:11:38 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAD621F8B65 for <dnsext@ietf.org>; Tue, 30 Aug 2011 20:11:37 -0700 (PDT)
Received: from shinkuro.com (69-196-144-227.dsl.teksavvy.com [69.196.144.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 3D3E71ECB41C; Wed, 31 Aug 2011 03:13:05 +0000 (UTC)
Date: Tue, 30 Aug 2011 23:12:57 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: Wilmer van der Gaast <wilmer@google.com>
Message-ID: <20110831031256.GA98758@shinkuro.com>
References: <20110830162134.GB84494@shinkuro.com> <CAMbvoa+nh5k8eOA-XRwBD5oxm17+=Q4gCagq0OBS5OEQX=g1sw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAMbvoa+nh5k8eOA-XRwBD5oxm17+=Q4gCagq0OBS5OEQX=g1sw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: dnsext@ietf.org, draft-vandergaast-edns-client-subnet@tools.ietf.org
Subject: Re: [dnsext] afasterinternet.com trial and draft-vandergaast-edns-client-subnet-00
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Aug 2011 03:11:43 -0000

Hi Wilmer,

Thanks for your reply.  A couple remarks below.  I have not passed
this by Olafur, and as before, I am _not_ speaking in any official
capacity.

On Tue, Aug 30, 2011 at 10:10:01PM +0100, Wilmer van der Gaast wrote:

> It's not really a public trial on the public Internet. It's merely a
> group of open resolvers and a few CDNs who all implemented support for
> edns-client-subnet in their systems and start to use it amongst just
> each other. The resolvers use a whitelist to make sure the option only
> goes to nameservers that expect it.

When you initially suggested you wanted to do some experiments, I took
that to mean that you were going to do some things in a lab.  Because
of the way EDNS0 code points are assigned, I recognized that it would
likely be better if you did things in your lab beforehand.  That was
why I told you that, while it would probably be a little tricky to get
a code point at that early stage, if you ran an experiment with some
code that used a code point clearly not about to be allocated, it was
probably safe enough for those purposes.

What the pages I already cited say, however, is not that you're doing
something in a lab, but that you're doing it on the Internet --
between consenting adults, sure, but on the public Internet
nevertheless.

By using an unassigned code point this way, you run two risks:

    1.  Some of the client code that gets used for this hangs around,
    and continues to set that EDNS0 option.  If the option code point
    gets assigned later, and to something else, you end up setting an
    option that doesn't do what you think it does (and you don't
    behave as a server receiving such an option would expect you to).

    2.  Some server code that gets used for this test hangs around,
    and continues to respond to that EDNS0 option.  This is basically
    the complement of the above case.  It's just as bad.

> published experimental RFC, get an official number from IANA. Not at
> any time did we intend to sidestep the IETF process. Apologies if we
> gave that impression.

I actually don't care about the IETF process.  What I do care about is
the potential for interoperability headaches later because of
undocumented collisions in EDNS0 option code interpretation.  Avoiding
that sort of headache is the exact reason we have a registry.  

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com