Subject: [radext] Fwd: RE: non-opsdir review of draft-ietf-radext-dynamic-discovery

From: Stefan Winter <[email-masked]>
Date: Tue, 25 Feb 2014 11:28:42 +0100

Here is the follow-up ...

-------- Original Message --------
Subject: RE: non-opsdir review of draft-ietf-radext-dynamic-discovery
Date: Mon, 24 Feb 2014 13:40:53 -0500
From: ietfdbh <[email-masked]>
To: 'Stefan Winter' <[email-masked]>

Hi Stefan,

Yes. It is ok to send this to the radext list.
You can also post the following comments, but I am not subscribed to radext,
so I will not follow subsequent discussions.
Here are a few comments, inline, regarding your reply.

David Harrington
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: Stefan Winter [mailto:[email-masked]]
> Sent: Monday, February 24, 2014 8:16 AM
> To: ietfdbh; [email-masked]
> Subject: Re: non-opsdir review of draft-ietf-radext-dynamic-discovery
[...]

> Well, one document has, it's the reference [I-D.ietf-radext-nai] "The
> Network Access Identifier" (which is normative).

Ah, you're right. I looked for references to terminology in the terminology
section.
It would be helpful to list, in the terminology section, which terms are
used and which references define the terms.
Something like "[draft-nai] defines the following terminology related to
identifiers: nai, realm, consortium"
That way readers don't need to hunt through all your normative references to
find the definitions.
I would not have necessarily thought to read a work-in-progress draft on NAI
to find the term realm.
Keep in mind you are trying to get people to buy into your proposal; if you
make it hard to read and understand, readers will just walk away.
> 
> 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.

It might be useful to point to both and include an explanation of why you
include the I-D.
That way, anybody reviewing the draft (including potential implementers and
IESG) will benefit from this additional information.
When the ID becomes an RFC, you can change the 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."
> 
So now that I better understand the purpose of realms, isn't the Diameter
standard designed to handle collaborating entities for authentication?
(obviously, not being a RADIUS, expert, neither am I a Diameter expert.)
[...]
> > 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.
> 

I suggest you include a "Operations and Manageability Considerations"
section, and explain the expected applicability.
Your explanation here would be useful to other reviewers.

> 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.
> 
You are, however, asking IANA to register assignments.
And I think you are using non-experimental registries.
And those assignments are not likely to be unassigned at the end of the
experiment.

This raises an additional point.
When I was on the IESG, there was a push (by people still on the IESG) to
require that experimental RFCs:
1) clearly state that the proposal is a proposed experiment,
2) explain what communities are expected to participate in the experiment,
3) explain the expected duration of the experiment,
4) describe the expected information to be gathered form the experiment,
5) describe "success" factors for the experiment,

There might be an RFC that more definitively states those (and possibly
other) requirements. Check with your AD.

> > 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 <[email-masked]>
> 
>       Contact: IETF Chair <[email-masked]>
> 
>       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."
> 

Radius/tls and radius/dtls are actually defined in documents other than this
one.
THIS document is about radius discovery using a specific approach and
algorithms, for specific environments.
This document is also experimental, and might never be published as an RFC.
So it concerns me to have radiustls and radiusdtls names reserved by this
document.

Might it be a good idea to separate this draft into two drafts?
	1) A standards-track document for registering RADIUS services in
DNS, a simple DNS discovery of radiustls and radiusdtls servers,
	2) An experimental draft for explaining how to go further to
discover realms, especially in the case of roaming consortia?
I'm not quite sure where one thing ends and the other starts.

One nit that I noticed in my initial review.
You use an example of very.bad.example
While cute, I did not understand whether this was simply cuteness in names,
or actually implying that this particular example was an example of a very
bad practice. I finally decided it was just cuteness, but ambiguity is not a
good thing in standards-related documents ;-)
I expect you could find better examples.

Hope this helps; you can forward this to the list, or not, at your
discretion.

dbh

---

From: Stefan Winter <[email-masked]>
Date: Wed, 26 Feb 2014 11:28:41 +0100

Hi,

> I would not have necessarily thought to read a work-in-progress draft on NAI

Okay, that's easy enough to fix :-) I've added that note to my working copy.

> When the ID becomes an RFC, you can change the reference.

Okay, adding RFC4282 with a note that it's soon-to-be-obsolete by
draft-nai (in Terminolofy section)

> (obviously, not being a RADIUS, expert, neither am I a Diameter expert.)

