Re: [radext] Fwd: New Version Notification for draft-ietf-radext-radius-fragmentation-05.txt

Alejandro Perez Mendez <alex@um.es> Tue, 18 March 2014 11:06 UTC

Return-Path: <alex@um.es>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519751A03CB for <radext@ietfa.amsl.com>; Tue, 18 Mar 2014 04:06:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level:
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham
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 ogyr_7lB8vcX for <radext@ietfa.amsl.com>; Tue, 18 Mar 2014 04:06:14 -0700 (PDT)
Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 8E71E1A03C9 for <radext@ietf.org>; Tue, 18 Mar 2014 04:06:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 8B26E4214 for <radext@ietf.org>; Tue, 18 Mar 2014 12:06:02 +0100 (CET)
X-Virus-Scanned: by antispam in UMU at xenon23.um.es
Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Q7Lov9u0E2m9 for <radext@ietf.org>; Tue, 18 Mar 2014 12:06:02 +0100 (CET)
Received: from [10.42.0.19] (84.124.131.72.dyn.user.ono.com [84.124.131.72]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 38BA7D36 for <radext@ietf.org>; Tue, 18 Mar 2014 12:06:01 +0100 (CET)
Message-ID: <53282898.9050504@um.es>
Date: Tue, 18 Mar 2014 12:06:00 +0100
From: Alejandro Perez Mendez <alex@um.es>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: radext@ietf.org
References: <20140307075126.8756.14600.idtracker@ietfa.amsl.com> <53197B56.10303@um.es> <53281E36.2020708@cisco.com>
In-Reply-To: <53281E36.2020708@cisco.com>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------090904090107080906060705"
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/XkL7Hs7zlHWr7k1X9cqhyTvbmVI
Subject: Re: [radext] Fwd: New Version Notification for draft-ietf-radext-radius-fragmentation-05.txt
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 18 Mar 2014 11:06:18 -0000

El 18/03/14 11:21, Benoit Claise escribió:
> Hi,
>> As agreed during last RADEXT meeting on Tuesday, we've submitted a
>> new version (05) of the draft, where we have added the following
>> text, related to the no-inclusion of authentication attributes in the
>> first fragment of the pre-authentication phase:
>>
>> The
>>    authors acknowledge this is formally violating [RFC2865], but there
>>    are no known operational issues with it.  
> because ... ? I believe it deserves a little bit more information.
>
> My meeting minutes tells me: because all implementations don't do this
> "An Access-request MUST contain either a User-Password or a
> CHAP-passwork or a State"

Hi Benoit,

we could extend that line to something like:

The
   authors acknowledge this is formally violating [RFC2865], but no
   operational issues are expected as no known implementation 
   perform that verification when proxying Access-Requests, since doing so would
   preclude them to support future extensions. 

Would it do it for you?

Regards,
Alejandro

>
> Regards, Benoit
>> Once this document goes
>>    beyond being considered as experimental, it will state it updates
>>    [RFC2865].
>> Regards,
>> Alejandro
>>
>>
>>
>> -------- Mensaje original --------
>> Asunto: 	New Version Notification for
>> draft-ietf-radext-radius-fragmentation-05.txt
>> Fecha: 	Thu, 06 Mar 2014 23:51:26 -0800
>> De: 	internet-drafts@ietf.org
>> Para: 	Alejandro Perez-Mendez <alex@um.es>, "Alejandro Perez-Mendez"
>> <alex@um.es>, Diego R. Lopez <diego@tid.es>, "Alan DeKok"
>> <aland@networkradius.com>, Alan DeKok <aland@networkradius.com>,
>> "Rafael Lopez" <rafa@um.es>, "Gabriel Lopez-Millan" <gabilm@um.es>,
>> Gabriel Lopez-Millan <gabilm@um.es>, Fernando Pereniguez-Garcia
>> <pereniguez@um.es>, Rafa Marin-Lopez <rafa@um.es>, "Diego R. Lopez"
>> <diego@tid.es>, "Fernando Pereniguez-Garcia" <pereniguez@um.es>
>>
>>
>>
>> A new version of I-D, draft-ietf-radext-radius-fragmentation-05.txt
>> has been successfully submitted by Alejandro Perez-Mendez and posted to the
>> IETF repository.
>>
>> Name:		draft-ietf-radext-radius-fragmentation
>> Revision:	05
>> Title:		Support of fragmentation of RADIUS packets
>> Document date:	2014-03-07
>> Group:		radext
>> Pages:		28
>> URL:            http://www.ietf.org/internet-drafts/draft-ietf-radext-radius-fragmentation-05.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/
>> Htmlized:       http://tools.ietf.org/html/draft-ietf-radext-radius-fragmentation-05
>> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-fragmentation-05
>>
>> Abstract:
>>    The Remote Authentication Dial-In User Service (RADIUS) protocol is
>>    limited to a total packet size of 4096 octets.  Provisions exist for
>>    fragmenting large amounts of authentication data across multiple
>>    packets, via Access-Challenge.  No similar provisions exist for
>>    fragmenting large amounts of authorization data.  This document
>>    specifies how existing RADIUS mechanisms can be leveraged to provide
>>    that functionality.  These mechanisms are largely compatible with
>>    existing implementations, and are designed to be invisible to
>>    proxies, and "fail-safe" to legacy clients and servers.
>>
>>                                                                                   
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>>
>>
>> _______________________________________________
>> radext mailing list
>> radext@ietf.org
>> https://www.ietf.org/mailman/listinfo/radext
>
>
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext