IPv6 Host Configuration of DNS Server Information Approaches
draft-ietf-dnsop-ipv6-dns-configuration-06

[Ballot discuss]
This document has normative references to mechanisms (such as the RA DNS configuration mechanism) that the IETF has no active effort to standardize (or even publish) as far as I know.

[Ballot discuss]
This document has normative references to mechanims (such as the RA DNS configuration mechanism) that the IETF has no active effort to standardize (or even publish) as far as I know.

[Ballot comment]
Comments from David Kessens:

The WLAN discussion is problematic. First problem is that there is no
definition of what WLAN actually is (802.11a/b/g perhaps ?) and
secondly because the problems that 802.11a/b/g supposedly has in the 
RA context can be considered as a general RA issue that is not related
at all to adding the DNS option. 
Specifically, if one already uses route advertisements over a WLAN
anyways, I cannot see why adding a DNS option would really make things
worse. More appropriate wording would be something like: 'The RA
option solution might not work very well on a congested medium that
uses reliable multicast for RA'.
actices, but provides no analysis of the security implications of multihoming.

Comments received from Iljitsch van Beijnum  (13 Oct 2004 10:45:15 +0200):

This message is mostly the same as one I posted to the wg list
yesterday. See that one for an additional list of smaller nits.
                                                                                       
First a side issue.
                                                                                       
Under the ND approach there are remarks about multicast difficulties in
wireless environments. There is some additional talk about multicast in
wireless environments in an appendix, but this discussion doesn't
capture the real-world complexities that exist here (and that DHCP also
uses multicast but the issue is very different there). The pertinent
information has been discussed on the list so including it shouldn't be
too hard, or maybe a spin-off informational RFC would be appropriate.
Also note that there isn't much of a real-world issue: ARP in IPv4 also
works, while it suffers from the same broadcast/multicast problems as
IPv6 neighbor discovery.

More to the point, two very important issues are missing.
                                                                                       
The first is that we are living in 2004. If this were 2001, we could
simply identify the best approach and standardize it. However, IPv6 is
already widely implemented in hosts and deployment is growing. The lack
of a recursive resolver configuration mechanism is felt every day. If
we select an approach that needs considerable implementation effort, it
can be as much as two years before this approach is actually available
to users. The worst choice in this regard would be the RA approach.
While in itself this is a very good approach, it suffers from the fact
that both routers and hosts must support it before it can be used.
Implementation cycles vary widely throughout the industry, but it's
safe to say that anyone who doesn't use both routers AND hosts with the
shortest implementation cycle will have to wait at least until 2006
before an RA approach could conceivably be available.
                                                                                       
The DHCP approach has the advantage that it can be implemented on
special purpose servers rather than having to be implemented in
routers. Some systems use a very simple mechanism to configure
recursive resolver addresses, and on those systems it's very easy to
add a userland DHCP client daemon that handles this task. However, on
widely used systems such as Windows and MacOS X reconfiguring recursive
resolvers isn't something that can be easily done by a userland
program. Realistically, users will have to wait until Microsoft or
Apple bundle support for DHCPv6 in their products. Again, this is
likely to take a significant amount of time.

The well-known address approach on the other hand, can be deployed
pretty much immediately. The only thing that's needed is for IANA to
register a set of addresses and within weeks these addresses would be
usable by any IPv6 implementation that supports DNS queries over IPv6
transport.
                                                                                       
The second issue is security.
                                                                                       
One thing that bothers me about a DHCP-only approach is that it
requires networks that have otherwise no interest in DHCPv6 to run
DHCPv6 servers and clients. Past experience shows that complex
UDP-based protocols are often implemented insecurely. So an approach
that doesn't require additional protocols would be preferable from a
security standpoint. (And from management and debugging standpoints as
well.)
                                                                                       
