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

Dean cheng <dean.cheng@huawei.com> Fri, 07 March 2014 01:29 UTC

Return-Path: <dean.cheng@huawei.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF401A0186 for <radext@ietfa.amsl.com>; Thu, 6 Mar 2014 17:29:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level:
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 NAb3sy0rItZO for <radext@ietfa.amsl.com>; Thu, 6 Mar 2014 17:29:49 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 27C1D1A0010 for <radext@ietf.org>; Thu, 6 Mar 2014 17:29:49 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEH86482; Fri, 07 Mar 2014 01:29:44 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Mar 2014 01:29:06 +0000
Received: from SJCEML702-CHM.china.huawei.com (10.212.94.48) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 7 Mar 2014 01:29:41 +0000
Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.52]) by SJCEML702-CHM.china.huawei.com ([169.254.4.61]) with mapi id 14.03.0158.001; Thu, 6 Mar 2014 17:29:35 -0800
From: Dean cheng <dean.cheng@huawei.com>
To: Alan DeKok <aland@deployingradius.com>, "radext@ietf.org" <radext@ietf.org>
Thread-Topic: [radext] Review of draft-cheng-behave-cgn-cfg-radius-ext
Thread-Index: AQHPN4898xpGI46XLUWhu3b9ziIo/ZrUthDg
Date: Fri, 07 Mar 2014 01:29:34 +0000
Message-ID: <DC7880973D477648AC15A3BA66253F6865F81B59@SJCEML701-CHM.china.huawei.com>
References: <5315A1E1.2040405@deployingradius.com>
In-Reply-To: <5315A1E1.2040405@deployingradius.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.143]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/QxlP45gS6U6ew7xjquqQTCG5Dq8
Subject: Re: [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: Fri, 07 Mar 2014 01:29:52 -0000

Alan,

Thanks for these useful suggestions and we'll incorporate
them in the next revision.

Dean

> -----Original Message-----
> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok
> Sent: Tuesday, March 04, 2014 1:50 AM
> To: radext@ietf.org
> Subject: [radext] Review of draft-cheng-behave-cgn-cfg-radius-ext
> 
>   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
>    follows:
> 
>   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
> redundant:
> 
>    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
> space.
> 
> 
> 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.
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext