[radext] Fwd: Re: non-opsdir review of draft-ietf-radext-dynamic-discovery
Stefan Winter <stefan.winter@restena.lu> Tue, 25 February 2014 09:09 UTC
Return-Path: <stefan.winter@restena.lu>
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 D46211A0658 for <radext@ietfa.amsl.com>; Tue, 25 Feb 2014 01:09:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.254
X-Spam-Level:
X-Spam-Status: No, score=0.254 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.547, WEIRD_PORT=0.001] 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 5eX2cbcnznFq for <radext@ietfa.amsl.com>; Tue, 25 Feb 2014 01:09:24 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 962FB1A03C3 for <radext@ietf.org>; Tue, 25 Feb 2014 01:09:23 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 689A310583 for <radext@ietf.org>; Tue, 25 Feb 2014 10:09:22 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5938710581 for <radext@ietf.org>; Tue, 25 Feb 2014 10:09:22 +0100 (CET)
Message-ID: <530C5DA2.1040803@restena.lu>
Date: Tue, 25 Feb 2014 10:08:50 +0100
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "radext@ietf.org" <radext@ietf.org>
References: <530B4629.2080407@restena.lu>
In-Reply-To: <530B4629.2080407@restena.lu>
X-Enigmail-Version: 1.6
OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
X-Forwarded-Message-Id: <530B4629.2080407@restena.lu>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="bBqrrpFmgRnJkMAgE17mBW6hxp7XJaUgN"
X-Virus-Scanned: ClamAV
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/YzB9hYRKA7_d1wurazp83rTUey8
Subject: [radext] Fwd: Re: non-opsdir review of draft-ietf-radext-dynamic-discovery
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: Tue, 25 Feb 2014 09:09:28 -0000
Hi, the draft was handed out for an early opsdir review. The below comments are not opsdir, but are useful input nontheless. They triggered a few editorial changes, see below. There's a follow-up which I'll forward in a few seconds. Greetings, Stefan Winter -------- Original Message -------- Subject: Re: non-opsdir review of draft-ietf-radext-dynamic-discovery Resent-Date: Mon, 24 Feb 2014 14:17:52 +0100 (CET) Resent-From: draft-alias-bounces@tools.ietf.org Resent-To: mikem@open.com.au, stefan.winter@restena.lu Date: Mon, 24 Feb 2014 14:16:25 +0100 From: Stefan Winter <stefan.winter@restena.lu> To: ietfdbh <ietfdbh@comcast.net>, draft-ietf-radext-dynamic-discovery@tools.ietf.org Hello, (inline; is it okay to forward this to the radext list?) > I started performing an OPSDIR review for this document. I decided this > might require a DNS expert, and turned the review back for re-assignment, > > I found this document difficult to review, because I am not an expert on > RADIUS. Thanks for sharing your results with us! > The Introduction immediately jumps into a discussion of realms, with no > references as to where to find a definition of realm. I checked the > terminology section, but there is no discussion of realms. I checked the > references section, but the documents listed there have no mention of realm. Well, one document has, it's the reference [I-D.ietf-radext-nai] "The Network Access Identifier" (which is normative). Many would think that referencing RFC4282 would be most natural when talking about realms, as it is the current RFC on that topic. However, it has many acknowledged errors, and [I-D.ietf-radext-nai] is an attempts to fix them; so I'd rather point to current work instead, and accept that our document gets delayed by a pending normative reference. I take your point though that [I-D.ietf-radext-nai] is referenced very late in the document, and that it should rather be introduced in the Introduction. I've done that in my -11-to-be now. The new text is: "1. Introduction RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP, RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers (clients, servers). Where more than one administrative entity collaborates for RADIUS authentication of their respective customers (a "roaming consortium"), the Network Access Identifier (NAI) [I-D.ietf-radext-nai] is the suggested way of differentiating users between those entities; the part of a username to the right of the @ delimiter in a NAI is called the user's "realm". Where many realms and RADIUS forwarding servers are in use, the number of realms to be forwarded and the corresponding number of servers to configure may be significant. Where new realms with new servers are added or details of existing servers change on a regular basis, maintaining a single monolithic configuration file for all these details may prove too cumbersome to be useful. Furthermore, in cases where a roaming consortium consists of independently working branches (e.g. departments, national subsidiaries), each with their own forwarding servers, and who add or change their realm lists at their own discretion, there is additional complexity in synchronising the changed data across all branches." > The Introduction continues into a discussion of "roaming consortia" and > "independently working branches", again with no references. > It is REALLY difficult to understand what this document is about without > references to the basic terminology in use here. Okay; "roaming consortium" is now defined inline, and "branches" has gotten two examples for easier consumption - see above. > Luckily, Wikipedia explains them, with references, so I could at least know > these were IETF-standard terms defined elsewhere, not just in this document. Sorry about that. > This document proposes the use of realm-to-DNS mappings in DNS, to provide > an approach to realm discovery. According to the Introduction, this is only > one such mechanism. This one such mechanism may use either S-NAPTR records > or SRV records. > The document also specifies various approaches for verifying an authorized > party. > I have some concerns about the manageability and operability for realm > discovery if there are multiple approaches, multiple mechanisms within that > approach, and multiple algorithms for verification. > I would expect better interoperability if this document was something where > the procedures were more nailed down. Point taken. In my defense though :-) : This is a document where global interop is not a requirement. A roaming agreement requires much more than technical discoverability; there's paperwork attached to it. Service contracts, backoffice compensations, procedures, ... So long as one consortium can settle on one deployment option, they will be able to interoperate based on that choice; this is the scope we're looking at here. The service contract for the consortium would nail down which CAs are trustworthy anchors; which properties a certificate needs to have, etc. Plus, this is Expermental :-) ; an abundance of options is maybe not the best but I'd hope it is tolerable at this stage. If one specific validation mechanism or DNS form prevails in real deployment, the document can evolve into Standards Track and become more narrow. > This document deals with DNS SRV records, but there is no mention of > RFC6335, the BCP for SRV and Transport registrations. I rather expected that > it might reference the BCP someplace. It might help reviewers if you > describe whether your proposal follows the BCP. The proposed names conform to section 5.1 of RFC6335. I noticed now (after realising that RFC6335 exists ;-) ) that my notion of service label = _ + "service name" and so what's requested at IANA is not a service label, but the underlysing service name. I've corrected the IANA Considerations section and added all required information as per section 8.1.1 of RFC6335. This is the new text of the corresponding subsection: " This document reserves the use of the "radiustls" and "radiusdtls" service names. Registration information as per [RFC6335] section 8.1.1 is as follows: Service Name: radiustls; radiusdtls Transport Protocols: TCP, UDP Assignee: IESG <iesg@ietf.org> Contact: IETF Chair <chair@ietf.org> Description: Authentication, Accounting and Dynamic authorization via the RADIUS protocol. These service names are used to construct the SRV service labels "_radiustls" and "_radiusdtls" for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. Reference: RFC Editor Note: please insert the RFC number of this document. The protocol does not use broadcast, multicast or anycast communication." > So this is NOT an OPSDIR review; that will be done by somebody else. > This is just a few suggestions that I think might make your document easier > for readers and reviewers. Sure thing! Thanks a lot! Stefan Winter > > David Harrington > ietfdbh@comcast.net > +1-603-828-1401 > > -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
- [radext] Fwd: Re: non-opsdir review of draft-ietf… Stefan Winter
- [radext] Fwd: RE: non-opsdir review of draft-ietf… Stefan Winter
- Re: [radext] Fwd: RE: non-opsdir review of draft-… Stefan Winter