Subject: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02

From: Joel Jaeggli <[email-masked]>
Date: Sun, 06 Feb 2011 19:35:35 -0800

This announcement is to serve as the beginning of the WGLC for:

draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02

http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02

WGLC runs from Monday Feb 7th to Monday Feb 21st.

The 01 version of this document received a lot of good feedback on this
list which has been incorporated into this version of the draft.

joelja

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 13 Feb 2011 09:29:29 -0800

The halfway point has been reached, please get your feedback in by
monday the 21st...

On 2/6/11 7:35 PM, Joel Jaeggli wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 14 Feb 2011 09:45:48 +1300

I think this is in good shape and ready to move forward.
In fact it would be good to fast track it before June 8th.

Regards
   Brian

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 20 Feb 2011 15:27:42 -0800

So, I kinda slacked on my own deadline.

I have reviewed the document and I think structurally and content-wise
it's pretty close to ready if not outright go to go, I have kind of a
lot of edits which I will include in a seperate email.

in section 2 the last paragraph is sufficiently obtuse that without
reading section 6 to which it refers you have no idea what it means.

   Finally, DNS whitelisting can be deployed in two primary ways:
   universally on a global basis, or on an ad hoc basis.  These two
   potential deployment models are described in Section 6.

In section 6 I would swap the order of 6.2 and 6.1 since the later is
what is happening and sems most likely to remain the case for the
forseeable future.

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 20 Feb 2011 15:35:43 -0800

So far on this Last call we've heard from:

Brian Carpenter
Fred Baker (wg chair)
Joel Jaeggli (wg chair)
Jason Livingood (author)

Deadline is end of monday everywhere to get your .02 in.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 21 Feb 2011 14:05:52 +0000

Inline below. And thank you for your review! I'll wait to see if any other minor tweaks are suggested today and then include this in a minor –03 update based on any other WGLC suggestions.

--JL

[JL] I'll address those in a separate email later today.

[JL] Good point. This now reads:

Finally, DNS whitelisting can be deployed in two primary ways: universally on a global basis, or on an ad hoc basis. Deployment on a universal deployment basis means that DNS whitelisting is implemented on all authoritative DNS servers, across the entire Internet. In contrast, deployment on an ad hoc basis means that only some authoritative DNS servers, and perhaps even only a few, implement DNS whitelisting. These two potential deployment models are described in Section 6<http://xml.resource.org/cgi-bin/xml2rfc.cgi#Likely%20Deployment%20Scenarios>.

[JL] Those sections will be reversed – good suggestion.

Thanks again!
Jason

joelja

---

From: Doug Barton <[email-masked]>
Date: Mon, 21 Feb 2011 10:51:26 -0800

> Deadline is end of monday everywhere to get your .02 in.

With respect to the authors I think this draft is a bad idea, and I 
oppose it moving forward.

