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

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<mailto: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<mailto:joelja@bogus.com>
Cc: v6ops@ietf.org<mailto: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<mailto:joelja@bogus.com>; Marc Lampo
Cc: v6ops@ietf.org<mailto: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> [mailto:v6ops-bounces@ietf.org] On
Behalf
> Of EXT - joelja@bogus.com<mailto:joelja@bogus.com>
> Sent: Monday, February 20, 2012 4:58 PM
> To: Marc Lampo
> Cc: v6ops@ietf.org<mailto: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<mailto: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<mailto:ietf@ietf.org> mailing lists by 2012-02-15. Exceptionally, comments
> may be
> > sent to iesg@ietf.org<mailto: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<mailto:v6ops@ietf.org>
> > https://www.ietf.org/mailman/listinfo/v6ops
> >
>
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org<mailto:v6ops@ietf.org>
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops