[radext] #182 (radius-fragmentation): transport review questions

"radext issue tracker" <trac+radext@trac.tools.ietf.org> Tue, 24 June 2014 07:38 UTC

Return-Path: <trac+radext@trac.tools.ietf.org>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9FC1D1B287C for <radext@ietfa.amsl.com>; Tue, 24 Jun 2014 00:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.151
X-Spam-Status: No, score=-1.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4XnUVaOT9MQM for <radext@ietfa.amsl.com>; Tue, 24 Jun 2014 00:38:11 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48601B287B for <radext@ietf.org>; Tue, 24 Jun 2014 00:38:11 -0700 (PDT)
Received: from localhost ([::1]:53402 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from <trac+radext@trac.tools.ietf.org>) id 1WzLIa-0001yV-2y; Tue, 24 Jun 2014 00:37:53 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "radext issue tracker" <trac+radext@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, stefan.winter@restena.lu
X-Trac-Project: radext
Date: Tue, 24 Jun 2014 07:37:38 -0000
X-URL: http://tools.ietf.org/radext/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/182
Message-ID: <065.43aead270fea325624ba7c979c6728de@trac.tools.ietf.org>
X-Trac-Ticket-ID: 182
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-radext-radius-fragmentation@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org
X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: aland@networkradius.com, alex@um.es, diego@tid.es, gabilm@um.es, pereniguez@um.es
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/9hrsZq-hBoP9TguNn6-SzYJn-ek
Cc: radext@ietf.org
Subject: [radext] #182 (radius-fragmentation): transport review questions
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: radext@ietf.org
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, 24 Jun 2014 07:38:13 -0000

#182: transport review questions

 - the document should more clearly distinguish between the limiting sizes
 of messages at different layers in the stack

     Although RADIUS uses the term "packet" even for RADIUS-level
     data (RFC 2965), I'll use the following terms:
         message    - a RADIUS unit of data
         packet - a UDP unit
         datagram - an IP unit

     i.e., a single RADIUS message (up to 4096 bytes) is always
     sent in a single UDP packet, which may be sent over one or more
     IP datagrams. Thus RADIUS already relies (heavily, IMO) on
     IP-level fragmentation and reassembly.

     E.g., RADIUS specifies a max length of 4096 octets;
     the field supports the same length as a max IP
     datagram (65535). The largest IPv4 datagram that is guaranteed
     to be reassembled is 576 bytes. So RADIUS is already
     potentially sending UDP packets that can't be reassembled
     by IPv4. There's nothing I see in RADIUS that reacts to
     path MTU or even interface MTU.

 - the need to send "large amounts" of data should be better discussed

     Even the 100K data limit can generate an excessive
     burst if the network is congested. See RFC 5405.

     However, given the stop-and-go (windowsize =1) protocol
     of exchanging fragments one at a time, this probably isn't
     an issue - but it should be explained as such.

 - PMTUD is a red-herring unless RADIUS sets the DF bit

     That would be a bad idea, IMO, because RADIUS already
     allows message sizes in excess of the largest safely
     assumed MTU. There's no good reason to set DF=1
     for RADIUS packets - they're not sent at a high enough
     data rate to have problems with IPv4 ID uniqueness
     (see RFC 6864).

     However, RADIUS doesn't appear to set the DF bit,
     nor is that discussed in this doc, so this is a
     red herring.

 - nothing in RADIUS appears to avoid IP fragmentation per se

     So I don't see why that's being added here.

 Reporter:                           |      Owner:  draft-ietf-radext-
  stefan.winter@restena.lu           |  radius-fragmentation@tools.ietf.org
     Type:  defect                   |     Status:  new
 Priority:  major                    |  Milestone:
Component:  radius-fragmentation     |    Version:
 Severity:  Waiting for Shepherd     |   Keywords:
  Writeup                            |

Ticket URL: <http://tools.ietf.org/wg/radext/trac/ticket/182>
radext <http://tools.ietf.org/radext/>