Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
draft-ietf-radext-status-server-09

[Ballot comment]
Support Lars' discuss re: limiting message rates

If there is a reason to perform a major edit on this document, please consider splitting the "documenting what was deployed" and "recommending fixes" into clearly separate sections (if not documents).

[Ballot comment]
The document says:

  The "hop by hop" functionality of Status-Server packets is useful to
  RADIUS clients attempting to determine the status of elements on the
  path between the client and a server.

This should read: ... determine the status of the first element on the
path between ... (because you are not forwarding from the proxy and there
are no security associations from a client to proxies beyond the first
one, there is no way to test proxies 2 and onwards)

The document notes on the discussion of codes and port numbers:

  However, as the category of [RFC2866] is Informational, this conflict
  is acceptable.

This is merely a statement about the status of various RFCs. Personally,
the substantive change is that this new RFC would allow a new code
to be used on port 1813. I think it should do an "Updates: RFC 2866"
and get it over with.

[Ballot comment]
The document says:

  The "hop by hop" functionality of Status-Server packets is useful to
  RADIUS clients attempting to determine the status of elements on the
  path between the client and a server.

This should read: ... determine the status of the first element on the
path between ... (because you are not forwarding from the proxy and there
are no security associations from a client to proxies beyond the first
one, there is no way to test proxies 2 and onwards)

[Ballot comment]
Please consider the comments from the Gen-ART Review by Francis Dupont:

  - Abstract page 2: there is an explicit reference to a RFC, this is in
  general forbidden but IMHO we are here in the allowed exception case.

  - 2.1.1 page 8: a servers policy -> a server policy

  - 3 page 10 (twice): etc. -> etc., ???

  - 4.2 page 13: adminstrators -> administrators

  - 4.2 page 15 (twice): e.g. -> e.g.,

  - 4.3 page 16: modelled -> modeled

  - 4.3 page 16: usually the hysteresis against flapping tries to keep
  the connection (i.e., failover after 3 missed responses), here it is
  the opposite. IMHO it is very aggressive but it is how RFC 3539 works
  so I have no concern about it.

  - 4.5 page 16: Proxyhas -> Proxy has

  - 4.5 page 17: cannot, -> cannot

  - 4.5 page 18: i.e. -> i.e.,

  - 5 page 19: EAP-MEssage -> EAP-Message

  - 8 page 23: synthesise -> synthesize

  - 8 page 23: in "the suggestion of [RFC5080] Section 2.2.2, which suggests"
  suggests -> proposes

  - 8 page 23: configurably is not in my dict?

  - 9.2 page 23: IMHO the RFC2119 reference should be moved to normative
  references section (perhaps others too?)

  - Authors' Addresses -> Author's Address

[Ballot comment]
I support Peter's discuss. 

Additionally, I noted the same thing Peter did wrt to random numbers.

Section 3: In the Request Authenticator description the two paragraphs repeat that Request Authentication SHOULD be unpredictable and then says why. Maybe the second paragraph should be tweaked:

The Request Authenticator value in a Status-Server packet
SHOULD also be unpredictable **because** an attacker **could**
trick a server
into responding to a predicted future request, and then use the
response to masquerade as that server to a future Status-Server
request from a client.

[Ballot comment]
Given that the Request Authenticator should be unpredictable and unique, a reference to RFC 4086 would be appropriate.

Please add a reference to RFC 1321 for the definition of MD5.

[Ballot discuss]
Is the use of MD5 in generating the Response Authenticator subject to collision attacks? If not, it would be helpful to describe why not, and provide a reference to RFC 4270. If so, then the security considerations need to be updated.

[Ballot comment]
Given that the Request Authenticator should be unpredictable and unique, a reference to RFC 4086 would be appropriate.

Please add a reference to RFC 1321 for the definition of MD5.

[Ballot comment]
Section 1812., paragraph 4:

>    The server MAY prioritize the handling of Status-Server packets over
>    the handling of other requests, subject to the rate limiting
>    described above.

  Without congestion control, implementing this MAY guarantees that the
  minimum amount of useful (= non-Status-Server) work will be done.


Section 4.3., paragraph 3:
>    If no response is received to Status-Server packets, the RADIUS
>    client can initiate failover to another proxy.  By continuing to send
>    Status-Server packets to the original proxy at an interval of Tw, the
>    RADIUS client can determine when the original proxy becomes
>    responsive again.

  This uses Status-Server messages as an overload detection mechanism.
  They need to be sent in a way that will back off the rate
  under overload, because otherwise the scheme can turn into an
  overload *generation* mechanism.


Section 4.5., paragraph 17:
>    It is RECOMMENDED, therefore, that implementations desiring the most
>    benefit from Status-Server also implement server failover.  The
>    combination of these two practices will maximize network reliability
>    and stability.

  If Status-Server messages are being sent in a way that is congestion
  controlled (i.e., the rate is reduced under overload).

