[radext] Review of draft-cheng-behave-cgn-cfg-radius-ext

Alan DeKok <aland@deployingradius.com> Tue, 04 March 2014 09:50 UTC

Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 8DACA1A03E8 for <radext@ietfa.amsl.com>; Tue, 4 Mar 2014 01:50:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bs36w3Xgstt1 for <radext@ietfa.amsl.com>; Tue, 4 Mar 2014 01:50:29 -0800 (PST)
Received: from power.freeradius.org (power.freeradius.org []) by ietfa.amsl.com (Postfix) with ESMTP id 935B51A0175 for <radext@ietf.org>; Tue, 4 Mar 2014 01:50:29 -0800 (PST)
Received: from localhost (localhost []) by power.freeradius.org (Postfix) with ESMTP id C1F2922400AD for <radext@ietf.org>; Tue, 4 Mar 2014 10:50:25 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([]) by localhost (power.freeradius.org []) (amavisd-new, port 10024) with ESMTP id 7h0qV7Qu85C3 for <radext@ietf.org>; Tue, 4 Mar 2014 10:50:25 +0100 (CET)
Received: from dhcp-b41d.meeting.ietf.org (dhcp-b41d.meeting.ietf.org []) by power.freeradius.org (Postfix) with ESMTPSA id 62D4622400A9 for <radext@ietf.org>; Tue, 4 Mar 2014 10:50:25 +0100 (CET)
Message-ID: <5315A1E1.2040405@deployingradius.com>
Date: Tue, 04 Mar 2014 09:50:25 +0000
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/FC1RpemdyCpWSgk9TDucwST3ICo
Subject: [radext] Review of draft-cheng-behave-cgn-cfg-radius-ext
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 09:50:33 -0000

  This is a quick review of the document prior to RADEXT WG meeting.

   This document proposes three new RADIUS attributes as RADIUS
   protocol's extensions, and they are used for separate purposes as

  Any draft is a RADIUS protocol extension.  I'd suggest changing this
text to:

   This document proposes three new attributes as follows:

  The following paragraphs could be re-organized.  They currently give a
description first, followed by the attribute name.  The text also seems

   The session limit is carried by a new RADIUS attribute ...

  Yes, most drafts define a new attribute.  I would just say:

  o Port-Session-Limit

    Sent in Access-Accept or CoA-Request.  Limits the of total number of
    TCP/UDP ports and/or ICMP identifiers which a subscriber can use.

  i.e. give the name, which packets it can occur in, and a short
description of its meaning.  The later sections will expand on these
descriptions, so there's no need to give complicated definitions here.

     o  Session Limit - This is the maximum number of TCP ports, or UDP

  Is this the same as "Port-Session-Limit" above?  If so, I suggest
using the same name.

  Also, all authorization attributes in RADIUS are for a particular
session.  So there's no need to call them "Session" limits.  By
definition, they're for one session, and only one session.

      [Discussion: should these attributes be allocated from the
      extended RADIUS attribute code space?]

  I don't think it matters.  They could be allocated from the standard

3.1 Port-Session-Limit

   This attribute is of type complex [RFC6158] ...

  There is no reason to make these attributes type "complex".  Everyone
would be better served by using TLVs, as defined in RFC 6929.

3.2 Port-Session-Range

   The port range follows the encoding specified in [RFC6431];

  RFC 6431 defines a data structure of 4 fields.  This attribute re-uses
that, but inserts it in the middle of other complex fields.  So it does
not appear to follow the requirements to be an "opaque data type" as
given in RFC 6158 Section A.1.3.

3.3.  Port-Forwarding-Map Attribute

   ... In addition, the attribute may contain a
   32-bit IPv4 address or a 128-bit IPv6 address, respectively, as their
   respective NAT mappings internal IP address.

  This definition violates RFC 6158 Section 3.4, which prohibits
polymorphic attributes.

7.2.  Name Spaces

   This document establishes a new name space for Session Type (see
   Section 3.1 for the initial reservation of values.  The allocation of
   future values is according to RFC Required policy [RFC5226]

  I don't think any previous RADIUS specification defined an IANA name
space for sub-fields of an attribute.  All of the existing enumerated
types are of data type "integer".

  Over all, the goal of the document seems reasonable.  But the encoding
of the attributes violates most of RFC 6158, without giving any reason
as to why.  Implementing it as-is would impose undue burden on implementors.

  I suggest using TLVs instead of these complex data types.  That would
avoid the need for polymorphic attributes, too.

  Alan DeKok.