Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery
Stefan Winter <stefan.winter@restena.lu> Wed, 24 July 2013 10:07 UTC
Return-Path: <stefan.winter@restena.lu>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB6511E83F4 for <radext@ietfa.amsl.com>; Wed, 24 Jul 2013 03:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFZQb3X5OW8F for <radext@ietfa.amsl.com>; Wed, 24 Jul 2013 03:07:03 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 6DEAC11E83AF for <radext@ietf.org>; Wed, 24 Jul 2013 03:06:43 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 2848410590 for <radext@ietf.org>; Wed, 24 Jul 2013 12:06:42 +0200 (CEST)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 19A861058C for <radext@ietf.org>; Wed, 24 Jul 2013 12:06:42 +0200 (CEST)
Message-ID: <51EFA72E.9050507@restena.lu>
Date: Wed, 24 Jul 2013 12:06:38 +0200
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: radext@ietf.org
References: <88ACDECA21EE5B438CA26316163BC14C25D334A9@BASS.ad.clarku.edu> <51DD5683.3070202@restena.lu> <51DE5730.4080008@deployingradius.com> <51E545A6.6040008@restena.lu> <51E54C2E.80002@deployingradius.com>
In-Reply-To: <51E54C2E.80002@deployingradius.com>
X-Enigmail-Version: 1.5.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="fwKQRj0qIhmm3goi57LCE70DGpgtWlvbT"
X-Virus-Scanned: ClamAV
Subject: Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguarding draft-ietf-radext-dynamic-discovery
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.12
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, 24 Jul 2013 10:07:04 -0000
Hi, > It may also be good to add a "Global-Packet-ID". The idea would be > that it's a 64-bit or 128-bit opaque token, created by the client. (Or > a proxy close to the client). Other proxies would then never touch it. > > It could be cached by proxies for a period of time. If a proxy sees > the same Global-Packet-ID in two different packets, it knows there's a > loop or retransmission via an alternate path. That's another approach, which would also work. There's a very small probability that two unrelated packets happen to get the same packet-id; that kind of indeterminism makes me a bit nervous. Anyway: I'm glad that we're discussing loop detection /at all/. I didn't get that far in my earlier attempts on the topic :-) Re the forward/reverse IP: > What about the discovered server? It would be subject to attacks by > third parties. > > i.e. realm A lists proxy B as it's server via DDNS. It then publishes > an article saying "free net access by using user@realmA". Everyone > wanting free net access contacts proxy B. Repeat for 10,000 domains, > and Proxy B gets a DoS. > > This should ideally be discovered *before* a using high-cost > connection like TLS. That's why a reverse lookup is useful. > > Now... this is RADIUS, and there aren't that many RADIUS proxies. But > if the DDNS draft makes it easier, there will be more RADIUS proxies, > and more possibility for such an attack. That doesn't really help: the forward and reverse IP checks work on the A/AAAA pair that is the "leaf" of the discovery process. Third parties adding a NAPTR where they should not will not be detected. If the end server is actually offering a dynamic discovery endpoint, then it will be properly configured for its legimiate customers. Having other people send non-legitimate customers to the same destination as well will not be detectable with an IP address check. >> This could be mentioned in Security Considerations, if you find it >> useful/important to have? > > Yes. The fact that DoS becomes possible by illegitimate clients is mentioned in RFC6614. I take your point that a mere usage of RFC6614 with hand-configured clients makes the problem less important, because firewalls could prevent the session establishment. For a next rev of dynamicdiscovery, I've added the following paragraph for Security Considerations in my working copy: With Dynamic Discovery being enabled for a RADIUS Server, and depending on the deployment scenario, the server may need to open up its target IP address and port for the entire internet, because arbitrary clients may discover it as a target for their authentication requests. If such clients are not part of the roaming consortium, the RADIUS/TLS connection setup phase will fail (which is intended) but the computational cost for the connection attempt is significant. With the port for a TLS-based service open, the RADIUS server shares all the typical attack vectors for services based on TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with Dynamic Discovery should consider these attack vectors and take appropriate counter-measures (e.g. blacklisting known-bad IPs on a firewall, rate-limiting new connection attempts, etc.). Is that okay for you? 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
- [radext] Fwd: Mail reguarding draft-ietf-radext-d… Stefan Winter
- [radext] Fwd: Re: Mail reguarding draft-ietf-rade… Stefan Winter
- [radext] Fwd: RE: Mail reguarding draft-ietf-rade… Stefan Winter
- Re: [radext] Fwd: RE: Mail reguarding draft-ietf-… Stefan Winter
- [radext] Fwd: RE: Fwd: RE: Mail reguarding draft-… Stefan Winter
- Re: [radext] Fwd: RE: Fwd: RE: Mail reguarding dr… Stefan Winter
- [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail reguardi… Stefan Winter
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Alan DeKok
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Stefan Winter
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Alan DeKok
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Stefan Winter
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Alan DeKok
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Stefan Winter
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Stefan Winter
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Sam Hartman
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Alan DeKok
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Alan DeKok
- Re: [radext] Fwd: RE: Fwd: RE: Fwd: RE: Mail regu… Stefan Winter