[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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


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.


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>,


(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

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

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

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