[secdir] secdir review of draft-ietf-radext-ip-port-radius-ext-10

Carl Wallace <carl@redhoundsoftware.com> Mon, 15 August 2016 19:56 UTC

User-Agent: Microsoft-MacOutlook/14.5.8.151023
Date: Mon, 15 Aug 2016 15:56:05 -0400
From: Carl Wallace <carl@redhoundsoftware.com>
To: draft-ietf-radext-ip-port-radius-ext.all@ietf.org
Message-ID: <D3D79695.6B471%carl@redhoundsoftware.com>
Thread-Topic: secdir review of draft-ietf-radext-ip-port-radius-ext-10
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/2O4TRuHlUWRRJSPgbCs3qndsMKs>
Cc: iesg@ietf.org, secdir@ietf.org
Subject: [secdir] secdir review of draft-ietf-radext-ip-port-radius-ext-10
Precedence: list

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.

[secdir] secdir review of draft-ietf-radext-ip-po… Carl Wallace
Re: [secdir] secdir review of draft-ietf-radext-i… mohamed.boucadair