Brian: If the client doesn't do anything with that knowledge, there's no reason for the client to follow draft-cha-ipv6-ra-mo-00.txt and there's no threat or danger.
If the client does start DHCPv6 because of receipt of M or O set, then draft-cha-ipv6-ra-mo-00.txt really adds no additional threats because as long as RAs continue to have the bit(s) set, everything is cool. If the RAs stop or the bits are cleared (across all RAs), then draft-cha-ipv6-ra-mo-00.txt would suggest that the client stop DHCPv6 when the lease expires (personally, I don't think clients should terminate the lease immediately). So, again, what issue is there? Sure, it may be that if the RA with the M or O set resumes being sent, the client would restart DHCPv6 but that's no different than if the client was power cycled. Also, the latency here (in the time period for detecting a lack of RAs and letting the lease expire) is such that the frequency of this issue is likely to be very low (once every few hours assuming very short lease times) that it is hard to see it cause problems. Likely the coming and going of the RAs is a much more severe concern as it probably implies loss of connectivity to parts of the network. And, if clients accept unsecured RAs, a rogue device setting and then clearing the M & O bits is the least of the worries (as per the above, the attack can do very little compared to sending other information in the RA). So, let's not create FUD about something that really isn't an issue. - Bernie -----Original Message----- From: Brian Haberman [mailto:[EMAIL PROTECTED] Sent: Monday, October 13, 2008 9:26 AM To: Bernie Volz (volz) Cc: [EMAIL PROTECTED]; Ted Lemon; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ipv6@ietf.org Subject: Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt" Bernie, Bernie Volz (volz) wrote: >> It would seem quite dangerous to enable/disable DHCPv6 clients >> arbitrarily based on bit settings in un-protected RA messages. > > This support already exists with the definition of the M & O bits. > Setting these in an RA means "run DHCPv6". As Joseph pointed out, the I don't interpret the specification that way. If the M and/or O bit are set in the RA, it is an indication that the service *exists*. The spec does not indicate what the client does with that knowledge. M 1-bit "Managed address configuration" flag. When set, it indicates that addresses are available via Dynamic Host Configuration Protocol [DHCPv6]. If the M flag is set, the O flag is redundant and can be ignored because DHCPv6 will return all available configuration information. O 1-bit "Other configuration" flag. When set, it indicates that other configuration information is available via DHCPv6. Examples of such information are DNS-related information or information on other servers within the network. Note: If neither M nor O flags are set, this indicates that no information is available via DHCPv6. > draft defines a mechanism to stop DHCPv6 if *NO* RAs have the M&O bits > set. If you have multiple RAs, some "valid" which say run DHCPv6 and > other RAs which are "rogue" that say don't run DHCPv6, the run ones win. > So, given this, I can't see how this adds any security issues that don't > already exist (ie, to cause DHCPv6 to be run). If DHCPv6 is not > requested by valid RAs, all rogue RAs can do is cause DHCPv6 to be run. > If DHCPv6 is requested by valid RAs, rouge RAs can't stop DHCPv6. > > - Bernie > > -----Original Message----- > From: HYUN WOOK CHA [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 07, 2008 8:41 PM > To: Brian Haberman > Cc: Ted Lemon; [EMAIL PROTECTED]; [EMAIL PROTECTED]; ipv6@ietf.org; Bernie > Volz (volz) > Subject: Re: Re: Request for Advices on the draft > "draft-cha-ipv6-ra-mo-00.txt" > > > Hello, Brian. > > As I presented last IETF 6MAN meeting, our draft aims to provide > automatic revocation of DHCPv6 clients in case that invocation of > clients can be done in accordance with the RFC2462. Thus, requirement of > our security model is that we should not intoduce additional threats to > the existing specification and implementations. Since per-interface > state variables are managed through timer based algorithm proposed in > the draft, illegal RA messages can not stop clients as long as legal RA > messages advertise the availability of DHCPv6 service. Also, we proposed > two options when state variables are invalidated: 1) DHCPv6 client may > refer state variables to decide whether it should keep its operation or > not only after all bindings(leases) expires. 2) DHCPv6 client may be > stopped immediately at the transition of variables from 1 to 0. With the > first option, client can keep its operation even if state variables will > be changed to 0 since legal RA messages are absent within lifetimes by > any reasons. > >> It would seem quite dangerous to enable/disable DHCPv6 clients >> arbitrarily based on bit settings in un-protected RA messages. > > I agree with your point. We do not have any security methods and just > consider using the SEND. > Regards, > Joseph > > ------- Original Message ------- > Sender : Brian Haberman<[EMAIL PROTECTED]> > Date : 2008-10-08 04:20 (GMT+09:00) > Title : Re: Request for Advices on the draft > "draft-cha-ipv6-ra-mo-00.txt" > > Joseph, > Do you have a particular security model in mind for giving Router > Advertisements the power to control software functionality on each node? > > It would seem quite dangerous to enable/disable DHCPv6 clients > arbitrarily based on bit settings in un-protected RA messages. > > Regards, > Brian > > > HYUN WOOK CHA wrote: >> Hello, Ted. >> >> That's correct. I believe that the ability to stop DHCP clients using >> M/O bits in RA is required once they were invoked by M/O bits in RA. >> >> >> Joseph >> >> ------- Original Message ------- Sender : Ted >> Lemon<[EMAIL PROTECTED]> Date : 2008-09-30 09:36 (GMT+09:00) >> Title : Re: Request for Advices on the draft >> "draft-cha-ipv6-ra-mo-00.txt" >> >> Joseph, to summarize, it sounds like you believe that the ability to >> stop DHCP clients broadcasting on a link is a requirement. And you >> therefore think that deprecating the M&O bits is not the right >> answer. Is that correct? >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
