[dnsop] Issues with draft-ietf-dnsop-ipv6-dns-configuration-04.txt

[Iljitsch van Beijnum <[e-mail]>]

Dear IESG,

As the dnsop wg chairs have decided against another iteration on 
draft-ietf-dnsop-ipv6-dns-configuration-04.txt, I'm taking them up on 
their suggestion to send any remaining gripes directly to the IESG 
(with a cc to the wg list).

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

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html