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

[Alan DeKok <[e-mail]>]

On Sep 9, 2026, at 8:02 AM, Fabian Mauchle <fabian.mauchle=[e-mail]> wrote:
> > 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.

  The intent was to address the issue of retransmissions taking different paths through the network.

> 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 a client is sending packets to (say) eduroam EU, then it's actually sending packets to a _specific_ eduroam EU server.  That server can forward packets to an IdP server, using a RADIUS ID.  Retransmissions on that exact path will re-use the IDs.

  But if that eduroam EU server goes down, then the client fails over to a different eduroam EU server.  That new server can still send packets to the same IdP server, but now all of the RADIUS IDs have changed.

  So the IdP server can't detect that the packet is a retransmission of the original client request.  The contents might be the same (modulo Proxy-State), but the source IP / port, and RADIUS ID will be different.

  For EAP, we get around this issue by processing EAP sessions based on State.  i.e. we ignore source IP/port.  But that can't be done for non-EAP traffic.

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

  OK.  I'll try to clarify the text.

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

  Sorry, RFC 3539 Section 2.8 explains why proxies should not use their own timers to determine retransmission intervals.  Instead, they should be passive / pass-through devices, and only retransmit when the client retransmits.

  While the text in RFC 3539 is a little unclear, the intent is there.  Control loops and timing loops should be "end to end".  Splitting up the timing loops into multiple pieces means that the client gets minimal feedback about congestion.  And, proxies retransmitting can result in an exponential explosion in the number of packets.

  I'll update the text to make this clearer.

  Alan DeKok.