Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01

Alan DeKok <> Wed, 22 October 2014 14:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A28E91ACC8B for <>; Wed, 22 Oct 2014 07:27:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nakn61u133ws for <>; Wed, 22 Oct 2014 07:26:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5310D1AC410 for <>; Wed, 22 Oct 2014 07:26:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8D1A522403A6; Wed, 22 Oct 2014 16:26:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IAfC3R6O5Elv; Wed, 22 Oct 2014 16:26:44 +0200 (CEST)
Received: from Thor.local ( []) by (Postfix) with ESMTPSA id A410122400DF; Wed, 22 Oct 2014 16:26:43 +0200 (CEST)
Message-ID: <>
Date: Wed, 22 Oct 2014 10:26:43 -0400
From: Alan DeKok <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Jouni Korhonen <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" <>, Stefan Winter <>, Sam Hartman <>
Subject: Re: [radext] WGLC for draft-ietf-radext-bigger-packets-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Oct 2014 14:27:00 -0000

Jouni Korhonen wrote:
> This email starts a two week WGLC for the I-D:
> draft-ietf-radext-bigger-packets-01
> Voice your support, comments and concerns on the list. The WGLC ends 5th
> November EOB (EEST). In the case of issues or other enhancement
> proposals, please enter them also into the issue tracker.

  It needs some clarification around the response packet code.  Sorry
for not doing this review earlier.  I'll open some issues.

  Editorial nits:

 The maximum packet length of 4096 octets is proving
 insufficient for ...

  That could be "is proving TO BE insufficient ..."

  Implementation notes:

FreeRADIUS supports TCP, and silently discards packets over 4K octets.
This limit isn't configurable, but could be with minimal work.  This
applies to both server and proxy.

  Technical comments:

* Section 5 defines the Response-Length attribute, but doesn't use the
typical RADIUS specification format, with ASCII art, etc.  This means
it's not clear how many octets the attribute takes.

  I suggest stating explicitly that it's of type "integer", as defined
in RFC 2865, Section 5.

* I'm of two minds about the "Too-Big" packet code.  It's useful, but it
may be better to change this to a generic "Protocol-Error" type, and
include an Error-Cause attribute, with value "Too-Big".

  That would allow the same packet code to be used in other situations.

* the document doesn't say how the "Too-Big" packet is created or
signed.  The rules for signing packets are different for Access-Accept
and Accounting-Request packets.  Which ones are used for "Too-Big" ?

* what happens when a TCP socket contains both Access-Request and
Accounting-Request packets?

  i.e. it is possible to have Access-Request of ID 1 and
Accounting-Request of ID 1 sent over a TCP socket at the same time.

  If the client receives a "Too-Big" attribute of ID 1, which packet is
it for?  Does it matter?

  How does a client match the Too-Big attribute to incoming packets?
These rules aren't clear.  It's also not clear if they can be resolved
in a reasonable amount of time.

  Perhaps one way to solve this issue is to define a "Protocol-Error"
packet, and a Protocol-Error-Ack packet.  The server would send one over
the TCP socket to the client, and the client would ACK it.  The packet
signing rules could be the same as for Accounting-Request.

  This change would make TCP sockets "two-way", in that servers would be
sending messages to clients.  But I think that's fine...

  Clients could then use the same packet to send protocol error messages
to servers.

  A Protocol-Error packet could then contain an Error-Cause attribute
with value "Packet-Too-Big", and a Response-Length of the allowed
response length.  It would then be up to the receiver of the packet to
change it's behavior.

  This also means that the receiver of Protocol-Error can't tell *which*
packet caused the problem.  But that might be fine.