1. The entire draft takes on the "You're doing it wrong!" tone that 
alienates operators from those in the IPv6 advocacy community that 
actually have something useful to contribute.
2. It purports objectivity about "why some would object" to the 
practice, but (IMO) has a clear editorial slant as to whitelisting being 
bad.
3. Most of Section 4 makes no sense at all. I don't see anyone adding 
v6-only hosts to "highly trafficked sites" any time soon.
4. The last paragraph of Section 4 is a complete red herring. It does 
not matter what the level of v4 impairment is relative to v6 impairment. 
The problem that sites are trying to solve is people who CAN reach the 
site over v4 who have a degraded experience after v6 is enabled. The 
0.078% (or 1/2000 to use Google's number) is not the percentage of the 
total number of potential Internet users, it's the total of users they 
_already have_.
5. Section 5 basically hand-waves the fact that operators are already 
doing lots of other things with DNS that make whitelisting essentially a 
drop in the bucket.
6. Section 7.1 is completely irrelevant. The end-to-end ship sailed 
years ago.

Simply put, if published this draft will do more harm than good. The 
major sites are already moving forward on wider v6 deployment, including 
Google, the site that popularized whitelisting. (See 
http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely 
believe that they need to use this technique are going to use it whether 
this document is released or not. "It works for Google" is a much more 
persuasive line of reasoning. Releasing this now makes us look like a 
bunch of old ladies wagging our fingers at recalcitrant children.

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 21 Feb 2011 11:01:45 -0800

> oppose it moving forward.

I proposed a series of edits (sent to jason first due to their length)
that neutralize the tone a bit but without I think altering the content.
I think that the characterization of the problems with a whitelisting
approach is useful and important. It's going to (has) happened anyway
and it's not a "we told you so" it's "these are the issues you have to
contend with."

> total number of potential Internet users, it's the total of users they

I my personal belief is that if anything it represents an under-sampling
of the problems that the userbase will experience. I'm not going to try
and back that up with emperical data since my sample is way too small to
be relevant.

---

From: Doug Barton <[email-masked]>
Date: Mon, 21 Feb 2011 11:06:15 -0800

> and it's not a "we told you so" it's "these are the issues you have to

I would be willing to reconsider my position after reviewing a new 
draft, but I admit to a strong bias. More to the point, I don't think 
that anyone has deployed this solution without thinking through the 
implications (certainly not on the larger sites) which is one of the 
reasons I think that publishing the draft at all is at best 
counterproductive.

Doug

--

---

From: John Curran <[email-masked]>
Date: Tue, 22 Feb 2011 05:00:43 +0800

On Feb 22, 2011, at 2:51 AM, Doug Barton wrote:
> ...
> Simply put, if published this draft will do more harm than good. The major sites are already moving forward on wider v6 deployment, including Google, the site that popularized whitelisting. (See http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely believe that they need to use this technique are going to use it whether this document is released or not. "It works for Google" is a much more persuasive line of reasoning. Releasing this now makes us look like a bunch of old ladies wagging our fingers at recalcitrant children.

Doug - 
 
  I'm not certain I read the draft the same way (doing more harm 
  than good), as section 9 clearly acknowledges that "major domains 
  may find DNS whitelisting a beneficial temporary tactic in their 
  transition to IPv6.  Such temporary use during the transition 
  to IPv6 is broadly accepted within the community, so long as it 
  does not become a long-term practice."

  While sites that genuinely believe they need to use this technique 
  may have consider many of the implications to them, the costs
  imparted to others and resulting scaling properties are quite
  suboptimal.  I believe it makes sense to publish a draft which 
  points this out and notes that it is still reasonable due to their
  temporary nature, or to acknowledge the permanent nature of these
  whitelists and start working on mechanisms for scalable long-term 
  management of them.

/John

p.s.  (my views alone; 100% recycled electrons used in this message)

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Feb 2011 10:04:19 +1300

> reasons I think that publishing the draft at all is at best

Not surprisingly, I disagree. To be blunt, the argument
"Google's doing it, so it must be right" is pretty powerful.
I don't doubt that Google thought it through; I know that they
discarded at least one alternative solution. I don't have much
faith that other content providers will be so careful.

I am reminded of the objections to RFC 2993 being published.
Sadly, its warnings were largely ignored: a large part of the
mess we are now in.

    Brian

---

From: Doug Barton <[email-masked]>
Date: Mon, 21 Feb 2011 13:10:08 -0800

>    does not become a long-term practice."

Yes, I read the same thing. AFTER pages and pages of text that basically 
say, "YOU'RE DOING IT WRONG." I have stated in other fora that we have 
to stop telling people that are actually deploying IPv6 that they are 
doing it wrong, both because that's detrimental on its face, and because 
given the incredibly limited amount of actual experience that we have 
with IPv6 on a wide-spread basis it's at best arrogant for anyone to say 
so at this point.

The other reason I find the draft objectionable (and I've repeated this 
once already, so this will be the last time today) is that the people 
who are deploying this solution don't _need_ us to to tell them it 
shouldn't be a long-term practice. They already know that, and are 
already taking steps to move past it.

>    imparted to others

Can you define what those "costs imparted to others" are?

>    and resulting scaling properties are quite

I have been following this issue closely and I haven't seen one single 
statement that anyone believes that this should be a long-term solution, 
or that anyone plans to make it so. Do you have a reference that I may 
have missed?

So to summarize once more, no good can come from publishing this, and 
it's likely that it will at least step on toes completely without reason 
to do so.

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Mon, 21 Feb 2011 13:18:22 -0800

> Sadly, its warnings were largely ignored: a large part of the

Actually I agree that the situations are incredibly similar. IETF 
theorists ignoring operational reality on ships that have already 
sailed. Imagine what a better place the world would be if the IETF had 
embraced the fact that people liked/needed NAT and had worked on finding 
a more robust way to do it instead of shouting at people that they 
should not want/use it.

Sorry for the strong words, and I hope you(pl.) understand that no 
personal attack is intended. But it gets really frustrating to see the 
same silly stuff year after year after year because certain people in 
the IETF are so determined to have architectural purity that they ignore 
the operational necessities of the people who actually need to make the 
stuff work.

Doug ( ... and no, it doesn't matter if you disagree with their 
definition of "works" either.)

--

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 21 Feb 2011 21:30:05 +0000

Doug - I'm glad you speak in support of those (like me, the humble author) who are focused on real operational issues involved in the deployment of IPv6. ;-)  It is the primary reason why the document was written. To wit, played forward a few years and widely adopted, DNS whitelisting could well be operationally problematic. As the draft attempts to make clear, the short-term is an entirely different matter.

Regards

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 21 Feb 2011 21:49:47 +0000

Yes, I read the same thing. AFTER pages and pages of text that basically
say, "YOU'RE DOING IT WRONG."

[JL] I'm happy to take suggestions on text you think is too strong.

I have stated in other fora that we have

[JL] The document points out the many implications of whitelisting. It also describes how it can make sense for some domains in the short term but that it is problematic in the long-term (which you seem to agree with). The document was not written based on theory but was instead motivated by some actual experience. If you believe any of the implications listed in the document are without merit or wish to suggest modifications to them (or other specific parts of the document), I'm all ears and I've been responsive to every single change requested (including from folks doing whitelisting).

[JL] To give one perspective, that of a network operator, please see Section 7.3.1, 7.3.3, 7.3.4, and 7.3.6. A network operator needs to add staff to discover which domains whitelist, discover the policies and application process for each domain, apply to be whitelisted for each domain, and monitor progress / approvals / appeals. Then, once it is place, monitoring must be put in place to ensure whitelisting remains in place and there is manual intervention via NOC and IPv6 SMEs when de-whitelisting occurs (through error or for some other reason). In addition, let's not leave off the added complexity of troubleshooting end user problems (we measure this in incremental seconds/minutes on the phone with users).

[JL] That didn't seem to be the sentiment at the WG meeting in Beijing, nor on the list up to the point of your email. If in fact no one believes this should be a long-term tactic, then what is the downside of the document if it attempts to detail all the reasons why this is so?

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 21 Feb 2011 21:57:14 +0000

[JL] I am mid-way through those edits (will take another day or so to factor them all in). These suggestions will be adopted in a –03 version along with the other specific feedback received in the past few days of WGLC.

Regards
Jason

---

From: Doug Barton <[email-masked]>
Date: Mon, 21 Feb 2011 13:59:49 -0800

> [JL] I'm happy to take suggestions on text you think is too strong.

That would be operating from the premise that there is any way to say 
these things that are useful, or at best not offensive. I disagree with 
that premise. :)

> [JL] To give one perspective, that of a network operator, please see
> Section 7.3.1, 7.3.3, 7.3.4, and 7.3.6. A network operator needs to add
> staff to discover which domains whitelist, discover the policies and
> application process for each domain, apply to be whitelisted for each
> domain, and monitor progress / approvals / appeals. Then, once it is
> place, monitoring must be put in place to ensure whitelisting remains in
> place and there is manual intervention via NOC and IPv6 SMEs when
> de-whitelisting occurs (through error or for some other reason). In
> addition, let's not leave off the added complexity of troubleshooting
> end user problems (we measure this in incremental seconds/minutes on the
> phone with users).

Ok, I'll grant you all of those, but I will also point out that all of 
those costs are voluntary. You don't have to choose to do any of those 
things. I think it's admirable if you do, since more traffic over IPv6 
is a great thing.

However I return to my main premise which is:
1. 99.9% of the organizations who have chose this solution already 
understand these issues, and
2. The 0.1% who don't, don't care.

Therefore no good can come from publishing this.

>     it's likely that it will at least step on toes completely without
>     reason to do so.
>
>
> [JL] That didn't seem to be the sentiment at the WG meeting in Beijing,
> nor on the list up to the point of your email.

... and please accept my apologies for not having been able to speak up 
sooner.

> If in fact no one
> believes this should be a long-term tactic, then what is the downside of
> the document if it attempts to detail all the reasons why this is so?

I've already explained the downside several times.

--

---

From: Tina Tsou <[email-masked]>
Date: Mon, 21 Feb 2011 14:13:55 -0800

Hi,
I generally support this document as attempt on real operational issues
involved in the deployment of IPv6.
 
Comments on section 10.1 "DNSSEC Considerations" are below.
It says that different answers are sent to different querying hosts. If
those are all known in advance, and the server has the DNS zone signing key,
it can separately sign the various alternative answer data sets however you
want. If they are not known in advance, then you have to have the keys
on-line so you can sign answer data in real time.

We keep our promises with one another - no matter what!
 
Best Regards,
Tina TSOU
http://tinatsou.weebly.com/contact.html
 
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Livingood, Jason
Sent: Monday, February 21, 2011 1:57 PM
To: Joel Jaeggli; Doug Barton
Cc: IPv6 Ops WG
Subject: Re: [v6ops] WGLC
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02

[JL] I am mid-way through those edits (will take another day or so to factor
them all in). These suggestions will be adopted in a -03 version along with
the other specific feedback received in the past few days of WGLC.
 
Regards
Jason

---

From: Thomas Narten <[email-masked]>
Date: Mon, 21 Feb 2011 17:03:05 -0500

OK. I did a quick read through of the document and think it's mostly
fine.

Two questions/issues.

First, I must have missed the text pointing out that whitelisting is
only a heuristic, in that it assumes that the address of query
identifies that actual requestor of the DNS info who will ultimately
initiate the v6 communication. In fact, the actual network address of
the client making the query may be unrelated to the DNS recursive
resolvers address, and thus the whitelisting policy a the server may
get this wrong. (This is certainly one of the complaints people have
raised.)

Where is this covered? I assume it is, and I admit to having missed
it, so I wonder if the point is being made a little too subtly. :-)

