Aaron & Corneliu,
RFC states as clear as posibile: "For retransmissions where the contents are identical, the Identifier MUST remain unchanged.".
And the RFC warns just as clearly in the next sentence: " Note that if Acct-Delay-Time is included in the attributes of an Accounting-Request then the Acct-Delay-Time value will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator." If you look closer at the retransmitted accounting packet you will notice that it is NOT identical, due to this fact. Therefore the packet MUST have a new identifier.
My question: how is suposed a Radius server to identify the duplicates?
This is a tough one- The radius server needs to be able to overcome the shortcomings of the radius protocol. It Can't rely simply on a single field that allows only values of 1 to 254 to decide if it's seen a packet before. Imagine a busy server- taking 1000 or more requests a second... One solution might be for the server to build it's own key- based on NAS_IP, SESSION_ID, and USER_NAME for example. That would make the packets pretty unique in most situations. This is the method used by the latest version of 3Com's security server.
But later, when it comes time to send another request, it has "forgotten" that it previously incremented the identifier and merrily uses the last one again!
Can you send along an example of this happening (using the same packet-ID twice in a row for the same destination port and with current HiperArc code)? If it is an issue it will be fixed. Keep in mind though that it only takes a couple hundred packets to wrap back around and reuse the same ID again.
The Radius server is supposed to contact the System Administrator and get him to purchase products from a vendor that knows how to read a RFC, or, failing that, at least fixes problems when they are pointed out to them.
What exactly was it that 3com missed in the RFC? You can send the trace directly to me if you don't want to post to the list. Thanks, Steve_valiunas@3com.com Aaron Nabil <nabil@spiritone.com> on 10/12/99 08:14:07 PM Please respond to usr-tc@lists.xmission.com Sent by: Aaron Nabil <nabil@spiritone.com> To: usr-tc@lists.xmission.com cc: (Steve Valiunas/MW/US/3Com) Subject: Re: (usr-tc) Radius question Corneliu Rudeanu writes...
I was really surprised to see how HARC deals with the radius packet identifier.
RFC states as clear as posibile: "For retransmissions where the contents are identical, the Identifier MUST remain unchanged.".
Yet watching (monitor radius) the id-s of the packets being retransmited I found that hiperArc (4.2.29) assigns diferrent id for the packets being re-sent to radius server for the same accounting request.
Hah! It's much better than that! (Note the date, too!)
From: Aaron Nabil <nabil@spiritone.com> Subject: (usr-tc) HiperArc BUG, doesn't increment identifier after re-transmit Date: 14 Jun 1998 16:58:15 -0700 (PDT)
The HiperArc has a nasty Radius bug.
If a packet get lost in transit or for some other reason is never acknoweldged, the HiperArc increments the identifier and tries sending it again after the timeout period.
But later, when it comes time to send another request, it has "forgotten" that it previously incremented the identifier and merrily uses the last one again!
Not only does it incorrectly increment the identifier, it then goes on to re-use the same identifier again later! Yes, this is so incredibly broken it's not even imaginable that it hasn't been fixed. But it hasn't.
My question: how is suposed a Radius server to identify the duplicates?
The Radius server is supposed to contact the System Administrator and get him to purchase products from a vendor that knows how to read a RFC, or, failing that, at least fixes problems when they are pointed out to them. -- Aaron Nabil - 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. - 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.