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

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Feb 2014 16:23:17 -0500

hi folks.
I just submitted version 01.  Changes include:

* Using Status-Server as a mechanism for discovering support for this in
  authentication and accounting flows.

* 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 did not make any changes regarding using access-reject for the error
case.  Still waiting for input on that.

Depending on how discussion goes in London, I'm likely to ask the chairs
to consider adopting this draft.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 15 Feb 2014 15:03:16 -0500

>   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.

> IANA in London and get the right stuff together to allocate a code.

  I'll be there.

> 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