Second, is the DNSSEC section really this simple?

>    10.1.  DNSSEC Considerations
> 
>    DNS security extensions defined in [RFC4033], [RFC4034], and
>    [RFC4035] use cryptographic digital signatures to provide origin
>    authentication and integrity assurance for DNS data.  This is done by
>    creating signatures for DNS data on a Security-Aware Authoritative
>    Name Server that can be used by Security-Aware Resolvers to verify
>    the answers.  Since DNS whitelisting is implemented on an
>    authoritative server, which provides different answers depending upon
>    which resolver server has sent a query, the DNSSEC chain of trust is
>    not altered.  Therefore there are no DNSSEC implications per se.
>    However, any implementer of DNS whitelisting should be quite careful
>    if they implement both DNSSEC signing of their domain and also DNS
>    whitelisting of that same domain.  Specifically, those domains should
>    ensure that records are being appropriately and reliably signed,
>    which may well prove operationally and/or technically challenging.

This basically says you can make this work just fine with DNSSEC. Is
that so? Has this feature been implemented/deployed? I.e., do we have
real experience with this? Do DNSSEC folk agree with the above text?

Thomas

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 21 Feb 2011 17:50:29 -0500

Hi Jason,
   Thanks for putting together this draft. It provides a very good 
overview of the whitelisting process. I did have a few comments though

* Meta comment
==============

