fragments going in both directions - allowed or not?

[stefan.winter@…]

During the PROTO write-up process, I gave the document another thorough read and spotted one question which I didn't see answered very explicitly in the draft text yet.

The document speaks of two phases when fragmented data may need to be sent: pre-authorization and post-authorization. It also speaks of two directions: NAS to AS and vice versa.

Nowhere is explicitly stated that pre-authz is *only* for the NAS to AS direction, and that post-authz is *only* for the AS to NAS direction. (The "Overview" section states that the phases "allow" the respective sides to send something to one another; it does not forbid e.g. that the AS may have much data to send to the NAS during the pre-authz phase anyway.)

So I was starting to read the document with the assumption that both sides can signal large amounts of data in both phases, and was wondering how that would work and look like.

Since the chapters 4.1 and 4.2 only touch the flows for one direction, I spent some thinking to figure out: what happens when the client sends its first chunk, and then the server realises it also has a lot to say to that client, and tries to send chunks itself?

At some point I think I figured that the State attribute would not be a problem (one State attribute can bind both the "ACK" to the client and the "More Data from me" from the server), but that an Access-Accept packet would need to contain simultaneously the AVPs:

Frag-Status = More-Data-Pending (AS indicates it has more to say)
Frag-Status = More-Data-Requested (AS asks next chunk from client)

That in turn is forbidden by the attribute table in section 9.3, which allows at max one occurence of Frag-Status.

So, in the end I convinced myself that only one party is allowed to signal large data to the other party; it's "half-duplex" in a way. I find it harsh to require a reader to go down to that amount of detailed reading to find out about that.

I wonder if that's actually the intention - in which case there should be some text earlier on in the document, e.g. "Overview" could state explicitly that for pre-authz, *only* NAS to AS large data is possible; and for post-authz, *only* AS to NAS large data is possible.

If it is NOT the intention, then this should be stated just as explicitly, and then the occurence table would have to be changed.

[alex@…]

Indeed, pre-authorization phase is intended only to allow the NAS sending a large packet to the AS.We don't want the AS to send authorization information until authentication has been completed (post-authorization). Besides, the fragmentation process should be seen as an atomic process, in the sense that when one of the peers is sending fragmented data, the other stop any kind of processing until the sender has completed the delivery. As you say, it is a half-duplex process.

I agree a clarification paragraph is required in the introductory text of section 4. In particular, it would be placed as the second paragraph of that section. Also, a minor change on the third paragraph would be required. The final text would be as follows:

[...]. The chunks are tied together via the State attribute.

The delivery of a large fragmented RADIUS packet with authorization data can happen before or after the end user has been authenticated by the AS. We can distinguish two phases:

1. Pre-authorization. In this phase, the NAS can send a large packet with authorization information to the AS before the end user is authenticated.
2. Post-authorization. In this phase, the AS can send a large packet with authorization data to the NAS after the end user has been authenticated.

The following subsections describe how to perform fragmentation for packets for these two phases, pre-authorization and post-authorization.
[...]

[stefan.winter@…]

This text is almost good, I only miss that the respectively "other" direction is not spelt out explicitly as forbidden.

Maybe adding an "only" in the two sentences helps, as in

"In this phase, *only* the (NAS|AS) can send a large packet ..." ?

You can resolve this minor wordsmithing nit together with the early TSVDIR review comments (TSVDIR review has been requested and is currently ongoing).

[alex@…]

I've changed that paragraph to:

• Indicate that the exchange of authorization data is not mandatory
• Add the word MAY to reflect that
• Add a sentence explicitly forbidding the "other" direction

[...]
We can distinguish two phases, which can be omitted if there is no authorization data to be sent:

1. Pre-authorization. In this phase, the NAS MAY send a large packet with authorization information to the AS before the end user is authenticated. Only the NAS is allowed to send authorization data during this phase.

2. Post-authorization. In this phase, the AS MAY send a large packet with authorization data to the NAS after the end user has been authenticated. Only the AS is allowed to send authorization data during this phase.

[...]