|
The suggested approach seems reasonable to me. This is more or less the same reasoning that led to having RFC 3539 cover SCTP as well as TCP. > Date: Sun, 5 Oct 2008 16:34:16 +0200 > From: aland@deployingradius.com > To: radiusext@ops.ietf.org > Subject: Question on reliable transports > > 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/> |