From owner-ietf-radius@livingston.com Fri Apr 2 16:33: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 QAA04310 for ; Fri, 2 Apr 1999 16:33: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 NAA21145; Fri, 2 Apr 1999 13:24:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA04630 for ietf-radius-outgoing; Fri, 2 Apr 1999 13:26:10 -0800 (PST) Message-Id: <199904022122.QAA04030@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-05.txt Date: Fri, 02 Apr 1999 16:22:43 -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-05.txt Pages : 14 Date : 01-Apr-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-05.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-05.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-05.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: <19990401100618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-acc-clientmib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-acc-clientmib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990401100618.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 Apr 2 16:33: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 QAA04324 for ; Fri, 2 Apr 1999 16:33: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 NAA21139; Fri, 2 Apr 1999 13:24:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA04641 for ietf-radius-outgoing; Fri, 2 Apr 1999 13:26:16 -0800 (PST) Message-Id: <199904022122.QAA04042@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-05.txt Date: Fri, 02 Apr 1999 16:22:51 -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-05.txt Pages : 15 Date : 01-Apr-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-05.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-05.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-05.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: <19990401100712.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-acc-servmib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-acc-servmib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990401100712.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 Apr 2 16:40: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 QAA04610 for ; Fri, 2 Apr 1999 16:40: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 NAA21904; Fri, 2 Apr 1999 13:33:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA05651 for ietf-radius-outgoing; Fri, 2 Apr 1999 13:38:00 -0800 (PST) Message-Id: <199904022134.QAA04355@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-05.txt Date: Fri, 02 Apr 1999 16:34:34 -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-05.txt Pages : 14 Date : 01-Apr-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-05.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-05.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-05.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: <19990401101107.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-auth-clientmib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-auth-clientmib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990401101107.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 Apr 2 16:40: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 QAA04639 for ; Fri, 2 Apr 1999 16:40: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 NAA21859; Fri, 2 Apr 1999 13:33:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA05607 for ietf-radius-outgoing; Fri, 2 Apr 1999 13:37:37 -0800 (PST) Message-Id: <199904022134.QAA04342@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-05.txt Date: Fri, 02 Apr 1999 16:34:12 -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-05.txt Pages : 16 Date : 01-Apr-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-05.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-05.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-05.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: <19990401100744.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-auth-servmib-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-auth-servmib-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990401100744.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 Sat Apr 3 04:26: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 EAA01843 for ; Sat, 3 Apr 1999 04:26: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 BAA08462; Sat, 3 Apr 1999 01:19:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA04955 for ietf-radius-outgoing; Sat, 3 Apr 1999 01:23:01 -0800 (PST) From: lst2@ibm.net Date: Sat, 3 Apr 1999 01:21:56 -0800 (PST) Message-Id: <199904030921.BAA10377@crow.prod.itd.earthlink.net> To: travelers@ibm.net Subject: (radius) Lose Weight And Regain That Youthful Energy! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: lst2@ibm.net ATTENTION! Get Your Life Back Today! (Guaranteed) Turn the clock BACK 20 years! (Guaranteed) -If you are overweight -If You have little or no Energy -If You have a Chronic Ailment -If Your Body Aches or Hurts -If You are Depressed -If You are Losing your Zest for Life We Have What You Need The Product (Anti-Aging) -All Natural (No Drugs or Chemicals) -No Membership Fees -Inexpensive 30 Day Supply-30 day Unconditional Money Back Guarantee -Regain that Youthful Energy and Lose Weight -No Need to Change your Eating Habits Remember how good you used to feel with boundless energy. Remember the way you used to look before you gained that weight. You can get that all back with our product. Don't let time and age ruin your life. It doesn't have to be that way. Take control of your life again by calling us. Being overweight and aging is treatable and we have the best, most natural method to do that. Try us for 30 days. You have nothing to lose. We guarantee unconditionally that our product will work. If it doesn't work for you just return the unused portion for a full refund. Call Toll-Free Now for More Info. & Ordering 1-800-345-9688 #3305 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! This message is being 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: boxforrent@usa.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Apr 4 23:46: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 XAA17783 for ; Sun, 4 Apr 1999 23:46:50 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA11491; Sun, 4 Apr 1999 20:40:03 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA03268 for ietf-radius-outgoing; Sun, 4 Apr 1999 20:41:20 -0700 (PDT) From: PublishingCo@mailcity.com Message-Id: <199904050316.LAA03868@db.> To: PublishingCo@mailcity.com Date: Sun, 04 Apr 99 20:48:05 EST Subject: (radius) Publishing Company for Sale! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: PublishingCo@mailcity.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 April 11th, 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 April 11th 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, email Stop-it-for-good@bigfoot.com 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 Mon Apr 5 00:03: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 AAA17904 for ; Mon, 5 Apr 1999 00:03:44 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA12041; Sun, 4 Apr 1999 20:55:34 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA03767 for ietf-radius-outgoing; Sun, 4 Apr 1999 20:59:46 -0700 (PDT) Message-ID: <77D4835D5290D111B8CC00805FE6AAD50159DF0A@bellnet-mail1.sbell.com.cn> From: SRD Niu HuaRong To: IETF Radius Subject: (radius) L2TP attributes Date: Mon, 5 Apr 1999 11:50:42 +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: SRD Niu HuaRong I know we have radius attribute "Tunnel-Password" for "outgoing tunnel password", do we have corresponding attributes for "tunnel shared secret" and "incoming tunnel password" ? Here what I said as the "outgoing tunnel password" is the password used by l2tp tunnel initiator to authenticate to the contacted peer, and "incoming tunnel password" is the one given by the contacted peer in request of initiator. Hua-rong Niu (niuh@sbell.com.cn) Research & Development, Shanghai Bell. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Apr 6 17:30: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 RAA17825 for ; Tue, 6 Apr 1999 17:30:12 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA05826; Tue, 6 Apr 1999 14:23:10 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA03247 for ietf-radius-outgoing; Tue, 6 Apr 1999 14:25:06 -0700 (PDT) From: Aydin Edguer Message-Id: <199904062122.RAA01082@harlequin.MorningStar.Com> Subject: Re: (radius) L2TP attributes To: ietf-radius@livingston.com Date: Tue, 6 Apr 1999 17:22:41 -0400 (EDT) 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 know we have radius attribute "Tunnel-Password" for "outgoing tunnel > password", do we have corresponding attributes for "tunnel shared secret" > and "incoming tunnel password" ? In my opinion... I cannot come up with a scenario in L2TP where you would need both an incoming and an outgoing tunnel password in the same user profile. In L2TP, the "outgoing tunnel password" (on the LAC) must be the same as the "incoming tunnel password" (on the LNS), because they are used as the "tunnel shared secret". Even if the "outgoing tunnel password" and the "incoming tunnel password" were different, in RADIUS, the user profiles for (a) a user connecting to the the LAC/NAS [that would require the "outgoing tunnel password" and (b) the LAC which is trying to establish a tunnel to the LNS [that would require an "incoming tunnel password"] will be different and thus the same attribute, Tunnel-Password, can be used unambiguously for both purposes. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 7 16:36: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 QAA15035 for ; Wed, 7 Apr 1999 16:36:03 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA06608; Wed, 7 Apr 1999 13:22:34 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA28597 for ietf-radius-outgoing; Wed, 7 Apr 1999 13:25:05 -0700 (PDT) Message-ID: <003d01be8134$917a0c90$1e136b83@ntdev.microsoft.com> From: "Glen Zorn" To: "Aydin Edguer" , References: <199904062122.RAA01082@harlequin.MorningStar.Com> Subject: Re: (radius) L2TP attributes Date: Wed, 7 Apr 1999 13:23:57 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Aydin Edguer writes: > > I know we have radius attribute "Tunnel-Password" for "outgoing tunnel > > password", do we have corresponding attributes for "tunnel shared secret" > > and "incoming tunnel password" ? > > In my opinion... > > I cannot come up with a scenario in L2TP where you would need both an > incoming and an outgoing tunnel password in the same user profile. > > In L2TP, the "outgoing tunnel password" (on the LAC) must be the same as > the "incoming tunnel password" (on the LNS), because they are used as the > "tunnel shared secret". > > Even if the "outgoing tunnel password" and the "incoming tunnel password" > were different, in RADIUS, the user profiles for (a) a user connecting to > the the LAC/NAS [that would require the "outgoing tunnel password" and > (b) the LAC which is trying to establish a tunnel to the LNS [that would > require an "incoming tunnel password"] will be different and thus the same > attribute, Tunnel-Password, can be used unambiguously for both purposes. True, but the draft _does_ say "This Attribute may contain a password to be used to authenticate to a remote server." Perhaps it should be changed to say "This Attribute may contain a password to be used to authenticate to a remote server or client."? > > - > 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 Apr 7 17:21:40 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 RAA15968 for ; Wed, 7 Apr 1999 17:21:39 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA07875; Wed, 7 Apr 1999 14:14:47 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA04057 for ietf-radius-outgoing; Wed, 7 Apr 1999 14:18:51 -0700 (PDT) From: "Heath Partington" To: "Ietf-Radius@Livingston. Com" Subject: (radius) draft-ietf-radius-auth-clientmib-05 Date: Wed, 7 Apr 1999 17:17:07 -0400 Message-ID: <000801be813b$fe3c2280$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" Content-Transfer-Encoding: 7bit Just a small nit-pick as I am attempting to implement some form of this mib - radiusAuthClientPendingRequests OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of RADIUS Access-Request packets destined for this server that have not yet timed out or received a response. This variable is incremented when an Access-Request is sent and decremented due to receipt of an Acess-Accept, Access-Reject or Access-Challenge, a timeout or retransmission." ::= { radiusAuthServerEntry 12 } Do we really want to decrement this counter when there is a retransmission to the same server? For this case we still are awaiting the return of the retransmitted packet. Thanks. 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 Wed Apr 7 17:54: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 RAA16657 for ; Wed, 7 Apr 1999 17:54:17 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA08800; Wed, 7 Apr 1999 14:47:25 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA07628 for ietf-radius-outgoing; Wed, 7 Apr 1999 14:49:40 -0700 (PDT) Message-ID: <007701be8140$6b22b7c0$1e136b83@ntdev.microsoft.com> From: "Glen Zorn" To: "Heath Partington" , "Ietf-Radius@Livingston. Com" References: <000801be813b$fe3c2280$da047392@hpartington.hq.springtidenet.com> Subject: Re: (radius) draft-ietf-radius-auth-clientmib-05 Date: Wed, 7 Apr 1999 14:48:42 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Heath Partington writes: > Just a small nit-pick as I am attempting to implement some form of this > mib - > > > radiusAuthClientPendingRequests OBJECT-TYPE > SYNTAX Gauge32 > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The number of RADIUS Access-Request packets > destined for this server that have not yet timed out > or received a response. This variable is incremented > when an Access-Request is sent and decremented due to > receipt of an Acess-Accept, Access-Reject or Access-Challenge, > a timeout or retransmission." > ::= { radiusAuthServerEntry 12 } > > > Do we really want to decrement this counter when there is a retransmission > to the same server? For this case we still are awaiting the return of the > retransmitted packet. I think that what would happen in the case of a retransmission to the same server is that you would increment it (because of the new Access-Request) _and_ decrement it (due to the retransmission), i.e., just leave it alone. Does that sound reasonable? > > > Thanks. > > 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. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 7 18:11: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 SAA17070 for ; Wed, 7 Apr 1999 18:11:20 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA09615; Wed, 7 Apr 1999 15:04:39 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA09629 for ietf-radius-outgoing; Wed, 7 Apr 1999 15:08:47 -0700 (PDT) From: "Heath Partington" To: "Glen Zorn" , "Ietf-Radius@Livingston. Com" Subject: RE: (radius) draft-ietf-radius-auth-clientmib-05 Date: Wed, 7 Apr 1999 18:06:56 -0400 Message-ID: <000901be8142$f387a3d0$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: <007701be8140$6b22b7c0$1e136b83@ntdev.microsoft.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Heath Partington" Content-Transfer-Encoding: 7bit > > I think that what would happen in the case of a > retransmission to the same > server is that you would increment it (because of the new > Access-Request) > _and_ decrement it (due to the retransmission), i.e., just > leave it alone. > Does that sound reasonable? > Yes this sounds perfectly reasonable as long as the document is updated - there are many fine points in this area that might cause differences in implementations if the descriptions are not clear. I was starting to think that this variable may only count initial authentication requests much like the radiusAuthClientAccessRequests variable which does not include retransmissions. The difference between a retransmission and a transmission to a different server for the same request may also be a difficult idea to catch if you were not reading carefully. Thanks. Heath - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Apr 8 20:10: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 UAA07929 for ; Thu, 8 Apr 1999 20:10:37 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA12708; Thu, 8 Apr 1999 17:03:33 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA21772 for ietf-radius-outgoing; Thu, 8 Apr 1999 17:02:12 -0700 (PDT) Message-ID: <370D4231.347FE1A5@acc.com> Date: Thu, 08 Apr 1999 16:56:33 -0700 From: Michael Zdan X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: (radius) zero attributes in access-challenge packet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Michael Zdan Content-Transfer-Encoding: 7bit rfc2138 states that access-challenge packets contain a list of zero or more attributes.What is the meaning of a RADIUS access-challenge packet that contains zero attributes? What would be the challenge that the NAS (and/or end-user) is expected to respond to? In other words, how MUST (or SHOULD) the NAS respond to receiveing a valid access-challenge that contains zero attributes? Thank you, Michael Zdan Software Engineer Ericsson, Inc. Data Networks and IP Services Access Product Division mzdan@acc.com Ph: 805.961.1575 Fax: 805.562.8085 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 9 09: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 JAA02318 for ; Fri, 9 Apr 1999 09:25:22 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA23241; Fri, 9 Apr 1999 06:15:18 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA19912 for ietf-radius-outgoing; Fri, 9 Apr 1999 06:18:31 -0700 (PDT) Message-Id: <199904091319.JAA00361@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) zero attributes in access-challenge packet In-reply-to: Your message of "Thu, 08 Apr 1999 16:56:33 PDT." <370D4231.347FE1A5@acc.com> Date: Fri, 09 Apr 1999 09:19:00 -0400 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok > rfc2138 states that access-challenge packets contain a list of zero or > more attributes.What is the meaning of a RADIUS access-challenge packet > that contains zero attributes? Not much. > What would be the challenge that the NAS (and/or end-user) is > expected to respond to? In other words, how MUST (or SHOULD) the NAS > respond to receiveing a valid access-challenge that contains zero > attributes? The ones I've seen all expect Reply-Message and State, at the minimum. An empty Access-Challenge packet would thus be treated like an Access-Reject. 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 Apr 9 11:00: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 LAA03261 for ; Fri, 9 Apr 1999 11:00:46 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA26015; Fri, 9 Apr 1999 07:53:30 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA26285 for ietf-radius-outgoing; Fri, 9 Apr 1999 07:57:28 -0700 (PDT) Message-ID: <003501be8298$99de86d0$0103a8c0@ds9> From: "Darran Potter" To: References: <199902180654.WAA12133@shell4.ba.best.com> Subject: Re: (radius) Acct-Tunnel-Packets-Lost? Date: Fri, 9 Apr 1999 15:52:18 +0100 Organization: Cisco Systems Inc 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit I'd appreciate an answer of this one too... since am updating CiscoSecure NT dictionaries. Darran ----- Original Message ----- From: MegaZone To: Sent: 18 February 1999 07:54 Subject: (radius) Acct-Tunnel-Packets-Lost? > 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. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 9 12:16: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 MAA04161 for ; Fri, 9 Apr 1999 12:16:07 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA29739; Fri, 9 Apr 1999 09:08:59 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA03684 for ietf-radius-outgoing; Fri, 9 Apr 1999 09:12:35 -0700 (PDT) From: Barney Wolff To: ietf-radius@livingston.com Date: Fri, 9 Apr 1999 12:04 EDT Subject: Re: (radius) zero attributes in access-challenge packet Content-Type: text/plain Message-ID: <370e26dd0.5251@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff This does not seem to me to be correct behavior. State is certainly not a required attribute in a Challenge. And since the group (wrongly, in my view, but nevertheless) has decreed that an empty string attribute is not valid, the absence of Reply-Message merely means that the NAS should put itself into a state to take new input from the user, which it will then send in a new Access-Request, but not send anything to the user to indicate this. Maybe the user "just knows" that this dialog is appropriate. Barney Wolff > From: Alan DeKok > Date: Fri, 09 Apr 1999 09:19:00 -0400 > > > What would be the challenge that the NAS (and/or end-user) is > > expected to respond to? In other words, how MUST (or SHOULD) the NAS > > respond to receiveing a valid access-challenge that contains zero > > attributes? > > The ones I've seen all expect Reply-Message and State, at the > minimum. An empty Access-Challenge packet would thus be treated like > 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 Fri Apr 9 12:17: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 MAA04185 for ; Fri, 9 Apr 1999 12:17:34 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA29940; Fri, 9 Apr 1999 09:10:45 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA03969 for ietf-radius-outgoing; Fri, 9 Apr 1999 09:15:04 -0700 (PDT) Message-ID: <000d01be82a3$6e0b3160$0103a8c0@ds9> From: "Darran Potter" To: Subject: (radius) Tagged attribute question Date: Fri, 9 Apr 1999 17:09:57 +0100 Organization: Cisco Systems Inc MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit When the Tunneling RFC states "If the Tag field is unused, it MUST be zero." what does it actually mean by "unused"? I assume it means "Radius Servers that dont allow more than one tunnel configuration per user profile" Any system that allows multiple tunnels will probably default to tag=1 when only one tag has been configured - even if the user didnt configure the Tunnel-Preference. Darran - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 9 12:37: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 MAA04388 for ; Fri, 9 Apr 1999 12:37:10 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA00607; Fri, 9 Apr 1999 09:28:28 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA05623 for ietf-radius-outgoing; Fri, 9 Apr 1999 09:32:12 -0700 (PDT) From: Barney Wolff To: Date: Fri, 9 Apr 1999 12:21 EDT Subject: Re: (radius) Tagged attribute question Content-Type: text/plain Message-ID: <370e2b7d0.5324@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff While we're discussing tags, I'd like to get the language (and perhaps intent) of the tag definitions clarified. For the binary attributes (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Preference) we are instructed to make tag 0 (ie, 8 zero bits) to indicate the absence of a tag. For the string attributes (Tunnel-Client-Endpoint, Tunnel-Server-Endpoint) we are instructed to omit the tag byte. For Tunnel-Password, the exact wording seems to say that we must make the tag 0x20 or greater to indicate that it's not being used, rather than making it zero or omitting it. This seems unnecessarily inconsistent, given that the length of the string portion of the Tunnel-Password is always a multiple of 16 bytes, and so the presence or absence of the tag could be uniquely determined by examining the attribute length. But if we're going to say the tag byte should always be present in Tunnel- Password, we should make it zero when not used. And was there any real need to treat having only a single set of attributes as a special case, and say that the tag SHOULD NOT be used? That complicates the code, rather than simplifying it. Barney Wolff - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 9 13: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 NAA04851 for ; Fri, 9 Apr 1999 13:27:26 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA03772; Fri, 9 Apr 1999 10:15:56 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA10691 for ietf-radius-outgoing; Fri, 9 Apr 1999 10:19:21 -0700 (PDT) Message-ID: <370E3734.AE93543@alcatel.be> Date: Fri, 09 Apr 1999 19:21:56 +0200 From: Marc De Vries X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: ietf-radius Subject: Re: (radius) Tagged attribute question References: <370e2b7d0.5324@databus.databus.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Marc De Vries Content-Transfer-Encoding: 7bit The special case is not just for user profiles that contain only one tunnel attribute set. It also accomodates servers that are not tag-aware and send plain integers and strings (and that ommit the Tunnel-Password). This special case may complicate the code for new implementations (IMO not really that big a deal), but at least it does not require everybody to upgrade their radius servers, only the dictionaries. Marc. Barney Wolff wrote: > > While we're discussing tags, I'd like to get the language (and perhaps > intent) of the tag definitions clarified. For the binary attributes > (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Preference) we are instructed > to make tag 0 (ie, 8 zero bits) to indicate the absence of a tag. For > the string attributes (Tunnel-Client-Endpoint, Tunnel-Server-Endpoint) > we are instructed to omit the tag byte. For Tunnel-Password, the > exact wording seems to say that we must make the tag 0x20 or greater > to indicate that it's not being used, rather than making it zero or > omitting it. This seems unnecessarily inconsistent, given that the > length of the string portion of the Tunnel-Password is always a > multiple of 16 bytes, and so the presence or absence of the tag could > be uniquely determined by examining the attribute length. But if > we're going to say the tag byte should always be present in Tunnel- > Password, we should make it zero when not used. > > And was there any real need to treat having only a single set of > attributes as a special case, and say that the tag SHOULD NOT be > used? That complicates the code, rather than simplifying it. > > 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 Apr 9 13:56: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 NAA05250 for ; Fri, 9 Apr 1999 13:56:15 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA05091; Fri, 9 Apr 1999 10:47:17 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA14082 for ietf-radius-outgoing; Fri, 9 Apr 1999 10:51:25 -0700 (PDT) Message-ID: <002301be82b1$5f69bce0$1e136b83@ntdev.microsoft.com> From: "Glen Zorn" To: "Darran Potter" , References: <199902180654.WAA12133@shell4.ba.best.com> <003501be8298$99de86d0$0103a8c0@ds9> Subject: Re: (radius) Acct-Tunnel-Packets-Lost? Date: Fri, 9 Apr 1999 10:49:45 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Darran Potter writes: > I'd appreciate an answer of this one too... since am updating CiscoSecure NT dictionaries. > > Darran > > ----- Original Message ----- > From: MegaZone > To: > Sent: 18 February 1999 07:54 > Subject: (radius) Acct-Tunnel-Packets-Lost? > > > > Possibly a stupid question. > > > > Was Acct-Tunnel-Packets-Lost ever assigned a number, or will it be dropped > > in the next revision? Yes, it's Attribute 86 and no, it's not being dropped :-) > > > > 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. > > - > 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 Apr 9 15:31:40 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 PAA06595 for ; Fri, 9 Apr 1999 15:31:39 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA08738; Fri, 9 Apr 1999 12:24:43 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA23328 for ietf-radius-outgoing; Fri, 9 Apr 1999 12:28:24 -0700 (PDT) Message-ID: <001101be82be$72dd5ea0$0103a8c0@ds9> From: "Darran Potter" To: References: <370e2b7d0.5324@databus.databus.com> <370E3734.AE93543@alcatel.be> Subject: Re: (radius) Tagged attribute question Date: Fri, 9 Apr 1999 20:23:19 +0100 Organization: Cisco Systems Inc 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit Since we will always be using tags, CiscoSecure will always send a non-zero tag. So I guess this will make us RFC compliant and non-interopable in one go. oh well. ----- Original Message ----- From: Marc De Vries Cc: ietf-radius Sent: 09 April 1999 18:21 Subject: Re: (radius) Tagged attribute question > The special case is not just for user profiles that contain only one > tunnel attribute set. It also accomodates servers that are not tag-aware > and send plain integers and strings (and that ommit the > Tunnel-Password). > > This special case may complicate the code for new implementations (IMO > not really that big a deal), but at least it does not require everybody > to upgrade their radius servers, only the dictionaries. > > Marc. > > Barney Wolff wrote: > > > > While we're discussing tags, I'd like to get the language (and perhaps > > intent) of the tag definitions clarified. For the binary attributes > > (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Preference) we are instructed > > to make tag 0 (ie, 8 zero bits) to indicate the absence of a tag. For > > the string attributes (Tunnel-Client-Endpoint, Tunnel-Server-Endpoint) > > we are instructed to omit the tag byte. For Tunnel-Password, the > > exact wording seems to say that we must make the tag 0x20 or greater > > to indicate that it's not being used, rather than making it zero or > > omitting it. This seems unnecessarily inconsistent, given that the > > length of the string portion of the Tunnel-Password is always a > > multiple of 16 bytes, and so the presence or absence of the tag could > > be uniquely determined by examining the attribute length. But if > > we're going to say the tag byte should always be present in Tunnel- > > Password, we should make it zero when not used. > > > > And was there any real need to treat having only a single set of > > attributes as a special case, and say that the tag SHOULD NOT be > > used? That complicates the code, rather than simplifying it. > > > > 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. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 9 16:09: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 QAA06977 for ; Fri, 9 Apr 1999 16:09:28 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA10412; Fri, 9 Apr 1999 13:02:45 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA27507 for ietf-radius-outgoing; Fri, 9 Apr 1999 13:06:43 -0700 (PDT) From: Barney Wolff To: ietf-radius Date: Fri, 9 Apr 1999 15:51 EDT Subject: Re: (radius) Tagged attribute question Content-Type: text/plain Message-ID: <370e5dca0.5735@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff The special case I was objecting to is specifically the single endpoint case, with the following language in the draft: 5. Attributes Multiple instances of each of the attributes defined below may be included in a single RADIUS packet. In this case, the attributes to be applied to any given tunnel SHOULD all contain the same value in their respective Tag fields; otherwise, the Tag field SHOULD NOT be used. The server is of course *allowed* not to use a tag, when there is only a single tunnel to be specified. But by saying SHOULD NOT, a server that always uses 1 for the first tunnel is being admonished, and I claim that there is no reason it should be. The notion that a server that uses tags can interoperate with a NAS that does not understand tags, in the degenerate case of a single tunnel, is not interesting to me. Oh well, it's a minor point, I suppose. Barney Wolff > Date: Fri, 09 Apr 1999 19:21:56 +0200 > Reply-To: Marc De Vries > > The special case is not just for user profiles that contain only one > tunnel attribute set. It also accomodates servers that are not tag-aware > and send plain integers and strings (and that ommit the > Tunnel-Password). > > This special case may complicate the code for new implementations (IMO > not really that big a deal), but at least it does not require everybody > to upgrade their radius servers, only the dictionaries. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Apr 10 12:14:40 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 MAA21680 for ; Sat, 10 Apr 1999 12:14:39 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA29838; Sat, 10 Apr 1999 09:07:34 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA15891 for ietf-radius-outgoing; Sat, 10 Apr 1999 09:07:09 -0700 (PDT) From: m8jn@ibm.net Date: Sat, 10 Apr 1999 09:05:33 -0700 (PDT) Message-Id: <199904101605.JAA09623@crow.prod.itd.earthlink.net> To: travelers@ibm.net Subject: (radius) Legal Cable TV Descrambler!! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: m8jn@ibm.net NOTE: THIS IS AN ADVERTISEMENT FOR LEGAL TV DE-SCRAMBLER IF YOU HAVE NO INTEREST IN THIS INFORMATION PLEASE CLICK DELETE NOW. THANK YOU-- LEGAL CABLE TV DE-SCRAMBLER Want to watch Sporting Events?--Movies?--Pay-Per-View?? *This is the Famous R-D-O Shack TV Descrambler You can assemble it from R-D-O Shack parts for about $12 or $15. We Send You: E-Z To follow Assembly Instructions. E-Z To read Original Drawings. The Famous R-D-O Shack Parts List. PLUS SOMETHING NEW YOU MUST HAVE! Something you can't do without. THE UP-TO-DATE REPORT: USING A DESCRAMBLER LEGALLY Warning: You should not build a TV Descrambler without reading this report first. Frequently Asked Questions--CABLE TV DESCRAMBLER Q: Will the descrambler work on Fiber, TCI, Jarrod and satellite systems? A: The answer is YES. In respect to satellite, you just get more stuff! There is one exception: The descrambler will not work with DSS satellite. Q: Do I need a converter box? A: This plan works with or without a converter box. Specific instructions are included in the plans for each! Q: Can the cable company detect that I have the descrambler? A: No, the signal descrambles right at the box and does not move back through the line! Q: Do I have to alter my existing cable system, television or VCR? A: The answer is no! Q: Does this work with my remote control? A: The answer is yes. The descrambler is manually controlled--but very easy to use! Q: Can you email me the plans? A: No the program comes with an easy to follow picture guide. Q: Does this work everywhere across the country? A: Yes, every where in the USA plus England, Brazil, Canada and other countries! Q: Is this deal guaranteed? A: Yes, if you are unhappy for any reason we will refund your money. Q: When I order, when will I get my stuff? A: We mail out all orders within 48 hours of receiving them. YOU SUPPLY A SELF-ADDRESSED, STAMPED, #10 LONG ENVELOPE, WITH TWO-FIRST CLASS STAMPS. Q: How much does it cost to get the instruction plans, the easy to follow diagram, and most important of all the Using a Descrambler LEGALLY. A: You get the complete package all for just--$10.00 (Cash, Check or Money Order.) (Arizona residents include 7% Arizona State Sales Tax) (All orders outside the U.S.A. add $5.00) Q: How do I order? A: Fill out form below and send it, along with your payment AND YOUR SELF ADDRESSED STAMPED ENVELOPE to: K Gaston PO Box 7375 J-1 Chandler, AZ 85246 MAKE CHECKS PAYABLE TO: K Gaston PRINT YOUR: (orders without an envelope will be processed up to 2 weeks later than complete orders) NAME_____________________________________________ ADDRESS__________________________________________ CITY/STATE/ZIP_____________________________________ E-MAIL ADDRESS___________________________________ *K Gaston is NOT ASSOCIATED in any way with RADIO SHACK. Neither the design nor instructions were developed by, are sold by, or are endorsed by Radio Shack. Parts for this fine-tuning device are available at many electronics stores (including Radio Shack) This is not a Radio Shack product. 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! Please do not respond to this e mail, e mails will not be read! To be removed from this list please respond to: 3stupiddogs@usa.net Thank you! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Apr 11 09:40: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 JAA02259 for ; Sun, 11 Apr 1999 09:40:04 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA10924; Sun, 11 Apr 1999 06:32:47 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA16649 for ietf-radius-outgoing; Sun, 11 Apr 1999 06:35:18 -0700 (PDT) From: ster@indiasite.com Message-Id: <199904111330.GAA10904@bast.livingston.com> Subject: (radius) Luxury Vacation AD Date: Mon, 19 Apr 1999 20:21:11 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: ster@indiasite.com Attention Miami Vacationers. Luxury Oceanside 2 bedroom Suite at World Famous "Alexander Hotel" in Miami Beach, Florida with Free Private Aircraft to Orlando, Key West, Bahamas or Naples (or your choice of destination), Free Limousine Service and Free use of our 60' Yacht. Prices starting at $3250 per week. Luxury Services International Inc. You can phone us at 954 9858303. fax 800 422 1535 to be removed email ster@indiasite.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Apr 11 19:02: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 TAA09717 for ; Sun, 11 Apr 1999 19:02:49 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA17408; Sun, 11 Apr 1999 15:55:53 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA01479 for ietf-radius-outgoing; Sun, 11 Apr 1999 15:57:14 -0700 (PDT) From: stephen21_TheGreat@bigfoot.com Message-Id: <199904112252.PAA17384@bast.livingston.com> Subject: (radius) luxury vacation ad Date: Tue, 20 Apr 1999 05:43:05 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: stephen21_TheGreat@bigfoot.com Attention Miami Vacationers. Luxury Oceanside 2 bedroom Suite at World Famous "Alexander Hotel" in Miami Beach, Florida with Free Private Aircraft to Orlando, Key West, Bahamas or Naples (or your choice of destination), Free Limousine Service and Free use of our 60' Yacht. Prices starting at $3250 per week. Luxury Services International Inc. You can phone us at 954 9858303. fax 800 422 1535 to be removed email stephen21_TheGreat@bigfoot.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Apr 12 16:07: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 QAA07864 for ; Mon, 12 Apr 1999 16:07:45 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA10233; Mon, 12 Apr 1999 13:00:40 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA04325 for ietf-radius-outgoing; Mon, 12 Apr 1999 13:03:19 -0700 (PDT) Date: Mon, 12 Apr 1999 13:03:14 -0700 (PDT) From: Carl Rigney Message-Id: <199904122003.NAA04298@server.livingston.com> To: daler@iea-software.com Subject: Re: (radius) More detail on Proxy Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Dale Reed writes: > Some implementations require Proxy-State to be before the reply > attributes Such implementations are broken, and should be fixed. The order of attributes of the same type must be preserved, but there's no requirement as to order of different attributes. -- 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 Mon Apr 12 16:27: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 QAA08001 for ; Mon, 12 Apr 1999 16:27:05 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA10354; Mon, 12 Apr 1999 13:04:33 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA05007 for ietf-radius-outgoing; Mon, 12 Apr 1999 13:08:54 -0700 (PDT) Message-ID: <371252A7.7321B5AE@iea-software.com> Date: Mon, 12 Apr 1999 13:08:07 -0700 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) More detail on Proxy References: <199904122003.NAA04298@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: > > Dale Reed writes: > > Some implementations require Proxy-State to be before the reply > > attributes > > Such implementations are broken, and should be fixed. > > The order of attributes of the same type must be preserved, but there's > no requirement as to order of different attributes. We have been hit by this problem from three different vendors now (all based on the same original code base) and its really starting to become a pain. We did modify RadiusNT to send Proxy-State first, but its getting really old talking to non-RADIUS saavy people that say OUR implementation was broke, not theirs. :( -- 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 Apr 12 17:06: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 RAA08368 for ; Mon, 12 Apr 1999 17:06:56 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA11968; Mon, 12 Apr 1999 13:55:06 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA10504 for ietf-radius-outgoing; Mon, 12 Apr 1999 13:58:55 -0700 (PDT) Date: Mon, 12 Apr 1999 13:58:53 -0700 (PDT) From: Carl Rigney Message-Id: <199904122058.NAA10491@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Last call before Last call Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney I've gone through all the messages since I sent out the drafts March 4th and have inserted clarifying language as appropriate. I plan to submit the revised drafts for working group last call this week, so if you have any remaining remarks on the existing 3 drafts, please send them to me or the list today or tomorrow. If you've already emailed your comments, you don't need to send them again; I've seen them already. -- Carl Rigney RADIUS WG Editor 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 Mon Apr 12 19:33: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 TAA09257 for ; Mon, 12 Apr 1999 19:33:29 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA16744; Mon, 12 Apr 1999 16:26:34 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA27348 for ietf-radius-outgoing; Mon, 12 Apr 1999 16:29:07 -0700 (PDT) Date: Mon, 12 Apr 1999 16:29:05 -0700 (PDT) From: Carl Rigney Message-Id: <199904122329.QAA27339@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Examples in draft-ietf-radius-radius-v2-00.txt Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Is there anyone out there with sufficient time and kindness to be willing to double-check the hex encodings of the example RADIUS packets in draft-ietf-radius-radius-v2-00.txt? I checked mine carefully, but it would be very reassuring to have someone else look at them and do the MD-5 again to see if I made any errors. -- 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 Apr 13 09:56: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 JAA22692 for ; Tue, 13 Apr 1999 09:56:10 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA28458; Tue, 13 Apr 1999 06:49:11 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA02072 for ietf-radius-outgoing; Tue, 13 Apr 1999 06:50:31 -0700 (PDT) Message-ID: <00ec01be85b4$5655e5b0$0103a8c0@ds9> From: "Darran Potter" To: References: <370e2b7d0.5324@databus.databus.com> Subject: Re: (radius) Tagged attribute question Date: Tue, 13 Apr 1999 14:48:39 +0100 Organization: Cisco Systems Inc 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Darran Potter" Content-Transfer-Encoding: 7bit Im wondering if the draft authors have any comment on any if this? Regarding 0x20...It should probably just say "invalid tag values should be ignored".. which is what I *think* it means..... who knows. One last question, the plain text tunnel password length that is encrypted along with the password itself... what benefit does this provide? Darran ----- Original Message ----- From: Barney Wolff To: Sent: 09 April 1999 17:21 Subject: Re: (radius) Tagged attribute question > While we're discussing tags, I'd like to get the language (and perhaps > intent) of the tag definitions clarified. For the binary attributes > (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Preference) we are instructed > to make tag 0 (ie, 8 zero bits) to indicate the absence of a tag. For > the string attributes (Tunnel-Client-Endpoint, Tunnel-Server-Endpoint) > we are instructed to omit the tag byte. For Tunnel-Password, the > exact wording seems to say that we must make the tag 0x20 or greater > to indicate that it's not being used, rather than making it zero or > omitting it. This seems unnecessarily inconsistent, given that the > length of the string portion of the Tunnel-Password is always a > multiple of 16 bytes, and so the presence or absence of the tag could > be uniquely determined by examining the attribute length. But if > we're going to say the tag byte should always be present in Tunnel- > Password, we should make it zero when not used. > > And was there any real need to treat having only a single set of > attributes as a special case, and say that the tag SHOULD NOT be > used? That complicates the code, rather than simplifying it. > > 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 Tue Apr 13 10:31: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 KAA23056 for ; Tue, 13 Apr 1999 10:31:39 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA29668; Tue, 13 Apr 1999 07:24:16 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA04644 for ietf-radius-outgoing; Tue, 13 Apr 1999 07:28:28 -0700 (PDT) From: Barney Wolff To: Date: Tue, 13 Apr 1999 10:24 EDT Subject: Re: (radius) Tagged attribute question Content-Type: text/plain Message-ID: <371354870.15d3@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff In theory at least, the password is not restricted to ascii and might include trailing null bytes, so an explicit length is required to identify exactly what bytes are included in the password. Of course, that's just as true for user-password, but the weight of history precludes changing that format. Barney Wolff > From: "Darran Potter" > Date: Tue, 13 Apr 1999 14:48:39 +0100 > > One last question, the plain text tunnel password length that is encrypted > along with the password itself... what benefit does this provide? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Apr 13 13:24: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 NAA24669 for ; Tue, 13 Apr 1999 13:24:09 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA05925; Tue, 13 Apr 1999 10:16:24 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA22509 for ietf-radius-outgoing; Tue, 13 Apr 1999 10:20:09 -0700 (PDT) Message-Id: <3.0.5.32.19990413101525.00b28c10@gump.eng.ascend.com> X-Sender: igoyret@gump.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Tue, 13 Apr 1999 10:15:25 -0700 To: Barney Wolff From: Ignacio Goyret Subject: Re: (radius) Tagged attribute question Cc: In-Reply-To: <371354870.15d3@databus.databus.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:24 AM 4/13/99 EDT, Barney Wolff wrote: >In theory at least, the password is not restricted to ascii and might >include trailing null bytes, so an explicit length is required to >identify exactly what bytes are included in the password. Of course, >that's just as true for user-password, but the weight of history precludes >changing that format. > >Barney Wolff > >> From: "Darran Potter" >> Date: Tue, 13 Apr 1999 14:48:39 +0100 >> >> One last question, the plain text tunnel password length that is encrypted >> along with the password itself... what benefit does this provide? There is one other reason: if you've obscured the password by padding it with extra bytes, you will need to send the exact size of the password pre-padding. Otherwise, it might be hard to guess. :-) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Apr 13 16:36: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 QAA28583 for ; Tue, 13 Apr 1999 16:36:11 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA11705; Tue, 13 Apr 1999 13:29:20 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA12660 for ietf-radius-outgoing; Tue, 13 Apr 1999 13:32:30 -0700 (PDT) Message-Id: <199904132031.NAA01165@gricmail.gric.com> From: "Fanny Matamoros" To: ietf-radius@livingston.com Date: Tue, 13 Apr 1999 15:33:09 +0000 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: (radius) denied in Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Fanny Matamoros" Content-Transfer-Encoding: 7BIT How I denied the in to the users that own to a group in the unix server??? Fanny - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Apr 13 21:32: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 VAA02531 for ; Tue, 13 Apr 1999 21:32:53 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA19509; Tue, 13 Apr 1999 18:25:52 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA08870 for ietf-radius-outgoing; Tue, 13 Apr 1999 18:29:15 -0700 (PDT) Message-ID: <002401be8616$00299440$18136b83@ntdev.microsoft.com> From: "Glen Zorn" To: "Barney Wolff" , "ietf-radius" References: <370e5dca0.5735@databus.databus.com> Subject: Re: (radius) Tagged attribute question Date: Tue, 13 Apr 1999 18:27:37 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Barney Wolff writes: > The special case I was objecting to is specifically the single endpoint > case, with the following language in the draft: > > 5. Attributes > > Multiple instances of each of the attributes defined below may be > included in a single RADIUS packet. In this case, the attributes to be > applied to any given tunnel SHOULD all contain the same value in their > respective Tag fields; otherwise, the Tag field SHOULD NOT be used. > > The server is of course *allowed* not to use a tag, when there is only > a single tunnel to be specified. But by saying SHOULD NOT, a server > that always uses 1 for the first tunnel is being admonished, and I > claim that there is no reason it should be. Actually, I tend to agree with you. lacking any storm of protest, I'll change the next (hopefully final) rev to say: 5. Attributes Multiple instances of each of the attributes defined below may be included in a single RADIUS packet. In this case, the attributes to be applied to any given tunnel SHOULD all contain the same value in their respective Tag fields. > The notion that a server > that uses tags can interoperate with a NAS that does not understand > tags, in the degenerate case of a single tunnel, is not interesting > to me. Hmm. Actually, that was one of the reasons why the tag field has > Oh well, it's a minor point, I suppose. True > > Barney Wolff > > > Date: Fri, 09 Apr 1999 19:21:56 +0200 > > Reply-To: Marc De Vries > > > > The special case is not just for user profiles that contain only one > > tunnel attribute set. It also accomodates servers that are not tag-aware > > and send plain integers and strings (and that ommit the > > Tunnel-Password). > > > > This special case may complicate the code for new implementations (IMO > > not really that big a deal), but at least it does not require everybody > > to upgrade their radius servers, only the dictionaries. > - > 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 Apr 13 21:32: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 VAA02541 for ; Tue, 13 Apr 1999 21:32:58 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA19511; Tue, 13 Apr 1999 18:25:56 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA08936 for ietf-radius-outgoing; Tue, 13 Apr 1999 18:30:24 -0700 (PDT) Message-ID: <002901be8616$24497930$18136b83@ntdev.microsoft.com> From: "Glen Zorn" To: "Barney Wolff" , References: <370e2b7d0.5324@databus.databus.com> Subject: Re: (radius) Tagged attribute question Date: Tue, 13 Apr 1999 18:28:38 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Barney Wolff writes: > While we're discussing tags, I'd like to get the language (and perhaps > intent) of the tag definitions clarified. For the binary attributes > (Tunnel-Type, Tunnel-Medium-Type, Tunnel-Preference) we are instructed > to make tag 0 (ie, 8 zero bits) to indicate the absence of a tag. For > the string attributes (Tunnel-Client-Endpoint, Tunnel-Server-Endpoint) > we are instructed to omit the tag byte. For Tunnel-Password, the > exact wording seems to say that we must make the tag 0x20 or greater > to indicate that it's not being used, rather than making it zero or > omitting it. This seems unnecessarily inconsistent, given that the > length of the string portion of the Tunnel-Password is always a > multiple of 16 bytes, and so the presence or absence of the tag could > be uniquely determined by examining the attribute length. But if > we're going to say the tag byte should always be present in Tunnel- > Password, we should make it zero when not used. OK. > > And was there any real need to treat having only a single set of > attributes as a special case, and say that the tag SHOULD NOT be > used? That complicates the code, rather than simplifying it. > > 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 Wed Apr 14 02:38: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 CAA13010 for ; Wed, 14 Apr 1999 02:38:41 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id XAA27977; Tue, 13 Apr 1999 23:31:47 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA20520 for ietf-radius-outgoing; Tue, 13 Apr 1999 23:35:24 -0700 (PDT) Message-Id: <199904140633.XAA13270@shell4.ba.best.com> Subject: Re: (radius) denied in In-Reply-To: <199904132031.NAA01165@gricmail.gric.com> from Fanny Matamoros at "Apr 13, 99 03:33:09 pm" To: fmatamor@ecnet.ec Date: Tue, 13 Apr 1999 23:33:09 -0700 (PDT) Cc: ietf-radius@livingston.com 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 Fanny Matamoros shaped the electrons to say... >How I denied the in to the users that own to a group in the unix >server??? The IETF-RADIUS mailing list is not for questions on the use of RADIUS, it is for discussion and development of the RADIUS protocol. If you have issues with your RADIUS server, you should consult your RADIUS vendor and/or any mailing lists pertaining to that server. Also, frankly, I can't understand at all what it is you are asking anyway. Sounds like *maybe* you are asking how to deny access to users who belong to a specific group defined under UNIX in /etc/groups. If that is the case your server needs to support this functionality, it is outside of the scope of the protocol itself. Look for a 'Group' Check-Item - servers such as Lucent RADIUS, Cistron RADIUS, and Radiator support this, to name a few. -MZ -- 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 Apr 14 13:53: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 NAA27222 for ; Wed, 14 Apr 1999 13:53:58 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA13818; Wed, 14 Apr 1999 10:46:32 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA28474 for ietf-radius-outgoing; Wed, 14 Apr 1999 10:48:49 -0700 (PDT) From: Aydin Edguer Message-Id: <199904141746.NAA01487@harlequin.MorningStar.Com> Subject: Re: (radius) Tagged attribute question To: ietf-radius@livingston.com Date: Wed, 14 Apr 1999 13:46:47 -0400 (EDT) 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 > > But if we're going to say the tag byte should always be present in Tunnel- > > Password, we should make it zero when not used. > > OK. No! Please don't!! The whole point behind the "no tags" is backwards compatibility. If an implementation does not support tags at all, then the attributes should have no tag field. For an integer attribute, this would make that the location in the attribute, where the TAG would normally reside, have a value of zero. For a string attribute, it would be the first octet of the string. If an implementation supports tags then it must use a valid non-zero value for the tag - 0x01 - 0x1F. Any values outside this range are used to denote the lag of TAG support. This is the reason why the most significant bit (leftmost) of the Salt field MUST be set (1). It guarantees that a salt cannot be mistaken for a TAG. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 14 14:45: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 OAA29112 for ; Wed, 14 Apr 1999 14:45:13 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA15970; Wed, 14 Apr 1999 11:38:28 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA04352 for ietf-radius-outgoing; Wed, 14 Apr 1999 11:42:37 -0700 (PDT) From: Barney Wolff To: ietf-radius@livingston.com Date: Wed, 14 Apr 1999 14:14 EDT Subject: Re: (radius) Tagged attribute question Content-Type: text/plain Message-ID: <3714e1920.2a9c@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff But there was never any possibility that the salt could be mistaken for a tag. Consider: the length of the string portion of the attribute must always be a multiple of 16, the length of the salt is fixed at 2, and the tag is fixed at 1. So if the low-order 4 bits of the length byte of the attribute is 0010, neither tag nor salt is present; if 0011, tag is present but salt is not; if 0100, salt is present and tag is not; if 0101, both tag and salt are present; all other values are bogus. The other way to look at the issue is to say that Tunnel-Password is a fixed-length attribute (actually, fixed + N*16) and the way to indicate absence of a tag in a fixed-length attribute is to make the byte zero. As zero is not a valid tag value, it should not be mistaken for a tag. Seems to me that a sensible (ie, liberal) attribute receiver should be prepared for either case. I don't quite get what specifically you're objecting to - I did NOT say that tag=0 in a string attribute should denote no-tag, only that Tunnel- Password should work like an integer attribute, not like a string, in what the sender SHOULD do. As above, I believe the receiver SHOULD take it either way. I don't think Tunnel-Password has ever been defined without the tag byte in any draft - so, "backward compatible" to what? Barney Wolff > From: Aydin Edguer > Subject: Re: (radius) Tagged attribute question > To: ietf-radius@livingston.com > Date: Wed, 14 Apr 1999 13:46:47 -0400 (EDT) > Content-Length: 969 > Reply-To: Aydin Edguer > > > > But if we're going to say the tag byte should always be present in Tunnel- > > > Password, we should make it zero when not used. > > > > OK. > > No! Please don't!! The whole point behind the "no tags" is backwards > compatibility. If an implementation does not support tags at all, then > the attributes should have no tag field. For an integer attribute, > this would make that the location in the attribute, where the TAG would > normally reside, have a value of zero. For a string attribute, it would > be the first octet of the string. > > If an implementation supports tags then it must use a valid non-zero > value for the tag - 0x01 - 0x1F. Any values outside this range are > used to denote the lag of TAG support. This is the reason why the > most significant bit (leftmost) of the Salt field MUST be set (1). > It guarantees that a salt cannot be mistaken for a TAG. > - > 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 Apr 14 14:56: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 OAA29562 for ; Wed, 14 Apr 1999 14:55:59 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA16308; Wed, 14 Apr 1999 11:43:22 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA04775 for ietf-radius-outgoing; Wed, 14 Apr 1999 11:47:44 -0700 (PDT) Message-ID: <00b101be86a7$2b14dac0$18136b83@ntdev.microsoft.com> From: "Glen Zorn" To: "Aydin Edguer" , References: <199904141746.NAA01487@harlequin.MorningStar.Com> Subject: Re: (radius) Tagged attribute question Date: Wed, 14 Apr 1999 11:42:17 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Aydin Edguer writes: > > > But if we're going to say the tag byte should always be present in Tunnel- > > > Password, we should make it zero when not used. > > > > OK. > > No! Please don't!! The whole point behind the "no tags" is backwards > compatibility. If an implementation does not support tags at all, then > the attributes should have no tag field. For an integer attribute, > this would make that the location in the attribute, where the TAG would > normally reside, have a value of zero. For a string attribute, it would > be the first octet of the string. Yes. > > If an implementation supports tags then it must use a valid non-zero > value for the tag - 0x01 - 0x1F. Any values outside this range are > used to denote the lag of TAG support. This is the reason why the > most significant bit (leftmost) of the Salt field MUST be set (1). > It guarantees that a salt cannot be mistaken for a TAG. Mu understanding of Barney's proposal was that if the Tag field is always present in the Tunnel-Password Attribute, just say it's zero if not used. This seems to be reasonable. Are people treating the Tag field the same in Tunnel-Password as in integer attributes (i.e., it disappears)? If so, then this obviously doesn't work. BTW, I thought that his remarks dealt _only_ w/the Tunnel-Password attribute. > - > 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 Apr 14 15:29: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 PAA01210 for ; Wed, 14 Apr 1999 15:29:52 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA18074; Wed, 14 Apr 1999 12:21:56 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA07714 for ietf-radius-outgoing; Wed, 14 Apr 1999 12:25:50 -0700 (PDT) Message-Id: <199904141924.MAA22011@shell4.ba.best.com> Subject: Re: (radius) Tagged attribute question (fwd) To: ietf-radius@livingston.com Date: Wed, 14 Apr 1999 12:24:51 -0700 (PDT) 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... >This seems to be reasonable. Are people treating the Tag field the same in >Tunnel-Password as in integer attributes (i.e., it disappears)? If so, then >this obviously doesn't work. BTW, I thought that his remarks dealt _only_ What I've seen seems to indicate yes. But for that matter it looks like those using it today are sending it as a plain old string - not doing any of the MD5 work. Has any NAS vendor implemented Tunnel-Password as in the draft, and NOT as a plain string? I'm concerned about this - if deployed systems use it as a plain string this could cause trouble when/if vendors try to use the draft system. -MZ -- 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 Apr 14 15:38: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 PAA01653 for ; Wed, 14 Apr 1999 15:38:46 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA18837; Wed, 14 Apr 1999 12:31:49 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA08516 for ietf-radius-outgoing; Wed, 14 Apr 1999 12:36:06 -0700 (PDT) Message-Id: <3.0.5.32.19990414123222.00c94b20@porky.ascend.com> X-Sender: mhold@porky.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 14 Apr 1999 12:32:22 -0700 To: MegaZone From: Matt Holdrege Subject: Re: (radius) Tagged attribute question (fwd) Cc: ietf-radius@livingston.com In-Reply-To: <199904141924.MAA22011@shell4.ba.best.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Matt Holdrege At 12:24 PM 4/14/99 -0700, MegaZone wrote: >Once upon a time Glen Zorn shaped the electrons to say... >>This seems to be reasonable. Are people treating the Tag field the same in >>Tunnel-Password as in integer attributes (i.e., it disappears)? If so, then >>this obviously doesn't work. BTW, I thought that his remarks dealt _only_ > >What I've seen seems to indicate yes. But for that matter it looks like >those using it today are sending it as a plain old string - not doing any >of the MD5 work. Has any NAS vendor implemented Tunnel-Password as in the >draft, and NOT as a plain string? Ascend encrypts it. Our customers do not want this password flying around unencrypted. It could be used for a nasty DoS attack. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 14 15:40: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 PAA01745 for ; Wed, 14 Apr 1999 15:40:39 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA18990; Wed, 14 Apr 1999 12:33:23 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA08673 for ietf-radius-outgoing; Wed, 14 Apr 1999 12:37:51 -0700 (PDT) From: Aydin Edguer Message-Id: <199904141935.PAA01504@harlequin.MorningStar.Com> Subject: Re: (radius) Tagged attribute question (fwd) To: ietf-radius@livingston.com Date: Wed, 14 Apr 1999 15:35:49 -0400 (EDT) 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 > Has any NAS vendor implemented Tunnel-Password as in the draft, > and NOT as a plain string? Yes, definitely [although the TAG field is currently ignored, if present]. It does cause some tech support calls, from people with older RADIUS servers. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 14 16:05: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 QAA02946 for ; Wed, 14 Apr 1999 16:05:16 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA19931; Wed, 14 Apr 1999 12:58:32 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA10876 for ietf-radius-outgoing; Wed, 14 Apr 1999 13:02:23 -0700 (PDT) Message-Id: <3.0.5.32.19990414125737.007f3210@gump.eng.ascend.com> X-Sender: igoyret@gump.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 14 Apr 1999 12:57:37 -0700 To: MegaZone From: Ignacio Goyret Subject: Re: (radius) Tagged attribute question (fwd) Cc: ietf-radius@livingston.com In-Reply-To: <199904141924.MAA22011@shell4.ba.best.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 12:24 PM 4/14/99 -0700, MegaZone wrote: >Once upon a time Glen Zorn shaped the electrons to say... >>This seems to be reasonable. Are people treating the Tag field the same in >>Tunnel-Password as in integer attributes (i.e., it disappears)? If so, then >>this obviously doesn't work. BTW, I thought that his remarks dealt _only_ > >What I've seen seems to indicate yes. But for that matter it looks like >those using it today are sending it as a plain old string - not doing any >of the MD5 work. Has any NAS vendor implemented Tunnel-Password as in the >draft, and NOT as a plain string? > >I'm concerned about this - if deployed systems use it as a plain string this >could cause trouble when/if vendors try to use the draft system. I don't know what vendors you are talking about but Ascend has implemented the draft (including the MD5 stuff) for a long time. We considered for a little while allowing plain text passwords as well but then decided against it. Both NavisRadius and the free RADIUS server posted in Ascend's ftp server support encrypted Tunnel-Passwords. -Ignacio - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 14 18:16: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 SAA08103 for ; Wed, 14 Apr 1999 18:16:23 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA25241; Wed, 14 Apr 1999 15:09:26 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA25710 for ietf-radius-outgoing; Wed, 14 Apr 1999 15:12:55 -0700 (PDT) From: Aydin Edguer Message-Id: <199904142210.SAA01538@harlequin.MorningStar.Com> Subject: Re: (radius) Tagged attribute question To: ietf-radius@livingston.com Date: Wed, 14 Apr 1999 18:10:54 -0400 (EDT) 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 > > If an implementation supports tags then it must use a valid non-zero > > value for the tag - 0x01 - 0x1F. Any values outside this range are > > used to denote the lag of TAG support. This is the reason why the > > most significant bit (leftmost) of the Salt field MUST be set (1). > > It guarantees that a salt cannot be mistaken for a TAG. > > My understanding of Barney's proposal was that if the Tag field is always > present in the Tunnel-Password Attribute, just say it's zero if not used. > This seems to be reasonable. Are people treating the Tag field the same in > Tunnel-Password as in integer attributes (i.e., it disappears)? Yes. When sending the Tunnel-Password attribute, when the TAG field is not supported, then the Tag field completely disappears and becomes the first octet of the Salt field. This is the reason for the explicit statement about the Salt field value that you previously added to the draft. Perhaps the disagreement is coming over the meaning of the term "unused". Case 1: TAGs are not supported and will not be used. The appearance of an integer attribute: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The appearance of a string attribute: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The appearance of a salted attribute: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Salt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Case 2: TAGs *are* supported and but no TAG has been defined. In this case, it appears that the request is to add 0x00 to the list of valid Tags (e.g., to not limit it to be 0x01 through 0x1F). In my opinion, the reason for the disallowing the 0x00 Tag was so that when you get an integer datatype attribute, you can immediately know whether the sending system supports tags or not. If you force the default to be one, when no Tag has been defined in the user file, but Tags, then it is immediately apparent. I can live with adding zero as a special case Tag value which can be used, but I want it to be clear that if the server does not support Tags that there does not have to be a tag field of zero in the Tunnel-Password or in any string datatype attribute (like Tunnel-Server-Endpoint). The appearance of an integer attribute: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The appearance of a string attribute: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The appearance of a salted attribute: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | Salt +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Salt (cont) | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Case 3: TAGs *are* supported and but a TAG has been defined in the profile. The appearance of an integer attribute: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The appearance of a string attribute: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The appearance of a salted attribute: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Tag | Salt +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Salt (cont) | String ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Apr 15 11:42: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 LAA03807 for ; Thu, 15 Apr 1999 11:42:57 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA13579; Thu, 15 Apr 1999 08:34:27 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA13942 for ietf-radius-outgoing; Thu, 15 Apr 1999 08:34:56 -0700 (PDT) Message-Id: <199904151529.LAA03294@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-tunnel-acct-03.txt Date: Thu, 15 Apr 1999 11:29:44 -0400 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 Modifications for Tunnel Protocol Support Author(s) : G. Zorn, D. Mitton, B. Aboba Filename : draft-ietf-radius-tunnel-acct-03.txt Pages : 10 Date : 14-Apr-99 This document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to support the provision of compulsory tunneling in dial-up networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-acct-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-tunnel-acct-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-tunnel-acct-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: <19990414163854.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-radius-tunnel-acct-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-radius-tunnel-acct-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19990414163854.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 Apr 16 13:27: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 NAA08572 for ; Fri, 16 Apr 1999 13:27:48 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA15029; Fri, 16 Apr 1999 10:19:16 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA27340 for ietf-radius-outgoing; Fri, 16 Apr 1999 10:19:26 -0700 (PDT) Message-Id: <199904161715.NAA08199@ietf.org> To: IETF-Announce:; Cc: RFC Editor Cc: Internet Architecture Board Cc: ietf-radius@livingston.com From: The IESG Subject: (radius) Protocol Action: RADIUS Authentication MIBs to Proposed Standard Date: Fri, 16 Apr 1999 13:15:28 -0400 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: The IESG The IESG has approved the following Internet-Drafts as Proposed Standards: o RADIUS Authentication Client MIB o RADIUS Authentication Server MIB In the same action, the IESG approved publication of the following Internet-Drafts as Informational RFCs: o RADIUS Accounting Client MIB o RADIUS Accounting Server MIB These documents are the product of the Remote Authentication Dial-In User Service Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary These documents define a set of extensions which instrument RADIUS (Remote Dial-In User Services) authentication and accounting functions, both on the client and on the server side. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions management stations can manage RADIUS authenication and accounting clients and servers. During IETF Last Call one comment pointed out that these MIBs use IPv4 addresses and so they do not cater for IPv6. We do not know of any current RADIUS authentication and accounting servers andcleints supporting IPv6, so it is not an immediate issue. It turns out that quite a few standards track MIBs have the same problem and so a standard solution is needed. We do not want to hold up these 4 MIBs for that. They can address the issue with the next revision when we will have a standard solution for this problem. Working Group Summary These documents represent the consensus of the Working Group. Protocol Quality The documents were reviewed for the IESG by Bert Wijnen. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 16 13:48: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 NAA09367 for ; Fri, 16 Apr 1999 13:48:09 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA15867; Fri, 16 Apr 1999 10:41:34 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA00230 for ietf-radius-outgoing; Fri, 16 Apr 1999 10:44:24 -0700 (PDT) Message-Id: <3.0.5.32.19990416134452.041a74f0@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 16 Apr 1999 13:44:52 -0400 To: ietf-radius@livingston.com From: Dave Mitton Subject: (radius) Tags, Tunnels and Mailing Lists.... Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton Ouch! I was removed from this list without notice from livingston last weekend. Probably another perturbation in the Bay/Nortel mailer forwarding or weekend maintenance. This has happened to me several times, I wish livingston bouncer would be a little more resilent or wait for retries on weekdays. Looking through the archives for the past week... The Funk Steel-Belted RADIUS/BaySecure Access Control server also implements encrypted tags but with a pre-draft layout (thanks Glen). And the Xylo/Bay/Nortel Annex/Versalar 5399/8000 does the matching client (R14+). That will get fixed in a future server release. Annex R16 client now has a configuration parameter for the draft version and draft compatible data-sensitive tags. Prior releases always send a zero tag (per draft v02). You have to go back to draft-*-00 to get straight string, no-tag passwords. Dave. --------------------------------------------------------------- David Mitton ESN: 248-4570 Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Solutions, IP Services 978-916-3030 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 Sat Apr 17 19:01: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 TAA04742 for ; Sat, 17 Apr 1999 19:01:33 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA11939; Sat, 17 Apr 1999 15:54:50 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA11238 for ietf-radius-outgoing; Sat, 17 Apr 1999 15:56:13 -0700 (PDT) From: publishingcompany@mailcity.com Message-Id: <199904172250.HAA21408@baosoft.com> To: publishingcompany@mailcity.com Date: Sat, 17 Apr 99 17:33:19 EST Subject: (radius) Publishing Company for Sale! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: publishingcompany@mailcity.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 April 22th, 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 April 22th 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 and type remove in the subject line. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Apr 17 22:15: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 WAA05507 for ; Sat, 17 Apr 1999 22:15:57 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id TAA13855; Sat, 17 Apr 1999 19:09:18 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA15818 for ietf-radius-outgoing; Sat, 17 Apr 1999 19:12:27 -0700 (PDT) From: robnb@bimamail.com Message-Id: <199904180320.EAA29728@mail.cnc.fr> Date: Sat, 17 Apr 99 21:18:48 EST To: gjehfj@sggj.net Subject: (radius) Earn Money from Home!! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: robnb@bimamail.com $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ !!! Earn Extra Income from Home !!! Dear Friend, How much do you need, just to pay your bills? How much do you want, so you can do more than just get by? Would an extra $1000 per month help? How about an extra $2000 per month? Seem impossible? Read on for details. Don't let this opportunity slip by! "AS SEEN ON NATIONAL TV" Thank you for your time and interest. This is the letter you've been reading about in the news lately. Due to the popularity of this letter on the Internet, a major nightly news program recently devoted an entire show to the investigation of the program described below to see if it really can make people money. The show also investigated whether or not the program was legal. Their findings proved once and for all that there are absolutely no laws prohibiting the participation in the program. This has helped to show people that this is a simple, harmless and fun way to make some extra money at home. The results of this show have been truly remarkable. So many people are participating that those involved are doing much better than ever before. Since everyone makes more as more people try it out, its been very exciting to be a part of lately. You will understand once you experience it. HERE IT IS BELOW: *** Print This Now For Future Reference *** The following income opportunity is one you may be interested in taking a look at. It can be started with VERY LITTLE investment and the income return is TREMENDOUS!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ If you would like to make at least $50,000 in less than 90 days ! Please read the enclosed program...THEN READ IT AGAIN!!! $$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$ THIS IS A LEGITIMATE, LEGAL, MONEY MAKING OPPORTUNITY.It does not require you to come into contact with people, do any hard work, and best of all, you never have to leave the house except to get the mail. If you believe that someday you'll get that big break that you 'vebeen waiting for, THIS IS IT! Simply follow the instructions, andyour dreams will come true. This multi-level e-mail order marketingprogram works perfectly...100% EVERY TIME. E-mail is the sales tool of the future. Take advantage of this non-commercialized method of advertising NOW!!! The longer you wait, the more people will be doing business using e-mail. Get your piece of this action!!! MULTI-LEVEL MARKETING (MLM) has finally gained respectability. It is being taught in the Harvard Business School, and both Stanford Research and the Wall Street Journal have stated that between 50% and 65% of all goods and services will be sold through multi-level methods by the mid to late 1990's. This is a Multi-Billion Dollar industry and of the 500,000 millionaires in the U.S., 20% (100,000) made their fortune in the last several years in MLM. Moreover, statistics show 45 people become millionaires everyday through Multi-Level Marketing. You may have heard this story before, but over the summer Donald Trump made an appearance on the David Letterman show. Dave asked him what he would do if he lost everything and had to start over from scratch. Without hesitating, Trump said he would find a good network marketing company and get to work. The audience started to hoot and boo him. He looked out at the audience and dead-panned his response: "That's why I'm sitting up here and you are all sitting out there!" The enclosed information is something I almost let slip through my fingers. Fortunately, sometime later I re-read everything and gave somethought and study to it. My name is Johnathon Rourke. Two years ago, the corporation I worked at for the past twelve years down-sized and my position was eliminated. After unproductive job interviews, I decided to open my own business. Over the past year, I incurred many unforeseen financial problems. I owed my family, friends and creditors over $35,000. The economy was taking a toll on my business and I just couldn't seem to make ends meet. I had to refinance and borrow against my home to support my family and struggling business. AT THAT MOMENT something significant happened in my life and I am writing to share the experience in hopes that this will change your life FOREVER FINANCIALLY!!! In mid December, I received this program via e-mail. Six month's prior to receiving this program I had been sending away for information on various business opportunities. All of the programs I received, in my opinion, were not cost effective. They were either too difficult for me to comprehend or the initial investment was too much for me to risk to see if they would work or not. One claimed that I would make a million dollars in one year...it didn't tell me I'd have to write a book to make it! But like I was saying, in December of 1997 I received this program. I didn't send for it, or ask for it, they just got my name off a mailing list.THANK GOODNESS FOR THAT!!! After reading it several times, to make sure I was reading it correctly, I couldn't believe my eyes. Here was a MONEY MAKING PHENOMENON. I could invest as much as I wanted to start, without putting me further into debt. After I got a pencil and paper and figured it out, I would at least get my money back. But like most of you I was still a little skeptical and a little worried about the legal aspects of it all. So I checked it out with the U.S. Post Office (1-800-725-2161 24-hrs) and they confirmed that it is indeed legal! After determining the program was LEGAL and NOT A CHAIN LETTER, I decided "WHY NOT." Initially I sent out 10,000 e-mails. It cost me about $15 for my time on-line. The great thing about e-mail is that I don't need any money for printing to send out the program, and because all of my orders are fulfilled via e-mail, my only expense is my time. I am telling you like it is I hope it doesn't turn you off, but I promised myself that I would not "rip-off" anyone, no matter how much money it made me. In less than one week, I was starting to receive orders for REPORT #1 By January 13, I had received 26 orders for REPORT #1. Your goal is to "RECEIVE at least 20 ORDERS FOR REPORT #1 WITHIN 2 WEEKS. IF YOU DON'T, SEND OUT MORE PROGRAMS UNTIL YOU DO!" My first step in making $50,000 in 90 days was done. By January 30, I had received 196 orders for REPORT #2. Your goal is to "RECEIVE AT LEAST 100+ ORDERS FOR REPORT #2 WITHIN 2 WEEKS. IF NOT, SEND OUT MORE PROGRAMS UNTIL YOU DO. ONCE YOU HAVE 100 ORDERS, THE REST IS EASY, RELAX, YOU WILL MAKE YOUR $50,000 GOAL." Well, I had 196 orders for REPORT #2, 96 more than I needed. So I sat back and relaxed. By March 1, of my e-mailing of 10,000, I received $58,000 with more coming in every day. I paid off ALL my debts and bought a much needed new car. Please take time to read the attached program, IT WILL CHANGE YOUR LIFE FOREVER!! ! Remember, it won't work if you don't try it. This program does work , but you must follow it EXACTLY! Especially the rules of not trying to place your name in a different place. It won't work and you'll lose out on a lot of money! In order for this program to work, you must meet your goal of 20+ orders for REPORT #1, and 100+ orders for REPORT #2 and you will make $50,000 or more in 90 days. I AM LIVING PROOF THAT IT WORKS!!! If you choose not to participate in this program, I am sorry. It really is a great opportunity with little cost or risk to you. If you choose to participate, follow the program and you will be on your way to financial security. If you are a fellow business owner and are in financial trouble like I was, or you want to start your own business, consider this a sign. I DID! Sincerely, Johnathon Rourke A PERSONAL NOTE FROM THE ORIGINATOR OF THIS PROGRAM: By the time you have read the enclosed program and reports, you should have concluded that such a program, and one that is legal, could not have been created by an amateur. Let me tell you a little about myself. I had a profitable business for 10 years. Then in 1979 my business began falling off. I was doing the same things that were previously successful for me, but it wasn't working. Finally, I figured it out. It wasn't me, it was the economy. Inflation and recession had replaced the stable economy that had been with us since 1945.I don't have to tell you what happened to the unemployment rate... because many of you know from first hand experience. There were more failures and bankruptcies than ever before. The middle class was vanishing. Those who knew what they were doing invested wisely and moved up. Those who did not, including those who never had anything to save or invest, were moving down into the ranks of the poor. As the saying goes, "THE RICH GET RICHER AND THE POOR GET POORER." The traditional methods of making money will never allow you to "move up" or "get rich", inflation will see to that. You have just received information that can give you financial freedom for the rest of your life, with "NO RISK" and "JUST A LITTLE BIT OF EFFORT." You can make more money in the next few months than you have ever imagined. I should also point out that I will not see a penny of this money, nor anyone else who has provided a testimonial for this program. I have already made over 4 MILLION DOLLARS!I have retired from the program after sending thousands and thousands of programs. Follow the program EXACTLY AS INSTRUCTED. Do not change it in any way . It works exceedingly well as it is now. Remember to e-mail a copy of this exciting report to everyone you can think of. One of the people you send this to may send out 50,000...and your name will be on everyone of them! Remember though, the more you send out the more potential customers you will reach. So my friend, I have given you the ideas, information, materials and opportunity to become financially independent. IT IS UP TO YOU NOW! "THINK ABOUT IT" Before you delete this program from your mailbox, as I almost did, take a little time to read it and REALLY THINK ABOUT IT. Get a pencil and figure out what could happen when YOU participate. Figure out the worst possible response and no matter how you calculate it, you will still make a lot of money! You will definitely get back what you invested. Any doubts you have will vanish when your first orders come in. IT WORKS! Jody Jacobs, Richmond, VA HERE'S HOW THIS AMAZING PROGRAM WILL MAKE YOU THOUSANDS OF DOLLAR$ INSTRUCTIONS: This method of raising capital REALLY WORKS 100% EVERY TIME. I am sure that you could use up to $50,000 or more in the next 90 days. Before you say "BULL... ", please read this program carefully. This is not a chain letter, but a perfectly legal money making opportunity. Basically, this is what you do: As with all multi-level businesses, we build our business by recruiting new partners and selling our products. Every state in the USA allows you to recruit new multi-level business partners, and we offer a product for EVERY dollar sent. YOUR ORDERS COME BY MAIL AND ARE FILLED BY E-MAIL, so you are not involved in personal selling. You do it privately in your own home, store or office. This is the GREATEST Multi-Level Mail Order Marketing anywhere. This is what you MUST do: 1. Order all 4 reports shown on the list below (you can't sell them if youdon't order them). -- For each report, send $5.00 CASH, the NAME & NUMBER OF THE REPORT YOU ARE ORDERING, YOUR E-MAIL ADDRESS, and YOUR NAME & RETURN ADDRESS (in case of a problem) to the person whose name appears on the list next to the report. MAKE SURE YOUR RETURN ADDRESS IS ON YOUR ENVELOPE IN CASE OF ANY MAIL PROBLEMS! -- When you place your order, make sure you order each of the four reports. You will need all four reports so that you can save them on your computer and resell them. -- Within a few days you will receive, via e-mail, each of the four reports. Save them on your computer so they will be accessible for you to send to the 1,000's of people who will order them from you. 2. IMPORTANT DO NOT alter the names of the people who are listed next to each report, or their sequence on the list, in any way other than is instructed below in steps "a" through "f" or you will lose out on the majority of your profits. Once you understand the way this works, you'll also see how it doesn't work if you change it. Remember, this method has been tested,and if you alter it, it will not work. a. Look below for the listing of available reports. b. After you've ordered the four reports, take this advertisement and remove the name and address under REPORT #4. This person has made it through the cycle and is no doubt counting their $50,000! c. Move the name and address under REPORT #3 down to REPORT #4. d. Move the name and address under REPORT #2 down to REPORT #3. e. Move the name and address under REPORT #1 down to REPORT #2. f. Insert your name/address in the REPORT #1 position. Please make sure you COPY ALL INFORMATION, every name and address, ACCURATELY! 3. Take this entire letter, including the modified list of names, and save it to your computer. Make NO changes to the instruction portion of this letter. Your cost to participate in this is practically nothing (surely you can afford $20). You obviously already have an Internet connection and e-mail is FREE! There are two primary methods of building your downline: METHOD #1: SENDING BULK E-MAIL Let's say that you decide to start small, just to see how it goes, and we'll assume you and all those involved send out only 2,000 programs each. Let's also assume that the mailing receives a 0.5% response. Using a good list the response could be much better. Also, many people will send out hundreds of thousands of programs instead of 2,000. But continuing with this example, you send out only 2,000 programs. With a 0.5% response, that is only 10 orders for REPORT #1. Those 10 people respond by sending out 2,000 programs each for a total of 20,000. Out of those 0.5%, 100 people respond and order REPORT #2. Those 100 mail out 2,000 programs each for a total of 200,000. The 0.5% response to that is 1,000 orders for REPORT #3. Those 1,000 send out 2,000 programs each for a 2,000,000 total. The 0.5% response to that is 10,000 orders for REPORT #4. That's 10,000 $5 bills for you. CASH!!! Your total income in this example is $50 + $500 + $5,000 + $50,000 for a total of $55,550!!! REMEMBER FRIEND, THIS IS ASSUMING 1,990 OUT OF THE 2,000 PEOPLE YOU MAIL TO WILL DO ABSOLUTELY NOTHING AND TRASH THIS PROGRAM! DARE TO THINK FOR A MOMENT WHAT WOULD HAPPEN IF EVERYONE, OR HALF SENT OUT 100,000 PROGRAMS INSTEAD OF 2,000. Believe me, many people will do justthat, and more! By the way, your cost to participate in this is practically nothing. You obviously already have an Internet connection and e-mail is FREE!!! REPORT #2 will show you the best methods for bulk e-mailing, tell you where to obtain free bulk e-mail software and where to obtain e-mail lists. METHOD #2 - PLACING FREE ADS ON THE INTERNET Advertising on the internet is very, very inexpensive, and there are HUNDREDS of FREE places to advertise. Let's say you decide to start small just to see how well it works. Assume your goal is to get ONLY 10 people to participate on your first level. (Placing a lot of FREE ads on the Internet will EASILY get a larger response.) Also assume that everyone else in YOUR ORGANIZATION gets ONLY 10 downline members. Follow this example to achieve the STAGGERING results below: 1st level--your 10 members with $5.......................................$50 2nd level--10 members from those 10 ($5 x 100)..................$500 3rd level--10 members from those 100 ($5 x 1,000)...........$5,000 4th level--10 members from those 1,000 ($5 x 10,000).....$50,000 THIS TOTALS ---------->$55,550 Remember friends, this assumes that the people who participate only recruit 10 people each. Think for a moment what would happen if they got 20 people to participate! Most people get 100's of participants! THINK ABOUT IT! For every $5.00 you receive, all you must do is e-mail them the report they ordered. THAT'S IT! ALWAYS PROVIDE SAME-DAY SERVICE ON ALL ORDERS! This will guarantee that the e-mail THEY send out with YOUR name and address on it will be prompt because they can't advertise until they receive the report! AVAILABLE REPORTS *** Order Each REPORT by NUMBER and NAME *** Notes: -- ALWAYS SEND $5 CASH (U.S. CURRENCY) FOR EACH REPORT. CHECKS NOT ACCEPTED. -- ALWAYS SEND YOUR ORDER VIA FIRST CLASS MAIL. -- Make sure the cash is concealed by wrapping it in at least two sheets of paper. On one of those sheets of paper, include: (a) the number & name of the report you are ordering, (b) your e-mail address, and (c) your name & postal address. PLACE YOUR ORDER FOR THESE REPORTS NOW: REPORT #1 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: W. Hawkes 27 Cotton Street #1 Roslindale, MA 02131 REPORT #2 "The Insider's Guide to Advertising for Free on the Internet" ORDER REPORT #1 FROM: R. Higgins 5623 West 11270 North Highland, UT 84003-9062 REPORT #3 "The Insider's Guide to Sending Bulk E-mail on the Internet" ORDER REPORT #3 FROM: E-Solutions 101 PO Box 6411 Providence RI 02940-6411 REPORT #4 "The Secrets to Multilevel Marketing on the Internet" ORDER REPORT #4 FROM: M. Chavez 7711 N. 51st Ave. #3077 Glendale, AZ 85301 About 50,000 new people get online every month! ******* TIPS FOR SUCCESS ******* -- TREAT THIS AS YOUR BUSINESS! Be prompt, professional, and follow the directions accurately. -- Send for the four reports IMMEDIATELY so you will have them when the orders start coming in because: When you receive a $5 order, you MUST send out the requested product/report. -- ALWAYS PROVIDE SAME-DAY SERVICE ON THE ORDERS YOU RECEIVE. -- Be patient and persistent with this program. If you follow the instructions exactly, your results WILL BE SUCCESSFUL! -- ABOVE ALL, HAVE FAITH IN YOURSELF AND KNOW YOU WILL SUCCEED! ******* YOUR SUCCESS GUIDELINES ******* Follow these guidelines to guarantee your success: If you don't receive 20 orders for REPORT #1 within two weeks, continue advertising or sending e-mails until you do. Then, a couple of weeks later you should receive at least 100 orders for REPORT#2. If you don 't, continue advertising or sending e-mails until you do. Once you have received 100 or more orders for REPORT #2, YOU CAN RELAX, because the system is already working for you, and the cash will continue to roll in! THIS IS IMPORTANT TO REMEMBER: Every time your name is moved down on the list, you are placed in front of a DIFFERENT report. You can KEEP TRACK of your PROGRESS by watching which report people are ordering from you. If you want to generate more income, send another batch of e-mails or continue placing ads and start the whole process again! There is no limit to the income you will generate from this business! Before you make your decision as to whether or not you participate in this program. Please answer one question. DO YOU WANT TO CHANGE YOUR LIFE? If the answer is yes, please look at the following facts about this program: 1. You are selling a product which does not Cost anything to PRODUCE, SHIP OR ADVERTISE. 2. All of your customers pay you in CASH! 3. E-mail is without question the most powerful method of distributing information on earth. This program combines the distribution power of e-mail together with the revenue generating power of multi-level marketing. 4. Your only expense--other than your initial $20 investment--is your time! 5. Virtually all of the income you generate from this program is PURE PROFIT! 6. This program will change your LIFE FOREVER. ACT NOW!Take your first step toward achieving financial independence. Orderthe reports and follow the program outlined above--SUCCESSwill be yourreward. Thank you for your time and consideration. PLEASE NOTE: If you need help with starting a business, registering a business name, learning how income tax is handled, etc., contact your localoffice of the Small Business Administration (a Federal Agency) 1-800-827-5722 for free help and answers to questions. Also, the InternalRevenue Service offers free help via telephone and free seminars aboutbusiness tax requirements. Your earnings are highly dependant on youractivities and advertising. The information contained on this site and in the report constitutes no guarantees stated nor implied. In the event that it is determined that this site or report constitutes a guarantee of any kind, that guarantee is now void. The earnings amounts listed on this site and in the report are estimates only. If you have any questions of the legality of this program, contact the Office of Associate Director for Marketing Practices, Federal Trade Commission, Bureau of Consumer Protection in Washington, DC. ///////////////////////////////////////////////////////////////// Remove at robnb@hotbot.com ///////////////////////////////////////////////////////////////// - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Apr 20 11:23: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 LAA11568 for ; Tue, 20 Apr 1999 11:23:55 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA12435; Tue, 20 Apr 1999 08:16:29 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA00897 for ietf-radius-outgoing; Tue, 20 Apr 1999 08:14:36 -0700 (PDT) Message-Id: <199904201511.AAA18971@kokagate.koka.ac.jp> From: "Rob" Subject: (radius) WATCH YOUR PROFITS INCREASE 30-50%! To: speclist673d@kokagate.koka.ac.jp X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Tue, 20 Apr 1999 07:12:53 -0500 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Rob" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA11568 START ACCEPTING CREDIT CARDS & WATCH YOUR PROFITS INCREASE 30-50%! WE SPECIALIZE IN HELPING: * INTERNET * STOREFRONT * HOMEBASED OR * MAIL ORDER BUSINESSES APPLY BEFORE APRIL 29, 1999 AND RECEIVE: * NO APPLICATION FEE * NO PROGRAMMING FEE YOUR TOTAL START UP COST IS ONLY $9.95! CALL 1-888-264-9272 (BUSINESS HOURS: 9AM -6PM MST) Remove at: mailto:pp21t@glay.org?subject=remove - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 21 05:04: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 FAA02755 for ; Wed, 21 Apr 1999 05:04:22 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id BAA09236; Wed, 21 Apr 1999 01:57:57 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA25160 for ietf-radius-outgoing; Wed, 21 Apr 1999 02:00:33 -0700 (PDT) From: "Snorre Corneliussen" To: Subject: (radius) Some newbee questions Date: Wed, 21 Apr 1999 10:57:07 +0200 Message-ID: <003101be8bd4$eeffc620$20bfa1c1@eto.ericsson.se> 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 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Snorre Corneliussen" Content-Transfer-Encoding: 7bit Hi. My name is Snorre Corneliussen. I'm employed at Ericsson in Norway and I'm currently working with H.323 Gatekeepers. We are using RADIUS as both an authentication and accounting protocol for H.323 traffic. We have used RADIUS for about a year and I have only followed the mailing list for a month or two. I therefore consider myself as a newbee when it comes to understanding the future development of RADIUS. So don't hesitate to give me feedback if my questions are far of the RADIUS track. When using IP telephony we send start and stop RADIUS accounting events from the gatekeeper to a AAA server. They are used for sending accounting information about when the call was started, and when it was stopped, plus some additional information about the call. We also use the response messages to start and stop to provide pre-paid and Advice of Charge information back our system and then to the user. This works fine when you look at the static usage of resources for a single IP telephony call. The problem occurs when we want to provide a more dynamic accounting information to the AAA server. When using more of the features of H.323 than only IP telephony, the use of resources will often change several time during the call. This means that we want a continues update of the Advice of Charge and pre-paid parameters. We use the specified interim message specified in draft-ietf-radius-acct-interim-01.txt. If I have understood this draft correctly the interim message is only used to send a pre-stop message in case the system crash or the stop message is lost. It is therefore sent a regular intervals. This is of course a problem for us because this means that it can happen that some usage of resources has changed twice during the interim interval. We therefore consider to send them at more random intervals. Is this a problem ? Another problem we have is that if you have a scenario where you want to charge for usage that is not time-related you have to send both a start and a stop message. Let me give you an example. If you have an address translation service. You want to charge the user when we uses this service to i.e. translate from an e164 number to an IP-address (often done by gatekeepers). This is not a usage of a service with a time component. I read somewhere that you can not only send a RADIUS accounting stop message, you have to send a start first. I guess that this requirement is added to ease the implementations of AAA servers. My question is, couldn't it be nice to have a RADIUS accounting message type that is both a start and a stop message. An example of such a message is a ticket. Using tickets is quite popular when charging for WEB content. If somebody would give me some reflections on my questions I would be very happy. Best Regards Snorre :-) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Apr 24 14:44: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 OAA13468 for ; Sat, 24 Apr 1999 14:44:19 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA12643; Sat, 24 Apr 1999 11:37:26 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA02806 for ietf-radius-outgoing; Sat, 24 Apr 1999 11:37:44 -0700 (PDT) From: "Heath Partington" To: "Ietf-Radius@Livingston. Com" Subject: (radius) radius client mibs Date: Sat, 24 Apr 1999 14:34:33 -0400 Message-ID: <001301be8e81$195663d0$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" Content-Transfer-Encoding: 7bit In both the authentication and accounting radius client mib drafts how does one figure out the preference of the server? Is that supposed to be one of the duties of the ServerIndex variable? 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 Sun Apr 25 01:38: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 BAA19383 for ; Sun, 25 Apr 1999 01:38:20 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA18694; Sat, 24 Apr 1999 22:31:37 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA18049 for ietf-radius-outgoing; Sat, 24 Apr 1999 22:35:21 -0700 (PDT) Message-Id: <199904250514.CAA23568@allnet.all.com.br> From: "Edward" Subject: (radius) Could This Be For Real? To: inlist343e@iname.com X-Mailer: Microsoft Outlook Express 4.72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Sat, 24 Apr 1999 23:43:20 -0500 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Edward" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA19383 OK, we are going to give you the power! You have worked with other companies or heard the sad tales of woe from frustrated networkers. What if you could put together the ideal network marketing company? What characteristics would you build into your company? How would you treat your distributors? Let's see... 1) First you'd need products that people want, need, can afford, give results, and are in demand. This is a must. (What if you had products with 9 years of extensive double blind studies, worked in seconds or minutes, and affordable! What if you could add products announced on CNN and weight loss products that really work! Naw!! Really?? This is only a dream, right?!) 2) What if in addition to other products IN DEMAND, you had an absolutely DELICIOUS nutritional snack bar. (What if this nutritional bar had 3 major medical health benefits and it contained: 1) Live enzymes with digestive capabilities and studies to prove that it aids in the prevention and the reversal of any degenerative disease including cancer, 2) Micro nutrients that have been proven to prevent and reduce the risk of cancer dramatically and actually has the endorsement of The National Cancer Foundation, 3) The only nutritional snack bar in the industry to be registered with the FDA and have a drug code right on the label. All this and still be amazingly delicious and filling! This couldn't possibly be for real, could it?!?) 3) Then, you would want a company who would be willing to expose these products thru the media, at their cost: TV and radio commercials, newspapers, talk shows, etc., to help you get the word out. Offer people the chance to purchase products thru an 800 number while viewing or listening to the advertisement. (I haven't seen anything like this before! Could you just imagine!) 4) Then you would want your ideal company to let you share in the sales generated from this media exposure. Imagine what kind of volume this national exposure would generate. (What company would do this? We had nothing to do with these sales! This would be radical!) 5) Wouldn't it be great if we were given the names and addresses of the people who ordered product this way, so that we could follow-up with the customer to either sell more product as needed or introduce him or her to our ideal business opportunity. That would take care of our distributors having to constantly be finding their own qualified leads. (Companies now let us find our own leads, they follow-up with these people and THEY pocket the proceeds!) 6) You would want your company's compensation plan structured in such a way that we wouldn't need hundreds or even thousands in our downline before we start earning a decent check. Most people cannot do this. (True, but who's going to tell you this when you start?) 7) Wouldn't it be great if we could share in the successes of other distributors, and not just those that are in our downline. We would want everybody to be successful, not just some. (Nope - all we can do is admire the others' success!) Yes, wouldn't it be great if a company like this existed? One that confronted all the major drawbacks in this industry and actually solved them....a company that was built by distributors, for distributors... . a company that would want it's distributors to be successful....wouldn 't it be great? Introducing the nation's first and only Wave5 company, a company that has done all that and more! For more information about this unprecedented business opportunity -- please email: mailto:starwave5@joinme.com?subject=more_info or mailto:ourwave5@altavista.net?subject=more_info now for complete details. You now have the power to achieve your goals! ******************************************************** To be removed from our mailing list, please send an email to mailto:lucylawless1@iname.com?subject=remove ******************************************************** - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Apr 25 20:54: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 UAA04776 for ; Sun, 25 Apr 1999 20:54:46 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA29257; Sun, 25 Apr 1999 17:48:05 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA14059 for ietf-radius-outgoing; Sun, 25 Apr 1999 17:50:59 -0700 (PDT) Message-ID: <000f01be8f7e$82c5b980$15136b83@ntdev.microsoft.com> From: "Glen Zorn" To: "Heath Partington" , "Ietf-Radius@Livingston. Com" References: <001301be8e81$195663d0$da047392@hpartington.hq.springtidenet.com> Subject: Re: (radius) radius client mibs Date: Sun, 25 Apr 1999 17:48:05 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Heath Partington writes: > > In both the authentication and accounting radius client mib drafts how does > one figure out the preference of the server? Is that supposed to be one of > the duties of the ServerIndex variable? Don't understand the question. > > 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. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Apr 26 00:08: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 AAA07570 for ; Mon, 26 Apr 1999 00:08:36 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA01381; Sun, 25 Apr 1999 21:01:54 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA18772 for ietf-radius-outgoing; Sun, 25 Apr 1999 21:05:51 -0700 (PDT) Message-ID: <3723E5D4.F09A7EF5@iea-software.com> Date: Sun, 25 Apr 1999 21:04:36 -0700 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Glen Zorn CC: Heath Partington , "Ietf-Radius@Livingston. Com" Subject: Re: (radius) radius client mibs References: <001301be8e81$195663d0$da047392@hpartington.hq.springtidenet.com> <000f01be8f7e$82c5b980$15136b83@ntdev.microsoft.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 Glen Zorn wrote: > > Heath Partington writes: > > > > > In both the authentication and accounting radius client mib drafts how > does > > one figure out the preference of the server? Is that supposed to be one > of > > the duties of the ServerIndex variable? > > Don't understand the question. I don't think that value is tracked in the MIB. Remember that the implementation of failover is not defined in RADIUS, and up to the client implementor. Some do a round roubin (in which cases there isn't a preference) while others have a primary/secdonary configuration. -- 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 Apr 26 09:22: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 JAA16974 for ; Mon, 26 Apr 1999 09:22:44 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA08261; Mon, 26 Apr 1999 06:15:55 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA06877 for ietf-radius-outgoing; Mon, 26 Apr 1999 06:18:56 -0700 (PDT) From: "Heath Partington" To: "Glen Zorn" , "Ietf-Radius@Livingston. Com" Subject: RE: (radius) radius client mibs Date: Mon, 26 Apr 1999 09:16:06 -0400 Message-ID: <001401be8fe6$f1501540$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: <000f01be8f7e$82c5b980$15136b83@ntdev.microsoft.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Heath Partington" Content-Transfer-Encoding: 7bit I was trying to figure out how an administrator knows which server in the server tables is contacted first - there is no variable that seems to indicate this in the current draft mibs. > > Heath Partington writes: > > > > > In both the authentication and accounting radius client mib > drafts how > does > > one figure out the preference of the server? Is that > supposed to be one > of > > the duties of the ServerIndex variable? > > Don't understand the question. > > > > > 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. > > > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Apr 26 14:33: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 OAA21288 for ; Mon, 26 Apr 1999 14:33:51 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA25989; Mon, 26 Apr 1999 11:26:59 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA16740 for ietf-radius-outgoing; Mon, 26 Apr 1999 11:30:28 -0700 (PDT) Message-ID: <003601be9012$9f8f6ae0$18136b83@ntdev.microsoft.com> From: "Glen Zorn" To: "Dale E. Reed Jr." Cc: "Heath Partington" , "Ietf-Radius@Livingston. Com" References: <001301be8e81$195663d0$da047392@hpartington.hq.springtidenet.com> <000f01be8f7e$82c5b980$15136b83@ntdev.microsoft.com> <3723E5D4.F09A7EF5@iea-software.com> Subject: Re: (radius) radius client mibs Date: Mon, 26 Apr 1999 11:25:58 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Dale E. Reed Jr. writes: > Glen Zorn wrote: > > > > Heath Partington writes: > > > > > > > > In both the authentication and accounting radius client mib drafts how > > does > > > one figure out the preference of the server? Is that supposed to be one > > of > > > the duties of the ServerIndex variable? > > > > Don't understand the question. > > I don't think that value is tracked in the MIB. Remember that the > implementation of failover is not defined in RADIUS, and up to the > client implementor. Oh, OK, I understand now. Good answer. > Some do a round roubin (in which cases there isn't > a preference) while others have a primary/secdonary configuration. > > -- > > 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 Mon Apr 26 14:39: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 OAA21370 for ; Mon, 26 Apr 1999 14:39:00 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA26027; Mon, 26 Apr 1999 11:27:09 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA16708 for ietf-radius-outgoing; Mon, 26 Apr 1999 11:30:23 -0700 (PDT) Message-ID: <003801be9012$a035e410$18136b83@ntdev.microsoft.com> From: "Glen Zorn" To: "Heath Partington" , "Ietf-Radius@Livingston. Com" References: <001401be8fe6$f1501540$da047392@hpartington.hq.springtidenet.com> Subject: Re: (radius) radius client mibs Date: Mon, 26 Apr 1999 11:28:40 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Heath Partington writes: > I was trying to figure out how an administrator knows which server in the > server tables is contacted first - there is no variable that seems to > indicate this in the current draft mibs. OK. That's because the concept of server preference is not part of RADIUS, and it's implementation is vendor-specific. > > > > > > Heath Partington writes: > > > > > > > > In both the authentication and accounting radius client mib > > drafts how > > does > > > one figure out the preference of the server? Is that > > supposed to be one > > of > > > the duties of the ServerIndex variable? > > > > Don't understand the question. > > > > > > > > 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. > > > > > > > > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Apr 26 19:20: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 TAA25377 for ; Mon, 26 Apr 1999 19:20:38 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA05454; Mon, 26 Apr 1999 16:08:56 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA18226 for ietf-radius-outgoing; Mon, 26 Apr 1999 16:12:29 -0700 (PDT) Message-ID: <00a701be9039$d78d4d50$18136b83@ntdev.microsoft.com> From: "Glen Zorn" To: Cc: "IETF Radius" Subject: (radius) Charset/language in RADIUS Date: Mon, 26 Apr 1999 16:09:20 -0700 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 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Content-Transfer-Encoding: 7bit Since we've taken the big step of recommending the use of UTF-8 in printable strings, perhaps it would be a good idea to go the rest of the way and support RFC 2484-style language/charset negotiation, 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 Apr 27 12:10: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 MAA19006 for ; Tue, 27 Apr 1999 12:10:06 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA21010; Tue, 27 Apr 1999 09:03:09 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA07145 for ietf-radius-outgoing; Tue, 27 Apr 1999 09:04:11 -0700 (PDT) Message-Id: <199904271951.MAA09740@turismo.turismo.gub.uy> From: "Stan" Subject: (radius) $100,000 + INCOME To: oppseeker56f@claramail.com X-Mailer: Microsoft Outlook Express 4..72.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V(null).1712.3 Mime-Version: 1.0 Date: Tue, 27 Apr 1999 07:22:04 -0500 Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Stan" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA19006 *Earn $2000 - $5000 weekly-starting within 1-4 weeks *78% Profit Paid Daily *No Selling *No Risk Guarantee *Work from home, No overhead, or employees. *High Tech Training & Support *Not MLM, 100x more profitable *Multibillion Dollar Travel Industry The most incredible part of our business is that ALL MY CLIENTS CALL ME! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY 12 NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! 24 Hour Toll Free Message 1-800-858-2540 If your an entrepreneur or have always wanted to be your own BOSS, read on. We supply state-of-the-art training and a support system that allows you to work your business from your home with just a phone- without cold calling. DO NOT CALL ME IF YOU ARE LOOKING FOR A "GET RICH QUICK" SCHEME or some extra cash or if you're lazy. We are only looking for FOCUSED serious entrepreneurs. (PT/FT) with the DESIRE to improve their lifestyle immediately. If you would like to be removed from our mailing list please reply to: mailto:100know@newmail.net?subject=remove Any Vulgarity will be filtered and your request for removal will be deleted! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Apr 28 20: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 UAA29058 for ; Wed, 28 Apr 1999 20:52:56 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA08137; Wed, 28 Apr 1999 17:44:51 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA07858 for ietf-radius-outgoing; Wed, 28 Apr 1999 17:46:06 -0700 (PDT) From: s0yp@msn.com To: dkieuryt@aol.com Subject: (radius) Earn $3000 - $5000 weekly-starting within 1-4 weeks! Message-ID: <09e5c3142001d49CPIMSSMTPU08@email.msn.com> Date: 28 Apr 1999 17:42:50 -0700 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: s0yp@msn.com 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-283-1222 *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-283-1222 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 Thu Apr 29 01:18: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 BAA02951 for ; Thu, 29 Apr 1999 01:18:35 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA13373; Wed, 28 Apr 1999 22:11:49 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA19262 for ietf-radius-outgoing; Wed, 28 Apr 1999 22:15:53 -0700 (PDT) Date: Wed, 28 Apr 1999 22:15:51 -0700 (PDT) From: Carl Rigney Message-Id: <199904290515.WAA19256@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Callback Administrative User Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Some one pointed out that currently there's no Callback Administrative User for Service-Type, although there are Callback values for the other items. If no has any serious objections, I'll go ahead and allocated value 11 for that. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Apr 29 03:59: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 DAA10270 for ; Thu, 29 Apr 1999 03:59:37 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id AAA15217; Thu, 29 Apr 1999 00:52:57 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA25498 for ietf-radius-outgoing; Thu, 29 Apr 1999 00:56:06 -0700 (PDT) Date: Thu, 29 Apr 1999 00:56:04 -0700 (PDT) From: Carl Rigney Message-Id: <199904290756.AAA25491@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Late night humor Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney OK, I know I've been staring at the drafts too long when I read this: > An example showing 8 Accounting-Requests should make things clearer. And find myself thinking about changing the "should" to "MUST". :-) -- Carl Rigney cdr@livingston.com "improvement in delay./52/ While this may seem significant, on a 2400 bps line it means that typing echo response takes 25 rather than 29 ms. At the present stage of human evolution, this difference is not detectable." -- Van Jacobson, RFC 1144 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 30 05:22: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 FAA20912 for ; Fri, 30 Apr 1999 05:21:59 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id CAA15019; Fri, 30 Apr 1999 02:15:05 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA01827 for ietf-radius-outgoing; Fri, 30 Apr 1999 02:15:45 -0700 (PDT) Date: Fri, 30 Apr 1999 02:15:44 -0700 (PDT) From: Carl Rigney Message-Id: <199904300915.CAA01820@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) EAP-Start Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney draft-ietf-radius-ext-03.txt currently says: > EAP-Start is indicated by sending an EAP-Message attribute > with a length of 2 (no data). Attributes with zero-length data are not allowed, so this needs to be reconciled. I'm not very familiar with EAP, is there an actual EAP-Start packet that could be included in the EAP-Message? That would solve this problem handily. Or lacking that, is there some kind of EAP-NOP? The Extensions draft is otherwise ready for Working Group Last Call, but I wanted to see if there's some easy fix for this that I can apply before sending it out. Also, the current text in ext-03 says User-Name can be returned in an Access-Accept or Access-Challenge. I think Challenge should be deleted since currently User-Name is not permitted in Challenge (and doesn't seem necessary, since it can now be sent in the Access-Accept). Mail directly to me, or to the list if you wish. Saying that 0-length attributes should be allowed is a dead subject, I'm looking for something else here. -- Carl Rigney RADIUS WG Editor 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 Apr 30 05:29: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 FAA20949 for ; Fri, 30 Apr 1999 05:29:21 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id CAA15163; Fri, 30 Apr 1999 02:22:45 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA02127 for ietf-radius-outgoing; Fri, 30 Apr 1999 02:27:00 -0700 (PDT) Date: Fri, 30 Apr 1999 02:26:59 -0700 (PDT) From: Carl Rigney Message-Id: <199904300926.CAA02121@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) NAS-Port-Id and Framed-Pool Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Since there were several members who liked the idea and no one who seemed to think it was a bad idea, I've added NAS-Port-Id (87) and Framed-Pool (88) to the extensions draft (coming soon!). I renamed Framed-IP-Pool to Framed-Pool since there's no reason it couldn't be used to implement IPX pools or Appletalk Pools or whatever else. (Yes, you may shudder at the thought, if you wish to.) Here's the current text I'm using, suggestions for improvement are gladly accepted. Possibly I need some clarification to make sure people understand the intent to Framed-Pool is like Framed-Pool = "foonet" and not Framed-Pool = "192.168.7.0/27"; its a reference to something that already exists on the NAS. Casual thought should make that seem obvious, since different NASes have to use different pools or routing would go insane, but it never hurts to make something clearer. If you don't have time to suggest something now, you can do so during the two week working group last call for the extensions document, coming soon. 5.17. NAS-Port-Id Description This Attribute contains a string with identifies the port of the NAS which is authenticating the user. It is only used in Access- Request packets. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number. Either NAS-Port or NAS-Port-Id SHOULD be present in an Access- Request packet, if the NAS differentiates among its ports. NAS- Port-Id is intended for use by NASes which cannot conveniently number their ports. A summary of the NAS-Port-Id Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 87 for NAS-Port-Id. Length >= 3 String The String field contains the name of the port in UTF-8 [6] format. 5.18. Framed-Pool Description This Attribute contains the name of an assigned address pool that SHOULD be used to assign an address for the user. If a NAS does not support multiple address pools, the NAS should ignore this Attribute. Address pools are usually used for IP addresses, but can be used for other protocols if the NAS supports pools for those protocols. A summary of the Framed-Pool Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 88 for Framed-Pool Length >= 3 String The string field contains the name of an assigned address pool configured on the NAS. 5.19. Table of Attributes Request Accept Reject Challenge # Attribute 0-1 0 0 0 87 NAS-Port-Id 0 0-1 0 0 88 Framed-Pool - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 30 05:30: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 FAA20964 for ; Fri, 30 Apr 1999 05:30:41 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id CAA15255; Fri, 30 Apr 1999 02:24:01 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA02201 for ietf-radius-outgoing; Fri, 30 Apr 1999 02:28:23 -0700 (PDT) Date: Fri, 30 Apr 1999 02:28:22 -0700 (PDT) From: Carl Rigney Message-Id: <199904300928.CAA02193@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) NAS-Port-Type = Ethernet Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Bernard asked about assigning a NAS-Port-Type for Ethernet, now that PPP over Ethernet exists. I don't see any problem in doing so (we have 4 billion values, after all) so I plan to assign 15, unless serious objections are raised. -- Carl - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Apr 30 05:52: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 FAA21168 for ; Fri, 30 Apr 1999 05:52:55 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id CAA15514; Fri, 30 Apr 1999 02:46:20 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id CAA02815 for ietf-radius-outgoing; Fri, 30 Apr 1999 02:49:53 -0700 (PDT) Date: Fri, 30 Apr 1999 02:49:51 -0700 (PDT) From: Carl Rigney Message-Id: <199904300949.CAA02810@server.livingston.com> To: milan.obuch@netlab.sk Subject: Re: (radius) NAS-Port-Id and Framed-Pool Cc: ietf-radius@livingston.com Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney milan.obuch@netlab.sk wrote directly to point out two corrections; I'm cc'ing my reply to the whole list so everyone knows they're caught and fixed. >>This Attribute contains a string with identifies the port of the >Maybe just a typo... >which identifies... >or >with identifier of ... It's a typo; it should be "which identifies." Thanks for catching that! >> NAS which is authenticating the user. It is only used in Access- >> Request packets. Note that this is using "port" in its sense of a >Why? Can't this attribute be used in Accounting packets as well? It can, I'll update the text. -- 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 Apr 30 06:22: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 GAA21314 for ; Fri, 30 Apr 1999 06:22:52 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA15814; Fri, 30 Apr 1999 03:16:04 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA03640 for ietf-radius-outgoing; Fri, 30 Apr 1999 03:20:41 -0700 (PDT) Date: Fri, 30 Apr 1999 03:20:39 -0700 (PDT) From: Carl Rigney Message-Id: <199904301020.DAA03631@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Status Update Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney RADIUS Extensions and RADIUS Accounting are ready for WG last call. The new RADIUS draft is almost done, I'm working on improving its discussion of Proxy based on all the feedback from draft v2-00, and then I think its ready for WG last call. I should be done by Monday, and then I'll submit all three to the Internet-Drafts directory and issue the two-week WG Last Call. As soon as that's over (and any changes made) they're off to IESG/IETF Last Call. The 3 tunneling drafts are nearly ready for IETF Last Call, and the 4 MIB drafts are approved and sitting in the RFC Editor's queue. -- Carl Rigney RADIUS WG Chair 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 Apr 30 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 LAA02430 for ; Fri, 30 Apr 1999 11:34:05 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA22645; Fri, 30 Apr 1999 08:27:16 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA19877 for ietf-radius-outgoing; Fri, 30 Apr 1999 08:30:32 -0700 (PDT) Date: Fri, 30 Apr 1999 11:30:22 -0400 (EDT) From: "Steven P. Crain" To: Carl Rigney cc: ietf-radius@livingston.com Subject: Re: (radius) NAS-Port-Id and Framed-Pool In-Reply-To: <199904300926.CAA02121@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, 30 Apr 1999, Carl Rigney wrote: > 5.17. NAS-Port-Id > > Description > > This Attribute contains a string with identifies the port of the ^ which > 5.18. Framed-Pool > > Description > > This Attribute contains the name of an assigned address pool that > SHOULD be used to assign an address for the user. If a NAS does > not support multiple address pools, the NAS should ignore this > Attribute. Address pools are usually used for IP addresses, but > can be used for other protocols if the NAS supports pools for > those protocols. We need to more clearly define the behavior if named pools are supported on the NAS, but this particular pool has not been configured. We also need to specify what should happen if the specified pool is exhausted. I recommend something like, "If the particular pool requested is not configured on the NAS, the NAS SHOULD ignore this Attribute. If the particular pool does not have available addresses, the NAS SHOULD by default reject the call, but may be configured to take some other action, such as taking an address from a backup pool." -- 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 Fri Apr 30 14:01: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 OAA09075 for ; Fri, 30 Apr 1999 14:01:49 -0400 (EDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA27348; Fri, 30 Apr 1999 10:54:59 -0700 (PDT) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA08013 for ietf-radius-outgoing; Fri, 30 Apr 1999 10:58:07 -0700 (PDT) From: "Bernard Aboba" To: "'Carl Rigney'" , Subject: RE: (radius) EAP-Start Date: Fri, 30 Apr 1999 11:04:20 -0700 Message-ID: <000401be9333$dffbf840$268939cc@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 CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <199904300915.CAA01820@server.livingston.com> Importance: Normal Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" Content-Transfer-Encoding: 7bit EAP-Start is not part of EAP, since an EAP-Start message will never be sent by an EAP peer or authenticator. It is merely a signal from RADIUS client to the RADIUS server. As such, signalling of EAP-Start needs to be handled within RADIUS. An alternative (albeit ugly) way to handle this would be to add another attribute, EAP-Start. I would also mention that there are limited applications for EAP-Start. Most implementations that I am familiar with begin the EAP conversation by sending an EAP-Message/EAP-Response/Identity packet to the RADIUS server. As a result, they never send an EAP-Start. The primary application for EAP-Start is in DNIS identification, in which the EAP-Message/EAP-Request/Identity is typically not sent. For example, this would allow for Internet access based on telephone number and possession of a token card. In such a case, the Access-Request would contain an EAP-Start as well as Calling-Station-Id and/or Called-Station-ID attributes. The function of the EAP-Start is to allow the RADIUS client to signal the RADIUS server that it is EAP-capable. This allows the RADIUS server to avoid sending an EAP-Message attribute to a NAS that does not support it. Removing User-Name from the Access-Challenge is not a good idea since this will prevent RADIUS proxies from forwarding the messages based on the realm within the NAI. This would be needed for example, if someone wanted to implement roaming support for EAP. -----Original Message----- From: owner-ietf-radius@livingston.com [mailto:owner-ietf-radius@livingston.com]On Behalf Of Carl Rigney Sent: Friday, April 30, 1999 2:16 AM To: ietf-radius@livingston.com Subject: (radius) EAP-Start draft-ietf-radius-ext-03.txt currently says: > EAP-Start is indicated by sending an EAP-Message attribute > with a length of 2 (no data). Attributes with zero-length data are not allowed, so this needs to be reconciled. I'm not very familiar with EAP, is there an actual EAP-Start packet that could be included in the EAP-Message? That would solve this problem handily. Or lacking that, is there some kind of EAP-NOP? The Extensions draft is otherwise ready for Working Group Last Call, but I wanted to see if there's some easy fix for this that I can apply before sending it out. Also, the current text in ext-03 says User-Name can be returned in an Access-Accept or Access-Challenge. I think Challenge should be deleted since currently User-Name is not permitted in Challenge (and doesn't seem necessary, since it can now be sent in the Access-Accept). Mail directly to me, or to the list if you wish. Saying that 0-length attributes should be allowed is a dead subject, I'm looking for something else here. -- Carl Rigney RADIUS WG Editor 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.