That's correct; Diameter has this functionality "built-in" while for
RADIUS it's a retrofit.

This also relates to one of your points below: this whole mechanism is
much less experimental than the document track Experimental might suggest.

If you take a look at the Diameter counterpart, it's way less thoroughly
described; much more thought on the exact details on DNS usage for
discovery has gone into this radext draft. And yet, the Diameter one is
standards-track; while this one is "experimental".

> Your explanation here would be useful to other reviewers.

Yes, that's a reasonable point. I'll add such a section.

Here is the current text:

"4.  Operations and Manageability Considerations

   The discovery algorithm as defined in this document contains several
   options; the major ones being use of NAPTR vs. SRV; how to determine
   the authorization status of a contacted server for a given realm;
   which trust anchors to consider trustworthy for the RADIUS
   conversation setup.

   Random parties which do not agree on the same set of options may not
   be able to interoperate.  However, such a global interoperability is
   not intended by this document.

   Discovery as per this document becomes important inside a roaming
   consortium, which has set up roaming agreements with the other
   partners.  Such roaming agreements require much more than a technical
   means of server discovery; there are administrative and contractual
   considerations at play (service contracts, backoffice compensations,
   procedures, ...).

   A roaming consortium's roaming agreement must include a profile of
   which choice points of this document to use.  So long as the roaming
   consortium can settle on one deployment profile, they will be able to
   interoperate based on that choice; this per-consortium
   interoperability is the intended scope of this document."

> other) requirements. Check with your AD.

right; for RFC6614 I had included such information in a subsection
"Document Status". I'll write up the same for this draft.

The current text is:

"1.3.  Document Status

   This document is an Experimental RFC.

   The communities expected to use this document are roaming consortia
   whose authentication services are based on the RADIUS protocol.

   The duration of the experiment is undetermined; as soon as enough
   experience is collected on the choice points mentioned below, it is
   expected to be obsoleted by a standards-track version of the protocol
   which trims down the choice points.

   If that removal of choice points obsoletes tags or service names as
   defined in this document and allocated by IANA, these items will be
   returned to IANA as per the provisions in [RFC6335].

   The document provides a discovery mechanism for RADIUS which is very
   similar to the approach that is taken with the Diameter protocol
   [RFC6733].  As such, the basic approach (using NAPTR records in DNS
   domains which match NAI realms) is not of very experimental nature.

   However, the document offers a few choice points and extensions which
   go beyond the provisions for Diameter.  The list of major additions/
   deviations is

   o  a fallback mechanism using SRV records, should no matching NAPTR
      records be found (not defined for Diameter)

   o  Provisions for determining the authority of a server to act for
      users of a realm (declared out of scope for Diameter)

   o  much more in-depth guidance on DNS regarding timeouts, failure
      conditions, alteration of TTLs (not considered for Diameter)

   o  a partially correct routing error detection (not considered for
      Diameter)"

RFC6335 speaks of special considerations only for experimental ports,
not service names. Do service names have an experimental space? I don't
see that in RFC2782.

A STD-track update could also return assignments to IANA. RFC6335 has a
process for that.

> Radius/tls and radius/dtls are actually defined in documents other than this

As protocols, yes; but their static-config deployment does not need
service names for use in DNS. So the other documents don't discuss that.

> So it concerns me to have radiustls and radiusdtls names reserved by this

If the document doesn't get published as an RFC, IANA will not make the
assignment, so I don't know if that's really a significant issue.

I would also not say the document is for specific environments; it's
useful for everyone doing dynamic discovery in any roaming consortium -
the deployment only needs to be profiled to a specific roaming
consortium's setup.

This is in a way comparable to the applicability of PKI - it is of
generic usefulness in many contexts, but each of those contexts makes
its own independent choice regarding deployment properties of a PKI
(e.g. browsers have a different security model than VPN dial-in
deployments in an enterprise; but they all use the PKI standards).

> I'm not quite sure where one thing ends and the other starts.

At least in my mind, these go together so closely that separating them
does not make much sense. E.g. one doesn't discover a RADIUS server on
its own for the sake of discovering; it's discovered for a reason,
namely authenticating someone. And that's where the realm immediately
comes in.

> I expect you could find better examples.

Umm... it's a leftover from an early rev of my individual submission, I
believe. I can just as well give it a generic name; there's no
particular reason for it.

Greetings,

Stefan Winter

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