Both DHCPv6 and RA have an inherent security problem because the host
is supposed to trust information that comes in from unknown sources.
This makes it very easy for an on-link attacker to present itself as a
legitimate DHCP server or router and provide clandestine configuration
information. I believe efforts are underway to remedy this situation,
but again, it will be some time before most clients will be able to use
these new mechanisms in practice. In the mean time having recursive
resolver information be available over insecure DHCP or RA means that
attackers gain an additional attack vector. (And heavy crypto doesn't
exactly go hand in hand with autoconfiguration, it remains to be seen
how well this is going to work in practice for nomadic users.)

Last but not least, not about the draft but about the decision that
needs to be made: it worries me that this issue hasn't been resolved
earlier. I believe one of the main reasons for this is that the DHCP
proponents are blocking consensus on the other approaches in order to
arrive at the situation where everyone implements DHCP and the issue
becomes moot. Note that there are several IPR claims on parts of DHCP
that may or may not apply here, adding insult to injury for those who
don't want to run DHCP in the first place.
                                                                                       
The only way to overcome this abuse of the IETF process is for the IESG
to recognize the lack of consensus and decide on the issue itself.
                                                                                       
Iljitsch van Beijnum

---

Comments from the ops directorate (Mar 30 17:21:11 PST 2005):

1. The document would benefit from a grammar edit.  Rather than requiring
the RFC Editor to do this work, I would prefer to see documents correct
grammatical mistakes prior to submission to the IESG.

2. The security considerations section (6) does not describe the
security implications of each approach.  This is important
because the approaches have different security implications.
For example, the RDNSS approach would utilize SEND for security,
which implies that the client has a trust anchor configured,
and the server signs RA messages.  On the other hand, the DHCPv6
approach would utilize DHCPv6 security, which has a different
trust model.  The anycast approach does not require
configuration security, since there is no protocol.

3. This document does not address the implications of DNS
configuration approaches on the use of link-local DNS
resolution, such as mDNS and LLMNR.  For example, where a
DNS server is not available, in the RDNSS or DHCPv6 case
no DNS server is configured, and link local name resolution
will be used exclusively without DNS queries being sent.
However, in the anycast case, DNS queries will be sent,
and if not answered, DNS clients may agressively retransmit.
Linklocal name resolution will only take place once they
time out.  The difference is particularly important for
dual stack hosts residing on IPv4 native networks, where the anycast
approach could result in persistent (and unnecessary) DNS traffic.

[Ballot comment]
The WLAN discussion is problematic. First problem is that there is no
definition of what WLAN actually is (802.11a/b/g perhaps ?) and
secondly because the problems that 802.11a/b/g supposedly has in the 
RA context can be considered as a general RA issue that is not related
at all to adding the DNS option. 
Specifically, if one already uses route advertisements over a WLAN
anyways, I cannot see why adding a DNS option would really make things
worse. More appropriate wording would be something like: 'The RA
option solution might not work very well on a congested medium that
uses reliable multicast for RA'.
actices, but provides no analysis of the security implications of multihoming.

Comments received from Iljitsch van Beijnum  (13 Oct 2004 10:45:15 +0200):

This message is mostly the same as one I posted to the wg list
yesterday. See that one for an additional list of smaller nits.
                                                                                       
First a side issue.
                                                                                       
Under the ND approach there are remarks about multicast difficulties in
wireless environments. There is some additional talk about multicast in
wireless environments in an appendix, but this discussion doesn't
capture the real-world complexities that exist here (and that DHCP also
uses multicast but the issue is very different there). The pertinent
information has been discussed on the list so including it shouldn't be
too hard, or maybe a spin-off informational RFC would be appropriate.
Also note that there isn't much of a real-world issue: ARP in IPv4 also
works, while it suffers from the same broadcast/multicast problems as
IPv6 neighbor discovery.

More to the point, two very important issues are missing.
                                                                                       
