[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Capabilities: Moving forward
Here is the motivation statement for capabilities exchange with some
added text to provide further explanations.
There is a need for a RADIUS server to discover capabilities of a NAS
that has initiated a connection to it.
The RADIUS server may require that the NAS supports a particular
RADIUS application.
For example, if the user being authenticated and authorized is a
prepaid
user, then the RADIUS needs to be assured that the NAS supports
prepaid capabilities as defined in [I-D.lior-radius-prepaid-
extensions].
This is critical to correct operation. Because if the user is a
prepaid user, then the AAA server will reply back to the NAS with
authroization attributes that are designed to control the prepaid
session (see the prepaid work). If the NAS does not support these
attributes the NAS will simply ignore the attributes. This will result
with the prepaid user getting free service.
***
Whether or not a NAS supports a particular capability could impact if
the user is allowed on the network; or which attributes are delivered
and perhaps the value of those attributes;
We therefore need a mechansim for the NAS to indicate with Applications
it supports.
***
Similarly, the network may need to know whether or not the NAS supports
a particular RADIUS feature such as Dymanic Authorization Extensions as
defined in [RFC3576].
This is more from an efficiency point of view and may also be required
for correct operation.
Using 3576 as an example. AAA server may wish to terminate a session.
If it knows that the NAS does not support 3576 it can use
Session-Timeout to have the NAS periodically re-authenticate and those
can control to some degree when it will terminate the session. However,
if it knows that the NAS supports 3576 DM messages then the AAA server
knows it can count on the DM message to percisely disconnect the
session.
Not having this knowledge if the AAA assumed that it can use 3576 it
will issue a DM message and the NAS which does not support 3576 would
reply back with an ICMP message indicating that that port is not in use
(or something like that). This is information is not useful since the
user session has already been allocated and we just found out that the
NAS does not support DM messages.
The same scenario could be used to illustrate why its important to know
that the NAS supports 3576 CoA messages.
***
Knowing the that a NAS supports a particular feature is very helpful.
It helps the AAA determine which features can be used to control the
session.
We therefore need a mechanism for the NAS to indicate which RADIUS
features it supports
***
In some cases, the NAS itself may also need to communicate that it
requires that the RADIUS server deliver a particular capability.
For example, the *NAS* may require that the server deliver the
Chargeable User Identity attribute as defined in [I-D.ietf-radext-
chargeable-user-id]. Here the NAS not only indicates that it can
support the CUI but requests that the CUI *MUST* be provided otherwise
it will reject the session.
***
Having a way for the NAS to specify that the Server needs to provide it
with some infomration is also useful.
We therefore need a scheme to have the NAS indicate to the Server that
it needs particular infomration.
***
Similarly, the RADIUS server may require that the NAS deliver certain
feature that the RADIUS server requires for the session.
For example, the network may require that the NAS deliver location
information as defined by [I-D.ietf-geopriv-radius-lo] before it can
authenticate the session.
In this case it the NAS would advertize support for particular
application or information. The NAS does not have to provide that
information in the Access-Request. A RADIUS server can then subscribe
to the particular information by challenging the NAS to provide the
information.
The NAS should be able to request the information either during the
initial authentication -- since the availablity of the information may
determine whether or not the user is authenticated or whether or not the
user will be provided with a certain capabilities.
****
We therefore need a scheme to have the NAS indicate what it supports and
a scheme for RADIUS Server to request that the NAS provide that
information. This needs to be provided for during the initial
access-request or subsequently by using CoA etc...
****
In summary:
o The NAS to specify which capabilities it supports.
o The NAS to specify which capabilities that are required to be
delivered by the RADIUS server.
o The RADIUS server to express the capabilities desired from the
NAS.
o The RADIUS server to express the capabilities that the RADIUS
server requires from the NAS.
NOTE:
The End-to-End-Capability is different then the capability exchange
defined in Base Diameter [RFC3588]. The purpose of the Diameter based
capability exchange is
support routing of Diameter messages. Whereas, the functionality
defined by here is designed to ensure whether we can send an
attribute or command or expect a behavior relating to this specific
user's session.
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Bernard Aboba
> Sent: Tuesday, October 18, 2005 12:14 AM
> To: radiusext@ops.ietf.org
> Subject: Capabilities: Moving forward
>
> >I do agree with Bernard that we first need to come to
> consensus on the
> >problem statement. I think your summary, quoted above, is one
> >reasonable candidate.
>
> After dozens and dozens of messages, there is very little to
> show for the discussion of Capabilities Solutions, so it's
> time to take a step backward and focus for a while on The
> Problem. Let's all take a breather from solution discussions
> for a while.
>
> I'd note that we've taken this approach before in RADEXT WG,
> with encouraging results. Discussion on the CUI document
> seemed hopelessly wedged until we were able to focus on the
> problem statement, which turned out to be relatively straight forward.
>
> A good problem statement is not just the union of all
> possible needs;
> shopping lists make poor design documents. Rather, a good problem
> statement seeks to get at the one or two core issues, which,
> if addressed, will enable solution of mutiple important problems.
>
> As a result, the goal in coming up with a problem statement
> is not to enumerate every possible corner condition and
> scenario, regardless of relevance; doing so will merely
> drive the development of as complex and unwieldly a solution
> as possible.
>
> Rather, the hallmark of a good problem statement is brevity,
> leading to solutions which do what is necessary and little more.
>
>
>
> --
> 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/>
>
--
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/>