Subject: [radext] Questions about draft-ietf-radext-bigger-packets-03

From: Stefan Winter <[email-masked]>
Date: Thu, 20 Aug 2015 08:13:53 +0200

Hello,

I'm currently writing the document writeup of
draft-ietf-radext-bigger-packets-03 and have a few questions that came
up during document review and the Technical Summary question. My
apologies if they were already discussed on the list; please provide a
pointer if so.

I will be opening one TRAC issue for each item below. It would be nice
if responses were made in TRAC, or at least in the thread which is
started by the creation of the TRAC ticket.

1)
Does the document require an "Updates" relationship to RFC2865? RFC2865
sets the maximum content of the Length field in a RADIUS datagram to
4096; this specification lifts that restriction.

2)
In the Abstract, I read:
"[...] this specification introduces no new experimental evaluation
criteria beyond those in the base TCP specification"

I wonder if this is really a clear-cut situation. Interoperability
(backward/forward compatibility) is given a lot of thought and makes a
number of assumptions.

One such assumption is that bigger-packets is for new use cases (only?).
It is however easy to construct cases where bigger-packets is also of
use for existing RADIUS uses, like this one:
IEEE 802.1X authentication on a wired network with jumbo frames enabled.
Layer 2 EAPoL payloads could grow to 9K, which would typically be
signalled by a Framed-MTU attribute; and which could trigger 9K of
EAP-Message payload.
I understand that the general statement of "SHOULD NOT generate a larger
response than 4096 by default" catches this case (for implementation
actually honoring the SHOULD NOT, which is sadly not a given). But it
makes me wonder if the topic is indeed so easy.

Another example which makes assumptions is that closure of a TCP session
when sending a big packet is taken as an indicator for non-support of
this specification. There are many other reasons why the TCP session
might go down (firewall state timeouts...). The client would
unjustifiedly reduce its transmission size for ... how long? Eternity?
That would mean a permanent loss of the big-packets feature. As a
suggestion: the Rationale section already has a better mechanism - after
TCP closure, start the next TCP session with the Status-Server max-size
discovery. It might be an idea to mandate this after every TCP closure
which occurs for reasons where a doubt exists - not only for high-volume
servers.

So, how does the group feel about recognising that backward
compatibility problems are something that should be evaluated in this
experiment? I could imagine a text like

OLD:
"However, this specification introduces no new
   experimental evaluation criteria beyond those in the base TCP
   specification; this specification can be evaluated along with that
   one for advancement on the standards track."

NEW:
"This specification introduces backward compatibility issues with
implementations of RFC6613 which do not support this experiment, and
with proxies which need to proxy an incoming large packet to a
size-constrained RFC2865 transport RADIUS server. The real-life
consequences of this lack of backward compatibility are to be studied in
and evaluated during the assessment of this experiment before the
features are sent to Standards Track."

3)
More specifically on Compatibility, section 3 states around dynamic
discovery:

"If dynamic discovery mechanisms are supported, configuration SHOULD be
   provided for the maximum size of clients and servers in each dynamic
   discovery category."

It is unclear to me what such a "category" would be. During the
discovery pahse, DNS has no leeway to discover maximum packet sizes.
There is also only one service and protocol tag. It remains unclear to
me how different groups of discovered servers could be put into distinct
categories. If the use of distinct, and non-standard service and
protocol tags is the vehicle to do this, this should be stated
explicitly in the document.

Maybe it would help to require a Status-Server negotiation as per
section 3.2 as first packet exchange on newly established dynamic
discovery TCP streams? This would obsolete the concept of configured
categories.

4)
Cexistence with RADIUS Fragmentation, clause 1.
The notion of an endpoint is introduced. It appears to me like the
decision to use either bigger-packets or RADIUS Fragementation is made
on a hop-by-hop basis. Did you mean something like "next hop" (as that
next hop may be an endpoint, or another proxy).
I assume that when deciding to use RADIUS Fragmentation for a next hop
whose support for this specification is not known, the generated request
packet would still be augmented with a Response-Length attribute to
learn about the next hop's capabilities? If so, can this be made
explicit in the text?

5) For "Document quality", I would mention implementations which are
known to implement the spec. Are there any? If so, you may want to add
an RFC6982 "Implementation Status" section.

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: Alan DeKok <[email-masked]>
Date: Thu, 20 Aug 2015 15:01:30 -0400

> which occurs for reasons where a doubt exists - not only for high-volume

  Explicit signalling sounds good to me.

> features are sent to Standards Track."

  Sounds good.

> discovery TCP streams? This would obsolete the concept of configured

  That's a good idea.

> on a hop-by-hop basis.

  Yes, and a protocol basis.  UDP gets fragmented, TCP gets bigger packets.

  I'd be wary of using bigger packets with UDP.  The document should probably recommend against it.

> an RFC6982 "Implementation Status" section.

  Uh.... clickety click... I'll take a look at the implementation side of things. :)  But that requires IANA allocation of the packet code and attributes.

  On that note:  Response-Length is a  2-octet unsigned integer of maximum response length.

  Can that be changed to be of data type "integer"?   And maybe reference data types?

  I'll refresh the data types document today.

  Alan DeKok.