Re: (usr-tc) RE: (USR-TC) RADIUS QUEST
Do you mean 6.09 ? If so, what about 6.08 ?
It's available in an Engineering Release, so you'll have to call tech support. (I know- another example of excess bureaucracy <g>). It is in the process of being posted as a service release. When this is completed you'll be able to grab it directly off of totalservice.3com.com. The Version is 6.0.83 and is available for WIndows. The more robust duplicate/out-of-order checking only affects accounting. Authentication still relies on packet identifier Steve jeff.binkley@asacomp.com (Jeff Binkley) on 10/13/99 08:13:00 AM Please respond to usr-tc@lists.xmission.com Sent by: jeff.binkley@asacomp.com (Jeff Binkley) To: USR-TC@LISTS.XMISSION.COM cc: (Steve Valiunas/MW/US/3Com) Subject: (usr-tc) RE: (USR-TC) RADIUS QUEST 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. - 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.
Thus spake Steve Valiunas
Do you mean 6.09 ? If so, what about 6.08 ?
It's available in an Engineering Release, so you'll have to call tech support. (I know- another example of excess bureaucracy <g>).
Heh...I really don't mind calling tech support for ER's, it just kinda annoyed me that tech support now has to go get permission from someone else to give them out. :) And even that doesn't *terribly* bother me...at least not on its own...its just a single fairly small example of the larger problem. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - 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.
participants (2)
-
Jeff Mcadams -
Steve Valiunas