Last Call Review of draft-ietf-dhc-access-network-identifier-08
review-ietf-dhc-access-network-identifier-08-secdir-lc-meadows-2015-07-02-00
Request | Review of | draft-ietf-dhc-access-network-identifier |
---|---|---|
Requested revision | No specific revision (document currently at 13) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2015-06-09 | |
Requested | 2015-05-28 | |
Authors | Shwetha Bhandari , Sri Gundavelli , Mark Grayson , Bernie Volz , Jouni Korhonen | |
I-D last updated | 2015-07-02 | |
Completed reviews |
Genart Last Call review of -08
by Francis Dupont
(diff)
Genart Telechat review of -10 by Francis Dupont (diff) Secdir Last Call review of -08 by Catherine Meadows (diff) Opsdir Last Call review of -08 by Al Morton (diff) |
|
Assignment | Reviewer | Catherine Meadows |
State | Completed | |
Request | Last Call review on draft-ietf-dhc-access-network-identifier by Security Area Directorate Assigned | |
Reviewed revision | 08 (document currently at 13) | |
Result | Has issues | |
Completed | 2015-07-02 |
review-ietf-dhc-access-network-identifier-08-secdir-lc-meadows-2015-07-02-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 draft specifies the format and mechanisms used for encoding network identifiers in DHCPv4 and DHCPv6 by defining new access identifier options and sub-options. The Security Considerations section gives a discussion of the security risks in using DHCP and their mitigation. However, what needs to be go in the Security Considerations Section is a discussion of the security risks raised by *this* document and possible mitigation. The information about DHCP security risks is useful, but not of primary importance. My impression is that this document gives formats for presenting fields whose use is already discussed in previous RFC’s, e.g. RFC3315, in which case there are no new security considerations. If that is so, then the Security Considerations Section should include (preferably begin with) a statement to the effect that, since this document only gives instructions for formatting and encoding fields whose use has already been specified in these previous RFC’s, it presents no additional security considerations beyond what is covered in those RFCs. If that is not the case, you should say what new security risks are introduced by *this* draft, e.g. does it enable a use of DHCP that was not possible before and could cause a new type of security risk if DHCP was used without authentication? Recommendation: Ready With Issues Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows at nrl.navy.mil