Issue: 2486bis internationalization and ! syntax

[Jari Arkko <jari.arkko@piuha.net>]

Issue 4 is about the interaction between internationzalition
an the ! transformation within NAIs. Basically you may change

    user@homerealm.example.net

to

    homerealm.example.net!user@otherrealm.example.net

and back, under certain exceptional AAA routing conditions,
i.e., when the local network can route/roam your request back
to the right place.

Now, what makes this interesting is that the usernamepart is
in UTF-8 and realmpart is an IDN in ASCII. Here there are
multiple resolutions of the issue.

#1: This transformation is an exceptional case where proxies
will perform some mapping from one character set to another.

Where such transformations are done, an attempt
to transform a string that can't be mapped to IDN (e.g. illegal
DNS name) should result in an error. From the user's point
of view this would be a similar error as you get when the domain
you are trying to give is unknown. Correct use of the this
transformation should not result in this error, given that the
string you put in from the '!' should have originally been a
realm name.

One drawback of this is that in order for the proxy to map UTF-8
to ASCII, it needs to understand the codepoints. This means in
practise that a proxy with a today's codepoint data is unable to
do the transformation for something that uses a newer codepoint.
New codepoints are often defined but my understanding is that
they are for quite special and small languages. Given this and
the exceptional nature of the ! usage this may be acceptable.

#2: Realmpart needs to be converted to IDNA if and when a DNS
query needs to be sent.  However, only  Diameter defines how DNS
queries can be used to locate AAA servers; RADIUS  implementations
do not support this.

It has been suggested that in order to "optimize for the common case" that
the entire string could be left in UTF-8, obviating the need for 
conversions
between UTF-8 and IDNA until a DNS query needed to be sent.  Since
RADIUS implementations do not send such queries, they would not need to
do the conversion at all.  Within a Diameter agent,  the conversion
could be delayed until it is required, at which time it might
conceivably fail.

One problem with this is that existing nde that does the
query would be unable to do a UTF-8 query but would be
able to do an IDN query. Oh well, there isn't much Diameter
usage that would be hit with this...

And there seems to be another more serious problem. Namely, even
if RADIUS doesn't do DNS queries, it still stores and compares
strings. If someone has already put in a rule or entry for an
international DNS name, he has  been able to do so already in
RFC 2486, because IDNs are really legal DNS names. And he
likely didn't use UTF-8, because that would have been illegal
as a NAI. Now, if we suddenly start sending the IDNs as UTF-8
instead, this will break existing usage. All that is needed for
this scenario to apply is someone who (a) has an international
DNS name and (b) has a RADIUS server. What's the likelihood
of this?

My conclusion: problems in approach #2 seem more likely
to appear in common cases, so my preference is #1. What
do others think?

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