Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
"Marc Lampo" <marc.lampo@eurid.eu> Mon, 20 February 2012 14:32 UTC
Return-Path: <marc.lampo@eurid.eu>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A396121F8697 for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 06:32:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.15
X-Spam-Level:
X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449]
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 q7auK-+Ho5M9 for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 06:32:02 -0800 (PST)
Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA4B21F8680 for <v6ops@ietf.org>; Mon, 20 Feb 2012 06:32:02 -0800 (PST)
X-ASG-Debug-ID: 1329748510-0369490e9a40890001-b2NLKh
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id BLmrYcUnTdJDtS3V; Mon, 20 Feb 2012 15:35:10 +0100 (CET)
X-Barracuda-Envelope-From: marc.lampo@eurid.eu
X-ASG-Whitelist: Client
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.eurid.eu (Postfix) with ESMTP id 91C02E408B; Mon, 20 Feb 2012 15:32:00 +0100 (CET)
X-Virus-Scanned: amavisd-new at techmail.eurid.eu
Received: from zimbra.eurid.eu ([127.0.0.1]) by localhost (zimbra.eurid.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9cnLggzzGiJ; Mon, 20 Feb 2012 15:32:00 +0100 (CET)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 7F86CE4050; Mon, 20 Feb 2012 15:32:00 +0100 (CET)
From: Marc Lampo <marc.lampo@eurid.eu>
To: jason_livingood@cable.comcast.com
References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com>
In-Reply-To: <20120201150911.25955.80172.idtracker@ietfa.amsl.com>
Date: Mon, 20 Feb 2012 15:32:00 +0100
X-ASG-Orig-Subj: RE: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
Message-ID: <017501ccefdc$68025a50$38070ef0$@lampo>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18)
Thread-Index: Aczg83O386MCjRztTKmEcXn2PnRYGAO5mMuQ
Content-Language: en-za
X-Originating-IP: [172.20.5.51]
X-Barracuda-Connect: zcs-master.vt.eurid.eu[10.19.100.121]
X-Barracuda-Start-Time: 1329748510
X-Barracuda-URL: http://10.19.10.12:8000/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at eurid.eu
Cc: v6ops@ietf.org
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Feb 2012 14:32:06 -0000
Hello, (sorry to be late with my comments, bit overloaded on my side) 6.1 Security Considerations - paragraph 2 (on DNSSEC) The text states : "there should not be any negative impact on DNSSEC" In my opinion, this is *wrong* : It is correct that, if an AAAA record exists (in a DNSSEC's zone), the appropriate RRSIG will be known to authoritative NS's. If, via white listing, the decision is taken not to present the AAAA record (and its signature), this seems OK. However : not returning an AAAA record seems identical to : there is no AAAA record. And that - there is no AAAA record - yields to "Next Secure" changes ! If no AAAA record exists, for a name, the corresponding NSEC (NSEC3) record should not hold a reference to AAAA. But if that AAAA record does exist, the authoritative NS will have NSEC (NSEC3) data that shows so. A DNSSEC query (ENDS0 + DO set) for AAAA (and the AAAA exists but due to whitelisting will not be returned), cannot be proven by accompanying (and required) NSEC (NSEC3) information. Hence : this draft will/might make DNSSEC validating name servers fail. If you look at 4.3.1.1 (Description of DNS Resolver Whitelisting) in detail, please observe : 1) the caching name server (and "stub resolver") ask 2 queries (there is only one line, but it are two queries : one for "A", one for "AAAA") 2) if the caching name server (or stub resolver) performs DNSSEC validation, it will never accept a reply of "NODATA" to the query of AAAA (because the NSEC (NSEC3) information will not prove that non-existance) ((and the validating name server will repeat the query to all authoritative NS's, looking for a validatable answer)) (the final result, to the user might be that only the A record is useable - mission accomplished ? But the side effect will be that validating caching name servers will hit *all* authoritative servers for the domain, "in search of" a correctly validating answer.) So, while for the end-user, the result might be identical, one "security impact" of this approach is additional (useless) DNS traffic and additional load on authoritative NS's (that implement whitelisting) Kind regards, Marc Lampo Security Officer EURid -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: 01 February 2012 04:09 PM To: IETF-Announce Cc: v6ops@ietf.org Subject: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC The IESG has received a request from the IPv6 Operations WG (v6ops) to consider the following document: - 'Considerations for Transitioning Content to IPv6' <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-02-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes considerations for the transition of end user content on the Internet to IPv6. While this is tailored to address end user content, which is typically web-based, many aspects of this document may be more broadly applicable to the transition to IPv6 of other applications and services. This document explores the challenges involved in the transition to IPv6, potential migration tactics, possible migration phases, and other considerations. The audience for this document is the Internet community generally, particularly IPv6 implementers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl ications/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-v6ops-v6-aaaa-whitelisting-impl ications/ No IPR declarations have been submitted directly on this I-D.
- [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whit… The IESG
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Erik Kline
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Tina TSOU
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Fred Baker
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Erik Kline
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Joel jaeggli
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Fred Baker
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Mark Andrews
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Joel jaeggli
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Livingood, Jason
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Marc Lampo
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Ronald Bonica
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Havard Eidnes
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Mark Andrews
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Joel jaeggli
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Mark Andrews
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Ronald Bonica
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Marc Lampo
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Lorenzo Colitti
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Ronald Bonica
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Livingood, Jason
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Livingood, Jason
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Livingood, Jason
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Ronald Bonica
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Livingood, Jason
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Marc Lampo
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Havard Eidnes
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Havard Eidnes
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Livingood, Jason
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Ronald Bonica
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Mark Andrews
- Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-… Livingood, Jason