Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06
Alan DeKok <aland@deployingradius.com> Thu, 22 August 2013 13:14 UTC
Return-Path: <aland@deployingradius.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90AAE11E81B8 for <radext@ietfa.amsl.com>; Thu, 22 Aug 2013 06:14:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9QDFP-E3f+0 for <radext@ietfa.amsl.com>; Thu, 22 Aug 2013 06:14:31 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54CD711E81C1 for <radext@ietf.org>; Thu, 22 Aug 2013 06:14:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 90D572240144; Thu, 22 Aug 2013 15:14:27 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at power.freeradius.org
Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-LP0bxw1zif; Thu, 22 Aug 2013 15:14:27 +0200 (CEST)
Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id EDB9F224013E; Thu, 22 Aug 2013 15:14:26 +0200 (CEST)
Message-ID: <52160EB3.9070603@deployingradius.com>
Date: Thu, 22 Aug 2013 09:14:27 -0400
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Peter Deacon <peterd@iea-software.com>
References: <86D0772B-4561-46BD-950D-AF95BED87292@gmail.com> <alpine.WNT.2.00.1308210755460.1748@SMURF>
In-Reply-To: <alpine.WNT.2.00.1308210755460.1748@SMURF>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "radext@ietf.org" <radext@ietf.org>
Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 22 Aug 2013 13:14:37 -0000
Peter Deacon wrote: > RFC5176 dynamic auth clients are not necessarily always RADIUS servers. > We have production systems where CoA client and RADIUS server are > separate with separate roles. Seeing value in maintaining separation I > do not favor Additional-Authorization. There is a network connecting the machines. The RADIUS server can proxy Access-Requests to the maching hosting the CoA information. > Accounting proposal is not atomic and depends on assumptions about type > of content. (e.g long attribute not able to fit within 4096 byte limit > cannot be transmitted) There has been no demonstrated need for large accounting packets. > Proposed 'T' bit in extended long attributes means existing systems > supporting extended attributes may require enhancement to pass needed > data. Despite 'SHOULD' language from RFC6929 I do not believe it > reasonable expectation proxy systems able to understand an attribute > known to be broke would elect to forward such an attribute anyway. There are no deployed proxies which implement 6929. The implementations could support the "T" bit before this document is finalized. Nothing prevents implementations from adding new, non-standardized functionality. > General. > > Attribute proxy not possible without proxy server modification to > support draft. The only issue is the T bit. No other proxy modifications are required. > Existing proxy servers not supporting draft may lose ability to > understand/enforce policy when attribute fragmentation is used. Tough. Existing proxy servers which don't implement RFC 6929 won't understand / enforce policies when RFC 6929 attributes are used. This argument is, IMHO, ridiculous. If we are to believe it at face value, it means we cannot implement ANY new feature in RADIUS. Because existing proxies won't be able to enforce policies for those new features. If you want to shut down all progress in RADEXT, just say so. There's no need to repeatedly bring up specious arguments. > A policy of limiting large RADIUS UDP packets to MTU would about triple > number of round trips needed to convey same information. Some systems don't support UDP fragmentation, and drop all fragmented UDP packets. So one alternative is to have *no* RADIUS traffic go through the network. You may think that's better. I don't. Alan DeKok.
- [radext] Adoption call for draft-perez-radext-rad… Jouni Korhonen
- Re: [radext] Adoption call for draft-perez-radext… Jouni Korhonen
- Re: [radext] Adoption call for draft-perez-radext… Stefan Winter
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Sam Hartman
- Re: [radext] Adoption call for draft-perez-radext… Peter Deacon
- Re: [radext] Adoption call for draft-perez-radext… Stefan Winter
- Re: [radext] Adoption call for draft-perez-radext… Peter Deacon
- Re: [radext] Adoption call for draft-perez-radext… Alejandro Perez Mendez
- Re: [radext] Adoption call for draft-perez-radext… Stefan Winter
- Re: [radext] Adoption call for draft-perez-radext… Alejandro Perez Mendez
- Re: [radext] Adoption call for draft-perez-radext… Alejandro Perez Mendez
- Re: [radext] Adoption call for draft-perez-radext… Alejandro Perez Mendez
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Peter Deacon
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Peter Deacon
- Re: [radext] Adoption call for draft-perez-radext… Alejandro Perez Mendez
- Re: [radext] Adoption call for draft-perez-radext… Stefan Winter
- Re: [radext] Adoption call for draft-perez-radext… Sam Hartman
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Jouni Korhonen
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Peter Deacon
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Peter Deacon
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Diego R. Lopez
- Re: [radext] Adoption call for draft-perez-radext… Peter Deacon
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Sam Hartman
- Re: [radext] Adoption call for draft-perez-radext… Alan DeKok
- Re: [radext] Adoption call for draft-perez-radext… Jouni Korhonen
- Re: [radext] Adoption call for draft-perez-radext… Sanchez, Mauricio
- Re: [radext] Adoption call for draft-perez-radext… Alejandro Perez Mendez
- Re: [radext] Adoption call for draft-perez-radext… Diego R. Lopez