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

[Heikki Vatiainen <[e-mail]>]

On Tue, 29 Nov 2022 at 01:19, Jan-Frederik Rieckers <[e-mail]>
wrote:

> On 28.11.22 23:19, Alan DeKok wrote:
> >    Stefan pointed out that we should probably add a flag saying "require
> secure transport".
> >
> >    i.e. SRADIUS has 8 octets of unused data in the packet header.  It
> would be good to define one as a flags field: "require secure transport".
> >
> >    Then if a proxy receives SRADIUS packets with that flag set, it will
> refuse to proxy the packets over plain UDP / TCP.  RADIUS/TLS is fine, as
> TLS will take care of securing the data.
>
> Allowing forwarding with RADIUS/TLS has the downside that the flag would
> be lost and it could result in RADIUS/UDP at some point if it is proxied
> further.
> Unless we find a way to include the Flag in "plain" RADIUS, but that
> would also require all proxies to honor the new flag.
>

There's also the possibility that IPsec or some other method is used to
securely forward RADIUS/UDP. This may not be easily visible for a Radius
proxy. This could lead to a situation that the potential newly added flag
is honoured while there's secure transport available.

Regarding secure transport: The revised Diameter RFC says:
https://www.rfc-editor.org/rfc/rfc6733.html#section-1.1.3
   o  Simplified security requirements.  The use of a secured transport
      for exchanging Diameter messages remains mandatory.  However, TLS/
      TCP and DTLS/SCTP have become the primary methods of securing
      Diameter with IPsec as a secondary alternative.  See Section 13
      for details.  The support for the End-to-End security framework
      (E2E-Sequence AVP and 'P'-bit in the AVP header) has also been
      deprecated.

The obsoleted RFC 3588 defined 'P'-bit as:
      The 'P' bit indicates the need for encryption for end-to-end security.

A quick search didn't tell why the above changes were done, but if secure
transport flag is considered, it might be useful to see what happened in
Diameter's case.

Thanks,
Heikki

-- 
Heikki Vatiainen
[e-mail]