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

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

Return-Path: <carl@redhoundsoftware.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF6212D76D for <secdir@ietfa.amsl.com>; Mon, 15 Aug 2016 12:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=redhoundsoftware-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ye679tp_7FvS for <secdir@ietfa.amsl.com>; Mon, 15 Aug 2016 12:56:13 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DB2F12D768 for <secdir@ietf.org>; Mon, 15 Aug 2016 12:56:13 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id w38so25871910qtb.0 for <secdir@ietf.org>; Mon, 15 Aug 2016 12:56:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhoundsoftware-com.20150623.gappssmtp.com; s=20150623; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :mime-version:content-transfer-encoding; bh=dJMhGiBB0rr3mnd78VeaRF++unrNucAp9WA1as42Tec=; b=sqm/cXeAu8NMX9Q55Vpu0MB97zSSA50kWlA9e2OqVTNfXQgMs4a1inF1GnMdnJ3RXO Nin8rHFnyEGsV3DqALDNcj+qpxuu+coSdRVszHkvBgY/hPr9ZrDEIUF56rVHlvQbABHk TVRBz4HYWD2GSasKmSjvKlDO+sf26eV9Qn8AchRIzJ5vbiQTLgihVxDJVdEoK/JbpZ67 zTEgw6J7howheiNqhEbJEChm8Zrf0lhFOwBuz3C3HUCJkryaU1qxh7+dhEGriyVpaj5V NfBBprpzNND7iLAXqt/+U9hSPYHT0QShWbcvRi3Og7NWqhgoJcgFEmotsQfU11Zt03py nGlA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:mime-version:content-transfer-encoding; bh=dJMhGiBB0rr3mnd78VeaRF++unrNucAp9WA1as42Tec=; b=h2J1Sd7mtCDZDFPqwnBP/riiAPeMloJvXfqUmyfClRq7Iuk60RZTUba61KyfBzznCL RrSTGXE4d8D7O8hsKzS7eY5aMuQswFOKKMdkohLF7IoCmM6w8lcpqbrPBsLm1C/0LaX9 Xzw7gS1Nm3qVaMB0cqd/GuudYYqZhCT2QXAM6MoyM4UG0gvKEUXyORFzF7KdGDbQqjxk HKT6+alGRijtg7gTzwzZ3SQOzkJI9RwDIyPWpIboCnRNhl+WeP801AuNzIjF8M39IrUP AtnthQPdQ4sdMd9h0TpYg2eHnP8MlbRJN9EsIcgt8RHUKKz4Y7dXXwISkpbjaQ7yq8tr Ia+Q==
X-Gm-Message-State: AEkooutAX+cDoMaqf6/3HFGpE7/HJuiMNBwi+MP84nPsjn8QbPZF3uDkYyVLwbkLnJWn2w==
X-Received: by 10.200.46.25 with SMTP id r25mr34336892qta.114.1471290972081; Mon, 15 Aug 2016 12:56:12 -0700 (PDT)
Received: from [192.168.2.29] (pool-96-255-23-4.washdc.fios.verizon.net. [96.255.23.4]) by smtp.gmail.com with ESMTPSA id p2sm13249253qta.15.2016.08.15.12.56.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 15 Aug 2016 12:56:11 -0700 (PDT)
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
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2016 19:56:14 -0000

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.