* This draft does not mention using a different (sub-)domain name as an 
alternative to whitelisting (e.g. as done in http://ipv6.google.com/ or 
http://www.v6.facebook.com/). I am not sure if you wanted to cover this 
here, but as the draft intends to also cover "what alternatives may 
exist", I think it may be useful to do so.

* Major
=======

* Section 2 (Figures 1 and 2)

I think the system logic (Fig 1) and the associated diagram (Fig 2) 
being described here are not correct. They ignore the fact that the DNS 
query is for a specific type (A or AAAA but not both) and the draft 
needs to mainly describe what happens when a AAAA query is received. I 
think it would greatly simplify things if these two were redone. e.g. 
Here is what I think the system logic should be

    1: The authoritative DNS server for example.com receives a DNS
       AAA query for www.example.com, for which AAAA
       (IPv6) address records exist.
    2: The authoritative DNS server examines the IP address of the DNS
       recursive resolver sending the query.
    3: The authoritative DNS server checks this IP address against the
       access control list (ACL) that is the DNS whitelist.
    4: If the DNS recursive resolver's IP address IS listed in the ACL,
       then the response to that specific DNS recursive resolver can
       contain AAAA (IPv6) address records.
    5: If the DNS recursive resolver's IP address IS NOT listed in the
       ACL, then the response to that specific DNS recursive resolver
       can cannot contain AAAA (IPv6) address records. The server should
       return a response with the response code (RCODE) being set to 0
       (No Error) with an empty answer section.

* Editorial
===========

* The reference names are too long and they obstruct the flow of the 
document.  e.g. "Network World Article on IETF 77 DNSOP WG Presentation" 
Is it possible to shorten them?

* Section 11

s/advise the end use/advise the end user/

Cheers
Suresh

---

From: Erik Kline <[email-masked]>
Date: Tue, 22 Feb 2011 11:35:34 +0900

> real experience with this? Do DNSSEC folk agree with the above text?

Certainly we (Google) have not tried to support both whitelisting and
DNSSEC.  Maybe there is some operational experience with it, but I've
not heard of any.

---

From: Erik Kline <[email-masked]>
Date: Tue, 22 Feb 2011 11:47:44 +0900

(agreeing with many sentiments)

> Simply put, if published this draft will do more harm than good. The major
> sites are already moving forward on wider v6 deployment, including Google,
> the site that popularized whitelisting. (See
> http://isoc.org/wp/worldipv6day/, et al) OTOH, sites that genuinely believe
> that they need to use this technique are going to use it whether this
> document is released or not. "It works for Google" is a much more persuasive
> line of reasoning. Releasing this now makes us look like a bunch of old
> ladies wagging our fingers at recalcitrant children.

After going 'round and 'round on this deciding if I should care about
this document or not, I ultimately decided "not, not at all".

The "manual overhead" complaints are certainly real and well
understood at this moment.  However, we (Google) have publicly stated
that all this will be automated and no communication will be required.

Note also that Akamai has publicly declared that they will
dynamically, automatically decide when to serve AAAAs and when not to.
 This is indistinguishble from automated whitelisting.  I suspect,
therefore, this draft will hold no water with them either, but
obviously can't speak for them.

In the end, I settled on the opinion that the IETF probably has to
publish RFCs that state warnings about things like "geographic load
balancing via DNS has the following implications:...", and then
everyone who has to go out and do that anyway goes out and does that
anyway.  In my mind this document is basically in that category.

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 22 Feb 2011 14:57:36 +0000

Ok, I'll grant you all of those, but I will also point out that all of
those costs are voluntary.

[JL] They are optional for the domain doing the whitelisting, but not really for others (such as network operators). Sure, in theory it is optional, but it will not long satisfy some users that they cannot access content X or Y via IPv6. So the cost burden is voluntary for the whitelisted domain and involuntary for others IMHO.

[JL] Others will follow the examples set during the transition. It's important to document this IMHO. I know you disagree, and I appreciate you sharing your perspective.

Jason

---

From: John Curran <[email-masked]>
Date: Wed, 23 Feb 2011 00:34:13 +0800

On Feb 22, 2011, at 5:10 AM, Doug Barton wrote:
> 
> I have been following this issue closely and I haven't seen one single statement that anyone believes that this should be a long-term solution, or that anyone plans to make it so. Do you have a reference that I may have missed?

Documenting the approach, including its benefits and 
limitations, is simply the right thing to do. It allows
others who come later to gain insight into some of the 
consideration that went into this particular solution.

> So to summarize once more, no good can come from publishing this, and it's likely that it will at least step on toes completely without reason to do so.

The publication itself is deemed useful by some of the WG.

We have yet to hear from a whitelisting party that actually views 
this as "stepping on toes" by publication (e.g. Erik Kline noted 
ambivalence & that "IETF probably has to publish RFCs that state 
warnings about things ...")  If some network would be offended by 
having this technique written up, it's time for them actually say 
that on this list, less we hold publication up for nothing more 
than a chimera.

/John

---

From: Fred Baker <[email-masked]>
Date: Tue, 22 Feb 2011 08:35:54 -0800

> that on this list, less we hold publication up for nothing more 

hear, hear!

---

From: Jason Fesler <[email-masked]>
Date: Tue, 22 Feb 2011 09:35:36 -0800

+1.

I'm not offended by the draft in the least.

It also won't affect whether or how we do whitelisting.  For reasons mentioned here, and in the draft.

-jason

On Feb 21, 2011, at 6:47 PM, Erik Kline wrote:

[email-masked]<mailto:[email-masked]>

---

From: Doug Barton <[email-masked]>
Date: Tue, 22 Feb 2011 10:23:37 -0800

On 02/22/2011 08:34, John Curran wrote:
> ambivalence&  that "IETF probably has to publish RFCs that state

The problem is that the people I'm speaking about don't bother 
participating anymore because the IETF echo chamber keeps publishing 
stuff like this that's at best irrelevant (as we've heard from 2 
relevant operators now) and at worst other things that are actively 
opposed to operational needs *cough*dhcpv6*cough*.

John, you've been a participant in the threads on the NANOG list where 
these exact topics (meaning, frustration with the IETF and its 
processes) are discussed, the frustration is expressed, and the 
operators have said point blank, "We don't bother with IETF anymore, 
they're not relevant."

You(pl.) can continue to sit on your hands and say, "Well if the 
operators want input they have to come here and give it" or you can 
listen to what some of the few operators left on the list are saying.

Doug

--

---

From: Mark Smith <[email-masked]>
Date: Wed, 23 Feb 2011 07:33:53 +1030

On Tue, 22 Feb 2011 10:23:37 -0800

> opposed to operational needs *cough*dhcpv6*cough*.

I'm an operator. My opinion is that the operators who complain are
those that don't bother spending the time properly understanding the
problem, including the scope of the scenarios that the solution needs
to address, or reading Internet Drafts where the problem is usually
first explained. It is my experience that most operators I've worked
with don't read RFCs at all, despite them being quite readable. They
just don't seem to be interested in advancing their understanding of
their chosen profession.

Participation is not announcing your opinion and then complaining when
it isn't blindly accepted.

A bit off topic, however DHCPv6 actually only really exists because
operators wanted it to. I don't think there is no strong functional need
for a stateful, database driven autoconfiguration method in a networking
protocol - it's just that that is how it was done in IPv4, because
keeping it as an ancestor of BOOTP probably made sense, and IPv4's node
addressing bits couldn't really facilitate any other mechanism. The
people who object to DHCPv6 not being able to be used for all
addressing aren't recognising there is a requirement (ie. they're not
bothering to understanding the problem) for a very light weight
stateless automatic addressing system for use on, for example, low
powered and resource constrained embedded systems. RAs exist because
these stateless nodes need to learn of available routers and other
information to autoconfigure themselves. As statefull addressing also
exists, there needs to be a mechanism to express to end-nodes the
addressing model being used on the link - RAs serve that purpose too.
People argue DHCPv6 should be able to supply the default gateway,
however I think they're ignoring the fact that RAs or something
similar, which makes most sense to be issued by onlink routers, still
need to exist to express which of the stateless / statefull onlink
addressing model is in use. Duplication of functionality just creates
more complexity. RAs are always going to be needed, so what is the
value in creating equivalent default gateway functionality DHCPv6?

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 23 Feb 2011 04:24:18 +0000

Suresh – Thanks for your review and detailed, specific feedback below. Your suggestions have been incorporated into a –03 update, which I will publish soon. Please see specific comments inline below for responses to each of the points you raise.

Thank you!
Jason

On 2/21/11 5:50 PM, "Suresh Krishnan" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jason,

* Meta comment
==============

[JL] Excellent suggestion! I have added a new sub-section to the Solutions part of the document. Here is how it will appear in the –03 version. Please let me know if you think this is sufficient or should be modified.

Gain Experience Using IPv6 Transition Names
Another alternative is for domains to gain experience using an FQDN which has become common for domains beginning the transition to IPv6; ipv6.example.com and www.ipv6.example.com. This can be a way for a domain to gain IPv6 experience and increase IPv6 use on a relatively controlled basis, and to inform any plans for DNS whitelisting with experience.

* Major
=======

[JL] Good feedback. I also received some other feedback on that section and so have synthesized it as follows below. Let me know if you think this is okay of course.

1. The authoritative DNS server for example.com receives DNS queries for the A (IPv4) and AAAA (IPv6) address resource records for the FQDN www.example.com, for which AAAA (IPv6) resource records exist.
2. The authoritative DNS server examines the IP address of the DNS recursive resolver sending the AAAA (IPv6) query.
3. The authoritative DNS server checks this IP address against the access control list (ACL) that is the DNS whitelist.
4 . If the DNS recursive resolver's IP address IS matched in the ACL, then the response to that specific DNS recursive resolver can contain AAAA (IPv6) address resource records.
5. If the DNS recursive resolver's IP address IS NOT matched in the ACL, then the response to that specific DNS recursive resolver cannot contain AAAA (IPv6) address resource records. In this case, the server should return a response with the response code (RCODE) being set to 0 (No Error) with an empty answer section for the AAAA record query.

* Editorial
===========

[JL] Sure thing – good suggestion. Also, in my recent experience, the RFC Editor will also look at those and they usually shorten them all further (or in different ways that are consistent in form across many documents). In any case, I have shortened all the non-RFC reference names.

* Section 11

[JL] Good catch! Corrected.

Thanks again!
Jason

Cheers
Suresh

joelja

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 23 Feb 2011 04:24:28 +0000

Thanks for your review and the feedback below. As noted in the other v6ops responses today, the changes you suggest will soon be reflected in a –03 update. Specific responses to the issues you identified are listed below.

Thank you,
Jason

On 2/21/11 5:03 PM, "Thomas Narten" <[email-masked]<mailto:[email-masked]>> wrote:

[JL] Cool – good to hear.

Two questions/issues.

[JL] Well, perhaps so subtly that it was missed! ;-) Thanks for pointing this out. I am planning to add this brief text at the end of Section 4 (Concerns Regarding DNS Whitelisting) as noted below. Let me know if you think this text should be modified of course.

