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

From: Jouni Korhonen <[email-masked]>
Date: Tue, 14 Jan 2014 10:46:43 +0200

The WGLC ended recently for this document. Zero reviews or comments.
If folks think the document is ready, at least express that on the
list. I'll extend the WGLC by few weeks shortly.

In a meanwhile I have requested reviews from various externals
interest groups (secdir, DNS ppl etc).

- Jouni & Mauricio

On Dec 30, 2013, at 7:00 AM, Jouni Korhonen <[email-masked]> wrote:

> Folks,
> 
> This email starts a two week WGLC for the
> draft-ietf-radext-dynamic-discovery-09.
> The WGLC ends 13th Jan 2014.
> 
> Please, review the document, submit your
> comments to the mailing list and also enter
> them into Issue Tracker.
> 
> - Jouni & Mauricio
> 
>

---

From: Stefan Winter <[email-masked]>
Date: Tue, 14 Jan 2014 14:28:05 +0100

Hi,

> list. I'll extend the WGLC by few weeks shortly.

FWIW, I like the document and think it should be allowed to move ahead :-)

Jim posted two comments to the document within hours of your WGLC
announcement (30 and 31 dec 2013). I'll work on those in the coming days.

> interest groups (secdir, DNS ppl etc).

Ah, thanks. I'm sure I'll get more beating from those guys then :-)

Stefan

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext
> 

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

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

---

From: <[email-masked]>
Date: Tue, 14 Jan 2014 13:43:02 +0000

Hi Stefan, Jouni,

I'm ok with the general content of this draft.
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? 

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

In Section 3.1. Applicability

   Dynamic server discovery as defined in this document is only
   applicable for AAA transactions where a RADIUS entity which acts as a
   forwarding server for one or more realms receives a request with a
   realm for which it is not authoritative, and which no explicit next
   hop is configured.  It is only applicable for

   a.  new user sessions, i.e. for the initial Access-Request.
       Subsequent messages concerning this session, for example Access-
       Challenges and Access-Accepts use the previously-established
       communication channel between client and server.

   b.  RADIUS DynAuth server discovery

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

Regards,

Lionel

-----Message d'origine-----
De : radext [mailto:[email-masked]] De la part de Jouni Korhonen
Envoyé : mardi 14 janvier 2014 09:47
À : [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09

- Jouni & Mauricio

_________________________________________________________________________________________________________________________

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.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 14 Jan 2014 15:15:15 +0100

Hi,

>    This specification defines three S-NAPTR service tags:

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

Tel: +352 424409 1
Fax: +352 422473

---

From: <[email-masked]>
Date: Tue, 14 Jan 2014 16:59:38 +0000

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:[email-masked]] 
Envoyé : mardi 14 janvier 2014 15:15
À : MORAND Lionel IMT/OLN; Jouni Korhonen; [email-masked]
Cc : [email-masked]; [email-masked]
Objet : Re: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09

Hi,

>    This specification defines three S-NAPTR service tags:

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

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

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

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: +352 424409 1
Fax: +352 422473

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

---

From: Stefan Winter <[email-masked]>
Date: Wed, 15 Jan 2014 09:51:37 +0100

Hi,

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

Ah, now I see that in RFC6408. I didn't at first glance because the ABNF
exclusively defines aaa+ap<int>.

The raw "aaa" sneaks in later. I don't understand what it is trying to
achieve (it is associated with "legacy" Diameter nodes which do not
support RFC6408; but if they don't support RFC6408 then they are not
going to use that tag; it's just as new as the aaa+apx ones - the
original NAPTR tags in RFC3588 were only "AAA+D2S" and "AAA+D2T"). ??
RFC6733 finally does the "right" thing and mentions "aaa" as the service
tag, but that's still not going to help implementations which only do
RFC3588.

Anyway... that's not my business :-)

Still no syntax problem, as the string "aaa" is still only a prefix of
the strings used in the radext draft.

I agree that an innocent reader might get a bit startled by the
similarity. In most cases, the service tag will be immediately followed
by the desired protocol though, which spells out "radius" or "diameter"
in clear-text. That should make the matter clear to the human eye.

Only in the case where a Diameter node uses no protocol indication
(Section 5.2.e of RFC6408) then he sees a raw "aaa" indeed; but there's
still no ambiguity: the radext draft has a mandatory protocol
indication; a raw "aaa" can thus not have anything to do with RADIUS.

I notice now, however, that the protocol tags are not sufficiently
covered in the actual algorithm; the server needs to maintain state
which transport it got from DNS so that he can later connect either via
DTLS or TLS. I will make that clearer in the next rev.

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

Prioritisation is done by NAPTR's and SRV's order/preference fields and
is in the discretion of the server operator. If the server operator of
the "auth+acct" server wants clients to talk to that one with priority
for both auth and acct, he will list this server with the same, highest
preference in DNS for both service tags.

It's not the client's decision to resort to a lower-priority server just
because it feels like it.

And as an extra thought: if multiple servers share the same priority,
and only one of them could also do accounting, then the RADIUS client
could still find out about it by evaluating the list of NAPTRs for
aaa+auth and aaa+acct simultaneously, and seeing that they have the same
replacement field content. He can then make an informed choice.

FWIW, I would be against adding this extra choice into the I-D text. It
is a very small corner case, and the algorithm is about finding an
output for a given input. It's not about being clever to find a common
output for two distinct inputs, which might by chance be identical (but
this could only be found out later). Extending the scope to cover that
would make things a bit blurry.

Greetings,

Stefan Winter

Tel: +352 424409 1
Fax: +352 422473