Analysis of Possible DHCPv6 and CGA Interactions

Summary: Needs a YES.

(Jari Arkko) Discuss

Discuss (2010-10-20 for -)
This is a good document, even if the actual message is quite short
and simple, and at times the draft struggles a bit to explain its
conclusions clearly. FWIW, I disagree with some of the discusses that
I have seen. I do have a few concerns (one shared with Russ), however:

Section 3 claims without good justification that CGA parameters should
be managed by a central entity. I think a reasonable case can be made
for some parameters (like algorithms, Sec) but maybe not all. I can
see also good reasons why central administration would be a bad idea
(e.g., prefix is a local network matter and comes from the RAs). In any
case, the document is silent about all this.

Section 3 also suggests that with Sec>0 the generation of the hashes
is something that should be centralized. Again, I can see also some
reasons not to. In particular, Sec was not designed as a way to burden
current machines but to enable higher cost searches when machines get
faster. That is, if generating a Sec>0 value is a big burden for our
computers, we should probably still use Sec=0. (I think there is a better
argument than the one used in the draft. A very low-power host might
want to delegate its key and hash generation to a more general purpose

Section 4 should expand on what the implications for using CGAs by
DHCPv6 servers. I believe that might actually be useful, as you could
tie different transactions with the same DHCPv6 server together, ensuring
that it is still the same node. But you could not prevent someone
claiming to be a DHCPv6 server.

I agree with other ADs that the draft should handwave less when it
describes the security implications of some new design. The idea of
the draft should be to describe what CGA can bring to DHCP security,
and the security implications cannot be skipped. One example where
you could easily write some more specific analysis is the above issue
on using unauthorized CGAs by DHCPv6 servers and what the security
impacts of that are.

(Ron Bonica) (was No Record, Abstain) Discuss

Discuss (2010-10-21 for -)
Support DISCUSS positions from security ADs

(Stephen Farrell) Discuss

Discuss (2012-04-17)
So since the authors clarified in -09 that this is not a problem statement 
(seems late in the day but whatever) I re-read the document and re-wrote
my discuss points. However, the overall thrust of the discuss remains: I
don't see that this document is useful or needed.

But to the details:

#0 I agree with other discussing ADs.

#1 CGA's have privacy benefits, and the idea of "registering" those with a dhcp
server would entirely remove that feature.  I fail to see why a client would
*ever* want to register its CGA, and the document makes only one incidental
mention of privacy. That seems entirely insufficient to me. This echoes Russ'
discuss with which I fully agree. You could resolve this discuss point by for
example stating that, for privacy preserving reasons, there is no known
use-case where it would make sense for a DHCP client to use a CGA. Additional
changes would flow from that I would expect, if you were happy to take that
approach. (But then that leaves *very* little text.)

#2 Related to #1, but I don't get this bit:

  "However, after CGA has been defined, as an independent security
   property, many other CGA usages have been proposed and defined, such
   as SHIM6 [RFC5533], Enhanced Route Optimization for Mobile IPv6
   [RFC4866], etc. In these scenarios, CGAs may be used in DHCPv6-
   managed networks."

*Exactly* what use-cases exist for this involving a DHCP client?  You need to
explain, if you don't accept the approach suggested in #1.

#3 I agree that it might, in principle, be interesting to use CGAs for DHCP
servers or relays. However, I fail to see why section 4 (with DHCP client text
removed) justifies this document and only section 4 (<1 page) seems to 
remain, if you accept #1. There are sometimes reasons why an RFC might
be worthwhile with only one page of real content but this is not one of
those cases IMO. You can just include that page in the relevant DHC WG 
I'm sorry, but I just don't think this is a useful document to produce.
Comment (2012-04-17)
No email
send info
- intro: what does "management to hosts" mean

(Russ Housley) Discuss

Discuss (2010-10-03 for -)
  The direction suggested by this document will undermine the privacy
  features associated with host-generated CGAs.  In general, CGAs are
  not used in the same environment as a DHCP server, and I do not see
  a justification for this to change.

  Without providing a reason, this document asserts that local a
  administrator ought to manage CGA generation parameters.  I am
  guessing that the concern is the computation burden, but this is not
  compelling.  Further, RFC 3315 already allows a DHCPv6 server to
  reject a CGA generated with unacceptable parameters.

  This document discusses the use of DHCPv6 to assign certificates to
  CGA address owners.  CGA 'ownership' can already be validated with
  the private key, so the need for a certificate is unclear.

  This document states: "... the generation of the Modifier field of a
  CGA address is computationally intensive."  RFC 3972 seems indicate
  otherwise for most key sizes.  In general, RSA key pair generation is
  not a big concern on modern processors.  It might be a mild concern
  on mobile devices, but some detailed explanation is required.

(Tim Polk) Discuss

Discuss (2010-10-20 for -)
I am submitting these issues as a discuss position, but please note that I expect to move from Discuss to Abstain
since I have significant issues with the overall direction.  My issues include one "discuss-discuss" and a number
of specific issues.

The document implies that centrally managed CGAs were envisioned in the original specs ("The current CGA
specifications do not mandate which device generates a CGA address.")  However, I see no evidence in RFC 3972
that centrally generated CGAs were envisioned.  My reading assumes locally generated CGAs.  Is there any
evidence that the wg really thought CGAs would be generated centrally?

Specific Issues:

In my opinion, this document fails to establish that a problem exists. The current DHCPv6-CGA coexistence model
is dismissed without a clear explanation, and the impact of centrally generated key pairs and modifiers on the
security assumptions for protocols that employ CGAs is not explored at all. [sections 1 and 2]

I believe that sections 3 and 4 should be addressed in separate documents, unless the authors believe that DHCPv6
only benefits from centrally managed CGAs.  Putting both concepts in one document is confusing. [global]

Increasing the security of a CGA against a brute force attack while weakening the base security assumptions
may not be a good compromise.  [section 3, glaringly absent from section 5]

The rationale for centrally generated key pairs is very weak, since a node (e.g. a cell phone) can reuse the same
key pair each time it joins a subnet and generates a new CGA.  [section 3]

It is unclear whether the concepts proposed in Section 4 ("What CGA can do for DHCPv6") rely on centrally 
managed CGAs or not.  From what I can tell, traditional CGAs might be very useful for DHCPv6 deployments,
but I am unsure about that.

The document states that when DHCPv6 is used to manage CGAs "it does not increase privacy risks".  Relative
to what?  IMHO, centrally generated CGAs have to increase privacy risks in comparison to CGAs generated by the
host itself. [section 5]

As stated in the security consideration, "This work does not include a complete security analysis".  In my opinion, 
such an analysis is crucial to determining whether this "problem" should be solved. As alluded to above, that
analysis needs to review the impact on current protocols that use CGAs.  If those protocols assume local
generation, what is the impact of the mechanisms described here? [section 5]
Comment (2010-10-20 for -)
No email
send info
What is an "unauthorized public & private key pair"?  What is a "certified public & private key pair"? [section 4]

(Sean Turner) (was Abstain) Discuss

Discuss (2011-12-01 for -)
This is an updated position based on -07.

1) I share the concerns raised by others.

2) s1:  Using CGA to protect DHCPv6 is 
   recommended though the concrete protocol is not defined in this 

