Re: [radext] draft-hartman-radext-bigger-packets-01

Alan DeKok <> Sat, 15 February 2014 20:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D3CE71A028F for <>; Sat, 15 Feb 2014 12:03:20 -0800 (PST)
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 O4ty24xPXcgk for <>; Sat, 15 Feb 2014 12:03:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 71BE81A028D for <>; Sat, 15 Feb 2014 12:03:17 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0D23224033D; Sat, 15 Feb 2014 21:03:13 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2FBn81cJwGqf; Sat, 15 Feb 2014 21:03:13 +0100 (CET)
Received: from Thor.local (unknown []) by (Postfix) with ESMTPSA id 0ACE222400DD; Sat, 15 Feb 2014 21:03:12 +0100 (CET)
Message-ID: <>
Date: Sat, 15 Feb 2014 15:03:16 -0500
From: Alan DeKok <>
User-Agent: Thunderbird (Macintosh/20100228)
MIME-Version: 1.0
To: Sam Hartman <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [radext] draft-hartman-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: Sat, 15 Feb 2014 20:03:21 -0000

Sam Hartman wrote:
> * Using Status-Server as a mechanism for discovering support for this in
>   authentication and accounting flows.

  That works, but is dangerously close to doing capability negotiation
in RADIUS.  I had put together a rough draft years ago with some Cisco
people.  Those ideas might help.

> * Removing the diameter considerations section
> * Discussing the issue where multiple requests are outstanding.
> * Allocating the radius type we need.
> Hopefully I can sit down with Alan or someone else familiar with RADIUS
> IANA in London and get the right stuff together to allocate a code.

  I'll be there.

> I did not make any changes regarding using access-reject for the error
> case.  Still waiting for input on that.

  Do you mean where the packet is too large?

  Some quick notes:



  "nice specification" :)  It should be complements with an E.

Section 2.1

If a server implementing this specification receives a Response-Length
attribute in a Status-Server request, it MUST include a Response-Length
attribute indicating the maximum size request it can process in its
response to the Status-Server request.

  I would also not that implementations can send a Response-Length in
Status-Server and (a) not get a reply to the packet, or (b) not get a
Response-Length in the reply.  In both of those cases, the normal RADIUS
defaults should be assumed.

Section 3:

  I would suggest *always* using Status-Server on the first connection
to a particular server, keyed by IP/port.  That way the discovery is
done once, and never again.  Large packets SHOULD NOT be sent until it
receives a positive acknowledgment from the server.

  Blindly sending a large packet should be discouraged.

  Also, once this capability has been negotiated, there's probably no
need to re-do it for every new connection to that IP/port.  So long as
*some* TCP connection remains open, you can likely assume that the
server process is still the same.

  However, if no TCP connections are open to the server for a period of
time, the client SHOULD send a new Status-Server for capability
discovery.  The server may have been replaced / downgraded / whatever.

Section 3.1

  When an RFc 6113

  Upper-case the C in RFC