The first is that we are living in 2004. If this were 2001, we could
simply identify the best approach and standardize it. However, IPv6 is
already widely implemented in hosts and deployment is growing. The lack
of a recursive resolver configuration mechanism is felt every day. If
we select an approach that needs considerable implementation effort, it
can be as much as two years before this approach is actually available
to users. The worst choice in this regard would be the RA approach.
While in itself this is a very good approach, it suffers from the fact
that both routers and hosts must support it before it can be used.
Implementation cycles vary widely throughout the industry, but it's
safe to say that anyone who doesn't use both routers AND hosts with the
shortest implementation cycle will have to wait at least until 2006
before an RA approach could conceivably be available.
                                                                                       
The DHCP approach has the advantage that it can be implemented on
special purpose servers rather than having to be implemented in
routers. Some systems use a very simple mechanism to configure
recursive resolver addresses, and on those systems it's very easy to
add a userland DHCP client daemon that handles this task. However, on
widely used systems such as Windows and MacOS X reconfiguring recursive
resolvers isn't something that can be easily done by a userland
program. Realistically, users will have to wait until Microsoft or
Apple bundle support for DHCPv6 in their products. Again, this is
likely to take a significant amount of time.

The well-known address approach on the other hand, can be deployed
pretty much immediately. The only thing that's needed is for IANA to
register a set of addresses and within weeks these addresses would be
usable by any IPv6 implementation that supports DNS queries over IPv6
transport.
                                                                                       
The second issue is security.
                                                                                       
One thing that bothers me about a DHCP-only approach is that it
requires networks that have otherwise no interest in DHCPv6 to run
DHCPv6 servers and clients. Past experience shows that complex
UDP-based protocols are often implemented insecurely. So an approach
that doesn't require additional protocols would be preferable from a
security standpoint. (And from management and debugging standpoints as
well.)
                                                                                       
Both DHCPv6 and RA have an inherent security problem because the host
is supposed to trust information that comes in from unknown sources.
This makes it very easy for an on-link attacker to present itself as a
legitimate DHCP server or router and provide clandestine configuration
information. I believe efforts are underway to remedy this situation,
but again, it will be some time before most clients will be able to use
these new mechanisms in practice. In the mean time having recursive
resolver information be available over insecure DHCP or RA means that
attackers gain an additional attack vector. (And heavy crypto doesn't
exactly go hand in hand with autoconfiguration, it remains to be seen
how well this is going to work in practice for nomadic users.)

Last but not least, not about the draft but about the decision that
needs to be made: it worries me that this issue hasn't been resolved
earlier. I believe one of the main reasons for this is that the DHCP
proponents are blocking consensus on the other approaches in order to
arrive at the situation where everyone implements DHCP and the issue
becomes moot. Note that there are several IPR claims on parts of DHCP
that may or may not apply here, adding insult to injury for those who
don't want to run DHCP in the first place.
                                                                                       
The only way to overcome this abuse of the IETF process is for the IESG
to recognize the lack of consensus and decide on the issue itself.
                                                                                       
Iljitsch van Beijnum

[Ballot comment]
This is a ridiculous form of rhetorical argument:

  Therefore, if ND supports the configuration of some additional
  services, such as DNS, NTP and SIP servers, ND should be extended
  in kernel part, and complemented by a user-land process.

There would be immediate architectural and SIP pushback against adding SIP to ND,
so using this as a whipping boy is ridiculous, and probably shows a negative technique
under way here.

[Ballot comment]
Where is RA going - to add a broad array of services to ND: they mention
SIP servers as well as NTP.  This slippery slope is nasty.

[Ballot comment]
This is a ridiculous form of rhetorical argument:

  Therefore, if ND supports the configuration of some additional
  services, such as DNS, NTP and SIP servers, ND should be extended
  in kernel part, and complemented by a user-land process.

There would be immediate architectural and SIP pushback against adding SIP to ND,
so using this as a whipping boy is ridiculous, and probably shows a negative technique
under way here.

[Ballot comment]
$ findref draft-ietf-dnsop-ipv6-dns-configuration-04.txt

!! Missing citation for Normative reference:
  P020 L013:    [1]  S. Bradner, "Intellectual Property Rights in IETF Technology",

