From owner-ietf-radius@portmasters.com Fri Feb 1 00:39:15 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23411 for ; Fri, 1 Feb 2002 00:39:06 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g115KvB09658 for ietf-radius-outgoing; Thu, 31 Jan 2002 23:20:57 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f From: "Glen Zorn" To: "Randy Bush" , Cc: , , , Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt Date: Thu, 31 Jan 2002 21:36:44 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Randy Bush [mailto:randy@psg.com] writes: > > Here's the quote from section 6.2 of RFC 2865: > > > > "Packet Type Coes have a range from 1 to 254, of which 1-5, 11-13 have > > been allocated. Because a new Packet Type has considerable impact on > > interoperability, a new Packet Type Code requires Standards Action, and > > should be allocated starting at 14." > > given the above, what do the authors wish to do with this document? > > and, if the authors were to propose this as a standards action, would > anyone on this list think that technical objections might be raised? Yes. > > randy > - > 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 Feb 1 00:42:44 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23464 for ; Fri, 1 Feb 2002 00:42:43 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g115PkL09733 for ietf-radius-outgoing; Thu, 31 Jan 2002 23:25:46 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: "Glen Zorn" Cc: , , , , Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt References: Message-Id: Date: Thu, 31 Jan 2002 21:41:30 -0800 Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Randy Bush Content-Transfer-Encoding: 7bit >> and, if the authors were to propose this as a standards action, would >> anyone on this list think that technical objections might be raised? > Yes. and, just to speculate, what technical objections do you think might be raised. randy - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri Feb 1 01:21:45 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23953 for ; Fri, 1 Feb 2002 01:21:45 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g1164ge10103 for ietf-radius-outgoing; Fri, 1 Feb 2002 00:04:42 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f From: "Glen Zorn" To: "Randy Bush" Cc: , , , , Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt Date: Thu, 31 Jan 2002 22:20:24 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Randy Bush [mailto:randy@psg.com] writes: > >> and, if the authors were to propose this as a standards action, would > >> anyone on this list think that technical objections might be raised? > > Yes. > > and, just to speculate, what technical objections do you think might be > raised. Well, purely speculating, I might guess that some people might not appreciate the standardization of what is basically a proprietary hack. Note that I have no problem with _documenting_ proprietary hacks (viz. RFC 2433, RFC 2637,... ;-), esp. if interoperability is improved by doing so, but _standardizing_ them is another question entirely. Furthermore, as Bernard pointed out, this is a _major_ modification to the RADIUS protocol, a protocol that is in the process of being superceded by another which includes this capability as a native feature. > > randy > - > 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 Feb 1 09:35:17 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24112 for ; Fri, 1 Feb 2002 09:35:17 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11EGu514837 for ietf-radius-outgoing; Fri, 1 Feb 2002 08:16:56 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f From: "Mark Jones" To: Subject: RE: (radius) draft-chiba-radius-dynamic-disconnect-00.txt Date: Fri, 1 Feb 2002 09:35:01 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Mark Jones" Content-Transfer-Encoding: 7bit Depending on the vendor, the customer documentation on this functionality can be pretty sparse so I do appreciate the efforts of the authors in documenting the current practices in an informational draft. I do have some comments on the draft: --- In the Introduction section (1.1) you state: The disconnect messages cause a user session to be terminated immediately, whereas change of filter messages modify the applicable packet filters for the user session and is the subject of this draft. which implies change of filter messages are the subject of the draft but the next section (1.2 Current Practices) contradicts this: This draft outlines the details for Disconnect Requests only and will not attempt to detail Change of Filters which is considered as beyond the scope of this draft. --- I seem to remember a Session-Key AVP figuring in at least two implementations of the Disconnect-Request. Wouldn't this also deserve a mention in a Current Practices document? --- In section 1.2.1, "the request message contains either, or all" should read "the request message contains one or more". --- I believe it is also common practice to send the following attributes in the Accounting-Stop packet for a successfully terminated session: Ascend-Disconnect-Cause = 150 (Disconnect-Requested-By-Radius-Client) Acct-Terminate-Cause = 7 (Admin-Reset) --- I would also welcome the addition of the change of filters messages to this or some another informational draft. Regards, Mark - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri Feb 1 09:50:22 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24542 for ; Fri, 1 Feb 2002 09:50:21 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11EXGR15032 for ietf-radius-outgoing; Fri, 1 Feb 2002 08:33:16 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f From: "Mark Jones" To: Subject: RE: (radius) draft-chiba-radius-dynamic-disconnect-00.txt Date: Fri, 1 Feb 2002 09:51:21 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Mark Jones" Content-Transfer-Encoding: 7bit Depending on the vendor, the customer documentation on this functionality can be pretty sparse so I do appreciate the efforts of the authors in documenting the current practices in an informational draft. I do have some comments on the draft: --- In the Introduction section (1.1) you state: The disconnect messages cause a user session to be terminated immediately, whereas change of filter messages modify the applicable packet filters for the user session and is the subject of this draft. which implies change of filter messages are the subject of the draft but the next section (1.2 Current Practices) contradicts this: This draft outlines the details for Disconnect Requests only and will not attempt to detail Change of Filters which is considered as beyond the scope of this draft. --- I seem to remember a Session-Key AVP figuring in at least two implementations of the Disconnect-Request. Wouldn't this also deserve a mention in a Current Practices document? --- In section 1.2.1, "the request message contains either, or all" should read "the request message contains one or more". --- I believe it is also common practice to send the following attributes in the Accounting-Stop packet for a successfully terminated session: Ascend-Disconnect-Cause = 150 (Disconnect-Requested-By-Radius-Client) Acct-Terminate-Cause = 7 (Admin-Reset) --- I would also welcome the addition of the change of filters messages to this or some another informational draft. Regards, Mark - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri Feb 1 10:00:29 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25000 for ; Fri, 1 Feb 2002 10:00:29 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11Eh3A15210 for ietf-radius-outgoing; Fri, 1 Feb 2002 08:43:03 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f X-Sent: 1 Feb 2002 14:59:01 GMT Message-Id: <5.1.0.14.2.20020201095435.00a95790@getmail.mitton.com> X-Sender: david@getmail.mitton.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 01 Feb 2002 09:58:37 -0500 To: , "Randy Bush" From: David Mitton Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt Cc: , , , In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: David Mitton Sorry, I'm at a disavantage here. I've fallen off the RADIUS list and I cannot find the archives yet. So I haven't seen Bernard's message that Glen is referring to. At 1/31/2002 10:20 PM -0800, Glen Zorn wrote: >Randy Bush [mailto:randy@psg.com] writes: > > > >> and, if the authors were to propose this as a standards action, would > > >> anyone on this list think that technical objections might be raised? > > > Yes. > > > > and, just to speculate, what technical objections do you think might be > > raised. > >Well, purely speculating, I might guess that some people might not >appreciate the standardization of what is basically a proprietary hack. Implemented by several vendors for several years now, but what the heck... >Note that I have no problem with _documenting_ proprietary hacks (viz. RFC >2433, RFC 2637,... ;-), esp. if interoperability is improved by doing so, >but _standardizing_ them is another question entirely. Well this was the AD's suggestion... > Furthermore, as >Bernard pointed out, this is a _major_ modification to the RADIUS protocol, >a protocol that is in the process of being superceded by another which >includes this capability as a native feature. except that many implementations already have it... and the code space has worked around it. I'm not really disaggreeing, but I don't think it's that big a deal either. Dave. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri Feb 1 12:22:59 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04788 for ; Fri, 1 Feb 2002 12:22:58 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11H5fh18601 for ietf-radius-outgoing; Fri, 1 Feb 2002 11:05:41 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f X-Originating-IP: [200.3.95.33] From: "Claudio Lapidus" To: gwz@cisco.com, randy@psg.com Cc: ietf-radius@portmasters.com, mchiba@cisco.com, gdommety@cisco.com, meklund@cisco.com, david@mitton.com Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt Date: Fri, 01 Feb 2002 14:21:39 -0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Feb 2002 17:21:40.0218 (UTC) FILETIME=[E93B2DA0:01C1AB44] Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Claudio Lapidus" "Glen Zorn" wrote: >Note that I have no problem with _documenting_ proprietary hacks (viz. RFC >2433, RFC 2637,... ;-), esp. if interoperability is improved by doing so, >but _standardizing_ them is another question entirely. Furthermore, as >Bernard pointed out, this is a _major_ modification to the RADIUS protocol, >a protocol that is in the process of being superceded by another which >includes this capability as a native feature. I agree with you that standardizing propietary extensions is a delicate issue, but perhaps there is something to gain in adding them with "OPTIONAL" level of compliance (per RFC 2119), thus guaranteeing interoperability with earlier implementations that, of course, do not implement the extension. IMHO, the fact is that this particular feature is very useful in a number of environments, and also that RADIUS has been rather aged by the evolution of technology. Perhaps giving the extension standard status would influence vendors to implement it more broadly, something I think would be beneficial for all of us. It is also true that DIAMETER already includes this as native, but there are a very large number of RADIUS implementations out there, and it seems to me that it would be much faster for them to include the proposed extension as an additional feature than the time it will take for all of them to adopt DIAMETER as primary AAA protocol. regards, cl. _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri Feb 1 12:30:37 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05053 for ; Fri, 1 Feb 2002 12:30:36 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11HD6N18915 for ietf-radius-outgoing; Fri, 1 Feb 2002 11:13:06 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f X-Originating-IP: [200.3.95.33] From: "Claudio Lapidus" To: mjones@bridgewatersystems.com, ietf-radius@portmasters.com Subject: RE: (radius) draft-chiba-radius-dynamic-disconnect-00.txt Date: Fri, 01 Feb 2002 14:28:58 -0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 01 Feb 2002 17:28:58.0966 (UTC) FILETIME=[EEBECF60:01C1AB45] Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Claudio Lapidus" "Mark Jones" wrote: >I would also welcome the addition of the change of filters messages to this >or some another informational draft. Agreed. In my opinion, the Change-Filters operation is even more useful than the Disconnect, as it opens the door to a range of dynamic services that are currently very hard to implement. 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. From owner-ietf-radius@portmasters.com Fri Feb 1 12:53:31 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05762 for ; Fri, 1 Feb 2002 12:53:30 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11HZdB19683 for ietf-radius-outgoing; Fri, 1 Feb 2002 11:35:39 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-Id: <3.0.5.32.20020201095133.015a3bc0@grigri.eng.ascend.com> X-Sender: igoyret@grigri.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 01 Feb 2002 09:51:33 -0800 To: David Mitton From: Ignacio Goyret Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt Cc: In-Reply-To: <5.1.0.14.2.20020201095435.00a95790@getmail.mitton.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Ignacio Goyret The mechanism is a well known and established common mechanism implemented by several different vendors, beyond the original vendor. If that doesn't qualify as de-facto "standard", I don't know what does. AFAIC, it won't change the world whether this draft is published as an informational or standard track. >> > >> and, if the authors were to propose this as a standards action, would >> > >> anyone on this list think that technical objections might be raised? >> > > Yes. >> > >> > and, just to speculate, what technical objections do you think might be >> > raised. >> >>Well, purely speculating, I might guess that some people might not >>appreciate the standardization of what is basically a proprietary hack. > >Implemented by several vendors for several years now, but what the heck... > >>Note that I have no problem with _documenting_ proprietary hacks (viz. RFC >>2433, RFC 2637,... ;-), esp. if interoperability is improved by doing so, >>but _standardizing_ them is another question entirely. > >Well this was the AD's suggestion... > >> Furthermore, as >>Bernard pointed out, this is a _major_ modification to the RADIUS protocol, >>a protocol that is in the process of being superceded by another which >>includes this capability as a native feature. > >except that many implementations already have it... >and the code space has worked around it. > >I'm not really disaggreeing, but I don't think it's that big a deal either. > >Dave. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri Feb 1 12:58:23 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05905 for ; Fri, 1 Feb 2002 12:58:22 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11Henn19836 for ietf-radius-outgoing; Fri, 1 Feb 2002 11:40:49 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-Id: <3.0.5.32.20020201095642.00a54a80@grigri.eng.ascend.com> X-Sender: igoyret@grigri.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 01 Feb 2002 09:56:42 -0800 To: From: Ignacio Goyret Subject: RE: (radius) draft-chiba-radius-dynamic-disconnect-00.txt Cc: "Mark Jones" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Ignacio Goyret A few more comments on the draft: Section 1.2.1 Disconnect-Request (DR) .... Current practices use the UPD port 1700 for sending requests... ^^^ s/UPD/UDP/ BTW, an acknowledgement to the originator of the idea would be a nice touch, even if that vendor doesn't exist by that name anymore, since AFAIK, none of the authors came up with this idea. At 09:35 AM 2/1/02 -0500, Mark Jones wrote: >Depending on the vendor, the customer documentation on this functionality >can be pretty sparse so I do appreciate the efforts of the authors in >documenting the current practices in an informational draft. > >I do have some comments on the draft: > ... - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri Feb 1 13:07:29 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06127 for ; Fri, 1 Feb 2002 13:07:28 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11HntX20152 for ietf-radius-outgoing; Fri, 1 Feb 2002 11:49:55 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Date: Fri, 1 Feb 2002 09:48:13 -0800 (PST) From: Bernard Aboba To: Ignacio Goyret cc: David Mitton , ashwinp@microsoft.com, ietf-radius@portmasters.com Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt In-Reply-To: <3.0.5.32.20020201095133.015a3bc0@grigri.eng.ascend.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Bernard Aboba > The mechanism is a well known and established common mechanism implemented > by several different vendors, beyond the original vendor. If that doesn't > qualify as de-facto "standard", I don't know what does. > > AFAIC, it won't change the world whether this draft is published as an > informational or standard track. Question: is the functionality implemented *exactly* the same way by multiple vendors? In other words, has interoperability been demonstrated? Who are the vendors who can interoperate with it? - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri Feb 1 14:05:36 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08329 for ; Fri, 1 Feb 2002 14:05:36 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11Ilip21791 for ietf-radius-outgoing; Fri, 1 Feb 2002 12:47:44 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-ID: From: "Nelson, David" To: "'Claudio Lapidus'" Cc: ietf-radius@portmasters.com, david@mitton.com Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt Date: Fri, 1 Feb 2002 14:02:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB52.F66A15A0" Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Nelson, David" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1AB52.F66A15A0 Content-Type: text/plain; charset="iso-8859-1" Claudio Lapidus writes... >It is also true that DIAMETER already includes this as native, but there are >a very large number of RADIUS implementations out there, and it seems to me >that it would be much faster for them to include the proposed extension as >an additional feature than the time it will take for all of them to adopt >DIAMETER as primary AAA protocol. That's probably true, at least in some cases. It is a Good Thing (tm), though? Given that RADIUS has some substantial deficiencies, ought we not to spend our collective efforts moving on to the successor protocol? There was a proposal in the AAA WG to standardize an improved RADIUS, but that was rejected in favor of standardizing Diameter. Sometimes having two standard protocols to solve a problem is less desirable than having one (good one). Regards, Dave David B. Nelson, Software Architect Enterasys Networks, Inc. 50 Minuteman Road Andover, MA 01801-1008 Phone: (978) 684-1330 FAX: (978) 684-1368 E-mail: dnelson@enterasys.com ------_=_NextPart_001_01C1AB52.F66A15A0 Content-Type: text/html; charset="iso-8859-1" RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt

