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

[<[e-mail]>]

Hi Stefan,

Thank you for our quick feedback. Please see below.
To sum-up, I can agree with your answer. Not a strong issue. But... as you know me, please see below :)

Regards,

Lionel

-----Message d'origine-----
De : Stefan Winter [mailto:[e-mail]] 
Envoyé : mardi 14 janvier 2014 15:15
À : MORAND Lionel IMT/OLN; Jouni Korhonen; [e-mail]
Cc : [e-mail]; [e-mail]
Objet : Re: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09

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 was just referring to the following in RFC6408: 

   IANA has reserved a value of "aaa" for Diameter in the "(S-NAPTR)
   Application Service Tag" registry created by [RFC3958].

It is not a problem of syntax (which is correct as I said) but more a question of the ambiguity around the prefix "aaa" for the (human) reader.

> [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 issue is slightly different for Diameter applications. In 3GPP, different applications usually point to different functional entities or multiple capabilities are grouped into the same application when used between the same entities. In the specific case of RADIUS, I was thinking that one could prefer to choose an Authentication server that supports also accounting when both functions are required, especially when you have to open TLS/DTLS connections with the remote server. This server might be prioritized among servers auth-only + servers acc-only. 

> [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.

[LM] Good.

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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.