!! Missing citation for Normative reference:
  P020 L016:    [2]  S. Bradner, "IETF Rights in Contributions", RFC 3667, February

$ idnits-v1.47 draft-ietf-dnsop-ipv6-dns-configuration-04.txt
idnits 1.47 (02 Nov 2004)

draft-ietf-dnsop-ipv6-dns-configuration-04.txt:

  The document seems to lack an IANA Considerations section
  Checking conformance with RFC 3667/3668 boilerplate...
  The document seems to lack an RFC 3667 Section 5.1 IPR Disclosure Acknowledgement
  -- however, there's a paragraph with a matching beginning. Boilerplate error?

  Warnings:
    There are 18 instances of lines with hyphenated line breaks in the document.

[Ballot comment]
A number of sentences are missing a "the" according to my sense of English, but are nonetheless clear.

I found the explanation of the anycast option difficult to follow.

Reviewed by Joel Halpern, Gen-ART.
His review:

This draft is basically ready for publication as an Informational RFC, but has nits that should be fixed before publication.  There is one item that I think needs clarification before publication.

Specifically, I found one aspect of this document confusing.  In discussing the use of well known anycast addresses for the recursive DNS server, several things are stated.  One is that the Host can be pre-configured, possibly by the factory, with the suitable address.  The other is that multiple servers may have distinct anycast addresses.
  "Redundancy by multiple RDNSSes is better provided
by multiple servers having different anycast addresses than multiple
servers sharing same anycast address...

I do not follow how the hsot can be pre-configured with the anycast address when there different anycast addresses in use.  Can this really be describes as "a well known anycast address"?

[Ballot discuss]
I think this document should have pointers to various other docs describing work we have done with anycast addresses. An IESG note may be appropriate; I've suggested one on the IESG list.

[Ballot discuss]
I think the section on the anycast approach needs extensive work.  As it stands now,
the document says that they don't mean RFC 1546 or RFC 3513 versions of anycast,
but doesn't quite ever come out and say what it does mean.  It comes close with:

  The approach with well-known anycast addresses is to set well-known
  anycast addresses in clients' resolver configuration files from the
  beginning, say, as factory default.  Thus, there is no transport
  mechanism and no packet format [9].
 
  An anycast address is an address shared by multiple servers (in
  this case, the servers are RDNSSes).  Request from a client to the
  anycast address is routed to a server selected by the routing
  system. However, it is a bad idea to mandate "site" boundary on
  anycast addresses, because most users just do not have their own
  servers and want to access their ISPs' across their site boundaries.
  Larger sites may also depend on their ISPs or may have their own
  RDNSSes within "site" boundaries.

This looks an awful like what was described in RFC 3258 without
any of the caveats related to routing system changes or finding
the administrative entity responsible.  More importantly, though,
it presumes that a well-known address burned into non-volatile
memory is not going to turn into the NTP problem we just
said was harmful; what makes the author so sure?  If this isn't something
required to be provided by the "site", then it becomes something where
one site's users could DoS another's--accidentally or on purpose.  To fix that,
you would actually have to filter traffic to this address from
non-customer peers, which is not mentioned as one of the costs.
It also doesn't acknowledge how easy this makes hijacking
or what it would take to make  DNSSEC help (it is the authoritative
servers that would have to move to DNSSEC to make hijacking
of the recursive servers less of a problem)

[Ballot comment]
I'd like to echo Steve's comments about dnssec.  This document should
discuss it in the security considerations section.  Also, the text in
that section about autoconfiguration is misleading in the far
long-term.  Configuration of root keys might be acceptable in many
environments where configuration of other state would be unacceptable.
I realize this is not an option today.

I disagree with Iljitsch van Beijnum that the anycast approach is more
secure.  It seems that it would suffer from the same sort of on-link
attacks as the RA and DHCP approaches.

[Ballot comment]
The Security Considerations section should be updated to mention DNSsec; if it is used -- and the signatures verified on the client host -- misconfiguration of a DNS server is simply denial of service.

