Subject: Review of draft-ietf-radext-radius-fragmentation?

From: Stefan Winter <[email-masked]>
Date: Thu, 05 Jun 2014 15:35:07 +0200

Hello tsv-area,

I'm co-chair of radext and the document shepherd for the above document,
and it's currently awaiting its PROTO write-up.

As I went through the latest revision, it occured to me that there are
quite some transport considerations in this, which are beyond my
technical knowledge.

In short:

A protocol that previously had no fragmentation support (RADIUS over
UDP, max size 4096 per datagram, max one datagram in flight, may be
"routed" via RADIUS proxies in a kind of overlay network) now gets some;
the fragmentation is done in a way which is "far away" from the usual
way - no sequence numbers, duplicate detection is based on a randomly
chosen State attribute, there is no explicit NAK for missing chunks and
instead the RADIUS timeout is the only way to detect and correct
fragments gone AWOL. There may be fragmentation-aware and -unaware
RADIUS proxies on the path between sender and ultimate recipient of the
payload.

I'm thinking that this warrants a closer look by TSV experts. Am I
asking at the right place?

The draft is here:
https://datatracker.ietf.org/doc/draft-ietf-radext-radius-fragmentation/

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66

---

From: Joe Touch <[email-masked]>
Date: Fri, 20 Jun 2014 17:28:57 -0700

Hi, Stefan,

Fragmentation issues have been a focus of both the INT and TSV areas. 
It'd be useful to contact the ADs directly for feedback in both cases.

I suspect the best place to start would be the TSVDIR, though. In the 
past, I've been the 'stuckee' for some of the fragmentation-related 
reviews, FWIW, so here are my initial observations:

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

I hope that helps... I'd be glad to address further questions on this list.

Joe