Re: [radext] BoF request for IETF 115

[[e-mail]]

> On Oct 2, 2022, at 10:27 AM, [e-mail] wrote:
> > Something I'd find useful is a RADIUS equivalent of traceroute.
> 
>   There are privacy implications for operators.  They might agree to
> connections on one hop, but there are multiple other hops they don't
> control.  Do they agree to sharing their information with operators they
don't
> know?
> 
>   That being said, a roaming group could require such information sharing
for
> its members.

This perhaps touches on a wider issue. RADIUS and EAP implementations tend
towards less privacy-preserving default configurations. Something else on my
wish-list is a persistent targeted identifier, similar to CUI but with
well-specified semantics, that is bound to the identity within the
authenticating EAP method. It is possible to get this outcome this with some
RADIUS and EAP products today, with configuration effort. I think a
standardised approach that reduced the configuration effort is desirable; to
get "privacy by default" for users, without compromising operators'
legitimate needs to know their users.
 
> > This would allow a RADIUS client to probe the path towards a named
> > realm across none, one or more proxies.
> >
> > I think this might be useful because
> > * the RADIUS protocol offers limited diagnostic information across
> > proxies (e.g., realm availability)
> 
>   We've needed a realm routing protocol for a very long time.
Unfortunately,
> there have been few people prepared to work on it.  It's not a simple
> problem.

I think there are people who might be prepared to work on it. However, I
think a realm routing protocol is orthogonal to a diagnostic tool:
traceroute is agnostic to RIP, BGP, etc. We need both. Although perhaps not
in this charter :-)

>   But hop-by-hop querying may be simpler.
> 
> > * troubleshooting RADIUS issues in federated environments often
> > requires coordinating with multiple parties to establish what they are
> > seeing
> > * there are multiple RADIUS transports, each with their own failure
> > modes; a path could incorporate two or more of these
> > * there are multiple discovery methods, such as RFC7585, that have
> > their own failure modes; a path could incorporate two or more of these
> 
>   Yes.
> 
>   One question would be: does this method probe one connection, or does it
> "flood fill" across multiple connections?

Absent a robust routing protocol, "flood fill" might be risky.

> > I imagine it would operate similarly to Status-Server, but traverse
> > proxies and provide reporting on the availability of the next hop, the
> > transport(s), realm discovery method(s), failure reasons, etc.
> 
>   A new packet type would work well here.

I agree.

> > Even if the work of radext is wildly successful, we will be operating
> > in a hybrid environment with RFC2865 for many years. I think this
> > could be a useful tool to help the adoption and operation of new
protocols.
> 
>   I agree.

In a similar vein, I think some guidance on operating hybrid environments
might be desirable. That might have already been mentioned?