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> Tue, 21 February 2012 07:02 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 5201F21E8046 for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 23:02:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.85
X-Spam-Level:
X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, 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 Gyj-sFmn9mkL for <v6ops@ietfa.amsl.com>; Mon, 20 Feb 2012 23:02:45 -0800 (PST)
Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1021E21E803F for <v6ops@ietf.org>; Mon, 20 Feb 2012 23:02:43 -0800 (PST)
X-ASG-Debug-ID: 1329807945-0369490e9a41a40001-b2NLKh
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id kOn54qpeq5TT52Tn; Tue, 21 Feb 2012 08:05:45 +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 97828E408B; Tue, 21 Feb 2012 08:02:31 +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 2Uy25HADZ0C9; Tue, 21 Feb 2012 08:02:31 +0100 (CET)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 84459E407C; Tue, 21 Feb 2012 08:02:31 +0100 (CET)
From: Marc Lampo <marc.lampo@eurid.eu>
To: 'Ronald Bonica' <rbonica@juniper.net>, joelja@bogus.com
References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <4F42C1E6.7010606@bogus.com> <13205C286662DE4387D9AF3AC30EF456D7671A227B@EMBX01-WF.jnpr.net>
In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7671A227B@EMBX01-WF.jnpr.net>
Date: Tue, 21 Feb 2012 08:02:31 +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: <008301ccf066$c7b96c10$572c4430$@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: AczwGv1RylzOYikrSOiJPgXVBRSCpgAB5BzwABD1LWA=
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: 1329807945
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: Tue, 21 Feb 2012 07:02:46 -0000
Hello, I had assumed : 1 zone file (and Mark Andrews correctly pointed at "views"). Would adding this piece of information, directly in the RFC, be useful to avoid confusion for future readers ? Thanks and kind regards, Marc Lampo -----Original Message----- From: Ronald Bonica [mailto:rbonica@juniper.net] Sent: 20 February 2012 11:55 PM To: EXT - joelja@bogus.com; Marc Lampo 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 Marc, Havard, Are you satisfied with the answers provided by Joel and Mark? Ron > -----Original Message----- > From: v6ops-bounces@ietf.org [mailto:v6ops-bounces@ietf.org] On Behalf > Of EXT - joelja@bogus.com > Sent: Monday, February 20, 2012 4:58 PM > To: Marc Lampo > 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 > > On 2/20/12 06:32 , Marc Lampo wrote: > > 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* : > > > > IMHO the following applies. > > if you have one zone yeah I agree. > > If you have two zones one with aaaa and one without (assuming this is > done with dns views style implementation) you can sign both and they'll > both be valid and complete from the vantage point of a client which > resolves one or the other of them but not both. > > this is a traditional split horizon problem. it's just not > inside/outside. > > joel > > > 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 mailing list > > v6ops@ietf.org > > https://www.ietf.org/mailman/listinfo/v6ops > > > > _______________________________________________ > v6ops mailing list > v6ops@ietf.org > https://www.ietf.org/mailman/listinfo/v6ops
- [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