Re: [radext] Review comments for draft-ietf-radext-dynamic-discovery-08

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5A4C71A0180 for <>; Fri, 14 Feb 2014 00:01:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RP_MATCHES_RCVD=-0.548, WEIRD_PORT=0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id het5Ori8i2xc for <>; Fri, 14 Feb 2014 00:01:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E5FDF1A01BD for <>; Fri, 14 Feb 2014 00:01:29 -0800 (PST)
Received: from ( [IPv6:2001:a18:1::34]) by (Postfix) with ESMTP id 4D960600050F3; Fri, 14 Feb 2014 09:01:28 +0100 (CET)
Received: from (localhost []) by (Postfix) with ESMTP id 37FA81690F5; Fri, 14 Feb 2014 09:01:28 +0100 (CET)
Received: from viper.local (unknown []) by (Postfix) with ESMTPSA id 2C7A11690F4; Fri, 14 Feb 2014 09:01:28 +0100 (CET)
Message-ID: <>
Date: Thu, 13 Feb 2014 18:26:47 +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: Jim Schaad <>,
References: <00dd01cef1eb$45fc8a30$d1f59e90$> <> <018301cf05c1$a2f50f70$e8df2e50$>
In-Reply-To: <018301cf05c1$a2f50f70$e8df2e50$>
X-Enigmail-Version: 1.6
OpenPGP: id=8A39DC66
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="K4Q6g0KAOlF1R8HlAPImvKSFneRFnFPXG"
X-Virus-Scanned: ClamAV
Subject: Re: [radext] Review comments for draft-ietf-radext-dynamic-discovery-08
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:36 -0000


> > I guess we should take another close look at the *exact* bytes of
> this ASN.1 definition after the next rev...
> The process of getting OIDs assigned is being changed.  I will create a new
> module and IANA section to deal with this and send it to you by the end of
> the week.

Which week was that? ;-)

>>> 12.  Section 3.1 - Not sure that I understand the reasoning for item b.
>> Routing of DynAuth packets is asynchronous to that of authentication
>> requests; and the DynAuth Server which can handle DynAuth packets could
>> be different from the authentication server in that domain.
>> So, both need to be configurable and be discovered independently. They
>> both take an input in form of a domain name though, so by using two
>> different service tags, they can both use the same algorithm to discover
> their
>> respective targets:
>> a) to discover RADIUS servers which can authenticate users
>> b) to discover DynAuth servers for a domain which can receive DynAuth
>> packets to alter user sessions.
>> Should I maybe reference RFC5176 for clarity regarding b) ? I do in the
> service
>> tag table, but a little more verbosity here may not hurt. Please let me
> know.
> It would seem to me that this should then be the case of accounting as well.
> It might be better to say that it needs to be unique for each service and
> then state that new conversations would be needed for each service.  Is
> DynAuth always a single round trip?

I have added a sentence about the "for each service", and added
Accounting as an item in its own right.

To my knowledge, DynAuth is always just one round-trip, yes.

Of course authorization for a session might change multiple times during
the session lifetime; and arguably only the first packet should need
dynamic discovery - the DynAuth client could memorize the discovery
result for subsequent authorization changes.

I've added a note to that effect as well.

>>> 13.  In Section 3.4.3  step 13 - should the 'or' be 'and/or' as it
>>> would seem that one could do a lookup for both _tcp and _udp if
>>> desired.  An input or output to the algorithm may need to be if udp or
>>> tcp is the desired mechanism to use.  (I don't see a comparable
>>> selection in the NAPTR
>>> processing.)
>> Yes; it's a non-exclusive OR. It depends on the capabilities of the RADIUS
>> client which executes the algorithm... if it only implements TCP/TLS, it
> would
>> only query for _tcp; if it supports both, it could try both labels (which
> one it
>> prefers is out of scope though).
>> NAPTR doesn't need this decision point - the NAPTR RR authoritatively
> tells
>> the querying entity which variant to try in which order.
> That makes sense.  However the question does arise if the mechanism then
> needs to be an output.
> tuples {hostname; port; protocol; order/preference; Effective TTL}

