Re: I-D Action:draft-ietf-radext-radsec-07.txt

[Alan DeKok <aland@deployingradius.com>]

Stefan Winter wrote:
> this rev should fix trac item #4, and all except two points in #3:

  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.

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