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

[Alan DeKok <[e-mail]>]

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.