[radext] #56: Review

["radext issue tracker" <trac@tools.ietf.org>]

#56: Review
---------------------------------------+------------------------------------
 Reporter:  aland@â                    |       Owner:            
     Type:  defect                     |      Status:  new       
 Priority:  major                      |   Milestone:  milestone1
Component:  radsec                     |     Version:  1.0       
 Severity:  Active WG Document         |    Keywords:            
---------------------------------------+------------------------------------
 I'd also suggest auditing it for "RADIUS over FOO".  That should be
 changed to "RADIUS/Foo", e.g.

 2.  Normative: Transport Layer Security for RADIUS over TCP

   to

 2.  Normative: Transport Layer Security for RADIUS/TCP

   and

 8.  Acknowledgements

    RADIUS over TLS ...

 to

    RADIUS/TLS

   and

 RADIUS has no notion of negotiating TLS in an established connection.
 Servers and clients need to be preconfigured to use RADIUS/TLS for a
 given endpoint.

    to

 RADIUS/TLS has no notion of ....

   Also, the reference names could be changed:

 [I-D.dekok-radext-tcp-transport]  is now "draft-ietf".  Not a big issue,
 but useful to change.

   There should also be an RFC editor note that the draft has a normative
 requirement on the TCP transport draft.

   The "connection backoff" algorithm should really be standardized:

    The proxy will at startup try to establish a TLS connection to each
    (if any) of the configured RadSec (TLS) servers.  If it fails to
    connect to a server, it will retry regularly.  There is some back-off
    where it will retry quickly at first, and with longer intervals
    later.


   See the Status-Server draft, which had a lot of feedback over the
 backoff algorithms it discussed.  I'm not proposing to use the same
 method here.  I'm suggesting that *something* should be defined,
 otherwise other reviewers will suggest defining the backoff algorithm.

   The backoff algorithm should also be mentioned in the "Security
 Considerations" section.  Bad clients that hammer a server can result in
 a DoS attack.

-- 
Ticket URL: <https://wiki.tools.ietf.org/wg/radext/trac/ticket/56>
radext <http://tools.ietf.org/radext/>


--
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/>