Subject: [radext] #13: Review

From: "radext issue tracker" <[email-masked]>
Date: Thu, 13 May 2010 22:37:27 -0000

#13: Review
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  stefan.winter@…         
     Type:  defect                     |      Status:  new                     
 Priority:  major                      |   Milestone:  milestone1              
Component:  dynamic-discovery          |     Version:  1.0                     
 Severity:  Active WG Document         |    Keywords:                          
---------------------------------------+------------------------------------
 Date first submitted: August 9, 2009
 Reference: http://ops.ietf.org/lists/radiusext/2009/msg00357.html

 Abstract
    This document specifies a means to find authoritative AAA servers for
    a given NAI realm as defined in [RFC4282].  It can be used in
    conjunction with RADIUS over TLS and RADIUS over DTLS.

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

 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?

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

 bank-rupt.com

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

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

 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.

 Now that the IDNAbis documents are headed toward WG last call, my
 recommendation is to reference these,
 rather than IDNA.
 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?

 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?

 [Alan DeKok]
 Bernard Aboba wrote:
 > [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?

   That's a reasonable idea.  I can update the DTLS document to say this.

 > [BA] Given that RadSec is a product name, what should the SRV prefixes
 be?
 > _radtls._tcp?  _raddtls._udp?

   I would say the latter two.  However, _radsec._tcp SHOULD also be used
 for backwards compatibility.

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

   I would suggest so, yes.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/13>
radext <http://tools.ietf.org/radext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>