Re: [radext] Extended IDs
Alan DeKok <aland@deployingradius.com> Sun, 03 December 2017 14:18 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 862581243FE for <radext@ietfa.amsl.com>; Sun, 3 Dec 2017 06:18:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 OuoGd1Nl24a2 for <radext@ietfa.amsl.com>; Sun, 3 Dec 2017 06:18:53 -0800 (PST)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id DBBC2124234 for <radext@ietf.org>; Sun, 3 Dec 2017 06:18:52 -0800 (PST)
Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id C42094D4; Sun, 3 Dec 2017 14:18:51 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <alpine.WNT.2.21.1.1712022028110.2252@smurf>
Date: Sun, 03 Dec 2017 09:18:50 -0500
Cc: Winter Stefan <stefan.winter@restena.lu>, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C4CACF8-3940-4209-B44F-C501DAE945CA@deployingradius.com>
References: <fef698a5-9802-c9be-04d7-1e869651c988@restena.lu> <dfd0ff02-c9e8-7253-4fb4-1e6def3e93b2@restena.lu> <alpine.WNT.2.21.1.1712022028110.2252@smurf>
To: Peter Deacon <peterd@iea-software.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/o_TCpLfUlxh5apKEAMsc1IHOBh8>
Subject: Re: [radext] Extended IDs
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 03 Dec 2017 14:18:55 -0000
On Dec 3, 2017, at 3:22 AM, Peter Deacon <peterd@iea-software.com> wrote: > draft-dekok-radext-request-authenticator-02 > > This approach also makes sense conceptually and seems to be marginally easier to manage. No changes to request attributes, no worry about dynamic auth req and no sequence counter to maintain when generating ORA response. That was a major goal in the design. > This approach offers a small benefit ORA response always unambiguously correlated with requesting peer avoiding possibility of (C.) behavior in proxy chains. It does have the possibility of a server sending the ORA attribute back in a response when it's not supposed to. In that case, an old-style proxy *could* forward that attribute downstream. We then have two cases: - the downstream proxy / client doesn't implement the draft, in which case the attribute is ignored - the downstream proxy / client does implement the draft, but hasn't negotiated it with the upstream (which doesn't implement it), and therefore the attribute is ignored. So the change is compatible with existing servers for all possible scenarios. > I don't agree with client behavior when ORA is expected yet missing. The response should always be to silently ignore request. Certainly mandatory fallback mechanism for static configuration is going way too far in dictating behavior / controlling operator preference. That's certainly a good option. I tried to cover all possible scenarios in the draft, with recommended behaviour. But I'm open to changing the recommendations. > Wouldn't count on those who elect to implement a mechanism like this to also spend too much time working viable scalable connection management to provide useful interop with servers that don't support ORA otherwise to be honest likely wouldn't be much point in implementing this draft in the first place. In my view it should not be assumed fallback is harmless or even a viable option. I'm happy with that. i.e. if the server sends bad packets, the client should ignore them. Alan DeKok.
- [radext] Extended IDs Stefan Winter
- Re: [radext] Extended IDs Stefan Winter
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Acee Lindem (acee)
- Re: [radext] Extended IDs Robert Raszuk
- Re: [radext] Extended IDs Jakob Heitz (jheitz)
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Jakob Heitz (jheitz)
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Astrid Smith
- Re: [radext] Extended IDs Naiming Shen (naiming)
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Stig Venaas
- Re: [radext] Extended IDs Enke Chen
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Arran Cudbard-Bell
- Re: [radext] Extended IDs peter
- Re: [radext] Extended IDs Bernard Aboba
- Re: [radext] Extended IDs Alan DeKok
- [radext] FW: Extended IDs Albert Tian
- Re: [radext] Extended IDs Enke Chen
- Re: [radext] Extended IDs Brian Weis (bew)
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Brian Weis (bew)
- Re: [radext] Extended IDs David Carrel
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Adam Bishop
- Re: [radext] Extended IDs Jun Zhuang
- Re: [radext] Extended IDs Naiming Shen (naiming)
- Re: [radext] Extended IDs Naiming Shen (naiming)
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Naiming Shen (naiming)
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Naiming Shen (naiming)
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Naiming Shen (naiming)
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Naiming Shen (naiming)
- Re: [radext] Extended IDs Jakob Heitz (jheitz)
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Naiming Shen (naiming)
- Re: [radext] Extended IDs Stefan Winter
- Re: [radext] Extended IDs Stefan Winter
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Enke Chen
- Re: [radext] Extended IDs Peter Deacon
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Acee Lindem (acee)
- Re: [radext] Extended IDs Adam Bishop
- Re: [radext] Extended IDs Enke Chen
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Stefan Winter
- Re: [radext] Extended IDs Acee Lindem (acee)
- Re: [radext] Extended IDs Alan DeKok
- Re: [radext] Extended IDs Acee Lindem (acee)
- Re: [radext] Extended IDs Stefan Winter
- Re: [radext] Extended IDs Alexander Clouter