Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-06
Alan DeKok <aland@deployingradius.com> Thu, 22 August 2013 23:17 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 6586221F9D09 for <radext@ietfa.amsl.com>; Thu, 22 Aug 2013 16:17:39 -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 cNKKZkpkdUqG for <radext@ietfa.amsl.com>; Thu, 22 Aug 2013 16:17:33 -0700 (PDT)
Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 78E5D11E826D for <radext@ietf.org>; Thu, 22 Aug 2013 16:17:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8324F2240144; Fri, 23 Aug 2013 01:17:18 +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 rXteLcQEHKhK; Fri, 23 Aug 2013 01:17:16 +0200 (CEST)
Received: from Thor-2.local (unknown [70.50.218.116]) by power.freeradius.org (Postfix) with ESMTPSA id 1B76C224013E; Fri, 23 Aug 2013 01:17:16 +0200 (CEST)
Message-ID: <52169BFE.7020404@deployingradius.com>
Date: Thu, 22 Aug 2013 19:17:18 -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> <52160EB3.9070603@deployingradius.com> <alpine.WNT.2.00.1308220754420.1748@SMURF>
In-Reply-To: <alpine.WNT.2.00.1308220754420.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 23:17:39 -0000
Peter Deacon wrote: > Speaking for myself this is problematic. Dynamic auth clients are just > clients with no capability to act as RADIUS server. They only manage a > subset of possible authorization parameters not capable of full response. Would it be possible to change them? After all, implementing any draft requires changes to existing systems. As with anything RADIUS, no proposal will be perfect. There may be some situations where the proposal doesn't match existing practices. e.g. multiple clients behind a NAT. The solution isn't to give on the proposal and walk away. The solution may be to say that certain situations are simply not supported. > The argument is not whether it is possible to coordinate rather value in > maintaining separation. If transport limits are lifted rather than > supporting adoption of this draft none of these "workarounds" are > necessary. Write a draft proposing to lift the transport limits for UDP. Make it handle all of the existing situations. e.g. "my upstream equipment doesn't deal with fragmented UDP packets, therefore I absolutely oppose raising the transport limits". When you replace one imperfect proposal with another imperfect proposal because the first one is imperfect... I just find it unproductive. > I apologize for any confusion. By attribute proxy I mean forwarding > requests based on attributes other than User-Name. See my response to Stefan. Are there roaming federations which proxy based on anything *other* than User-Name? If so, I'm unaware of them. What you do in your own network is your issue. However, the draft could be clearer, and state that private networks need to do something so that the fragmentation proxy works. > My understanding is both existing and new attributes may be conveyed > using the fragmentation mechanism. Existing attributes may end up being > transmitted in separate requests where previously they would have to > occur in the same request. Yes. This does not address my counter-argument. > [ re: UDP fragmentation] > > This is an edge problem within most operators administrative control to > effect. Maybe. Do a search for "SIP UDP fragmentation", and you'll see many complaints. The summary is that fragmented UDP packets are not generally supported across the Internet. An operator may be able to fix their own equipment. They do *not* have the capability to fix someone else's equipment. 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