From owner-ietf-radius@livingston.com Mon Jan 4 00:54:24 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA07543 for ; Mon, 4 Jan 1999 00:54:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA16805; Sun, 3 Jan 1999 21:46:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA24531 for ietf-radius-outgoing; Sun, 3 Jan 1999 21:41:35 -0800 (PST) Message-Id: <3.0.1.32.19990104111257.006952ac@172.16.1.10> X-Sender: srikanth@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 04 Jan 1999 11:12:57 +0500 To: ietf-radius@livingston.com From: Nayani Srikanth Subject: (radius) Octet - Packet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Nayani Srikanth Sir/Madam, In the RADIUS accounting RFC 2139 of the attributes mentioned there are two attributes Acct-Input-Octets and Acct-Input-Packets . How do they differ? and how do we descide on the number of Packets? Regards, Srikanth. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 4 07:00:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA15483 for ; Mon, 4 Jan 1999 07:00:17 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA22019; Mon, 4 Jan 1999 03:52:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA07117 for ietf-radius-outgoing; Mon, 4 Jan 1999 03:49:55 -0800 (PST) Message-Id: <3.0.1.32.19990104172151.006b8a3c@172.16.1.10> X-Sender: srikanth@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 04 Jan 1999 17:21:51 +0500 To: ietf-radius@livingston.com From: Nayani Srikanth Subject: (radius) Accounting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Nayani Srikanth Sir/Madam, In RADIUS accounting does the Radius server stop billing all the users connected to a particular NAS when an Accounting-on is received from that NAS i.e does it stop and start again. Also if a NAS goes down due to some hardware problems while some stops are still pending for some users, when and how will the RADIUS server stop billing the users connected to this illfated NAS. Regards, Srikanth. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 4 11:36:58 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA18098 for ; Mon, 4 Jan 1999 11:36:58 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA28842; Mon, 4 Jan 1999 08:29:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA22432 for ietf-radius-outgoing; Mon, 4 Jan 1999 08:30:28 -0800 (PST) Message-ID: <3690F9F5.5801239F@frigate.com> Date: Mon, 04 Jan 1999 09:27:17 -0800 From: Bill Webb X-Mailer: Mozilla 4.5 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Nayani Srikanth CC: ietf-radius@livingston.com Subject: Re: (radius) Octet - Packet References: <3.0.1.32.19990104111257.006952ac@172.16.1.10> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Bill Webb Nayani Srikanth wrote: > Sir/Madam, > In the RADIUS accounting RFC 2139 of the attributes mentioned there > are two attributes Acct-Input-Octets and Acct-Input-Packets . How do they > differ? and how do we descide on the number of Packets? > > Regards, > Srikanth. > Octets are the number of bytes (characters) while packets are the number of actual packets. Typically the number of octets is 10-100 times the number of packets. Typically router code will increment packet and octet counters at some appropriate point in the code. The number of packets is pretty well defined (though there may be questions here as well for packets that exceed the path MTU), but I don't think the RFC defines any interpretation of the Input-Octet counter (e.g. is this pre or post-compression?) so it may vary between NAS's. The NAS vendor's documentation should state what they define the attribute to mean. -- Bill Webb. Email: webb@frigate.com WWW: http://www.frigate.com/~webb -- above opinions are my own, not anyone else's. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 5 11:21:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA07631 for ; Tue, 5 Jan 1999 11:21:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA21820; Tue, 5 Jan 1999 08:11:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA08470 for ietf-radius-outgoing; Tue, 5 Jan 1999 08:11:01 -0800 (PST) Message-Id: <4.1.19990105110817.00b71de0@mis.cqtel.com> X-Sender: rkidderm@mis.cqtel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 5 Jan 1999 11:09:32 -0500 To: portmaster-radius@livingston.com, ietf-radius@livingston.com From: Roy Kidder Subject: (radius) Looking for FAQ Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Roy Kidder Can someone point me to a FAQ for this list (if one exists)? Thanks in advance, Roy _________________________________________________ Roy Kidder Data Network Manager SmarTalk Teleservices - - - - - - - - - - - - - - - - - - - - - - - - - "...has reached rock bottom, and has started to dig." --excerpt from a military officer's review. _________________________________________________ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 5 14:24:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA09826 for ; Tue, 5 Jan 1999 14:24:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA04536; Tue, 5 Jan 1999 11:16:23 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA02966 for ietf-radius-outgoing; Tue, 5 Jan 1999 11:18:05 -0800 (PST) From: mhytqasw@gre.ac.uk Date: Sun, 3 Jan 1999 23:20:04 -0700 Message-Id: <199901040620.XAA14616@dellcity.com> To: mhytqasw@gre.ac.uk Subject: (radius) Unlimited Income Opportunity Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: mhytqasw@gre.ac.uk Look, we don't want to waste your time....or ours. If you are 100% SERIOUS about earning a solid, six-figure income from home, and you're not afraid to work for it WE CAN HELP YOU! * NOT MLM or GLOBAL * Completely Legitimate Home-Based Business * Registered with D&B and BBB * Professional Training and Fantastic Support * Work Entirely From Home (no personal selling) Grab your share of the 3.4 Trillion Dollar Travel Industry NOW! CALL TOLL FREE 888-474-4721 (24 Hour Recorded Message) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 5 22:49:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA15722 for ; Tue, 5 Jan 1999 22:49:31 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id TAA07152; Tue, 5 Jan 1999 19:40:47 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA26519 for ietf-radius-outgoing; Tue, 5 Jan 1999 19:42:07 -0800 (PST) FromTheDeskOf: Roy Kidder Message-Id: <4.1.19990105223255.00a96790@mis.cqtel.com> X-Sender: rkidderm@mis.cqtel.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 5 Jan 1999 22:40:33 -0500 To: ietf-radius@livingston.com From: Roy Kidder Subject: (radius) Looking for code In-Reply-To: <19990105185128.A14631@netmonger.net> References: <36929BDA.859D67A9@livingston.com> <3.0.6.32.19990104211704.00915a30@mail.deltech.net> <36918B58.25EB867E@livingston.com> <19990105180703.B29813@netmonger.net> <36929BDA.859D67A9@livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Roy Kidder I am looking for code (and perhaps even some documentation) for the suite of UNIX tools (/bin/login, etc) which uses a RADIUS server instead of /etc/passwd? I maintain a RADIUS server for my company and would love to consolidate all the user logins. Any help anyone can provide would be greatly appreciated. Roy Kidder _________________________________________________ Roy Kidder Data Network Manager SmarTalk Teleservices - - - - - - - - - - - - - - - - - - - - - - - - - ERROR: All attempts to communicate with device '/usr/headspace' have failed. Giving Up. _________________________________________________ - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 5 23:33:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA16278 for ; Tue, 5 Jan 1999 23:33:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA08813; Tue, 5 Jan 1999 20:25:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA28552 for ietf-radius-outgoing; Tue, 5 Jan 1999 20:27:27 -0800 (PST) X-Authentication-Warning: mirage.irdu.nus.edu.sg: roland owned process doing -bs Date: Wed, 6 Jan 1999 12:21:50 +0800 (SGT) From: Roland Yeo X-Sender: roland@mirage.irdu.nus.edu.sg To: Roy Kidder cc: ietf-radius@livingston.com Subject: Re: (radius) Looking for code In-Reply-To: <4.1.19990105223255.00a96790@mis.cqtel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Roland Yeo you might want to look at Pluggable Authentication Modules. some URLs below for your reference. http://wwwwseast2.usec.sun.com/software/solaris/pam/ http://www.us.kernel.org/pub/linux/libs/pam/ http://www.us.kernel.org/pub/linux/libs/pam/modules.html regards, roland -- Roland Yeo Pacific Internet Ltd - Singapore On Tue, 5 Jan 1999, Roy Kidder wrote: > I am looking for code (and perhaps even some documentation) for the > suite of UNIX tools (/bin/login, etc) which uses a RADIUS server > instead of /etc/passwd? I maintain a RADIUS server for my company and > would love to consolidate all the user logins. > > Any help anyone can provide would be greatly appreciated. > > Roy Kidder > _________________________________________________ > Roy Kidder > Data Network Manager > SmarTalk Teleservices > - - - - - - - - - - - - - - - - - - - - - - - - - > ERROR: All attempts to communicate with device > '/usr/headspace' have failed. Giving Up. > _________________________________________________ > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 7 02:00:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA18813 for ; Thu, 7 Jan 1999 02:00:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA26511; Wed, 6 Jan 1999 22:52:30 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA17039 for ietf-radius-outgoing; Wed, 6 Jan 1999 22:48:52 -0800 (PST) Date: Wed, 6 Jan 1999 22:48:51 -0800 (PST) From: Carl Rigney Message-Id: <199901070648.WAA17034@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) Making progress Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney Here's the game plan: >That's doable. I hope to have my 4 documents to the working group last >call in January. The extensions draft and Glenn's 7 documents are >ready for WG last call now, I'll post that right after the holidays >(doing a last call while everyone is away on vacation seems wrong). >I expect comments on the WG last call to be minimal for everything but >perhaps the BCP on how to allocate numbers, but even that one should be >ready for submission to the IESG sometime in February. -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 7 02:00:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA18843 for ; Thu, 7 Jan 1999 02:00:34 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA26513; Wed, 6 Jan 1999 22:52:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA17174 for ietf-radius-outgoing; Wed, 6 Jan 1999 22:52:15 -0800 (PST) Date: Wed, 6 Jan 1999 22:52:14 -0800 (PST) From: Carl Rigney Message-Id: <199901070652.WAA17168@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) WG LAST CALL on RADIUS SNMP drafts Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney This is the Working Group last call for the 4 RADIUS SNMP drafts before sending them to IETF Last Call before advancing them to Proposed Standard. If you have any comments on them please send them to the authors or the ietf-radius@livingston.com mailing list BEFORE January 22nd. http://www.ietf.org/internet-drafts/draft-ietf-radius-acc-clientmib-02.txt, http://www.ietf.org/internet-drafts/draft-ietf-radius-acc-servmib-02.txt, http://www.ietf.org/internet-drafts/draft-ietf-radius-auth-clientmib-02.txt, http://www.ietf.org/internet-drafts/draft-ietf-radius-auth-servmib-02.txt. -- Carl Rigney RADIUS WG Chair cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 7 02:03:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA22629 for ; Thu, 7 Jan 1999 02:03:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA26748; Wed, 6 Jan 1999 22:55:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA17334 for ietf-radius-outgoing; Wed, 6 Jan 1999 22:55:47 -0800 (PST) Date: Wed, 6 Jan 1999 22:55:45 -0800 (PST) From: Carl Rigney Message-Id: <199901070655.WAA17326@server.livingston.com> To: ietf-radius@livingston.com Subject: (radius) WG LAST CALL on L2TP RADIUS Drafts Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney This is the Working Group last call for the 3 RADIUS L2TP drafts before sending them to IETF Last Call before advancing them to Proposed Standard. If you have any comments on them please send them to the authors or the ietf-radius@livingston.com mailing list BEFORE January 22nd. The RFC Editor may need to hang on to them until the L2TP working group's drafts get RFC numbers as well so that the appropriate reference can be inserted, but we might as well get them into the queue. If L2TP changes substantially we can always update and re-issue these. http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-imp-04.txt http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-auth-06.txt http://www.ietf.org/internet-drafts/draft-ietf-radius-tunnel-acct-02.txt -- Carl Rigney RADIUS WG Chair cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 7 02:20:22 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id CAA24491 for ; Thu, 7 Jan 1999 02:20:21 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id XAA27438; Wed, 6 Jan 1999 23:12:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id XAA18281 for ietf-radius-outgoing; Wed, 6 Jan 1999 23:12:30 -0800 (PST) Date: Wed, 6 Jan 1999 23:12:29 -0800 (PST) From: Carl Rigney Message-Id: <199901070712.XAA18272@server.livingston.com> To: ietf-radius@livingston.com Subject: Re: (radius) Extensions draft Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Carl Rigney OK, megazone points out that Connect-Info should probably have transmit speed first, then receive speed (from the NAS point of view). So I've updated the relevant paragraph of the RADIUS Extensions draft to say: The String field is encoded as ASCII characters. The connection speed SHOULD be included at the beginning of the first Connect-Info attribute in the packet. If the transmit and receive connection speeds differ, they may both be included in the first attribute with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information. For example, "28800 V42BIS/LAPM" or "52000/31200 V90" Any objections or suggestions? -- Carl Rigney cdr@livingston.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 7 18:05:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA13832 for ; Thu, 7 Jan 1999 18:05: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 OAA01846; Thu, 7 Jan 1999 14:57:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA03979 for ietf-radius-outgoing; Thu, 7 Jan 1999 14:57:55 -0800 (PST) Message-ID: <36953AF1.A0D7BFE9@uol.com.br> Date: Thu, 07 Jan 1999 20:53:37 -0200 From: Alberto Ferreira Delgado X-Mailer: Mozilla 4.5 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Lista Radius Subject: (radius) Merit Radius 3.6B !!! Content-Type: multipart/mixed; boundary="------------7CEBD36A447DE3A147518D31" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alberto Ferreira Delgado This is a multi-part message in MIME format. --------------7CEBD36A447DE3A147518D31 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I am trying to update our version of radius to the new one 3.6B, but we are having problems with the accounting responses to the NAS, the NAS is sending o lot of accounting request to radius for the same user, seems to me that the NAS is not receveing the correct asnwer from radius, other thing that i had observed is that the Acct-Delay-Time is incresing in this requests,my question : Does Anybody know why the NAS is sending a lot of accounting requests to radius? soomeone had a similar problem with the nem Radius ? I am testing with a pm3 and NetServer I need to change or configure something ? or this version of Radius does not work with pm3 ? Regards, -- ---------------------------------------------------------------------- Tonight you're a star, and I'm the big dipper. ---------------------------------------------------------------------- --------------7CEBD36A447DE3A147518D31 Content-Type: text/x-vcard; charset=us-ascii; name="afdelgado.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Alberto Ferreira Delgado Content-Disposition: attachment; filename="afdelgado.vcf" begin:vcard n:Delgado;Alberto Ferreira tel;cell:9155-7263 tel;home:4799-0470 tel;work:224-7596 x-mozilla-html:TRUE org:Universo Online;Tecnologia adr:;;Al. Barão de limeira, 425;São Paulo;São Paulo;01202-000;Brasil version:2.1 email;internet:afdelgado@uol.com.br title:Analista de Sistemas fn:Alberto Ferreira Delgado end:vcard --------------7CEBD36A447DE3A147518D31-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 7 20:49:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA15405 for ; Thu, 7 Jan 1999 20:49:47 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA08778; Thu, 7 Jan 1999 17:40:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA20664 for ietf-radius-outgoing; Thu, 7 Jan 1999 17:42:19 -0800 (PST) From: William Bulley Message-Id: <199901080143.UAA07816@ohm.merit.edu> Subject: Re: (radius) Merit Radius 3.6B !!! To: afdelgado@uol.com.br Date: Thu, 7 Jan 1999 20:43:16 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <36953AF1.A0D7BFE9@uol.com.br> from "Alberto Ferreira Delgado" at Jan 7, 99 08:53:37 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William Bulley According to Alberto Ferreira Delgado: > > I am trying to update our version of radius to the new one 3.6B, but > we are having problems with the accounting responses to the NAS, the NAS > is sending o lot of accounting request to radius for the same user, > seems to me that the NAS is not receveing the correct asnwer from > radius, other thing that i had observed is that the Acct-Delay-Time is > incresing in this requests,my question : This kind of question should be directed to aaa-support@merit.edu and not to this IETF mailing list. > Does Anybody know why the NAS is sending a lot of accounting > requests to radius? soomeone had a similar problem with the nem Radius ? > I am testing with a pm3 and NetServer If the NAS does not receive an Access-Accept it should not generate any Accounting-Requests. After the Access-Accept, the only reason a NAS would not "shut-up" would be if it did not receive an Accounting-Response. You can examine debug logs to see if an Accounting-Response has been sent to the NAS by our server... > I need to change or configure something ? or this version of Radius > does not work with pm3 ? We have many PM3 units working with 3.6 server code. Regards, web... -- William Bulley Senior Systems Research Programmer Merit Network, Inc. Email: web@merit.edu 4251 Plymouth Road, Suite C Phone: (734) 764-9993 Ann Arbor, Michigan 48105-2785 Fax: (734) 647-3185 If entropy is increasing, where is it coming from? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 8 03:30:05 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA08592 for ; Fri, 8 Jan 1999 03:30:05 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id AAA17889; Fri, 8 Jan 1999 00:21:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA09159 for ietf-radius-outgoing; Fri, 8 Jan 1999 00:20:54 -0800 (PST) Date: Fri, 8 Jan 1999 16:14:09 +0800 (SGT) From: Jianying Zhou X-Sender: jyzhou@colorado To: aft@socks.nec.com, ietf-cat-wg@lists.stanford.edu, cryptography@c2.net, dns-security@tis.com, Firewalls@lists.gnac.net, ids@uow.edu.au, ietf-open-pgp@imc.org, ietf-otp@bellcore.com, ietf-pkix@imc.org, ietf-radius@livingston.com, ietf-smime@imc.org, ietf-ssh@clinet.fi, ietf-tls@consensus.com, ietf@ietf.org, ipsec@tis.com, OGsecurity@opengroup.org, pem-dev@tis.com, risks@csl.sri.com, spki@c2.net, virus-l@lehigh.edu, www-buyinfo@allegra.att.com, www-security@ns2.rutgers.edu Subject: (radius) Re: ACM CCS'99 CFP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Jianying Zhou I apology for sending a large attachment in an early message. Sorry. Jianying Zhou - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 12 00:44:28 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA02205 for ; Tue, 12 Jan 1999 00:44:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA13687; Mon, 11 Jan 1999 21:29:59 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA00442 for ietf-radius-outgoing; Mon, 11 Jan 1999 21:28:58 -0800 (PST) From: ggt6@cnt.net To: user@the-internet.com Message-ID: < > Date: Mon, 11 Jan 99 20:37:56 EST Subject: (radius) hi Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: ggt6@cnt.net Do you know the major reason most small businesses fail? Lack of advertising. Do you know the reason for the lack of advertising? Money. Most small businesses cannot afford to spend high dollars on effective advertising. UNTIL NOW. Welcome to the new millenium. Direct email has proven to be the number one successful way for a small business to advertise in the past two years. Why spend thousands of dollars on expensive magazine and newspaper ads that only a fraction of the readers are actually going to see, when you can send your ad directly to the consumer. Direct email advertising is exactly that, it is direct advertising. It places your ad directly in the email box of millions of people, and it is inexpensive. With this new advertising media, small companies can now compete with larger companies on a level playing field. Our director of marketing is one of the top experts in this field, and has been interviewed by CNN, USA Today, the Los Angeles Times, the New York Times, and the Wall Street Journal. We have put together a list of five million email addresses of individuals and small businesses in the United States. We have added another 1.5 million International addresses. Do not be fooled by our competitors who claim to have 20 and 30 million email addresses. Your are buying the same addresses over, they have duplicates as high as 70%. We guarantee you that there are no duplicates in our lists or your money back. We also update our lists every two weeks. You will be buying the freshest email addresses on the Internet. Guaranteed! We could easily get $1000 for our addresses, but we are selling our entire 5 million address database, plus the 1.5 million international list for only $299. But that's not all you get. If you order by January 15th you also get a free full working demo of ! ! ! Stealth Mass Mailer, the direct mail program capable of sending as many as 300,000 emails per hour. You also get a free full working demo of BulkMate, an email address database manager. The regular price for this CD is $349, but if you order before January 15th you will get the sale price of ONLY $299! To order call us at (909) 613-9407. Or you can fill out the following order form: -------------------------------------------------------------------------------------------- Name:____________________________ Address:_________________________________________________ Telephone:_________________________ Email Address:_______________________________ Please send $299 plus $12 for shipping and handling to: IMC Marketing 806 Buccanon Blvd. Bldg 115, Suite 119 Boulder City, NV 89005 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 13 06:39:43 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA09457 for ; Wed, 13 Jan 1999 06:39:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA13686; Wed, 13 Jan 1999 03:28:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA01584 for ietf-radius-outgoing; Wed, 13 Jan 1999 03:28:09 -0800 (PST) Message-Id: <3.0.1.32.19990113115720.00697868@172.16.1.10> X-Sender: srikanth@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 13 Jan 1999 11:57:20 +0500 To: ietf-radius@livingston.com From: Nayani Srikanth Subject: (radius) Class Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Nayani Srikanth Sir/Madam, One of the radius attributes is Class(25) . This is a token that is given by the Radius server when a Access-Request is accepted . It is indicated (in Rfc 2138) that the same value should be sent to the Radius server when sending a Accounting -Request packet. I have two questions: 1) Is the same Class used to match Accounting start and stop requests by the Radius server. 2)How is this value differnt from Accounting-Session-ID attribue(44). Thanks in advance, Srikanth. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 13 12:11:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA12137 for ; Wed, 13 Jan 1999 12:11:50 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA24269; Wed, 13 Jan 1999 09:03:24 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA21709 for ietf-radius-outgoing; Wed, 13 Jan 1999 09:04:42 -0800 (PST) From: Dnsefjk@earthlink.net Date: Wed, 13 Jan 1999 08:58:06 -0800 (PST) Message-Id: <199901131658.IAA14683@crow.prod.itd.earthlink.net> To: travel@aol.com Subject: (radius) Home Based Biz! Not MLM! No Selling! 2-4k per wk!! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dnsefjk@earthlink.net Look, we don't want to waste your time....or ours. If you are 100% SERIOUS about earning a solid, six-figure income from home, and you're not afraid to work for it WE CAN HELP YOU! * NOT MLM or GLOBAL * Completely Legitimate Home-Based Business * Registered with D&B and BBB, traded on stock exchange * Professional Training and Fantastic Support * Work Entirely From Home (no personal selling) Grab your share of the 3.4 Trillion Dollar Travel Industry NOW! CALL TOLL FREE 1-888-248-6736 (24 Hour Recorded Message) To be removed from our mailing list simply respond to: whyme90@hotmail.com Any vulgarity will be filtered and your request for removal will deleted. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 13 13:54:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA15475 for ; Wed, 13 Jan 1999 13:54:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA28439; Wed, 13 Jan 1999 10:40:43 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA03995 for ietf-radius-outgoing; Wed, 13 Jan 1999 10:42:41 -0800 (PST) Date: Wed, 13 Jan 1999 13:50:34 -0500 Message-Id: <199901131850.NAA00927@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: (radius) Accounting information in Access-Request packets? Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok I was wondering about the validity of having accounting attributes in an Access-Request packet. RFC 2138 and 2139 are silent on this topic, though 2139 does say that RFC 2138 attributes may be in an Accounting-Request packet. The reason behind this question is that Ascend NASes send Acct-Session-Id in an Access-Request. I can see the benefit to this behaviour, but I'm left wondering about the ambiguity of the spec. Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 13 22:04:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA23842 for ; Wed, 13 Jan 1999 22:04:17 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA22338; Wed, 13 Jan 1999 18:55:47 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA23789 for ietf-radius-outgoing; Wed, 13 Jan 1999 18:57:15 -0800 (PST) Message-ID: <369D5B5D.D51298FD@iea-software.com> Date: Wed, 13 Jan 1999 18:50:05 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Nayani Srikanth CC: ietf-radius@livingston.com Subject: Re: (radius) Class References: <3.0.1.32.19990113115720.00697868@172.16.1.10> 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." Nayani Srikanth wrote: > > One of the radius attributes is Class(25) . This is a token that is > given by the Radius server when a Access-Request is accepted . It is > indicated (in Rfc 2138) that the same value should be sent to the Radius > server when sending a Accounting -Request packet. > > I have two questions: > > 1) Is the same Class used to match Accounting start and stop requests > by the Radius server. It could be, but you should use the Acct-Session-ID to match them (see below). > 2)How is this value differnt from Accounting-Session-ID attribue(44). Its created by the RADIUS SERVER, not the RADIUS client. For example, the authenticating server may NOT be the accounting server, in which case it might not be that useful. However, it can allow for sophisticated tranaction management. We've been looking at this heavily, but I am curious as to what clients DO support the class and state attributes? -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 13 23:39:46 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA26458 for ; Wed, 13 Jan 1999 23:39:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA25556; Wed, 13 Jan 1999 20:31:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA28321 for ietf-radius-outgoing; Wed, 13 Jan 1999 20:33:24 -0800 (PST) Message-ID: <369D6F01.2A64ED2C@livingston.com> Date: Wed, 13 Jan 1999 20:13:53 -0800 From: Thomas Kinnen Organization: Lucent RABU X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: Re: (radius) Class References: <3.0.1.32.19990113115720.00697868@172.16.1.10> <369D5B5D.D51298FD@iea-software.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Thomas Kinnen "Dale E. Reed Jr." wrote: > We've been looking at this heavily, but I am curious as to what > clients DO support the class and state attributes? The Portmasters with ComOS 3.8 or better support the Class attribute We make use if it with Radius ABM. ---- Thomas C Kinnen - "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer" - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 14 01:38:55 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA27481 for ; Thu, 14 Jan 1999 01:38:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id WAA27766; Wed, 13 Jan 1999 22:30:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA03283 for ietf-radius-outgoing; Wed, 13 Jan 1999 22:31:33 -0800 (PST) Message-Id: <3.0.1.32.19990114120257.0069e1cc@172.16.1.10> X-Sender: srikanth@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Thu, 14 Jan 1999 12:02:57 +0500 To: "Dale E. Reed Jr." From: Nayani Srikanth Subject: Re: (radius) Class Cc: ietf-radius@livingston.com In-Reply-To: <369D5B5D.D51298FD@iea-software.com> References: <3.0.1.32.19990113115720.00697868@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Nayani Srikanth Sir/Madam, I have extensions to my previous qualms. 1) Is it essential for the accounting request to go to the same radius server which has given a access-accept ? 2) If so how will the Radius client keep track of the server which gave the access-accept and insist on response for accounting - request from the same radius server. In such a scenario what are the roles played by Class attribute(25) and Accounting session ID attribute. Thanks in advance, Srikanth. At 06:50 PM 1/13/99 -0800, you wrote: >Nayani Srikanth wrote: >> >> One of the radius attributes is Class(25) . This is a token that is >> given by the Radius server when a Access-Request is accepted . It is >> indicated (in Rfc 2138) that the same value should be sent to the Radius >> server when sending a Accounting -Request packet. >> >> I have two questions: >> >> 1) Is the same Class used to match Accounting start and stop requests >> by the Radius server. > >It could be, but you should use the Acct-Session-ID to match them (see >below). > >> 2)How is this value differnt from Accounting-Session-ID attribue(44). > >Its created by the RADIUS SERVER, not the RADIUS client. For example, >the authenticating server may NOT be the accounting server, in which >case it might not be that useful. However, it can allow for >sophisticated tranaction management. > >We've been looking at this heavily, but I am curious as to what >clients DO support the class and state attributes? > >-- >Dale E. Reed Jr. (daler@iea-software.com) >_________________________________________________________________ > IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs > Internet Solutions for Today | http://www.iea-software.com > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 14 04:24:45 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA04594 for ; Thu, 14 Jan 1999 04:24: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 BAA01361; Thu, 14 Jan 1999 01:12:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id BAA09790 for ietf-radius-outgoing; Thu, 14 Jan 1999 01:11:21 -0800 (PST) Date: Thu, 14 Jan 99 05:49 CDT To: bajoehai61@corona.laa.com.au From: bajoehai61@corona.laa.com.au (broyeure) Comments: Authenticated sender is Subject: (radius) .1 Million Mailing. Message-Id: <19990114498JAA50495@transweopro.cl> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: bajoehai61@corona.laa.com.au (broyeure) LOW COST ADVERTISING SERVICES & PROMOTIONAL PACKAGES = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = SERVICES: 1)CO-OP EMAILING: We send your 5-line message to 1 million addresses on the Net...$75 2)CLASSIFIED ADVERTISING: We submit your ad to 150 top free classified sites globally...$15 3)SEARCH ENGINE SUBMISSION: We submit your site to 1000+ s. engines, directories, FFA, ...$15 4)SUBMIT ELECTRONIC TRADE OPPORTUNITY: Hundreds of thousands of global traders to see it!....$15 5)SEARCH FOR BUYERS IN 100 COUNTRIES: We request Chamber of Commerce to assist you seek buyers, agents, reps,........................................................$15 -------------------------------------------------------------------- PROMOTIONAL PACKAGE (A): CO-OP EMAILING of your 5-line message to 1 million addresses all over the Net. PLUS any one of the above services (from #2- 5). TOTAL COST OF PACKAGE (A): only US$80.00 . Save $10 -------------------------------------------------------------------- PROMOTIONAL PACKAGE (B): CO-OP E-MAILING: your 5-line message to 1 million addresses all over the Net. PLUS any two of the above services (from #2 - 5) TOTAL COST OF PACKAGE (B) only US$ 90.00 . Save $15 -------------------------------------------------------------------- PROMOTIONAL PACKAGE (C): All of the above 5 services (#1-5). Only $99. Save $36 -------------------------------------------------------------------- PROMOTIONAL PACKAGE (D): TWO AUTOMATIC CLASSIFIED AD SUBMITTING SOFTWARES: buy one for US$60, get the other FREE! Together , they submit your ad, automatically and in minutes, to 150 of the top internet free classified sites. Once you buy them, you can use them regularly to place those free ads! This price is valid only with this offer! TOTAL COST OF PACKAGE (D) only US$60.00 . Save $60! Above promotional packages expire soon! You need to order Now! Act today! -------------------------------------------------------------------- ORDER FORM (Mail or fax order with payment. Once I receive them, I shall email you the formal Submission Form for you to fill in and mail/fax back. I shall then process your ordered services/packages!) __Services:___1 , ____2, ____3, _____4, _____5. Total ___x$15 = $_____ __Package (A) :with service #___ $80.0 __Package (B):with service #___,#____ 90.00 __Package (C): with all 5 services (#1-5) 99.00 __Package (D): two auto ad submitting softwares 60.00 I enclose payment by: ___cash, ___Check, ___Money Order___Visa____M/Card. Charge my credit card #__________________________________ Expiry Date:________ Signature:__________________________ Name:__________________________________________ Address: _______________________________________ ________________________________________ City:_________________State:___________Zip_________ E-Mail (Required.Please type or PRINT!): _________________________________________________ Mail/Fax above to: Al Jebaly, 3668 161st Terrace N., Loxahatchee, Fl 33470 USA Fax (561) 792-6175. Phone (561) 792-2097 - - - - - - - - - - - - - - Removal from lists, go to http://3520611773/remove/ 21d56g4d - - - - - - - - - - - - - - - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 14 10:08:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA06784 for ; Thu, 14 Jan 1999 10:08:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA05885; Thu, 14 Jan 1999 06:56:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA21182 for ietf-radius-outgoing; Thu, 14 Jan 1999 06:54:03 -0800 (PST) Message-Id: <3.0.5.32.19990114095254.038c8d20@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 14 Jan 1999 09:52:54 -0500 To: Nayani Srikanth From: Dave Mitton Subject: Re: (radius) Class Cc: ietf-radius@livingston.com In-Reply-To: <3.0.1.32.19990114120257.0069e1cc@172.16.1.10> References: <369D5B5D.D51298FD@iea-software.com> <3.0.1.32.19990113115720.00697868@172.16.1.10> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton At 12:02 PM 1/14/99 +0500, Nayani Srikanth wrote: >Sir/Madam, > I have extensions to my previous qualms. > > 1) Is it essential for the accounting request to go to the same > radius server which has given a access-accept ? Not by the protocol/RFC, But it may be an essential operational requirement because of the benefits that you may derive from from that. Several RADIUS servers use the combination of authentication information and accounting messages to attempt to track the real time status of the NASes, and do resource managmement. For example our BaySecure Access Control (BSAC) server (Funk SBR) has this requirement. If you do not choose to meet that requirement, you simply don't get the feature. > 2) If so how will the Radius client keep track of the server which > gave the access-accept and insist on response for accounting - > request from the same radius server. In such a scenario what > are the roles played by Class attribute(25) and Accounting > session ID attribute. Most RADIUS clients are real dumb and only talk to one RADIUS server most of the time. The transferance of state in the case of failover is another RADIUS black art. I'm not aware of a client that is not this simply deterministic (but I publicly make these kinds of statements to draw out evidence to the contrary.) If you are working with some sort of distributed database, then you will have to tie your RADIUS servers in on the game. Dave. > >Thanks in advance, >Srikanth. > > > >At 06:50 PM 1/13/99 -0800, you wrote: >>Nayani Srikanth wrote: >>> >>> One of the radius attributes is Class(25) . This is a token that is >>> given by the Radius server when a Access-Request is accepted . It is >>> indicated (in Rfc 2138) that the same value should be sent to the Radius >>> server when sending a Accounting -Request packet. >>> >>> I have two questions: >>> >>> 1) Is the same Class used to match Accounting start and stop requests >>> by the Radius server. >> >>It could be, but you should use the Acct-Session-ID to match them (see >>below). >> >>> 2)How is this value differnt from Accounting-Session-ID attribue(44). >> >>Its created by the RADIUS SERVER, not the RADIUS client. For example, >>the authenticating server may NOT be the accounting server, in which >>case it might not be that useful. However, it can allow for >>sophisticated tranaction management. >> >>We've been looking at this heavily, but I am curious as to what >>clients DO support the class and state attributes? >> >>-- >>Dale E. Reed Jr. (daler@iea-software.com) >>_________________________________________________________________ >> IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs >> Internet Solutions for Today | http://www.iea-software.com >> >> > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton 978-670-8888 Main, [ESN: 248-4570] Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Networks, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 14 11:33:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA09660 for ; Thu, 14 Jan 1999 11:33: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 IAA08602; Thu, 14 Jan 1999 08:17:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA28227 for ietf-radius-outgoing; Thu, 14 Jan 1999 08:16:06 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Thu, 14 Jan 1999 17:05:46 +0200 MR-Received: by mta BTMV98; Relayed; Thu, 14 Jan 1999 17:05:46 +0200 MR-Received: by mta BTMA06; Relayed; Thu, 14 Jan 1999 17:05:19 +0200 Disclose-recipients: prohibited Date: Thu, 14 Jan 1999 17:05:46 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) Class In-reply-to: <3.0.5.32.19990114095254.038c8d20@fred.xylogics.com> To: ietf-radius Message-id: <0546051714011999/A35133/BTMV98/11D174452D00*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D174452D00 X400-MTS-identifier: [;0546051714011999/A35133/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT There has been discussion on this mailing list before about the use of Class and Acct-Session-Id. I will attempt to summarise (a and b). a) The Class attribute is given a value by the RADIUS authentication server. This value MUST be given to the RADIUS accounting server by the NAS. Typical uses are: - the authentication server passes additional info to the accounting server (NAS is transparent) - used to link Access-Requests to Accounting-Requests (keeping session state in the RADIUS (proxy) server for e.g. resource management) - as a grouping criterium when generating statistics (SNMP) - used to send class-based state info from NAS to RADIUS server (proprietary) b) The Acct-Session-Id attribute is given a value by the NAS, and MUST be sent in Accounting-Requests. Some NASses also send the Acct-Session-Id in Access-Requests. If also sent in Access-Request, typical uses are: - used to link Access-Requests to Accounting-Requests (keeping session state in the RADIUS (proxy) server for e.g. resource management) In my opinion, Acct-Session-Id should be sent in Access-Requests to allow a proxy server to keep session state, while the Class atrribute can still be used for grouping sessions and producing class-based statistics. If session state is to be maintained (either by Class or Session-Id), the authentication and accounting server will need to be able to synchronise. They can be the same server, but this is not required. The NAS should not be required to send the Accounting-Request to the server which sent the Access-Accept, and I have not seen any NAS do that yet. I hope this answers the questions. Regards, Marc. [previous text snipped a bit] >> 1) Is it essential for the accounting request to go to the same >> radius server which has given a access-accept ? >> 2) If so how will the Radius client keep track of the server which >> gave the access-accept and insist on response for accounting - >> request from the same radius server. In such a scenario what >> are the roles played by Class attribute(25) and Accounting >> session ID attribute. >>>> One of the radius attributes is Class(25) . This is a token that is >>>> given by the Radius server when a Access-Request is accepted . It is >>>> indicated (in Rfc 2138) that the same value should be sent to the Radius >>>> server when sending a Accounting -Request packet. >>>> >>>> I have two questions: >>>> >>>> 1) Is the same Class used to match Accounting start and stop requests >>>> by the Radius server. >>> >>>It could be, but you should use the Acct-Session-ID to match them (see >>>below). >>> >>>> 2)How is this value differnt from Accounting-Session-ID attribue(44). >>> - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 14 12:05:43 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA11260 for ; Thu, 14 Jan 1999 12:05:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA10453; Thu, 14 Jan 1999 08:51:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA02491 for ietf-radius-outgoing; Thu, 14 Jan 1999 08:51:04 -0800 (PST) Message-ID: <005e01be3fdd$d448dda0$c889e9cc@titanium.techapp.com> From: "Russell J. LeBar" To: Subject: Re: (radius) Class Date: Thu, 14 Jan 1999 10:49:09 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Russell J. LeBar" But you should always have a primary and a secondary RADIUS server to provide redundancy. Which means there is always a chance that the auth* is done by one server but the accounting goes to another. Do you assume that this rarely happens and thus the problems it creates are trivial? -----Original Message----- From: Dave Mitton >At 12:02 PM 1/14/99 +0500, Nayani Srikanth wrote: >>Sir/Madam, >> I have extensions to my previous qualms. >> >> 1) Is it essential for the accounting request to go to the same >> radius server which has given a access-accept ? > > Not by the protocol/RFC, But it may be an essential operational >requirement because of the benefits that you may derive from from that. > Several RADIUS servers use the combination of authentication information >and accounting messages to attempt to track the real time status of the >NASes, and do resource managmement. >For example our BaySecure Access Control (BSAC) server (Funk SBR) has this >requirement. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 06:14:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA04162 for ; Fri, 15 Jan 1999 06:14:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA14227; Fri, 15 Jan 1999 03:06:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA20823 for ietf-radius-outgoing; Fri, 15 Jan 1999 03:05:16 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Fri, 15 Jan 1999 11:43:47 +0200 MR-Received: by mta BTMV98; Relayed; Fri, 15 Jan 1999 11:58:57 +0200 MR-Received: by mta BTMA06; Relayed; Fri, 15 Jan 1999 11:58:32 +0200 Disclose-recipients: prohibited Date: Fri, 15 Jan 1999 11:43:47 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) Class In-reply-to: <005e01be3fdd$d448dda0$c889e9cc@titanium.techapp.com> To: ietf-radius Message-id: <5047431115011999/A20551/BTMV98/11D17AEB2B00*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D17AEB2B00 X400-MTS-identifier: [;5047431115011999/A20551/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT We have a proxy implementation on a cluster platform of typically two machines. If authentication and accounting of a particular session are received on the same machine, there is no problem. If they are received on different machines, they exchange the relevant state information, and one will act as the MASTER state holder. This is just to illustrate that the way the servers keep state is independant of the RADIUS protocol, and is strictly a server implementation issue. What _is_ relevant to RADIUS is the means to link all requests of a particular session. As explained in a previous mail, this can be done with Class or Acct-Session-Id, but the RADIUS RFCs do not address this issue, hence the recurring discussions and interop issues. >But you should always have a primary and a secondary RADIUS server to >provide redundancy. Which means there is always a chance that the auth* is >done by one server but the accounting goes to another. Do you assume that >this rarely happens and thus the problems it creates are trivial? > >-----Original Message----- >From: Dave Mitton > > >>At 12:02 PM 1/14/99 +0500, Nayani Srikanth wrote: >>>Sir/Madam, >>> I have extensions to my previous qualms. >>> >>> 1) Is it essential for the accounting request to go to the same >>> radius server which has given a access-accept ? >> >> Not by the protocol/RFC, But it may be an essential operational >>requirement because of the benefits that you may derive from from that. >> Several RADIUS servers use the combination of authentication information >>and accounting messages to attempt to track the real time status of the >>NASes, and do resource managmement. >>For example our BaySecure Access Control (BSAC) server (Funk SBR) has this >>requirement. > > >- >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 Jan 15 08:07:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA04762 for ; Fri, 15 Jan 1999 08:07:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id EAA15224; Fri, 15 Jan 1999 04:59:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA23939 for ietf-radius-outgoing; Fri, 15 Jan 1999 05:01:42 -0800 (PST) Message-Id: <3.0.2.32.19990115140317.01dca970@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 15 Jan 1999 14:03:17 +0100 To: Carl Rigney , ietf-radius@livingston.com From: Harald Tveit Alvestrand Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <199901070655.WAA17326@server.livingston.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Tveit Alvestrand I'll reiterate what I told Glen in private mail: A worry has been expressed to me that this set of drafts describe how to set up a tunnel between a corporate firewall and a NAS box. This would make the NAS box part of the trust boundary of the corporation, and expose the NAS box operator to heavy liability and operational problems. Some possible responses: - The protocol does not require the endpoints of a tunnel to be in any particular place. The tunnel endpoint could be at the connected system, where it ought to be. Counter: How would the NAS box tell the connected system to set up a tunnel, if there is no such function in its connection protocol? Anyway, if that's a recommended mode, it should be documented. - Tunnels aren't just for security. There might be other reasons to tunnel. Counter: But if you use tunnels for security, you should be warned that you can't use this feature. I certainly don't understand this protocol well enough to see what's possible, what's reasonable and what's obvious. But I know that I didn't feel like I understood the problem and the Right Way to solve it after reading the documents. And that I don't like. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:44:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00779 for ; Fri, 15 Jan 1999 19:44:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13800 for ; Fri, 15 Jan 1999 16:41:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA19075 for ietf-radius-outgoing; Fri, 15 Jan 1999 14:31:07 -0800 (PST) Date: Fri, 15 Jan 99 14:26:56 PST From: William "Chops" Westfield To: "Dale E. Reed Jr." Cc: Nayani Srikanth , ietf-radius@livingston.com Subject: Re: (radius) Class In-Reply-To: Your message of Wed, 13 Jan 1999 18:50:05 -0800 Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William "Chops" Westfield We've been looking at this heavily, but I am curious as to what clients DO support the class and state attributes? I would think it's quite common. The seminal radius servers used both, IIRC (Livinsgton's server used state for challenge/response, Merit made heavy use of class (at least, they made us fix bugs there...)) BillW cisco - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:44:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00781 for ; Fri, 15 Jan 1999 19:44:46 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13808 for ; Fri, 15 Jan 1999 16:41:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA17997 for ietf-radius-outgoing; Fri, 15 Jan 1999 14:23:48 -0800 (PST) Date: Fri, 15 Jan 99 14:19:56 PST From: William "Chops" Westfield To: Dave Mitton Cc: Carl Rigney , ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: Your message of Fri, 15 Jan 1999 15:59:26 -0500 Message-ID: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: William "Chops" Westfield > A worry has been expressed to me that this set of drafts describe > how to set up a tunnel between a corporate firewall and a NAS box. > This would make the NAS box part of the trust boundary of the > corporation, and expose the NAS box operator to heavy liability and > operational problems I have problems with this concern. RADIUS makes the NAS a trust boundary as it is. What makes this any different? This sort of strengthens the current house of cards, or it's just more of the same. What's the real problem here? I agree completely. A NAS is by definition part of the "trust boundry" of a corporation - I don't see how it matters if your incoming users come in through tunnels, or over POTS lines... BillW - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:44:54 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00783 for ; Fri, 15 Jan 1999 19:44:47 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13815 for ; Fri, 15 Jan 1999 16:41:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA16931 for ietf-radius-outgoing; Fri, 15 Jan 1999 14:15:49 -0800 (PST) Message-ID: From: "Nelson, David" To: "'ietf-radius@livingston.com'" Subject: FW: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Fri, 15 Jan 1999 17:11:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Mike O'Dell writes: > so as a manufacturer of NAS equipment, is Bay prepared to > assume the liability in the ensuing lawsuit (eg, indemnify > the ISP using your hardware) when SEC-critical financial > information (being carried because - "it's safe - it's > encrypted!") from company A is disclosed to company B??? > In response, I observe that: 1.) there are many things in life whose use requires judgment and are not inherently "safe", 2.) any idiot can sue anyone else on any given day, usually with the complicity of a greedy lawyer; it doesn't mean the case has any merit, 3.) many foolish things have been done and many wise things have been left undone simply because of sabre-rattling threats of litigation, 4.) by this logic no one would manufacture or sell inherently dangerous, but useful, items such as automobiles, lawn mowers, snow blowers, kitchen knives and security software, and 5.) yes, many manufacturers do carry product liability insurance. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:44:54 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00787 for ; Fri, 15 Jan 1999 19:44:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13824 for ; Fri, 15 Jan 1999 16:41:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA20440 for ietf-radius-outgoing; Fri, 15 Jan 1999 14:41:36 -0800 (PST) Message-ID: <009b01be40d8$486bf1e0$51f41fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Harald Tveit Alvestrand" , "Beadles, Mark A." , , "Carl Rigney" Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Fri, 15 Jan 1999 14:42:04 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0098_01BE4095.38172BE0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_0098_01BE4095.38172BE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand writes: >At 13:52 15.01.99 -0500, Beadles, Mark A. wrote: >> >>If the NAS box operator is not willing to accept this liability and >>operational >>issues, then the NAS box operator should not offer this type of service. >>That >>is a business question, not a protocol question. >> >>On the other hand, there are service providers who are willing to accept the >>liability and operational issues, and customers who are willing to accept >>the >>redrawing of trust boundaries in order to receive the functionality desired. >> >>We cannot let protocols dictate business models. We must make our protocols >>flexible enough to accommodate any reasonable business model. > >Agreed. I care about quality of documentation and "fair warning", not about >saving the world from itself. > >IF (the security section of?) this draft set discusses the diverse models >for deployment and the dangers they incur to the point where I can see at >once what I had to have pointed out to me, I have no real problem with >shipping it; sort of "This is a gun. That is your foot. If you put your >finger here and pull, your foot will not be terribly useful." Wow! A well-reasoned, intelligent argument. > >Or to use another metaphor: I don't want to lower the temperature of >McDonald's coffee (it's bad enough as it is), I want to make sure people >know it's hot. > >If possible. I think it's possible. I will revise the security considerations section of the attributes draft again to point out these concerns. Are there any others? > > Harald A > >-- >Harald Tveit Alvestrand, Maxware, Norway >Harald.Alvestrand@maxware.no > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_0098_01BE4095.38172BE0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19990115T224204Z END:VCARD ------=_NextPart_000_0098_01BE4095.38172BE0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:44:55 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00790 for ; Fri, 15 Jan 1999 19:44:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13833 for ; Fri, 15 Jan 1999 16:41:53 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA24217 for ietf-radius-outgoing; Fri, 15 Jan 1999 10:54:41 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF602F@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Harald Tveit Alvestrand'" , ietf-radius@livingston.com, Carl Rigney Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Fri, 15 Jan 1999 13:52:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Harald Tveit Alvestrand [mailto:Harald@Alvestrand.no] >A worry has been expressed to me that this set of drafts describe how to >set up a tunnel between a corporate firewall and a NAS box. >This would make the NAS box part of the trust boundary of the corporation, >and expose the NAS box operator to heavy liability and operational problems. If the NAS box operator is not willing to accept this liability and operational issues, then the NAS box operator should not offer this type of service. That is a business question, not a protocol question. On the other hand, there are service providers who are willing to accept the liability and operational issues, and customers who are willing to accept the redrawing of trust boundaries in order to receive the functionality desired. We cannot let protocols dictate business models. We must make our protocols flexible enough to accommodate any reasonable business model. Traditionally, a strict demarcation has been seen between the customer's network and the service provider's network, and neither party has trusted the other. This model is changing, there are now service providers willing to take on the greater operational burden, and customers willing to expose themselves to greater calculated risk. The functionality described in these drafts is absolutely needed, and yes, one of the areas of application WILL be tunneling between a corporate firewall and a NAS box. I agree that this should only be undertaken when both parties are fully aware of the risks inherent in this. I would be happy with wording that stated, basically, that creating a tunnel between a NAS box and a customer gateway can result in a connection that crosses trust boundaries, and as such, should only be done when a thorough security analysis has been performed. + Mark Anthony Beadles + MCI WorldCom Advanced Networks + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:44:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00788 for ; Fri, 15 Jan 1999 19:44:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13830 for ; Fri, 15 Jan 1999 16:41:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA07105 for ietf-radius-outgoing; Fri, 15 Jan 1999 12:59:55 -0800 (PST) Message-Id: <3.0.5.32.19990115155926.00ce8100@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 15 Jan 1999 15:59:26 -0500 To: Carl Rigney , ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton (Harald; meant to send this to the list not just you) At 02:03 PM 1/15/99 +0100, you wrote: >I'll reiterate what I told Glen in private mail: > >A worry has been expressed to me that this set of drafts describe how to >set up a tunnel between a corporate firewall and a NAS box. >This would make the NAS box part of the trust boundary of the corporation, >and expose the NAS box operator to heavy liability and operational problems. > I have problems with this concern. RADIUS makes the NAS a trust boundary as it is. What makes this any different? This sort of strengthens the current house of cards, or it's just more of the same. What's the real problem here? Is someone is just waking up, or thinks they have a charter monopoly on solutions? I'm having real reality check problems here. Dave. >Some possible responses: > >- The protocol does not require the endpoints of a tunnel to be in any > particular place. The tunnel endpoint could be at the connected system, > where it ought to be. > > Counter: How would the NAS box tell the connected system to set up a > tunnel, if there is no such function in its connection protocol? > Anyway, if that's a recommended mode, it should be documented. > >- Tunnels aren't just for security. There might be other reasons to tunnel. > > Counter: But if you use tunnels for security, you should be warned that > you can't use this feature. > >I certainly don't understand this protocol well enough to see what's possible, >what's reasonable and what's obvious. > >But I know that I didn't feel like I understood the problem and the Right >Way to solve it after reading the documents. > >And that I don't like. > > Harald A > >-- >Harald Tveit Alvestrand, Maxware, Norway >Harald.Alvestrand@maxware.no > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton 978-670-8888 Main, [ESN: 248-4570] Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Networks, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:44:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00789 for ; Fri, 15 Jan 1999 19:44:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13827 for ; Fri, 15 Jan 1999 16:41:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA13032 for ietf-radius-outgoing; Fri, 15 Jan 1999 13:49:32 -0800 (PST) Message-ID: <006a01be40d1$01faaaa0$51f41fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Harald Tveit Alvestrand" , "Carl Rigney" , Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Fri, 15 Jan 1999 13:49:01 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0061_01BE408D.CE96AC60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_0061_01BE408D.CE96AC60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand writes: >I'll reiterate what I told Glen in private mail: > >A worry has been expressed to me that this set of drafts describe how to >set up a tunnel between a corporate firewall and a NAS box. That's an accurate representation, I think. >This would make the NAS box part of the trust boundary of the corporation, >and expose the NAS box operator to heavy liability and operational problems. One thing that I don't understand is why that is an IETF (protocol, not political ;-) problem. There are many service providers willing to accept those risks and responsibilities, and many that are rolling out that type of service now. > >Some possible responses: > >- The protocol does not require the endpoints of a tunnel to be in any > particular place. The tunnel endpoint could be at the connected system, > where it ought to be. > > Counter: How would the NAS box tell the connected system to set up a > tunnel, if there is no such function in its connection protocol? > Anyway, if that's a recommended mode, it should be documented. > >- Tunnels aren't just for security. There might be other reasons to tunnel. > > Counter: But if you use tunnels for security, you should be warned that > you can't use this feature. That's not necessarily true: if you rely upon the NAS to start e.g. an IPSec tunnel for you _and_ do not prpvide any other protection for your sensitive traffic (TLS, Kerberos, PGP, etc.), then there is the risk that the fabled "evil ISP" would sniff your traffic and cause horrible things to happen (note that this is true in _any_ security gateway <==> security gateway scenario). OTOH, both L2TP and PPTP allow the PPP client to negotiate directly with the tunnel server, so the client can insist upon PPP encryption. > >I certainly don't understand this protocol well enough to see what's possible, >what's reasonable and what's obvious. > >But I know that I didn't feel like I understood the problem and the Right >Way to solve it after reading the documents. > >And that I don't like. > > Harald A > >-- >Harald Tveit Alvestrand, Maxware, Norway >Harald.Alvestrand@maxware.no > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_0061_01BE408D.CE96AC60 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19990115T214900Z END:VCARD ------=_NextPart_000_0061_01BE408D.CE96AC60-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:58:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00778 for ; Fri, 15 Jan 1999 19:44: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 QAA13796 for ; Fri, 15 Jan 1999 16:41:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA13506 for ietf-radius-outgoing; Fri, 15 Jan 1999 13:53:46 -0800 (PST) Message-Id: To: "Glen Zorn" cc: "Harald Tveit Alvestrand" , "Carl Rigney" , ietf-radius@livingston.com, mo@UU.NET Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-reply-to: Your message of "Fri, 15 Jan 1999 13:49:01 PST." <006a01be40d1$01faaaa0$51f41fac@glennz-2.dns.microsoft.com> Date: Fri, 15 Jan 1999 16:53:26 -0500 From: "Mike O'Dell" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mike O'Dell" it is patently irresponsible to promulgate a protocol feature which is known to have *catastrophic* security implications -mo - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:58:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00780 for ; Fri, 15 Jan 1999 19:44:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13803 for ; Fri, 15 Jan 1999 16:41:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA12512 for ietf-radius-outgoing; Fri, 15 Jan 1999 13:44:33 -0800 (PST) Message-Id: To: Dave Mitton cc: Carl Rigney , ietf-radius@livingston.com, mo@UU.NET Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-reply-to: Your message of "Fri, 15 Jan 1999 15:59:26 EST." <3.0.5.32.19990115155926.00ce8100@fred.xylogics.com> Date: Fri, 15 Jan 1999 16:44:14 -0500 From: "Mike O'Dell" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mike O'Dell" handling crypto involves the exchange of bodily fluids a NAS doing crypto tunnels for multiple clients simultaneously raises the stakes exponentially, not to mention "creating an attractive nuisance" so as a manufacturer of NAS equipment, is Bay prepared to assume the liability in the ensuing lawsuit (eg, indemnify the ISP using your hardware) when SEC-critical financial information (being carried because - "it's safe - it's encrypted!") from company A is disclosed to company B??? -mo - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:58:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00782 for ; Fri, 15 Jan 1999 19:44:46 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13811 for ; Fri, 15 Jan 1999 16:41:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA15673 for ietf-radius-outgoing; Fri, 15 Jan 1999 14:07:15 -0800 (PST) Message-ID: <007b01be40d3$798fd8e0$51f41fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Mike O'Dell" Cc: "Harald Tveit Alvestrand" , "Carl Rigney" , , Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Fri, 15 Jan 1999 13:59:48 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0076_01BE408F.5034EF60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_0076_01BE408F.5034EF60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mike O'Dell writes: > >it is patently irresponsible to promulgate a protocol feature >which is known to have *catastrophic* security implications > > -mo > > What? ------=_NextPart_000_0076_01BE408F.5034EF60 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19990115T215947Z END:VCARD ------=_NextPart_000_0076_01BE408F.5034EF60-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:58:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00785 for ; Fri, 15 Jan 1999 19:44:47 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13818 for ; Fri, 15 Jan 1999 16:41:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA18085 for ietf-radius-outgoing; Fri, 15 Jan 1999 14:24:09 -0800 (PST) Message-Id: <3.0.2.32.19990115231315.01cb0e40@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 15 Jan 1999 23:13:15 +0100 To: "Beadles, Mark A." , ietf-radius@livingston.com, Carl Rigney From: Harald Tveit Alvestrand Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <9A74C89D6696D2118E500008C7BA7C56BF602F@wcomexch1.wcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Tveit Alvestrand At 13:52 15.01.99 -0500, Beadles, Mark A. wrote: > >If the NAS box operator is not willing to accept this liability and >operational >issues, then the NAS box operator should not offer this type of service. >That >is a business question, not a protocol question. > >On the other hand, there are service providers who are willing to accept the >liability and operational issues, and customers who are willing to accept >the >redrawing of trust boundaries in order to receive the functionality desired. > >We cannot let protocols dictate business models. We must make our protocols >flexible enough to accommodate any reasonable business model. Agreed. I care about quality of documentation and "fair warning", not about saving the world from itself. IF (the security section of?) this draft set discusses the diverse models for deployment and the dangers they incur to the point where I can see at once what I had to have pointed out to me, I have no real problem with shipping it; sort of "This is a gun. That is your foot. If you put your finger here and pull, your foot will not be terribly useful." Or to use another metaphor: I don't want to lower the temperature of McDonald's coffee (it's bad enough as it is), I want to make sure people know it's hot. If possible. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:58:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00786 for ; Fri, 15 Jan 1999 19:44:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13821 for ; Fri, 15 Jan 1999 16:41:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA16279 for ietf-radius-outgoing; Fri, 15 Jan 1999 14:11:45 -0800 (PST) Message-Id: <3.0.5.32.19990115171117.009c9a70@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 15 Jan 1999 17:11:17 -0500 To: "Mike O'Dell" From: Dave Mitton Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: Carl Rigney , ietf-radius@livingston.com, mo@UU.NET In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton This argument silly. a) Bay already supports the setup of L2TP tunnels (and BayDVS) using RADIUS. However no "crypto" or bodily fluids are involved. Because L2TP itself, last I looked at it, is not secure and does not require those things. At the moment, (and probably never will with this product) we do not support IPsec. A major ISP is using this technology today and outsourcing our corporate network national access with it. (well, actually they don't use RADIUS because they're still heavily into our old ACP protocol, but they could) b) Your second argument is incorrect, because we don't make those representations. Since it's not "secure", perhaps you are failing to see it's usefullness for other features. Level 3 tunnelling is very useful in solving IP address allocation and partioning issues. Other customers are using tunneling as a POP or access outsourcing facility. There is not much IPsec in practice yet. Dave. At 04:44 PM 1/15/99 -0500, Mike O'Dell wrote: > >handling crypto involves the exchange of bodily fluids > >a NAS doing crypto tunnels for multiple clients simultaneously >raises the stakes exponentially, not to mention >"creating an attractive nuisance" > >so as a manufacturer of NAS equipment, is Bay prepared to >assume the liability in the ensuing lawsuit (eg, indemnify >the ISP using your hardware) when SEC-critical financial >information (being carried because - "it's safe - it's >encrypted!") from company A is disclosed to company B??? > > -mo >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton 978-670-8888 Main, [ESN: 248-4570] Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Networks, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 19:58:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA00784 for ; Fri, 15 Jan 1999 19:44:47 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13791 for ; Fri, 15 Jan 1999 16:41:47 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA21381 for ietf-radius-outgoing; Fri, 15 Jan 1999 14:47:08 -0800 (PST) Date: Fri, 15 Jan 1999 17:46:46 -0500 (EST) From: Stuart A Barkley To: ietf-radius@livingston.com Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <9A74C89D6696D2118E500008C7BA7C56BF602F@wcomexch1.wcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Stuart A Barkley On Fri, 15 Jan 1999, Beadles, Mark A. wrote: > From: Harald Tveit Alvestrand [mailto:Harald@Alvestrand.no] > >A worry has been expressed to me that this set of drafts describe how to > >set up a tunnel between a corporate firewall and a NAS box. > >This would make the NAS box part of the trust boundary of the corporation, > >and expose the NAS box operator to heavy liability and operational > problems. > > If the NAS box operator is not willing to accept this liability and > operational issues, then the NAS box operator should not offer this > type of service. That is a business question, not a protocol > question. However the NAS operator may not understand the implications until it is too late. People often mistake the fact that something is published in a RFC as a statement that it is good and useful. They often don't understand the different statuses of RFCs and will seek RFC buzzword compatibility with everything published. > On the other hand, there are service providers who are willing to > accept the liability and operational issues, and customers who are > willing to accept the redrawing of trust boundaries in order to > receive the functionality desired. Where does this liability end? Can we (IETF or individual contributers) be considered liable because we make a (perceived) recommendation that this is acceptable behavior? > We cannot let protocols dictate business models. We must make our > protocols flexible enough to accommodate any reasonable business > model. Traditionally, a strict demarcation has been seen between > the customer's network and the service provider's network, and > neither party has trusted the other. This model is changing, there > are now service providers willing to take on the greater operational > burden, and customers willing to expose themselves to greater > calculated risk. As I see it, it isn't a necessary protocol. A client can do the tunneling themselves if that is necessary, there are existing protocols for this. A service provider can apply ip filtering to the NAS data if the customer wants to restrict access to only a single firewall entrance point (Compulsory Tunneling apparently being the only documented use of this functionality). > The functionality described in these drafts is absolutely needed, > and yes, one of the areas of application WILL be tunneling between a > corporate firewall and a NAS box. I agree that this should only be > undertaken when both parties are fully aware of the risks inherent > in this. It may be that I don't understand what the needs are for these protocols (L2TP, PPTP, L2F) as implemented at the NAS level. If tunneling is required can not the other end of the link do the necessary setup and thus be insured it is working to its own satisfaction? Can someone explain where such things are really necessary in a NAS environment? > I would be happy with wording that stated, basically, that creating > a tunnel between a NAS box and a customer gateway can result in a > connection that crosses trust boundaries, and as such, should only > be done when a thorough security analysis has been performed. I would be happier without any words at all. Then I don't need to keep explaining why it is bad and unneeded to people who only see that a new RFC has been published and feel the need to jump on the implementation bandwagon. On the other hand, if there is really some useful benefit I would like to understand what that is. -- Stuart A Barkley email: stuartb@uu.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 20:23:34 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02063 for ; Fri, 15 Jan 1999 20:23:33 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA12417; Fri, 15 Jan 1999 16:04:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA00696 for ietf-radius-outgoing; Fri, 15 Jan 1999 16:05:55 -0800 (PST) Date: Fri, 15 Jan 1999 19:05:31 -0500 (EST) From: Stuart A Barkley To: ietf-radius@livingston.com Subject: (radius) comment on draft-ietf-radius-tunnel-acct-02.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Stuart A Barkley Some comments on the tunneling drafts inspired by todays other comments to the list. I haven't given these drafts as much attention as they deserve or as I would like. draft-ietf-radius-tunnel-acct-02.txt says in part: > Network Working Group G. Zorn > Internet-Draft Microsoft Corporation > Updates: RFC 2139 D. Mitton > Category: Informational Bay Networks > September 1998 Note that draft-ietf-radius-tunnel-acct-02.txt is a draft for an informational RFC. The other related related draft RFCs are stated to be Standards Track and it could be incorrectly inferred that implementing the other RFCs requires also implementing this one. Radius Accounting was published as an information RFC nominally documenting existing practise. However, this status has been widely misunderstood with people thinking that there is a radius accounting standard. > 3. Motivation > > Many applications of tunneling protocols such as PPTP and L2TP involve > dial-up network access. Some, such as the provision of secure access to > corporate intranets via the Internet, are characterized by voluntary > tunneling: the tunnel is created at the request of the user for a spe- > cific purpose. Other applications involve compulsory tunneling: the > tunnel is created without any action from the user and without allowing > the user any choice in the matter. Examples of applications that might > be implemented using compulsory tunnels are Internet software upgrade > servers, software registration servers and banking services. This same text also appears in -auth-06 and imp-04. The text in imp-04 is a little more readable there since it is broken into smaller paragraphs. > These are > all services which, without compulsory tunneling, would probably be pro- > vided using dedicated networks or at least dedicated network access > servers (NAS), since they are characterized by the need to limit user > access to specific hosts. I question this last statement. Compulsory tunneling is not required for these functions and should not be implied as required for these functions. > Given the existence of widespread support for > compulsory tunneling, however, these types of services could be accessed > via any Internet service provider (ISP). Typically, ISPs providing a > service want to collect data regarding that service, for billing, net- > work planning, etc. > The most popular way to collect usage data in dial- > up networks today is by means of RADIUS Accounting. The use of RADIUS > Accounting allows dial-up usage data to be collected at a central loca- > tion, rather than stored on each NAS. It makes sense to use RADIUS > Accounting to collect usage data regarding tunneling, since RADIUS > Accounting has been widely implemented and was designed to carry this > type of information. I have major problems with this section. As noted above this is only an "Informational" RFC and so has no true authoritative status. People can chose to implement what they want. However, I don't like having such strong words encouraging support for radius accounting. It certainly is not used by at least one major ISP. The only reason it is popular is that we continue to allow confusing words like those above to be said about radius accounting. Its true radius accounting was designed to carry this information, however it is also true that as a transport mechanism it doesn't work in large scale networks and that the data transported according to the RFC is incomplete. > In order to provide this functionality, new RADIUS > attributes are needed to aid in the collation of tunnel usage data; this > document defines these attributes. In addition, several new values for > the Acct-Status-Type attribute are proposed. Specific recommendations > for, and examples of, the application of this attribute for the L2TP and > PPTP protocols can be found in draft-ietf-radius-tunnel-imp-XX.txt. > [...] > 5. New Acct-Status-Type Values This section then goes on to describe several new Acct-Status-Type values which can be sent inside the radius transport. I already have concerns with the existing radius accounting data model and these new Acct-Status-Type values continue a bad trend in system design. The accounting data transported inside the protocol needs to be complete in each accounting request and should be consistent between accounting requests. In order for these tunneling requests to be useful you need good assurance that all of the data gets to the accounting system. If accounting requests get lost somewhere you are left with a fairly incomplete mess. These requests need to have interim accounting support and both the interim and final requests should contain all required information. Timestamps are required inside the data separate from any transport protocol. Tunnel-Stop and Tunnel-Link-Stop should have distinct timestamps for all interesting times (at least the Start and End times). As a practical requirement outside the radius protocol family the NAS should have a well controlled clock from which to obtain timestamp information if either accurate logs or actual revenue invoicing are going to be derived from this data stream. -- Stuart A Barkley email: stuartb@uu.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 20:32:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02342 for ; Fri, 15 Jan 1999 20:32:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA14891; Fri, 15 Jan 1999 17:24:11 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA06804 for ietf-radius-outgoing; Fri, 15 Jan 1999 17:26:13 -0800 (PST) Message-Id: <3.0.2.32.19990116021936.009b78e0@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sat, 16 Jan 1999 02:19:36 +0100 To: "Glen Zorn" , "Beadles, Mark A." , , "Carl Rigney" From: Harald Tveit Alvestrand Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <009b01be40d8$486bf1e0$51f41fac@glennz-2.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Tveit Alvestrand At 14:42 15.01.99 -0800, Glen Zorn wrote: >Harald Tveit Alvestrand writes: >>Or to use another metaphor: I don't want to lower the temperature of >>McDonald's coffee (it's bad enough as it is), I want to make sure people >>know it's hot. >> >>If possible. > >I think it's possible. I will revise the security considerations section of >the attributes draft again to point out these concerns. Are there any >others? I certainly hope it's possible. I think you need a couple of subsections: - Deployment scenarios (where a tunnel can go, and how it gets there) - Threats that are appropriate to different scenarios - Available or needed protection mechanisms for each scenario I'd think that it would be best to post candidate text to the list before going to the bother of shipping a new draft; it's often easier to get people to read smaller pieces of text. Once you, I and the list believe we have something, I'll certainly ping our security ADs to see what they think about it before shipping it off to the Last Call. I'm sure there can be other concerns - I'd like to find a reviewer for it who has *somewhat* more RADIUS knowledge than I have, but isn't actively involved in it, to do a review & evaluation; any volunteers? Looking forward to going forward....I'm changing the status of the -auth draft on my tracking page to "New version expected", and the 2 others to "waiting for -auth". (see http://www.ops.ietf.org) Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 15 20:44:22 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA02638 for ; Fri, 15 Jan 1999 20:44:22 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA15429; Fri, 15 Jan 1999 17:36:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA07762 for ietf-radius-outgoing; Fri, 15 Jan 1999 17:38:55 -0800 (PST) Message-ID: <00bf01be40f1$0e62bb00$51f41fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Stuart A Barkley" , Subject: Re: (radius) comment on draft-ietf-radius-tunnel-acct-02.txt Date: Fri, 15 Jan 1999 17:39:23 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BC_01BE40AD.FD5E7B20" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_00BC_01BE40AD.FD5E7B20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Stuart A Barkley writes: >Some comments on the tunneling drafts inspired by todays other >comments to the list. I haven't given these drafts as much attention >as they deserve or as I would like. At least you didn't wait unitl _after_ last call... > >draft-ietf-radius-tunnel-acct-02.txt says in part: > >> Network Working Group G. Zorn >> Internet-Draft Microsoft Corporation >> Updates: RFC 2139 D. Mitton >> Category: Informational Bay Networks >> September 1998 > >Note that draft-ietf-radius-tunnel-acct-02.txt is a draft for an >informational RFC. The other related related draft RFCs are stated to >be Standards Track and it could be incorrectly inferred that >implementing the other RFCs requires also implementing this one. Only by people that don't understand the term "Informational"; the lack of dependency is precisely why there is more than one document. >Radius Accounting was published as an information RFC nominally >documenting existing practise. However, this status has been widely >misunderstood with people thinking that there is a radius accounting >standard. Presumably, the same people who would make the 'incorrect inference' mentioned above. I don't know what more could be done about this. Every Informational RFC contains as its first paragraph the folowing: Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. How much clearer can it get? There is a reason, I think, for this behavior, however. People are desperate for an accounting standard; since RADIUS is the only semi-reasonable approach we have provided, they grasp at the straw. Note that I said "semi-reasonable"; I agree that RADIUS accounting is seriously flawed. However, the RADIUS WG was barred from even attempting to fix it. > >> 3. Motivation >> >> Many applications of tunneling protocols such as PPTP and L2TP involve >> dial-up network access. Some, such as the provision of secure access to >> corporate intranets via the Internet, are characterized by voluntary >> tunneling: the tunnel is created at the request of the user for a spe- >> cific purpose. Other applications involve compulsory tunneling: the >> tunnel is created without any action from the user and without allowing >> the user any choice in the matter. Examples of applications that might >> be implemented using compulsory tunnels are Internet software upgrade >> servers, software registration servers and banking services. > >This same text also appears in -auth-06 and imp-04. The text in >imp-04 is a little more readable there since it is broken into smaller >paragraphs. > >> These are >> all services which, without compulsory tunneling, would probably be pro- >> vided using dedicated networks or at least dedicated network access >> servers (NAS), since they are characterized by the need to limit user >> access to specific hosts. > >I question this last statement. Compulsory tunneling is not required >for these functions and should not be implied as required for these >functions. I can't see any implication of "requirement" there. The sentence is merely an observation of how most of these applications have been implemented in the real-world, according to the authors. It is certainly possible to restrict network access through filters. In a network that contains more than one type (or even version of the same type) or NAS, filtering doesn't scale, however. Allow me to note that the first two example applications probably do not require that tunneled traffic be encrypted to be useful. > >> Given the existence of widespread support for >> compulsory tunneling, however, these types of services could be accessed >> via any Internet service provider (ISP). Typically, ISPs providing a >> service want to collect data regarding that service, for billing, net- >> work planning, etc. > >> The most popular way to collect usage data in dial- >> up networks today is by means of RADIUS Accounting. The use of RADIUS >> Accounting allows dial-up usage data to be collected at a central loca- >> tion, rather than stored on each NAS. It makes sense to use RADIUS >> Accounting to collect usage data regarding tunneling, since RADIUS >> Accounting has been widely implemented and was designed to carry this >> type of information. > Note that the quoted section is from . >I have major problems with this section. > >As noted above this is only an "Informational" RFC and so has no true >authoritative status. People can chose to implement what they want. >However, I don't like having such strong words encouraging support for >radius accounting. It certainly is not used by at least one major >ISP. UUNET? >The only reason it is popular is that we continue to allow >confusing words like those above to be said about radius accounting. So all the netops who use RADIUS accounting are innocent victims of IETF brainwashing who've been led down the primrose path? Considering the many ISPs that still support PAP years after it was officially renounced by the IETF (just for one example), I find it difficult to beleive that they are quite that easy to sway. In fact, if I were an ISP, I think that I would be extremely insulted by the patronizing tone of this steatement. In any case, the _real_ reason RADIUS accounting is popular is that there is _no_ alternative (other than turning your NASs into SNMP processors instead of access servers). > >Its true radius accounting was designed to carry this information, >however it is also true that as a transport mechanism it doesn't work >in large scale networks and that the data transported according to the >RFC is incomplete. This incompleteness, of course, is a good reason to kill efforts to complete it... > >> In order to provide this functionality, new RADIUS >> attributes are needed to aid in the collation of tunnel usage data; this >> document defines these attributes. In addition, several new values for >> the Acct-Status-Type attribute are proposed. Specific recommendations >> for, and examples of, the application of this attribute for the L2TP and >> PPTP protocols can be found in draft-ietf-radius-tunnel-imp-XX.txt. >> [...] >> 5. New Acct-Status-Type Values > >This section then goes on to describe several new Acct-Status-Type >values which can be sent inside the radius transport. I already have >concerns with the existing radius accounting data model and these new >Acct-Status-Type values continue a bad trend in system design. The >accounting data transported inside the protocol needs to be complete >in each accounting request and should be consistent between accounting >requests. In order for these tunneling requests to be useful you need >good assurance that all of the data gets to the accounting system. If >accounting requests get lost somewhere you are left with a fairly >incomplete mess. So is it the new attributes you don't like or the fact that they are carried over RADIUS? I'm confused... > >These requests need to have interim accounting support and both the >interim and final requests should contain all required information. > >Timestamps are required inside the data separate from any transport >protocol. Tunnel-Stop and Tunnel-Link-Stop should have distinct >timestamps for all interesting times (at least the Start and End >times). As a practical requirement outside the radius protocol family >the NAS should have a well controlled clock from which to obtain >timestamp information if either accurate logs or actual revenue >invoicing are going to be derived from this data stream. We are not talking about things that should happen outside RADIUS - this is the RADIUS WG. If you require an accurate, wall-clock-time clock in the NASs you buy, that's fine, but (as has been pointed out many times on this list) the provision of such clocks is not universal in NASs and we cannot assume their presence. >-- >Stuart A Barkley email: stuartb@uu.net > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_00BC_01BE40AD.FD5E7B20 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19990116T013922Z END:VCARD ------=_NextPart_000_00BC_01BE40AD.FD5E7B20-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Jan 16 14:55:45 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA16732 for ; Sat, 16 Jan 1999 14:55:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA27296; Sat, 16 Jan 1999 11:46:50 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA09081 for ietf-radius-outgoing; Sat, 16 Jan 1999 11:46:18 -0800 (PST) Message-ID: <002e01be4188$f6da1e40$51f41fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Stuart A Barkley" , Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Sat, 16 Jan 1999 11:46:50 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_002B_01BE4145.E757EA80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_002B_01BE4145.E757EA80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Stuart A Barkley writes: >I would be happier without any words at all. Then I don't need to >keep explaining why it is bad and unneeded to people who only see that >a new RFC has been published and feel the need to jump on the >implementation bandwagon. On the other hand, if there is really some >useful benefit I would like to understand what that is. I think that it would be more useful if you could explain to _us_ (since we obviously don't get it!) why the entire concept of compulsory tunneling is "bad and unneded". Preferably this explanation would take the form of clear, English sentences without references to either cryptography or metaphorical "fluids". Hint: "I don't like it" is _not_ helpful; neither is "If it becomes a standard, UUNET will have to do it and we don't want to". >-- >Stuart A Barkley email: stuartb@uu.net > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_002B_01BE4145.E757EA80 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19990116T194649Z END:VCARD ------=_NextPart_000_002B_01BE4145.E757EA80-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Jan 16 18:06:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17577 for ; Sat, 16 Jan 1999 18:06:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA00595; Sat, 16 Jan 1999 14:58:40 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA15760 for ietf-radius-outgoing; Sat, 16 Jan 1999 14:59:03 -0800 (PST) Message-Id: <3.0.2.32.19990117000028.024a7320@dokka.maxware.no> X-Sender: hta@dokka.maxware.no X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Sun, 17 Jan 1999 00:00:28 +0100 To: "Glen Zorn" , "Stuart A Barkley" , From: Harald Tveit Alvestrand Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <002e01be4188$f6da1e40$51f41fac@glennz-2.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Tveit Alvestrand At 11:46 16.01.99 -0800, Glen Zorn wrote: > >I think that it would be more useful if you could explain to _us_ (since we >obviously don't get it!) why the entire concept of compulsory tunneling is >"bad and unneded". Preferably this explanation would take the form of >clear, English sentences without references to either cryptography or >metaphorical "fluids". Hint: "I don't like it" is _not_ helpful; neither is >"If it becomes a standard, UUNET will have to do it and we don't want to". play it again, sam..... Let us see if I can understand what this thing actually does. NOTE: I *still* don't feel that I understand it, so feel free to correct me. When an end system connects to a NAS, and gets Internet connectivity, the end system is free to set up tunnels to anywhere it wants to, using any mechanism the service it connects to allows. For a PPP connection, it can use IP-in-IP tunnels, for instance. The list of tunnel technologies mentioned in -auth is: 1 Point-to-Point Tunneling Protocol (PPTP) [1] 2 Layer Two Forwarding (L2F) [2] 3 Layer Two Tunneling Protocol (L2TP) [3] 4 Ascend Tunnel Management Protocol (ATMP) [4] 5 Virtual Tunneling Protocol (VTP) [5] 6 IP Authentication Header in the Tunnel-mode (AH) [6] 7 IP-in-IP Encapsulation (IP-IP) [7] 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [8] 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [9] 10 Generic Route Encapsulation (GRE) [10] 11 Bay Dial Virtual Services (DVS) 12 IP-in-IP Tunneling [11] (BTW, this reminds me: Any such list means that it will get longer in the future. There is no IANA considerations section in this document, and I can't find any other mechanism whereby new identifiers are allocated. This must be fixed - see "IANA considerations" RFC) From the way L2TP is described, it seems to be intended for the scenario where all traffic from an end-system is going into the tunnel; L2TP is also strongly biased towads "not modifying the PPP-using end system", which means that L2TP tunnels will terminate at the NAS, not the end host. For the other technologies, both approaches may be possible. The scenario described where mandatory tunnelling is useful: "These are all services which, without compulsory tunneling, would probably be pro- vided using dedicated networks or at least dedicated network access servers (NAS), since they are characterized by the need to limit user access to specific hosts." Now, let's play this scenario: Someone dials into a NAS box. He presents an identifier, and authenticates, in order to use general Internet access (or corporate LAN access, or whatever). He then fires up his home banking application, installs software, or does something else that invokes one of these "dedicated" services. He's now supposed to DISCONNECT FROM THE INTERNET in order to use these "dedicated" services, which are provided over the SAME NETWORK?????? (note - I regularly keep chat sessions, extra Web browser windows and so on open and active while doing Web-based banking - my bank is just SLOW.....) This means that the usefulness of mandatory tunneling is limited to two cases (IMHO, of course): - The case where what is sent through the tunnel is the only thing the person CAN be doing at the moment (such as boot-time registration) - The case where what is sent through the tunnel is the only thing the person WANTS to be doing at the moment (such as secured corporate LAN access). The first one seems a very limited scope. The second one seems to be what this spec is aimed at, but I can't tell what situation is suited to both this and NAS termination of tunnels. What have I missed? Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Jan 16 18:27:46 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17625 for ; Sat, 16 Jan 1999 18:27:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA00969; Sat, 16 Jan 1999 15:20:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA17516 for ietf-radius-outgoing; Sat, 16 Jan 1999 15:21:16 -0800 (PST) Message-Id: To: "Glen Zorn" cc: "Stuart A Barkley" , ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-reply-to: Your message of "Sat, 16 Jan 1999 11:46:50 PST." <002e01be4188$f6da1e40$51f41fac@glennz-2.dns.microsoft.com> Date: Sat, 16 Jan 1999 18:20:58 -0500 From: "Mike O'Dell" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mike O'Dell" let me try on Stuart's behalf we believe it is *highly* irresponsible to standardize something which is extremely dangerous. there is no reason to do tunneling if you don't intend to encrypt the tunnel. otherwise, the tunnel accomplishes nothing that cannot be done as easily with other mechanisms like route or packet filters. if you do encrypt the tunnel, then the tunnel *must* go all the way to the mobile machine and *not* stop at the NAS; otherwise the NAS must be the equivalent of "multi-level secure" (and with compartments). if the tunnels stop at the NAS then you have an element in the protection boundaries (note the plural) which is shared between mutually-antagonistic parties and that is just madness. it is profoundly naive, not to mention irresponsible, for the WG to just say "the NAS implementation has gotta be good enough to use this feature". there are some features for which that warning is arguably sufficient. however, having a NAS a shared element in multiple protection boundaries is a threat of a completely different magnitude and is simply indefensible. -mo ======================== Mike O'Dell VP, Chief Scientist UUNET - the MCI/Worldcom Internet Company 3060 Williams Drive Fairfax, VA 22031 Voice: 703-206-5890 Fax: 703-206-5601 Email: mo@uu.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Jan 16 18:52:15 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17784 for ; Sat, 16 Jan 1999 18:52:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA01324; Sat, 16 Jan 1999 15:44:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA18533 for ietf-radius-outgoing; Sat, 16 Jan 1999 15:45:29 -0800 (PST) From: rja@corp.home.net (Ran Atkinson) Message-Id: <990116154450.ZM10645@dragonfly.eos.home.net> Date: Sat, 16 Jan 1999 15:44:49 -0800 X-Mailer: Z-Mail (4.0.1 13Jan97) To: ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: rja@corp.home.net (Ran Atkinson) Mike and Harald seem on target to me. Ran rja@corp.home.net --- Forwarded mail from "Mike O'Dell" Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Fri, 15 Jan 1999 16:53:26 -0500 From: "Mike O'Dell" it is patently irresponsible to promulgate a protocol feature which is known to have *catastrophic* security implications -mo ---End of forwarded mail from "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 Sat Jan 16 18:58:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA17826 for ; Sat, 16 Jan 1999 18:58:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA01533; Sat, 16 Jan 1999 15:50:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA18776 for ietf-radius-outgoing; Sat, 16 Jan 1999 15:51:46 -0800 (PST) From: rja@corp.home.net (Ran Atkinson) Message-Id: <990116155106.ZM10665@dragonfly.eos.home.net> Date: Sat, 16 Jan 1999 15:51:06 -0800 In-Reply-To: "Mike O'Dell" "Re: (radius) WG LAST CALL on L2TP RADIUS Drafts" (Jan 16, 18:20) References: X-Mailer: Z-Mail (4.0.1 13Jan97) To: ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: rja@corp.home.net (Ran Atkinson) To clarify my position a bit: - I think that the current draft is indefensible because it doesn't document the issues thoroughly. Glen Zorn appears to be working on resolving this. - If the draft is revised appropriately and documents clearly the issues and concerns being raised, I won't object at Last Call. However, the revised text needs to be bold and clear, not timid and diplomatic IMHO. - Generally speaking, RADIUS does NOT have good security properties and (like many other protocols) is being extended beyond its appropriate use. IMHO this is why the IESG chartered RADIUS WG so narrowly and more generally why narrow IETF WG charters are strongly desirable. Ran rja@corp.home.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Jan 16 21:49:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA19459 for ; Sat, 16 Jan 1999 21:49:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA04261; Sat, 16 Jan 1999 18:41:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA24548 for ietf-radius-outgoing; Sat, 16 Jan 1999 18:43:03 -0800 (PST) From: Aydin Edguer Message-Id: <199901170241.VAA10830@picu.morningstar.com> Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts To: mo@UU.NET Date: Sat, 16 Jan 1999 21:41:41 -0500 (EST) Cc: gwz@pinky.microsoft.com, stuartb@UU.NET, ietf-radius@livingston.com In-Reply-To: from "Mike O'Dell" at Jan 16, 99 06:20:58 pm X-Mailer: ELM [version 2.4 PL24 PGP2] 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 > there is no reason to do tunneling if you don't intend to > encrypt the tunnel. otherwise, the tunnel accomplishes > nothing that cannot be done as easily with other mechanisms > like route or packet filters. False. L2TP allow the transport of non-IP protocols over an IP network. This cannot be accomplished with route or packet filters. False. L2TP allows the transport of IP and other protocols back to a centrol location while hiding the intervening topology and thus avoiding increases in hop count and permitting the use of private address space across the public Internet. This cannot easily be accomplished with route or packet filters. However, this does not raise questions for the RADIUS-WG - your questions are better directed to the working groups that created L2TP or the customers that want to use L2TP, L2F, PPTP, GRE, and ATMP and offer them as value added services. The RADIUS-WG is trying provide guidelines for using the current protocol used to configure services, such as SLIP and PPP for dial-up clients to configure the tunneling services for dial-up clients. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Jan 16 21:53:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA19474 for ; Sat, 16 Jan 1999 21:53:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA04388; Sat, 16 Jan 1999 18:45:44 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA24681 for ietf-radius-outgoing; Sat, 16 Jan 1999 18:47:39 -0800 (PST) Message-Id: To: Aydin Edguer cc: mo@UU.NET, gwz@pinky.microsoft.com, stuartb@UU.NET, ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-reply-to: Your message of "Sat, 16 Jan 1999 21:41:41 EST." <199901170241.VAA10830@picu.morningstar.com> Date: Sat, 16 Jan 1999 21:47:17 -0500 From: "Mike O'Dell" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mike O'Dell" ok, the list of Bad Ideas is even longer. -mo - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 00:54:33 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id AAA07927 for ; Mon, 18 Jan 1999 00:54:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA23828; Sun, 17 Jan 1999 21:46:03 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA10051 for ietf-radius-outgoing; Sun, 17 Jan 1999 21:45:33 -0800 (PST) Message-Id: <3.0.1.32.19990118111618.006c4110@172.16.1.10> X-Sender: srikanth@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 18 Jan 1999 11:16:18 +0500 To: ietf-radius@livingston.com From: Nayani Srikanth Subject: (radius) Class. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Nayani Srikanth Sir/Madam, I have three qualms. 1) Does class denote the radius server's location so that the accounting requests go to the same server which sent the access -accept. 2) Also does the Accounting -session -ID atttribute denote the ID of the the accounting request sent to a particular server. i.e will the combination of class and Accounting - session -ID uniquely identify an accounting - request. Or is it that the accounting-session-ID should be universally unique. 3) In the event of a Radius server going down after Accounting - Start has been serviced what is the action taken by the Radius client on receiving a corresponding accounting -stop. Thanks in advance , Srikanth. *********************************************************** Bridging the hiatus intervening hardware and software SRIKANTH NAYANI, VOICE: 91 - 40 - 774 2606 RENDEZVOUS ON CHIP, EMAIL: srikanth@trinc.com 1st Floor, PLOT#14, KARKHANA, SECUNDERABAD-9. *********************************************************** - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 07:27:35 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA16470 for ; Mon, 18 Jan 1999 07:27:34 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id EAA28133; Mon, 18 Jan 1999 04:19:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA21266 for ietf-radius-outgoing; Mon, 18 Jan 1999 04:19:17 -0800 (PST) Message-Id: <3.0.1.32.19990118115045.006ccbc0@172.16.1.10> X-Sender: srikanth@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Mon, 18 Jan 1999 11:50:45 +0500 To: ietf-radius@livingston.com From: Nayani Srikanth Subject: (radius) Servers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Nayani Srikanth Sir/Madam, I have a question: Will the radius servers talk to each other and update their databases ? This I feel will be required when on one instance for a user the accounting is done by one radius server and at another for the same user the accounting may be done by another radius server. Thus the users utilisation time has to be a cumilative one. Thanks in advance, Srikanth. *********************************************************** Bridging the hiatus intervening hardware and software SRIKANTH NAYANI, VOICE: 91 - 40 - 774 2606 RENDEZVOUS ON CHIP, EMAIL: srikanth@trinc.com 1st Floor, PLOT#14, KARKHANA, SECUNDERABAD-9. *********************************************************** - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 11:05:10 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA18746 for ; Mon, 18 Jan 1999 11:05:09 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA01993; Mon, 18 Jan 1999 07:57:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA01410 for ietf-radius-outgoing; Mon, 18 Jan 1999 07:57:46 -0800 (PST) Message-ID: <00a101be42fb$1737ccf0$c889e9cc@titanium.techapp.com> From: "Russell J. LeBar" To: Subject: Re: (radius) comment on draft-ietf-radius-tunnel-acct-02.txt Date: Mon, 18 Jan 1999 09:56:19 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MIMEOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Russell J. LeBar" This reminds me of a phrase: "In theory there is no difference between theory and practice. In practice there is" In theory, rfc2139 is not a standard. In practice it is. > Status of this Memo > > This memo provides information for the Internet community. It does > not specify an Internet standard of any kind. Distribution of this > memo is unlimited. > >How much clearer can it get? There is a reason, I think, for this behavior, >however. People are desperate for an accounting standard; since RADIUS is >the only semi-reasonable approach we have provided, they grasp at the straw. >Note that I said "semi-reasonable"; I agree that RADIUS accounting is >seriously flawed. However, the RADIUS WG was barred from even attempting to >fix it. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 11:48:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA19680 for ; Mon, 18 Jan 1999 11:48: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 IAA03509; Mon, 18 Jan 1999 08:35:51 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA05399 for ietf-radius-outgoing; Mon, 18 Jan 1999 08:38:06 -0800 (PST) From: Aydin Edguer Message-Id: <199901181636.LAA18707@harlequin.MorningStar.Com> Subject: Re: (radius) Servers To: srikanth@trinc.com Date: Mon, 18 Jan 1999 11:36:06 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <3.0.1.32.19990118115045.006ccbc0@172.16.1.10> from "Nayani Srikanth" at Jan 18, 99 11:50:45 am 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 > Will the radius servers talk to each other and update their databases ? This is an implementation issue, not a protocol issue. This is not covered by the RADIUS standard and there is no stadard behavior among the existing RADIUS servers. > This I feel will be required when on one instance for a user the > accounting is done by one radius server and at another for the > same user the accounting may be done by another radius server. > Thus the users utilisation time has to be a cumilative one. The assumption made by many servers is that all accounting records will be postprocessed, rather than processed in real-time. This means that the records from more than one server can be gathered together into a single accounting file and the fact that different RADIUS servers were used by a single provider is obscured. Other RADIUS servers use a RDBMS backend and depend upon the replication capabilities of the underlying database to keep the records for multiple servers in sync. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 12:33:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA20425 for ; Mon, 18 Jan 1999 12:33:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA05606; Mon, 18 Jan 1999 09:24:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA10478 for ietf-radius-outgoing; Mon, 18 Jan 1999 09:25:04 -0800 (PST) From: Pat.Calhoun@eng.sun.com Message-ID: <492493082.916680102418.JavaMail.pcalhoun@hsmpka.eng.sun.com> Date: Mon, 18 Jan 1999 09:21:42 -0800 (PST) To: ietf-radius@livingston.com Subject: Re: (radius) Servers Cc: Aydin Edguer Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailer: Sun(TM) Web Access 1.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com >> Will the radius servers talk to each other and update their databases ? > >This is an implementation issue, not a protocol issue. This is not >covered by the RADIUS standard and there is no stadard behavior among >the existing RADIUS servers. > >> This I feel will be required when on one instance for a user the >> accounting is done by one radius server and at another for the >> same user the accounting may be done by another radius server. >> Thus the users utilisation time has to be a cumilative one. > >The assumption made by many servers is that all accounting records will >be postprocessed, rather than processed in real-time. This means that >the records from more than one server can be gathered together into >a single accounting file and the fact that different RADIUS servers >were used by a single provider is obscured. Which, by the way, severely limits one's options if the service needs accounting in real-time. An example is a debit card, where the cost of the service must be subtracted immediately following the user's session. This would allow the user to call Customer Support and talk to them about the session. If post-processing were used, the user would get the following response from Customer Service "Sorry, but our records do not show any activity on your card, please call again later." I for one would have a hard time with this. PatC - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 14:29:40 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA23814 for ; Mon, 18 Jan 1999 14:29:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA12349; Mon, 18 Jan 1999 11:20:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA25127 for ietf-radius-outgoing; Mon, 18 Jan 1999 11:21:28 -0800 (PST) From: Aydin Edguer Message-Id: <199901181919.OAA18758@harlequin.MorningStar.Com> Subject: Re: (radius) Class. To: srikanth@trinc.com Date: Mon, 18 Jan 1999 14:19:34 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <3.0.1.32.19990118111618.006c4110@172.16.1.10> from "Nayani Srikanth" at Jan 18, 99 11:16:18 am 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 > 1) Does class denote the radius server's location so that the accounting > requests go to the same server which sent the access -accept. No, Class has nothing to do with location. Class is a convenient method for allowing the RADIUS server to add an attribute that will allow it or other services to track responses. This means that Class has actually been used for multiple conflicting goals. Example #1 - Class can be used to categorize users and allow summaries of usage on a Class basis by a RADIUS accounting server, without having to have access to a database to link a username and a class. Example #2 - Class can be used to add a non-guessable unique value to accounting responses to help minimize the risk of additional fraudulent billing records. It does not eliminate the risk, and the originating NAS can still change the time of records, but it is more difficult to generate additional session records. These two uses are conflicting and really depends upon the environment and the RADIUS server. > 2) Also does the Accounting -session -ID atttribute denote the ID of the > the accounting request sent to a particular server. i.e will the > combination of class and Accounting - session -ID uniquely identify an > accounting - request. Or is it that the accounting-session-ID should be > universally unique. No, the Acct-Session-Id has nothing to do with the server. In fact, the NAS must guarantee that the Start and Stop records MUST have the same Acct-Session-Id whether the Accounting-Request is sent to the same RADIUS server or not. It is purely NAS based. Read the RADIUS accounting document (RFC 2139). The guarantee is that the NAS will not re-use the Acct-Session-Id. There are no guarantees that the same Acct-Session-Id will not be used by different NASes. > 3) In the event of a Radius server going down after Accounting - Start has > been serviced what is the action taken by the Radius client on receiving a > corresponding accounting -stop. Huh? A RADIUS client will not *receive* an Accounting Stop message. A RADIUS client (NAS) will *generate* an Accounting Stop message. If the RADIUS server goes down then the NAS (RADIUS client) will either continue to resend until the RADIUS server comes back up OR it will try to send to a different RADIUS server. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 14:41:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24001 for ; Mon, 18 Jan 1999 14:41:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA12788; Mon, 18 Jan 1999 11:33:10 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA26593 for ietf-radius-outgoing; Mon, 18 Jan 1999 11:35:31 -0800 (PST) Message-ID: <36A38C18.87F6DF1C@iea-software.com> Date: Mon, 18 Jan 1999 11:31:36 -0800 From: "Dale E. Reed Jr." Organization: IEA Software, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Nayani Srikanth CC: ietf-radius@livingston.com Subject: Re: (radius) Class. References: <3.0.1.32.19990118111618.006c4110@172.16.1.10> 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." Nayani Srikanth wrote: > > I have three qualms. > > 1) Does class denote the radius server's location so that the accounting > requests go to the same server which sent the access -accept. The RADIUS client SHOULD NOT interpret the class. It must just send it back unmodified. Therefore, the client can not act upon it as you are requesting. > 2) Also does the Accounting -session -ID atttribute denote the ID of the > the accounting request sent to a particular server. i.e will the > combination of class and Accounting - session -ID uniquely identify an > accounting - request. Or is it that the accounting-session-ID should be > universally unique. The NAS-Identifier and Acct-Session-ID uniquely identify a session. > 3) In the event of a Radius server going down after Accounting - Start has > been serviced what is the action taken by the Radius client on receiving a > corresponding accounting -stop. This is not defined, althogh a client could use an Accounting-On request to signal that it has been restarted. Some NASes send an all zero Acct-Session-ID to signal they were rebooted. -- Dale E. Reed Jr. (daler@iea-software.com) _________________________________________________________________ IEA Software, Inc. | RadiusNT, Emerald, and NT FAQs Internet Solutions for Today | http://www.iea-software.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 15:45:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25318 for ; Mon, 18 Jan 1999 15:45:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA15958; Mon, 18 Jan 1999 12:36:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA03655 for ietf-radius-outgoing; Mon, 18 Jan 1999 12:36:46 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Mon, 18 Jan 1999 15:32 EST Subject: Re: (radius) Class. Content-Type: text/plain Message-ID: <36a39b590.2d50@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff Well, no. The server can put more than one piece of info in Class. Only the auth and acct servers have to agree on the interpretation of the attribute. Barney Wolff > From: Aydin Edguer > Date: Mon, 18 Jan 1999 14:19:34 -0500 (EST) > > Example #1 - Class can be used to categorize users and allow summaries > of usage on a Class basis by a RADIUS accounting server, without having > to have access to a database to link a username and a class. > > Example #2 - Class can be used to add a non-guessable unique value to > accounting responses to help minimize the risk of additional fraudulent > billing records. It does not eliminate the risk, and the originating > NAS can still change the time of records, but it is more difficult to > generate additional session records. > > These two uses are conflicting and really depends upon the environment > and the RADIUS server. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 16:06:21 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA25550 for ; Mon, 18 Jan 1999 16:06:20 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA16912; Mon, 18 Jan 1999 12:58:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA06240 for ietf-radius-outgoing; Mon, 18 Jan 1999 13:00:22 -0800 (PST) From: Aydin Edguer Message-Id: <199901182058.PAA18832@harlequin.MorningStar.Com> Subject: Re: (radius) Class. To: barney@databus.com Date: Mon, 18 Jan 1999 15:58:29 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <36a39b590.2d50@databus.databus.com> from "Barney Wolff" at Jan 18, 99 03:32:00 pm 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 > Well, no. The server can put more than one piece of info in Class. > Only the auth and acct servers have to agree on the interpretation of > the attribute. If there is only one server involved, Class is simple and useful. But there can be multiple servers involved in a roaming situation, which can lead to conflicting uses of the Class attribute. The issue of two auth servers wishing to add different Class attributes is non-trivial to resolve within the protocol. It can, of course, be resolved externally to the protocol by agreements between organizations and enforced using attribute filtering (another controversial area of RADIUS). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 18:05:32 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27091 for ; Mon, 18 Jan 1999 18:05:32 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA21039; Mon, 18 Jan 1999 14:57:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA19321 for ietf-radius-outgoing; Mon, 18 Jan 1999 14:57:53 -0800 (PST) From: Barney Wolff To: ietf-radius@livingston.com Date: Mon, 18 Jan 1999 17:48 EST Subject: Re: (radius) Class. Content-Type: text/plain Message-ID: <36a3bc690.2ff1@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff This does point up our near-total underspecification of proxy behavior. My own auth proxy encapsulates the "real" server's Class in its own, and then the acct proxy unearths it to send to the "real" acct server. I am here depending on having the same implementation (not the same host) as both auth and acct proxies. Once in a while a misconfiguration causes that to be violated, and I do have code to avoid disaster when Class doesn't look as expected. So I should really have said that Class "only" needs to be agreed between servers and at each level of proxy. Barney > From: Aydin Edguer > Date: Mon, 18 Jan 1999 15:58:29 -0500 (EST) > > > Well, no. The server can put more than one piece of info in Class. > > Only the auth and acct servers have to agree on the interpretation of > > the attribute. > > If there is only one server involved, Class is simple and useful. But > there can be multiple servers involved in a roaming situation, which can > lead to conflicting uses of the Class attribute. The issue of two auth > servers wishing to add different Class attributes is non-trivial to resolve > within the protocol. It can, of course, be resolved externally to the > protocol by agreements between organizations and enforced using attribute > filtering (another controversial area of RADIUS). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 18:29:08 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA27193 for ; Mon, 18 Jan 1999 18:29:06 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id PAA21907; Mon, 18 Jan 1999 15:20:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id PAA21632 for ietf-radius-outgoing; Mon, 18 Jan 1999 15:21:11 -0800 (PST) Message-Id: <3.0.5.32.19990118182047.0081f2d0@vulcan> X-Sender: mitton@vulcan X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Mon, 18 Jan 1999 18:20:47 -0500 To: "Mike O'Dell" , "Glen Zorn" From: Dave Mitton Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: "Stuart A Barkley" , ietf-radius@livingston.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton At 06:20 PM 1/16/99 -0500, Mike O'Dell wrote: > >let me try on Stuart's behalf > >we believe it is *highly* irresponsible to standardize >something which is extremely dangerous. I yet to figure out what is "dangerous" here. >there is no reason to do tunneling if you don't intend to >encrypt the tunnel. otherwise, the tunnel accomplishes >nothing that cannot be done as easily with other mechanisms >like route or packet filters. I think this is your opinion. Tunnel technology is deployed and has been in use by multiple vendors for several years now. Shiva, Cisco(L2F), USR/3Com (VTP), Bay (DVS), Ascend (ATMP) Someone must think it's useful for something. > >if you do encrypt the tunnel, then the tunnel *must* go all >the way to the mobile machine and *not* stop at the NAS; >otherwise the NAS must be the equivalent of "multi-level >secure" (and with compartments). if the tunnels stop at >the NAS then you have an element in the protection >boundaries (note the plural) which is shared between >mutually-antagonistic parties and that is just madness. The typical setup does not terminate a tunnel, but initiates a tunnel from the NAS to the designated server, under the provisioning and control of the service provider. Hence the term "mandatory" tunnelling. The provisioning of the service is from the service provider's NAS to the mutually-cooperative tunnel server (usually governed by the form of a service contract). This cooperation forms the trust basis, and compartmentalization between the parties. The data stream actually carried over the tunnel is only presumed to IP packets which COULD be encrypted via any means agreed upon between the source and the sink. However that is not part of the service being discussed here, nor for layering purposes should it be. >it is profoundly naive, not to mention irresponsible, for >the WG to just say "the NAS implementation has gotta be >good enough to use this feature". there are some features >for which that warning is arguably sufficient. however, having >a NAS a shared element in multiple protection boundaries >is a threat of a completely different magnitude and >is simply indefensible. > Sorry, still don't get what you mean. While I don't intend to be irresponsible, I don't see how I/we am/are. > -mo > >======================== >Mike O'Dell >VP, Chief Scientist >UUNET - the MCI/Worldcom Internet Company > >3060 Williams Drive >Fairfax, VA 22031 >Voice: 703-206-5890 >Fax: 703-206-5601 >Email: mo@uu.net >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton 978-670-8888 Main Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Networks, I&SP Group 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 19:53:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA27663 for ; Mon, 18 Jan 1999 19:53:46 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA25150; Mon, 18 Jan 1999 16:45:47 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA29690 for ietf-radius-outgoing; Mon, 18 Jan 1999 16:46:12 -0800 (PST) Message-ID: <007e01be4345$2b75d6e0$51f41fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Mike O'Dell" Cc: "Stuart A Barkley" , Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Mon, 18 Jan 1999 16:46:28 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_007B_01BE4302.181CF8A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_007B_01BE4302.181CF8A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Mike O'Dell writes: > >let me try on Stuart's behalf Thanks! > >we believe it is *highly* irresponsible to standardize >something which is extremely dangerous. Hmm. Depending upon ones' point of view, it seems that virtually anything could fit into that category. SNMP comes immediately to mind, as does non-escrowed IPSec. > >there is no reason to do tunneling if you don't intend to >encrypt the tunnel. otherwise, the tunnel accomplishes >nothing that cannot be done as easily with other mechanisms >like route or packet filters. I don't think that this is true. For example, L2TP can be used to carry non-IP protocols over the Internet. Many people think that that's useful. While it's true that L2TP clients could be written for and installed on dialup hosts, this would entail considerable user and administrator involvement, which many people think is bad. > >if you do encrypt the tunnel, then the tunnel *must* go all >the way to the mobile machine and *not* stop at the NAS; No, _security_ should extend end-to-end. "Tunnel" and "security" are not the same thing. I think that it's likely that many LAC implementations will use IPSec, but that use will be to protect the control channel and perhaps the PPP negotiations on the data channels (to avoid some of the problems involved with passing domain names in the clear, for example). You seem to be suggesting (correct me if I'm wrong) that we are somehow trying to subvert the idea of end-to-end security, which is absolutely not true. >otherwise the NAS must be the equivalent of "multi-level >secure" (and with compartments). In other words, it has to keep the data (and the associated keys) destined for the various LNS seperate and make sure that the data is delivered to the correct place. I suspect that (crypto or no) any LAC that couldn't forward packets correctly would not be a big seller ;-) >if the tunnels stop at >the NAS then you have an element in the protection >boundaries (note the plural) which is shared between >mutually-antagonistic parties and that is just madness. This argument may be valid. If it is, then it certainly applies to backbone routers and security gateways as well, does it not? > >it is profoundly naive, not to mention irresponsible, for >the WG to just say "the NAS implementation has gotta be >good enough to use this feature". there are some features >for which that warning is arguably sufficient. however, having >a NAS a shared element in multiple protection boundaries >is a threat of a completely different magnitude and >is simply indefensible. That depends upon what is being protected. If and only if the LAC is considered as the sole provider of security for the tunneled connections is the user data at risk. If the end-to-end principle is applied and the user data itself is protected, I can't see how there is any danger. > > -mo > >======================== >Mike O'Dell >VP, Chief Scientist >UUNET - the MCI/Worldcom Internet Company > >3060 Williams Drive >Fairfax, VA 22031 >Voice: 703-206-5890 >Fax: 703-206-5601 >Email: mo@uu.net > ------=_NextPart_000_007B_01BE4302.181CF8A0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19990119T004628Z END:VCARD ------=_NextPart_000_007B_01BE4302.181CF8A0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 21:20:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA28126 for ; Mon, 18 Jan 1999 21:20:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA27688; Mon, 18 Jan 1999 18:10:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA05252 for ietf-radius-outgoing; Mon, 18 Jan 1999 18:11:45 -0800 (PST) To: user@the-internet.com Date: Mon, 18 Jan 99 15:28:23 EST From: hu8@livingston.com Subject: (radius) hi Message-Id: <23530037507186@aaf.com.au> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: hu8@livingston.com BOOST YOUR SEX APPEAL AND CHANGE YOUR SOCIAL AND SEX LIFE FOREVER. SCIENCE AND NATURE'S SEXUAL SECRET WEAPON! Scientists have isolated the natural Human male/female Pheromone attractants and they are NOW available to YOU, legally, in the US. ATTRACT THE OPPOSITE SEX LIKE NEVER BEFORE ! IT'S GUARANTEED, or you pay nothing! PHEROMONES in the News! >From the NY Times to the LA Times. USA Today, The Wall Street Journal, Psychology Today, 20/20, Hard Copy, Single Living, Medical Tribune, Philadelphia Inquirer, Dateline, Discovery, Hustler, Playboy, Rocky Mountain News, McCalls, Penthouse, Cosmopolitan, BBC-TV, Colordao Telegraph, GQ, Time, Redbook, Fortune Magazine, and more. Radio and Television Stations worldwide. All have reported the scientific findings amidst excitement, controversy, commotion and thrill about pheromones and their potential use. The Press Has Said it Better Than We Can. "PUT IT TO THE TEST" MERIDIAN TV: Sold extensively in the UK, phermomones were tested live on television in the UK, when the unknowing female presenter was VERY ATTRACTED to one of the twin guys, he was wearing "Androstenone Pheromone" but she did not know this, and did not know why she was attracted to him ! US NEWS and WORLD REPORTS "The key to starting a love affair might be right under your nose. Scientists have just announced the discovery of a virtual sixth sense, a tiny organ in the nasal cavity that responds to chemicals known as pheromones. These natural substances are thought to play a role in basic human emotions such as fear, hunger--and love." FORTUNE MAGAZINE: "An imaginative University of Utah anatomist named David L. Berliner was working with substances that occur in human skin. When he left some of the extracts in open vials around the lab, he noticed a sudden, puzzling rise in camaraderie among a previously acrimonious group of researchers working with him. When he changed the extracts a few months later, the group resumed its contentious ways. Berliner froze and saved the extracts. Nearly 30 years later, ... thanks to a method of containing drugs and cosmetics inside tiny, spongelike polymer spheres, he returned to the subject. In 1989 he ... has isolated the suspected good-fellowship pheromones -- behavior-controlling substances similar to those already known to stimulate sexual activity in animals. (One whiff of a pheromone called aphrodisin from a female hamster and a male is ready to mate.) On March 3, 1998 FOX Affiliate, WSVN in Miami did a story on Pheromones, stating, "If you're looking for love, we've got a potion for passion." ... "Tonight, a secret weapon to attract the opposite sex. Researchers developing their own passion potion. Ever been attracted to someone but weren't really sure why? .... More and more research is pointing to chemicals these days.... undetectable chemicals... pheromones ... a clear odorless liquid" Customers Say: "... works as advertised, best product of its' kind" I've always had trouble meeting women-then I tried your product. Now girls come up to me and introduce themselves all the time! I'd like to know if your product is available in a larger quantity so I can make sure I'm never without it! -Dave J I've been driving a tractor trailer for about 6 years and I'm on the road all the time. It's been impossible to meet women until I tried pheromones. Now every truck stop I pull into I meet new women, and many of them ask me out. Thanks! -Tom on the Road Again, WHAT ARE PHEROMONES? Pheromones are a naturally occurring chemical compound found in all insects, all animals, and in humans. When pheromones are secreted they dictate sexual behavior and attract the opposite sex. Be careful. Animal pheromones do NOT attract humans. Have you ever wondered why people who are not particularly attractive seem to attract dates like flies to honey? They seem to have some "chemical attraction" about themselves. Some call it animal magnetism. It may be pheromones. Now you can have that "chemical attraction" whenever you want. PHEROMONES - THE FACTS Pheromones are natural chemicals which play an important role in sexual communication. Animals, including humans release chemicals in tears, saliva and perspiration. These chemicals send signals relating to mood and health to the subconscious awareness. One theory is that the dominant male will exude more of these chemical attractants than a submissive or weaker male. This chemical attracts more females to him. It is similar for woman attracting men. This natural attractant can also contribute to more intense excitement during love making (sexual foreplay and sexual intercourse). Pheromones may also contribute to the dating phrase, "chemical attraction" that we all talk about. WSVN-TV (March 3, 1998) "Ever been attracted to someone but weren't really sure why? .... More and more research is pointing to chemicals these days.... Undetectable chemicals... pheromones ... a clear odorless liquid" MORE RESEARCH AND REFERENCES: Following is some research done on products made by our manufacturer, and bottled under a different name. It contains the same pheromone type and content as Hi-Octane http://www.angelfire.com/fl/beaches69/index.html ABOUT OUR PRODUCT: Hi-Octane (tm) . is made up of PHEROMONES suspended in witch hazel.. This product is designed to be added to your favorite cologne or perfume. . contains both male and female PHEROMONES. Nature never intended for just one PHEROMONE to be present; but two, male and female. Our manufacturering process uses both PHEROMONES in ALL our products. This will not attract same sex; but works as nature intended, attracting the opposite sex. . comes in 1/8 oz. Bottle with a small funnel so you can easily pour it into your cologne or perfume. One 1/8 oz. bottle is enough to mix with 4 to 8 oz of your favorite perfume product. Similar pheromone products have been sold for up to $100 elsewhere. We sell the the strongest product on the market today for only $39.95. BUY two -- get one free. The world's largest manufacturer of Pheromones, MC Marble, now manufactures Hi-Octane (tm), a pheromone prodcut that is the "Most Powerful sexual attractant on the Market today." HI_OCTANE is made with two powerful synthesized human pheromones, Alpha-Androstenol and Alpha-Androstenone. HI-OCTANE will attract the opposite sex of the wearer. McCall's magazine writes "...pheromones can improve one's love life, pheromones send out subconscious scent signals to the opposite sex that naturally trigger romantic feelings." HI-OCTANE according to the manufacturer, may also intensify sex, by increasing sexual pleasure and endurance of both partners, and creating a higher sexual ecstasy. Individual results may vary. One private study claims that pheromones don't work for everyone. 75% of those trying it had success. Isn't it worth trying? HOW TO ORDER Hi OctaneTM Hi OctaneTM is available from Euphoria Products. A 1/8 oz. bottle with a convenient funnel (to be added to your favorite perfume) is $39.95. Mix 1/4 of the bottle with every 2 oz of your favorite product. One 1/8 oz. bottle is enough to mix with 4 to 8 oz of your favorite product. *** For a limited time, when you order two bottles (up to a two month's supply) of Hi Octane(tm), you'll get a third bottle ABSOLUTELY FREE. *** Please add $3.00 shipping and handling per order. (regardless of how many bottles you order, you pay only $3.00 total!) UPS Second Day Air Delivery is available for an additional $9.00 per order. Overnight, add $15.00 per order. Florida residents, please add applicable sales tax. For orders from outside of the US only ground shipping is available for $15. Our manufacturing facility offers the STRONGEST pheromones on the market today. Our manufacturing facility assures you that Hi-Octane will be always contain the male and female pheromones, the way nature intended it, to best attract the opposite sex for you. It is and will always be manufactured with the finest ingredients to assure your satisfaction. SATISFACTION GUARANTEED Try Hi OctaneTM risk-free. Your satisfaction is unconditionally guaranteed. If you do not find you are meeting and dating and scoring with more people of the opposite sex after using High OctaneTM for 30 days, simply return the unused portion of your order at any time for a full refund--no questions asked. Call 520-453-0303 Extension 404, 24 hours/day, 7 days/week for credit card orders. Have your MasterCard, Visa, American Express, and Discover Card ready and say, " I would like to order ___ bottles of High Octane." If you would like to order by mail, you can send in a check or money order, or credit card information, along with your name and street address (no PO Boxes please) and a day time phone number to: Euphoria Products Dept. 202 1859 No Pine Island Rd. Suite #133 Plantation, FL 33322 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 21:35:19 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA28214 for ; Mon, 18 Jan 1999 21:35:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA28628; Mon, 18 Jan 1999 18:27:04 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA06349 for ietf-radius-outgoing; Mon, 18 Jan 1999 18:29:28 -0800 (PST) From: "Ramos, Jorge" To: "'ietf-radius@livingston.com'" Subject: (radius) Radius and Authentication MemberShip Date: Mon, 18 Jan 99 21:12:00 PST Message-ID: <36A416F2@perupost.Peru.NCR.COM> Encoding: 11 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Ramos, Jorge" Hello, After install RADIUS with MCIS2.0 and Site Server 3.0 , we are not available to configure the Authentication Provider tab, because this tab is not appear in the configuration window. Anybody knows how can I access this tab to configure RADIUS with MemberShip Authentication thanks in advance Jorge - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 18 21:53:35 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA28254 for ; Mon, 18 Jan 1999 21:53:29 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA29300; Mon, 18 Jan 1999 18:45:35 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA07195 for ietf-radius-outgoing; Mon, 18 Jan 1999 18:47:55 -0800 (PST) Message-ID: <00be01be4356$2ab7f560$51f41fac@glennz-2.dns.microsoft.com> From: "Glen Zorn" To: "Harald Tveit Alvestrand" , "Stuart A Barkley" , Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Mon, 18 Jan 1999 18:48:13 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00BB_01BE4313.1A419DA0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2120.0 X-Mimeole: Produced By Microsoft MimeOLE V4.72.2120.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" This is a multi-part message in MIME format. ------=_NextPart_000_00BB_01BE4313.1A419DA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Harald Tveit Alvestrand writes: >At 11:46 16.01.99 -0800, Glen Zorn wrote: >> >>I think that it would be more useful if you could explain to _us_ (since we >>obviously don't get it!) why the entire concept of compulsory tunneling is >>"bad and unneded". Preferably this explanation would take the form of >>clear, English sentences without references to either cryptography or >>metaphorical "fluids". Hint: "I don't like it" is _not_ helpful; neither is >>"If it becomes a standard, UUNET will have to do it and we don't want to". > >play it again, sam..... > >Let us see if I can understand what this thing actually does. >NOTE: I *still* don't feel that I understand it, so feel free to correct me. > >When an end system connects to a NAS, and gets Internet connectivity, >the end system is free to set up tunnels to anywhere it wants to, using any >mechanism the service it connects to allows. >For a PPP connection, it can use IP-in-IP tunnels, for instance. Yes, that's true; it may be irrelevant, however, since the end system will never see any RADIUS packets - these attributes are designed to support _only_ tunnels that originate at the NAS. > >The list of tunnel technologies mentioned in -auth is: > > 1 Point-to-Point Tunneling Protocol (PPTP) [1] > 2 Layer Two Forwarding (L2F) [2] > 3 Layer Two Tunneling Protocol (L2TP) [3] > 4 Ascend Tunnel Management Protocol (ATMP) [4] > 5 Virtual Tunneling Protocol (VTP) [5] > 6 IP Authentication Header in the Tunnel-mode (AH) [6] > 7 IP-in-IP Encapsulation (IP-IP) [7] > 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [8] > 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) [9] > 10 Generic Route Encapsulation (GRE) [10] > 11 Bay Dial Virtual Services (DVS) > 12 IP-in-IP Tunneling [11] > Several of those (especially the IPSec ones) don't seem very useful to me. I believe I had originally included just the first four; the rest were added later (many at the request/suggestion of Ran Atkinson). >(BTW, this reminds me: Any such list means that it will get longer in >the future. There is no IANA considerations section in this document, >and I can't find any other mechanism whereby new identifiers are >allocated. This must be fixed - see "IANA considerations" RFC) Good point. > >>From the way L2TP is described, it seems to be intended for the >scenario where all traffic from an end-system is going into the tunnel; >L2TP is also strongly biased towads "not modifying the PPP-using end system", >which means that L2TP tunnels will terminate at the NAS, not the end host. Yes. >For the other technologies, both approaches may be possible. > >The scenario described where mandatory tunnelling is useful: > >"These are >all services which, without compulsory tunneling, would probably be pro- >vided using dedicated networks or at least dedicated network access >servers (NAS), since they are characterized by the need to limit user >access to specific hosts." > >Now, let's play this scenario: > > Someone dials into a NAS box. > He presents an identifier, and authenticates, in order to use general > Internet access (or corporate LAN access, or whatever). Maybe, maybe not. It's quite possible that (s)he might have been handed a canned object designed just to connect to a certain host or network on the Internet. > He then fires up his home banking application, installs software, or > does something else that invokes one of these "dedicated" services. > > He's now supposed to DISCONNECT FROM THE INTERNET in order to use > these "dedicated" services, which are provided over the SAME NETWORK?????? > >(note - I regularly keep chat sessions, extra Web browser windows and so on >open and active while doing Web-based banking - my bank is just SLOW.....) Here's a different example (which doesn't assume the sophisctication of you or I ;-): I have a neighbor who is Internet illiterate and has no desire to get an account with an ISP. Nevertheless, he has a modem and would love to have the convenience of on-line banking. The bank, OTOH, has no desire to install and maintain a bank of modems so that people like my neighbor can dial in directly. With compulsory tunneling, the bank can easily outsource the access service and supply my neighbor with a floppy disk with a self-contained object on it that will dial a selected number and have the connection automatically tunneled to its server across the Internet. End-to-end security might be supplied by TLS, or Kerberos, whatever. The bank likes this because it can ensure that no (more knowledgeable) customer can use the disk to start a connection, then spend hours downloading porn on it's dime and because it doesn't have to be locked into a single ISP's architecture (unlike the alternative of address filtering on the NAS). My neighbor likes it because he gets to do the what he wants w/o having to learn a bunch of stuff about something he doesn't care about. It's true that this particular scenario could be implemented using RADIUS and NAS-side address filters; the problem with this (from the bank's point of view) is that this approach seriously reduces the bank's flexibility in choosing a service provider, because address filters in RADIUS are quite vendor-specific. > >This means that the usefulness of mandatory tunneling is limited to two >cases (IMHO, of course): > > - The case where what is sent through the tunnel is the only thing the > person CAN be doing at the moment (such as boot-time registration) Actually, I'm inclined to think that that is the only case. > - The case where what is sent through the tunnel is the only thing the > person WANTS to be doing at the moment (such as secured corporate > LAN access). > >The first one seems a very limited scope. Actually, the scope is huge. >The second one seems to be what this spec is aimed at, but I can't tell >what situation is suited to both this and NAS termination of tunnels. Suppose that 1) my employer supplies me w/an ISP account, so that he can reduce costs by outsourcing remote access 2) he would much prefer that I spend the time he is paying for doing actually accessing the corporate network, as opposed to surfing 3) effective use of my corporate network requires that I use an IP address _on_ that network (instead of the ISP's network) This _could_ all be accomplished through the use of voluntary tunneling and IP address filters, but it is _much_ simpler for everyone involved to use a compulsory tunnel. > >What have I missed? > > Harald A > > > > > > > >-- >Harald Tveit Alvestrand, Maxware, Norway >Harald.Alvestrand@maxware.no > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > ------=_NextPart_000_00BB_01BE4313.1A419DA0 Content-Type: text/x-vcard; name="Glen Zorn.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Glen Zorn.vcf" BEGIN:VCARD VERSION:2.1 N:Zorn;Glen FN:Glen Zorn EMAIL;PREF;INTERNET:gwz@pinky.microsoft.com REV:19990119T024812Z END:VCARD ------=_NextPart_000_00BB_01BE4313.1A419DA0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 15:03:58 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA26706 for ; Tue, 19 Jan 1999 15:03:56 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA05006; Tue, 19 Jan 1999 11:50:09 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA13991 for ietf-radius-outgoing; Tue, 19 Jan 1999 11:48:34 -0800 (PST) Message-ID: <36A4DCEE.774AD088@livingston.com> Date: Tue, 19 Jan 1999 11:28:46 -0800 From: Thomas Kinnen Organization: Lucent RABU X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts References: <199901070655.WAA17326@server.livingston.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Thomas Kinnen Carl Rigney wrote: > > This is the Working Group last call for the 3 RADIUS L2TP drafts before > sending them to IETF Last Call before advancing them to Proposed > Standard. If you have any comments on them please send them to the authors > or the ietf-radius@livingston.com mailing list BEFORE January 22nd. One thing in the drafts that I'm not to overlly thrilled by is the fact many of the attrubtes are using a different structure then the existing string and int types to add this 'tag' collumn in. This will cause server vendors to have to hard code in special code points for these attributes. I would rather see a new data type called Tstring or Tint for taged String or taged int. --- Thomas C Kinnen - "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer" - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 15:13:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA27102 for ; Tue, 19 Jan 1999 15:13:31 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA05639; Tue, 19 Jan 1999 12:05:43 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA15904 for ietf-radius-outgoing; Tue, 19 Jan 1999 12:08:08 -0800 (PST) From: Aydin Edguer Message-Id: <199901192006.PAA19032@harlequin.MorningStar.Com> Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts To: tkinnen@livingston.com Date: Tue, 19 Jan 1999 15:06:13 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <36A4DCEE.774AD088@livingston.com> from "Thomas Kinnen" at Jan 19, 99 11:28:46 am 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 > One thing in the drafts that I'm not to overlly thrilled by > is the fact many of the attrubutes are using a different structure > then the existing string and int types to add this 'tag' collumn in. Tags are definitely a new thing, but they have been in the drafts since draft-01 (they were not in draft-00) [24 March 1997]. The format stabilized around draft-03 and has not really changed. > This will cause server vendors to have to hard code in special code > points for these attributes. I would rather see a new data type > called Tstring or Tint for taged String or taged int. It will definitely adds work for the RADIUS servers. The approach I would recommend, is the one that Merit adopted, which is to add "TAGGED" as additional characteristic of attributes, along with "SALTED" (for new encrypted attributes). This allows other attributes to easily use the new format in a generic way. This way the basic types do not change. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 16:08:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA28686 for ; Tue, 19 Jan 1999 16:08:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA07074; Tue, 19 Jan 1999 12:59:12 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA20558 for ietf-radius-outgoing; Tue, 19 Jan 1999 13:01:01 -0800 (PST) Message-Id: <199901192108.QAA31545@cryptocard.ott.igs.net> From: Alan DeKok To: ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-reply-to: Your message of "Tue, 19 Jan 1999 15:06:13 EST." <199901192006.PAA19032@harlequin.MorningStar.Com> cc: Aydin Edguer Date: Tue, 19 Jan 1999 16:08:36 -0500 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Alan DeKok > The approach I would recommend, is the one that Merit adopted, which > is to add "TAGGED" as additional characteristic of attributes, along > with "SALTED" (for new encrypted attributes). This allows other > attributes to easily use the new format in a generic way. > > This way the basic types do not change. Maybe I'm missing something. The TAGGED attributes are NOT 'tag + integer' and 'tag + string', but '4-octet integer with the first octet as (perhaps) a tag', and 'string with the first octet as (perhaps) a tag'. The 'perhaps' bit causes much more coding to properly support tagged integers and strings, IMHO. From draft-ietf-radius-tunnel-auth-06.txt: (for a 'string' attribute) The Tag field is one octet in length and is intended to provide a means of grouping attributes in the same packet which refer to the same tunnel. Valid values for this field are 0x01 through 0x1F, inclusive. If the value of the Tag field is less than or equal to 0x1F, it SHOULD be interpreted as indicating which tunnel (of sev- eral alternatives) this attribute pertains; otherwise, it SHOULD be interpreted as the first byte of the following String field. i.e. Ambiguous in definition (is it a string octet or a tag octet?) and in implementation (maybe we do that, maybe we don't.) I can see interoperability problems resulting from these abiguities. The tagged attributes are, then, NEW basic types. If the spec said 'tag PLUS integer/string', then for the 'tagged integer' type, I would expect to see: 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and not expect to see 'tag (perhaps), followed by 3 octet network byte order integer' 4 octet network-byte-order integers are well understood. 3 octet ones are not, and require special-case code. Having the first octet of a string as 'perhaps' a tag also requires special-case code. Is it really necessary to save that extra byte of space in the packet for each tagged attribute? Is there a benefit that the current spec has, which trivializes my worries about the format? Alan DeKok. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 16:27:52 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29137 for ; Tue, 19 Jan 1999 16:27:52 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA08014; Tue, 19 Jan 1999 13:20:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA22602 for ietf-radius-outgoing; Tue, 19 Jan 1999 13:21:58 -0800 (PST) Message-ID: <36A4F2D1.CD2702DD@livingston.com> Date: Tue, 19 Jan 1999 13:02:09 -0800 From: Thomas Kinnen Organization: Lucent RABU X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 i86pc) X-Accept-Language: en MIME-Version: 1.0 To: ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts References: <199901192108.QAA31545@cryptocard.ott.igs.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Thomas Kinnen Alan DeKok wrote: > > > The approach I would recommend, is the one that Merit adopted, which > > is to add "TAGGED" as additional characteristic of attributes, along > > with "SALTED" (for new encrypted attributes). This allows other > > attributes to easily use the new format in a generic way. > > > > This way the basic types do not change. > > Maybe I'm missing something. The TAGGED attributes are NOT > 'tag + integer' and 'tag + string', but '4-octet integer with the > first octet as (perhaps) a tag', and 'string with the first octet as > (perhaps) a tag'. > > The 'perhaps' bit causes much more coding to properly support tagged > integers and strings, IMHO. Yep, That's why I would perfer to see a new basic data type that specifices that there is a tag. This would also allow the reuses of this data type as new adttributes are added that require to be grouped together with out adding additional special case coding. ---- Thomas C Kinnen - "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer" - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 16:54:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA29858 for ; Tue, 19 Jan 1999 16:54:00 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA09526; Tue, 19 Jan 1999 13:45:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA25519 for ietf-radius-outgoing; Tue, 19 Jan 1999 13:47:33 -0800 (PST) From: Aydin Edguer Message-Id: <199901192145.QAA19101@harlequin.MorningStar.Com> Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts To: alan@cryptocard.com Date: Tue, 19 Jan 1999 16:45:31 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <199901192108.QAA31545@cryptocard.ott.igs.net> from "Alan DeKok" at Jan 19, 99 04:08:36 pm 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 > > The approach I would recommend, is the one that Merit adopted, which > > is to add "TAGGED" as additional characteristic of attributes, along > > with "SALTED" (for new encrypted attributes). This allows other > > attributes to easily use the new format in a generic way. > > > > This way the basic types do not change. > > Maybe I'm missing something. I ...think... you may be missing something. The field is the same size as the normal data type. The first octet in network byte order is then masked off *by the receiver* to determine if a TAG was used in the attribute. This is to allow backwards compatibility - you can actually use tagged attributes without modifying your RADIUS server using appropriate values. For instance, to send an integer with "Tag 0x01, Value 0x10", you can just send a Value 16777232 (dec). > From draft-ietf-radius-tunnel-auth-06.txt: > > (for a 'string' attribute) > The Tag field is one octet in length and is intended to provide a > means of grouping attributes in the same packet which refer to the > same tunnel. Valid values for this field are 0x01 through 0x1F, > inclusive. If the value of the Tag field is less than or equal to > 0x1F, it SHOULD be interpreted as indicating which tunnel (of sev- > eral alternatives) this attribute pertains; otherwise, it SHOULD > be interpreted as the first byte of the following String field. > > i.e. Ambiguous in definition (is it a string octet or a tag octet?) > and in implementation (maybe we do that, maybe we don't.) I can see > interoperability problems resulting from these abiguities. It is always string a string attribute. It may or may not be tagged. You can unambiguously determine if there is a tag based upon the value of the first octet. The Tag is a *part* of the traditional data type. It is not external to the data type. > The tagged attributes are, then, NEW basic types. If the spec said > 'tag PLUS integer/string', then for the 'tagged integer' type, I would > expect to see: > > 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) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This is the opposite of how I would feel. *If* the Tagged attributes were a new data type, then they would have a format like this, because the Length would actually be different. Because they share the same length and thus can fit in the same format, they are not really new basic types. > 4 octet network-byte-order integers are well understood. 3 octet > ones are not, and require special-case code. Having the first octet > of a string as 'perhaps' a tag also requires special-case code. It is still a 4 octect network-byte-order. The first octet is then masked off to verify if a tag is present. > Is it really necessary to save that extra byte of space in the packet > for each tagged attribute? It is to allow backwards compatibility. It is actually very flexible and allows you to use an unmodified server to send properly Tagged values. > Is there a benefit that the current spec has, which trivializes my > worries about the format? For more on this, you can go back to the RADIUS-WG mailing list archives. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 19:27:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA02935 for ; Tue, 19 Jan 1999 19:27:50 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA13918; Tue, 19 Jan 1999 16:14:55 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA11704 for ietf-radius-outgoing; Tue, 19 Jan 1999 16:16:33 -0800 (PST) Date: Tue, 19 Jan 1999 19:16:14 -0500 (EST) From: Stuart A Barkley To: ietf-radius@livingston.com Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Stuart A Barkley First, let me repeat that I haven't given the L2TP RADIUS drafts as much attention as they deserve. I have also not given L2TP itself strong attention in the past, but I did give earlier drafts a quick once over orientation pass. I expect to have more time to pay attention to and be involved with various IETF activities in the not too distant future. Now that this work has progressed into an area I'm currently directly monitoring and am concerned with, I need to raise issues that I see. Certainly a number of these issues are more directly related to pppext or other working groups. However, since I don't have the history in those groups and others on the radius mailing list may have similar lack of background I will keep this discussion here for now. My arguments against this set of extensions consist of 2 major areas: - having a meaningful purpose - size, implementation time, debug time and support of the extensions by NAS vendors The L2TP radius protocol drafts refer to three examples for using L2TP (in draft-ietf-radius-tunnel-imp-04.txt section 6): - Internet software upgrade servers - Software registration servers - Banking services I don't see how any of these examples pose any problem with existing technology. These can be solved with routing filters applied when dedicated service is desired and can be solved with either generic IP connectivity support or dedicated client based tunneling otherwise. There are some areas for roamops/radius to standardize functionality for better interoperablity among multiple NAS vendors and ISPs. Section 6.1 of draft-ietf-radius-tunnel-imp-04.txt goes on to describe "Advantanges of RADIUS-based compulsory tunneling". This describes why user based radius attributes are advantageous over static or realm based attributes, but fails to provide any further insight on why compulsory tunneling is desired. Some other purposes for L2TP which have been proposed on this list and elsewhere include: - Non IP protocols - hop count/TTL reduction - private/unregistered IP address space - multilink PPP These don't seem to be reasons for L2TP either. Multi protocol routers exist and the other problems are general internet issues. The following reasons appear to be valid issues with running client tunneling protocols. Perhaps we need some extended ppp options to transfer needed information to the client: - Administrative issues on client - Client tunnel configuration by remote service So overall I have yet to see what I consider a sufficient reason for spending any time working with these protocols. If there are any other reasons someone would want to run compulsory tunneling I would like to understand the reasons. Given the large amount of time which has already been spent on this and the number of people working on these protocols I assume there must be some real reasons for these somewhere. Failing to find a purpose for these protocols, I need to also question the size of the effort to implement these. I find 274 pages of L2TP internet drafts plus 43 pages of radius L2TP internet drafts. This represents a very large code base for vendors to develop, properly debug and support. We have many other things which we need our current and future vendors to work on for us. Within the L2TP protocol specifications themselves I find a number of things which appear to reimplement existing functionality. L2TP appears to reimplement much of both TCP and IP which is something else which seems to need clear reason. In order to give L2TP itself the necessary time to understand its full implications I would also still be needing some understanding of what it claims to offer. Without that its hard to determine if it actually meets its design goals. Stuart -- Stuart A Barkley email: stuartb@uu.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 19:56:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03094 for ; Tue, 19 Jan 1999 19:56:17 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA14938; Tue, 19 Jan 1999 16:48:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA14653 for ietf-radius-outgoing; Tue, 19 Jan 1999 16:50:22 -0800 (PST) From: Aydin Edguer Message-Id: <199901200048.TAA19237@harlequin.MorningStar.Com> Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts To: stuartb@UU.NET Date: Tue, 19 Jan 1999 19:48:33 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: from "Stuart A Barkley" at Jan 19, 99 07:16:14 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > My arguments against this set of extensions consist of 2 major areas: > > - having a meaningful purpose FACT: The tunneling protocols exist FACT: The tunneling protocols are in active use FACT: There must be a method to configure equipment for said protocols Therefore, as long as said tunneling protocols are still being used, there is a meaningful purpose for supporting RADIUS configuration of tunneling. Your arguments have little bearing upon the RADIUS-WG, since they are directed at trying to say the tunneling protcols are not needed, not to the sole purpose of the RADIUS-WG which is the authentication and authorization of Services for Dial in Users. If you care to argue about why the RADIUS drafts are insufficient to configure the services, your points have validity to this WG. Otherwise you are in the wrong forum. > - size, implementation time, debug time and support of the extensions > by NAS vendors Since most of the tunneling protocols are *already* implemented by one or more of the NAS vendors and since one or more of the NAS vendors are already supporting the RADIUS drafts for tunneling attributes, this is moot point. > Some other purposes for L2TP which have been proposed on this list and > elsewhere include: > > - Non IP protocols > - hop count/TTL reduction > - private/unregistered IP address space > - multilink PPP > > These don't seem to be reasons for L2TP either. Multi protocol > routers exist and the other problems are general internet issues. Yes, multiprotocol routers exist and L2TP depends upon the LNS to be a multiprotocol router in order to accept the PPP NCP negotiations for the non-IP protocols. Yes, there are other non-L2TP tunneling solutions to transporting non-IP protocols over the Internet. But the use of tunneling for providing transport is clearly necessary over the IP-based Internet. The use of client-side (voluntary) versus NAS-side (compulsory) tunneling is one that is best left to the service provider and end-user. And there has been considerable service provider *demands* for the support of compulsory tunneling. L2TP is the only way I know to permit Multilink Protocol sessions to be split across more than vendor's NAS. All the other "stacking" methods I am aware of are proprietary. For a service provider who uses only one vendor's equipment, that may not be an issue. If you know of an alternative, please be more explicit. But to be honest, it is a matter of curiosity only, it really does *NOT* matter to *THIS* working group. As long as we need to configure L2TP on a NAS for a Dial in User, we need the current RADIUS tunnel drafts. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 21:01:10 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA03803 for ; Tue, 19 Jan 1999 21:01:09 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA16895; Tue, 19 Jan 1999 17:52:41 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA19386 for ietf-radius-outgoing; Tue, 19 Jan 1999 17:52:41 -0800 (PST) Date: Tue, 19 Jan 1999 20:52:22 -0500 (EST) From: Stuart A Barkley To: Aydin Edguer cc: ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <199901200048.TAA19237@harlequin.MorningStar.Com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Stuart A Barkley On Tue, 19 Jan 1999, Aydin Edguer wrote: > > My arguments against this set of extensions consist of 2 major areas: > > > > - having a meaningful purpose > > FACT: The tunneling protocols exist > FACT: The tunneling protocols are in active use > FACT: There must be a method to configure equipment for said protocols Actually the one in question doesn't exist yet. Its existence is yet to be determined (although I expect that it will eventually happen despite my misgivings). > Therefore, as long as said tunneling protocols are still being used, > there is a meaningful purpose for supporting RADIUS configuration of > tunneling. Not if the protocols serve no purpose. What I am requesting is some understandable new useful purpose, not just "its good" or "it already exists". > Your arguments have little bearing upon the RADIUS-WG, since they are > directed at trying to say the tunneling protcols are not needed, not > to the sole purpose of the RADIUS-WG which is the authentication and > authorization of Services for Dial in Users. If you care to argue > about why the RADIUS drafts are insufficient to configure the services, > your points have validity to this WG. Otherwise you are in the wrong > forum. Understood and mentioned in my earlier statement. I would like to get out some more meaningful comments about the specifics of the L2TP RADIUS drafts, but my immediate work schedule may not allow for that. I will be trying to limit future comments to this more productive nature. > > - size, implementation time, debug time and support of the extensions > > by NAS vendors > > Since most of the tunneling protocols are *already* implemented by one > or more of the NAS vendors and since one or more of the NAS vendors are > already supporting the RADIUS drafts for tunneling attributes, this > is moot point. So we have something large implemented by the current vendor base without a known reason for existence? The "existing implementation" is what will be documented (sort of like radius was) and we really can't supply any meaningful comments which impact these existing implementations. These are not implemented on tomorrows NASes and are a wonderful way for the current vendors to build up a huge development base which a new vendor must over come to get all the boxes checked off on their product regardless of whether anyone uses them or not. Likewise the existing vendors will continue to be bloated down with this code when the leaner trimmer implementations don't require such things. This can also impact vendors when attempting to merge two similar but distinct product lines. > > Some other purposes for L2TP which have been proposed on this list and > > elsewhere include: > > > > - Non IP protocols > > - hop count/TTL reduction > > - private/unregistered IP address space > > - multilink PPP > > > > These don't seem to be reasons for L2TP either. Multi protocol > > routers exist and the other problems are general internet issues. > > Yes, multiprotocol routers exist and L2TP depends upon the LNS to > be a multiprotocol router in order to accept the PPP NCP negotiations > for the non-IP protocols. I was more thinking of some of the routers we use. They will handle multiple non-IP protocols, but that is mostly historic code base which we don't use and don't expect other vendors to provide. > Yes, there are other non-L2TP tunneling solutions to transporting > non-IP protocols over the Internet. But the use of tunneling for > providing transport is clearly necessary over the IP-based Internet. > The use of client-side (voluntary) versus NAS-side (compulsory) > tunneling is one that is best left to the service provider and end-user. > And there has been considerable service provider *demands* for the > support of compulsory tunneling. As a service provider I don't see a purpose for this compulsory tunneling. I am still looking for the proponents to explain what this is useful for. As an ISP user I want my data packets to take the shortest internet route to their destination. I don't need packets bouncing across the country to get to somewhere down the street. As the operator of a corporate firewall I want the tunnel to extend to the remote equipment so that I can ensure that my perimeter is really secure. > L2TP is the only way I know to permit Multilink Protocol sessions > to be split across more than vendor's NAS. All the other "stacking" > methods I am aware of are proprietary. For a service provider who > uses only one vendor's equipment, that may not be an issue. If you > know of an alternative, please be more explicit. But to be honest, > it is a matter of curiosity only, it really does *NOT* matter to *THIS* > working group. Okay. This might be a situation where tunneling helps, but then I need to force all multilink users into tunneling. Perhaps the multilink protocol needs work under its working group (existing solutions are proprietary and we are interested in multivendor support). This is the closest I've seen to a valid reason for compulsory tunneling and it seems like a long stretch. > As long as we need to configure L2TP on a NAS for > a Dial in User, we need the current RADIUS tunnel drafts. In C: if (need_L2TP) { do_lots_of_work(); } If the tested condition is false then you don't need to evaluate the body of the statement. Some of the most effective coding is the removal of code. Stuart - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 21:23:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA04016 for ; Tue, 19 Jan 1999 21:23:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA17392; Tue, 19 Jan 1999 18:15:20 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA20433 for ietf-radius-outgoing; Tue, 19 Jan 1999 18:16:32 -0800 (PST) Date: Tue, 19 Jan 1999 18:16:24 -0800 From: Paul Krumviede Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts To: ietf-radius@livingston.com Message-id: <36A53C6F.9FFFF446@mci.net> Organization: MCI WorldCom MIME-version: 1.0 X-Mailer: Mozilla 4.5 (Macintosh; U; PPC) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en References: Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Paul Krumviede Stuart A Barkley wrote: > > On Tue, 19 Jan 1999, Aydin Edguer wrote: > > > > My arguments against this set of extensions consist of 2 major areas: > > > > > > - having a meaningful purpose > > > > FACT: The tunneling protocols exist > > FACT: The tunneling protocols are in active use > > FACT: There must be a method to configure equipment for said protocols FACT: cleartext passwords exist. They are in active use. Now try convincing the IESG and/or the IAB that you should be able to advance something on the standards track that requires use of them. I don't mean to imply that the tunneling questions, and the desire to support configuration for them, falls into the same category, but proof by assertion isn't always convincing. > > Therefore, as long as said tunneling protocols are still being used, > > there is a meaningful purpose for supporting RADIUS configuration of > > tunneling. > > Not if the protocols serve no purpose. What I am requesting is some > understandable new useful purpose, not just "its good" or "it already > exists". In at least some environments, I have potential customers asking for the ability to support internal (private, unregistered or registered to somebody else) IP address spaces for VPNs. For this I need some form of encapsulation. In some cases, such potential customers are also interested in my carrying PPP packets back to an edge device of theirs so they can do the final PPP authentication (and maybe periodic CHAP, or something else) without me, as a service provider, having to be involved. L2TP is one way of satisfying these. That isn't to say that we would offer such a service, but there seems to be at least some market demand for this kind of thing. -paul - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 21:33:08 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA04152 for ; Tue, 19 Jan 1999 21:33:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA17635; Tue, 19 Jan 1999 18:25:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA20928 for ietf-radius-outgoing; Tue, 19 Jan 1999 18:27:43 -0800 (PST) From: Aydin Edguer Message-Id: <199901200225.VAA19281@harlequin.MorningStar.Com> Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts To: stuartb@UU.NET Date: Tue, 19 Jan 1999 21:25:55 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: from "Stuart A Barkley" at Jan 19, 99 08:52:22 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Aydin Edguer > > > My arguments against this set of extensions consist of 2 major areas: > > > > > > - having a meaningful purpose > > > > FACT: The tunneling protocols exist > > FACT: The tunneling protocols are in active use > > FACT: There must be a method to configure equipment for said protocols > > Actually the one in question doesn't exist yet. Its existence is yet > to be determined (although I expect that it will eventually happen > despite my misgivings). While most of our discussions have been about L2TP, since that is the most recent work, when I said "tunneling protocols exist", I really did mean *exist* in already approved IETF informational documents and *existing* products. Please see: RFC 1701 "Generic Routing Encapsulation (GRE)" RFC 2107 "Ascend Tunnel Management Protocol - ATMP" RFC 1853 "IP in IP Tunneling", RFC 2341 "Layer Two Forwarding (L2F)" I also did mean *exist* in vendor implementations - Point-to-Point Tunneling Protocol (PPTP) Bay Dial Virtual Services (DVS) These are all *existing* protocols that are in use and that can be configured on different vendor NASes. I know that more than one NAS vendor was providing means to support compulsory tunneling using these protocols. But until the RADIUS tunnel drafts, the configuration was done in different proprietary ways. Therefore, these drafts serve a useful purpose by allowing vendor interoperability of *existing* functionality, even assuming that L2TP is not approved as a standard. Furthermore, due to the large number of vendors with interoperable L2TP implementations, as evidenced by the interoperability workshops, even if the IETF refuses to approve the L2TP draft as a standards track document, it *will* be released to customers, and will probably be made an informational document. > > Therefore, as long as said tunneling protocols are still being used, > > there is a meaningful purpose for supporting RADIUS configuration of > > tunneling. > > Not if the protocols serve no purpose. What I am requesting is some > understandable new useful purpose, not just "its good" or "it already > exists". It is not my purpose to supply a reason - it is the service providers who provide multi-million dollar orders to vendors that supply the reason. Since most service providers are not part of this mailing list, asking here is not very useful. Especially when, as members of this list give *existing* uses by service providers, you say that they are not sufficient reasons. They may not be sufficient reasons for you, but they are for the current users and those are the people who will be using the work. We have service providers who are offering to outsource network access to corporations. These corporations are using multiple protocols on the LAN. They use local equipment on their network to provide the same support to dial-in clients. They therefore require that the service provider provide matching functionality. This is done using tunneling protocols. Similarly, these corporations are using private addresses on their LAN. They use local equipment on their network to provide the same support to dial-in clients. They therefore require that the service provider provide matching functionality. This is done using tunneling protocols. UUnet/Worldcom/MCI may not be offering these services. UUnet/Worldcom/MCI may not need to use tunneling protocols to offer these services. But there are already other service providers who are and do. The fact that RADIUS-WG is chartered to try to work on functionality that already exists is a good reason for the RADIUS-WG to consider "it already exists" to be sufficient for us to try to put it down on paper in a vendor-independent way. > > As long as we need to configure L2TP on a NAS for > > a Dial in User, we need the current RADIUS tunnel drafts. > > In C: > > if (need_L2TP) { > do_lots_of_work(); > } if (need_L2TP || need_L2F || need_PPTP || need_GRE || need_IP-IP) { configure_existing_implementation_in_a_standard_way(); } - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 21:45:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA04266 for ; Tue, 19 Jan 1999 21:45:38 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA17953; Tue, 19 Jan 1999 18:37:52 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA21407 for ietf-radius-outgoing; Tue, 19 Jan 1999 18:40:19 -0800 (PST) Message-Id: To: Aydin Edguer cc: stuartb@UU.NET, ietf-radius@livingston.com, mo@UU.NET Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-reply-to: Your message of "Tue, 19 Jan 1999 21:25:55 EST." <199901200225.VAA19281@harlequin.MorningStar.Com> Date: Tue, 19 Jan 1999 21:39:59 -0500 From: "Mike O'Dell" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mike O'Dell" one of the major responsibilities of the IETF is to say NO to Bad Ideas, no matter how much people wish to do The Wrong Thing. saying "yes, for the right price" is a different, though ancient, occupation. -mo - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Tue Jan 19 22:34:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA06321 for ; Tue, 19 Jan 1999 22:34:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id TAA18685; Tue, 19 Jan 1999 19:26:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA23032 for ietf-radius-outgoing; Tue, 19 Jan 1999 19:28:32 -0800 (PST) Message-ID: <004901be4424$d56cc7a0$52f51fac@ntdev.microsoft.com> From: "Glen Zorn" To: "Mike O'Dell" , "Aydin Edguer" Cc: , , References: Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Tue, 19 Jan 1999 19:24:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.1012.300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.1012.300 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Mike O'Dell writes: > one of the major responsibilities of the IETF is > to say NO to Bad Ideas, no matter how much people > wish to do The Wrong Thing. Silly me, I thought that the IETF ran on "rough consensus and running code"! The fact that both are apparently present in this case is apparently irrelevant. > > saying "yes, for the right price" is a different, > though ancient, occupation. > > -mo > - > 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 Jan 19 23:02:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA06689 for ; Tue, 19 Jan 1999 23:02:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id TAA19175; Tue, 19 Jan 1999 19:54:02 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA24087 for ietf-radius-outgoing; Tue, 19 Jan 1999 19:56:28 -0800 (PST) Message-Id: To: "Glen Zorn" cc: "Mike O'Dell" , "Aydin Edguer" , stuartb@UU.NET, ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-reply-to: Your message of "Tue, 19 Jan 1999 19:24:37 PST." <004901be4424$d56cc7a0$52f51fac@ntdev.microsoft.com> Date: Tue, 19 Jan 1999 22:56:09 -0500 From: "Mike O'Dell" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mike O'Dell" you understand the basic notion correctly, but i think you are applying it incompletely after you decide to do something, THEN the IETF Credo guides the efforts. (code is the tie-breaker and sometimes the insight giver) what i'm talking about is being wise enough to decide to not do something even when you have running code. in fact, it is sometimes only then when you actually understand you didn't want it to do something so these are not inconsistent you implication taken in extremis leads to "mob rule via C compiler" and that is certainly NOT the Right Answer The answer to many problems is often LESS but RIGHT functionality, not more. cheers, -mo - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 01:14:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id BAA08494 for ; Wed, 20 Jan 1999 01:14: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 WAA21504; Tue, 19 Jan 1999 22:06:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA28892 for ietf-radius-outgoing; Tue, 19 Jan 1999 22:08:49 -0800 (PST) Message-Id: <199901200607.WAA01853@shell4.ba.best.com> Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts (fwd) To: ietf-radius@livingston.com Date: Tue, 19 Jan 1999 22:07:43 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Once upon a time Mike O'Dell shaped the electrons to say... >to say NO to Bad Ideas, no matter how much people Fine. But I still have not seen anything to indicate RADIUS L2TP support is a "Bad Idea." I consider the arguments on security to be spurious. Just because I *can* shoot myself in the foot with my Glock doesn't mean I don't have reason to have one. It is *my* responsibility not to do so. BTW I still have all my toes. I'm in the VPN group at GTEI. L2TP is something customers are *demanding* and the vendor who provides it - wins. If they need end to end security then we'll show them the way to IPSec. But the simple fact is many of them don't give a damn about it and what they want is a way to extend their private address space and/or non-IP protocols out to users in the world. Filters are *NOT* viable. Period. Not with the dispsersed network. Routing their IP addresses scattered as /32s across the world is NOT viable. Tunneling is the best solution. And it has to be transparent to the end user - anything that requires mucking with their system is a market failure before it appears. Compulsory L2TP tunneling is simple and effective. They connect to a NAS and *poof* they're on their network. The user has no need to know that they are actually riding a tunnel. Security doesn't enter into it either. Without the tunnel they'd be bare IP traffic anyway, no difference. Any 'standard' that doesn't perform in the real world isn't worth the effort of producing, because it will be stillborn. L2TP already has widespread vendor acceptance. Off hand I can't think of any respected vendor that isn't committed to it. RADIUS is the de facto AAA protocol. It isn't perfect, but it is what we have. (Personally I think the DIAMETER group is doing some nice work these days, for the future.) There have been a number of arguments put forth in favor of the draft, and aside from the "Bad Idea" comments I haven't seen any solid arguments agaist it. If any service provider or NAS vendor does not wish to support L2TP then they do not have to. Let the market decide. I certainly don't expect all of them to do so. There are plenty of examples today of standards that aren't universally supported. That's fine, it is a free marketplace. L2TP itself is not a secure tunnel media. If you want security they you want to stuff it into IPSec. It'd also be nice if Gary Malkin's (now expired) draft on multichassis MP using L2TP found support. But that's not RADIUS related... -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 Jan 20 06:51:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA17115 for ; Wed, 20 Jan 1999 06:51:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA25926; Wed, 20 Jan 1999 03:43:01 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA09301 for ietf-radius-outgoing; Wed, 20 Jan 1999 03:44:38 -0800 (PST) Message-Id: <3.0.1.32.19990120171544.006bcac4@172.16.1.10> X-Sender: srikanth@172.16.1.10 X-Mailer: Windows Eudora Light Version 3.0.1 (32) Date: Wed, 20 Jan 1999 17:15:44 +0500 To: ietf-radius@livingston.com From: Nayani Srikanth Subject: (radius) Callback Nmuber & ID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Nayani Srikanth Hello, In rfc 2138 there are two attributes describing callback number and ID . The former is said to be the callback number and the later the name of the place . There is a tangiable ambiguity with the callback ID in terms of what number it should hold . Can you please enlighten me. Thanks in advance, Srikanth. *********************************************************** Bridging the hiatus intervening hardware and software SRIKANTH NAYANI, VOICE: 91 - 40 - 774 2606 RENDEZVOUS ON CHIP, EMAIL: srikanth@trinc.com 1st Floor, PLOT#14, KARKHANA, SECUNDERABAD-9. *********************************************************** - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 07:44:38 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA17554 for ; Wed, 20 Jan 1999 07:44:37 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id EAA26641; Wed, 20 Jan 1999 04:36:38 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA10886 for ietf-radius-outgoing; Wed, 20 Jan 1999 04:39:06 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Wed, 20 Jan 1999 13:32:33 +0200 MR-Received: by mta BTMV98; Relayed; Wed, 20 Jan 1999 13:32:35 +0200 MR-Received: by mta BTMA06; Relayed; Wed, 20 Jan 1999 13:32:02 +0200 Disclose-recipients: prohibited Date: Wed, 20 Jan 1999 13:32:33 +0200 (MET-DST) From: MARC DE VRIES WE41/KT Subject: Re: (radius) Class. In-reply-to: <36a3bc690.2ff1@databus.databus.com> To: ietf-radius Message-id: <5633321320011999/A26759/BTMV98/11D1A3601F00*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal UA-content-id: 11D1A3601F00 X400-MTS-identifier: [;5633321320011999/A26759/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MARC DE VRIES WE41/KT Just a thought: I have seen multiple Class attributes in Access-Accept, all of which returned in Accounting-Request (tested with only one NAS type). You can have the two Class implementations (session-id and group) using two distict attribute instances or a single one. Access-Accept: Class = "realm:faraway.com;auth-session-id:123456" or Access-Accept: Class = "realm:faraway.com", Class = "auth-session-id:123456" For roaming, using multiple class attributes may be better than class-in-class encapsulation because of the attribute length limit. Marc. >This does point up our near-total underspecification of proxy behavior. >My own auth proxy encapsulates the "real" server's Class in its own, and >then the acct proxy unearths it to send to the "real" acct server. I >am here depending on having the same implementation (not the same host) >as both auth and acct proxies. Once in a while a misconfiguration causes >that to be violated, and I do have code to avoid disaster when Class >doesn't look as expected. >So I should really have said that Class "only" needs to be agreed between >servers and at each level of proxy. > >Barney > >> From: Aydin Edguer >> Date: Mon, 18 Jan 1999 15:58:29 -0500 (EST) >> >> > Well, no. The server can put more than one piece of info in Class. >> > Only the auth and acct servers have to agree on the interpretation of >> > the attribute. >> >> If there is only one server involved, Class is simple and useful. But >> there can be multiple servers involved in a roaming situation, which can >> lead to conflicting uses of the Class attribute. The issue of two auth >> servers wishing to add different Class attributes is non-trivial to resolve >> within the protocol. It can, of course, be resolved externally to the >> protocol by agreements between organizations and enforced using attribute >> filtering (another controversial area of RADIUS). >- >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 Jan 20 08:15:01 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA17756 for ; Wed, 20 Jan 1999 08:15:01 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id FAA27071; Wed, 20 Jan 1999 05:05:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA11787 for ietf-radius-outgoing; Wed, 20 Jan 1999 05:07:26 -0800 (PST) From: Aydin Edguer Message-Id: <199901201306.IAA14476@volitans.MorningStar.Com> Subject: Re: (radius) Callback Nmuber & ID To: srikanth@trinc.com Date: Wed, 20 Jan 1999 08:06:01 -0500 (EST) Cc: ietf-radius@livingston.com In-Reply-To: <3.0.1.32.19990120171544.006bcac4@172.16.1.10> from "Nayani Srikanth" at Jan 20, 99 05:15:44 pm 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 > In rfc 2138 there are two attributes describing callback number and ID. > The former is said to be the callback number and the later the name of > the place . There is a tangiable ambiguity with the callback ID in terms > of what number it should hold. Can you please enlighten me. I am sorry, I do not see any ambiguity. The Callback-Id does not hold a number (unless you are using numbers for user-names). The Callback-Id is used to hold the User-Name/Identifier for the remote system. Only the Callback-Number contains a phone number and it is the phone number the NAS should use to dial the remote system. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 08:49:24 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA17967 for ; Wed, 20 Jan 1999 08:49:23 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id FAA28015; Wed, 20 Jan 1999 05:41:27 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA13235 for ietf-radius-outgoing; Wed, 20 Jan 1999 05:43:26 -0800 (PST) Message-Id: <3.0.5.32.19990120053847.00b8d680@porky> X-Sender: mhold@porky X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Wed, 20 Jan 1999 05:38:47 -0800 To: Stuart A Barkley , mo@UU.NET From: Matt Holdrege Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: ietf-radius@livingston.com In-Reply-To: References: <199901200048.TAA19237@harlequin.MorningStar.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 08:52 PM 1/19/99 -0500, Stuart A Barkley wrote: >So we have something large implemented by the current vendor base >without a known reason for existence? The "existing implementation" >is what will be documented (sort of like radius was) and we really >can't supply any meaningful comments which impact these existing >implementations. > >These are not implemented on tomorrows NASes and are a wonderful way >for the current vendors to build up a huge development base which a >new vendor must over come to get all the boxes checked off on their >product regardless of whether anyone uses them or not. Likewise the >existing vendors will continue to be bloated down with this code when >the leaner trimmer implementations don't require such things. This >can also impact vendors when attempting to merge two similar but >distinct product lines. Ah, now I see a real-world reason for UUnet to object to L2TP. The above is a valid reason for UUnet to be concerned. UUnet has been a leader in the ISP business since forever and they have a very large and growing network. UUnet understandably pushes vendors to build better products for their network. Anything that might get in the way of product development is a bad thing for them. Totally understandable. I also understand Mike O'Dell's arguments that L2TP can be a "bad thing" for the Internet and customers. I understand how lay people, trade magazines, and unscrupulous salespeople may misuse and misrepresent L2TP as a secure way to access an intranet. We all know this happens. I understand that assuming a multi-user third party NAS as a trust boundary is a bad thing. I know that service providers understand this. They are not stupid. UUnet's operation is very large and I don't claim to understand its overall architecture. But I'll take their word for it that they do not have any need for L2TP. But I do understand other service provider architectures and I understand corporate networks and I understand the driving forces behind their architectures. Those driving forces push for a solution. They are like a raging river looking for an outlet. We have a delta of outlets available and L2TP is one of them. For some, it is the best available choice. For others, there are other choices. Choices are one of the great things about the Internet. We wouldn't be here without them. The fact that there are choices are available means that each choice is a good idea for some and a bad idea for others. Mike claims that L2TP is a bad idea. Others claim it is a good idea. So we have a choice. While I can understand UUnet's worries over product development, I would say that supporting L2TP is undeniably part of the business. It has been implemented on everything from large NAS's to small cable/adsl CPE devices to PC's. Although the L2TP RFC has taken a very long time to show itself, the industry has not waited. When the next solution comes down the pike, it will not wait for standards approval either. The industry is way too dynamic to wait for standards these days. I think the IESG is painfully aware of this. Also as the ISP business grows, NAS and router applications grow with it. It's an undeniable fact that NAS's have to grow their hardware and software to meet the increasing requirements of ISP's. Yet even that doesn't stop smaller, lighter NAS architectures from being built. Witness the new architectures that we have developed for the MEGACO WG and ETSI TIPHON. When I see people trying to stop standards development, I often wonder if they are trying to stifle competition. I know of several cases in the past where this has been true. I truly don't believe UUnet is trying to stifle competition. But I think that if L2TP were somehow stopped, that would be the lasting effect. Sorry for the long ramble and I'm sorry that this is taking place on the Radius list. Matt Holdrege http://www.ascend.com matt@ascend.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 09:40:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA19045 for ; Wed, 20 Jan 1999 09:40:47 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA28972; Wed, 20 Jan 1999 06:32:25 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA15300 for ietf-radius-outgoing; Wed, 20 Jan 1999 06:34:33 -0800 (PST) From: Crlaljkf@worldnet.att.net Date: Wed, 20 Jan 1999 06:31:48 -0800 (PST) Message-Id: <199901201431.GAA12386@magpie.prod.itd.earthlink.net> To: movies@aol.com Subject: (radius) Legal Cable TV Descrambler! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Crlaljkf@worldnet.att.net NOTE: THIS E-MAIL IS AN ADVERTISEMENT FOR LEGAL TV DE-SCRAMBLER” IF YOU HAVE NO INTEREST IN THIS INFORMATION PLEASE CLICK DELETE NOW. THANK YOU--DLMSR MARKETING-- LEGAL 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 cant do without. THE UP TO DATE REPORT: USING A DESCRAMBLER LEGALLY Warning you should not build a TV Descrambler without reading this report first. Frequent 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 instruction are included in the plans for each! Q: Can the cable company detect that I have the descrambler? A: No, the signal descramblers right at the box and does not move back thorough 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 plans come 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 I 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 it. YOU SUPPLY A SELF-ADDRESS, STAMPED, #10 LONG ENVELOPE, WITH TWO-FIRST CLASS STAMPS. (Orders our of the US, add $5.00 shipping) Q: How much does it cost to get the instruction plans, the easy to follow diagram, and most important of all Using a Descrambler LEGALLY. A: You get the complete package all for just--$9.00 (Cash, Check or Money Order.) (Plus $5.00 if shipping out of US) (Florida residents please ad 7% sales tax) Q: Where do I order? A: Send your orders to: DLMSR-JA-10 PO Box 17481 Jacksonville, Fl 32245-7481 MAKE CHECKS PAYABLE TO DLMSR MARKETING PRINT YOUR: NAME_____________________________________________ ADDRESS__________________________________________ CITY/STATE/ZIP____________________________________ E-MAIL ADDRESS_________________________________ *DLMSR is NOT ASSOCIATED in any way with RADIO SHACK. Neither the design nor instruction 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. Please do not respond to this e mail, e mails will not be read! To be removed from this list please respond to: lucky1227@hotmail.com Thank you! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 14:16:48 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24003 for ; Wed, 20 Jan 1999 14:16:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA16285; Wed, 20 Jan 1999 11:07:49 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA17372 for ietf-radius-outgoing; Wed, 20 Jan 1999 11:09:10 -0800 (PST) Message-Id: <035201be4498$d908e870$1b8939cc@e1kj2.internaut.com> From: "Bernard Aboba" To: "Harald Tveit Alvestrand" , "Glen Zorn" , "Beadles, Mark A." , , "Carl Rigney" Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Wed, 20 Jan 1999 09:18:01 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" >- Threats that are appropriate to different scenarios > For PPP-based tunneling (L2TP & PPTP), the threat model is covered in draft-ietf-pppext-l2tp-security-03.txt. I would remind people that in PPP-based tunneling, PPP security is negotiated between the client and the tunnel server, and covers the entire length of the path. This is because the client does not have a way to know that they are being tunneled. Thus, any security the NAS may negotiate with the tunnel server will occur in addition to that negotiated between the client and NAS. In L2TP compulsory tunneling, this means that PPP encryption and compression will be negotiated between the client and the tunnel server. In addition, the NAS may bring up an IPSEC ESP SA between itself and the tunnel server. This adds protection against a number of possible attacks which are discussed in the L2TP security draft. This means that it is not correct to say that the NAS is completely responsible for the security of the tunnel. I would also note that people should not assume that the tunneling will always occur over IP. L2TP can run over non-IP media, such as Frame Relay and in these cases, it will be common to not have any NAS-LNS security. I would also note that many of the arguments that have been made here can also be made against IPSEC tunnel mode operating in a router-router environment. After all, if the router does not set up the tunnel correctly, then the encapsulated IP packets will be sent in the clear. It is interesting to note that L2TP is actually *more* secure than IPSEC tunnel mode in this case, since PPP security can be negotiated between the client and LNS. >- Available or needed protection mechanisms for each scenario > You are essentially asking for a security analysis for each tunneling protocol. Such an analysis belongs in the relevant protocol drafts, not in this set of documents. In particular, if there are objections to the use of compulsory tunneling for L2TP or IPSEC, then these objections should have been raised to the protocol drafts. To my knowledge they have not been raised. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 15:55:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA25818 for ; Wed, 20 Jan 1999 15:55: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 MAA20771; Wed, 20 Jan 1999 12:45:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA27808 for ietf-radius-outgoing; Wed, 20 Jan 1999 12:45:21 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF604B@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Aydin Edguer'" , stuartb@UU.NET Cc: ietf-radius@livingston.com Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Wed, 20 Jan 1999 15:43:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Aydin Edguer [SMTP:edguer@MorningStar.Com] >UUnet/Worldcom/MCI may not be offering these services. UUnet/Worldcom/MCI >may not need to use tunneling protocols to offer these services. But >there are already other service providers who are and do. Please do not confuse Mr. Barkley's opinions with the opinions or products of MCI WorldCom. MCI WorldCom Advanced Networks has been a sponsor of the L2TP bakeoffs for the last year or so, and is on the board of the CIUG, the primary group responsible for L2TP interoperability testing. MCI WorldCom offers, among its many products and services, tunneling. Mr. Barkley is certainly entitled to his opinion, as am I, but please do not get the impression that MCI WorldCom does not offer tunneling services or intend to continue to do so. + Mark Anthony Beadles + MCI WorldCom Advanced Networks + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + > -----Original Message----- > From: Aydin Edguer [SMTP:edguer@MorningStar.Com] > Sent: Tuesday, January 19, 1999 9:29 PM > To: stuartb@UU.NET > Cc: ietf-radius@livingston.com > Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts > > Sender: owner-ietf-radius@livingston.com > Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) > by hil-img-1.compuserve.com (8.8.6/8.8.6/2.17) with ESMTP id > VAA19733 > for ; Tue, 19 Jan 1999 21:29:01 -0500 > (EST) > Received: from server.livingston.com (server.livingston.com > [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id > SAA17653; Tue, 19 Jan 1999 18:25:22 -0800 (PST) > Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) > id SAA20928 for ietf-radius-outgoing; Tue, 19 Jan 1999 18:27:43 -0800 > (PST) > From: Aydin Edguer > Message-Id: <199901200225.VAA19281@harlequin.MorningStar.Com> > Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts > To: stuartb@UU.NET > Date: Tue, 19 Jan 1999 21:25:55 -0500 (EST) > Cc: ietf-radius@livingston.com > In-Reply-To: > from "Stuart A Barkley" at Jan 19, 99 08:52:22 pm > X-Mailer: ELM [version 2.4 PL23] > MIME-Version: 1.0 > Content-Type: text/plain; charset=US-ASCII > Content-Transfer-Encoding: 7bit > Sender: owner-ietf-radius@livingston.com > Precedence: bulk > Reply-To: Aydin Edguer > > > > > My arguments against this set of extensions consist of 2 major > areas: > > > > > > > > - having a meaningful purpose > > > > > > FACT: The tunneling protocols exist > > > FACT: The tunneling protocols are in active use > > > FACT: There must be a method to configure equipment for said protocols > > > > Actually the one in question doesn't exist yet. Its existence is yet > > to be determined (although I expect that it will eventually happen > > despite my misgivings). > > While most of our discussions have been about L2TP, since that is the > most recent work, when I said "tunneling protocols exist", I really > did mean *exist* in already approved IETF informational documents and > *existing* products. > > Please see: > RFC 1701 "Generic Routing Encapsulation (GRE)" > RFC 2107 "Ascend Tunnel Management Protocol - ATMP" > RFC 1853 "IP in IP Tunneling", > RFC 2341 "Layer Two Forwarding (L2F)" > > I also did mean *exist* in vendor implementations - > Point-to-Point Tunneling Protocol (PPTP) > Bay Dial Virtual Services (DVS) > > These are all *existing* protocols that are in use and that can be > configured on different vendor NASes. I know that more than one NAS > vendor was providing means to support compulsory tunneling using these > protocols. But until the RADIUS tunnel drafts, the configuration was > done in different proprietary ways. Therefore, these drafts serve > a useful purpose by allowing vendor interoperability of *existing* > functionality, even assuming that L2TP is not approved as a standard. > > Furthermore, due to the large number of vendors with interoperable L2TP > implementations, as evidenced by the interoperability workshops, even > if the IETF refuses to approve the L2TP draft as a standards track > document, it *will* be released to customers, and will probably be made > an informational document. > > > > Therefore, as long as said tunneling protocols are still being used, > > > there is a meaningful purpose for supporting RADIUS configuration of > > > tunneling. > > > > Not if the protocols serve no purpose. What I am requesting is some > > understandable new useful purpose, not just "its good" or "it already > > exists". > > It is not my purpose to supply a reason - it is the service providers > who provide multi-million dollar orders to vendors that supply the > reason. Since most service providers are not part of this mailing > list, asking here is not very useful. Especially when, as members > of this list give *existing* uses by service providers, you say that > they are not sufficient reasons. They may not be sufficient reasons > for you, but they are for the current users and those are the people > who will be using the work. > > We have service providers who are offering to outsource network access > to corporations. These corporations are using multiple protocols on > the LAN. They use local equipment on their network to provide the same > support to dial-in clients. They therefore require that the service > provider provide matching functionality. > > This is done using tunneling protocols. > > Similarly, these corporations are using private addresses on their LAN. > They use local equipment on their network to provide the same support to > dial-in clients. They therefore require that the service provider > provide matching functionality. > > This is done using tunneling protocols. > > UUnet/Worldcom/MCI may not be offering these services. UUnet/Worldcom/MCI > may not need to use tunneling protocols to offer these services. But > there are already other service providers who are and do. > > The fact that RADIUS-WG is chartered to try to work on functionality that > already exists is a good reason for the RADIUS-WG to consider "it already > exists" to be sufficient for us to try to put it down on paper in a > vendor-independent way. > > > > As long as we need to configure L2TP on a NAS for > > > a Dial in User, we need the current RADIUS tunnel drafts. > > > > In C: > > > > if (need_L2TP) { > > do_lots_of_work(); > > } > > if (need_L2TP || need_L2F || need_PPTP || need_GRE || need_IP-IP) { > configure_existing_implementation_in_a_standard_way(); > } > > - > 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 Jan 20 16:10:39 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA26067 for ; Wed, 20 Jan 1999 16:10:39 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA21656; Wed, 20 Jan 1999 13:02:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA29885 for ietf-radius-outgoing; Wed, 20 Jan 1999 13:05:10 -0800 (PST) From: Barney Wolff To: ietf-radius Date: Wed, 20 Jan 1999 15:58 EST Subject: Re: (radius) Class. Content-Type: text/plain Message-ID: <36a644e50.4beb@databus.databus.com> Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Barney Wolff In theory, this ought to work. I wonder how many NAS impelmentations support returning multiple Class attributes safely in the acct request. The implication for NAS memory is fairly profound, as all the Classes have to be kept around until the end of the session. Trivial for a new hardware design, of course, but not necessarily for updated software on old hardware. Barney > Date: Wed, 20 Jan 1999 13:32:33 +0200 (MET-DST) > From: MARC DE VRIES WE41/KT > > I have seen multiple Class attributes in Access-Accept, all of which returned > in Accounting-Request (tested with only one NAS type). > > You can have the two Class implementations (session-id and group) using two > distict attribute instances or a single one. > > Access-Accept: > Class = "realm:faraway.com;auth-session-id:123456" > > or > > Access-Accept: > Class = "realm:faraway.com", > Class = "auth-session-id:123456" > > For roaming, using multiple class attributes may be better than class-in-class > encapsulation because of the attribute length limit. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 16:28:47 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA26277 for ; Wed, 20 Jan 1999 16:28:46 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA22292; Wed, 20 Jan 1999 13:20:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA02209 for ietf-radius-outgoing; Wed, 20 Jan 1999 13:22:35 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF604D@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Harald Tveit Alvestrand'" , ietf-radius@livingston.com, Stuart A Barkley , Glen Zorn Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Wed, 20 Jan 1999 16:20:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Harald Tveit Alvestrand [SMTP:Harald@Alvestrand.no] >This means that the usefulness of mandatory tunneling is limited to two >cases (IMHO, of course): > > - The case where what is sent through the tunnel is the only thing the > person CAN be doing at the moment (such as boot-time registration) > - The case where what is sent through the tunnel is the only thing the > person WANTS to be doing at the moment (such as secured corporate > LAN access). > >The first one seems a very limited scope. >The second one seems to be what this spec is aimed at, but I can't tell >what situation is suited to both this and NAS termination of tunnels. > >What have I missed? The first case is certainly limited, although that in itself should not be a reason to halt advancement of the draft, IMHO. However, you are correct, the second case is certainly more interesting. But LAN access is a much broader scope, and brings up many scenarios that can be ideally met by compulsory tunneling. Examples include: -Remote access over the internet to a non-IP LAN, for example an IPX network. -Remote access, using a non-IP intervening network, to an IP network (e.g. L2TP over ATM tunneling to an IP network). -The "distributed NAS" scenario, a very interesting one IMHO. User dials into one NAS, begins PPP, is L2TP tunneled to a second NAS, which finishes PPP and provides access to the user's home network, which may not be otherwise accessible. The two NAS's can be regarded as two halves of a distributed NAS which provides access to the home network. The intervening L2TP tunnel takes the place of the backplane on a standard NAS. -Remote access over the internet to a non-public, non-unique IP address space. Certainly anyone who is extermely concerned about security will ALSO perform encryption end-to-end, perform authentication within the end application, and perform bidirectional authorization at the NAS. Compulsory tunneling does not prevent anyone from applying these security measures if they so desire. But the functionality provided by compulsory tunneling goes beyond pure "security". Perhaps some of the fear here is that naive users and providers will be confused by this document into thinking that compulsory tunneling is the ONLY security that need be applied. I suppose we could insert some words of warning into the draft to indicate that is NOT the point. However, the flip side of this mode of thinking is that if compulsory tunneling is involved, then the resulting network is somehow insecure no matter what other measures are applied. This is also wrong. We have many years of experience here providing remote LAN access over a global public network using compulsory tunneling (admittedly non-IP), and we have never experienced the catastrophic failures predicted by others on this list, because we apply MANY other security measures. Compulsory tunneling is simply a mechanism that allows providers to build highly functional, almost customizable, networks for end users. + Mark Anthony Beadles + MCI WorldCom Advanced Networks + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + > -----Original Message----- > From: Harald Tveit Alvestrand [SMTP:Harald@Alvestrand.no] > Sent: Saturday, January 16, 1999 6:02 PM > To: ietf-radius@livingston.com; Stuart A Barkley; Glen Zorn > Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts > > Sender: owner-ietf-radius@livingston.com > Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) > by hil-img-6.compuserve.com (8.8.6/8.8.6/2.17) with ESMTP id > SAA21478 > for ; Sat, 16 Jan 1999 18:02:15 -0500 > (EST) > Received: from server.livingston.com (server.livingston.com > [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id > OAA00613; Sat, 16 Jan 1999 14:58:48 -0800 (PST) > Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) > id OAA15760 for ietf-radius-outgoing; Sat, 16 Jan 1999 14:59:03 -0800 > (PST) > Message-Id: <3.0.2.32.19990117000028.024a7320@dokka.maxware.no> > X-Sender: hta@dokka.maxware.no > X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) > Date: Sun, 17 Jan 1999 00:00:28 +0100 > To: "Glen Zorn" , "Stuart A Barkley" > , > > From: Harald Tveit Alvestrand > Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts > In-Reply-To: <002e01be4188$f6da1e40$51f41fac@glennz-2.dns.microsoft.com> > Mime-Version: 1.0 > Content-Type: text/plain; charset="us-ascii" > Sender: owner-ietf-radius@livingston.com > Precedence: bulk > Reply-To: Harald Tveit Alvestrand > > At 11:46 16.01.99 -0800, Glen Zorn wrote: > > > >I think that it would be more useful if you could explain to _us_ (since > we > >obviously don't get it!) why the entire concept of compulsory tunneling > is > >"bad and unneded". Preferably this explanation would take the form of > >clear, English sentences without references to either cryptography or > >metaphorical "fluids". Hint: "I don't like it" is _not_ helpful; neither > is > >"If it becomes a standard, UUNET will have to do it and we don't want > to". > > play it again, sam..... > > Let us see if I can understand what this thing actually does. > NOTE: I *still* don't feel that I understand it, so feel free to correct > me. > > When an end system connects to a NAS, and gets Internet connectivity, > the end system is free to set up tunnels to anywhere it wants to, using > any > mechanism the service it connects to allows. > For a PPP connection, it can use IP-in-IP tunnels, for instance. > > The list of tunnel technologies mentioned in -auth is: > > 1 Point-to-Point Tunneling Protocol (PPTP) [1] > 2 Layer Two Forwarding (L2F) [2] > 3 Layer Two Tunneling Protocol (L2TP) [3] > 4 Ascend Tunnel Management Protocol (ATMP) [4] > 5 Virtual Tunneling Protocol (VTP) [5] > 6 IP Authentication Header in the Tunnel-mode (AH) [6] > 7 IP-in-IP Encapsulation (IP-IP) [7] > 8 Minimal IP-in-IP Encapsulation (MIN-IP-IP) [8] > 9 IP Encapsulating Security Payload in the Tunnel-mode (ESP) > [9] > 10 Generic Route Encapsulation (GRE) [10] > 11 Bay Dial Virtual Services (DVS) > 12 IP-in-IP Tunneling [11] > > (BTW, this reminds me: Any such list means that it will get longer in > the future. There is no IANA considerations section in this document, > and I can't find any other mechanism whereby new identifiers are > allocated. This must be fixed - see "IANA considerations" RFC) > > From the way L2TP is described, it seems to be intended for the > scenario where all traffic from an end-system is going into the tunnel; > L2TP is also strongly biased towads "not modifying the PPP-using end > system", > which means that L2TP tunnels will terminate at the NAS, not the end host. > For the other technologies, both approaches may be possible. > > The scenario described where mandatory tunnelling is useful: > > "These are > all services which, without compulsory tunneling, would probably be pro- > vided using dedicated networks or at least dedicated network access > servers (NAS), since they are characterized by the need to limit user > access to specific hosts." > > Now, let's play this scenario: > > Someone dials into a NAS box. > He presents an identifier, and authenticates, in order to use general > Internet access (or corporate LAN access, or whatever). > He then fires up his home banking application, installs software, or > does something else that invokes one of these "dedicated" services. > > He's now supposed to DISCONNECT FROM THE INTERNET in order to use > these "dedicated" services, which are provided over the SAME > NETWORK?????? > > (note - I regularly keep chat sessions, extra Web browser windows and so > on > open and active while doing Web-based banking - my bank is just SLOW.....) > > This means that the usefulness of mandatory tunneling is limited to two > cases (IMHO, of course): > > - The case where what is sent through the tunnel is the only thing the > person CAN be doing at the moment (such as boot-time registration) > - The case where what is sent through the tunnel is the only thing the > person WANTS to be doing at the moment (such as secured corporate > LAN access). > > The first one seems a very limited scope. > The second one seems to be what this spec is aimed at, but I can't tell > what situation is suited to both this and NAS termination of tunnels. > > What have I missed? > > Harald A > > > > > > > > -- > Harald Tveit Alvestrand, Maxware, Norway > Harald.Alvestrand@maxware.no > > - > 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 Jan 20 16:40:54 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA26395 for ; Wed, 20 Jan 1999 16:40:54 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA22801; Wed, 20 Jan 1999 13:32:58 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA03556 for ietf-radius-outgoing; Wed, 20 Jan 1999 13:35:14 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF604F@wcomexch1.wcom.net> From: "Beadles, Mark A." To: stuartb@UU.NET, "'Aydin Edguer'" Cc: ietf-radius@livingston.com Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Wed, 20 Jan 1999 16:33:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Beadles, Mark A. [SMTP:MBeadles@WCOM.NET] >Please do not confuse Mr. Barkley's opinions with the opinions or products >of MCI WorldCom. Before everybody jumps all over me....Please do not confuse MY opinions with those of MCI WorldCom, either. They are my own. + Mark Anthony Beadles + MCI WorldCom Advanced Networks + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 16:49:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id QAA26575 for ; Wed, 20 Jan 1999 16:49:13 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA23303; Wed, 20 Jan 1999 13:41:14 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA04733 for ietf-radius-outgoing; Wed, 20 Jan 1999 13:43:42 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF6051@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Stuart A Barkley'" , ietf-radius@livingston.com Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Wed, 20 Jan 1999 16:42:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." >Failing to find a purpose for these protocols, I need to also question >the size of the effort to implement these. I find 274 pages of L2TP >internet drafts plus 43 pages of radius L2TP internet drafts. This >represents a very large code base for vendors to develop, properly >debug and support. We have many other things which we need our >current and future vendors to work on for us. > >Within the L2TP protocol specifications themselves I find a number of >things which appear to reimplement existing functionality. L2TP >appears to reimplement much of both TCP and IP which is something >else which seems to need clear reason. If you find that the L2TP protocol ITSELF is deficient or unnecessary, please take it to the L2TP list. (I would recommend you do it quickly, too, BTW, since it's currently in draft 12 and is basically functionally "done"). But this is the RADIUS list, and we are discussing the draft in question, not the applicability or size of the entire L2TP protocol. + Mark Anthony Beadles + MCI WorldCom Advanced Networks + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + > -----Original Message----- > From: Stuart A Barkley [SMTP:stuartb@UU.NET] > Sent: Tuesday, January 19, 1999 7:26 PM > To: ietf-radius@livingston.com > Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts > > Sender: owner-ietf-radius@livingston.com > Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) > by hpamgaaa.compuserve.com (8.8.8/8.8.8/HP-1.0) with ESMTP id > TAA02332 > for ; Tue, 19 Jan 1999 19:25:13 -0500 > (EST) > Received: from server.livingston.com (server.livingston.com > [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id > QAA13948; Tue, 19 Jan 1999 16:15:08 -0800 (PST) > Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) > id QAA11704 for ietf-radius-outgoing; Tue, 19 Jan 1999 16:16:33 -0800 > (PST) > Date: Tue, 19 Jan 1999 19:16:14 -0500 (EST) > From: Stuart A Barkley > To: ietf-radius@livingston.com > Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts > In-Reply-To: > Message-ID: > MIME-Version: 1.0 > Content-Type: TEXT/PLAIN; charset=US-ASCII > Sender: owner-ietf-radius@livingston.com > Precedence: bulk > Reply-To: Stuart A Barkley > > First, let me repeat that I haven't given the L2TP RADIUS drafts as > much attention as they deserve. I have also not given L2TP itself > strong attention in the past, but I did give earlier drafts a quick > once over orientation pass. I expect to have more time to pay > attention to and be involved with various IETF activities in the not > too distant future. > > Now that this work has progressed into an area I'm currently directly > monitoring and am concerned with, I need to raise issues that I see. > Certainly a number of these issues are more directly related to pppext > or other working groups. However, since I don't have the history in > those groups and others on the radius mailing list may have similar > lack of background I will keep this discussion here for now. > > My arguments against this set of extensions consist of 2 major areas: > > - having a meaningful purpose > - size, implementation time, debug time and support of the extensions > by NAS vendors > > The L2TP radius protocol drafts refer to three examples for using L2TP > (in draft-ietf-radius-tunnel-imp-04.txt section 6): > > - Internet software upgrade servers > - Software registration servers > - Banking services > > I don't see how any of these examples pose any problem with existing > technology. These can be solved with routing filters applied when > dedicated service is desired and can be solved with either generic IP > connectivity support or dedicated client based tunneling otherwise. > There are some areas for roamops/radius to standardize functionality > for better interoperablity among multiple NAS vendors and ISPs. > > Section 6.1 of draft-ietf-radius-tunnel-imp-04.txt goes on to describe > "Advantanges of RADIUS-based compulsory tunneling". This describes > why user based radius attributes are advantageous over static or realm > based attributes, but fails to provide any further insight on why > compulsory tunneling is desired. > > Some other purposes for L2TP which have been proposed on this list and > elsewhere include: > > - Non IP protocols > - hop count/TTL reduction > - private/unregistered IP address space > - multilink PPP > > These don't seem to be reasons for L2TP either. Multi protocol > routers exist and the other problems are general internet issues. > > The following reasons appear to be valid issues with running client > tunneling protocols. Perhaps we need some extended ppp options to > transfer needed information to the client: > > - Administrative issues on client > - Client tunnel configuration by remote service > > So overall I have yet to see what I consider a sufficient reason for > spending any time working with these protocols. If there are any > other reasons someone would want to run compulsory tunneling I would > like to understand the reasons. Given the large amount of time which > has already been spent on this and the number of people working on > these protocols I assume there must be some real reasons for these > somewhere. > > Failing to find a purpose for these protocols, I need to also question > the size of the effort to implement these. I find 274 pages of L2TP > internet drafts plus 43 pages of radius L2TP internet drafts. This > represents a very large code base for vendors to develop, properly > debug and support. We have many other things which we need our > current and future vendors to work on for us. > > Within the L2TP protocol specifications themselves I find a number of > things which appear to reimplement existing functionality. L2TP > appears to reimplement much of both TCP and IP which is something > else which seems to need clear reason. In order to give L2TP itself > the necessary time to understand its full implications I would also > still be needing some understanding of what it claims to offer. > Without that its hard to determine if it actually meets its design > goals. > > Stuart > -- > Stuart A Barkley email: stuartb@uu.net > > - > 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 Jan 20 17:51:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA27748 for ; Wed, 20 Jan 1999 17:51: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 OAA25448; Wed, 20 Jan 1999 14:40:22 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA11945 for ietf-radius-outgoing; Wed, 20 Jan 1999 14:42:45 -0800 (PST) Message-ID: <9A74C89D6696D2118E500008C7BA7C56BF6055@wcomexch1.wcom.net> From: "Beadles, Mark A." To: "'Mike O'Dell'" , "Glen Zorn (E-mail)" Cc: ietf-radius@livingston.com, stuartb@UU.NET, "'Aydin Edguer'" Subject: RE: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Wed, 20 Jan 1999 17:41:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Beadles, Mark A." From: Mike O'Dell [SMTP:mo@UU.NET] >ah yes - it happens in the best of families.... > >please do not confuse WANS opinions with those of UUNET, >where we do not offer tunneling and don't intend to start Mr. Odell brings up an excellent point here. It will be up to each individual service provider whether they wish to offer services enabled by the draft in question. And it will be up to each individual NAS vendor whether they wish to sell NAS's that adhere to this draft. And this is obviously a controversial draft, given that there are such strong opinions on both sides, even within a "single" organization. However, I don't believe we are trying to mandate service offerings or NAS feature lists here. What we seem to be trying to do is bring standardization to a very fragmented functional set that is already offered by most NAS vendors. Many, but not all, service providers would like to offer services based on this draft. Many NAS vendors appear willing to conform to this functionality. If we can come to agreement on some wording strongly admonishing users and providers not to bet the farm on compulsory tunneling, is there anyone who would still oppose adoption of the draft? Is anyone working on such wording, or have suggestions? + Mark Anthony Beadles + MCI WorldCom Advanced Networks + + mbeadles@wcom.net + http://www.wcom.net + + Voice 614.723.1941 + Fax 614.723.8407 + - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 18:06:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA28000 for ; Wed, 20 Jan 1999 18:06:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA23968; Wed, 20 Jan 1999 13:57:28 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA06492 for ietf-radius-outgoing; Wed, 20 Jan 1999 13:59:37 -0800 (PST) Message-Id: To: "Beadles, Mark A." cc: "'Aydin Edguer'" , stuartb@UU.NET, ietf-radius@livingston.com, mo@UU.NET Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-reply-to: Your message of "Wed, 20 Jan 1999 15:43:28 EST." <9A74C89D6696D2118E500008C7BA7C56BF604B@wcomexch1.wcom.net> Date: Wed, 20 Jan 1999 16:59:15 -0500 From: "Mike O'Dell" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mike O'Dell" ah yes - it happens in the best of families.... please do not confuse WANS opinions with those of UUNET, where we do not offer tunneling and don't intend to start -mo - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 20 20:33:26 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA29593 for ; Wed, 20 Jan 1999 20:33: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 RAA29962; Wed, 20 Jan 1999 17:24:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA25932 for ietf-radius-outgoing; Wed, 20 Jan 1999 17:24:03 -0800 (PST) Message-Id: <3.0.2.32.19990120055149.00bd8860@dokka.maxware.no> X-Sender: hta@dokka.maxware.no (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Wed, 20 Jan 1999 05:51:49 +0100 To: "Glen Zorn" , "Stuart A Barkley" , From: Harald Tveit Alvestrand Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <00be01be4356$2ab7f560$51f41fac@glennz-2.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Tveit Alvestrand I think we're converging towards an agreement: - Tunnelling (of the type we're talking about here) isn't useful for security. It's useful for making connections for things that otherwise wouldn't run across the open Internet. - At least with L2TP, tunnels are between the NAS and the site being connected to. There is no definition for anything else at the moment. - If the customer wants security, he should supply it end-to-end; the NAS should be treated with no less distrust (and no more) than any other ISP device. I don't think it's a terribly useful service: At 18:48 18.01.99 -0800, Glen Zorn wrote: >Here's a different example (which doesn't assume the sophisctication of you >or I ;-): I have a neighbor who is Internet illiterate and has no desire to >get an account with an ISP. Nevertheless, he has a modem and would love to >have the convenience of on-line banking. The bank, OTOH, has no desire to >install and maintain a bank of modems so that people like my neighbor can >dial in directly. well.....he may not understand much about the Internet, but he does understand "the football game stops showing when I access my bank". I think using the PC for one thing at a time is a paradigm that won't last for long. But my disbelief in the model won't make me stop shipping documents, if the document, to my mind, gives a correct representation of what it's good for. Harald A -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 09:59:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA14294 for ; Thu, 21 Jan 1999 09:59:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA16544; Thu, 21 Jan 1999 06:50:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA27965 for ietf-radius-outgoing; Thu, 21 Jan 1999 06:50:55 -0800 (PST) Message-Id: <199901211438.GAA06250@mailman.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 21 Jan 1999 09:23:13 -0500 To: Harald Tveit Alvestrand From: Chip Sharp Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: "Glen Zorn" , "Stuart A Barkley" , In-Reply-To: <3.0.2.32.19990120055149.00bd8860@dokka.maxware.no> References: <00be01be4356$2ab7f560$51f41fac@glennz-2.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Chip Sharp At 1/20/99 +0100, Harald Tveit Alvestrand wrote: >I think we're converging towards an agreement: > >- Tunnelling (of the type we're talking about here) isn't useful for > security. It's useful for making connections for things that > otherwise wouldn't run across the open Internet. >- At least with L2TP, tunnels are between the NAS and the site > being connected to. There is no definition for anything else at > the moment. Actually, the current specifications allow an IP client to set up a L2TP tunnel to the LNS. This is sometimes called "voluntary" tunneling as opposed to the "compulsory" tunneling when the NAS initiates the tunnel to the LNS. >- If the customer wants security, he should supply it end-to-end; > the NAS should be treated with no less distrust (and no more) than > any other ISP device. There are many levels and types of security. End-to-end (e.g., client-to-client, application-to-application) authentication, authorization and encryption is certainly more secure than relying on an L2TP tunnel. Of course, it doesn't matter what kind of alarm system you have on your Benz if someone steals your keys. :-) ...snip... >-- >Harald Tveit Alvestrand, Maxware, Norway >Harald.Alvestrand@maxware.no > -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. -------------------------------------------------- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 11:01:59 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA15212 for ; Thu, 21 Jan 1999 11:01:57 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA18475; Thu, 21 Jan 1999 07:54:00 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA02886 for ietf-radius-outgoing; Thu, 21 Jan 1999 07:54:56 -0800 (PST) Message-Id: <3.0.5.32.19990121105359.007c5100@vulcan> X-Sender: mitton@vulcan X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 21 Jan 1999 10:53:59 -0500 To: Chip Sharp , Harald Tveit Alvestrand From: Dave Mitton Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: "Glen Zorn" , "Stuart A Barkley" , In-Reply-To: <199901211438.GAA06250@mailman.cisco.com> References: <3.0.2.32.19990120055149.00bd8860@dokka.maxware.no> <00be01be4356$2ab7f560$51f41fac@glennz-2.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton At 09:23 AM 1/21/99 -0500, Chip Sharp wrote: >At 1/20/99 +0100, Harald Tveit Alvestrand wrote: >>I think we're converging towards an agreement: >> >>- Tunnelling (of the type we're talking about here) isn't useful for >> security. It's useful for making connections for things that >> otherwise wouldn't run across the open Internet. >>- At least with L2TP, tunnels are between the NAS and the site >> being connected to. There is no definition for anything else at >> the moment. > >Actually, the current specifications allow an IP client to set up a L2TP >tunnel to the LNS. This is sometimes called "voluntary" tunneling as >opposed to the "compulsory" tunneling when the NAS initiates the tunnel to >the LNS. Which specifications? Can you point me at the citation? Thanks. These drafts discuss how to use RADIUS to setup a tunnel. For the most part a compulsory tunnel (even in the title...). I'm not really aware of voluntary implementations, so they're not discussed much. But more to the point, RADIUS is only engaged during an authentication or service initiation. You mention an "IP client", but once someone becomes an IP (PPP) client of the network, they have already passed through the PPP authentication phase, and they have no interface to RADIUS, or for that matter no really defined way to engage the services of the NAS further. They have the service intended by their provider. If they wish to start a tunnel from their own client, that is an end-to-end decision, and they must know the appropriate access information to proceed. The typical way someone may interface to NAS to initiate voluntary tunneling, would be via an async terminal style connection. Then they can type a command to start a tunnel, (I believe Shiva supports this?) This would initiate a new RADIUS authentication cycle and the attributes as provisioned in the NAS'es RADIUS server will come into play. It's been stated by others in this discussion that somehow these specifications allow callers to terminate or initiate tunnels to anywhere. This is false. These specifications provide a standard communication path between the NAS and the RADIUS server to provision a service. The user has no control or visibility into this process. For an IP client, he is not even let out of the PPP authentication phase until the service is completely setup. This means authentication by the remote gateway/LNS and likely a remote domain authentication server. >>- If the customer wants security, he should supply it end-to-end; >> the NAS should be treated with no less distrust (and no more) than >> any other ISP device. > >There are many levels and types of security. End-to-end (e.g., >client-to-client, application-to-application) authentication, authorization >and encryption is certainly more secure than relying on an L2TP tunnel. Of >course, it doesn't matter what kind of alarm system you have on your Benz >if someone steals your keys. :-) > >...snip... >>-- >>Harald Tveit Alvestrand, Maxware, Norway >>Harald.Alvestrand@maxware.no >> > >-------------------------------------------------- >Chip Sharp voice: +1 (919) 851-2085 >Cisco Systems Consulting Eng. - Telco >Reality - Love it or Leave it. >-------------------------------------------------- >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > --------------------------------------------------------------- David Mitton 978-670-8888 Main Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Networks, I&SP Group 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 11:38:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA15859 for ; Thu, 21 Jan 1999 11:38:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA20640; Thu, 21 Jan 1999 08:30:42 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA06853 for ietf-radius-outgoing; Thu, 21 Jan 1999 08:32:22 -0800 (PST) Message-Id: <3.0.2.32.19990121172529.029d6360@127.0.0.1> X-Sender: hta@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Thu, 21 Jan 1999 17:25:29 +0100 To: Dave Mitton , Chip Sharp From: Harald Alvestrand Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: "Glen Zorn" , "Stuart A Barkley" , In-Reply-To: <3.0.5.32.19990121105359.007c5100@vulcan> References: <199901211438.GAA06250@mailman.cisco.com> <3.0.2.32.19990120055149.00bd8860@dokka.maxware.no> <00be01be4356$2ab7f560$51f41fac@glennz-2.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Alvestrand At 10:53 21.01.99 -0500, Dave Mitton wrote: > >It's been stated by others in this discussion that somehow these >specifications allow callers to terminate or initiate tunnels to anywhere. >This is false. > The hint that led me to believe that it might be possible is that the specification includes attributes for the addresses of BOTH ends of the tunnel. But these attributes are only sent to the NAS, who has no standard way of telling anyone else about them, so.... It was only when I re-read the "tunnel-imp" draft that I came to the conclusion that endsystem termination wasn't supported. Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 11:50:13 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA15993 for ; Thu, 21 Jan 1999 11:50:12 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA21504; Thu, 21 Jan 1999 08:41:56 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA08362 for ietf-radius-outgoing; Thu, 21 Jan 1999 08:43:51 -0800 (PST) Message-Id: <199901211630.IAA02229@mailman.cisco.com> X-Sender: chsharp@dogwood.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0.2 Date: Thu, 21 Jan 1999 11:37:29 -0500 To: Dave Mitton From: Chip Sharp Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: Harald Tveit Alvestrand , "Glen Zorn" , "Stuart A Barkley" , In-Reply-To: <3.0.5.32.19990121105359.007c5100@vulcan> References: <199901211438.GAA06250@mailman.cisco.com> <3.0.2.32.19990120055149.00bd8860@dokka.maxware.no> <00be01be4356$2ab7f560$51f41fac@glennz-2.dns.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Chip Sharp At 1/21/99 -0500, Dave Mitton wrote: >At 09:23 AM 1/21/99 -0500, Chip Sharp wrote: >>At 1/20/99 +0100, Harald Tveit Alvestrand wrote: >>>I think we're converging towards an agreement: >>> >>>- Tunnelling (of the type we're talking about here) isn't useful for >>> security. It's useful for making connections for things that >>> otherwise wouldn't run across the open Internet. >>>- At least with L2TP, tunnels are between the NAS and the site >>> being connected to. There is no definition for anything else at >>> the moment. >> >>Actually, the current specifications allow an IP client to set up a L2TP >>tunnel to the LNS. This is sometimes called "voluntary" tunneling as >>opposed to the "compulsory" tunneling when the NAS initiates the tunnel to >>the LNS. > > Which specifications? Can you point me at the citation? Thanks. > ..snip... Mea Culpa. Sorry folks. With all the discussion of whether L2TP is a valid protocol or not, I forgot what mail list I was on or what documents/protocols were being discussed. :-\ I was wrong. As far as I know there are no specifications anywhere for RADIUS to set up a client-initiated L2TP tunnel. Nor do I hope ever to see one (let's see, we define a new RADIUS attribute and a new LCP parameter to tell the PPP client to initiate a L2TP tunnel to the defined LNS. ;-) ;-) ;-) ). Chip -------------------------------------------------- Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it. -------------------------------------------------- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 13:03:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA17031 for ; Thu, 21 Jan 1999 13:02:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA27483; Thu, 21 Jan 1999 09:54:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA17614 for ietf-radius-outgoing; Thu, 21 Jan 1999 09:55:18 -0800 (PST) From: Clark_Rudder@infonet.com X-Lotus-FromDomain: ISC@INFONET To: ietf-radius@livingston.com, radiusabm-users@livingston.com Message-ID: <88256700.0061BC2C.00@issmail1.infonet.com> Date: Thu, 21 Jan 1999 09:51:30 -0800 Subject: (radius) Mutual Authentication Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Clark_Rudder@infonet.com Has anybody heard of the term "Mutual Authentication"? I'd appreciate it if you could point me to some info. Here is the definition as it was given to me "Mutual authentication is the process of providing principals (users or services) with tickets that they can use to identify themselves to other principals and secret cryptographic keys for secure communication with other principals. A ticket is a sequence of a few hundred bytes. This ticket can then be embedded in virtually any other network protocol. This allows the processes implementing that protocol to be sure of the identity of the principals involved." Thanks, Clark - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 13:15:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id NAA17123 for ; Thu, 21 Jan 1999 13:14:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA28564; Thu, 21 Jan 1999 10:06:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA19710 for ietf-radius-outgoing; Thu, 21 Jan 1999 10:08:07 -0800 (PST) Message-ID: From: "Nelson, David" To: "'Clark_Rudder@infonet.com'" Cc: "'ietf-radius@livingston.com'" Subject: RE: (radius) Mutual Authentication Date: Thu, 21 Jan 1999 13:04:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Nelson, David" Clark Rudder writes... > Has anybody heard of the term "Mutual Authentication"? I'd appreciate it > if you could point me to some info. > > Here is the definition as it was given to me > > "Mutual authentication is the process of providing > principals (users or services) with tickets that they can use to identify > themselves to other principals and secret cryptographic keys for secure > communication with other principals. A ticket is a sequence of a few > hundred > bytes. This ticket can then be embedded in virtually any other network > protocol. This allows the processes implementing that protocol to be sure > of > the identity of the principals involved." > This sound like a description of Kerberos tickets. Many applications can and have been "Kerberized" to require and exchange Kerberos tickets. Kerberos is a distributed authentication system that supports mutual authentication. There are probably other authentication services to which the text you provide could also apply. It's fairly general. Regards, Dave David B. Nelson Cabletron Systems, Inc. Software Engineer V 50 Minuteman Road (978) 684-1330 Andover, MA 01810 - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 15:00:40 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA18468 for ; Thu, 21 Jan 1999 15:00:40 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id LAA04606; Thu, 21 Jan 1999 11:52:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id LAA03068 for ietf-radius-outgoing; Thu, 21 Jan 1999 11:52:33 -0800 (PST) Message-ID: <00cc01be4577$73c52fc0$52f51fac@ntdev.microsoft.com> From: "Glen Zorn" To: "Mike O'Dell" Cc: "Mike O'Dell" , "Aydin Edguer" , , References: Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Thu, 21 Jan 1999 11:50:11 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.1012.300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.1012.300 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Mike O'Dell writes: > you understand the basic notion correctly, but i think you are > applying it incompletely I was going to let this pass, but since assent generally is taken as agreement, I can't. > > after you decide to do something, THEN the IETF Credo > guides the efforts. This statement begs the question "To whom does the term "you" refer in the above statement?" Apparently not the consensus of the WG, since it is only relevant _after_ the decision is made. Apparently not the implementers, a 'mob with C compilers' who will gladly 'say yes' to anything 'for the right price'. Obviously not customers, since they aren't smart enough to know what's good for them. So who is it that decides to do something? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 15:23:12 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA19048 for ; Thu, 21 Jan 1999 15:23:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA05890; Thu, 21 Jan 1999 12:11:39 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA05680 for ietf-radius-outgoing; Thu, 21 Jan 1999 12:12:49 -0800 (PST) Message-Id: <3.0.5.32.19990121120432.0091e3f0@gump.eng.ascend.com> X-Sender: igoyret@gump.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 21 Jan 1999 12:04:32 -0800 To: "Mike O'Dell" From: Ignacio Goyret Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: ietf-radius@livingston.com, mo@UU.NET In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret At 04:59 PM 1/20/99 -0500, Mike O'Dell wrote: >please do not confuse WANS opinions with those of UUNET, >where we do not offer tunneling and don't intend to start Why is it that this statement reminds me of Mr Watson's (IBM founder) near 1949, when he stated that "only 12 computers would be needed in the whole world"... ? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 17:02:36 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA02047 for ; Thu, 21 Jan 1999 17:02:35 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA11579; Thu, 21 Jan 1999 13:52:54 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA17403 for ietf-radius-outgoing; Thu, 21 Jan 1999 13:52:28 -0800 (PST) Message-Id: To: Ignacio Goyret cc: "Mike O'Dell" , ietf-radius@livingston.com Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-reply-to: Your message of "Thu, 21 Jan 1999 12:04:32 PST." <3.0.5.32.19990121120432.0091e3f0@gump.eng.ascend.com> Date: Thu, 21 Jan 1999 16:52:09 -0500 From: "Mike O'Dell" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mike O'Dell" i note that IBM did OK anyway.... - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 17:04:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA02073 for ; Thu, 21 Jan 1999 17:03:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA11838; Thu, 21 Jan 1999 13:56:00 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA18088 for ietf-radius-outgoing; Thu, 21 Jan 1999 13:57:54 -0800 (PST) Message-Id: <3.0.5.32.19990121134934.008ced70@gump.eng.ascend.com> X-Sender: igoyret@gump.eng.ascend.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 21 Jan 1999 13:49:34 -0800 To: "Mike O'Dell" From: Ignacio Goyret Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: Ignacio Goyret , "Mike O'Dell" , ietf-radius@livingston.com In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Ignacio Goyret At 04:52 PM 1/21/99 -0500, Mike O'Dell wrote: >i note that IBM did OK anyway.... Yep, and last time I checked, it sold more than 12 computers... :-) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 17:27:51 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA02462 for ; Thu, 21 Jan 1999 17:27:50 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA12773; Thu, 21 Jan 1999 14:19:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA20933 for ietf-radius-outgoing; Thu, 21 Jan 1999 14:20:34 -0800 (PST) Message-Id: <3.0.5.32.19990121141639.008bfbd0@bichon.cisco.com> X-Sender: gclark@bichon.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 21 Jan 1999 14:16:39 -0800 To: Ignacio Goyret , "Mike O'Dell" From: Glen Clark Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Cc: ietf-radius@livingston.com, mo@UU.NET In-Reply-To: <3.0.5.32.19990121120432.0091e3f0@gump.eng.ascend.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Clark At 12:04 PM 1/21/99 -0800, Ignacio Goyret wrote: >At 04:59 PM 1/20/99 -0500, Mike O'Dell wrote: > >>please do not confuse WANS opinions with those of UUNET, >>where we do not offer tunneling and don't intend to start > >Why is it that this statement reminds me of Mr Watson's (IBM founder) >near 1949, when he stated that "only 12 computers would be needed in >the whole world"... ? Only 12 computers are needed in the whole world. The rest are just processor envy ;-) > > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 19:38:04 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA03820 for ; Thu, 21 Jan 1999 19:38: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 QAA17808; Thu, 21 Jan 1999 16:30:08 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA05419 for ietf-radius-outgoing; Thu, 21 Jan 1999 16:31:35 -0800 (PST) Date: Thu, 21 Jan 1999 19:31:16 -0500 (EST) From: Stuart A Barkley To: ietf-radius@livingston.com Subject: (radius) further comments on draft-ietf-radius-tunnel-acct-02.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Stuart A Barkley I have still not been able to give these drafts complete attention, but I have a few comments on draft-ietf-radius-tunnel-acct-02.txt. There are a few minor comments of the other drafts, but unless otherwise mentioned these apply to -acct-02. Section 3 "Motivation" of -acct-02 and -auth-06 consists of one large paragraph. Section 6 "Introduction" of -imp-04 breaks similar text up into three paragraphs which are more easily digestible. Section 5 of -acct-02 defines several new Acct-Status-Type values for the Accounting-Request packet. These packets are sent upon various events of the system. Because it is possible for the accounting request to be lost or significantly delayed we should have provision for interim accounting packets. These interim packets should contain enough information in a single packet so that usage can be as fully reported as possible (lost Stop packets would cause information to only be accurate up to the last interim packet). My preference would be that the start packets have a start timestamp, interim packets have the start and current timestamp and the stop packets have a start and stop timestamp. By using timestamps instead of just having something like Acct-Session-Time you leave open the possibility of adding additional timestamps for other points of interest in the session (e.q. when was the Tunnel requested vs when did the Tunnel actually come up for data transfer or both timestamps when dual authentication is performed). We use this type of data both for invoicing users and for network operational statistics. By having a series of timestamps for significant points in the state diagram for the process we are able to compute what ever delta time metric we need instead of relying upon only a single elapsed time value. Whether the timestamp has any external meaning is a separate issues which has been discussed before, but these should be in well defined units. Once a timestamp is determined for a particular attribute it should be constant for every accounting packet for a particular Tunnel. Also by putting timestamps in the packets we can eliminate the need to Acct-Delay-Time (although that can be very helpful when attempting to normalize the NAS timestamps to real world time). Section 5 of -acct-02 defines several new Acct-Status-Type values for the Accounting-Request packet and section 6 defines several new attributes including Acct-Tunnel-Connection. What is the relationship to Acct-Session-Id already defined for radius accounting? Can this tunnel be contained inside a PPP session which has been already reported by radius accounting? Can multiple Tunnels and Tunnel-Links exist inside a single PPP session sequentially or simultaneously? Should these tunnel accounting requests always contain the Acct-Session-Id of the containing PPP session? My concern here is that when accounting for "port connect time" you really need to relate all of the contained sessions together so that you don't double charge for simultaneous sessions on the same port. Its possible this is just another instance of where the radius accounting model doesn't meet our specific needs, but I think others would also find it useful to be able to relate these various tunnels together. Section 10 "UserID issues" or -imp-04 got me just thinking about the routing of accounting packets from the NAS back to the home radius server. I don't see User-Name in and of the -acct-02 accounting request packets. How is a radius proxy server supposed to route these packets? I certainly have not studied this for more than 5 minutes and perhaps it is covered somewhere I haven't noticed. Spelling: My spell checker found a few things. Are people generally interested in these or does the RFC editor take care of these sorts of things? I doubt I found everything either, I rely heavily on spell checkers (hopefully I won't accidently correct the following before sending this message out). -acct-02: Acknowledgements should be Acknowledgments. -auth-06: Acknowledgements should be Acknowledgments. -imp-04: Advantanges should be Advantages. -imp-04: accomodated should be accommodated. -imp-04: Start-Control-Conection-Reply should be Start-Control-Connection-Reply. -imp-04: implmentation should be implementation. -imp-04: Acknowledgements should be Acknowledgments. Stuart -- Stuart A Barkley email: stuartb@uu.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 20:21:49 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id UAA04186 for ; Thu, 21 Jan 1999 20:21:48 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id RAA19038; Thu, 21 Jan 1999 17:12:45 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id RAA08774 for ietf-radius-outgoing; Thu, 21 Jan 1999 17:14:33 -0800 (PST) Message-ID: <002501be45a4$72a6f510$52f51fac@ntdev.microsoft.com> From: "Glen Zorn" To: "Stuart A Barkley" , References: Subject: Re: (radius) further comments on draft-ietf-radius-tunnel-acct-02.txt Date: Thu, 21 Jan 1999 17:13:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.1012.300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.1012.300 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Stuart A Barkley writes: > I have still not been able to give these drafts complete attention, > but I have a few comments on draft-ietf-radius-tunnel-acct-02.txt. > There are a few minor comments of the other drafts, but unless > otherwise mentioned these apply to -acct-02. > > Section 3 "Motivation" of -acct-02 and -auth-06 consists of one large > paragraph. Section 6 "Introduction" of -imp-04 breaks similar text up > into three paragraphs which are more easily digestible. OK > > Section 5 of -acct-02 defines several new Acct-Status-Type values for > the Accounting-Request packet. These packets are sent upon various > events of the system. Because it is possible for the accounting > request to be lost or significantly delayed we should have provision > for interim accounting packets. These interim packets should contain > enough information in a single packet so that usage can be as fully > reported as possible (lost Stop packets would cause information to > only be accurate up to the last interim packet). Interim accounting is discussed (slightly) in http://www.ietf.org/internet-drafts/draft-ietf-radius-acct-interim-01.txt > > My preference would be that the start packets have a start timestamp, > interim packets have the start and current timestamp and the stop > packets have a start and stop timestamp. By using timestamps instead > of just having something like Acct-Session-Time you leave open the > possibility of adding additional timestamps for other points of > interest in the session (e.q. when was the Tunnel requested vs when > did the Tunnel actually come up for data transfer or both timestamps > when dual authentication is performed). We use this type of data both > for invoicing users and for network operational statistics. By having > a series of timestamps for significant points in the state diagram for > the process we are able to compute what ever delta time metric we need > instead of relying upon only a single elapsed time value. > > Whether the timestamp has any external meaning is a separate issues > which has been discussed before, but these should be in well defined > units. Once a timestamp is determined for a particular attribute it > should be constant for every accounting packet for a particular > Tunnel. > > Also by putting timestamps in the packets we can eliminate the need to > Acct-Delay-Time (although that can be very helpful when attempting to > normalize the NAS timestamps to real world time). There is an attribute called Event-Timestamp described in draft-ietf-radius-ext-02 (expired and apparently removed from the IETF site). I like the idea of start, stop and interim timestamps; OTOH, I'm tired of fighting for (new and) sensible RADIUS enhancements like that. If you are talking about timestamps incorporated in individual attributes, that's going to be a _really_ tough row to hoe. Good luck! > > Section 5 of -acct-02 defines several new Acct-Status-Type values for > the Accounting-Request packet and section 6 defines several new > attributes including Acct-Tunnel-Connection. What is the relationship > to Acct-Session-Id already defined for radius accounting? Can this > tunnel be contained inside a PPP session which has been already > reported by radius accounting? Actually, the PPP session is contained inside the tunnel, but yes, I think that you can account seperately for PPP and tunnel usage. For example, in the case where a user authenticates to a NAS which then starts a tunnel, the usage of the NAS port is different than the tunnel usage. >Can multiple Tunnels and Tunnel-Links > exist inside a single PPP session sequentially or simultaneously? Multiple links can exist inside a tunnel simultaneously in L2TP, PPTP and L2F. > > Should these tunnel accounting requests always contain the > Acct-Session-Id of the containing PPP session? The tunnel (or tunnel link) encapsulates PPP, not vice-versa, but yes, Acct-Session-Id is required in every accounting request packet (RFC 2139). > > My concern here is that when accounting for "port connect time" you > really need to relate all of the contained sessions together so that > you don't double charge for simultaneous sessions on the same port. > > Its possible this is just another instance of where the radius > accounting model doesn't meet our specific needs, but I think others > would also find it useful to be able to relate these various tunnels > together. > > Section 10 "UserID issues" or -imp-04 got me just thinking about the > routing of accounting packets from the NAS back to the home radius > server. I don't see User-Name in and of the -acct-02 accounting > request packets. How is a radius proxy server supposed to route these > packets? I certainly have not studied this for more than 5 minutes > and perhaps it is covered somewhere I haven't noticed. > > Spelling: My spell checker found a few things. Are people generally > interested in these or does the RFC editor take care of these sorts of > things? Yes, I'm _very_ interested in spelling errors and other typos. The RFC Editor sometimes catches some them, but that's not really their job: it's supposed to be a finished document when it reaches them. >I doubt I found everything either, I rely heavily on spell > checkers (hopefully I won't accidently correct the following before > sending this message out). > > -acct-02: Acknowledgements should be Acknowledgments. > -auth-06: Acknowledgements should be Acknowledgments. > -imp-04: Advantanges should be Advantages. > -imp-04: accomodated should be accommodated. > -imp-04: Start-Control-Conection-Reply should be Start-Control-Connection-Reply. > -imp-04: implmentation should be implementation. > -imp-04: Acknowledgements should be Acknowledgments. Thanks! > > Stuart > -- > Stuart A Barkley email: stuartb@uu.net > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 21 21:38:45 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id VAA04657 for ; Thu, 21 Jan 1999 21:38:45 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id SAA20920; Thu, 21 Jan 1999 18:30:06 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id SAA12828 for ietf-radius-outgoing; Thu, 21 Jan 1999 18:31:02 -0800 (PST) Date: Thu, 21 Jan 1999 21:30:42 -0500 (EST) From: Stuart A Barkley To: Glen Zorn cc: ietf-radius@livingston.com Subject: Re: (radius) further comments on draft-ietf-radius-tunnel-acct-02.txt In-Reply-To: <002501be45a4$72a6f510$52f51fac@ntdev.microsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Stuart A Barkley On Thu, 21 Jan 1999, Glen Zorn wrote: > Stuart A Barkley writes: > > > Section 5 of -acct-02 defines several new Acct-Status-Type values for > > the Accounting-Request packet. These packets are sent upon various > > events of the system. Because it is possible for the accounting > > request to be lost or significantly delayed we should have provision > > for interim accounting packets. These interim packets should contain > > enough information in a single packet so that usage can be as fully > > reported as possible (lost Stop packets would cause information to > > only be accurate up to the last interim packet). > > Interim accounting is discussed (slightly) in > http://www.ietf.org/internet-drafts/draft-ietf-radius-acct-interim-01.txt Yes, but this defines a new Acct-Status-Type value. What Acct-Status-Type value does an interim Tunnel-Stop-ish accounting request contain? > > My preference would be that the start packets have a start timestamp, > > interim packets have the start and current timestamp and the stop > > packets have a start and stop timestamp. By using timestamps instead > > of just having something like Acct-Session-Time you leave open the > > possibility of adding additional timestamps for other points of > > interest in the session (e.q. when was the Tunnel requested vs when > > did the Tunnel actually come up for data transfer or both timestamps > > when dual authentication is performed). We use this type of data both > > for invoicing users and for network operational statistics. By having > > a series of timestamps for significant points in the state diagram for > > the process we are able to compute what ever delta time metric we need > > instead of relying upon only a single elapsed time value. > > > > Whether the timestamp has any external meaning is a separate issues > > which has been discussed before, but these should be in well defined > > units. Once a timestamp is determined for a particular attribute it > > should be constant for every accounting packet for a particular > > Tunnel. > > > > Also by putting timestamps in the packets we can eliminate the need to > > Acct-Delay-Time (although that can be very helpful when attempting to > > normalize the NAS timestamps to real world time). > > There is an attribute called Event-Timestamp described in > draft-ietf-radius-ext-02 (expired and apparently removed from the IETF > site). Hmm, I only had draft-ietf-radius-ext-00. I just found the latest in ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-ext-02.txt. > I like the idea of start, stop and interim timestamps; OTOH, I'm > tired of fighting for (new and) sensible RADIUS enhancements like that. If > you are talking about timestamps incorporated in individual attributes, > that's going to be a _really_ tough row to hoe. Good luck! Yes, my preference is several attributes so that the various interesting metrics are available and so that interim and stop packets will have complete information. And Yes, I expect that this won't fly but since we are doing a new draft for this it is a possibility. I would like to see a good complete data model independent from the transport so we have a basis for building other transports or even file formats. e.g. draft-ietf-roamops-actng-05.txt attempts to encode radius attributes, but without supplementing the radius data with external information (like receive time at the radius server) it isn't complete enough information for our use. Even if Event-Timestamp is included there are complicated issues regarding computing constant start times for sessions if you are feeding split records to other downstream systems. This is starting to drift from the real L2TP RADIUS drafts. > > Section 5 of -acct-02 defines several new Acct-Status-Type values for > > the Accounting-Request packet and section 6 defines several new > > attributes including Acct-Tunnel-Connection. What is the relationship > > to Acct-Session-Id already defined for radius accounting? Can this > > tunnel be contained inside a PPP session which has been already > > reported by radius accounting? > > Actually, the PPP session is contained inside the tunnel, but yes, I think > that you can account seperately for PPP and tunnel usage. For example, in > the case where a user authenticates to a NAS which then starts a tunnel, the > usage of the NAS port is different than the tunnel usage. > > >Can multiple Tunnels and Tunnel-Links > > exist inside a single PPP session sequentially or simultaneously? > > Multiple links can exist inside a tunnel simultaneously in L2TP, PPTP and > L2F. So each of these tunnels should have a unique Acct-Session-Id? That sounds good and is probably implied when taken with RFC-2139. Would a tunnel with a single contained link and the PPP session use the same Acct-Session-Id? If there are multiple links in a tunnel are there multiple Acct-Session-Ids assigned and can these be related to the containing tunnel Acct-Session-Id? I guess the links could all use the tunnel Acct-Session-Id since the Tunnel- and Tunnel-Link- messages have other attributes which uniquely identify them. What would the multiple PPP sessions use? > > Should these tunnel accounting requests always contain the > > Acct-Session-Id of the containing PPP session? > > The tunnel (or tunnel link) encapsulates PPP, not vice-versa, but yes, > Acct-Session-Id is required in every accounting request packet (RFC 2139). Should the table in section 7 of -acct-02 include this information? OTOH, RFC-2139 does say all accounting packets should have both Acct-Status-Type and Acct-Session-Id so maybe this is okay. Thanks for the clarification, Stuart -- Stuart A Barkley email: stuartb@uu.net - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 22 08:24:29 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA18558 for ; Fri, 22 Jan 1999 08:24:28 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id FAA01245; Fri, 22 Jan 1999 05:14:32 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA19471 for ietf-radius-outgoing; Fri, 22 Jan 1999 05:12:16 -0800 (PST) MR-Received: by mta BTMA97.MUAS; Relayed; Fri, 22 Jan 1999 13:51:22 +0200 MR-Received: by mta BTMV98; Relayed; Fri, 22 Jan 1999 13:51:23 +0200 MR-Received: by mta BTMA06; Relayed; Fri, 22 Jan 1999 14:05:02 +0200 Disclose-recipients: prohibited Date: Fri, 22 Jan 1999 13:51:22 +0200 (MET-DST) From: CHRISTIAAN SIERENS WE3/KT Subject: (radius) L2TP Radius : Tunnel-Client-Endpoint? To: ietf-radius@livingston.com Message-id: <1322511322011999/A26789/BTMV98/11D1B3731400*@MHS> Autoforwarded: false MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: normal Sensitivity: Company-Confidential UA-content-id: 11D1B3731400 X400-MTS-identifier: [;1322511322011999/A26789/BTMV98] Hop-count: 2 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: CHRISTIAAN SIERENS WE3/KT What is the purpose of the Tunnel-Client-Endpoint attribute? I do not understand that it is not needed for the reason given in the draft, i.e. as a globally unique indentifier part for accounting purpose, since I assume that the NAS (as initiator of the tunnel) knows his own IP-address and does therefore not need to get it from the Radius server. Or, is it also the intention to specify from which NAS-INTERFACE the tunnel should/must be initiated? And what must happen when the IP-address given in Tunnel-Client-Endpoint does not match with any of the IP-addresses allocacted to the NAS (or its interfaces)? The tunnel and call of the user must be rejected then? - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 22 12:49:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA24465 for ; Fri, 22 Jan 1999 12:49:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA09360; Fri, 22 Jan 1999 09:39:21 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA08966 for ietf-radius-outgoing; Fri, 22 Jan 1999 09:40:07 -0800 (PST) Message-ID: <01a801be462e$1396c340$52f51fac@ntdev.microsoft.com> From: "Glen Zorn" To: "CHRISTIAAN SIERENS WE3/KT" , References: <1322511322011999/A26789/BTMV98/11D1B3731400*@MHS> Subject: Re: (radius) L2TP Radius : Tunnel-Client-Endpoint? Date: Fri, 22 Jan 1999 09:38:47 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.1012.300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.1012.300 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" CHRISTIAAN SIERENS WE3/KT writes: > What is the purpose of the Tunnel-Client-Endpoint attribute? > > I do not understand that it is not needed for the reason given in the draft, > i.e. as a globally unique indentifier part for accounting purpose, since I > assume that the NAS (as initiator of the tunnel) knows his own IP-address and > does therefore not need to get it from the Radius server. Tunnel-Client-Endpoint is not necessarily an IP address and NASs don't necessarily have only one IP address. > > Or, is it also the intention to specify from which NAS-INTERFACE the tunnel > should/must be initiated? Not quite that hardware-specific, but that's the general idea. > > And what must happen when the IP-address given in Tunnel-Client-Endpoint does > not match with any of the IP-addresses allocacted to the NAS (or its > interfaces)? The tunnel and call of the user must be rejected then? Yes. If that happened, however, it would be an indication of misconfiguration, either of the NAS or the RADIUS server. > > - > 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 Jan 22 15:19:15 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA01069 for ; Fri, 22 Jan 1999 15:19:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA18567; Fri, 22 Jan 1999 12:10:41 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA29587 for ietf-radius-outgoing; Fri, 22 Jan 1999 12:12:21 -0800 (PST) Message-ID: <001e01be4643$659b9200$52f51fac@ntdev.microsoft.com> From: "Glen Zorn" To: "Stuart A Barkley" Cc: References: Subject: Re: (radius) further comments on draft-ietf-radius-tunnel-acct-02.txt Date: Fri, 22 Jan 1999 12:11:24 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.1012.300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.1012.300 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Glen Zorn" Stuart A Barkley writes: > On Thu, 21 Jan 1999, Glen Zorn wrote: > > > Stuart A Barkley writes: > > > > > Section 5 of -acct-02 defines several new Acct-Status-Type values for > > > the Accounting-Request packet. These packets are sent upon various > > > events of the system. Because it is possible for the accounting > > > request to be lost or significantly delayed we should have provision > > > for interim accounting packets. These interim packets should contain > > > enough information in a single packet so that usage can be as fully > > > reported as possible (lost Stop packets would cause information to > > > only be accurate up to the last interim packet). > > > > Interim accounting is discussed (slightly) in > > http://www.ietf.org/internet-drafts/draft-ietf-radius-acct-interim-01.txt > > Yes, but this defines a new Acct-Status-Type value. What > Acct-Status-Type value does an interim Tunnel-Stop-ish accounting > request contain? Tunnel-Stop (? guess I don't understand the question). The intent is that an accounting request be sent every time a "significant" tunnel-related event occurs, but there is no reason why the tunnel attributes can't be sent in interim accounting requests, too. > > > > My preference would be that the start packets have a start timestamp, > > > interim packets have the start and current timestamp and the stop > > > packets have a start and stop timestamp. By using timestamps instead > > > of just having something like Acct-Session-Time you leave open the > > > possibility of adding additional timestamps for other points of > > > interest in the session (e.q. when was the Tunnel requested vs when > > > did the Tunnel actually come up for data transfer or both timestamps > > > when dual authentication is performed). We use this type of data both > > > for invoicing users and for network operational statistics. By having > > > a series of timestamps for significant points in the state diagram for > > > the process we are able to compute what ever delta time metric we need > > > instead of relying upon only a single elapsed time value. > > > > > > Whether the timestamp has any external meaning is a separate issues > > > which has been discussed before, but these should be in well defined > > > units. Once a timestamp is determined for a particular attribute it > > > should be constant for every accounting packet for a particular > > > Tunnel. > > > > > > Also by putting timestamps in the packets we can eliminate the need to > > > Acct-Delay-Time (although that can be very helpful when attempting to > > > normalize the NAS timestamps to real world time). > > > > There is an attribute called Event-Timestamp described in > > draft-ietf-radius-ext-02 (expired and apparently removed from the IETF > > site). > > Hmm, I only had draft-ietf-radius-ext-00. I just found the latest in > ftp://ftp.ietf.org/internet-drafts/draft-ietf-radius-ext-02.txt. I had only looked at the Web site, from which it is missing (or I just can't see it). - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sat Jan 23 12:27:56 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA25534 for ; Sat, 23 Jan 1999 12:27:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA11835; Sat, 23 Jan 1999 09:19:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA26822 for ietf-radius-outgoing; Sat, 23 Jan 1999 09:19:50 -0800 (PST) From: 45454@osiris.echo.ch Message-Id: <199901231824.TAA16188@osiris.echo.ch> To: user@the-internet.com Date: Sat, 23 Jan 99 09:02:19 EST Subject: (radius) Super Bowl Sunday! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: 45454@osiris.echo.ch Meet me in MiamiGlobal Sports Connection has been accepting online and telephone wagerson sporting events since the 1996 Football season. Our same daypayouts, friendly customer service and convenient online wagering hasmade Global Sports Connection one of the largest and most trustedwagering companies in the world. Global Sports Connection has beenfeatured on MSNBC Power Lunch, GQ Magazine (6/98), Bloomberg News andUSA Today.Global Sports Connection would like to invite you to try our SportsBetting Services on Super Bowl XXXIII. The Denver Broncos arecurrently 7 point favorites over the Atlanta Falcons. Some additionalproposition wagers for the Super Bowl are:The first player to score in the game will be wearing an odd or evennumber on his jersey.Which team will score first or score last. (TD, FG, Safety)Who will be the first player to score.The number of times the chain will be brought on the feild to measurefor a first down.First or last score of the game will be a TD, FG, S! ! ! afety.Will there be a score in the in the last 2:00 minutes of the first half.Please visit our website at http://www.betmaker.com to see theremaining Super Bowl propositions and place your wagers on the game. Have a fantastic Super Bowl Sunday! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Sun Jan 24 19:44:25 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id TAA05815 for ; Sun, 24 Jan 1999 19:44:22 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id QAA04038; Sun, 24 Jan 1999 16:35:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id QAA13289 for ietf-radius-outgoing; Sun, 24 Jan 1999 16:32:56 -0800 (PST) Message-Id: <3.0.2.32.19990125010013.00c8dc90@127.0.0.1> X-Sender: hta@127.0.0.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Mon, 25 Jan 1999 01:00:13 +0100 To: "Bernard Aboba" , "Glen Zorn" , "Beadles, Mark A." , , "Carl Rigney" From: Harald Alvestrand Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <035201be4498$d908e870$1b8939cc@e1kj2.internaut.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Harald Alvestrand At 09:18 20.01.99 -0800, Bernard Aboba wrote: >>- Threats that are appropriate to different scenarios >> > >For PPP-based tunneling (L2TP & PPTP), the threat model is >covered in draft-ietf-pppext-l2tp-security-03.txt. > >I would remind people that in PPP-based tunneling, PPP security is >negotiated between the client and the tunnel server, and covers >the entire length of the path. This is because the client does not >have a way to know that they are being tunneled. Thus, any >security the NAS may negotiate with the tunnel server will occur >in addition to that negotiated between the client and NAS. > >In L2TP compulsory tunneling, this means that PPP encryption >and compression will be negotiated between the client and the >tunnel server. In addition, the NAS may bring up an IPSEC ESP SA >between itself and the tunnel server. This adds protection against >a number of possible attacks which are discussed in the L2TP >security draft. Bernard, these two paragraphs form a completely adequate (to me) security section for the tunnel-impl draft! (Of course, this depends on L2TP always using PPP inside; is this always true?) Glenn, Bernard, is it OK to take this text and put it there? > >This means that it is not correct to say that the NAS is completely >responsible for the security of the tunnel. > >I would also note that people should not assume that the tunneling >will always occur over IP. L2TP can run over non-IP media, such >as Frame Relay and in these cases, it will be common to not have >any NAS-LNS security. > >I would also note that many of the arguments that have been made >here can also be made against IPSEC tunnel mode operating in a >router-router environment. After all, if the router does not set up the >tunnel correctly, then the encapsulated IP packets will be sent in >the clear. It is interesting to note that L2TP is actually *more* secure >than IPSEC tunnel mode in this case, since PPP security can >be negotiated between the client and LNS. > > >>- Available or needed protection mechanisms for each scenario >> > >You are essentially asking for a security analysis for each >tunneling protocol. Absolutely. That is *exactly* what a security section is supposed to be. Or rather, for the tunnel-auth draft: The list of questions that each mode of operation raises, which each tunnelling protocol has to answer. >Such an analysis belongs in the relevant protocol drafts, not in >this set of documents. The answers, yes. The questions, no. >In particular, if there are objections to the use of compulsory >tunneling for L2TP or IPSEC, then these objections should have >been raised to the protocol drafts. To my knowledge they have >not been raised. Failures of others.....the L2TP documents have been yelled at, objected to, commented and asked for revisions of on so many other points (including the need to document numerous security problems) that the particular issues that pertain to operating a NAS box that is not implicitly in the same trust domain as the tunnel endpoint have not been raised. It does not excuse us; WE are the ones responsible for the multi-domain situation. Harald -- Harald Tveit Alvestrand, Maxware, Norway Harald.Alvestrand@maxware.no - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 25 14:06:57 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id OAA24899 for ; Mon, 25 Jan 1999 14:06:55 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id KAA23158; Mon, 25 Jan 1999 10:58:15 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id KAA29617 for ietf-radius-outgoing; Mon, 25 Jan 1999 10:57:01 -0800 (PST) From: n275@ibm.net Date: Mon, 25 Jan 1999 10:51:20 -0800 (PST) Message-Id: <199901251851.KAA22916@magpie.prod.itd.earthlink.net> To: people@ibm.net Subject: (radius) Home Based Wealth Building Opportunity! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: n275@ibm.net What have you done with your dreams? Would you like to achieve financial freedom? As a member of our team you can earn a 6 figure income and travel for pennies on the dollar. *Work from home *78% Profit paid daily *Full support & thorough training from our team *Not MLM *100x more profitable With an honest effort you can earn 2-5k weekly within your FIRST MONTH! Interested? Call 1-800-345-9688 Ext. 2055 24 hour recorded information. No obligation! Please serious inquiries only! To be removed from our mailing list, reply to: Spartucus692@excite.com and enter remove in the subject. Any vulgarity will be filtered and your request for removal will be deleted. THANKS! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Mon Jan 25 23:25:25 1999 Received: from bast.livingston.com ([149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id XAA05093 for ; Mon, 25 Jan 1999 23:25:25 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id UAA11952; Mon, 25 Jan 1999 20:16:31 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id UAA15199 for ietf-radius-outgoing; Mon, 25 Jan 1999 20:16:31 -0800 (PST) Message-ID: <36AD4278.1942C1EF@public.szonline.net> Date: Tue, 26 Jan 1999 12:20:09 +0800 From: Roy X-Mailer: Mozilla 4.5 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: portmaster-radius@livingston.com Subject: (radius) (no subject) Content-Type: multipart/alternative; boundary="------------283443DF3BF61DEA4C1DD9C0" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Roy --------------283443DF3BF61DEA4C1DD9C0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, two question: 1) Radius NT 2.0.1 Beta 14 revision 5, I alway got error in log file, as follow: Sat Jan 16 18:32:30 1999: [204,104] could not cache client datum for host localhost Sat Jan 16 18:32:30 1999: [204,104] could not cache client datum for host 10.253.3.11 I do have entries of localhost and 10.253.3.11 in hosts file In this case, i could use Radius to authenticate the dial-in user of NT 4.0, sp3, using Route and RAS service. 2) I use IBM 2210 as a Radius client to authenticate a telnet user. I do got it. BUT I dont know the authenticated user's level, since IBM 2210's telnet user belong to one of the three levels: administrator, operator, monitor. How could i use profile to define the user of IBM 2210 to authorize some user to be a certain level? Thanks roy yfluo@public.szonline.net --------------283443DF3BF61DEA4C1DD9C0 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, two question:

