Subject: RFC 4672 & 4673 issues and errata

From: Alfred Hönes <[email-masked]>
Date: Mon, 6 Nov 2006 22:33:47 +0100 (MEZ)

Hello,
after studying the recently published RFCs on RADIUS related
MIB modules, I would like to send to you, the authors of
RFC 4672 and RFC 4673, a few additional comments on these RFCs.

As there are some general/important issues raised in this message
(see items (1)..(3) below), I have copied it to Bert Wijnen for
the MIB doctors.

Item (3) details an apparently severe structural inconsistency
in both specifications.

(0)

Another, general issue has been dealt with in another message
already sent to you, the authors of RFC 4668..4671, and Bert Wijnen.
For completeness, I repeat the list of related objects within
your RFCs:

- radiusDynAuthServerID
    in the RADIUS-DYNAUTH-CLIENT-MIB, RFC 4672, page 7

- radiusDynAuthServerIdentifier
    in the RADIUS-DYNAUTH-SERVER-MIB, RFC 4673, page 6

(1)  abuse of defined terms

In the titles and the text body of both RFCs, a very 'popular'
clash of terms shines up.

As specified in RFC 3410 and Part 1 of STD 62, RFC 3411, and
re-stated in the boilerplate Section 3, "The Internet-Standard
Management Framework", of both RFCs, there's just one single
Management Information Base (MIB) comprised of various "MIB modules".
Thus, throughout the titles and the text bodies of the RFCs, the
proper term, "RADIUS ... MIB module" should be used consistently,
instead of the rather sluggish "RADIUS ... MIB".

(2)  OID hierarchy

I am surprised that the 'OID anchor' of the RADIUS-DYNAUTH-xxx-MIB
modules does not match the OID hierarchy used in the other RADIUS
MIB modules published/updated concurrently.
I would have expected the new RADIUS MIB modules to be assigned OIDs
in the following, hierarchical way (using abbreviated notation):

  radiusMIB                  { mib-2 67 }  -- legacy, assigned by IANA
  radiusDynAuth              { radiusMIB 3 }       -- new
  RADIUS-DYNAUTH-CLIENT-MIB  { radiusDynAuth 1 }   -- new
  RADIUS-DYNAUTH-SERVER-MIB  { radiusDynAuth 2 }   -- new

instead of obtaining separate IANA assignments for the MIB module
OIDs, directly under mib-2.

Has there been a strong reason for this deviation from the established
pattern?

(3)  severe MIB module structural problem
     -- issue instantiated similarly in both RFCs

Let's start with RFC 4672 and the RADIUS-DYNAUTH-CLIENT-MIB module.

On page 5 of RFC 4672, two module-global scalar objects are specified;
the DESCRIPTION clause of the
radiusDynAuthClientDisconInvalidServerAddresses OBJECT-TYPE says:

                                           [...].  This counter may
                 experience a discontinuity when the DAC module
                 (re)starts, as indicated by the value of
                 radiusDynAuthClientCounterDiscontinuity."

and the literally same sentence appears again in the DESCRIPTION
clause of the radiusDynAuthClientCoAInvalidServerAddresses OBJECT-TYPE.

This would make sense iff radiusDynAuthClientCounterDiscontinuity
would have been defined as another module-global scalar MIB object.
But unfortunately, radiusDynAuthClientCounterDiscontinuity is a
tabular row object in the radiusDynAuthServerTable, with separate
instances for every radiusDynAuthServerIndex instantiated there.
So, which object instance should be taken for reference ???
Moreover, should ever the radiusDynAuthServerTable be empty,
no such CounterDiscontinuity objects would be instantiated,
invalidating the semantical integrity of the MIB module.

Thus, let's take a closer look at the DESCRIPTION clause of the
radiusDynAuthClientCounterDiscontinuity OBJECT-TYPE, on page 17
of the RFC:

          DESCRIPTION
                "The time (in hundredths of a second) since the
                 last counter discontinuity.  A discontinuity may
                 be the result of a reinitialization of the DAC
                 module within the managed entity."

It remains unclear which scope was intended, i.e. whether "the last
counter discontinuity" was meant to just cover the counters within
the same conceptual row of the table, of it was meant to cover all
the counter objects in the MIB module.
If the former interpretation is to be accepted, the references
to this object from the scalar objects' DESCRIPTIONS quoted above
would be severely ambiguous.
In case of the latter interpretation, the semantics of this object
indeed do not depend in any way on the conceptual row, i.e. the
related radiusDynAuthServerIndex instance; but if an object of
the same semantics appears in every table row instantiated, all
of its instances must have the same value at any point in time.
Hence, the object with that semantics should have been modeled
as a module-global scalar object, and not as a tabular object !!!

IMHO, such a single, module-global scalar object would perhaps be
sufficient for the desired purpose.

In a similar way, the module-global scalar counters in the
RADIUS-DYNAUTH-SERVER-MIB module,
radiusDynAuthServerDisconInvalidClientAddresses and
adiusDynAuthServerCoAInvalidClientAddresses,
as specified on page 6 of RFC 4673, refer to the object,
radiusDynAuthServerCounterDiscontinuity,
which turns out to be a tabular row object in the
radiusDynAuthClientTable, not another scalar object,
thus leading to the same kind of ambiguity.

Taken altogether, the specifications are ambigous and will certainly
lead to interoperability problems.

I strongly propose to revise these MIB module specifications as
soon as possible.

(3')  Note:

Why not using, in the text above, the common ISO-standard
unit-multiple name, "centiseconds" (abbreviation: "cs"),
instead of the long-winded "hundredths of a second" ?

This applies to the UNITS and the DESCRIPTION clauses of
  - radiusDynAuthClientRoundTripTime         (RFC 4672, page 7),
  - radiusDynAuthClientCounterDiscontinuity  (RFC 4672, page 17),
  - radiusDynAuthServerCounterDiscontinuity  (RFC 4673, page 17),
  and (for information only:)
  several objects in RFC 4668..4671 as well.

(4)  erratum: repeatedly occurring spurious text in RFC 4672

The DESCRIPTION clauses of several OBJECT-TYPE invocations in RFC 4672
contain the same spurious fragment of a sentence:

   [...].  Disconnect-NAK packets received from unknown addresses.

This fragment apparently has been copied inadvertently from the
DESCRIPTION clause for radiusDynAuthClientDisconInvalidServerAddress,
and it should be deleted afterwards, in all instances:

  - radiusDynAuthClientCoAInvalidServerAddresses  (page 5),
  - radiusDynAuthClientDisconRequests  (page 8),
  - radiusDynAuthClientDisconAuthOnlyRequests  (page 8), and
  - radiusDynAuthClientDisconRetransmissions  (page 8).

(5)  erratum: word omission in RFC 4673

The DESCRIPTION clause of the radiusDynAuthServCoAUserSessChanged
OBJECT-TYPE, on page 15 of RFC 4673, says:

       DESCRIPTION
             "The number of user sessions authorization
              changed for the CoA-Requests received from this
              Dynamic Authorization Client.  [...]

For clarity, it should perhaps better say:

                                         vvvvvv
       DESCRIPTION
|            "The number of user sessions with authorization
              changed for the CoA-Requests received from this
              Dynamic Authorization Client.  [...]

[or use similar wording].

I leave it to your decision as to which of the items listed above
should be addressed by an RFC Errata Note submitted to the
RFC-Editor's RFC Errata web page (please make freely use of the
material presented above), or otherwise filed for consideration
in any future update to these RFCs.
But, as stated above with item (3), perhaps an immediate revision
of the MIB modules should be considered seriously.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+