Alain: And, if hosts just run DHCPv6 anyway, it makes the job of the rogue server user even easier - since it need not even bother to generate RAs. So, security is no better or worse. It may even be slightly better if they need to generate the RAs since a) it is more work (especially if SEND is used) and b) there's a chance that this fact can be discovered if a network is monitoring RAs to make sure only "legal" ones are generated.
>Why is is not good for IPv6? Why have hosts needless generate periodic DHCP traffic when there is no DHCP server present? True that in DHCPv6 the impact is much more minor as multicasting is used (in DHCPv4 all hosts on the network receive the packets because they are broadcast), but it still seems better to me to avoid unnecessary traffic. You can certainly have hosts that always run DHCPv6, or at least policy settings that would allow it on a host. - Bernie > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Soliman Hesham > Sent: Monday, April 26, 2004 9:55 PM > To: Alain Durand; IETF IPv6 Mailing List; JINMEI Tatuya / ???? > Subject: RE: [rfc2462bis] whether we need the M/O flags > > > Alain > > Your point about security is valid but is relevant to > securing RAs in general, and is not specific to the M/O bits. > If you want to be sure they're > secure just use SEND. > > Hesham > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Alain Durand > > Sent: Monday, April 26, 2004 1:14 PM > > To: IETF IPv6 Mailing List; JINMEI Tatuya / ???? > > Subject: Re: [rfc2462bis] whether we need the M/O flags > > > > > > 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. > > > > The are security implication for the hosts in implementing > > those bits. > > They are received in RA, which are mostly insecure (anyone > > can send a > > "valid" RA) > > The current text says a host should turn stateful autoconf when > > receiving those bits. > > 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. > > > > 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? To give a hint that DHCPv6 is present? > > Host should not blindly believe this unless the RA are > secured. > 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? > > > > - Alain. > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > [EMAIL PROTECTED] > > Administrative Requests: > https://www1.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > ======================================================== > This email may contain confidential and privileged material > for the sole use of the intended recipient. Any review or > distribution by others is > strictly prohibited. If you are not the intended recipient > please contact the sender and delete all copies. > ======================================================== > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > [EMAIL PROTECTED] > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
