Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

Ronald Bonica <rbonica@juniper.net> Tue, 21 February 2012 13:46 UTC

Return-Path: <rbonica@juniper.net>
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 2702421F8733 for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 05:46:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.226
X-Spam-Level:
X-Spam-Status: No, score=-106.226 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 8qwO3nNfVtyP for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 05:46:17 -0800 (PST)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with ESMTP id C993721F855B for <v6ops@ietf.org>; Tue, 21 Feb 2012 05:46:16 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKT0Of9pmGsRrzJ2+kxLcyPfER74usTjb9@postini.com; Tue, 21 Feb 2012 05:46:16 PST
Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Feb 2012 05:44:45 -0800
Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by p-cldfe01-hq.jnpr.net (172.24.192.59) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 05:44:45 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 21 Feb 2012 08:44:45 -0500
From: Ronald Bonica <rbonica@juniper.net>
To: Marc Lampo <marc.lampo@eurid.eu>, "EXT - joelja@bogus.com" <joelja@bogus.com>
Date: Tue, 21 Feb 2012 08:44:11 -0500
Thread-Topic: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
Thread-Index: AczwGv1RylzOYikrSOiJPgXVBRSCpgAB5BzwABD1LWAADht0UA==
Message-ID: <13205C286662DE4387D9AF3AC30EF456D7671A23BD@EMBX01-WF.jnpr.net>
References: <20120201150911.25955.80172.idtracker@ietfa.amsl.com> <017501ccefdc$68025a50$38070ef0$@lampo@eurid.eu> <4F42C1E6.7010606@bogus.com> <13205C286662DE4387D9AF3AC30EF456D7671A227B@EMBX01-WF.jnpr.net> <008301ccf066$c7b96c10$572c4430$@lampo@eurid.eu>
In-Reply-To: <008301ccf066$c7b96c10$572c4430$@lampo@eurid.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EXCLAIMER-MD-CONFIG: e4081efb-6d29-443c-8708-750833aec629
Cc: "v6ops@ietf.org" <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 13:46:21 -0000

Authors,

What do you think?

                Ron

> -----Original Message-----
> From: Marc Lampo [mailto:marc.lampo@eurid.eu]
> Sent: Tuesday, February 21, 2012 2:03 AM
> To: Ronald Bonica; EXT - joelja@bogus.com
> 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
> 
> 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