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

Alan DeKok <aland@deployingradius.com> Sat, 15 February 2014 20:03 UTC

Message-ID: <52FFC804.4050403@deployingradius.com>
Date: Sat, 15 Feb 2014 15:03:16 -0500
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228)
MIME-Version: 1.0
To: Sam Hartman <hartmans@painless-security.com>
References: <tsleh36k8qi.fsf@mit.edu>
In-Reply-To: <tsleh36k8qi.fsf@mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/radext/vSIqynqZImv6Kw6k1iGaq-5yMgM
Cc: radext@ietf.org
Subject: Re: [radext] draft-hartman-radext-bigger-packets-01
Precedence: list

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:

Abstract

   compliments

  "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

[radext] draft-hartman-radext-bigger-packets-01 Sam Hartman
Re: [radext] draft-hartman-radext-bigger-packets-… Alan DeKok