Skip to main content

Telechat Review of draft-ietf-csi-dhcpv6-cga-ps-
review-ietf-csi-dhcpv6-cga-ps-secdir-telechat-hanna-2010-10-10-00

Request Review of draft-ietf-csi-dhcpv6-cga-ps
Requested revision No specific revision (document currently at 09)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2010-10-19
Requested 2010-09-25
Authors Sheng Jiang , Sean Shen
I-D last updated 2010-10-10
Completed reviews Genart Last Call review of -?? by Roni Even
Secdir Telechat review of -?? by Steve Hanna
Assignment Reviewer Steve Hanna
State Completed
Request Telechat review on draft-ietf-csi-dhcpv6-cga-ps by Security Area Directorate Assigned
Completed 2010-10-10
review-ietf-csi-dhcpv6-cga-ps-secdir-telechat-hanna-2010-10-10-00
I have reviewed this document as part of the security directorate's  
ongoing effort to review all IETF documents being processed by the  
IESG. These comments were written primarily for the benefit of the  
security area directors. Document editors and WG chairs should treat  
these comments just like any other last call comments.

This document discusses several ways that DHCPv6 can be used with
Cryptographically Generated Addresses (CGA), pointing out benefits
and concerns. While the document does discuss security issues in
several places, it often lapses into vague terminology like "one
should carefully consider the impact on security". Given that the
primary benefit of using CGAs is to improve security by providing
address validation without complex key distribution, carefully
analyzing security issues seems necessary for this document.

On the other hand, the Document Shepherd Write-up for this document
says "The WG was not very energetic on this document. The document
describes possible applications of CGAs and DHCP interaction and
when the WG was asked whether there was enough interest to work on
solutions, the reply was silence. As such, the consensus is based
on most of the WG being indifferent." So maybe this document is
only intended as a sketch of possible issues that can be explored
later in a more in-depth document if someone is interested in
doing so. If that's the case, maybe it's OK to not fully analyze
all the security implications. However, in that case, I think the
Security Considerations section should state clearly that this
document does not contain a complete security analysis and any
further work in this area should include such an analysis. Nobody
should implement the techniques described in this document without
conducting that more thorough analysis.

I noticed a few typos. On page 6, the word "certificated" should be
"certified". Three sentences later, "depend on policies" should be
"depending on policies". And the draft names in the Change Log say
"dhacpv6" instead of "dhcpv6".

Thanks,

Steve