Re: I-D Action:draft-ietf-radext-radsec-02.txt

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

Hi,

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the RADIUS EXTensions Working Group of the IETF.
>
>
> 	Title           : TLS encryption for RADIUS over TCP (RadSec)
> 	Author(s)       : S. Winter, et al.
> 	Filename        : draft-ietf-radext-radsec-02.txt
> 	Pages           : 17
> 	Date            : 2008-10-24
>
> This document specifies security on the transport layer (TLS) for the
> RADIUS protocol [RFC2865] when transmitted over TCP
> [I-D.dekok-radext-tcp-transport].  This enables dynamic trust
> relationships between RADIUS servers.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>   

This version reflects some offline comments I received in the last
couple of weeks. It's mostly a cleanup and re-sync of things that got
lost in the text reshuffling, use of documentation prefixes and such
things. The diff
http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-ietf-radext-radsec-02.txt
is not very large.

Two issues came up in the discussion that I'd like to raise here:

1) Use of underscore constructs in A and AAAA records
============================================

The dynamic lookup algorithm in Appendix A currently does a NAPTR lookup
for the realm, and if not found looks for

_radsec._tcp.realm IN A/AAAA

It has been brought to my attention that many DNS people frown over
using underscore service lookups with A and AAAA. Apparently, there is
an opinion that this is exactly what SRV was intended for, and I agree.
The thing is: the algorithm in Appendix A is derived from the RFC3588
dynamic lookup algorithm. I.e. there is standards-track precedence for
using _service._transport IN A. The section 5.2 in RFC3588 says:


"If no NAPTR records are found, the requester queries for those
      address records for the destination address,
      '_diameter._sctp'.realm or '_diameter._tcp'.realm.  Address
      records include A RR's, AAAA RR's or other similar records, chosen
      according to the requestor's network protocol capabilities."

I have asked on dime why A/AAAA was given preference over a
corresponding SRV lookup when 3588 was designed, but didn't get a reply
so far. 3588bis currently has the same text.

Now, I wonder if there are good reason for doing so, or if it might be
wiser to specify an SRV lookup if NAPTR doesn't yield results.

2) Registration state of NAPTR "AAAS+RADSECT"
=========================================

Appendix A uses the above NAPTR type. This type is not registered AFAIK.
I am unsure about the registration procedures though. From my
understanding, getting a registered entry requires an RFC normatively
stating the corresponding lookups and protocol specs. Appendix A is
currently not normative, which would be counter-productive in this case.
It might make more sense to make the lookup algorithm normative (of
course after settling the SRV issue above).

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