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