[radext] #14: DDNS Application

["radext issue tracker" <trac@tools.ietf.org>]

#14: DDNS Application
------------------------------------+---------------------------------------
 Reporter:  leslie@â                |       Owner:  stefan.winter@â         
     Type:  defect                  |      Status:  new                     
 Priority:  blocker                 |   Milestone:  milestone1              
Component:  dynamic-discovery       |     Version:  1.0                     
 Severity:  Active WG Document      |    Keywords:                          
------------------------------------+---------------------------------------
 Date first submitted: November 17, 2009
 Reference: http://ops.ietf.org/lists/radiusext/2009/msg00633.html

 I came across your RADEXT
 draft (draft-ietf-radext-dynamic-discovery-01.txt).

 You need to know that NAPTR records cannot be used "in the wild" (as in,
 "just retrieve the NAPTR record"), as currently described in your
 document.

 NAPTR records are part of the DNS implementation of the Dynamic
 Delegation Discovery System (DDDS) -- see RFC3403.  To use them, you
 need to define a DDDS application (as outlined in that suite of
 documents).

 You may find that S-NAPTR (RFC3958) does the trick for you.
 [Stefan Winter] 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.

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


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