In s2 it say: also using the CGA for DHCPv6 security purpose, analyzed 
   in section 4 this document, etc.

I didn't think this document was providing recommendations on analyzing possible solutions.  Maybe just delete this sentence?

3) s4: I'll have to think some more about this one:

  The usage of CGAs can also avoid DHCPv6's dependence on 
  IPsec [RFC3315] in relay scenarios.

How do CGAs provide replay protection?

4) s4: contains the following about pre-configured a CGA-enabled DHCPv6 server:

 But in this case the 
 address will be fixed. It may increase the vulnerability to, e.g., 
 brute force attacks.

Brute force attacks against?

5) I think this is a typo but I want to be sure:

 However, DHCPv6 servers are suitable to serve such computational 
 delegation requests from thousands clients. 

Shouldn't this be "not suitable"

6) s7 contains the following:

   Without other pre-configured security mechanism, like pre-notified 
   DHCPv6 server address, using host-based CGA by DHCPv6 servers could 
   not prevent attacks claiming to be a DHCPv6 server. 

I think you're talking about spoofing here.  Is this really true?  What happens when they use IPsec?

7) s7: One thing I think you also need to talk about is when the DHCPv6 server says no to the address based on a Sec value and then the DHCPv6 server says use a value one that is weaker.
Comment (2011-12-01 for -)
No email
send info
#1) abstract and s1: Having trouble parsing the following:


 This document analyzes the possible interactions between DHCPv6 and 
 Cryptographically Generated Addresses (CGAs), and gives 
 recommendations and reasons whether these possibilities should be 
 developed as solutions or be declined in the future.


 This document analyzes the possible interactions between DHCPv6 and 
 Cryptographically Generated Addresses (CGAs), and gives 
 recommendations on whether or not these interactions should be 
 developed as solutions.

