Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice

Joe Abley <jabley@hopcount.ca> Thu, 22 May 2014 16:34 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18381A01E5 for <ietf@ietfa.amsl.com>; Thu, 22 May 2014 09:34:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_uLx0Nea-9Q for <ietf@ietfa.amsl.com>; Thu, 22 May 2014 09:34:46 -0700 (PDT)
Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECD51A0201 for <ietf@ietf.org>; Thu, 22 May 2014 09:34:46 -0700 (PDT)
Received: by mail-ig0-f177.google.com with SMTP id l13so3759710iga.4 for <ietf@ietf.org>; Thu, 22 May 2014 09:34:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=clsxVpqSmj7lr4fPAzWYVGztHd3JsEWg4Z85MEf6vuk=; b=ExinUSqPhIM3QeeS5wcCsEnm8vY+eaSx6n2MP1tgb7wovW5p8L/lFFsUR2in1JY3pC q8kN+0DRYhLdCvQ3Eib8xRFToz3B1VeY2L4OPeimG7bOrvFl0NUXmHTREccmXsxrliEL x2guW5c1g9ryQ2cSuzf+wlHm4XQ1tbnDD4awY=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=clsxVpqSmj7lr4fPAzWYVGztHd3JsEWg4Z85MEf6vuk=; b=GEomzK/rumeNpbj6/ZCGFmSucOM/VKoT9Msu53GY0qfPHzsXyp6/NpiH4yigXxMUq9 kqG2AVnkOzjtcVD4X4ADq55UP13HJN01P0zrGj0fyY+JiZfBzL4oY4tIDzKt1KRQldib 7YeqPxk80aCAdMMEy8YwGzQ15CZ0jHihE/aN2AfV9tfyMD+SQQtYfP8gCQoQJYNlcVfO +l2KJj7006Jt8CBpB2JAhORv3XrCHA1stgFxzPZrnfXnH94UM6cnWyfoyGNc3lsg32Yd awOWNxNYwAS0i7SjCQLfW+IXEN14hDH2pek+u3KPlsS1KvdzL7uRZhPFUGkkMpi7fW8o 3zcA==
X-Gm-Message-State: ALoCoQniu3h16AjmJlRW7UwxERFNbHTmIcaSwZWaZ3dYBTL75B/I5nhyaDLfuua8kYstuypQgRjv
X-Received: by 10.50.43.170 with SMTP id x10mr23814103igl.36.1400776484707; Thu, 22 May 2014 09:34:44 -0700 (PDT)
Received: from [199.212.90.50] (24-52-234-221.cable.teksavvy.com. [24.52.234.221]) by mx.google.com with ESMTPSA id q5sm4716080igg.10.2014.05.22.09.34.43 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 22 May 2014 09:34:44 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Subject: Re: Last Call: <draft-iab-2870bis-01.txt> (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <6.2.5.6.2.20140521194638.06eaf508@resistor.net>
Date: Thu, 22 May 2014 12:34:43 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <1111FB79-012A-414B-B8CD-0BBDAE8BD6A8@hopcount.ca>
References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <6.2.5.6.2.20140521194638.06eaf508@resistor.net>
To: S Moonesamy <sm+ietf@elandsys.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/TUH2dtlJ-j55IFZXDwjihU6DE_k
Cc: liman@netnod.se, IETF-Discussion Discussion <ietf@ietf.org>, barc.blanchet@viagenie.ca
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 May 2014 16:34:48 -0000

Hi SM,

Some reaction to your comments below, plus a comment of my own. I'll note that I am not a root server operator, although in the past I have played one on TV. My comments on your comments are provided merely as additional thoughts from an innocent bystander.

On 22 May 2014, at 1:23, S Moonesamy <sm+ietf@elandsys.com> wrote:

> In Section 1:
> 
>  "The operational requirements are defined in [RSSAC-001]."
> 
> There isn't any document about Service Expectations at
> http://www.icann.org/en/groups/rssac

I understand that RSSAC have made recent progress on that document, and that it will appear soon. I would presume that the RFC Editor would hold final publication of this document, once approved, until that reference showed up, as is the case for references to IETF documents. I don't know whether that's a good presumption though. I just thought I'd mention it as a plausible workflow.

> According to a message posted a few months ago c.root-servers.net is not reachable on 2001:500:2::c from one network.  Section 3 of the draft mentions that the root name service must answer queries from any entity with a valid IP address.

At any time many parts of the Internet are unreachable from other parts of the Internet, for many reasons unrelated to specifications (national issues, cable breaks, failures in particular networks, peering disputes, etc.)

I'll note that the document describes requirements for the *service*, not for any particular component of the service.

So I think this concern is orthogonal to the purpose and contents of this document.

> I'll note that there will no longer be an IETF document with the following requirement:
> 
>  "The root zone MUST be signed by the Internet Assigned Numbers
>   Authority (IANA) in accordance with DNSSEC"

I actually think that it makes sense to separate the requirements for the root name *service* from the contents of the root zone that is being served. The document requires the service to support DNSSEC (which I think is right and proper), and has nothing to say about the contents of the root zone (which again, I think is right and proper).

I have one comment of my own.

Section 3 specifies that:

> 3.  Deployment Requirements
> 
>    The root name service:
> 
>       MUST answer queries from any entity conforming to [RFC1122] with a
>       valid IP address.

The document does not discuss what "valid" means in this context. In a protocol sense, "valid" presumably means "well-formed", which means that any 32-bit/128-bit integer will do.

The address 10.4.5.6 is a valid IP address in a protocol sense, although use of that address is constrained operationally by RFC 1918. It would be reasonable not to send a response to a query from an address that is known to be unreachable from the point of view of the root server.

Inbound queries with source addresses for which there is no corresponding return route, similarly, cannot be usefully replied to. Individual root servers with (e.g.) unicast RPF configured upstream will not receive those queries. In this category are addresses that have not been allocated by an RIR or are not announced on the Internet for some other reason (perhaps they are used in disconnected networks which are leaking).

Individual root servers have in the past mitigated attack traffic (e.g. reflection attacks) using techniques such as Response Rate Limiting. There is good reason to believe that such techniques do a good job at allowing legitimate queries to be answered whilst preventing responses that might otherwise enable (e.g.) a reflection attack.

Taken at face value, this MUST requires individual root server operators to do things that, operationally, are undesirable. I suggest some qualification, e.g. of the form "the root name service MAY refuse to answer particular queries to mitigate operational events that might otherwise threaten its stability and availability".


Joe