transport review questions

[stefan.winter@…]

• the document should more clearly distinguish between the limiting sizes of messages at different layers in the stack

Although RADIUS uses the term "packet" even for RADIUS-level
data (RFC 2965), I'll use the following terms:

message - a RADIUS unit of data
packet - a UDP unit
datagram - an IP unit

i.e., a single RADIUS message (up to 4096 bytes) is always
sent in a single UDP packet, which may be sent over one or more
IP datagrams. Thus RADIUS already relies (heavily, IMO) on
IP-level fragmentation and reassembly.

E.g., RADIUS specifies a max length of 4096 octets;
the field supports the same length as a max IP
datagram (65535). The largest IPv4 datagram that is guaranteed
to be reassembled is 576 bytes. So RADIUS is already
potentially sending UDP packets that can't be reassembled
by IPv4. There's nothing I see in RADIUS that reacts to
path MTU or even interface MTU.

• the need to send "large amounts" of data should be better discussed

Even the 100K data limit can generate an excessive
burst if the network is congested. See RFC 5405.

However, given the stop-and-go (windowsize =1) protocol
of exchanging fragments one at a time, this probably isn't
an issue - but it should be explained as such.

• PMTUD is a red-herring unless RADIUS sets the DF bit

That would be a bad idea, IMO, because RADIUS already
allows message sizes in excess of the largest safely
assumed MTU. There's no good reason to set DF=1
for RADIUS packets - they're not sent at a high enough
data rate to have problems with IPv4 ID uniqueness
(see RFC 6864).

However, RADIUS doesn't appear to set the DF bit,
nor is that discussed in this doc, so this is a
red herring.

• nothing in RADIUS appears to avoid IP fragmentation per se

So I don't see why that's being added here.

[aland@…]

Multiple implementations force the DF bit to be zero. When DF=1, implementations sending large packets get ICMP errors instead of data transport. This is bad.

[stefan.winter@…]

The authors have added section 11.4 for transport considerations, which tackles the second bullet at least.

Following discussions with the authors, we agreed that PMTUD is out of scope for this document - it is much rather a generic RADIUS question that needs to (additional) considerations here; the datagrams produced by this document are "normal-sized" RADIUS datagrams on the wire.

Meanwhile, an early TSVDIR review has been requested, whose results will very likely supersede the open bullets in this ticket.

I am closing the ticket now, and will open a new one with the results of the TSVDIR review by the time it's finished.