Re: [radext] Proposed charter text based on IETF-115 BoF

Alan said:

"  ALPN is about negotiating which application protocol is inside of
TLS....   i.e. a hop-by-hop RADIUS packet (inside of TLS) which says "I
have this capability".

[BA] Since TLS ALPN negotiation will be "hop by hop", there could be
scenarios where the SRADIUS ALPN could be negotiated on one hop, but not
another.  A RADIUS proxy can do the conversion, but that could yield
unexpected results.

For example, say a company requires that new NAS devices support SRADIUS,
and upgrades the proxy to support SRADIUS.  But because there are still
some legacy devices left, they still have to maintain a legacy RADIUS
server in addition to an SRADIUS server.

Is there a way for the company to make sure that SRADIUS NAS devices
communicate using SRADIUS on each hop?  Or could an SRADIUS NAS
Access-Request end up being routed to a legacy RADIUS server (or a legacy
RADIUS over (D)TLS server)? If the proxy negotiates SRADIUS with the NAS,
but legacy RADIUS or RADIUS over (D)TLS with the server, then even new
devices supporting SRADIUS might not end up talking SRADIUS end-to-end.

On Mon, Nov 28, 2022 at 7:27 AM Alan DeKok <aland@deployingradius.com>
wrote:

> On Nov 28, 2022, at 8:33 AM, Heikki Vatiainen <hvn@radiatorsoftware.com>
> wrote:
> > Would it be a good idea to add ALPN to RFC 6614 (RADIUS over TLS /
> RadSec) update to create a foundation for SRADIUS and other possible future
> enhancements? What ALPN provides appears to be a good match for what's
> needed for RADIUS too. HTTP, for example, seems to have used it with good
> success.
>
>   I would keep the 6614bis document simple and clear.  Adding ALPN to it
> would serve no purpose for that document.
>
> > Maybe ideas, such as reverse CoA draft, could benefit from this too. The
> reverse CoA draft has text about configuration flag and in-band signalling
> to inform the other end about reverse CoA capability, but careful use of
> ALPN might be a solution for this too. By careful I mean, for example, not
> introducing ALPN Protocol IDs for each and every thing.
>
>   ALPN is about negotiating which application protocol is inside of TLS.
> The reverse CoA document is just RADIUS.  So it needs negotiation inside of
> the application layer.
>
>   i.e. a hop-by-hop RADIUS packet (inside of TLS) which says "I have this
> capability".
>
>   Alan DeKok.
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext
>