Subject: Re: [dnsop] new WGLC on "IPv6 Host Configuration of DNS Server Information Approaches"

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Oct 2004 13:16:05 +0200

On 30-sep-04, at 14:36, David Meyer wrote:

> 	This note starts the (hopefully last) WG Last Call for
> 	comments on draft-ietf-dnsop-ipv6-dns-configuration-04.txt,
> 	"IPv6 Host Configuration of DNS Server Information
> 	Approaches".

I'm glad we now at least have a document that documents the approaches. 
However, this document fails to provide a good basis for deciding which 
approaches should be followed through. Many of the pros and cons listed 
are questionable, and are only applied to one option while they are 
equally (in)valid with regard to another option. For example, under ND 
there are remarks about multicast difficulties in wireless 
environments, but the fact that DHCP for IPv6 also uses multicast isn't 
mentioned, while a thorough discussion of the differences would be 
illuminating. I believe this document can be improved with regard to 
bias (there is some bias in same places) and structure, as there is 
arguing for and against approaches in different places rather than in 
an evaluation or conclusions part.

Also, 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. 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. (Although there is no reason why it couldn't be implemented on 
routers, of course.) 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 a management and debugging standpoint as 
well.)

Additionally, 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.

Also, not being very familiar with DNSSEC, I'd be interested to learn 
about the usefulness of DNSSEC for hosts that only support DNS queries 
over IPv6 transport.

Last but not least, 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. I think 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.

Specific comments:

On page 4: "When advertising more than one RDNSS options" this should 
be "option" singular.

Also page 4: "However, it is worth noting that some link layers (e.g., 
WLAN) need to acknowledge multicast packets, which may increase the 
amount of link-layer traffic." I don't believe that in 802.11b link 
layer multicast are acknowledged. However, there is another detrimental 
effect: multicasts are sent at an artificially low speed, taking up a 
lot of bandwidth.

Still on page 4, I find the following statement interesting: "RFC2461 
[3] states, however, that there may be some link type on which ND is 
not possible; on such a link, some other mechanism will be needed for 
DNS configuration." This disqualifies DHCP as well as ND.

On page 5: "4) This mechanism works over a broad range of scenarios and 
leverages IPv6 ND.  This works well on links that support broadcast 
reliably (e.g., Ethernet LANs) but not necessarily on other links 
(e.g., Wireless LANs)." I can tell you from personal experience that ND 
and any other multicast or broadcast based discovery protocol such as 
ARP or multicast DNS work just fine over 802.11b and 802.11g. (Actual 
multicast applications are another story, some limited testing with 
this (a single vendor) failed fairly spectacularly.)

Still page 5: "Because it is unacceptable to write and rewrite the DNS 
configuration file (e.g., resolv.conf) from the kernel, another 
approach is needed." Huh? Why is this unacceptable? Note that Apple 
already does this (well, I can't tell if it's the actual kernel that 
writes the file, but it's certainly something buried deep inside the 
system.) Also note that the actual resolv.conf file is there just for 
backward compatibility: the "real" information is kept elsewhere where 
user land programs can't easily modify it. The same for Windows: DNS 
management is part of the system.

"3.2.3.  Observations

    In the general case, on general-purpose networks, stateless DHCPv6
    provides significant advantages and no significant disadvantages."

This statement is absolutely not supported by the earlier text, as 
there IS an additional delay.

Page 12: "According to either RA or DHCP mechanism, the well-known 
addresses can be obtained by IPv6 host." An article would be 
appropriate here: "by an IPv6 host". But I'm not sure what this 
sentence is supposed to say anyway.

Page 13: "Well-known anycast addresses approach is also a feasible and 
simple mechanism for ISP [9]." Grammar.

Page 14: "IPv6 host can decide which approach is or may be used in its 
subnet with O flag in RA message [8]." More grammar.

(A final note: nearly all lines end in a space. Otherwise empty lines 
contain 4 spaces.)

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

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Oct 2004 21:15:35 +0900

Iljitsch;