Claudio Lapidus writes...

>It is also true that DIAMETER already includes this as native, but there are
>a very large number of RADIUS implementations out there, and it seems to me
>that it would be much faster for them to include the proposed extension as
>an additional feature than the time it will take for all of them to adopt
>DIAMETER as primary AAA protocol.

That's probably true, at least in some cases.  It is a Good Thing (tm),
though?  Given that RADIUS has some substantial deficiencies, ought we not
to spend our collective efforts moving on to the successor protocol?  There
was a proposal in the AAA WG to standardize an improved RADIUS, but that was
rejected in favor of standardizing Diameter.  Sometimes having two standard
protocols to solve a problem is less desirable than having one (good one).

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: dnelson@enterasys.com

------_=_NextPart_001_01C1AB52.F66A15A0-- - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Fri Feb 1 17:24:35 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13250 for ; Fri, 1 Feb 2002 17:24:35 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g11M4w526445 for ietf-radius-outgoing; Fri, 1 Feb 2002 16:04:58 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt Date: Fri, 1 Feb 2002 14:20:41 -0800 Message-ID: Thread-Topic: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt Thread-Index: AcGrSxBFrn/rXCa+Q1qO8eKAJBGLiwAIcPGg From: "Ashwin Palekar" To: "Bernard Aboba" , "Ignacio Goyret" , "David Mitton" , X-OriginalArrivalTime: 01 Feb 2002 22:20:41.0606 (UTC) FILETIME=[AF21BA60:01C1AB6E] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by linux2.portmasters.com id g11M4u926443 Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: "Ashwin Palekar" Content-Transfer-Encoding: 8bit Additional comments/questions: 1. Is the list of attributes that can be used for identification limited in any way to UserID and SessionID? For example, Is it possible to disconnect by using Calling-Station-ID (could be mac-address in 802.1x). 2. Might be better to have 1 draft for change filter(+ replymessage & others) and disconnect so that we do not have to come up with new packet types. -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Friday, February 01, 2002 9:48 AM To: Ignacio Goyret Cc: David Mitton; Ashwin Palekar; ietf-radius@portmasters.com Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt > The mechanism is a well known and established common mechanism > implemented by several different vendors, beyond the original vendor. > If that doesn't qualify as de-facto "standard", I don't know what > does. > > AFAIC, it won't change the world whether this draft is published as an > informational or standard track. Question: is the functionality implemented *exactly* the same way by multiple vendors? In other words, has interoperability been demonstrated? Who are the vendors who can interoperate with it? - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Thu Feb 21 13:10:16 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27295 for ; Thu, 21 Feb 2002 13:10:11 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g1LHjU810682 for ietf-radius-outgoing; Thu, 21 Feb 2002 11:45:30 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-Id: <3.0.5.32.20020221100456.00b63180@grigri.eng.ascend.com> X-Sender: igoyret@grigri.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 21 Feb 2002 10:04:56 -0800 To: schulzrinne@cs.columbia.edu, abk2001@cs.columbia.edu, sankaran@cs.columbia.edu From: Ignacio Goyret Subject: (radius) draft-schulzrinne-sipping-radius-accounting-00.txt Cc: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Ignacio Goyret From the draft: >5.3 NAS-Port > > The NAS-Port attribute indicates the port number of the SIP Server > that provides service to the user. This is usually 5060. This > attribute MUST be present in Accounting-Request packets. > This use of the attribute is quite different from the usual use for this attribute. I strongly suggest that you obtain a *new* attribute for this use. BTW, you should change the numbers you assigned to all the SIP-* attributes and request numbers from IANA to avoid conflicts and interoperability issues. At least as far as www.iana.org is concerned, IANA has not assigned any of those numbers (see http://www.iana.org/assignments/radius-types) - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Thu Feb 21 13:17:58 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27660 for ; Thu, 21 Feb 2002 13:17:57 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g1LHv4C10907 for ietf-radius-outgoing; Thu, 21 Feb 2002 11:57:04 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Message-Id: <3.0.5.32.20020221101630.00aef620@grigri.eng.ascend.com> X-Sender: igoyret@grigri.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 21 Feb 2002 10:16:30 -0800 To: Henning Schulzrinne From: Ignacio Goyret Subject: (radius) Re: draft-schulzrinne-sipping-radius-accounting-00.txt Cc: Ignacio Goyret , schulzrinne@cs.columbia.edu, abk2001@cs.columbia.edu, sankaran@cs.columbia.edu, ietf-radius@portmasters.com In-Reply-To: <3C753779.2A1414DA@cs.columbia.edu> References: <3.0.5.32.20020221100456.00b63180@grigri.eng.ascend.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Ignacio Goyret At 01:07 PM 2/21/02 -0500, Henning Schulzrinne wrote: >> >From the draft: >> >> >5.3 NAS-Port >> > >> > The NAS-Port attribute indicates the port number of the SIP Server >> > that provides service to the user. This is usually 5060. >> >> This use of the attribute is quite different from the usual use for this >> attribute. I strongly suggest that you obtain a *new* attribute for this >> use. > >What is the usual use for this parameter? I couldn't quite figure it >out. From RFC 2865: >5.5. NAS-Port > > Description > > This Attribute indicates the physical port number of the NAS which > is authenticating the user. It is only used in Access-Request > packets. Note that this is using "port" in its sense of a > physical connection on the NAS, not in the sense of a TCP or UDP > port number. It indicates a _physical port number_ not a TCP or UDP port, as you are using it. If you want to use it to indicate a TCP or UDP (or whatever other protocol) port number, use a different attribute. >> BTW, you should change the numbers you assigned to all the SIP-* attributes >> and request numbers from IANA to avoid conflicts and interoperability issues. >> At least as far as www.iana.org is concerned, IANA has not assigned any of >> those numbers (see http://www.iana.org/assignments/radius-types) > >The Internet Draft was meant as the necessary documentation, after we >get the bugs fixed and have some expert feedback. In that case, use VSAs until your bugs are ironed out. Otherwise, it will cause endless confusion and all kinds of interoperability problems in the future (was the attribute SIP-xyz value 100 (draft) or 101 (later assigned by IANA) ?) - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Thu Feb 21 14:58:17 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01640 for ; Thu, 21 Feb 2002 14:58:13 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g1LJaGL12602 for ietf-radius-outgoing; Thu, 21 Feb 2002 13:36:16 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Date: Thu, 21 Feb 2002 11:16:46 -0800 (PST) From: Bernard Aboba To: Ignacio Goyret cc: Henning Schulzrinne , ietf-radius@portmasters.com Subject: Re: (radius) draft-schulzrinne-sipping-radius-accountin-00.txt In-Reply-To: <3.0.5.32.20020221101630.00aef620@grigri.eng.ascend.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Bernard Aboba Enclosed below find Section 6 of RFC 2865, which specifies the IANA considerations for RADIUS. Note that release of blocks of attributes require IETF Consensus (and permission from IANA). ----------------------------------------------------------------------- 6. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the RADIUS protocol, in accordance with BCP 26 [RFC2434]. There are three name spaces in RADIUS that require registration: Packet Type Codes, Attribute Types, and Attribute Values (for certain Attributes). RADIUS is not intended as a general-purpose Network Access Server (NAS) management protocol, and allocations should not be made for purposes unrelated to Authentication, Authorization or Accounting. 6.1. Definition of Terms The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration". The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IETF Consensus", "Standards Action". 6.2. Recommended Registration Policies For registration requests where a Designated Expert should be consulted, the IESG Area Director for Operations should appoint the Designated Expert. For registration requests requiring Expert Review, the ietf-radius mailing list should be consulted. Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have been allocated. Because a new Packet Type has considerable impact on interoperability, a new Packet Type Code requires Standards Action, and should be allocated starting at 14. Attribute Types have a range from 1 to 255, and are the scarcest resource in RADIUS, thus must be allocated with care. Attributes 1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated following Expert Review, with Specification Required. Release of blocks of Attribute Types (more than 3 at a time for a given purpose) should require IETF Consensus. It is recommended that attributes 17 and 21 be used only after all others are exhausted. Note that RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) and the use of that should be encouraged instead of allocation of global attribute types, for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. As stated in the "Attributes" section above: "[Attribute Type] Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used." Therefore Attribute values 192-240 are considered Private Use, and values 241-255 require Standards Action. Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Adding additional values to the list can be done on a First Come, First Served basis by the IANA. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@portmasters.com Thu Feb 21 22:01:02 2002 Received: from linux2.portmasters.com (root@ns2.jakes.org [216.138.104.67]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10716 for ; Thu, 21 Feb 2002 22:01:01 -0500 (EST) Received: (from majordomo@localhost) by linux2.portmasters.com (8.11.1/8.11.1) id g1M2cRG19429 for ietf-radius-outgoing; Thu, 21 Feb 2002 20:38:27 -0600 X-Authentication-Warning: linux2.portmasters.com: majordomo set sender to owner-ietf-radius@portmasters.com using -f Date: Thu, 21 Feb 2002 18:18:57 -0800 (PST) From: Bernard Aboba To: Henning Schulzrinne cc: Ignacio Goyret , ietf-radius@portmasters.com Subject: Re: (radius) draft-schulzrinne-sipping-radius-accountin-00.txt In-Reply-To: <3C75A4C4.21FD1436@cs.columbia.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@portmasters.com Precedence: bulk Reply-To: Bernard Aboba > Submission of an I-D seemed like the right approach to start the > process... Well, not being familiar with the problem you're trying to solve, it's hard to give advice. However, it rarely hurts to understand the likely uses of the accounting data and the level of reliability and security that is required. Because accounting data can influence preparation of financial statements, protocol choices are often constrained by legal or regulatory requirements. The considerations that go into the design of "archival" accounting systems are reviewed in RFC 2975. These are systems where it is expected that accounting data will be used in preparation of financial statements, and where data may need to be archived until the expiration of the relevant "statute of limitations" (typically 7 years in the US). The document includes a review of various existing accounting technologies against the "archival" accounting requirements. In particular, you might wish to consult the table on page 47 of RFC 2975, to get a rough idea of what approaches are likely to be acceptable for a given intended use. - To unsubscribe, email 'majordomo@portmasters.com' with 'unsubscribe ietf-radius' in the body of the message.