On 26-apr-04, at 19:14, Alain Durand wrote:
Let me try to explain why I, as an implementor, do not like the M/O bits very much.
It is not that DHCPv6 cannot be made secure, it is that the M/O bits are
an automatic and insecure way to trigger an external configuration mechanism.
So you object to the security level of DHCPv6 rather than that of the M and O bits?
You should read what I just said above before commenting too quickly. I have nothing against DHCPv6, but against insecure commands that trigger a configuration mechanism, any configuration mechanisms.
So one could mount an attack fairly easily by introducing a rogue DHCPv6
server on a network that had no DHCPv6 so far and send a fake RA with
the M/O bits on. The host will then configure itself using data coming
from the new rogue DHCPv6 server.
So what is the alternative? If there are no M and O bits, people implementing DHCPv6 will have to perform DHCP *always* so there is no protection against a rogue DHCPv6 server over the situation you describe.
Again you commented without reading what I wrote. People who run DHCPv4 on the client side decide to do so, it is not that DHCPv4 client is triggered by a remote mechanism.
I never said that if you implement DHCPv6 you MUST always turn it on.
This is a decision that has to be made by the person configuring the host.
If you want people to enable DHCPv6 manually: ok, no problem. But why would the M and O bits be in the way in that case? Just ignore them.
Because the specs says I should (lower case) obey M & O. Read what I wrote.
2462 says "host should invoke the stateful address autoconfiguration protocol"
and not "MUST invoke", so there are already provision for not obeying
the M/O bits. But if those bits are not mandatory to execute, why are they here in the first place?
Maybe because the IETF has no business to tell people in which way they should run their network, but only to provide them guidance on how a certain task can be performed in an interoperable way IF and WHEN the operator decides they want this task to be performed in the first place.
This is a general statement that nobody can disagree with but has no relevance to the discussion.
Sorry.
To give a hint that DHCPv6 is present?
Don't you consider this useful?
Ah, this is a very good question, actually, at the core of the discussion.
Thank you for asking it.
I'm not sure this is useful. You seem to think it is. Please tell me which problem it solves.
Host should not blindly believe this unless the RA are secured.
So what kind of bad stuff is going to happen when hosts start querying a rogue DHCPv6 server? I think the main problem is that traffic can be redirected through a rogue router which then has the opportunity to perform man in the middle attacks. However, the rogue system can just as easily perform the same thing using just RAs.
Not only that. A host might have been previously configured with the address of a DNS server. There is a risk
that the O bit will trigger a query to find out the DNS server, and a corrupt entry will either override or complement
the correct one. This way the attacker could redirect part or all of my web traffic wherever he wants without having
to mess with the routers. Of course DNSsec will help, but it is not there yet.
Also, there are no such bits in IPv4, and host implementations that chose to turn DHCPv4 on simply try it. Why is is not good for IPv6?
The difference is that in IPv4 you have the choice between manual configuration and DHCP, so absense of the former implies that the latter must be used. There is no such dichotomy in IPv6: absense of manual address configuration doesn't mean DHCPv6 should be used. IPv6 hosts have enjoyed the benefits of stateless address configuration for years and it's very likely that huge numbers of people running IPv6 networks will never want to run DHCPv6. So requiring hosts to always try DHCPv6 doesn't make any sense.
You obviously did not talk to the same IT folks in large enterprises I do.
Many do not like stateless autoconf much and would like to run DHCPv6 for address allocation.
There are a number of very good reasons for that, especially for servers.
And again, "requiring hosts to always try DHCPv6" is not what I want.
I'm saying, if a host wants to try DHCPv6 for its configuration, that is fine, but this
is a configuration decision, and there are many situations where it is not wise
to have DHCPv6 triggered automatically by insecure messages on the network.
- Alain,
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
