Re: [radext] #178 (radius-fragmentation): fragments going in both directions - allowed or not?

"radext issue tracker" <> Mon, 30 June 2014 09:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6EEF31A01AC for <>; Mon, 30 Jun 2014 02:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jk2shFHrlNNJ for <>; Mon, 30 Jun 2014 02:03:24 -0700 (PDT)
Received: from ( [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 287091A01A7 for <>; Mon, 30 Jun 2014 02:03:24 -0700 (PDT)
Received: from localhost ([::1]:45440 by with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <>) id 1X1XUd-0001m3-CM; Mon, 30 Jun 2014 02:03:19 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" <>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
X-Trac-Project: radext
Date: Mon, 30 Jun 2014 09:03:19 -0000
Message-ID: <>
References: <>
X-Trac-Ticket-ID: 178
In-Reply-To: <>
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
Subject: Re: [radext] #178 (radius-fragmentation): fragments going in both directions - allowed or not?
X-Mailman-Version: 2.1.15
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Jun 2014 09:03:25 -0000

#178: fragments going in both directions - allowed or not?

Comment (by

 Indeed, pre-authorization phase is intended only to allow the NAS sending
 a large packet to the AS.We don't want the AS to send authorization
 information until authentication has been completed (post-authorization).
 Besides, the fragmentation process should be seen as an atomic process, in
 the sense that when one of the peers is sending fragmented data, the other
 stop any kind of processing until the sender has completed the delivery.
 As you say, it is a half-duplex process.

 I agree a clarification paragraph is required in the introductory text of
 section 4. In particular, it would be placed as the second paragraph of
 that section. Also, a minor change on the third paragraph would be
 required. The final text would be as follows:

         [...]. The chunks are tied together via the State attribute.

     The delivery of a large fragmented RADIUS packet with authorization
 data can happen before or after the end user has been authenticated by the
 AS. We can distinguish two phases:
     1. Pre-authorization. In this phase, the NAS can send a large packet
 with authorization information to the AS before the end user is
     2. Post-authorization. In this phase, the AS can send a large packet
 with authorization data to the NAS after the end user has been

     The following subsections describe how to perform fragmentation for
 packets for these two phases, pre-authorization and post-authorization.

 Reporter:                           |       Owner:  draft-ietf-radext-           |
     Type:  defect                   |      Status:  new
 Priority:  major                    |   Milestone:
Component:  radius-fragmentation     |     Version:
 Severity:  Waiting for Shepherd     |  Resolution:
  Writeup                            |
 Keywords:                           |

Ticket URL: <>
radext <>