An additional concern is that the IP address of a recursive resolver is not a precise indicator of the IPv6 preparedness, or lack of IPv6-related impairments, of end user hosts which query (use) a particular recursive resolver. While the recursive resolver may be an imperfect proxy for judging IPv6 preparedness, it is at least one of the best available methods at the current time.

[JL] I'm not aware that anyone has put this into practice as of yet, but people with the relevant expertise have indicated it should work fine (this will of course get an even closer review during both IESG review and a security review, which typically follow WGLC). Basically, the authoritative server is handling the responses from recursive servers. Since the authoritative server is therefore the control point, it can sign both A and AAAA RRs, and it is just that the AAAAs are not always handed out. So this should be okay from the perspective of a chain-of-trust (in contrast to if a recursive resolver attempted to say block or rewrite AAAA RR responses in a signed domain).

However, this made me think that I have a related item in Section 3 that I modified as follows (see underlined text):

These end user networks may also have other tools at their disposal in order to address this concern, including applying rules to network equipment such as routers and firewalls (this will necessarily vary by the type of network, as well as the technologies used and the design of a given network), as well as configuration of their recursive resolvers (though modifying or suppressing AAAA resource records in a DNSSEC-signed domain on a Security-Aware Resolver will be problematic [reference to DNSSEC section]).

