[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: I-D Action:draft-ietf-radext-radsec-02.txt
> 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:
> Internet-Drafts are also available by anonymous FTP at:
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
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
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).
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
Tel: +352 424409 1
Fax: +352 422473
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.