Re: Bang-path routing

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> Yes, there are a large number of issues in RFC 4282, particularly Section
> 2.4:

  Ok.  I'll take a look at writing up some comments on the document.

>    o  Normalization requirements, as specified in Section 2.2 of
>       [RFC4013], are also designed to assist in comparisons.
> 
> [BA] This assumes that the NAI is being entered by a user, rather than
> being automatically configured, which is often the case.  Why should
> normalization be required for an automatically configured NAI? 

  Perhaps normal form when multiple encodings are possible?  RFC 5198
defines a "normalization form NFC", which could apply here.

> [BA] It seems that the set of prohibited characters should be the same
> within IDNAbis as within a realm that is also an FQDN.  However, this
> statement ensures that they will be different since RFC 4013 and IDNAbis
> are not in sync. Why not just cite IDNAbis?

  Ok... is there a draft with ABNF for internationalized domain names,
*before* the punycode encoding?  The closest I've found is email
internationalization (RFC5234), which is "experimental".

> [BA] IDNAbis does not require end systems to do this kind of
> checking, because presumably these checks are done when the user name
> and realm is created in the first place.  If the user name/realm was
> never created on the AAA server, then presumably the name also can't
> be used on the client, so periodic compliance checks are unnecessary. 

  I agree.

> Can't we just say that the realm is required to be registerable as an 
> FQDN, and that registry and IDNAbis restrictions must be obeyed? This
> would leave sufficient flexibility for registry-specific restrictions. 

  That might be simplest.

>    The realm name is an "IDN-unaware domain name slot" as defined in
>    [RFC3490].  That is, it can contain only ASCII characters.  An
>    implementation MAY support Internationalized Domain Names (IDNs)
>    using the ToASCII operation; see [RFC3490] for more information.
> 
> [BA] Given that EAP and RADIUS specifications specifically mandate 
> UTF-8 usage, this appears wrong.  

  I think it's referring to the punycode version of the realm.  In which
case I'm left wondering where the ABNF is for the *non* punycode version
of the realm.

>    The responsibility for the conversion of internationalized domain
>    names to ASCII is left for the end systems, such as network access
>    clients and AAA servers.  Similarly, we expect domain name
>    comparisons, matching, resolution, and AAA routing to be performed on
>    the ASCII versions of the internationalized domain names.  This
>    provides a canonical representation, ensures that intermediate
>    systems such as AAA proxies do not need to perform translations, and
>    can be expected to work through systems that are unaware of
>    international character sets.

  This is completely and totally wrong, for a host of reasons.  For one,
no one does this.  (AAA implementors or roaming providers).  For two,
systems that are unaware of international character sets need only to
*route* on the realm name.  They don't need to *interpret* it, or to
*print* it.  As a result, simple checks for equality are good enough.
i.e. "is the realm in this packet identical to the realm an
administrator preconfigured?"

> [BA] A more sensible approach would be to require conversion of UTF-8
> to punycode as specified in IDNAbis.  

  Only when the realm name is used to perform DNS lookups.  In that
case, the DNS resolving library will Do the Right Thing.  Within the AAA
system, the realm MUST be left as UTF-8.

  Alan DeKok.

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