[radext] Re: I-D Action: draft-ietf-radext-review-radius-02.txt

[Fabian Mauchle <[e-mail]>]

On 10.08.2026 20:58, Alan DeKok wrote:
>    This document rearranges the text a bit to be clearer, and adds substantial new text which summarizes the issues discussed on this list in the past year or so.
A review of the diff to -01, two things that struck me:

 > 5.3.3 There is no end to end identifier	
 > Where Diameter defines an End-To-End Identifier ([RFC6733],	
 > Section 3), RADIUS Identifiers are strictly hop by hop.  This	
 > limitation means that there is no way for proxies to determine if a	
 > retransmitted packet is the same as a one which was previously sent.	

This confuses me, either I'm thinking of the wrong thing or I'm missing 
some context.

With the hop by hp identifiers, each proxy can determine if a request is 
a duplicate on that hop. If this properly happens on every hop there 
should not be additional load.

If this refers to the NAS retransmitting the same request with a new 
identifier or updated contents (as was discussed regarding 
accounting-delay-time), this should be mentioned in the context. And 
this would violate even the hop by hop identifier as in this case the 
proxy can't determine retransmissions on the single hop.

 > 5.3.4. There are no end to end timers
 > While proxies are forbidden from retransmitting packets,

In light of radsec that would not be accurate.
- for TLS and TCP its forbidden
- for TLS/TCP to UDP proxy, the proxy must (or at least should) retransmit
- for pure UDP, I think the orignial RFC2865 is silent on this topic, it 
doesn't specify retransmissions for proxy, but there's no explicit MUST 
NOT retransmit in there?

-- 
Fabian