Re: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09

[Stefan Winter <[e-mail]>]

Hi,

> But, just after a brief review of the last version, I have the following comments/questions.
> 
> In Section 2.1.1.1. Registration of Application Service and Protocol Tags
> 
> 
>    This specification defines three S-NAPTR service tags:
> 
> 
>    +-----------------+-----------------------------------------+
>    | Service Tag     | Use                                     |
>    +-----------------+-----------------------------------------+
>    | aaa+auth        | RADIUS Authentication, i.e. traffic as  |
>    |                 | defined in [RFC2865]                    |
>    | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
>    | aaa+acct        | RADIUS Accounting, i.e. traffic as      |
>    |                 | defined in [RFC2866]                    |
>    | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - |
>    | aaa+dynauth     | RADIUS Dynamic Authorisation, i.e.      |
>    |                 | traffic as defined in [RFC5176]         |
>    +--------------- --+-----------------------------------------+
> 
>                       Figure 1: List of Service Tags
> 
> [LM] For historical reasons, "aaa" is already assigned to Diameter. The proposed values for RADIUS related Application Service Tags are not wrong per se but it could be misleading... What about using "RADIUS+" instead of "aaa+" to avoid such possible confusion? 

We developed the RADIUS spec in sync with the Diameter equivalent, and
this was the way forward everybody agreed to.

There are multiple things to consider in this:

* IANA assignments of a service tag are NOT sensitive to a "+"
separator; the entire thing is a string of bytes. It either literally
matches the service you are looking for or not. In that light, two
different strings which by chance have the first four characters in
common does not mean they have anything to do with each other.

* There is no possibility for a naming clash between Diameter's
aaa+ap<int> and RADIUS aaa+{auth,acct,dynauth}.

* The protocol tag which follows the service tag in the DNS NAPTR record
makes clear that we're talking RADIUS, not Diameter.

* I don't think "aaa" as a whole is owned by Diameter anyway... Even in
the Diameter spec, there is a protocol tag for Diameter following the
service tag. Both in combination make the NAPTR type "owned" by
Diameter. And the old RFC3588 definition uses the monolithic "aaa+D2x"
string (where x varies, and the D hard-codes Diameter).

> [LM] I don't know if it is something commonly in use but I was wondering if it would be also suitable to define a service tag for Auth+Acc when both types of traffic are sent to the same server. 

It may or may not be that both types of traffic end up at the same
server. If they do, adding a second NAPTR for Accounting doesn't add
much overhead. I would be concerned about this if there were "hundreds"
of NAPTR records per domain to evaluate, and economising on their number
was important. I didn't ever encounter this in reality though.

Looking sideways, not even the Diameter S-NAPTR spec allows to
concatenate multiple application IDs into one service tag, so... if you
guys haven't found a use case for it in 3G big-scale, I don't think it's
necessary or urgent?

> [LM] I think that the case for initial Accounting-Request is missing. Sorry if this point was discussed earlier on the mailing list.

It may well have been, I don't remember it though. :-)

You are right; where the NAS has a User-Name for its Accounting record,
it would need to discover a destination using the algorithm, so this
should be reflected in an added bullet. I'll do this for the next
revision update.

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: [phone]
Fax: [phone]

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66