draft-ietf-radext-dynamic-discovery-12.txt   draft-ietf-radext-dynamic-discovery-13.txt 
RADIUS Extensions Working Group S. Winter RADIUS Extensions Working Group S. Winter
Internet-Draft RESTENA Internet-Draft RESTENA
Intended status: Experimental M. McCauley Intended status: Experimental M. McCauley
Expires: April 30, 2015 OSC Expires: September 7, 2015 AirSpayce
October 27, 2014 March 06, 2015
NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS
draft-ietf-radext-dynamic-discovery-12 draft-ietf-radext-dynamic-discovery-13
Abstract Abstract
This document specifies a means to find authoritative RADIUS servers This document specifies a means to find authoritative RADIUS servers
for a given realm. It is used in conjunction with either RADIUS/TLS for a given realm. It is used in conjunction with either RADIUS/TLS
and RADIUS/DTLS. and RADIUS/DTLS.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015. This Internet-Draft will expire on September 7, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 4 1.3. Document Status . . . . . . . . . . . . . . . . . . . . . 6
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. DNS Resource Record definition . . . . . . . . . . . . . 4 2.1. DNS Resource Record (RR) definition . . . . . . . . . . . 7
2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.3. Optional name mangling . . . . . . . . . . . . . . . 9 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 12
2.2. Definition of the X.509 certificate property 2.2. Definition of the X.509 certificate property
SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 11 SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 13
3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 12 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 15
3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 12 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Configuration Variables . . . . . . . . . . . . . . . . . 13 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 16
3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4. Realm to RADIUS server resolution algorithm . . . . . . . 14 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 17
3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 14 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 18
3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 18
3.4.4. Validity of results . . . . . . . . . . . . . . . . . 17 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 19
3.4.5. Delay considerations . . . . . . . . . . . . . . . . 18 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 20
3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 18 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 21
4. Operations and Manageability Considerations . . . . . . . . . 20 4. Operations and Manageability Considerations . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 22 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 27 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 30
1. Introduction 1. Introduction
RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP, RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TCP,
RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers
(clients, servers). (clients, servers).
Where more than one administrative entity collaborates for RADIUS Where more than one administrative entity collaborates for RADIUS
authentication of their respective customers (a "roaming authentication of their respective customers (a "roaming
consortium"), the Network Access Identifier (NAI) consortium"), the Network Access Identifier (NAI)
skipping to change at page 3, line 14 skipping to change at page 3, line 14
of existing servers change on a regular basis, maintaining a single of existing servers change on a regular basis, maintaining a single
monolithic configuration file for all these details may prove too monolithic configuration file for all these details may prove too
cumbersome to be useful. cumbersome to be useful.
Furthermore, in cases where a roaming consortium consists of Furthermore, in cases where a roaming consortium consists of
independently working branches (e.g. departments, national independently working branches (e.g. departments, national
subsidiaries), each with their own forwarding servers, and who add or subsidiaries), each with their own forwarding servers, and who add or
change their realm lists at their own discretion, there is additional change their realm lists at their own discretion, there is additional
complexity in synchronising the changed data across all branches. complexity in synchronising the changed data across all branches.
These situations can benefit significantly from a distributed Where realms can be partitioned (e.g. according to their top-level
mechanism for storing realm and server reachability information. domain ending), forwarding of requests can be realised with a
This document describes one such mechanism: storage of realm-to- hierarchy of RADIUS servers, all serving their partition of the realm
server mappings in DNS. space. Figure 1 show an example of this hierarchical routing.
+-------+
| |
| . |
| |
+---+---+
/ | \
+----------------/ | \---------------------+
| | |
| | |
| | |
+--+---+ +--+--+ +----+---+
| | | | | |
| .edu | . . . | .nl | . . . | .ac.uk |
| | | | | |
+--+---+ +--+--+ +----+---+
/ | \ | \ |
/ | \ | \ |
/ | \ | \ |
+-----+ | +-----+ | +------+ |
| | | | | |
| | | | | |
+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
| | | | | | | | | | | |
|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
| | | | | | | | | | | |
+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
| |
| |
+--+--+ +--+--+
| | | |
+-+-----+-+ | |
| | +-----+
+---------+
user: paul@surfnet.nl surfnet.nl Authentication server
Figure 1: RADIUS hierarchy based on Top-Level Domain partitioning
However, such partitioning is not always possible. As an example, in
one real-life deployment, the administrative boundaries and RADIUS
forwarding servers are are organised along country borders, but
generic top-level domains such as .edu do not map to this choice of
boundaries (see [I-D.wierenga-ietf-eduroam] for details). These
situations can benefit significantly from a distributed mechanism for
storing realm and server reachability information. This document
describes one such mechanism: storage of realm-to-server mappings in
DNS; realm-based request forwarding can then be realised without a
static hierarchy such as in the following figure:
---------
/ \
--------- ------------
/ \
| DNS -
----------| \
/ \ surfnet.nl NAPTR? |
(1) / ---- -> radius.surfnet.nl /
/ \ /
/ -------- ---------
/ \---------/
|
| ---------------------------------------
| / (2) RADIUS \
| | |
+---+---+ +----+---+ +----+---+ +--+---+ +-----+----+ +-----+-----+
| | | | | | | | | | | |
|utk.edu| |utah.edu| |case.edu| |hva.nl| |surfnet.nl| |soton.ac.uk|
| | | | | | | | | | | |
+----+--+ +--------+ +--------+ +------+ +----+-----+ +-----------+
| |
| |
+--+--+ +--+--+
| | | |
+-+-----+-+ | |
| | +-----+
+---------+
user: paul@surfnet.nl surfnet.nl Authentication server
Figure 2: RADIUS hierarchy based on Top-Level Domain partitioning
This document also specifies various approaches for verifying that This document also specifies various approaches for verifying that
server information which was retrieved from DNS was from an server information which was retrieved from DNS was from an
authorised party; e.g. an organisation which is not at all part of a authorised party; e.g. an organisation which is not at all part of a
given roaming consortium may alter its own DNS records to yield a given roaming consortium may alter its own DNS records to yield a
result for its own realm. result for its own realm.
1.1. Requirements Language 1.1. Requirements Language
In this document, several words are used to signify the requirements In this document, several words are used to signify the requirements
skipping to change at page 4, line 23 skipping to change at page 6, line 39
experience is collected on the choice points mentioned below, it is experience is collected on the choice points mentioned below, it is
expected to be obsoleted by a standards-track version of the protocol expected to be obsoleted by a standards-track version of the protocol
which trims down the choice points. which trims down the choice points.
If that removal of choice points obsoletes tags or service names as If that removal of choice points obsoletes tags or service names as
defined in this document and allocated by IANA, these items will be defined in this document and allocated by IANA, these items will be
returned to IANA as per the provisions in [RFC6335]. returned to IANA as per the provisions in [RFC6335].
The document provides a discovery mechanism for RADIUS which is very The document provides a discovery mechanism for RADIUS which is very
similar to the approach that is taken with the Diameter protocol similar to the approach that is taken with the Diameter protocol
[RFC6733]. As such, the basic approach (using NAPTR records in DNS [RFC6733]. As such, the basic approach (using Naming Authority
domains which match NAI realms) is not of very experimental nature. Pointer (NAPTR) records in DNS domains which match NAI realms) is not
of very experimental nature.
However, the document offers a few choice points and extensions which However, the document offers a few choice points and extensions which
go beyond the provisions for Diameter. The list of major additions/ go beyond the provisions for Diameter. The list of major additions/
deviations is deviations is
o Provisions for determining the authority of a server to act for o Provisions for determining the authority of a server to act for
users of a realm (declared out of scope for Diameter) users of a realm (declared out of scope for Diameter)
o much more in-depth guidance on DNS regarding timeouts, failure o much more in-depth guidance on DNS regarding timeouts, failure
conditions, alteration of Time-To-Live (TTL) information than the conditions, alteration of Time-To-Live (TTL) information than the
Diameter counterpart Diameter counterpart
o a partially correct routing error detection during DNS lookups o a partially correct routing error detection during DNS lookups
2. Definitions 2. Definitions
2.1. DNS Resource Record definition 2.1. DNS Resource Record (RR) definition
DNS definitions of RADIUS/TLS servers can be either S-NAPTR records DNS definitions of RADIUS/TLS servers can be either S-NAPTR records
(see [RFC3958]) or SRV records. When both are defined, the (see [RFC3958]) or Service Record (SRV) records. When both are
resolution algorithm prefers S-NAPTR results (see Section 3.4 below). defined, the resolution algorithm prefers S-NAPTR results (see
Section 3.4 below).
2.1.1. S-NAPTR 2.1.1. S-NAPTR
2.1.1.1. Registration of Application Service and Protocol Tags 2.1.1.1. Registration of Application Service and Protocol Tags
This specification defines three S-NAPTR service tags: This specification defines three S-NAPTR service tags:
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| Service Tag | Use | | Service Tag | Use |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| aaa+auth | RADIUS Authentication, i.e. traffic as | | aaa+auth | RADIUS Authentication, i.e. traffic as |
| | defined in [RFC2865] | | | defined in [RFC2865] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
skipping to change at page 5, line 21 skipping to change at page 7, line 35
| aaa+auth | RADIUS Authentication, i.e. traffic as | | aaa+auth | RADIUS Authentication, i.e. traffic as |
| | defined in [RFC2865] | | | defined in [RFC2865] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+acct | RADIUS Accounting, i.e. traffic as | | aaa+acct | RADIUS Accounting, i.e. traffic as |
| | defined in [RFC2866] | | | defined in [RFC2866] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. |
| | traffic as defined in [RFC5176] | | | traffic as defined in [RFC5176] |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
Figure 1: List of Service Tags Figure 3: List of Service Tags
This specification defines two S-NAPTR protocol tags: This specification defines two S-NAPTR protocol tags:
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| Protocol Tag | Use | | Protocol Tag | Use |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| radius.tls.tcp | RADIUS transported over TLS as defined | | radius.tls.tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] | | | in [RFC6614] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| radius.dtls.udp | RADIUS transported over DTLS as defined | | radius.dtls.udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] | | | in [RFC7360] |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
Figure 2: List of Protocol Tags Figure 4: List of Protocol Tags
Note well: Note well:
The S-NAPTR service and protocols are unrelated to the IANA The S-NAPTR service and protocols are unrelated to the IANA
Service Name and Transport Protocol Number registry Service Name and Transport Protocol Number registry
The delimiter '.' in the protocol tags is only a separator for The delimiter '.' in the protocol tags is only a separator for
human reading convenience - not for structure or namespacing; it human reading convenience - not for structure or namespacing; it
MUST NOT be parsed in any way by the querying application or MUST NOT be parsed in any way by the querying application or
resolver. resolver.
skipping to change at page 7, line 12 skipping to change at page 9, line 25
TLS handshake. Only TLS ciphersuites using X.509 certificates can be TLS handshake. Only TLS ciphersuites using X.509 certificates can be
used with this algorithm. used with this algorithm.
There are numerous ways to define which certificates are acceptable There are numerous ways to define which certificates are acceptable
for use in this context. This document defines one mandatory-to- for use in this context. This document defines one mandatory-to-
implement mechanism which allows to verify whether the contacted host implement mechanism which allows to verify whether the contacted host
is authoritative for an NAI realm or not. It also gives one example is authoritative for an NAI realm or not. It also gives one example
of another mechanism which is currently in wide-spread deployment, of another mechanism which is currently in wide-spread deployment,
and one possible approach based on DNSSEC which is yet unimplemented. and one possible approach based on DNSSEC which is yet unimplemented.
For the approaches which use trust roots (see the following two
sections), a typical deployment will use a dedicated trust store for
RADIUS/TLS certificate authorities, particularly a trust store which
is independent from default "browser" trust stores. Often, this will
be one or few CAs, and they only issue certificates for the specific
purpose of establishing RADIUS server-to-server trust. It is
important not to trust a large set of CAs which operate outside the
control of the roaming consortium, for their issuance of certificates
with the properties important for authorisation (such as NAIRealm and
policyOID below) is difficult to verify. Therefore, clients SHOULD
NOT be pre-configured with a list of known public CAs by the vendor
or manufacturer. Instead, the clients SHOULD start off with an empty
CA list. The addition of a CA SHOULD be done only when manually
configured by an administrator.
2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm
Verification of authority to provide AAA services over RADIUS/TLS is Verification of authority to provide AAA services over RADIUS/TLS is
a two-step process. a two-step process.
Step 1 is the verification of certificate wellformedness and validity Step 1 is the verification of certificate wellformedness and validity
as per [RFC5280] and whether it was issued from a root certificate as per [RFC5280] and whether it was issued from a root certificate
which is deemed trustworthy by the RADIUS/TLS client. which is deemed trustworthy by the RADIUS/TLS client.
Step 2 is to compare the value of algorithm's variable "R" after the Step 2 is to compare the value of algorithm's variable "R" after the
skipping to change at page 9, line 29 skipping to change at page 12, line 15
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| SRV Label | Use | | SRV Label | Use |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
| _radiustls._tcp | RADIUS transported over TLS as defined | | _radiustls._tcp | RADIUS transported over TLS as defined |
| | in [RFC6614] | | | in [RFC6614] |
| - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
| _radiustls._udp | RADIUS transported over DTLS as defined | | _radiustls._udp | RADIUS transported over DTLS as defined |
| | in [RFC7360] | | | in [RFC7360] |
+-----------------+-----------------------------------------+ +-----------------+-----------------------------------------+
Figure 3: List of SRV Labels Figure 5: List of SRV Labels
Just like NAPTR records, the lookup and subsequent follow-up of SRV Just like NAPTR records, the lookup and subsequent follow-up of SRV
records may yield more than one server to contact in a prioritised records may yield more than one server to contact in a prioritised
list. [RFC2782] does not specify rules regarding "Definition of list. [RFC2782] does not specify rules regarding "Definition of
Conditions for Retry/Failure", nor "Server Identification and Conditions for Retry/Failure", nor "Server Identification and
Handshake". This specification defines that the rules for these two Handshake". This specification defines that the rules for these two
topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be
used both for targets retrieved via an initial NAPTR RR as well as used both for targets retrieved via an initial NAPTR RR as well as
for targets retrieved via an initial SRV RR (i.e. in the absence of for targets retrieved via an initial SRV RR (i.e. in the absence of
NAPTR RRs). NAPTR RRs).
skipping to change at page 12, line 40 skipping to change at page 15, line 26
| foo.example | foo.example | YES | | foo.example | foo.example | YES |
| foo.example | *.example | YES | | foo.example | *.example | YES |
| bar.foo.example | *.example | NO | | bar.foo.example | *.example | NO |
| bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) |
| bar.foo.example | bar.*.example | NO (NAIRealm invalid) | | bar.foo.example | bar.*.example | NO (NAIRealm invalid) |
| bar.foo.example | *.*.example | NO (NAIRealm invalid) | | bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) |
| sub.bar.foo.example | *.bar.foo.example | YES | | sub.bar.foo.example | *.bar.foo.example | YES |
+-----------------+-----------------------------------------------+ +-----------------+-----------------------------------------------+
Figure 4: Examples for NAI realm vs. certificate matching Figure 6: Examples for NAI realm vs. certificate matching
Appendix A contains the ASN.1 definition of the above objects. Appendix A contains the ASN.1 definition of the above objects.
3. DNS-based NAPTR/SRV Peer Discovery 3. DNS-based NAPTR/SRV Peer Discovery
3.1. Applicability 3.1. Applicability
Dynamic server discovery as defined in this document is only Dynamic server discovery as defined in this document is only
applicable for new AAA transactions and per service (i.e. distinct applicable for new AAA transactions and per service (i.e. distinct
discovery is needed for Authentication, Accounting, and Dynamic discovery is needed for Authentication, Accounting, and Dynamic
skipping to change at page 17, line 10 skipping to change at page 19, line 46
Terminate (see next section for a rationale). If no, O is the Terminate (see next section for a rationale). If no, O is the
result of dynamic discovery. Terminate. result of dynamic discovery. Terminate.
20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate. 20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate.
3.4.4. Validity of results 3.4.4. Validity of results
The dynamic discovery algorithm is used by servers which do not have The dynamic discovery algorithm is used by servers which do not have
sufficient configuration information to process an incoming request sufficient configuration information to process an incoming request
on their own. If the discovery algorithm result contains the on their own. If the discovery algorithm result contains the
server's own listening address (IP address and port), then this will server's own listening address (IP address and port), then there is a
either lead to a tight loop (if that DNS entry has topmost priority, potential for an endless forwarding loop. If the listening address
the server would forward the request to itself, triggering dynamic is the DNS result with the highest priorty, the server will enter a
discovery again in a perpetual loop), or lead to a potential loop tight loop (the server would forward the request to itself,
with intermediate hops in between (the server could forward to triggering dynamic discovery again in a perpetual loop). If the
another host with a higher priority, which might use DNS itself and address has a lower priority in the set of results, there is a
forward the packet back to the first server). The underlying reason potential loop with intermediate hops in between (the server could
that enables these loops is that the server executing the discovery forward to another host with a higher priority, which might use DNS
algorithm is seriously misconfigured in that it does not recognise itself and forward the packet back to the first server). The
the request as one that is to be processed by itself. RADIUS has no underlying reason that enables these loops is that the server
built-in loop detection, so any such loops would remain undetected. executing the discovery algorithm is seriously misconfigured in that
So, if step 18 of the algorithm discovers such a possible-loop it does not recognise the request as one that is to be processed by
situation, the algorithm should be aborted and an error logged. Note itself. RADIUS has no built-in loop detection, so any such loops
that this safeguard does not provide perfect protection against would remain undetected. So, if step 18 of the algorithm discovers
routing loops: other reasons include the possiblity that a subsequent such a possible-loop situation, the algorithm should be aborted and
hop has a statically configured next-hop which leads to an earlier an error logged. Note that this safeguard does not provide perfect
host in the loop; or the algorithm execution was executed with greedy protection against routing loops. One reason which might introduce a
result evaluation, and the own address was in a lower-priority branch loop include the possiblity that a subsequent hop has a statically
of the result set which was not retrieved from DNS at all. configured next-hop which leads to an earlier host in the loop.
Another reason for occuring loops is if the algorithm was executed
with greedy result evaluation, and the own address was in a lower-
priority branch of the result set which was not retrieved from DNS at
all, and thus can't be detected.
After executing the above algorithm, the RADIUS server establishes a After executing the above algorithm, the RADIUS server establishes a
connection to a home server from the result set. This connection can connection to a home server from the result set. This connection can
potentially remain open for an indefinite amount of time. This potentially remain open for an indefinite amount of time. This
conflicts with the possibility of changing device and network conflicts with the possibility of changing device and network
configurations on the receiving end. Typically, TTL values for configurations on the receiving end. Typically, TTL values for
records in the name resolution system are used to indicate how long records in the name resolution system are used to indicate how long
it is safe to rely on the results of the name resolution. If these it is safe to rely on the results of the name resolution. If these
TTLs are very low, thrashing of connections becomes possible; the TTLs are very low, thrashing of connections becomes possible; the
Effective TTL mitigates that risk. When a connection is open and the Effective TTL mitigates that risk. When a connection is open and the
skipping to change at page 18, line 17 skipping to change at page 21, line 9
The host's name resolution library may need to contact outside The host's name resolution library may need to contact outside
entities to perform the name resolution (e.g. authoritative name entities to perform the name resolution (e.g. authoritative name
servers for a domain), and since the NAI discovery algorithm is based servers for a domain), and since the NAI discovery algorithm is based
on uncontrollable user input, the destination of the lookups is out on uncontrollable user input, the destination of the lookups is out
of control of the server that performs NAI discovery. If such of control of the server that performs NAI discovery. If such
outside entities are misconfigured or unreachable, the algorithm outside entities are misconfigured or unreachable, the algorithm
above may need an unacceptably long time to terminate. Many RADIUS above may need an unacceptably long time to terminate. Many RADIUS
implementations time out after five seconds of delay between Request implementations time out after five seconds of delay between Request
and Response. It is not useful to wait until the host name and Response. It is not useful to wait until the host name
resolution library signals a timeout of its name resolution resolution library signals a timeout of its name resolution
algorithms. The algorithm therefore control execution time with algorithms. The algorithm therefore controls execution time with
TIMER. Execution of the NAI discovery algorithm SHOULD be non- TIMER. Execution of the NAI discovery algorithm SHOULD be non-
blocking (i.e. allow other requests to be processed in parallel to blocking (i.e. allow other requests to be processed in parallel to
the execution of the algorithm). the execution of the algorithm).
3.4.6. Example 3.4.6. Example
Assume Assume
a user from the Technical University of Munich, Germany, has a a user from the Technical University of Munich, Germany, has a
RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example".
skipping to change at page 26, line 21 skipping to change at page 29, line 14
[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
"Transport Layer Security (TLS) Encryption for RADIUS", "Transport Layer Security (TLS) Encryption for RADIUS",
RFC 6614, May 2012. RFC 6614, May 2012.
[RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a [RFC7360] DeKok, A., "Datagram Transport Layer Security (DTLS) as a
Transport Layer for RADIUS", RFC 7360, September 2014. Transport Layer for RADIUS", RFC 7360, September 2014.
[I-D.ietf-radext-nai] [I-D.ietf-radext-nai]
DeKok, A., "The Network Access Identifier", draft-ietf- DeKok, A., "The Network Access Identifier", draft-ietf-
radext-nai-08 (work in progress), September 2014. radext-nai-15 (work in progress), December 2014.
8.2. Informative References 8.2. Informative References
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, March 2005. Wireless LANs", RFC 4017, March 2005.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
skipping to change at page 28, line 19 skipping to change at page 31, line 19
6, rue Richard Coudenhove-Kalergi 6, rue Richard Coudenhove-Kalergi
Luxembourg 1359 Luxembourg 1359
LUXEMBOURG LUXEMBOURG
Phone: +352 424409 1 Phone: +352 424409 1
Fax: +352 422473 Fax: +352 422473
EMail: stefan.winter@restena.lu EMail: stefan.winter@restena.lu
URI: http://www.restena.lu. URI: http://www.restena.lu.
Mike McCauley Mike McCauley
Open Systems Consultants AirSpayce Pty Ltd
9 Bulbul Place 9 Bulbul Place
Currumbin Waters QLD 4223 Currumbin Waters QLD 4223
AUSTRALIA AUSTRALIA
Phone: +61 7 5598 7474 Phone: +61 7 5598 7474
Fax: +61 7 5598 7070 EMail: mikem@airspayce.com
EMail: mikem@open.com.au URI: http://www.airspayce.com
URI: http://www.open.com.au.
 End of changes. 21 change blocks. 
68 lines changed or deleted 169 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/