Subject: Re: [dhcwg] Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

From: HYUN WOOK CHA <[email-masked]>
Date: Wed, 08 Oct 2008 00:41:19 +0000 (GMT)

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-masked]> 
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-masked]> 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 [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 7 Oct 2008 22:47:17 -0400

> 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
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-masked]] 
Sent: Tuesday, October 07, 2008 8:41 PM
To: Brian Haberman
Cc: Ted Lemon; [email-masked]; [email-masked]; [email-masked]; 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. 

> 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 -------

Joseph,

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Mon, 13 Oct 2008 09:26:16 -0400

Bernie,

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

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 13 Oct 2008 09:47:44 -0400

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-masked]] 
Sent: Monday, October 13, 2008 9:26 AM
To: Bernie Volz (volz)
Cc: [email-masked]; Ted Lemon; [email-masked];
[email-masked]; [email-masked]
Subject: Re: Request for Advices on the draft
"draft-cha-ipv6-ra-mo-00.txt"

Bernie,

       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.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 13 Oct 2008 09:48:37 -0400

Brian - I think this thread reasonably supports the conclusion that  
the text in the RFCs does not clearly capture the consensus reached of  
the IETF.  In my opinion, some sort of additional information is  
needed because I've gotten questions on exactly this issue.  I think  
the problem can be resolved with a couple of sentences (as I wrote  
earlier); e.g.:

* Add a new Note after the description of the M/O flags in Section 4.2  
of RFC 4861:

  Note: The DHCPv6 client behavior in response to the receipt of M and  
O flags is unspecified.

* Add a sentence to the clarification in RFC 4862:

  o Removed the text regarding the M and O flags, considering the  
maturity of implementations
    and operational experiences. ManagedFlag and OtherConfigFlag were  
removed accordingly. (Note
    that this change does not mean the use of these flags is  
deprecated.)  *The DHCPv6 client
    behavior in response to the receipt of M and O flags is  
unspecified.*

* Change the following sentence from Section 3 of RFC 4861:

  For example, routers can specify whether hosts should use DHCPv6 and/ 
or autonomous (stateless)
  address configuration.

  to:

  For example, routers can specify whether DHCPv6 services are  
available for address configuration and other
  configuration information.

Now, it's not clear that simply clarifying the earlier consensus is  
sufficient, because leaving the DHCPv6 client behavior in response to  
the M/O flags unspecified may not provide enough information for  
implementors.  But, I think additional clarification to implementors  
is a separate discussion...

- Ralph

On Oct 13, 2008, at Oct 13, 2008,9:26 AM, Brian Haberman wrote:

> 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.
>
>
>> From: HYUN WOOK CHA [mailto:[email-masked]] Sent:  
>> Tuesday, October 07, 2008 8:41 PM
>> To: Brian Haberman
>> consider using the SEND. Regards, Joseph
>> Sender : Brian Haberman<[email-masked]> Date   :  
>> 2008-10-08 04:20 (GMT+09:00)
>>      Do you have a particular security model in mind for giving  
>> Router Advertisements the power to control software functionality  
>> on each node?
>>> -------------------------------------------------------------------- IETF 
>>>  IPv6 working group mailing list [email-masked] Administrative