RE: [radext] Review of draft-ietf-radext-radsec
Bernard Aboba <bernard_aboba@hotmail.com> Fri, 27 January 2012 23:55 UTC
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C50B21F85C7; Fri, 27 Jan 2012 15:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.18
X-Spam-Level:
X-Spam-Status: No, score=-102.18 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 F+gOmhJXlr7s; Fri, 27 Jan 2012 15:55:49 -0800 (PST)
Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6121F85D2; Fri, 27 Jan 2012 15:55:48 -0800 (PST)
Received: from BLU152-W47 ([65.55.116.74]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Jan 2012 15:55:47 -0800
Message-ID: <BLU152-W47CF17AFF3BBE1A27619E2938E0@phx.gbl>
Content-Type: multipart/alternative; boundary="_951639fe-3bc0-49ed-a414-debe6639e541_"
X-Originating-IP: [131.107.0.118]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: Stefan Winter <stefan.winter@restena.lu>, radext@ietf.org, ietf@ietf.org
Subject: RE: [radext] Review of draft-ietf-radext-radsec
Date: Fri, 27 Jan 2012 15:55:47 -0800
Importance: Normal
In-Reply-To: <4F225888.9050601@restena.lu>
References: <BLU152-W47F6A92D20A1F5192F829493860@phx.gbl>, , <4F2109F8.4060505@restena.lu>, <BLU152-W62655DE23A3845D39E8C63938E0@phx.gbl>, <4F225888.9050601@restena.lu>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jan 2012 23:55:47.0939 (UTC) FILETIME=[30E54B30:01CCDD4F]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jan 2012 23:55:50 -0000
Stefan said: "Ok... 3579 defines it to be that way, simply pointing to dynauth; my draft could do so, too, of course. 5080 lists that it is done elsewhere but doesn't reference a particular RFC; looks to me like it could refer to RFC3579." [BA] Yes. Stefan also said: "Interesting use. I don't recall "Error-Cause = Invite" being specified anywhere; it's not in the list of enumerated Error-Cause reasons in the IANA registry anyway. And it's one message on the list that was never replied to. Looks to me like it's one particular NAS sending weird things out-of-spec." [BA] Since the message was posted on the FreeRADIUS list, I was hoping that Alan could enlighten us. The meaning of "Error-Cause=Invite" wasn't obvious to me (e.g. it didn't look like there was an error involved), and as you mentioned, "Invite" isn't in the list of enumerated Error-Cause values. Stefan said: "I would like to note however that ICMP Port Unreachable is a *very* coarse-grained way of NAKing accounting that is of little use anyway... That being said, I can change the spec to "patch" the situation with your suggestion of using Accounting-Response + Error-Cause. It may be the adequate thing to do since this specification is going for Experimental only. [BA] I agree that an ICMP Port Unreachable is not a useful way for a RADIUS server to tell a RADIUS client that it can't process a particular Accounting-Request. However, it does allow the destination to indicate that RADIUS accounting is not supported at all, in a way that can be distinguished from a server or network failure. That's the functionality missing in RADIUS over TLS. Stefan said: "In the long run though, I think this solution is inadequate; if Accounting-NAK signalling is to be fixed, it should be fixed properly (i.e. on a per-packet basis) for all transports, not just this one. Maybe by updating 2866 with a consistent use of Error-Cause, or maybe by adding an Accounting-NAK packet type, analogous to the dynauth NAKs. It is definitely a useful thing to work on; but it's not for the RAIDUS/TLS draft to decide. That would need a wg chartered item (luckily radext is discussing rechartering right now; this might be worthwhile to include...)" [BA] I agree that ICMP Port Unreachable or an equivalent in RADIUS/TLS is not a solution to the other problems you mention. Stefan said: "Please let me know if you'd prefer the Error-Cause "patch" to be in this spec; I'll do as you say ;) [BA] Here is suggested text: (5) RADIUS/UDP [RFC2865] uses negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of RADIUS Accounting packets. Since RADIUS/TLS does not utilize a separate port for Accounting packets, this mechanism is not available. In the event that a client is misconfigured to send Accounting-Request packets to a RADIUS/TLS server which does not support accounting, the RADIUS/TLS server SHOULD reply with an Accounting-Response containing an Error-Cause attribute with value 406 "Unsupported Extension". A RADIUS/TLS accounting client receiving such an Accounting-Response SHOULD log the error.
- Review of draft-ietf-radext-radsec Bernard Aboba
- Re: Review of draft-ietf-radext-radsec Stefan Winter
- Re: Review of draft-ietf-radext-radsec Stefan Winter
- RE: [radext] Review of draft-ietf-radext-radsec Bernard Aboba
- RE: [radext] Review of draft-ietf-radext-radsec Bernard Aboba
- Re: [radext] Review of draft-ietf-radext-radsec Stefan Winter
- Re: [radext] Review of draft-ietf-radext-radsec Stefan Winter
- RE: [radext] Review of draft-ietf-radext-radsec Bernard Aboba