[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Review of draft-lior-radext-end-to-end-caps-01.txt
Submitter name: Alan DeKok
Submitter email address: aland@ox.org
Date first submitted: August 31, 2005
Reference:
Document: draft-lior-radext-end-to-end-caps-01.txt
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:
In section 1.1, there are multiple references to "the network", and
what "the network" knows or wants. It would be better (if possible)
to refer to specific entities or devices in the network. This would
allow the document to define what devices it's talking about, and what
the requirements are for those devices.
The text in Section 2 makes it difficult to determine who has SHOULD
versus MAY versus MUST for the capabilities. Suggestions are offered
below.
Section 2 paragraph 3 says:
"A NAS that requires certain capabilities from the
RADIUS server SHOULD include the End-to-End-Capability attribute
indicating which capabilities MUST be delivered by the RADIUS server."
There appears to be a conflict between "SHOULD" and "MUST". If the
RADIUS server MUST deliver certain capabilities, it MUST know that
it's supposed to do that. Barring local configuration changes by an
administrator, the only way for it to know it MUST provide
capabilities is for the NAS to inform it.
I suggest changing the SHOULD to a MUST.
Section 2 paragraph 3 says:
"the NAS MAY reject subsequent replies from the RADIUS server"
I'm not sure what this means, as there is no such concept in
RADIUS. Perhaps "the NAS MAY ignore subsequent replies", or "the NAS
MAY stop talking to the RADIUS server"? I don't understand the
failure modes here. It looks like the NAS will just stop talking to
the RADIUS server, with possibly no recourse to another server.OB
But I don't see why it would be necessary for a NAS to ignore a
RADIUS server. The NAS may require certain information for some
sessions and not others, in which case it should keep talking to the
RADIUS server. If the NAS requires certain information for all
sessions, and the RADIUS server doesn't supply it, that would appear
to be a protocol incompatibilty, and the devices will never
communicate. So text in the draft to deal with this case don't appear
to help implementations or deployments.
Section 2 paragraph 5 says:
"the RADIUS server MAY
specifiy which capabilities that it requires from the NAS."
If the capabilities are required, then I suggest that the MAY be
changed to a MUST
Section 2 paragraph 5 say:
"If the capabilities are not delivered to the RADIUS
server, the RADIUS server MAY reject the session."
If the capabilities are required (as indicated above), then the MAY
above should be changed to a MUST.
The text from Section 2 is awkward, and it's difficult to figure out
who has what MAY, SHOULD, or MUST. I suggest using the following
table. It is a 2-dimensional matrix, where the RADIUS server and NAS
can look up their respective values for a capability, and determine
how to proceed with the request.
RADIUS Server
unsupported Supported Required
unsupported pass-1 pass-1 fail
NAS Supported pass-1 pass-2 pass-2
Required fail pass-2 pass-2
Results: fail = incompatible capabilities, access is rejected
pass-1 = backwards compatibily, capability is unused
pass-2 = both parties implement the capability
Section 2 describes the format for capabilities. The string of bit
pairs is unusual. It may be difficult to extend to future
capabilities, and isn't amenable to compact representation. e.g. "I
support capabilities 5, 100, and 200). I hesitate to suggest
run-length encoding as a solution, however.
There's an errant "SHALL" in the "String" description at the top of
page 5. It should probably be a "MUST".
The table on page 6 seems to say that the NASes can't indicate
UNSUPPORTED. i.e. It says "The NAS MAY indicate SUPPORTED only". The
MAY's here should be MUST's, i.e. "MUST indicate one of SUPPORTED or
UNSUPPORTED only".
Similarly, saying "MAY indicate SUPPORTED and REQUIRED" is
imprecise. I suggest "MUST indicate one of UNSUPPORTED, SUPPORTED, or
REQUIRED".
Going through the table on page 6 in detail, my comments on the
capabilities are:
1: this is superfluous. Implementations signal this by using RADIUS.
2: this is mostly superfluous. If the NAS doesn't support
accounting, it will never send accounting packets, and the RADIUS
server should figure it out. There is no use-case shown as to how
this capability would benefit RADIUS.
3: I'm not sure what the error conditions are here. It's nice for a
NAS to signal to a RADIUS server that it supports tunnel attributes,
but again no use-case or benefit is shown. What problem does this
feature solve?
4: If a NAS doesn't support Disconnect-Message, it won't ACK or NAK
the Disconnect-Request, and the server will figure it out.
5: Same comment as above.
6: Why would the NAS require chargeable user ID? Can a RADIUS server
require CUI?
7-17, no comments.
Summary
-------
The capabilities exchange may be useful, but I would like to see an
analysis of it's impact on RADIUS exchanges, as discussed on the list.
i.e. If the NAS requires a capability, it has to advertise it in an
Access-Request packet, so the RADIUS server will see that capability.
There appears to be no provision in the document for an ACK of a
REQUIRED capability. I'm not sure how both ends can then agree on
what services are required and offered.
I would expect that anything other than an explicit ACK of any
REQUIRED capabilities MUST be treated as an Access-Reject.
If the RADIUS server can send capabilities to the client, then the
use of Access-Challenge would seem to be required. i.e. Even for
requests containing User-Password, capability exchange and agreement
may require at least one Access-Request/Access-Challenge cycle. If
the NAS does not support a capability, it will treat the
Access-Challenge as a Reject. Otherwise, it will have to continue the
capability exchange.
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/>