From owner-ietf-radius@portmasters.com Thu May 9 17:02:26 2002 Received: from portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08951 for ; Thu, 9 May 2002 17:02:26 -0400 (EDT) Received: (from majordomo@localhost) by portmasters.com (8.11.1/8.11.1) id g49JUDI20580 for ietf-radius-outgoing; Thu, 9 May 2002 14:30:13 -0500 X-Authentication-Warning: portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-ID: <00b101c1f79b$d6f33860$6b01a8c0@grumpy> From: "VICTOR MUSLIN" To: "ietf-radius" Subject: (radius) Proxy-State attribute Date: Thu, 9 May 2002 16:55:21 -0400 Organization: Prodigy Internet MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "VICTOR MUSLIN" Content-Transfer-Encoding: 7bit Is Proxy-State attribute widely supported by RADIUS accounting servers? Thanks. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri May 10 15:49:25 2002 Received: from portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14563 for ; Fri, 10 May 2002 15:49:24 -0400 (EDT) Received: (from majordomo@localhost) by portmasters.com (8.11.1/8.11.1) id g4AILJb01578 for ietf-radius-outgoing; Fri, 10 May 2002 13:21:19 -0500 X-Authentication-Warning: portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-ID: <00db01c1f85b$62e790e0$6b01a8c0@grumpy> From: "VICTOR MUSLIN" To: "Ruslan R. Laishev" Cc: "ietf-radius" References: <00b101c1f79b$d6f33860$6b01a8c0@grumpy> <3CDBE38F.40E42AB7@smtp.deltatel.ru> Subject: Re: (radius) Proxy-State attribute Date: Fri, 10 May 2002 15:46:27 -0400 Organization: Prodigy Internet MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "VICTOR MUSLIN" Content-Transfer-Encoding: 7bit Thanks. RFC notwithstanding, sometimes some features -- especially more esoteric ones -- are not implemented. What I was hoping is to get people's actual experiences with real RADIUS servers used. ----- Original Message ----- From: "Ruslan R. Laishev" To: "VICTOR MUSLIN" Cc: "ietf-radius" Sent: Friday, May 10, 2002 11:13 AM Subject: Re: (radius) Proxy-State attribute > Any RFC-compliant RADIUS server support this attribute. > > VICTOR MUSLIN wrote: > > > > Is Proxy-State attribute widely supported by RADIUS accounting servers? > > Thanks. > > > > - > > To unsubscribe, email 'majordomo@portmasters.com' with > > 'unsubscribe ietf-radius' in the body of the message. > > -- > Cheers, Ruslan. > +---------------------pure personal opinion------------------------+ > RADIUS Server for OpenVMS project - www.radiusvms.com > vms-isps@dls.net - Forum for ISP running OpenVMS > Mobile: +7 (901) 971-3222 > TKD (WTF) in Russia, St.-Petersburg - www.TaeKwonDo-WTF.SPb.RU > http://starlet.deltatel.ru/~laishev/public_pgp_key.txt - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Sat May 11 02:54:58 2002 Received: from portmasters.com (root@[216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19766 for ; Sat, 11 May 2002 02:54:57 -0400 (EDT) Received: (from majordomo@localhost) by portmasters.com (8.11.1/8.11.1) id g4B5ORK09499 for ietf-radius-outgoing; Sat, 11 May 2002 00:24:27 -0500 X-Authentication-Warning: portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-ID: <3CDCBF44.366157E2@smtp.deltatel.ru> Date: Sat, 11 May 2002 10:50:44 +0400 From: "Ruslan R. Laishev" Organization: StarLet Team X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: ru,en MIME-Version: 1.0 CC: ietf-radius Subject: Re: (radius) Proxy-State attribute References: <00b101c1f79b$d6f33860$6b01a8c0@grumpy> <3CDBE38F.40E42AB7@smtp.deltatel.ru> <00db01c1f85b$62e790e0$6b01a8c0@grumpy> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Ruslan R. Laishev" Content-Transfer-Encoding: 7bit VICTOR MUSLIN wrote: > > Thanks. RFC notwithstanding, sometimes some features -- especially more > esoteric ones -- are not implemented. What I was hoping is to get people's > actual experiences with real RADIUS servers used. For example, RADIUS-VMS is a server wich uses Proxy-State, Livingston 2.1 is another server wich support Proxy-State... -- Cheers, Ruslan. +---------------------pure personal opinion------------------------+ RADIUS Server for OpenVMS project - www.radiusvms.com vms-isps@dls.net - Forum for ISP running OpenVMS Mobile: +7 (901) 971-3222 TKD (WTF) in Russia, St.-Petersburg - www.TaeKwonDo-WTF.SPb.RU http://starlet.deltatel.ru/~laishev/public_pgp_key.txt - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Sun May 12 11:04:49 2002 Received: from portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19163 for ; Sun, 12 May 2002 11:04:49 -0400 (EDT) Received: (from majordomo@localhost) by portmasters.com (8.11.1/8.11.1) id g4CDXSG26636 for ietf-radius-outgoing; Sun, 12 May 2002 08:33:28 -0500 X-Authentication-Warning: portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f X-Originating-IP: [200.82.34.61] From: "Claudio Lapidus" To: victor@prodigy.net Cc: ietf-radius@portmasters.com Subject: Re: (radius) Proxy-State attribute Date: Sun, 12 May 2002 11:58:09 -0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 12 May 2002 14:58:09.0771 (UTC) FILETIME=[6E503BB0:01C1F9C5] Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Claudio Lapidus" On Fri, 10 May 2002 15:46:27 -0400, VICTOR MUSLIN wrote: >Thanks. RFC notwithstanding, sometimes some features -- especially more >esoteric ones -- are not implemented. What I was hoping is to get people's >actual experiences with real RADIUS servers used. From my own actual work experience, here you have a list of servers that make rutinary use of Proxy-State: - Cisco Access Registrar - Alcatel SMC - Lucent NavisRadius - Radiator Right now, I cannot recall for sure if Cistron and FreeRadius implement it too, but I remember to had run some tests about a year ago and I think they do. If this is important for you, I can go after the archived test protocols. Let me know. regards, cl. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri May 24 11:52:45 2002 Received: from portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03340 for ; Fri, 24 May 2002 11:52:44 -0400 (EDT) Received: (from majordomo@localhost) by portmasters.com (8.11.1/8.11.1) id g4OENoU10922 for ietf-radius-outgoing; Fri, 24 May 2002 09:23:50 -0500 X-Authentication-Warning: portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-ID: <002901c2033a$45517cf0$6b01a8c0@grumpy> From: "VICTOR MUSLIN" To: "ietf-radius" Subject: (radius) Accounting-On question Date: Fri, 24 May 2002 11:47:11 -0400 Organization: Prodigy Internet MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "VICTOR MUSLIN" Content-Transfer-Encoding: 7bit Is RADIUS client allowed to send any Accounting packets (Accounting-Start, Accounting-Stop, Interim-Update) before Accounting-On packet had been acknowledge? What is the typical pracice? I did not notice this to be specified in the RFCs I checked. Similarly with Accounting-Off, is RADIUS client allowed to send any other packets after sending Accounting-Off? This may be a moot point compared with the Accounting-On issue. Thanks. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri May 24 14:58:46 2002 Received: from portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10568 for ; Fri, 24 May 2002 14:58:46 -0400 (EDT) Received: (from majordomo@localhost) by portmasters.com (8.11.1/8.11.1) id g4OHWGX13273 for ietf-radius-outgoing; Fri, 24 May 2002 12:32:16 -0500 X-Authentication-Warning: portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-Id: <4.3.2.7.2.20020524114449.020e0468@franklin.cisco.com> X-Sender: gwz@franklin.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 May 2002 11:52:03 -0700 To: "VICTOR MUSLIN" From: Glen Zorn Subject: Re: (radius) Accounting-On question Cc: "ietf-radius" In-Reply-To: <002901c2033a$45517cf0$6b01a8c0@grumpy> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Glen Zorn At 11:47 AM 5/24/2002 -0400, VICTOR MUSLIN wrote: >Is RADIUS client allowed to send any Accounting packets (Accounting-Start, >Accounting-Stop, Interim-Update) before Accounting-On packet had been >acknowledge? What is the typical pracice? I did not notice this to be >specified in the RFCs I checked. > >Similarly with Accounting-Off, is RADIUS client allowed to send any other >packets after sending Accounting-Off? This may be a moot point compared with >the Accounting-On issue. My reading of RFC 2866 is that if Accounting-On is sent at all, it should be in the first Accounting-Request packet sent from the client after reboot, and similarly for Accounting-Off. However, both Accounting-On and Accounting -Off are optional. >Thanks. > >- >To unsubscribe, email 'majordomo@portmasters.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri May 24 17:08:59 2002 Received: from portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14601 for ; Fri, 24 May 2002 17:08:58 -0400 (EDT) Received: (from majordomo@localhost) by portmasters.com (8.11.1/8.11.1) id g4OJgMc14595 for ietf-radius-outgoing; Fri, 24 May 2002 14:42:22 -0500 X-Authentication-Warning: portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-ID: <006501c20366$c7559f20$6b01a8c0@grumpy> From: "VICTOR MUSLIN" To: "Glen Zorn" Cc: "ietf-radius" References: <4.3.2.7.2.20020524114449.020e0468@franklin.cisco.com> Subject: Re: (radius) Accounting-On question Date: Fri, 24 May 2002 17:05:47 -0400 Organization: Prodigy Internet MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "VICTOR MUSLIN" Content-Transfer-Encoding: 7bit Thank you, Glen, but I don't believe this quite answers the question. What I am asking is not whether Start/Stop can be sent before Accounting-On is SENT, but before Accounting-On is ACKNOWLEDGED. (I am assuming that Accounting-On is acknowledged by Accounting-Response, no?). Assuming that RADIUS client sends Accounting-On/Off, suppose Accounting-On does not reach the server... a) Should Accounting-On be re-transmitted? (probably "yes"), b) Should the client not send Start/Stop messages until Accounting-On is acknowledged? c) If the answer to (b) is "yes", then should no service be allowed on the NAS until Accounting-On is acknowledged? Alternatively, if the service is allowed (or if RADIUS client is not a physical NAS and the concept of "service" is something entirely different), then what should RADIUS client do with sessions that are starting before Accounting-On is acknowledged? Queue up the Accounting Start/Stops? My assumption is that Accounting-On is most useful when RADIUS server manages some resources, such as IP pools, based on the session state. Thus when Accounting-On is received, the server can clean up all sessions in progress from that client. However, if after RADIUS client restarts an Accounting-Start reaches the server before Accounting-On, it is likely that the server will loose state synchronization with the client and will free resources still in use. Given that there are lots of implementation, I assume this issue had been addressed and solved in the past. I am looking for some commonly accepted practices. Thanks. ----- Original Message ----- From: "Glen Zorn" To: "VICTOR MUSLIN" Cc: "ietf-radius" Sent: Friday, May 24, 2002 2:52 PM Subject: Re: (radius) Accounting-On question > At 11:47 AM 5/24/2002 -0400, VICTOR MUSLIN wrote: > >Is RADIUS client allowed to send any Accounting packets (Accounting-Start, > >Accounting-Stop, Interim-Update) before Accounting-On packet had been > >acknowledge? What is the typical pracice? I did not notice this to be > >specified in the RFCs I checked. > > > >Similarly with Accounting-Off, is RADIUS client allowed to send any other > >packets after sending Accounting-Off? This may be a moot point compared with > >the Accounting-On issue. > > My reading of RFC 2866 is that if Accounting-On is sent at all, it should > be in the first Accounting-Request packet sent from the client after > reboot, and similarly for Accounting-Off. However, both Accounting-On and > Accounting -Off are optional. > > > >Thanks. > > > >- > >To unsubscribe, email 'majordomo@portmasters.com' with > >'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Sat May 25 12:22:10 2002 Received: from portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25818 for ; Sat, 25 May 2002 12:22:09 -0400 (EDT) Received: (from majordomo@localhost) by portmasters.com (8.11.1/8.11.1) id g4PErFE27602 for ietf-radius-outgoing; Sat, 25 May 2002 09:53:15 -0500 X-Authentication-Warning: portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f X-Originating-IP: [200.45.98.37] From: "Claudio Lapidus" To: victor@prodigy.net Cc: ietf-radius@portmasters.com Subject: Re: (radius) Accounting-On question Date: Sat, 25 May 2002 13:16:10 -0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 25 May 2002 16:16:10.0935 (UTC) FILETIME=[7BDFEC70:01C20407] Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Claudio Lapidus" Hello Victor, >Assuming that RADIUS client sends Accounting-On/Off, suppose Accounting-On >does not reach the server... > >a) Should Accounting-On be re-transmitted? (probably "yes"), Always according to local policies regarding retransmissions. Some clients let you define multiple target servers, adjust the max time allowed before a sent packet is declared unacknowledged, if that timeout remains constant for succesive retransmissions or if it is going to increase for each attempt, if multiple servers are to be tried in a "failover" or "round-robin" mode, etc. >b) Should the client not send Start/Stop messages until Accounting-On is >acknowledged? I don't see why. Radius protocol is stateless in nature. It is designed to make each message independent of any other, and this is the way to properly implement it. If a certain message wasn't acknowledged, the client may elect to take some extra steps to attempt its delivery, but this is unrelated to what to do with new events that merit new mesages to generate and transmit, I think. >c) If the answer to (b) is "yes", then should no service be allowed on the >NAS until Accounting-On is acknowledged? Alternatively, if the service is >allowed (or if RADIUS client is not a physical NAS and the concept of >"service" is something entirely different), then what should RADIUS client >do with sessions that are starting before Accounting-On is acknowledged? >Queue up the Accounting Start/Stops? There are different postures here. Depending on the nature of the service being provided (and how critical you consider its accounting), some implementations allow you to not actually start user's service until the NAS gets an acknowledge _for an Accounting Start message_. Of course, this is rather restrictive from a service point of view, but it guarantees that no service is delivered without proper accounting. Other implementations tend to prioritize service delivery as their main function and leave tha acct funcionality as an accesory one. However, I cannot remember any client being so restrictive with regard to an Acct-On or Acct-Off message. > >My assumption is that Accounting-On is most useful when RADIUS server >manages some resources, such as IP pools, based on the session state. Thus >when Accounting-On is received, the server can clean up all sessions in >progress from that client. That's exactly the way it works for most servers, yes. However, if after RADIUS client restarts an >Accounting-Start reaches the server before Accounting-On, it is likely that >the server will loose state synchronization with the client and will free >resources still in use. As in the previous case, when the server receives an acct-start message it allocates a resource to the client. Then, when it receives tha acct-on, it releases it. Wasn't it supposed to behave that way? How could the server tell an out-of-sequence message from a correctly sequenced one? I think this is a very special and stretched case, not often found in common remote access scenarios, where Radius has its main application. Probably the main point here is the old discussion that tries to state if an Accounting-Response message is to be considered as a transport layer ACK or as an application layer one: when a server sends an Acct-Response is it saying to the client "I have received your message" or "I have received your message and made sure that the application layer has taken care of it"? You may want to consult RFC2975 for a very insightful explanation of the point. Going back to your question "c)", I would like to remind you that Radius was designed with the specific goal of centralize AAA information for remote access service. If you want to use its syntaxis and message structure to manage "some entirely different concept of service", certainly you can try, but you may well end up with a very specialized implementation that doesn't easily interoperates with any other implementation out there, unless they're already "service-aware", and here I say "service" in the restricted way you put it. I think that you'll have to pay very close attention to what the semantics implies in each of these cases. regards, cl. _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message.