Subject: [radext] Retransmission behaviour in proxies

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jul 2016 17:25:29 +0200

I've had discussions in Berlin with Jim & Bernard about problems related to proxying.  This message describes the problems and proposed solutions.

  The historical approach has to require that proxies do retransmits only when the client retransmits.  The idea here is that the traffic should be shaped by end to end network behaviour.  That is, the original client sending the traffic should (somehow) get signalled about network issues, and modify it's behaviour accordingly.  All of the intermediate nodes then act as simple packet forwarders.

  To recapitulate, RADIUS over TCP (RFC 6613) Section 2.5 ends with:

   Intrinsically, proxy systems operate with multiple control loops
   instead of one end-to-end loop, and so they are less stable.  This is
   true even for TCP-TCP proxies.  As discussed in [RFC3539], the only
   way to achieve stability equivalent to a single TCP connection is to
   mimic the end-to-end behavior of a single TCP connection.  This
   typically is not achievable with an application-layer RADIUS
   implementation, regardless of transport.

  The current proxy retransmit works for UDP (sort of). It works less well for TCP and UDP interaction.

  When going from UDP to TCP transport, a client can retransmit, and the proxy will *not* retransmit over the TCP connection, because TCP is reliable.  That's OK.

  When going from TCP to UDP transport, the client will *not* retransmit, so the proxy *should* do it's own retransmissions out the UDP side.  This situation is not covered in RFC 6613.  So we need to fix that.

  At the same time the UDP retransmission behaviour is terrible.  While RFC 5080 Section 2.2.1 describes suggested retransmission behaviour (and is 10 years old at this point), most RADIUS clients do not implement it's recommendations.  They just use fixed retransmission intervals with no jitter, exponential back off, etc.

  My suggestion is the following:

- suggest that UDP to TCP proxies don't retransmit, as per RFC 6613.

- suggest that TCP to TCP proxies are mostly OK, as per RFC 6613.

- require that TCP to UDP proxies implement the retransmission behaviour described in RFC 5080 Section 2.2.1

- suggest that UDP to UDP proxy behaviour is slightly more complicated

  - where there is no Proxy-State attribute in the packet, we can assume that the previous hop was a RADIUS client.  The current node is a RADIUS server, and is much more likely to implement RFC 5080 correctly.  In that case, it MAY be beneficial for the proxy to quench duplicates from the client, and to implement the RFC 5080 retransmissions itself.

  - where here is a Proxy-State attribute  in the packet, we can assume that the previous hop was a RADIUS proxy, and (hopefully) implements RFC 5080 correctly.  In that case, the proxy should just "pass through" the retransmissions from the client to the next hop.  The proxy SHOULD NOT implement it's own retransmission behaviour.

  I think that solves the basic issues related to UDP / TCP transport.

  A related goal would be to determine how RADIUS clients can look at traffic in order to optimize network behaviour.  AS RFC 6613 notes, this may be difficult.  The hope is that we can do better than what we're doing now.

  A simple approach would be to track traffic based on destination realm.  The assumption would be that each realm goes to one location (whatever that is), and that analyzing traffic for that realm can be done.  And that such analysis would lead to the client better optimizing traffic for that realm.

  The difficulty with RADIUS is that traffic is burst, and controlled by users logging in.  When TCP has 100K+ to transfer for a web page, it has time to do traffic statistics.  We're just not as lucky with RADIUS.

  Alan DeKok.