#2) s1:


 Then, configuring CGA-relevant parameters using DHCPv6 is 
 also discussed per parameters


 Then, configuring CGA-relevant parameters using DHCPv6 is 

#3) s2: The use of "should" here is throwing me off.  I think what you want to say is that for DHCP managed networks hosts get their addressed form DHCPv6 servers.


 However, in a DHCPv6-managed network, hosts should get their 
 addresses from DHCPv6 servers. This may result that a DHCPv6-managed 
 network declines the network access requests from CGA owners. 


 However, hosts in DHCPv6-managed network get their 
 addresses from DHCPv6 servers. For a DHCPv6-managed 
 network, CGA owners could be declined network access.

#4) s2:


 There is no existing operation to 
 allow DHCPv6 servers to decline the requested CGA and reply 
 suggestion in order to generate a new address accordingly. 

 New DHCPv6 options may be defined to support DHCPv6 servers to 
 decline the requested CGA, notify the hosts the reason and give 
 suggestion information in order to generate a new CGA accordingly. 


 There is no existing operation to 
 allow DHCPv6 servers to decline the host-requested address
 and to reply with information to generate a a new address. 
 New DHCPv6 options could be defined to allow DHCPv6 servers to 
 decline requested-CGAs, to inform the host about why the address
 has been declined, and to give 
 information needed to construct an acceptable CGA. 

#5) s2:


 Specifically, a node can request that a DHCPv6 server grants the use 
 of a self-generated CGA by sending a DHCPv6 Request message.


 Specifically, a node could request that a DHCPv6 server grant the use 
 of a self-generated CGA by sending a DHCPv6 Request message.

#6) s3: r/it is not possible that network/it is not possible for network

and I think you could leave this bit off:

 Hosts may generate such CGA in order to get access or use
 network services.

You already made that point earlier.

r/Central managed/generated key/Centrally managed/generated keys

Again, maybe I'm over-reacting but this draft doesn't provide requirements:

r/Therefore, there are no requirements for network to 
      configure/suggest it./
 Therefore, a mechanism to configure/suggest a value is
 not analyzed. 

Actually do this one 3 times (public key/modifier/collision count).

#7) s4:

 CGA option with an address ownership proof mechanism and a signature 
 option with a corresponding verification mechanism may be introduced 
 into DHCPv6 protocol. With these two new options, the receiver


 CGA option with an address ownership proof mechanism and a signature 
 option with a corresponding verification mechanism would allow the receiver

#8) s4:


 Then, hosts may decline the DHCPv6 messages 
 from other servers, which may be fake servers.


 Then, hosts can decline the DHCPv6 messages 
 from other servers.

They might be fake they might be real it's just not needed.

#9) s5:

r/computationally powerful to take such heavy burden, too.
/computationally powerful enough to also generate CGAs
for all of its hosts.

#10) s6:


  A few interactions has been declined by the analysis, including


  The analysis has determined that a few interactions
  are not worth pursuing including:


   This document suggests a few possible interactions may be defined in 
   the future: 

   - allowing DHCPv6 servers to decline the requested CGA and reply 
      suggestion in order to generate a new CGA accordingly, 

   - using DHCPv6 to propagate prefix to hosts, 

  - propagate the suggested Sec value to hosts, 

  - DHCPv6 servers, relays or clients use CGA addresses as source 
    addresses, also in DHCPv6 message exchanging. 

