Re: Proxy State and RFC 3576bis

[Alan DeKok <aland@nitros9.org>]

Bernard Aboba wrote:
> One of the deployment blockers with RFC 3576 is the need to modify
> proxies to handle routing of RFC 3576 packets.  While proxies typically
> keep tables for dowstream forwarding, they typically do not keep tables
> for upstream forwarding.  Rather, they typically rely on the Proxy-State
> attribute to enable forwarding of an Access-Response back to the
> originating NAS.

  I've been working with sites recently to deploy RFC 3576 solutions.
We've found out that the simplest way to perform upstream forwarding is
to keep session state in DB's for all intermediate nodes.  i.e. We
ignore Proxy-State.

  When there is a failover relationship between two servers for
downstream forwarding, DBN replication is used to ensure that both share
the same information for upstream forwarding.

  That is, the packets may traverse different paths going downstream and
upstream.  However, since servers in a failover relationship are
"identical", they should behave identically for up/downstream forwarding.

> Given this, I am wondering how RADIUS proxies should handle Proxy-State
> for RFC 3576 packets:
> 
> a. Do they add Proxy-State attributes to a Disconnect/CoA-Request as
> suggested in the current text (and as would be done for an Access-Request)?

  No.

> b. Or can the RADIUS server include a Proxy-State attribute previously
> obtained from an Access-Request used in the original authentication
> within the Disconnect/CoA-Request to assist the proxy in routing the
> request back to the NAS?  In this case, wouldn't the RADIUS proxy
> *remove* Proxy-State attributes from the Disconnect/CoA-Request??

  Yes.

  However, Proxy-State is almost entirely useless.  For downstream
forwarding, we can't key off of the Proxy-State in replies to find the
corresponding request, because some implementations historically mangled
 Proxy-State, in defiance of the RFC requirements.  Therefore, it's best
for the server to keep internal tables for downstream forwarding, and
use those tables to match replies to requests.

  Proxy-State is added for RFC compliance, but is otherwise ignored.
The contents are never examined to match replies to requests.

  For RFC 3576 behavior, once sessions are kept in a DB, Proxy-State is
also useless.  Since Proxy-State isn't signed or authenticated, and
since it can be mangled by intermediate nodes, it can't be used by an
intermediate node as the basis for any decision.

  If we ignore deployment issues, a solution to the upstream routing
problem would be add a new attribute.  This attribute would be added on
downstream proxying by intermediate nodes, just like Proxy-State.  But
it would be signed and authenticated at each hop.  Its contents would be
sufficient information for the upstream path to make a forwarding
decision, independent of any other data.  Intermediate nodes therefore
become stateless, and servers in a failover relationship do not have to
contact each other to maintain information about upstream paths for
sessions.

  This means that all of the proxying servers would have to support this
attribute, and that the final home server would have to store N copies
of the attribute per session, one for each intermediate hop.  It would
also allow intermediate nodes to catch routing loops, as they could
potentially examine all copies of the new attribute for "their" copy.

  Since all proxies have to be updated from base RFC 2865 functionality
to support RFC 3576 upstream routing, this proposal might just work.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>