Re: Summary of WG review of "RADIUS over TCP" document

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
>> I would prefer to leave the discussion of Status-Server && RADIUS ID
>> use in this document. The traditional use of Status-Server is over UDP,
>> and therefore does not have the issues presented here. (i.e. suggestion
>> to reserve one RADIUS ID per TCP connection for Status-Server.)
> 
> Why should the ID be unique regardless of packet code when run
> over reliable transport, but not UDP?  This suggests that the ID is
> being processed differently for unreliable vs. reliable transport, which
> seems odd.

  With UDP, there is no "connection" from client to server.  So any
Status-Server checks are sent from any client port.  This removes much
of the problem of reserving one ID: the client just opens another source
port.

  If it uses the same source port for Status-Server as for
Access-Request, then it would need to ensure that the ID allocated to
Status-Server is unused by any Access-Request.

  With TCP, there is a connection between client and server.  The
watchdog timer algorithm in RFC 3539 is defined per *connection*.  So an
ID has to be reserved, because the client can't open a new connection to
test if an existing connection is still alive.

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