Hi, > Partly psychological... people are more likely to read a "RADIUS over > TCP" document than an "AAA over TCP" document. Also, standardizing TCP > as a RADIUS transport would require the publication of *some* kind of > document, if I understand the IETF process correctly. We couldn't just > announce that it's OK... The draft currently already references 3539, in section "Connection Keepalive": " A RadSec node which initiates a RadSec connection SHOULD send the Status-Server packets defined in [10] according to the state machine in section 3.4 of [6] since RadSec operates on a reliable transport protocol." where [6] is a reference to 3539. That text could be made more explicitly though, and reference 3539 as a whole, not just the one section with the state machine. > The "RADIUS over TCP" document could reference existing RADIUS > practices, and explain in excruciating detail why they won't work for TCP. > > Also, some issues relating to RADIUS PDU's over a stream transport may > be discussed. e.g. receiving half a RADIUS packet and then a FIN is > *not* a problem. The MIB counters for > radiusAuthServMalformedAccessRequests should NOT be incremented. e.g. > receiving a PDU with malformed attributes means that the TCP connection > SHOULD be closed. > > Many RADIUS practices related to handling error cases require a PDU to > be "silently discarded". This won't work for TCP. The connection has > to be closed, too. The existing RFC's have to be audited, and a new > document issued which explains the correct behavior. Sounds plausible. Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Attachment:
signature.asc
Description: This is a digitally signed message part.