> For example, under ND 
> there are remarks about multicast difficulties in wireless environments, 
> but the fact that DHCP for IPv6 also uses multicast isn't mentioned,

As was discussed in mailing lists, DHCP and ARP are better than ND,
because they use multicast only in one way.

It should also be noted that most, if not all, routing protocols
depends on broadcast/multicast, though we are hopless if routes
are not available.
 
> already widely implemented in hosts and deployment is growing.

For these 10 years, IPv6 has been already widely implemented in
hosts and deployment has been growing.

> usable by any IPv6 implementation that supports DNS queries over IPv6 

IANA registration of WK addresses is useful, even if other approaches
are used.

> The second issue is security.

If you want cryptographic security, you must configure your hosts
a lot. So, don't bother to automate so little effort of DNS
configuration.

							Masataka Ohta

PS

Given the discussion on anycast root servers, which just simply
use ARP, which no one call "shared unicast", Pekka's comment is
invalid. IPv6 WG should simply drop their own strange mechanism
which they wrongly call "anycast".

.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Oct 2004 17:43:47 +0200

In your previous mail you wrote:

=> none, i.e., DNSSEC is IP version agnostic. In fact the only possible
impact is positive: both IPv6 RRs and DNSSEC work better with larger
packets (aka EDNS0)...

Regards

[email-masked]

PS: IMHO the quick and dirty solution (i.e., well known addresses) is
the best, at least because its pros and cons are clear! BTW I give
the ::1 IID to my main DNS server (but for other reasons :-).
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Oct 2004 15:02:57 +0200

On 12-okt-04, at 14:15, Masataka Ohta wrote:

>> environments,

> because they use multicast only in one way.

This is true for DHCP but not for ARP: here, a router (that is 
presumably connected by wire to the wifi accesspoint) broadcasts ARP 
requests that hosts must hear. In theory, RAs can work the same way as 
DHCP (client multicasts, server unicasts) but that's not the way it 
works today.

> IANA registration of WK addresses is useful, even if other approaches

I agree 100%.

> a lot. So, don't bother to automate so little effort of DNS

I would rather like to see WKAs, no need for crypto.

> which they wrongly call "anycast".

Link-level anycast vs interdomain anycast maybe?

.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 12 Oct 2004 19:29:02 +0200

> => none, i.e., DNSSEC is IP version agnostic.

I assumed as much. However, the trouble is that most branches of the 
DNS tree are only directly visible to those of us who can do IPv4. Can 
this be a problem when deploying DNSSEC?

> the ::1 IID to my main DNS server (but for other reasons :-).

Ah, but the trouble is that this won't work on an IPv6-only machine...

.

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 12 Oct 2004 22:26:52 +0900

Iljitsch;

> DHCP (client multicasts, server unicasts) but that's not the way it 

With ND, both RA and RS are multicast that your chance of failure
is multiplied.

> Link-level anycast vs interdomain anycast maybe?

Just interlink, not necessarily interdomain.

						Masataka Ohta

.

---

From: Francis Dupont <[email-masked]>
Date: Tue, 12 Oct 2004 23:09:36 +0200

=> this is a DNS issue, DNSSEC cannot change this by itself
(but DNSSEC supporters are not afraid of new things and IMHO
most of them already use IPv6 :-).

   
=> I don't understand? Perhaps you mean this relies on IPv6 enabled
name servers...

Thanks

PS: DNSSEC has two parts: TSIG/SIG(0)/... which protect transactions
(using direct write messages between clients and servers, i.e.,
exceptions) and DNSKEY/RRSIG/... which protect data (which can be
relayed/cached/etc). Only the first part can get special transport
constraints, the second part works as soon as the "general" DNS
works (cf the DNS IPv6 deployment document).
As the first part is not required (i.e., there are other ways to
protect dynamic updates and zone transfers) usually the proper DNSSEC
is only the second part (i.e., when someone talks about DNSSEC deployment
he talks only about the second party: signing data).
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 13 Oct 2004 10:45:15 +0200

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.

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

.