Skip to main content

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