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

From: Alejandro Perez Mendez <[email-masked]>
Date: Thu, 24 Jan 2013 10:53:01 +0100

Hello,

we have uploaded a new version of our RADIUS fragmentation draft. This 
version introduces some relevant changes:

  * Improved description of fragmentation of Access-Accept packets.
  * Use of Additional-Authorization service type instead of Authorize-Only
  * Improved description of CHUNK size calculation.
  * New section describing how to deal with Proxy-State attributes,
    including the mechanism used by the RADIUS client to discover the
    amount of space required for them along the path (also includes the
    description of a new RADIUS Attribute for that purpose).
  * Improved description of the management of State attributes.
  * New section about the interaction with RADIUS-EAP.
  * New section describing in detail how to rebuild a received
    fragmented packet.

Regards,
Alejandro

-------- Mensaje original --------
Asunto: 	New Version Notification for 
draft-perez-radext-radius-fragmentation-04.txt
Fecha: 	Thu, 24 Jan 2013 01:49:03 -0800
De: 	[email-masked]
Para: 	[email-masked]
CC: 	[email-masked], [email-masked], [email-masked], 
[email-masked], [email-masked]

A new version of I-D, draft-perez-radext-radius-fragmentation-04.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 04
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-01-24
WG ID:		 Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-04.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-04
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-04

Abstract:
    This document describes a mechanism providing fragmentation support
    of RADIUS packets that exceed the 4 KB limit.

The IETF Secretariat

---

From: Sam Hartman <[email-masked]>
Date: Thu, 24 Jan 2013 10:40:27 -0500

This sounds great.
What's the state within radext?
I know it's now chartered; how can we help get this adopted?

---

From: Alan DeKok <[email-masked]>
Date: Thu, 24 Jan 2013 10:50:49 -0500

> I know it's now chartered; how can we help get this adopted?

  Pipe up in radext.  It's on the RADEXT charter now.  So we'll need
reviewers, and a call for WG adoption.

  Alan DeKok.

---

From: "Diego R. Lopez" <[email-masked]>
Date: Thu, 24 Jan 2013 23:37:24 +0000

> reviewers, and a call for WG adoption.
At the last RADEXT meeting the call for reviewers was made, two reviewers
identified (Alex has contacted them once the latest version was available)
so WG adoption should be close.

BTW, the implementation of a PoC is finished and we are discussing how
to make a demo of it anytime soon (sorry for the spoiler, you UMU guys)

Be goode,

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
-----------------------------------------

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 29 Jan 2013 17:05:19 +0100

Dear all,

we have received additional comments from Yoshihiro Ohba (many thanks) that we share with you. 

Please, see some comments inline.

"Here is my review of draft-perez-radext-radius-fragmentation-04.

Section 1:

"Each RADIUS packet can transport several RADIUS attributes, to convey
the necessary information to the other peer, up to a maximum size of 4
KB of total data (including RADIUS packet headers)."

[YO] I suggest to replace "4 KB" with "4096 bytes" throughout the
document since "KB" can mean 4000 bytes in some cases.

[Rafa] OK.

"A reference-based mechanism is also proposed in [RFC6158], where
attributes can be obtained through an out-of-band protocol."

[YO} Meaning of this sentence is unclear. Does this mean RADIUS
attributes are obtained through some other protocol instead of RADIUS?
Or does this mean the actual format of the Value field of a RADIUS
Attribute is defined in other protocol specification? In the latter
case, it should be also mentioned that RADIUS-EAP is categorized as the
mechanism defined in RFC 6158.

[Rafa] It is referring the value of the attributes can be obtained by other protocol instead of RADIUS. This is coming from a previous comment related with SAML transport. Instead of transporting the real SAML messages an URL is set as attribute value. We can try to clarify a little bit more.

"However, there are no proposals to deal with fragmentation at a packet
level, when the total size exceeds the 4 KB limit imposed by the RADIUS
specification."

