Re: [radext] Secure COA

[Sam Hartman <[e-mail]>]

>>>>> "Alan" == Alan DeKok <[e-mail]> writes:

    Alan> On Mar 23, 2015, at 6:21 PM, Sam Hartman <[e-mail]> wrote:
    >> I think solving this requirement would be necessary for moving
    >> COA to the standards track or removing the health warning in
    >> 5176.

    Alan>   I agree.

    Alan>   Let’s say that each proxy selectively forwards CoA packets
    Alan> based on it’s knowledge of the user sessions.  This means that
    Alan> every proxy has to maintain information on every user session,
    Alan> which is untenable.

I actually can think of ways of approaching this.
This scaling problem seems no worse than some scaling problems websites
face and some of the solutions there seem applicable.
However, this seems like the wrong approach to me, because it is more
complex than needed.

    Alan>   Or maybe the sessions contain some kind of state that the
    Alan> proxy can cryptographically verify.  That means sharing the
    Alan> cryptographic keys with all proxies, which is also untenable.

It's much less obvious to me that this is untenible.
We definitely have key distribution mechanisms that seem up to the task.
This is especially true in deployments where the original access request
travels through  the same operators as  the COA packet travels in
reverse.
In that case, operators can add/transform their own state, and need only
manage keys within  their own domain.


    Alan>   In the end, I don’t see this as a session state problem.
    Alan> It’s a routing problem.  For a situation Visited -> Proxy ->
    Alan> Home, packets are usually forwarded based on User-Name, and
    Alan> realm.  When the Home server wants to disconnect a user, it
    Alan> typically sends User-Name as part of the session
    Alan> identification attributes.  So all that’s needed is for the
    Alan> proxy to look up that realm.

    Alan>   i.e. the algorithm is this:

    Alan> forwarding proxy: receive packet with User-Name, look up
    Alan> realm, and forward packet to that realm.

    Alan> CoA proxy: receive packet with Operator-Name and User-Name.
    Alan> Look up realm from *User-Name*.  If the source of the packet
    Alan> does not match a known destination for that realm, then drop
    Alan> the packet as being non-compliant.  Otherwise, look up realm
    Alan> from *Operator-Name*, and forward the CoA packet there.

This seems fairly weak to me.

I'd be much more comfortable with a solution that took routing and
session state into account.