U>Aaron & Corneliu, U>>RFC states as clear as posibile: "For retransmissions where the U>contents >are identical, the Identifier MUST remain unchanged.". U>And the RFC warns just as clearly in the next sentence: " Note that if U>Acct-Delay-Time is included U>in the attributes of an Accounting-Request then the Acct-Delay-Time U>value will be updated when U>the packet is retransmitted, changing the content of the Attributes U>field and requiring a new U>Identifier and Request Authenticator." U> If you look closer at the retransmitted accounting packet you will U>notice that U>it is NOT identical, due to U>this fact. Therefore the packet MUST have a new identifier. U>>My question: how is suposed a Radius server to identify the U>duplicates? U> This is a tough one- U> The radius server needs to be able to overcome the shortcomings of U>the radius protocol. It Can't rely simply on a single field that U>allows only values of 1 to 254 to decide if it's seen a packet before. U>Imagine a busy server- taking 1000 or more requests a second... U> One solution might be for the server to build it's own key- based on U>NAS_IP, SESSION_ID, and USER_NAME for example. That would make the U>packets pretty unique in most situations. This is the method used by U>the latest version of 3Com's security server. Do you mean 6.09 ? If so, what about 6.08 ? Jeff Binkley ASA Network Computing U> Thanks, U> Steve_valiunas@3com.com CMPQwk 1.42 9999 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.