Re: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09
Stefan Winter <stefan.winter@restena.lu> Wed, 15 January 2014 08:51 UTC
Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06821AE2E5 for <radext@ietfa.amsl.com>; Wed, 15 Jan 2014 00:51:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level:
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.538, WEIRD_PORT=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVYIx3a8a2Ta for <radext@ietfa.amsl.com>; Wed, 15 Jan 2014 00:51:54 -0800 (PST)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 5770F1AE223 for <radext@ietf.org>; Wed, 15 Jan 2014 00:51:54 -0800 (PST)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id F25D71058E; Wed, 15 Jan 2014 09:51:41 +0100 (CET)
Received: from [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7] (unknown [IPv6:2001:a18:1:8:921b:eff:fe1b:d2e7]) by smtprelay.restena.lu (Postfix) with ESMTPS id E5C461058A; Wed, 15 Jan 2014 09:51:41 +0100 (CET)
Message-ID: <52D64C19.90703@restena.lu>
Date: Wed, 15 Jan 2014 09:51:37 +0100
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: lionel.morand@orange.com, Jouni Korhonen <jouni.nospam@gmail.com>, "radext@ietf.org" <radext@ietf.org>
References: <15BCB5AD-55A0-4C74-B9BB-67448122EFF6@gmail.com> <23ABE552-71C9-4231-82B0-0D1861C922CB@gmail.com> <11892_1389706983_52D53EE7_11892_12055_1_6B7134B31289DC4FAF731D844122B36E43D683@PEXCVZYM13.corporate.adroot.infra.ftgroup> <52D54673.9000600@restena.lu> <22239_1389718780_52D56CFC_22239_11701_1_6B7134B31289DC4FAF731D844122B36E43DBB2@PEXCVZYM13.corporate.adroot.infra.ftgroup>
In-Reply-To: <22239_1389718780_52D56CFC_22239_11701_1_6B7134B31289DC4FAF731D844122B36E43DBB2@PEXCVZYM13.corporate.adroot.infra.ftgroup>
X-Enigmail-Version: 1.6
OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="PdoPOCTBHUC3g2SJNbbImXl2GIw0gFVul"
X-Virus-Scanned: ClamAV
Cc: "radext-chairs@tools.ietf.org" <radext-chairs@tools.ietf.org>, "draft-ietf-radext-dynamic-discovery@tools.ietf.org" <draft-ietf-radext-dynamic-discovery@tools.ietf.org>
Subject: Re: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2014 08:51:57 -0000
Hi, > * 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. 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. > 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. 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 -- 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
- [radext] WGLC for draft-ietf-radext-dynamic-disco… Jouni Korhonen
- Re: [radext] WGLC for draft-ietf-radext-dynamic-d… Jouni Korhonen
- Re: [radext] WGLC for draft-ietf-radext-dynamic-d… Stefan Winter
- Re: [radext] WGLC for draft-ietf-radext-dynamic-d… lionel.morand
- Re: [radext] WGLC for draft-ietf-radext-dynamic-d… Stefan Winter
- Re: [radext] WGLC for draft-ietf-radext-dynamic-d… lionel.morand
- Re: [radext] WGLC for draft-ietf-radext-dynamic-d… Stefan Winter
- Re: [radext] WGLC for draft-ietf-radext-dynamic-d… lionel.morand
- Re: [radext] WGLC for draft-ietf-radext-dynamic-d… Stefan Winter
- Re: [radext] WGLC for draft-ietf-radext-dynamic-d… Stefan Winter