[Ballot comment]
Comments received from Iljitsch van Beijnum  (13 Oct 2004 10:45:15 +0200):

This message is mostly the same as one I posted to the wg list
yesterday. See that one for an additional list of smaller nits.
                                                                                       
First a side issue.
                                                                                       
Under the ND approach there are remarks about multicast difficulties in
wireless environments. There is some additional talk about multicast in
wireless environments in an appendix, but this discussion doesn't
capture the real-world complexities that exist here (and that DHCP also
uses multicast but the issue is very different there). The pertinent
information has been discussed on the list so including it shouldn't be
too hard, or maybe a spin-off informational RFC would be appropriate.
Also note that there isn't much of a real-world issue: ARP in IPv4 also
works, while it suffers from the same broadcast/multicast problems as
IPv6 neighbor discovery.

More to the point, two very important issues are missing.
                                                                                       
The first is that we are living in 2004. If this were 2001, we could
simply identify the best approach and standardize it. However, IPv6 is
already widely implemented in hosts and deployment is growing. The lack
of a recursive resolver configuration mechanism is felt every day. If
we select an approach that needs considerable implementation effort, it
can be as much as two years before this approach is actually available
to users. The worst choice in this regard would be the RA approach.
While in itself this is a very good approach, it suffers from the fact
that both routers and hosts must support it before it can be used.
Implementation cycles vary widely throughout the industry, but it's
safe to say that anyone who doesn't use both routers AND hosts with the
shortest implementation cycle will have to wait at least until 2006
before an RA approach could conceivably be available.
                                                                                       
The DHCP approach has the advantage that it can be implemented on
special purpose servers rather than having to be implemented in
routers. Some systems use a very simple mechanism to configure
recursive resolver addresses, and on those systems it's very easy to
add a userland DHCP client daemon that handles this task. However, on
widely used systems such as Windows and MacOS X reconfiguring recursive
resolvers isn't something that can be easily done by a userland
program. Realistically, users will have to wait until Microsoft or
Apple bundle support for DHCPv6 in their products. Again, this is
likely to take a significant amount of time.

The well-known address approach on the other hand, can be deployed
pretty much immediately. The only thing that's needed is for IANA to
register a set of addresses and within weeks these addresses would be
usable by any IPv6 implementation that supports DNS queries over IPv6
transport.
                                                                                       
The second issue is security.
                                                                                       
One thing that bothers me about a DHCP-only approach is that it
requires networks that have otherwise no interest in DHCPv6 to run
DHCPv6 servers and clients. Past experience shows that complex
UDP-based protocols are often implemented insecurely. So an approach
that doesn't require additional protocols would be preferable from a
security standpoint. (And from management and debugging standpoints as
well.)
                                                                                       
Both DHCPv6 and RA have an inherent security problem because the host
is supposed to trust information that comes in from unknown sources.
This makes it very easy for an on-link attacker to present itself as a
legitimate DHCP server or router and provide clandestine configuration
information. I believe efforts are underway to remedy this situation,
but again, it will be some time before most clients will be able to use
these new mechanisms in practice. In the mean time having recursive
resolver information be available over insecure DHCP or RA means that
attackers gain an additional attack vector. (And heavy crypto doesn't
exactly go hand in hand with autoconfiguration, it remains to be seen
how well this is going to work in practice for nomadic users.)

Last but not least, not about the draft but about the decision that
needs to be made: it worries me that this issue hasn't been resolved
earlier. I believe one of the main reasons for this is that the DHCP
proponents are blocking consensus on the other approaches in order to
arrive at the situation where everyone implements DHCP and the issue
becomes moot. Note that there are several IPR claims on parts of DHCP
that may or may not apply here, adding insult to injury for those who
don't want to run DHCP in the first place.
                                                                                       
The only way to overcome this abuse of the IETF process is for the IESG
to recognize the lack of consensus and decide on the issue itself.
                                                                                       
Iljitsch van Beijnum