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
- [radext] Review of draft-cheng-behave-cgn-cfg-rad… Alan DeKok
- Re: [radext] Review of draft-cheng-behave-cgn-cfg… lionel.morand
- Re: [radext] Review of draft-cheng-behave-cgn-cfg… Dean cheng
- Re: [radext] Review of draft-cheng-behave-cgn-cfg… Dean cheng