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> Wed, 22 February 2012 09:20 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 BAEE121F8961 for <v6ops@ietfa.amsl.com>; Wed, 22 Feb 2012 01:20:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.775
X-Spam-Level:
X-Spam-Status: No, score=-0.775 tagged_above=-999 required=5 tests=[AWL=-0.225, 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 7VBPE6eqRpRr for <v6ops@ietfa.amsl.com>; Wed, 22 Feb 2012 01:20:24 -0800 (PST)
Received: from barra.eurid.eu (barra.eurid.eu [78.41.71.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7511321F8820 for <v6ops@ietf.org>; Wed, 22 Feb 2012 01:20:19 -0800 (PST)
X-ASG-Debug-ID: 1329902616-0369490e9c44770001-b2NLKh
Received: from zimbra.eurid.eu (zcs-master.vt.eurid.eu [10.19.100.121]) by barra.eurid.eu with ESMTP id tZ7FZEaQyHarByU5; Wed, 22 Feb 2012 10:23:36 +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 4E4F2E4075; Wed, 22 Feb 2012 10:20:16 +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 Pdm+1dztMXDL; Wed, 22 Feb 2012 10:20:16 +0100 (CET)
Received: from zimbra.eurid.eu (zimbra.eurid.eu [10.19.100.120]) by zimbra.eurid.eu (Postfix) with ESMTP id 379D1E4052; Wed, 22 Feb 2012 10:20:16 +0100 (CET)
From: Marc Lampo <marc.lampo@eurid.eu>
To: "'Livingood, Jason'" <Jason_Livingood@cable.comcast.com>, 'Ronald Bonica' <rbonica@juniper.net>, joelja@bogus.com, 'Mark Andrews' <marka@isc.org>
References: <CB695E6D.51184%jason_livingood@cable.comcast.com> <CB696023.51192%jason_livingood@cable.comcast.com>
In-Reply-To: <CB696023.51192%jason_livingood@cable.comcast.com>
Date: Wed, 22 Feb 2012 10:20:16 +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: <00e401ccf143$303934a0$90ab9de0$@lampo>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Mailer: Microsoft Office Outlook 12.0
X-Mailer: Zimbra 6.0.14_GA_2928 (ZimbraConnectorForOutlook/5.0.3064.18)
Thread-Index: AQHM8NGMkD00gtDZEUSP/1IDM55exZZHw6MAgADeEzA=
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: 1329902616
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: Wed, 22 Feb 2012 09:20:27 -0000

Hello,
(my time zone implies I see your replies only “the next day”)

1) I assume one cannot, in this RFC, elaborate too much on how
“aaaa-whitelisting”
can be implemented, so I can live with this sentence (though "view" is a
term
from the Bind implementation, other implementations might use different
wording).

2) regarding the previous sentence :
"So even though an authoritative DNS server will selectively return
 AAAA resource records and/or A resource records,
 these resource records can certainly still be signed."

In this context - assuming we are talking about a signed domain with
chain-of-trust
appropriately in place - I'd propose :
"So even though an authoritative DNS server will selectively return
 AAAA resource records and/or A resource records,
 these resource records must be signed,
 as well as any accompanying NextSecure information
 that proves existence and/or not-existence of AAAA resource records."

So :
-> it's a *must*
-> it's not only the A and/or AAAA RRs, but also the NSEC/NSEC3 RRs.


Kind regards,

Marc Lampo
Security Officer
EURid (for .eu)


From: Livingood, Jason [mailto:Jason_Livingood@cable.comcast.com]
Sent: 21 February 2012 08:55 PM
To: Ronald Bonica; Marc Lampo; EXT - joelja@bogus.com; Mark Andrews
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

I made this addition in the relevant section (6.1). Let me know if it does
not capture this sufficiently (or does so inelegantly). 

Thanks
Jason

In practical terms this means that two separate views or zones are used,
each of which is signed, so that whether or not particular resource
records exist, the existence or non-existence of the record can still be
validated using DNSSEC. 




On 2/21/12 2:46 PM, "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
wrote:

Good idea and it is quick & easy edit. Making the change now. Will send
text momentarily.

Jason

On 2/21/12 8:44 AM, "Ronald Bonica" <rbonica@juniper.net> wrote:

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
_______________________________________________
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