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

From: Jouni Korhonen <[email-masked]>
Date: Wed, 22 Oct 2014 11:04:32 +0300

Folks,

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.

- Jouni & Stefan

---

From: Alan DeKok <[email-masked]>
Date: Wed, 22 Oct 2014 10:26:43 -0400

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Oct 2014 10:43:01 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

    Alan> Jouni Korhonen wrote:
    Alan> * Section 5 defines the Response-Length attribute, but doesn't
    Alan> use the typical RADIUS specification format, with ASCII art,
    Alan> etc.  This means it's not clear how many octets the attribute
    Alan> takes.

    Alan>   I suggest stating explicitly that it's of type "integer", as
    Alan> defined in RFC 2865, Section 5.

makes sense.
If you want to supply ASCII art I'd be happy to include it.
If you want to pretend we live in a post-data-types world and start that
world now I'd be delighted.

    Alan> * I'm of two minds about the "Too-Big" packet code.  It's
    Alan> useful, but it may be better to change this to a generic
    Alan> "Protocol-Error" type, and include an Error-Cause attribute,
    Alan> with value "Too-Big".

    Alan>   That would allow the same packet code to be used in other
    Alan> situations.

    Alan> * the document doesn't say how the "Too-Big" packet is created
    Alan> or signed.  The rules for signing packets are different for
    Alan> Access-Accept and Accounting-Request packets.  Which ones are
    Alan> used for "Too-Big" ?

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

    Alan> * what happens when a TCP socket contains both Access-Request
    Alan> and Accounting-Request packets?

Hmm, I was thinking about TCP where we have separate accounting and
authentication ports.
However, we don't seem to have that for radsec.

    Alan>   i.e. it is possible to have Access-Request of ID 1 and
    Alan> Accounting-Request of ID 1 sent over a TCP socket at the same
    Alan> time.

    Alan>   If the client receives a "Too-Big" attribute of ID 1, which
    Alan> packet is it for?  Does it matter?

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.

    Alan>   How does a client match the Too-Big attribute to incoming
    Alan> packets?  These rules aren't clear.  It's also not clear if
    Alan> they can be resolved in a reasonable amount of time.

    Alan>   Perhaps one way to solve this issue is to define a
    Alan> "Protocol-Error" packet, and a Protocol-Error-Ack packet.  The
    Alan> server would send one over the TCP socket to the client, and
    Alan> the client would ACK it.  The packet signing rules could be
    Alan> the same as for Accounting-Request.

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

--Sam

---

From: Alan DeKok <[email-masked]>
Date: Wed, 22 Oct 2014 10:54:33 -0400

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

> Pick one, or pick the one that is appropriate for what you're responding

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

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

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

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

---

From: Sam Hartman <[email-masked]>
Date: Wed, 22 Oct 2014 11:01:25 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> writes:

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

You know the socket and port.
You're trying to sort between one accounting request and one
access-request with id 1.
That seems relatively easy.
However:

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

Agreed.
Also, they get proxied, and we don't want that here (I don't think)

    Alan>   That means we need a new packet code.

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

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

    Alan>   i.e.:

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

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

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

I'm happy with that solutionn.

Others?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 22 Oct 2014 11:59:32 -0400

> Also, they get proxied, and we don't want that here (I don't think)

  We don't want this packet proxied.

  Alan DeKok.