IETF Logo Mail Archive

RE: [AAA-DOCTORS] [Dime] FEDAUTH BOF request

Peter Deacon <peterd@iea-software.com> Mon, 07 June 2010 17:17 UTC

Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B6E28C445 for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Mon, 7 Jun 2010 10:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.247
X-Spam-Level:
X-Spam-Status: No, score=-0.247 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32rVDNVH02dc for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Mon, 7 Jun 2010 10:17:49 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 896893A9037 for <radext-archive-IeZ9sae2@lists.ietf.org>; Sun, 6 Jun 2010 14:09:07 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1OLN1T-0002gC-Cs for radiusext-data0@psg.com; Sun, 06 Jun 2010 21:04:47 +0000
Received: from [70.89.142.196] (helo=aspen.internal.iea-software.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <peterd@iea-software.com>) id 1OLN1Q-0002fq-DI for radiusext@ops.ietf.org; Sun, 06 Jun 2010 21:04:44 +0000
Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id <B0005291726@aspen.internal.iea-software.com>; Sun, 6 Jun 2010 14:04:42 -0700
Date: Sun, 06 Jun 2010 14:04:39 -0700
From: Peter Deacon <peterd@iea-software.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
cc: 'Alper Yegin' <alper.yegin@yegin.org>, tena@huawei.com, aaa-doctors@ietf.org, radiusext@ops.ietf.org, dime@ietf.org, dromasca@avaya.com
Subject: RE: [AAA-DOCTORS] [Dime] FEDAUTH BOF request
In-Reply-To: <BLU137-DS5162535EAE6642C60FB4893D40@phx.gbl>
Message-ID: <alpine.WNT.2.00.1006061319410.1732@SMURF>
References: <EDC652A26FB23C4EB6384A4584434A04022444EC@307622ANEX5.global.avaya.com>, <F3CA54ABFDD5489FAFE036ECB6EE0011@china.huawei.com> <BLU137-W24E56D43201C0B9EEB3A4A93D10@phx.gbl> <019f01cb03b7$e63fcaf0$b2bf60d0$@yegin@yegin.org> <BLU137-DS5162535EAE6642C60FB4893D40@phx.gbl>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>

On Sun, 6 Jun 2010, Bernard Aboba wrote:

> Previous tests have shown problems with use of RADIUS/EAP over UDP in
> federated scenarios:

> http://www.cesnet.cz/doc/techzpravy/2008/eduroam-authentication-over-jammed-
> network/

> As noted in the above paper, once packet loss is introduced, completing the
> multiple roundtrips of EAP authentication becomes increasingly difficult.

This paper has some crazy figures.. look at the data for packet loss.

40% packet loss (client to server) = 78% success rate for PEAP-MSCHAPv2
40% packet loss (server to client) = 20% success rate for PEAP-MSCHAPv2

There is a footnote on this issue "The more favorable results for 
client-to-server jamming are caused by the aggressive packet re-sending 
strategy of wpa_supplicant compared to the behavior of Radiator."

If the server did not receive client request or client did not receive 
server response the knowledge available and avenue for response by the 
client is the same in either case.  The figures appear to reflect a 
substantial implementation artifact in the servers tx side retransmit.

regards,
Peter

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

v2.23.0 | Report a Bug | By Email