Re: [radext] Proposed new charter text

Peter Deacon <peterd@iea-software.com> Mon, 23 March 2015 04:14 UTC

Return-Path: <peterd@iea-software.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 0A4C61A87CD for <radext@ietfa.amsl.com>; Sun, 22 Mar 2015 21:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Fz5g8sE11cLt for <radext@ietfa.amsl.com>; Sun, 22 Mar 2015 21:14:31 -0700 (PDT)
Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 42BC11A87C7 for <radext@ietf.org>; Sun, 22 Mar 2015 21:14:31 -0700 (PDT)
Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <B0005964320@aspen.iea-software.com>; Sun, 22 Mar 2015 21:14:30 -0700
Date: Sun, 22 Mar 2015 21:14:36 -0700
From: Peter Deacon <peterd@iea-software.com>
To: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com>
Message-ID: <alpine.WNT.2.20.1.1503221852040.3600@SMURF>
References: <5502B836.5000100@restena.lu> <alpine.WNT.2.20.1.1503221133420.3600@SMURF> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <alpine.WNT.2.20.1.1503221518060.3600@SMURF> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com>
User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07)
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="992167078-9685-1427084076=:3600"
Archived-At: <http://mailarchive.ietf.org/arch/msg/radext/snR5m9uf_Bn0RtaeO63NrrSH6cs>
Cc: "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] Proposed new charter text
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: Mon, 23 Mar 2015 04:14:33 -0000

On Sun, 22 Mar 2015, Alan DeKok wrote:

> On Mar 22, 2015, at 8:44 PM, Peter Deacon <peterd@iea-software.com> wrote:

>  Maybe I’m misunderstanding something, but no.  A CoA or 
> Disconnect-Request packet addresses *one* session with *one* request. 
> Nothing in RFC 5176 suggests otherwise.

RFC5176 Section 2.3 explains atomicity requirements while CoA or DM 
requests match multiple sessions.

>>  Sufficient / required session identifying attributes varies between
>>  NASes and sometimes across access technologies within the same NAS.
>>  There are no further constraints expressed in draft on both required /
>>  acceptable session identifying attributes and method of initial
>>  authentication proxy (realm based or other policy based)

>  Because the draft doesn’t address session identification.  It just 
> addresses proxying.  RFC 5176 addresses session identification.  Badly, 
> IMHO, but that’s the WG consensus.  No one could agree on a solution, so 
> it was left pretty much the same as RFC 3576.

This an important reason why I believe state will be required in some 
cases to facilitate correlation in the event insufficient information is 
available to do so.

I believe the mechanism to support can be fully opaque like 
Operator-NAS-Identifier and fully implementation dependant I advocate only 
enabling communication channel exist.

I believe Operator-NAS-Identifier's constraints make it insufficient for 
this role otherwise it would be sufficient.  Section 3.1 20 octets 
language is insufficient and automatic removal of NAS identifying 
attributes may be counterproductive.

I do not advocate for fixing Dynamic authorization or session identifying 
attributes.  I do not advocate for fixing Proxy.  In previous remarks 
possible courses of action were enumerated to assist in demonstrating why 
state is needed by implementations.

With regards to CoA draft I would support either a separate State 
attribute or loosening constraints of Operator-NAS-Identifier.

Regardless of concerns specific to CoA draft appreciate any consideration 
of my recommendation.

regards,
Peter