[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Capabilities negotiation problem statement
Please see inline...
> -----Original Message-----
> From: email@example.com
> [mailto:firstname.lastname@example.org] On Behalf Of Bernard Aboba
> Sent: Saturday, August 27, 2005 7:27 AM
> To: email@example.com
> Subject: 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 problem.
> 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.
I am aware of that but this is inefficient! It requires that we send a
message and try. It is more efficient if we know up front via a
> > 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 for "dialup".
In some cases they don't work at all and in other cases they work but
> > 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
But in subsequent interaction for that session -- either in accounting
or in subsequent requests or in issuing commands such as proposed by LOG
OFF then the Server can indicate what it may desire.
> > For one I need to be assured that the NAS supports the mandatory
> > semantics.
> That's relatively simple though -- a NAS can signal support
> for the extended format with a single attribute.
Ahhhhh so you do support a capability exchange!!! I thought you didn't.
So we have at least one.
> > 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.
Not true. Is 2865 focused? Is 2869 focused? I would even argue that 3576
presents two different capabilities, DM and COA Each may be supported
> 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.
Ideally sure but in some cases it is not possible to split a complex AAA
application into smaller RFCs just to stay true to that ideal.
Diameter CC is a perfect example of that. Not all the features will be
implemented by a given vendor or even be ever be implmented by anyone.
> 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 unitanry purpose.
You mean like user-name? Perhaps let user-name carry the actual user
name and have another attribute carry the routing information? I would
> to unsubscribe send a message to
> firstname.lastname@example.org with the word 'unsubscribe' in
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.