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

From: Alejandro Perez Mendez <[email-masked]>
Date: Fri, 07 Mar 2014 08:55:02 +0100

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.  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: 	[email-masked]
Para: 	Alejandro Perez-Mendez <[email-masked]>, "Alejandro Perez-Mendez"
<[email-masked]>, Diego R. Lopez <[email-masked]>, "Alan DeKok"
<[email-masked]>, Alan DeKok <[email-masked]>, "Rafael
Lopez" <[email-masked]>, "Gabriel Lopez-Millan" <[email-masked]>, Gabriel
Lopez-Millan <[email-masked]>, Fernando Pereniguez-Garcia
<[email-masked]>, Rafa Marin-Lopez <[email-masked]>, "Diego R. Lopez"
<[email-masked]>, "Fernando Pereniguez-Garcia" <[email-masked]>

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

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 18 Mar 2014 11:24:40 +0800

<chair mumble..>

Folks,

Are you now happy with the note added into the draft? 

- Jouni 

On Mar 7, 2014, at 3:55 PM, Alejandro Perez Mendez <[email-masked]> wrote:

> 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
> Asunto:	New Version Notification for draft-ietf-radext-radius-fragmentation-05.txt
> Para:	Alejandro Perez-Mendez <[email-masked]>, "Alejandro Perez-Mendez" <[email-masked]>, Diego R. Lopez <[email-masked]>, "Alan DeKok" <[email-masked]>, Alan DeKok <[email-masked]>, "Rafael Lopez" <[email-masked]>, "Gabriel Lopez-Millan" <[email-masked]>, Gabriel Lopez-Millan <[email-masked]>, Fernando Pereniguez-Garcia <[email-masked]>, Rafa Marin-Lopez <[email-masked]>, "Diego R. Lopez" <[email-masked]>, "Fernando Pereniguez-Garcia" <[email-masked]>
> 
> 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:
> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext

---

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Mar 2014 11:21:42 +0100

Hi,
>     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"

Regards, Benoit
> Once this document goes
> <[email-masked]>, Alan DeKok <[email-masked]>, 
> "Rafael Lopez" <[email-masked]>, "Gabriel Lopez-Millan" <[email-masked]>, 
> Gabriel Lopez-Millan <[email-masked]>, Fernando Pereniguez-Garcia 
> 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:

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Tue, 18 Mar 2014 12:06:00 +0100

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

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 18 Mar 2014 09:27:46 -0400

>    preclude them to support future extensions. 

  Perhaps this (word-smithing)

The authors acknowledge that this specification violates the "MUST"
requirement of [RFC2865] Section 4.1.  We note that a proxy which
enforces that requirement would be unable to support future RADIUS
authentication extensions.  Extensions to the protocol would therefore
be impossible to deploy.

All known implementations have chosen the philosophy of "be liberal in
what you accept".  That is, they accept traffic which violates the
requirement of [RFC2865] Section 4.1.  We therefore expect to see no
operational issues with this specification.  After we gain more
operational experience with this specification, it can be re-issued as a
standards track document, and update [RFC2865].

  Alan DeKok.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 18 Mar 2014 19:50:21 +0100

> standards track document, and update [RFC2865].
To answer Alejandro's question here: If the WG is fine with this, I'm fine.

Regards, Benoit

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 19 Mar 2014 11:07:16 +0100

> standards track document, and update [RFC2865].

Thanks for the improved text. I will use it.