IETF Logo Mail Archive

Re: [Int-area] DCHP-based authentication for DSL?

<Bernard_Aboba@hotmail.com> Thu, 25 October 2007 19:41 UTC

Return-path: <int-area-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8ac-000743-OS; Thu, 25 Oct 2007 15:41:58 -0400
Received: from int-area by megatron.ietf.org with local (Exim 4.43) id 1Il8ab-00073o-0O for int-area-confirm+ok@megatron.ietf.org; Thu, 25 Oct 2007 15:41:57 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Il8aa-00073Y-Gh for int-area@lists.ietf.org; Thu, 25 Oct 2007 15:41:56 -0400
Received: from bay0-omc2-s3.bay0.hotmail.com ([65.54.246.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Il8aU-0002U4-AS for int-area@lists.ietf.org; Thu, 25 Oct 2007 15:41:56 -0400
Received: from BAY117-DS2 ([207.46.8.29]) by bay0-omc2-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Oct 2007 12:41:37 -0700
X-Originating-IP: [131.107.0.74]
X-Originating-Email: [bernard_aboba@hotmail.com]
Message-ID: <BAY117-DS213B42206C26BC7FD3B7A93950@phx.gbl>
From: Bernard_Aboba@hotmail.com
In-Reply-To: <005501c81555$6f49f360$ba3dfea9@ad.redback.com> <471F0F26.4070006@uninett.no> <471FACDD.3000707@cisco.com> <C087AF58-A3DF-40CC-9AB2-BE30E3657A00@cisco.com><471FB475.3020409@cisco.com> <472046D9.5030903@nitros9.org>
To: Alan DeKok <aland@nitros9.org>, ric@cisco.com
References: <005501c81555$6f49f360$ba3dfea9@ad.redback.com> <471F0F26.4070006@uninett.no> <471FACDD.3000707@cisco.com> <C087AF58-A3DF-40CC-9AB2-BE30E3657A00@cisco.com><471FB475.3020409@cisco.com> <472046D9.5030903@nitros9.org>
Subject: Re: [Int-area] DCHP-based authentication for DSL?
Date: Thu, 25 Oct 2007 12:41:37 -0700
X-Unsent: 1
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 12.0.1365
X-MimeOLE: Produced By Microsoft MimeOLE V12.0.1365
X-OriginalArrivalTime: 25 Oct 2007 19:41:37.0564 (UTC) FILETIME=[0E9D7DC0:01C8173F]
X-Spam-Score: 1.7 (+)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: Internet Area <int-area@lists.ietf.org>
X-BeenThere: int-area@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/int-area>
List-Post: <mailto:int-area@lists.ietf.org>
List-Help: <mailto:int-area-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@lists.ietf.org?subject=subscribe>
Errors-To: int-area-bounces@lists.ietf.org

The problem is that some EAP methods (e.g. most non-TLS based methods) don't 
support fragmentation, so in practice I'm not sure that all existing methods 
would work over a 500 octet MTU.

--------------------------------------------------
From: "Alan DeKok" <aland@nitros9.org>
Sent: Thursday, October 25, 2007 12:33 AM
To: <ric@cisco.com>
Cc: "Internet Area" <int-area@lists.ietf.org>
Subject: Re: [Int-area] DCHP-based authentication for DSL?

> Richard Pruss wrote:
>> The fragmentation size problem may be addressed by the relay agent
>> having the role of EAP authenticator, as it splits the EAP traffic into
>> RADIUS out of DHCP, and DHCP messages should be normally sized to the
>> server.
>
>  RADIUS packets are maximum 4k in size, so RADIUS wouldn't be the
> limiting factor.  What is the limiting factor is EAPoL, where packets
> can't be fragmented.  Most RADIUS servers already look for a MTU in the
> Access-Request, and limit the size of EAP responses on their end, so
> that the EAP data will fit into one Ethernet packet.
>
>  My tests on various implementations show that RADIUS servers and
> 802.1x supplicants appear to work with MTUs set very low, such as 100
> octets.  The result is a LOT more RADIUS traffic than normal, but the
> authentication process succeeds.
>
>  So limiting the DHCP packet sizes to 500 octets shouldn't affect the
> operation EAP.  Similar issues apply to PANA, where there is IP and UDP
> overhead on top of what would otherwise be EAPoL.
>
>  Alan DeKok.
>
>
> _______________________________________________
> Int-area mailing list
> Int-area@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/int-area
> 


_______________________________________________
Int-area mailing list
Int-area@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area

v2.23.0 | Report a Bug | By Email