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

Alan DeKok <> Fri, 25 July 2014 18:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A024D1A0334 for <>; Fri, 25 Jul 2014 11:47:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RKVS_2HSI_us for <>; Fri, 25 Jul 2014 11:47:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B2F4C1A030C for <>; Fri, 25 Jul 2014 11:47:41 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3144C22403BA; Fri, 25 Jul 2014 20:47:41 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6yuy2kSE4P90; Fri, 25 Jul 2014 20:47:37 +0200 (CEST)
Received: from Thor.local (unknown []) by (Postfix) with ESMTPSA id 400B62240168; Fri, 25 Jul 2014 20:47:37 +0200 (CEST)
Message-ID: <>
Date: Fri, 25 Jul 2014 14:47:36 -0400
From: Alan DeKok <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Arran Cudbard-Bell <>
References: <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [radext] draft-cheng-behave-cgn-cfg-radius-ext-07 feedback
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Jul 2014 18:47:43 -0000

  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:

  Port ranges, protocols, etc. are all there.

  I wrote a document for IPFIX to RADIUS mappings:

  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.