[radext] Re: Gorry Fairhurst's Discuss on draft-ietf-radext-radiusdtls-bis-15: (with DISCUSS and COMMENT)

[Jan-Frederik Rieckers <[e-mail]>]

Hi Gorry,

also from me thanks for your review. Some of the points Alan already 
addressed, I'll add my comments below:

On 3/4/26 15:32, Gorry Fairhurst via Datatracker wrote:
> ### S 6.2.3 - DISCUSS
> “In order to avoid congestive collapse, it is RECOMMENDED that...”
> - I would like to discuss why this is only recommended, why its this not
> required if it contributes to congestion. At least I expected some careful
> explanation of why this “SHOULD” might be deviated from in specific usage.

There is no technical reason why this should be forbidden, and if it is 
used in a simple client/server architecture without proxies, using 
Acct-Delay-Time does not cause any problems.

I've started a Pull Request in the editor's copy on github that adds an 
appendix, that gives one example how using Acct-Delay-Time in this way 
contributes to congestion.
https://github.com/radext-wg/draft-ietf-radext-radiusdtls-bis/pull/166

I'm not sure if this resolves your DISCUSS.

Regarding the comment about deviation from the recommendation, I hope 
that the appendix gives a good overview of what might happen, and the 
last paragraph of the section also gives guidance on how Acct-Delay-Time 
can be used.
I suspect that most cases where Acct-Delay-Time is used, it is due to 
existing setups and backward compatibility.

> 
> ### S 6.4 - DISCUSS
>    “Note that PMTU
>     discovery can only discover the PMTU of the current RADIUS hop and a
>     RADIUS client has no reliable way to discover the PMTU across the
>     whole RADIUS proxy chain.  Further discussion of this topic is
>     outside of the scope of this document.”
> - I am trying to figure out what the above text really means, and why this is
> an issue: I wonder if this is more of a concern when there is a proxy from a
> TCP to UDP, or one from UDP to TCP. When a large packet is sent from UDP to
> TCP? - presumably a proxy from a TCP stream will simply segment to the
> Min(PMTU,SMSS) and hence the larger TLS record can be varied, whereas from TCP
> to UDP the proxy might be limited by the UDP datagram size. Of course, a proxy
> between two UDP “connections” would need some way of determining a useful PMTU
> across both paths. ... I think I do not understand what actually the issue?

At the radext session during the last IETF meeting we discussed whether 
we should just remove any reference of PMTU discovery and the 
implications of that and put it into a separate document that focuses on 
RADIUS proxying.

> ### S 6.2.2 - Comment
> “Due to the lossy nature of UDP,”
> - I think statement is wrong. UDP is not “lossy”! It seems more accurate to say
> that “UDP datagrams can be lost/reordered”.

I've changed it in the editor's copy, will be changed in the next I-D 
version.

> 
> ### S 6.2.2 - Comment
> “but MUST NOT forward those
> retransmissions across the reliable transport.”
> - To be clear, it would be helpful to say which retransmissions were being
> discussed: /retransmissions/retransmissions over unreliable transports/

In this case, it is actually irrelevant if the retransmission came over 
unreliable or reliable transports.

