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
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Peter Deacon
- Re: [radext] Proposed new charter text Sam Hartman
- Re: [radext] Proposed new charter text Stefan Winter
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Sam Hartman
- Re: [radext] Secure COA Sam Hartman
- Re: [radext] Secure COA Alan DeKok
- Re: [radext] Secure COA Sam Hartman
- Re: [radext] Proposed new charter text Peter Deacon
- [radext] Proposed new charter text Stefan Winter
- Re: [radext] Proposed new charter text Stefan Winter
- Re: [radext] Proposed new charter text Alan DeKok
- Re: [radext] Proposed new charter text Stefan Winter