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

Stefan Winter <> Fri, 14 February 2014 08:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 745361A01B7 for <>; Fri, 14 Feb 2014 00:01:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.798
X-Spam-Status: No, score=-0.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-0.548] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d-hXAqdJ-WK7 for <>; Fri, 14 Feb 2014 00:01:36 -0800 (PST)
Received: from ( [IPv6:2001:a18:1::51]) by (Postfix) with ESMTP id B989E1A01C3 for <>; Fri, 14 Feb 2014 00:01:30 -0800 (PST)
Received: from ( [IPv6:2001:a18:1::34]) by (Postfix) with ESMTP id AA4AD600050F5; Fri, 14 Feb 2014 09:01:28 +0100 (CET)
Received: from (localhost []) by (Postfix) with ESMTP id 95DA11690F5; Fri, 14 Feb 2014 09:01:28 +0100 (CET)
Received: from viper.local (unknown []) by (Postfix) with ESMTPSA id 854B11690F4; Fri, 14 Feb 2014 09:01:28 +0100 (CET)
Message-ID: <>
Date: Thu, 13 Feb 2014 18:31:27 +0100
From: Stefan Winter <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To:, Jouni Korhonen <>, "" <>
References: <> <> <11892_1389706983_52D53EE7_11892_12055_1_6B7134B31289DC4FAF731D844122B36E43D683@PEXCVZYM13.corporate.adroot.infra.ftgroup> <> <22239_1389718780_52D56CFC_22239_11701_1_6B7134B31289DC4FAF731D844122B36E43DBB2@PEXCVZYM13.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
OpenPGP: id=8A39DC66
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="domTmBxmaaHar5DqxB9JhaOikdIQtAQwO"
X-Virus-Scanned: ClamAV
Cc: "" <>, "" <>
Subject: Re: [radext] WGLC for draft-ietf-radext-dynamic-discovery-09
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Feb 2014 08:01:38 -0000


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

Fixed for -10.



>> 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
> _______________________________________________
> radext mailing list