1) Radius NT 2.0.1 Beta 14 revision 5, I alway got error in log file, as follow:

Sat Jan 16 18:32:30 1999: [204,104] could not cache client datum for host localhost
Sat Jan 16 18:32:30 1999: [204,104] could not cache client datum for host 10.253.3.11

I do have entries of localhost and 10.253.3.11 in hosts file

In this case, i could use Radius to authenticate the dial-in user of NT 4.0, sp3, using Route and RAS service.
 
 

2) I use IBM 2210 as a Radius client to authenticate a telnet user. I do got it. BUT I dont know the authenticated user's level, since IBM 2210's telnet user belong to one of the three levels: administrator, operator, monitor.   How could i use  profile to define the user of IBM 2210 to authorize some user to be a certain level?

Thanks
 

roy

yfluo@public.szonline.net --------------283443DF3BF61DEA4C1DD9C0-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 27 04:06:14 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id EAA21271 for ; Wed, 27 Jan 1999 04:06:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id AAA20480; Wed, 27 Jan 1999 00:56:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA04388 for ietf-radius-outgoing; Wed, 27 Jan 1999 00:56:19 -0800 (PST) From: stephe@catalanaocci.es Date: Wed, 27 Jan 1999 03:53:46 -0500 (EST) Message-Id: <199901270853.DAA16183@en-sam.pcso.com> To: stephe@catalanaocci.es Subject: (radius) $150K+ Per Year / Home-Based / NOT MLM Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: stephe@catalanaocci.es 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:"getlost@tfz.net" Look, we don't want to waste your time.......or ours If you're serious about retiring in the next 2 years with enough income to live the "good life" and not afraid to work for it, we can help you. REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! Please don't bother to call unless you are totally serious. Call today- toll free 1-800-775-0712 Ext 8726 Recorded Message - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 27 06:17:07 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA21996 for ; Wed, 27 Jan 1999 06:17:07 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id DAA21761; Wed, 27 Jan 1999 03:08:33 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id DAA08317 for ietf-radius-outgoing; Wed, 27 Jan 1999 03:10:33 -0800 (PST) Message-Id: <017101be49df$e7d7b240$1b8939cc@e1kj2.internaut.com> From: "Bernard Aboba" To: "Glen Zorn" , "Beadles, Mark A." , , "Carl Rigney" , "Harald Alvestrand" Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Wed, 27 Jan 1999 02:29:20 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-Mimeole: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Bernard Aboba" >Bernard, these two paragraphs form a completely adequate (to me) >security section for the tunnel-impl draft! >(Of course, this depends on L2TP always using PPP inside; is this >always true?) Yes, L2TP always tunnels PPP. >Glenn, Bernard, is it OK to take this text and put it there Yes, it is ok to add the text below to the "Security considerations" section. >Absolutely. >That is *exactly* what a security section is supposed to be. >Or rather, for the tunnel-auth draft: The list of questions that each >mode of operation raises, which each tunnelling protocol has to answer. Such an analysis is supplied for L2TP in the L2TP security draft. Interestingly, while the draft was placed on the standards track by PPPEXT, it has been unclear to me what the IESG wanted to do with it. It was decided not to include it in the L2TP draft proper so as to allow its expedited advancement. Given the questions, I'd suggest that an L2TP security analysis is necessary and needs to be on the standards track. > >>Such an analysis belongs in the relevant protocol drafts, not in >>this set of documents. > >The answers, yes. The questions, no. From the above discussion, I think we can come up with an abreviated list of questions and brief answers relating to compulsory tunneling. >Failures of others.....the L2TP documents have been yelled at, >objected to, commented and asked for revisions of on so many other >points (including the need to document numerous security problems) >that the particular issues that pertain to operating a NAS box that >is not implicitly in the same trust domain as the tunnel endpoint >have not been raised. >It does not excuse us; WE are the ones responsible for the multi-domain >situation. > I'm available to assist in preparing any material relating to L2TP security that the IESG may request. My experience with this is that the issues can be somewhat intricate so that they are worth explaining in detail. These can include subjects as arcane as why L2TP/IPSEC is not compatible with NAT (answer has to do with IKE; if UDP checksumming is turned off and IPSEC ESP is used, L2TP/IPSEC packets should pass the NAT.) - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 27 10:36:18 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA24204 for ; Wed, 27 Jan 1999 10:36:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA26191; Wed, 27 Jan 1999 07:26:48 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA18917 for ietf-radius-outgoing; Wed, 27 Jan 1999 07:28:48 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199901271520.HAA22536@hsmpka.eng.sun.com> Date: Wed, 27 Jan 1999 07:18:19 -0800 To: "Bernard Aboba" , "Harald Alvestrand" , "Carl Rigney" , , "Beadles, Mark A." , "Glen Zorn" Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) > >>Bernard, these two paragraphs form a completely adequate (to me) >>security section for the tunnel-impl draft! >>(Of course, this depends on L2TP always using PPP inside; is this >>always true?) > >Yes, L2TP always tunnels PPP. > >>Glenn, Bernard, is it OK to take this text and put it there > >Yes, it is ok to add the text below to the "Security considerations" >section. > >>Absolutely. >>That is *exactly* what a security section is supposed to be. >>Or rather, for the tunnel-auth draft: The list of questions that each >>mode of operation raises, which each tunnelling protocol has to answer. > >Such an analysis is supplied for L2TP in the L2TP security draft. >Interestingly, while the draft was placed on the standards track by >PPPEXT, it has been unclear to me what the IESG wanted to do >with it. It was decided not to include it in the L2TP draft proper >so as to allow its expedited advancement. Given the questions, >I'd suggest that an L2TP security analysis is necessary and >needs to be on the standards track. > >> >>>Such an analysis belongs in the relevant protocol drafts, not in >>>this set of documents. >> >>The answers, yes. The questions, no. > >From the above discussion, I think we can come up with an >abreviated list of questions and brief answers relating to >compulsory tunneling. > >>Failures of others.....the L2TP documents have been yelled at, >>objected to, commented and asked for revisions of on so many other >>points (including the need to document numerous security problems) >>that the particular issues that pertain to operating a NAS box that >>is not implicitly in the same trust domain as the tunnel endpoint >>have not been raised. >>It does not excuse us; WE are the ones responsible for the multi-domain >>situation. >> > > >I'm available to assist in preparing any material relating >to L2TP security that the IESG may request. My experience >with this is that the issues can be somewhat intricate so that they >are worth explaining in detail. These can include subjects as >arcane as why L2TP/IPSEC is not compatible with NAT (answer >has to do with IKE; if UDP checksumming is turned off and >IPSEC ESP is used, L2TP/IPSEC packets should pass >the NAT.) I am not sure this is true. If the UDP Port numbers are not available to the NAT gateway, how would it work? Perhaps you mean address, and not port translation. However, port translation is really what's used out there today. PatC > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Wed Jan 27 22:16:27 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id WAA11032 for ; Wed, 27 Jan 1999 22:16: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 TAA24082; Wed, 27 Jan 1999 19:08:00 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id TAA24132 for ietf-radius-outgoing; Wed, 27 Jan 1999 19:09:29 -0800 (PST) Date: Wed, 27 Jan 1999 19:00:59 -0800 (PST) From: Glen Zorn To: Patrice Calhoun cc: Bernard Aboba , Harald Alvestrand , Carl Rigney , ietf-radius@livingston.com, "Beadles, Mark A." Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <199901271520.HAA22536@hsmpka.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Wed, 27 Jan 1999, Patrice Calhoun wrote: > > > > >>Bernard, these two paragraphs form a completely adequate (to me) > >>security section for the tunnel-impl draft! > >>(Of course, this depends on L2TP always using PPP inside; is this > >>always true?) > > > >Yes, L2TP always tunnels PPP. > > > >>Glenn, Bernard, is it OK to take this text and put it there > > > >Yes, it is ok to add the text below to the "Security considerations" > >section. > > > >>Absolutely. > >>That is *exactly* what a security section is supposed to be. > >>Or rather, for the tunnel-auth draft: The list of questions that each > >>mode of operation raises, I'm not quite clear on what you mean by 'modes of operation'. > >>which each tunnelling protocol has to answer. Sorry, Harald, but this makes no sense to me: it's like putting the security considerations for every unix command into the man page for rsh. Realistically, that's just what we're doing here: the RADIUS server is telling the NAS to start a tunnel to a certain destination. > > > >Such an analysis is supplied for L2TP in the L2TP security draft. > >Interestingly, while the draft was placed on the standards track by > >PPPEXT, it has been unclear to me what the IESG wanted to do > >with it. It was decided not to include it in the L2TP draft proper > >so as to allow its expedited advancement. Given the questions, > >I'd suggest that an L2TP security analysis is necessary and > >needs to be on the standards track. > > > >> > >>>Such an analysis belongs in the relevant protocol drafts, not in > >>>this set of documents. > >> > >>The answers, yes. The questions, no. > > > >From the above discussion, I think we can come up with an > >abreviated list of questions and brief answers relating to > >compulsory tunneling. > > > >>Failures of others.....the L2TP documents have been yelled at, > >>objected to, commented and asked for revisions of on so many other > >>points (including the need to document numerous security problems) > >>that the particular issues that pertain to operating a NAS box that > >>is not implicitly in the same trust domain as the tunnel endpoint > >>have not been raised. > >>It does not excuse us; WE are the ones responsible for the multi-domain > >>situation. > >> > > > > > >I'm available to assist in preparing any material relating > >to L2TP security that the IESG may request. My experience > >with this is that the issues can be somewhat intricate so that they > >are worth explaining in detail. These can include subjects as > >arcane as why L2TP/IPSEC is not compatible with NAT (answer > >has to do with IKE; if UDP checksumming is turned off and > >IPSEC ESP is used, L2TP/IPSEC packets should pass > >the NAT.) > > I am not sure this is true. If the UDP Port numbers are not available to the > NAT gateway, how would it work? Perhaps you mean address, and not port > translation. However, port translation is really what's used out there today. > > PatC > > > > >- > >To unsubscribe, email 'majordomo@livingston.com' with > >'unsubscribe ietf-radius' in the body of the message. > > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 03:18:09 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id DAA22889 for ; Thu, 28 Jan 1999 03:18:08 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id AAA01186; Thu, 28 Jan 1999 00:08:01 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id AAA06508 for ietf-radius-outgoing; Thu, 28 Jan 1999 00:10:19 -0800 (PST) Message-ID: <000801be4a95$a5f79000$f201800a@langeland.maxware.no> From: "Harald Alvestrand (outlook)" To: "Glen Zorn" , "Patrice Calhoun" Cc: "Bernard Aboba" , "Carl Rigney" , , "Beadles, Mark A." Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts Date: Thu, 28 Jan 1999 09:10:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Harald Alvestrand (outlook)" >> >>Absolutely. >> >>That is *exactly* what a security section is supposed to be. >> >>Or rather, for the tunnel-auth draft: The list of questions that each >> >>mode of operation raises, > >I'm not quite clear on what you mean by 'modes of operation'. > Since there turns out to be only one mode of operation, namely tunnels from the dial-in NAS to a tunnelling server, it doesn't make much sense for me either. >> >>which each tunnelling protocol has to answer. > >Sorry, Harald, but this makes no sense to me: it's like putting the >security considerations for every unix command into the man page for rsh. >Realistically, that's just what we're doing here: the RADIUS server is >telling the NAS to start a tunnel to a certain destination. And there are security issues with making such a tunnel, and those security issues have to be documented. That's all that the hullaballoo has been about so far; haven't you been listening? In particular, this is going to be deployed where the NAS belongs to one organization and the client and the tunnel endpoint belong to another; the security section HAS to document how much these need to trust each other. Harald - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 08:45:40 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id IAA25148 for ; Thu, 28 Jan 1999 08:45:39 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id FAA05298; Thu, 28 Jan 1999 05:37:26 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA16224 for ietf-radius-outgoing; Thu, 28 Jan 1999 05:37:35 -0800 (PST) Message-Id: <199901281334.FAA05266@bast.livingston.com> To: user@the_internet.com Date: Wed, 27 Jan 99 16:02:38 EST From: sadddd@livingston.com Subject: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: sadddd@livingston.com Hi Sexy, I am lonely waiting for you to call me. Let me be the "Little Secret" in your life! WARNING!! These lines are extremely xxx-rated. Adults over 18 only!!! Sex starved girls will give you a hot sexual experience you'll never forget. Not recommended for people with weak hearts or bad backs!!! Call 1-800-HOT-PUSSY(468-7877) $2.99-$4.99 per min. Billed by Teleworld Visa/Mastercard/Amex Must be over 18 Call 1-900-288-LIVE(5483) (US ONLY) Billed as 1-ON-1 on your phone bill $25.00 per call Must be over 18 1-900-451-PUSSY(7877) (Canada) $2.99-$4.99 per min. (US $) CALL NOW!!! CALL NOW!!! CALL NOW!!! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 10:06:17 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA26065 for ; Thu, 28 Jan 1999 10:06:16 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id GAA07191; Thu, 28 Jan 1999 06:57:46 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id GAA19822 for ietf-radius-outgoing; Thu, 28 Jan 1999 06:59:21 -0800 (PST) Message-ID: From: "Varghese, Joe" To: ietf-radius@livingston.com Subject: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius ma iling list? Date: Thu, 28 Jan 1999 08:56:14 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BE4ACD.D7254E50" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Varghese, Joe" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01BE4ACD.D7254E50 Content-Type: text/plain; charset="iso-8859-1" Just wanted to know if anyone else is having the same problem I am - I'm receiving a *lot* of junk e-mail (the latest one advertising an adult oriented content), and it looks like the solicitors got my address via the ietf-radius newsgroup (on the bottom of each one there's an "To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message" message). Is anyone else having this problem? Can someone who's on charge of this mailing list make sure that this kind of junk e-mail doesnt get passed via the list? I've attached a few of the messages just in case it's needed .... Thanks. joe varghese -------------------------------- George (Joe) Varghese varghese@lucent.com (630) 713-9522 ------_=_NextPart_000_01BE4ACD.D7254E50 Content-Type: message/rfc822 Content-Description: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! Content-Location: ATT-0-06402A138CB5D211B2FF00A0C9821DF9-% 28radius%29%20CALL%201-800-HOT-PUSSY.... CALL%20NOW%21%21 Message-ID: <199901281334.FAA05266@bast.livingston.com> From: sadddd@livingston.com Reply-To: sadddd@livingston.com To: the_internet.com!user@server.livingston.com Subject: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! Date: Wed, 27 Jan 1999 15:02:38 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Hi Sexy, I am lonely waiting for you to call me. Let me be the "Little Secret" in your life! WARNING!! These lines are extremely xxx-rated. Adults over 18 only!!! Sex starved girls will give you a hot sexual experience you'll never forget. Not recommended for people with weak hearts or bad backs!!! Call 1-800-HOT-PUSSY(468-7877) $2.99-$4.99 per min. Billed by Teleworld Visa/Mastercard/Amex Must be over 18 Call 1-900-288-LIVE(5483) (US ONLY) Billed as 1-ON-1 on your phone bill $25.00 per call Must be over 18 1-900-451-PUSSY(7877) (Canada) $2.99-$4.99 per min. (US $) CALL NOW!!! CALL NOW!!! CALL NOW!!! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. ------_=_NextPart_000_01BE4ACD.D7254E50 Content-Type: message/rfc822 Content-Description: (radius) $150K+ Per Year / Home-Based / NOT MLM Content-Location: ATT-1-07402A138CB5D211B2FF00A0C9821DF9-% 28radius%29%20$150K+%20Per%20Year%20%2F% 20Home-Based%20%2F%20NOT%20MLM Message-ID: <199901270853.DAA16183@en-sam.pcso.com> From: stephe@catalanaocci.es Reply-To: stephe@catalanaocci.es To: stephe@catalanaocci.es Subject: (radius) $150K+ Per Year / Home-Based / NOT MLM Date: Wed, 27 Jan 1999 02:53:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" 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:"getlost@tfz.net" Look, we don't want to waste your time.......or ours If you're serious about retiring in the next 2 years with enough income to live the "good life" and not afraid to work for it, we can help you. REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! Please don't bother to call unless you are totally serious. Call today- toll free 1-800-775-0712 Ext 8726 Recorded Message - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. ------_=_NextPart_000_01BE4ACD.D7254E50 Content-Type: message/rfc822 Content-Description: (radius) Home Based Wealth Building Opportunity! Content-Location: ATT-2-08402A138CB5D211B2FF00A0C9821DF9-% 28radius%29%20Home%20Based%20Wealth%20Bu ilding%20Opportunity%21 Message-ID: <199901251851.KAA22916@magpie.prod.itd.earthlink.net> From: n275@ibm.net Reply-To: n275@ibm.net To: people@ibm.net Subject: (radius) Home Based Wealth Building Opportunity! Date: Mon, 25 Jan 1999 12:51:20 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" What have you done with your dreams? Would you like to achieve financial freedom? As a member of our team you can earn a 6 figure income and travel for pennies on the dollar. *Work from home *78% Profit paid daily *Full support & thorough training from our team *Not MLM *100x more profitable With an honest effort you can earn 2-5k weekly within your FIRST MONTH! Interested? Call 1-800-345-9688 Ext. 2055 24 hour recorded information. No obligation! Please serious inquiries only! To be removed from our mailing list, reply to: Spartucus692@excite.com and enter remove in the subject. Any vulgarity will be filtered and your request for removal will be deleted. THANKS! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. ------_=_NextPart_000_01BE4ACD.D7254E50 Content-Type: message/rfc822 Content-Description: (radius) Super Bowl Sunday! Content-Location: ATT-3-09402A138CB5D211B2FF00A0C9821DF9-% 28radius%29%20Super%20Bowl%20Sunday%21 Message-ID: <199901231824.TAA16188@osiris.echo.ch> From: 45454@osiris.echo.ch Reply-To: 45454@osiris.echo.ch To: user@the-internet.com Subject: (radius) Super Bowl Sunday! Date: Sat, 23 Jan 1999 08:02:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Meet me in MiamiGlobal Sports Connection has been accepting online and telephone wagerson sporting events since the 1996 Football season. Our same daypayouts, friendly customer service and convenient online wagering hasmade Global Sports Connection one of the largest and most trustedwagering companies in the world. Global Sports Connection has beenfeatured on MSNBC Power Lunch, GQ Magazine (6/98), Bloomberg News andUSA Today.Global Sports Connection would like to invite you to try our SportsBetting Services on Super Bowl XXXIII. The Denver Broncos arecurrently 7 point favorites over the Atlanta Falcons. Some additionalproposition wagers for the Super Bowl are:The first player to score in the game will be wearing an odd or evennumber on his jersey.Which team will score first or score last. (TD, FG, Safety)Who will be the first player to score.The number of times the chain will be brought on the feild to measurefor a first down.First or last score of the game will be a TD, FG, S! ! ! afety.Will there be a score in the in the last 2:00 minutes of the first half.Please visit our website at http://www.betmaker.com to see theremaining Super Bowl propositions and place your wagers on the game. Have a fantastic Super Bowl Sunday! - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. ------_=_NextPart_000_01BE4ACD.D7254E50-- - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 10:16:31 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA26198 for ; Thu, 28 Jan 1999 10:16: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 HAA07687; Thu, 28 Jan 1999 07:08:17 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA20529 for ietf-radius-outgoing; Thu, 28 Jan 1999 07:10:46 -0800 (PST) Message-ID: <36B07F8F.696F6EFD@noln.com> Date: Thu, 28 Jan 1999 10:17:35 -0500 From: Sheryl Hope Shay Organization: National On-Line Network, Inc. X-Mailer: Mozilla 4.5 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Varghese, Joe" CC: ietf-radius@livingston.com Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius mailing list? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Sheryl Hope Shay Yes, Its a really problem with this list. I am considering blocking the domain. This has been going on for a while. They have to be cognizant of this abuse happening. Sheryl Shay National On-Line Network "Varghese, Joe" wrote: > Just wanted to know if anyone else is having the same problem I am - I'm > receiving a *lot* of junk e-mail (the latest one advertising an adult > oriented content), and it looks like the solicitors got my address via the > ietf-radius newsgroup (on the bottom of each one there's an "To unsubscribe, > email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message" message). > > Is anyone else having this problem? Can someone who's on charge of this > mailing list make sure that this kind of junk e-mail doesnt get passed via > the list? > > I've attached a few of the messages just in case it's needed .... > > Thanks. > > joe varghese > > -------------------------------- > George (Joe) Varghese > varghese@lucent.com > (630) 713-9522 > > ------------------------------------------------------------------------ > > Subject: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! > Date: Wed, 27 Jan 1999 15:02:38 -0600 > From: sadddd@livingston.com > To: the_internet.com!user@server.livingston.com > > Hi Sexy, > > I am lonely waiting for you to call me. Let me be the "Little Secret" in > your life! > > WARNING!! > > These lines are extremely xxx-rated. Adults over 18 only!!! Sex starved > girls will give you a hot sexual experience you'll never forget. Not > recommended for people with weak hearts or bad backs!!! > > Call 1-800-HOT-PUSSY(468-7877) > > $2.99-$4.99 per min. Billed by Teleworld > Visa/Mastercard/Amex Must be over 18 > > Call 1-900-288-LIVE(5483) (US ONLY) > > Billed as 1-ON-1 on your phone bill > $25.00 per call Must be over 18 > > 1-900-451-PUSSY(7877) (Canada) > > $2.99-$4.99 per min. (US $) > > CALL NOW!!! CALL NOW!!! CALL NOW!!! > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > > ------------------------------------------------------------------------ > > Subject: (radius) $150K+ Per Year / Home-Based / NOT MLM > Date: Wed, 27 Jan 1999 02:53:46 -0600 > From: stephe@catalanaocci.es > To: stephe@catalanaocci.es > > 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:"getlost@tfz.net" > > Look, we don't want to waste your time.......or ours > > If you're serious about retiring in the next 2 years with enough income > to live the "good life" and not afraid to work for it, we can help you. > > REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! > > Please don't bother to call unless you are totally serious. > > Call today- toll free 1-800-775-0712 Ext 8726 > > Recorded Message > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > > ------------------------------------------------------------------------ > > Subject: (radius) Home Based Wealth Building Opportunity! > Date: Mon, 25 Jan 1999 12:51:20 -0600 > From: n275@ibm.net > To: people@ibm.net > > What have you done with your dreams? > > Would you like to achieve financial freedom? > > As a member of our team you can earn > a 6 figure income and travel for pennies > on the dollar. > > *Work from home > *78% Profit paid daily > *Full support & thorough training from our team > *Not MLM > *100x more profitable > > With an honest effort you can earn 2-5k weekly within > your FIRST MONTH! > > Interested? > > Call 1-800-345-9688 > Ext. 2055 > 24 hour recorded information. > No obligation! > > Please serious inquiries only! > > To be removed from our mailing list, > reply to: Spartucus692@excite.com > and enter remove in the subject. > Any vulgarity will be filtered and your > request for removal will be deleted. > THANKS! > > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. > > ------------------------------------------------------------------------ > > Subject: (radius) Super Bowl Sunday! > Date: Sat, 23 Jan 1999 08:02:19 -0600 > From: 45454@osiris.echo.ch > To: user@the-internet.com > > Meet me in MiamiGlobal Sports Connection has been accepting online and > telephone wagerson sporting events since the 1996 Football season. Our same > daypayouts, friendly customer service and convenient online wagering hasmade > Global Sports Connection one of the largest and most trustedwagering > companies in the world. Global Sports Connection has beenfeatured on MSNBC > Power Lunch, GQ Magazine (6/98), Bloomberg News andUSA Today.Global Sports > Connection would like to invite you to try our SportsBetting Services on > Super Bowl XXXIII. The Denver Broncos arecurrently 7 point favorites over > the Atlanta Falcons. Some additionalproposition wagers for the Super Bowl > are:The first player to score in the game will be wearing an odd or > evennumber on his jersey.Which team will score first or score last. (TD, FG, > Safety)Who will be the first player to score.The number of times the chain > will be brought on the feild to measurefor a first down.First or last score > of the game will be a TD, FG, S! > ! > ! > afety.Will there be a score in the in the last 2:00 minutes of the first > half.Please visit our website at http://www.betmaker.com to see theremaining > Super Bowl propositions and place your wagers on the game. Have a fantastic > Super Bowl Sunday! > - > To unsubscribe, email 'majordomo@livingston.com' with > 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 10:50:58 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA27261 for ; Thu, 28 Jan 1999 10:50:57 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA08712; Thu, 28 Jan 1999 07:33:13 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA22302 for ietf-radius-outgoing; Thu, 28 Jan 1999 07:35:32 -0800 (PST) Message-Id: <3.0.5.32.19990128103526.03005100@fred.xylogics.com> X-Sender: mitton@fred.xylogics.com X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 28 Jan 1999 10:35:26 -0500 To: "Varghese, Joe" , ietf-radius@livingston.com From: Dave Mitton Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius mailing list? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Dave Mitton Yes, everyone receives them, because they are simply posted to the list address, and forwarded to all list subscribers. Hence the bottom note which gets put on all list forwarded mail. Anyone can send anything to the list, there is nothing stopping that. The alternative is to close the list only to subscribers. Then only messages sent from an address in the subscriber list would be accepted at the forwarder. So far the list maintainer has been unwilling (or unable) to take that step (if he can implement it). The downside (besides implementation) is that the list becomes more of a hassle to access. Dave. At 08:56 AM 1/28/99 -0600, Varghese, Joe wrote: > >Just wanted to know if anyone else is having the same problem I am - I'm >receiving a *lot* of junk e-mail (the latest one advertising an adult >oriented content), and it looks like the solicitors got my address via the >ietf-radius newsgroup (on the bottom of each one there's an "To unsubscribe, >email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message" message). > >Is anyone else having this problem? Can someone who's on charge of this >mailing list make sure that this kind of junk e-mail doesnt get passed via >the list? > >I've attached a few of the messages just in case it's needed .... > >Thanks. > >joe varghese > > >-------------------------------- >George (Joe) Varghese >varghese@lucent.com >(630) 713-9522 > > >Content-Type: message/rfc822 >Content-Description: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! >Content-Location: ATT-0-06402A138CB5D211B2FF00A0C9821DF9-% > 28radius%29%20CALL%201-800-HOT-PUSSY.... > CALL%20NOW%21%21 > >Message-ID: <199901281334.FAA05266@bast.livingston.com> >From: sadddd@livingston.com >Reply-To: sadddd@livingston.com >To: the_internet.com!user@server.livingston.com >Subject: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! >Date: Wed, 27 Jan 1999 15:02:38 -0600 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2232.9) >Content-Type: text/plain; > charset="iso-8859-1" > >Hi Sexy, > >I am lonely waiting for you to call me. Let me be the "Little Secret" in >your life! > >WARNING!! > >These lines are extremely xxx-rated. Adults over 18 only!!! Sex starved >girls will give you a hot sexual experience you'll never forget. Not >recommended for people with weak hearts or bad backs!!! > > >Call 1-800-HOT-PUSSY(468-7877) > >$2.99-$4.99 per min. Billed by Teleworld >Visa/Mastercard/Amex Must be over 18 > > >Call 1-900-288-LIVE(5483) (US ONLY) > >Billed as 1-ON-1 on your phone bill >$25.00 per call Must be over 18 > > >1-900-451-PUSSY(7877) (Canada) > >$2.99-$4.99 per min. (US $) > >CALL NOW!!! CALL NOW!!! CALL NOW!!! >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. >Content-Type: message/rfc822 >Content-Description: (radius) $150K+ Per Year / Home-Based / NOT MLM >Content-Location: ATT-1-07402A138CB5D211B2FF00A0C9821DF9-% > 28radius%29%20$150K+%20Per%20Year%20%2F% > 20Home-Based%20%2F%20NOT%20MLM > >Message-ID: <199901270853.DAA16183@en-sam.pcso.com> >From: stephe@catalanaocci.es >Reply-To: stephe@catalanaocci.es >To: stephe@catalanaocci.es >Subject: (radius) $150K+ Per Year / Home-Based / NOT MLM >Date: Wed, 27 Jan 1999 02:53:46 -0600 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2232.9) >Content-Type: text/plain; > charset="iso-8859-1" > > >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:"getlost@tfz.net" > >Look, we don't want to waste your time.......or ours > >If you're serious about retiring in the next 2 years with enough income >to live the "good life" and not afraid to work for it, we can help you. > >REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! > >Please don't bother to call unless you are totally serious. > >Call today- toll free 1-800-775-0712 Ext 8726 > >Recorded Message > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. >Content-Type: message/rfc822 >Content-Description: (radius) Home Based Wealth Building Opportunity! >Content-Location: ATT-2-08402A138CB5D211B2FF00A0C9821DF9-% > 28radius%29%20Home%20Based%20Wealth%20Bu > ilding%20Opportunity%21 > >Message-ID: <199901251851.KAA22916@magpie.prod.itd.earthlink.net> >From: n275@ibm.net >Reply-To: n275@ibm.net >To: people@ibm.net >Subject: (radius) Home Based Wealth Building Opportunity! >Date: Mon, 25 Jan 1999 12:51:20 -0600 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2232.9) >Content-Type: text/plain; > charset="iso-8859-1" > > >What have you done with your dreams? > >Would you like to achieve financial freedom? > >As a member of our team you can earn >a 6 figure income and travel for pennies >on the dollar. > >*Work from home >*78% Profit paid daily >*Full support & thorough training from our team >*Not MLM >*100x more profitable > >With an honest effort you can earn 2-5k weekly within >your FIRST MONTH! > >Interested? > >Call 1-800-345-9688 >Ext. 2055 >24 hour recorded information. >No obligation! > >Please serious inquiries only! > >To be removed from our mailing list, >reply to: Spartucus692@excite.com >and enter remove in the subject. >Any vulgarity will be filtered and your >request for removal will be deleted. >THANKS! > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. >Content-Type: message/rfc822 >Content-Description: (radius) Super Bowl Sunday! >Content-Location: ATT-3-09402A138CB5D211B2FF00A0C9821DF9-% > 28radius%29%20Super%20Bowl%20Sunday%21 > >Message-ID: <199901231824.TAA16188@osiris.echo.ch> >From: 45454@osiris.echo.ch >Reply-To: 45454@osiris.echo.ch >To: user@the-internet.com >Subject: (radius) Super Bowl Sunday! >Date: Sat, 23 Jan 1999 08:02:19 -0600 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2232.9) >Content-Type: text/plain; > charset="iso-8859-1" > >Meet me in MiamiGlobal Sports Connection has been accepting online and >telephone wagerson sporting events since the 1996 Football season. Our same >daypayouts, friendly customer service and convenient online wagering hasmade >Global Sports Connection one of the largest and most trustedwagering >companies in the world. Global Sports Connection has beenfeatured on MSNBC >Power Lunch, GQ Magazine (6/98), Bloomberg News andUSA Today.Global Sports >Connection would like to invite you to try our SportsBetting Services on >Super Bowl XXXIII. The Denver Broncos arecurrently 7 point favorites over >the Atlanta Falcons. Some additionalproposition wagers for the Super Bowl >are:The first player to score in the game will be wearing an odd or >evennumber on his jersey.Which team will score first or score last. (TD, FG, >Safety)Who will be the first player to score.The number of times the chain >will be brought on the feild to measurefor a first down.First or last score >of the game will be a TD, FG, S! >! >! >afety.Will there be a score in the in the last 2:00 minutes of the first >half.Please visit our website at http://www.betmaker.com to see theremaining >Super Bowl propositions and place your wagers on the game. Have a fantastic >Super Bowl Sunday! >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > --------------------------------------------------------------- David Mitton 978-670-8888 Main, [ESN: 248-4570] Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Networks, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 10:51:50 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA27282 for ; Thu, 28 Jan 1999 10:51:49 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA09303; Thu, 28 Jan 1999 07:43:36 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA23118 for ietf-radius-outgoing; Thu, 28 Jan 1999 07:45:11 -0800 (PST) From: Pat.Calhoun@eng.sun.com (Patrice Calhoun) Message-Id: <199901281540.HAA21210@hsmpka.eng.sun.com> Date: Thu, 28 Jan 1999 07:38:29 -0800 To: "Dave Mitton" , , "Varghese, Joe" Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius mailing list? X-Mailer: Sun NetMail 2.2.5 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Pat.Calhoun@eng.sun.com (Patrice Calhoun) >Yes, everyone receives them, because they are simply posted to the list >address, and forwarded to all list subscribers. Hence the bottom note >which gets put on all list forwarded mail. > >Anyone can send anything to the list, there is nothing stopping that. > >The alternative is to close the list only to subscribers. Then only >messages sent from an address in the subscriber list would be accepted at >the forwarder. So far the list maintainer has been unwilling (or unable) >to take that step (if he can implement it). > >The downside (besides implementation) is that the list becomes more of a >hassle to access. I am willing to deal with the hassle if it means that less messages will be sent to my mailbox. PatC > > Dave. > >At 08:56 AM 1/28/99 -0600, Varghese, Joe wrote: >> >>Just wanted to know if anyone else is having the same problem I am - I'm >>receiving a *lot* of junk e-mail (the latest one advertising an adult >>oriented content), and it looks like the solicitors got my address via the >>ietf-radius newsgroup (on the bottom of each one there's an "To unsubscribe, >>email 'majordomo@livingston.com' with >>'unsubscribe ietf-radius' in the body of the message" message). >> >>Is anyone else having this problem? Can someone who's on charge of this >>mailing list make sure that this kind of junk e-mail doesnt get passed via >>the list? >> >>I've attached a few of the messages just in case it's needed .... >> >>Thanks. >> >>joe varghese >> >> >>-------------------------------- >>George (Joe) Varghese >>varghese@lucent.com >>(630) 713-9522 >> >> >>Content-Type: message/rfc822 >>Content-Description: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! >>Content-Location: ATT-0-06402A138CB5D211B2FF00A0C9821DF9-% >> 28radius%29%20CALL%201-800-HOT-PUSSY.... >> CALL%20NOW%21%21 >> >>Message-ID: <199901281334.FAA05266@bast.livingston.com> >>From: sadddd@livingston.com >>Reply-To: sadddd@livingston.com >>To: the_internet.com!user@server.livingston.com >>Subject: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! >>Date: Wed, 27 Jan 1999 15:02:38 -0600 >>MIME-Version: 1.0 >>X-Mailer: Internet Mail Service (5.5.2232.9) >>Content-Type: text/plain; >> charset="iso-8859-1" >> >>Hi Sexy, >> >>I am lonely waiting for you to call me. Let me be the "Little Secret" in >>your life! >> >>WARNING!! >> >>These lines are extremely xxx-rated. Adults over 18 only!!! Sex starved >>girls will give you a hot sexual experience you'll never forget. Not >>recommended for people with weak hearts or bad backs!!! >> >> >>Call 1-800-HOT-PUSSY(468-7877) >> >>$2.99-$4.99 per min. Billed by Teleworld >>Visa/Mastercard/Amex Must be over 18 >> >> >>Call 1-900-288-LIVE(5483) (US ONLY) >> >>Billed as 1-ON-1 on your phone bill >>$25.00 per call Must be over 18 >> >> >>1-900-451-PUSSY(7877) (Canada) >> >>$2.99-$4.99 per min. (US $) >> >>CALL NOW!!! CALL NOW!!! CALL NOW!!! >>- >>To unsubscribe, email 'majordomo@livingston.com' with >>'unsubscribe ietf-radius' in the body of the message. >>Content-Type: message/rfc822 >>Content-Description: (radius) $150K+ Per Year / Home-Based / NOT MLM >>Content-Location: ATT-1-07402A138CB5D211B2FF00A0C9821DF9-% >> 28radius%29%20$150K+%20Per%20Year%20%2F% >> 20Home-Based%20%2F%20NOT%20MLM >> >>Message-ID: <199901270853.DAA16183@en-sam.pcso.com> >>From: stephe@catalanaocci.es >>Reply-To: stephe@catalanaocci.es >>To: stephe@catalanaocci.es >>Subject: (radius) $150K+ Per Year / Home-Based / NOT MLM >>Date: Wed, 27 Jan 1999 02:53:46 -0600 >>MIME-Version: 1.0 >>X-Mailer: Internet Mail Service (5.5.2232.9) >>Content-Type: text/plain; >> charset="iso-8859-1" >> >> >>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:"getlost@tfz.net" >> >>Look, we don't want to waste your time.......or ours >> >>If you're serious about retiring in the next 2 years with enough income >>to live the "good life" and not afraid to work for it, we can help you. >> >>REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! >> >>Please don't bother to call unless you are totally serious. >> >>Call today- toll free 1-800-775-0712 Ext 8726 >> >>Recorded Message >> >>- >>To unsubscribe, email 'majordomo@livingston.com' with >>'unsubscribe ietf-radius' in the body of the message. >>Content-Type: message/rfc822 >>Content-Description: (radius) Home Based Wealth Building Opportunity! >>Content-Location: ATT-2-08402A138CB5D211B2FF00A0C9821DF9-% >> 28radius%29%20Home%20Based%20Wealth%20Bu >> ilding%20Opportunity%21 >> >>Message-ID: <199901251851.KAA22916@magpie.prod.itd.earthlink.net> >>From: n275@ibm.net >>Reply-To: n275@ibm.net >>To: people@ibm.net >>Subject: (radius) Home Based Wealth Building Opportunity! >>Date: Mon, 25 Jan 1999 12:51:20 -0600 >>MIME-Version: 1.0 >>X-Mailer: Internet Mail Service (5.5.2232.9) >>Content-Type: text/plain; >> charset="iso-8859-1" >> >> >>What have you done with your dreams? >> >>Would you like to achieve financial freedom? >> >>As a member of our team you can earn >>a 6 figure income and travel for pennies >>on the dollar. >> >>*Work from home >>*78% Profit paid daily >>*Full support & thorough training from our team >>*Not MLM >>*100x more profitable >> >>With an honest effort you can earn 2-5k weekly within >>your FIRST MONTH! >> >>Interested? >> >>Call 1-800-345-9688 >>Ext. 2055 >>24 hour recorded information. >>No obligation! >> >>Please serious inquiries only! >> >>To be removed from our mailing list, >>reply to: Spartucus692@excite.com >>and enter remove in the subject. >>Any vulgarity will be filtered and your >>request for removal will be deleted. >>THANKS! >> >>- >>To unsubscribe, email 'majordomo@livingston.com' with >>'unsubscribe ietf-radius' in the body of the message. >>Content-Type: message/rfc822 >>Content-Description: (radius) Super Bowl Sunday! >>Content-Location: ATT-3-09402A138CB5D211B2FF00A0C9821DF9-% >> 28radius%29%20Super%20Bowl%20Sunday%21 >> >>Message-ID: <199901231824.TAA16188@osiris.echo.ch> >>From: 45454@osiris.echo.ch >>Reply-To: 45454@osiris.echo.ch >>To: user@the-internet.com >>Subject: (radius) Super Bowl Sunday! >>Date: Sat, 23 Jan 1999 08:02:19 -0600 >>MIME-Version: 1.0 >>X-Mailer: Internet Mail Service (5.5.2232.9) >>Content-Type: text/plain; >> charset="iso-8859-1" >> >>Meet me in MiamiGlobal Sports Connection has been accepting online and >>telephone wagerson sporting events since the 1996 Football season. Our same >>daypayouts, friendly customer service and convenient online wagering hasmade >>Global Sports Connection one of the largest and most trustedwagering >>companies in the world. Global Sports Connection has beenfeatured on MSNBC >>Power Lunch, GQ Magazine (6/98), Bloomberg News andUSA Today.Global Sports >>Connection would like to invite you to try our SportsBetting Services on >>Super Bowl XXXIII. The Denver Broncos arecurrently 7 point favorites over >>the Atlanta Falcons. Some additionalproposition wagers for the Super Bowl >>are:The first player to score in the game will be wearing an odd or >>evennumber on his jersey.Which team will score first or score last. (TD, FG, >>Safety)Who will be the first player to score.The number of times the chain >>will be brought on the feild to measurefor a first down.First or last score >>of the game will be a TD, FG, S! >>! >>! >>afety.Will there be a score in the in the last 2:00 minutes of the first >>half.Please visit our website at http://www.betmaker.com to see theremaining >>Super Bowl propositions and place your wagers on the game. Have a fantastic >>Super Bowl Sunday! >>- >>To unsubscribe, email 'majordomo@livingston.com' with >>'unsubscribe ietf-radius' in the body of the message. >> >--------------------------------------------------------------- >David Mitton 978-670-8888 Main, [ESN: 248-4570] >Consulting Engineer, Nortel Networks 978-916-4570 Direct >Carrier Packet Networks, I&SP Netwks 978-916-4789 FAX >Billerica, MA 01821 dmitton@nortelnetworks.com >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 11:05:06 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA27804 for ; Thu, 28 Jan 1999 11:05:05 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id HAA09907; Thu, 28 Jan 1999 07:56:19 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id HAA24300 for ietf-radius-outgoing; Thu, 28 Jan 1999 07:58:47 -0800 (PST) X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "William Little" To: ietf-radius@livingston.com Message-ID: <86256707.0057BF6F.00@mwgate02.mw.3com.com> Date: Thu, 28 Jan 1999 10:00:21 -0600 Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius mailing list? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "William Little" I also find these messages very irritating. Would it be possible to filter the messages that are forwarded to people on the mailing list? Bill Dave Mitton on 01/28/99 09:35:26 AM Please respond to Dave Mitton To: "Varghese, Joe" , ietf-radius@livingston.com cc: (William Little/MW/US/3Com) Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius mailing list? Yes, everyone receives them, because they are simply posted to the list address, and forwarded to all list subscribers. Hence the bottom note which gets put on all list forwarded mail. Anyone can send anything to the list, there is nothing stopping that. The alternative is to close the list only to subscribers. Then only messages sent from an address in the subscriber list would be accepted at the forwarder. So far the list maintainer has been unwilling (or unable) to take that step (if he can implement it). The downside (besides implementation) is that the list becomes more of a hassle to access. Dave. At 08:56 AM 1/28/99 -0600, Varghese, Joe wrote: > >Just wanted to know if anyone else is having the same problem I am - I'm >receiving a *lot* of junk e-mail (the latest one advertising an adult >oriented content), and it looks like the solicitors got my address via the >ietf-radius newsgroup (on the bottom of each one there's an "To unsubscribe, >email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message" message). > >Is anyone else having this problem? Can someone who's on charge of this >mailing list make sure that this kind of junk e-mail doesnt get passed via >the list? > >I've attached a few of the messages just in case it's needed .... > >Thanks. > >joe varghese > > >-------------------------------- >George (Joe) Varghese >varghese@lucent.com >(630) 713-9522 > > >Content-Type: message/rfc822 >Content-Description: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! >Content-Location: ATT-0-06402A138CB5D211B2FF00A0C9821DF9-% > 28radius%29%20CALL%201-800-HOT-PUSSY.... > CALL%20NOW%21%21 > >Message-ID: <199901281334.FAA05266@bast.livingston.com> >From: sadddd@livingston.com >Reply-To: sadddd@livingston.com >To: the_internet.com!user@server.livingston.com >Subject: (radius) CALL 1-800-HOT-PUSSY....CALL NOW!! >Date: Wed, 27 Jan 1999 15:02:38 -0600 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2232.9) >Content-Type: text/plain; > charset="iso-8859-1" > >Hi Sexy, > >I am lonely waiting for you to call me. Let me be the "Little Secret" in >your life! > >WARNING!! > >These lines are extremely xxx-rated. Adults over 18 only!!! Sex starved >girls will give you a hot sexual experience you'll never forget. Not >recommended for people with weak hearts or bad backs!!! > > >Call 1-800-HOT-PUSSY(468-7877) > >$2.99-$4.99 per min. Billed by Teleworld >Visa/Mastercard/Amex Must be over 18 > > >Call 1-900-288-LIVE(5483) (US ONLY) > >Billed as 1-ON-1 on your phone bill >$25.00 per call Must be over 18 > > >1-900-451-PUSSY(7877) (Canada) > >$2.99-$4.99 per min. (US $) > >CALL NOW!!! CALL NOW!!! CALL NOW!!! >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. >Content-Type: message/rfc822 >Content-Description: (radius) $150K+ Per Year / Home-Based / NOT MLM >Content-Location: ATT-1-07402A138CB5D211B2FF00A0C9821DF9-% > 28radius%29%20$150K+%20Per%20Year%20%2F% > 20Home-Based%20%2F%20NOT%20MLM > >Message-ID: <199901270853.DAA16183@en-sam.pcso.com> >From: stephe@catalanaocci.es >Reply-To: stephe@catalanaocci.es >To: stephe@catalanaocci.es >Subject: (radius) $150K+ Per Year / Home-Based / NOT MLM >Date: Wed, 27 Jan 1999 02:53:46 -0600 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2232.9) >Content-Type: text/plain; > charset="iso-8859-1" > > >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:"getlost@tfz.net" > >Look, we don't want to waste your time.......or ours > >If you're serious about retiring in the next 2 years with enough income >to live the "good life" and not afraid to work for it, we can help you. > >REGARDLESS OF YOUR CURRENT AGE OR YOUR DEBT LOAD! > >Please don't bother to call unless you are totally serious. > >Call today- toll free 1-800-775-0712 Ext 8726 > >Recorded Message > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. >Content-Type: message/rfc822 >Content-Description: (radius) Home Based Wealth Building Opportunity! >Content-Location: ATT-2-08402A138CB5D211B2FF00A0C9821DF9-% > 28radius%29%20Home%20Based%20Wealth%20Bu > ilding%20Opportunity%21 > >Message-ID: <199901251851.KAA22916@magpie.prod.itd.earthlink.net> >From: n275@ibm.net >Reply-To: n275@ibm.net >To: people@ibm.net >Subject: (radius) Home Based Wealth Building Opportunity! >Date: Mon, 25 Jan 1999 12:51:20 -0600 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2232.9) >Content-Type: text/plain; > charset="iso-8859-1" > > >What have you done with your dreams? > >Would you like to achieve financial freedom? > >As a member of our team you can earn >a 6 figure income and travel for pennies >on the dollar. > >*Work from home >*78% Profit paid daily >*Full support & thorough training from our team >*Not MLM >*100x more profitable > >With an honest effort you can earn 2-5k weekly within >your FIRST MONTH! > >Interested? > >Call 1-800-345-9688 >Ext. 2055 >24 hour recorded information. >No obligation! > >Please serious inquiries only! > >To be removed from our mailing list, >reply to: Spartucus692@excite.com >and enter remove in the subject. >Any vulgarity will be filtered and your >request for removal will be deleted. >THANKS! > >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. >Content-Type: message/rfc822 >Content-Description: (radius) Super Bowl Sunday! >Content-Location: ATT-3-09402A138CB5D211B2FF00A0C9821DF9-% > 28radius%29%20Super%20Bowl%20Sunday%21 > >Message-ID: <199901231824.TAA16188@osiris.echo.ch> >From: 45454@osiris.echo.ch >Reply-To: 45454@osiris.echo.ch >To: user@the-internet.com >Subject: (radius) Super Bowl Sunday! >Date: Sat, 23 Jan 1999 08:02:19 -0600 >MIME-Version: 1.0 >X-Mailer: Internet Mail Service (5.5.2232.9) >Content-Type: text/plain; > charset="iso-8859-1" > >Meet me in MiamiGlobal Sports Connection has been accepting online and >telephone wagerson sporting events since the 1996 Football season. Our same >daypayouts, friendly customer service and convenient online wagering hasmade >Global Sports Connection one of the largest and most trustedwagering >companies in the world. Global Sports Connection has beenfeatured on MSNBC >Power Lunch, GQ Magazine (6/98), Bloomberg News andUSA Today.Global Sports >Connection would like to invite you to try our SportsBetting Services on >Super Bowl XXXIII. The Denver Broncos arecurrently 7 point favorites over >the Atlanta Falcons. Some additionalproposition wagers for the Super Bowl >are:The first player to score in the game will be wearing an odd or >evennumber on his jersey.Which team will score first or score last. (TD, FG, >Safety)Who will be the first player to score.The number of times the chain >will be brought on the feild to measurefor a first down.First or last score >of the game will be a TD, FG, S! >! >! >afety.Will there be a score in the in the last 2:00 minutes of the first >half.Please visit our website at http://www.betmaker.com to see theremaining >Super Bowl propositions and place your wagers on the game. Have a fantastic >Super Bowl Sunday! >- >To unsubscribe, email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message. > --------------------------------------------------------------- David Mitton 978-670-8888 Main, [ESN: 248-4570] Consulting Engineer, Nortel Networks 978-916-4570 Direct Carrier Packet Networks, I&SP Netwks 978-916-4789 FAX Billerica, MA 01821 dmitton@nortelnetworks.com - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 12:02:15 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA00530 for ; Thu, 28 Jan 1999 12:02:14 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id IAA12060; Thu, 28 Jan 1999 08:54:00 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id IAA00416 for ietf-radius-outgoing; Thu, 28 Jan 1999 08:56:00 -0800 (PST) Message-ID: <000c01be4af8$22d546a0$2302a212@w9l3l1> From: "=?iso-8859-1?Q?Andr=E9_Zelenkovas?=" To: "Varghese, Joe" , Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius mailing list? Date: Thu, 28 Jan 1999 11:55:15 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "=?iso-8859-1?Q?Andr=E9_Zelenkovas?=" >Is anyone else having this problem? I think everybody is getting the same messages. Perhaps changing the list address might solve part of the problem, if some of the spammers are not subscribed to the list. André - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 12:10:37 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA00980 for ; Thu, 28 Jan 1999 12:10:36 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA12397; Thu, 28 Jan 1999 09:01:07 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA01256 for ietf-radius-outgoing; Thu, 28 Jan 1999 09:03:44 -0800 (PST) Comments: ( Received on motgate2.mot.com from client pobox.mot.com, sender abasi@wdg.mot.com ) X-Authentication-Warning: gautama.ipsg.mot.com: abasi owned process doing -bs Date: Thu, 28 Jan 1999 09:00:17 -0800 (PST) From: Farshad Abasi X-Sender: abasi@gautama To: "Varghese, Joe" cc: ietf-radius@livingston.com Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius ma iling list? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Farshad Abasi I am getting these also.... Please filter out junk mail if possible... --------------------------------------- Farshad Abasi Software Engineer, Motorola Canada Ltd. --------------------------------------- Ph: 241-6149 Fax: 241-6042 Email: abasi@wdg.mot.com --------------------------------------- On Thu, 28 Jan 1999, Varghese, Joe wrote: > >Just wanted to know if anyone else is having the same problem I am - I'm >receiving a *lot* of junk e-mail (the latest one advertising an adult >oriented content), and it looks like the solicitors got my address via the >ietf-radius newsgroup (on the bottom of each one there's an "To unsubscribe, >email 'majordomo@livingston.com' with >'unsubscribe ietf-radius' in the body of the message" message). > >Is anyone else having this problem? Can someone who's on charge of this >mailing list make sure that this kind of junk e-mail doesnt get passed via >the list? > >I've attached a few of the messages just in case it's needed .... > >Thanks. > >joe varghese > > >-------------------------------- >George (Joe) Varghese >varghese@lucent.com >(630) 713-9522 > > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 12:29:46 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id MAA02000 for ; Thu, 28 Jan 1999 12:29:46 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id JAA13530; Thu, 28 Jan 1999 09:19:58 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id JAA03373 for ietf-radius-outgoing; Thu, 28 Jan 1999 09:22:32 -0800 (PST) Message-ID: <36B09C6C.9E746C2F@develcon.com> Date: Thu, 28 Jan 1999 11:20:44 -0600 From: Merlin Hansen Organization: Develcon Electronics X-Mailer: Mozilla 4.05 [en] (X11; I; SunOS 4.1.4 sun4m) MIME-Version: 1.0 To: "ietf-radius@livingston.com" Subject: Re: (radius) Off-topic: Does anyone else recieve junk e-mail via the Radius ma iling list? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Merlin Hansen Filters would, or could, be dificult to maintain do to spammers using multiple fake email addresses and different subject lines. The majordomo list server has the capability to filter out any messages from non-subscribers. This should eliminate the bulk of the junk mail. As for those spammers who actually subscribe, a little creative administration should soon rid us of them also. So the answer to the problem may well be for the list administrator to reconfigure majordomo and then monitor the list periodically to unsubscribe any wannabe-spammers. Merlin. -Hmmm, speaking of non-list-subject related mail, I seem to have generated -one myself! Farshad Abasi wrote: > > I am getting these also.... Please filter out junk mail if possible... > -- | Develcon Electronics | Software Developer | | 856-51 St. E, Saskatoon,| Research and Development Department | | Saskatchewan, Canada. | E-mail : merlin.hansen@develcon.com | | S7K 5C7 | Web Site : http://www.develcon.com | - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 15:09:44 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id PAA08029 for ; Thu, 28 Jan 1999 15:09:43 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id MAA20953; Thu, 28 Jan 1999 12:00:56 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id MAA20922 for ietf-radius-outgoing; Thu, 28 Jan 1999 12:03:03 -0800 (PST) Date: Thu, 28 Jan 1999 11:48:04 -0800 (PST) From: Glen Zorn To: "Harald Alvestrand (outlook)" cc: Patrice Calhoun , Bernard Aboba , Carl Rigney , ietf-radius@livingston.com, "Beadles, Mark A." Subject: Re: (radius) WG LAST CALL on L2TP RADIUS Drafts In-Reply-To: <000801be4a95$a5f79000$f201800a@langeland.maxware.no> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: Glen Zorn On Thu, 28 Jan 1999, Harald Alvestrand (outlook) wrote: > > >> >>Absolutely. > >> >>That is *exactly* what a security section is supposed to be. > >> >>Or rather, for the tunnel-auth draft: The list of questions that each > >> >>mode of operation raises, > > > >I'm not quite clear on what you mean by 'modes of operation'. > > > > Since there turns out to be only one mode of operation, namely > tunnels from the dial-in NAS to a tunnelling server, it doesn't make > much sense for me either. > > >> >>which each tunnelling protocol has to answer. > > > >Sorry, Harald, but this makes no sense to me: it's like putting the > >security considerations for every unix command into the man page for rsh. > >Realistically, that's just what we're doing here: the RADIUS server is > >telling the NAS to start a tunnel to a certain destination. > > > And there are security issues with making such a tunnel, and those > security issues have to be documented. > That's all that the hullaballoo has been about so far; haven't you been > listening? Carefully, I thought. > > In particular, this is going to be deployed where the NAS belongs to one > organization and the client and the tunnel endpoint belong to another; the > security section HAS to document how much these need to trust each other. Certainly, but those issues seem to me to be constant regardless of the type of tunnel created. > > Harald > > > - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 17:04:11 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA09822 for ; Thu, 28 Jan 1999 17:04:10 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id NAA26015; Thu, 28 Jan 1999 13:54:34 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id NAA03201 for ietf-radius-outgoing; Thu, 28 Jan 1999 13:56:45 -0800 (PST) Message-Id: <199901282155.NAA11835@shell4.ba.best.com> Subject: (radius) Think before deciding to close the list To: ietf-radius@livingston.com Date: Thu, 28 Jan 1999 13:55:32 -0800 (PST) From: MegaZone Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-Trade-Organization-1: Internet Service Providers' Consortium (ISP/C) X-Trade-Organization-2: Director At Large X-Mailer: ELM [version 2.4ME+ PL38 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: MegaZone Once upon a time Farshad Abasi shaped the electrons to say... >I am getting these also.... Please filter out junk mail if possible... There is no effective way to filter the junk mail - notice the address for each mail is different. Unless you wanted to make the list moderated - which is a bad idea. First you'd need a moderator, second it would stop all conversation except for spurts when the moderator clears the batch of postings. That is very bad for a discussion list trying to work things out in a timely manner. The list can be closed so that only subscribers can post. I used to run this list, and all of the lists at livingston.com, when I still worked there. In fact, all of the Livingston/Lucent lists *are* run that way. It was only the IETF lists that are not. Why? Because IETF WGs are supposed to be open to anyone to send comments to. It is an open forum. Making it harder for people to send comments, or requiring people to subscribe to the list to do so was considered more detrimental to the spirit of the WG process than the occaisional spam. Personally the spam I get from this list doesn't even register in the sea of email I deal with daily. I don't have a problem hitting the 'd' key and moving on. Before everyone jumps on the 'close the list' bandwagon, I'd seriously think about the tradeoffs. Is avoiding the spam - which doesn't even average one a day - worth turning an IETF WG into a closed forum? For those who don't know, closing the list means you can post *ONLY* from the address that is subscribed. And Majordomo is very picky - it may even reject a different machine name within the same domain. It also means that anyone who reads the RFCs or drafts and tries to send the WG a question will fail - they'd have to subscribe first. Not something people will expect to have to do. Personally I think the cure is worse that the disease in this case. But if the weight of the WG favors closing the list - fine. Just no one complain if you start finding yourself unable to post anything, etc. -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 Thu Jan 28 17:23:18 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA09995 for ; Thu, 28 Jan 1999 17:23:17 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA26989; Thu, 28 Jan 1999 14:14:43 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA05742 for ietf-radius-outgoing; Thu, 28 Jan 1999 14:16:52 -0800 (PST) From: "Mark Beyer" To: "MegaZone" , Subject: RE: (radius) Think before deciding to close the list Date: Thu, 28 Jan 1999 14:14:25 -0800 Message-ID: <000301be4b0b$909415a0$af56e2d0@mbeyer-laptop.hq.freegate.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.2377.0 In-Reply-To: <199901282155.NAA11835@shell4.ba.best.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Mark Beyer" > Is avoiding the spam - which doesn't even > average one a day - worth turning an IETF WG into a closed forum? It was for the dhcp lists, which I believe were closed to non-subscribers due to spam. Mark - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Thu Jan 28 17:58:00 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA10506 for ; Thu, 28 Jan 1999 17:57:59 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id OAA01721; Thu, 28 Jan 1999 14:50:16 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id OAA12512 for ietf-radius-outgoing; Thu, 28 Jan 1999 14:52:47 -0800 (PST) Message-ID: <001e01be4b10$bf116220$c889e9cc@titanium.techapp.com> From: "Russell J. LeBar" To: Subject: Re: (radius) Think before deciding to close the list Date: Thu, 28 Jan 1999 16:51:25 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: "Russell J. LeBar" The spam is only going to get worse. This will have to be done at some point period. Considering we now have a thread going on about the spam I'd have to say the time is now.... -----Original Message----- From: Mark Beyer >> Is avoiding the spam - which doesn't even >> average one a day - worth turning an IETF WG into a closed forum? > >It was for the dhcp lists, which I believe were closed to non-subscribers >due to spam. - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message. From owner-ietf-radius@livingston.com Fri Jan 29 07:12:19 1999 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by ietf.org (8.8.5/8.8.7a) with ESMTP id HAA25397 for ; Fri, 29 Jan 1999 07:12:18 -0500 (EST) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id EAA21440; Fri, 29 Jan 1999 04:03:18 -0800 (PST) Received: (from majordom@localhost) by server.livingston.com (8.8.5/8.6.9) id EAA28512 for ietf-radius-outgoing; Fri, 29 Jan 1999 04:04:07 -0800 (PST) From: ylarotia@NASBPD01BS.ntc.nokia.com (Yla-Rotiala AarneNTC/Boston) To: ietf-radius@livingston.com (ietf-radius) Message-ID: <1999Jan29.065900.1991.455203@rhino.ntc.nokia.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Nokia Telecommunications Date: Fri, 29 Jan 1999 06:58:11 -0500 Subject: RE: (radius) Think before deciding to cl Sender: owner-ietf-radius@livingston.com Precedence: bulk Reply-To: ylarotia@NASBPD01BS.ntc.nokia.com (Yla-Rotiala AarneNTC/Boston) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA25397 Hi! > Personally I think the cure is worse that the disease in this case. But > if the weight of the WG favors closing the list - fine. Just no one > complain if you start finding yourself unable to post anything, etc. I agree with this. Spam from this list is a nuisance, and a small one at that, too. Rgs, Aarne - To unsubscribe, email 'majordomo@livingston.com' with 'unsubscribe ietf-radius' in the body of the message.