Subject: Re: [radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery

From: Stefan Winter <[email-masked]>
Date: Fri, 18 Jan 2013 13:01:11 +0100

Hi,

>  Currently the internationalization advice provided in Section 2.3.1
>  appears to differ from that provided in RFC 4282bis, creating potentially
>  unpredictable interactions.
> 
>     Dynamic server discovery as defined in this document is only
>     applicable for AAA transactions where a RADIUS server receives a
>     request with a realm for which no home RADIUS server is known.
> 
>  [BA] Does this paragraph really apply to RADIUS servers and not proxies?
>  Typically a server will only check the realm and see if it represents a
>  realm it is serving; if not an error is flagged.  Asking RADIUS servers
>  (not proxies) to route for realms for which they are not authoritative
>  seems dangerous.

That's right; the text should rather state "RADIUS proxies".

Is it worth forging the text a bit more fine-grained to take into
account that there are RADIUS entities which are both RADIUS server for
a certain realm, and RADIUS proxy for others?

In eduroam, this is quite common: a RADIUS server is authoritative for
realm foo.xy, but may receive requests from any other realm; in which
case it is *not* supposed to flag an error as you state above, but
instead trigger discovery (or in absence of a corresponding DNS entry
send to a known "DEFAULT" proxy).

The wording would then be a bit more difficult/clumsy. Like:

     Dynamic server discovery as defined in this document is only
     applicable for AAA transactions where a RADIUS entity which acts
     as a proxy for one or more realms receives a request with a realm
     for which it is not authoritative.

>  Also, the meaning of "no home RADIUS server is known" is not clear.

This was supposed to mean: there is no entry in the realm routing table
for the specific realm encountered in the User-Name. Does the "is not
authoritative" wording fix this for you?

>  According to RFC 4282bis, only bit-by-bit comparisons are supported in the
>  AAA infrastructure.  As a result, were a client to not provide a
>  normalized realm, the resulting failure of the  comparison would trigger
>  use of dynamic server discovery.  Is this what is intended??

Yes; an authoritative server should list its own realm in its
configuration in all the variants it expects.

If an unexpected variant comes along, dynamic discovery is triggered. I
guess it is worth expanding the "loop prevention" advice from section
2.3.1 to cover this as well: if dynamic discovery is triggered because
of an unknown variant of the same realm, and dynamic discovery points
towards the proxy/server itself, the proxy should note that and not
enter dynamic discovery *again* to prevent a loop.

Thinking of it, it would algorithmically probably be best to add a new
final step of the algorithm: instead of terminating after step 7 or 14,
test the output set O whether it contains an IP/port combination on
which the proxy itself is listening; if yes, terminate with an error and
set O = { }.

>  Section 2.3.1
> 
>     Note well: The attribute User-Name is defined to contain UTF-8 text.
>     In practice, the content may or may not be UTF-8.  Even if UTF-8, it
>     may or may not map to a domain name in the realm part. Implementors
>     MUST take possible conversion error paths into consideration when
>     parsing incoming User-Name attributes.
> 
>  [BA] This would appear to contradict RFC 4282bis requirements for realm
>  normalization and realm correspondence to a legal FQDN.

As noted in another thread: 4282bis can state whatever it likes, but the
content of User-Name is constructed by end-users by typing something
into their keyboard (or similar). There is no guarantee that the
incoming value is in any way valid.

The text in 2.3.1 just makes implementers aware of that fact.

> Although Section
>  2.2 does mention conversion to punycode, the exact steps to be performed
>  are not described:
> 
>     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 RADIUS server.

Hm. I don't know how to word this in a better way than hand-waving. Can
I just reference a section of an RFC? If yes, which?

What I intended to say was: assume a RADIUS server is authoritative for
the realm "tu-münchen.example". The DNS label in section 2.2 would then
be _radiustls._tcp.xn--tu-mnchen-t9a.example.

So, it's about getting from "tu-münchen.example" to
"xn--tu-mnchen-t9a.example". I'm sure the Internationalised DNS RFCs
have a deterministic way of getting there?

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

---

From: Stefan Winter <[email-masked]>
Date: Fri, 18 Jan 2013 13:22:47 +0100

Hi again,

> have a deterministic way of getting there?

I'm looking at RFC5891 now. Would referencing Section 5 of that RFC be
enough? The text would then be:

    It is expected that in most cases, the label used for the records is
    the DNS A-label representation of the literal realm name for
    which the server is the authoritative RADIUS server (i.e. the realm
    name after conversion according to section 5 of [RFC5891]).

Would that do?

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473

---

From: Sam Hartman <[email-masked]>
Date: Fri, 18 Jan 2013 15:14:20 -0500

>>>>> "Stefan" == Stefan Winter <[email-masked]> writes:

    Stefan> Hi again,
    Stefan>     It is expected that in most cases, the label used for
    Stefan> the records is the DNS A-label representation of the literal
    Stefan> realm name for which the server is the authoritative RADIUS
    Stefan> server (i.e. the realm name after conversion according to
    Stefan> section 5 of [RFC5891]).

I think that's good.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 18 Jan 2013 12:45:01 -0800

It makes sense to say that Dynamic Discovery will utilize an A-label representation in retrieving RRs from DNS. 

But we do need to be clear about what is expected in the User-Name attribute (e.g. U-labels, not A-labels). 

> From: [email-masked]
> To: [email-masked]
> Date: Fri, 18 Jan 2013 15:14:20 -0500
> CC: [email-masked]
> Subject: Re: [radext] #147: Internationalization and	draft-ietf-radext-dynamic-discovery
> 
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext