Question on reliable transports

[Alan DeKok <aland@deployingradius.com>]

  I've been working on the TCP && DTLS drafts, and have a few questions
for a wider audience, especially those with experience deploying RadSec.

  First, there appears to be a fair bit of overlap between the
discussion of TCP as a reliable transport, and the reliable transport
offered by DTLS.  Many of the issues surrounding lack of retransmission,
transport-layer "connections", etc. are the same.

  My thought was to slightly re-target the TCP draft to be a "RADIUS
over reliable transport" draft.  The result would be a draft that
applies to both TCP and DTLS, and possibly to future reliable transports
for RADIUS.  Any TLS issues would be left to the DTLS draft, which could
then concentrate on security, rather than on reliable transport.

  Does this approach seem reasonable to the list?  The drafts are still
individual submissions, but the may be WG drafts at some point in the
future, so obtaining consensus now would be a positive step.

  The second issue is what to do about accounting over reliable
transport.  Accounting-Request packets that do not get "accepted"
silently fail with the server failing to respond to the client.  i.e.
there is no Accounting-NAK packet in RADIUS.

  The issue here is that this behavior severely limits the utility of
reliable transport.  If the accounting server does not ACK a series of
Accounting-Request packets, then the client must wait for timeouts
before re-using the request ID's.  When coupled with the limit of 256
packets being sent over one connection, these limits may result in an
upper bound of only a few packets/s.

  How do these issues affect real-world deployments of RadSec?  Is it a
problem?  If so, is a solution required?

  Alan DeKok.

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