Re: [radext] Client ID exhaustion

Enke Chen <enkechen@cisco.com> Wed, 26 April 2017 19:17 UTC

Return-Path: <enkechen@cisco.com>
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 443531289C3 for <radext@ietfa.amsl.com>; Wed, 26 Apr 2017 12:17:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.523
X-Spam-Level:
X-Spam-Status: No, score=-14.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 3yeZ3N8Ugu7u for <radext@ietfa.amsl.com>; Wed, 26 Apr 2017 12:17:04 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DD301293F4 for <radext@ietf.org>; Wed, 26 Apr 2017 12:17:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1897; q=dns/txt; s=iport; t=1493234223; x=1494443823; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=GVKhaCGaIQ2Dpr+/sU9bkd24GsD/3bvsy8YaR3VeS28=; b=TmqoDsWUJHwd/BngAIVtl76xEavfI1NiPwR7YxCXFbG6Ye67oX9e0L+/ n+fO8a3XG2ZjjnySX4qfhmzDrfV3PKcTVRp//oocrNsRcw0fohcZrNodR YPvAgp3yz+L1RXX0nOH9T5cKMMhCoBOek81H4XliZhE4akingO8wxD7+w 0=;
X-IronPort-AV: E=Sophos;i="5.37,255,1488844800"; d="scan'208";a="416396742"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Apr 2017 19:17:02 +0000
Received: from [10.82.220.141] (rtp-vpn3-1160.cisco.com [10.82.220.141]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3QJH2SA001343; Wed, 26 Apr 2017 19:17:02 GMT
To: radext@ietf.org
References: <f521cd74-028d-33e7-4b94-0a9d65bd7d37@restena.lu>
Cc: Enke Chen <enkechen@cisco.com>
From: Enke Chen <enkechen@cisco.com>
Message-ID: <e4c8aee2-c97f-e89e-8b48-6c943651238f@cisco.com>
Date: Wed, 26 Apr 2017 12:17:01 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <f521cd74-028d-33e7-4b94-0a9d65bd7d37@restena.lu>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/RuSqr1KrHTOCG1d7mquwz39NDIo>
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: Wed, 26 Apr 2017 19:17:05 -0000

Hi, Stefan:

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.

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
>