[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Capabilities negotiation problem statement
> 3GPP2 for example use advertisement for:
> Prepaid - Before we push down a Prepaid policy we need to know whether
> the NAS supports that policy. Otherwise the NAS will ignore the policy
> and allow the session to continue. As you can see this is a serious
This case sounds the same as the security issue with filter rules. That
is, the RADIUS server needs to send an attribute that cannot be safely
ignored by the NAS.
> Dynamic Auth - we need to understand whether a NAS supports 3576 for
> correct operation.
RFC 3576 already specifies how a RADIUS server can determine if a
NAS supports it. Where the RADIUS client does not support RFC 3576, the
server will receive an ICMP port unreachable message in reply to a
Disconnect or CoA-Request. If the proxy supports RFC 3576, but the NAS
does not, then the proxy replies with an Error-Cause value of "Unsupported
"Unsupported Extension" is a fatal error sent due to lack of support
for an extension such as Disconnect and/or CoA messages. This will
typically be sent by a proxy receiving an ICMP port unreachable
message after attempting to forward a Request to the NAS.
> Sure for simple deployement scenarios like Dial up. But now we are
> talking about more sophisticated usage for RADIUS.
The existing RADIUS mechanisms work for all services. They are not just
> But this is not efficient. Why send an attribute or a set of attributes
> if they are not required by the Server?
RADIUS is a request/response protocol. There is no way for a NAS to know
what the RADIUS server requires before sending an Access-Request.
> For one I need to be assured that the NAS supports the mandatory
That's relatively simple though -- a NAS can signal support for the
extended format with a single attribute.
> I may support NAS Filter Rule but only some of its options.
To date, RADIUS documents have focused on a single subject and included
clear guidelines about what is needed to be considered compliant. As an
example, RFC 2868 is focused on tunnel attributes, so that a vendor can
indicate that they are compliant with it, without being forced to
implement attributes relating to a different capability.
Similarly, existing RADIUS attributes are typically either implemented or
not implemented. If an attribute covers divergent capabilities so that
vendors are unlikely to fully implement it within a single device, I would
argue that that attribute should be broken down into distinct attributes,
each with a unitary purpose.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.