Re: [radext] Client ID exhaustion
Stefan Winter <stefan.winter@restena.lu> Thu, 27 April 2017 09:00 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 4B5DE128656 for <radext@ietfa.amsl.com>; Thu, 27 Apr 2017 02:00:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no
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 qUORy6aLkIum for <radext@ietfa.amsl.com>; Thu, 27 Apr 2017 02:00:45 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 849361273E2 for <radext@ietf.org>; Thu, 27 Apr 2017 02:00:45 -0700 (PDT)
Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9E3844397C for <radext@ietf.org>; Thu, 27 Apr 2017 11:00:43 +0200 (CEST)
To: radext@ietf.org
References: <f521cd74-028d-33e7-4b94-0a9d65bd7d37@restena.lu> <e4c8aee2-c97f-e89e-8b48-6c943651238f@cisco.com>
From: Stefan Winter <stefan.winter@restena.lu>
Openpgp: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66
Message-ID: <fe4e2daa-21f8-66f6-83b5-19245f1e4564@restena.lu>
Date: Thu, 27 Apr 2017 11:00:43 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <e4c8aee2-c97f-e89e-8b48-6c943651238f@cisco.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="aRGRIDFxiQe6B2ln8F2sH5Hu33KGXboxp"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/TNVwxNTVOhsWPF7pm3JOjhdaqmk>
Subject: Re: [radext] Client ID exhaustion
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 27 Apr 2017 09:00:47 -0000
Hello, > The case we have is with the wireless controller that needs to manage > thousands of APs and tens of thousands of clients. The wireless world > uses "centralized" management model. The scaling requirements keep > increasing every year. > > Though RADIUS is an old protocol, it is a critical piece in the wireless > world. Your reply did not indicate whether the wireless controller implements the MAY in RFC2865 (a piece of information I specifically asked for). Does it? Greetings, Stefan Winter > > Thanks. -- Enke > > On 4/26/17 5:43 AM, Stefan Winter wrote: >> Hello, >> >> >> we keep hearing assertions on the list that change is needed regarding >> the ID field in RADIUS. >> >> >> I would like to recall RFC2865's section 2.5 >> >> >> "If a >> >> NAS needs more than 256 IDs for outstanding requests, it MAY use >> additional source ports to send requests from, and keep track of IDs >> for each source port. This allows up to 16 million or so outstanding >> requests at one time to a single server." >> >> >> It's fairly clear that implementations which do not follow the MAY will >> run into exhaustion problems rather soon. >> >> It's less clear that implementations which do follow this MAY still do. >> We've heard finger-in-the-air calculations on the list that this may >> become a problem earlier than one might think. But is there actual >> evidence to that end in deployed reality? >> >> Can someone please share their experience regarding a deployment and >> implementation which DOES implement the MAY above but STILL runs out of >> RADIUS packet IDs? >> >> Obviously, for those implementors which do not implement the MAY, the >> suggestion would be to implement that before trying to make protocol >> changes. The corresponding advice in RFC2865 may be 17 years old now, >> but that doesn't mean it is not good advice. >> >> Greetings, >> >> Stefan Winter >> >> >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette 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] Client ID exhaustion Stefan Winter
- Re: [radext] Client ID exhaustion Alan DeKok
- Re: [radext] Client ID exhaustion Enke Chen
- Re: [radext] Client ID exhaustion Stefan Winter
- Re: [radext] Client ID exhaustion Alan DeKok
- Re: [radext] Client ID exhaustion Ignacio Goyret
- Re: [radext] Client ID exhaustion Enke Chen
- Re: [radext] Client ID exhaustion Alan DeKok