In any case, based on my last email to Tina Tsou, here's the latest text for that section. I've now added a second paragraph to this, based on the new text above in Section 3. Don't hesitate to suggest modifications of course to any of this section.

DNS security extensions defined in [RFC4033]<applewebdata://F36861A5-8A63-428E-9EF2-B6649FA1406F#RFC4033>, [RFC4034]<applewebdata://F36861A5-8A63-428E-9EF2-B6649FA1406F#RFC4034>, and [RFC4035]<applewebdata://F36861A5-8A63-428E-9EF2-B6649FA1406F#RFC4035> use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creating signatures for DNS data on a Security-Aware Authoritative Name Server that can be used by Security-Aware Resolvers to verify the answers. Since DNS whitelisting is implemented on an authoritative server, which provides different answers depending upon which resolver server has sent a query, the DNSSEC chain of trust is not altered. Even though the authoritative server will not always return a AAAA resource record when one exists, respective A resource records and AAAA resource records can and should both be signed.  Therefore there are no DNSSEC implications per se. However, any implementer of DNS whitelisting should be careful if they implement both DNSSEC signing of their domain and also DNS whitelisting of that same domain. Specifically, those domains should ensure that resource records are being appropriately and reliably signed, which may present incremental operational and/or technical challenges.

However, as noted in [Section 3], end user networks may also choose to implement tools at their disposal in order to address IPv6-related impairments. One of those possible tools could involve unspecified changes to the configuration of their recursive resolvers. If it is a Security-Aware Resolver, modifying or suppressing AAAA resource records for a DNSSEC-signed domain will be problematic and could break the chain of trust established with DNSSEC.

Thanks,
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 23 Feb 2011 04:24:24 +0000

Hi Tina – Thank you for your review and specific feedback below. These changes will be in the –03 update soon. See my specific responses inline below.

Thanks!
Jason

On 2/21/11 5:13 PM, "Tina Tsou" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,
I generally support this document as attempt on real operational issues involved in the deployment of IPv6.

[JL] Thanks! :-)

Comments on section 10.1 “DNSSEC Considerations” are below.
It says that different answers are sent to different querying hosts. If those are all known in advance, and the server has the DNS zone signing key, it can separately sign the various alternative answer data sets however you want. If they are not known in advance, then you have to have the keys on-line so you can sign answer data in real time…

[JL] Good point. I have attempted to make this more clear. Here is how that section now appears. If you think this needs further modification, just say so.

DNS security extensions defined in [RFC4033], [RFC4034], and [RFC4035] use cryptographic digital signatures to provide origin authentication and integrity assurance for DNS data. This is done by creating signatures for DNS data on a Security-Aware Authoritative Name Server that can be used by Security-Aware Resolvers to verify the answers. Since DNS whitelisting is implemented on an authoritative server, which provides different answers depending upon which resolver server has sent a query, the DNSSEC chain of trust is not altered. Even though the authoritative server will not always return a AAAA resource record when one exists, respective A resource records and AAAA resource records can and should both be signed.  Therefore there are no DNSSEC implications per se. However, any implementer of DNS whitelisting should be careful if they implement both DNSSEC signing of their domain and also DNS whitelisting of that same domain. Specifically, those domains should ensure that resource records are being appropriately and reliably signed, which may present incremental operational and/or technical challenges.

Thank you again,
Jason

We keep our promises with one another – no matter what!

Best Regards,
Tina TSOU

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Livingood, Jason
Sent: Monday, February 21, 2011 1:57 PM
To: Joel Jaeggli; Doug Barton
Cc: IPv6 Ops WG
Subject: Re: [v6ops] WGLC draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02

Regards
Jason

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 22 Feb 2011 21:30:32 -0800

While this is a different type of white-listing, is it relevant to
include a brief discussion of the so-called "yahoo dns hack"
www.ietf.org/proceedings/77/slides/dnsop-7.pdf ?  I am not sure if it
is documented in any other place as an IETF draft or not, but it is
implemented today in multiple types of DNS server software.

This is a unique case from the rest of the white-listing doc, so it
may be out of scope, but i think it is in the same solution space, but
different angle, and may impact on how white-listing from the
authoritative servers works given that the authoritative policies will
be more willing if their is IPv6 workign from end to end
(client-recursive-authoritative).