Personally, I fear that adding an explanation will make the sentence 
harder to understand.
It's just a reiteration of section 3.9.2 (RADIUS packet 
retransmissions), that already states that RAIDUS/TLS clients MUST NOT 
retransmit packets. (in that case "when indicated by the timers", and 
section 6.2.2 only adds a "also don't if you get a retransmission of the 
'downstream' packet")

> 
> ### S 6.2.3 - Comment
>    “In order to avoid congestive collapse, it is RECOMMENDED that RadSec
>     clients which originate Accounting-Request packets (i.e., not
>     proxies) do not include Acct-Delay-Time ([RFC2866], Section 5.2) in
>     those packets.”
> - I expect this point is important, but I do not think the text is currently
> correct, this does not *avoid* congestion collapse, maybe the intention is to
> say this reduces the probability of collapse?
> 
> ### S 6.2.3 - Comment
>    “this duplication contributes to congestive collapse of the
>     network, if one or more RADIUS proxies performs retransmission to the
>     next hop for each of those packets independently.”
> - I expect the described effect is important, but I also do not think the text
> is correct. i.e.: I cannot see that *automatically* results in congestion, nor
> in congestion collapse! I would suggest that this “contributes to traffic and
> can induce congestion, which could contribute to congestion collapse”, or
> something similar?

In the PR I mentioned earlier I've also removed "congestive collapse" 
and replaced it with "congestion", I'll do some more wordsmithing on the 
PR, to better explain under which circumstances there can be congestive 
collapse.

> 
> ### S 6.4 (TCP Applications Are Not UDP Applications) - Comment
>    “Implementers should be aware that programming a robust TCP-based
>     application can be very different from programming a robust UDP-based
>     application.”
> - Please can this text refer to the requirement in RFC8085 that provides
> guidelines for using UDP?

I've read a little bit of RFC 8085 and I'm not sure which parts of this 
RFC we can reference here that would add value to this document.
 From what I read, there is little guidance on implementation and more 
on how to design a UDP-based protocol. Since we are using an existing 
UDP-based protocol (RADIUS) and only extending it, there is not much 
that we can do without significantly changing the way RADIUS behaves.

If you have specific parts of RFC 8085 that you feel are applicable to 
this document and should be referenced, I'm happy to add it.

> ### S 6.4 - Comment
> “ RADIUS/DTLS clients MAY use PMTU discovery [RFC6520] to determine the
>     PMTU between the client and server.”
> - Given this also refers to UDP, please also consider including please a
> reference to RFC 8899, aka DPLPMTUD for UDP, as specified in QUIC, etc.

(See comment about removing PMTU)
If PMTU is left in, I'll see if we can add a reference to RFC 8899.

> ### S 6.4 - Comment
>    “While a RADIUS client has
>     limited to no possibilities to reduce the size of an outgoing RADIUS
>     packet without unwanted side effects, it gives the RADIUS client the
>     possibility to determine whether or not the RADIUS packet can even be
>     sent over the connection.”
> - This may be related to my “DISCUSS” (sorry), but I do not yet see what that
> would be an issue when the proxy connects onward over TCP, QUIC or similar
> transport.

If it's sent via RADIUS/TLS, there is no problem. But if it's sent via 
RADIUS/UDP or RADIUS/DTLS, the MTU restrictions apply.
And if a client (or a proxy acting as client when forwarding) determines 
that a packet is too big for one connection, but it might not be too big 
for another connection in the same fail-over-pool, it can choose the 
connection where the packet might get through. E.g., it has a 
RADIUS/DTLS and a RADIUS/TLS server configured, then it can choose the 
RADIUS/TLS server, because there the MTU is irrelevant.

> ### S 6.4 - Comment
>    “Sending RADIUS packets that exceed the
>     PMTU between the client and the server will result in IP
>     fragmentation.  IP fragmentation may not be functioning, “
> - This seems an odd statement without reference. Can this please refer to an
> RFC, such as RFC 8900? - Also there is no mention of the TCP Sender MSS, which
> also limits the maximum packet size sent by a TCP sender, this seems like it
> would be a useful thing to note.

The MSS of TCP is not applicable here, because in TCP we rely on the 
stream functionality, and we don't care about the individual TCP 
segments on application layer.
For DTLS via UDP, we cannot fragment a single RADIUS packet in multiple 
UDP datagrams.

But, if the PMTU text is removed, this becomes irrelevant.
RFC 8900 is already referenced in section 5.1, if we leave PMTU in, I'll 
add a reference in this section too.

Cheers,
Janfred

-- 
Herr Jan-Frederik Rieckers
Security, Trust & Identity Services

E-Mail: [e-mail] | Fon: [phone] | Fax: [phone]
Pronomen: er/sein | Pronouns: he/him
__________________________________________________________________________________

DFN - Deutsches Forschungsnetz | German National Research and Education 
Network
Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
Alexanderplatz 1 | 10178 Berlin
https://www.dfn.de

Vorstand: Prof. Dr.-Ing. Stefan Wesner | Prof. Dr. Helmut Reiser | 
Christian Zens
Geschäftsführung: Dr. Christian Grimm | Alina Hain
VR AG Charlottenburg 7729B | USt.-ID. DE 136623822