[YO] Meaning of "at a packet level" is unclear. Suggested change:
"However, there are no proposals to fragement a large-sized RADIUS
packet into multiple small-sized RADIUS packets, where the length of the
original (unfragmented) RADIUS packet exceeds the 4096-octet limit
imposed by the RADIUS specification."

[Rafa] This sounds good.

Section 2:

[YO] I am not sure if "T" flag is needed. In other words, it should be
possible to change [I-D.ietf-radext-radius-extensions] to simply allow a
fragment with the M-flag cleared not to be included in a non-last chunk.

[Rafa] 

Yes, that may be possible. It is worth noting that we wanted to keep unmodified any existing I-D by the time being. Moreover, [I-D.ietf-radext-radius-extensions] has not considered that fragmentation at packet level may occur for obvious reasons. Moreover, that I-D is in a mature state now.

In any case, we may ask authors of [I-D.ietf-radext-radius-extensions].

Section 3.3:

[YO] Access-Accept fragmentation scheme looks odd compared to
Access-Request and Access-Challenge fragmentation schemes. There are
several questions related to this: (1) Why multiple chunks of
Access-Accept cannot be sent without having an Access-Challange to be
sent in between? (2) Why an Access-Accept cannot contain a
More-Data-Pending attribute instead of using a new service type value?
(3) How can a large attributue that is allowed to appear in an
Access-Accept but not allowed to appear in Access-Challenge be fragmented?

[Rafa]

1) We wanted to be symmetric in the design, where Access-Request/Access-Challenge exchange is used somehow for fragmentation support. In any case, we have also considered the usage of Access-Accept with Service-Type[AddAuth] so until all the attributes in the whole RADIUS Access-Accept are finally sent the exchange will be Access-Request/Access-Accept (Service-Type[AddAuth]), while the last one is simply Access-Request/Access-Accept. This mode of operation would solve your question 3).

2) I think that may be also possible. In any case, I think Alan or Alex can elaborate a little bit a more about the usage of Service-Type[AddAuth].

3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think?  

Section 8:

[YO] Security Considerations section is too short. Security mechansims
that are needed for secure operation of the proposed fragmentation
mechanism needs to be described in this section.

[Rafa] Yes this section will be improved. Jim also raised comments about it.

Section 9:

[YO] I don't think the following statement is true: "This document has
no actions for IANA." because Section 6 defines new attributes.

[Rafa] Correct. This needs to be fixed.

Best Regards,
Yoshihiro Ohba
"

Best regards.

-------------------------------------------------------
Rafael Marin Lopez, PhD
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: [email-masked]
-------------------------------------------------------

---

From: Alejandro Perez Mendez <[email-masked]>
Date: Wed, 30 Jan 2013 09:37:15 +0100

Hello Yoshi, Rafa,

> 3) Precisely, trying to answer this question we just came up with the solution in 1). What do you think?

This alternative sounds good to me. However, I think there may be still 
some advantages of using Service-Type instead of (or in addition to) 
More-Data-Pending for Access-Accept packets.

If the NAS/RP does not know anything about fragmentation (i.e. does not 
support this draft), it may take the first Access-Accept chunk, ignore 
the More-Data-Pending attribute (it is unknown for it), and process it 
as a complete packet. As no additional round-trip is mandatory after an 
Access-Accept packet, it may be problematic as it is possible that part 
of the obligations from the AS to the NAS (e.g. FW policies) are not 
enforced.

However, RFC 2865 says that (in relation to Access-Accept packets):

    A NAS is not
           required to implement all of these service types, and MUST treat
           unknown or unsupported Service-Types as though an Access-Reject
           had been received instead

Therefore, if the NAS does not understand 
Service-Type=AdditionalAuthorization, the Access-Accept packet will be 
interpreted as an Access-Reject one, which seems to be the most 
reasonable approach.

This sort of problems seem to not be critical with Access-Challenge 
packets, as the NAS is expected to generate a new Access-Request packet 
afterwards, and the AS can detect whether fragmentation was supported.

Regards,
Alejandro

> _______________________________________________
> radext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/radext