Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback

Dean cheng <dean.cheng@huawei.com> Tue, 29 July 2014 18:26 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 9365B1B29AD for <radext@ietfa.amsl.com>; Tue, 29 Jul 2014 11:26:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 r_GAM33msu0r for <radext@ietfa.amsl.com>; Tue, 29 Jul 2014 11:26:23 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 925521B2903 for <radext@ietf.org>; Tue, 29 Jul 2014 11:26:21 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHS43759; Tue, 29 Jul 2014 18:23:30 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 29 Jul 2014 19:23:30 +0100
Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.137]) by SJCEML703-CHM.china.huawei.com ([169.254.5.229]) with mapi id 14.03.0158.001; Tue, 29 Jul 2014 11:23:25 -0700
From: Dean cheng <dean.cheng@huawei.com>
To: Alan DeKok <aland@deployingradius.com>, Arran Cudbard-Bell <a.cudbardb@freeradius.org>
Thread-Topic: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback
Thread-Index: AQHPqDcJCcBQbKrtAk6emD97/90CcZuxlrgAgAXLN9A=
Date: Tue, 29 Jul 2014 18:23:24 +0000
Message-ID: <DC7880973D477648AC15A3BA66253F6865FD7DBA@SJCEML702-CHM.china.huawei.com>
References: <mailman.0.1406300368.3016.radext@ietf.org> <D1A82475-4CAA-49D8-A2E3-AC07F4879F15@freeradius.org> <53D2A648.6090606@deployingradius.com>
In-Reply-To: <53D2A648.6090606@deployingradius.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.212.245.225]
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/B3KFLCdkQsdm1lhyjoguAHs7qpI
Cc: "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback
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, 29 Jul 2014 18:26:26 -0000

Alan, Arran,

Thanks for the suggestions, I'll take a look
of these and get back to you.

Please note that this draft is now
draft-ietf-radext-ip-port-radius-ext-01 that
was discussed last week in Toronto.

Dean

> -----Original Message-----
> From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok
> Sent: Friday, July 25, 2014 11:48 AM
> To: Arran Cudbard-Bell
> Cc: radext@ietf.org
> Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback
> 
>   After some other discussion with Arran, I think there is another way
> to solve this problem.
> 
>   As background, this document allows for a NAS to communicate a
> TCP/UDP port set information for specific hosts.  It seems duplicate
> effort to re-define all of the port / protocol information in a RADIUS
> document.
> These information elements are already defined in IPFIX:
> 
> http://www.iana.org/assignments/ipfix/ipfix.xhtml
> 
>   Port ranges, protocols, etc. are all there.
> 
>   I wrote a document for IPFIX to RADIUS mappings:
> 
> http://tools.ietf.org/html/draft-dekok-radius-ipfix-00
> 
>   The intent was to allow for flow-specific accounting in RADIUS.  That
> goal was talked about a lot 2-3 years ago, but has since been ignored.
> I believe that we can re-use it here.
> 
>   The only change necessary to my IPFix document is to add the
> following:
> 
> - use of Acct-Multi-Session-Id to have flow-specific accounting streams
> 
> - use Acct-Multi-Session-Id and Acct-Status-Type start / stop to
> indicate port range allocate / de-allocate.
> 
> 
>   The benefits here are numerous, I think.  RADIUS gains flow-specific
> accounting, and port range allocation signaling.  However, RADIUS does
> *not* need to manage any attributes related to ports, protocols, ranges,
> etc.  All of that is already defined in IPFIX.  We could just reference
> IPFIX, and be done.
> 
>   Alan DeKok.
> 
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext