Issue 324: Proposed new name resolution with S-NAPTR

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

Hi,

after issue 324's reminder about NAPTR, the following text might address
the issue:

"2.2.  DNS RR definition

   DNS definitions of RADIUS/TLS servers can be either S-NAPTR records
   (see [RFC3958]) or SRV records.  When both are defined, the
   resolution algorithm prefers S-NAPTR results (see section Section 2.3
   below).

   This specification defines two S-NAPTR service tag: a general-purpose
   tag "nai-roaming" and a special-purpose tag "eduroam" for the eduroam
   roaming consortium.  This specification defines two S-NAPTR protocol
   tags: "radius.tls" for RADIUS over TLS [I-D.ietf-radext-radsec] and
   "radius.dtls" for RADIUS over DTLS [I-D.dekok-radext-dtls].

   This specification defines the SRV prefix "_radiustls._tcp" for
   RADIUS over TLS [I-D.ietf-radext-radsec] and "_radiustls._udp" for
   RADIUS over DTLS [I-D.dekok-radext-dtls].  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."

Accompanied by an IANA Consideration section:

"4.  IANA Considerations

   This document requests IANA registration of the following S-NAPTR
   parameters:

   o  Application Service Tags

      *  nai-roaming

      *  eduroam

   o  Application Protocol Tags

      *  radius.tls

      *  radius.dtls"


This is one of three ways how I could see the resolution happen. They are

1) a single "nai-roaming" service tag, and if some consortium needs its
own, use x-<identifier>
2) a generic "nai-roaming" service tag, and further labels allocated per
their own RFC - I define my own one inline in this document
3) a tag+subtag mechanism (see also my mail to Leslie Daigle, forwarded
by Bernard) to allow e.g.:
   nai-roaming_eduroam.org
   nai-roaming_3gppnetworks.org
   nai-roaming_wimaxforum.com

Number 1 is always possible, but a bailout to unregulated space, with
possible clashes due to the freeform x-...
Number 2 is cumbersome for roaming consortia, because they need their
own RFC to describe themselves.
Number 3 would be cool, but would require allocation of a wildcard
"subspace" within the S-NAPTR service tag space. I'm unsure whether this
is foreseen.

I've put number 2 in the draft to have a starting point, but would
prefer 3 if we can sort it out.

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