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

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

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

Right. In addition, though the revocation method in the draft, clients invoked by rogue(or misconfigured) RAs will be stopped without users's intervention after problems are fixed. 

Joseph

------- Original Message -------
Sender : Bernie Volz (volz)<[email-masked]> 
Date   : 2008-10-08 11:47 (GMT+09:00)
Title  : RE: Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

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

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

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Brian Haberman <[email-masked]>
Date: Tue, 07 Oct 2008 15:20:30 -0400

Joseph,

Regards,
Brian

---

From: Joseph Hyunwook Cha <[email-masked]>
Date: Thu, 09 Oct 2008 01:20:52 +0000 (GMT)

Hello, James

> If the point is to somehow "save resources" by turning off DHCP when
> not wanted, isn't that really more of a client implementation issue
> than it is a protocol issue?  The existing M/O bits only suggest when
> starting DHCP might be good.  It's up to implementations to determine
> whether to start it, and if so when to quit.

Right. This is closer to my point.
However, by looking the below text, I am not clear that usage of M/O flags is removed because it is not a protocol issue but an implementational one. 

<from RFC4862>     
      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.)
</RFC4862>

<from RFC4861>
      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.
</RFC4861>

What I am wondering is what is the design rationale behind M and O bits. Why should DHCPv6 clients be controlled/instructed/guided by RA messages?
I guess that there might be more than resource saving. DHCPv6 protocol provides address(and prefixes) and additional configuration parameters like DNS servers, etc. However, it does not provide default gateway and prefix length, which may be givne by only RA. IMHO, this design decision shows that stateful address configuration though DHCPv6 should be integrated with RA (an IPv6 core protocol) and controlled/instructed/guided by RA messages as stateless address autoconfiguration is. 

As long as current architecture(or situation) is supported, I still believe that our draft has value to provide a right guidance on the usage of M/O flags to implementors. 

Joseph

------- Original Message -------
Sender : James Carlson<[email-masked]> 
Date   : 2008-10-08 21:06 (GMT+09:00)
Title  : Re: Re: Request for Advices on the draft "draft-cha-ipv6-ra-mo-00.txt"

HYUN WOOK CHA writes:
> 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!
  an

Why is all this new machinery necessary?

If the point is to force all of the DHCPv6 clients with existing
leases to give them up, then the existing Reconfigure message would do
the trick, and would avoid creating new security issues to analyze,
and avoid a new dependence on the weird M/O bits that many of us would
like to see deprecated.

If the point is to somehow "save resources" by turning off DHCP when
not wanted, isn't that really more of a client implementation issue
than it is a protocol issue?  The existing M/O bits only suggest when
starting DHCP might be good.  It's up to implementations to determine
whether to start it, and if so when to quit.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677