From owner-ietf-radius@livingston.com Mon Feb 1 04:58:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA19381 for ; Mon, 1 Feb 1999 04:58:17 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA08102; Mon, 1 Feb 1999 01:49:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA17639 for ietf-radius-outgoing; Mon, 1 Feb 1999 01:49:16 -0800 (PST) Message-Id: X-Mailer: Novell GroupWise 5.5 Date: Mon, 01 Feb 1999 10:47:49 +0100 From: "Peter Jakobs" To: , Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius mailing list? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Peter Jakobs" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA19381 It would already help if livingston would either secure their server or if we would allow posting only for subscribed listeners. Possibly both. >>> "Varghese, Joe" 01/28/99 03:56pm >>> Just wanted to know if anyone else is having the same problem I am - I'm receiving a *lot* of junk e-mail (the latest one advertising an adult oriented content), and it looks like the solicitors got my address via the ietf-radius newsgroup (on the bottom of each one there's an "To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message" message). Is anyone else having this problem? Can someone who's on charge of this mailing list make sure that this kind of junk e-mail doesnt get passed via the list? I've attached a few of the messages just in case it's needed .... Thanks. joe varghese -------------------------------- George (Joe) Varghese varghese@lucent.com (630) 713-9522 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 2 15:24:27 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA02982 for ; Tue, 2 Feb 1999 15:24:26 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA06662; Tue, 2 Feb 1999 12:15:27 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA09898 for ietf-radius-outgoing; Tue, 2 Feb 1999 12:11:38 -0800 (PST) Message-Id: <199902022009.PAA02457@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-radius@livingston.com From: The IESG Subject: (radius) Document Action: Microsoft Vendor-specific RADIUS Attributes to Informational Date: Tue, 02 Feb 1999 15:09:00 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: The IESG The IESG has approved the Internet-Draft 'Microsoft Vendor-specific RADIUS Attributes' as a Informational. This document is the product of the Remote Authentication Dial-In User Service Working Group. The IESG contact persons are Bert Wijnen and Harald Alvestrand. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 2 19:57:23 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA09681 for ; Tue, 2 Feb 1999 19:57:22 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA18505; Tue, 2 Feb 1999 16:48:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA11235 for ietf-radius-outgoing; Tue, 2 Feb 1999 16:50:04 -0800 (PST) Date: Tue, 2 Feb 1999 16:50:02 -0800 (PST) From: Carl Rigney Message-Id: <199902030050.QAA11203@server.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius mailing list? Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Livingston does block non-subscribers from posting to our portmaster-* mailing lists, and could easily do so for the IETF mailing lists we run as a courtesy to various working groups. That would mean that people who aren't on the working group mailing list wouldn't be able to send a message to the working group without subscribing first, which would cut down on the ability for various other IETFers to send a quick question to the list. We've been reluctant to take that step, but if consensus in the working group is they're willing to make it harder for outsiders to provide input in return for less spam, we could turn on that filter. Rather than cluttering the list with this kind of meta-discussion, please email ME directly with your thoughts and I'll see if there's consensus one way or the other. Please don't discuss this any further on the list, though - we've now had as many articles on this issue as we had spam to trigger it. -- Carl Rigney IETF RADIUS WG List Administrator cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 2 20:21:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA09941 for ; Tue, 2 Feb 1999 20:21:11 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA19077; Tue, 2 Feb 1999 17:11:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA12910 for ietf-radius-outgoing; Tue, 2 Feb 1999 17:13:44 -0800 (PST) Date: Tue, 2 Feb 1999 17:13:43 -0800 (PST) From: Carl Rigney Message-Id: <199902030113.RAA12904@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Implementation survey, part II Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Please fill this out and return it to cdr@livingston.com by February 8th, 5pm PST. For RADIUS to advance to Proposed Standard, every feature must have at least two independent implementations, or must be cut from the draft. I'm putting together the document on that. I already have the email everyone sent me in November mentioning their implementations, and now I'm ready for the feature lists. Please read these directions carefully and email your answers to me directly, not to the list. I only need a reply to this if your implementation is INDEPENDENT, that is, not based on Livingston's original RADIUS 1.3, 1.13 or 1.16 server. If you started out once upon a time with our server and eventually replaced all our code with fresh code, that counts as independent. If you did your implementation from scratch, better yet. Please fill out the Organization, Product and Version fields following their colons, and mark the features with a Y or N *before* the feature, and keep the spelling and order exactly as they are here (so I can automate processing the results). Lines starting with __ are headers and should not be marked. Y means you support that feature in your RADIUS server NOW, N means you do not. No fair saying you'll be adding it later, it has to be in your implementation that's already done and being used somewhere, although beta or experimental software counts as in use, as long as its actually running. Note that not all values of a given attribute need to be supported, if your NAS only supports PPP but not SLIP, that still counts as supporting Framed-Protocol. If you make both a server and a NAS, please send in two submissions (as two seperate email messages), one for each. If you make different flavors of NAS but they have the same RADIUS client, you only need to send me an entry for one flavor of NAS. Note that Accounting is informational so its attributes are not listed here, but the Accounting packet codes *are* included in the RADIUS RFC, so they are listed here. Company name: Product Name: Product Version: __ Proxy supported: Server can forward an access-request to another RADIUS server Server can receive an access-accept, reject, or challenge and forward to a RADIUS client Server copies all Proxy-States from request to response when replying to request Server strips its own Proxy-State from response before forwarding to client __Packet Types supported: Access-Request Access-Accept Access-Reject Access-Challenge Accounting-Request Accounting-Response __ Attributes supported: User-Name User-Password up to 16 characters long User-Password up to 128 characters long (encrypted as described in RFC 2138) CHAP-Password NAS-IP-Address NAS-Port Service-Type Framed-Protocol Framed-IP-Address Framed-IP-Netmask Framed-Routing Filter-Id Framed-MTU Framed-Compression Login-IP-Host Login-Service Login-TCP-Port Reply-Message Callback-Number Callback-Id Framed-Route Framed-IPX-Network State Class (for a Client this means it sends Class from access-accepts in its accounting-requests Vendor-Specific Session-Timeout Idle-Timeout Termination-Action Called-Station-Id Calling-Station-Id NAS-Identifier Proxy-State Login-LAT-Service Login-LAT-Node Login-LAT-Group Framed-AppleTalk-Link Framed-AppleTalk-Network Framed-AppleTalk-Zone CHAP-Challenge NAS-Port-Type Port-Limit Login-LAT-Port __ Features supported: Identifier (in packet header) Request Authenticator Response Authenticator Challenge Response Supports PAP Supports CHAP - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 3 10:58:22 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA24239 for ; Wed, 3 Feb 1999 10:58:21 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA07988; Wed, 3 Feb 1999 07:48:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA18818 for ietf-radius-outgoing; Wed, 3 Feb 1999 07:46:53 -0800 (PST) From: jaegert@us.ibm.com X-Lotus-FromDomain: IBMUS Message-ID: <8525670D.00568270.09@D51MTA03.pok.ibm.com> Date: Wed, 3 Feb 1999 10:44:32 -0500 Subject: (radius) Call for Papers: Fourth ACM Workshop on Role-based Access Control Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: jaegert@us.ibm.com CALL FOR PAPERS Fourth ACM WORKSHOP ON ROLE-BASED ACCESS CONTROL Date: Oct. 28-29, 1999 Place: George Mason University url: www.list.gmu.edu/rbac Sponsored By: ACM Sigsac Hosted By: George Mason University The essence of Role-Based Access Control (RBAC) is that permissions are assigned to roles rather than to individual users. Users acquire these permissions by virtue of being authorized to act in these roles. The driving motivation for RBAC is to simplify security policy administration while facilitating the definition of flexible, customized policies. Basic RBAC models have been successfully applied since the mainframe era, but emerging systems, which have greater numbers of users, roles, and systems, challenge the expressive power of these traditional models. Workshop Scope: The ACM workshops on RBAC bring together researchers, developers, and practitioners to discuss the application of RBAC to both traditional and emerging systems and the development of new access control paradigms for future applications. The workshop invites participation from the database, network, distributed systems, operating systems, security and application communities. Contributions reporting experiences with the implementation and use of RBAC systems are strongly encouraged. Attendance is limited to 40 participants to foster a workshop atmosphere. Topics of interest include, but are not restricted to: - Modeling and specification of RBAC systems - Administration of RBAC systems - RBAC in database security - Specification and enforcement of security policy - Delegation and inheritance of access rights in RBAC systems - Task-based access control and RBAC in collaborative environments - Application Areas e.g., health-care, WWW - Support for RBAC in traditional access control systems - RBAC and organizational control principles - Experiences with RBAC-based systems; case studies - Enabling technologies: Java, LDAP, intra-net environments - Implementation, integration and scalability of RBAC - End-user tools to support RBAC administration and engineering Submissions: Users, developers and researchers are invited to submit seven copies of their papers (in English and limited to 6000 words) to the Program Chair at the coordinates given below before the due date. Submissions can be either hard copy or electronic (postscript preferred). Papers must be original and should not be under consideration for publication elsewhere. Copyrights for accepted papers must be transferable to ACM (except for Government work). Papers will be published by ACM in a proceedings to be distributed at the workshop and mailed to all SIGSAC members. Outstanding papers will be considered for publication in ACM's new Transactions on Information and Systems Security (TISSEC). Proposals for panels and group discussions should be sent, preferably by email, to the Panels Chair at dferraiolo@nist.gov. Paper Submissions should be sent to: Sylvia Osborn, Program Committee Chair, Dept. of Computer Science, The University of Western Ontario, MC355, London, Ontario, Canada, N6A 5B7 email: sylvia@csd.uwo.ca SCHEDULE: Papers and Panel Proposals Due: May 15, 1999 Notification of acceptance and advance program: June 30, 1999 Deadline for final version of papers: July 31, 1999 Workshop: October 28-29, 1999 CONFERENCE STEERING COMMITTEE: Ed Coyne, Science Applications International Corporation David Ferraiolo, National Institute of Standards and Technology Trent Jaeger, IBM T.J. Watson Research Center Sylvia Osborn, The University of Western Ontario Ravi Sandhu, George Mason University Charles Youman, Blue Cross Blue Shield General Conference Chair: Charles Youman, Blue Cross Blue Shield Local Arrangements: Srinivas Ganta, CygnaCom Solutions Inc. Program Committee Chair: Sylvia Osborn, The University of Western Ontario Panels Chair: David Ferraiolo, National Institute of Standards and Technology Proceedings Chair: Vijay Atluri, Rutgers University Publicity Chair: Trent Jaeger, IBM T.J. Watson Research Center PROGRAM COMMITTEE: Vijay Atluri, Rutgers University Dave Ferraiolo, National Institute of Standards and Technology Luigi Giuri, Fondazione Ugo Bordoni Trent Jaeger, IBM T.J. Watson Research Center Carl Landwehr, U.S. Naval Research Laboratory Emil Lupu, Imperial College Ravi Sandhu, George Mason University Richard Simon Roshan Thomas, TIS Labs at Network Associates Dan Thomsen, Secure Computing Corp. Dan Wallach, Rice University REGISTRATION: Information on registration and accommodations will be provided. There will be a registration fee for all participants to cover meeting costs. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 3 11:30:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25121 for ; Wed, 3 Feb 1999 11:30:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA09457; Wed, 3 Feb 1999 08:21:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA22749 for ietf-radius-outgoing; Wed, 3 Feb 1999 08:23:08 -0800 (PST) Message-Id: <199902031621.LAA24764@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-auth-servmib-03.txt Date: Wed, 03 Feb 1999 11:20:59 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Authentication Server MIB Author(s) : G. Zorn, B. Aboba Filename : draft-ietf-radius-auth-servmib-03.txt Pages : 16 Date : 02-Feb-99 This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-auth-servmib-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-auth-servmib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-auth-servmib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990202150624.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-auth-servmib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-auth-servmib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990202150624.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 3 11:31:18 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25213 for ; Wed, 3 Feb 1999 11:31:17 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA09510; Wed, 3 Feb 1999 08:21:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA22809 for ietf-radius-outgoing; Wed, 3 Feb 1999 08:23:45 -0800 (PST) Message-Id: <199902031621.LAA24782@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-auth-clientmib-03.txt Date: Wed, 03 Feb 1999 11:21:37 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Authentication Client MIB Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-radius-auth-clientmib-03.txt Pages : 14 Date : 02-Feb-99 This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-auth-clientmib-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-auth-clientmib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-auth-clientmib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990202152604.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-auth-clientmib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-auth-clientmib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990202152604.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 3 11:31:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA25229 for ; Wed, 3 Feb 1999 11:31:35 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA09468; Wed, 3 Feb 1999 08:21:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA22718 for ietf-radius-outgoing; Wed, 3 Feb 1999 08:22:57 -0800 (PST) Message-Id: <199902031620.LAA24751@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-acc-clientmib-03.txt Date: Wed, 03 Feb 1999 11:20:50 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Accounting Client MIB Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-radius-acc-clientmib-03.txt Pages : 13 Date : 02-Feb-99 This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-acc-clientmib-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-acc-clientmib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-acc-clientmib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990202150353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-acc-clientmib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-acc-clientmib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990202150353.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 3 12:19:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA27318 for ; Wed, 3 Feb 1999 12:19:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA12493; Wed, 3 Feb 1999 09:09:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA27699 for ietf-radius-outgoing; Wed, 3 Feb 1999 09:10:24 -0800 (PST) Message-Id: <199902031708.MAA26784@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-acc-servmib-03.txt Date: Wed, 03 Feb 1999 12:08:10 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Accounting Server MIB Author(s) : G. Zorn, B. Aboba Filename : draft-ietf-radius-acc-servmib-03.txt Pages : 15 Date : 02-Feb-99 This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-acc-servmib-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-acc-servmib-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-acc-servmib-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990203114554.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-acc-servmib-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-acc-servmib-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990203114554.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 4 19:24:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA24374 for ; Thu, 4 Feb 1999 19:24:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA24627; Thu, 4 Feb 1999 16:14:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA26512 for ietf-radius-outgoing; Thu, 4 Feb 1999 16:14:07 -0800 (PST) Message-Id: <199902050012.QAA22453@shell4.ba.best.com> Subject: (radius) Question on draft status To: ietf-radius@livingston.com Date: Thu, 4 Feb 1999 16:12:39 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone I'm going to be teaching a bit on RADIUS at ISPF II next month, and I'm trying to make sure I'm current on everything. I have the latest drafts, but I want to check a couple of things: I believe these two: RADIUS Accounting Interim Accounting Record Extension draft-ietf-radius-acct-interim-01.txt Extensible Authentication Protocol Support in RADIUS draft-ietf-radius-eap-05.txt were absorbed into: RADIUS Extensions draft-ietf-radius-ext-02.txt (And that a newer draft of this should be out very soon.) So I can ignore the first two, correct? I also unearthed 3 drafts which appear to be dead and buried: RADIUS Extension for Multicast Router Authentication draft-yamanouchi-radius-ext-00.txt Lightweight Directory Access Protocol (v3): Dynamic Attributes for the Remote Access Dialin User Service (RADIUS) draft-aboba-dynradius-01.txt RADIUS IP Security Extensions draft-ietf-radius-ipsec-00.txt Dead, right? Thanks. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 5 03:01:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA16821 for ; Fri, 5 Feb 1999 03:01:41 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id XAA03925; Thu, 4 Feb 1999 23:41:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA18649 for ietf-radius-outgoing; Thu, 4 Feb 1999 23:43:04 -0800 (PST) Message-Id: <033501be50da$074e09c0$1b8939cc@e1kj2.internaut.com> From: "Bernard Aboba" To: "MegaZone" , Subject: Re: (radius) Question on draft status Date: Thu, 4 Feb 1999 23:34:54 -0800 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 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" > >Extensible Authentication Protocol Support in RADIUS >draft-ietf-radius-eap-05.txt This one was indeed absorbed into the ext-02 document. >> >I also unearthed 3 drafts which appear to be dead and buried: >RADIUS Extension for Multicast Router Authentication >draft-yamanouchi-radius-ext-00.txt This one was never considered in RADIUS WG; it was discussed in IDMR where it met its demise. >Lightweight Directory Access Protocol (v3): Dynamic Attributes for >the Remote Access Dialin User Service (RADIUS) >draft-aboba-dynradius-01.txt This one is again not on the RADIUS WG agenda, but it is very much alive -- more than half a dozen companies are currently implementing something like this in one form or another. I'll be updating the spec in the next few weeks. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 5 09:27:55 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA28405 for ; Fri, 5 Feb 1999 09:27:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA08852; Fri, 5 Feb 1999 06:13:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA01459 for ietf-radius-outgoing; Fri, 5 Feb 1999 06:15:25 -0800 (PST) Date: Fri, 5 Feb 1999 06:07:38 -0800 (PST) From: "pcalhoun@eng.sun.com" Subject: Re: (radius) Question on draft status To: Bernard Aboba Cc: MegaZone , ietf-radius@livingston.com In-Reply-To: "Your message with ID" <033501be50da$074e09c0$1b8939cc@e1kj2.internaut.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "pcalhoun@eng.sun.com" > > > >Extensible Authentication Protocol Support in RADIUS > >draft-ietf-radius-eap-05.txt > > This one was indeed absorbed into the ext-02 document. As was Interim Accounting > > >> > >I also unearthed 3 drafts which appear to be dead and buried: > >RADIUS Extension for Multicast Router Authentication > >draft-yamanouchi-radius-ext-00.txt > > > This one was never considered in RADIUS WG; it was > discussed in IDMR where it met its demise. > > >Lightweight Directory Access Protocol (v3): Dynamic Attributes for > >the Remote Access Dialin User Service (RADIUS) > >draft-aboba-dynradius-01.txt > > This one is again not on the RADIUS WG agenda, but it > is very much alive -- more than half a dozen companies > are currently implementing something like this in one > form or another. I'll be updating the spec in the next few > weeks. > > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 04:05:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA17470 for ; Tue, 9 Feb 1999 04:05:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id AAA08776; Tue, 9 Feb 1999 00:55:41 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA23809 for ietf-radius-outgoing; Tue, 9 Feb 1999 00:54:32 -0800 (PST) From: winner-stocks@winner-stocks.com To: ietf-radius@livingston.com Date: Monday, February 8, 1999 7:04:40 o'clock PM EST Message-Id: <19990208190440.TAA19709@winner-stocks.com> Subject: (radius) ADV: Stock Set for Warp Drive (OTC BB: TREK) Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: winner-stocks@winner-stocks.com To be removed from our mailing list, simply reply with "REMOVE" in the subject line. Now you can own a piece of the 24th Century! Starbase-1 Coffee Company, Ltd. (OTC-BB) Symbol "TREK" Stock Info: Shares Outstanding: 862,511 Restricted Shares: 631,683 Free Trading Shares: 230,828 Closing Price 2/8/99: $3.13 Visit http://www.winner-stocks.com for more info on the company and the products it has to offer. Starbase-1 Coffee Company, Ltd. went public in 1998. Exposure of this unique company's name and products has been growing at warp speed. Rarely do you get the opportunity to get involved in a Company on the ground floor (there are only 230,828 Free Trading Shares) that is represented by the biggest business category in the United States, by the third largest commodity in the USA, by the power of a Major Hollywood Movie studio AND by the name of STAR TREK. Coffee compainies such as Starbucks (NASDAQ: SBUX) started out at $5.00 a share back in 1992, today the price is over $50.00 and there are over 86 Million shares outstanding! Compare this with the less than 1 million shares outstanding for Starbase-1 Coffee Company, Ltd.! Now you CAN own a piece of the 24th Century! Star Trek boasts the most dedicated and loyal fans. Starbase-1 uses only premium coffees and candies to create a high quality product with dynamic packaging designed to entice the fan and collector alike. The Company has now opened a retail Showroom that already has a loyal following. The Company's Internet store and mall order catalogues have reached around the world. Star Trek Gourmet Foods have been featured on the Star Trek World Tour, sold at Star Trek Fan Conventions around the country, received acclaim in Gourmet Foods publications, seen in Yahoo! Magazine and has been featured on QVC. We know that the facts can sometimes be boring, but here they are: Licensing and Entertainment Starbase manufactures and distributes Star Trek Gourmet Foods under a licensing agreement with Viacom (Paramount Pictures). The Star Trek properties covered by these licenses are Star Trek, Star Trek: The Next generation, Star Trek: Deep Space Nine, Star Trek: Voyager and all the Star Trek Movies I-IX. The territories covered by the above licensing agreements include the United States and its territories and possessions and Canada and all of its Providence. Licencing and Entertainment are two of the biggest business categories in the United States. Coffee is the third largest commodity in the United States only after steel and petroleum. With the power of Viacom and the sheer depth of the Star Trek name, this most unique company will beam ahead at warp speed. The Company's license is for the following products: 1. Pictured-themed gourmet coffees and teas and related accessories. (Currently 20 flavors and blends of coffee are available separately and in gift boxes.) 2. Pictured-themed chocolate bars and packages of assorted chocolates, as well as molded chocolate shapes, and hot chocolates, all of which may be sold as gift packs. (Currently gift boxes of truffles and cremes and two flavors of hot chocolate are being marketed.) 3. Pictured-themed gourmet hard candy, including but not limited to lollipops and candy rolls to be packed separately or in gift boxes. (Current two designs of holographic lollipops are available and Star Trek Insignia Pops are sold in tubs of 50.) 4. Pictured-themed collectible beverage bottles filled with assorted teas and/or ciders and or coffees or fruit juices or other beverages approved by Viacom. WHATS THE POTENTIAL OF ALL THIS???? The first Star Trek television episode aired on September 8, 1966. Since that time, Star Trek has grown into one of the licensing industry's most enduring and broad-based properties. Sales of Star Trek products have totaled over $2.5 billion at retail since the first product debuted and there are now over 200 official Star Trek licensees worldwide. Department stores, mass merchants and specialty stores nationwide enjoy consistent sales of Star Trek- related toys, gifts and collectibles, computer and video games, novelizations, comic books, magazines, poster and apparel and now gourmet foods and candy novelettes. The original television series remains the single most successful show in syndication history. There have been over 20 million Star Trek home video cassettes sold, including all 79 episodes of the original series. The first U.S. space shuttle, the "Enterprise" was given its name after NASA received over 400,000 requests from Star Trek fans. Star Trek conventions are held every weekend of every year in at least four different U. S. cities, attracting over 300,000 fans. Worldwide, Star Trek has millions of fans and has spawned over 500 fan publications. A phenomenal thirteen Star Trek books are sold ever minute in the United States. The longest streak of consecutive New York Times bestsellers of any series in publishing history: 46 consecutive paperback bestsellers over a 6 1/2 year stretch. AND LAST BUT NOT LEAST: You can get a free catalog of the company's products by calling 1-888-239-8497. Once again be sure to visit the web site at http://www.winner-stocks.com for more info on the company and the products it has to offer. TM & ©Paramount Pictures. All Rights Reserved STARBASE-1 Coffee Company, Ltd. Authorized User. DISCLAIMER ---------- This material is being provided by Winner-Stocks, an electronic newsletter paid by the issuer for publishing the information contained in this report. Starbase-1 Coffee Company, LTD. has paid a consideration of 5,000 shares of common stock of Starbase-1 Coffee Company, LTD. to Winner-Stocks as payment for the publication of the information contained in this report. Winner-Stocks and its affiliates have agreed not to sell the common stock received as payment for its services until February 10, 1999, which date is 2 trading days from the initial dissemination of this report. After such date, Winner-Stocks may sell such shares. Because Winner-Stocks is paid for its services, there is an inherent conflict of interest in Winner-Stocks's statements and opinions and such statements and opinions cannot be considered independent. The information contained in this publication is for informational purposes only, and not to be construed as an offer to sell or solicitation of an offer to buy any security. Winner- Stocks makes no representation or warrant relating to the validity of the facts presented nor does Winner-Stocks represent or warrant that all material facts necessary to make an investment decision are presented above. All statements of opinions are those of Winner-Stocks. Winner- Stocks relies exclusively on information gathered from public filings on featured companies, as well as, in certain circumstances, interviews conducted by Winner-Stocks of management of featured companies. Investors should not rely solely on the information contained in this publication. Rather, investors should use the information contained in this publication as a starting point for conducting additional research on the featured companies in order to allow the investor to form his or her own opinion regarding the featured companies. Factual statements contained in this publication are made as of the date stated and they are subject to change without notice. Winner-Stocks is not a registered investment adviser, broker or a dealer. Investment in the companies reviewed is speculative and extremely high-risk and may result in the loss of some or all of any investment made in Starbase-1 Coffee Company, LTD. Projections of future financial results are provided soley by Starbase-1 Coffee Company, LTD. No assurances are given that Starbase-1 Coffee Company, LTD. will achieve said projections. This publication contains forward-looking statements that are subject to risk and uncertainties that could cause results to differ materially from those set forth in the forward-looking statements. These forward-looking statements represent the judgment of Starbase-1 Coffee Company, LTD. as of the date of this publication. The Company disclaims any intent or obligation to update these forward-looking statements. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 13:20:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA25296 for ; Tue, 9 Feb 1999 13:20:27 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA20566; Tue, 9 Feb 1999 10:04:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA21711 for ietf-radius-outgoing; Tue, 9 Feb 1999 10:05:46 -0800 (PST) Message-ID: From: Jonathan Garini To: ietf-radius@livingston.com Subject: (radius) RFC2139: User-Name should be MUST Date: Tue, 9 Feb 1999 20:01:37 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="windows-1255" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jonathan Garini Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id NAA25296 RFC 2139 does not specify the User-Name attribute as a must but rather as a MAY. Most of the NASs does send the User-Name in accounting packets. However, we have seen one NAS that don't send this attribute. This NAS indeed comply with RFC 2139, but it does not comply with real life operations.   I think the RFC should be amended to include the User-ID attribute as MUST.   Regards, Jonathan.   - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 13:31:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA25638 for ; Tue, 9 Feb 1999 13:31:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA21560; Tue, 9 Feb 1999 10:21:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA23843 for ietf-radius-outgoing; Tue, 9 Feb 1999 10:24:03 -0800 (PST) Message-ID: <36C07DFE.6269155F@livingston.com> Date: Tue, 09 Feb 1999 10:27:10 -0800 From: Thomas Kinnen Organization: Lucent Technologies RABU X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Garini CC: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Thomas Kinnen Jonathan Garini wrote: > > RFC 2139 does not specify the User-Name attribute as a must but rather as a > MAY. > Most of the NASs does send the User-Name in accounting packets. However, we > have seen one NAS that don't send this attribute. This NAS indeed comply > with RFC 2139, but it does not comply with real life operations. > > I think the RFC should be amended to include the User-ID attribute as MUST. I would disagree as hard wired network lines (PTP T1, FR, Sync lines, etc) may not be using authentication but still generate accounting data. ---- Thomas C Kinnen - "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer" - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 13:32:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA25667 for ; Tue, 9 Feb 1999 13:32:30 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA21319; Tue, 9 Feb 1999 10:17:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA23410 for ietf-radius-outgoing; Tue, 9 Feb 1999 10:19:54 -0800 (PST) Message-ID: <36C07C43.1F6A04B9@iea-software.com> Date: Tue, 09 Feb 1999 10:19:47 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Garini CC: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Jonathan Garini wrote: > > RFC 2139 does not specify the User-Name attribute as a must but rather as a > MAY. > Most of the NASs does send the User-Name in accounting packets. However, we > have seen one NAS that don't send this attribute. This NAS indeed comply > with RFC 2139, but it does not comply with real life operations. > > I think the RFC should be amended to include the User-ID attribute as MUST. There are situations where this is allowed in "real life". For example: 1) Accounting-on and Accounting-Off packets don't have users associated with them. 2) Most NASes send a reboot accounting packet (like Livingston) to signal that it rebooted and all sessions for it should be cleared/closed. 3) Reporting a session-start before authentication (like on modem-answer). 4) Reporting a disconnect problem on modem answer (like the user never did connect, therefore obviously couldn't authenticate). This is a good one for reporting to see what problems you are having. I would recommend a strong SHOULD, but MUST isn't reasonable unless situations like the above are specifically allowed. -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 13:39:07 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA25901 for ; Tue, 9 Feb 1999 13:39:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA21966; Tue, 9 Feb 1999 10:28:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA24849 for ietf-radius-outgoing; Tue, 9 Feb 1999 10:31:11 -0800 (PST) From: Aydin Edguer Message-Id: <199902091829.NAA22544@harlequin.MorningStar.Com> Subject: Re: (radius) RFC2139: User-Name should be MUST To: ietf-radius@livingston.com Date: Tue, 9 Feb 1999 13:29:19 -0500 (EST) Cc: jonathan@mail.extent.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > RFC 2139 does not specify the User-Name attribute as a must but rather > as a MAY. Most of the NASs does send the User-Name in accounting packets. > However, we have seen one NAS that don't send this attribute. This NAS > indeed comply with RFC 2139, but it does not comply with real life > operations. I think the RFC should be amended to include the User-ID > attribute as MUST. I am sorry, but I must disagree. The Accounting-Request message is used for more than just user accounting (i.e. Acct-Status-Type is Start or Stop). These other purposes which are defined in RFC 2139, such as Accounting-On and Accounting-Off do not and should not require a User-Name attribute. In addition with the new tunneling extensions that are becoming available (example: Tunnel-Start) (see draft-ietf-radius-tunnel-acct-02.txt) there may be no user associated with a particular action that is being accounted. Finally, there are some vendor equipment that allows the use of the Accounting-Request, Acct-Status-Type = Stop message for network monitoring of failed sessions which do not yet have a User-Name. This feature can typically be disabled with a configuration parameter on the NAS. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 13:41:03 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA25947 for ; Tue, 9 Feb 1999 13:41:02 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA22155; Tue, 9 Feb 1999 10:30:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA25191 for ietf-radius-outgoing; Tue, 9 Feb 1999 10:33:28 -0800 (PST) Message-ID: From: Jonathan Garini To: "'Dale E. Reed Jr.'" Cc: ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST Date: Tue, 9 Feb 1999 20:29:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jonathan Garini I will still go for a MUST (at least for Account-STOPs). All the scenarios described can be handled by sending an empty string for the User-Name value, like many NASes does currently. Still, if you do have a User-Name you MUST provide it (e.g. if a session was started with Access-Accept than the User-Name attribute must be present in the account stop packet). As to hard wired network lines, these are solved with the same method, and of course, this is an RFC for remote dialup, which should be considered most. Regards, Jonathan. > -----Original Message----- > From: Dale E. Reed Jr. [mailto:daler@iea-software.com] > Sent: Tuesday, February 09, 1999 8:20 PM > To: Jonathan Garini > Cc: ietf-radius@livingston.com > Subject: Re: (radius) RFC2139: User-Name should be MUST > > > Jonathan Garini wrote: > > > > RFC 2139 does not specify the User-Name attribute as a must > but rather as a > > MAY. > > Most of the NASs does send the User-Name in accounting > packets. However, we > > have seen one NAS that don't send this attribute. This NAS > indeed comply > > with RFC 2139, but it does not comply with real life operations. > > > > I think the RFC should be amended to include the User-ID > attribute as MUST. > > There are situations where this is allowed in "real life". > For example: > > 1) Accounting-on and Accounting-Off packets don't have users > associated > with them. > > 2) Most NASes send a reboot accounting packet (like Livingston) to > signal > that it rebooted and all sessions for it should be cleared/closed. > > 3) Reporting a session-start before authentication (like on > modem-answer). > > 4) Reporting a disconnect problem on modem answer (like the user never > did > connect, therefore obviously couldn't authenticate). This > is a good > one > for reporting to see what problems you are having. > > I would recommend a strong SHOULD, but MUST isn't reasonable unless > situations > like the above are specifically allowed. > > -- > Dale E. Reed Jr. (daler@iea-software.com) > _________________________________________________________________ > IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > Internet Solutions for Today | http://www.iea-software.com > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 13:47:19 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA26079 for ; Tue, 9 Feb 1999 13:47:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA22567; Tue, 9 Feb 1999 10:37:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA26105 for ietf-radius-outgoing; Tue, 9 Feb 1999 10:40:27 -0800 (PST) Message-ID: From: Jonathan Garini To: "'Aydin Edguer'" , ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST Date: Tue, 9 Feb 1999 20:36:25 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jonathan Garini My suggestion does not hurt any of the functionality you described. I think you all agree that when dealing with dialup authenticated sessions than we MUST know who the user was. > -----Original Message----- > From: Aydin Edguer [mailto:edguer@MorningStar.Com] > Sent: Tuesday, February 09, 1999 8:29 PM > To: ietf-radius@livingston.com > Cc: jonathan@mail.extent.com > Subject: Re: (radius) RFC2139: User-Name should be MUST > > > > RFC 2139 does not specify the User-Name attribute as a must > but rather > > as a MAY. Most of the NASs does send the User-Name in > accounting packets. > > However, we have seen one NAS that don't send this > attribute. This NAS > > indeed comply with RFC 2139, but it does not comply with real life > > operations. I think the RFC should be amended to include the User-ID > > attribute as MUST. > > I am sorry, but I must disagree. The Accounting-Request > message is used > for more than just user accounting (i.e. Acct-Status-Type is > Start or Stop). > These other purposes which are defined in RFC 2139, such as > Accounting-On > and Accounting-Off do not and should not require a User-Name > attribute. > > In addition with the new tunneling extensions that are > becoming available > (example: Tunnel-Start) (see > draft-ietf-radius-tunnel-acct-02.txt) there > may be no user associated with a particular action that is > being accounted. > > Finally, there are some vendor equipment that allows the use of the > Accounting-Request, Acct-Status-Type = Stop message for > network monitoring > of failed sessions which do not yet have a User-Name. This > feature can > typically be disabled with a configuration parameter on the NAS. > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 13:54:07 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA26327 for ; Tue, 9 Feb 1999 13:54:06 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA22925; Tue, 9 Feb 1999 10:41:41 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA26708 for ietf-radius-outgoing; Tue, 9 Feb 1999 10:44:30 -0800 (PST) From: Aydin Edguer Message-Id: <199902091842.NAA22554@harlequin.MorningStar.Com> Subject: Re: (radius) RFC2139: User-Name should be MUST To: ietf-radius@livingston.com Date: Tue, 9 Feb 1999 13:42:39 -0500 (EST) Cc: jonathan@mail.extent.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > I will still go for a MUST (at least for Account-STOPs). All the scenarios > described can be handled by sending an empty string for the User-Name value, > like many NASes does currently. What is the point of sending a piece of information that (a) has no content and that (b) is not backwards compatible with existing equipment and usage? The only reason why having an empty User-Name is better than having no User-Name is if your server software is unable to accommodate the absence of the attribute. In this case, it would be better to improve the server software to add an empty User-Name or to otherwise deal with it than to add noise to the signal. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 14:06:02 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA26718 for ; Tue, 9 Feb 1999 14:06:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA23387; Tue, 9 Feb 1999 10:51:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA27854 for ietf-radius-outgoing; Tue, 9 Feb 1999 10:54:03 -0800 (PST) Message-ID: From: Jonathan Garini To: "'Aydin Edguer'" , ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST Date: Tue, 9 Feb 1999 20:49:57 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jonathan Garini > > The only reason why having an empty User-Name is better than having no > User-Name is if your server software is unable to accommodate > the absence > of the attribute. In this case, it would be better to > improve the server > software to add an empty User-Name or to otherwise deal with > it than to > add noise to the signal. > I agree here. But Still the client MUST send User-Name for authenticated sessions. Similar procedure that applied for the class attribute should be applied for User-Name. When available in Access-Request MUST be send in accounting as well. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 14:21:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA27126 for ; Tue, 9 Feb 1999 14:21:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA24238; Tue, 9 Feb 1999 11:10:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA00406 for ietf-radius-outgoing; Tue, 9 Feb 1999 11:12:16 -0800 (PST) From: Aydin Edguer Message-Id: <199902091910.OAA22568@harlequin.MorningStar.Com> Subject: RE: (radius) RFC2139: User-Name should be MUST To: ietf-radius@livingston.com Date: Tue, 9 Feb 1999 14:10:25 -0500 (EST) Cc: jonathan@mail.extent.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > My suggestion does not hurt any of the functionality you described. I think > you all agree that when dealing with dialup authenticated sessions than we > MUST know who the user was. First: Having a requirement that if a User-Name is used in the Access-Request that results in an Access-Accept, that the corresponding Accounting-Requests for the service resulting from the Access-Accept include the User-Name is not the same as requiring that all Accounting-Requests include a User-Name. I would disagree with the blanket requirement of a User-Name in every Accounting-Request. Second: Desiring to know who is authenticating is the reason why a User-Name is currently required in the Access-Request message in RFC 2138. However, there are times when you are not providing service based upon a User-Name, but instead upon other information (for example: the Calling-Station-Id). In these situations and others, there is no reason that the User-Name in the Access-Request and the Accounting-Request must correspond and in fact they may not if the Access-Accept includes a User-Name attribute. [This functionality was specifically added to the RADIUS protocol after the release of RFC 2138 - I refer you back to the archives of the mailing list available from [ietf-radius.9704] Date: Thu, 3 Apr 1997 01:50:35 -0800 (PST) From: Carl Rigney Subject: (radius) Agenda for 38th IETF Tue 4/8 15:30-17:30 ... Allowing Usernames in Access-Accepts (for use with Calling-Station-Id)? [ietf-radius.9708] Date: Mon, 25 Aug 1997 23:47:40 -0700 (PDT) From: Carl Rigney Subject: (radius) 38th IETF RADIUS Working Group Minutes ... Usernames are now allowed in Access-Accepts, for example in a case where the User is identified by their Calling-Station-Id. ] If you are trying to match Accounting records with Authentication records, then you can try to use the Class attribute or for some vendors, the Acct-Session-Id to link the messages. I would disagree with requiring the User-Names to *have* to match between an Access-Request and an Accounting-Request. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 14:44:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA27429 for ; Tue, 9 Feb 1999 14:44:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA25184; Tue, 9 Feb 1999 11:34:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA03514 for ietf-radius-outgoing; Tue, 9 Feb 1999 11:37:22 -0800 (PST) Message-ID: From: Jonathan Garini To: "'Aydin Edguer'" , ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST Date: Tue, 9 Feb 1999 21:33:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jonathan Garini > Having a requirement that if a User-Name is used in the > Access-Request that > results in an Access-Accept, that the corresponding > Accounting-Requests for > the service resulting from the Access-Accept include the > User-Name is not > the same as requiring that all Accounting-Requests include a > User-Name. Right. Either will do, but the first method should be easier to implement. > Second: > Desiring to know who is authenticating is the reason why a > User-Name is > currently required in the Access-Request message in RFC 2138. > However, > there are times when you are not providing service based upon > a User-Name, > but instead upon other information (for example: the > Calling-Station-Id). > > In these situations and others, there is no reason that the > User-Name in > the Access-Request and the Accounting-Request must correspond > and in fact > they may not if the Access-Accept includes a User-Name attribute. This is indeed an issue. However, a bigger problem are NASs that NEVER send User-Name in accounting packets. Let me withdraw the implementation issue and stick with the problem (I hope you agree should be solved). Do you have another implementation suggestion that solves this problem? > > If you are trying to match Accounting records with > Authentication records, > then you can try to use the Class attribute or for some vendors, the > Acct-Session-Id to link the messages. > Matching is not issue, the class attribute is indeed the way we workedaround this problem in our server. My concern is not for our server, but for all sites running the general server implementations and won't be able to know to which user an accounting packet belongs to. > I would disagree with requiring the User-Names to *have* to > match between > an Access-Request and an Accounting-Request. > Why do you disagree? Isn't it how most of the NASs are doing anyway? Why shouldn't we make it a stanard, when most users think it is? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 15:00:16 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA27736 for ; Tue, 9 Feb 1999 15:00:15 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA25855; Tue, 9 Feb 1999 11:49:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA05254 for ietf-radius-outgoing; Tue, 9 Feb 1999 11:51:58 -0800 (PST) From: Aydin Edguer Message-Id: <199902091950.OAA22579@harlequin.MorningStar.Com> Subject: RE: (radius) RFC2139: User-Name should be MUST To: ietf-radius@livingston.com Date: Tue, 9 Feb 1999 14:50:05 -0500 (EST) Cc: jonathan@mail.extent.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > This is indeed an issue. However, a bigger problem are NASs that NEVER send > User-Name in accounting packets. I know of no NAS vendor whose products will never send a User-Name attribute in an accounting packet so I cannot comment. Perhaps there is a configuration option that needs to be modified in your current setup. > Let me withdraw the implementation issue and stick with the problem (I hope > you agree should be solved). Do you have another implementation suggestion > that solves this problem? Add the requirement that the NAS include the User-Name attribute (when reasonable) to your purchasing requirements and only buy equipment that meets your needs. File a bug report with the NAS vendor and explain your issues with the product's behavior. Just because the behavior is permitted by a standard does not mean that you must accept the behavior. A reasonable dialogue with the vendor is the best approach in many cases rather than trying to change the standard to fit a specific need that does not necessarily match others' needs. > > I would disagree with requiring the User-Names to *have* to match between > > an Access-Request and an Accounting-Request. > > Why do you disagree? Isn't it how most of the NASs are doing anyway? Why > shouldn't we make it a stanard, when most users think it is? I gave an example. In the case where the user is authenticated using the Calling-Station-Id, the RADIUS server may return a User-Name attribute which changes the User-Name associated with a session and thus the User-Name which will be recorded in the Accounting-Request messages. A vendor who can do this is Ascend Communications. In this case, you can use "CLID" authentication and the User-Name that is included in the Access-Request will be the ASCII reprentation of the phone number (it will be identical to the Calling-Station-Id). By returning the User-Name attribute in the Access-Accept, you can modify the name used for accounting to agree with a "real name" (User-Name = "Frank_Black"). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 15:19:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28081 for ; Tue, 9 Feb 1999 15:19:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA26481; Tue, 9 Feb 1999 12:04:41 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA06911 for ietf-radius-outgoing; Tue, 9 Feb 1999 12:07:29 -0800 (PST) Date: Tue, 9 Feb 99 12:03:49 PST From: William "Chops" Westfield To: Jonathan Garini Cc: "'Aydin Edguer'" , ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST In-Reply-To: Your message of Tue, 9 Feb 1999 20:36:25 +0200 Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William "Chops" Westfield My suggestion does not hurt any of the functionality you described. I think you all agree that when dealing with dialup authenticated sessions than we MUST know who the user was. I disagree. In fact, the cisco accounting code permits accounting to be done without authentication (ie there is never a username.) Accounting is not the same as billing. BillW cisco - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 15:34:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28421 for ; Tue, 9 Feb 1999 15:34:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA27654; Tue, 9 Feb 1999 12:25:05 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA09066 for ietf-radius-outgoing; Tue, 9 Feb 1999 12:27:09 -0800 (PST) Message-ID: From: Jonathan Garini To: "'William \"Chops\" Westfield'" Cc: "'Aydin Edguer'" , ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST Date: Tue, 9 Feb 1999 22:23:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jonathan Garini > My suggestion does not hurt any of the functionality you > described. I > think you all agree that when dealing with dialup authenticated > sessions than we MUST know who the user was. > > I disagree. In fact, the cisco accounting code permits accounting to > be done without authentication (ie there is never a username.) Yes, but Cisco always sends the user-name when it has it, and that's my point. > > Accounting is not the same as billing. > And how can one perform billing if his accounting data useless? Regards, Jonathan. P.S. William, if you in charge for the Radius Cisco code why won't you change it and send Framed-Address in account-start like all the big RAS vendors does? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 15:36:19 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28451 for ; Tue, 9 Feb 1999 15:36:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA27813; Tue, 9 Feb 1999 12:27:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA09341 for ietf-radius-outgoing; Tue, 9 Feb 1999 12:30:04 -0800 (PST) Message-ID: From: Jonathan Garini To: "'Aydin Edguer'" Cc: ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST Date: Tue, 9 Feb 1999 22:26:01 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jonathan Garini > > Add the requirement that the NAS include the User-Name attribute (when > reasonable) to your purchasing requirements and only buy > equipment that > meets your needs. Hmmm... So you think RFCs slips should be dealt this way? > > File a bug report with the NAS vendor and explain your issues with the > product's behavior. Is it a bug? > > Just because the behavior is permitted by a standard does not > mean that > you must accept the behavior. A reasonable dialogue with the > vendor is > the best approach in many cases rather than trying to change > the standard > to fit a specific need that does not necessarily match others' needs. How would the NAS vendor or the customer should know they are doing something wrong. Isn't it our job to prevent such things? How can they figure it for themselves when reading the RFCs? > > > > I would disagree with requiring the User-Names to *have* > to match between > > > an Access-Request and an Accounting-Request. > > > > Why do you disagree? Isn't it how most of the NASs are > doing anyway? Why > > shouldn't we make it a stanard, when most users think it is? > > I gave an example. In the case where the user is authenticated using > the Calling-Station-Id, the RADIUS server may return a > User-Name attribute > which changes the User-Name associated with a session and thus the > User-Name which will be recorded in the Accounting-Request messages. > > A vendor who can do this is Ascend Communications. In this case, you > can use "CLID" authentication and the User-Name that is included in > the Access-Request will be the ASCII reprentation of the phone number > (it will be identical to the Calling-Station-Id). By returning the > User-Name attribute in the Access-Accept, you can modify the name used > for accounting to agree with a "real name" (User-Name = > "Frank_Black"). > What's your point? why do you disagree? I have finished my role here for this thread, I don't like to argue for the sake of the argument nor for what is obvious. The RFC is lacking in this case. I have raised the issue, if you think nothing should be done than let it be. I have no personal interest here neither at the server nor the client side. I have spotted a problem and brought it up you can solve it or leave it, the only people who are hurt are users of vendors who comply with the RFC but still offers a crippled functionality. I can see the narrow interest of a NAS vendor who does not have this problem that it will remain a problem for new RADIUS client implementation, however, I can't see how the RADIUS standard will benefit from such an approach. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 15:42:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28520 for ; Tue, 9 Feb 1999 15:42:30 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA28387; Tue, 9 Feb 1999 12:33:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA10248 for ietf-radius-outgoing; Tue, 9 Feb 1999 12:36:29 -0800 (PST) Message-ID: <36C09D92.A21F5E9A@livingston.com> Date: Tue, 09 Feb 1999 12:41:54 -0800 From: Thomas Kinnen Organization: Lucent Technologies RABU X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Thomas Kinnen Jonathan Garini wrote: > > Accounting is not the same as billing. > And how can one perform billing if his accounting data useless? Not everyone bills based on users. I've seen setups that have billed based on NAS, PORT, Called-Station-Id, Calling-Station-Id, Realm, or combinations of them. Some people don't even use the accounting data for billing but for auditing. ---- Thomas C Kinnen - [Test Engineer - Radius ABM] - LUCENT Technologies RABU "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer" - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 15:49:02 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA28690 for ; Tue, 9 Feb 1999 15:49:02 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA28725; Tue, 9 Feb 1999 12:39:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA11015 for ietf-radius-outgoing; Tue, 9 Feb 1999 12:42:50 -0800 (PST) Message-Id: <199902092049.PAA06685@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-reply-to: Your message of "Tue, 09 Feb 1999 14:50:05 EST." <199902091950.OAA22579@harlequin.MorningStar.Com> Date: Tue, 09 Feb 1999 15:49:50 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok Aydin Edguer said: > By returning the User-Name attribute in the Access-Accept, you can > modify the name used for accounting to agree with a "real name" > (User-Name = "Frank_Black"). ... and ignoring the explicit instructions of the RFC. May I quote from RFC 2138: > The following table provides a guide to which attributes may be found > in which kinds of packets, and in what quantity. > > Request Accept Reject Challenge # Attribute > 1 0 0 0 1 User-Name > ... Sending a User-Name in an Access-Accept is non-compliant behaviour. My preference goes this way: 1 - An Acct-Session-Id SHOULD be in an Access-Request. The presence of the Acct-Session-Id allows the authentication and accounting information to be matched. 2 - If the User-Name attribute is unique (e.g. user name, not CLID hack), then the User-Name SHOULD be in the first Accounting-Request. This will help in the situation where the Acct-Session-Id is NOT sent in the Access-Request. And the Acct-Session-Id in the first Accounting-Request will permit grouping of the accounting data. 3 - Failing that, the server SHOULD send a unique 'Class' to the NAS. This allows the information to be grouped under control of the server. 4 - If the User-Name is NOT unique, and the Acct-Session-Id is unknown, and there's no Class attribute, then there is little hope for matching an Access-Request packet to an Accounting-Request packet. In the case of item #4, we CAN use NAS-Port coupled with NAS-IP-Address, but that's an ugly hack. In your case, your acceptance of User-Name in Access-Accept is incorrect. The Class attribute would be a better choice for a reply attribute. The RFC is a little too vague on the topic of 1-3, as evidenced by the confusion in the current discussion. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 15:57:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAB28812 for ; Tue, 9 Feb 1999 15:57:54 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA29623; Tue, 9 Feb 1999 12:48:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA12190 for ietf-radius-outgoing; Tue, 9 Feb 1999 12:51:57 -0800 (PST) From: Aydin Edguer Message-Id: <199902092050.PAA22600@harlequin.MorningStar.Com> Subject: Re: (radius) RFC2139: User-Name should be MUST To: ietf-radius@livingston.com Date: Tue, 9 Feb 1999 15:50:05 -0500 (EST) Cc: alan@cryptocard.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > > By returning the User-Name attribute in the Access-Accept, you can > > modify the name used for accounting to agree with a "real name" > > (User-Name = "Frank_Black"). > > ... and ignoring the explicit instructions of the RFC. > > May I quote from RFC 2138: You may, but you will then be ignoring the previous message I sent, which quoted from the RADIUS-WG notes that explicitly added the functionality described: [This functionality was specifically added to the RADIUS protocol after the release of RFC 2138 - I refer you back to the archives of the mailing list available from [ietf-radius.9704] Date: Thu, 3 Apr 1997 01:50:35 -0800 (PST) From: Carl Rigney Subject: (radius) Agenda for 38th IETF Tue 4/8 15:30-17:30 ... Allowing Usernames in Access-Accepts (for use with Calling-Station-Id)? [ietf-radius.9708] Date: Mon, 25 Aug 1997 23:47:40 -0700 (PDT) From: Carl Rigney Subject: (radius) 38th IETF RADIUS Working Group Minutes ... Usernames are now allowed in Access-Accepts, for example in a case where the User is identified by their Calling-Station-Id. ] > In your case, your acceptance of User-Name in Access-Accept is incorrect. No, it is not incorrect, because the allowed behavior has been changed since the publication of RFC 2138. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 16:02:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA28982 for ; Tue, 9 Feb 1999 16:02:47 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA29463; Tue, 9 Feb 1999 12:48:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA12077 for ietf-radius-outgoing; Tue, 9 Feb 1999 12:51:06 -0800 (PST) Message-Id: <199902092049.MAA08843@shell4.ba.best.com> Subject: RE: (radius) RFC2139: User-Name should be MUST (fwd) To: ietf-radius@livingston.com Date: Tue, 9 Feb 1999 12:49:55 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Once upon a time Jonathan Garini shaped the electrons to say... >Yes, but Cisco always sends the user-name when it has it, and that's my >point. FACT: A NAS doesn't always have it. FACT: A NAS cannot send something it does not have. Sending a empty value is a bogus hack. MUST is not appropriate, there have been several examples given of when a username would not be sent. You keep fixating on one basic example. It is not appropriate to tailor the RFC to this situation. I would agree that MAY could be too weak and it could be upgraded to a 'SHOULD', which is stronger. But I simply cannot accept a MUST for this AVP, I have not seen any reasonable argument that supports this claim. Your argument is just too weak. I would agree it is generally a good idea to send information that you have, so if the NAS has User-Name then it SHOULD send it. But I don't think we should presume that it MUST always be sent, especially as this is not a minor change to an RFC that has been as is for years. Changing it to SHOULD still provides some leeway. And in the end it is up to the end user to ensure that the NAS they purchase supports the values that they need. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 16:09:55 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29119 for ; Tue, 9 Feb 1999 16:09:54 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA00453; Tue, 9 Feb 1999 13:00:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA13611 for ietf-radius-outgoing; Tue, 9 Feb 1999 13:03:19 -0800 (PST) Message-ID: From: Jonathan Garini To: "'MegaZone'" Cc: ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST (fwd) Date: Tue, 9 Feb 1999 22:59:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jonathan Garini Since my initial message I have changed my suggestion to MUST where sessions are authenticated. I am not fixating on a general MUST, but on a specific MUST where it is an authenticated session. Same way you MUST send the class in accounting where it was in Access-Accept, but you don't need to send it if it wasn't. > -----Original Message----- > From: MegaZone [mailto:megazone@megazone.org] > Sent: Tuesday, February 09, 1999 10:50 PM > To: ietf-radius@livingston.com > Subject: RE: (radius) RFC2139: User-Name should be MUST (fwd) > > > Once upon a time Jonathan Garini shaped the electrons to say... > >Yes, but Cisco always sends the user-name when it has it, > and that's my > >point. > > FACT: A NAS doesn't always have it. > FACT: A NAS cannot send something it does not have. > > Sending a empty value is a bogus hack. MUST is not > appropriate, there > have been several examples given of when a username would not > be sent. You > keep fixating on one basic example. It is not appropriate to > tailor the > RFC to this situation. > > I would agree that MAY could be too weak and it could be upgraded to a > 'SHOULD', which is stronger. But I simply cannot accept a > MUST for this > AVP, I have not seen any reasonable argument that supports this claim. > Your argument is just too weak. > > I would agree it is generally a good idea to send information > that you have, > so if the NAS has User-Name then it SHOULD send it. But I > don't think we > should presume that it MUST always be sent, especially as > this is not a > minor change to an RFC that has been as is for years. Changing it to > SHOULD still provides some leeway. > > And in the end it is up to the end user to ensure that the > NAS they purchase > supports the values that they need. > > -MZ > -- > -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 > X*=- > Gweep, Discordian, Author, > Engineer, me.. > Join ISP/C Internet Service Providers' Consortium > > "A little nonsense now and then, is relished by the wisest > men" 781-788-0130 > > Hail Discordia! > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 16:12:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29228 for ; Tue, 9 Feb 1999 16:12:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA01000; Tue, 9 Feb 1999 13:02:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA13916 for ietf-radius-outgoing; Tue, 9 Feb 1999 13:05:35 -0800 (PST) Message-Id: <3.0.5.32.19990209160526.036e2c70@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 09 Feb 1999 16:05:26 -0500 To: Alan DeKok , ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: <199902092049.PAA06685@cryptocard.ott.igs.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton At 03:49 PM 2/9/99 -0500, Alan DeKok wrote: >Aydin Edguer said: > >> By returning the User-Name attribute in the Access-Accept, you can >> modify the name used for accounting to agree with a "real name" >> (User-Name = "Frank_Black"). > > ... and ignoring the explicit instructions of the RFC. > > May I quote from RFC 2138: > >> The following table provides a guide to which attributes may be found >> in which kinds of packets, and in what quantity. >> >> Request Accept Reject Challenge # Attribute >> 1 0 0 0 1 User-Name >> ... > > Sending a User-Name in an Access-Accept is non-compliant behaviour. > > > My preference goes this way: > >1 - An Acct-Session-Id SHOULD be in an Access-Request. > > The presence of the Acct-Session-Id allows the authentication and > accounting information to be matched. > > >2 - If the User-Name attribute is unique (e.g. user name, not CLID hack), > then the User-Name SHOULD be in the first Accounting-Request. > > This will help in the situation where the Acct-Session-Id is NOT > sent in the Access-Request. And the Acct-Session-Id in the first > Accounting-Request will permit grouping of the accounting data. > > >3 - Failing that, the server SHOULD send a unique 'Class' to the NAS. > This allows the information to be grouped under control of the server. > > >4 - If the User-Name is NOT unique, and the Acct-Session-Id is unknown, > and there's no Class attribute, then there is little hope for matching > an Access-Request packet to an Accounting-Request packet. > > > In the case of item #4, we CAN use NAS-Port coupled with >NAS-IP-Address, but that's an ugly hack. I'm sorry, but you cannot depend on User-Name to be unique at all. The same user could be logging in multiple times (especially with multi-link ppp) and without authentication there could be "others" attempting authentication on other ports. I would submit that the proper way to generate a robust unique session key is to combine all of, as best you can, NAS-IP-Address, NAS-Port-Type*, NAS-Port-Number, User-Name, and Acct-Session-ID. And you will have to use place-holders and/or soft matching logic to make this work over multiple vendors, and the Access-Request to Acct-Request(Start) gap. In the later case, if you are a server vendor, you get to control the Class attribute to help matters. But clients should not be generating their own Class. *(not all NASes generate unique port numbers across all port types) Further more there are Acct messages other than Start & Stop and a robust server should recognize this and ignore them. Dave. > > In your case, your acceptance of User-Name in Access-Accept is >incorrect. The Class attribute would be a better choice for a reply >attribute. > > The RFC is a little too vague on the topic of 1-3, as evidenced by >the confusion in the current discussion. > > Alan DeKok. >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 16:15:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29296 for ; Tue, 9 Feb 1999 16:15:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA01187; Tue, 9 Feb 1999 13:05:21 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA14304 for ietf-radius-outgoing; Tue, 9 Feb 1999 13:08:17 -0800 (PST) Message-ID: From: Jonathan Garini To: "'William \"Chops\" Westfield'" Cc: ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST Date: Tue, 9 Feb 1999 23:04:13 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jonathan Garini > I disagree. In fact, the cisco accounting code permits accounting to > be done without authentication (ie there is never a username.) > BTW, Cisco is an example of a vendor who always send the User-Name in accounting even for account starts of dedicated lines, where it uses an empty string for the Value. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 16:18:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29356 for ; Tue, 9 Feb 1999 16:18:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA01439; Tue, 9 Feb 1999 13:08:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA14779 for ietf-radius-outgoing; Tue, 9 Feb 1999 13:11:35 -0800 (PST) From: Aydin Edguer Message-Id: <199902092109.QAA22609@harlequin.MorningStar.Com> Subject: Re: (radius) RFC2139: User-Name should be MUST (fwd) To: ietf-radius@livingston.com Date: Tue, 9 Feb 1999 16:09:45 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > I would agree it is generally a good idea to send information that you have, > so if the NAS has User-Name then it SHOULD send it. But I don't think we > should presume that it MUST always be sent, especially as this is not a > minor change to an RFC that has been as is for years. I would agree with this observation and viewpoint. If the NAS has a User-Name associated with the service being accounted, then it SHOULD send the User-Name in the Accounting-Request. I would disagree that a NAS must include a User-Name (even if there is no User-Name associated with the record). I would add that there are no guarantees that the User-Name in the Accounting-Request will be the same as the User-Name in the initial Access-Request. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 16:44:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29720 for ; Tue, 9 Feb 1999 16:44:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA02584; Tue, 9 Feb 1999 13:34:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA17642 for ietf-radius-outgoing; Tue, 9 Feb 1999 13:37:37 -0800 (PST) Message-ID: <36C0AA99.C4628434@iea-software.com> Date: Tue, 09 Feb 1999 13:37:29 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Aydin Edguer CC: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST References: <199902091842.NAA22554@harlequin.MorningStar.Com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Aydin Edguer wrote: > > > I will still go for a MUST (at least for Account-STOPs). All the scenarios > > described can be handled by sending an empty string for the User-Name value, > > like many NASes does currently. > > What is the point of sending a piece of information that (a) has no content > and that (b) is not backwards compatible with existing equipment and usage? > > The only reason why having an empty User-Name is better than having no > User-Name is if your server software is unable to accommodate the absence > of the attribute. In this case, it would be better to improve the server > software to add an empty User-Name or to otherwise deal with it than to > add noise to the signal. I agree with this 100%. On the server side we have all had to deal with this and I don't see any need to change the RFC to a MUST for it. -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 17:16:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00119 for ; Tue, 9 Feb 1999 17:16:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA04229; Tue, 9 Feb 1999 14:04:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA21449 for ietf-radius-outgoing; Tue, 9 Feb 1999 14:07:02 -0800 (PST) Message-ID: <36C0B051.DB411CB8@iea-software.com> Date: Tue, 09 Feb 1999 14:01:53 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Garini CC: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Jonathan Garini wrote: > > Matching is not issue, the class attribute is indeed the way we workedaround > this problem in our server. My concern is not for our server, but for all > sites running the general server implementations and won't be able to know > to which user an accounting packet belongs to. I think the real problem is using a RADIUS client implementation that is less than useful (like not sending usernames consistently in the account records). You should be talking to the vendor of that product to see if they have an update to correct the problem. In my many years with RADIUS this is really a 1% of 1% type issue, and not something that happens alot. > > I would disagree with requiring the User-Names to *have* to > > match between > > an Access-Request and an Accounting-Request. > > > > Why do you disagree? Isn't it how most of the NASs are doing anyway? Why > shouldn't we make it a stanard, when most users think it is? There are uses where the authenticated name in an Accept-Request is the CallerID number. The Accept-Accept returns a different username for the NAS to report the accounting with. Therefore, the two wont match. -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 17:26:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA00410 for ; Tue, 9 Feb 1999 17:26:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA05086; Tue, 9 Feb 1999 14:16:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA23134 for ietf-radius-outgoing; Tue, 9 Feb 1999 14:19:42 -0800 (PST) Message-ID: <36C0B34A.AE81AD1E@iea-software.com> Date: Tue, 09 Feb 1999 14:14:34 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Garini CC: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Jonathan Garini wrote: > > > I disagree. In fact, the cisco accounting code permits accounting to > > be done without authentication (ie there is never a username.) > > BTW, Cisco is an example of a vendor who always send the User-Name in > accounting even for account starts of dedicated lines, where it uses an > empty string for the Value. An AVP Pair length of 2 is non-RFC compliant (a blank data field). Many NASes send them (Ascend, USR, Cisco, ...) but that doesn't mean the RFC should be again updated to police this. Its up to us to not only follow the RFC, but use atleast SOME common sense when working with RADIUS so that we can get our products to work together. If you have a customer that bought RADIUS client x and it doesn't include a username and that makes your product not work, your customer has two choices (assuming that talking to your and the vendor doesn't work): 1) buy a new RADIUS client 2) buy a new RADIUS server It really isn't any more complicated than that. :) -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 18:24:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA01385 for ; Tue, 9 Feb 1999 18:24:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA07323; Tue, 9 Feb 1999 15:14:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA29368 for ietf-radius-outgoing; Tue, 9 Feb 1999 15:17:25 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Tue, 9 Feb 1999 18:10 EST Subject: Re: (radius) RFC2139: User-Name should be MUST Content-Type: text/plain Message-ID: <36c0c1f90.1d51@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff > Date: Tue, 09 Feb 1999 14:14:34 -0800 > From: "Dale E. Reed Jr." > > An AVP Pair length of 2 is non-RFC compliant (a blank data field). > Many NASes send them (Ascend, USR, Cisco, ...) but that doesn't mean > the RFC should be again updated to police this. Its up to us to > not only follow the RFC, but use atleast SOME common sense when > working with RADIUS so that we can get our products to work together. Well, that is not true in general, only for specific attribute types. In fact, requiring a non-empty value has always been on the order of a typo, rather than a well-considered and agreed-on decision. It has, in fact, misled at least one vendor (you know who you are) into adding a trailing null on non-empty string attributes. We're well into the gray area between NASREQ (of blessed memory?) and RADIUS. It would be an outrage to tolerate a NAS that knows the user's identity but omits it from an acct start/stop. If anybody cares, I'm in the camp that would not send a fake empty user attribute, but would make it a MUST that the attribute be sent if the user is known. So now both sides can hate me. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 9 19:44:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02134 for ; Tue, 9 Feb 1999 19:44:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA09575; Tue, 9 Feb 1999 16:28:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA06059 for ietf-radius-outgoing; Tue, 9 Feb 1999 16:29:03 -0800 (PST) From: marketinglist-request@qube.djbm.com Message-Id: <199902100024.SAA13239@qube.djbm.com> Date: 2/9/99 6:00:08 PM Central Daylight Time To: marketinglist-request@qube.djbm.com Subject: (radius) member List Free Offer Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: marketinglist-request@qube.djbm.com ************************************************* This mailing list is member only : and there are 2 addresses to be unsubscribed and removed from this list. We maintain upwards of 500 websites that offer free information in exchange for joining this list. You may JOIN or LEAVE this list at any time by following the simple instructions that can be found at the end of this email. Or e-mail reply with REMOVE in subject line TO: mdb@qube.djbm.com ************************************************* Todays recomendation: FREE CASSETTE TAPE The Silver Bullet cassette tape that Could Make you a fortune! Get your FREE copy click here: http://www.djbm.com/rg.htm Click here ------------------------------------------------- To SUBSCRIBE a friend to the List: ------------------------------------------------- Have them send a blank email to: marketinglist-request@djbm.com with the word "subscribe" in the subject line (no quotes). or click here: mailto:marketinglist-request@djbm.com?subject=subscribe ------------------------------------------------- To UNSUBSCRIBE your Email Address from the List: ------------------------------------------------- Send a blank email to: marketinglist-request@djbm.com with the word "unsubscribe" in the subject line (no quotes). or click here: mailto:marketinglist-request@djbm.com?subject=unsubscribe - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 04:11:19 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA13888 for ; Wed, 10 Feb 1999 04:11:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA24863; Wed, 10 Feb 1999 01:00:56 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA00446 for ietf-radius-outgoing; Wed, 10 Feb 1999 01:01:12 -0800 (PST) Message-ID: <36C14ACD.C3E8C651@iea-software.com> Date: Wed, 10 Feb 1999 01:01:01 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Barney Wolff CC: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST References: <36c0c1f90.1d51@databus.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Barney Wolff wrote: > > > An AVP Pair length of 2 is non-RFC compliant (a blank data field). > > Many NASes send them (Ascend, USR, Cisco, ...) but that doesn't mean > > the RFC should be again updated to police this. Its up to us to > > not only follow the RFC, but use atleast SOME common sense when > > working with RADIUS so that we can get our products to work together. > > Well, that is not true in general, only for specific attribute types. > In fact, requiring a non-empty value has always been on the order of > a typo, rather than a well-considered and agreed-on decision. It has, > in fact, misled at least one vendor (you know who you are) into adding > a trailing null on non-empty string attributes. RFC 2138 says: > Length > > The Length field is one octet, and indicates the length of this > Attribute including the Type, Length and Value fields. If an > Attribute is received in an Access-Request but with an invalid > Length, an Access-Reject SHOULD be transmitted. If an Attribute > is received in an Access-Accept, Access-Reject or Access-Challenge > packet with an invalid length, the packet MUST either be treated > an Access-Reject or else silently discarded. Now, almost all of the attributes of variable lengths (like username) say: > Type > 1 for User-Name. > > Length > >= 3 Now, reading the above, if we receive a request with the following data: ... 01 02 04 06 ff 00 00 01 ... Where 01 is the Username AVP, and 04 is the NAS-IP-Address AVP, then the length specifier for the username is NOT ">= 3" which means its "invalid" and "MUST" be either silently discarded or sent an Access-Reject. Looking at 2139: > Length > > The Length field is one octet, and indicates the length of this > attribute including the Type, Length and Value fields. If an > attribute is received in an Accounting-Request with an invalid > Length, the entire request should be silently discarded. And you can guess the rest. This is what I am talking about. I know of ATLEAST 4 major NAS vendors that send an AVP pair with a length of 2, which if you interpret the above strictly, cause major pains with Authentication and Accounting. Now if we require that the username attribute be required (even if there is no username itself), then to follow the RFC as I've noted above, it would have to contain atleast one character or something (read, kludge). -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 10:19:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA15973 for ; Wed, 10 Feb 1999 10:19:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA08330; Wed, 10 Feb 1999 07:09:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA18457 for ietf-radius-outgoing; Wed, 10 Feb 1999 07:10:09 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Wed, 10 Feb 1999 09:57 EST Subject: Re: (radius) RFC2139: User-Name should be MUST Content-Type: text/plain Message-ID: <36c1a1450.2879@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff How about reading what's right after the definition of the Length, namely the Value definition, which does say "zero or more octets." By my way of thinking, an invalid length is <2 or beyond the end of the packet, making further processing impossible. At best, you can claim that an empty attribute of a type that is not allowed to be empty makes its *attribute* invalid, but not the whole packet. "Be conservative in what you send, liberal in what you accept." Barney Wolff > Date: Wed, 10 Feb 1999 01:01:01 -0800 > From: "Dale E. Reed Jr." > To: Barney Wolff > Cc: ietf-radius@livingston.com > Subject: Re: (radius) RFC2139: User-Name should be MUST > Content-Length: 2825 > Reply-To: "Dale E. Reed Jr." > > RFC 2138 says: > > > Length > > > > The Length field is one octet, and indicates the length of this > > Attribute including the Type, Length and Value fields. If an > > Attribute is received in an Access-Request but with an invalid > > Length, an Access-Reject SHOULD be transmitted. If an Attribute > > is received in an Access-Accept, Access-Reject or Access-Challenge > > packet with an invalid length, the packet MUST either be treated > > an Access-Reject or else silently discarded. > > Now, almost all of the attributes of variable lengths (like username) > say: > > > Type > > 1 for User-Name. > > > > Length > > >= 3 > > Now, reading the above, if we receive a request with the following data: > > ... 01 02 04 06 ff 00 00 01 ... > > Where 01 is the Username AVP, and 04 is the NAS-IP-Address AVP, then > the length specifier for the username is NOT ">= 3" which means its > "invalid" and "MUST" be either silently discarded or sent an > Access-Reject. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 13:34:07 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA20625 for ; Wed, 10 Feb 1999 13:34:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA19186; Wed, 10 Feb 1999 10:24:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA08693 for ietf-radius-outgoing; Wed, 10 Feb 1999 10:26:17 -0800 (PST) Message-ID: <36C1CF41.EDAD8F7D@iea-software.com> Date: Wed, 10 Feb 1999 10:26:09 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Barney Wolff CC: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST References: <36c1a1450.2879@databus.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Barney Wolff wrote: > > How about reading what's right after the definition of the Length, > namely the Value definition, which does say "zero or more octets." > By my way of thinking, an invalid length is <2 or beyond the end of > the packet, making further processing impossible. At best, you can > claim that an empty attribute of a type that is not allowed to be > empty makes its *attribute* invalid, but not the whole packet. Then the RFC needs to either adjust the value to 1 or more or the length to >= 2. How can you have zero octets and maintain a length of three? > > > Length, an Access-Reject SHOULD be transmitted. If an Attribute > > > is received in an Access-Accept, Access-Reject or Access-Challenge > > > packet with an invalid length, the packet MUST either be treated > > > an Access-Reject or else silently discarded. I do agree that ignoring the attribute would be good, but the RFC says "PACKET" not attribute. It actually makes since though, since if the attribute length if bad, then rest of the packet may be bad. I just go by what the RFC says. :) -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 14:14:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA21356 for ; Wed, 10 Feb 1999 14:14:35 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA21084; Wed, 10 Feb 1999 11:03:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA13840 for ietf-radius-outgoing; Wed, 10 Feb 1999 11:06:10 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Wed, 10 Feb 1999 10:58:06 -0800 (PST) From: Glen Zorn To: "Dale E. Reed Jr." cc: Barney Wolff , ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: <36C1CF41.EDAD8F7D@iea-software.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Wed, 10 Feb 1999, Dale E. Reed Jr. wrote: > Barney Wolff wrote: > > > > How about reading what's right after the definition of the Length, > > namely the Value definition, which does say "zero or more octets." The individual attribute descriptions state (at least) the minimum length of the attribute. I can't find any attributes for which the minimum length is less than three, which means that empty value fields are illegal for the standard attributes. The passage you cite makes it possible to define a legal RADIUS attribute with a zero-length Value field but that seems irrelevant in the current context. > > By my way of thinking, an invalid length is <2 or beyond the end of > > the packet, making further processing impossible. At best, you can > > claim that an empty attribute of a type that is not allowed to be > > empty makes its *attribute* invalid, but not the whole packet. The RFC is pretty specific about this. > > Then the RFC needs to either adjust the value to 1 or more or the > length to >= 2. How can you have zero octets and maintain a > length of three? > > > > > Length, an Access-Reject SHOULD be transmitted. If an Attribute > > > > is received in an Access-Accept, Access-Reject or Access-Challenge > > > > packet with an invalid length, the packet MUST either be treated > > > > an Access-Reject or else silently discarded. > > I do agree that ignoring the attribute would be good, but the RFC > says "PACKET" not attribute. It actually makes since though, since > if the attribute length if bad, then rest of the packet may be > bad. I just go by what the RFC says. :) > > > -- > Dale E. Reed Jr. (daler@iea-software.com) > _________________________________________________________________ > IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > Internet Solutions for Today | http://www.iea-software.com > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 14:20:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA21473 for ; Wed, 10 Feb 1999 14:20:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA21496; Wed, 10 Feb 1999 11:11:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA14849 for ietf-radius-outgoing; Wed, 10 Feb 1999 11:14:06 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Wed, 10 Feb 1999 14:08 EST Subject: Re: (radius) RFC2139: User-Name should be MUST Content-Type: text/plain Message-ID: <36c1da790.2e23@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff > Date: Wed, 10 Feb 1999 10:58:06 -0800 (PST) > From: Glen Zorn > (BW assertion): > > > By my way of thinking, an invalid > length is <2 or beyond the end > of > > the packet, making further processing impossible. At best, you can > > > claim that an empty attribute of a type that is not allowed to be > > > empty makes its *attribute* invalid, but not the whole packet. > > The RFC is pretty specific about this. Well, no, it isn't. Since we're talking here about 2139, let's remember that the actual text does not say "MUST" or even "SHOULD" but just "should." So even if you interpret "invalid" to mean "invalid for this particular attribute" the acct server is free to ignore the "error" if it has good reason. Hey, live by strict construction, die by strict construction. Barney, who's done arguing this point - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 14:53:55 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA21924 for ; Wed, 10 Feb 1999 14:53:54 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA23000; Wed, 10 Feb 1999 11:33:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA17358 for ietf-radius-outgoing; Wed, 10 Feb 1999 11:35:53 -0800 (PST) Message-Id: <199902101935.OAA00810@cryptocard.ott.igs.net> To: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-reply-to: Your message of "Wed, 10 Feb 1999 09:57:00 EST." <36c1a1450.2879@databus.databus.com> Date: Wed, 10 Feb 1999 14:35:01 -0500 From: Alan DeKok Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok > How about reading what's right after the definition of the Length, > namely the Value definition, which does say "zero or more octets." And which appears to be contradicting the "Length >= 3" specification in every string attribute. I choose one definition, you choose another, and we have non-interoperating implementations. > By my way of thinking, an invalid length is <2 or beyond the end of > the packet, making further processing impossible. At best, you can > claim that an empty attribute of a type that is not allowed to be > empty makes its *attribute* invalid, but not the whole packet. An empty string attribute may not be meaningless. I can't figure out what it would mean, but enough implementations use them that there must be SOME rational purpose behind them. > "Be conservative in what you send, liberal in what you accept." Is this necessarily a good philosophy for a secure authentication and authorization server? Can you implement a security policy in the face of unknown or ambiguous information? We're forced to come up with new hacks every time we test our server against another NAS, or another NAS vendor. I'd prefer a well-defined protocol that isn't ambiguous (e.g. w.r.t. Length), vendor implementations that don't vary randomly from the spec, or at least some agreement on the Right Way of Doing Things. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 15:08:03 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA22145 for ; Wed, 10 Feb 1999 15:08:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA24243; Wed, 10 Feb 1999 11:52:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA19474 for ietf-radius-outgoing; Wed, 10 Feb 1999 11:55:23 -0800 (PST) Message-Id: <3.0.5.32.19990210145452.02e8f290@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 10 Feb 1999 14:54:52 -0500 To: Alan DeKok , ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: <199902101935.OAA00810@cryptocard.ott.igs.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton You have now achieved enlightenment. Welcome to the RADIUS working group. ;^p Dave. At 02:35 PM 2/10/99 -0500, Alan DeKok wrote: >> How about reading what's right after the definition of the Length, >> namely the Value definition, which does say "zero or more octets." > > And which appears to be contradicting the "Length >= 3" >specification in every string attribute. I choose one definition, you >choose another, and we have non-interoperating implementations. > >> By my way of thinking, an invalid length is <2 or beyond the end of >> the packet, making further processing impossible. At best, you can >> claim that an empty attribute of a type that is not allowed to be >> empty makes its *attribute* invalid, but not the whole packet. > > An empty string attribute may not be meaningless. I can't figure >out what it would mean, but enough implementations use them that there >must be SOME rational purpose behind them. > >> "Be conservative in what you send, liberal in what you accept." > > Is this necessarily a good philosophy for a secure authentication >and authorization server? Can you implement a security policy in the >face of unknown or ambiguous information? > > We're forced to come up with new hacks every time we test our server >against another NAS, or another NAS vendor. I'd prefer a well-defined >protocol that isn't ambiguous (e.g. w.r.t. Length), vendor >implementations that don't vary randomly from the spec, or at least >some agreement on the Right Way of Doing Things. > > Alan DeKok. >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 15:17:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA22232 for ; Wed, 10 Feb 1999 15:17:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA25050; Wed, 10 Feb 1999 12:04:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA20854 for ietf-radius-outgoing; Wed, 10 Feb 1999 12:07:46 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Wed, 10 Feb 1999 11:59:43 -0800 (PST) From: Glen Zorn To: Barney Wolff cc: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: <36c1da790.2e23@databus.databus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Wed, 10 Feb 1999, Barney Wolff wrote: > > Date: Wed, 10 Feb 1999 10:58:06 -0800 (PST) > > From: Glen Zorn > > > (BW assertion): > > > > By my way of thinking, an invalid > > length is <2 or beyond the end > > of > > the packet, making further processing impossible. At best, you can > > > > claim that an empty attribute of a type that is not allowed to be > > > > empty makes its *attribute* invalid, but not the whole packet. > > > > The RFC is pretty specific about this. > > Well, no, it isn't. Since we're talking here about 2139, let's remember > that the actual text does not say "MUST" or even "SHOULD" but just "should." In section 1.1 it uses the standard definition of requirements specification, which says about "should", "must", etc. that these words are "often capitalized". I take this to mean that "should" = "SHOULD" in the context of specifying a requirement (which the "Length" paragraph is apparently meant to do). > So even if you interpret "invalid" to mean "invalid for this particular > attribute" the acct server is free to ignore the "error" if it has good > reason. Sure, that's true for 2138 too, but what's a "good reason"? Just MHO, but I don't think that hacking to get around protocol lameness is a good reason (except _very_ short term) but that seems to be what we've been reduced to... >Hey, live by strict construction, die by strict construction. > > Barney, who's done arguing this point > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 15:19:42 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA22270 for ; Wed, 10 Feb 1999 15:19:41 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA25377; Wed, 10 Feb 1999 12:09:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA21330 for ietf-radius-outgoing; Wed, 10 Feb 1999 12:12:16 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Wed, 10 Feb 1999 12:04:14 -0800 (PST) From: Glen Zorn To: Alan DeKok cc: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: <199902101935.OAA00810@cryptocard.ott.igs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Wed, 10 Feb 1999, Alan DeKok wrote: > > How about reading what's right after the definition of the Length, > > namely the Value definition, which does say "zero or more octets." > > And which appears to be contradicting the "Length >= 3" > specification in every string attribute. I choose one definition, you > choose another, and we have non-interoperating implementations. There's no contradiction. Attributes with zero-length Value fields are legal in RADIUS, but no standard attributes have zero-length Value fields. > > > By my way of thinking, an invalid length is <2 or beyond the end of > > the packet, making further processing impossible. At best, you can > > claim that an empty attribute of a type that is not allowed to be > > empty makes its *attribute* invalid, but not the whole packet. > > An empty string attribute may not be meaningless. I can't figure > out what it would mean, but enough implementations use them that there > must be SOME rational purpose behind them. And that's legal, as long as the attribute in question is not a standard one. > > > "Be conservative in what you send, liberal in what you accept." > > Is this necessarily a good philosophy for a secure authentication > and authorization server? Can you implement a security policy in the > face of unknown or ambiguous information? > > We're forced to come up with new hacks every time we test our server > against another NAS, or another NAS vendor. I'd prefer a well-defined > protocol that isn't ambiguous (e.g. w.r.t. Length), vendor > implementations that don't vary randomly from the spec, or at least > some agreement on the Right Way of Doing Things. May I suggest Diameter? > > Alan DeKok. > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 15:28:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA22354 for ; Wed, 10 Feb 1999 15:28:46 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA26128; Wed, 10 Feb 1999 12:20:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA22383 for ietf-radius-outgoing; Wed, 10 Feb 1999 12:23:05 -0800 (PST) Date: Wed, 10 Feb 99 12:18:41 PST From: William "Chops" Westfield To: Glen Zorn Cc: "Dale E. Reed Jr." , Barney Wolff , ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: Your message of Wed, 10 Feb 1999 10:58:06 -0800 (PST) Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William "Chops" Westfield We had to fix a bug in cisco radius where a null username (typed by the user) was passed to the radius authentication request packet as a zero-length username (length 2 attribute.) It must have been upsetting someone. I guess we didn't handle the equivilent case for accounting. (for authen, the fix was not to permit a null username at the UI level.) BillW - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 15:42:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA22522 for ; Wed, 10 Feb 1999 15:42:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA26936; Wed, 10 Feb 1999 12:27:56 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA23525 for ietf-radius-outgoing; Wed, 10 Feb 1999 12:30:45 -0800 (PST) Message-Id: <199902102029.PAA00900@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-reply-to: Your message of "Wed, 10 Feb 1999 12:04:14 PST." Date: Wed, 10 Feb 1999 15:29:56 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok > There's no contradiction. Attributes with zero-length Value fields are > legal in RADIUS, but no standard attributes have zero-length Value fields. ... as defined in the RFC's. But if I believed the RFC's, my RADIUS server would discard packets from most major NAS vendors. (sigh) > > I'd prefer a well-defined > > protocol that isn't ambiguous (e.g. w.r.t. Length), vendor > > implementations that don't vary randomly from the spec, or at least > > some agreement on the Right Way of Doing Things. > > May I suggest Diameter? Will Diameter protect me from vendors who decide to implement part of the RFC, ignore part of the RFC, or add their own weirdness to the protocol? I'm optimistic, but also prepared for the worst. I think it would help if we had a reference implementation against which we could measure standards compliance. (e.g. bind.) I hope that such an implementation becomes available before Diameter is widely used, or we'll end up suffering the same problems as we now have with Radius. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 16:24:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA23081 for ; Wed, 10 Feb 1999 16:24:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA29093; Wed, 10 Feb 1999 13:11:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA27973 for ietf-radius-outgoing; Wed, 10 Feb 1999 13:14:37 -0800 (PST) Message-ID: <36C1F6B5.B2760DE9@iea-software.com> Date: Wed, 10 Feb 1999 13:14:29 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alan DeKok CC: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST References: <199902102029.PAA00900@cryptocard.ott.igs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Alan DeKok wrote: > > > There's no contradiction. Attributes with zero-length Value fields are > > legal in RADIUS, but no standard attributes have zero-length Value fields. > > ... as defined in the RFC's. > > But if I believed the RFC's, my RADIUS server would discard packets > from most major NAS vendors. (sigh) As DOES ours, unless the user turns on the "Allow Malformed" option, which is becoming a support nightmare and is now the default. So now our pacakge isn't considered RFC compliant, unless they uncheck a default. :( -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 16:44:07 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA23460 for ; Wed, 10 Feb 1999 16:44:06 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA00590; Wed, 10 Feb 1999 13:27:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA29474 for ietf-radius-outgoing; Wed, 10 Feb 1999 13:30:35 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Wed, 10 Feb 1999 13:22:32 -0800 (PST) From: Glen Zorn To: Alan DeKok cc: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: <199902102029.PAA00900@cryptocard.ott.igs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Wed, 10 Feb 1999, Alan DeKok wrote: > > There's no contradiction. Attributes with zero-length Value fields are > > legal in RADIUS, but no standard attributes have zero-length Value fields. > > ... as defined in the RFC's. > > But if I believed the RFC's, my RADIUS server would discard packets > from most major NAS vendors. (sigh) > > > > I'd prefer a well-defined > > > protocol that isn't ambiguous (e.g. w.r.t. Length), vendor > > > implementations that don't vary randomly from the spec, or at least > > > some agreement on the Right Way of Doing Things. > > > > May I suggest Diameter? > > Will Diameter protect me from vendors who decide to implement part > of the RFC, ignore part of the RFC, or add their own weirdness to the > protocol? I'm optimistic, but also prepared for the worst. Nothing can protect you from wanton ignorance or disregard of the standards. A lot of the behavior yopu're talking about is, I think, just implemented because RADIUS is not capable of doing what customers need. I believe that Diameter is being designed to avoid those kind of pitfalls e.g., with standard support for vendor-specific attributes _from the start_, and attribute space that is large enough that assignment need not be penuriious, server-initiated message exchanges, etc.). > > I think it would help if we had a reference implementation against > which we could measure standards compliance. (e.g. bind.) I hope > that such an implementation becomes available before Diameter is > widely used, or we'll end up suffering the same problems as we now > have with Radius. I don't think that a reference implementation is the answer here, just a protocol that's _really_ (as opposed to merely claimed to be) flexible and extensible. > > Alan DeKok. > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 16:48:27 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA23697 for ; Wed, 10 Feb 1999 16:48:26 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA00756; Wed, 10 Feb 1999 13:30:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA29746 for ietf-radius-outgoing; Wed, 10 Feb 1999 13:33:07 -0800 (PST) Date: Wed, 10 Feb 1999 13:29:43 -0800 (PST) From: "pcalhoun@eng.sun.com" Subject: Re: (radius) RFC2139: User-Name should be MUST To: Alan DeKok Cc: ietf-radius@livingston.com In-Reply-To: "Your message with ID" <199902102029.PAA00900@cryptocard.ott.igs.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "pcalhoun@eng.sun.com" > > There's no contradiction. Attributes with zero-length Value fields are > > legal in RADIUS, but no standard attributes have zero-length Value fields. > > ... as defined in the RFC's. > > But if I believed the RFC's, my RADIUS server would discard packets > from most major NAS vendors. (sigh) > > > > I'd prefer a well-defined > > > protocol that isn't ambiguous (e.g. w.r.t. Length), vendor > > > implementations that don't vary randomly from the spec, or at least > > > some agreement on the Right Way of Doing Things. > > > > May I suggest Diameter? > > Will Diameter protect me from vendors who decide to implement part > of the RFC, ignore part of the RFC, or add their own weirdness to the > protocol? I'm optimistic, but also prepared for the worst. > > I think it would help if we had a reference implementation against > which we could measure standards compliance. (e.g. bind.) I hope > that such an implementation becomes available before Diameter is > widely used, or we'll end up suffering the same problems as we now > have with Radius. > The plan is to make a reference implementation available on the 'net for interoperability testing before it becomes widely deployed. PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 17:00:55 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA24115 for ; Wed, 10 Feb 1999 17:00:54 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA02433; Wed, 10 Feb 1999 13:51:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA02191 for ietf-radius-outgoing; Wed, 10 Feb 1999 13:53:57 -0800 (PST) Message-Id: <199902102153.QAA00981@cryptocard.ott.igs.net> To: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-reply-to: Your message of "Wed, 10 Feb 1999 13:22:32 PST." Date: Wed, 10 Feb 1999 16:53:05 -0500 From: Alan DeKok Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok > Nothing can protect you from wanton ignorance or disregard of the > standards. A lot of the behavior yopu're talking about is, I think, just > implemented because RADIUS is not capable of doing what customers need. I'd respectfully disagree. My experience has been that Radius clients often: - don't support Access-Challenge packets - send empty attributes in requests - ignore other length and value specifications in the RFC's - require vendor-specific attributes before believing an Access-Accept - etc. Radius servers are broken, too, as in they: - treat 'Proxy-State' as something other than undistinguished octets - send non-spec attributes on Accounting-Response etc. Taking the 'customer' as the NAS vendor or the ISP/business trying to implement Radius, then NONE of these problems are a result of "RADIUS not being capable of doing what customers need." Instead, the problems exist because of one of history; misunderstanding; or sheer laziness. The only way to catch and stop these problems is with a reference implementation, not a better-defined protocol. (I won't comment on Diameter here.) Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 17:09:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA24462 for ; Wed, 10 Feb 1999 17:09:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA28768; Wed, 10 Feb 1999 13:05:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA27329 for ietf-radius-outgoing; Wed, 10 Feb 1999 13:08:20 -0800 (PST) From: Aydin Edguer Message-Id: <199902102106.QAA22693@harlequin.MorningStar.Com> Subject: Re: (radius) RFC2139: User-Name should be MUST To: ietf-radius@livingston.com Date: Wed, 10 Feb 1999 16:06:26 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > An empty string attribute may not be meaningless. I can't figure out > what it would mean, but enough implementations use them that there must > be SOME rational purpose behind them. There may have been rational purposes at one time, but in general, those times are long past, if they ever existed. For instance, one vendor will include a State attribute with an empty string value in an Access-Request as a "hint" to the RADIUS server that the NAS supported the Access-Challenge RADIUS packet types. This made sense when it was done 4 years ago (long before RFC 2058 was completed), but it does not make sense now, except for backwards compatibility and a method for complying with the RFC should be added. There is also a vendor that includes a vendor specific attribute with an empty string value in an Access-Request. This is allowed by the RFC, since it is a vendor attribute, but it doesn't really make sense. It should be considered a bug, not a feature. It is true that back when there were discussions about a fictitious RADIUS 2 protocol and roaming, that the idea of using empty attributes to override earlier attributes (basically to delete them) was discussed but it was "what if" discussions, not actual implementations. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 17:20:45 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA24913 for ; Wed, 10 Feb 1999 17:20:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA03640; Wed, 10 Feb 1999 14:10:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA04569 for ietf-radius-outgoing; Wed, 10 Feb 1999 14:12:17 -0800 (PST) Date: Wed, 10 Feb 1999 14:12:11 -0800 From: Paul Krumviede Subject: Re: (radius) RFC2139: User-Name should be MUST To: Glen Zorn Cc: Alan DeKok , ietf-radius@livingston.com Message-id: <36C2043B.6DD7488@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede Glen Zorn wrote: > Nothing can protect you from wanton ignorance or disregard of the > standards. True. > A lot of the behavior yopu're talking about is, I think, just > implemented because RADIUS is not capable of doing what customers need. This seems very unlikely. The RADIUS WG was, in some respects, a strange entity: it was formed (originally) to document the existing protocol (and thus, to some extent, implementations). To the extent that it delayed doing so in favor of chasing enhancements that *suppliers* wanted, it prolonged the period during which there was no standard against which one could test an implementation for compliance (note that I-Ds don't really count here, since they highlight the fact that they are mutable). Having said that, perhaps discussions of history don't really help us engineer better solutions. So please take flames to private email. -paul - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 17:39:43 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA25746 for ; Wed, 10 Feb 1999 17:39:42 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA04072; Wed, 10 Feb 1999 14:17:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA05629 for ietf-radius-outgoing; Wed, 10 Feb 1999 14:20:08 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Alan DeKok'" , ietf-radius@livingston.com Subject: RE: (radius) RFC2139: User-Name should be MUST Date: Wed, 10 Feb 1999 17:16:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Alan DeKok writes... Instead, the problems exist because of one of history; misunderstanding; or sheer laziness. The only way to catch and stop these problems is with a reference implementation, not a better-defined protocol. I think that you can catch these sorts of problems just as effectively with "bake-off" style interoperability testing. Perhaps more effectively. As for stopping the problems, I think that only market pressures can achieve that end. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 17:47:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA26019 for ; Wed, 10 Feb 1999 17:47:31 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA05319; Wed, 10 Feb 1999 14:34:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA07787 for ietf-radius-outgoing; Wed, 10 Feb 1999 14:37:46 -0800 (PST) Date: Wed, 10 Feb 99 14:33:38 PST From: William "Chops" Westfield To: Paul Krumviede Cc: Glen Zorn , Alan DeKok , ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: Your message of Wed, 10 Feb 1999 14:12:11 -0800 Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William "Chops" Westfield This seems very unlikely. The RADIUS WG was, in some respects, a strange entity: it was formed (originally) to document the existing protocol (and thus, to some extent, implementations). Oh come on. One of the major problems with the radius RFC is that it only documents one (of the two) major vendors' implementations that were in effect at the time the RFC was being written. The other vendor apprently did not opt to participate, but did have a major market share. "Late comers" have been forced to choose to implement features from that set, even when they directly conflict with the RFC. I think one of the uunet folk accused us of "haggling over the price." So what else is new? BillW - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 17:49:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA26111 for ; Wed, 10 Feb 1999 17:48:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA05474; Wed, 10 Feb 1999 14:36:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA07972 for ietf-radius-outgoing; Wed, 10 Feb 1999 14:39:11 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Wed, 10 Feb 1999 14:31:08 -0800 (PST) From: Glen Zorn To: Paul Krumviede cc: Alan DeKok , ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: <36C2043B.6DD7488@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Wed, 10 Feb 1999, Paul Krumviede wrote: > Glen Zorn wrote: > > > Nothing can protect you from wanton ignorance or disregard of the > > standards. > > True. > > > A lot of the behavior yopu're talking about is, I think, just > > implemented because RADIUS is not capable of doing what customers need. > > This seems very unlikely. The RADIUS WG was, in some respects, a > strange entity: it was formed (originally) to document the existing > protocol (and thus, to some extent, implementations). Yes. > To the extent > that it delayed doing so in favor of chasing enhancements that > *suppliers* wanted, Hmm. So "suppliers" made up these enhancements (presumably just to spend money)? I could have sworn that most of the enhancement requests came from customers of said suppliers. > it prolonged the period during which there > was no standard against which one could test an implementation > for compliance (note that I-Ds don't really count here, since > they highlight the fact that they are mutable). > But you just said that the WG was 'formed to document the existing protocol'. This implies that 'the existing protocol' (and, by extension, the Livingston implementation) _was_ the 'standard against which to test'. In any case, I think that that is a pretty lame excuse for shipping a non-compliant implementation today. What is _not_ a lame excuse is that the RFCs do not represent the true "standard", which includes the Ascend extensions. > Having said that, perhaps discussions of history don't really > help us engineer better solutions. 'Those who do not learn from history are doomed to repeat it.' >So please take flames to > private email. I was unaware that I was flaming anyone or anything. Noting that RADIUS is to some (large or small) extent inadequate for the tasks that need to be performed is hardly novel nor (I imagined) very controversial. > > -paul > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 18:05:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA26611 for ; Wed, 10 Feb 1999 18:05:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA06919; Wed, 10 Feb 1999 14:53:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA09895 for ietf-radius-outgoing; Wed, 10 Feb 1999 14:56:19 -0800 (PST) Date: Wed, 10 Feb 1999 14:56:14 -0800 From: Paul Krumviede Subject: Re: (radius) RFC2139: User-Name should be MUST To: William Chops Westfield , ietf-radius@livingston.com Message-id: <36C20E8E.F124C677@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede William Chops Westfield wrote: > > This seems very unlikely. The RADIUS WG was, in some respects, a > strange entity: it was formed (originally) to document the existing > protocol (and thus, to some extent, implementations). > > Oh come on. One of the major problems with the radius RFC is that it > only documents one (of the two) major vendors' implementations that were > in effect at the time the RFC was being written. The other vendor > apprently did not opt to participate, but did have a major market share. > "Late comers" have been forced to choose to implement features from > that set, even when they directly conflict with the RFC. So if I change "protocol" with "protocols" you'll be happy? Is all I was trying to say was that: 1) I doubt that the problems with RADIUS stemmed from its inability to do what people wanted; 2) That to the extent that the WG was formed to document existing practice, it is hard to produce an interoperable standard when there exist multiple, possibly non-interoperable, implementations. > I think one of the uunet folk accused us of "haggling over the price." > So what else is new? I do not, and never have had, any connection with Uunet, other than the fact that in September my employer (MCI) completed a "merger" with WorldCom, which also owns Uunet. Oh, at one point long ago my then employer was a Uunet customer. So what is your point? -paul - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 18:13:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA26854 for ; Wed, 10 Feb 1999 18:13:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA07740; Wed, 10 Feb 1999 15:02:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA10754 for ietf-radius-outgoing; Wed, 10 Feb 1999 15:05:31 -0800 (PST) Date: Wed, 10 Feb 1999 15:05:25 -0800 From: Paul Krumviede Subject: Re: (radius) RFC2139: User-Name should be MUST To: Glen Zorn Cc: ietf-radius@livingston.com Message-id: <36C210B5.306EB5FA@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede Glen Zorn wrote: > > On Wed, 10 Feb 1999, Paul Krumviede wrote: > > > A lot of the behavior yopu're talking about is, I think, just > > > implemented because RADIUS is not capable of doing what customers need. > > > > This seems very unlikely. The RADIUS WG was, in some respects, a > > strange entity: it was formed (originally) to document the existing > > protocol (and thus, to some extent, implementations). > > Yes. > > > To the extent > > that it delayed doing so in favor of chasing enhancements that > > *suppliers* wanted, > > Hmm. So "suppliers" made up these enhancements (presumably just to > spend money)? I could have sworn that most of the enhancement requests > came from customers of said suppliers. I've heard, more than once, that "somebody in MCI" is requesting particular work. When I ask who, nobody seems to remember. Given the way some companies seem to work, this seems to be a not uncommon tactic to win management approval for doing something. I don't think that MCI is the only company to be named in this kind of situation. But the WG charter, as originally written, was to document existing practice(s). We didn't do that first. > > it prolonged the period during which there > > was no standard against which one could test an implementation > > for compliance (note that I-Ds don't really count here, since > > they highlight the fact that they are mutable). > > > > But you just said that the WG was 'formed to document the existing > protocol'. This implies that 'the existing protocol' (and, by extension, > the Livingston implementation) _was_ the 'standard > against which to test'. In any case, I think that that is a pretty lame > excuse for shipping a non-compliant implementation today. What is _not_ a > lame excuse is that the RFCs do not represent the true "standard", which > includes the Ascend extensions. I believe that the original charter was to document what existed. I didn't write the charter, nor was (or am) I a member of the IESG, but I don't think that the intent was to document any particular implemtation. -paul - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 19:05:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA28095 for ; Wed, 10 Feb 1999 19:05:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA06335; Wed, 10 Feb 1999 14:47:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA09106 for ietf-radius-outgoing; Wed, 10 Feb 1999 14:50:22 -0800 (PST) Date: Wed, 10 Feb 1999 14:50:18 -0800 From: Paul Krumviede Subject: Re: (radius) RFC2139: User-Name should be MUST To: Glen Zorn Cc: Alan DeKok , ietf-radius@livingston.com Message-id: <36C20D2A.9FF57811@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede > >So please take flames to > > private email. For what it counts, I meant flames in response to my message. I did not mean to imply that Glen's message, to which I responded, was a flame. -paul - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 21:18:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA29791 for ; Wed, 10 Feb 1999 21:18:27 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA17074; Wed, 10 Feb 1999 18:02:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA25561 for ietf-radius-outgoing; Wed, 10 Feb 1999 18:05:30 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Wed, 10 Feb 1999 17:57:27 -0800 (PST) From: Glen Zorn To: Paul Krumviede cc: ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: <36C210B5.306EB5FA@mci.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Wed, 10 Feb 1999, Paul Krumviede wrote: > Glen Zorn wrote: > > > > On Wed, 10 Feb 1999, Paul Krumviede wrote: > > > > > A lot of the behavior yopu're talking about is, I think, just > > > > implemented because RADIUS is not capable of doing what customers need. > > > > > > This seems very unlikely. The RADIUS WG was, in some respects, a > > > strange entity: it was formed (originally) to document the existing > > > protocol (and thus, to some extent, implementations). > > > > Yes. > > > > > To the extent > > > that it delayed doing so in favor of chasing enhancements that > > > *suppliers* wanted, > > > > Hmm. So "suppliers" made up these enhancements (presumably just to > > spend money)? I could have sworn that most of the enhancement requests > > came from customers of said suppliers. > > I've heard, more than once, that "somebody in MCI" is requesting > particular work. When I ask who, nobody seems to remember. Given > the way some companies seem to work, this seems to be a not > uncommon tactic to win management approval for doing something. > I don't think that MCI is the only company to be named in this > kind of situation. Sorry, I was not referring to MCI or WorldCom specifically; I have no idea whether you folks made any requests e.g. to Ascend. It's just that in my experience vendors don't tend to do a lot of work without (at least the perception on their part) of substantial customer demand. Of course, the meaning of "substantial" varies from vendor to vendor but I imagine that a request from MCI or ATT would be seen as substantial by most companies. > > But the WG charter, as originally written, was to document > existing practice(s). We didn't do that first. > > > > it prolonged the period during which there > > > was no standard against which one could test an implementation > > > for compliance (note that I-Ds don't really count here, since > > > they highlight the fact that they are mutable). > > > > > > > But you just said that the WG was 'formed to document the existing > > protocol'. This implies that 'the existing protocol' (and, by extension, > > the Livingston implementation) _was_ the 'standard > > against which to test'. In any case, I think that that is a pretty lame > > excuse for shipping a non-compliant implementation today. What is _not_ a > > lame excuse is that the RFCs do not represent the true "standard", which > > includes the Ascend extensions. > > I believe that the original charter was to document what existed. I > didn't write the charter, nor was (or am) I a member of the IESG, > but I don't think that the intent was to document any particular > implemtation. > Perhaps not, but allowing a Livingston employee to chair the WG more or less guaranteed that, right? Note that I am _not_ implying or suggesting _any_ impropriety on the part of Carl Rigney; it just makes sense that since RADIUS was (and to some extent still is) considered a Livingston protocol and a Livingston employee is chairing the WG, the WG would tend toward documenting the Livingston implementation. This is not necessarily bad, but in hind sight it might have been a better idea to issue the RFC as Informational and go on from there. > -paul > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 22:04:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA00197 for ; Wed, 10 Feb 1999 22:04:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA18252; Wed, 10 Feb 1999 18:55:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA27757 for ietf-radius-outgoing; Wed, 10 Feb 1999 18:58:41 -0800 (PST) Date: Wed, 10 Feb 1999 18:58:38 -0800 (PST) From: Carl Rigney Message-Id: <199902110258.SAA27745@server.livingston.com> To: gwz@acm.org, paul@mci.net Subject: Re: (radius) RFC2139: User-Name should be MUST Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I don't see any value in discussions of past history. That horse turned into glue long, long ago. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 10 22:11:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA00241 for ; Wed, 10 Feb 1999 22:11:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id TAA18597; Wed, 10 Feb 1999 19:02:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA28097 for ietf-radius-outgoing; Wed, 10 Feb 1999 19:05:05 -0800 (PST) Date: Wed, 10 Feb 1999 19:05:04 -0800 (PST) From: Carl Rigney Message-Id: <199902110305.TAA28088@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Status update Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney The 2 RADIUS MIBs at revision 04 will be going to IETF last call for proposed standard any day now. The 2 RADIUS Accounting MIBs at revision 04 are ready for informational as soon as the IESG OK's them. The 3 drafts re Tunneling & RADIUS are nearly done with WG Last Call; I'll double-check their status next week. The updated RADIUS Accounting draft and extensions draft (which now incorporates interim and eap) should be going to WG Last Call next week, with the updated RADIUS draft going to WG last call by 2/26 (sooner if I can manage). Coming soon on their heels will be last call for an informational draft of the Known Implementations (so people can point out any errors of transcription on my part), and then a draft of BCP offering guidance to the IANA for attribute and value allocation. The RADIUS Working Group will NOT be meeting in Minneapolis; there's no need. -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 11 01:16:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA03607 for ; Thu, 11 Feb 1999 01:16:11 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA24248; Wed, 10 Feb 1999 22:07:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA06661 for ietf-radius-outgoing; Wed, 10 Feb 1999 22:09:13 -0800 (PST) Date: Wed, 10 Feb 99 22:05:20 PST From: William "Chops" Westfield To: Glen Zorn Cc: Paul Krumviede , ietf-radius@livingston.com Subject: Re: (radius) RFC2139: User-Name should be MUST In-Reply-To: Your message of Wed, 10 Feb 1999 17:57:27 -0800 (PST) Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William "Chops" Westfield >> Sorry, I was not referring to MCI or WorldCom specifically; Me either. Given what amounts to a "weak" spec, given the choice between implementing a customer request and sticking to the spec, the customers win. (customers ask for stuff like user configurable tcp timers too, but at least there there is a strong spec with a lot of backing.) BillW - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 12 04:23:18 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA06923 for ; Fri, 12 Feb 1999 04:23:17 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA22202; Fri, 12 Feb 1999 01:12:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA16311 for ietf-radius-outgoing; Fri, 12 Feb 1999 01:13:18 -0800 (PST) From: BHagan4902@aol.com Message-ID: Date: Fri, 12 Feb 1999 03:10:50 EST Mime-Version: 1.0 Subject: (radius) Publishing Company For Sale! Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 18 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: BHagan4902@aol.com See information about Free Credit Application Below! My Multi-Million Dollar Publishing Company ONLY $149 Free Pre-Approved Merchant Account Application with Order!! To Start Your Business Out Right!! If you ever wanted "the easy way out" to make a lot of money with a business of your own.... Here is the EASIEST WAY TO START! I'm writing this letter to let you in on something that'll blow you away. What I'm about to present is something I've never done before...something that I'll never do again.... So PAY ATTENTION! For the past few years...I've have been running ads in newspapers & magazines, by direct mail, and throughout the internet. These ads were always small and very cheap... On these ads, we have been selling little manuals. These manuals have sold for anywhere between $10 to $99 each. We always ran different ads for each manual we were selling. I like selling information because NOBODY can put a price on it...ESPECIALLY when it is your own...The Sky is the Limit! Plus it is very cheap to reproduce How-To manuals. It costs between 40 cents and $3 to print the entire print manuals and around 35 cents to copy the manuals on disk. AND you can sell them for up to $99 each. That is one hell of a markup! These manuals tell you how to get a car with no money down and no credit...another one tells you how to avoid taxes by depositing income offshore...now you may not be interested in saving money by going offshore...but believe me....there are MILLIONS OF PEOPLE WHO DO...and they are willing to pay me to teach them!!! Well this is where the unbelievable offer comes in...I hope you are sitting down for this one...because this is a once in a lifetime chance for you. I do not know of an easier way to become financially independent...In fact THERE IS NO EASIER WAY!!! The next few paragraphs will reveal everything to you. I am willing to sell you my entire informational product line with FULL REPRINT RIGHTS and complete step-by-step instructions on how to start your mail order information business with very little money. Remember, these are PROVEN WINNERS. If you are stumped on something to sell or if you are having trouble writing a good ad, I have also included an entire book on disk to help you produce KILLER ads! This entire package which I call a Publishing Company in a Box will come on 1 CD containing over 2000 'Hot-Selling' Books, Reports And Manuals ready to print and sell, Sell, SELL! It also will come with a signed letter giving YOU FULL REPRINT RIGHTS allowing you to sell them for as much as you want and however you want. You Can even sell the entire kit to someone else to resale on their own! You also receive copies of KILLER ads which can fill your mailbox with cash! I am not even going to ask you for any of the money either... What you make is yours to keep . In fact...you get to make a ton of money on these manuals for as long as you wish...and you will never have to pay me another red cent in royalties! I am even going to print out and prepare our #1 selling report which contains the secrets of obtaining credit without a credit check and producing an offshore income without taxes so that you will be able to take it down to your local copy shop and be ready to sell it the same day you have received it. Watch out though - one individual is making $70,000 a month on this report alone! (Why - Because you can include a FREE offshore credit application for those with bad or no credit with this report and explode your mailbox with orders) Note: THIS APPLICATION IS INCLUDED! All I ask for is...$149 and I will include FREE Priority Mail Shipping! Yes, I said $149. There are no zeros missing. Plus if you order before Feb. 18th, 1999 I will include 4 extra special bonuses... Bonus #1 - "Search Engine Magic" on disk. This report will shoot your web site up to the top of the search engine listings. Other web advertisers are selling this manual for $99 by itself - But I will give it to you for FREE with this package. Bonus #2 - The report "How to Make at least $1,600 a week online...Starting Now!" which is taking the internet by storm will be included absolutely FREE! Bonus #3 - I will include special details about a secret source for direct mail leads that can produce cash orders along with out KILLER ads. And another source will be given which allows you to advertise nationwide through newspapers to 70,000,000 readers for as low as 7 cents per word. Bonus #4 - I also will include a pre-approved application for a merchant account for your business benefit. Taking credit cards will increase your business up to 100%. The normal $195 application fee will be waved with this pre-approved application. But there is one drawback... I am sending this ad to 10,000 other people...and I will only allow 50 kits to be sold. It wouldn't make much sense if I sold this kit to 1,000 or 2,000 people...The market would be saturated with these same manuals... and I don't want to do that. To make sure that the people in this offer get the same results I have...ONLY 50 people can have it for $149.00! Chances are, I will get all 50 within a week's time. So if this is something you are interested in...RUSH me a check or money order for $149.00 TODAY to insure your future business. But, even if you decide to pass this up...Don't sweat it. It's not like I am going to be mad or anything like that. I know I will get my 50 order limit really fast. And anyone who gets their check into me late... I will simply send it back. For only $149.00, I am going to let you have the easiest money you will ever make. The manuals are written, the ads are presented, the advertising plan is laid out, and all you have to do is print them out for pennies and place the ads. Do it today! Rush me your payment of $149.00 right now...and get your very own MILLION DOLLAR publishing company going! You can start with one or two manuals...even the day you receive the package...and then expand to include ALL of them! For $149.00, you have everything you need to make a killing with your very own business. If you want to make real money - then this offer is for you! "I took the report "Search Engine Magic" and sold over 50 copies on disk within 2 weeks! They sold for $99 and I was able to copy them for under 50 cents each. Wait till I start marketing the other products included in this line!!!" Joe Fisher - Internet Marketer To rush order this "MILLION DOLLAR Publishing Company in a Box" simply fill out the order form below and fax it to our 24 hour order line at: FAX ORDER LINE: 1 (212) 504-8032 Regular Mail to: Financial Systems P.O. Box 301 Orange, Ma 01364 ORDER FORM -------------------------------------------------------------- Please send to: Your Name__________________________________________ Your Address________________________________________ Your City____________________________________________ State / Zip___________________________________________ Phone #: ____________________________________________ (For problems with your order only. No salesmen will call.) Email Address_______________________________________ We Accept Checks or Money Orders along with all Major Credit Cards including Visa, MasterCard and American Express. (NOTE - We only ship to the address listed on the credit card) (Please Fill Out Below Section and Make sure that the above name and address are listed as it appears on the card) for $149.00 Credit Card Number:________________________________ Expiration Date:___________________________ Signature:_________________________ Date:____________________ [ ] YES! Please rush my Publishing Company in a Box. I understand I have FULL REPRINT Rights and can sell any of the items for whatever price I desire, even the entire kit. [ ] DOUBLE YES! I am ordering before Feb. 18th, 1999! Please include the extra special bonuses! * Please check one of the following payment options: [ ] I am faxing a check (Do not send original, we will make a draft from the faxed check) [ ] I am faxing or mailing my credit card number. (Note your card will be charged for $149.00 and we only ship to the address on the card) [ ] I am enclosing a check or money order for $149.00! Note - If ordering outside continental US, please add $5 to S&H P.S. Don't forget you will receive 2,000 Manuals, Books, and Reports (Some of which are up to 200 pages each)...all for $149...You have full reprint and resale rights to make as much money as you want without ever paying any royalties whatsoever! * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * You have been carefully selected to receive the following as a person obviously interested in this subject based upon your previous internet postings, or visits to one of our affiliate web sites. If you have received this message in error, hit reply with the word unsubscribe in the subject. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 12 12:55:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA12697 for ; Fri, 12 Feb 1999 12:55:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA07881; Fri, 12 Feb 1999 09:37:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA11868 for ietf-radius-outgoing; Fri, 12 Feb 1999 09:27:24 -0800 (PST) From: 6546554@mail.mcnet.ch Message-Id: <199902121717.SAA16775@mail.mcnet.ch> To: user@the_internet.com Date: Fri, 12 Feb 99 08:43:25 EST Subject: (radius) SEEKING A NEW JOB ? Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: 6546554@mail.mcnet.ch SEEKING A NEW JOB ? Get the latest International Headhunter and Company Contact Directories.+AD4- For FASTER SERVICE, use our WEBSITE: http://www.usaplaza.com/CarmotLP See our MONEY-BACK GUARANTEE INTERNATIONAL HEADHUNTER DIRECTORIES have name, contact person, address, phone, +ACY- sector specialization. HEADHUNTERS EUROPE, ENGINEERS: 830+- in Belgium, UK, France, Germany, Ireland, Holland, Spain, Swiss. US+ACQ-99. HEADHUNTERS EUROPE, FINANCE: 250+- in Austria, Belgium, Denmark,England, Finland, France, Germany, Greece, Italy, Ireland, Luxembourg, Netherlands, Norway, Spain, Switzerland. US+ACQ-99. HEADHUNTERS EUROPE, MARKETING/SALES: 260+- in Austria, Belgium, Denmark, England, France, Germany, Greece, Italy, Netherlands, Norway, Portugal, Spain, Sweden, Switzerland. US+ACQ-99. HEADHUNTERS EASTERN EUROPE: 75+- contacts in Bulgaria, Czech, Hungary, Poland, Romania, Russia, Slovak. US+ACQ-49. HEADHUNTERS SOUTH AMERICA: Over 75 contacts in Argentina, Brazil, Chile, Colombia, Costa Rica, Dominican Republic, El Salvador, Guatemala,Mexico, Netherlands Antilles, Venezuela. US+ACQ-99. HEADHUNTERS AUSTRIA:100+-contacts.US+ACQ-39. HEADHUNTERS BELGIUM:370+-contacts.US+ACQ-49 HEADHUNTERS FRANCE: 1,250+-contacts.US+ACQ-129. HEADHUNTERS SPAIN: 120+- contacts. US+ACQ-49. HEADHUNTERS ITALY: 550+- contacts. US+ACQ-69. HEADHUNTERS NETHERLANDS:740+-contacts.US+ACQ-69. HEADHUNTERS GERMANY: 1,590+-contacts. US+ACQ-149. HEADHUNTERS SWITZERLAND: 290+-contacts. US+ACQ-69 HEADHUNTERS SCANDINAVIA: 100+- contacts in Denmark, Finland, Norway and Sweden. US+ACQ-49. COMPANY CONTACT DIRECTORIES +AH4- Up-to-date company contacts importantto your job search. SINGAPORE CONTACT DIRECTORY: Singapore business, economy, and lifestyle. Address/phone/fax of leading firms, 500+- recruiters, 300+- E-Mailaddresses, 100+- Websites, other useful contacts. US+ACQ-75.-- HONG KONG CONTACT DIRECTORY: Hong Kong employment, business, economy,and lifestyle. Address/phone/fax of leading Hong Kong firms, recruitment agencies, +ACY- other useful contacts. US+ACQ-60.-- FAR EAST CONTACT DIRECTORY: China, Hong Kong, Japan, S.Korea, Taiwan business, economy, employment, lifestyle. Address/phone/fax of leading firms, recruiters, other useful contacts. US+ACQ-60.-- SOUTH EAST ASIA CONTACT DIRECTORY: Brunei, Cambodia, Indonesia, Laos, Malaysia, Philippines, Singapore, Thailand, Vietnam business, economy, lifestyle. Address/phone of leading companies, recruiters, useful contacts. US+ACQ-60.-- MIDDLE EAST CONTACT DIRECTORY: Saudi Arabia, Kuwait, Oman, Qatar, Dubai, Yemen business, economy, lifestyle. Address/phone/fax of leading firms, recruiters, +ACY- useful contacts. US+ACQ-60.-- AUSTRALIA +ACY- NEW ZEALAND CONTACT DIRECTORY: Business, economy,lifestyle. Address/phone/fax of leading companies, recruitment agencies, otheruseful contacts. US+ACQ-60.-- HOW TO ORDER: Send check or money order in US Dollars, drawn on a US Bank, Payable to: CARMOT LP Send us your order with payment and your shipping address. Allow 4-6weeks for funds clearance and delivery. CARMOT LP 3885 South Decatur Boulevard, Morgan Sterling Suite 2010 Las Vegas, Nevada 89103-5873, USA Tel (1) 702 320 2673, Fax (1) 702 871 8427, Email carmot+AEA-morgan sterling.com MONEY-BACK GUARANTEE: When you do your mailing, within 90 days of ordering, to Recruiters listed in directories purchased from us, we will reimburse you postage for any resumes returned due to incorrect address. For FASTER SERVICE, use our WEBSITE: http://www.usaplaza.com/CarmotLP - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Feb 15 11:07:22 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA20965 for ; Mon, 15 Feb 1999 11:07:21 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA12031; Mon, 15 Feb 1999 07:57:43 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA00565 for ietf-radius-outgoing; Mon, 15 Feb 1999 07:55:07 -0800 (PST) Message-Id: <199902151553.KAA20143@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-acc-servmib-04.txt Date: Mon, 15 Feb 1999 10:53:00 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Accounting Server MIB Author(s) : G. Zorn, B. Aboba Filename : draft-ietf-radius-acc-servmib-04.txt Pages : 15 Date : 12-Feb-99 This memo defines a set of extensions which instrument RADIUS accounting server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-acc-servmib-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-acc-servmib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-acc-servmib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990212155944.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-acc-servmib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-acc-servmib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990212155944.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Feb 15 11:07:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA20978 for ; Mon, 15 Feb 1999 11:07:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA12026; Mon, 15 Feb 1999 07:57:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA00610 for ietf-radius-outgoing; Mon, 15 Feb 1999 07:57:04 -0800 (PST) Message-Id: <199902151554.KAA20243@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-auth-servmib-04.txt Date: Mon, 15 Feb 1999 10:54:57 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Authentication Server MIB Author(s) : G. Zorn, B. Aboba Filename : draft-ietf-radius-auth-servmib-04.txt Pages : 16 Date : 12-Feb-99 This memo defines a set of extensions which instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-auth-servmib-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-auth-servmib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-auth-servmib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990212160154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-auth-servmib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-auth-servmib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990212160154.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Feb 15 11:32:20 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA22412 for ; Mon, 15 Feb 1999 11:32:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA13090; Mon, 15 Feb 1999 08:22:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA01655 for ietf-radius-outgoing; Mon, 15 Feb 1999 08:22:56 -0800 (PST) Message-Id: <199902151620.LAA21691@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-acc-clientmib-04.txt Date: Mon, 15 Feb 1999 11:20:47 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Accounting Client MIB Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-radius-acc-clientmib-04.txt Pages : 13 Date : 12-Feb-99 This memo defines a set of extensions which instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS accounting clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-acc-clientmib-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-acc-clientmib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-acc-clientmib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990215105133.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-acc-clientmib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-acc-clientmib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990215105133.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Feb 15 19:06:35 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA12092 for ; Mon, 15 Feb 1999 19:06:34 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA29172; Mon, 15 Feb 1999 15:56:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA18774 for ietf-radius-outgoing; Mon, 15 Feb 1999 15:57:59 -0800 (PST) From: hjgjfdk@prodigy.net Date: Tue, 16 Feb 1999 10:23:28 +1030 (CDT) Message-Id: <199902152353.KAA27970@pene.science.adelaide.edu.au> To: travelers@ibm.net Subject: (radius) FUN HOME BASED BIZ!!! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: hjgjfdk@prodigy.net WHAT DREAMS DO YOU HAVE FOR YOUR LIFE? HOW ARE YOU GOING TO GET THERE? INTERESTED IN EARNING INCOME FROM HOME AS A BUSINESS OWNER? WANT TO TRAVEL TO EXOTIC DESTINATIONS AT DEEP DISCOUNTS, WHENEVER YOU WANT? READ ON IF YOU ARE INTERESTED. * Let me show you how I am currently earning 12,000/ month and more. * You can expect to earn 2500.00 / month part time and 10,000/ month full time. Your desire to see your dreams fullfilled , combined with our training and support are the path to success. * TRAVEL INDUSTRY BUSINESS * NOT MLM * EARNINGS START WITHIN 1-4 WEEKS * 78 % PROFIT PAID DIRECTLY TO YOU * TRAINING AND SUPPORT PROVIDED * WORK FROM HOME, BE YOUR OWN BOSS AND SET YOUR OWN HOURS This is not a hobby or a game. Entrepreneurs ready to get started , with serious inquiries call: 1 800 345-9688 ext 9630 TOLL FREE! NO OBLIGATION! 24 hour recorded message This mailing is done by an independent marketing co. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via E mail. No wasted paper! Delete with one simple keystroke! Less refuse in our Dumps! This is the new way of new millenium! To be removed from our mailing list please reply to: moreinfo@fnmail.com E mails will not be read but you will be removed. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 16 11:14:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA01781 for ; Tue, 16 Feb 1999 11:14:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA14651; Tue, 16 Feb 1999 08:04:21 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA18333 for ietf-radius-outgoing; Tue, 16 Feb 1999 08:03:54 -0800 (PST) Date: Wed, 17 Feb 1999 00:04:53 +0800 To: badoukou4@esbs.u-strasbg.fr From: badoukou4@esbs.u-strasbg.fr (numytou) Comments: Authenticated sender is Subject: (radius) Free software info! Message-Id: <19990216481BAA53154@noiumoliu.ihp.sinica.edu.tw> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: badoukou4@esbs.u-strasbg.fr (numytou) Do you know who just visited your website in the last minute ? Do you want to contact your most precious leads - website visitors ? Do you want your website visitors to keep comming back and buy ? YOU NEED SENSOR! - never lose your website contacts again ! SENSOR! is a new software technology that allows you to identify your website visitors in "real time". Turn "quick" visitors into pure leads and increase your potential ! WHY DO YOU NEED SENSOR!? Imagine visiting a department store to buy a pair of shoes. You examine all the shoes on display, try some, think about buying a pair, hesitate, and leave the store. You arrive home & get a phone call from the Manager of the store you just visited, thanking you for visiting the store, and offering you, if you came back, a special discount on any of the shoes you examined and tried! The result!? You will be pleasantly surprised, and --most probably-- you will go back to buy the shoes you really wanted! The store Manager gains a very satisfied customer and a lot of goodwill! HOW DOES SENSOR HELP YOU and YOUR WEBSITE ? Sensor detects your visitor's e-mail address, and collects it in a file for your immediate or future follow up! You can use an auto email responder to thank the visitors for the visit, announce coming specials, and induce them with discounts if they came back soon! SENSOR! - turning visitors to pure and true leads ! FREE - FREE - get your free details! MORE INFORMATION Available on this software ! *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* For MORE INFO, just call or fax us ACT NOW -turn visitors into PURE LEADS ! 24 hours / 7 days=Call 1-800-242-0363 Ext 1992. Or fax (310) 495-0232. When you call, or fax, please leave: 1)your name 2)Your phone # with area code 3)email address (please carefully spell it!) 4)fax # (if you have one) 4)Your site's URL 5)and mention you want free information on SENSOR. All above information is required to enable us email or fax you the free details on SENSOR! Thanks. *-* - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 16 11:25:41 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA02190 for ; Tue, 16 Feb 1999 11:25:40 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA15109; Tue, 16 Feb 1999 08:14:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA19635 for ietf-radius-outgoing; Tue, 16 Feb 1999 08:18:00 -0800 (PST) Message-ID: <36C99A77.EF13EDCA@karlnet.com> Date: Tue, 16 Feb 1999 11:19:03 -0500 From: Justin McCann X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: (radius) (RADIUS) Access-Challenge packets Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Justin McCann I have been reading and re-reading RFC2138, trying to understand just how the Access-Challenge packets work. Could someone please comment on and/or correct my understanding? (Jumping right into the middle of the authentication...) a. Having received an Access-Request packet, the RADIUS server, for whatever reason (interaction with SecurID server, whatever) decides to send an Access-Challenge packet to the NAS. b. The Access-Challenge packet MAY contain any combination of the following two attributes (one, both, or legally none): --a single 'State' value, which could be the cryptographic seed the user enters into his crypto device to generate a new password, or could just be some variable to hold state --a single 'Reply-Message' value, which could contain the cryptographic seed, and should be displayed to the user. c. The NAS passes on the info to the dial-in client, which displays it to the user, who enters the seed into the crypto device they have, and types in a response, which is sent to the NAS. d. The NAS creates a new Access-Request packet, one that contains the 'State' value, if there was one. Thanks, Justin -- ------------------------------------------------------------ Justin McCann 560 Chestershire KarlNet, Inc. Columbus, OH 43204 email: justin@karlnet.com 614.308.9354 (H) 614.789.0511 (W) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 16 11:38:05 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA02787 for ; Tue, 16 Feb 1999 11:38:04 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA16236; Tue, 16 Feb 1999 08:28:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA21081 for ietf-radius-outgoing; Tue, 16 Feb 1999 08:31:24 -0800 (PST) From: Aydin Edguer Message-Id: <199902161629.LAA22902@harlequin.MorningStar.Com> Subject: Re: (radius) (RADIUS) Access-Challenge packets To: ietf-radius@livingston.com Date: Tue, 16 Feb 1999 11:29:30 -0500 (EST) Cc: justin@karlnet.com X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > b. The Access-Challenge packet MAY contain any combination of the > following two attributes (one, both, or legally none): > --a single 'State' value, which could be the cryptographic seed the > user enters into his crypto device to generate a new password, or could > just be some variable to hold state No, the "State" value is never displayed to the user and the NAS should not attempt to interpet the "State". The purpose of the "State" attribute is to allow the RADIUS Server to match the Access-Challenge to the Access-Request that the NAS generates in response to the challenge. It is only the RADIUS server state. > --a single 'Reply-Message' value, which could contain the > cryptographic seed, and should be displayed to the user. There can be one or more Reply-Message attributes that contain the text that should be displayed to the user. The Access-Challenge can be used for many more purposes than just a token-card or crypto device. It can be used just as part of a menu system (Livingston and other RADIUS servers support this). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 16 14:02:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA06643 for ; Tue, 16 Feb 1999 14:02:58 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA23413; Tue, 16 Feb 1999 10:50:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA06957 for ietf-radius-outgoing; Tue, 16 Feb 1999 10:52:47 -0800 (PST) From: jane76a@yahoo.com Message-Id: <199902161843.KAA22705@bast.livingston.com> Subject: (radius) ADV: 900+ Search Engines, For Only 9.95 Date: Tue, 16 Feb 1999 07:13:05 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: jane76a@yahoo.com Email removal 800-771-2003 Monday thru Friday, 8-5 Pacific Time We'll Submit Your Site To Over 900 Search Engines, Directories, & Indices For A Cost Of Only $ 9.95 (*) *** 100% Money Back Guarantee *** *** Immediately Increase Your Sites Exposure *** For About One Penny Each We Will Submit Your Web Site To Over 900 Of The Net's Hottest Search Engines, Directories & Indices. If your site isn't listed in the Search Engines, how can people find you to buy your products or services? For just $9.95 we'll take the work load off your back instead of you trying to do it manually which can take days to do. We're the professionals that are here to help you have a shot at having a successful marketing experience with the internet. You know as well as we that your time is best utilized managing your business and not sitting at some keyboard hours upon hours trying to save about one penny for each submission. See how it's kind of crazy to try to tackle this on your own. It's just not cost effective to try to do this yourself to save just $9.95. See why thousands and thousands of businesses world wide both large and small have come to us to utilize our services. Hotels, Motels, On-Line Stores, Travel Agents, Colleges, Universities, Governments, Fortune 500 companies, Movie Studios, Chambers Of Commerce and many, many more. Shouldn't you give us a call now? To Learn More, Call Us At The Numbers Below. Call us toll free at (800) 771-2003 in the USA and Canada or outside the USA at (916) 771-4739 and we'll provide you with all the necessary information to get you submitted Right Away. #2488 (*) We submit your site MONTHLY to over 900 Search Engines, Directories and Indicies for only $9.95 per month. 12 month minimum term required. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 16 16:18:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA09524 for ; Tue, 16 Feb 1999 16:18:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA28286; Tue, 16 Feb 1999 13:01:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA20635 for ietf-radius-outgoing; Tue, 16 Feb 1999 13:04:01 -0800 (PST) Message-ID: <36C9DD47.39239ECB@iea-software.com> Date: Tue, 16 Feb 1999 13:04:08 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IETF RADIUS Subject: (radius) Proxy-State Order Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Is there anything that requires the Proxy-State Attribute in an Access-Accept packet to be the first (or before) the other attributes, if a Proxy-State attribute was received in the Access-Request? Currently we append the Proxy-State at the end of the Access-Accept and a couple of vendors are having problems Proxying to us, because they are only looking at the first attribute for the Proxy-State. RFC 2138 specifically says that you do not have to preserve order for different attributes (only for multiple attributes of the same type). Does any of the roaming drafts address this? -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 16 16:26:43 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA09860 for ; Tue, 16 Feb 1999 16:26:42 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA28928; Tue, 16 Feb 1999 13:15:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA22284 for ietf-radius-outgoing; Tue, 16 Feb 1999 13:18:31 -0800 (PST) From: Barney Wolff To: IETF RADIUS Date: Tue, 16 Feb 1999 16:17 EST Subject: Re: (radius) Proxy-State Order Content-Type: text/plain Message-ID: <36c9e09f0.e28@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff They'd have trouble with me, too. You're right, they're wrong. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 16 16:40:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10578 for ; Tue, 16 Feb 1999 16:40:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA29895; Tue, 16 Feb 1999 13:30:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA23804 for ietf-radius-outgoing; Tue, 16 Feb 1999 13:33:43 -0800 (PST) Date: Tue, 16 Feb 99 16:30:21 EST From: David Bolen Subject: Re: (radius) Proxy-State Order In-Reply-To: Your message of Tue, 16 Feb 1999 16:17 EST To: IETF RADIUS Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: David Bolen Barney Wolff writes: > They'd have trouble with me, too. You're right, they're wrong. Ditto here. My code tacks on any saved set of client Proxy-State attributes as the final stage of generating the response back to the originator of the request, so while the internal order is preserved, the attributes appear as the final attributes in any response. Of course, being "right" here might not help if someone absolutely has to interoperate with these clients and they can't be fixed, but I definitely believe it's their implementation that is faulty. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 16 16:43:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10709 for ; Tue, 16 Feb 1999 16:43:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA00103; Tue, 16 Feb 1999 13:30:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA23868 for ietf-radius-outgoing; Tue, 16 Feb 1999 13:34:09 -0800 (PST) Message-Id: <199902162132.QAA10179@ietf.org> To: IETF-Announce:; Cc: ietf-radius@livingston.com From: The IESG Subject: (radius) Last Call: RADIUS Authentication MIBs to Proposed Standard Date: Tue, 16 Feb 1999 16:32:01 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: The IESG The IESG has received a request from the Remote Authentication Dial-In User Service Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o RADIUS Authentication Client MIB o RADIUS Authentication Server MIB The IESG will also consider publication of the following Internet-Drafts as Informational RFCs: o RADIUS Accounting Client MIB o RADIUS Accounting Server MIB The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by March 2, 1999. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-radius-auth-clientmib-04.txt http://www.ietf.org/internet-drafts/draft-ietf-radius-auth-servmib-04.txt http://www.ietf.org/internet-drafts/draft-ietf-radius-acc-clientmib-04.txt http://www.ietf.org/internet-drafts/draft-ietf-radius-acc-servmib-04.txt - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 16 16:44:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA10734 for ; Tue, 16 Feb 1999 16:44:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA29756; Tue, 16 Feb 1999 13:28:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA23541 for ietf-radius-outgoing; Tue, 16 Feb 1999 13:31:06 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Tue, 16 Feb 1999 13:23:12 -0800 (PST) From: Glen Zorn To: "Dale E. Reed Jr." cc: IETF RADIUS Subject: Re: (radius) Proxy-State Order In-Reply-To: <36C9DD47.39239ECB@iea-software.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Tue, 16 Feb 1999, Dale E. Reed Jr. wrote: > > Is there anything that requires the Proxy-State Attribute in an > Access-Accept packet to be the first (or before) the other attributes, > if a Proxy-State attribute was received in the Access-Request? Not that I know of. > > Currently we append the Proxy-State at the end of the Access-Accept > and a couple of vendors are having problems Proxying to us, because > they are only looking at the first attribute for the Proxy-State. > Offhand I'd say the other vendors are broken and your behavior is fine. > RFC 2138 specifically says that you do not have to preserve order > for different attributes (only for multiple attributes of the same > type). Does any of the roaming drafts address this? > Nope. > > -- > > Dale E. Reed Jr. Emerald and RadiusNT > __________________________________________ > IEA Software, Inc. www.iea-software.com > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 17 09:12:19 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA02289 for ; Wed, 17 Feb 1999 09:12:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA26143; Wed, 17 Feb 1999 06:02:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA12976 for ietf-radius-outgoing; Wed, 17 Feb 1999 06:04:19 -0800 (PST) Message-Id: <199902171402.JAA02023@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-auth-clientmib-04.txt Date: Wed, 17 Feb 1999 09:02:13 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Authentication Client MIB Author(s) : B. Aboba, G. Zorn Filename : draft-ietf-radius-auth-clientmib-04.txt Pages : 14 Date : 16-Feb-99 This memo defines a set of extensions which instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions IP-based management stations can manage RADIUS authentication clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-auth-clientmib-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-auth-clientmib-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-auth-clientmib-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990217082434.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-auth-clientmib-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-auth-clientmib-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990217082434.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 18 02:04:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA25911 for ; Thu, 18 Feb 1999 02:04:21 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA29794; Wed, 17 Feb 1999 22:53:56 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA02324 for ietf-radius-outgoing; Wed, 17 Feb 1999 22:55:21 -0800 (PST) Message-Id: <199902180654.WAA12133@shell4.ba.best.com> Subject: (radius) Acct-Tunnel-Packets-Lost? To: ietf-radius@livingston.com Date: Wed, 17 Feb 1999 22:54:07 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Possibly a stupid question. Was Acct-Tunnel-Packets-Lost ever assigned a number, or will it be dropped in the next revision? Thanks. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 18 18:17:12 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA26110 for ; Thu, 18 Feb 1999 18:17:11 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA26517; Thu, 18 Feb 1999 15:00:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA10649 for ietf-radius-outgoing; Thu, 18 Feb 1999 15:01:57 -0800 (PST) From: "Heath Partington" To: Subject: (radius) radius retransmission id's Date: Thu, 18 Feb 1999 17:59:52 -0500 Message-ID: <004e01be5b92$648cbb50$da047392@hpartington.hq.springtidenet.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Heath Partington" According to RFC2138: Identifier The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MUST remain unchanged. I am writing a RADIUS client where the number of valid id's(255) may not be enough at any given time - so I was forced to store more than one set of id's for a single cpu instance. I decided to store a set of id's per each server configured. As most RADIUS clients do - when a server is unreachable I begin sending retransmissions to a secondary server. Unfortunately since the second server has a completely different set of id's I may not be able to use the same identifier that I was using to transmit to the initial server (because the 2nd server is already using it to perform another action). I assume that the goal of keeping the identifier the same for all retransmissions was to enable the server(s) to detect duplicate packets. So my question - is there a drawback to rewording the specification to say something like: "For retransmissions to the same server, the Identifier MUST remain unchanged"? Trying to remain standard compatible, Heath _____________________ Heath Partington Spring Tide Networks (978) 635 - 3739 x121 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 18 18:31:25 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27188 for ; Thu, 18 Feb 1999 18:31:24 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA27338; Thu, 18 Feb 1999 15:15:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA12463 for ietf-radius-outgoing; Thu, 18 Feb 1999 15:18:22 -0800 (PST) Message-ID: <36CC9E94.2E3E6FEC@iea-software.com> Date: Thu, 18 Feb 1999 15:13:25 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Heath Partington CC: ietf-radius@livingston.com Subject: Re: (radius) radius retransmission id's References: <004e01be5b92$648cbb50$da047392@hpartington.hq.springtidenet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Heath Partington wrote: > > According to RFC2138: > > Identifier > > The Identifier field MUST be changed whenever the content of the Attributes > field changes, and whenever a valid reply has been received for a previous > request. For retransmissions, the Identifier MUST remain unchanged. > > I am writing a RADIUS client where the number of valid id's(255) may not be > enough at any given time - so I was forced to store more than one set of > id's for a single cpu instance. I decided to store a set of id's per each > server configured. As most RADIUS clients do - when a server is unreachable > I begin sending retransmissions to a secondary server. Unfortunately since > the second server has a completely different set of id's I may not be able > to use the same identifier that I was using to transmit to the initial > server (because the 2nd server is already using it to perform another > action). > > I assume that the goal of keeping the identifier the same for all > retransmissions was to enable the server(s) to detect duplicate packets. > > So my question - is there a drawback to rewording the specification to say > something like: "For retransmissions to the same server, the Identifier MUST > remain unchanged"? As I remember this discussion a while back, a retransmisions means sending a packet to the same server again. Failing over to a secondary server is not considered a retransmission (and if the secret is diffrent, you have to re-create the attributes anyways). -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 18 22:06:19 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA02856 for ; Thu, 18 Feb 1999 22:06:19 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA04764; Thu, 18 Feb 1999 18:55:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA28431 for ietf-radius-outgoing; Thu, 18 Feb 1999 18:58:01 -0800 (PST) From: Chanwall@aol.com Message-ID: Date: Thu, 18 Feb 1999 20:25:56 EST Mime-Version: 1.0 Subject: (radius) Get your Business on the Internet NOW!! Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 64 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Chanwall@aol.com Internet Marketing Starter Kit An On-line Marketing Course Get your Business on the Internet NOW!! Have you thought about starting your own Internet business? Do you like the idea of working when you want and  from the comfort of your own home?  Tired of driving to a job that offers no real hope of financial independence?  It's time to stop making your boss rich and start reaping the incredible profits that are being made every day on the Internet. There has never been a better time to start your own business. With the Internet in it's infancy the future is very bright for on line marketing. Getting a business on the web is easy, but you need the tools! That's what I provide. The Internet Marketing Starter Kit is an online marketing course that provides everything you need to get started. It is different from any other marketing report you have seen. I walk you through each step you need to take to create a successful on line business. From making a web page, getting it hosted, writing ad copy to advertising it and bringing in the dough. This course is the result of over 25 years of sales and marketing for experience.  The past 3 1/2 years I have been on the Internet looking at ways to make money.  I have used and a wide variety of marketing methods. In the end it all came down to this. You can have a terrific product but if no one knows about it you will never get any customers. That's what on-line marketing is all about, getting exposure for a product and making it easy for the customer to buy from you, a  formula that is successful. All successful Internet businesses have a few things in common... a) a web site b) a product  c) a way to sell the product and d) customers.  I show you how each step of the way. This year more people will be buying goods and services on line that ever before! You can have a website selling your products NOW!  In this revealing, step-by-step on-line marketing course... •You will learn how to get Internet Access for FREE. •You will learn how to create your own web site. •You will also learn where to get FREE software that makes it easy to publish your own site within minutes without extensive on line experience or computer programming knowledge. •You will learn how and where to have your website hosted absolutely free. •You will learn where to get bulk email software absolutely free and how to use those programs to promote your business. •You will learn where and how to advertise your products on the Internet for FREE! •You will learn how to create "killer" ad copy to turn the visitors to your page into paying customers. •You will learn how to get full versions of thousands of popular software titles so you can REALLY evaluate them before you buy. •You will learn how to accept credit cards on line for your products with NO MONTHLY FEES, NO CREDIT CHECK and NO APPLICATION or SIGN UP FEES. So sign up for this course today and get on the fast track to profit on the Internet. Here is what some graduates of the course have said. I ordered the Internet Marketing Starter Kit 2 weeks ago.  After I finished all the chapters and the web designing tutorial I published my website and promoted it using the methods in the course.  I was thrilled when orders started coming in for our diet products business. The first day we advertised it I got three orders, the second day I got four.  This is great!  Thanks for all your help.   Mike Boles, Ridgefield, Conn. ----------------------------------------------------------------------- I especially liked the fact that I could accept credit cards at my website the same day I signed up for the service.  I was turned down by my bank for a merchant account and did not want to commit to a long term contract of $59 a month that another service wanted. I am also saving over $20 a month on Internet access as I now get it free.  I was skeptical at first but I tried it and its everything you claim.  The best $79 I ever spent! Sharon Ilkes, Hiawatha, Kansas ----------------------------------------------------------------------- Don't pass up this opportunity to take advantage of this incredible offer. When you order the Starter Kit you will receive the complete course in written form and the course on a 3.5" diskette. You also get access to a password protected web site where you can download the software you will need to publish your web site and promote it. •Free Internet Access •Free Web Building Software •Free Web Hosting •Free Bulk Mail Software •Accept Credit Cards with.. NO Monthly Fees! NO Credit Check! NO Sign-Up Fees! •Learn to write "killer" ad copy! •Advertise your web site for FREE! •Free Email Lists •Step-by-Step Instructions •Guaranteed to get Results!  Order NOW and receive this special BONUS FREE!!! Order now and you will receive 250,000 fresh email addresses harvested from An Online service within the last 30 days.  You will get a username and a password to access the "E-List" from a secret web site with your Internet Marketing Starter Kit.  That's not all!  I will personally provide 30 days of marketing and technical support via email (I usually charge $90 per hour for consulting services.)   Hold on to your seat there's more! You also get more than 100 money making business reports. These reports each tell you about a specific business that you can start.. You can even go into business selling these reports! ACT NOW!!! Product Name: Internet Marketing Starter Kit $39.95 You will receive your Starter Kit by US mail.  The Kit Includes... •3.5" floppy disk containing the contents of the Marketing Course. •The complete course in written form. •Your Username and Password to access the on-line course. ROCK SOLID MONEY BACK GUARANTEE Your satisfaction guaranteed!  If this information is not everything I have said it is and more, I will provide a complete refund.  Guaranteed to get results!  I am so confident in the information I provide that if you are not completely satisfied I will refund your money.   You will not be disappointed, I guarantee it! ---------------------cut here and mail --------------------------------- Internet Marketing Starter Kit Order Form - Code KC1 To order by mail send $39.95 plus $4.95 S&H total $44.90 check or money order payable to: TC Schmidt, 4654 E. Ave S, Suite B-102, Palmdale, CA 93552 Name______________________________ Address____________________________ Address____________________________ City, State, Zip_______________________ Email Address_______________________ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Feb 21 02:02:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00387 for ; Sun, 21 Feb 1999 02:02:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA14806; Sat, 20 Feb 1999 22:50:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA15605 for ietf-radius-outgoing; Sat, 20 Feb 1999 22:47:14 -0800 (PST) From: 5465@server1.rrz-freiburg.de Message-Id: <199902210640.HAA10322@server1.rrz-freiburg.de> To: user@the_internet.com Date: Sat, 20 Feb 99 22:33:34 EST Subject: (radius) BOOST YOUR SEX APPEAL AND CHANGE YOUR SOCIAL AND SEX LIFE FOREVER. Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: 5465@server1.rrz-freiburg.de BOOST YOUR SEX APPEAL AND CHANGE YOUR SOCIAL AND SEX LIFE FOREVER. SCIENCE AND NATURE'S SEXUAL SECRET WEAPON! Scientists have isolated the natural Human male/female Pheromone attractants and they are NOW available to YOU, legally, in the US. ATTRACT THE OPPOSITE SEX LIKE NEVER BEFORE ! IT'S GUARANTEED, or you pay nothing! PHEROMONES in the News! >From the NY Times to the LA Times. USA Today, The Wall Street Journal, Psychology Today, 20/20, Hard Copy, Single Living, Medical Tribune, Philadelphia Inquirer, Dateline, Discovery, Hustler, Playboy, Rocky Mountain News, McCalls, Penthouse, Cosmopolitan, BBC-TV, Colordao Telegraph, GQ, Time, Redbook, Fortune Magazine, and more. Radio and Television Stations worldwide. All have reported the scientific findings amidst excitement, controversy, commotion and thrill about pheromones and their potential use. The Press Has Said it Better Than We Can. "PUT IT TO THE TEST" MERIDIAN TV: Sold extensively in the UK, phermomones were tested live on television in the UK, when the unknowing female presenter was VERY ATTRACTED to one of the twin guys, he was wearing "Androstenone Pheromone" but she did not know this, and did not know why she was attracted to him ! US NEWS and WORLD REPORTS "The key to starting a love affair might be right under your nose. Scientists have just announced the discovery of a virtual sixth sense, a tiny organ in the nasal cavity that responds to chemicals known as pheromones. These natural substances are thought to play a role in basic human emotions such as fear, hunger--and love." FORTUNE MAGAZINE: "An imaginative University of Utah anatomist named David L. Berliner was working with substances that occur in human skin. When he left some of the extracts in open vials around the lab, he noticed a sudden, puzzling rise in camaraderie among a previously acrimonious group of researchers working with him. When he changed the extracts a few months later, the group resumed its contentious ways. Berliner froze and saved the extracts. Nearly 30 years later, ... thanks to a method of containing drugs and cosmetics inside tiny, spongelike polymer spheres, he returned to the subject. In 1989 he ... has isolated the suspected good-fellowship pheromones -- behavior-controlling substances similar to those already known to stimulate sexual activity in animals. (One whiff of a pheromone called aphrodisin from a female hamster and a male is ready to mate.) On March 3, 1998 FOX Affiliate, WSVN in Miami did a story on Pheromones, stating, "If you're looking for love, we've got a potion for passion." ... "Tonight, a secret weapon to attract the opposite sex. Researchers developing their own passion potion. Ever been attracted to someone but weren't really sure why? .... More and more research is pointing to chemicals these days.... undetectable chemicals... pheromones ... a clear odorless liquid" Customers Say: "... works as advertised, best product of its' kind" I've always had trouble meeting women-then I tried your product. Now girls come up to me and introduce themselves all the time! I'd like to know if your product is available in a larger quantity so I can make sure I'm never without it! -Dave J I've been driving a tractor trailer for about 6 years and I'm on the road all the time. It's been impossible to meet women until I tried pheromones. Now every truck stop I pull into I meet new women, and many of them ask me out. Thanks! -Tom on the Road Again, WHAT ARE PHEROMONES? Pheromones are a naturally occurring chemical compound found in all insects, all animals, and in humans. When pheromones are secreted they dictate sexual behavior and attract the opposite sex. Be careful. Animal pheromones do NOT attract humans. Have you ever wondered why people who are not particularly attractive seem to attract dates like flies to honey? They seem to have some "chemical attraction" about themselves. Some call it animal magnetism. It may be pheromones. Now you can have that "chemical attraction" whenever you want. PHEROMONES - THE FACTS Pheromones are natural chemicals which play an important role in sexual communication. Animals, including humans release chemicals in tears, saliva and perspiration. These chemicals send signals relating to mood and health to the subconscious awareness. One theory is that the dominant male will exude more of these chemical attractants than a submissive or weaker male. This chemical attracts more females to him. It is similar for woman attracting men. This natural attractant can also contribute to more intense excitement during love making (sexual foreplay and sexual intercourse). Pheromones may also contribute to the dating phrase, "chemical attraction" that we all talk about. WSVN-TV (March 3, 1998) "Ever been attracted to someone but weren't really sure why? .... More and more research is pointing to chemicals these days.... Undetectable chemicals... pheromones ... a clear odorless liquid" MORE RESEARCH AND REFERENCES: Following is some research done on products made by our manufacturer, and bottled under a different name. It contains the same pheromone type and content as Hi-Octane http://www.angelfire.com/fl/beaches69/index.html ABOUT OUR PRODUCT: Hi-Octane (tm) . is made up of PHEROMONES suspended in witch hazel.. This product is designed to be added to your favorite cologne or perfume. . contains both male and female PHEROMONES. Nature never intended for just one PHEROMONE to be present; but two, male and female. Our manufacturering process uses both PHEROMONES in ALL our products. This will not attract same sex; but works as nature intended, attracting the opposite sex. . comes in 1/8 oz. Bottle with a small funnel so you can easily pour it into your cologne or perfume. One 1/8 oz. bottle is enough to mix with 4 to 8 oz of your favorite perfume product. Similar pheromone products have been sold for up to $100 elsewhere. We sell the the strongest product on the market today for only $39.95. BUY two -- get one free. The world's largest manufacturer of Pheromones, MC Marble, now manufactures Hi-Octane (tm), a pheromone prodcut that is the "Most Powerful sexual attractant on the Market today." HI_OCTANE is made with two powerful synthesized human pheromones, Alpha-Androstenol and Alpha-Androstenone. HI-OCTANE will attract the opposite sex of the wearer. McCall's magazine writes "...pheromones can improve one's love life, pheromones send out subconscious scent signals to the opposite sex that naturally trigger romantic feelings." HI-OCTANE according to the manufacturer, may also intensify sex, by increasing sexual pleasure and endurance of both partners, and creating a higher sexual ecstasy. Individual results may vary. One private study claims that pheromones don't work for everyone. 75% of those trying it had success. Isn't it worth trying? HOW TO ORDER Hi OctaneTM Hi OctaneTM is available from Euphoria Products. A 1/8 oz. bottle with a convenient funnel (to be added to your favorite perfume) is $39.95. Mix 1/4 of the bottle with every 2 oz of your favorite product. One 1/8 oz. bottle is enough to mix with 4 to 8 oz of your favorite product. *** For a limited time, when you order two bottles (up to a two month's supply) of Hi Octane(tm), you'll get a third bottle ABSOLUTELY FREE. *** Please add $3.00 shipping and handling per order. (regardless of how many bottles you order, you pay only $3.00 total!) UPS Second Day Air Delivery is available for an additional $9.00 per order. Overnight, add $15.00 per order. Florida residents, please add applicable sales tax. For orders from outside of the US only ground shipping is available for $15. Our manufacturing facility offers the STRONGEST pheromones on the market today. Our manufacturing facility assures you that Hi-Octane will be always contain the male and female pheromones, the way nature intended it, to best attract the opposite sex for you. It is and will always be manufactured with the finest ingredients to assure your satisfaction. SATISFACTION GUARANTEED Try Hi OctaneTM risk-free. Your satisfaction is unconditionally guaranteed. If you do not find you are meeting and dating and scoring with more people of the opposite sex after using High OctaneTM for 30 days, simply return the unused portion of your order at any time for a full refund--no questions asked. Call 520-453-0303 Extension 404, 24 hours/day, 7 days/week for credit card orders. Have your MasterCard, Visa, American Express, and Discover Card ready and say, " I would like to order ___ bottles of High Octane." If you would like to order by mail, you can send in a check or money order, or credit card information, along with your name and street address (no PO Boxes please) and a day time phone number to: Euphoria Products Dept. 202 1859 No Pine Island Rd. Suite #133 Plantation, FL 33322 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Feb 22 13:37:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21021 for ; Mon, 22 Feb 1999 13:37:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA16631; Mon, 22 Feb 1999 10:26:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA25632 for ietf-radius-outgoing; Mon, 22 Feb 1999 10:24:45 -0800 (PST) From: gfht7@cks.de To: user@the_internet.com Date: Fri, 19 Feb 99 10:32:06 EST Subject: (radius) hi Message-Id: <19990219193633.a7353d45.in@qmpro.cks.de> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: gfht7@cks.de IS YOUR COMPUTER READY FOR 2000? Make sure you're not left behind, prepare for Y2K. Did you know 98% of new computers FAIL Y2K testing? Did you know that Windows 3.x, 95, 98, and NT are not Y2K compliant? These programs need to be patched before the year 2000, if you want to keep using them. Our diskette will test your computer's clock (RTC) and BIOS, see if you're ready for the New Year. Our diskette will test your computer's software, and unlike other Test diskettes, we can read your source coding line by line to find the exact problems in your programs. Our test diskette can read 85% of all shrink wrapped software on the market, plus C++, V-Basics, Oracle, MS-SQL, Access, Delphi, Paradox, Fox Pro, Power Builder, Sybase, and more. If you have a problem, then we have the answer for you! For a limited time, you can receive the Test Diskette at 50% off the normal price. Price: $39.90 SALE PRICE: $19.95 + s/h ($2.00) Call 909/627-3557 IMC Marketing, Information Technologies Dept. An A+ Authorized Service Center. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Feb 22 14:38:08 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22104 for ; Mon, 22 Feb 1999 14:38:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA19229; Mon, 22 Feb 1999 11:30:56 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA04100 for ietf-radius-outgoing; Mon, 22 Feb 1999 11:33:17 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF61E9@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'ietf-radius'" Subject: (radius) Event-Timestamp possible ambiguity Date: Mon, 22 Feb 1999 14:30:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." The description in the extensions draft concerning Event-Timestamp is potentially ambiguous. >5.3. Event-Timestamp > >Description > This attribute is included in an Accounting-Request packet to > record the time on the clock of the NAS that this event occured. <...> >Value > > The Value field is four octets encoding an unsigned integer with > the number of seconds since January 1, 1970 00:00 GMT. The description makes it look like the timestamp may be in local time ("the time on the clock on the NAS"). Yes, the Value text clarifies that this should be GMT, but I have had people who read the document bring this up as a point of confusion. Could we clarify the Even-Timestamp description to make specific reference to GMT/UTC? Something like: Description This attribute is included in an Accounting-Request packet to record the UTC time on the clock of the NAS that this event occurred. + Mark Anthony Beadles + MCI WorldCom + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Feb 22 15:22:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22790 for ; Mon, 22 Feb 1999 15:22:00 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA20168; Mon, 22 Feb 1999 11:59:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA07287 for ietf-radius-outgoing; Mon, 22 Feb 1999 12:02:50 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Mon, 22 Feb 1999 11:53:45 -0800 (PST) From: Glen Zorn To: "Beadles, Mark A." cc: "'ietf-radius'" Subject: Re: (radius) Event-Timestamp possible ambiguity In-Reply-To: <9A74C89D6696D2118E500008C7BA7C56BF61E9@wcomexch1.wcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Mon, 22 Feb 1999, Beadles, Mark A. wrote: > The description in the extensions draft concerning Event-Timestamp is > potentially ambiguous. > > >5.3. Event-Timestamp > > > >Description > > This attribute is included in an Accounting-Request packet to > > record the time on the clock of the NAS that this event occured. > <...> > >Value > > > > The Value field is four octets encoding an unsigned integer with > > the number of seconds since January 1, 1970 00:00 GMT. > > The description makes it look like the timestamp may be in local time ("the > time on the clock on the NAS"). Yes, the Value text clarifies that this > should be GMT, but I have had people who read the document bring this up as > a point of confusion. > > Could we clarify the Even-Timestamp description to make specific reference > to GMT/UTC? Something like: > > > Description > This attribute is included in an Accounting-Request packet to > record the UTC time on the clock of the NAS that this event occurred. Sounds like a good idea to me. > > > + Mark Anthony Beadles + MCI WorldCom + > + mbeadles@wcom.net + http://www.wcom.net + > + Voice 614.723.1941 + Fax 614.723.8407 + > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Feb 22 15:47:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23148 for ; Mon, 22 Feb 1999 15:47:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA22004; Mon, 22 Feb 1999 12:40:00 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA11182 for ietf-radius-outgoing; Mon, 22 Feb 1999 12:42:31 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Mon, 22 Feb 1999 12:34:34 -0800 (PST) From: Glen Zorn To: ietf-radius@livingston.com cc: cdr@livingston.com Subject: (radius) User-Name attribute in Access Accept Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn A while back Aydin mentioned that there was WG consensus that the User-Name attribute should be allowed in Access Accept packets. Is this/will this be reflected in the upcoming revision of RFC 2138? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Feb 22 16:06:25 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23343 for ; Mon, 22 Feb 1999 16:06:24 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA23139; Mon, 22 Feb 1999 12:59:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA13442 for ietf-radius-outgoing; Mon, 22 Feb 1999 13:02:14 -0800 (PST) Date: Mon, 22 Feb 1999 13:02:12 -0800 (PST) From: Carl Rigney Message-Id: <199902222102.NAA13435@server.livingston.com> To: gwz@acm.org, ietf-radius@livingston.com Subject: Re: (radius) User-Name attribute in Access Accept Cc: cdr@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Should the SHOULD be a MUST? Most existing RADIUS clients probably don't honor this right now, so SHOULD allows it and recommends it, but doesn't make implementations that don't do it now broken when the new RFC comes out. > This Attribute indicates the name of the user to be authenticated. It > MUST be sent in Access-Request packets. It MAY be sent in an > Access-Accept packet, in which case the client SHOULD use the name > returned in the Access-Accept packet in any Accounting-Request packets > for this session. -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 23 12:10:23 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11680 for ; Tue, 23 Feb 1999 12:10:22 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA17136; Tue, 23 Feb 1999 09:02:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA20322 for ietf-radius-outgoing; Tue, 23 Feb 1999 08:59:52 -0800 (PST) Date: Tue, 23 Feb 1999 08:59:42 -0800 (PST) From: Carl Rigney Message-Id: <199902231659.IAA20302@server.livingston.com> To: MBeadles@wcom.net, gwz@acm.org Subject: Re: (radius) Event-Timestamp possible ambiguity Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney OK, I'll make that clarification; thanks for the suggestion. If people have any other suggested clarifications please send them along right away; I'm hoping to get the RADIUS, RADIUS Accounting and Extensions drafts into the draft depositary by the cutoff date this Friday so I can ask for last call on them. -- Carl Rigney - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 23 18:37:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19783 for ; Tue, 23 Feb 1999 18:37:51 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA02395; Tue, 23 Feb 1999 15:29:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA05829 for ietf-radius-outgoing; Tue, 23 Feb 1999 15:30:09 -0800 (PST) Date: Tue, 23 Feb 1999 15:30:07 -0800 (PST) From: Carl Rigney Message-Id: <199902232330.PAA05822@server.livingston.com> To: MBeadles@wcom.net Subject: Re: (radius) Event-Timestamp possible ambiguity Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney How about this phrasing for Event-Timestamp, to remove the opportunity for misunderstanding? > This attribute is included in an Accounting-Request packet to record > the time that this event occured on the NAS, in seconds since January > 1, 1970 00:00 UTC. > The Value field is four octets encoding an unsigned integer with the number > of seconds since January 1, 1970 00:00 UTC. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 23 19:02:15 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20763 for ; Tue, 23 Feb 1999 19:02:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA03664; Tue, 23 Feb 1999 15:54:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA08771 for ietf-radius-outgoing; Tue, 23 Feb 1999 15:57:12 -0800 (PST) Date: Tue, 23 Feb 1999 15:57:09 -0800 (PST) From: Carl Rigney Message-Id: <199902232357.PAA08757@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Anyone using Distinguished User-names? Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney RFC 2138 mentions that a User-Name may be: distinguished name A name in ASN.1 form used in Public Key authentication systems. Has anyone actually implemented these? If not, does anyone object if I remove that as useless? -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 23 19:20:12 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21489 for ; Tue, 23 Feb 1999 19:20:11 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA04639; Tue, 23 Feb 1999 16:13:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA10844 for ietf-radius-outgoing; Tue, 23 Feb 1999 16:15:40 -0800 (PST) From: Aydin Edguer Message-Id: <9902240014.AA18456@gefilte.MorningStar.Com> Subject: Re: (radius) Anyone using Distinguished User-names? To: ietf-radius@livingston.com Date: Tue, 23 Feb 1999 19:14:51 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > RFC 2138 mentions that a User-Name may be: > distinguished name > A name in ASN.1 form used in Public Key authentication systems. > Has anyone actually implemented these? There is nothing in most NAS equipment that would prevent this, but I am not aware of any RADIUS servers that use it as such. If you are updating this section, it might be useful to add something that points to RFC 2486 "The Network Access Identifier". - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 23 19:35:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22232 for ; Tue, 23 Feb 1999 19:35:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA05185; Tue, 23 Feb 1999 16:23:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA11657 for ietf-radius-outgoing; Tue, 23 Feb 1999 16:25:27 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF6219@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Carl Rigney'" Cc: ietf-radius@livingston.com Subject: RE: (radius) Event-Timestamp possible ambiguity Date: Tue, 23 Feb 1999 19:23:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." That sounds good to me. + Mark Anthony Beadles + MCI WorldCom Advanced Networks + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + > -----Original Message----- > From: Carl Rigney [SMTP:cdr@livingston.com] > Sent: Tuesday, 23 February 1999 18:30 > To: MBeadles@wcom.net > Cc: ietf-radius@livingston.com > Subject: Re: (radius) Event-Timestamp possible ambiguity > > How about this phrasing for Event-Timestamp, to remove the opportunity > for misunderstanding? > > > This attribute is included in an Accounting-Request packet to record > > the time that this event occured on the NAS, in seconds since January > > 1, 1970 00:00 UTC. > > > The Value field is four octets encoding an unsigned integer with the > number > > of seconds since January 1, 1970 00:00 UTC. > > -- > Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 23 19:42:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22467 for ; Tue, 23 Feb 1999 19:42:31 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA05723; Tue, 23 Feb 1999 16:30:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA12198 for ietf-radius-outgoing; Tue, 23 Feb 1999 16:31:25 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902240027.QAA01343@hsmpka.eng.sun.com> Date: Tue, 23 Feb 1999 16:21:41 -0800 To: "Aydin Edguer" , Subject: Re: (radius) Anyone using Distinguished User-names? X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Content-Transfer-Encoding: 7bit >> RFC 2138 mentions that a User-Name may be: >> distinguished name >> A name in ASN.1 form used in Public Key authentication systems. >> Has anyone actually implemented these? > >There is nothing in most NAS equipment that would prevent this, but I am >not aware of any RADIUS servers that use it as such. > >If you are updating this section, it might be useful to add something >that points to RFC 2486 "The Network Access Identifier". Yes, I would add that RFC2486 is probably used more often than an X.500 distinguished name. The draft should reflect this if at all possible. PatC >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 23 19:45:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22647 for ; Tue, 23 Feb 1999 19:45:21 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA06298; Tue, 23 Feb 1999 16:38:29 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA13039 for ietf-radius-outgoing; Tue, 23 Feb 1999 16:39:17 -0800 (PST) Date: Tue, 23 Feb 1999 16:39:15 -0800 (PST) From: Carl Rigney Message-Id: <199902240039.QAA13029@server.livingston.com> To: Pat.Calhoun@eng.sun.com Subject: Re: (radius) Anyone using Distinguished User-names? Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I've updated the working draft to mention RFC 2486 NAIs. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Feb 23 20:16:12 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24135 for ; Tue, 23 Feb 1999 20:16:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA07429; Tue, 23 Feb 1999 17:08:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA15443 for ietf-radius-outgoing; Tue, 23 Feb 1999 17:10:30 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Tue, 23 Feb 1999 17:02:24 -0800 (PST) From: Glen Zorn To: ietf-radius@livingston.com Subject: (radius) accounting for failed calls Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn I'm trying to figure out how to do this in an interoperable way. Somebody suggested that I send an Accounting-Request with a status type of stop, no user name and a session time of 0, along with a VSA representing the reason for failure. The question is, how many RADIUS accounting servers would this break? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 13:52:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21893 for ; Wed, 24 Feb 1999 13:52:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA29026; Wed, 24 Feb 1999 10:39:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA11317 for ietf-radius-outgoing; Wed, 24 Feb 1999 10:40:58 -0800 (PST) From: Barney Wolff To: Glen Zorn , ietf-radius@livingston.com Date: Wed, 24 Feb 1999 13:39 EST Subject: Re: (radius) accounting for failed calls Content-Type: text/plain Message-ID: <36d447b00.703@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Speaking for my own implementation, I'd be delighted to receive such a request. What's acm.org's vendor OID? :) Barney Wolff > Date: Tue, 23 Feb 1999 17:02:24 -0800 (PST) > From: Glen Zorn > To: ietf-radius@livingston.com > Subject: (radius) accounting for failed calls > Content-Length: 423 > Reply-To: Glen Zorn > > I'm trying to figure out how to do this in an interoperable way. Somebody > suggested that I send an Accounting-Request with a status type of stop, no > user name and a session time of 0, along with a VSA representing the > reason for failure. The question is, how many RADIUS accounting servers > would this break? > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 14:34:22 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22653 for ; Wed, 24 Feb 1999 14:34:21 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA01510; Wed, 24 Feb 1999 11:26:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA17399 for ietf-radius-outgoing; Wed, 24 Feb 1999 11:29:09 -0800 (PST) Message-Id: <3.0.1.32.19990224133640.0070101c@splitrock.net> X-Sender: jchisolm@splitrock.net X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Wed, 24 Feb 1999 13:36:40 -0600 To: Glen Zorn From: Joe Chisolm Subject: Re: (radius) accounting for failed calls Cc: ietf-radius@livingston.com In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Joe Chisolm I would rather have the status type be "call reject". If your server is trying to do any kind of auditing, the phantom stop could be a problem. At 05:02 PM 2/23/99 -0800, Glen Zorn wrote: >I'm trying to figure out how to do this in an interoperable way. Somebody >suggested that I send an Accounting-Request with a status type of stop, no >user name and a session time of 0, along with a VSA representing the >reason for failure. The question is, how many RADIUS accounting servers >would this break? > > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 15:14:42 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23411 for ; Wed, 24 Feb 1999 15:14:41 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA03005; Wed, 24 Feb 1999 12:06:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA21087 for ietf-radius-outgoing; Wed, 24 Feb 1999 12:08:48 -0800 (PST) Message-Id: <199902242008.PAA00973@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: (radius) Matching NAS-IP-Address to actual real-life NAS IP address Date: Wed, 24 Feb 1999 15:08:58 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok Under what circumstances can a RADIUS client put a NAS-IP-Address attribute inside of a packet, which is different than the IP address from which the packet is sent? I can understand if there's a proxy server between the NAS and the end authenticating server. The NAS-IP-Address *may* match the NAS, and the sending IP address will be the proxy. However, one of our customers ran into the following problem. They had a firewall with 3 interfaces, on 3 networks. Let's call them DMZ, Public, and Private. The RADIUS server is on the Private network, and is seeing the Access-Request packets coming from the Private network address of the firewall. These requests are due to people from the Public network requesting authentication. However, the NAS-IP-Address that the firewall is placing inside of the packet contains the DMZ IP address of the firewall. So the firewall is leaking information across networks, and is confusing to the server about its IP address. I'd like to see the draft updated to talk about this issue. Even adding a 'SHOULD' would help, as in: --------------------------------- 5.4. NAS-IP-Address Description This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user. It is only used in Access-Request packets. Either NAS-IP-Address or NAS- Identifier SHOULD be present in an Access-Request packet. If the NAS is originating the packet, then the value of the NAS-IP-Address attribute SHOULD match the IP address of the interface from which the packet is sent. --------------------------------- (where the last sentence is new.) Personally, I'd prefer a MUST, but I'd be satisfied with a SHOULD. Not surprisingly, the vendors response was: "Our interpretation of the RFC is that the NAS-IP-Address attribute does not have to match the IP address of the interface from which the packet was sent." If this interpreation is correct, then there isn't much point in having a NAS-IP-Address attribute, as the RADIUS server doesn't know, and doesn't care about other IP addresses the NAS may have. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 15:19:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23463 for ; Wed, 24 Feb 1999 15:19:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA03236; Wed, 24 Feb 1999 12:10:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA21587 for ietf-radius-outgoing; Wed, 24 Feb 1999 12:13:32 -0800 (PST) Message-Id: <3.0.5.32.19990224151229.030e8620@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 24 Feb 1999 15:12:29 -0500 To: Glen Zorn , ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) accounting for failed calls In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton At 05:02 PM 2/23/99 -0800, Glen Zorn wrote: >I'm trying to figure out how to do this in an interoperable way. Somebody >suggested that I send an Accounting-Request with a status type of stop, no >user name and a session time of 0, along with a VSA representing the >reason for failure. The question is, how many RADIUS accounting servers >would this break? > > >- If this is a failed user-based session (Service-Type mismatch, or IPCP failure, etc), then I'd suggest that you send the Username that you authenticated with. If this is a call that never got to authentication, then this is appropriate. But you might be tempted to dust off Acct-Status-Type = 5 for this. The Nortel/Bay Versalar 5399/8000 when a parameter radius_acct_level is set to advanced generates Acct-Requests with Acct-Status-Types of 4 and 5 for Call-Start, Call-Stop, and VSEs of VALUE Acct-Status-Type Annex-User-Reject 0x06300001 purge-acct-rec VALUE Acct-Status-Type Annex-Call-Reject 0x06300002 for failures in call setup or session setup. Our RADIUS server would have no problem with any of this, as the lack of name would not cause it to choke. And it uses the NAS-IP-Address, Port-Type, Port-Number matching rules to clear any managed state. Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 15:48:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23996 for ; Wed, 24 Feb 1999 15:48:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA04421; Wed, 24 Feb 1999 12:41:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA24730 for ietf-radius-outgoing; Wed, 24 Feb 1999 12:43:42 -0800 (PST) Message-ID: <36D4647D.8AE97D3F@iea-software.com> Date: Wed, 24 Feb 1999 12:43:41 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Glen Zorn CC: ietf-radius@livingston.com Subject: Re: (radius) accounting for failed calls References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit Glen Zorn wrote: > > I'm trying to figure out how to do this in an interoperable way. Somebody > suggested that I send an Accounting-Request with a status type of stop, no > user name and a session time of 0, along with a VSA representing the > reason for failure. The question is, how many RADIUS accounting servers > would this break? As long as it includes NAS-Identifier and NAS-Port, it would be great. The rest is up to the user of our software on whether they want to log it or not. You could use the Acct-Terminate-Cause rather than a VSA (it you can) to make it more generic. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 15:52:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24070 for ; Wed, 24 Feb 1999 15:52:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA04370; Wed, 24 Feb 1999 12:41:01 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA24651 for ietf-radius-outgoing; Wed, 24 Feb 1999 12:43:00 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Alan DeKok'" , ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Wed, 24 Feb 1999 15:39:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Alan DeKok writes... > Under what circumstances can a RADIUS client put a NAS-IP-Address > attribute inside of a packet, which is different than the IP address > from which the packet is sent? I suppose if the RADIUS client is a multi-homed host, it might do so. The primary purpose of the NAS-IP-Address attribute (or the NAS- Identifier) is so that the RADIUS server may look up the shared secret of the NAS. A multi-homed NAS may have it's secret registered on the RADIUS server by only one of it's IP addresses. A somewhat contrived example, perhaps... > I'd like to see the draft updated to talk about this issue. Even > adding a 'SHOULD' would help, as in: > > --------------------------------- > 5.4. NAS-IP-Address > > Description > > This Attribute indicates the identifying IP Address of the NAS > which is requesting authentication of the user. It is only used > in Access-Request packets. Either NAS-IP-Address or NAS- > Identifier SHOULD be present in an Access-Request packet. > > If the NAS is originating the packet, then the value of the > NAS-IP-Address attribute SHOULD match the IP address of the > interface from which the packet is sent. I don't know that this is important to require or desire. The NAS-IP-Address is just a "name" by which the RADIUS server may know the identity of the NAS, and thus know it's shared secret. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 16:11:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24326 for ; Wed, 24 Feb 1999 16:11:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA05396; Wed, 24 Feb 1999 13:03:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA27308 for ietf-radius-outgoing; Wed, 24 Feb 1999 13:06:24 -0800 (PST) Message-ID: From: Indranil Bagchi To: "'Nelson, David'" , ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Wed, 24 Feb 1999 13:05:16 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Indranil Bagchi I would agree with this point of view. We have a radius client to authenticate users telnetting into our ethernet switch. Howver, the switch has no fixed IP address. It uses the address of the vlan over which the radius server is reachable. This might change for a number of reasons including change of IP address associated with the vlan or if the route to the radius server changes. Tying the NAS IP address with the vlan address would make the lookup to fail in the above scenario. Regards -----Original Message----- From: Nelson, David [mailto:dnelson@cabletron.com] Sent: Wednesday, February 24, 1999 8:40 PM To: 'Alan DeKok'; ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Alan DeKok writes... > Under what circumstances can a RADIUS client put a NAS-IP-Address > attribute inside of a packet, which is different than the IP address > from which the packet is sent? I suppose if the RADIUS client is a multi-homed host, it might do so. The primary purpose of the NAS-IP-Address attribute (or the NAS- Identifier) is so that the RADIUS server may look up the shared secret of the NAS. A multi-homed NAS may have it's secret registered on the RADIUS server by only one of it's IP addresses. A somewhat contrived example, perhaps... > I'd like to see the draft updated to talk about this issue. Even > adding a 'SHOULD' would help, as in: > > --------------------------------- > 5.4. NAS-IP-Address > > Description > > This Attribute indicates the identifying IP Address of the NAS > which is requesting authentication of the user. It is only used > in Access-Request packets. Either NAS-IP-Address or NAS- > Identifier SHOULD be present in an Access-Request packet. > > If the NAS is originating the packet, then the value of the > NAS-IP-Address attribute SHOULD match the IP address of the > interface from which the packet is sent. I don't know that this is important to require or desire. The NAS-IP-Address is just a "name" by which the RADIUS server may know the identity of the NAS, and thus know it's shared secret. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 16:26:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24548 for ; Wed, 24 Feb 1999 16:26:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA06169; Wed, 24 Feb 1999 13:18:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA28987 for ietf-radius-outgoing; Wed, 24 Feb 1999 13:22:08 -0800 (PST) Date: Wed, 24 Feb 1999 13:22:07 -0800 (PST) From: Carl Rigney Message-Id: <199902242122.NAA28977@server.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) accounting for failed calls Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Rather than abuse Accounting stop records in this way, would people prefer to add a Access-Failed value for accounting records? I know I've argued against this in the past, that you can't do accounting if you haven't authenticated the user, and that this belongs in SNMP rather than RADIUS, but perhaps I'm mellowing with age. Thoughts? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 16:30:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24601 for ; Wed, 24 Feb 1999 16:30:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA06377; Wed, 24 Feb 1999 13:23:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA29540 for ietf-radius-outgoing; Wed, 24 Feb 1999 13:27:00 -0800 (PST) Date: Wed, 24 Feb 1999 13:26:59 -0800 (PST) From: Carl Rigney Message-Id: <199902242126.NAA29532@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Zero-length strings Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Right now there are no zero-length strings in RADIUS, because all the definitions require at least an octet of data. People's use of zero length attributes disturbs me, because I suspect they're implying semantics in such usage that are not documented and therefore non interoperable. So I want to pin this discrepancy down by either updating the language from "0-253 octets of data" to "1-253 octets" or by explicitly describing what to do with a zero length attribute. The reference implementation (RADIUS 1.13 from Livingston) didn't allow zero length attributes; if the protocol is going to be changed to allow zero length attributes I want to see really strong justification for their usefulness IN AN INTEROPERABLE MANNER. Post fast, the next draft's only a couple of days away. (Its fine to email me directly, or to the list, as you prefer.) -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 16:33:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24692 for ; Wed, 24 Feb 1999 16:33:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA05995; Wed, 24 Feb 1999 13:16:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA28626 for ietf-radius-outgoing; Wed, 24 Feb 1999 13:19:33 -0800 (PST) Date: Wed, 24 Feb 1999 13:19:32 -0800 (PST) From: Carl Rigney Message-Id: <199902242119.NAA28619@server.livingston.com> To: ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney There's no point in attempting to match the NAS-IP-Address to the IP address of the client the access-request is received from. They won't match in proxy, so I don't see any particular value in requiring that they match for multi-homed NASes. The NAS-IP-Address is just a convenient and unique identifier for NASes that don't use NAS-Identifier to uniquely identify themselves. Would people like me to add language to the RADIUS draft pointing this out? -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 16:34:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24724 for ; Wed, 24 Feb 1999 16:34:50 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA06640; Wed, 24 Feb 1999 13:28:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA00237 for ietf-radius-outgoing; Wed, 24 Feb 1999 13:31:20 -0800 (PST) Message-Id: <199902242131.QAA01298@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress In-reply-to: Your message of "Wed, 24 Feb 1999 15:39:43 EST." Date: Wed, 24 Feb 1999 16:31:33 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok dnelson@cabletron.com says: > Alan DeKok writes... > > Under what circumstances can a RADIUS client put a NAS-IP-Address > > attribute inside of a packet, which is different than the IP address > > from which the packet is sent? > > I suppose if the RADIUS client is a multi-homed host, it might do so. > The primary purpose of the NAS-IP-Address attribute (or the NAS- > Identifier) is so that the RADIUS server may look up the shared secret > of the NAS. Really? The RFC doesn't say that at all. I won't quote it, but it does seem to differentiate between a 'client', which originates a request and has a shared secret, and a 'NAS'. The implementations I'm familiar with key on the IP address (and possibly port) of the client for the shared secret. The NAS-IP-Address attribute is treated as ONLY informational. In fact, I've just tried this with servers from different vendors. I sent an Access-Request packet from client X, with NAS-IP-Address of Y. I didn't define Y as a RADIUS client, yet the user was authenticated. > > If the NAS is originating the packet, then the value of the > > NAS-IP-Address attribute SHOULD match the IP address of the > > interface from which the packet is sent. > > I don't know that this is important to require or desire. The > NAS-IP-Address is just a "name" by which the RADIUS server may know > the identity of the NAS, and thus know it's shared secret. I'd have to disagree. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 16:47:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24923 for ; Wed, 24 Feb 1999 16:47:27 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA06854; Wed, 24 Feb 1999 13:32:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA00687 for ietf-radius-outgoing; Wed, 24 Feb 1999 13:36:11 -0800 (PST) Message-ID: <36D470C9.106FDAF@iea-software.com> Date: Wed, 24 Feb 1999 13:36:09 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Carl Rigney CC: ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings References: <199902242126.NAA29532@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit Carl Rigney wrote: > > Right now there are no zero-length strings in RADIUS, because all the > definitions require at least an octet of data. People's use of zero > length attributes disturbs me, because I suspect they're implying > semantics in such usage that are not documented and therefore non > interoperable. So I want to pin this discrepancy down by either > updating the language from "0-253 octets of data" to "1-253 octets" or > by explicitly describing what to do with a zero length attribute. > > The reference implementation (RADIUS 1.13 from Livingston) didn't allow > zero length attributes; if the protocol is going to be changed to allow > zero length attributes I want to see really strong justification for > their usefulness IN AN INTEROPERABLE MANNER. Post fast, the next > draft's only a couple of days away. > > (Its fine to email me directly, or to the list, as you prefer.) I'm an advocate of "if there isn't any data, don't include the attribute". Therefore, I'd like to see a requirement on all attributes of 1-253 octets. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 16:53:12 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24997 for ; Wed, 24 Feb 1999 16:53:11 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA07232; Wed, 24 Feb 1999 13:45:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA01839 for ietf-radius-outgoing; Wed, 24 Feb 1999 13:48:45 -0800 (PST) From: "Heath Partington" To: "Alan DeKok" , Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Wed, 24 Feb 1999 16:46:39 -0500 Message-ID: <000701be603f$28c444b0$da047392@hpartington.hq.springtidenet.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <199902242131.QAA01298@cryptocard.ott.igs.net> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Heath Partington" Content-Transfer-Encoding: 7bit I think the multi-homed case is a valid case but looking at the draft I believe it does need to be updated to clarify this point. > -----Original Message----- > From: owner-ietf-radius@livingston.com > [mailto:owner-ietf-radius@livingston.com]On Behalf Of Alan DeKok > Sent: Wednesday, February 24, 1999 4:32 PM > To: ietf-radius@livingston.com > Subject: Re: (radius) Matching NAS-IP-Address to actual > real-life NAS IP > a ddress > > > dnelson@cabletron.com says: > > Alan DeKok writes... > > > Under what circumstances can a RADIUS client put a > NAS-IP-Address > > > attribute inside of a packet, which is different than the > IP address > > > from which the packet is sent? > > > > I suppose if the RADIUS client is a multi-homed host, it > might do so. > > The primary purpose of the NAS-IP-Address attribute (or the NAS- > > Identifier) is so that the RADIUS server may look up the > shared secret > > of the NAS. > > Really? The RFC doesn't say that at all. I won't quote it, but it > does seem to differentiate between a 'client', which originates a > request and has a shared secret, and a 'NAS'. > > The implementations I'm familiar with key on the IP address (and > possibly port) of the client for the shared secret. The > NAS-IP-Address attribute is treated as ONLY informational. > > In fact, I've just tried this with servers from different vendors. > > I sent an Access-Request packet from client X, with NAS-IP-Address > of Y. I didn't define Y as a RADIUS client, yet the user was > authenticated. > > > > If the NAS is originating the packet, then the value of the > > > NAS-IP-Address attribute SHOULD match the IP address of the > > > interface from which the packet is sent. > > > > I don't know that this is important to require or desire. The > > NAS-IP-Address is just a "name" by which the RADIUS server may know > > the identity of the NAS, and thus know it's shared secret. > > I'd have to disagree. > > Alan DeKok. > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 16:56:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25051 for ; Wed, 24 Feb 1999 16:56:30 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA07418; Wed, 24 Feb 1999 13:49:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA02346 for ietf-radius-outgoing; Wed, 24 Feb 1999 13:52:37 -0800 (PST) Message-Id: <199902242152.QAA01417@cryptocard.ott.igs.net> To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress In-reply-to: Your message of "Wed, 24 Feb 1999 13:19:32 PST." <199902242119.NAA28619@server.livingston.com> Date: Wed, 24 Feb 1999 16:52:49 -0500 From: Alan DeKok Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok Carl Rigney wrote: > There's no point in attempting to match the NAS-IP-Address to the IP > address of the client the access-request is received from. They > won't match in proxy, so I don't see any particular value in > requiring that they match for multi-homed NASes. Exactly, which is why I suggested that they 'SHOULD' match. I'm not sure what it would mean for a multi-homed NAS if they don't match, which is why I brought up the question. The side effect of the problem in this case, was a firewall leaking secret information across it's "protected" interfaces. Not a Good Thing. > The NAS-IP-Address is just a convenient and unique identifier for > NASes that don't use NAS-Identifier to uniquely identify themselves. Most radius servers treat the NAS-IP-Address as informational, not as identifying. i.e. They ignore it, other than for logging purposes. > Would people like me to add language to the RADIUS draft pointing this out? You've got my vote. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:03:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25233 for ; Wed, 24 Feb 1999 17:03:50 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA07703; Wed, 24 Feb 1999 13:56:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA02987 for ietf-radius-outgoing; Wed, 24 Feb 1999 13:59:31 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Alan DeKok'" , ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Wed, 24 Feb 1999 16:55:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Alan DeKok writes... > Really? The RFC doesn't say that at all. That's the way it has always worked, at least before the introduction of RADIUS Proxy servers. > I won't quote it, but it > does seem to differentiate between a 'client', which originates a > request and has a shared secret, and a 'NAS'. Both a NAS and a RADIUS Proxy Server may act as RADIUS Client. All RADIUS clients must have a shared secret, that the RADIUS servers used by these RADIUS clients have access to. > The implementations I'm familiar with key on the IP address (and > possibly port) of the client for the shared secret. The > NAS-IP-Address attribute is treated as ONLY informational. Hmmm. This is one way, probably the only way, to implement RADIUS Proxy service. Since the "second-hop" RADIUS server cannot be required to share a secret with the NAS, the "first-hop" RADIUS server must share a secret with the "second-hop" RADIUS server for the purpose of decrypting the end user's password. Another way of stating this is that the encryption of the end user's password is per "hop", each RADIUS Proxy server must decrypt it to clear text and then re-encrypt it using the shared secret of the next RADIUS server up the food chain. On RADIUS responses, it works just the other way around. > > I don't know that this is important to require or desire. The > > NAS-IP-Address is just a "name" by which the RADIUS server may know > > the identity of the NAS, and thus know it's shared secret. > > I'd have to disagree. Well, I reiterate my statement for the non-proxy case, however I fully recognize that for RADIUS Proxy service to work, RADIUS servers are going to have to do as you suggest and look at the source IP address of the RADIUS client to be able to look up the appropriate shared secret. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:05:58 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25289 for ; Wed, 24 Feb 1999 17:05:56 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA07875; Wed, 24 Feb 1999 13:58:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA03216 for ietf-radius-outgoing; Wed, 24 Feb 1999 14:01:26 -0800 (PST) Message-Id: <199902242201.RAA21650@merit.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: "Dale E. Reed Jr." cc: Carl Rigney , ietf-radius@livingston.com, rsc@merit.edu Subject: Re: (radius) Zero-length strings In-reply-to: Your message of "Wed, 24 Feb 1999 13:36:09 PST." <36D470C9.106FDAF@iea-software.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Feb 1999 17:01:01 -0500 From: "Richard S. Conto" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Richard S. Conto" I don't like zero length strings (I call them empty strings, because people I've worked will have been confused between NULL and 0 and ""), but that doesn't mean that an empty string isn't valid. It's like the difference between reporting 0 or not reporting anything at all (0 vs. missing data.) At least one vendor uses zero length strings, (in the STATE attribute) and as one of the contributors to a well known RADIUS implementation, I have to cope with it. I also have to anticipate RADIUS clients that accept whatever a user provides, and that includes empty strings and garbage filled strings. I think that zero-length (empty) strings MUST be allowed, especially where the value may be provided by a human being, or where the use of the value is left to the vendor (USER-NAME and STATE come to mind.) I think so for the pragmatic reason that there are implementations using it, and for the architectural reason that an empty value is different from a missing value. =============================================================== > originally from: "Dale E. Reed Jr." > originally to: Carl Rigney > originally cc: ietf-radius@livingston.com > subject: Re: (radius) Zero-length strings > date: Wed, 24 Feb 1999 13:36:09 -0800 > -------- >Carl Rigney wrote: >> >> Right now there are no zero-length strings in RADIUS, because all the >> definitions require at least an octet of data. People's use of zero >> length attributes disturbs me, because I suspect they're implying >> semantics in such usage that are not documented and therefore non >> interoperable. So I want to pin this discrepancy down by either >> updating the language from "0-253 octets of data" to "1-253 octets" or >> by explicitly describing what to do with a zero length attribute. >> >> The reference implementation (RADIUS 1.13 from Livingston) didn't allow >> zero length attributes; if the protocol is going to be changed to allow >> zero length attributes I want to see really strong justification for >> their usefulness IN AN INTEROPERABLE MANNER. Post fast, the next >> draft's only a couple of days away. >> >> (Its fine to email me directly, or to the list, as you prefer.) > >I'm an advocate of "if there isn't any data, don't include the >attribute". Therefore, I'd like to see a requirement on all >attributes of 1-253 octets. > >-- > >Dale E. Reed Jr. Emerald and RadiusNT >__________________________________________ >IEA Software, Inc. www.iea-software.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:08:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25345 for ; Wed, 24 Feb 1999 17:08:56 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA08068; Wed, 24 Feb 1999 14:02:00 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA03602 for ietf-radius-outgoing; Wed, 24 Feb 1999 14:05:02 -0800 (PST) Date: Wed, 24 Feb 1999 14:05:01 -0800 (PST) From: Carl Rigney Message-Id: <199902242205.OAA03596@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Has anyone implemented Configuration-Token? Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Has anyone implemented Configuration-Token (from the extensions draft)? If so, please speak up quickly. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:19:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25596 for ; Wed, 24 Feb 1999 17:19:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA08409; Wed, 24 Feb 1999 14:10:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA04529 for ietf-radius-outgoing; Wed, 24 Feb 1999 14:13:26 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF622A@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Carl Rigney'" , ietf-radius@livingston.com Subject: RE: (radius) accounting for failed calls Date: Wed, 24 Feb 1999 17:11:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Carl Rigney [mailto:cdr@livingston.com] >Rather than abuse Accounting stop records in this way, would people prefer to >add a Access-Failed value for accounting records? I know I've argued against >this in the past, that you can't do accounting if you haven't authenticated >the user, and that this belongs in SNMP rather than RADIUS, but perhaps I'm mellowing >with age. An Access-Failed message is certainly more elegant, but an accounting-stop with time of 0 would work too. Our systems would not break with an accounting-stop time of zero, and we could easily flag it as an exceptional condition for service level accounting. Either way, I like the idea of adding this. I don't necessarily agree that this "belongs" in SNMP either. + Mark Anthony Beadles + MCI WorldCom + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:22:15 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25679 for ; Wed, 24 Feb 1999 17:22:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA08611; Wed, 24 Feb 1999 14:15:27 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA05061 for ietf-radius-outgoing; Wed, 24 Feb 1999 14:18:46 -0800 (PST) Message-Id: <199902242218.RAA01544@cryptocard.ott.igs.net> To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress In-reply-to: Your message of "Wed, 24 Feb 1999 16:55:29 EST." Date: Wed, 24 Feb 1999 17:18:59 -0500 From: Alan DeKok Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok > > Really? The RFC doesn't say that at all. > > That's the way it has always worked, at least before the > introduction of RADIUS Proxy servers. My copy of the Livingston 1.16 source looks up the client using the IP address of the receiving socket. The NAS-IP-Address attribute isn't even *referenced* in the source. That is, it's information, not identifying. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:23:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25760 for ; Wed, 24 Feb 1999 17:23:47 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA08744; Wed, 24 Feb 1999 14:16:58 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA05191 for ietf-radius-outgoing; Wed, 24 Feb 1999 14:19:47 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF622B@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Carl Rigney'" , ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Wed, 24 Feb 1999 17:18:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Carl Rigney [mailto:cdr@livingston.com] >There's no point in attempting to match the NAS-IP-Address to the IP address of >the client the access-request is received from. They won't match in proxy, >so I don't see any particular value in requiring that they match for >multi-homed NASes. The NAS-IP-Address is just a convenient and unique identifier >for NASes that don't use NAS-Identifier to uniquely identify themselves. That is exactly right. Imagine a back end database, shared among several RADIUS servers, which keeps track of all the NAS-IP-Addresses of the clients you talk to. Not for tracking shared secrets, but doing things based on geographical location, local time of day, country, etc. by using the NAS-IP-Address as a means of identifying WHICH NAS it is. It has nothing intrinsically to do with the IP address of any particular interface card on the NAS. >Would people like me to add language to the RADIUS draft pointing this out? I thought it was obvious until this thread, so maybe you should. + Mark Anthony Beadles + MCI WorldCom + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:27:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25908 for ; Wed, 24 Feb 1999 17:27:46 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA08923; Wed, 24 Feb 1999 14:20:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA05688 for ietf-radius-outgoing; Wed, 24 Feb 1999 14:23:28 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Wed, 24 Feb 1999 14:15:29 -0800 (PST) From: Glen Zorn To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) accounting for failed calls In-Reply-To: <199902242122.NAA28977@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Wed, 24 Feb 1999, Carl Rigney wrote: > Rather than abuse Accounting stop records in this way, would people prefer to > add a Access-Failed value for accounting records? I know I've argued against > this in the past, that you can't do accounting if you haven't authenticated > the user, and that this belongs in SNMP rather than RADIUS, but perhaps I'm mellowing > with age. > > Thoughts? I would _much_ prefer that (though I prefer the name "Call-Failure"). > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:28:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25936 for ; Wed, 24 Feb 1999 17:28:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA09186; Wed, 24 Feb 1999 14:21:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA05917 for ietf-radius-outgoing; Wed, 24 Feb 1999 14:24:45 -0800 (PST) From: William Bulley Message-Id: <199902242226.RAA07369@ohm.merit.edu> Subject: Re: (radius) accounting for failed calls To: dmitton@baynetworks.com Date: Wed, 24 Feb 1999 17:26:02 -0500 (EST) Cc: gwz@acm.org, ietf-radius@livingston.com In-Reply-To: <3.0.5.32.19990224151229.030e8620@fred.xylogics.com> from "Dave Mitton" at Feb 24, 99 03:12:29 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William Bulley Content-Transfer-Encoding: 7bit According to Dave Mitton: > > If this is a call that never got to authentication, then this is appropriate. > But you might be tempted to dust off Acct-Status-Type = 5 for this. This is what we call "Modem-Stop" (see our dictionary, any version from 1995 on) Carl allowed us to use these (he reserved the 4 and 5 values of Modem-Start and Modem-Stop respectively) several years ago... Regards, web... -- William Bulley Senior Systems Research Programmer Merit Network, Inc. Email: web@merit.edu 4251 Plymouth Road, Suite C Phone: (734) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (734) 647-3185 The big difference between space and time is you can't reuse time... - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:36:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26364 for ; Wed, 24 Feb 1999 17:36:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA10043; Wed, 24 Feb 1999 14:29:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA06803 for ietf-radius-outgoing; Wed, 24 Feb 1999 14:32:15 -0800 (PST) Message-Id: <199902242230.OAA25985@shell4.ba.best.com> Subject: Re: (radius) accounting for failed calls (fwd) To: ietf-radius@livingston.com Date: Wed, 24 Feb 1999 14:30:37 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Glen Zorn shaped the electrons to say... >> Rather than abuse Accounting stop records in this way, would people prefer to >> add a Access-Failed value for accounting records? I know I've argued against >> this in the past, that you can't do accounting if you haven't authenticated >> the user, and that this belongs in SNMP rather than RADIUS, but perhaps I'm mellowing >> with age. >> >> Thoughts? >I would _much_ prefer that (though I prefer the name "Call-Failure"). I think this is the better idea as well. Though "Session-Failure" would seem to be better - it isn't necessarily a 'Call'. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 17:46:08 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26836 for ; Wed, 24 Feb 1999 17:46:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA10796; Wed, 24 Feb 1999 14:39:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA07981 for ietf-radius-outgoing; Wed, 24 Feb 1999 14:42:24 -0800 (PST) Message-Id: <199902242240.OAA28017@shell4.ba.best.com> Subject: Re: (radius) accounting for failed calls (fwd) To: ietf-radius@livingston.com Date: Wed, 24 Feb 1999 14:40:38 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time William Bulley shaped the electrons to say... >This is what we call "Modem-Stop" (see our dictionary, any version >from 1995 on) I know of 3 non-RFC values: 4 Modem-Start 5 Modem-Stop 6 Cancel And the Nortel/Bay VSEs: 0x06300001 Annex-User-Reject 0x06300002 Annex-Call-Reject 0x06300003 Annex-IPCP-Start 0x06300004 Annex-IPXCP-Start 0x06300005 Annex-ATCP-Start 0x06300006 Annex-Accounting-Restart 0x06300007 Annex-Accounting-Shutdown 0x06300008 Annex-Tunnel-Start 0x06300009 Annex-Tunnel-Stop 0x0630000a Annex-Tunnel-Reject 0x0630000b Annex-Tunnel-Link-Start 0x0630000c Annex-Tunnel-Link-Stop 0x0630000d Annex-MP-Start 0x0630000e Annex-MP-Stop It seems that many of the VSEs can be replaced by RFC/Draft values now. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 18:13:58 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28309 for ; Wed, 24 Feb 1999 18:13:57 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA12080; Wed, 24 Feb 1999 15:02:29 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA10903 for ietf-radius-outgoing; Wed, 24 Feb 1999 15:05:36 -0800 (PST) Message-ID: <36D485BE.83184F16@iea-software.com> Date: Wed, 24 Feb 1999 15:05:34 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Alan DeKok CC: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress References: <199902242131.QAA01298@cryptocard.ott.igs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit Alan DeKok wrote: > > > I suppose if the RADIUS client is a multi-homed host, it might do so. > > The primary purpose of the NAS-IP-Address attribute (or the NAS- > > Identifier) is so that the RADIUS server may look up the shared secret > > of the NAS. > > Really? The RFC doesn't say that at all. I won't quote it, but it > does seem to differentiate between a 'client', which originates a > request and has a shared secret, and a 'NAS'. The server should ALWAYS use the IP Address it received the request from to verify against the secret and NOT the NAS-IP-Address or NAS-Identifier. Anything else would be a security hole. > The implementations I'm familiar with key on the IP address (and > possibly port) of the client for the shared secret. The > NAS-IP-Address attribute is treated as ONLY informational. Correct. > In fact, I've just tried this with servers from different vendors. > > I sent an Access-Request packet from client X, with NAS-IP-Address > of Y. I didn't define Y as a RADIUS client, yet the user was > authenticated. Which is expected behavior for me. > > > If the NAS is originating the packet, then the value of the > > > NAS-IP-Address attribute SHOULD match the IP address of the > > > interface from which the packet is sent. > > > > I don't know that this is important to require or desire. The > > NAS-IP-Address is just a "name" by which the RADIUS server may know > > the identity of the NAS, and thus know it's shared secret. > > I'd have to disagree. Actually, the NAS-Identifier is just a "name". The NAS-IP-Address should be the IP Address of the ORIGINATOR of the request. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 18:20:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28780 for ; Wed, 24 Feb 1999 18:20:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA12468; Wed, 24 Feb 1999 15:14:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA12392 for ietf-radius-outgoing; Wed, 24 Feb 1999 15:17:25 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Wed, 24 Feb 1999 15:09:25 -0800 (PST) From: Glen Zorn To: "Dale E. Reed Jr." cc: Carl Rigney , ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings In-Reply-To: <36D470C9.106FDAF@iea-software.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Wed, 24 Feb 1999, Dale E. Reed Jr. wrote: > Carl Rigney wrote: > > > > Right now there are no zero-length strings in RADIUS, because all the > > definitions require at least an octet of data. People's use of zero > > length attributes disturbs me, because I suspect they're implying > > semantics in such usage that are not documented and therefore non > > interoperable. So I want to pin this discrepancy down by either > > updating the language from "0-253 octets of data" to "1-253 octets" or > > by explicitly describing what to do with a zero length attribute. > > > > The reference implementation (RADIUS 1.13 from Livingston) didn't allow > > zero length attributes; if the protocol is going to be changed to allow > > zero length attributes I want to see really strong justification for > > their usefulness IN AN INTEROPERABLE MANNER. Post fast, the next > > draft's only a couple of days away. > > > > (Its fine to email me directly, or to the list, as you prefer.) > > I'm an advocate of "if there isn't any data, don't include the > attribute". Therefore, I'd like to see a requirement on all > attributes of 1-253 octets. Ditto. > > -- > > Dale E. Reed Jr. Emerald and RadiusNT > __________________________________________ > IEA Software, Inc. www.iea-software.com > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 18:59:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01317 for ; Wed, 24 Feb 1999 18:59:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA13442; Wed, 24 Feb 1999 15:52:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA16006 for ietf-radius-outgoing; Wed, 24 Feb 1999 15:53:10 -0800 (PST) Date: Wed, 24 Feb 1999 15:53:08 -0800 (PST) From: Carl Rigney Message-Id: <199902242353.PAA15998@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Retransmission hints Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney In going through the archives to find things that have confused people in the past (and thus are good candidates for discussing in more depth in the revised RADIUS draft) I came across the issue of retransmissions. I'd like to add something along the following lines to the Operations section. Comments please? 2.X Retransmission Notes If the RADIUS server and alternate RADIUS server share the same shared secret, it is OK to retransmit the packet to the backup RADIUS server with the same ID and Request Authenticator, because the content of the attributes haven't changed. If you wanted to use a new Request Authenticator when sending to the backup server, you could (and would then have to use a new ID). If you change the contents of the User-Password attribute (or any other attribute), you need a new Request Authenticator and therefore a new ID. If the NAS is retransmitting a RADIUS request to the same server as before, and the attributes haven't changed, you MUST use the same same Request Authenticator and ID. If any attributes have changed, you MUST use a new Request Authenticator and ID. A NAS MAY use the same ID across all servers, or MAY keep track of IDs seperately for each server, its up to the implementer. If a NAS needs more than 256 IDs for outstanding requests, it MAY use additional source ports to send requests from, and keep track of IDs for each source port. This allows up to 16 million or so outstanding requests at one time to a single server. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 19:13:24 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02259 for ; Wed, 24 Feb 1999 19:13:23 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13870; Wed, 24 Feb 1999 16:01:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA16965 for ietf-radius-outgoing; Wed, 24 Feb 1999 16:04:03 -0800 (PST) Message-Id: <199902250004.TAA01986@cryptocard.ott.igs.net> To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress In-reply-to: Your message of "Wed, 24 Feb 1999 17:18:05 EST." <9A74C89D6696D2118E500008C7BA7C56BF622B@wcomexch1.wcom.net> Date: Wed, 24 Feb 1999 19:04:15 -0500 From: Alan DeKok Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok "Beadles, Mark A." wrote: > > Imagine a back end database, shared among several RADIUS servers, > which keeps track of all the NAS-IP-Addresses of the clients you > talk to. Not for tracking shared secrets, but doing things based on > geographical location, local time of day, country, etc. by using the > NAS-IP-Address as a means of identifying WHICH NAS it is. Wouldn't that identifier be better handled by using the pre-existing NAS-Identifier attribute? (ducks the thrown shoe) > It has nothing intrinsically to do with the IP address of any > particular interface card on the NAS. Hmm.. so the NAS-IP-Address isn't necessarily associated with a RADIUS client, but if it is, it's randomly chosen from one of the IP addresses that the client is using (multi-homed or aliased). What do you do when you've got 2 NASes, each with a private and a public network, with the RADIUS server on the shared public network? The server can get requests from each NAS, with the SAME NAS-IP-Address. e.g. (ala Livingston 1.16) radrecv: Request from 206.248.21.33 ... NAS-IP-Address = 192.168.1.1 ... radrecv: Request from 206.248.21.200 ... NAS-IP-Address = 192.168.1.1 ... The same scenario applies to proxies, too. So NAS-IP-Address CANNOT be used as a unique NAS identifier. That's why I asked my original question. As for NAS-Identifier, I haven't seen many implementations actually use it. Would it be desirable to have the RFC suggest a method for generating a *unique* per-NAS identifier? (I won't do so here.) > >Would people like me to add language to the RADIUS draft pointing this out? > > I thought it was obvious until this thread, so maybe you should. I think I've argued successfully that your suggested use of NAS-IP-Address as a unique identifier has its problems. Therefore, the proper methods for implementating and handling that attribute are not obvious. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 19:29:08 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03488 for ; Wed, 24 Feb 1999 19:29:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA14731; Wed, 24 Feb 1999 16:21:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA18468 for ietf-radius-outgoing; Wed, 24 Feb 1999 16:22:45 -0800 (PST) From: Aydin Edguer Message-Id: <9902250021.AA18734@gefilte.MorningStar.Com> Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address To: ietf-radius@livingston.com Date: Wed, 24 Feb 1999 19:21:56 -0500 (EST) Cc: aland@cryptocard.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > Wouldn't that identifier be better handled by using the pre-existing > NAS-Identifier attribute? The purpose of the NAS-Identifier and NAS-IP-Address are similar. The difference is not the purpose but the format of the attribute. Not all NASes support the NAS-Identifier attribute, but most (?all?) do support either the NAS-Identifier or the NAS-IP-Address. Some may allow the operator to configure which will be used. > What do you do when you've got 2 NASes, each with a private and a > public network, with the RADIUS server on the shared public network? > The server can get requests from each NAS, with the SAME NAS-IP-Address. No, this would be considered a misconfiguration. 5.32. NAS-Identifier The String field is one or more octets, and should be unique to the NAS within the scope of the RADIUS server. -- RFC 2138 5.4. NAS-IP-Address This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user. -- RFC 2138 If the NAS-IP-Address is not unique then it would not be "the identifying IP Address". Explicit text can be added to the NAS-IP-Address to make this as clear as it is for NAS-Identifier (if necessary). > So NAS-IP-Address CANNOT be used as a unique NAS identifier. I am not sure how you reached this conclusion. The NAS-IP-Address does not have to be the same as the IP address used by the NAS to originate the RADIUS Access-Request but it should still be a unique identifier of the NAS. Since there is no way for a NAS to know all the NAS-Identifiers or all the NAS-IP-Addresses that are available, enforcement of this requirement is left up to the system operator. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 19:56:43 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05418 for ; Wed, 24 Feb 1999 19:56:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA16178; Wed, 24 Feb 1999 16:49:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA20902 for ietf-radius-outgoing; Wed, 24 Feb 1999 16:52:18 -0800 (PST) Message-Id: <199902250052.TAA02217@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address In-reply-to: Your message of "Wed, 24 Feb 1999 19:21:56 EST." <9902250021.AA18734@gefilte.MorningStar.Com> Date: Wed, 24 Feb 1999 19:52:30 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok Aydin Edguer wrote: > > What do you do when you've got 2 NASes, each with a private and a > > public network, with the RADIUS server on the shared public network? > > The server can get requests from each NAS, with the SAME NAS-IP-Address. > > No, this would be considered a misconfiguration. I disagree. You can't control which NAS-IP-Address is sent by the NAS, and if you're a server others proxy to, you can't control the IP addresses chosen by remote administrators. Scenario: Sales guy 1 dials into a POP in L.A., NAS-IP-Address = 192.168.1.1 Sales guy 2 dials into a POP in N.Y., NAS-IP-Address = 192.168.1.1 They both are proxied to your corporate RADIUS server in Chicago. Please convince me that NAS-IP-Address attribute is a unique identifier under your control. You can't. > 5.32. NAS-Identifier > > The String field is one or more octets, and should be unique to > the NAS within the scope of the RADIUS server. This is what I would like. The ONLY way to have such a unique identifier in a world of proxies is to have a GLOBALLY unique identifier. > 5.4. NAS-IP-Address > > This Attribute indicates the identifying IP Address of the NAS > which is requesting authentication of the user. > > -- RFC 2138 > > If the NAS-IP-Address is not unique then it would not be "the identifying > IP Address". Explicit text can be added to the NAS-IP-Address to make > this as clear as it is for NAS-Identifier (if necessary). It's an "identifying IP Address". Unlike the NAS-Identifer definition, the word "unique" does not appear here. ergo, the RFC does not require it to be unique. In a world of private IP's sent via RADIUS proxies across the Internet, NAS-IP-Address CANNOT be unique. (I'll ignore the horrifying idea of NATs inspecting and translating IP's inside of RADIUS packets.) > > So NAS-IP-Address CANNOT be used as a unique NAS identifier. > > I am not sure how you reached this conclusion. I hope I've better explained my reasoning above. > The NAS-IP-Address does not have to be the same as the IP address > used by the NAS to originate the RADIUS Access-Request but it should > still be a unique identifier of the NAS. Unfortunately, the RFC does not currently state this restriction. I believe that the RFC cannot make this restriction, either. > Since there is no way for a NAS to know all the NAS-Identifiers or all > the NAS-IP-Addresses that are available, enforcement of this requirement > is left up to the system operator. ??? Why would the NAS have to "know all of the NAS-Identifiers"? All it needs is a globally unique ID. These are well known, they're called Ethernet MAC addresses. (Not that I'm advocating using MAC addresses for NAS-Identifier, though it wouldn't hurt) Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 20:22:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07002 for ; Wed, 24 Feb 1999 20:22:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA18141; Wed, 24 Feb 1999 17:15:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA22578 for ietf-radius-outgoing; Wed, 24 Feb 1999 17:15:58 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF622C@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Alan DeKok'" , ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Wed, 24 Feb 1999 20:12:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Alan DeKok [SMTP:aland@cryptocard.com] > Wouldn't that identifier be better handled by using the pre-existing >NAS-Identifier attribute? > > (ducks the thrown shoe) How'd you see that shoe coming? :) Not all NAS vendors support NAS-Identifier, nor are they required to. > Hmm.. so the NAS-IP-Address isn't necessarily associated with a >RADIUS client The NAS-IP-Address is associated with the NAS that originated the chain of RADIUS requests that led to the current one. >The server can get requests from each NAS, with the SAME >NAS-IP-Address. e.g. (ala Livingston 1.16) Yes, this CAN happen. It would be a very bad idea to implement a network this way, since you couldn't keep track of your NAS's. You could just as well say, "The server can get requests from each NAS, with the SAME NAS-Identifier." It could happen, but it's no way to run a network. > So NAS-IP-Address CANNOT be used as a unique NAS identifier. That's >why I asked my original question. Yes it can. If you care to use it this way (and that is an operational choice, not a protocol requirement), then as long as the NAS-IP-Address is unique within the space of concern to your RADIUS servers, you're golden. > I think I've argued successfully that your suggested use of >NAS-IP-Address as a unique identifier has its problems. Heck, I didn't think of it all by myself, but thanks. People use NAS-IP-Address for this all the time. >Therefore, >the proper methods for implementating and handling that attribute are >not obvious. Right, which is why Carl may want to make a note about. Aydin's suggestion would do. + Mark Anthony Beadles + MCI WorldCom + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 20:30:25 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07531 for ; Wed, 24 Feb 1999 20:30:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA18404; Wed, 24 Feb 1999 17:23:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA23121 for ietf-radius-outgoing; Wed, 24 Feb 1999 17:25:03 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF622D@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Alan DeKok'" , ietf-radius@livingston.com, "'roamops@tdmx.rutgers.edu'" Subject: (radius) Globally unique NAS-Identifier (was: Matching NAS-IP-Address to a ctual real-life NAS IP address) Date: Wed, 24 Feb 1999 20:22:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." (from a thread on the RADIUS list - trim the to: line where appropriate) From: Alan DeKok [SMTP:alan@cryptocard.com] >Scenario: > > Sales guy 1 dials into a POP in L.A., NAS-IP-Address = 192.168.1.1 > Sales guy 2 dials into a POP in N.Y., NAS-IP-Address = 192.168.1.1 > They both are proxied to your corporate RADIUS server in Chicago. > Please convince me that NAS-IP-Address attribute is a unique >identifier under your control. You can't. I'm not sure why your corporate RADIUS server cares about the NAS-IP-Address in either case. What useful information does this carry to the corporation? For that matter, a service provider may wish to deliberately HIDE IP address information from the corporation in a proxy situation. > This is what I would like. The ONLY way to have such a unique >identifier in a world of proxies is to have a GLOBALLY unique >identifier. Ah, well, this is the RADIUS protocol working group. In my opinion, issues relating to global uniqueness and a "world of proxies" would seem to belong properly to the Roaming Operations working group, where I have cc'ed this message. > All it needs is a globally unique ID. These are well known, they're >called Ethernet MAC addresses. (Not that I'm advocating using MAC >addresses for NAS-Identifier, though it wouldn't hurt) Not all IP interfaces have globally unique Ethernet MAC addresses. And you may want a NAS-Identifier to remain static even if you change a faulty card in a NAS, you know? + Mark Anthony Beadles + MCI WorldCom Advanced Networks + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Feb 24 21:16:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10653 for ; Wed, 24 Feb 1999 21:16:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA19444; Wed, 24 Feb 1999 18:10:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA25348 for ietf-radius-outgoing; Wed, 24 Feb 1999 18:13:21 -0800 (PST) Message-Id: <199902250213.VAA02516@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com, roamops@tdmx.rutgers.edu Subject: (radius) Re: Globally unique NAS-Identifier (was: Matching NAS-IP-Address to a ctual real-life NAS IP address) In-reply-to: Your message of "Wed, 24 Feb 1999 20:22:01 EST." <9A74C89D6696D2118E500008C7BA7C56BF622D@wcomexch1.wcom.net> Date: Wed, 24 Feb 1999 21:13:17 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok "Beadles, Mark A." wrote: > From: Alan DeKok [SMTP:alan@cryptocard.com] > > > Please convince me that NAS-IP-Address attribute is a unique > >identifier under your control. You can't. > > I'm not sure why your corporate RADIUS server cares about the NAS-IP-Address > in either case. What useful information does this carry to the corporation? It doesn't, but my original problem was that people were advocating the use of NAS-IP-Address as a (potentially globally) unique NAS ID, for tracking/database keying purposes. I think such use is incorrect. > For that matter, a service provider may wish to deliberately HIDE IP address > information from the corporation in a proxy situation. Then they should remove all NAS specific information from the packet, and replace it with information about the proxy server. In fact, if they're using private IP addresses for their NASes, this requirement should probably be mentioned in the RADIUS RFC as a MUST. Polluting the global information space with private IP's is a Bad Thing. > In my opinion, issues relating to global uniqueness and a "world of > proxies" would seem to belong properly to the Roaming Operations > working group, where I have cc'ed this message. When in doubt, avoid the issue by redefining the problem. :) If RADIUS proxies don't advertise private IP's from the NASes, we don't need global uniqueness other than public proxy IP address. > Not all IP interfaces have globally unique Ethernet MAC addresses. And you > may want a NAS-Identifier to remain static even if you change a faulty card > in a NAS, you know? I know, which is why I wasn't entirely advocating it. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 00:29:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25012 for ; Thu, 25 Feb 1999 00:29:31 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA23237; Wed, 24 Feb 1999 21:22:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA02712 for ietf-radius-outgoing; Wed, 24 Feb 1999 21:25:56 -0800 (PST) Date: Thu, 25 Feb 1999 00:25:52 -0500 (EST) From: "Steven P. Crain" To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) Retransmission hints In-Reply-To: <199902242353.PAA15998@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Wed, 24 Feb 1999, Carl Rigney wrote: > If you wanted to use a new Request Authenticator when sending to the > backup server, you could (and would then have to use a new ID). Since its sending to a different server, it wouldn't necessarily need a new ID. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net, An ISP with Excellence in the Greater Boston Area. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 00:29:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25032 for ; Thu, 25 Feb 1999 00:29:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA23191; Wed, 24 Feb 1999 21:22:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA02659 for ietf-radius-outgoing; Wed, 24 Feb 1999 21:24:47 -0800 (PST) Date: Thu, 25 Feb 1999 00:21:38 -0500 (EST) From: "Steven P. Crain" To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings In-Reply-To: <199902242126.NAA29532@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Wed, 24 Feb 1999, Carl Rigney wrote: > definitions require at least an octet of data. People's use of zero > length attributes disturbs me, because I suspect they're implying > semantics in such usage that are not documented and therefore non > interoperable. So I want to pin this discrepancy down by either > updating the language from "0-253 octets of data" to "1-253 octets" or > by explicitly describing what to do with a zero length attribute. I strongly prefer allowing 0 length attributes, mostly because I see no valid reason to exclude it and because I have seen other unrelated protocols exhibit strange behavior because of similar restrictions. (E.g. Sybase's SQL server has to store zero-length strings as a single space.) I would like to see the following semantics defined: Attribute not included: attribute is not relevant, and any default behavior shoul be used. Attribute included, length field=2: integer/date types: not permitted, or possibly a shorthand for 0 string types: a zero-length string Attribute included, 0 value: Set the attribute to 0. *Not* just use the default on the client or whatever. That should be implied by absense of the attribute, not some hacked in value. I would encourage allowing zero-length strings in many standard attributes: User-Name, to indicate we want to authenticate "" (as in the person pressed Enter when prompted for username). Class, to cause the NAS to pass an empty string back in accounting. State, to cause an empty State to be passed back by the server to the client. The problem with all of this is that it does not document the way vendors currently use it, and it would not be interoperable with the broken things they currently do. If it comes down to disallowing zero-length attributes or allowing them and making them simply meaningless place-holders, I would have to vote to disallow them. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net, An ISP with Excellence in the Greater Boston Area. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 01:15:55 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26363 for ; Thu, 25 Feb 1999 01:15:54 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA24053; Wed, 24 Feb 1999 21:56:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA03787 for ietf-radius-outgoing; Wed, 24 Feb 1999 22:00:20 -0800 (PST) Message-Id: <199902250559.VAA16375@shell4.ba.best.com> Subject: Re: (radius) Zero-length strings (fwd) To: ietf-radius@livingston.com Date: Wed, 24 Feb 1999 21:59:08 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Steven P. Crain shaped the electrons to say... >Attribute not included: > attribute is not relevant, and any default behavior shoul be used. Fine. >Attribute included, length field=2: > integer/date types: not permitted, or possibly a shorthand for 0 > string types: a zero-length string My concern here is how existing implementations will handle it. What if a server sends a zero-length string to a client in say Framed-Route? I would expect it to ignore it - but will any today be confused? So far we've heard mostly form server folks that the servers should be ok. Will all clients gracefully handle zero-length strings? >Attribute included, 0 value: > Set the attribute to 0. *Not* just use the default on the client >or whatever. That should be implied by absense of the attribute, not some >hacked in value. Unfortunately this will break or change current behavior. For example Framed-IP-Address = 0.0.0.0 will, in my experience, result in default behavior. You wouldn't want a 0 value IP being assigned. Of course, on the other hand, I would like to see Idle-Timeout = 0 turn it off, as it stands today you can't override a locally configured timer and turn it off. So people are using the kludge of setting it to a huge value. > State, to cause an empty State to be passed back by the server to >the client. I don't understand what an empty State will accomplish. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 01:17:15 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26389 for ; Thu, 25 Feb 1999 01:17:15 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA23893; Wed, 24 Feb 1999 21:53:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA03654 for ietf-radius-outgoing; Wed, 24 Feb 1999 21:56:50 -0800 (PST) Message-ID: <36D4E61F.3CEFEF80@iea-software.com> Date: Wed, 24 Feb 1999 21:56:47 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Richard S. Conto" CC: Carl Rigney , ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings References: <199902242201.RAA21650@merit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit "Richard S. Conto" wrote: > > I don't like zero length strings (I call them empty strings, > because people I've worked will have been confused between > NULL and 0 and ""), but that doesn't mean that an empty string > isn't valid. It's like the difference between reporting 0 or > not reporting anything at all (0 vs. missing data.) > > At least one vendor uses zero length strings, (in the STATE > attribute) and as one of the contributors to a well known > RADIUS implementation, I have to cope with it. > > I also have to anticipate RADIUS clients that accept whatever > a user provides, and that includes empty strings and garbage > filled strings. I can't agree with this. What possible usefullness can state with an empty contents (AVP length of two) contribute to anything and what makes it different than not including it at all? The same thing really goes for username. A NAS should reject a request immediately is a user hits enter for the username, and not even bother with sending the request. Althought the RADIUS client is supposed to be simple, its not supposed to be stupid. :( Because there are broken or current implementations that send a AVP length of two, doesn't mean that the RFC has to accept or allow it. The purpose of this update that Carl is working on is to clarify the implementation rules and clean up problems. This is one I brought up over a year ago and am excited about getting cleaned up. > I think that zero-length (empty) strings MUST be allowed, > especially where the value may be provided by a human being, > or where the use of the value is left to the vendor (USER-NAME > and STATE come to mind.) I think so for the pragmatic > reason that there are implementations using it, and for the > architectural reason that an empty value is different from a > missing value. Whats different from the server making interpreting a missing attribute the same as it would interpret an AVP length of two? I really don't like (although I can live with it) an AVP length of 3 with the single data of 0. I interpret this as a blank NULL terminated string (and we all know strings are not NULL terminated in RADIUS). -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 01:17:20 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26399 for ; Thu, 25 Feb 1999 01:17:19 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA24252; Wed, 24 Feb 1999 22:03:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA03991 for ietf-radius-outgoing; Wed, 24 Feb 1999 22:05:58 -0800 (PST) Message-ID: <36D4E842.E293989F@iea-software.com> Date: Wed, 24 Feb 1999 22:05:54 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Nelson, David" CC: "'Alan DeKok'" , ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit "Nelson, David" wrote: > > > The implementations I'm familiar with key on the IP address (and > > possibly port) of the client for the shared secret. The > > NAS-IP-Address attribute is treated as ONLY informational. > > Hmmm. This is one way, probably the only way, to implement RADIUS > Proxy service. Since the "second-hop" RADIUS server cannot be > required to share a secret with the NAS, the "first-hop" RADIUS > server must share a secret with the "second-hop" RADIUS server for > the purpose of decrypting the end user's password. Another way of > stating this is that the encryption of the end user's password is per > "hop", each RADIUS Proxy server must decrypt it to clear text and then > re-encrypt it using the shared secret of the next RADIUS server up the > food chain. On RADIUS responses, it works just the other way around. Except that there are other Password attributes besides PAP which may not be clear text. It is good to state that each RADIUS server must unpackage the request and if it needs to proxy/forward it, must re-package the request specifically for the server it is forwarding it to. > > > I don't know that this is important to require or desire. The > > > NAS-IP-Address is just a "name" by which the RADIUS server may know > > > the identity of the NAS, and thus know it's shared secret. > > > > I'd have to disagree. > > Well, I reiterate my statement for the non-proxy case, however I fully > recognize that for RADIUS Proxy service to work, RADIUS servers are > going to have to do as you suggest and look at the source IP address of > the RADIUS client to be able to look up the appropriate shared secret. A RADIUS server should NEVER look at anything but the IP Address the request came in from to determine the secret and validitiy of the request. As an implementaion issue, you shouldn't even look at the contents of the request until you have verified the request came from an allowed IP (therefore, if someone is playing a DOS attack, you don't waste time looking at the packet). There are many RADIUS implementations that do look at the full request before checking the source and are suspectible to DOS and malformed packet attacks. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 01:33:46 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26770 for ; Thu, 25 Feb 1999 01:33:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA24781; Wed, 24 Feb 1999 22:19:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA04575 for ietf-radius-outgoing; Wed, 24 Feb 1999 22:23:01 -0800 (PST) Message-ID: <36D4EC42.58E86AAF@iea-software.com> Date: Wed, 24 Feb 1999 22:22:58 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Steven P. Crain" CC: Carl Rigney , ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit "Steven P. Crain" wrote: > > I strongly prefer allowing 0 length attributes, mostly because I see no > valid reason to exclude it and because I have seen other unrelated > protocols exhibit strange behavior because of similar restrictions. (E.g. > Sybase's SQL server has to store zero-length strings as a single space.) Thats a sybase thing. MS SQL 7 finally fixed that totaly annoying "bug" and allows zero Length Strings for a varchar. But comparing a fixed number of fields database (where the field has to be there regardless if you set it to anything or not) to a dynamic field protocol like RADIUS isn't fair. > I would like to see the following semantics defined: > > Attribute not included: > attribute is not relevant, and any default behavior shoul be used. > > Attribute included, length field=2: > integer/date types: not permitted, or possibly a shorthand for 0 > string types: a zero-length string I don't see the relevance for either. My gripe about this is that we want to keep the protocol clean and fast. Putting a whole bunch of meaningless attributes in just clutters things up. I mean this whole semantic thing would be required to complicate things is it simply wasn't allowed. > Attribute included, 0 value: > Set the attribute to 0. *Not* just use the default on the client > or whatever. That should be implied by absense of the attribute, not some > hacked in value. This is a per-attribute issue of how to interpret the value, and doesn't need to be addressed globally. > I would encourage allowing zero-length strings in many standard > attributes: > User-Name, to indicate we want to authenticate "" (as in the > person pressed Enter when prompted for username). The NAS shouldn't send a request in that case (it should just re-prompt or eventually dump the user). If you are talking Caller-ID auth, thats a different story. > Class, to cause the NAS to pass an empty string back in > accounting. Which is just more waste of processing and accomplished nothing? > State, to cause an empty State to be passed back by the server to > the client. Same as above. > The problem with all of this is that it does not document the way vendors > currently use it, and it would not be interoperable with the broken things > they currently do. If it comes down to disallowing zero-length attributes > or allowing them and making them simply meaningless place-holders, I would > have to vote to disallow them. IMHO, forcing broken implementations to get fixed is a GOOD thing. Adding the ability for something to be interpreted many different ways is a bad thing. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 01:40:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26891 for ; Thu, 25 Feb 1999 01:40:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA25216; Wed, 24 Feb 1999 22:33:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA05003 for ietf-radius-outgoing; Wed, 24 Feb 1999 22:36:46 -0800 (PST) Message-Id: <4.1.19990225013056.0098c560@nips.acec.com> X-Sender: natale@nips.acec.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Thu, 25 Feb 1999 01:33:51 -0500 To: "Dale E. Reed Jr." From: Bob Natale Subject: Re: (radius) Zero-length strings Cc: ietf-radius@livingston.com In-Reply-To: <36D4EC42.58E86AAF@iea-software.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Bob Natale >At 2/25/99:01:22 AM, Dale E. Reed Jr. wrote: Hi Dale, <...> >IMHO, forcing broken implementations to get fixed is a GOOD thing. >Adding the ability for something to be interpreted many different >ways is a bad thing. Yes, I agree. This kind of guidance needs to be added to the IETF "way"...on a par with the older wisdom such as "Be liberal in what you accept and conservative in what you send" (paraphrased). Backwards compatibility has its place, and its limits. Cordially, BobN ------------ ISO 9001 Registered Quality Supplier ----------- Bob Natale | ACE*COMM | 301-721-3000 [v] Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f] bnatale@acecomm.com| Gaithersburg MD 20878 | www.acecomm.com ------------- Free downloads at www.winsnmp.com ------------- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 06:57:53 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06556 for ; Thu, 25 Feb 1999 06:57:52 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA00256; Thu, 25 Feb 1999 03:50:43 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA14253 for ietf-radius-outgoing; Thu, 25 Feb 1999 03:51:11 -0800 (PST) Date: Thu, 25 Feb 1999 06:51:06 -0500 (EST) From: "Steven P. Crain" To: "Dale E. Reed Jr." cc: Carl Rigney , ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings In-Reply-To: <36D4EC42.58E86AAF@iea-software.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Wed, 24 Feb 1999, Dale E. Reed Jr. wrote: > > Attribute included, length field=2: > > integer/date types: not permitted, or possibly a shorthand for 0 > > string types: a zero-length string > > I don't see the relevance for either. My gripe about this is that we > want to keep the protocol clean and fast. Putting a whole bunch of > meaningless attributes in just clutters things up. I mean this whole > semantic thing would be required to complicate things is it simply > wasn't allowed. Perhaps, but I mean to suggest that it not be a special case. A zero-length string is a well defined object that might be useful and is well behaved wrt the common operations that a radius server would be performing (logging it, string comparisons, and so forth). The values of mant attributes ought to be considered as undistinguished octets, in which case a zero-length values is just as much a black box as a 13-length one or a 4-length one. > > I would encourage allowing zero-length strings in many standard > > attributes: > > User-Name, to indicate we want to authenticate "" (as in the > > person pressed Enter when prompted for username). > > The NAS shouldn't send a request in that case (it should just re-prompt > or eventually dump the user). Why? What if I want that to be a valid guest login? That should not be something unnaturally restricted at the protocol level. > > Class, to cause the NAS to pass an empty string back in > > accounting. > > Which is just more waste of processing and accomplished nothing? No, to the client and the protocol it is a black box, and who is to say what it might mean to the server. > > State, to cause an empty State to be passed back by the server to > > the client. > > Same as above. Agreed, they are the same. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net, An ISP with Excellence in the Greater Boston Area. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 10:50:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11772 for ; Thu, 25 Feb 1999 10:50:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA05851; Thu, 25 Feb 1999 07:32:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA23954 for ietf-radius-outgoing; Thu, 25 Feb 1999 07:34:09 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199902251529.HAA02409@hsmpka.eng.sun.com> Date: Thu, 25 Feb 1999 07:23:45 -0800 To: "Beadles, Mark A." , "'roamops@tdmx.rutgers.edu'" , , "'Alan DeKok'" Subject: Re: (radius) Globally unique NAS-Identifier (was: Matching NAS-IP-Address to a ctual real-life NAS IP address) X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Content-Transfer-Encoding: 7bit >(from a thread on the RADIUS list - trim the to: line where appropriate) >From: Alan DeKok [SMTP:alan@cryptocard.com] >>Scenario: >> >> Sales guy 1 dials into a POP in L.A., NAS-IP-Address = 192.168.1.1 >> Sales guy 2 dials into a POP in N.Y., NAS-IP-Address = 192.168.1.1 >> They both are proxied to your corporate RADIUS server in Chicago. > >> Please convince me that NAS-IP-Address attribute is a unique >>identifier under your control. You can't. > >I'm not sure why your corporate RADIUS server cares about the NAS-IP-Address >in either case. What useful information does this carry to the corporation? >For that matter, a service provider may wish to deliberately HIDE IP address >information from the corporation in a proxy situation. > >> This is what I would like. The ONLY way to have such a unique >>identifier in a world of proxies is to have a GLOBALLY unique >>identifier. > >Ah, well, this is the RADIUS protocol working group. In my opinion, issues >relating to global uniqueness and a "world of proxies" would seem to belong >properly to the Roaming Operations working group, where I have cc'ed this >message. > >> All it needs is a globally unique ID. These are well known, they're >>called Ethernet MAC addresses. (Not that I'm advocating using MAC >>addresses for NAS-Identifier, though it wouldn't hurt) > >Not all IP interfaces have globally unique Ethernet MAC addresses. And you >may want a NAS-Identifier to remain static even if you change a faulty card >in a NAS, you know? Furthermore, some NASes only have Frame Relay or ATM interfaces, and it isn't clear to me that these boxes have a MAC address. If the language to the NAS Identifier is changed to insist that it is the NASes FQDN, then it should be guaranteed to be unique. PatC > > > > >+ Mark Anthony Beadles + MCI WorldCom Advanced Networks + >+ mbeadles@wcom.net + http://www.wcom.net + >+ Voice 614.723.1941 + Fax 614.723.8407 + > > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 11:00:46 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12188 for ; Thu, 25 Feb 1999 11:00:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA06532; Thu, 25 Feb 1999 07:53:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA25903 for ietf-radius-outgoing; Thu, 25 Feb 1999 07:56:18 -0800 (PST) Message-Id: <199902251555.KAA06881@merit.edu> X-Mailer: exmh version 2.0.2 2/24/98 To: "Dale E. Reed Jr." cc: "Richard S. Conto" , Carl Rigney , ietf-radius@livingston.com, rsc@merit.edu Subject: Re: (radius) Zero-length strings In-reply-to: Your message of "Wed, 24 Feb 1999 21:56:47 PST." <36D4E61F.3CEFEF80@iea-software.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Feb 1999 10:55:52 -0500 From: "Richard S. Conto" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Richard S. Conto" > originally from: "Dale E. Reed Jr." > subject: Re: (radius) Zero-length strings > date: Wed, 24 Feb 1999 21:56:47 -0800 > -------- ... >I can't agree with this. What possible usefullness can state >with an empty contents (AVP length of two) contribute to anything >and what makes it different than not including it at all? The >same thing really goes for username. A NAS should reject a >request immediately is a user hits enter for the username, and >not even bother with sending the request. Althought the RADIUS >client is supposed to be simple, its not supposed to be stupid. :( I can suggest several reasons, such as being used as a placeholder, or to be part of some more complicated, multi-pass authentication policy enforced by the NAS. And I don't think a NAS should immediately reject a zero (empty) USER-NAME. That's a policy that should be determined by the service provider, and should be entirely be between the service provider and the user. Perhaps CALLING-STATION-ID would sufficiently identify the user (as far as the service-provider is concerned), or the combination of NAS-Identifier (or NAS-Ip-Address) and NAS-PORT. >Because there are broken or current implementations that send >a AVP length of two, doesn't mean that the RFC has to accept >or allow it. The purpose of this update that Carl is working >on is to clarify the implementation rules and clean up problems. >This is one I brought up over a year ago and am excited about >getting cleaned up. I think you need to justify why an empty string should be explicitly disallowed. An empty string (in most cases) is no different than any other invalid value, such as a mal-formed FRAMED-ROUTE. If the RADIUS server wants to disallow it, that's fine. ... >Whats different from the server making interpreting a missing >attribute the same as it would interpret an AVP length of two? >I really don't like (although I can live with it) an AVP >length of 3 with the single data of 0. I interpret this as >a blank NULL terminated string (and we all know strings are not >NULL terminated in RADIUS). Missing data really is different than default (or zero) data. And making a special case that an empty string should be represented as a one octet string with the value '\0' goes contrary to the spirit of your previous arguments against special cases (and only makes sense to a programmer who things that C-strings are undistinguished octets.) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 11:34:06 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13336 for ; Thu, 25 Feb 1999 11:34:06 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA08032; Thu, 25 Feb 1999 08:26:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA29403 for ietf-radius-outgoing; Thu, 25 Feb 1999 08:29:45 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Alan DeKok'" , ietf-radius@livingston.com, roamops@tdmx.rutgers.edu Subject: RE: (radius) Re: Globally unique NAS-Identifier (was: Matching NA S-IP-Address to a ctual real-life NAS IP address) Date: Thu, 25 Feb 1999 11:26:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Alan DeKok writes... > ...but my original problem was that people were advocating > the use of NAS-IP-Address as a (potentially globally) unique NAS ID, > for tracking/database keying purposes. I think such use is incorrect. Reasonable arguments have been advanced that the RADIUS attribute NAS-IP-Address is not sufficient to identify a NAS, for purposes of looking up it's shared secret, et. al. This has been demonstrated for the RADIUS Proxy Service case. Assertions have been made that the source IP address of the UDP datagram containing a RADIUS request is the only correct way to identify the NAS, or more generally the RADIUS client, at least in the most general case. This was, I believe, the rough consensus that last time this issue was debated on the RADIUS WG mailing list, although there was not uniform satisfaction with this approach. There are some cases, I think, in which the source IP address of the RADIUS packet might not suffice either. For example, (a) the RADIUS client obtains it's IP address from some local DHCP server, and thus the IP address for this particular RADIUS client varies from time to time, or (b) the RADIUS client is hiding behind a NAT or NAPT gateway, and thus it's apparent IP address is the same as other similarly configured RADIUS clients. These examples may well be considered as improper or unwise network configurations for deploying RADIUS, and I would be among the first to agree. My point is that source IP address is not a panacea for globally unique identification. There may be times in which the NAS-IP-Address could be used to help resolve ambiguities inherent in the source IP address. Given that we are documenting the RADIUS protocol as currently implemented, the best current practice may well be to use the source IP address of the RADIUS request packet to identify the RADIUS client. I think that scheme has some practical configuration limitations, and a better use of the existing RADIUS "identification" attributes, NAS-IP-Address and NAS- Identifier, may be fruitful areas for ongoing research. Perhaps the Roaming Operations WG would have some advice to lend in this regard. > Then they should remove all NAS specific information from the > packet, and replace it with information about the proxy server. > > In fact, if they're using private IP addresses for their NASes, this > requirement should probably be mentioned in the RADIUS RFC as a MUST. > Polluting the global information space with private IP's is a Bad > Thing. > > > In my opinion, issues relating to global uniqueness and a "world of > > proxies" would seem to belong properly to the Roaming Operations > > working group, where I have cc'ed this message. > > When in doubt, avoid the issue by redefining the problem. :) > > If RADIUS proxies don't advertise private IP's from the NASes, we > don't need global uniqueness other than public proxy IP address. The above discussion addresses the RADIUS Proxy Service issues, but does not address the DHCP or NAT examples I have cited. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 12:22:43 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14217 for ; Thu, 25 Feb 1999 12:22:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA10917; Thu, 25 Feb 1999 09:13:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA04717 for ietf-radius-outgoing; Thu, 25 Feb 1999 09:15:23 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF6233@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Richard S. Conto'" , "Dale E. Reed Jr." Cc: ietf-radius@livingston.com, Carl Rigney Subject: RE: (radius) Zero-length strings Date: Thu, 25 Feb 1999 12:12:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Richard S. Conto [mailto:rsc@merit.edu] >And I don't think a NAS should immediately reject a zero (empty) >USER-NAME. That's a policy that should be determined by the >service provider, and should be entirely be between the service >provider and the user. Perhaps CALLING-STATION-ID would sufficiently >identify the user (as far as the service-provider is concerned), or >the combination of NAS-Identifier (or NAS-Ip-Address) and NAS-PORT. You've got it exactly, Richard.. A NAS is properly a Policy Enforcement Point in this scenario, and should not undertake to make such policy decisions as "reject user if username === null". But wait, the above seems to be in the realm of what a NAS SHOULD do, and not what the RADIUS protocol LOOKS like, right? So therefore the only possible choice is to EITHER allow a NAS to send a null attribute, or to allow that it NOT SEND an attribute that is otherwise required by the protocol. So I would say that zero-length attributes are in. + Mark Anthony Beadles + MCI WorldCom + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 12:37:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14419 for ; Thu, 25 Feb 1999 12:37:31 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA11462; Thu, 25 Feb 1999 09:20:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA05814 for ietf-radius-outgoing; Thu, 25 Feb 1999 09:23:39 -0800 (PST) Message-ID: <36D58716.FBBACD41@iea-software.com> Date: Thu, 25 Feb 1999 09:23:34 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Nelson, David" CC: "'Alan DeKok'" , ietf-radius@livingston.com, roamops@tdmx.rutgers.edu Subject: Re: (radius) Re: Globally unique NAS-Identifier (was: Matching NAS-IP-Address to a ctual real-life NAS IP address) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit "Nelson, David" wrote: > > > ...but my original problem was that people were advocating > > the use of NAS-IP-Address as a (potentially globally) unique NAS ID, > > for tracking/database keying purposes. I think such use is incorrect. > > Reasonable arguments have been advanced that the RADIUS attribute > NAS-IP-Address is not sufficient to identify a NAS, for purposes of > looking up it's shared secret, et. al. This has been demonstrated for > the RADIUS Proxy Service case. I think you are missing what he is asking, though. He's not asking about the secret (key), he is asking about a what to define a primary key constraint in an RDBMS. For accounting purposes we use the following combination: NAS-Identifier (either NAS-IP-Address or NAS-Identifier) Acct-Session-ID Acct-Status-Type You can add in NAS-Port and User-Name if you need to make the key more dense, though. > Assertions have been made that the source IP address of the UDP datagram > containing a RADIUS request is the only correct way to identify the NAS, > or more generally the RADIUS client, at least in the most general case. > This was, I believe, the rough consensus that last time this issue was > debated on the RADIUS WG mailing list, although there was not uniform > satisfaction with this approach. Again, this is not what he is talking about. :( -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 12:51:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14614 for ; Thu, 25 Feb 1999 12:51:34 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA12267; Thu, 25 Feb 1999 09:38:29 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA07982 for ietf-radius-outgoing; Thu, 25 Feb 1999 09:41:36 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Thu, 25 Feb 1999 18:35:07 +0200 MR-Received: by mta BTMV98; Relayed; Thu, 25 Feb 1999 18:35:07 +0200 MR-Received: by mta BTMA06; Relayed; Thu, 25 Feb 1999 18:34:33 +0200 Disclose-recipients: prohibited Date: Thu, 25 Feb 1999 18:35:07 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address In-reply-to: <199902242008.PAA00973@cryptocard.ott.igs.net> To: ietf-radius Message-id: <9807351825021999/A44935/BTMV98/11D2CCA30700*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D2CCA30700 X400-MTS-identifier: [;9807351825021999/A44935/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT > Under what circumstances can a RADIUS client put a NAS-IP-Address >attribute inside of a packet, which is different than the IP address >from which the packet is sent? > [...] > Not surprisingly, the vendors response was: > > "Our interpretation of the RFC is that the NAS-IP-Address attribute > does not have to match the IP address of the interface from which > the packet was sent." > > If this interpreation is correct, then there isn't much point in >having a NAS-IP-Address attribute, as the RADIUS server doesn't know, >and doesn't care about other IP addresses the NAS may have. for another vendor's response: we have a radius server that makes a clear distinction between the two: we consider the source ip address when validating the packet source (radius secret). any other functionality (like port reservation per nas, statistics generation,...) is based on the NAS-Id attributes (4 and/or 32). I believe this is exactly the purpose of having the two IPs: being able to ID the NAS independent of where the packet comes from, and being able to validate that the packet comes from a trusted source. It is common for NASses to send their 'system IP' in attr 4, but provide the 'interface IP' as source IP address depending on the outgoing interface. regards, Marc. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:03:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14807 for ; Thu, 25 Feb 1999 13:03:35 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA13996; Thu, 25 Feb 1999 09:56:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA10658 for ietf-radius-outgoing; Thu, 25 Feb 1999 09:59:13 -0800 (PST) Date: Thu, 25 Feb 1999 09:59:10 -0800 (PST) From: Carl Rigney Message-Id: <199902251759.JAA10644@server.livingston.com> To: scrain@shore.net Subject: Re: (radius) Retransmission hints Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney >> If you wanted to use a new Request Authenticator when sending to the >> backup server, you could (and would then have to use a new ID). > >Since its sending to a different server, it wouldn't necessarily need a >new ID. IDs are really (server, source port, ID) 3-tuples, so if you're sending to a new server, its a new ID, even if the content of the ID field in the packet hasn't changed. But that may be confusing to explain. Note that if you use different ID tracks for different servers, then the server MUST use the address you sent to when replying to you. Do we want to make that explicit? Do we want to require that IDs be tracked globally on a NAS, and not per server? At the moment we don't say one way or the other, but this is a subtle enough point that I'd like to provide guidance in the updated draft. People who need to have more than 256 requests outstanding can always open additional source ports so there's no capacity issue either way. I note in passing that hammering a server with 256+ requests back-to-back before it even responds to the first one is hardly very network or server friendly. Thoughts on language concerning global ID vs. per-server ID? -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:04:03 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14818 for ; Thu, 25 Feb 1999 13:04:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA14109; Thu, 25 Feb 1999 09:57:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA10810 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:00:32 -0800 (PST) Message-ID: From: "Nelson, David" To: "'ietf-radius@livingston.com'" Subject: FW: (radius) Re: Globally unique NAS-Identifier (was: Matching N AS-IP-Address to a ctual real-life NAS IP address) Date: Thu, 25 Feb 1999 12:55:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Dale Reed writes... > I think you are missing what he is asking, though. He's not asking > about the secret (key), he is asking about a what to define a primary > key constraint in an RDBMS. Well, I don't think I did misunderstand the topic. Here's Alan's original question: Under what circumstances can a RADIUS client put a NAS-IP-Address attribute inside of a packet, which is different than the IP address from which the packet is sent? I understand that the topic has wandered somewhat along the way. > For accounting purposes we use the following combination: > > NAS-Identifier (either NAS-IP-Address or NAS-Identifier) > Acct-Session-ID > Acct-Status-Type > > You can add in NAS-Port and User-Name if you need to make the key more > dense, though. Your suggestions are certainly relevant to featureful, robust RADIUS server design and implementation. I wonder, however, if they have direct bearing on the RADIUS protocol definition, which is the fodder of this WG. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:06:53 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14872 for ; Thu, 25 Feb 1999 13:06:52 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA14450; Thu, 25 Feb 1999 09:59:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA11135 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:03:09 -0800 (PST) Date: Thu, 25 Feb 1999 10:03:07 -0800 (PST) From: Carl Rigney Message-Id: <199902251803.KAA11127@server.livingston.com> To: daler@iea-software.com Subject: Re: (radius) Zero-length strings Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney > IMHO, forcing broken implementations to get fixed is a GOOD thing. > Adding the ability for something to be interpreted many different ways > is a bad thing. I believe this can't be emphasized enough, and wholeheartedly agree that we want to avoid baroque interpretations - in the real world protocols get implemented by programmers on tight schedules, and we should strive for simplicity wherever feasible. Complicated "magic" interpretations are a sure attractor for interoperability problems. -- Carl Rigney - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:09:06 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14894 for ; Thu, 25 Feb 1999 13:09:05 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA14599; Thu, 25 Feb 1999 10:01:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA11338 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:04:54 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Thu, 25 Feb 1999 18:58:08 +0200 MR-Received: by mta BTMV98; Relayed; Thu, 25 Feb 1999 18:58:16 +0200 MR-Received: by mta BTMA06; Relayed; Thu, 25 Feb 1999 18:57:48 +0200 Disclose-recipients: prohibited Date: Thu, 25 Feb 1999 18:58:08 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) Zero-length strings In-reply-to: <199902242126.NAA29532@server.livingston.com> To: ietf-radius Message-id: <0808581825021999/A45543/BTMV98/11D2CCBA0700*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D2CCBA0700 X400-MTS-identifier: [;0808581825021999/A45543/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT >interoperable. So I want to pin this discrepancy down by either >updating the language from "0-253 octets of data" to "1-253 octets" or >by explicitly describing what to do with a zero length attribute. Changing the 0-253 to 1-253 will not allow future extension to use zero-length attributes. Including text saying zero-length attribs should/must be ignored or smth would also limit future extensions. Currently, zero-length attributes are possible, but none of the standard attributes can be zero-length (len >=3). Including something similar to the above statement _is_ something I think most people can live with? (does not change a thing, only clarifies) >The reference implementation (RADIUS 1.13 from Livingston) didn't allow >zero length attributes; if the protocol is going to be changed to allow >zero length attributes I want to see really strong justification for >their usefulness IN AN INTEROPERABLE MANNER. Post fast, the next >draft's only a couple of days away. I may have missed it, but I doubt the RFC states that Livingston RADIUS 1.13 is to be used as a reference. No matter what history is tied to it, a standard protocol should/must not refer to any particalur vendor implementation, and certainly not one that has already been outdated by that same standard. Many vendors use zero-length strings. It is irrelevant whether or not this breaks Livingston RADIUS or any other implementation. What is relevant is that it does not conform to the standard as it is today. Implementaions that do conform to the current RFC, must not use zero-length strings in the listed attributes, and will be interoperable wrt this issue. So (IMHO), except for some clarifying statement, I do not think any changes to the RFC are required for this. regards, Marc. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:12:46 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14952 for ; Thu, 25 Feb 1999 13:12:39 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA14765; Thu, 25 Feb 1999 10:03:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA11648 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:06:42 -0800 (PST) Date: Thu, 25 Feb 1999 10:06:41 -0800 (PST) From: Carl Rigney Message-Id: <199902251806.KAA11636@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Proxy Snares Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Sorry, I should have asked for input on this previously, instead of at the last moment like this, but I'm very interested in hearing from anyone who's implemented RADIUS proxy about anything they found hard to understand in RFC 2138 and 2139, and especially anything that wasn't stated in the drafts, but whose implications caused them grief in implementation that could have been saved if someone had sad "and don't forget to think about when doing proxy." Email on the topic today would be most helpful, but even if you don't have time now (or are reading this next week due to the list volume :-) ) I'd be very interested in hearing your thoughts. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:17:06 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15043 for ; Thu, 25 Feb 1999 13:16:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA15357; Thu, 25 Feb 1999 10:09:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA12380 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:12:29 -0800 (PST) Date: Thu, 25 Feb 1999 10:12:28 -0800 (PST) From: Carl Rigney Message-Id: <199902251812.KAA12372@server.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney dnelson@cabletron.com says: > The primary purpose of the NAS-IP-Address attribute (or the NAS- > Identifier) is so that the RADIUS server may look up the shared secret > of the NAS. This is exactly wrong. The shared secret MUST be looked up based on the source IP address of the RADIUS packet, not the contents of the packet. Otherwise proxy wouldn't work. I think 2138 was ambiguous on that and we added language to the forthcoming draft to make this (subtle but vital) point. The protocol treats client and NAS interchangeably, but once you're doing proxy then there is a certain special status for the endpoints of the proxy chain; one being a NAS, the other being the final server. -- Carl Rigney - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:24:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15183 for ; Thu, 25 Feb 1999 13:24:51 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA15953; Thu, 25 Feb 1999 10:17:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA13259 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:19:39 -0800 (PST) Date: Thu, 25 Feb 1999 10:19:37 -0800 (PST) From: Carl Rigney Message-Id: <199902251819.KAA13253@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Quoting Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I may have misattributed a quote to David Nelson in my recent message; in which case I apologize for the error in attribution. -- Carl Rigney - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:25:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15201 for ; Thu, 25 Feb 1999 13:25:24 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA15948; Thu, 25 Feb 1999 10:17:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA13086 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:18:17 -0800 (PST) Date: Thu, 25 Feb 1999 13:17:23 -0500 (EST) From: "Steven P. Crain" To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) Retransmission hints In-Reply-To: <199902251759.JAA10644@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Thu, 25 Feb 1999, Carl Rigney wrote: > Thoughts on language concerning global ID vs. per-server ID? The issue of how a client interacts with many servers seems marginal. The purpose of the ID field is to allow a single client/server pair to keep track of which reply is to which request. What IDs the client uses with other servers should not matter as far as the RADIUS protocol is concerned. So, I would press for per-server IDs being acceptible. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net, An ISP with Excellence in the Greater Boston Area. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:31:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15369 for ; Thu, 25 Feb 1999 13:31:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA16382; Thu, 25 Feb 1999 10:24:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA14246 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:27:28 -0800 (PST) Date: Thu, 25 Feb 1999 10:27:25 -0800 (PST) From: Carl Rigney Message-Id: <199902251827.KAA14235@server.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney > As for NAS-Identifier, I haven't seen many implementations actually > use it. Would it be desirable to have the RFC suggest a method for > generating a *unique* per-NAS identifier? (I won't do so here.) NAS configuration is outside the scope of the RADIUS working group's charter. (Sorry, it just wouldn't feel like a real WG discussion if I didn't get to say that at least once. :-) ) Probably the admin just sets some string which is then returned in the NAS-Identifier. Tastes will vary; simplest would be to use hostname, or shelf number, or serial number of the box, but it could also be a geographical indicator, or whatever. As far as the protocol is concerned its just a string that it passes along if it has it. Its useful to log, but doesn't affect the operation of the protocol. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:31:57 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15400 for ; Thu, 25 Feb 1999 13:31:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA16386; Thu, 25 Feb 1999 10:24:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA14291 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:27:44 -0800 (PST) From: "Heath Partington" To: "Carl Rigney" , Cc: Subject: RE: (radius) Retransmission hints Date: Thu, 25 Feb 1999 13:25:51 -0500 Message-ID: <001001be60ec$45cca360$da047392@hpartington.hq.springtidenet.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <199902251759.JAA10644@server.livingston.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Heath Partington" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-radius@livingston.com > [mailto:owner-ietf-radius@livingston.com]On Behalf Of Carl Rigney > Sent: Thursday, February 25, 1999 12:59 PM > To: scrain@shore.net > Cc: ietf-radius@livingston.com > Subject: Re: (radius) Retransmission hints > > > >> If you wanted to use a new Request Authenticator when > sending to the > >> backup server, you could (and would then have to use a new ID). > > > >Since its sending to a different server, it wouldn't > necessarily need a > >new ID. > > IDs are really (server, source port, ID) 3-tuples, so if > you're sending to > a new server, its a new ID, even if the content of the ID > field in the packet > hasn't changed. But that may be confusing to explain. > > Note that if you use different ID tracks for different > servers, then the > server MUST use the address you sent to when replying to you. > Do we want > to make that explicit? > > Do we want to require that IDs be tracked globally on a NAS, > and not per > server? At the moment we don't say one way or the other, but > this is a subtle > enough point that I'd like to provide guidance in the updated draft. > > People who need to have more than 256 requests outstanding can always > open additional source ports so there's no capacity issue either way. > I note in passing that hammering a server with 256+ requests > back-to-back before it even responds to the first one is hardly very > network or server friendly. My implementation currently tracks ids on a per server basis. Is there a reason why a server would respond using a different address then the one the client sent to? I personally would not like to see the restriction that ids cannot be kept per server as I have already implemented it that way. One benefit of keeping the ids per server is to prohibit the last case you talk about where you bomb a single server with more than 255 requests. Of course I guess you could keep track of this separately... > > Thoughts on language concerning global ID vs. per-server ID? > > -- > Carl Rigney > cdr@livingston.com > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:43:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16079 for ; Thu, 25 Feb 1999 13:43:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA16854; Thu, 25 Feb 1999 10:35:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA15435 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:38:12 -0800 (PST) Date: Thu, 25 Feb 1999 10:38:10 -0800 (PST) From: Carl Rigney Message-Id: <199902251838.KAA15427@server.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Aydin Edguer writes: > 5.32. NAS-Identifier > The String field is one or more octets, and should be unique to > the NAS within the scope of the RADIUS server. > > 5.4. NAS-IP-Address > This Attribute indicates the identifying IP Address of the NAS > which is requesting authentication of the user. > >If the NAS-IP-Address is not unique then it would not be "the identifying >IP Address". Explicit text can be added to the NAS-IP-Address to make >this as clear as it is for NAS-Identifier (if necessary). Excellent idea. How about this for NAS-IP-Address: This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user, and should be unique to the NAS within the scope of the RADIUS server. Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request, the source IP address of the access-request MUST be used. NAS-IP-Address is only used in Access-Request packets. Either NAS-IP-Address or NAS-Identifier MUST be present in an Access-Request packet. I'll add a similar disclaimer to NAS-Identifier. The new draft mentions this elsewhere as well, but its an extremely important point and thus useful to spend a couple of extra lines on. And to people thinking "Isn't this delving into trivia" I would say that this is exactly the kind of thing we should catch and document before going to draft standard. Many thanks to all the respondents so far. -- Carl Rigney - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:43:35 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16091 for ; Thu, 25 Feb 1999 13:43:35 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA16970; Thu, 25 Feb 1999 10:35:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA15552 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:39:06 -0800 (PST) Date: Thu, 25 Feb 1999 13:38:12 -0500 (EST) From: "Steven P. Crain" To: Heath Partington cc: Carl Rigney , ietf-radius@livingston.com Subject: RE: (radius) Retransmission hints In-Reply-To: <001001be60ec$45cca360$da047392@hpartington.hq.springtidenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Thu, 25 Feb 1999, Heath Partington wrote: > My implementation currently tracks ids on a per server basis. Is there a > reason why a server would respond using a different address then the one the > client sent to? Yes, on a multi-homed machine the response could come from any of the interfaces. The radius server needs special code to be able to make sure its response comes from the same interface that received the request. Many server implemenations simply bind to any incoming IP address, which would not interoperate correctly with your client if the server was run on a machine with more than one interface. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:51:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16540 for ; Thu, 25 Feb 1999 13:51:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA17129; Thu, 25 Feb 1999 10:39:29 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA15936 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:42:25 -0800 (PST) Date: Thu, 25 Feb 1999 10:42:21 -0800 (PST) From: Carl Rigney Message-Id: <199902251842.KAA15919@server.livingston.com> To: alan@cryptocard.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I think NAS-IP-Address should be a unique identifier. If a RADIUS proxy wants to muck around with attributes to pretend it only has one NAS, that's within its rights, but let's hope the proxy writer also does the right thing with NAS-Port too, in that case. And if the Proxy wants to hide NAS IP addresses, it would be better to remove the NAS-IP-Address and insert a NAS-Identifier, but that seems to fall squarely into the field of implementation decisions, which the RFC should stay clear of dictating. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:53:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16561 for ; Thu, 25 Feb 1999 13:53:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA17393; Thu, 25 Feb 1999 10:46:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA16815 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:49:53 -0800 (PST) Date: Thu, 25 Feb 1999 13:51:59 -0500 (EST) From: "Steven P. Crain" To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) Proxy Snares In-Reply-To: <199902251806.KAA11636@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Thu, 25 Feb 1999, Carl Rigney wrote: > Sorry, I should have asked for input on this previously, instead of at > the last moment like this, but I'm very interested in hearing from > anyone who's implemented RADIUS proxy about anything they found hard to > understand in RFC 2138 and 2139, and especially anything that wasn't > stated in the drafts, but whose implications caused them grief in > implementation that could have been saved if someone had sad "and don't > forget to think about when doing proxy." > > Email on the topic today would be most helpful, but even if you don't have > time now (or are reading this next week due to the list volume :-) ) I'd > be very interested in hearing your thoughts. I haven't implemented RADIUS proxy, but I would like to respond as a user of a proxy implementation. We have had difficulty in providing roaming services to other companies because many of the proxy implementations do not provide a mechanism for controlling what attributes/values can be present in responses they relay to the client. With many proxies, they would happily pass Framed-IP-Address = 149.198.247.6 and then noone would locally be able to get to www.livingston.com :-! I recommend language something like "Proxy implementations SHOULD exercize reasonable administrative control over responses they relay." -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 13:54:12 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16575 for ; Thu, 25 Feb 1999 13:54:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA17460; Thu, 25 Feb 1999 10:46:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA16857 for ietf-radius-outgoing; Thu, 25 Feb 1999 10:50:12 -0800 (PST) Date: Thu, 25 Feb 1999 10:50:10 -0800 (PST) From: Carl Rigney Message-Id: <199902251850.KAA16849@server.livingston.com> To: Pat.Calhoun@eng.sun.com Subject: Re: (radius) Globally unique NAS-Identifier (was: Matching NAS-IP-Address to a ctual real-life NAS IP address) Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney > If the language to the NAS Identifier is changed to insist that it is > the NASes FQDN, then it should be guaranteed to be unique. NAS-Identifier states: The String field is one or more octets, and should be unique to the NAS within the scope of the RADIUS server. For example, a fully qualified domain name would be suitable as a NAS-Identifier. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets. So it mentions FQDN as a good choice, but lets people choose other things if it makes more sense in their situation. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 14:07:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16821 for ; Thu, 25 Feb 1999 14:07:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA18294; Thu, 25 Feb 1999 10:59:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA18716 for ietf-radius-outgoing; Thu, 25 Feb 1999 11:03:00 -0800 (PST) Message-Id: <3.0.5.32.19990225105233.00923840@gump.eng.ascend.com> X-Sender: igoyret@gump.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 25 Feb 1999 10:52:33 -0800 To: Carl Rigney From: Ignacio Goyret Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address Cc: ietf-radius@livingston.com In-Reply-To: <199902251838.KAA15427@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret At 10:38 AM 2/25/99 -0800, Carl Rigney wrote: > > NAS-IP-Address is only used in > Access-Request packets. Either NAS-IP-Address or NAS-Identifier MUST > be present in an Access-Request packet. What about Accounting-Request? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 14:11:30 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16889 for ; Thu, 25 Feb 1999 14:11:29 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA18601; Thu, 25 Feb 1999 11:03:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA19130 for ietf-radius-outgoing; Thu, 25 Feb 1999 11:06:28 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Carl Rigney'" , ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Thu, 25 Feb 1999 14:02:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Carl Rigney writes... > Excellent idea. How about this for NAS-IP-Address: > > This Attribute indicates the identifying IP Address of the > NAS which is requesting authentication of the user, and > should be unique to the NAS within the scope of the RADIUS > server. Note that NAS-IP-Address MUST NOT be used to select > the shared secret used to authenticate the request, the > source IP address of the access-request MUST be used. To this I would recommend adding an operational note, to the effect of the following: The source IP address of the access-request packet MUST be known to the RADIUS server, possibly precluding network configurations in which the source IP address is variable (e.g. assigned by DHCP) or not unique (e.g. that of a NAT proxy server). Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 14:27:24 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17155 for ; Thu, 25 Feb 1999 14:27:23 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA19350; Thu, 25 Feb 1999 11:20:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA21024 for ietf-radius-outgoing; Thu, 25 Feb 1999 11:22:54 -0800 (PST) Date: Thu, 25 Feb 1999 11:22:52 -0800 (PST) From: Carl Rigney Message-Id: <199902251922.LAA21015@server.livingston.com> To: dnelson@cabletron.com Subject: Re: FW: (radius) Re: Globally unique NAS-Identifier (was: Matching N AS-IP-Address to a ctual real-life NAS IP address) Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I agree that the RADIUS protocol doesn't care about what's used as a key into the accounting database. Once its delivered the accounting information; it no longer cares what happens to it. :-) -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 14:27:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17165 for ; Thu, 25 Feb 1999 14:27:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA19023; Thu, 25 Feb 1999 11:13:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA20307 for ietf-radius-outgoing; Thu, 25 Feb 1999 11:16:38 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF6239@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Carl Rigney'" , ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Thu, 25 Feb 1999 14:14:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Carl Rigney [mailto:cdr@livingston.com] >Excellent idea. How about this for NAS-IP-Address: > > This Attribute indicates the identifying IP Address of the NAS which is > requesting authentication of the user, and should be unique to the NAS > within the scope of the RADIUS server. Note that NAS-IP-Address MUST > NOT be used to select the shared secret used to authenticate the > request, the source IP address of the access-request MUST be used. This looks right on. + Mark Anthony Beadles + MCI WorldCom + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 14:27:30 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17176 for ; Thu, 25 Feb 1999 14:27:29 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA19355; Thu, 25 Feb 1999 11:20:05 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA21085 for ietf-radius-outgoing; Thu, 25 Feb 1999 11:23:10 -0800 (PST) Message-Id: <199902251923.OAA06127@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) Retransmission hints In-reply-to: Your message of "Thu, 25 Feb 1999 09:59:10 PST." <199902251759.JAA10644@server.livingston.com> Date: Thu, 25 Feb 1999 14:23:17 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok Carl Rigney wrote: > > IDs are really (server, source port, ID) 3-tuples, Let me start another firestorm by saying I almost disagree. Say you've got a server which uniquely identifies requests based on the client, source port, ID, and request code. The clients use the same source port for all messages (as do most clients I've seen). The server keeps track of the requests for a period of time, X, in order to detect duplicate requests from the NAS. After that time, the server deletes the remembered requests/replies from it's cache. When the server is under heavy load from a client: 200+ requests per second, where X is ~5s. This server will then: - send 256 replies to 256 client requests. - ignore "duplicate" requests with the same client, source port, ID, and request code. (Or send "duplicate" replies, the effect is the same) - after the timeout period X has passed, it will start replying to requests again. The net effect is that authentication becomes "bursty". Lots of people get authenticated, then more people wait a long time, then more people get authenticated again. The only solution I could think of was to use the Request Authenticator as part of the unique request identifier. My reasoning goes like this: IF the client is sending another request with the same code, ID, and source port, it MUST either be a duplicate request, or a new request. IF it's a duplicate request, then the Request Authenticator MUST be the same. IF it's a new request, then the Request Authenticator MUST be different. IF it's a new request, then the client must have received the old reply, and the server can throw away its saved copy of the old request. With these modifications, a server can do 256 requests per second, with *all* requests having ID=0. This gets rids of the "bursty" problem, and flattens the response time. > Note that if you use different ID tracks for different servers, then the > server MUST use the address you sent to when replying to you. Do we want > to make that explicit? Yes. > Do we want to require that IDs be tracked globally on a NAS, and not > per server? At the moment we don't say one way or the other, but > this is a subtle enough point that I'd like to provide guidance in > the updated draft. ID's SHOULD be tracked per server. If ID's are tracked globally, we run into the "pseudo duplicate" problem above even more quickly. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 14:38:45 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17407 for ; Thu, 25 Feb 1999 14:38:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA20047; Thu, 25 Feb 1999 11:31:05 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA22505 for ietf-radius-outgoing; Thu, 25 Feb 1999 11:34:11 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF623B@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Nelson, David'" , ietf-radius@livingston.com, "'Carl Rigney'" Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Thu, 25 Feb 1999 14:30:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Nelson, David [mailto:dnelson@cabletron.com] >The source IP address of the access-request packet MUST be known >to the RADIUS server, possibly precluding network configurations >in which the source IP address is variable (e.g. assigned by DHCP) >or not unique (e.g. that of a NAT proxy server). I don't think that this text belongs in the description of NAS-IP-Address, since we have already established that this attribute is not used for shared secret checking. It may be appropriate to put this text somewhere else, like in the security considerations. I would also note as a nit that just because an address is assigned by DHCP does not mean it is variable. + Mark Anthony Beadles + MCI WorldCom + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 14:40:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17436 for ; Thu, 25 Feb 1999 14:40:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA20217; Thu, 25 Feb 1999 11:33:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA22812 for ietf-radius-outgoing; Thu, 25 Feb 1999 11:36:55 -0800 (PST) Message-Id: <199902251937.OAA06194@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address In-reply-to: Your message of "Thu, 25 Feb 1999 10:42:21 PST." <199902251842.KAA15919@server.livingston.com> Date: Thu, 25 Feb 1999 14:37:05 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok Carl Rigney wrote: > I think NAS-IP-Address should be a unique identifier. I agree. It should be a "MUST" requirement in the RFC. However, there should also be a sentence enhancing awareness of private IP's. Something like: Implementors of RADIUS proxy servers should be aware of the problems associated with ensuring uniqueness while proxying a NAS-IP-Address containing an IP address from a private network. That doesn't dictate implementation, but it does make people aware of the issue. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 15:17:10 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18219 for ; Thu, 25 Feb 1999 15:17:09 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA21742; Thu, 25 Feb 1999 12:09:27 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA26119 for ietf-radius-outgoing; Thu, 25 Feb 1999 12:11:02 -0800 (PST) Message-ID: From: Paul Raison To: ietf-radius@livingston.com Subject: RE: (radius) IDs Date: Thu, 25 Feb 1999 15:10:18 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1457.3) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Raison A corresponding question is how does the client "know" when it is safe to re-use an identifier (please see inline comment below). > -----Original Message----- > From: Alan DeKok [SMTP:alan@cryptocard.com] > Sent: Thursday, February 25, 1999 2:23 PM > To: ietf-radius@livingston.com > Subject: Re: (radius) Retransmission hints > > Carl Rigney wrote: > > > > IDs are really (server, source port, ID) 3-tuples, > > Let me start another firestorm by saying I almost disagree. > > Say you've got a server which uniquely identifies requests based on > the client, source port, ID, and request code. The clients use the > same source port for all messages (as do most clients I've seen). > > The server keeps track of the requests for a period of time, X, in > order to detect duplicate requests from the NAS. After that time, the > server deletes the remembered requests/replies from it's cache. > > When the server is under heavy load from a client: 200+ requests per > second, where X is ~5s. This server will then: > > New devices are emerging that are terminating multiple T3 or OC12 > (and more) ports which brings the likelihood of 200+ current requests > into reality > > - send 256 replies to 256 client requests. > > - ignore "duplicate" requests with the same client, source port, ID, > and request code. (Or send "duplicate" replies, the effect is the > same) > > In the case of sending "duplicate" replies, does the Server > (inadvertently) > authenticate a new set of users without going to the database? > > - after the timeout period X has passed, it will start replying to > requests again. > > > The net effect is that authentication becomes "bursty". Lots of > people get authenticated, then more people wait a long time, then more > people get authenticated again. > > The only solution I could think of was to use the Request > Authenticator as part of the unique request identifier. My reasoning > goes like this: > > IF the client is sending another request with the same code, ID, and > source port, it MUST either be a duplicate request, or a new request. > > IF it's a duplicate request, then the Request Authenticator MUST be > the same. > > IF it's a new request, then the Request Authenticator MUST be > different. > > IF it's a new request, then the client must have received the old > reply, and the server can throw away its saved copy of the old > request. > > > With these modifications, a server can do 256 requests per second, > with *all* requests having ID=0. This gets rids of the "bursty" > problem, and flattens the response time. > > > Note that if you use different ID tracks for different servers, then > the > > server MUST use the address you sent to when replying to you. Do we > want > > to make that explicit? > > Yes. > > > Do we want to require that IDs be tracked globally on a NAS, and not > > per server? At the moment we don't say one way or the other, but > > this is a subtle enough point that I'd like to provide guidance in > > the updated draft. > > ID's SHOULD be tracked per server. > > If ID's are tracked globally, we run into the "pseudo duplicate" > problem above even more quickly. > > Alan DeKok. > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 15:24:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18300 for ; Thu, 25 Feb 1999 15:24:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA22222; Thu, 25 Feb 1999 12:17:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA27132 for ietf-radius-outgoing; Thu, 25 Feb 1999 12:20:50 -0800 (PST) From: "Heath Partington" To: "Steven P. Crain" Cc: "Carl Rigney" , Subject: RE: (radius) Retransmission hints Date: Thu, 25 Feb 1999 15:20:00 -0500 Message-ID: <001301be60fc$387465d0$da047392@hpartington.hq.springtidenet.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Heath Partington" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-radius@livingston.com > [mailto:owner-ietf-radius@livingston.com]On Behalf Of Steven P. Crain > Sent: Thursday, February 25, 1999 1:38 PM > To: Heath Partington > Cc: Carl Rigney; ietf-radius@livingston.com > Subject: RE: (radius) Retransmission hints > > > On Thu, 25 Feb 1999, Heath Partington wrote: > > > My implementation currently tracks ids on a per server > basis. Is there a > > reason why a server would respond using a different address > then the one the > > client sent to? > > Yes, on a multi-homed machine the response could come from any of the > interfaces. The radius server needs special code to be able > to make sure > its response comes from the same interface that received the request. > > Many server implemenations simply bind to any incoming IP > address, which > would not interoperate correctly with your client if the > server was run on > a machine with more than one interface. So the assumption here is that the server is listening on the same port for all of these interfaces? Shouldn't a multi-homed server have to put this extra code in to insure that the return address is the same as the one it received the request on? > > -- > Steven P. Crain, Development > http://www.shore.net/~scrain > Shore.Net: Local Ties... World Class Connections > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 15:39:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18651 for ; Thu, 25 Feb 1999 15:39:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA22739; Thu, 25 Feb 1999 12:30:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA28659 for ietf-radius-outgoing; Thu, 25 Feb 1999 12:33:16 -0800 (PST) Date: Thu, 25 Feb 1999 12:33:14 -0800 (PST) From: Carl Rigney Message-Id: <199902252033.MAA28652@server.livingston.com> To: praison@redstonecom.com Subject: RE: (radius) IDs Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney > In the case of sending "duplicate" replies, does the Server > (inadvertently) authenticate a new set of users without going to the database? That can't happen, because the Response Authenticator in the reply is based on Request Authenticator, so if the response gets mixed up, it'll be rejected as invalid, and the request will be retransmitted. RADIUS servers that want to serve really huge NASes (100,000 ports) or with very bursty traffic would be wise to check the request authenticator when weeding out duplicates. Someday I'd like to see a good informational RFC discussing RADIUS timers in depth; for the moment such things are left to the inventiveness of implementers. -- Carl Rigney cdr@livingston.com "I think the essense of reliable protocol design is getting the timers right. If you do, the protocol will probably work & scale (though there may be lots of things you'll have to tweak to get good performance). If you botch the timers, the protocol is guaranteed to fall apart at some scale (but, unfortunately, people are very bad about anticipating the effects of scale & a lot of these bench-top grad student projects end up escaping & causing no end of suffering for their users before they die)." -- Van Jacobson, 96/7/18 talking about something else entirely - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:01:24 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19314 for ; Thu, 25 Feb 1999 16:01:23 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA23951; Thu, 25 Feb 1999 12:53:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA01320 for ietf-radius-outgoing; Thu, 25 Feb 1999 12:56:53 -0800 (PST) Message-ID: <36D5B8FC.7036E817@iea-software.com> Date: Thu, 25 Feb 1999 12:56:28 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Richard S. Conto" CC: ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings References: <199902251555.KAA06881@merit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit "Richard S. Conto" wrote: > > I can suggest several reasons, such as being used as a placeholder, > or to be part of some more complicated, multi-pass authentication > policy enforced by the NAS. Can someone come up with a clear reason why having an AVP length of two is ANY diffrent than not including the attribute? Thats all I'm trying to get at. I will not accept the definition of a default, because a default is an ambiguity that we are trying to avoid and should be a defined value for the attribute, not an empty string. I'm very accepting of a reason, but I don't like "just because". > And I don't think a NAS should immediately reject a zero (empty) > USER-NAME. That's a policy that should be determined by the > service provider, and should be entirely be between the service > provider and the user. Perhaps CALLING-STATION-ID would sufficiently > identify the user (as far as the service-provider is concerned), or > the combination of NAS-Identifier (or NAS-Ip-Address) and NAS-PORT. I agree that this is a NAS configuration issue. Do you allow blank passwords as well? > >Because there are broken or current implementations that send > >a AVP length of two, doesn't mean that the RFC has to accept > >or allow it. The purpose of this update that Carl is working > >on is to clarify the implementation rules and clean up problems. > >This is one I brought up over a year ago and am excited about > >getting cleaned up. > > I think you need to justify why an empty string should be explicitly > disallowed. An empty string (in most cases) is no different than > any other invalid value, such as a mal-formed FRAMED-ROUTE. If the > RADIUS server wants to disallow it, that's fine. > ... Because I think an empty string is the same as not sending the attribute. An invalid value is NOT the same as not including a value at all. > Missing data really is different than default (or zero) data. This is dependant on the implementation. For example, if I don't send a Framed-Address to a client, most will assign an address. Is that considered the default? What will happen if I send an AVP length of two for a Framed-Address? I think missing data in most cases tells the NAS to use the default. For a server, if we receive a NAS-Port-Type with an AVP length of 2, is that considered an Async call? There is no default and the attribute should never have been sent in the first place. > And making a special case that an empty string should be > represented as a one octet string with the value '\0' goes > contrary to the spirit of your previous arguments against > special cases (and only makes sense to a programmer who > things that C-strings are undistinguished octets.) I wasn't making a special case. I was just saying that I could live with an avp length of three with some "blank" single octet (regardless what it was) but I don't like an AVP len of two. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:08:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19589 for ; Thu, 25 Feb 1999 16:08:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA24338; Thu, 25 Feb 1999 13:02:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA02281 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:05:26 -0800 (PST) Date: Thu, 25 Feb 1999 13:05:25 -0800 (PST) From: Carl Rigney Message-Id: <199902252105.NAA02269@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Closing loopholes Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney As though I haven't generated enough traffic already... Without passing any value judgements, I'd like to hear from any implementers who have run into problems interoperating as a result of people misreading or missingg anything in RFC 2138 and 2139 (and especially any cases of willful misinterpretation due to poor phrasing on the author's part), or making assumptions not supported by actual chapter or verse. There's no need to mention again anything mentiond on the list in the last week, and feel free to omit names, but I want to nail down all the fuzzy points I can hear of so that when this goes to Draft Standard, there can be no more finger-pointing or blame-escaping by the unrighteous. Note that if someone just hasn't implemented something, I don't need to hear that. I'm just looking for cases where interoperability has slipped through the cracks in the language. Again, no names needed; I'm looking for ways to improve the draft, not finger pointing. And no need to tell me anything that's been mentioned in the last week; that's all covered or will be within a few hours. Feel free to email me privately if you prefer, or raise it on the list, but I'd like to hear it today if at all possible. If you can't get to it today, I'd appreciate hearing about it eventually anyway, but today or tonight would be best. -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:09:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19620 for ; Thu, 25 Feb 1999 16:09:19 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA24441; Thu, 25 Feb 1999 13:02:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA02343 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:05:54 -0800 (PST) Message-ID: <36D5BB2A.CAAF4CDB@iea-software.com> Date: Thu, 25 Feb 1999 13:05:46 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MARC DE VRIES WE41/KT CC: ietf-radius Subject: Re: (radius) Zero-length strings References: <0808581825021999/A45543/BTMV98/11D2CCBA0700*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit MARC DE VRIES WE41/KT wrote: > > >interoperable. So I want to pin this discrepancy down by either > >updating the language from "0-253 octets of data" to "1-253 octets" or > >by explicitly describing what to do with a zero length attribute. > > Changing the 0-253 to 1-253 will not allow future extension to use zero-length > attributes. RADIUS is based on Attribute-Value pairs. Now we are trying to say its ok to remove the Value from AVP? An attribute that doesn't have atleast two values, doesn't really qualify for an attribute, IMHO. An attribute must have atleast two possible values, and as a result not sending a value introduces ambiguity in the interpretation. > Including text saying zero-length attribs should/must be ignored or smth would > also limit future extensions. This is only for the standard attributes. Vendor Specific attributes are not limited by this. > Currently, zero-length attributes are possible, but none of the standard > attributes can be zero-length (len >=3). That isn't a consensus, and many vendors today don't follow that (the second part). > Including something similar to the above statement _is_ something I think most > people can live with? (does not change a thing, only clarifies) At the minimum, I would like to see that clairified. > Many vendors use zero-length strings. It is irrelevant whether or not this > breaks Livingston RADIUS or any other implementation. What is relevant is that > it does not conform to the standard as it is today. I agree with this. > Implementaions that do conform to the current RFC, must not use zero-length > strings in the listed attributes, and will be interoperable wrt this issue. So > (IMHO), except for some clarifying statement, I do not think any changes to the > RFC are required for this. Can anyone come up with an attribute were an AVP len of two is useful? -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:16:07 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19868 for ; Thu, 25 Feb 1999 16:16:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA24869; Thu, 25 Feb 1999 13:09:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA03051 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:12:26 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Thu, 25 Feb 1999 13:04:12 -0800 (PST) From: Glen Zorn To: "Beadles, Mark A." cc: "'Richard S. Conto'" , "Dale E. Reed Jr." , ietf-radius@livingston.com, Carl Rigney Subject: RE: (radius) Zero-length strings In-Reply-To: <9A74C89D6696D2118E500008C7BA7C56BF6233@wcomexch1.wcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Thu, 25 Feb 1999, Beadles, Mark A. wrote: > From: Richard S. Conto [mailto:rsc@merit.edu] > >And I don't think a NAS should immediately reject a zero (empty) > >USER-NAME. That's a policy that should be determined by the > >service provider, and should be entirely be between the service > >provider and the user. Perhaps CALLING-STATION-ID would sufficiently > >identify the user (as far as the service-provider is concerned), or > >the combination of NAS-Identifier (or NAS-Ip-Address) and NAS-PORT. Which begs the question "Why are you sending a User-Name at all?". > > You've got it exactly, Richard.. A NAS is properly a Policy Enforcement > Point in this scenario, and should not undertake to make such policy > decisions as "reject user if username === null". > > But wait, the above seems to be in the realm of what a NAS SHOULD do, > and not what the RADIUS protocol LOOKS like, right? So therefore the only > possible choice is to EITHER allow a NAS to send a null attribute, or to > allow that it NOT SEND an attribute that is otherwise required by the > protocol. So I would say that zero-length attributes are in. I disagree. Given a choice between a bad hack to work around a protocol deficiency and fixing the protocol, I'd pick the latter every time. > > + Mark Anthony Beadles + MCI WorldCom + > + mbeadles@wcom.net + http://www.wcom.net + > + Voice 614.723.1941 + Fax 614.723.8407 + > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:16:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19894 for ; Thu, 25 Feb 1999 16:16:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA24867; Thu, 25 Feb 1999 13:09:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA03041 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:12:22 -0800 (PST) Date: Thu, 25 Feb 1999 16:12:10 -0500 (EST) From: "Steven P. Crain" To: "Dale E. Reed Jr." cc: "Richard S. Conto" , ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings In-Reply-To: <36D5B8FC.7036E817@iea-software.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Thu, 25 Feb 1999, Dale E. Reed Jr. wrote: > > And I don't think a NAS should immediately reject a zero (empty) > > USER-NAME. That's a policy that should be determined by the > > service provider, and should be entirely be between the service > > provider and the user. Perhaps CALLING-STATION-ID would sufficiently > > identify the user (as far as the service-provider is concerned), or > > the combination of NAS-Identifier (or NAS-Ip-Address) and NAS-PORT. > > I agree that this is a NAS configuration issue. Do you allow > blank passwords as well? I imagine a blank username would have a blank password to go with it. > For example, if I don't send a Framed-Address to a client, > most will assign an address. Is that considered the default? > What will happen if I send an AVP length of two for a Framed-Address? > I think missing data in most cases tells the NAS to use the default. > > For a server, if we receive a NAS-Port-Type with an AVP length > of 2, is that considered an Async call? There is no default and > the attribute should never have been sent in the first place. I wouldn't think AVP length 2 would be allowed for either of these examples. > > And making a special case that an empty string should be > > represented as a one octet string with the value '\0' goes > > contrary to the spirit of your previous arguments against > > special cases (and only makes sense to a programmer who > > things that C-strings are undistinguished octets.) > > I wasn't making a special case. I was just saying that I > could live with an avp length of three with some "blank" single > octet (regardless what it was) but I don't like an AVP len of > two. But an AVP length of 2 is the natural way to specify an octet array of length 0, and one of length 3 with a special character is the natural way to denote a single octet with that value. I realize that you are not recommending your proposal, but I can't see why you would prefer it over allowing the natural denotion of a zero length octet array. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:26:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20311 for ; Thu, 25 Feb 1999 16:26:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA25304; Thu, 25 Feb 1999 13:19:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA04120 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:22:43 -0800 (PST) Message-ID: From: "Varghese, Joe" To: ietf-radius@livingston.com Subject: RE: (radius) Zero-length strings Date: Thu, 25 Feb 1999 15:19:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Varghese, Joe" > > Which begs the question "Why are you sending a User-Name at all?". > Answer: Because the User-Name *must* be present in the Auth-Request. Comment: All the arguments for a null User-Name can also be made for the User-Password or CHAP-Password attribute. If the protocol demands a certain attribute, shouldn't it contain a provision for implementations which dont use it at all (i.e., a zero length string)? Of course, the argument could be made that if an implementation is not using the User-Name as stated, then it's not RADIUS but a RADIUS flavor. This does limit the flexibility of the protocol, though. -------------------------------- George (Joe) Varghese varghese@lucent.com (630) 713-9522 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:29:02 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20412 for ; Thu, 25 Feb 1999 16:29:02 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA25461; Thu, 25 Feb 1999 13:22:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA04396 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:25:23 -0800 (PST) Date: Thu, 25 Feb 1999 16:25:13 -0500 (EST) From: "Steven P. Crain" To: "Dale E. Reed Jr." cc: MARC DE VRIES WE41/KT , ietf-radius Subject: Re: (radius) Zero-length strings In-Reply-To: <36D5BB2A.CAAF4CDB@iea-software.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Thu, 25 Feb 1999, Dale E. Reed Jr. wrote: > RADIUS is based on Attribute-Value pairs. Now we are trying to say > its ok to remove the Value from AVP? An attribute that doesn't have > atleast two values, doesn't really qualify for an attribute, IMHO. > An attribute must have atleast two possible values, and as a result > not sending a value introduces ambiguity in the interpretation. If sending a zero-length value were "not sending a value" then I wouls aggree. But "" is a value, just the ultimate short value. And the attribute can still take any number of other values. (Pardon the "" shorthand.) I don't think there should be any special significance for "". It should not be treated the same as the attribute being ommitted, but only as a diminutive case of a string. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:33:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20616 for ; Thu, 25 Feb 1999 16:33:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA25641; Thu, 25 Feb 1999 13:26:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA04839 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:29:37 -0800 (PST) Message-ID: <36D5C0B8.128EF4B5@iea-software.com> Date: Thu, 25 Feb 1999 13:29:28 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Steven P. Crain" CC: "Richard S. Conto" , ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit "Steven P. Crain" wrote: > > > > And making a special case that an empty string should be > > > represented as a one octet string with the value '\0' goes > > > contrary to the spirit of your previous arguments against > > > special cases (and only makes sense to a programmer who > > > things that C-strings are undistinguished octets.) > > > > I wasn't making a special case. I was just saying that I > > could live with an avp length of three with some "blank" single > > octet (regardless what it was) but I don't like an AVP len of > > two. > > But an AVP length of 2 is the natural way to specify an octet array of > length 0, and one of length 3 with a special character is the natural way > to denote a single octet with that value. I realize that you are not > recommending your proposal, but I can't see why you would prefer it over > allowing the natural denotion of a zero length octet array. But why include it at all? My main complaint is that you shouldn't specify an attribute if you don't also specify a value for it. An Octet array of zero is no specified value, which just leads to an interpretation problem of what is trying to be sent. For those cases like state that are not supposed to be interpreted, I have to ask what is the server doing with the octet array of zero, besides just ignoring it (which is further proof it shouldn't have been in the request). Is there any implementation that actually USES an AVP Length of two that is receives for something and doesn't just ignore it? -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:35:24 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20714 for ; Thu, 25 Feb 1999 16:35:24 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA25797; Thu, 25 Feb 1999 13:27:47 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA05030 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:31:07 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF6240@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Glen Zorn'" Cc: "'Richard S. Conto'" , "Dale E. Reed Jr." , ietf-radius@livingston.com, Carl Rigney Subject: RE: (radius) Zero-length strings Date: Thu, 25 Feb 1999 16:27:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Glen Zorn [mailto:gwz@acm.org] >So therefore the only >> possible choice is to EITHER allow a NAS to send a null attribute, or to >> allow that it NOT SEND an attribute that is otherwise required by the >> protocol. So I would say that zero-length attributes are in. > >I disagree. Given a choice between a bad hack to work around a protocol >deficiency and fixing the protocol, I'd pick the latter every time. OK, fine, I'm easy. Therefore the protocol must allow packets that do not contain User-Name and User-Password attributes, if the user sends empty strings to the NAS. I'm just saying you can't have it both ways; we can't design the protocol so that the NAS has to decide policy. + Mark Anthony Beadles + MCI WorldCom + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:39:02 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20818 for ; Thu, 25 Feb 1999 16:39:02 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA25943; Thu, 25 Feb 1999 13:30:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA05310 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:33:49 -0800 (PST) Message-ID: <36D5C1B5.5DCF3875@iea-software.com> Date: Thu, 25 Feb 1999 13:33:41 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Steven P. Crain" CC: ietf-radius Subject: Re: (radius) Zero-length strings References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit "Steven P. Crain" wrote: > > > RADIUS is based on Attribute-Value pairs. Now we are trying to say > > its ok to remove the Value from AVP? An attribute that doesn't have > > atleast two values, doesn't really qualify for an attribute, IMHO. > > An attribute must have atleast two possible values, and as a result > > not sending a value introduces ambiguity in the interpretation. > > If sending a zero-length value were "not sending a value" then I wouls > aggree. But "" is a value, just the ultimate short value. And the > attribute can still take any number of other values. > > (Pardon the "" shorthand.) Sure, but I don't agree. If you look at the protocol there are two octets that represent the Attribute ID and and the AVP length. The VALUE octet(s) follow that. If the AVP length is 2, there is NO value octets that follow that. Therefore, an AVP length of two is NOT "", its simply not including a value. > I don't think there should be any special significance for "". It should > not be treated the same as the attribute being ommitted, but only as a > diminutive case of a string. I don't think I can agree with that as a reason. :( -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:44:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21004 for ; Thu, 25 Feb 1999 16:44:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA26435; Thu, 25 Feb 1999 13:37:05 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA06133 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:40:24 -0800 (PST) From: "Heath Partington" To: "Beadles, Mark A." , "'Glen Zorn'" Cc: "'Richard S. Conto'" , "Dale E. Reed Jr." , , "Carl Rigney" Subject: RE: (radius) Zero-length strings Date: Thu, 25 Feb 1999 16:38:32 -0500 Message-ID: <001801be6107$30b66e00$da047392@hpartington.hq.springtidenet.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <9A74C89D6696D2118E500008C7BA7C56BF6240@wcomexch1.wcom.net> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Heath Partington" Content-Transfer-Encoding: 7bit It sounds to me like there are some valid reasons for sending an attribute length of 2 (username) and some reasons that don't sound valid at all. Doesn't sound like the RFC can/should exclude it. Perhaps a note regarding what makes sense when we say that an attribute length of 2 is valid. > -----Original Message----- > From: owner-ietf-radius@livingston.com > [mailto:owner-ietf-radius@livingston.com]On Behalf Of Beadles, Mark A. > Sent: Thursday, February 25, 1999 4:27 PM > To: 'Glen Zorn' > Cc: 'Richard S. Conto'; Dale E. Reed Jr.; ietf-radius@livingston.com; > Carl Rigney > Subject: RE: (radius) Zero-length strings > > > From: Glen Zorn [mailto:gwz@acm.org] > >So therefore the only > >> possible choice is to EITHER allow a NAS to send a null > attribute, or to > >> allow that it NOT SEND an attribute that is otherwise > required by the > >> protocol. So I would say that zero-length attributes are in. > > > >I disagree. Given a choice between a bad hack to work > around a protocol > >deficiency and fixing the protocol, I'd pick the latter every time. > > OK, fine, I'm easy. Therefore the protocol must allow packets that > do not contain User-Name and User-Password attributes, if the user > sends empty strings to the NAS. I'm just saying you can't > have it both > ways; we can't design the protocol so that the NAS has to > decide policy. > > + Mark Anthony Beadles + MCI WorldCom + > + mbeadles@wcom.net + http://www.wcom.net + > + Voice 614.723.1941 + Fax 614.723.8407 + > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:49:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21267 for ; Thu, 25 Feb 1999 16:49:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA26879; Thu, 25 Feb 1999 13:41:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA06633 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:44:50 -0800 (PST) From: Aydin Edguer Message-Id: <199902252142.QAA23177@harlequin.MorningStar.Com> Subject: Re: (radius) Zero-length strings To: ietf-radius@livingston.com Date: Thu, 25 Feb 1999 16:42:54 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > Is there any implementation that actually USES an AVP Length of two that > is receives for something and doesn't just ignore it? Yes. There is such an implementation. My apologies to those who have seen this previously: For instance, one vendor will include a State attribute with an empty string value in an Access-Request as a "hint" to the RADIUS server that the NAS supported the Access-Challenge RADIUS packet types. The sample RADIUS server provided by the vendor will _not_ send an Access-Challenge is it does _not_ see the State attribute in the Access-Request. [Note: other, newer, RADIUS servers from the vendor do not have this requirement] This made sense when it was done 4 years ago (long before RFC 2058 was completed), but it does not make sense now, except for backwards compatibility with the old sample server [that is, unfortunately, still in use at some sites]. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 16:53:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21364 for ; Thu, 25 Feb 1999 16:53:31 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA27049; Thu, 25 Feb 1999 13:45:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA07040 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:48:37 -0800 (PST) Date: Thu, 25 Feb 1999 16:48:26 -0500 (EST) From: "Steven P. Crain" To: Glen Zorn cc: "Beadles, Mark A." , "'Richard S. Conto'" , "Dale E. Reed Jr." , ietf-radius@livingston.com, Carl Rigney Subject: RE: (radius) Zero-length strings In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Thu, 25 Feb 1999, Glen Zorn wrote: > On Thu, 25 Feb 1999, Beadles, Mark A. wrote: > > > From: Richard S. Conto [mailto:rsc@merit.edu] > > >And I don't think a NAS should immediately reject a zero (empty) > > >USER-NAME. That's a policy that should be determined by the > > >service provider, and should be entirely be between the service > > >provider and the user. Perhaps CALLING-STATION-ID would sufficiently > > >identify the user (as far as the service-provider is concerned), or > > >the combination of NAS-Identifier (or NAS-Ip-Address) and NAS-PORT. > > Which begs the question "Why are you sending a User-Name at all?". Those examples probably shouldn't be sending a User-Name, but in the case where the person has specifically pressed enter after the "login:" prompt, you need to ask the RADIUS server if User-Name = "" is allowed to log in. The current draft of the RADIUS spec does not provide a way to ask this question, should someone have the policy to desire it. > I disagree. Given a choice between a bad hack to work around a protocol > deficiency and fixing the protocol, I'd pick the latter every time. As far as needing a bad hack to work around non- User-Name authentication, you are correct. We should (and did, as I recall) fix the spec to not require some hacked up username. OTOH, having to store a zero-length string value as at least one byte is also a "bad hack to work around a protocol deficiency." The biggest arguments against zero length values seem to be: 1) They aren't discussed at all in the drafts, and many implementations are abusing them. We simply need to discuss and limit their use. If we specifically state that they refer to a value consisting of an undistinguished string of octets 0 bytes long, and prohibit them from being used to indicate the absence of an attribute, it should curb the abuse. They won't get used very much, but when they are used it will be well-defined. 2) They are a diminutive case with very little apparent usefulness. I have indicated at least one case in which they could be immediately useful (request authentication of a person who entered a zero-length User-Name, perhaps to bring them to a guest service, new account signup, forgotten username lookup service or the like). I admit that the usefulness is very limitted. On the pro side, there is also that there is no compelling reason to remove the diminutive case of a zero length value. (Yeah, I'm the mathematician type that starts off Fibonacci's sequence 0,1 instead of the more common 1,1.) -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 17:02:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21782 for ; Thu, 25 Feb 1999 17:02:06 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA27741; Thu, 25 Feb 1999 13:55:14 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA08056 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:58:24 -0800 (PST) From: "Heath Partington" To: "Aydin Edguer" , Subject: RE: (radius) Zero-length strings Date: Thu, 25 Feb 1999 16:57:29 -0500 Message-ID: <001a01be6109$d6b971b0$da047392@hpartington.hq.springtidenet.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <199902252142.QAA23177@harlequin.MorningStar.Com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Heath Partington" Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-radius@livingston.com > [mailto:owner-ietf-radius@livingston.com]On Behalf Of Aydin Edguer > Sent: Thursday, February 25, 1999 4:43 PM > To: ietf-radius@livingston.com > Subject: Re: (radius) Zero-length strings > > > > Is there any implementation that actually USES an AVP > Length of two that > > is receives for something and doesn't just ignore it? > > Yes. There is such an implementation. > > My apologies to those who have seen this previously: > > For instance, one vendor will include a State attribute > with an empty > string value in an Access-Request as a "hint" to the RADIUS > server that > the NAS supported the Access-Challenge RADIUS packet types. > > The sample RADIUS server provided by the vendor will _not_ send an > Access-Challenge is it does _not_ see the State attribute in the > Access-Request. [Note: other, newer, RADIUS servers from the vendor > do not have this requirement] > > This made sense when it was done 4 years ago (long before RFC 2058 was > completed), but it does not make sense now, except for backwards > compatibility with the old sample server [that is, unfortunately, > still in use at some sites]. Why? Was there a different description for the State attribute at that time? > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 17:02:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21803 for ; Thu, 25 Feb 1999 17:02:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA27763; Thu, 25 Feb 1999 13:55:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA08127 for ietf-radius-outgoing; Thu, 25 Feb 1999 13:58:43 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Thu, 25 Feb 1999 13:50:33 -0800 (PST) From: Glen Zorn To: "Beadles, Mark A." cc: "'Richard S. Conto'" , "Dale E. Reed Jr." , ietf-radius@livingston.com, Carl Rigney Subject: RE: (radius) Zero-length strings In-Reply-To: <9A74C89D6696D2118E500008C7BA7C56BF6240@wcomexch1.wcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Thu, 25 Feb 1999, Beadles, Mark A. wrote: > From: Glen Zorn [mailto:gwz@acm.org] > >So therefore the only > >> possible choice is to EITHER allow a NAS to send a null attribute, or to > >> allow that it NOT SEND an attribute that is otherwise required by the > >> protocol. So I would say that zero-length attributes are in. > > > >I disagree. Given a choice between a bad hack to work around a protocol > >deficiency and fixing the protocol, I'd pick the latter every time. > > OK, fine, I'm easy. Therefore the protocol must allow packets that > do not contain User-Name and User-Password attributes, if the user > sends empty strings to the NAS. I'm just saying you can't have it both > ways; we can't design the protocol so that the NAS has to decide policy. Agreed. > > + Mark Anthony Beadles + MCI WorldCom + > + mbeadles@wcom.net + http://www.wcom.net + > + Voice 614.723.1941 + Fax 614.723.8407 + > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 17:24:30 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22697 for ; Thu, 25 Feb 1999 17:24:29 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA29770; Thu, 25 Feb 1999 14:16:27 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA10659 for ietf-radius-outgoing; Thu, 25 Feb 1999 14:18:58 -0800 (PST) Date: Thu, 25 Feb 1999 17:17:53 -0500 (EST) From: Jeff Weisberg Message-Id: <199902252217.RAA20191@sulcus.op.net> To: ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jeff Weisberg certainly, in an information theoretic sense, all 3 of Attr = "value" Attr = "" are different, and (may) convey different information, and ergo should certainly be permitted so as to convey the appropriate information. but, for the *standard* attrs, I don't see Attr = "" as conveying anything different, *if is permitted*. so, I'd be happy to not permit AVPs of len=2 for standard attrs, if we permit the attr to not be present, but would not want to restrict non-standard attrs in any such manner. --jeff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 17:24:35 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22708 for ; Thu, 25 Feb 1999 17:24:34 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA29775; Thu, 25 Feb 1999 14:16:27 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA10642 for ietf-radius-outgoing; Thu, 25 Feb 1999 14:18:55 -0800 (PST) Date: Thu, 25 Feb 1999 17:17:57 -0500 (EST) From: Jeff Weisberg Message-Id: <199902252217.RAA20192@sulcus.op.net> To: ietf-radius@livingston.com Subject: RE: (radius) Zero-length strings Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jeff Weisberg | Which begs the question "Why are you sending a User-Name at all?". Username and -Password are required to be present. --jeff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 17:24:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22707 for ; Thu, 25 Feb 1999 17:24:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA29780; Thu, 25 Feb 1999 14:16:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA10655 for ietf-radius-outgoing; Thu, 25 Feb 1999 14:18:56 -0800 (PST) Date: Thu, 25 Feb 1999 17:17:50 -0500 (EST) From: Jeff Weisberg Message-Id: <199902252217.RAA20190@sulcus.op.net> To: ietf-radius@livingston.com Subject: RE: (radius) IDs Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jeff Weisberg | Someday I'd like to see a good informational RFC discussing RADIUS | timers in depth; for the moment such things are left to the | inventiveness of implementers. RFC 1536 (Common DNS Implementation Errors and Suggested Fixes), section 1 (Fast Retransmissions) is a good start. many of the same issues apply. --jeff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 17:24:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22721 for ; Thu, 25 Feb 1999 17:24:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA29766; Thu, 25 Feb 1999 14:16:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA10657 for ietf-radius-outgoing; Thu, 25 Feb 1999 14:18:57 -0800 (PST) Date: Thu, 25 Feb 1999 17:18:01 -0500 (EST) From: Jeff Weisberg Message-Id: <199902252218.RAA20193@sulcus.op.net> To: ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jeff Weisberg | | Can someone come up with a clear reason why having an AVP length | of two is ANY diffrent than not including the attribute? Thats | all I'm trying to get at. I will not accept the definition of a | default, because a default is an ambiguity that we are trying | to avoid and should be a defined value for the attribute, not | an empty string. I'm very accepting of a reason, but I don't | like "just because". For standard attrs? probably no. Or the general case of any attr? In which case, not present and empty are clearly different for the hypothetical "Text-To-Display-Instead-of-Normal-NAS-Banner" attribute: : FoobarOS version 7.0 Text-To-Display-Instead-of-Normal-NAS-Banner = "Welcome to My ISP" Welcome to My ISP Text-To-Display-Instead-of-Normal-NAS-Banner = "" --jeff or to paraphrase Firth: One of the main causes of the fall of the Roman Empire was that lacking zero length AVPs, they had no way to indicate ... - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 17:44:22 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23846 for ; Thu, 25 Feb 1999 17:44:22 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA00919; Thu, 25 Feb 1999 14:34:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA12967 for ietf-radius-outgoing; Thu, 25 Feb 1999 14:37:30 -0800 (PST) From: Aydin Edguer Message-Id: <199902252235.RAA23191@harlequin.MorningStar.Com> Subject: RE: (radius) Zero-length strings To: ietf-radius@livingston.com Date: Thu, 25 Feb 1999 17:35:35 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > Why? Was there a different description for the State attribute at that > time? In the beginning... billions and billions of nano-seconds ago... many NASes did not support the RADIUS Access-Challenge. Sending them an Access-Challenge would not result in good behavior. In order to differentiate between a NAS that was willing to do it and a NAS that just wouldn't, the inclusion of the empty string in the State attribute of the Access-Request was useful as a hint that the NAS supported the Access-Challenge. Thus the hack was started for backwards compatibility reasons. Now, there is a legacy server, that needs the hack in order for the Access-Challenge to be used, so the NAS continues the behavior in the name of backwards compatibility. It is recognized by the vendor that this is *NOT* RFC compliant. This is not an attempt to excuse the behavior but to answer the original question "Is there any implementation that actually USES an AVP Length of two". The answer was "yes". - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 18:57:16 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28089 for ; Thu, 25 Feb 1999 18:57:15 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA04024; Thu, 25 Feb 1999 15:46:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA21107 for ietf-radius-outgoing; Thu, 25 Feb 1999 15:49:14 -0800 (PST) Date: Thu, 25 Feb 99 15:45:42 PST From: William "Chops" Westfield To: Jeff Weisberg Cc: ietf-radius@livingston.com Subject: Re: (radius) Zero-length strings In-Reply-To: Your message of Thu, 25 Feb 1999 17:18:01 -0500 (EST) Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William "Chops" Westfield Or the general case of any attr? In which case, not present and empty are clearly different for the hypothetical "Text-To-Display-Instead-of-Normal-NAS-Banner" attribute: Good example. In fact, I believe that cisco's implementation treats the existing Reply-Message (18) in exactly the way you describe. BillW cisco - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 19:02:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28459 for ; Thu, 25 Feb 1999 19:02:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA04494; Thu, 25 Feb 1999 15:55:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA21827 for ietf-radius-outgoing; Thu, 25 Feb 1999 15:56:27 -0800 (PST) Date: Thu, 25 Feb 1999 15:56:24 -0800 (PST) From: Carl Rigney Message-Id: <199902252356.PAA21819@server.livingston.com> To: MBeadles@wcom.net Subject: RE: (radius) Zero-length strings Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney > Therefore the protocol must allow packets that do not contain > User-Name and User-Password attributes, if the user sends empty strings > to the NAS. There's no problem with an empty User-Password; you just null-pad 16 bytes of data and encrypt it as usual. The new draft allows you to omit User-Name where its no longer needed, such as for Call-Check or EAP. I'm still unsure with regard to users just hitting return on the User-Name. I'm not sure a zero-length username is valid from an authentication standpoint, and if authentication isn't being done, its not a matter for RADIUS. I note that email to "@foo.com" is not considered valid either. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Feb 25 22:00:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04607 for ; Thu, 25 Feb 1999 22:00:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA08214; Thu, 25 Feb 1999 18:13:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA02636 for ietf-radius-outgoing; Thu, 25 Feb 1999 18:16:10 -0800 (PST) Date: Thu, 25 Feb 1999 18:16:08 -0800 (PST) From: Carl Rigney Message-Id: <199902260216.SAA02624@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Call Check Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney The new RADIUS draft allocates a Service-Type for Call-Check (10) but doesn't discuss it in depth. Call Check seems to still be in enough flux that rather than document it in the RADIUS draft, I'm thinking it might be better to write up an experimental or informational draft covering it in more detail, so that can be revised as we get more implementation experience with it, without having to re-issue the entire 100-page RADIUS draft. Does anyone object? Likewise for Acct-Status-Type for Session-Failed. I'd like to do it as a short experimental draft, along with values for failure codes (which I suspect will generate a LOT of discussion, so I want to hold off on it for now). After both of those get real-world experience and acceptance, possibly they can be folded into a future revision of the extensions draft, although its getting pretty darn hefty itself. -- Carl Rigney cdr@livingston.com "It doesn't have to finish but it has to stop." -- Mike O'Dell - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 09:38:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19407 for ; Fri, 26 Feb 1999 09:38:30 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA18295; Fri, 26 Feb 1999 06:30:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA28254 for ietf-radius-outgoing; Fri, 26 Feb 1999 06:32:46 -0800 (PST) Message-Id: <199902261431.GAA24989@shell4.ba.best.com> Subject: RE: (radius) Zero-length strings (fwd) To: ietf-radius@livingston.com Date: Fri, 26 Feb 1999 06:31:23 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Jeff Weisberg shaped the electrons to say... >Username and -Password are required to be present. I believe that in the newer drafts User-Name is not required under specific circumstances, such as Call-Check and EAP. As for X-Password - can't Signature be used in place of a password? Or am I misreading the intent of Signature? In any case, you can encode a null password as User-Password - it is just all padding. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 09:45:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19504 for ; Fri, 26 Feb 1999 09:45:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA18699; Fri, 26 Feb 1999 06:37:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA28937 for ietf-radius-outgoing; Fri, 26 Feb 1999 06:40:46 -0800 (PST) Message-Id: <199902261439.GAA26084@shell4.ba.best.com> Subject: RE: (radius) Zero-length strings (fwd) To: ietf-radius@livingston.com Date: Fri, 26 Feb 1999 06:39:05 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Carl Rigney shaped the electrons to say... >I'm still unsure with regard to users just hitting return on the >User-Name. I'm not sure a zero-length username is valid from an >authentication standpoint, and if authentication isn't being done, its >not a matter for RADIUS. I think that it could be - the server could consider a z-l u-n to indicate authentication should fall back to a field like Calling-Station-Id. Or perhaps there is a public access port and it can allow z-l u-n based on the NAS and port, etc. The basic point here is that you can't prove a negative, and as long as there is the possibility of this being a valid authentication under any usage model then it should be allowed. The protocol should not force the business model - or we'll get kludges with faked User-Name fields, or invite non-compliance. Zero-Length User-Name is something I can see a justification for. I'm still not convinced that Z-L State or Class is meaningful. If some vendor used it as a signalling kludge in the past, I still don't see that as enough justification to include it. Whereas a Z-L U-N means something - the user hit Enter without entering a name, sent no name in PAP, etc - which is different from no User-Name AVP at all (as in Call-Check), I don't see that a Zero-Length State or Class are meaningful or differentiated from just not being present. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 10:48:30 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20896 for ; Fri, 26 Feb 1999 10:48:29 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA20696; Fri, 26 Feb 1999 07:41:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA04021 for ietf-radius-outgoing; Fri, 26 Feb 1999 07:44:06 -0800 (PST) Message-Id: <3.0.5.32.19990226104311.038ec820@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 26 Feb 1999 10:43:11 -0500 To: Jeff Weisberg , ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) Zero-length strings In-Reply-To: <199902252217.RAA20191@sulcus.op.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton Wow, take a day at home due to a snow storm, and it storms in the RADIUS WG! Quickly... as I have other things to finish today.... I'm in favor of ZLS. 'cuz: - closes a symmetry hole in parsing - which should be dealt with anyways (liberal in acceptance) - allows the semantic argued below (useful in overriding defaults and short strings) Basically I would follow Steven and Jeff's line. While not in favor of sending attrs that don't mean anything, I do think there are times where it does mean something useful. There are also other value cases that should be dealt with for specific datatypes (e.g. ipaddrs of 0.0.0.0) in a datatype/specific attr dependent manner. Dave. At 05:17 PM 2/25/99 -0500, Jeff Weisberg wrote: > > >certainly, in an information theoretic sense, all 3 of > Attr = "value" > Attr = "" > >are different, and (may) convey different information, and ergo >should certainly be permitted so as to convey the appropriate >information. > >but, for the *standard* attrs, I don't see > Attr = "" > >as conveying anything different, *if is >permitted*. > > >so, I'd be happy to not permit AVPs of len=2 for standard >attrs, if we permit the attr to not be present, but would >not want to restrict non-standard attrs in any such manner. > > > --jeff > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 12:31:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22693 for ; Fri, 26 Feb 1999 12:31:30 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA24640; Fri, 26 Feb 1999 09:22:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA15144 for ietf-radius-outgoing; Fri, 26 Feb 1999 09:25:56 -0800 (PST) Date: Fri, 26 Feb 1999 09:25:54 -0800 (PST) From: Carl Rigney Message-Id: <199902261725.JAA15126@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) More detail on Proxy Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I'm planning to include the following detailed description of Proxy under the Operations section in the new Draft (now only hours away). Comments welcome. With proxy RADIUS, one RADIUS server forwards an authentication (or accounting) request to a remote RADIUS server, and returns its reply to the network access server (NAS). A common use for proxy RADIUS is roaming. Roaming permits two or more administrative entities to allow each other's users to dial in to either entity's network for service. The NAS sends its RADIUS access-request to the "forwarding server" which forwards it to the "remote server." The remote server sends a response (Access-Accept, Access-Reject, or Access-Challenge) back to the forwarding server, which sends it back to the NAS. The choice of which server to forward the request to is based on the authentication "realm." A realm can either be based on part of the User-Name, for example the part following an at ("@") sign (a "named realm"), or a Called-Station-Id (a "numbered realm"), or using whatever other criteria the forwarding server is configured to use. Frequently, a fully qualified domain name is used as the named realm to provide uniqueness. A RADIUS server can function as both a forwarding server and a remote server, serving as a forwarding server for some realms and a remote server for other realms. One forwarding server can forward to any number of remote servers. A remote server can have any number of servers forwarding to it and can provide authentication for any number of realms. One forwarding server can forward to another forwarding server to create a chain of proxies, although care must be taken to avoid introducing loops. The following scenario illustrates the communication between a NAS and the forwarding and remote RADIUS servers: 1. A NAS sends its access-request to the forwarding server. 2. The forwarding server forwards the access-request to the remote server. 3. The remote server sends an access-accept, access-reject or access-challenge back to the forwarding server. For this example, an access-accept is sent. 4. The forwarding server sends the access-accept to the NAS. A forwarding server may either perform its forwarding function in a pass through manner, where it sends retransmissions on as soon as it gets them, or it may take responsibility for retransmissions, for example in cases where the network link between forwarding and remote server has very different characteristics than the link between NAS and forwarding server. Extreme care should be used when implementing a proxy server that takes responsibility for retransmissions so that its retransmission policy is robust and scalable. We now examine each step in more detail. 1. A NAS sends its access-request to the forwarding server. The forwarding server unencrypts the User-Password, if present, using the shared secret it knows for the NAS. If a CHAP-Password attribute is present in the packet and no CHAP-Challenge attribute is present, the forwarding server MUST leave the Request-Authenticator untouched or copy it to a CHAP-Challenge attribute. The forwarding server MAY add one Proxy-State attribute to the packet. If it does, the Proxy-State MUST appear after any other Proxy-States in the packet. The forwarding server MUST NOT modify any other Proxy-States that were in the packet and MUST NOT change the order of any attributes of the same type, including Proxy State. 2. The forwarding server encrypts the User-Password, if present, using the secret it shares with the remote server, sets the Identifier as needed, and forwards the access-request to the remote server. 3. The remote server (if the final destination) verifies the user using User-Password, CHAP-Password, or such method as future extensions may dictate, and returns an access-accept, access-reject or access-challenge back to the forwarding server. For this example, an access-accept is sent. The remote server MUST copy all Proxy-State attributes (and only the Proxy-State attributes) in order from the access-request to the response packet, without modifying them. 4. The forwarding server verifies the Response Authenticator using the secret it shares with the remote server, and silently discards the packet if it fails verification. If the packet passes verification, the forwarding server removes the last Proxy-State (if it attached one), signs the Response Authenticator using the secret it shares with the NAS, restores the Identifier to match the one in the original request by the NAS, and sends the access-accept to the NAS. A forwarding server may need to modify attributes to enforce local policy. Such policy is outside the scope of this document, with the following restrictions. A forwarding server MUST not modify existing Proxy-State, State, or Class attributes present in the packet. Implementers of forwarding servers should consider carefully which values it is willing to accept for Service-Type. Careful consideration must be given to the effects of passing along Service-Types of NAS-Prompt or Administrative in a proxied access-accept, and implementers may wish to provide mechanisms to block those or other service types, or other attributes. Such mechanisms are outside the scope of this document. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 13:00:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23062 for ; Fri, 26 Feb 1999 13:00:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA25574; Fri, 26 Feb 1999 09:52:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA18656 for ietf-radius-outgoing; Fri, 26 Feb 1999 09:55:46 -0800 (PST) Date: Fri, 26 Feb 1999 09:55:43 -0800 (PST) From: Carl Rigney Message-Id: <199902261755.JAA18644@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Zero Length Summary Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney So after carefully reading dozens of messages this is how it seems to me. The people against zero length strings want examples of what they're good for, and all the examples so far seem to fall into one of the following cases, each of which can be handled more cleanly in the existing framework, or in some cases with minor changes that have already been incorporated into the new draft. Most uses of zero length strings is to get around the requirement that certain attributes must be present in the packet. It strikes me as odd that implementers are willing to violate the length requirements in the RFC, but balk at violating the rules on what attributes are required. The new draft loosens up requirements so this should no longer be necessary. A few vendors are using zero length strings to convey special undocumented meanings. This harms interoperability and is therefore evil and not to be encouraged. There needs to be a way to convey an empty password. This is already easily done because User-Password is required to be null padded to a multiple of 16 bytes of data. At first thought, it troubled me that a null password would then give a snooper the MD5 checksum of the shared secret followed by the request authenticator, but as far as I know, having both Y and MD5(X+Y) does not get you any closer to discovering X, so there's no real security problem here. And besides, an attacker could sign up for his own account, xor his own captured packet, and uncover the same information. So this doesn't seem to be a problem. Possibly there needs to be a way to convey an empty username. I'm uncomfortable with the whole notion of authenticating a nameless user; I can't send email to "@livingston.com", why should I be able to authenticate "" as a user? But for those who really want to have nameless users, they should just omit the User-Name attribute. I contemplated adding language allowing null padding for User-Names, but "Carl" and "Carl\0" are seperate users, and in particular UTF-8 can have embedded zero octets and RADIUS should support UTF-8 as the IETF's choice for internationalization, so I think its simpler just to omit attributes when they are zero length. And the existing document has never had zero length strings, so I'm going to correct the 0-253 typo that allowed people to willfully misunderstand all the explicit length desciptions. I'm still willing to entertain NEW arguments one way or the other, but please, no repeats of things already said or rehashes of existing arguments. -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 15:04:06 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25893 for ; Fri, 26 Feb 1999 15:04:02 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA29287; Fri, 26 Feb 1999 11:56:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA04394 for ietf-radius-outgoing; Fri, 26 Feb 1999 11:57:52 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Fri, 26 Feb 1999 11:49:39 -0800 (PST) From: Glen Zorn To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) Call Check In-Reply-To: <199902260216.SAA02624@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Thu, 25 Feb 1999, Carl Rigney wrote: > The new RADIUS draft allocates a Service-Type for Call-Check (10) but doesn't > discuss it in depth. Call Check seems to still be in enough flux that rather > than document it in the RADIUS draft, I'm thinking it might be better to write > up an experimental or informational draft covering it in more detail, so that > can be revised as we get more implementation experience with it, without having > to re-issue the entire 100-page RADIUS draft. What does Call-Check do? I can't find it in any draft... > > Does anyone object? > > Likewise for Acct-Status-Type for Session-Failed. I'd like to do it > as a short experimental draft, along with values for failure codes > (which I suspect will generate a LOT of discussion, so I want to hold > off on it for now). > Let's just get this stuff done, shall we? > After both of those get real-world experience and acceptance, possibly they > can be folded into a future revision of the extensions draft, although its > getting pretty darn hefty itself. Why do we need any real-world experience to put something in a draft? If it's useless, it can always be taken out before the doc goes to Draft Standard. > > -- > Carl Rigney > cdr@livingston.com > > "It doesn't have to finish but it has to stop." -- Mike O'Dell > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 15:04:19 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25912 for ; Fri, 26 Feb 1999 15:04:19 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA29396; Fri, 26 Feb 1999 11:57:27 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA04759 for ietf-radius-outgoing; Fri, 26 Feb 1999 12:00:33 -0800 (PST) X-Authentication-Warning: pinky.microsoft.com: gwz owned process doing -bs Date: Fri, 26 Feb 1999 11:52:20 -0800 (PST) From: Glen Zorn To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) Call Check In-Reply-To: <199902260216.SAA02624@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Thu, 25 Feb 1999, Carl Rigney wrote: > The new RADIUS draft allocates a Service-Type for Call-Check (10) but doesn't > discuss it in depth. Call Check seems to still be in enough flux that rather > than document it in the RADIUS draft, I'm thinking it might be better to write > up an experimental or informational draft covering it in more detail, so that > can be revised as we get more implementation experience with it, without having > to re-issue the entire 100-page RADIUS draft. > > Does anyone object? > > Likewise for Acct-Status-Type for Session-Failed. I'd like to do it > as a short experimental draft, along with values for failure codes > (which I suspect will generate a LOT of discussion, so I want to hold > off on it for now). I'll volunteer to write it, if you'll supply a number... > > After both of those get real-world experience and acceptance, possibly they > can be folded into a future revision of the extensions draft, although its > getting pretty darn hefty itself. > > -- > Carl Rigney > cdr@livingston.com > > "It doesn't have to finish but it has to stop." -- Mike O'Dell > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 15:22:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26104 for ; Fri, 26 Feb 1999 15:22:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA29957; Fri, 26 Feb 1999 12:14:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA06798 for ietf-radius-outgoing; Fri, 26 Feb 1999 12:17:43 -0800 (PST) Message-Id: <3.0.5.32.19990226151806.03903a00@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 26 Feb 1999 15:18:06 -0500 To: Carl Rigney , ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) Zero Length Summary In-Reply-To: <199902261755.JAA18644@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton Let me make my position clear. I do not want to send zero length attributes just because they may be required for some situations. In those situations, either the requirement should be relaxed, or the operation should be revisited. I only want to send zero length strings (not integers) when it means something to set the value to null. Often this means overriding an otherwise inaccessable or unknown default. Dave. At 09:55 AM 2/26/99 -0800, Carl Rigney wrote: >So after carefully reading dozens of messages this is how it seems to >me. > >The people against zero length strings want examples of what they're >good for, and all the examples so far seem to fall into one of the >following cases, each of which can be handled more cleanly in the >existing framework, or in some cases with minor changes that have >already been incorporated into the new draft. > >Most uses of zero length strings is to get around the requirement that >certain attributes must be present in the packet. It strikes me as odd >that implementers are willing to violate the length requirements in the >RFC, but balk at violating the rules on what attributes are required. >The new draft loosens up requirements so this should no longer be >necessary. > >A few vendors are using zero length strings to convey special >undocumented meanings. This harms interoperability and is therefore >evil and not to be encouraged. > >There needs to be a way to convey an empty password. This is already >easily done because User-Password is required to be null padded to a >multiple of 16 bytes of data. At first thought, it troubled me that a >null password would then give a snooper the MD5 checksum of the shared >secret followed by the request authenticator, but as far as I know, >having both Y and MD5(X+Y) does not get you any closer to discovering >X, so there's no real security problem here. And besides, an attacker >could sign up for his own account, xor his own captured packet, and >uncover the same information. So this doesn't seem to be a problem. > >Possibly there needs to be a way to convey an empty username. I'm >uncomfortable with the whole notion of authenticating a nameless user; >I can't send email to "@livingston.com", why should I be able to >authenticate "" as a user? But for those who really want to have >nameless users, they should just omit the User-Name attribute. I >contemplated adding language allowing null padding for User-Names, but >"Carl" and "Carl\0" are seperate users, and in particular UTF-8 can >have embedded zero octets and RADIUS should support UTF-8 as the IETF's >choice for internationalization, so I think its simpler just to omit >attributes when they are zero length. > >And the existing document has never had zero length strings, so I'm >going to correct the 0-253 typo that allowed people to willfully >misunderstand all the explicit length desciptions. > >I'm still willing to entertain NEW arguments one way or the other, but >please, no repeats of things already said or rehashes of existing >arguments. > >-- >Carl Rigney >cdr@livingston.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 15:30:10 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26205 for ; Fri, 26 Feb 1999 15:30:09 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA00371; Fri, 26 Feb 1999 12:22:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA07806 for ietf-radius-outgoing; Fri, 26 Feb 1999 12:26:10 -0800 (PST) Message-Id: <3.0.5.32.19990226152637.00bd6210@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 26 Feb 1999 15:26:37 -0500 To: ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress In-Reply-To: <199902251812.KAA12372@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton on this topic: - I've never understood why not to send a NAS-IP-Address attribute. It's trivial to include and should be there ALWAYS, and it's value is most obvious. - WRT: NAS-Identifier, I had an argument with one of my developers who claimed that the wording of the RFC indicated that it is not recommended that you send both. I'd like to get that "recommendation" struck out. I brought this up once before: >Return-Path: >Received: from atlas.xylogics.com by vulcan.xylogics.com > id AA12506 (4.1/UK-doug-951219); Wed, 28 Jan 98 09:43:32 EST >Received: from smtp-gw.BayNetworks.COM (ext-ns4.baynetworks.com [192.32.253.7]) by atlas.xylogics.com (8.7.3/8.7.3) with ESMTP id JAA04481 for ; Wed, 28 Jan 1998 09:43:31 -0500 (EST) >Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) > by smtp-gw.BayNetworks.COM (8.8.6/8.8.6) with ESMTP id JAA16554 > for ; Wed, 28 Jan 1998 09:44:06 -0500 (EST) >Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA04517; Wed, 28 Jan 1998 06:36:05 -0800 (PST) >Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA13569 for ietf-radius-outgoing; Wed, 28 Jan 1998 06:38:13 -0800 (PST) >Message-Id: <3.0.5.32.19980128093808.00871e30@vulcan.xylogics.com> >X-Sender: mitton@vulcan.xylogics.com >X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) >Date: Wed, 28 Jan 1998 09:38:08 -0500 >To: ietf-radius@livingston.com >From: Dave Mitton >Subject: (radius) NAS-IP-Address,or NAS-Identifier, but not both. Why? >Mime-Version: 1.0 >Content-Type: text/enriched; charset="us-ascii" >Sender: owner-ietf-radius@livingston.com >Precedence: bulk >Reply-To: Dave Mitton > >RADIUS, RFC 2138, Section 4.1 says: > > An Access-Request MUST contain a User-Name attribute. It >SHOULD > > contain either a NAS-IP-Address attribute or NAS-Identifier > > attribute (or both, although that is not recommended). > > >A similar phrase is more findable in Accounting RFC 2139, Section 5.13, > > > [5] An Accounting-Request MUST contain either a NAS-IP-Address or a > > NAS-Identifier, and it is permitted (but not recommended) for it to > > contain both. > > >I'm most curious about the _why_ both is not "recommended"? > > >Providing the IP-Address is a no-brainer. > >And I thought that providing the system name in text in the >NAS-Identifier was most user and debug friendly. > > >But I get push back when I try to include both. > > > Dave. >- --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 15:35:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26332 for ; Fri, 26 Feb 1999 15:35:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA00592; Fri, 26 Feb 1999 12:28:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA08775 for ietf-radius-outgoing; Fri, 26 Feb 1999 12:31:56 -0800 (PST) Message-Id: <199902262032.PAA11731@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) Zero Length Summary In-reply-to: Your message of "Fri, 26 Feb 1999 15:18:06 EST." <3.0.5.32.19990226151806.03903a00@fred.xylogics.com> Date: Fri, 26 Feb 1999 15:32:05 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok Dave Mitton wrote: > I only want to send zero length strings (not integers) when it means > something to set the value to null. Often this means overriding an > otherwise inaccessable or unknown default. For which RADIUS attributes is this behaviour useful, and in what situations? Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 16:09:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27056 for ; Fri, 26 Feb 1999 16:09:00 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA01528; Fri, 26 Feb 1999 13:02:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA12050 for ietf-radius-outgoing; Fri, 26 Feb 1999 13:05:39 -0800 (PST) Date: Fri, 26 Feb 99 16:02:17 EST From: David Bolen To: Carl Rigney Cc: ietf-radius@livingston.com Subject: Re: (radius) More detail on Proxy In-Reply-To: Your message of Fri, 26 Feb 1999 09:25:54 -0800 (PST) Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: David Bolen > 1. A NAS sends its access-request to the forwarding server. (...) > > The forwarding server MAY add one Proxy-State attribute to the packet. > If it does, the Proxy-State MUST appear after any other Proxy-States in > the packet. The forwarding server MUST NOT modify any other > Proxy-States that were in the packet and MUST NOT change the order of > any attributes of the same type, including Proxy State. This seems a bit restrictive to me. It seems to me that what must be done is limited to returning any set of Proxy-State attributes that were received in the request in the identical order on any generated response. However, any means that provides this functionality should be acceptable. For example, in my server I strip out any Proxy-State attributes from a received request and hold onto them internally. When I replicate the request to the next target server, I add my own Proxy-State attribute, but that is the only one that will be seen by that next hop server. When the reply comes back, I use my Proxy-State to match things up, remove it, and then replace any saved Proxy-State attributes for the client to which I am replying. It's not totally clear if doing the above would really violate your proposed paragraph since it's not truly a "modification" of the Proxy-States in the received packet but I'd be happier if the actual phrases were more oriented towards what the server MUST do with respect to returning the attributes unchanged and un-reordered to the client, then what the packet must look like to the next server. > 4. The forwarding server verifies the Response Authenticator using (...) > > A forwarding server may need to modify attributes to enforce local > policy. Such policy is outside the scope of this document, with the > following restrictions. A forwarding server MUST not modify existing > Proxy-State, State, or Class attributes present in the packet. It seems that a clause such as this may be appropriate for the forwarding path (step 2 probably) as well, since a forwarding server may wish to enforce policy (hiding NAS addresses, for example) or attribute modification for inter-domain forwarding of requests in addition to the NAS reply case here. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 16:12:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27150 for ; Fri, 26 Feb 1999 16:12:11 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA01391; Fri, 26 Feb 1999 12:59:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA11778 for ietf-radius-outgoing; Fri, 26 Feb 1999 13:02:21 -0800 (PST) Date: Fri, 26 Feb 1999 13:02:18 -0800 (PST) From: Carl Rigney Message-Id: <199902262102.NAA11769@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) New Drafts available for FTP Cc: ad-op@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney The following 3 drafts will be available in the usual internet-drafts location soon, but you can FTP them right now from ftp://ftp.livingston.com/pub/radius/ if you don't want to wait. draft-ietf-radius-radius-07.txt RADIUS draft-ietf-radius-accounting-07.txt RADIUS Accounting draft-ietf-radius-ext-03.txt RADIUS Extensions I'll be issuing the Working Group Last Call on them as soon as I see they're available in the drafts directory, or Monday, whichever comes first, but feel to email me comments anytime in the next two weeks. I would be especially grateful for anyone who's willing to undertake the tedious task of double-checking that the packet dumps in the "Examples" section of the RADIUS draft are in fact valid. Once working group last call is completed satisfactorily, the RADIUS draft will go to IETF Last Call for advancement to Draft Standard, and the other two drafts will go to the IESG asking to be released as informational. Next week I should have the rough draft of the allocation policy guidelines for people to comment on, and shortly after that I should have the Implementation Survey document available for comment. The 4 MIB documents have completed working group last call. The two RADIUS MIB documents will be submitted for IETF Last Call for advanced to proposed standard, and the two RADIUS Accounting MIB documents will be submitted to the IESG as informational. The 3 Tunneling documents have completed working group last call, and my understanding is that they're just waiting for the L2TP document. The RADIUS Working Group is not meeting in Minnesota. -- Carl Rigney cdr@livingston.com "It doesn't have to finish but it has to stop." -- Mike O'Dell - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 16:15:10 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27241 for ; Fri, 26 Feb 1999 16:15:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA01858; Fri, 26 Feb 1999 13:08:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA12632 for ietf-radius-outgoing; Fri, 26 Feb 1999 13:11:30 -0800 (PST) Date: Fri, 26 Feb 1999 13:11:27 -0800 (PST) From: Carl Rigney Message-Id: <199902262111.NAA12615@server.livingston.com> To: dmitton@baynetworks.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Why bother to provide both? Either identifies the NAS, so what's the good of carrying redundant information in the request? But I'd be OK with softening the not recommended to a "think about whether you really want to carry redundant info" or omitting it altogether, depending on how people feel. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Feb 26 16:19:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27333 for ; Fri, 26 Feb 1999 16:19:46 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA01721; Fri, 26 Feb 1999 13:07:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA12459 for ietf-radius-outgoing; Fri, 26 Feb 1999 13:10:37 -0800 (PST) Date: Fri, 26 Feb 1999 16:10:18 -0500 (EST) From: Stuart A Barkley To: ietf-radius@livingston.com Subject: Re: (radius) Zero Length Summary In-Reply-To: <3.0.5.32.19990226151806.03903a00@fred.xylogics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Stuart A Barkley As usual these are my personal opinion, but they all really seem to be so obvious that I can't argue for them very well. Starting with: There is a big difference between not having an attribute and having a null value for the attribute as was shown with the system prompt example. The specification of individual attribute can make the determination of whether that specific attribute can have a zero length value and what meaning is conveyed. All of the currently defined standard attributes seem to explicitly disallow zero length values which is not inconsistent with generally allowing transport of zero length values. Future additions or changes to individual standard attributes need to make the determination of whether zero length values are meaningful and are subject of separate discussions (where I can see lots of different opinions). Vendor specific attributes may allow zero length attributes. Gives: Zero length values need to be supported by the base radius transport protocol. So: A radius server or client should generally expect to need to deal with zero length values for attributes and the programmers of radius code should take that into account during the system design. (Just like they need to deal with embedded 0 bytes in character strings and lots of other subtle considerations.) Stuart -- Stuart A Barkley email: stuartb@uu.net UUNET WorldCom phone: +1 703 206 5645 I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Feb 27 01:08:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00601 for ; Sat, 27 Feb 1999 01:08:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA11013; Fri, 26 Feb 1999 22:01:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA17295 for ietf-radius-outgoing; Fri, 26 Feb 1999 22:02:55 -0800 (PST) From: Paul_Febvre@inmarsat.org MIME-Version: 1.0 Date: Sat, 27 Feb 1999 04:22:05 +0000 Message-Id: <0003AF41.C22093@inmarsat.org> Subject: Re[2]: (radius) Matching NAS-IP-Address to actual real-life Cc: ietf-radius@livingston.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul_Febvre@inmarsat.org Content-Transfer-Encoding: 7bit Apologies for butting in, but I don't feel the information is redundant under certain circumstances. Previous threads have indicated that the NAS-IP-Address is not a good identifier for a NAS, particularly in a fully redundant or large scale implementation, in which case NAS-Identifier is by far the best approach. The NAS-IP-Address may not be the address of the RADIUS client at the NAS, but instead may be considered to be the termination point for any tunnels carrying out-bound traffic to a specific user. This information may then be maintained at the RADIUS server and provided to any authorised LNS needing such routing information. I also would like to see the 'not-recommended' status regarding the carrying of both NAS-IP-Address and NAS-Identifier being removed from the standard. Paul ______________________________ Reply Separator _________________________________ Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS Author: Carl Rigney at Internet Date: 26/02/99 13:11 Why bother to provide both? Either identifies the NAS, so what's the good of carrying redundant information in the request? But I'd be OK with softening the not recommended to a "think about whether you really want to carry redundant info" or omitting it altogether, depending on how people feel. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ********************************************************************** - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Feb 27 17:27:35 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14411 for ; Sat, 27 Feb 1999 17:27:34 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA20469; Sat, 27 Feb 1999 14:20:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA11583 for ietf-radius-outgoing; Sat, 27 Feb 1999 14:22:10 -0800 (PST) From: admin1@fnmail.com Date: Sat, 27 Feb 1999 17:13:52 -0500 (EST) Message-Id: <199902272213.RAA15465@ns2.gis.net> To: travelers@ibm.net Subject: (radius) Travel, Make $$ & Have Lots of Fun! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: admin1@fnmail.com Set your own hours. Set your own schedule. Grow with the largest and fastest growing industry in the world. State of the art marketing system that brings the customer to you and does the selling for you. All from your own home!!! NOT Multi-level Marketing If you are coachable and teachable with a burning DESIRE to improve your life style Then You owe it to yourself to listen and look. Call the toll free # below to hear a recorded 2 minute overview 1-888-376-1192 Ask about our vacation/travel discount packages including: 2 Free round-trip airline tickets, 2 Free tickets to Universal Studio or Sea World AND.... Much Much More !!! This mailing is done by an independent marketing co. and has been sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 - SECTION 301). http://www.senate.gov/~murkowski/commercialemail/EMailAmendText.html "Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by sending an e-mail with REMOVE in the subject to: admin1@fnmail.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Feb 27 23:56:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19299 for ; Sat, 27 Feb 1999 23:56:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA25007; Sat, 27 Feb 1999 20:49:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA21004 for ietf-radius-outgoing; Sat, 27 Feb 1999 20:50:46 -0800 (PST) Message-ID: <36FDB3BF.E78AF93B@iea-software.com> Date: Sat, 27 Mar 1999 20:44:47 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Stuart A Barkley CC: ietf-radius@livingston.com Subject: Re: (radius) Zero Length Summary References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit Stuart A Barkley wrote: > > As usual these are my personal opinion, but they all really seem to be > so obvious that I can't argue for them very well. > > Starting with: > > There is a big difference between not having an attribute and having a > null value for the attribute as was shown with the system prompt > example. Heres my opinion on this. For something that has the ability to have a null value (like System prompt), there needs to be another attribute like "Show-System-Prompt" that would say whether to show the system prompt or not. If there is a case where the attribute of zero length has a meaning, its best to have a way to specifically list an on/off state without having to interpret a zero length attribute as off. > Vendor specific attributes may allow zero length attributes. Attribute #26 can not have a zero length value. The actual content of the data of attribute 26 is not defined, although its recommended to also be in AVP type format. > Gives: > > Zero length values need to be supported by the base radius transport > protocol. I don't equate the VSA contents to the base radius transports. Looking at the RFC: > The String field is one or more octets. The actual format of the > information is site or application specific, and a robust > implementation SHOULD support the field as undistinguished octets. Therefore, I don't see how you can even assume that the VAS has a length in it. Several VSA implementations don't even have a length octet in the data of attribute #26. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 08:26:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17477 for ; Mon, 1 Mar 1999 08:26:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id FAA19325; Mon, 1 Mar 1999 05:19:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA07532 for ietf-radius-outgoing; Mon, 1 Mar 1999 05:20:04 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Mon, 01 Mar 1999 13:55:24 +0200 MR-Received: by mta BTMV98; Relayed; Mon, 01 Mar 1999 13:55:25 +0200 MR-Received: by mta BTMA06; Relayed; Mon, 01 Mar 1999 13:58:15 +0200 Disclose-recipients: prohibited Date: Mon, 01 Mar 1999 13:55:24 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) More detail on Proxy In-reply-to: <199902261725.JAA15126@server.livingston.com> To: ietf-radius Message-id: <3224551301031999/A25219/BTMV98/11D30B771600*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D30B771600 X400-MTS-identifier: [;3224551301031999/A25219/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT [snipped a lot] >The forwarding server MAY add one Proxy-State attribute to the packet. >If it does, the Proxy-State MUST appear after any other Proxy-States in >the packet. The forwarding server MUST NOT modify any other >Proxy-States that were in the packet and MUST NOT change the order of >any attributes of the same type, including Proxy State. >4. The forwarding server verifies the Response Authenticator using the >secret it shares with the remote server, and silently discards the >packet if it fails verification. If the packet passes verification, >the forwarding server removes the last Proxy-State (if it attached >one), signs the Response Authenticator using the secret it shares with >the NAS, restores the Identifier to match the one in the original >request by the NAS, and sends the access-accept to the NAS. > >A forwarding server may need to modify attributes to enforce local >policy. Such policy is outside the scope of this document, with the >following restrictions. A forwarding server MUST not modify existing >Proxy-State, State, or Class attributes present in the packet. > The above contains a number of proxy implementation guidelines whereas RADIUS should only care about the interface (RADIUS) between clients, proxies and servers. Example 1: Proxy-State RADIUS requirement: A server must reply to a client with the same Proxy-State attributes (and in the same order?) as it received in the request. Server implementation: 1. as in the proposed text 2. the server stores the received Proxy-States but does not forward them to the next hop server. The server retrieves the Proxy-States when replying to the client. 3. ? Example 2: Class RADIUS requirement: A client must send the same Class attributes (and in the same order?) in Accounting-Requests as it received in Access-Accept. Client implementation: 1. similar to propsed text (forward all to next-hop client) 2. the client stores the received Classes but does not forward them to the next-hop client. The client retrieves the Classes when forwarding Accounting-Requests to the next-hop server. 3. ? Requiring the Class and Proxy-State attributes to be passed on end-to-end is something that was discussed in the ROAMOPS workgroup long ago, and had to do with auditing in roaming environments. As far as I know, this was recommended in such roaming environments as a policy, but should not be a RADIUS protocol requirement. regards, Marc. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 09:39:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18314 for ; Mon, 1 Mar 1999 09:39:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA20566; Mon, 1 Mar 1999 06:32:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA09948 for ietf-radius-outgoing; Mon, 1 Mar 1999 06:35:53 -0800 (PST) Date: Mon, 1 Mar 1999 09:35:39 -0500 (EST) From: Jeff Weisberg Message-Id: <199903011435.JAA21619@sulcus.op.net> To: ietf-radius@livingston.com Subject: Re: (radius) More detail on Proxy Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jeff Weisberg | RADIUS requirement: | A server must reply to a client with the same Proxy-State attributes (and in | the same order?) as it received in the request. | | Server implementation: [...] | 2. the server stores the received Proxy-States but does not forward them to the | next hop server. The server retrieves the Proxy-States when replying to the | client. someone last week mentioned that their implementation did this. it has been (uncomfortably) sitting in my mind. I do not like it. I use Proxy-State for 2 things, (1) loop detection, and (2) debugging. this defeats both (loop detection being the more important) --jeff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 09:39:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18324 for ; Mon, 1 Mar 1999 09:39:50 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA20558; Mon, 1 Mar 1999 06:32:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA09928 for ietf-radius-outgoing; Mon, 1 Mar 1999 06:35:34 -0800 (PST) Date: Mon, 1 Mar 1999 09:35:01 -0500 (EST) From: Jeff Weisberg Message-Id: <199903011435.JAA21616@sulcus.op.net> To: ietf-radius@livingston.com Subject: Re: (radius) Zero Length Summary Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jeff Weisberg | Heres my opinion on this. For something that has the ability to | have a null value (like System prompt), there needs to be another | attribute like "Show-System-Prompt" that would say whether to show | the system prompt or not. If there is a case where the attribute | of zero length has a meaning, its best to have a way to specifically | list an on/off state without having to interpret a zero length | attribute as off. so if I understand what you just said, (a) you do see a real and valid use for zero length values (b) instead of using a zero length value, you advocate using 2 attributes to convey the information I need to ask then, if there is clearly a valid use for such a thing, what is so abhorent that should be avoided at such costs? --jeff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 09:54:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18515 for ; Mon, 1 Mar 1999 09:54:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA20955; Mon, 1 Mar 1999 06:47:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA10462 for ietf-radius-outgoing; Mon, 1 Mar 1999 06:50:26 -0800 (PST) Date: Mon, 1 Mar 1999 09:50:11 -0500 (EST) From: Jeff Weisberg Message-Id: <199903011450.JAA21628@sulcus.op.net> To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jeff Weisberg | Why bother to provide both? Either identifies the NAS, so what's the | good of carrying redundant information in the request? well, since I send both, I guess I'll say what/why. when I proxy a request off, I figure that the NAS address and FQDN are fairly meaningless to the remote ISP, so I set the NAS-ID to something along the lines of "OpNet Philadelphia NAS #4", as a convenience aid. --jeff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 10:15:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19400 for ; Mon, 1 Mar 1999 10:15:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA21467; Mon, 1 Mar 1999 07:08:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA11488 for ietf-radius-outgoing; Mon, 1 Mar 1999 07:11:16 -0800 (PST) Message-Id: <199903011511.KAA25513@server1.btna.com> From: "Mun, Mike" To: ietf-radius@livingston.com, Jeff Weisberg Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Mon, 1 Mar 1999 10:06:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE63F5.BD2FD470" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mun, Mike" 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_000_01BE63F5.BD2FD470 Content-Type: text/plain Both NAS IP and NAS Id do not give any better way to identify a NAS if private NAS IP addresses can be used. I propose a structure way such as 1.1.1.1@isp.com for NAS ID to identify a NAS in global scope. Mike ---------- From: Jeff Weisberg [SMTP:jaw@Op.Net] Sent: Monday, March 01, 1999 9:50 AM To: ietf-radius@livingston.com Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP address | Why bother to provide both? Either identifies the NAS, so what's the | good of carrying redundant information in the request? well, since I send both, I guess I'll say what/why. when I proxy a request off, I figure that the NAS address and FQDN are fairly meaningless to the remote ISP, so I set the NAS-ID to something along the lines of "OpNet Philadelphia NAS #4", as a convenience aid. --jeff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. ------_=_NextPart_000_01BE63F5.BD2FD470 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgsPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQBIAAAAUkU6IChyYWRpdXMpIE1hdGNoaW5nIE5BUy1JUC1B ZGRyZXNzIHRvIGFjdHVhbCByZWFsLWxpZmUgTkFTIElQIGFkZHJlc3MAvxcBCYABACEAAABFQTZG NDBBQ0I1Q0ZEMjExOTJFNTAwQUEwMDA5MjhEMQAxBwEggAMADgAAAM8HAwABAAoACwAKAAEA+gAB BYADAA4AAADPBwMAAQAKAAYACAABAPMAAQ2ABAACAAAAAgACAAEDkAYApAsAABwAAABAADkAwGlj CfVjvgEeAHAAAQAAAEQAAAAocmFkaXVzKSBNYXRjaGluZyBOQVMtSVAtQWRkcmVzcyB0byBhY3R1 YWwgcmVhbC1saWZlIE5BUyBJUCBhZGRyZXNzAAIBcQABAAAAGwAAAAG+Y/MFlXd6FdbPBRHSiL4A oMmFRdYAACxIIAACAQkQAQAAAC4IAAAqCAAAgBEAAExaRnXXxnX6AwAKAHJjcGcxMjVyMgxgYzED MAEHC2BukQ4QMDMzDxZmZQ+STwH3AqQDYwIAY2gKwHOEZXQC0XBycTIAAJIqCqFubxJQIDAB0IUB 0DYPoDA1MDQUIfMB0BQQNH0HbQKDAFAD1PsR/xMLYhPhFFATshj0FNB/BxMV5A/AFl8XbxyfHMB9 4Qawc3RlbQKAApEI5qo7CW8wHx9lDjA1IEr/IWEhHyIpIDQiUiC/JI8kTc8jzyH/IE8QYDI4Khor Mf8q7yv5IDQsIiqPLl8uHS2f+yvPL5Q5DlAy5DRBLGM0QFMCgh4AeWwHkGgJ4HTDAAAD8GRjdGwK sQBgmGRqdR4ABRBnaAVCOxYyDAFjCcA2gAMwc258ZXgbYAewBbAAwAJzc7EAUHNiMhRQNaBhE/D0 XGsJ4HALkDZ4CGA2sPULgGU14HY8IAFANxsMMN835CxAOsAEoAuAZywxOGb0YmEbQGQCIDkgOMY2 EPM3ED5RIDE1cw5QOh87L/88MwBRPLwAoDfuPz9ARjVk/w/AQU9CXzwzDlA8r0UPRh/tQHMzAoIT EGM54EzhNxBJQHB0aTxQIEQBEGFUdWwFQFAKwGEJwGFwcGggRgIhOaQpgGb0aS0PkDgBQDvwUXM2 eHpiCyByCVBS0hrQUtJ39jQpgRswcAHQTrI3P0vf30zmURBP0AUQAjAtUHADYRA6IFRvWDBTdWJK agWQdFgwRGEeEDr9OaQ2UT9ST1NfVG42AEBjvw4hTOE9dg5QVe9W/lI8QbkbMSBIQFEEkDmkN1nv /1r/XA9M4TvPXX8PkBzACNDyYgqwdDhLOg9USBBff89ghmkAYZALUHkvUIBccPsLEWIFczmkLEBi /2QPZR9/VH9Vj2sfbCpYUlf0WSk5dzZvcYVoszlx33LveCBE+G9jdQeAAjAF0FBAThaPcORO9Qxg CVBjZjJ5KLFOkUh5cASQZnFrHkHNAVUzSHF2YW93dpBvkf0BgG5YsABgCfBO4HqAAgH7OWBeEmUA 8HqANcB94A5Q0nYIkHdrC4BkakCB4v8E8AdAEGEBQA4Ab2JAQoNF/QIQbwVCG1ES8h4RC1EeEKAg QzpcXFeAb1Ah3m1QcAMQB5CF8E0N4ANg5HNvAYAgTwEgDeCBMFpch6ZFAMADEC5MsHTffnAbQHaQ OKFmcnhIMYliPU90YwMgEvMAgAWQbHb/Q6FI0A5wOWCLQgGQACCL0v+CMXrBAcGLQRsQD3AAAEjQ 8wzQAZAgLh5SizgOUIvy/0+wNvCMb41/jo8PwEjQBYG3kC+RP5JPbGpASNBsj+/7lK+VtSmOvCmA k4+Yb5Wk+GIgKAKRmY+Lg1nQlz//m/+dD54fi7Bi0J9ijD+gz/+h3468LECfb6Tvpf+nD4uw/3ZA o++pf6qPq5QK+QMwdm8zcZ84kXtChIBQYE5B8QXwSVAgAHA4oLPjOKBtTLAgE1AFQGdPIgBweXwg YhtQHhAFwGyQteB0/7UQsUB6wQaQteCWALPiBpD+IBdwTyCFkrPmTuAfMAQQbweRgtADoLYAILIA CYAu5iC0ELfxb3ATYpYAshHdDnB0CHATgLZycw5wUGDNTIAgApIIkGxkEvIPQA9AcR4AiwBiAFlQ RVJgTElOSyCIsrawOpQxLr8DQAQAcC4FoNeGcAKQEvJkWTBhvMM9UQMLgA4gNyAA0MnqAHn5us4R jIIAgKoAS6kLAgDCoIoXwqEQwqExAC7DSYBAAGkAcwBww2GgYwBvAG3CoeDBrRfDcMKgxRBhxEFs AHT9xOE6w0/EXh5QApK88Bswv0+xCMEL8nyVvw3JciCAsd2z1ES2r7exA6BnCQBMcOcDIATwurBl LgqFCoWwVPuxH7Ile4cASKC6UM8/0EN/ZnB+9dDPyiM4cjkgEvJiyGtta61jIF97AAMQ8VkhYX0t 15fPq7C2Yr3+NEghbs9v32YPZx9oL2k/J2pG1YdX9CBKAREgVxZlBAC2AHJAoFtTTQBUUDpqYXdA T/O/oAfAdF3YP9lEbbvaf3/bj3Cvsm/VeAZgAjDiYU1TAiDAYHksevFyvDEwjjHscDQw7UAgOTpe oTxBTQqFWFLNMBtQZi33UABAcOmQQN1AgeAPcB4AvwIgv7IKhViXYYFYMCjvBLYpevGK0GhAgrPh LbQg/C1BuQTNAgDQu4DOoR8w/QdALd1AEFC4fQKRPXIPwP/VpeSPsPLTz+l/svjPptWH9dJsfOLQ aLXhs6G2Qc0Rr7qRgeABAP0jP7pQRU8A//1ituUIkPORNhCz0uxwh1CztmAbEHQn/8P8Z2eEcMc4 oIdguYFycnlAgh8xvnXsMXrRC4CAslkwaRDgt84i/+IfMHEKUB4AP9Js+nfdcGwAUffgh+C6YRxg b7Rh/lLscLpwZwThuXBJXicGMLsgtoEAoi8AoHnvzy0AoB+wumR4t1IEtQIR/mYHgm3QB8C7obOw WTD/1sO45rRDRlFETgWlBeD7E4BPgGnn0LdQerADQD5RNzXh85MEdG2EgAaxU1DvAFMG0gyn8vBE BaXNEYdQ/3qws7BAgoLgTMBAoP/i3UL7uXACISLkEORBT9DycPfAj36Q+NDycLd0IzQi7HDtvGFh BaXwIG7doK3gH7B/BqGIwLow0mwFpYUwftAg/9eQWMCIMNJs2CbuYLnwvZB/WKCCwLgQtgDscB4g iMEgeieIsGrMcEywELDvbSf3tmD+0QWlJxwJ7qoewARF/f5QZLdQAiH/4nqw84BQEN/PENYWBwLW +M+mfcKgJPAAAAMA/T9SAwAAAwAmAAAAAAADADYAAAAAAB4AMUABAAAAFAAAAEJUTkFfVkFSRVNU T04xX01NVU4AAwAaQAAAAAAeADBAAQAAABQAAABCVE5BX1ZBUkVTVE9OMV9NTVVOAAMAGUAAAAAA AgH5PwEAAABmAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPUVYQ0hBTkdFL09VPUJU TkFIVUIxL0NOPVJFQ0lQSUVOVFMvQ049VkFSRVNUT04xL0NOPUJUTkFfVkFSRVNUT04xX01NVU4A AAAeAPg/AQAAAAoAAABNdW4sIE1pa2UAAAAeADhAAQAAABQAAABCVE5BX1ZBUkVTVE9OMV9NTVVO AAIB+z8BAAAAZgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYAAAAvTz1FWENIQU5HRS9PVT1C VE5BSFVCMS9DTj1SRUNJUElFTlRTL0NOPVZBUkVTVE9OMS9DTj1CVE5BX1ZBUkVTVE9OMV9NTVVO AAAAHgD6PwEAAAAKAAAATXVuLCBNaWtlAAAAHgA5QAEAAAAUAAAAQlROQV9WQVJFU1RPTjFfTU1V TgBAAAcwoHK1tvNjvgFAAAgwcNQvvfVjvgEeAD0AAQAAAAUAAABSRTogAAAAAB4AHQ4BAAAARAAA AChyYWRpdXMpIE1hdGNoaW5nIE5BUy1JUC1BZGRyZXNzIHRvIGFjdHVhbCByZWFsLWxpZmUgTkFT IElQIGFkZHJlc3MACwApAAAAAAALACMAAAAAAAMABhC+WAa1AwAHEPcCAAADABAQAAAAAAMAERAB AAAAHgAIEAEAAABlAAAAQk9USE5BU0lQQU5ETkFTSURET05PVEdJVkVBTllCRVRURVJXQVlUT0lE RU5USUZZQU5BU0lGUFJJVkFURU5BU0lQQUREUkVTU0VTQ0FOQkVVU0VESVBST1BPU0VBU1RSVUNU VQAAAAAuJw== ------_=_NextPart_000_01BE63F5.BD2FD470-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 10:29:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21035 for ; Mon, 1 Mar 1999 10:29:58 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA22331; Mon, 1 Mar 1999 07:23:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA12321 for ietf-radius-outgoing; Mon, 1 Mar 1999 07:26:22 -0800 (PST) Message-Id: <3.0.5.32.19990301102644.03943100@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 01 Mar 1999 10:26:44 -0500 To: Carl Rigney From: Dave Mitton Subject: Re: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Cc: ietf-radius@livingston.com In-Reply-To: <199902262111.NAA12615@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton Because as a client implementation, I want to be able to support a Server that uses either. If a server only supports one or the other, then I won't work with half the servers. If all servers have to support both, because no client can support both, then I would submit that either we decide on one to be REQUIRED and the other OPTIONAL and be done with it. I don't understand why the current state of things is so wishy-washy. If identification is required pick one that works, or allow both, and let the servers sort it out. Dave. At 01:11 PM 2/26/99 -0800, Carl Rigney wrote: >Why bother to provide both? Either identifies the NAS, so what's the >good of carrying redundant information in the request? > >But I'd be OK with softening the not recommended to a "think about >whether you really want to carry redundant info" or omitting it >altogether, depending on how people feel. > >-- >Carl >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 10:45:53 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21666 for ; Mon, 1 Mar 1999 10:45:52 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA23204; Mon, 1 Mar 1999 07:38:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA13260 for ietf-radius-outgoing; Mon, 1 Mar 1999 07:40:00 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF6251@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Mun, Mike'" , Jeff Weisberg , ietf-radius@livingston.com Subject: RE: (radius) Matching NAS-IP-Address to actual real-life NAS IP a ddress Date: Mon, 1 Mar 1999 10:36:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Mun, Mike [mailto:Mike.Mun@BTNA.com]: >Both NAS IP and NAS Id do not give any better way to identify a NAS if >private NAS IP addresses can be used. I propose a structure way such as >1.1.1.1@isp.com for NAS ID to identify a NAS in >global scope. I fail to see why the RADIUS protocol WG needs to define internal structure of the NAS-ID attribute in order to enhance communication between administrative domains. I do not see that as a RADIUS protocol issue. The RADIUS protocol says, here is an attribute and its on-the-wire format. Contents and administrative use of that attribute WITHIN a single scope should be left up to the operator. I don't see how anybody would argue with that: within a single administrative domain, an operator can stuff whatever they want to in there and interpret it however they operationally see fit. If they want to use NAS-IP-Ads or use some implementation specific code that is meaningless outside, so be it. Contents and administrative us of that attribute BETWEEN scopes, IMHO, belong elsewhere, like roamops. + Mark Anthony Beadles + MCI WorldCom + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 13:10:03 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25293 for ; Mon, 1 Mar 1999 13:10:02 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA01676; Mon, 1 Mar 1999 10:01:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA00113 for ietf-radius-outgoing; Mon, 1 Mar 1999 10:04:19 -0800 (PST) Date: Mon, 1 Mar 99 13:00:45 EST From: David Bolen To: Jeff Weisberg Cc: ietf-radius@livingston.com Subject: Re: (radius) More detail on Proxy In-Reply-To: Your message of Mon, 1 Mar 1999 09:35:39 -0500 (EST) Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: David Bolen Jeff Weisberg writes: > I use Proxy-State for 2 things, (1) loop detection, and (2) debugging. But Proxy-State is geared for saving state from a proxy server across a forwarded request to the next server in line, so the only hard requirement on it is that it be included unmodified in the response from that next hop server. While your implementation is certainly free to impose other uses on the attribute, I don't think it should force implementation requirements on other implementations other than that specified in the RFC. While we could redefine the attribute to enforce its inclusion in all forwarded packets, I think that would be stretching its purpose too far. > this defeats both (loop detection being the more important) There are other methods to do both as well, which is an implementation choice. Loop detection based strictly on Proxy-State makes too many assumptions, to my mind, not all of which are RADIUS based. What if the set of domains performing authentication are not all RADIUS? Crossing a non-RADIUS domain is certainly likely to keep all the important aspects of a request (username, password, etc..), but if it loops around back to you it's unlikely to maintain something like the original Proxy-State attributes as it will be a re-formed request from the edge of the non-RADIUS domain. But if you specifically want to do it based on an attribute, then perhaps it would be better (safer across multiple implementations) to insert your own vendor-specific attribute and use that. That way you wouldn't depend on semantics for an attribute like Proxy-State that isn't required by the protocol. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 13:38:46 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26063 for ; Mon, 1 Mar 1999 13:38:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA02697; Mon, 1 Mar 1999 10:30:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA03195 for ietf-radius-outgoing; Mon, 1 Mar 1999 10:33:25 -0800 (PST) Message-ID: <36DADD6A.6F20F6C2@iea-software.com> Date: Mon, 01 Mar 1999 10:33:14 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jeff Weisberg CC: ietf-radius@livingston.com Subject: Re: (radius) Zero Length Summary References: <199903011435.JAA21616@sulcus.op.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit Jeff Weisberg wrote: > > | Heres my opinion on this. For something that has the ability to > | have a null value (like System prompt), there needs to be another > | attribute like "Show-System-Prompt" that would say whether to show > | the system prompt or not. If there is a case where the attribute > | of zero length has a meaning, its best to have a way to specifically > | list an on/off state without having to interpret a zero length > | attribute as off. > > > so if I understand what you just said, > (a) you do see a real and valid use for zero length values > (b) instead of using a zero length value, you advocate > using 2 attributes to convey the information > > I need to ask then, if there is clearly a valid use for such a thing, > what is so abhorent that should be avoided at such costs? By using two attributes you remove the ambiguity of a the definition. In this case, send Show-System-Prompt=No rather than Sysetem-Prompt with a AVP length of zero is still only sending one attribute, not two. This was just an example of clearly defining a behavior rather than trying to interpret a possible confusing situation. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 13:44:03 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26180 for ; Mon, 1 Mar 1999 13:44:02 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA02976; Mon, 1 Mar 1999 10:36:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA04035 for ietf-radius-outgoing; Mon, 1 Mar 1999 10:40:01 -0800 (PST) Message-ID: <36DADEF7.97247117@iea-software.com> Date: Mon, 01 Mar 1999 10:39:51 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: MARC DE VRIES WE41/KT CC: ietf-radius Subject: Re: (radius) More detail on Proxy References: <3224551301031999/A25219/BTMV98/11D30B771600*@MHS> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit MARC DE VRIES WE41/KT wrote: > > Example 1: Proxy-State > > RADIUS requirement: > A server must reply to a client with the same Proxy-State attributes (and in > the same order?) as it received in the request. I'd like to see some added clarity on order here. There are some current interoperatability issues with whether Proxy-State must be returned before the other attributes or not. I know this is a RADIUS RFC and not proxy, but people still base Proxy implementations soley on this RFC and a little extra definition goes a long way... > Server implementation: > 1. as in the proposed text > 2. the server stores the received Proxy-States but does not forward them to the > next hop server. The server retrieves the Proxy-States when replying to the > client. I don't think either are incorrect. > Example 2: Class > > RADIUS requirement: > A client must send the same Class attributes (and in the same order?) in > Accounting-Requests as it received in Access-Accept. > > Client implementation: > 1. similar to propsed text (forward all to next-hop client) > 2. the client stores the received Classes but does not forward them to the > next-hop client. The client retrieves the Classes when forwarding > Accounting-Requests to the next-hop server. > 3. ? I don't think this is the same. A client doesn't proxy a request, a server does. I would assume that in proxy, receiving a CLASS attribute in the Accounting Request means that is MUST be forwarded. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 13:58:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26578 for ; Mon, 1 Mar 1999 13:58:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA03548; Mon, 1 Mar 1999 10:50:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA05610 for ietf-radius-outgoing; Mon, 1 Mar 1999 10:53:39 -0800 (PST) Date: Mon, 1 Mar 99 13:50:12 EST From: David Bolen To: "Dale E. Reed Jr." Cc: ietf-radius Subject: Re: (radius) More detail on Proxy In-Reply-To: Your message of Mon, 01 Mar 1999 10:39:51 -0800 Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: David Bolen "Dale E. Reed Jr." writes: > I'd like to see some added clarity on order here. I think that order should be enforced (as is true of all like attributes in a packet) but that order when compared to other attributes need not be maintained. In other words, treat them as other attributes are treated. If we want extra text here, we can just reinforce the general behavior description. > Server implementation: > 1. as in the proposed text > 2. the server stores the received Proxy-States but does not forward them to the > next hop server. The server retrieves the Proxy-States when replying to the > client. > I don't think either are incorrect. For (1) are you saying that Carl's initial text was incorrect? While not how I've implemented things, it seemed to me his approach was ok. For (2), it seems to me to satisfy the RFC requirements just fine. It's just an implementation suggestion, not a requirement. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 14:05:43 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26848 for ; Mon, 1 Mar 1999 14:05:42 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA03815; Mon, 1 Mar 1999 10:57:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA06525 for ietf-radius-outgoing; Mon, 1 Mar 1999 11:00:48 -0800 (PST) Message-ID: <36DAE3D7.E2C44D1@iea-software.com> Date: Mon, 01 Mar 1999 11:00:39 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: David Bolen CC: ietf-radius Subject: Re: (radius) More detail on Proxy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit David Bolen wrote: > > > I'd like to see some added clarity on order here. > > I think that order should be enforced (as is true of all like > attributes in a packet) but that order when compared to other > attributes need not be maintained. In other words, treat them as > other attributes are treated. If we want extra text here, we can just > reinforce the general behavior description. Some implementations require Proxy-State to be before the reply attributes, which is causing problems with us because we attach Proxy-State at the end. > > Server implementation: > > 1. as in the proposed text > > 2. the server stores the received Proxy-States but does not forward them to the > > next hop server. The server retrieves the Proxy-States when replying to the > > client. > > I don't think either are incorrect. > > For (1) are you saying that Carl's initial text was incorrect? While > not how I've implemented things, it seemed to me his approach was ok. No. > For (2), it seems to me to satisfy the RFC requirements just fine. > It's just an implementation suggestion, not a requirement. It actually could be a way to kee the packets small, especially over many-hop requests. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 14:18:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27159 for ; Mon, 1 Mar 1999 14:18:50 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA04327; Mon, 1 Mar 1999 11:11:21 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA07974 for ietf-radius-outgoing; Mon, 1 Mar 1999 11:14:27 -0800 (PST) Date: Mon, 1 Mar 99 14:10:56 EST From: David Bolen To: "Dale E. Reed Jr." Subject: Re: (radius) More detail on Proxy In-Reply-To: Your message of Mon, 01 Mar 1999 11:00:39 -0800 Cc: ietf-radius Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: David Bolen "Dale E. Reed Jr." writes: > Some implementations require Proxy-State to be before the reply > attributes, which is causing problems with us because we attach > Proxy-State at the end. We had a recent thread on that right? I think the general agreement was that those implementations were broken. Clearly that sort of behavior has never been required by the RFC nor could be assumed by an implementation. I do agree that if such implementations do exist, having a comment specifically highlighting such an assumption as incorrect could be a good thing, although it's unfortunate since it's already existing attribute behavior in general, so an implementation writer that made that mistake might already not be paying close attention to the RFC :-) I don't think I'd want to require any sort of support for interoperability with such an implementation, however, in general. If you're stuck with an unchangeable peer that you must work with, then some sort of configurable option or behavior change in your implementation is probably the only way out. I'd see changes such as this as specific workarounds for interoperability with broken implementations, of which there might be any number of similar problems depending on the implementation in question. For example, I had to implement a configurable option to avoid NULs in my Proxy-State attributes in order to interoperate with older Livingston/Merit code (not sure about the latest stuff) since they NUL-terminated all string attributes internally. Clearly that wasn't implied by the RFC, nor would I make having such an option a requirement for any implementation, but I needed it in the real world. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 14:26:19 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27342 for ; Mon, 1 Mar 1999 14:26:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA04616; Mon, 1 Mar 1999 11:18:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA08700 for ietf-radius-outgoing; Mon, 1 Mar 1999 11:21:38 -0800 (PST) Message-Id: <199903011922.OAA25616@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius Subject: Re: (radius) More detail on Proxy In-reply-to: Your message of "Mon, 01 Mar 1999 11:00:39 PST." <36DAE3D7.E2C44D1@iea-software.com> Date: Mon, 01 Mar 1999 14:22:06 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok "Dale E. Reed Jr." wrote: > Some implementations require Proxy-State to be before the reply > attributes, which is causing problems with us because we attach > Proxy-State at the end. Some implementations are hard-coded to look for attributes in a certain order, at certain places. e.g. first user-name, then password, then others. Such implementations are wrong. The RFC does NOT specify where the attributes are placed in a packet. If I wanted a hard-coded non-extensible machine-dependent data structure, I'd ask for one. No thanks. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 15:25:23 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29647 for ; Mon, 1 Mar 1999 15:25:22 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA07196; Mon, 1 Mar 1999 12:18:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA14346 for ietf-radius-outgoing; Mon, 1 Mar 1999 12:20:59 -0800 (PST) Message-ID: <36DAF6A1.72176093@iea-software.com> Date: Mon, 01 Mar 1999 12:20:50 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: David Bolen CC: ietf-radius Subject: Re: (radius) More detail on Proxy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit David Bolen wrote: > > > Some implementations require Proxy-State to be before the reply > > attributes, which is causing problems with us because we attach > > Proxy-State at the end. > > We had a recent thread on that right? I think the general agreement > was that those implementations were broken. Clearly that sort of > behavior has never been required by the RFC nor could be assumed by an > implementation. Yes we did. However, I still wasn't able to pursuade the vendor that they were incorrect, because the RFC doesn't say that (I know, I know...). I just thought a quick one liner who save us from this in the future. > I do agree that if such implementations do exist, having a comment > specifically highlighting such an assumption as incorrect could be a > good thing, although it's unfortunate since it's already existing > attribute behavior in general, so an implementation writer that made > that mistake might already not be paying close attention to the RFC :-) They say that the current RFC to is vague for Proxy behavior and the generic attribute description doesn't pertain to proxy. > I don't think I'd want to require any sort of support for > interoperability with such an implementation, however, in general. If > you're stuck with an unchangeable peer that you must work with, then > some sort of configurable option or behavior change in your > implementation is probably the only way out. Thats what we are working on right now. > I'd see changes such as this as specific workarounds for > interoperability with broken implementations, of which there might be > any number of similar problems depending on the implementation in > question. For example, I had to implement a configurable option to > avoid NULs in my Proxy-State attributes in order to interoperate with > older Livingston/Merit code (not sure about the latest stuff) since > they NUL-terminated all string attributes internally. Clearly that > wasn't implied by the RFC, nor would I make having such an option a > requirement for any implementation, but I needed it in the real world. The more of the known implementation problems that are causing interoperability issues we can document and state, the better the protocol will be in the future. -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 15:51:05 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00511 for ; Mon, 1 Mar 1999 15:51:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA08045; Mon, 1 Mar 1999 12:42:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA16799 for ietf-radius-outgoing; Mon, 1 Mar 1999 12:45:54 -0800 (PST) Date: Mon, 1 Mar 99 15:42:25 EST From: David Bolen To: "Dale E. Reed Jr." Subject: Re: (radius) More detail on Proxy In-Reply-To: Your message of Mon, 01 Mar 1999 12:20:50 -0800 Cc: ietf-radius Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: David Bolen "Dale E. Reed Jr." writes: > Yes we did. However, I still wasn't able to pursuade the vendor > that they were incorrect, because the RFC doesn't say that (I know, > I know...). I know you know, but the RFC _does_ say that - or rather it explicitly specifies a rule that does not require that behavior so I can't see how anyone would read the lack of further clarification as explicitly setting out the rule (e.g., its not MUST in the RFC...) > I just thought a quick one liner who save us from > this in the future. I guess the only general comment is that I don't think we should expect to have to include statements within the RFC on every way that you can break the RFC soley to state those approaches as bad. > They say that the current RFC to is vague for Proxy behavior and > the generic attribute description doesn't pertain to proxy. Hmm - I guess I think they're sniffing funny stuff when they are reading the RFC. General attribute behavior is just that - general, and that's why it's in the general discussion of attributes right up near the front of the RFC. Not requiring the order of attributes of different types to be preserved seems pretty clear. So unless text explicitly excluded Proxy-State from the earlier discussion (which it doesn't, that I can see), they have no reason to believe it is not covered. Besides which, without such a clause, clearly making such a limiting assumption about Proxy-State is a bad implementation practice. But of course I'm talking to the choir - unless maybe they read this list too :-) > The more of the known implementation problems that are causing > interoperability issues we can document and state, the better > the protocol will be in the future. In general I agree, although I'm not sure how cluttered I'd want the protocol RFC to become with stuff like this. Perhaps a separate usage document, or something documenting the results of interoperability testing, gotchas discovered, etc.. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 17:49:30 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04053 for ; Mon, 1 Mar 1999 17:49:30 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA14170; Mon, 1 Mar 1999 14:42:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA29979 for ietf-radius-outgoing; Mon, 1 Mar 1999 14:45:30 -0800 (PST) Date: Mon, 1 Mar 99 14:42:10 PST From: William "Chops" Westfield To: Carl Rigney Cc: ietf-radius@livingston.com Subject: Re: (radius) Closing loopholes In-Reply-To: Your message of Thu, 25 Feb 1999 13:05:25 -0800 (PST) Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William "Chops" Westfield I suppose our thorniest incompatibilities have shown up when trying to map our (non-flat) interface naming scheme into the puny 16 bits that the radius spec allows for NAS-Port. Aside from being difficult to start with, there is no standard and little agreement on how to do this, even supposing that everyone has flat numbering of T1lines and channels therein... Throw in another address space (most recently, PPP over ATM) and it becomes next to impossible... 1) Guidelines in this area would help 2)) 32 bits would help more 3) A string would be even nicer BillW - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 18:12:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04585 for ; Mon, 1 Mar 1999 18:12:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA15122; Mon, 1 Mar 1999 15:05:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA02850 for ietf-radius-outgoing; Mon, 1 Mar 1999 15:08:30 -0800 (PST) Message-ID: <36DB1D1A.6EE1@ascend.com> Date: Mon, 01 Mar 1999 15:04:58 -0800 From: Bill Webb Organization: Ascend Engineering X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5.1 i86pc) MIME-Version: 1.0 To: William Chops Westfield CC: Carl Rigney , ietf-radius@livingston.com Subject: Re: (radius) Closing loopholes References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Bill Webb Content-Transfer-Encoding: 7bit William Chops Westfield wrote: > > I suppose our thorniest incompatibilities have shown up when trying to > map our (non-flat) interface naming scheme into the puny 16 bits that the > radius spec allows for NAS-Port. Aside from being difficult to start with, > there is no standard and little agreement on how to do this, even supposing > that everyone has flat numbering of T1lines and channels therein... Throw > in another address space (most recently, PPP over ATM) and it becomes next > to impossible... > 1) Guidelines in this area would help > 2)) 32 bits would help more > 3) A string would be even nicer > > BillW Yes, having a NAS-Portname string Attribute would be a big win rather than attempting to contort existing naming structures into 16 bits or even 32-bits. One can then leave NAS-port for programs that require a integer value, and use NAS-portname when attempting to reconcile accounting records with syslog or with whatever the command line or SNMP reports for the name of the port. Another Bill W (Bill Webb this time). Ascend Communications (but speaking on my own behalf). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 1 18:17:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04685 for ; Mon, 1 Mar 1999 18:17:26 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA15344; Mon, 1 Mar 1999 15:10:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA03468 for ietf-radius-outgoing; Mon, 1 Mar 1999 15:13:31 -0800 (PST) From: Aydin Edguer Message-Id: <199903012311.SAA23351@harlequin.MorningStar.Com> Subject: Re: (radius) Closing loopholes To: ietf-radius@livingston.com Date: Mon, 1 Mar 1999 18:11:31 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > I suppose our thorniest incompatibilities have shown up when trying to > map our (non-flat) interface naming scheme into the puny 16 bits that the > radius spec allows for NAS-Port. It was already agreed that this will be expanded to allow the full 32-bits of NAS-Port, there are just very few vendors who are taking advantage of the change. This change was decided at the Memphis IETF (IETF 38): Date: Thu, 3 Apr 1997 01:50:35 -0800 (PST) Subject: (radius) Agenda for 38th IETF Tue 4/8 15:30-17:30 Allow NAS-Port to use 32 bits, not just 16? Date: Mon, 25 Aug 1997 23:47:40 -0700 (PDT) Subject: (radius) 38th IETF RADIUS Working Group Minutes NAS-Port should be updated to allow use of all 32 bits, not just 16. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 01:48:46 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03915 for ; Tue, 2 Mar 1999 01:48:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA26147; Mon, 1 Mar 1999 22:41:29 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA27652 for ietf-radius-outgoing; Mon, 1 Mar 1999 22:43:21 -0800 (PST) Date: Mon, 1 Mar 1999 22:43:19 -0800 (PST) From: Carl Rigney Message-Id: <199903020643.WAA27646@server.livingston.com> To: billw@cisco.com Subject: Re: (radius) Closing loopholes Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney > 2)) 32 bits would help more The new draft permits 32 bits for NAS-Port. The PM-4 (and I think Ascend's Max, but don't know for sure) breaks that down as: 2 bits for shelf number (extensible into higher-bits) 4 bits for slot number 5 bits for line number (to support future densities) 5 bits for channel number But vendors can use whatever scheme they like. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 03:22:41 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA15528 for ; Tue, 2 Mar 1999 03:22:40 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id AAA27555; Tue, 2 Mar 1999 00:14:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA01007 for ietf-radius-outgoing; Tue, 2 Mar 1999 00:17:16 -0800 (PST) Date: Tue, 2 Mar 1999 00:17:15 -0800 (PST) From: Carl Rigney Message-Id: <199903020817.AAA01000@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) NAS-Port-Id and Framed-IP-Pool Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney In reviewing the archives, the two most-asked-for attributes not already granted are a string alternative to NAS-Port, for NASes that cannot conveniently number their interfaces, and a Framed-IP-Pool string to allow multiple assigned address pools. Do people still think these would be useful, and if so, would they be worth adding to the Extensions draft? Feel free to email me directly or if you prefer, to the mailing list. -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 05:32:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18145 for ; Tue, 2 Mar 1999 05:32:56 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id CAA29256; Tue, 2 Mar 1999 02:26:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA04598 for ietf-radius-outgoing; Tue, 2 Mar 1999 02:26:48 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Tue, 02 Mar 1999 11:11:31 +0200 MR-Received: by mta BTMV98; Relayed; Tue, 02 Mar 1999 11:11:31 +0200 MR-Received: by mta BTMA06; Relayed; Tue, 02 Mar 1999 11:13:56 +0200 Disclose-recipients: prohibited Date: Tue, 02 Mar 1999 11:11:31 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) More detail on Proxy In-reply-to: <36DADEF7.97247117@iea-software.com> To: ietf-radius Message-id: <8831111102031999/A15511/BTMV98/11D312CB1F00*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D312CB1F00 X400-MTS-identifier: [;8831111102031999/A15511/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT >> Example 1: Proxy-State >> >> RADIUS requirement: >> A server must reply to a client with the same Proxy-State attributes (and in >> the same order?) as it received in the request. > >I'd like to see some added clarity on order here. There are some >current >interoperatability issues with whether Proxy-State must be returned >before the other attributes or not. I know this is a RADIUS RFC and >not proxy, but people still base Proxy implementations soley on this >RFC and a little extra definition goes a long way... Implementations currently relying on preservation of Proxy-State ordering are making assumptions that lead to interop issues. However, something may need to be added to RADIUS to allow multiple Proxy-States to go end-to-end. What I mean is, that each proxy in the chain should be able to identify its own Proxy-State. This can be done by disallowing re-ordering of the Proxy-States, or by imposing a structured value containing a NAS-Id (FQDN if you like). I like the ordering best. Requiring the Proxy-State attribute to be placed at the front, back or up-side-down-bent-over does not seem useful, as the relative position of different-type attributes has never been guaranteed (this even forced TAG format attributes to be invented...), and should not be unless it is the only way to make the protocol work. >> Example 2: Class >> >> RADIUS requirement: >> A client must send the same Class attributes (and in the same order?) in >> Accounting-Requests as it received in Access-Accept. >> >> Client implementation: >> 1. similar to propsed text (forward all to next-hop client) >> 2. the client stores the received Classes but does not forward them to the >> next-hop client. The client retrieves the Classes when forwarding >> Accounting-Requests to the next-hop server. >> 3. ? > >I don't think this is the same. A client doesn't proxy a request, a >server does. I would assume that in proxy, receiving a CLASS attribute >in the Accounting Request means that is MUST be forwarded. Replacing 'client' with 'proxy' and 'next-hop-client' with 'NAS' will probably make more sense. If we define closer-to-NAS as downstream, the example becomes: A proxy server stores the Class values received from the upstream proxy/server, and removes them from the Access-Accept when forwarding to the downstream nas/proxy. The proxy then adds the Class values to the Accounting-Request when forwarding to the upstream proxy/server. Anyway, the point is: the proposed text specifies server implementation requirements and enforces a specific policy (end-to-end passing), two things I would not expect to see in a protocol specification unless it is the only way to make the protocol work. regards, Marc. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 11:12:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04199 for ; Tue, 2 Mar 1999 11:12:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA05692; Tue, 2 Mar 1999 08:04:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA18674 for ietf-radius-outgoing; Tue, 2 Mar 1999 08:02:41 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Carl Rigney'" , ietf-radius@livingston.com Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool Date: Tue, 2 Mar 1999 10:59:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Carl Rigney writes... > and a Framed-IP-Pool string > to allow multiple assigned address pools. I guess I missed this one. Could someone please elaborate? I presume the Framed-IP-Pool (or pools) would be assigned to a RADIUS user, in an Access-Accept. I understand well how a NAS might use a pool of IP addresses administered in the NAS for assignment to PPP or SLIP dial-up connections. Unless the "user" is the NAS itself or the dial-up connection is from another NAS or a router, I'm confused as to how the user is going to utilize a pool of addresses. Assuming that the attribute is useful, then I wonder if a string is the right way to encode it. I can think of several ways to describe one or more ranges or collections of IP addresses using ASCII (or UTF-8) strings, each of which would be parsed quite differently in software. This naturally leads to poor interoperability. I have no problems using strings for names and for opaque data structures. I really don't like using strings for transparent data structures unless the encoding format is unambiguously spelled out in the RFC. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 12:03:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05411 for ; Tue, 2 Mar 1999 12:03:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA07653; Tue, 2 Mar 1999 08:55:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA25217 for ietf-radius-outgoing; Tue, 2 Mar 1999 08:59:09 -0800 (PST) Message-Id: <199903021659.LAA20235@server1.btna.com> From: "Mun, Mike" To: "'Carl Rigney'" , ietf-radius@livingston.com, "Nelson, David" Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool Date: Tue, 2 Mar 1999 11:55:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE64CD.F72EED90" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mun, Mike" 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_000_01BE64CD.F72EED90 Content-Type: text/plain; charset="iso-8859-1" Here is what I think a good reason to have Framed-IP-Pool: Some Radius server has resource management for IP addresses which can be full at a time. A NAS can send Framed-IP-Pool as a hint to the server as addition available addresses, the server can response back with these Framed-IP-Pool instead of access reject. If the NAS receives a Framed-IP-Pool in an access accept, it then selects framed-ip-address from its pool. There are the reasons some user wants to use Framed-IP-Address from a particular pool. Access-challenge can give a user selection of server's pool or a NAS pool by user's profile configuration. Mike ---------- From: Nelson, David [SMTP:dnelson@cabletron.com] Sent: Tuesday, March 02, 1999 10:59 AM To: 'Carl Rigney'; ietf-radius@livingston.com Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool Carl Rigney writes... > and a Framed-IP-Pool string > to allow multiple assigned address pools. I guess I missed this one. Could someone please elaborate? I presume the Framed-IP-Pool (or pools) would be assigned to a RADIUS user, in an Access-Accept. I understand well how a NAS might use a pool of IP addresses administered in the NAS for assignment to PPP or SLIP dial-up connections. Unless the "user" is the NAS itself or the dial-up connection is from another NAS or a router, I'm confused as to how the user is going to utilize a pool of addresses. Assuming that the attribute is useful, then I wonder if a string is the right way to encode it. I can think of several ways to describe one or more ranges or collections of IP addresses using ASCII (or UTF-8) strings, each of which would be parsed quite differently in software. This naturally leads to poor interoperability. I have no problems using strings for names and for opaque data structures. I really don't like using strings for transparent data structures unless the encoding format is unambiguously spelled out in the RFC. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. ------_=_NextPart_000_01BE64CD.F72EED90 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgEQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAsAAAAUkU6IChyYWRpdXMpIE5BUy1Qb3J0LUlkIGFuZCBG cmFtZWQtSVAtUG9vbADHDQEJgAEAIQAAADIwNzA0MEFDQjVDRkQyMTE5MkU1MDBBQTAwMDkyOEQx APgGASCAAwAOAAAAzwcDAAIACwA6ADsAAgBdAQEFgAMADgAAAM8HAwACAAsANwAIAAIAJwEBDYAE AAIAAAACAAIAAQOQBgC8DQAAHAAAAEAAOQBAn6JtzWS+AR4AcAABAAAAKAAAAChyYWRpdXMpIE5B Uy1Qb3J0LUlkIGFuZCBGcmFtZWQtSVAtUG9vbAACAXEAAQAAABsAAAABvmTHFD5X2gjX0H0R0oi+ AKDJhUXWAAB/D+AAAgEJEAEAAAB/CgAAewoAABQWAABMWkZ16/NaNwMACgByY3BnMTI1cjIMYGMx AzABBwtgbpEOEDAzMw8WZmUPkk8B9wKkA2MCAGNoCsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdCF AdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQA9T7Ef8TC2IT4RRQE7IY9BTQfwcTFeQPwBZfF28cnxzA feEGsHN0ZW0CgAKRCOaqOwlvMB8fZQ4wNSBK/yFhIR8iKSA0IlIgvySPJE3PI88h/yBPEGAyOCoa KzH/Ku8r+SA0LCIqjy5fLh0tn/srzy+UOQ5QMuQ0QSxjNEBTAoIeAHlsB5BoCeB0wwAAA/BkY3Rs CrEAYJhkanUeAAUQZ2gFQjsWMgwBYwnANoADMHNufGV4G2AHsAWwAMACc3OxAFBzYjIUUDWgYRPw 9FxrCeBwC5A2eAhgNrD1C4BlNeB2PCABQDcbDDDfN+QsQDrABKALgGcsMThm9GJhG0BkAiA5IDjG NhDzNxA+USAxNXMOUDofOy//PDMAUTy8AKA37j8/QEY1ZP8PwEFPQl88Mw5QPK9FD0Yf7UBzMwKC ExBjOeBM4TcQSUBwdGk8UCBEARBhVHVsBUBQCsBhCcBhcHBoIEYCITmkKYBm9GktD5A4AUA78FFz Nnh6YgsgcglQUtIa0FLSd/Y0KYEbMHAB0E6yNz9L399M5lEQT9AFEAIwLVBwA2EQOiBUb1gwU3Vi SmoFkHRYMERhHhA6/TmkNlE/Uk9TX1RuNgBAY78OIUzhPXYOUFXvVv5SPEG5GzEgSEBRBJA5pDdZ 7/9a/1wPTOE7z11/D5AcwAjQ8mIKsHQ4SzoPVEgQX3/PYIZpAGGQC1B5L1CAXHD7CxFiBXM5pCxA Yv9kD2Uff1R/VY9rH2wqWFJX9FkpOXc2b3GFaLM5cd9y73ggRPhvY3UHgAIwBdBQQB5BzQFVM0hx dmFvd3aQb5H9AYBuWLAAYAnwTuB6gAIBuzlgXhJlAPB6gDXAcCLApFx2CJB3awuAZGpA/37CBPAH QBBhAUAOAG9iQEL7gCUCEG8FQhtREvIeEQtRQR4QIEM6XFxXgG+9UCFtUHADEAeQgtBNDeDJA2Bz bwGAIE8BIA3gtX4QXISGRQDAAxAuTLC+dHtQG0B2kDihZnJ4SDF7hkJPdGMDIBLzAIAFkGz+dkOh SNAOcDlgiCIBkAAg/4iyfxF6wQHBiCEbEA9wAADnSNAM0AGQIC4eUogYDlD/iNJPsDbwiU+KX4tv D8BI0G8FgY0Pjh+PL2xqQEjQbPeMz5GPkpUpi5wpgJBvlU/xkoRiICgCkZZviGNZ0P+UH5jfme+a /4iQYtCcQokf/52vnr+LnCxAnE+hz6Lfo+//iJB2QKDPpl+nb6h0CvkDMLd2b3GfOJF7YhAfMCAE AAwgdxsQBUBJIHRo6QuAayCS4GeBUDigHzDXTIACILFQb0AwYU8xV/CDg0AJgC1JUC1QgVBsbDoK hQqFUwNwE4BS60BhruAgG0ByYbGywQQg7x8whDAIcITAIAOBUBAeIPd6wn2RsTBQsbBO4LZhG0Bf sNIN4FBgf7ADoGITgGY/T6ADILERkuBPEAeALiD6QQewQQXwuRIbQH0wsx3/sbAEIJLgsXEFQLKh sWATgP+1tbxiTuOycbLghaEBoDXg3bgILL0quRK2YXACIBNx/UxwY7GgA/CxYL0iE3G7fbcLgB4B rrAghECxsGOEwO8EER8wWMK6YEnD8L0yuqL/HzCEwE8hvHLCf7GwvoHEJP/EEgUwv9BPAL0iuwI1 4K5A7wQgA1CzQwUgLbgVyZEDcN/IkQQgwRAG8LpgVDYQsJH/CsATgL0ysjS1kbUCruC18b9skAIw BCCyoc1hsxlBylr/kuAKsU8QepALYAXAy1QCkPpBxCMtGwG5oAnwtzC5A/5nTyKS4M1jySS+YsPh tbT5ABBxdYFgvVHLQ8PQvcHzupPVI2J5zVPUiQNgbdDrvxEFoG5t0GcIcFkwvmF9i4B7tHa0HK00 rf+vBXv/g+BIoNndZnB71dr/3AE4VEM5IBLyYmtta6pDII5fewADEFkhYX0t4Tf32dutlmK9NEgh bs9v32YPf2cfaC9pP2pG3ydX9AexbB+yYb/QWSB+wDigW1NNsFRQOmTnAbJhQH+wz78BrwDYkQWg bV3h3+Lk/2275B/lL3Cvr0/fGAZgAjCF7AFUClBzZGF5v9D/ewC2sFBgE6C/0DQw96BAsMgwOjV4 IEFNCoVYUtggJ0MKwAMgUvQgOOCYeSc7sLAbUGYtUAD9tWJA5uB+wA9wHgDuZLSGq1imB/BFWDAo +mQpupL/s7EAILOAOKAAcLteApE9cv8PwN9F7t+t0t1v88+v2NnWn98n+Tmw4ErgHhBzLgaw8bQc PiA8ONDKEAfA/lL/xk8DAg9wB1eyodHRfEC24P9PocoQvxLH8PmS/jHKVctSvwagtByxQNgwxEKx QG0asX8MEbFhxiAQ4LpRgqDmsGy/OKDNEg9hy0A14EyBIOcQ977w1XBZMT8NlxdwxhB6obu9I7t9 KNVxDMP9cHcP0w+5UQu3CpLcdVJBREn+VbrAzWLIgcdj0UXRQshgew+RsUB1quEbMOBA/mF3++cQ vEBoCvHVo9x1DqBLAv/OQs/x1TPD8LfrAsAOoKrA/8OBHzHHQsU2fZHcdQu0erPNsqFQH9DVYlNM t+FAcPF/wC11cNfSOODTkwagXewQVaVAxEK9MiLNYiL/3HWwwcU2yxHnEMPw1XG9Mu8gnwGQsMHP pG6BYMvBGhnP1XPuUObAFwJJJ4NQ1+L/zWH+Mc3zGcK9Ms1jsMGx4O9Ags4STxDm4HrcZhtouBf9 Bt1Bx/B6oCrzsQK9Mlkw/QMRYihBsLLNYbmBv9MBkP+xQBSgGNKwsMPxCZwjdUrk/2yQ1mCyobsw +4B7cMiRGHP/uRKxZNPzYbF/wDOSzfLcdb97cH+gL7GCkBBi1XFt1XD/zHGWEcYR1XH7gNHhIWQb z2e1gAnYurBDSbFAE/JV8FRGLTj9cAmkv8FAUP+44cPhuLQUp9yhDtLUoAZx/za2MbCBoMSArLBs MMdChDLfbJEPgsuwsMG3EHTYQbmg+9ZgELFkzfPLUbRnV6FtIPZvfoBQAGIrgX5gDR+y0/8mwNdS vwF9wDrEPJa3k7cQ37UQxiH+YbeiRABh1KAk4f/g8dx1AwGMsEHhBpEYgrIx+0IiTLEnsSDm4NxQ Rs8kof84cfNQzBF60UlPSlIYsSIX/zQTRvJ9krERMCJH8URQ2DD95rBzQGHzUBmBDBHmsUNHsb0j UkZDBt1hkGdsob+/wLQc7LHcZlWoBEFCumD/7DTsEFg/WLX5MO4V9eA2YHuCIb/BSTQgBta08EDk IG5FXmDm8bXxVli/XSM1nwBQg+CI4IIhx4FSbwLAEdx1KDk3PHE2ODS5bfAzMwBQYJ9hN0F9MO5v teH20bqAMHPg6NDY/9/couHG+NAYsRJwYjdEPRH3hZL5EIWQatVwczA4IPrN9ifBs9x1J2VZ+gpo EB2lvRFAZNZgw+G9MkgRc7chni7ftrsy4Jjcdn0AbjAAAwD9P1IDAAADACYAAAAAAAMANgAAAAAA HgAxQAEAAAAUAAAAQlROQV9WQVJFU1RPTjFfTU1VTgADABpAAAAAAB4AMEABAAAAFAAAAEJUTkFf VkFSRVNUT04xX01NVU4AAwAZQAAAAAACAfk/AQAAAGYAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEA AAAGAAAAL089RVhDSEFOR0UvT1U9QlROQUhVQjEvQ049UkVDSVBJRU5UUy9DTj1WQVJFU1RPTjEv Q049QlROQV9WQVJFU1RPTjFfTU1VTgAAAB4A+D8BAAAACgAAAE11biwgTWlrZQAAAB4AOEABAAAA FAAAAEJUTkFfVkFSRVNUT04xX01NVU4AAgH7PwEAAABmAAAAAAAAANynQMjAQhAatLkIACsv4YIB AAAABgAAAC9PPUVYQ0hBTkdFL09VPUJUTkFIVUIxL0NOPVJFQ0lQSUVOVFMvQ049VkFSRVNUT04x L0NOPUJUTkFfVkFSRVNUT04xX01NVU4AAAAeAPo/AQAAAAoAAABNdW4sIE1pa2UAAAAeADlAAQAA ABQAAABCVE5BX1ZBUkVTVE9OMV9NTVVOAEAABzDAMHoQyWS+AUAACDCQ7S73zWS+AR4APQABAAAA BQAAAFJFOiAAAAAAHgAdDgEAAAAoAAAAKHJhZGl1cykgTkFTLVBvcnQtSWQgYW5kIEZyYW1lZC1J UC1Qb29sAAsAKQAAAAAACwAjAAAAAAADAAYQXHRCAgMABxDlBgAAAwAQEAAAAAADABEQAQAAAB4A CBABAAAAZQAAAEhFUkVJU1dIQVRJVEhJTktBR09PRFJFQVNPTlRPSEFWRUZSQU1FRC1JUC1QT09M OlNPTUVSQURJVVNTRVJWRVJIQVNSRVNPVVJDRU1BTkFHRU1FTlRGT1JJUEFERFJFU1NFU1cAAAAA CU4= ------_=_NextPart_000_01BE64CD.F72EED90-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 14:13:12 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08872 for ; Tue, 2 Mar 1999 14:13:11 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA12623; Tue, 2 Mar 1999 11:04:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA09881 for ietf-radius-outgoing; Tue, 2 Mar 1999 11:08:23 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Dave Mitton'" Cc: "'ietf-radius@livingston.com'" Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool Date: Tue, 2 Mar 1999 14:04:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Dave Mitton writes... > A number of NAS client implementations have IP Address pool allocation > schemes. > This attribute would be a selector for such a pool. > The description of the actual pool contents would be left to other > configuration mechanisms. Ah, I understand. So Framed-IP-Pool is analogous to Filter-ID, a name for a local data structure. The contents of the data structure are created, communicated or configured by some mechanism outside the scope of RADIUS. Cool. I see that this attribute might be of utility. Of course, I've always been left a little unsatisfied by the "some mechanism outside the scope of RADIUS" business. It doesn't do much to promote interoperability. However, since we have already cast the die in terms of the Filter-ID usage, I guess Framed-IP-Pool would be OK on that basis. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 14:16:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08913 for ; Tue, 2 Mar 1999 14:15:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA12491; Tue, 2 Mar 1999 11:03:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA09603 for ietf-radius-outgoing; Tue, 2 Mar 1999 11:06:08 -0800 (PST) Date: Tue, 2 Mar 1999 14:05:15 -0500 (EST) From: "Steven P. Crain" To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) More detail on Proxy In-Reply-To: <199902261725.JAA15126@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Fri, 26 Feb 1999, Carl Rigney wrote: > I'm planning to include the following detailed description of Proxy under > the Operations section in the new Draft (now only hours away). > Comments welcome. > > With proxy RADIUS, one RADIUS server forwards an authentication (or > accounting) request to a remote RADIUS server, and returns its reply to ^^^ unclear antecedant. I think you mean the remote server's reply. Also, this downplays the proxy server's role as gatekeeper. It doesn't necessarily send the reply it got back to the NAS. It is likely to at least tweak it a little, SHOULD do sanity checking on the attributes, and might send back a completely different responce if it likes. Something like "With proxy RADIUS, one RADIUS server forwards an authentication (or accounting) request to a remote RADIUS server, and bases its reply to the network access server (NAS) on the reply it got from the remote RADIUS server" might be more correct. > the network access server (NAS). A common use for proxy RADIUS is > roaming. Roaming permits two or more administrative entities to allow > each other's users to dial in to either entity's network for service. > > The NAS sends its RADIUS access-request to the "forwarding server" > which forwards it to the "remote server." The remote server sends a > response (Access-Accept, Access-Reject, or Access-Challenge) back to > the forwarding server, which sends it back to the NAS. The choice of > which server to forward the request to is based on the authentication > "realm." A realm can either be based on part of the User-Name, for > example the part following an at ("@") sign (a "named realm"), or a > Called-Station-Id (a "numbered realm"), or using whatever other > criteria the forwarding server is configured to use. Frequently, a > fully qualified domain name is used as the named realm to provide > uniqueness. This could be misleading. In my operation, different customers have password entries on different hosts. E.g. User Host george@spandex.com apple sue@spandex.com orange john@nowhere.org apple hello@shore.net orange *@another.net radius.another.net The choice of remote server in our case is based on looking up the host associated with the whole User-Name, not some portion of it. I would change "A realm can either be based on part of the User-Name" to "A realm can either be based on all or part of the User-Name." > A RADIUS server can function as both a forwarding server and a remote > server, serving as a forwarding server for some realms and a remote > server for other realms. One forwarding server can forward to any > number of remote servers. A remote server can have any number of > servers forwarding to it and can provide authentication for any number > of realms. One forwarding server can forward to another forwarding > server to create a chain of proxies, although care must be taken to > avoid introducing loops. > > The following scenario illustrates the communication between a NAS and > the forwarding and remote RADIUS servers: > > 1. A NAS sends its access-request to the forwarding server. > > 2. The forwarding server forwards the access-request to the remote > server. > > 3. The remote server sends an access-accept, access-reject or > access-challenge back to the forwarding server. For this example, > an access-accept is sent. > > 4. The forwarding server sends the access-accept to the NAS. > > A forwarding server may either perform its forwarding function in a > pass through manner, where it sends retransmissions on as soon as it > gets them, or it may take responsibility for retransmissions, for > example in cases where the network link between forwarding and remote > server has very different characteristics than the link between NAS and > forwarding server. > > Extreme care should be used when implementing a proxy server that takes > responsibility for retransmissions so that its retransmission policy is > robust and scalable. > > We now examine each step in more detail. > > The forwarding server MAY add one Proxy-State attribute to the packet. Though it probbaly isn't useful, I would think it could add more than one if the need arose? > If it does, the Proxy-State MUST appear after any other Proxy-States in > the packet. The forwarding server MUST NOT modify any other > Proxy-States that were in the packet and MUST NOT change the order of > any attributes of the same type, including Proxy State. Hmmm, I recall hearing of implementations that *didn't* work like this. One did something to encode the existing Proxy-States, something like "state" -> "nas1.somewhere.org:state" with some provision for handling a state that was too long for the prefix. Isn't the important part that it be able to restore the Proxy-State attributes to their original state in whatever replies it sends back to the NAS? Do we need to make such strict rules when they aren't really necessary for interoperability? > 3. The remote server (if the final destination) verifies the user using > User-Password, CHAP-Password, or such method as future extensions may > dictate, and returns an access-accept, access-reject or > access-challenge back to the forwarding server. For this example, an > access-accept is sent. The remote server MUST copy all Proxy-State > attributes (and only the Proxy-State attributes) in order from the ^^^^ This is unclear. Do you mean "the remote server MUST NOT copy any other attributes" or "the remote server is not required to copy any other attributes?" > access-request to the response packet, without modifying them. > > 4. The forwarding server verifies the Response Authenticator using the > secret it shares with the remote server, and silently discards the > packet if it fails verification. If the packet passes verification, > the forwarding server removes the last Proxy-State (if it attached > one), signs the Response Authenticator using the secret it shares with Or otherwise restores the Proxy-State to what was received from the NAS. > the NAS, restores the Identifier to match the one in the original > request by the NAS, and sends the access-accept to the NAS. > > A forwarding server may need to modify attributes to enforce local > policy. Such policy is outside the scope of this document, with the > following restrictions. A forwarding server MUST not modify existing > Proxy-State, State, or Class attributes present in the packet. A forwarding server might need to do other, more complex manipulations as well. E.g. if the Access-Accept contains unacceptable avps it might want to return a NAK to the NAS. If it gets a NAK it might want to forward the request to another remote server, and so forth. Also, if it changes the response from ACK to NAK, it doesn't make as much sense for it to be required to keep the State & Class attributes intact. I also disagree with the "MUST" re modifying Class and possibly State. In our case, we proxy auth requests to customers, but we do not proxy accounting requests to them. We use the Class attribute to record which account to bill for the session. Obviously, we don't want the customer to be able to send a Class attribute that would conflict with that. Perhaps something similar is needed here as my comments regarding Proxy-State above. Class should not be messed with in an irreversible manner, if the accounting messages will also be proxied. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 14:22:23 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09143 for ; Tue, 2 Mar 1999 14:22:22 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA12940; Tue, 2 Mar 1999 11:14:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA10756 for ietf-radius-outgoing; Tue, 2 Mar 1999 11:16:33 -0800 (PST) Date: Tue, 2 Mar 1999 14:18:37 -0500 (EST) From: "Steven P. Crain" To: "Dale E. Reed Jr." cc: MARC DE VRIES WE41/KT , ietf-radius Subject: Re: (radius) More detail on Proxy In-Reply-To: <36DADEF7.97247117@iea-software.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Mon, 1 Mar 1999, Dale E. Reed Jr. wrote: > > Example 2: Class > > > > RADIUS requirement: > > A client must send the same Class attributes (and in the same order?) in > > Accounting-Requests as it received in Access-Accept. > > > > Client implementation: > > 1. similar to propsed text (forward all to next-hop client) > > 2. the client stores the received Classes but does not forward them to the > > next-hop client. The client retrieves the Classes when forwarding > > Accounting-Requests to the next-hop server. > > 3. ? > > I don't think this is the same. A client doesn't proxy a request, a > server does. I would assume that in proxy, receiving a CLASS attribute > in the Accounting Request means that is MUST be forwarded. As far as the remote server is concerned, the proxy is an NAS. The only requirement on sending Class attributes should be that the remote server requested them in the Access-Accept. So, in general if you add a Class to the Access-Accept, you could safely remove that same Class (and any others that the remote server had not requested) from Accounting messages. That brings up another point -- is a NAS allowed to send Class attributes in Accounting messages that were not requested at Authentication time? That would seem to be an abuse of the intended purpose of the Class attribute, but is basically equivalent to a proxy server not cleaning up after itself and removing Class attributes it had requested from accounting messages it forwards. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 14:29:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09314 for ; Tue, 2 Mar 1999 14:29:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA13253; Tue, 2 Mar 1999 11:21:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA11513 for ietf-radius-outgoing; Tue, 2 Mar 1999 11:24:04 -0800 (PST) Message-ID: <36DC3ACA.F7CA42BA@iea-software.com> Date: Tue, 02 Mar 1999 11:23:54 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Nelson, David" CC: ietf-radius@livingston.com Subject: Re: (radius) NAS-Port-Id and Framed-IP-Pool References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dale E. Reed Jr." Content-Transfer-Encoding: 7bit "Nelson, David" wrote: > > > A number of NAS client implementations have IP Address pool allocation > > schemes. > > This attribute would be a selector for such a pool. > > The description of the actual pool contents would be left to other > > configuration mechanisms. > > Ah, I understand. So Framed-IP-Pool is analogous to Filter-ID, a name > for a local data structure. The contents of the data structure are > created, communicated or configured by some mechanism outside the scope > of RADIUS. Cool. I see that this attribute might be of utility. > > Of course, I've always been left a little unsatisfied by the "some > mechanism outside the scope of RADIUS" business. It doesn't do much to > promote interoperability. However, since we have already cast the die > in terms of the Filter-ID usage, I guess Framed-IP-Pool would be OK on > that basis. Ascend has a good example of this in their pool definition. You could define two pools, one routable and one non-routable (like 192.168.x.x) and then based on whether you want to force the user through a proxy or not, you assign them to the respective pool. It sure beats defining all those filters. :) -- Dale E. Reed Jr. Emerald and RadiusNT __________________________________________ IEA Software, Inc. www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 15:42:16 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11074 for ; Tue, 2 Mar 1999 15:42:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA15815; Tue, 2 Mar 1999 12:33:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA18077 for ietf-radius-outgoing; Tue, 2 Mar 1999 12:35:33 -0800 (PST) Date: Tue, 2 Mar 1999 15:37:42 -0500 (EST) From: "Steven P. Crain" To: Carl Rigney cc: ietf-radius@livingston.com Subject: (radius) Comments on latest Radius Draft In-Reply-To: <199902262102.NAA11769@server.livingston.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" Section 4.1 It looks like you missed removing the requirement that User-Name be in all Access-Requests. Section 4.1 includes "An Access-Request MUST contain a User-Name attribute." Section 5.6 Also, in 5.6 the description of Call Check has an odd sentence: > It is recommended that such Access-Requests use the value > Calling-Station-Id as the User-Name. I think you mean "value of Calling-Station-Id as the value of User-Name" or somthing like that. Also, User-Name is now allowed in Access-Accept packets, but there is no discussion as to what it means. I realize that this is intended to provide a User-Name to include in Accounting messages if the Calling-Station-Id was used to authenticate, but that should be specified. I would like to see User-Name allowed for other purposes. E.g. joe@my.net could be authed with Service-Type = Login, Login-Service = Rlogin, Login-IP-Host = shell.my.net, User-Name = "joe" (or even "joe314" or "guest"). This would eleviate many hacks that have been used over the years, and allow a dialup authentication name space that is different from the Login-IP-Host's name space. Name space is not much of an issue with PPP, but if you provide shell access for large numbers of customers, it becomes much more of an issue. [Note on security: if the radius server is trusted to approve rlogin connections, it should be trusted to specify what username to rlogin with as well.] -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 2 15:42:52 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11101 for ; Tue, 2 Mar 1999 15:42:51 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA15938; Tue, 2 Mar 1999 12:35:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA18275 for ietf-radius-outgoing; Tue, 2 Mar 1999 12:37:37 -0800 (PST) Date: Tue, 2 Mar 1999 15:39:37 -0500 (EST) From: "Steven P. Crain" To: "Nelson, David" cc: "'Dave Mitton'" , "'ietf-radius@livingston.com'" Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Tue, 2 Mar 1999, Nelson, David wrote: > Of course, I've always been left a little unsatisfied by the "some > mechanism outside the scope of RADIUS" business. It doesn't do much to > promote interoperability. However, since we have already cast the die > in terms of the Filter-ID usage, I guess Framed-IP-Pool would be OK on > that basis. Maybe we should call it Framed-IP-Pool-ID for consistency. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 10:17:58 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10142 for ; Wed, 3 Mar 1999 10:17:57 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA11668; Wed, 3 Mar 1999 07:09:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA14861 for ietf-radius-outgoing; Wed, 3 Mar 1999 07:11:55 -0800 (PST) Message-Id: <199903031510.KAA07766@server1.btna.com> From: "Mun, Mike" To: "Nelson, David" , "Steven P. Crain" Cc: "'Dave Mitton'" , "'ietf-radius@livingston.com'" Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool Date: Wed, 3 Mar 1999 10:05:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE6587.FF18E8D0" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mun, Mike" 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_000_01BE6587.FF18E8D0 Content-Type: text/plain; charset="iso-8859-1" From AS server's point of view, I think Framed-IP-Pool should be an integer value: 0 NAS pool available 1 NAS pool only If this attribute is not present, then NAS pool is not available. Mike ---------- From: Steven P. Crain [SMTP:scrain@shore.net] Sent: Tuesday, March 02, 1999 3:40 PM To: Nelson, David Cc: 'Dave Mitton'; 'ietf-radius@livingston.com' Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool On Tue, 2 Mar 1999, Nelson, David wrote: > Of course, I've always been left a little unsatisfied by the "some > mechanism outside the scope of RADIUS" business. It doesn't do much to > promote interoperability. However, since we have already cast the die > in terms of the Filter-ID usage, I guess Framed-IP-Pool would be OK on > that basis. Maybe we should call it Framed-IP-Pool-ID for consistency. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. ------_=_NextPart_000_01BE6587.FF18E8D0 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IikPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAsAAAAUkU6IChyYWRpdXMpIE5BUy1Qb3J0LUlkIGFuZCBG cmFtZWQtSVAtUG9vbADHDQEJgAEAIQAAAEFBOUE5NjlGNEREMUQyMTE5MkU1MDBBQTAwMDkyOEQx AB4HASCAAwAOAAAAzwcDAAMACgAKACYAAwAZAQEFgAMADgAAAM8HAwADAAoABQAaAAMACAEBDYAE AAIAAAACAAIAAQOQBgBIDAAAHAAAAEAAOQCAKytFh2W+AR4AcAABAAAAKAAAAChyYWRpdXMpIE5B Uy1Qb3J0LUlkIGFuZCBGcmFtZWQtSVAtUG9vbAACAXEAAQAAABsAAAABvmTszueqEw/T0NMR0oi+ AKDJhUXWACZfESAAAgEJEAEAAAAKCQAABgkAAAwUAABMWkZ1Q3kTpwMACgByY3BnMTI1cjIMYGMx AzABBwtgbpEOEDAzMw8WZmUPkk8B9wKkA2MCAGNoCsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdCF AdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQA9T7Ef8TC2IT4RRQE7IY9BTQfwcTFeQPwBZfF28cnxzA feEGsHN0ZW0CgAKRCOaqOwlvMB8fZQ4wNSBK/yFhIR8iKSA0IlIgvySPJE3PI88h/yBPEGAyOCoa KzH/Ku8r+SA0LCIqjy5fLh0tn/srzy+UOQ5QMuQ0QSxjNEBTAoIeAHlsB5BoCeB0wwAAA/BkY3Rs CrEAYJhkanUeAAUQZ2gFQjsWMgwBYwnANoADMHNufGV4G2AHsAWwAMACc3OxAFBzYjIUUDWgYRPw 9FxrCeBwC5A2eAhgNrD1C4BlNeB2PCABQDcbDDDfN+QsQDrABKALgGcsMThm9GJhG0BkAiA5IDjG NhDzNxA+USAxNXMOUDofOy//PDMAUTy8AKA37j8/QEY1ZP8PwEFPQl88Mw5QPK9FD0Yf7UBzMwKC ExBjOeBM4TcQSUBwdGk8UCBEARBhVHVsBUBQCsBhCcBhcHBoIEYCITmkKYBm9GktD5A4AUA78FFz Nnh6YgsgcglQUtIa0FLSd/Y0KYEbMHAB0E6yNz9L399M5lEQT9AFEAIwLVBwA2EQOiBUb1gwU3Vi SmoFkHRYMERhHhA6/TmkNlE/Uk9TX1RuNgBAY78OIUzhPXYOUFXvVv5SPEG5GzEgSEBRBJA5pDdZ 7/9a/1wPTOE7z11/D5AcwAjQ8mIKsHQ4SzoPVEgQX3/PYIZpAGGQC1B5L1CAXHD7CxFiBXM5pCxA Yv9kD2Uff1R/VY9rH2wqWFJX9FkpOXc2b3GFaLM5cd9y73ggRPhvY3UHgAIwBdBQQB5D/xMQZnAe AAGRNeAAAHuie5Q/HiALUR4QdnBt8XPgMTT9WcA5WdB7ogCQfQF8JWazu25AZsJuGvBuMWbCaoAW 9QIQbAkAd4AlHgAKwAGQ9xthgaQKsGMKYH+UC4ABAJ8CMAHhZrMeEDkAXCd9oN+EsSAwApF/pHqg YmHBhLJrAoACAGIHMHNM4W3RM/tIcWZwNUghgJB7pQzBh7GmIIVCe7FuYQeAIIZxd3uidnB90DkO IDRAD7A3/XtIb2GxOIEbUHv4i4aJ3/uLOwWgdYPRbkA54B5QAVW/h1J2YYFgdpBvkQGAbliw/wBg CfBO4HqAAgE5YF4SjSBLkcE1wHAiwFx2CJB3/muDkWpAkzIE8AdAEGEBQN8OAG9iQEKUlQIQbwVC G1GDEvJ85iBDOlxcV4B6b1AhbVBwAxAHkJdATZMN4ANgc28BgCBPASBrDeCNIFyY9kUAwAMQLn1M sHSGgBtAdpA4oWZyeO9IMZqyT3SIACAS8wCABZD8bHZDoUjQDnA5YJySggL/nSKDlAHBnJEbEA9w AABI0PMM0AGQIC57RJymDlCdQv9PsDbwnb+ez5/fD8BI0AWBt6F/oo+jn2xqQEjQbKE/+6X/pwUp oAwpgKTfqb+m9PhiICgCkarfnNNZ0KiP/61Prl+vb50AYtCwsp2Psh//sy+gDCxAsL+2P7dPuF+d AP92QLU/us+737zkCvkDMHZvy3GfOJF7V/IgQQXwG0DmcmGxABBxdZXQE4AEIFRwb1ehIJiwIJMy LKAgSSB0aAuAa1fhw4lxfXBJUC1QlcADINs2AAhgbDighfAgA5FXofxlZwSQxuAHQApQWDAKhf+m 44SCCwo3/MeAGwAAYABB/GRizUNuMXqAzVAAQBOQ/wyCwZWHDcKIh/2cZArhubDznQAG4GR5DECc 8Y9jnJH/BKCV0KoyrHSDlIeypoSJwXM54cMqe07FMcZgyJFh/8oQAxB78sqPy5/Mr82/AFD/zu/P /9EP0h/TL9Q/1U/WX38DIAIgbDAKhdy2wo/WlEnfxtDHcQQgWTDDcWJmUBOA/+gB4YHGUB8wG0AC MMcwx3DfCfAHsNcG6NXXhy7lX+Zv/9aymFBIoOvNblFum+O768//79/w75rykEXyT9bBOFQ5ICES 8mJrbWuB8yBfx3sAAxBZIWF9LfhH8Sv7wgZivTTd229vZZ9mr2e//2jPad32N1f0BgAeEP5Q3+Ac UC6XEFAAwkFbU03YVFA6lBAD8kDIwR8w8i444HRd+O/59G27+y9v/D9wr8O/9ihTesEDEVRhIBBz ZGF5xzB7AHK/GwATkccwNDAOgE3wOojB/FBN2BV08hVBgeBMwMcwS1kgkzBk2BVDYwMRJ58QcROA mFB80EzAJzsRcHHHAHRmLVAAQHBKsEBP/fCTMF5gi2FuLo8Qba4n2BVYl2GARVgwKBLU/inqEshh HtDIMDigyWA4oP/H3BoRS1IaYPZVBb/CQvR/7wqvxEjxJvY3T9/gDUHHMJ4yDcIOY8cwD/sgd5iA 11lB2BXYFT6Y4SCPEWHR3ccxJ08xlDBskHnoEIXwf+nxNeCYwadQ/fB80DXgIHePMEhQTxBzbdAq QMkgefnpwiAimKCJgSEHiYDa0P/JYHxgxRD9wX6Aj+AlE5QQBm+S8MayUkFESVWcUyLJIEqw/gFz cwPA/8dAeuBMsJgQEjApgiZAnWD/UGCLcCEH6UDFAMYCyZKYgK+S8FAAhrAjwXkpQUiBYP9hoscw KOGDACAgiZBeICJj/y+wG0AlAJQgfHAlE0Bw2Ab/IXDCQSvxkjDGsiUil+Er8b3IMEQkIEhQydDH MmcNUcvoEMfdd8jmT0vlASEH/+nQWTDJIEyAfGDrttgVewD+eckxLfHIxZQh6pF64MfcvzGikgEh sb6gfGGRkGMswP8gnPhAynYDTRBR/kIn0HqyA9gVG9B0cDovL3flPoAuBRcvfgSkFDYFI/sP8Fjx THqAlDBYQMcAKTDZQZAgV5IQyQFD18Ayoe5DEiBGkBrQaTmxOm0PN/8kIligBKHocB5hlqCaERFw /ZoAapIQTLArgBM+ICBPAPpo2BUnRNnJgBKYR5AwQr8lMeBiMMaJgCkgMgEu9sYnkZH3mfEmfQBN sAAAAwD9P1IDAAADACYAAAAAAAMANgAAAAAAHgAxQAEAAAAUAAAAQlROQV9WQVJFU1RPTjFfTU1V TgADABpAAAAAAB4AMEABAAAAFAAAAEJUTkFfVkFSRVNUT04xX01NVU4AAwAZQAAAAAACAfk/AQAA AGYAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAGAAAAL089RVhDSEFOR0UvT1U9QlROQUhVQjEv Q049UkVDSVBJRU5UUy9DTj1WQVJFU1RPTjEvQ049QlROQV9WQVJFU1RPTjFfTU1VTgAAAB4A+D8B AAAACgAAAE11biwgTWlrZQAAAB4AOEABAAAAFAAAAEJUTkFfVkFSRVNUT04xX01NVU4AAgH7PwEA AABmAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAABgAAAC9PPUVYQ0hBTkdFL09VPUJUTkFIVUIx L0NOPVJFQ0lQSUVOVFMvQ049VkFSRVNUT04xL0NOPUJUTkFfVkFSRVNUT04xX01NVU4AAAAeAPo/ AQAAAAoAAABNdW4sIE1pa2UAAAAeADlAAQAAABQAAABCVE5BX1ZBUkVTVE9OMV9NTVVOAEAABzCg tgxLhmW+AUAACDDQ6Bj/h2W+AR4APQABAAAABQAAAFJFOiAAAAAAHgAdDgEAAAAoAAAAKHJhZGl1 cykgTkFTLVBvcnQtSWQgYW5kIEZyYW1lZC1JUC1Qb29sAAsAKQAAAAAACwAjAAAAAAADAAYQrcU+ kAMABxBBAwAAAwAQEAAAAAADABEQAQAAAB4ACBABAAAAZQAAAEZST01BU1NFUlZFUlNQT0lOVE9G VklFVyxJVEhJTktGUkFNRUQtSVAtUE9PTFNIT1VMREJFQU5JTlRFR0VSVkFMVUU6ME5BU1BPT0xB VkFJTEFCTEUxTkFTUE9PTE9OTFlJRlQAAAAAknE= ------_=_NextPart_000_01BE6587.FF18E8D0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 10:35:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12377 for ; Wed, 3 Mar 1999 10:35:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA12231; Wed, 3 Mar 1999 07:26:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA16165 for ietf-radius-outgoing; Wed, 3 Mar 1999 07:30:17 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Steven P. Crain'" Cc: "'ietf-radius@livingston.com'" Subject: RE: (radius) More detail on Proxy Date: Wed, 3 Mar 1999 10:26:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Steven Crain writes... > This could be misleading. In my operation, different customers have > password entries on different hosts. E.g. > > User Host > george@spandex.com apple > sue@spandex.com orange > john@nowhere.org apple > hello@shore.net orange > *@another.net radius.another.net > > The choice of remote server in our case is based on looking > up the host associated with the whole User-Name, not some > portion of it. > > I would change "A realm can either be based on part of the > User-Name" to "A realm can either be based on all or part of > the User-Name." While I wouldn't want to absolutely prohibit the behavior that you have implemented (for reasons important to your business), I certainly wouldn't want to encourage the RADIUS community at large to follow your lead. You have essentially created a flat name space. That, IMHO, doesn't scale well. I think that a hierarchical name space, where the realm part is akin to the FQDN part in an SMTP address is much more scalable. I note that other large scale, distributed authentication systems such as Kerberos do parse the realm part separately from the username part. I suggest that this be the recommended practice for RADIUS proxy as well. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 10:43:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12541 for ; Wed, 3 Mar 1999 10:43:00 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA12496; Wed, 3 Mar 1999 07:36:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA16695 for ietf-radius-outgoing; Wed, 3 Mar 1999 07:39:28 -0800 (PST) From: Aydin Edguer Message-Id: <199903031537.KAA23386@harlequin.MorningStar.Com> Subject: RE: (radius) More detail on Proxy To: ietf-radius@livingston.com Date: Wed, 3 Mar 1999 10:37:34 -0500 (EST) Cc: scrain@shore.net X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > I think that a hierarchical name space, where the realm part is akin to > the FQDN part in an SMTP address is much more scalable. ... > I suggest that this be the recommended practice for RADIUS proxy as well. It already is - see RFC 2486 "The Network Access Identifier" and the description of User-Name in draft-ietf-radius-radius-07.txt. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 10:48:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12693 for ; Wed, 3 Mar 1999 10:48:17 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA12650; Wed, 3 Mar 1999 07:39:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA16949 for ietf-radius-outgoing; Wed, 3 Mar 1999 07:42:52 -0800 (PST) Message-Id: <3.0.5.32.19990303104157.0347ceb0@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 03 Mar 1999 10:41:57 -0500 To: "Mun, Mike" , "Nelson, David" , "Steven P. Crain" From: Dave Mitton Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool Cc: "'ietf-radius@livingston.com'" In-Reply-To: <199903031510.KAA07766@server1.btna.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton That's silly. From the server's point of view, you should know if you configured an IP pool on that NAS and provision the use of it accordingly. If there is no pool, then ignore it. If you need some help in remembering such things, your server implementation can certainly organize it's data internally. Many of the leading RADIUS servers now have internal "attributes" which are used to trigger appropriate behaviors. The NAS never sees them on the wire. The semantics of Framed-IP-Address already allow for the NAS to assign an address given the magic value of 255.255.255.254. Your proposal is redundant. Adding another attribute just allows the Server to select from multiple potential pools. I would even go so far as to say that it could be used in a DHCP request from the NAS, to a DHCP server that uses "Class" arguments for address selection. Dave. At 10:05 AM 3/3/99 -0500, Mun, Mike wrote: >>From AS server's point of view, I think Framed-IP-Pool should be an integer >value: >0 NAS pool available >1 NAS pool only >If this attribute is not present, then NAS pool is not available. >Mike > > > ---------- > From: Steven P. Crain [SMTP:scrain@shore.net] > Sent: Tuesday, March 02, 1999 3:40 PM > To: Nelson, David > Cc: 'Dave Mitton'; 'ietf-radius@livingston.com' > Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool > > On Tue, 2 Mar 1999, Nelson, David wrote: > > > Of course, I've always been left a little unsatisfied by the "some > > > mechanism outside the scope of RADIUS" business. It doesn't do >much to > > promote interoperability. However, since we have already cast the >die > > in terms of the Filter-ID usage, I guess Framed-IP-Pool would be >OK on > > that basis. > > Maybe we should call it Framed-IP-Pool-ID for consistency. > > -- > Steven P. Crain, Development > http://www.shore.net/~scrain > Shore.Net: Local Ties... World Class Connections > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > >Attachment Converted: "L:\Eudora\attachments\RE (radius) NAS-Port-Id and Fr1" > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 10:51:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12956 for ; Wed, 3 Mar 1999 10:51:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA12840; Wed, 3 Mar 1999 07:44:41 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA17263 for ietf-radius-outgoing; Wed, 3 Mar 1999 07:47:52 -0800 (PST) Message-Id: <199903031546.HAA03142@shell4.ba.best.com> Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool (fwd) To: ietf-radius@livingston.com Date: Wed, 3 Mar 1999 07:46:33 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Mun, Mike shaped the electrons to say... >From AS server's point of view, I think Framed-IP-Pool should be an integer >value: >0 NAS pool available >1 NAS pool only >If this attribute is not present, then NAS pool is not available. This is not what is meant. There are NASen with *multiple, named pools*. The Ascend Max does this now, the PortMaster-4 will have this in ComOS 4.1, and I believe there are others as well - Assured Access and ACC I believe. The idea is being able to assign multiple IP pools and then stick a user into the appropriate pool. How the pool is established is outside of RADIUS, just as it is today (Framed-IP-Address = 255.255.255.254). It could well be something like Framed-IP-Pool-ID = "dhcp" and the NAS is ocnfigured so that when it is told to use that pool it calls the DHCP server. And Framed-IP-Pool-ID = "outsource1", whatever. I, for one, would like to see this standardized. It would be nice to correlate all of the VSAs and see how many are redundant - if say 3 vendors all have VSAs for the same thing, it may make sense to make a standard AVP for that. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 10:53:35 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12996 for ; Wed, 3 Mar 1999 10:53:34 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA13186; Wed, 3 Mar 1999 07:46:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA17451 for ietf-radius-outgoing; Wed, 3 Mar 1999 07:49:52 -0800 (PST) Message-Id: <199903031548.HAA03529@shell4.ba.best.com> Subject: (radius) NAS-Port-Id and Framed-IP-Pool (fwd) To: ietf-radius@livingston.com Date: Wed, 3 Mar 1999 07:48:50 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Carl Rigney shaped the electrons to say... >Do people still think these would be useful, and if so, would they >be worth adding to the Extensions draft? Feel free to email me directly >or if you prefer, to the mailing list. I don't have any real feeling on the named ports, but I do believe a Framed-IP-Pool-ID would be a useful addition. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 11:18:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13594 for ; Wed, 3 Mar 1999 11:18:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA14140; Wed, 3 Mar 1999 08:11:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA19407 for ietf-radius-outgoing; Wed, 3 Mar 1999 08:13:17 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Aydin Edguer'" Cc: "'ietf-radius@livingston.com'" Subject: RE: (radius) More detail on Proxy Date: Wed, 3 Mar 1999 11:09:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Aydin Edguer writes... > > I suggest that this be the recommended practice for RADIUS > > proxy as well. > > It already is - see RFC 2486 "The Network Access Identifier" > and the description of User-Name in > draft-ietf-radius-radius-07.txt. Yes, your point is well taken. However the reference in draft-ietf-radius-radius-07.txt (on pp 25-26) indicates that the User-Name attribute MAY be one of several formats, including an RFC 2486 NAI. I think that's not as strong as indicating that an RFC 2486 NAI SHOULD be used for the User-Name attribute in RADIUS proxy configurations. It's this somewhat stronger recommendation that I'm advocating. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 11:18:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13604 for ; Wed, 3 Mar 1999 11:18:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA14132; Wed, 3 Mar 1999 08:11:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA19497 for ietf-radius-outgoing; Wed, 3 Mar 1999 08:14:20 -0800 (PST) Message-Id: <199903031613.LAA09220@server1.btna.com> From: "Mun, Mike" To: "Mun, Mike" , "Nelson, David" , "Steven P. Crain" , Dave Mitton Cc: "'ietf-radius@livingston.com'" Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool Date: Wed, 3 Mar 1999 11:08:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE6590.C7F64770" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mun, Mike" 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_000_01BE6590.C7F64770 Content-Type: text/plain That is in the single domain. What I talk about is in case of roaming users and proxy to different domain. Mike ---------- From: Dave Mitton [SMTP:dmitton@baynetworks.com] Sent: Wednesday, March 03, 1999 10:42 AM To: Mun, Mike; Nelson, David; Steven P. Crain Cc: 'ietf-radius@livingston.com' Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool That's silly. From the server's point of view, you should know if you configured an IP pool on that NAS and provision the use of it accordingly. If there is no pool, then ignore it. If you need some help in remembering such things, your server implementation can certainly organize it's data internally. Many of the leading RADIUS servers now have internal "attributes" which are used to trigger appropriate behaviors. The NAS never sees them on the wire. The semantics of Framed-IP-Address already allow for the NAS to assign an address given the magic value of 255.255.255.254. Your proposal is redundant. Adding another attribute just allows the Server to select from multiple potential pools. I would even go so far as to say that it could be used in a DHCP request from the NAS, to a DHCP server that uses "Class" arguments for address selection. Dave. At 10:05 AM 3/3/99 -0500, Mun, Mike wrote: >>From AS server's point of view, I think Framed-IP-Pool should be an integer >value: >0 NAS pool available >1 NAS pool only >If this attribute is not present, then NAS pool is not available. >Mike > > > ---------- > From: Steven P. Crain [SMTP:scrain@shore.net] > Sent: Tuesday, March 02, 1999 3:40 PM > To: Nelson, David > Cc: 'Dave Mitton'; 'ietf-radius@livingston.com' > Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool > > On Tue, 2 Mar 1999, Nelson, David wrote: > > > Of course, I've always been left a little unsatisfied by the "some > > > mechanism outside the scope of RADIUS" business. It doesn't do >much to > > promote interoperability. However, since we have already cast the >die > > in terms of the Filter-ID usage, I guess Framed-IP-Pool would be >OK on > > that basis. > > Maybe we should call it Framed-IP-Pool-ID for consistency. > > -- > Steven P. Crain, Development > http://www.shore.net/~scrain > Shore.Net: Local Ties... World Class Connections > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > >Attachment Converted: "L:\Eudora\attachments\RE (radius) NAS-Port-Id and Fr1" > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. ------_=_NextPart_000_01BE6590.C7F64770 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IiEQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQSAAQAsAAAAUkU6IChyYWRpdXMpIE5BUy1Qb3J0LUlkIGFuZCBG cmFtZWQtSVAtUG9vbADHDQEJgAEAIQAAAEIwOUE5NjlGNEREMUQyMTE5MkU1MDBBQTAwMDkyOEQx AA4HASCAAwAOAAAAzwcDAAMACwANAB8AAwAWAQEFgAMADgAAAM8HAwADAAsACAAxAAMAIwEBDYAE AAIAAAACAAIAAQOQBgD8DgAAHAAAAEAAOQDgqsIfkGW+AR4AcAABAAAAKAAAAChyYWRpdXMpIE5B Uy1Qb3J0LUlkIGFuZCBGcmFtZWQtSVAtUG9vbAACAXEAAQAAABsAAAABvmWMnW0UH/HF0XsR0oi+ AKDJhUXWAAC6KiAAAgEJEAEAAAC9CwAAuQsAAIgZAABMWkZ1XgNmHAMACgByY3BnMTI1cjIMYGMx AzABBwtgbpEOEDAzMw8WZmUPkk8B9wKkA2MCAGNoCsBzhGV0AtFwcnEyAACSKgqhbm8SUCAwAdCF AdA2D6AwNTA0FCHzAdAUEDR9B20CgwBQA9T7Ef8TC2IT4RRQE7IY9BTQfwcTFeQPwBZfF28cnxzA feEGsHN0ZW0CgAKRCOaqOwlvMB8fZQ4wNSBK/yFhIR8iKSA0IlIgvySPJE3PI88h/yBPEGAyOCoa KzH/Ku8r+SA0LCIqjy5fLh0tn/srzy+UOQ5QMuQ0QSxjNEBTAoIeAHlsB5BoCeB0wwAAA/BkY3Rs CrEAYJhkanUeAAUQZ2gFQjsWMgwBYwnANoADMHNufGV4G2AHsAWwAMACc3OxAFBzYjIUUDWgYRPw 9FxrCeBwC5A2eAhgNrD1C4BlNeB2PCABQDcbDDDfN+QsQDrABKALgGcsMThm9GJhG0BkAiA5IDjG NhDzNxA+USAxNXMOUDofOy//PDMAUTy8AKA37j8/QEY1ZP8PwEFPQl88Mw5QPK9FD0Yf7UBzMwKC ExBjOeBM4TcQSUBwdGk8UCBEARBhVHVsBUBQCsBhCcBhcHBoIEYCITmkKYBm9GktD5A4AUA78FFz Nnh6YgsgcglQUtIa0FLSd/Y0KYEbMHAB0E6yNz9L399M5lEQT9AFEAIwLVBwA2EQOiBUb1gwU3Vi SmoFkHRYMERhHhA6/TmkNlE/Uk9TX1RuNgBAY78OIUzhPXYOUFXvVv5SPEG5GzEgSEBRBJA5pDdZ 7/9a/1wPTOE7z11/D5AcwAjQ8mIKsHQ4SzoPVEgQX3/PYIZpAGGQC1B5L1CAXHD7CxFiBXM5pCxA Yv9kD2Uff1R/VY9rH2wqWFJX9FkpOXc2b3GFaLM5cd9y73ggRPhvY3UHgAIwBdBQQB5BzQFVM0hx dmFvd3aQb5H9AYBuWLAAYAnwTuB6gAIBuzlgXhJlAPB6gDXAcCLApFx2CJB3awuAZGpA/37CBPAH QBBhAUAOAG9iQEL7gCUCEG8FQhtREvIeEQtRQR4QIEM6XFxXgG+9UCFtUHADEAeQgtBNDeDJA2Bz bwGAIE8BIA3gtX4QXISGRQDAAxAuTLC+dHtQG0B2kDihZnJ4SDF7hkJPdGMDIBLzAIAFkGz+dkOh SNAOcDlgiCIBkAAg/4iyfxF6wQHBiCEbEA9wAADnSNAM0AGQIC4eUogYDlD/iNJPsDbwiU+KX4tv D8BI0G8FgY0Pjh+PL2xqQEjQbPeMz5GPkpUpi5wpgJBvlU/xkoRiICgCkZZviGNZ0P+UH5jfme+a /4iQYtCcQokf/52vnr+LnCxAnE+hz6Lfo+//iJB2QKDPpl+nb6h0CvkDMOd2b3GfOJF7VBsQBUAE AOuwsAOgdDYQIACQD3A14IYgTLCFkW4uIFewguZJsRAHQGsgAaBmQbC193+wE3GEQCADYINAQIKu 4BdhwbMAfTAgF3BveHn9sRBvscAGkBBQHzB60bHV3wqFCoWtNK3/rwV7g+BIoP+3H7gjZnB71biv ubE4VDkgIRLyYmtta6pDIF/HewADEFkhYX0tv1e3i/utlmK9NEghbs9v32YPZx//aC9pP2pGvUdX 9FkRTzGD4AMCQAIgIFtTTVRQrDpktIDKwkBMcHk44Cx0dwWwvkAuBaBtXf+//8EEbbvCP8NPcK+v T704NwZgAjDKIVcJgDjgc2S1zAAsevFyGwATkDPVEAc0MNXgQLAwOjQyIJxBTQqFWFIF0HVu1RH1 ufE7B7FshDDXgcpRu/Bd1/BTHhDFYAOgULIwQ6dQAAuACoVDY8ohJwiQ3QAwLVAAQHDSAEDFAH7A 7w9wHgACIMyiJwqFWJcH8CpFWDAo2xQpB7BBU+QtUAkRLUk4oLUyV/D3g0AJgN7QUN6BBvACkT1y /w/AvWXM/63Su4/R76/Yt4bbvUewcicEIACQbGwwtw2fV/KxFASQYbHmkXBvV6G3tBJ+wtUQeQhg sVBoCGD6bDigaxNQB+AGkOoDBaB6bm3QZwhwCYC1IbKQUP8KhekgBvC0ELECsJHeUbUm/37AAJDt QxOAtNG0Ek8AswDeYwWhQHLm8cowSbQwsSH/HzCwshNQ7InVELEhA6Dj8PsTUPECdLcN8KHqEjjg 7AH/hDAHgEAx4zCw4h8wB4AG0PsGcUCRcw5wUGCxINuy6fP/BcDolAqFB3ALUPXBAjBZMP/uon+w s7EEkAGQC4BsMLQQ5HJnAHBpevLy5pHU4L+S0VehBJEHQPBTewBu+hEP8LMKhTXgQGRSQURJ/lUF 8OiU8UIH4BsQTzH7ZmwgIlkw49FixOAHkCL8IHf20NVhCsDvAzigtdDbCoXj0mcEkLMAcLVxF3D/ BzCCgfYA/wHuoBsw8HGwcP8TgO3COOBhseiBB5GxIYNQ/+61GqAfMLcNBDIbQBWxTxD3TnC0Et9Y QU7gHzAawLMA/mwfMOOAtbD7werhfZGxE//twrXRTIAN0PKwtSH39U7RvQkzZ08hsQSFkAzQY+mg r3/AIBC0EinhLg5oNPBx/ln3UgLSE2D/sbNxHzHXcP/7EKywtw0JAUCCGAHw0rMA/QAGIOOiCfQF Q9QB97K1wl8bQDXg4xAKUOgSbU+haf/4geyHHhAH0f+x7PLMkPO29wCg6nPZI2cVIbXgT4ACkf8F QRUhzADtZO+R7+DqgvYAhwFErdGS4ERIQ1D1of5xIBAeAPf1FbMKpfIxCzGfHBTolO1ktNG1ECJD 4iD/C2AAkPgw69B6srUQCmIMVf/39RVE7qG3DYIQsxDKQxEuu7KA1iEwV2DWgE3wLyXg/dXxLSWA xwDVEdd2AKAP4PNZQff1Pj7oA+3R6J/ppf+yofbRsvDfXOpGG1H5Yfti/wJxJ8YN01gwJ8ZIgCOy 7cLf7PPKYIWhsxAWZz54YC6b/0zAbDAnxvCjs3ETCPEzsoD/tXAFMHrB8jUu1zNFL2e3Bvo+uek+ Nv4jo79fOGTJ5e/ZDcsFf6DZskArwQZBzCG3zOY4ZNQVVByh1Ooy1bX2M9ZA4RBQ1pY4ZNcT2Bv3 N/vaZMpZJ9fw2r/bzz12t9z/3g/fH2w3fyOyT+JQ/z5R1RDWYNUx1cPVENgbJ129N/s+hHEa4mHR KjEnynH7f8BskHm1EPYA2UHFQIRRf5LgxQDKwLGh13AQIPkAc9tt0OwBYhpSgpAi9OJN/+9PBPUA 1WD6YXMFkcTgC3D/e3CxFO/gfoC0Ev3UAJAAQP+xYSGB8HK2ggUwRAC2gifG3xYA9pJY1071tXFt FwH7VLtWcdmwYoWw75DwYkh8QP9hotUQsWGEwACg9RHKYgmG97PRsoD8uD79gC/nTvWw8r//gH3A /HWDYvuBSMBEtMH/DYBP4gzAHKG1ECrdGIT2APknxk9L7TFOfe1zcvGzcPc2Jzf7ewB5G1FdYSvF f7H/EEGygN9cYeIKYuuBZrEXEf5j5wc37i3nPZTZHNhxxVIPAvB6sjf75BB0cDovlC93cTAuPHcv fjwEbz0cPIPYENRBTHqA/7FU/0RQzJB0oLJA7/DqkR/zgqD/eaB6ACJjIaY37UBNUfJG4H88AQAw S8EHoYWwRDCFkGq/7/Fa4UUOBhHtcDf7J3i5/7CwRGh7cLD1syAJ0WEV9QD/C2BiQWvfJSD5wNVg +LJ1kospAWuAZHPgIkw6hWF+dYXg2bCFYP/xgSXQsFznR3BHr0i5MSI2/TjIh3//iI+JnzlHTTTK pCOjjAjKMDGMCEVTTnPgyMA4LXnRIDcw2fZrMRYS/aFF97GAxRFcwk5IkcVw2AHMRIkjozk3jiA5 MTaOM3/KQAYx4xDZ9vgwAkACgVD378C6ALKAUxewxOB2EioxfCZTHFCQspEekZDWAEb0QVj39ULm 0fYRdCDVEfZB1YDOUDIwdIwNy3bywf+QccwqhnbWp3iveb96z/f1/3yvfb9+zwZQvdZvwLhAvrgZ t4Z9AKUxpXAAAAADAP0/UgMAAAMAJgAAAAAAAwA2AAAAAAAeADFAAQAAABQAAABCVE5BX1ZBUkVT VE9OMV9NTVVOAAMAGkAAAAAAHgAwQAEAAAAUAAAAQlROQV9WQVJFU1RPTjFfTU1VTgADABlAAAAA AAIB+T8BAAAAZgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAYAAAAvTz1FWENIQU5HRS9PVT1C VE5BSFVCMS9DTj1SRUNJUElFTlRTL0NOPVZBUkVTVE9OMS9DTj1CVE5BX1ZBUkVTVE9OMV9NTVVO AAAAHgD4PwEAAAAKAAAATXVuLCBNaWtlAAAAHgA4QAEAAAAUAAAAQlROQV9WQVJFU1RPTjFfTU1V TgACAfs/AQAAAGYAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAGAAAAL089RVhDSEFOR0UvT1U9 QlROQUhVQjEvQ049UkVDSVBJRU5UUy9DTj1WQVJFU1RPTjEvQ049QlROQV9WQVJFU1RPTjFfTU1V TgAAAB4A+j8BAAAACgAAAE11biwgTWlrZQAAAB4AOUABAAAAFAAAAEJUTkFfVkFSRVNUT04xX01N VU4AQAAHMCB1FoaPZb4BQAAIMHBH9seQZb4BHgA9AAEAAAAFAAAAUkU6IAAAAAAeAB0OAQAAACgA AAAocmFkaXVzKSBOQVMtUG9ydC1JZCBhbmQgRnJhbWVkLUlQLVBvb2wACwApAAAAAAALACMAAAAA AAMABhBgbl9jAwAHELkIAAADABAQAAAAAAMAERABAAAAHgAIEAEAAABlAAAAVEhBVElTSU5USEVT SU5HTEVET01BSU5XSEFUSVRBTEtBQk9VVElTSU5DQVNFT0ZST0FNSU5HVVNFUlNBTkRQUk9YWVRP RElGRkVSRU5URE9NQUlOTUlLRS0tLS0tLS0tLS1GUgAAAAAS3Q== ------_=_NextPart_000_01BE6590.C7F64770-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 11:38:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14062 for ; Wed, 3 Mar 1999 11:38:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA14782; Wed, 3 Mar 1999 08:30:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA21264 for ietf-radius-outgoing; Wed, 3 Mar 1999 08:34:02 -0800 (PST) Message-Id: <3.0.5.32.19990303113327.0093b1d0@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 03 Mar 1999 11:33:27 -0500 To: "Mun, Mike" , "Mun, Mike" , "Nelson, David" , "Steven P. Crain" From: Dave Mitton Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool Cc: "'ietf-radius@livingston.com'" In-Reply-To: <199903031613.LAA09229@server1.btna.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton Okay. Well in that case, returning the Framed-IP-Addr=255.255.255.254 value should suffice. I've quickly come to the conclusion, that service provider offering proxy authentication, wants to "edit" or control the actual return parameters, of which this is a prime example because of the necessary control of the network configuration. The proxy server would have templates for the services being offered to each proxy target. Hopefully the service provider has an address allocation scheme that may be proxy domain dependent, and would insert that in the NAS return message appropriately. He may want to use different pools of addresses for different customer bases, and could either do a server based assigment or direct the NAS accordingly. Dave. At 11:08 AM 3/3/99 -0500, Mun, Mike wrote: >That is in the single domain. What I talk about is in case of roaming users >and proxy to different domain. > >Mike > > ---------- > From: Dave Mitton [SMTP:dmitton@baynetworks.com] > Sent: Wednesday, March 03, 1999 10:42 AM > To: Mun, Mike; Nelson, David; Steven P. Crain > Cc: 'ietf-radius@livingston.com' > Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool > > That's silly. > > From the server's point of view, you should know if you configured >an IP > pool on that NAS and provision the use of it accordingly. If there >is no > pool, then ignore it. > > If you need some help in remembering such things, your server > implementation can certainly organize it's data internally. Many of >the > leading RADIUS servers now have internal "attributes" which are used >to > trigger appropriate behaviors. The NAS never sees them on the wire. > > The semantics of Framed-IP-Address already allow for the NAS to >assign an > address given the magic value of 255.255.255.254. Your proposal is >redundant. > > Adding another attribute just allows the Server to select from >multiple > potential pools. > I would even go so far as to say that it could be used in a DHCP >request > from the NAS, to a DHCP server that uses "Class" arguments for >address > selection. > > Dave. > > At 10:05 AM 3/3/99 -0500, Mun, Mike wrote: > >>From AS server's point of view, I think Framed-IP-Pool should be >an integer > >value: > >0 NAS pool available > >1 NAS pool only > >If this attribute is not present, then NAS pool is not available. > >Mike > > > > > > ---------- > > From: Steven P. Crain [SMTP:scrain@shore.net] > > Sent: Tuesday, March 02, 1999 3:40 PM > > To: Nelson, David > > Cc: 'Dave Mitton'; 'ietf-radius@livingston.com' > > Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool > > > > On Tue, 2 Mar 1999, Nelson, David wrote: > > > > > Of course, I've always been left a little unsatisfied by >the "some > > > > > mechanism outside the scope of RADIUS" business. It >doesn't do > >much to > > > promote interoperability. However, since we have already >cast the > >die > > > in terms of the Filter-ID usage, I guess Framed-IP-Pool >would be > >OK on > > > that basis. > > > > Maybe we should call it Framed-IP-Pool-ID for consistency. > > > > -- > > Steven P. Crain, Development > > http://www.shore.net/~scrain > > Shore.Net: Local Ties... World Class Connections > > > > - > > To unsubscribe, email 'majordomo@livingston.com' with > > 'unsubscribe ietf-radius' in the body of the message. > > > >Attachment Converted: "L:\Eudora\attachments\RE (radius) >NAS-Port-Id and Fr1" > > > --------------------------------------------------------------- > David Mitton ESN: 248-4570 > Consulting Engineer, Nortel Networks 978-916-4570 Direct > Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX > Billerica, MA 01821 >dmitton@nortelnetworks.com > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 12:04:05 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14437 for ; Wed, 3 Mar 1999 12:04:04 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA16021; Wed, 3 Mar 1999 08:56:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA23792 for ietf-radius-outgoing; Wed, 3 Mar 1999 08:59:44 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Wed, 03 Mar 1999 17:52:04 +0200 MR-Received: by mta BTMV98; Relayed; Wed, 03 Mar 1999 17:52:04 +0200 MR-Received: by mta BTMA06; Relayed; Wed, 03 Mar 1999 17:51:24 +0200 Disclose-recipients: prohibited Date: Wed, 03 Mar 1999 17:52:04 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) NAS-Port-Id and Framed-IP-Pool In-reply-to: <3.0.5.32.19990303113327.0093b1d0@fred.xylogics.com> To: "'ietf-radius@livingston.com'" Message-id: <1104521703031999/A36833/BTMV98/11D31C740300*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D31C740300 X400-MTS-identifier: [;1104521703031999/A36833/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT There seems to be some confusion as to the purpose of Framed-IP-Pool-Id, so I will attempt a clarification (based on current practice with a proprietary pool-id attribute). The NAS is configured with the following IP pools: pool-1 10.0.0.1/24 pool-2 10.0.1.1/24 pool-3 10.0.2.1/24 The network operator serves three realms (using a proxy), each realm using their own IP ranges. When forwarding an Access-Accept containing Framed-Address=255.255.255.254 from realm-1 to the NAS, the proxy adds the attribute: Framed-IP-Pool-Id = 1 When forwarding an Access-Accept containing Framed-Address=255.255.255.254 from realm-2 to the NAS, the proxy adds the attribute: Framed-IP-Pool-Id = 2 etc. The result is that users will get an IP address assigned that belongs to the address space of their realm. Regards, Marc. >Well in that case, returning the Framed-IP-Addr=255.255.255.254 >value should suffice. > >I've quickly come to the conclusion, that service provider offering proxy >authentication, wants to "edit" or control the actual return parameters, of >which this is a prime example because of the necessary control of the >network configuration. >The proxy server would have templates for the services being offered to >each proxy target. > >Hopefully the service provider has an address allocation scheme that may be >proxy domain dependent, and would insert that in the NAS return message >appropriately. He may want to use different pools of addresses for >different customer bases, and could either do a server based assigment or >direct the NAS accordingly. > > Dave. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 12:49:05 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15007 for ; Wed, 3 Mar 1999 12:49:05 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA17308; Wed, 3 Mar 1999 09:41:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA28078 for ietf-radius-outgoing; Wed, 3 Mar 1999 09:44:12 -0800 (PST) Date: Wed, 3 Mar 99 9:40:51 PST From: William "Chops" Westfield Subject: RE: (radius) NAS-Port-Id and Framed-IP-Pool (fwd) In-Reply-To: Your message of Wed, 3 Mar 1999 07:46:33 -0800 (PST) To: ietf-radius@livingston.com Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William "Chops" Westfield cisco supports multiple named address pools as well, and an attribute to pick which one to use would be a good thing, IMO. BillW - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 13:38:08 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15849 for ; Wed, 3 Mar 1999 13:38:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA19868; Wed, 3 Mar 1999 10:26:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA03448 for ietf-radius-outgoing; Wed, 3 Mar 1999 10:29:49 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Carl Rigney'" , ietf-radius@livingston.com Subject: RE: (radius) More detail on Proxy Date: Wed, 3 Mar 1999 13:25:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Carl, Based on the recent discussions of NAI usage, I'll recommend that the following changes to the RADIUS draft: Original text: > The NAS sends its RADIUS access-request to the "forwarding server" > which forwards it to the "remote server." The remote server sends a > response (Access-Accept, Access-Reject, or Access-Challenge) back to > the forwarding server, which sends it back to the NAS. The choice of > which server to forward the request to is based on the authentication > "realm." A realm can either be based on part of the User-Name, for > example the part following an at ("@") sign (a "named realm"), or a > Called-Station-Id (a "numbered realm"), or using whatever other > criteria the forwarding server is configured to use. Frequently, a > fully qualified domain name is used as the named realm to provide > uniqueness. Proposed revised text: The NAS sends its RADIUS access-request to the "forwarding server" which forwards it to the "remote server." The remote server sends a response (Access-Accept, Access-Reject, or Access-Challenge) back to the forwarding server, which sends it back to the NAS. The User-Name attribute SHOULD contain a Network Access Identifier [RFC 2486] for RADIUS Proxy operations. The choice of which server receives the forwarded request SHOULD be based on the authentication "realm." The authentication realm SHOULD be the realm part of a Network Access Identifier (a "named realm"). Alternatively, the choice of which server receives the forwarded request MAY be based on a Called-Station-Id (a "numbered realm"), or MAY be based on whatever other criteria the forwarding server is configured to use. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 14:21:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16862 for ; Wed, 3 Mar 1999 14:21:46 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA22773; Wed, 3 Mar 1999 11:15:05 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA10432 for ietf-radius-outgoing; Wed, 3 Mar 1999 11:18:04 -0800 (PST) From: Clark_Rudder@infonet.com X-Lotus-FromDomain: ISC@INFONET To: "Nelson, David" cc: "'Carl Rigney'" , ietf-radius@livingston.com, x003@hotmail.com Message-ID: <88256729.0069191C.00@issmail1.infonet.com> Date: Wed, 3 Mar 1999 11:14:24 -0800 Subject: RE: (radius) More detail on Proxy Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Clark_Rudder@infonet.com I really like this suggestion. Perhaps, though, changing the last line from >Alternatively, the choice of which >server receives the forwarded request MAY be based on a >Called-Station-Id (a "numbered realm"), or MAY be based on whatever >other criteria the forwarding server is configured to use. to Alternatively, the choice of which server receives the forwarded request MAY be based on whatever other criteria the forwarding server is configured to use, such as Called-Station-Id (a "numbered realm"). This seems to flow better if the intent is to say that you SHOULD use the Realm but you MAY use something else. Otherwise, it sounds like you are pushing Called-Station-Id. -Clark "Nelson, David" on 03/03/99 10:25:52 AM Please respond to "Nelson, David" To: "'Carl Rigney'" , ietf-radius@livingston.com cc: (bcc: Clark Rudder/HQ/ISC) Subject: RE: (radius) More detail on Proxy Carl, Based on the recent discussions of NAI usage, I'll recommend that the following changes to the RADIUS draft: Original text: > The NAS sends its RADIUS access-request to the "forwarding server" > which forwards it to the "remote server." The remote server sends a > response (Access-Accept, Access-Reject, or Access-Challenge) back to > the forwarding server, which sends it back to the NAS. The choice of > which server to forward the request to is based on the authentication > "realm." A realm can either be based on part of the User-Name, for > example the part following an at ("@") sign (a "named realm"), or a > Called-Station-Id (a "numbered realm"), or using whatever other > criteria the forwarding server is configured to use. Frequently, a > fully qualified domain name is used as the named realm to provide > uniqueness. Proposed revised text: The NAS sends its RADIUS access-request to the "forwarding server" which forwards it to the "remote server." The remote server sends a response (Access-Accept, Access-Reject, or Access-Challenge) back to the forwarding server, which sends it back to the NAS. The User-Name attribute SHOULD contain a Network Access Identifier [RFC 2486] for RADIUS Proxy operations. The choice of which server receives the forwarded request SHOULD be based on the authentication "realm." The authentication realm SHOULD be the realm part of a Network Access Identifier (a "named realm"). Alternatively, the choice of which server receives the forwarded request MAY be based on a Called-Station-Id (a "numbered realm"), or MAY be based on whatever other criteria the forwarding server is configured to use. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 14:53:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17420 for ; Wed, 3 Mar 1999 14:53:00 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA24247; Wed, 3 Mar 1999 11:46:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA14604 for ietf-radius-outgoing; Wed, 3 Mar 1999 11:49:14 -0800 (PST) From: Aydin Edguer Message-Id: <9903031948.AA20827@gefilte.MorningStar.Com> Subject: RE: (radius) More detail on Proxy To: ietf-radius@livingston.com Date: Wed, 3 Mar 1999 14:48:11 -0500 (EST) Cc: Clark_Rudder@infonet.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > This seems to flow better if the intent is to say that you SHOULD use the > Realm but you MAY use something else. Otherwise, it sounds like you are > pushing Called-Station-Id. I actually prefer the previous wording. This is because, in my opinion, Network Access Identifier (NAI) and Called-Station-Id *are* preferred to other methods for calculating the path used to forward the request. For modem outsourcing (larger ISP or carrier, offering ports to a smaller ISP) where there is a desire not want to require a full NAI, the phone number that was dialed by the customer is easier and preferred to other methods. We do not want to encourage the use of other identifiers, although we recognize that some operators may use them. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 15:32:45 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18527 for ; Wed, 3 Mar 1999 15:32:44 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA25501; Wed, 3 Mar 1999 12:24:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA18453 for ietf-radius-outgoing; Wed, 3 Mar 1999 12:27:16 -0800 (PST) From: Clark_Rudder@infonet.com X-Lotus-FromDomain: ISC@INFONET To: Aydin Edguer cc: ietf-radius@livingston.com Message-ID: <88256729.006CE357.00@issmail1.infonet.com> Date: Wed, 3 Mar 1999 11:56:32 -0800 Subject: RE: (radius) More detail on Proxy Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Clark_Rudder@infonet.com >> This seems to flow better if the intent is to say that you SHOULD use the >> Realm but you MAY use something else. Otherwise, it sounds like you are >> pushing Called-Station-Id. > >I actually prefer the previous wording. This is because, in my opinion, >Network Access Identifier (NAI) and Called-Station-Id *are* preferred to >other methods for calculating the path used to forward the request. In that case, the original might be a bit too ambiguous. I'm not trying to argue the point other than for clarity. If the wording is to be such that the reader knows that the "Network Access Identifier (NAI) and Called-Station-Id *are* preferred to other methods for calculating the path used to forward the request" then, perhaps, such should be stated more clearly. -Clark - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 15:58:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18975 for ; Wed, 3 Mar 1999 15:58:09 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA26418; Wed, 3 Mar 1999 12:50:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA21448 for ietf-radius-outgoing; Wed, 3 Mar 1999 12:54:03 -0800 (PST) Date: Wed, 3 Mar 1999 15:53:09 -0500 (EST) From: "Steven P. Crain" To: "Nelson, David" cc: "'ietf-radius@livingston.com'" Subject: RE: (radius) More detail on Proxy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Steven P. Crain" On Wed, 3 Mar 1999, Nelson, David wrote: > Steven Crain writes... > > > This could be misleading. In my operation, different customers have > > password entries on different hosts. E.g. > > > > User Host > > george@spandex.com apple > > sue@spandex.com orange > > john@nowhere.org apple > > hello@shore.net orange > > *@another.net radius.another.net > > > > The choice of remote server in our case is based on looking > > up the host associated with the whole User-Name, not some > > portion of it. > > > > I would change "A realm can either be based on part of the > > User-Name" to "A realm can either be based on all or part of > > the User-Name." > > While I wouldn't want to absolutely prohibit the behavior that > you have implemented (for reasons important to your business), > I certainly wouldn't want to encourage the RADIUS community at > large to follow your lead. > > You have essentially created a flat name space. That, IMHO, > doesn't scale well. I think that a hierarchical name space, > where the realm part is akin to the FQDN part in an SMTP > address is much more scalable. I note that other large scale, > distributed authentication systems such as Kerberos do parse > the realm part separately from the username part. I suggest > that this be the recommended practice for RADIUS proxy as well. What you say makes perfect sense in the context of roaming, but proxying is not only used for roaming. We use it to load balance customers over more than shell host, without the sometimes clueless users necessarily needing to remember when they log in which host their account is on. Users want a complete virtual domain. They bought clueless.com, and they want to use it for everything. Thier email is sent to bob@clueless.com, and it is really delivered to bob404@shell19.isp.net. Someone visits www.clueless.com and get a vhost running on www13.isp.net. They also want to log in using bob@clueless.com, not bob404@shell19.isp.net. The RADIUS proxy server needs to support flat per-user proxying for our own customers (bob@clueless.com->bob404@shell19.isp.net) and more traditional per-realm proxying for anything not specifically defined for roaming. -- Steven P. Crain, Development http://www.shore.net/~scrain Shore.Net: Local Ties... World Class Connections - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 16:21:23 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19587 for ; Wed, 3 Mar 1999 16:21:22 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA27499; Wed, 3 Mar 1999 13:14:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA23857 for ietf-radius-outgoing; Wed, 3 Mar 1999 13:18:11 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Wed, 3 Mar 1999 15:59 EST Subject: (radius) proxy issues, etc Content-Type: text/plain Message-ID: <36dda6ff0.5ebe@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff I would be extremely wary of specifying proxy behavior other than that strictly needed to function at all. How the proxy decides which server to send its request to, what attributes are passed along, whether proxy- state is forwarded or saved, are all matters of implementation and of no impact on the bits-on-the-wire between the NAS and the proxy. It is, really, not valid to speak of "forwarding" a request in the same sense as forwarding a packet. What the proxy is really doing is making an independent request, and then using information in the corresponding response, together with its own intelligence and database, to construct a response to the original request. Separately, count me as favoring a pool-selection attribute, and against a call-failed acct status instead of terminate-cause codes in the stop. NAS vendors are already doing the latter - why make everybody change? I don't know whether to be glad or sorry I was out of the country this past week. Sure saved me a lot of time posting flames. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 16:53:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20367 for ; Wed, 3 Mar 1999 16:53:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA28611; Wed, 3 Mar 1999 13:45:21 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA27272 for ietf-radius-outgoing; Wed, 3 Mar 1999 13:48:24 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Barney Wolff'" , ietf-radius@livingston.com Subject: RE: (radius) proxy issues, etc Date: Wed, 3 Mar 1999 16:44:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="ISO-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Barney Wolff writes... > How the proxy decides which server > to send its request to, what attributes are passed along, > whether proxy-state is forwarded or saved, are all matters > of implementation and of no impact on the bits-on-the-wire > between the NAS and the proxy. Yes and no. Strictly speaking, the protocol definition is independent of the implementation issues you mention. And if all the NAS and RADIUS servers are from the same vendor the issues are unlikely to be of concern. However, when you consider a multi-vendor environment, then I claim that the syntax and semantics of certain attributes do matter. If multi-vendor interoperability is a goal, then some common understanding of how forwarding (proxying) decisions are made is important. > It is, really, not valid to speak of "forwarding" a request > in the same sense as forwarding a packet. I agree with the distinction you draw here. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 3 17:46:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23458 for ; Wed, 3 Mar 1999 17:46:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA01976; Wed, 3 Mar 1999 14:38:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA04902 for ietf-radius-outgoing; Wed, 3 Mar 1999 14:41:57 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Wed, 3 Mar 1999 17:15 EST Subject: RE: (radius) proxy issues, etc Content-Type: text/plain Message-ID: <36ddbaaf0.609e@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff > From: "Nelson, David" > Date: Wed, 3 Mar 1999 16:44:55 -0500 > > ... However, when you > consider a multi-vendor environment, then I claim that the > syntax and semantics of certain attributes do matter. If > multi-vendor interoperability is a goal, then some common > understanding of how forwarding (proxying) decisions are made > is important. Well, I certainly don't disagree that a common interpretation of attribute syntax and semantics is necessary, pairwise, on each hop. But forwarding is a different matter. A proxy can decide on any basis whatsoever - hash the user id, alternate for load sharing, time of day, etc, without the slightest effect on interoperability. The proxy's algorithm must be understood by, and controlled by, its owner. Neither the NAS nor the eventual server needs to know it. Of course, a proxy that forwards a request to the wrong server is not very useful, so the proxy needs a good model of reality. I just don't see that as a standards issue. Regards, Barney - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 5 12:19:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17600 for ; Fri, 5 Mar 1999 12:19:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA27840; Fri, 5 Mar 1999 09:10:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA06505 for ietf-radius-outgoing; Fri, 5 Mar 1999 09:10:40 -0800 (PST) From: "Bernard Aboba" To: "Steven P. Crain" , "Carl Rigney" Cc: Subject: RE: (radius) More detail on Proxy Date: Fri, 5 Mar 1999 07:51:44 -0800 Message-Id: <002001be6720$11775440$0e8939cc@internaut.com> 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 8.5, Build 4.71.2173.0 In-Reply-To: Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit Steven P. Crain shaped the electrons thusly: > Also, this downplays the proxy server's > role as gatekeeper. It doesn't necessarily > send the reply it got back to the NAS. Indeed. This is how proxys implement policy, as described in draft-ietf-roamops-auth-10.txt. As part of that policy function, MERIT defined Acct-Status-Type=Proxy-Stop (6). This is used when an Access-Reject is sent to the NAS despite getting an Access-Accept from the RADIUS server. This should be included in the proxy section. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 5 13:08:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18573 for ; Fri, 5 Mar 1999 13:08:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA00212; Fri, 5 Mar 1999 10:00:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA12242 for ietf-radius-outgoing; Fri, 5 Mar 1999 10:04:20 -0800 (PST) Message-Id: <199903051802.KAA28884@shell4.ba.best.com> Subject: RE: (radius) More detail on Proxy (fwd) To: ietf-radius@livingston.com Date: Fri, 5 Mar 1999 10:02:26 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Bernard Aboba shaped the electrons to say... >As part of that policy function, MERIT defined >Acct-Status-Type=Proxy-Stop (6). This is used 3Com/USR has an Acct-Status-Type = Cancel (6) Are these used for the same thing, or is this a conflict? -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 5 13:22:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18930 for ; Fri, 5 Mar 1999 13:22:03 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA01002; Fri, 5 Mar 1999 10:14:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA13826 for ietf-radius-outgoing; Fri, 5 Mar 1999 10:18:00 -0800 (PST) From: William Bulley Message-Id: <199903051819.NAA00267@ohm.merit.edu> Subject: Re: (radius) More detail on Proxy (fwd) To: megazone@megazone.org Date: Fri, 5 Mar 1999 13:19:24 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <199903051802.KAA28884@shell4.ba.best.com> from "MegaZone" at Mar 5, 99 10:02:26 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William Bulley Content-Transfer-Encoding: 7bit According to MegaZone: > > Once upon a time Bernard Aboba shaped the electrons to say... > >As part of that policy function, MERIT defined > >Acct-Status-Type=Proxy-Stop (6). This is used > > 3Com/USR has an Acct-Status-Type = Cancel (6) > > Are these used for the same thing, or is this a conflict? This is a conflict. Or a mis-statement... :-) These are the Merit values and (should be) the USR/3COM values: VALUE Acct-Status-Type Start 1 VALUE Acct-Status-Type Stop 2 VALUE Acct-Status-Type Alive 3 VALUE Acct-Status-Type Modem-Start 4 VALUE Acct-Status-Type Modem-Stop 5 VALUE Acct-Status-Type Cancel 6 VALUE Acct-Status-Type Accounting-On 7 VALUE Acct-Status-Type Accounting-Off 8 Regards, web... -- William Bulley Senior Systems Research Programmer Merit Network, Inc. Email: web@merit.edu 4251 Plymouth Road, Suite C Phone: (734) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (734) 647-3185 [Sniglets (c) 1999] Hip-Hop-crisy: noun; the state-of-being where a person pretends to like the Grammy Award winning musical art form... - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 5 17:18:08 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25087 for ; Fri, 5 Mar 1999 17:18:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA09025; Fri, 5 Mar 1999 14:09:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA09880 for ietf-radius-outgoing; Fri, 5 Mar 1999 14:12:52 -0800 (PST) Message-Id: <199903052209.RAA24503@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-accounting-v2-00.txt Date: Fri, 05 Mar 1999 17:09:26 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Accounting Author(s) : C. Rigney Filename : draft-ietf-radius-accounting-v2-00.txt Pages : 27 Date : 04-Mar-99 This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-accounting-v2-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-accounting-v2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-accounting-v2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990304101958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-accounting-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-accounting-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990304101958.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 5 17:18:12 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25108 for ; Fri, 5 Mar 1999 17:18:11 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA09013; Fri, 5 Mar 1999 14:09:58 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA09951 for ietf-radius-outgoing; Fri, 5 Mar 1999 14:13:14 -0800 (PST) Message-Id: <199903052209.RAA24534@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-ext-03.txt Date: Fri, 05 Mar 1999 17:09:45 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Extensions Author(s) : C. Rigney, W. Willats, P. Calhoun Filename : draft-ietf-radius-ext-03.txt Pages : 39 Date : 04-Mar-99 This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2138 and RFC 2139. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-ext-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-ext-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-ext-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990304102654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-ext-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-ext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990304102654.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 5 17:24:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25086 for ; Fri, 5 Mar 1999 17:18:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA09008; Fri, 5 Mar 1999 14:09:56 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA09870 for ietf-radius-outgoing; Fri, 5 Mar 1999 14:12:49 -0800 (PST) Message-Id: <199903052209.RAA24486@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-radius-v2-00.txt Date: Fri, 05 Mar 1999 17:09:22 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : Remote Authentication Dial In User Service (RADIUS) Author(s) : C. Rigney, A. Rubens, W. Simpson, S. Willens Filename : draft-ietf-radius-radius-v2-00.txt Pages : 75 Date : 04-Mar-99 This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-radius-v2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-radius-v2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990304101003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-radius-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-radius-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990304101003.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 5 23:56:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20980 for ; Fri, 5 Mar 1999 23:56:27 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA16015; Fri, 5 Mar 1999 20:49:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA02655 for ietf-radius-outgoing; Fri, 5 Mar 1999 20:52:53 -0800 (PST) Message-Id: <199903052209.RAA24534@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-ext-03.txt Date: Fri, 05 Mar 1999 17:09:45 -0500 X-Rcpt-To: aalok@bisquare.com X-UIDL: ed632cbf58ca0861a2833585092f3ee6 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : RADIUS Extensions Author(s) : C. Rigney, W. Willats, P. Calhoun Filename : draft-ietf-radius-ext-03.txt Pages : 39 Date : 04-Mar-99 This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2138 and RFC 2139. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-ext-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-ext-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-ext-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990304102654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-ext-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-ext-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990304102654.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 5 23:57:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA21013 for ; Fri, 5 Mar 1999 23:57:00 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA16037; Fri, 5 Mar 1999 20:50:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA02721 for ietf-radius-outgoing; Fri, 5 Mar 1999 20:54:11 -0800 (PST) Message-Id: <199903052209.RAA24486@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: ietf-radius@livingston.com From: Internet-Drafts@ietf.org Subject: (radius) I-D ACTION:draft-ietf-radius-radius-v2-00.txt Date: Fri, 05 Mar 1999 17:09:22 -0500 X-Rcpt-To: aalok@bisquare.com X-UIDL: 7f154232aacdfa7ea843aaceea21d73a Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Remote Authentication Dial-In User Service Working Group of the IETF. Title : Remote Authentication Dial In User Service (RADIUS) Author(s) : C. Rigney, A. Rubens, W. Simpson, S. Willens Filename : draft-ietf-radius-radius-v2-00.txt Pages : 75 Date : 04-Mar-99 This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-radius-v2-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-radius-radius-v2-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-radius-radius-v2-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <19990304101003.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-radius-v2-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-radius-v2-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990304101003.I-D@ietf.org> --OtherAccess-- --NextPart-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 8 02:40:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24875 for ; Mon, 8 Mar 1999 02:40:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id XAA12344; Sun, 7 Mar 1999 23:33:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA01363 for ietf-radius-outgoing; Sun, 7 Mar 1999 23:31:03 -0800 (PST) From: "Bernard Aboba" To: "William Bulley" , Cc: Subject: RE: (radius) More detail on Proxy (fwd) Date: Sun, 7 Mar 1999 14:12:00 -0800 Message-Id: <000801be68e7$85c707a0$0e8939cc@internaut.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2014.211 In-Reply-To: <199903051819.NAA00267@ohm.merit.edu> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit Am I correct in saying that Acct-Status-Type=Cancel (6) is *only* sent by proxies when they convert an Access-Accept to an Access-Reject? Do both MERIT and USR/3Com use it this way? By the way, what is ALIVE used for? Is this for Interim accounting? > > This is a conflict. Or a mis-statement... :-) > > These are the Merit values and (should be) the USR/3COM values: > > VALUE Acct-Status-Type Start 1 > VALUE Acct-Status-Type Stop 2 > VALUE Acct-Status-Type Alive 3 > VALUE Acct-Status-Type Modem-Start 4 > VALUE Acct-Status-Type Modem-Stop 5 > VALUE Acct-Status-Type Cancel 6 > VALUE Acct-Status-Type Accounting-On 7 > VALUE Acct-Status-Type Accounting-Off 8 > > Regards, > > web... - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 8 11:11:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02024 for ; Mon, 8 Mar 1999 11:11:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA18686; Mon, 8 Mar 1999 08:03:58 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA25583 for ietf-radius-outgoing; Mon, 8 Mar 1999 08:06:26 -0800 (PST) From: William Bulley Message-Id: <199903081607.LAA05800@ohm.merit.edu> Subject: Re: (radius) More detail on Proxy (fwd) To: aboba@internaut.com (Bernard Aboba) Date: Mon, 8 Mar 1999 11:07:51 -0500 (EST) Cc: megazone@megazone.org, ietf-radius@livingston.com In-Reply-To: <000801be68e7$85c707a0$0e8939cc@internaut.com> from "Bernard Aboba" at Mar 7, 99 02:12:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William Bulley Content-Transfer-Encoding: 7bit According to Bernard Aboba: > > Am I correct in saying that > Acct-Status-Type=Cancel (6) is *only* > sent by proxies when they convert an Access-Accept > to an Access-Reject? I believe that is the way we use it. We use it this way in MichNet -- others don't use it this way IMHO. > Do both MERIT and USR/3Com use it this way? We do, but you'd have to ask them about theirs... > By the way, what is ALIVE used for? Is this for > Interim accounting? We don't use it (yet) -- we had talked about using it for a sort of "accounting checkpoint" message -- perhaps this is what the accounting Interim message is used for... Regards, web... -- William Bulley Senior Systems Research Programmer Merit Network, Inc. Email: web@merit.edu 4251 Plymouth Road, Suite C Phone: (734) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (734) 647-3185 [Sniglets (c) 1999] Hip-Hop-crisy: noun; the state-of-being where a person pretends to like the Grammy Award winning musical art form... - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 8 12:30:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03954 for ; Mon, 8 Mar 1999 12:30:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA21238; Mon, 8 Mar 1999 09:23:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA03996 for ietf-radius-outgoing; Mon, 8 Mar 1999 09:26:34 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Mon, 08 Mar 1999 18:19:52 +0200 MR-Received: by mta BTMV98; Relayed; Mon, 08 Mar 1999 18:19:52 +0200 MR-Received: by mta BTMA06; Relayed; Mon, 08 Mar 1999 18:19:06 +0200 Disclose-recipients: prohibited Date: Mon, 08 Mar 1999 18:19:52 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) I-D ACTION:draft-ietf-radius-radius-v2-00.txt In-reply-to: <199903052209.RAA24486@ietf.org> To: ietf-radius Message-id: <6752191808031999/A40651/BTMV98/11D344933400*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D344933400 X400-MTS-identifier: [;6752191808031999/A40651/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT Some comments on the draft-ietf-radius-radius-v2-00. MAY or MAY NOT be useful... 1. page 6 If any condition is not met, the RADIUS server sends an "Access- Reject" response indicating that this user request is invalid. If desired, the server MAY include a text message in the Access-Reject which MAY be displayed by the client to the user. No other Attributes are permitted in an Access-Reject. Proxy-State should also be permitted in Access-Reject 2. page 10 The forwarding server MUST NOT modify any other Proxy-States that were in the packet and MUST NOT change the order of any attributes of the same type, including Proxy State. A forwarding server MUST not modify existing Proxy-State, State, or Class attributes present in the packet. As discussed on the list earlier, most of this page is implementation dependent. It could be included as an example (as in the new accounting draft), but not as a requirement. In any case, I would interpret "MUST NOT modify" as "MAY delete and add again later on", but this is not clear from the text. 3. page 17 and 65 An Access-Request MUST contain a User-Name attribute. Request Accept Reject Challenge # Attribute 0-1 0-1 0 0 1 User-Name There is a mismatch here. 4. page 24 string 1-253 octets. Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead. In the new accounting draft, the string can still be 0-253. Has there been concensus on this issue? 5. page 51 5.30. Called-Station-Id Description This Attribute allows the NAS to send in the Access-Request packet the phone number that the user called, using Dialed Number Identification (DNIS) or similar technology. Note that this may be different from the phone number the call comes in on. It is only used in Access-Request packets. Why does this say 'only used in Access-Request packets'? This is valuable info in accounting as well, as many operators use the DNIS number to identify realms. I would either remove the restriction or add 'but MAY be sent in Accounting-Request packets.' 6. page 65 There is a special note [1] regarding usage of password attributes, but no special note for usage of NAS-IP and NAS-Identifier. That extra note *is* provided, however, in the accounting draft. Should it be added here as well (although already covered in the body)? 7. page 75 I guess it MUST be included, but still makes me wonder: (snipped some) "THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE." ;) Kind regards, Marc. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 8 15:40:15 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09714 for ; Mon, 8 Mar 1999 15:40:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA00776; Mon, 8 Mar 1999 12:33:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA25489 for ietf-radius-outgoing; Mon, 8 Mar 1999 12:36:30 -0800 (PST) Message-Id: <199903082034.MAA13054@shell4.ba.best.com> Subject: RE: (radius) More detail on Proxy (fwd) To: ietf-radius@livingston.com Date: Mon, 8 Mar 1999 12:34:54 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Bernard Aboba shaped the electrons to say... >By the way, what is ALIVE used for? Is this for >Interim accounting? ALIVE and Interim-Update are one in the same in the real world- in fact they have the same value. Cisco appears to support Interim-Update and servers such as Cistron will accept it, they had Alive as the value before Interim update became the standard. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 9 15:45:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18813 for ; Tue, 9 Mar 1999 15:45:05 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA13993; Tue, 9 Mar 1999 12:37:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA00282 for ietf-radius-outgoing; Tue, 9 Mar 1999 12:37:51 -0800 (PST) Message-Id: <3.0.5.32.19990309153823.033103d0@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 09 Mar 1999 15:38:23 -0500 To: ietf-radius@livingston.com From: Dave Mitton Subject: (radius) It's a protocol, no it's a trendy restaurant... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton Boston Globe, Calendar, Dining Review March 4th, 1999 http://www.boston.com/globe/calendar/dining/radius.htm - limited time URL It's oh so cool (and so is the food) RADIUS 8 High Street Boston (617) 426-1234 Restaurant reviewed 03/04/99 by Alison Arnett ---- Hours: Lunch: Mon.-Fri. 11:30 a.m.-2:30 p.m. Dinner: Mon.-Thurs. 5:30-10 p.m.; Fri.-Sat. 5:30-11 p.m. Reservations accepted. Smoking in bar area; non-smoking lounge downstairs. Prices: Lunch: appetizers $8-$16, main courses $13-$19. Dinner: appetizers $8-$18, main courses $21-$37, desserts $9, cheese plate $14. Good Choices: Duck, pistachio and roasted pear terrine; soup of lobster, cauliflower and curry; crab and cucumber terrine; sauteed skate; wild striped bass; garlic and herb rubbed chicken; loin of venison; hot apple soup; chocolate tasting plate; red wine basted pear, star anise ice cream. Credit cards: American Express, Diners Club, MasterCard, Visa, Carte Blanche Access: Fully accessible. ---- Radius came alive in downtown Boston in mid-December after much pre-opening fanfare. The trepidation from restaurateurs about this new mega-competitor was palpable for months in the city. It was as though the most infamous gunfighter in the West had swept through the saloon's swinging doors. Owned by Christopher Myers and chef Michael Schlow, Radius lives up to expectations in the style department - it's perhaps the most conceptually aware restaurant I've seen in Boston. The menu covers alone, which resemble the latest Kate Spade hand bags, give it a cutting-edge cachet. The room - from the circle-within-a-circle shape, the dark gray cloth-like surfaces, the carefully positioned circles of lipstick red, the various veneers of exotic woods - is severely elegant, a space designed rather than decorated. "Look at us: Cool, too cool. Hot, too hot," the very walls cry out. It is cool - and a little self-conscious. Schlow's food is just as stylish - and not at all self-conscious. Previously the chef at Cafe Louis, he infuses his food with a refined brawniness. From the first spoonful of an unusual lobster, cauliflower, and curry soup, there's no doubt of Schlow's boldness. The broth is thickened with pureed cauliflower so that the soup tastes as rich as cream but without fat. The curry is bright against the roof of the mouth and tiny squares of Granny Smith apples add an unexpected crunch and sweetness. He often balances strength with delicacy. The sauteed local skate ranks among the best treatments I've tasted of this mercurial fish - which can be wonderful or drab depending on the skill and care with which it's prepared. The mild fish is played straight and then underpinned with an earthy mix of soft leeks, artichokes, and spinach. A lobster broth gives it depth and richness. And then as an irresistible fillip, there are these teensy-weensy balls that crunch slightly to the bite. They turn out to be potatoes, and in their almost effete form, they illustrate several things about Schlow's food - one is the just-this-side of fussiness of his garnishes. Each tiny cube of carrot or beet, each daub of red marmalade with a wonderful duck and pistachio terrine, each tiny spear of asparagus is cut to jewel-like precision. Leading to the next aspect of his food - the vegetables are almost always as delicious as the meat or fish. Roasted wild striped bass is masterfully done so that the outside surface is crisp, the interior moist. But then it's hard not to rhapsodize, too, about the slender haricots vert and those baby artichokes with their hint of acidity that work so well against rich nuggets of foie gras. The carrots, turnips, and other root vegetables under the garlic and herb-rubbed chicken are deeply carmalized so that they give a definitely sweet tinge to the dish, offset by a crust that is just this side of fried chicken. Seared salmon with smoked bacon and lentils is accompanied by celery root puree so good it puts mashed potatoes to shame. Not everything works as well. In an appetizer, the sweetbreads are overly crunchy, seemingly a waste of the meat's silken texture. And the mushroom and potato pave with them is too stiff. Roasted squab is excellent, although the shape is rather truncated-looking. But accompanying cabbage leaves filled with short rib meat fall flat because the cabbage is so tough. The pork confit is something Schlow says is begged for by customers, but I'm not a fan - something about the shredded texture and the skim of sweetness is offputting. And a giant veal chop on the first menu was indeed large but rather boring, especially considering its $37 tab. Roast venison loin, which replaced it, is a much more interesting dish. Myers has composed a thoughtful wine list - just reading it is fun; and although numerous bottles come with heady price tags, the more reasonably priced wines are interesting, too. I have to admit I wasn't unknown here, having met Este Benson, the general manager, and Myers many years before I began reviewing when both worked at Michaela's. But the wait staff, a legion of men and women in loose charcoal-gray designer outfits (the costumiere is listed on the menu), are certainly attentive and very well versed in the food and the wines. And Benson and Myers seem to watch the room like hawks. Coming to Radius for dessert alone would be silly, I guess. But it would be worth it. Paul Connors, the pastry chef who has been with Schlow for years, has come into his own in this restaurant. The desserts are beautiful, very sophisticated, and they taste good - really good. A waiter brings a shallow soup bowl with a few candied pecans, medjool dates, and a tuille-shaped butter wafer filled with vanilla ice cream to the table and then pours in hot apple soup. The apple broth is fragrant; the ice cream blends ever so slightly, cold against hot, with the soup; the dates give a deeper note of sweetness; and the nuts crunch. It's heaven, although possibly not as heavenly as a chocolate tasting plate with milk chocolate pot de creme, another pot of white chocolate mousse, and a thrillingly vibrant chocolate sorbet. A frill of oven-dried anise gives an extra accent point to a pear roasted in red wine and served with a little black walnut cake and star anise ice cream. Radius has some quirks that can be unnerving. Even after several visits, the fact that the front door and inner doors have not the least bit of signage made me stop, wondering if I was at the right place. The entryway is cramped, especially around the coat room; on one evening cold air whipped around into the curved dining area each time the door opened. And, although Myers spoke of all the measures taken to reduce noise in the room, it's hard to hear companions when the room fills at the height of the evening. Those are minor annoyances, though, and as the staff and kitchen settle into their rhythms and the instant notoriety dies down, Radius shows every sign of strength - in its cuisine and its ambience. It will be a pleasure to watch it blossom. Dave Mitton dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 9 18:15:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21495 for ; Tue, 9 Mar 1999 18:15:00 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA21754; Tue, 9 Mar 1999 15:07:58 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA16762 for ietf-radius-outgoing; Tue, 9 Mar 1999 15:11:03 -0800 (PST) From: Barney Wolff To: Dave Mitton , ietf-radius@livingston.com Date: Tue, 9 Mar 1999 18:03 EST Subject: Re: (radius) It's a protocol, no it's a trendy restaurant... Content-Type: text/plain Message-ID: <36e5a91b0.5958@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Judging by the complexity and ornateness of the cuisine, are you sure this isn't DIAMETER? Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 10 11:18:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13284 for ; Wed, 10 Mar 1999 11:18:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA17825; Wed, 10 Mar 1999 08:06:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA05062 for ietf-radius-outgoing; Wed, 10 Mar 1999 08:07:57 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199903101605.IAA21954@hsmpka.eng.sun.com> Date: Wed, 10 Mar 1999 07:57:56 -0800 To: "Barney Wolff" , , "Dave Mitton" Subject: Re: (radius) It's a protocol, no it's a trendy restaurant... X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Content-Transfer-Encoding: 7bit >Judging by the complexity and ornateness of the cuisine, are you sure >this isn't DIAMETER? Only if it is prepared with more finesses and is absolutely scrumptious :) :) PatC > >Barney Wolff >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 12 04:01:54 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29478 for ; Fri, 12 Mar 1999 04:01:53 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id AAA05144; Fri, 12 Mar 1999 00:55:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA07263 for ietf-radius-outgoing; Fri, 12 Mar 1999 00:56:51 -0800 (PST) Message-ID: <003d01be6c65$ce5c8860$0378a8c0@dima> From: "Dmitry Goncharenko(at Crimea)" To: Subject: (radius) Acct-Interim-Interval value Date: Fri, 12 Mar 1999 00:51:50 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dmitry Goncharenko(at Crimea)" Hi, Can anybody confirm that my understanding of the following is correct: The Value field contains the number of seconds between each interim update to be sent from the NAS for this session. The value MUST NOT be smaller than 60 and SHOULD NOT be less than 600. So I understood it that the value MUST always be >= 60 but it's better to be at least 600. Or may be there is a mistake in the text and it should say "SHOULD be less than 600" Thank you, Dmitry. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 12 07:11:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00888 for ; Fri, 12 Mar 1999 07:11:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id EAA08409; Fri, 12 Mar 1999 04:04:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA12177 for ietf-radius-outgoing; Fri, 12 Mar 1999 04:07:31 -0800 (PST) From: RXX6550388@aol.com Message-ID: <38cf2d11.36e8ed7b@aol.com> Date: Fri, 12 Mar 1999 05:33:31 EST Mime-Version: 1.0 Subject: (radius) Strengthen your marriage or relationship Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 for Windows 95 sub 56 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: RXX6550388@aol.com Content-Transfer-Encoding: 7bit ------------------------------------------------------------------------------ --------------------------- -Increase your sexual potential -Strengthen your marriage or relationship -Increase lust and romance -Better foreplay -Exercises anyone can do -Increase passion and desire -Be able to have sex more times a day -Satisfy your partners needs Its time to put futher enjoyment into your life, time is limited so use it to its full pleasure. Order our informational guide to Strengthen your marriage or relationship for our print value of $9.00. We will rush your guide to you within days of receiving your payment. Ordering instructions are below. Order by mail send payment to: K.C. Smith 10 East Louisiana Evansville, IN 47711 Make sure to write your address twice to ensure delivery. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Mar 12 10:29:03 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03147 for ; Fri, 12 Mar 1999 10:29:02 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA12753; Fri, 12 Mar 1999 07:22:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA19743 for ietf-radius-outgoing; Fri, 12 Mar 1999 07:22:03 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199903121520.HAA20547@hsmpka.eng.sun.com> Date: Fri, 12 Mar 1999 07:22:19 -0800 To: "Dmitry Goncharenko(at Crimea)" , Subject: Re: (radius) Acct-Interim-Interval value X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Content-Transfer-Encoding: 7bit >Hi, > >Can anybody confirm that my understanding of the following is correct: > > The Value field contains the number of seconds between each > interim update to be sent from the NAS for this session. The value > MUST NOT be smaller than 60 and SHOULD NOT be less than 600. > >So I understood it that the value MUST always be >= 60 but it's better to be >at least 600. Or may be there is a mistake in the text and it should say >"SHOULD be less than 600" > Yes that can be confusing. What this means is that in no case can the value ever be smaller then 60 seconds. However, it is strongly recommended that the value be greater than 600 seconds. If you want to set it smaller than 600 seconds, you certainly can (we just provide the Gun, you can shoot yourself in the foot if you like). The reason why we set the SHOULD was to try to minimize the problem where the Interim Update traffic started to flood the network. PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 15 11:58:03 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22436 for ; Mon, 15 Mar 1999 11:58:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA12098; Mon, 15 Mar 1999 08:50:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA00613 for ietf-radius-outgoing; Mon, 15 Mar 1999 08:49:40 -0800 (PST) From: URTI3319@yahoo.com Message-Id: <199903151645.IAA11947@bast.livingston.com> Subject: (radius) regarding your site Date: Mon, 15 Mar 1999 05:10:16 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: URTI3319@yahoo.com Email removal 800-771-2003, Monday thru Friday 8-5 Pacific Time We'll Submit Your Site To Over 900 Search Engines, Directories, & Indices For A Cost Of Only $ 39.95 100% Money Back Guarantee Immediately Increase Your Sites Exposure READ THIS TESTIMONIAL "The day after we received confirmation from you that you had submitted our web site to search engines, directories and indices we got a "Niagra" of hits! In fact, we doubled and almost tripled our "hits." And since then we have had a pattern of hits that has doubled the number of hits we averaged for the same period last year. For this little country inn, you have developed sales for us we never expected to get." For Just Pennies Each We Will Submit Your Web Site To Over 900 Of The Net's Hottest Search Engines, Directories & Indices. If your site isn't listed in the Search Engines, how can people find you to buy your products or services? See why thousands and thousands of businesses world wide both large and small have come to us to utilize our services. Hotels, Motels, On-Line Stores, Travel Agents, Colleges, Universities, Governments, Fortune 500 companies, Movie Studios, Chambers Of Commerce and many, many more. Shouldn't you give us a call now? Call us toll free at (800) 771-2003 in the USA and Canada or outside the USA at (916) 771-4739 and we'll provide you with all the necessary information to get you submitted Right Away. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 15 13:51:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23500 for ; Mon, 15 Mar 1999 13:51:51 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA16450; Mon, 15 Mar 1999 10:44:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA14097 for ietf-radius-outgoing; Mon, 15 Mar 1999 10:47:08 -0800 (PST) Message-ID: <001401be6f13$a008b6e0$0378a8c0@dima> From: "Dmitry Goncharenko(at Crimea)" To: Subject: (radius) RADIUS proxy Date: Mon, 15 Mar 1999 10:41:24 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dmitry Goncharenko(at Crimea)" Hi, I've got some questions after reading draft-ietf-radius-radius-v2-00.txt. * A RADIUS server can function as both a forwarding server and a remote * server, serving as a forwarding server for some realms and a remote * server for other realms. One forwarding server can forward to any * number of remote servers. A remote server can have any number of * servers forwarding to it and can provide authentication for any * number of realms. One forwarding server can forward to another * forwarding server to create a chain of proxies, although care must be * taken to avoid introducing loops. How can I find out whether the packet was already forwarded by my server? Proxy-state doesn't have defined structure (it's implementation dependent), so I can use for example a vendor specific attribute, but can I add my VSA to the Access-Request that is being forwarded? Will it be reliable to use Request-Authenticator field to match requests? * 1. A NAS sends its access-request to the forwarding server. The * forwarding server decrypts the User-Password, if present, using * the shared secret it knows for the NAS. If a CHAP-Password * attribute is present in the packet and no CHAP-Challenge * attribute is present, the forwarding server MUST leave the * Request-Authenticator untouched or copy it to a CHAP-Challenge * attribute. So, it looks like I can leave Request-Authenticator untouched in any case, right? * 2. The forwarding server encrypts the User-Password, if present, * using the secret it shares with the remote server, sets the * Identifier as needed, and forwards the access-request to the * remote server. Does it mean that I should generate my own Identifier and replace the one in the packet that I received from a RADIUS client? Why was it decided to do? May be it's better (more secure?) to generate my own Request-Authenticator too? Thank you, Dmitry. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 15 15:44:30 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24311 for ; Mon, 15 Mar 1999 15:44:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA20344; Mon, 15 Mar 1999 12:37:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA26199 for ietf-radius-outgoing; Mon, 15 Mar 1999 12:40:37 -0800 (PST) From: Aydin Edguer Message-Id: <199903152038.PAA24621@harlequin.MorningStar.Com> Subject: Re: (radius) RADIUS proxy To: ietf-radius@livingston.com Date: Mon, 15 Mar 1999 15:38:32 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > How can I find out whether the packet was already forwarded by my server? You check for a Proxy-State attribute with a value you recognize. > so I can use for example a vendor specific attribute, but can I add my > VSA to the Access-Request that is being forwarded? No, you should not add a Vendor-Specific attribute - you should use the Proxy-State attribute. Yes, you should add the Proxy-State attribute to the Access-Request before forwarding it. Yes, the server could add a Vendor-Specific attribute, but adding a Vendor-Specific attribute for this purpose is not necessary or desirable. > it looks like I can leave Request-Authenticator untouched in any case, > right? No, the Request-Authenticator should be regenerated by the proxy server. The value SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server), since repetition of a request value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. -- RFC 2138 RADIUS Regeneration is the best way to guarantee that the Request-Authenticator is unique over the lifetime of the shared secret between the proxy server and the home server. > Does it mean that I should generate my own Identifier and replace the > one in the packet that I received from a RADIUS client? Yes, you should. This is because there can only be a single example of request tuple (IP addr, UDP port, Identifier) active at one time between the proxy server and the home server and the best way to guarantee this is to regenerate an Identifier, since two or more NAS may be using the same Identifier at one time. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 15 16:19:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24524 for ; Mon, 15 Mar 1999 16:19:34 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA21321; Mon, 15 Mar 1999 13:12:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA29884 for ietf-radius-outgoing; Mon, 15 Mar 1999 13:15:33 -0800 (PST) Message-ID: <003901be6f28$77f4cee0$0378a8c0@dima> From: "Dmitry Goncharenko(at Crimea)" To: Subject: Re: (radius) RADIUS proxy Date: Mon, 15 Mar 1999 13:11:58 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dmitry Goncharenko(at Crimea)" >> How can I find out whether the packet was already forwarded by my server? >You check for a Proxy-State attribute with a value you recognize. But the attribute is implementation dependent so any other server anywhere in the loop could add the same Proxy-State as I did. It doesn't look as a reliable way to check for me. Is the anything that prohibits to add a Proxy-State with the same value to the request? >> it looks like I can leave Request-Authenticator untouched in any case, >> right? > >No, the Request-Authenticator should be regenerated by the proxy server. ... >Regeneration is the best way to guarantee that the Request-Authenticator >is unique over the lifetime of the shared secret between the proxy server >and the home server. Ok, thanks, it's just not clear from the new draft and what is more from RFC when it's related with proxy. Dmitry. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 15 16:48:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24764 for ; Mon, 15 Mar 1999 16:48:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA22141; Mon, 15 Mar 1999 13:40:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA03671 for ietf-radius-outgoing; Mon, 15 Mar 1999 13:43:00 -0800 (PST) From: William Bulley Message-Id: <199903152144.QAA24469@ohm.merit.edu> Subject: Re: (radius) RADIUS proxy To: dima@crimea.com Date: Mon, 15 Mar 1999 16:44:23 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <003901be6f28$77f4cee0$0378a8c0@dima> from "Dmitry Goncharenko" at Mar 15, 99 01:11:58 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William Bulley Content-Transfer-Encoding: 7bit According to Dmitry Goncharenko: > > But the attribute is implementation dependent so any other server anywhere > in the loop could add the same Proxy-State as I did. It doesn't look as a > reliable way to check for me. Is the anything that prohibits to add a > Proxy-State with the same value to the request? I have long wanted to implement John Vollbrecht's suggestion that the Proxy-State be a complex or multi-valued beast. But events have conspired to prevent that implementation, sigh... :-( IIRC the idea was to place the source machine's IP address and UDP port in the Proxy-State attribute sent out to "mark" the Access-Request as having come from "me" so that when it came back to "me" as an Access-Accept (or whatever) that I would be able to identify it as "mine" This is sort of like the problem our human immune system has to deal with in detecting foreign protein as distinct from its own cells... :-) Regards, web... -- William Bulley Senior Systems Research Programmer Merit Network, Inc. Email: web@merit.edu 4251 Plymouth Road, Suite C Phone: (734) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (734) 647-3185 [Sniglets (c) 1999] Hip-Hop-crisy: noun; the state-of-being where a person pretends to like the Grammy Award winning musical art form... - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 15 17:49:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25178 for ; Mon, 15 Mar 1999 17:49:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA24875; Mon, 15 Mar 1999 14:41:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA11814 for ietf-radius-outgoing; Mon, 15 Mar 1999 14:44:53 -0800 (PST) From: Aydin Edguer Message-Id: <199903152242.RAA24650@harlequin.MorningStar.Com> Subject: Re: (radius) RADIUS proxy To: ietf-radius@livingston.com Date: Mon, 15 Mar 1999 17:42:54 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > > > How can I find out whether the packet was already forwarded by my server? > > You check for a Proxy-State attribute with a value you recognize. > > But the attribute is implementation dependent so any other server anywhere > in the loop could add the same Proxy-State as I did. Yes, that is theoretically possible. It is, however, very unlikely to be true, if you are judicious in choosing the format of your Proxy-State values. For instance - you could use: "Vendor OID [774] : src.ip.ad.dr : srcport" It is unlikely that someone will use the same string by chance. > Is the anything that prohibits to add a Proxy-State with the same value > to the request? Sure. Because the software should look into the packet for Proxy-State and if it sees that the Access-Request already has a Proxy-State that it thinks it added, it should log an error message saying: "hey admin, I think this packet is stuck in a loop" and possibly drop the packet. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 15 18:19:27 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25407 for ; Mon, 15 Mar 1999 18:19:26 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA25870; Mon, 15 Mar 1999 15:12:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA15435 for ietf-radius-outgoing; Mon, 15 Mar 1999 15:16:16 -0800 (PST) Date: Mon, 15 Mar 99 18:12:51 EST From: David Bolen To: Aydin Edguer Subject: Re: (radius) RADIUS proxy In-Reply-To: Your message of Mon, 15 Mar 1999 17:42:54 -0500 (EST) Cc: ietf-radius@livingston.com Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: David Bolen Aydin Edguer writes: > Sure. Because the software should look into the packet for Proxy-State and > if it sees that the Access-Request already has a Proxy-State that it thinks > it added, it should log an error message saying: "hey admin, I think this > packet is stuck in a loop" and possibly drop the packet. Except that you're assuming a packet that might loop back to you as another request would still have the Proxy-State you inserted, a semantic which is not guaranteed, and a semantic which the recent discussion on this list showed that some implementations would not produce. The inserted Proxy-State is only required to be returned unchanged by the server you forwarded it to within it's response, and not necessarily preserved during other forwarding hops of the request. If you want to do loop detection based on an attribute (other than peer address, identifier, or other items) then I think the only guaranteed way to do it is with a VSA which is going to have to be preserved along any forwarding hops. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 15 19:36:08 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25866 for ; Mon, 15 Mar 1999 19:36:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA28146; Mon, 15 Mar 1999 16:29:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA23284 for ietf-radius-outgoing; Mon, 15 Mar 1999 16:31:06 -0800 (PST) From: Aydin Edguer Message-Id: <199903152327.SAA24663@harlequin.MorningStar.Com> Subject: Re: (radius) RADIUS proxy To: ietf-radius@livingston.com Date: Mon, 15 Mar 1999 18:27:40 -0500 (EST) X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer Content-Transfer-Encoding: 7bit > > Sure. Because the software should look into the packet for Proxy-State and > > if it sees that the Access-Request already has a Proxy-State that it thinks > > it added, it should log an error message saying: "hey admin, I think this > > packet is stuck in a loop" and possibly drop the packet. > > Except that you're assuming a packet that might loop back to you... No, I am not assuming anything. I was answering a specific question. The question was "Is the anything that prohibits to add a Proxy-State with the same value to the request?". The answer is yes. The fact that some downstream RADIUS implementer is trying to filter out Proxy-State attributes, has no bearing on the answer to the question. > The inserted Proxy-State is only required to be returned unchanged by > the server you forwarded it to within it's response, and not > necessarily preserved during other forwarding hops of the request. Correct according to RFC 2138 but possibly not correct (depending upon interpretation) according to the new draft document that will become the new Draft Standard for RADIUS: The forwarding server MUST NOT modify any other Proxy-States that were in the packet and MUST NOT change the order of any attributes of the same type, including Proxy State. ... A forwarding server MUST not modify existing Proxy-State, State, or Class attributes present in the packet. -- draft-ietf-radius-radius-v2-00.txt The question is whether deleting an attribute is a subset of modifying an attribute. Either way, since there may always be older servers in a stream, you cannot absolutely count on Proxy-State for loop detection. But the specific question I was answering was not about loop detection, it was whether you could have a packet with the same Proxy-State in it twice. My answer remains "no", since the server *should* not allow that to happen, because it is a definite symptom of a loop, even if loops cannot always be detected. > If you want to do loop detection based on an attribute (other than > peer address, identifier, or other items) then I think the only > guaranteed way to do it is with a VSA which is going to have to be > preserved along any forwarding hops. Excuse me, but how is that guaranteed? A proxy server can filter out Vendor-Specific attributes just as easily as it can filter out the Proxy-State. In fact, some RADIUS servers, for better or for worse, will filter out any unknown Vendor-Specific attribute automatically. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 15 19:58:18 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25943 for ; Mon, 15 Mar 1999 19:58:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA29059; Mon, 15 Mar 1999 16:49:57 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA25205 for ietf-radius-outgoing; Mon, 15 Mar 1999 16:53:32 -0800 (PST) Date: Mon, 15 Mar 99 19:50:04 EST From: David Bolen To: Aydin Edguer Cc: ietf-radius@livingston.com Subject: Re: (radius) RADIUS proxy In-Reply-To: Your message of Mon, 15 Mar 1999 18:27:40 -0500 (EST) Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: David Bolen > No, I am not assuming anything. I was answering a specific question. Sorry, I chose to reply to the most recent message (your second response) in the thread that was about loop detection... your first of your pair of responses did specifically say to use Proxy-State for loop detection: > How can I find out whether the packet was already forwarded by my server? You check for a Proxy-State attribute with a value you recognize. > so I can use for example a vendor specific attribute, but can I add my > VSA to the Access-Request that is being forwarded? No, you should not add a Vendor-Specific attribute - you should use the Proxy-State attribute. and I sort of just referenced both in my reply at once. Sorry for not being clearer. > The question was "Is the anything that prohibits to add a Proxy-State > with the same value to the request?". The answer is yes. Why? If two servers use the same mechanism for Proxy-State, there's nothing formally stopping them from both inserting an identically encoded Proxy-State object, and if the second server preserves the first in the forwarded request, they will both be present. And if two servers use different mechanisms, there's no guarantee they can't produce the same result. > Correct according to RFC 2138 but possibly not correct (depending upon > interpretation) according to the new draft document that will become > the new Draft Standard for RADIUS: Which was what the recent discussion on this list was about that I alluded to. Discussion at that time included several mentions of earlier Proxy-State's not necessarily remaining in the forwarded copy (and the issue of whether that conflicted with "modify" in the text). Not sure what if any change to the text is forthcoming, if any. > But the specific question I was answering was not about loop detection, > it was whether you could have a packet with the same Proxy-State in it > twice. My answer remains "no", since the server *should* not allow that > to happen, because it is a definite symptom of a loop, even if loops cannot > always be detected. I'm not sure I agree. If you have two different implementations, there is no guarantee that they might not produce the same Proxy-State. > Excuse me, but how is that guaranteed? A proxy server can filter out > Vendor-Specific attributes just as easily as it can filter out the > Proxy-State. Not if it wants to forward on an identical request that it received. The Proxy-State attribute is by definition an inserted attribute that is an artifact of the proxy process, and has no bearing on anything but the specific hop over which it is received (e.g., it's not part of the original request). But a VSA is not so limited, and it would not be smart of a server to purge a VSA in general. I'll agree however that "guarantee" is perhaps a bit strong. Certainly, there may exist administrative controls that filter a request across an administrative proxy boundary (our own server does this), but I definitely think a VSA has a much better chance of remaining unchanged through the forwarding process than Proxy-State with respect to loop detection - again if you want to do so based on attributes. > Proxy-State. In fact, some RADIUS servers, for better or for worse, > will filter out any unknown Vendor-Specific attribute automatically. If they're doing that during a proxy stage, then I'd consider them very poor implementations - unless such filtering is part of a larger administrative restriction model and not just because they didn't recognize the attribute. They can't know whether or not a final RADIUS server will be able to make use of that information. After all, that's the whole point of VSAs - they may not be globally understood, but can still be processed (or transparently forwarded) as part of a request. But I agree with your point in general - while I still consider them more likely to survive than Proxy-State, they probably aren't all that much more guaranteed. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 05:01:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08383 for ; Tue, 16 Mar 1999 05:01:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA10176; Tue, 16 Mar 1999 01:54:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA18083 for ietf-radius-outgoing; Tue, 16 Mar 1999 01:57:20 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Tue, 16 Mar 1999 10:40:03 +0200 MR-Received: by mta BTMV98; Relayed; Tue, 16 Mar 1999 10:40:21 +0200 MR-Received: by mta BTMA06; Relayed; Tue, 16 Mar 1999 10:40:16 +0200 Disclose-recipients: prohibited Date: Tue, 16 Mar 1999 10:40:03 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) RADIUS proxy In-reply-to: To: ietf-radius Message-id: <9103401016031999/A14059/BTMV98/11D382A80200*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D382A80200 X400-MTS-identifier: [;9103401016031999/A14059/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT > > How can I find out whether the packet was already forwarded by my server? > > You check for a Proxy-State attribute with a value you recognize. > > > so I can use for example a vendor specific attribute, but can I add my > > VSA to the Access-Request that is being forwarded? > > No, you should not add a Vendor-Specific attribute - you should use the > Proxy-State attribute. > Our proxy implementation uses following attribute combos to detect loops: NAS-Id (attr 4 or 32) Acct-Session-Id (if available in Access-Request) OR NAS-Id NAS-Port User-Name This of course assuming these attributes are not altered along the proxy path. >> Correct according to RFC 2138 but possibly not correct (depending upon >> interpretation) according to the new draft document that will become >> the new Draft Standard for RADIUS: > >Which was what the recent discussion on this list was about that I >alluded to. Discussion at that time included several mentions of >earlier Proxy-State's not necessarily remaining in the forwarded copy >(and the issue of whether that conflicted with "modify" in the text). >Not sure what if any change to the text is forthcoming, if any. > I do not believe preservation of Proxy-States through proxy hops is required, but it may be desirable in some roaming environments. IMO, the draft/RFC can list this preservation as an example or even recommended practice, but not as a requirement the way it is formulated today. Kind regards, Marc. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 05:05:53 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08451 for ; Tue, 16 Mar 1999 05:05:52 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA10482; Tue, 16 Mar 1999 01:58:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA18280 for ietf-radius-outgoing; Tue, 16 Mar 1999 02:02:25 -0800 (PST) Message-ID: <008201be6f93$899a50a0$0378a8c0@dima> From: "Dmitry Goncharenko(at Crimea)" To: Subject: Re: (radius) RADIUS proxy Date: Tue, 16 Mar 1999 01:47:27 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dmitry Goncharenko(at Crimea)" >But the specific question I was answering was not about loop detection, >it was whether you could have a packet with the same Proxy-State in it >twice. My answer remains "no", since the server *should* not allow that >to happen, because it is a definite symptom of a loop, even if loops cannot >always be detected. May be it makes sense to rewrite the paragraph about a proxy like this: The forwarding server MAY add one Proxy-State attribute to the packet. If it does, the Proxy-State MUST appear after any other Proxy-States in the packet. The forwarding server MUST NOT add a Proxy-State attribute with a value that already exists in the packet for another Proxy-State. The forwarding server MUST NOT modify or delete any other Proxy-States that were in the packet and MUST NOT change the order of any attributes of the same type, including Proxy State. Dmitry. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 05:06:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08461 for ; Tue, 16 Mar 1999 05:06:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA10523; Tue, 16 Mar 1999 01:59:01 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA18308 for ietf-radius-outgoing; Tue, 16 Mar 1999 02:02:48 -0800 (PST) Message-ID: <008101be6f93$88af0640$0378a8c0@dima> From: "Dmitry Goncharenko(at Crimea)" To: Subject: Re: (radius) RADIUS proxy Date: Tue, 16 Mar 1999 01:47:21 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dmitry Goncharenko(at Crimea)" >For instance - you could use: > "Vendor OID [774] : src.ip.ad.dr : srcport" >It is unlikely that someone will use the same string by chance. It's unlikely but possible. >Sure. Because the software should look into the packet for Proxy-State and >if it sees that the Access-Request already has a Proxy-State that it thinks >it added, it should log an error message saying: "hey admin, I think this >packet is stuck in a loop" and possibly drop the packet. But the Proxy-State from your example could be added by any downstream server in the chain and in this case I'd drop a correct request. Dmitry. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 08:18:25 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09549 for ; Tue, 16 Mar 1999 08:18:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id FAA13236; Tue, 16 Mar 1999 05:11:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA23825 for ietf-radius-outgoing; Tue, 16 Mar 1999 05:12:31 -0800 (PST) Message-ID: <002e01be6fae$12085080$0378a8c0@dima> From: "Dmitry Goncharenko(at Crimea)" To: Subject: Proxy loop detection (was: Re: (radius) RADIUS proxy) Date: Tue, 16 Mar 1999 05:05:36 -0800 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Dmitry Goncharenko(at Crimea)" >an attribute. Either way, since there may always be older servers in >a stream, you cannot absolutely count on Proxy-State for loop detection. May be in this case another technique could be used, like it's done in IP. Instead of trying to detect loops some Hop-Counter attribute (or field) can be used. First proxy in the chain sets this attribute to a maximum value of hops. Every forwarding proxy decrements the value and when it reaches 0 the request must be rejected. I'm not sure whether anything like this was discussed before in the list so I'm sorry if it was already decided as a bad idea. Dmitry. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 08:42:16 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09724 for ; Tue, 16 Mar 1999 08:42:15 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id FAA13704; Tue, 16 Mar 1999 05:35:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA24718 for ietf-radius-outgoing; Tue, 16 Mar 1999 05:38:51 -0800 (PST) Message-Id: <199903161340.IAA09202@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) RADIUS proxy In-reply-to: Your message of "Mon, 15 Mar 1999 16:44:23 EST." <199903152144.QAA24469@ohm.merit.edu> Date: Tue, 16 Mar 1999 08:40:09 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok William Bulley wrote: > IIRC the idea was to place the source machine's IP address > and UDP port in the Proxy-State attribute sent out to "mark" > the Access-Request as having come from "me" so that when it > came back to "me" as an Access-Accept (or whatever) that I > would be able to identify it as "mine" A normal RADIUS client doesn't need a Proxy-State to match Access-Accept's to Access-Request's. If a RADIUS server is proxying a request, it's acting as a RADIUS client to an end server, so it really doesn't need a Proxy-State, either. I'm not saying that Proxy-State isn't *useful*. It's just that it's possible to modify the proxy server implementation to make Proxy-State unnecessary. e.g. For each end server, the proxy server opens a UDP port in 1024..64000, and sends proxied request out those ports. Packets received on those ports MUST come from the matching end server, and those packets are matched to proxied requests through the Request Authenticator. There's no room for spoofed or lost packets without the proxy server knowing about it. If some proxy server down the chain deletes all Proxy-State attributes, our proxy server won't care. What exactly is Proxy-State for, then? Is it simply a tag to make it easier to implement simple proxy servers? So far as I can see, the Proxy-State attribute is *informational*, and should not be use to make any sort of decisions on the proxy server. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 12:43:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11896 for ; Tue, 16 Mar 1999 12:43:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA23039; Tue, 16 Mar 1999 09:35:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA14663 for ietf-radius-outgoing; Tue, 16 Mar 1999 09:34:04 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Tue, 16 Mar 1999 11:53 EST Subject: Re: (radius) RADIUS proxy Content-Type: text/plain Message-ID: <36ee96060.488e@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff > From: Alan DeKok > Date: Tue, 16 Mar 1999 08:40:09 -0500 > > What exactly is Proxy-State for, then? Is it simply a tag to make > it easier to implement simple proxy servers? So far as I can see, the > Proxy-State attribute is *informational*, and should not be use to > make any sort of decisions on the proxy server. The original intent was to make a stateless proxy possible. That is, the proxy could encode all its state into the attribute, keeping none. I don't know how the proxy was supposed to choose the ID field if it truly kept no state, but that was the idea, anyway. I would object to language denying the proxy the right to strip proxy- state and keep it internally, to send back in its response. My proxy has to deal with a server that does not understand proxy-state, so that's what I do. If anybody objects, I would claim that I'm not really a proxy, but a server that happens to use RADIUS as a way to communicate with its database. Surely that cannot be forbidden, as a proxy from RADIUS to TACACS or some other auth protocol would be faced with the same issue. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 15:00:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13201 for ; Tue, 16 Mar 1999 15:00:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA00380; Tue, 16 Mar 1999 11:53:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA00253 for ietf-radius-outgoing; Tue, 16 Mar 1999 11:56:46 -0800 (PST) Message-Id: <199903161958.OAA10615@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) RADIUS proxy In-reply-to: Your message of "Tue, 16 Mar 1999 11:53:00 EST." <36ee96060.488e@databus.databus.com> Date: Tue, 16 Mar 1999 14:58:02 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok Barney Wolff wrote: > The original intent was to make a stateless proxy possible. That is, > the proxy could encode all its state into the attribute, keeping none. That's what I thought. But subject to recent discussions, probably impossible. So the Proxy-State field is mostly useless, especially since many RADIUS servers expect to parse it in a particular implementation-defined format. > I would object to language denying the proxy the right to strip proxy- > state and keep it internally, to send back in its response. My proxy > has to deal with a server that does not understand proxy-state, so > that's what I do. I hope that this behaviour is configurable. > If anybody objects, I would claim that I'm not really a proxy, but > a server that happens to use RADIUS as a way to communicate with its > database. Surely that cannot be forbidden, as a proxy from RADIUS > to TACACS or some other auth protocol would be faced with the same > issue. Hey, it can't be any worse than other implementation-specific RADIUS decisions I've seen. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 15:54:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13874 for ; Tue, 16 Mar 1999 15:54:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA02903; Tue, 16 Mar 1999 12:47:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA06140 for ietf-radius-outgoing; Tue, 16 Mar 1999 12:50:58 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Tue, 16 Mar 1999 15:47 EST Subject: Re: (radius) RADIUS proxy Content-Type: text/plain Message-ID: <36eec42d0.4b3b@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff > From: Alan DeKok > Date: Tue, 16 Mar 1999 14:58:02 -0500 > > So the Proxy-State field is mostly useless, especially since many > RADIUS servers expect to parse it in a particular > implementation-defined format. I don't disagree on the worth of the attribute. But any server that tries to parse proxy-state is making a serious error. It's supposed to be opaque, interpretable only by the thing that generated it. A NAS or proxy that needs to communicate non-standard info to a server should be using the VS attribute, not misusing proxy-state. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 18:16:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15294 for ; Tue, 16 Mar 1999 18:16:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA08434; Tue, 16 Mar 1999 15:09:00 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA22904 for ietf-radius-outgoing; Tue, 16 Mar 1999 15:12:06 -0800 (PST) Message-Id: <199903162310.PAA21476@shell4.ba.best.com> Subject: Re: (radius) RADIUS proxy (fwd) To: ietf-radius@livingston.com Date: Tue, 16 Mar 1999 15:10:32 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Content-Transfer-Encoding: 7bit Once upon a time Alan DeKok shaped the electrons to say... > A normal RADIUS client doesn't need a Proxy-State to match >Access-Accept's to Access-Request's. If a RADIUS server is proxying a This isn't the trouble at hand - a normal client-server setup doesn't have loop potential either. The issue isn't matching the reply to the request - the trouble is knowing that a loop exists. Proxy A talks to Proxy B which talks to Proxy C - which talks to Proxy A. Frankly I don't believe there is any foolproof method to detect loops. VSA may be the best, as I agree with the sentiment that any server that arbitrarily removes VSAs isn't well behaved. But Proxy-State can also be useful. Not all servers remove it, personally I think that even those that can should NOT do so by default - but make it an option to be used ONLY when required. As in when talking to a server that does not understand Proxy-State. Don't force poor behavior by implementation. I think being able to talk to legacy servers is good - but don't lower the bar when it doesn't have to be. There is the *chance* of another proxy adding a clone Proxy-State. But I think the odds of a proxy server that just happens to be in a loop condition with another server just happens to insert a Proxy-State which happens to be a current value on the first server is sufficiently low. Of course, I'd also hope that the humans involved would take precautions to avoid loops as best they can - while acknowleding that, especially in complex proxy meshes, they will happen. Proxy-State does, or at lease, should, make it easier to match replies to requests - but I agree that other methods should be able to handle that. Maybe I'm misunderstanding, but my impression is that the client-server relationship DOES still exist between proxy servers. And that the reply MUST come from the same IP/port tuple that the request was sent to. Which would mean the standard NAS-server style matching still works. -MZ -- -=*X I'm going down... under that is! X*=- Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium "A little nonsense now and then, is relished by the wisest men" 781-788-0130 Hail Discordia! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Mar 16 20:49:12 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16641 for ; Tue, 16 Mar 1999 20:49:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA11920; Tue, 16 Mar 1999 17:41:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA07713 for ietf-radius-outgoing; Tue, 16 Mar 1999 17:44:46 -0800 (PST) From: dkieuryt@cs.interbusiness.it Date: Tue, 16 Mar 1999 20:43:39 -0500 (EST) Message-Id: <199903170143.UAA16400@smtp4.mindspring.com> To: Subject: (radius) Hot Business You Can Work From Home Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: dkieuryt@cs.interbusiness.it We are sorry if you received this email in error. To be removed from this list please send an email to the address below. mailto:discontinueme@mailroom.com $ ENTREPRENEURS $ CALL NOW!!! 1-888-807-4061 *Tired of working for someone else and getting paid what "they" feel you're worth? *Tired of the "get-rich-quick" $5 fantasy programs? *Tired of the MLM "dream scene"? *Looking for a legitimate home-based enterprise that can generate you $10k-$20k+ monthly? THEN CHECK THIS OUT!!! >90% profit on all sales that pay you from $1250-$6250 per sale >No personal selling or "convince me" tactics involved >No special skills or equipment required or "inventory" to keep >Complete information system in place does the explaining for you >Free-enterprise in its purest form, not MLM or franchise >Full training and support in an environment of upmost integrity >Exceptional products, not "vitamins, lotions, and potions" >Lead generation system that brings qualified prospects to you >Multiple 6 figure income realistically attainable in 1st year >2 to 3 year retirement program... PERIOD! This program is all about money... how to make it, how to keep it, and how to make it work for you. CALL NOW!!! 1-888-807-4061 Leave your name and number. After a brief interview, I will get you all the information you need to make your own relaxed and intelligent decision about your future. (Serious inquiries only please) J. Hampton - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Mar 17 09:13:07 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29347 for ; Wed, 17 Mar 1999 09:13:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA25203; Wed, 17 Mar 1999 06:04:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA03416 for ietf-radius-outgoing; Wed, 17 Mar 1999 06:04:18 -0800 (PST) Message-Id: <199903171405.JAA14471@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) RADIUS proxy (fwd) In-reply-to: Your message of "Tue, 16 Mar 1999 15:10:32 PST." <199903162310.PAA21476@shell4.ba.best.com> Date: Wed, 17 Mar 1999 09:05:34 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok MegaZone wrote: > The issue isn't matching the reply to the request - the trouble is knowing > that a loop exists. Proxy A talks to Proxy B which talks to Proxy C - which > talks to Proxy A. Frankly I don't believe there is any foolproof method > to detect loops. From recent discussion, I doubt there's *any* method for detecting loops, as too many servers play incompatible games with Proxy-State. > VSA may be the best, as I agree with the sentiment that any server > that arbitrarily removes VSAs isn't well behaved. Certain implementation decisions make it easier for the server to drop attributes it doesn't understand. e.g. An incoming RADIUS request is parsed into machine-specific data structures (VALUE_PAIRs), and the proxied packet is parsed from those data structures to RADIUS attributes. So any attribute which doesn't make it into a structure doesn't get proxied. This behaviour is probably incorrect, and proxies most likely should copy RADIUS attributes "raw", if at all possible. I guess I'm being pedantic here in coming up with a lot of "what if" situations, and pointing out implementation problems. But I like to be clear on exactly what's going on and why, before making an informed decision. > Proxy-State does, or at lease, should, make it easier to match replies to > requests - but I agree that other methods should be able to handle that. > Maybe I'm misunderstanding, but my impression is that the client-server > relationship DOES still exist between proxy servers. And that the > reply MUST come from the same IP/port tuple that the request was sent to. > Which would mean the standard NAS-server style matching still works. I believe so. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Mar 18 04:25:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19093 for ; Thu, 18 Mar 1999 04:25:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA25348; Thu, 18 Mar 1999 01:18:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA08489 for ietf-radius-outgoing; Thu, 18 Mar 1999 01:18:36 -0800 (PST) From: TButlerjr@aol.com Message-ID: Date: Thu, 18 Mar 1999 03:57:01 EST Mime-Version: 1.0 Subject: (radius) requested Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Mailer: AOL 3.0 16-bit for Windows sub 46 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: TButlerjr@aol.com Content-Transfer-Encoding: 7bit INTERNATIONAL DRIVER'S LICENSE Need a new driver's license? Too many points or other trouble? Want a license that can never be suspended or revoked? Want ID for nightclubs or hotel check-in? Avoid tickets, fines, and mandatory driver's education. Protect your privacy, and hide your identity. The United Nations gave you the privilege to drive freely throughout the world! (Convention on International Road Traffic of September 19, 1949 & World Court Decision, The Hague, Netherlands, January 21, 1958) Take advantage of your rights. Order a valid International Driver's License that can never be suspended or revoked. Confidentiality assured. CALL NOW!!! 1-937-586-9313 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 22 02:34:41 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15652 for ; Mon, 22 Mar 1999 02:34:41 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id XAA18572; Sun, 21 Mar 1999 23:28:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA07497 for ietf-radius-outgoing; Sun, 21 Mar 1999 23:30:17 -0800 (PST) From: Silvia_Brown@gte.net Message-Id: <199903220724.XAA68476@mail.wa.freei.net> Subject: (radius) Find Out What The Future Holds For You? Date: Sun, 21 Mar 99 22:45:12 Pacific Standard Time X-Priority: 3 X-MSMailPriority: Normal Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Silvia_Brown@gte.net LIVE PERSONAL PSYCHIC! (as seen on T.V.) LEARN TODAY WHAT YOUR FUTURE HOLDS FOR LOVE, FAMILY AND MONEY. ASTROLOGY CLAIRVOYANCY NUMEROLOGY TAROT ALL QUESTIONS ANSWERED IMMEDIATELY! REALIZE YOUR OWN DESTINY! CALL RIGHT NOW! 1-900-226-4140 or 1-800-372-3384 for VISA, MC (These are not sex lines!) This message is intended for Psyhic Readers , Psychic Users and people who are involved in the $1 Billion Dollar a year Psychic Industry. If this message has reached you in error, please disregard it and accept our apoligies. To be removed from this list, please respond with the subject "remove". Thank you. Stop Unsolicited Commercial Email-join CAUCE (http://www.cauce.org) Support HR 1748, the anti-spam bill. LIVE PERSONAL PSYCHIC! (as seen on T.V.) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Mar 22 02:59:02 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15700 for ; Mon, 22 Mar 1999 02:59:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id XAA18841; Sun, 21 Mar 1999 23:52:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA08250 for ietf-radius-outgoing; Sun, 21 Mar 1999 23:56:16 -0800 (PST) From: pam215@hotmail.com Date: Sun, 21 Mar 99 23:30:47 EST To: Friend@public.com Subject: (radius) Accept Credit Cards Online!!! Message-ID: <> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: pam215@hotmail.com INCREASE SALES UP TO 100% ACCEPT CREDIT CARDS OVER THE INTERNET *** NO SETUP FEES Good Credit / Bad Credit/ No Credit **** NO PROBLEM****!!! It Just Doesn't Matter - Everyone Gets Approved No Upfront Fees For Application-Processing While Others Charge You From $195 TO $250 To Get Set Up WE CHARGE ZERO FOR SETUP FEES!! Limited Offer So Take Advantage Of It!! We Specialize In Servicing The Following: *Multilevel Marketing *Mail Order/Phone Sales *At Home Business*INTERNET BASED BUSINESS *New Business*Small Business Whatever!!! We Do It All!!! Everyone Is Welcome! Call us toll free today 1-800-600-0343 ext. 2310 What Can We Do For Your Company???? >>>>>INTERNET SERVICE<<<<< SECURE REAL-TIME ON-LINE TRANSACTIONS make it as easy as possible for your customers to purchase your products or services. We use SSL SECURITY (best on the NET today). Now tell me if this doesn't sound intriguing, lets say a customer visits your web site and decides they want to buy your product(s) or service(s). They would simply enter their credit card information and receive an approval WITHIN 5 SECONDS. That's all there is to it!!! From that point on, the sale is complete and the money will be directly deposited into your business checking account within 24 to 48 hours. So you will have LIQUID ASSETS AVAILABLE ALMOST IMMEDIATELY!!!! Your customer will be e-mailed a receipt and you will be e-mailed an invoice slip, all instantaneously. Now, since this program is automated for 24 hours a day 7 days a week, you will be receiving orders and making money in your sleep! IT'S JUST THAT EASY!!!! WHAT MAKES US SO SPECIAL????? * We process over $4 Billion in credit card transactions every year. * We have over 100,000 merchants online and growing. * We offer secured on-line real time transactions. * We offer 24 hour customer service 7 days a week in 17 different languages. * We offer complete training and installation through our technical support group. * We offer a life time warranty and unlimited upgrades. * We help make money for your company and your customers. >>>>>REFERRAL PROGRAM<<<<< ****EARN $200 PER REFERRAL**** ****ATTENTION MARKETING DIRECTORS**** Increase your marketability by giving your customers the opportunity to accept credit cards as an added feature offered with your companies product(s) or service(s)!!!! Ideal opportunity for WEB HOSTS, WEB PAGE DESIGNERS, INTERNET SERVICE PROVIDERS, AND WEB MALLS!!!!! ***MLM's (Multi-Level Marketer's) Welcome.*** If you've ever attempted to acquire a merchant account, you know how difficult this procedure can normally be. We can arranged for all of your associates to be PRE-APPROVED FOR A CREDIT CARD MERCHANT ACCOUNT. This opportunity not only benefits your clients but will also add another selling feature for your company. Each client that establishes a merchant account with us will result in a $200 REFERRAL FEE to your company. ***$10,000 per month in referral fees is not uncommon with large INTERNET PROVIDERS*** If your an opportunist, this is the MARKETING FEATURE YOU'VE BEEN WAITING FOR. >>>>>CONTACT INFORMATION<<<<< Just place a toll free phone call to 1-800-600-0343 ext.2310. Leave a message with your Name, Phone Number, and a brief description of your type of business. Once you call, an account executive will contact you within 24 hours to discuss your options, answer your questions, and start you on your way to financial success. DON'T DELAY!!!! ACT TODAY!!! ____________________________________________________________ To be Removed send and email to stevencsi@mailcity.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Mar 28 14:31:30 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03600 for ; Sun, 28 Mar 1999 14:31:29 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA14973; Sun, 28 Mar 1999 11:24:37 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA01043 for ietf-radius-outgoing; Sun, 28 Mar 1999 11:26:39 -0800 (PST) From: ooooo6521@eastmail.com Message-Id: <199903281922.LAA14957@bast.livingston.com> Subject: (radius) VIDEO CONFERENCE VIA THE INTERNET Date: Tue, 6 Apr 1999 02:12:48 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: ooooo6521@eastmail.com SUBJECT: VIDEO CONFERENCE VIA INTERNET. Complete video kit includes camera, software and complete tutorial instructions. Inexpensive! One for $89 or two for $165, plus shipping. Our Guide to Video Conferencing adds value to this very attractive purchase. Communicate visually in real time with friends. Collaborate on documents or spreadsheets with business partners while video conferencing on internet. Capable of applications sharing and video clips also. Call toll free 1-800-835-9511 to order your exciting new communications system. We accept Visa, Mastercard, American Express Or send check to (plus $6 shipping per unit) to: Box 317, Kaunakakai, Hawaii 96748. PC, Mac, USB Port or Parallel Port compatible. Confirmation of your order and projected arrival date will be e mailed. Catch the new wave of free two-way video communicating via internet Pictures, especially video, take up much space on the internet. This package is intended for wise and judicious video use. to be removed email ooooo6521@eastmail.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.