Re: [radext] draft-dekok-radext-reverse-coa-00

[Alexander Clouter <[e-mail]>]

On Thu, 20 Oct 2022, at 20:39, Alan DeKok wrote:
>   At least parts of this are implemented in Cisco && Aruba equipment, and in FreeRADIUS.
> 
>> A new version of I-D, draft-dekok-radext-reverse-coa-00.txt
>> has been successfully submitted by Alan DeKok and posted to the
>> IETF repository.
>
> 5.  Reverse Routing
> 
>    The "reverse" routing table for CoA packets was first described in
>    Section 2.1 of [RFC8559].  We extend that table here.
> 
>    In our extension, the table does not map realms to home servers.
>    Instead, it maps keys to connections.  The keys will be defined in
>    more detail below.  For now, we say that keys can be derived from a
>    RADIUS client to server connection, and from the contents of a CoA
>    packet which needs to be routed.
> 
>    When the server recieves a TLS connection from a client, it derives a
>    key for that connection, and associates the connection with that key.

"'i' before the 'e' unless it is after a 'c' (and other exceptions)"

There is another occurrence later in this section too.

> 6.  Implementation Status
> 
>    FreeRADIUS supports CoA proxying using Vendor-Specific attributes.
>    It also permits RADIUS clients to send Status-Server packets over a
>    RADIUS/TLS connection which contain Operator-Name.  This information
>    is used to determne which realms are accessible via reverse CoA over
>    which RADIUS/TLS connection.

'determne' -> 'determine'.

We do open a potential security issue here as a bad actor could advertise realms they do not own to steer traffic to them.

So for something like 'eduroam', no doubt there are attribute/sanity filters that prevent bob.ac.uk advertising bob.nl but the RADIUS server may process the Operator-Name's from the Server-Status before those filters kick in.

Thanks