Re: Review of draft-ietf-radext-dynamic-discovery-01

[Stefan Winter <stefan.winter@restena.lu>]

Hi,

> [BA] References aren't allowed in the abstract.  Also, this is only about RADIUS, not AAA in general, no?
>   

I've purged the reference in the upcoming revision. As for AAA vs.
RADIUS, there is still no conclusion about the dime vs. this approach,
and whether they can be united. Discussion continues; probably at the
dime meeting in Anaheim.

> 1.2
>
>    RadSec node: a RadSec client or server
>
>    RadSec Client: a RadSec instance which initiates a new connection.
>
>    RadSec Server: a RadSec instance which listens on a RadSec port and
>    accepts new connections
>
> [BA] As we discussed at IETF 75, RadSec is a product name.  Can we use "RADIUS over TLS" and "RADIUS over DTLS" 
> (or maybe RAD-TLS and RAD-DTLS) instead?
>   

I've purged the references to "RadSec" in the upcoming revision. It is
now RADIUS over TLS, as in the corresponding draft.

> Section 2.1
>
>    Dynamic server discovery as defined in this document is only
>    applicable for AAA transactions where a AAA server receives a request
>    with a NAI realm for which no home AAA server is known.  I.e. where
>    static server configuration does not contain a known home
>    authentication server, or where the server configuration explicitly
>    states that the realm destination is to be looked up dynamically.
>    Furthermore, it is only applicable for new user sessions, i.e. for
>    the initial Access-Request.  
>
> [BA] Is this about AAA in general (including Diameter) or just about RADIUS?
>   

Again, subject to further discussion.

>
>       2.2. DNS RR definition
>
>
>
>    DNS definitions of RadSec servers can be either NAPTR records or SRV
>    records.  When both are defined, the resolution algorithm prefers
>    NAPTR results (see section Section 2.3 <http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-01#section-2.3> below).  The NAPTR service
>    field used is "AAAS+RADSECT".  The SRV prefix used is "_radsec._tcp".
>    It is expected that in most cases, the label used for the records is
>    the DNS representation (punycode) of the literal realm name for which
>    the server is the AAA server.
>
> [BA] Given that RadSec is a product name, what should the SRV prefixes be? 
> _radtls._tcp?  _raddtls._udp? 
>   

The _raddtls indicates datagram transport, so the _udp looks halfways
redundant and thus not clean.

I have preliminarily used _radiustls._tcp and _radiustls._udp in the draft.

>    bank-rupt.com
>
> [BA] Suggest use of an example.com domain instead (e.g. bank.example.com). 
>   

I switched to the TLD "example" and a consortium member "bad" in the
upcoming revision.

>
>       2.3. Realm to AAA server resolution algorithm
>
>
>
>    Input I to the algorithm is a User-Name in the form of a NAI as
>    defined in [RFC4282 <http://tools.ietf.org/html/rfc4282>] as extracted from the User-Name attribute in an
>    Access-Request.  Output O of the algorithm is a set of hostname:port
>    and an assoiciated order/preference; the set can be empty.
>
>    Note well: The attribute User-Name does not necessarily contain well-
>    formed NAIs and may not even contain well-formed UTF-8 strings.  This
>    document describes server discovery only for well-formed NAIs in
>    UTF-8 encoding.  The result of all other possible contents of User-
>    Name is unspecified; this includes, but is not limited to:
>
> [BA] Given the problems with RFC 4282 described by Alan at IETF 73, I'd suggest not referencing RFC 4282
> if possible, just focusing on the User-Name attribute, which is defined as UTF-8 by RFC 2865. 
>   

There is still a need to talk about the local vs. realm separator
character. 4282's primary merit for the purposes of the NAI discovery
draft lies in defining the @ character to find the realm. I can drop the
literal reference to 4282, but would then need to write (duplicate) text
from 4282 about the @ character. Is that acceptable?

> As far as I can tell here, the issue here is whether it is possible to utilize the realm-name in UTF-8
> to resolve the address of the RADTLS/DTLS server.  As noted in the IAB document, there are several possible
> ways that this resolution could take place:
>
> a. An A/AAAA query could be sent via mDNS and/or LLMNR, using the realm encoded in UTF-8. 
> b. An A/AAAA query could be sent, by converting the realm in UTF-8 to punycode, using ToASCII(). 
> c. An A/AAAA query could be sent, using the realm encoded in UTF-8. 
>
> When attempting resolution via b), it is possible that the conversion will fail.  If none of the other 
> resolution mechanisms are attempted, or if they fail too, then resolution of the server will not be 
> possible.
>   

The input to the algorithm is a UTF-8 string. The draft then merely
mentions the "host's name resolution library". IMHO, it is then that
library's business to try several mechanism in some host-defined order
and for those, either convert the UTF-8 input into a form of its liking,
or use it directly. Especially after reading the IAB document, it seems
to me that going into more detail or prescribing a particular behaviour
will not work.

The case of the name resolution failing is mentioned in the sentence "If
name resolution returns with error, O = { }. Terminate."

Do you think more text is needed in this area?

> Now that the IDNAbis documents are headed toward WG last call, my recommendation is to reference these,
> rather than IDNA. 
>   

Hm, I don't think I managed IDNA explicitly at all. It only came to play
in the example where tu-münchen was resolved to punycode. Related to my
argument above, whether or not a host name resultion library uses IDNA
(or -bis) is depending on the local host configuration for name
resolution. I'd rather not touch IDNA specialities at all, if that's
possible.

>
>       2.3. Realm to AAA server resolution algorithm
>
>
>
> In addition to the material here, I recommend providing advice on IPv4/IPv6 usage.  One issue that
> has been encountered in IPv6 implementations is that attempting to connect via IPv6 preferentially
> is problematic.  Even though a AAAA RR might be available, and IPv6 might be supported and available
> on a link, this doesn't mean that IPv6 connectivity exists, due to routing table issues.  As a result,
> attempting bring up an IPv6 connection before failing over to IPv4 will often result in a performance
> problem.  A better approach (implemented in MacOS X) is to attempt to bring up both IPv4 and IPv6
> connections and then use the connection that comes up first. 
>
> Section 3
>
>    [Note:
>    assuming here that a hypothetical RADIUS/UDP SRV discovery will NOT
>    deliver the shared secret in the DNS response!]
>
> [BA] I certainly hope not. This somewhat begs the question of when server resolution is useful.  Presumably,
> this is primarily for use with certificate-based authentication, no?  I'd assume that if TLS PSK is being
> used then you'd have static configuration, correct?
>   

Mostly so, I guess. You could construct wild ideas about a consortium
having one PSK (or RADIUS shared secret) for all its realms, so using
some dynamic discovery might work across the consortium. But that's
really ugly. I suppose it's best to delete the UDP+SRV, and PSK+SRV text
completely.
 
> Section 4
>
>    This document contains no actions for IANA.  Maybe.  Not sure about
>    the labels "AAAS+RADSECT" and "_radsec._tcp.".
>
> [BA] What about RADIUS over DTLS?  Does this document apply to that as well? 
>   

This section was completely re-written to consider the S-NAPTR "stuff".
More on that in a separate mail.

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



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>