[Ballot discuss]
Section 4.1., paragraph 2:
>    The client SHOULD also have a configurable global timer (Tw) that is
>    used when sending periodic Status-Server queries during server fail-
>    over.  The default value SHOULD be 30 seconds, and the value MUST NOT
>    be permitted to be set below 6 seconds.  If a response has not been
>    received within the timeout period, the Status-Server packet is
>    deemed to have received no corresponding Response packet, and MUST be
>    discarded.

  DISCUSS: I would like to discuss two issues with this design. First,
  since it is only RECOMMENDED to implement Tw and not REQUIRED, clients
  need not do so. How do clients without Tw decide that a server has not
  responded?

  Second, there is no discussion on what rate clients should
  be using when *issuing* Status-Server queries. The current text allows
  a client to send Status-Server queries to the server at high rates,
  and does not require the client to reduce its sending rate when it
  receives no responses. In other words, there currently isn't any sort
  of congestion control. Has this been discussed by the working group?
  It seems like all the pieces are already there to implement a simple
  congestion control scheme: have clients issue at most one request per
  Tw (already implied by Section 4.3 text but not clearly stated
  anywhere), double Tw up to some conservative maximum when the server
  does not respond, restore the initial Tw when it does (Section 4.3
  again has some text that goes into that direction).

  (1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the document
      and, in particular, does he or she believe this version is ready
      for forwarding to the IESG for publication?

Bernard Aboba is the document shepherd.  I have personally reviewed
the document, and believe it is ready for publication as an Informational RFC.

  (1.b)  Has the document had adequate review both from key members of
      the interested community and others?  Does the Document Shepherd
      have any concerns about the depth or breadth of the reviews that
      have been performed?

This document specifies the Status-Server functionality
that has been implemented in the field.  Therefore, the major concern
is whether the document reflects existing implementations.  So
far the specification has been reviewed by the implementers of the
RADIATOR and FreeRADIUS servers, both of which support Status-Server.

  (1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective, e.g.,
      security, operational complexity, someone familiar with AAA,
      internationalization or XML?

No.

  (1.d)  Does the Document Shepherd have any specific concerns or
      issues with this document that the Responsible Area Director
      and/or the IESG should be aware of?  For example, perhaps he or
      she is uncomfortable with certain parts of the document, or has
      concerns whether there really is a need for it.  In any event, if
      the interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.

Status-Server is being published as an Informational RFC due to
limitations of the design which are documented in the Applicability
section.  However, the goal is to document what has
been implemented rather than re-designing it from scratch.

    (1.e)  How solid is the consensus of the interested community behind
      this document?  Does it represent the strong concurrence of a few
      individuals, with others being silent, or does the interested
      community as a whole understand and agree with it?

There is consensus within the RADEXT WG to publish the document as
an Informational RFC. 

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise the areas of conflict in
      separate email messages to the Responsible Area Director.  (It
      should be in a separate email because this questionnaire is
      entered into the ID Tracker.)

No.

    (1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are not
      enough; this check needs to be thorough.  Has the document met all
      formal review criteria it needs to, such as the MIB Doctor, media
      type and URI type reviews?

idnits is clean:

idnits 2.12.00

tmp/draft-ietf-radext-status-server-06.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see

  http://trustee.ietf.org/license-info):
----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt:
----------------------------------------------------------------------------

      No issues found here.

  Checking nits according to http://www.ietf.org/ID-Checklist.html:
----------------------------------------------------------------------------

      No issues found here.

  Miscellaneous warnings:
----------------------------------------------------------------------------

      No issues found here.

Checking references for intended status: Informational
----------------------------------------------------------------------------

    No issues found here.

    No nits found.
----------------------------------------------------------------------------
----

  (1.h)  Has the document split its references into normative and
      informative?  Are there normative references to documents that are
      not ready for advancement or are otherwise in an unclear state?
      If such normative references exist, what is the strategy for their
      completion?  Are there normative references that are downward
      references, as described in [RFC3967]?  If so, list these downward
      references to support the Area Director in the Last Call procedure
      for them [RFC3967].

The references in the document have been split into normative and
informative.

Normative references are all stable documents published as RFCs.

    (1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document?  If the document specifies protocol extensions, are
      reservations requested in appropriate IANA registries?  Are the
      IANA registries clearly identified?  If the document creates a new
      registry, does it define the proposed initial contents of the
      registry and an allocation procedure for future registrations?
      Does it suggested a reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis].  If the document
      describes an Expert Review process has Shepherd conferred with the
      Responsible Area Director so that the IESG can appoint the needed
      Expert during the IESG Evaluation?

The IANA considerations section (7) exists, and is consistent with
the body of the document.  Note that no new registries are created
nor does the document require assignment of any new protocol parameters,
since the Status-Server Code (12) was assigned in RFC 2865.

  (1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML code,
      BNF rules, MIB definitions, etc., validate correctly in an
      automated checker?

Not applicable.

  (1.k)  The IESG approval announcement includes a Document
      Announcement Write-Up.  Please provide such a Document
      Announcement Writeup?  Recent examples can be found in the
      "Action" announcements for approved documents.  The approval
      announcement contains the following sections:

      Technical Summary

This document specifies a deployed extenion to RADIUS which enables
clients to query the status of a RADIUS server.  While the
Status-Server Code (12) was defined as experimental in RFC 2865
Section 3, details of the protocol's operation have not been
documented until now. 

      Working Group Summary

This document has completed RADEXT WG last call, with the primary
areas of discussion relating to security and ID field usage.

The RADEXT WG elected to recommend this document for publication
as an Informational RFC rather than as a standards-Track RFC due
to concerns about problems with deployed implementations.  The
fixes recommended within the document are compatible with
existing servers that receive Status-Server packets, but impose new
security requirements on clients that send Status-Server packets.

      Document Quality

The document has been reviewed by IETF RADEXT WG members.
An expert review has been carried out by Ignacio Goyret.

Status-Server has been implemented by multiple vendors,
including RADIATOR, FreeRADIUS and Cistron.  It is currently
in use within EDUROAM, an educational roaming consortium
with more than one million users worldwide.  As
a result, the document reflects operational experience.

      Personnel

Bernard Aboba is the document shepherd for this document.
Dan Romascanu is the responsible AD.