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 14:57 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 5F53D21F8468 for <radext@ietfa.amsl.com>; Wed, 24 Jul 2013 07:57:02 -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 8a-g+d+2-MqS for <radext@ietfa.amsl.com>; Wed, 24 Jul 2013 07:57:01 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3333921F841B for <radext@ietf.org>; Wed, 24 Jul 2013 07:56:59 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 3964C10590 for <radext@ietf.org>; Wed, 24 Jul 2013 16:56:58 +0200 (CEST)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2981C1058C for <radext@ietf.org>; Wed, 24 Jul 2013 16:56:57 +0200 (CEST)
Message-ID: <51EFEB39.4060102@restena.lu>
Date: Wed, 24 Jul 2013 16:56:57 +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="uCEfWf9VDnjWO0mSBaqeTc8Ju18ohvKAN"
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 14:57:57 -0000

Hi,

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

It also just occured to me that your attack is too complex to be useful
for an attacker; it would require actual humans lured into trying to log
into realmA in masses, so that their login attempts overload proxy B. It
would require hundreds or thousands of humans trying to log in per
second so that proxy B feels the load.

If realmA really wants to DoS proxy B, they would take note of proxy B's
IP address and port, and hire a cheap botnet. The botnet would simply
not care whether there is a reverse IP to check.

In short... once your server is up in the open, it can be contacted by
anyone, like it or not. An implementation needs to cope with that.

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