Re: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04
Paul Wouters <paul@nohats.ca> Thu, 07 August 2014 14:32 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1B1B2B7E; Thu, 7 Aug 2014 07:32:29 -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, RP_MATCHES_RCVD=-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 8lHaOXR4Itwq; Thu, 7 Aug 2014 07:32:26 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0879B1B2B87; Thu, 7 Aug 2014 07:32:15 -0700 (PDT)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A639B80048; Thu, 7 Aug 2014 10:32:13 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1407421933; bh=epX8Helxj1QJrhTmIusStRD7bVWG7RvOItS+AJJjcLs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CT6pipVkrkvo6BTyDRQTajYPp5CiO9ti2EzVFTkCLZcAL/k5s1loMTXXRMEm6qUhy SkrBQqgTvrd2kHkEIDQc65mCL4AnTwVMh884Efg1+kQRvUOExMQjVIQ4FBPbNMOBwT JhZ7H7EMJA2aFms6w9HYe1T0/XUbTENyJ1Db51SE=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s77EWBel029444; Thu, 7 Aug 2014 10:32:12 -0400
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 07 Aug 2014 10:32:11 -0400
From: Paul Wouters <paul@nohats.ca>
To: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
In-Reply-To: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com>
Message-ID: <alpine.LFD.2.10.1408071024250.21674@bofh.nohats.ca>
References: <04F423A7-DEEC-47B0-8FB7-61D14F2D89EB@cisco.com>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/vVl8bgT6dMUCXux-Bv1MnKOiXcQ
Cc: "draft-ietf-dnsop-as112-dnam.all@tools.ietf.org" <draft-ietf-dnsop-as112-dnam.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Aug 2014 14:32:30 -0000
On Thu, 7 Aug 2014, Klaas Wierenga (kwiereng) wrote: > For security considerations relating to AS112 service in general, see RFC6304bis]." > > And in the introduction > > "The AS112 project does not accommodate the addition and removal of > DNS zones elegantly. Since additional zones of definitively local > significance are known to exist” > > It appears to me that moving from a static list of well known ranges as defined in 6304bis to a dynamic adding and dropping of IP-address ranges that are "of definitively local > significance” is prone to error, potentially leading to blackholing valid address space, either on purpose or by accident. I may show my ignorance here, but I feel that a discussions as to why that risk doesn’t exist is warranted. Actually, the static list is much more problematic. Mostly because some AS112 instances would not yet have the new addition, while other AS112 instances would, and the replies would be inconsistent. By using the DNAME protocol, it makes anything thrown at an AS112 work. Anyone else throwing something in would still cause less packets on the internet than those DNS packets leaking out the regular DNS infrastructure. For instance, ISPs could run an AS112 instance to take all RFC1918 queries. When new ranges are added (like 100.64.0.0/16) the ISP does not even need to update their AS112 instance (they have to do so now). The document's main purpose is to get rid of that bad static list. Because it is static, an ISP cannot even really add anything to it, without causing inconsistency. The only people that can make a mistake to "null route" their domain into AS112 are the owners of the domain. Don't configure NS records that point to AS112 and you are fine. Paul
- [secdir] secdir review of draft-ietf-dnsop-as112-… Klaas Wierenga (kwiereng)
- [secdir] secdir review of draft-ietf-dnsop-as112-… Klaas Wierenga (kwiereng)
- Re: [secdir] secdir review of draft-ietf-dnsop-as… Klaas Wierenga (kwiereng)
- Re: [secdir] secdir review of draft-ietf-dnsop-as… Paul Wouters
- Re: [secdir] secdir review of draft-ietf-dnsop-as… Klaas Wierenga (kwiereng)
- Re: [secdir] secdir review of draft-ietf-dnsop-as… Paul Wouters