If i understand it correctly, this is an action on the recursive name
server, not that authoritative name server.  I believe it is a
relevant tool, especial in a world of hobbled 6to4 and bogon address
space.  The broken customer calls will come into the ISPs help desk,
and this may be a relevant tool to make IPv6 customers happy and keep
IPv4 customers working without spending hours troubleshooting the
customer LAN.

If you think this is out of scope and confuses the issue, i
understand.  But perhaps including it will make it clear the different
between recursive namer server white listing vs authoritative name
server white-listing

Cameron

---

From: Jason Fesler <[email-masked]>
Date: Tue, 22 Feb 2011 23:57:19 -0800

On Feb 22, 2011, at 9:30 PM, Cameron Byrne wrote:

> www.ietf.org/proceedings/77/slides/dnsop-7.pdf ?

FWIW: When we originally discussed that (in a small group) it was believed that at least one carrier could influence their IPv6 capable users to query the DNS resolvers over IPv6.  The number of ISPs that can do that (today) I suspect are limited; so the original framing of this proposal should be deemphasized.

That said, the feature set that we sponsored in bind *does* allow for an easy way for a single recursor to offer A+AAAA to one pool, and A only (when both would otherwise exist) to your second pool.  That alone can be used to help mitigate the so called "broken user problem", and allow that particular recursor to score well with automated whitelisting systems.  So, there is value with the system; just not necessarily as directly as we had hoped.

Your other points, imo, are quite valid - but I must admit a bias.

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 23 Feb 2011 00:09:10 -0800

On Feb 22, 2011 11:57 PM, "Jason Fesler" <[email-masked]> wrote:
> FWIW: When we originally discussed that (in a small group) it was believed
that at least one carrier could influence their IPv6 capable users to query
the DNS resolvers over IPv6.  The number of ISPs that can do that (today) I
suspect are limited; so the original framing of this proposal should be
deemphasized.

It applies very well to mobile

Cb

> That said, the feature set that we sponsored in bind *does* allow for an
easy way for a single recursor to offer A+AAAA to one pool, and A only (when
both would otherwise exist) to your second pool.  That alone can be used to
help mitigate the so called "broken user problem", and allow that particular
recursor to score well with automated whitelisting systems.  So, there is
value with the system; just not necessarily as directly as we had hoped.

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 23 Feb 2011 14:47:42 +0000

I see Jason Fesler replied on the substance of most of your questions. For the purposes of this document, I'd like to keep it out of scope though. It certainly may be worth a separate I-D from someone else, but it may be a DNSEXT WG draft (TBD).

JL

On 2/23/11 12:30 AM, "Cameron Byrne" <[email-masked]<mailto:[email-masked]>> wrote:

Cameron

---

From: Doug Barton <[email-masked]>
Date: Wed, 23 Feb 2011 12:28:18 -0800

On 02/22/2011 06:57, Livingood, Jason wrote:
> [JL] They are optional for the domain doing the whitelisting, but not
> really for others (such as network operators). Sure, in theory it is
> optional, but it will not long satisfy some users that they cannot
> access content X or Y via IPv6. So the cost burden is voluntary for the
> whitelisted domain and involuntary for others IMHO.

I think you misunderstood me on "optional." I meant that the costs are 
optional for those networks _applying_ to be whitelisted, but there is 
an even more serious disconnect apparent in what you wrote above.

In my first post about this draft I pointed out that I think most of 
Section 4 is pointless because no one is going to be deploying v6-only 
hosts any time soon. Obviously I need to amplify my point.

NO ONE IS GOING TO BE ....

just kidding. :)

But seriously folks, while we still live in a mostly-v4 world there are 
simply not going to be content providers putting up v6-only hosts. It 
will be years from now before that happens, and when it happens it will 
be (in large part) _because_ the issues that whitelisting is designed to 
avoid are no longer a problem. So you're completely on the wrong side of 
the chicken-egg problem to start with.

But this is also an excellent example of why I think people are likely 
to find this draft offensive rather than helpful. Do you(pl.) honestly 
believe that operators are so incredibly stupid that the need to have it 
explained to them that, "If you put up a v6-only host, and then do 
whitelisting, some people with v6 transport won't be able to reach it." 
And if you _do_ believe that it's necessary to explain that, can you 
explain to me why you believe it?

Doug

--

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 23 Feb 2011 22:39:02 -0800

Last Call for this document has concluded...

Jason did an epic job at turning around both the suggested changes and
the minor  but relatively numerous language edits suggested. The result
is draft-03

here:

http://tools.ietf.org/html/draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03

and the diff1 output

here:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03.txt

Barring the signficant gnashing of teeth, we will proceed with a
document shepherd writeup and request IESG publication. Doug Barton's
criticsm will be noted in the document shepherd review which I will
circulate probably Monday. if anyone feels like they might be inclined
to file an appeal at some later date please let me know so I can inlude
that information in the packet for the IESG.

thanks.
joel

---

From: Doug Barton <[email-masked]>
Date: Wed, 23 Feb 2011 23:03:50 -0800

On 02/23/2011 22:39, Joel Jaeggli wrote:
> circulate probably Monday.

Thanks.

> if anyone feels like they might be inclined

"Not I" said the fly. :) It's clear that the mood of the group is to 
allow the draft to move forward.

Doug

--

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 23 Feb 2011 23:33:32 -0800

Thanks!

Joel

---

From: Tina Tsou <[email-masked]>
Date: Thu, 24 Feb 2011 11:41:44 -0800

