RE: Last Call: draft-ietf-radext-status-server (Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol) to Informational RFC

Bernard Aboba <bernard_aboba@hotmail.com> Tue, 16 March 2010 01:16 UTC

Message-ID: <BLU137-W77528576E419A476C15AB932D0@phx.gbl>
Content-Type: multipart/alternative; boundary="_b857c37d-a77c-42ee-a748-36db7f90be31_"
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: ietf@ietf.org, ietf-announce@ietf.org
CC: "radiusext@ops.ietf.org" <radiusext@ops.ietf.org>
Subject: RE: Last Call: draft-ietf-radext-status-server (Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol) to Informational RFC
Date: Mon, 15 Mar 2010 18:13:24 -0700
Importance: Normal
In-Reply-To: <20100315194232.AC7A93A69BE@core3.amsl.com>
References: <20100315194232.AC7A93A69BE@core3.amsl.com>
MIME-Version: 1.0
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk

An editorial comment on Section 2. 

Section 2

   Status-Server packets are sent by a RADIUS client to a RADIUS server
   in order to test the status of that server.  A Message-Authenticator
   attribute MUST be included so as to provide per-packet authentication
   and integrity protection.  A single Status-Server packet MUST be
   included within a UDP datagram.  RADIUS proxies MUST NOT forward
   Status-Server packets.

   Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy
   or server, the destination of a Status-Server packet is set to the IP
   address of the server which is being tested.  As a result, the client
   is provided with an indication of the status of that server only,
   since no RADIUS proxies are on the path between the RADIUS client and
   server.  Since servers respond to a Status-Server packet without
   examining the User-Name attribute, the response to a Status-Server
   packet cannot be used to infer any information about the reachability
   of specific realms.

   A RADIUS server or proxy implementing this specification SHOULD
   respond to a Status-Server packet with an Access-Accept
   (authentication port) or Accounting-Message (accounting port).  An
   Access-Challenge response is NOT RECOMMENDED.  An Access-Reject
   response MAY be used.  The list of attributes that are permitted in
   Status-Server and Access-Accept packets responding to Status-Server
   packets are provided in the Section 6.

[BA] These three paragraphs are a bit disjoint.  Recommend changing it
to the following:

   Status-Server packets are sent by a RADIUS client to a RADIUS server
   in order to test the status of that server.   The destination of
   a Status-Server packet is set to the IP address of the server that
   is being tested.  A single Status-Server packet MUST be included 
   within a UDP datagram.  A Message-Authenticator attribute MUST be 
   included so as to provide per-packet authentication and integrity 
   protection. 

   RADIUS proxies or servers MUST NOT forward Status-Server packets.
   A RADIUS server or proxy implementing this specification SHOULD
   respond to a Status-Server packet with an Access-Accept
   (authentication port) or Accounting-Response (accounting port).  An
   Access-Challenge response is NOT RECOMMENDED.  An Access-Reject
   response MAY be used.  The list of attributes that are permitted in
   Status-Server and Access-Accept packets responding to Status-Server
   packets are provided in the Section 6.

   Since a Status-Server packet MUST NOT be forwarded 
   by a RADIUS proxy or server, the client is provided with an indication 
   of the status of that server only, since no RADIUS proxies are on the 
   path between the RADIUS client and server.  Since servers respond 
   to a Status-Server packet without examining the User-Name attribute, 
   the response to a Status-Server packet cannot be used to infer any 
   information about the reachability of specific realms. 





> To: ietf-announce@ietf.org
> From: iesg-secretary@ietf.org
> CC: radiusext@ops.ietf.org
> Subject: Last Call: draft-ietf-radext-status-server (Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol) to Informational RFC
> Date: Mon, 15 Mar 2010 12:42:32 -0700
> 
> The IESG has received a request from the RADIUS EXTensions WG (radext) to 
> consider the following document:
> 
> - 'Use of Status-Server Packets in the Remote Authentication Dial In User 
>    Service (RADIUS) Protocol '
>    <draft-ietf-radext-status-server-06.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> ietf@ietf.org mailing lists by 2010-03-29. Exceptionally, 
> comments may be sent to iesg@ietf.org instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-radext-status-server-06.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17334&rfc_flag=0
> 
> 
> --
> 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/>

Last Call: draft-ietf-radext-status-server (Use o… The IESG
RE: Last Call: draft-ietf-radext-status-server (U… Bernard Aboba