[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[radext] #9: AD review (technical)
#9: AD review (technical)
Reporter: dromasca@â | Owner: aland@â
Type: defect | Status: new
Priority: major | Milestone: milestone1
Component: tcp-transport | Version: 1.0
Severity: Submitted WG Document | Keywords:
Date first submitted: March 9, 2010
Please find below the AD review of AD review of
draft-ietf-radext-tcp-transport-05. I believe that the document will be
ready for IETF Last Call only after the issues raised in this review are
The issues are divided into Technical (T) and Editorial (E).
T1. The document is marked as EXPERIMENTAL. It would be useful if it
mentions in one of the introductory sections what are the goals and
limitations (if any) of the experimental deployment and what would be
the success criteria of the experiment that would allow for taking the
document to the standards track later.
T2. Section 2.2:
> Since these ports are unused by existing RADIUS implementations, the
assigned values SHOULD be used as the default ports for RADIUS over
Why is this a SHOULD and not a MUST?
T3. Section 2.3 needs a complete re-writing:
> The MIB Module definitions in [RFC4668], [RFC4669], [RFC4670],
[RFC4671], [RFC4672], and [RFC4673] each contain only one reference
to UDP. These references are in the DESCRIPTION field of the MIB
Module definition, and are in the form of "The UDP port" or "the UDP
Actually the count is not accurate. 4688 and 4670 have each two MIB
objects that refer to UDP ports, 4669 and 4671 have none, 4672 and 4673
have one each, but only in 4672 the port is referred to as UDP port
(although it is clear from the context that UDP is assumed).
> Implementations of RADIUS over TCP SHOULD re-use these MIB Modules to
perform statistics counting for RADIUS over TCP connections.
However, implementors are warned that there is no way for these MIB
Modules to distinguish between packets sent over UDP or over TCP
This does not work. One cannot know what current implementations do.
Some may behave as described here, but other may not and could count
statistics strictly over UDP as defined in the DESCRIPTION of the MIB
objects. You cannot count on that the agent implementations will do, so
there is no interoperability.
> Implementations of RADIUS over TCP SHOULD include the protocol (UDP)
or (TCP) in the radiusAuthServIdent, radiusAuthClientID,
radiusAuthClientIdentifier, radiusAccServIdent, radiusAccClientID, or
radiusAccClientIdentifier fields of the MIB Module. This information
can help the administrator distinguish capabilities of systems in the
This is also broken. First it is a change in the semantics of the
respective objects. This cannot be done even in a MIB document that
updates the respective RFCs because of the SMIv2 rules. Then these
objects are of a syntax of SnmpAdminString - so including the protocol
is based on non-interoperable heuristics. Last, describing the
capabilities (UDP, TCP or both) does not indicate what runs and is
activated at a certain moment, not to speak cannot indicate anything
about specific sessions between clients and servers.
The correct solution is for the MIB documents to be updated in the
future with new MIB objects of appropriate syntax. For the time being
the only thing that this section should say is that the MIB modules do
not support RADIUS over TCP and that they will need to be updated in the
T4. The following section in 2.6.1 is confusing:
> Much of the discussion in this section can be summarized by the
following requirement. RADIUS requests MAY be re-transmitted
verbatim only if the following 5-tuple (Client IP address, Client
port, Transport Protocol, Server IP address, Server port) remains the
Actually this is not a retransmission on the same connection, so I do
not know why it needs to be mentioned at all. This aparently contradicts
the first paragraph of 2.6.1 which says 'As TCP is a reliable transport,
implementations MUST NOT retransmit RADIUS request packets over a given
T5. The last paragraph in 2.6.1:
> The above requirement is necessary, but not sufficient in all cases.
Other specifications give additional situations where the packet is
to be considered as a new request. Those recommendations MUST also
Having a MUST requirement over undefined 'other specification' is not
implementable. I would suggest to either clarify what are these 'other
specifications' or take this out.
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/9>
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.