Hi Jason,
I think the wording below is OK. I would see if anyone complains about the
wording. It could be a bit more specific. For example, you could add a few
words right at the end so instead of
 
                ... may present incremental operational and/or technical
challenges.
 
it said
 
                ... may present incremental operational and/or technical
challenges such as a requirement for on-line signing.

Best Regards,
Tina TSOU
 
From: Livingood, Jason [mailto:[email-masked]] 
Sent: Tuesday, February 22, 2011 8:24 PM
To: Tina Tsou
Cc: 'IPv6 Ops WG'
Subject: Re: [v6ops] WGLC
draft-ietf-v6ops-v6-aaaa-whitelisting-implications-02
 
Hi Tina - Thank you for your review and specific feedback below. These
changes will be in the -03 update soon. See my specific responses inline
below.
 
Thanks!
Jason
 
On 2/21/11 5:13 PM, "Tina Tsou" <[email-masked]> wrote:
 
Hi,
 
[JL] Thanks! :-)

[JL] Good point. I have attempted to make this more clear. Here is how that
section now appears. If you think this needs further modification, just say
so.
 
DNS security extensions defined in [RFC4033], [RFC4034], and [RFC4035] use
cryptographic digital signatures to provide origin authentication and
integrity assurance for DNS data. This is done by creating signatures for
DNS data on a Security-Aware Authoritative Name Server that can be used by
Security-Aware Resolvers to verify the answers. Since DNS whitelisting is
implemented on an authoritative server, which provides different answers
depending upon which resolver server has sent a query, the DNSSEC chain of
trust is not altered. Even though the authoritative server will not always
return a AAAA resource record when one exists, respective A resource records
and AAAA resource records can and should both be signed.  Therefore there
are no DNSSEC implications per se. However, any implementer of DNS
whitelisting should be careful if they implement both DNSSEC signing of
their domain and also DNS whitelisting of that same domain. Specifically,
those domains should ensure that resource records are being appropriately
and reliably signed, which may present incremental operational and/or
technical challenges.

Thank you again, 
Jason

 
Best Regards,
Tina TSOU

 
 
Regards
Jason

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 24 Feb 2011 14:18:19 -0800

I don't think we need to be that specific about how people sort out the
issue of signing their zones. if 4470 is required for a particular
deployment it's probably because you have some condition or desire other
than two differing views of the same zone.

On 2/24/11 11:41 AM, Tina Tsou wrote:
> Hi Jason,
> 
> I think the wording below is OK. I would see if anyone complains about
> the wording. It could be a bit more specific. For example, you could add
> a few words right at the end so instead of
> 
>  
> 
> itsaid
>  < /span>We keep our promises with one another – no matter what!
> 
>  
> 
> Best Regards,
> 
> Tina TSOU
> 
> *From:*Livingood, Jason [mailto:[email-masked]]
> *Sent:* Tuesday, February 22, 2011 8:24 PM
> *To:* Tina Tsou
> *Cc:* 'IPv6 Ops WG'
> *Subject:* Re: [v6ops] WGLC
> < al>Hi Tina – Thank you for your review and specific feedback below.
> These changes will be in the –03 update soon. See my specific responses
> inline below.
> 
>  
> 
> Thanks!
> 
> Jason
> 
>  
> 
>     I generally support this document as attempt on real operational
>     issues involved in the deployment of IPv6.
> 
> < p class=
> nt-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New
> Roman";color:black'> 
> 
> [JL] Thanks! :-)
> 
>  
> 
>     It says e sent to different querying hosts. If those are all known
>     in advance, and the server has the DNS zone signing key, it can
>     separately sign the various alternative answer data sets however you
>     want. If they are not known in advance, then you have to have the
>     keys on-line so you can sign answer data in real time…
> 
>  
> 
> [JL] Good point. I have attempted to make this more clear. Here is how
> that section now appears. If you think this needs further modification,
> just say so.
> 
> /DNS security extensions defined in /*/[RFC4033]/*
> <#RFC4033>/, /*/[RFC4034]/* <#RFC4034>/, and /*/[RFC4035]/*
> <#RFC4035>/ use cryptographic digital signatures to provide origin
> creating signatures for DNS data on a Security-Aware Authoritative Name
> Server that can be used by Secu rity-Awa e answers. //Since DNS
> whitelisting is implemented on an authoritative server, which provides
> different answers depending upon which resolver server has sent a query,
> the DNSSEC chain of trust is not altered. Even though the authoritative
> server will not always return a AAAA resource record when one exists,
> respective A resource records and AAAA resource records can and should
> both be signed.  Therefore there are no DNSSEC implications per se.
> However, any implementer of DNS whitelisting should be careful if they
> implement both DNSSEC signing of their domain and also DNS whitelisting
> of that same domain. Specifically, those domains should ensure that
> resource records are being appropriately and reliably signed, which may
> present incremental operational and/or technical challenges./
> 
>  
> 
>  
> 
> Thank you again, 
> 
> Jason
> 
>  
> 
>      
> 
>      
> 
>     Tina TSOU <
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked]] *On Behalf Of *Livingood, Jason
>     *Sent:* Monday, February 21, 2011 1:57 PM
>     *To:* Joel Jaeggli; Doug Barton
>     *Cc:* t: Re: [v6ops] WGLC
>         I think that the characterization of the problems with a
>         whitelistingapproach is useful and important. It's going to
>         (has) happened anyway
> 
>     [JL] I am mid-way through those edits (will take another day or so
>     to factor them all in). These suggestions will be ad opted in g with