Good point: I've added "protocol" as one element of the output tuple in -10.

>>> 14.  In section 4 paragraph 1/2 - It is not clear to me if these
>>> paragraphs are saying that DNS is required.  If this is not the case
>>> then you should be more explicit about what being trusted means for an
>>> output.  From the "even if" sentence it would appear nothing.
>> DNS - trust neither the resulting IP/port nor infer authorisation DNSSEC -
>> trust the IP/port, but still don't inter authorisation
>> (So, use DNSSEC or not, you still have to do extra work afterwards)
>> Actually, the section would read more clearly if I'd simply remove the
> first
>> para - it's redundant because the first sentence of para 2 says it all.
>> I've removed the first para, does this clear up the ambiguity?
> Yes that does make it better
>>> 15.  In section 5 - I am having a problem with the fact that you are
>>> saying that big clearing houses are no longer a problem.  On the
>>> mailing list you have explicitly stated that this is still a standard
>>> configuration that will exist.  It is also going to be unknown to
>>> either the user and to operators if a clearing house is being used.
>> I don't think I'm saying that they are not a problem any more. The section
>> states that discovery can technically make them obsolete if the operators
> in a
>> consortium really want that.
>> There may be reasons unrelated to discovery which make them not want
>> that. That's a pity, but nothing this draft can help with (and the second
> bullet
>> makes clear that proxies are likely to remain in existence).
>> Packet inspection by all kinds of intermediates is big topic these days,
> and I'm
>> all for eliminating such snooping points. The TLS part does its share, IP
> nodes
>> can't read stuff any more; the discovery part can do its part by taking
> away 0
>> or more intermediate RADIUS proxies.
>> This doesn't solve all problems in the space; including that the existence
> of a
>> proxy or not is not known to the end user. It also doesn't tehcnically
>> eliminate the possibility to deploy proxies at all.
>> If you are looking for that, we're talking of a different draft (but that
> is such a
>> complex problem that I have no idea what to write into that one ;-) )
> I still find this paragraph somewhat confusing.  How about:
> This protocol allows for RADIUS clients to identify and directly connect to
> the RADIUS home server.  This can eliminate the use of clearinghouses to do
> forwarding of requests, it also eliminates the ability of the clearinghouse
> to then aggregate the user information that flows through it.  However,
> there exist reasons why clearinghouses might still be used.  One reason to
> keep a clearinghouse is to act as a gateway for multiple backends in a
> company.

Ok, if that's clearer, fine :-) I've replaced my paragraph with your

> - I would rather talk about your issue in Eduroam as the reason as that is
> probably more interesting, but I don't remember the details anymore.

One big reason to have an intermediate system is for sanitisation of
requests. With that I mean: filter out "dangerous" attribues (e.g. a
VLAN assignment attribute sent from an IdP very likely does not make
sense in a roaming scenario - of course we expect IdPs to exercise
hygiene themselves and not send those attributes, but mistakes do
happen) or adding tagging attributes (e.g. if the SP did not indicate
it's real-world name in Operator-Name, its next-hop proxy can do that
for him (again, of course SPs should do this themselves, but not
everyone can be bothered to).

I've added a half sentence in the end of that para to give a hint that
filtering and tagging are useful things a proxy may have to do.

Another round of thanks for this subsequent review. This certainly makes
the document better!


> Jim
>> And this concludes my actions on your review. Phew!
>> I'm planning to publish a roundup -09 on Friday. If you have comments
>> before that, I'll try to get them in, if not, it's either a -10 or maybe
> IETF LC (as I
>> hope we are now nearing zero bugs :-) ).
>> 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
>> 6
> _______________________________________________
> radext mailing list