NEW (lets have just one bullet for declining and replying and be specific about what can be replied, making it parallel too):

   This document suggests a few possible interactions be investigated:

   - allowing DHCPv6 servers to decline requested-CGAs and reply 
     with Prefix or Sec values to generate an
     appropriate CGAs, 

  - using CGA addresses for interactions between DHCPv6
    servers/relays and clients

#11) s7:


   By allowing DHCPv6 servers to decline the requested CGA and reply 
   suggestion in order to generate a new CGA accordingly, is actually 
   increase the network access flexibility. This may also benefit the 
   network security too. 


   Allowing DHCPv6 servers to decline the requested-CGA and reply 
   with information to generate an appropriate CGA might actually 
   increase network access flexibility. This might also benefit the 
   network security too. 

OLD (there's no mechanism yet and I don't think you're making recommendation hence may/can switch):

   Prefix is information that should be advertised. However, the new 
   mechanism using DHCPv6 to propagate prefix to hosts gives attackers 
   another way to propagate bogus prefixes, which may waste hosts 


   Prefix is information that can be advertised. However, if
   DHCPv6 propagates the prefix to hosts, then attackers have
   another way to propagate bogus prefixes.  This can waste hosts' 


   The suggested Sec value is only replied to the host when requested 
   CGA is declined by the DHCPv6 server. For security reasons, networks 
   should NOT enforce any CGA parameters. Otherwise, malicious attackers 
   may use this enforcement to attack hosts. Networks may suggest 
   certain CGA parameters, but host does not have to follow. However, if 
   the hosts not follow, they may not be able to access part or full 
   network services. 

NEW (not sure I got this all right):

   When propagating the Sec value from the DHCPv6 server to host, it is
   only returned if the DHCPv6 declines the requested-CGA. For security
   reasons, networks SHOULD NOT enforce any CGA parameters.
   Enforcing CGA parameters could allow malicious attackers to attack
   hosts by forcing them to perform computationally intensive operations.
   Networks can suggest the Sec value, but hosts need not heed the
   suggestion. However, if the hosts do not follow the suggestion, then
   DHCPv6 servers might deny network services. 

(Ralph Droms) Yes

(Gonzalo Camarillo) No Objection

(Wesley Eddy) No Objection

(David Harrington) (was Discuss) No Objection

Comment (2012-03-28)
No email
send info
Updated for revision -09-

This  comment is about the inadequacies of security considerations. I think more would would be needed to assess whether the proposals contained in the document are viable in an Internet environment. To a large degree, these comments mirror those from other ADs, so I will simplify my discuss to save I support the discusses raised by Tim and Russ and Stephen and Sean.

(Pete Resnick) No Objection

Comment (2011-12-01 for -)
No email
send info
I reluctantly ballot "No objection" to this document, but given the other DISCUSSes, I think it's not an issue. Essentially, I agree with Stephen's first DISCUSS: I don't know why the publication of this document is necessary. In particular, I note that the writeup says:

   The document is an informational problem statement. The WG
   expressed no interest in working in the solutions to the problem

If the WG has no interest in addressing the issues here (indeed, there isn't a WG working on this problem anymore), and there are a list of questions not sufficiently addressed by this draft, it should probably be shelved until there is such a group. But it is only informational, so I won't object if it ends up going forward.

(Peter Saint-Andre) No Objection

Comment (2011-11-30 for -)
No email
send info
I concur with the DISCUSS position lodged by Jari Arkko, and share some of the concerns expressed by other IESG members.

Deborah Brungard No Record

Alissa Cooper No Record

Roman Danyliw No Record

Martin Duke No Record

Benjamin Kaduk No Record

Erik Kline No Record

Murray Kucherawy No Record

Warren Kumari No Record

Barry Leiba No Record

Alvaro Retana No Record

Martin Vigoureux No Record

Éric Vyncke No Record

Magnus Westerlund No Record

Robert Wilton No Record