From owner-ietf-ppp@merit.edu Fri Sep 6 14:47:42 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 456FE5DDE1; Fri, 6 Sep 2002 14:47:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1956991323; Fri, 6 Sep 2002 14:42:45 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D8D9E91320; Fri, 6 Sep 2002 14:42:44 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 69D1E91324 for ; Fri, 6 Sep 2002 14:41:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 57BF25DE69; Fri, 6 Sep 2002 14:41:51 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from kff (unknown [208.57.187.120]) by segue.merit.edu (Postfix) with ESMTP id 75BD95DDE1 for ; Fri, 6 Sep 2002 14:41:50 -0400 (EDT) Received: from [127.0.0.1] by kff (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Fri, 6 Sep 2002 14:41:22 -0400 Message-Id: <5.1.1.6.2.20020906143304.0408d1f0@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Fri, 06 Sep 2002 14:41:20 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: PPP Bridging Control Protocol (BCP) - Working Group Last Call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is last call. I will advise the area directors that we want to recycle PPP Bridging Control Protocol (BCP) (draft-ietf-pppext-rfc2878bis-01.txt) at Proposed Standard on September 21, 2002 unless there is substantive comment raised on the list. Karl From owner-ietf-ppp@merit.edu Tue Sep 10 05:35:47 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 52E925DDFA; Tue, 10 Sep 2002 05:35:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B5F291253; Tue, 10 Sep 2002 05:35:13 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B22119122F; Tue, 10 Sep 2002 05:35:12 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0AFDE91253 for ; Tue, 10 Sep 2002 05:35:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C8D195DDFF; Tue, 10 Sep 2002 05:35:09 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from emily.fle.fujitsu.com (unknown [193.122.18.249]) by segue.merit.edu (Postfix) with SMTP id B939F5DDFA; Tue, 10 Sep 2002 05:35:08 -0400 (EDT) Received: from 10.142.50.249 by emily.fle.fujitsu.com (InterScan E-Mail VirusWall NT); Tue, 10 Sep 2002 10:36:09 +0100 Received: by fle2.fleblue.fujitsu.com with Internet Mail Service (5.5.2656.59) id ; Tue, 10 Sep 2002 10:32:48 +0100 Message-ID: From: Xin Chen To: "'ietf-ppp@merit.edu'" , "'aaa-wg@merit.edu'" Subject: Question on EAP Date: Tue, 10 Sep 2002 10:32:40 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu 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. ------=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C258AD.01FD9E20" ------_=_NextPart_001_01C258AD.01FD9E20 Content-Type: text/plain Dear all, Sorry for those who get this twice. I am a starter of PPP and related extentions. I have a question based on the case below, An authenticator in a WLAN link uses EAP to authenticate terminals. The authenticator uses AAA (radius or Diameter) to communicate with authentication server. The authentication server is not only providing authentication service but registration services. Once the authentication is successful, the terminal will be considered registered with the network, and services can be provided. And the registration service of the authentication server needs to know the user's status in the network (registered or not). Therefore, it relys on some sort of information reported by the authenticator which is close to the terminals When the terminal powers off, we want the authenticator to detect this and report to the authenitcation server that user is not registered anymore (becuase user has turned off its terminal). The question is does the current WLAN technologies and EAP protocol support this operation. Regards Xin Chen Mobile Network Architecture Fujitsu Laboratories of Europe LTD Tel: +44 (0) 2086064453 Mobile: +44 (0)7775741020 ------_=_NextPart_001_01C258AD.01FD9E20 Content-Type: text/html Message
Dear all,
 
Sorry for those who get this twice. I am a starter of PPP and related extentions. I have a question based on the case below,
 
An authenticator in a WLAN link uses EAP to authenticate terminals. The authenticator uses AAA (radius or Diameter) to communicate with authentication server. The authentication server is not only providing authentication service but registration services. Once the authentication is successful, the terminal will be considered registered with the network, and services can be provided.
 
And the registration service of the authentication server needs to know the user's status in the network (registered or not). Therefore, it relys on some sort of information reported by the authenticator which is close to the terminals
 
When the terminal powers off, we want the authenticator to detect this and report to the authenitcation server that user is not registered anymore (becuase user has turned off its terminal).
 
The question is does the current WLAN technologies and EAP protocol support this operation.
 
Regards
 
Xin Chen
Mobile Network Architecture
Fujitsu Laboratories of Europe LTD
Tel: +44 (0) 2086064453
Mobile: +44 (0)7775741020
 
------_=_NextPart_001_01C258AD.01FD9E20-- ------=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" This e-mail has been scanned by Trend InterScan Software. This e-mail (and its attachment(s) if any) is intended for the named addressee(s) only. It may contain information which is privileged and confidential within the meaning of the applicable law. Unauthorised use, copying or disclosure is strictly prohibited and may be unlawful. If you are not the intended recipient please delete this email and contact the sender via email return. Fujitsu Laboratories of Europe Ltd (FLE) does not accept responsibility for changes made to this email after it was sent. The views expressed in this email may not necessarily be the views held by FLE. Unless expressly stated otherwise, this email does not form part of a legally binding contract or agreement between the recipient and FLE. ------=_NextPartTM-000-f397d7e8-d98a-4315-a009-11f07349b410-- From owner-ietf-ppp@merit.edu Thu Sep 12 02:55:03 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 77A4F5DE37; Thu, 12 Sep 2002 02:55:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CA920913E0; Thu, 12 Sep 2002 02:54:50 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CDF3913DF; Thu, 12 Sep 2002 02:54:50 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CC706913DC for ; Thu, 12 Sep 2002 02:54:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 97D2F5DE37; Thu, 12 Sep 2002 02:54:48 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [193.180.251.47]) by segue.merit.edu (Postfix) with ESMTP id E7FC35DD95; Thu, 12 Sep 2002 02:54:47 -0400 (EDT) Received: from esealnt610.al.sw.ericsson.se (esealnt610.al.sw.ericsson.se [153.88.254.69]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8C6sjRb029568; Thu, 12 Sep 2002 08:54:46 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Thu, 12 Sep 2002 08:51:48 +0200 Message-ID: From: "Jari Arkko (LMF)" To: "'Xin Chen'" , "'ietf-ppp@merit.edu'" , "'aaa-wg@merit.edu'" Subject: RE: Question on EAP Date: Thu, 12 Sep 2002 08:51:41 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This does not seem to be an EAP related function as such. If the given link layer technology gives you an indication of "power off" in some manner, then the access network or the authenticator can send a RADIUS accounting stop or similar message to the home network. So, I don't think EAP is involved. Both RADIUS accounting and DIAMETER should be able to support such notifications in the AAA space. I'm not sure how well WLAN allows you to detect the power-off of a terminal and distinguish it from temporary radio disturbances. Jari -----Original Message----- From: Xin Chen [mailto:x.chen@fle.fujitsu.com] Sent: 10. syyskuuta 2002 12:33 To: 'ietf-ppp@merit.edu'; 'aaa-wg@merit.edu' Subject: Question on EAP Dear all, Sorry for those who get this twice. I am a starter of PPP and related extentions. I have a question based on the case below, An authenticator in a WLAN link uses EAP to authenticate terminals. The authenticator uses AAA (radius or Diameter) to communicate with authentication server. The authentication server is not only providing authentication service but registration services. Once the authentication is successful, the terminal will be considered registered with the network, and services can be provided. And the registration service of the authentication server needs to know the user's status in the network (registered or not). Therefore, it relys on some sort of information reported by the authenticator which is close to the terminals When the terminal powers off, we want the authenticator to detect this and report to the authenitcation server that user is not registered anymore (becuase user has turned off its terminal). The question is does the current WLAN technologies and EAP protocol support this operation. Regards Xin Chen Mobile Network Architecture Fujitsu Laboratories of Europe LTD Tel: +44 (0) 2086064453 Mobile: +44 (0)7775741020 From owner-ietf-ppp@merit.edu Thu Sep 12 21:24:31 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 023B75DE9C; Thu, 12 Sep 2002 21:24:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 411D0912E5; Thu, 12 Sep 2002 21:24:19 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 085F5912E7; Thu, 12 Sep 2002 21:24:18 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06CEA912E5 for ; Thu, 12 Sep 2002 21:24:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D639C5DE94; Thu, 12 Sep 2002 21:24:17 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46]) by segue.merit.edu (Postfix) with ESMTP id 38B595DE89 for ; Thu, 12 Sep 2002 21:24:17 -0400 (EDT) Received: from [127.0.0.1] by kff (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 12 Sep 2002 21:24:07 -0400 Message-Id: <5.1.1.6.2.20020912134307.0378c260@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 12 Sep 2002 21:24:04 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: Implementation Survey for LCP MIB (RFC 1471) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thanks to Mike MacFaden for developing this survey, and my apologies to him for letting it sit on the shelf for so long. Thanks also to Bernard Aboba from whom I lifted most of the introductory text. LCP MIB Implementation Survey Please fill this out and return it to karlfox@columbus.rr.com by October 27, 2002. For the LCP MIB (RFC 1471) to advance to Draft Standard, every feature must have at least two independent implementations, or must be cut from the draft. Please read these directions carefully and email your answers to me directly, not to the list. I only need a reply to this if your implementation is INDEPENDENT, that is, not based on another implementation. If you started out once upon a time with another code base and eventually replaced all the code with fresh code, that counts as independent. If you did your implementation from scratch, better yet. Please provide contact information and fill out the Company, Product and Version fields following their colons, and mark the features with a Y or N *before* the feature, and keep the spelling and order exactly as they are here (so I can automate processing the results). Lines starting with __ and blank lines should not be marked. Lines starting with a # take a numeric or other non-binary response; if you have a number to respond with, put your number before the # sign. Y means you support that feature in your implementation NOW, N means you do not. No fair saying that you'll be adding it later; it has to be in your implementation that's already done and is being used somewhere, although beta or experimental software counts as in use, as long as its actually running. If you make different kinds of devices but they use the same LCP MIB implementation, you only need to send me an entry for one. Thank you, Karl Fox PPPEXT Working Group Chair ---------------------------------------- __ LCP MIB Implementation Survey Contact name: Contact email address: Contact phone number: Company name: Product Name: Product Version: __ Tables Supported pppLinkStatusTable supported pppLinkConfigTable supported read-write pppLinkConfigTable supported, but read-only pppLqrTable supported pppLqrConfigTable supported read-write pppLqrConfigTable supported, but read-only pppLqrExtnsTable supported __ IF-MIB Table behavior For any PPP rows created in the PPP-LCP-MIB do you populate the ifTable __ with ifEntries of ifType ppp(23)? # If you answered N to the previous question, what does your agent return to __ a get of pppLinkStatusPhysicalIndex? From owner-ietf-ppp@merit.edu Thu Sep 12 21:26:53 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id EB41E5DE89; Thu, 12 Sep 2002 21:26:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 789BF912E7; Thu, 12 Sep 2002 21:26:42 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 419E4912E8; Thu, 12 Sep 2002 21:26:42 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 52966912E7 for ; Thu, 12 Sep 2002 21:26:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 452FF5DE94; Thu, 12 Sep 2002 21:26:41 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46]) by segue.merit.edu (Postfix) with ESMTP id CFDD35DE89 for ; Thu, 12 Sep 2002 21:26:40 -0400 (EDT) Received: from [127.0.0.1] by kff (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 12 Sep 2002 21:26:39 -0400 Message-Id: <5.1.1.6.2.20020912141322.03b14d90@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 12 Sep 2002 21:26:36 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: Implementation Survey for PPP Security MIB (RFC 1472) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thanks to Mike MacFaden for developing this survey, and my apologies to him for letting it sit on the shelf for so long. Thanks also to Bernard Aboba from whom I lifted most of the introductory text. PPP Security MIB Implementation Survey Please fill this out and return it to karlfox@columbus.rr.com by October 27, 2002. For the PPP SEC MIB (RFC 1472) to advance to Draft Standard, every feature must have at least two independent implementations, or must be cut from the draft. Please read these directions carefully and email your answers to me directly, not to the list. I only need a reply to this if your implementation is INDEPENDENT, that is, not based on another implementation. If you started out once upon a time with another code base and eventually replaced all the code with fresh code, that counts as independent. If you did your implementation from scratch, better yet. Please provide contact information and fill out the Company, Product and Version fields following their colons, and mark the features with a Y or N *before* the feature, and keep the spelling and order exactly as they are here (so I can automate processing the results). Lines starting with __ and blank lines should not be marked. Lines starting with a # take a numeric or other non-binary response; if you have a number to respond with, put your number before the # sign. Y means you support that feature in your implementation NOW, N means you do not. No fair saying that you'll be adding it later; it has to be in your implementation that's already done and is being used somewhere, although beta or experimental software counts as in use, as long as its actually running. If you make different kinds of devices but they use the same PPP Security MIB implementation, you only need to send me an entry for one. Thank you, Karl Fox PPPEXT Working Group Chair ---------------------------------------- __ PPP Security MIB Implementation Survey Contact name: Contact email address: Contact phone number: Company name: Product Name: Product Version: __ Tables Supported pppSecurityConfigTable supported read-write pppSecurityConfigTable supported, but read-only pppSecuritySecretsTable supported read-write pppSecuritySecretsTable supported, but read-only __ Which OIDs are supported for pppSecuritySecretsProtocol? List them. # OID 1 # OID 2 # OID 3 From owner-ietf-ppp@merit.edu Thu Sep 12 21:33:54 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 138615DE89; Thu, 12 Sep 2002 21:33:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 429BA912EA; Thu, 12 Sep 2002 21:33:46 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09EDC912E8; Thu, 12 Sep 2002 21:33:45 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3F7F4912EC for ; Thu, 12 Sep 2002 21:33:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20E8B5DE94; Thu, 12 Sep 2002 21:33:09 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46]) by segue.merit.edu (Postfix) with ESMTP id A89875DE89 for ; Thu, 12 Sep 2002 21:33:08 -0400 (EDT) Received: from [127.0.0.1] by kff (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 12 Sep 2002 21:32:59 -0400 Message-Id: <5.1.1.6.2.20020912141315.03b13de0@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 12 Sep 2002 21:32:57 -0400 To: ietf-ppp@merit.edu From: Karl Fox Subject: Implementation Survey for IP NCP MIB (RFC 1473) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thanks to Mike MacFaden for developing this survey, and my apologies to him for letting it sit on the shelf for so long. Thanks also to Bernard Aboba from whom I lifted most of the introductory text. IP NCP MIB Implementation Survey Please fill this out and return it to karlfox@columbus.rr.com by October 27, 2002. For the IP NCP MIB (RFC 1473) to advance to Draft Standard, every feature must have at least two independent implementations, or must be cut from the draft. Please read these directions carefully and email your answers to me directly, not to the list. I only need a reply to this if your implementation is INDEPENDENT, that is, not based on another implementation. If you started out once upon a time with another code base and eventually replaced all the code with fresh code, that counts as independent. If you did your implementation from scratch, better yet. Please provide contact information and fill out the Company, Product and Version fields following their colons, and mark the features with a Y or N *before* the feature, and keep the spelling and order exactly as they are here (so I can automate processing the results). Lines starting with __ and blank lines should not be marked. Lines starting with a # take a numeric or other non-binary response; if you have a number to respond with, put your number before the # sign. Y means you support that feature in your implementation NOW, N means you do not. No fair saying that you'll be adding it later; it has to be in your implementation that's already done and is being used somewhere, although beta or experimental software counts as in use, as long as its actually running. If you make different kinds of devices but they use the same IP NCP MIB implementation, you only need to send me an entry for one. Thank you, Karl Fox PPPEXT Working Group Chair ---------------------------------------- __ IP NCP MIB Implementation Survey Contact name: Contact email address: Contact phone number: Company name: Product Name: Product Version: __ Tables Supported pppIpTable supported pppIpConfigTable supported read-write pppIpConfigTable supported, but read-only # What value is returned for pppIpLocalMaxSlotId when __ pppIpLocalToRemoteCompressionProtocol is vj-tcp(2)? # What value is returned for pppIpLocalMaxSlotId when __ pppIpRemoteToLocalCompressionProtocol is vj-tcp(2)? # What value is returned when both of the above are vj-tcp(2)? # What value is returned when none of the above are vj-tcp(2) From owner-ietf-ppp@merit.edu Fri Sep 13 11:26:53 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 8B29D5DF02; Fri, 13 Sep 2002 11:26:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF7AC91205; Fri, 13 Sep 2002 11:26:40 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8F60991315; Fri, 13 Sep 2002 11:26:40 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 811F991205 for ; Fri, 13 Sep 2002 11:26:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B04E5DF02; Fri, 13 Sep 2002 11:26:39 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from tx1.wvinternetservices.com (tx1.wvinternetservices.com [66.118.65.5]) by segue.merit.edu (Postfix) with ESMTP id E7BA65DE07 for ; Fri, 13 Sep 2002 11:26:38 -0400 (EDT) Received: from a (63-144-68-101.citynet.net [63.144.68.101]) by tx1.wvinternetservices.com (8.12.6/8.12.6=Outbound) with SMTP id g8DFW3qO026303 for ; Fri, 13 Sep 2002 11:32:04 -0400 Message-ID: <000701c25b39$baa16cc0$6544903f@a> From: "Bill Cunningham" To: Subject: PPTP Date: Fri, 13 Sep 2002 11:25:00 -0400 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.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Does the PPTP offer a secure layer from spam and people being able to read your e-mail over a search engine only by knowing your email address? From owner-ietf-ppp@merit.edu Fri Sep 13 11:58:09 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 0398F5DF02; Fri, 13 Sep 2002 11:58:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0998191319; Fri, 13 Sep 2002 11:57:56 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6E0A9131A; Fri, 13 Sep 2002 11:57:55 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BD53791319 for ; Fri, 13 Sep 2002 11:57:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9E6AD5DF02; Fri, 13 Sep 2002 11:57:54 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id 1248F5DE07 for ; Fri, 13 Sep 2002 11:57:54 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA02866; Fri, 13 Sep 2002 09:57:53 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA15238; Fri, 13 Sep 2002 11:57:52 -0400 (EDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.12.5+Sun/8.12.5) with ESMTP id g8DFvejT071347; Fri, 13 Sep 2002 11:57:41 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.12.5+Sun/8.12.5/Submit) id g8DFvec8071344; Fri, 13 Sep 2002 11:57:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15746.2803.445721.819877@gargle.gargle.HOWL> Date: Fri, 13 Sep 2002 11:57:39 -0400 From: James Carlson To: "Bill Cunningham" Cc: Subject: Re: PPTP In-Reply-To: Bill Cunningham's message of 13 September 2002 11:25:00 References: <000701c25b39$baa16cc0$6544903f@a> X-Mailer: VM 7.01 under Emacs 21.2.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Bill Cunningham writes: > Does the PPTP offer a secure layer from spam and people being able to read > your e-mail over a search engine only by knowing your email address? PPTP is the Point-to-Point Tunneling Protocol, a proprietary Microsoft mechanism for carrying PPP across an internet. PPP is a link layer protocol that can carry IP datagrams, among other things. The features of PPTP and PPP have no effect whatsoever on email applications. So, the answer would have to be "no." PPTP is often used with MPPE, Microsoft's proprietary encryption scheme. This encrypts the datagrams as they go over the internet. This affects only the packets between the two nodes speaking PPTP, and has no effect at all on the packets once they leave that tunnel on their way to some an email server, search engine, or other node. (On top of all that, if people can read your email on any search engine, then you have much bigger problems than any protocol could ever hope to solve.) Good luck. -- James Carlson, Solaris Networking SUN Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From owner-ietf-ppp@merit.edu Tue Sep 17 08:03:44 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 93B2A5DDB0; Tue, 17 Sep 2002 08:03:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8DADE91239; Tue, 17 Sep 2002 08:03:36 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2102D91247; Tue, 17 Sep 2002 08:03:02 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10E5291239 for ; Tue, 17 Sep 2002 08:02:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CAD7B5DDD3; Tue, 17 Sep 2002 08:02:16 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from ietf.org (unknown [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 50D1B5DDB0 for ; Tue, 17 Sep 2002 08:02:16 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11317; Tue, 17 Sep 2002 08:00:26 -0400 (EDT) Message-Id: <200209171200.IAA11317@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-ppp@merit.edu From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-pppext-rfc2284bis-06.txt Date: Tue, 17 Sep 2002 08:00:26 -0400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Extensible Authentication Protocol (EAP) Author(s) : L. Blunk, J. Vollbrecht, B. Aboba Filename : draft-ietf-pppext-rfc2284bis-06.txt Pages : 31 Date : 2002-9-16 This document defines the Extensible Authentication Protocol (EAP), an authentication protocol which supports multiple authentication mechanisms. EAP typically runs directly over the link layer without requiring IP and therefore includes its own support for in-order delivery and retransmission. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. While EAP was originally developed for use with PPP, it is also now in use with IEEE 802. This document obsoletes RFC 2284. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-rfc2284bis-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-rfc2284bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-16152020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-rfc2284bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-rfc2284bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-16152020.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp@merit.edu Wed Sep 25 11:33:24 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 54A7E5DDB4; Wed, 25 Sep 2002 11:33:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45DAE912C4; Wed, 25 Sep 2002 11:32:22 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 429DA912C2; Wed, 25 Sep 2002 11:32:15 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7EAF0912C5 for ; Wed, 25 Sep 2002 11:32:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 68DEB5DE43; Wed, 25 Sep 2002 11:32:09 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46]) by segue.merit.edu (Postfix) with ESMTP id D1A1D5DDB4 for ; Wed, 25 Sep 2002 11:32:08 -0400 (EDT) Received: from [127.0.0.1] by kff (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 25 Sep 2002 09:48:14 -0400 Message-Id: <5.1.1.6.2.20020925094531.03ccee80@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 25 Sep 2002 09:48:11 -0400 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: PPP Bridging Control Protocol (BCP) recycled at Proposed Standard Cc: ietf-ppp@merit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that PPP Bridging Control Protocol (BCP), draft-ietf-pppext-rfc2878bis-01.txt, be recycled at Proposed Standard. Karl From owner-ietf-ppp@merit.edu Wed Sep 25 14:08:24 2002 Return-Path: Delivered-To: ietf-ppplog@merit.edu Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by segue.merit.edu (Postfix) with ESMTP id 38A4E5DE6C; Wed, 25 Sep 2002 14:08:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F108912B1; Wed, 25 Sep 2002 14:08:12 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3AA49912B3; Wed, 25 Sep 2002 14:08:12 -0400 (EDT) Delivered-To: ietf-ppp@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4B11E912B1 for ; Wed, 25 Sep 2002 14:08:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3A1C85DE69; Wed, 25 Sep 2002 14:08:11 -0400 (EDT) Delivered-To: ietf-ppp@merit.edu Received: from kff (dhcp93127046.columbus.rr.com [24.93.127.46]) by segue.merit.edu (Postfix) with ESMTP id 9F91F5DE61 for ; Wed, 25 Sep 2002 14:08:10 -0400 (EDT) Received: from [127.0.0.1] by kff (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 25 Sep 2002 14:07:38 -0400 Message-Id: <5.1.1.6.2.20020925140628.00ace6d0@pop-server.columbus.rr.com> X-Sender: karlfox@pop-server.columbus.rr.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 25 Sep 2002 14:07:35 -0400 To: Thomas Narten , Erik Nordmark From: Karl Fox Subject: PPP Bridging Control Protocol (BCP) recycled at Proposed Standard Cc: ietf-ppp@merit.edu, iesg-secretary@ietf.org In-Reply-To: References: <"Your message with ID" <5.1.1.6.2.20020925094531.03ccee80@pop-server.columbus.rr.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Thomas and Erik, The PPPEXT Working Group recommends that PPP Bridging Control Protocol (BCP), draft-ietf-pppext-rfc2878bis-01.txt, be recycled at Proposed Standard. Karl