Last Call Review of draft-ietf-radext-ip-port-radius-ext-09
review-ietf-radext-ip-port-radius-ext-09-secdir-lc-wallace-2016-08-19-00

Request Review of draft-ietf-radext-ip-port-radius-ext
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-08-16
Requested 2016-08-04
Draft last updated 2016-08-19
Completed reviews Genart Last Call review of -09 by Ron Bonica (diff)
Genart Telechat review of -11 by Ron Bonica (diff)
Secdir Last Call review of -09 by Carl Wallace (diff)
Opsdir Last Call review of -09 by Tim Chown (diff)
Assignment Reviewer Carl Wallace
State Completed
Review review-ietf-radext-ip-port-radius-ext-09-secdir-lc-wallace-2016-08-19
Reviewed rev. 09 (document currently at 17)
Review result Has Issues
Review completed: 2016-08-19

Review
review-ietf-radext-ip-port-radius-ext-09-secdir-lc-wallace-2016-08-19

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 defines three new RADIUS attributes.  For devices that
implement IP port ranges, these attributes are used to communicate with a
RADIUS server in order to configure and report TCP/UDP ports and ICMP
identifiers, as well as mapping behavior for specific hosts.


I've a few questions/comments:

- The Security Considerations section currently references the security
considerations from 2865 and 5176.  Should 6887 be included to address
considerations related to the forwarding attribute?
- When the port limit attribute is used, does presentation of a new
"global" setting undo previously established IP specific settings (or vice
versa)? 
- Should the IP-Port-Range attribute require at least one of
IP-Port-Ext-IPv4-Addr or IP-Port-Local-Id to be present? How is the
attribute used when both are absent?
- The summary statement associated with the attributes in section 1 might
benefit from indicating the purpose of the attribute relative to each
packet type in which it may appear (for example, the purpose of a port
limit info attribute is different when included in an Access-Request than
in an Access-Response).
- Each attribute lists applicable packet types and indicates the attribute
must not appear in any other packet type. It may be worth adding a note to
clarify what should happen if the attribute does appear (assuming ignore).
- The UE acronym on page 30 should be expanded.
- In 3.1.2, change "are previously allocated" to "were previously
allocated".
- In 4.1.3, is "RADIUS associate" a commonly used term? This seems like a
requirement on use with CoA-Requests that should be mentioned earlier.