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

[Alan DeKok <[e-mail]>]

Sam Hartman wrote:
> If you want to pretend we live in a post-data-types world and start that
> world now I'd be delighted.

  I'm all for that.  Call it an "integer" attribute as per RFC 2865
Section 5, and we're done.

> I can see two choices.
> Pick one, or pick the one that is appropriate for what you're responding
> to.

  It's hard to know which packet type is being responded to.

> I don't think it matters that much, no.
> If it does you can see which of the packets you sent is bigger than the
> response length you just got.

  That might be hard work, if the client is sending 100's of 1000's of
packets.  The packets will be sorted by socket, IPs, ports, etc.  Not by
size.

> I'd really rather not do that; it seems rather complex and I'd really
> like to try and find a way to make this mechanism simple.

  I'd prefer to not overload Access-Reject or Accounting-Response.
Those are for *normal* situations.  i.e. they do signaling for users,
not for protocol errors.

  That means we need a new packet code.

> Let's explore how important it is that clients be able to match the
> too-big packet and if so how difficult that ends up being.

  TBH, the simplest thing would be to include the original packet code
in a new attribute.  That way the peer receiving the packet knows how to
find the original.  It can match code, src/dst IP, src/dst port.

  And change the name of the packet code. A generic name is much
prettier than a specific one.

  i.e.:

Packet code == Protocol-Error
   Attribute-TBD = Access-Request
   Error-Cause = Packet-Too-Big
   Response-Length = 8192

  The packet signing rules should be the same as for Access-Accept, I
think.  i.e. copy the original vector to the response vector and sign.
Even if the original was Accounting-Request.

  I think that's simple, has minimal changes to the document, and has
minimal changes to existing implementations.

  Alan DeKok.