From owner-ietf-ppp-outgoing@merit.edu Fri Aug 4 12:48:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14383 for ; Fri, 4 Aug 2000 12:48:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 18AC65DDF1; Fri, 4 Aug 2000 12:45:46 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 058BB5DDEB; Fri, 4 Aug 2000 12:45:45 -0400 (EDT) Received: from smtpproxy1.mitre.org (mbunix.mitre.org [129.83.20.100]) by segue.merit.edu (Postfix) with ESMTP id 4FCB45DDB5 for ; Fri, 4 Aug 2000 12:45:43 -0400 (EDT) Received: from avsrv1.mitre.org (avsrv1.mitre.org [129.83.20.58]) by smtpproxy1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA11055; Fri, 4 Aug 2000 12:45:38 -0400 (EDT) Received: from linus.mitre.org (linus.mitre.org [129.83.10.1]) by smtpsrv1.mitre.org (8.9.3/8.9.3) with ESMTP id MAA26092; Fri, 4 Aug 2000 12:43:26 -0400 (EDT) Received: from mitre.org (threshold.mitre.org [129.83.114.30]) by linus.mitre.org (8.9.3/8.9.3) with ESMTP id MAA09730; Fri, 4 Aug 2000 12:45:34 -0400 (EDT) Message-ID: <398AF32F.8988EC51@mitre.org> Date: Fri, 04 Aug 2000 12:45:35 -0400 From: Jonathan Herzog X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp@merit.edu, "Kim D. Morgenstern" Subject: Security concerns with PPP-EAP-TLS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Below is an excerpt from a short report on the security of EAP-TLS. The full report will be available, sometime next week, at http://www.mitre.org/support/papers/ (The rest of the report is merely background and unnecessary for those familiar with both TLS and EAP.) Comments invited. ------------------------------------------------------------------ Some Security Concerns Regarding PPP--EAP--TLS (Copyright 2000 The MITRE Corporation. All Rights Reserved.) MP 00B0000019 Jonathan Herzog jherzog@mitre.org 4. TLS in PPP In RFC 2716, it is recommended that TLS be added to the authentication mechanisms available for use in PPP, and suggests a way in which TLS can be embedded within EAP. In fact, this embedding is very simple: TLS already specifies the formats that its messages take, so these messages are simply sent as the data of PPP packets. In PPP--EAP--TLS, TLS is executed only until the end of the first run of the Handshake protocol. At that point, the authentication has finished, the shared secret has been exchanged, and the underlying Record protocol has been initialized and is providing a secure tunnel. In PPP, however the authentication phase and the encryption phase are distinct; all that PPP requires from TLS is authentication and a shared secret. Hence, the secure tunnel provided by TLS is abandoned, and the shared secret stored for use by ECP. Although PPP does not guarantee reliability, this does not seem to compromise the security of TLS. (In fact, since TLS is designed to be secure against active attacks (i.e., those that disrupt or forge messages), vulnerability to packet loss would indicate a serious design flaw.) What could be troubling, however, is the fact that PPP is a peer-to-peer connection while TLS is based on a client-server model. Except for PPP--EAP--TLS, all EAP protocols provide authentication in one direction only. Two simultaneous authentication protocols, therefore, would not conflict. TLS, however, can provide mutual authentication, and it is unclear what should happen when it is requested by both sides. The desirable behavior, of course, would be for both requests to collapse into a single run of the protocol, using mutual authentication. However, the specification seems to allow the possibility of two independent runs of TLS. If this happens, then at their completion the PPP connection will have two separate shared secrets and two (possibly distinct) cryptosuites. PPP--EAP--TLS specifies how one shared secret is used to generate the keys necessary for ECP, but not how to pick which of the two shared secrets or cryptosuites are to be used. Another related oddity is that the role of the authenticator in PPP--EAP--TLS does not map directly to the role of authenticator in other authentication protocols. Elsewhere, the authenticator is the one receiving the authentication; the peer proves its identity to the authenticator. But in PPP--EAP--TLS, the authenticator takes on the role of server, and as mentioned above, it is possible for authentication in TLS to be server--to--client only. And while in PPP--EAP--TLS (as opposed to TLS) the client is required to authenticate itself when the server requests such, the server is not required to request. So, the authenticator can now request an authentication mechanism by which it is authenticated to the peer but not vice versa. Also, there appears to be a large disconnect between PPP--EAP--TLS and ECP. During PPP--EAP--TLS, the client and server negotiate a set of cryptographic algorithms, and according to the specification, any subsequent run of ECP is required negotiate those same algorithms. This raises several potential sources of concern, however. 1) First, all cryptosuites defined in TLS require that a keyed MAC be added whenever encryption is used. However, none of the encryption algorithms defined for ECP have any type of integrity check. It is therefore impossible for ECP to negotiate the exact cryptosuite which was agreed upon in TLS. This is easily fixed by defining ECP protocols to match the TLS cryptosuites, but no such protocols are defined at this time. 2) Even if ECP performs the most natural action and uses the encryption algorithm from the TLS cryptosuite, problems remain. ECP is designed to be extensible; theoretically, ECP can negotiate any algorithm mutually acceptable to both parties. However, TLS is not similarly extensible; the list of cryptosuites available to TLS are enumerated in the specifications, and to use any cryptosuites not on that list would mean either revising or deviating from the standard. In other words, compliant implementations of ECP will no longer be able to use private or proprietary algorithms when EAP--TLS is used for authentication. 3) Lastly, this requirement---that ECP use the algorithm negotiated in TLS---potentially undermines the basic design of PPP. In the original design of PPP, authentication and encryption are negotiated and enacted in separate phases. If TLS is used as proposed, however, the negotiation of encryption has been transplanted from ECP to the earlier phase of EAP. While this may not necessarily introduce any weaknesses, it does significantly change the design of PPP. 5. Summary and Suggestions The use of TLS as an authentication mechanism is an excellent idea. However, some minor issues should be addressed before it should be used. In particular, it would be advisable for the authenticator to play the role of client (rather than server), to bring EAP--TLS into concordance with the way those roles are used in other EAP protocols. Also, the specification should resolve the ambiguity that results when both sides request TLS. It would be simpler to require that both requests be merged into a single run of the protocol, but if the specification wishes to allow simultaneous runs it should describe how to choose between the resulting secrets and cryptosuites. Lastly, EAP--TLS raises three concerns about ECP: * First, EAP--TLS relocates cryptosuite negotiation from ECP to EAP. While this may be a change for the better, it is still a significant alteration to the design of PPP and may deserve further consideration. * Second, it highlights the fact that no defined ECP protocol includes a keyed MAC for integrity. While this is not a problem caused by EAP--TLS, it is still serious enough to warrant note. * Third, it prohibits ECP from using any cryptosuite that cannot be negotiated in TLS, including all private algorithms. The solution to the last two concerns above would seem simple and two-fold. First, ECP cryptosuites that include integrity protection should be defined. Ideally, these would include all the cryptosuites defined in the TLS specification. Second, the list of cryptosuites available to TLS should be expanded to include all ECP cryptosuites. The TLS specifications explicitly allows subsequent standards to expand the list of cryptosuites; the EAP--TLS specification should map ECP cryptosuites to a set of TLS cryptosuites which may only be available during EAP--TLS. -- Jonathan C. Herzog | business: jherzog@mitre.org | "Television is #include | pleasure: jherzog@iname.com | furniture." From owner-ietf-ppp-outgoing@merit.edu Fri Aug 11 08:25:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11561 for ; Fri, 11 Aug 2000 08:25:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 965CC5DE10; Fri, 11 Aug 2000 08:24:29 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 86A945DE0C; Fri, 11 Aug 2000 08:24:29 -0400 (EDT) Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id C8DC85DDFB for ; Fri, 11 Aug 2000 08:24:27 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id FAA11936 for ; Fri, 11 Aug 2000 05:24:26 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id FAA16120 for ; Fri, 11 Aug 2000 05:24:21 -0700 (MST)] Received: from dhruva.miel.mot.com (dhruva.miel.mot.com [217.1.125.31]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id RAA23881 for ; Fri, 11 Aug 2000 17:59:10 +0530 (IST) Received: from miel.mot.com (dhruva.miel.mot.com [217.1.125.31]) by dhruva.miel.mot.com (8.9.1/8.9.1) with ESMTP id RAA05817 for ; Fri, 11 Aug 2000 17:51:11 +0530 (IST) Message-ID: <3993EFB5.5198B457@miel.mot.com> Date: Fri, 11 Aug 2000 17:51:09 +0530 From: Muralidhar Rayapeddi X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp Subject: Termination of a PPP link. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit hi, I have a scenario where the LCP, IPCP & CCP negotiations have gone to the OPENED state & the link is up. Now when the administrator wants to down the link (sends CLOSE & DOWN event) then does that mean there is a CCP terminate req, ack getting exchanged, IPCP term req, ack getting exchanged and finally lcp term req & ack. Please clarify. Thanks, Murali. From owner-ietf-ppp-outgoing@merit.edu Fri Aug 11 08:32:58 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11957 for ; Fri, 11 Aug 2000 08:32:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C7BBF5DE23; Fri, 11 Aug 2000 08:31:11 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AB7915DE25; Fri, 11 Aug 2000 08:31:11 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id EE4845DE23 for ; Fri, 11 Aug 2000 08:31:09 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA24214; Fri, 11 Aug 2000 06:31:07 -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,v1.7) with ESMTP id IAA17182; Fri, 11 Aug 2000 08:31:07 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id IAA05708; Fri, 11 Aug 2000 08:31:07 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14739.61963.431402.349894@gargle.gargle.HOWL> Date: Fri, 11 Aug 2000 08:31:07 -0400 (EDT) From: James Carlson To: Muralidhar Rayapeddi Cc: ietf-ppp Subject: Re: Termination of a PPP link. In-Reply-To: Muralidhar Rayapeddi's message of 11 August 2000 17:51:09 References: <3993EFB5.5198B457@miel.mot.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Muralidhar Rayapeddi writes: > I have a scenario where the LCP, IPCP & CCP negotiations have gone > to the OPENED state & the link is up. Now when the administrator wants > to down the link (sends CLOSE & DOWN event) then does that mean > there is a CCP terminate req, ack getting exchanged, IPCP term req, ack > getting exchanged and finally lcp term req & ack. While it's certainly legal to do that, there's no need for it. Most implementations send only LCP Terminate-Request in order to shut down a link. Even that much is not required -- you can just drop carrier if you want (assuming, of course, that the physical layer you're using has some notion of "carrier detect"). Also, for what it's worth, there's no reason to serialize the NCPs. You could (if you chose to) shut down IPCP and CCP at the same time by sending IPCP Terminate-Request and CCP Terminate-Request. You don't have to wait for Terminate-Ack before shutting down another NCP. There's also no implied ordering to the NCPs. You do not have to shut them down in the order in which you brought them up. -- James Carlson, Internet Engineering 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 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Aug 14 13:37:03 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15533 for ; Mon, 14 Aug 2000 13:37:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 76B655DDB2; Mon, 14 Aug 2000 13:36:35 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 659B95DDB1; Mon, 14 Aug 2000 13:36:35 -0400 (EDT) Received: from hl.egroups.com (hl.egroups.com [208.50.99.197]) by segue.merit.edu (Postfix) with SMTP id 933CA5DDA8 for ; Mon, 14 Aug 2000 13:36:33 -0400 (EDT) X-eGroups-Return: kollerm@ttc.com Received: from [10.1.10.108] by hl.egroups.com with NNFMP; 14 Aug 2000 17:36:33 -0000 Date: Mon, 14 Aug 2000 17:36:30 -0000 From: "Michael Koller" To: ietf-ppp@merit.edu Subject: Do LERs/LSRs Perform PPP Negotiation ? Message-ID: <8n9amu+fov3@eGroups.com> User-Agent: eGroups-EW/0.82 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Mailer: eGroups Message Poster X-Originating-IP: 157.234.250.2 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This may be off-topic. If so, let me know. Here goes: Since PoS uses PPP as its datalink, is it true that every PoS router perform PPP LCP/NCP negotiation? Or do routers just use the PPP packet format for transport without any link or network negotiation? Thanks. From owner-ietf-ppp-outgoing@merit.edu Mon Aug 14 13:44:17 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15774 for ; Mon, 14 Aug 2000 13:44:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1BDA65DDB1; Mon, 14 Aug 2000 13:43:50 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E4E4A5DDB7; Mon, 14 Aug 2000 13:43:49 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id DFB5B5DDB1 for ; Mon, 14 Aug 2000 13:43:47 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA28124; Mon, 14 Aug 2000 11:43:45 -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,v1.7) with ESMTP id NAA00273; Mon, 14 Aug 2000 13:43:44 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id NAA08906; Mon, 14 Aug 2000 13:43:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14744.12241.657260.82421@gargle.gargle.HOWL> Date: Mon, 14 Aug 2000 13:43:45 -0400 (EDT) From: James Carlson To: "Michael Koller" Cc: ietf-ppp@merit.edu Subject: Re: Do LERs/LSRs Perform PPP Negotiation ? In-Reply-To: Michael Koller's message of 14 August 2000 17:36:30 References: <8n9amu+fov3@eGroups.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Michael Koller writes: > Since PoS uses PPP as its datalink, is it true that every PoS router > perform PPP LCP/NCP negotiation? Generally, yes, as long as they conform with the standards. There are other things (such as SRP) that run Packet-over-SONET without using PPP. > Or do routers just use the PPP > packet format for transport without any link or network negotiation? No. If you're using PPP, you must negotiate LCP and (if you're an LER or LSR) IPCP and MPLSCP. Avoiding accidental misconfiguration is a Good Thing; that's what PPP negotiation is for. More to the point -- I don't know of any routers that claim to do PPP without negotiating and I know several that do negotiate. I can't say I know all of the implementations that exist. Perhaps there are also broken ones out there ... -- James Carlson, Internet Engineering 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 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Aug 16 11:33:26 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28130 for ; Wed, 16 Aug 2000 11:33:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D9BD5DD9C; Wed, 16 Aug 2000 11:30:59 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 4B9C25DDBF; Wed, 16 Aug 2000 11:30:59 -0400 (EDT) Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 83D195DD9C for ; Wed, 16 Aug 2000 11:30:57 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id IAA03239 for ; Wed, 16 Aug 2000 08:30:56 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA25763 for ; Wed, 16 Aug 2000 08:30:55 -0700 (MST)] Received: from dhruva.miel.mot.com (dhruva.miel.mot.com [217.1.125.31]) by miel.mot.com (8.9.3/8.9.3) with ESMTP id VAA15845 for ; Wed, 16 Aug 2000 21:05:47 +0530 (IST) Received: from miel.mot.com (dhruva.miel.mot.com [217.1.125.31]) by dhruva.miel.mot.com (8.9.1/8.9.1) with ESMTP id UAA18847 for ; Wed, 16 Aug 2000 20:57:49 +0530 (IST) Message-ID: <399AB2F5.817631B0@miel.mot.com> Date: Wed, 16 Aug 2000 20:57:49 +0530 From: Muralidhar Rayapeddi X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: ietf-ppp Subject: case of failure negotiations on ppp Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit I am bugging with fsm details in this, sorry about that. hi, I have two processes running at application level simulating ppp. I want to execute a failure case where one of the ppp stack does not respond to lcp config request but sends lcp cfg req & ack. call this as pppA pppB is a normal guy. According to fsm pppA sends a lcp req and does not process pppB's lcp req. It receives ack from pppB & so moves to ack rcvd state (7). In this state if timer expires for A then it sends a lcp cfg req & moves to req sent state (6). If it again receives an ack for this req, it does an irc and moves to (7). So the timer expiry does not have effect, b'cos every time the restart counter gets initialized. I think this looks like a while (1) Now we will take pppB's case. It receives a req, sends a req & correspondingly sends an ack. It will move to ack sent state (8). But it does not get a response for the request it sent, b'cos pppA didn't process it. This times out, keeps sending lcp req and when the timer expires it says tlf & goes to stopped state (3). Here if pppA sends a lcp cfg req (as it does), then according to fsm, it does an irc,src,sca and moves to (8). So pppB also continues in this loop. So when does the link termination happen. Please clarify. Regards, Murali. From owner-ietf-ppp-outgoing@merit.edu Wed Aug 16 11:41:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28369 for ; Wed, 16 Aug 2000 11:41:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B78A75DD93; Wed, 16 Aug 2000 11:41:29 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A01BD5DDAD; Wed, 16 Aug 2000 11:41:29 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id E2F575DD93 for ; Wed, 16 Aug 2000 11:41:27 -0400 (EDT) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA21277; Wed, 16 Aug 2000 09:41:20 -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,v1.7) with ESMTP id LAA21557; Wed, 16 Aug 2000 11:41:09 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id LAA12356; Wed, 16 Aug 2000 11:41:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14746.46614.18641.177741@gargle.gargle.HOWL> Date: Wed, 16 Aug 2000 11:41:10 -0400 (EDT) From: James Carlson To: Muralidhar Rayapeddi Cc: ietf-ppp Subject: Re: case of failure negotiations on ppp In-Reply-To: Muralidhar Rayapeddi's message of 16 August 2000 20:57:49 References: <399AB2F5.817631B0@miel.mot.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Muralidhar Rayapeddi writes: > If it again receives an ack for this req, it does an irc and moves to > (7). So the > timer expiry does not have effect, b'cos every time the restart counter > gets > initialized. I think this looks like a while (1) Right. There are many of these cases in PPP. Decent implementations have to have additional counters and timers to detect and eliminate loops. See section 4.5 of RFC 1661. > So when does the link termination happen. Please clarify. The RFCs do not cover all possible things that need to be done to make a stable and resilient implementation. -- James Carlson, Internet Engineering 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 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Wed Aug 16 13:54:04 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01035 for ; Wed, 16 Aug 2000 13:54:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BD5875DDDF; Wed, 16 Aug 2000 13:53:35 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A4B705DDF1; Wed, 16 Aug 2000 13:53:35 -0400 (EDT) Received: from postman.nlc.com (postman.nlc.com [209.204.132.16]) by segue.merit.edu (Postfix) with ESMTP id 4AF8A5DDDF for ; Wed, 16 Aug 2000 13:53:33 -0400 (EDT) Received: from exchange3.nlc.com (exchange3.nlc.com [10.0.0.83]) by postman.nlc.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id e7GHraQ23892 for ; Wed, 16 Aug 2000 10:53:40 -0700 (PDT) Received: by exchange3.nlc.com with Internet Mail Service (5.5.2650.21) id ; Wed, 16 Aug 2000 10:56:58 -0700 Message-ID: <5F26C476B78BD31199E1009027B11DCAB2BED6@exchange3.nlc.com> From: "Kendall, Greg" To: ietf-ppp Subject: two questions about PAP Date: Wed, 16 Aug 2000 10:56:51 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu In the following interaction: > PAP AUTH_REQ(ID 1)-----------------------> time out PAP AUTH_REQ(ID 2)-----------------------> > <-------------------------------PAP AUTH_ACK (ID 1) > Should the ID have been incremented in the timeout retransmission? Should the AUTH_ACK with the previous ID be ignored or accepted? Thanks for your comments. From owner-ietf-ppp-outgoing@merit.edu Wed Aug 16 14:03:16 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01242 for ; Wed, 16 Aug 2000 14:03:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0607E5DDF9; Wed, 16 Aug 2000 14:00:30 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id E6E425DDF6; Wed, 16 Aug 2000 14:00:29 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id 0E5365DDD9 for ; Wed, 16 Aug 2000 14:00:28 -0400 (EDT) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA10619; Wed, 16 Aug 2000 11:00:16 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA08609; Wed, 16 Aug 2000 14:00:14 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id OAA12611; Wed, 16 Aug 2000 14:00:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14746.54960.499774.517878@gargle.gargle.HOWL> Date: Wed, 16 Aug 2000 14:00:16 -0400 (EDT) From: James Carlson To: "Kendall, Greg" Cc: ietf-ppp Subject: Re: two questions about PAP In-Reply-To: Kendall, Greg's message of 16 August 2000 10:56:51 References: <5F26C476B78BD31199E1009027B11DCAB2BED6@exchange3.nlc.com> X-Mailer: VM 6.75 under Emacs 20.7.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Kendall, Greg writes: > PAP AUTH_REQ(ID 1)-----------------------> > time out > PAP AUTH_REQ(ID 2)-----------------------> > > <-------------------------------PAP AUTH_ACK (ID 1) > Should the ID have been incremented in the timeout retransmission? Yes. RFC 1334 states this as a "MUST." > Should the AUTH_ACK with the previous ID be ignored or accepted? It might be ignored, but I wouldn't be unhappy with an implementation that accepted it. PAP Authenticate-Ack means only that the peer is happy with your identity. There's no reason to be picky about this message or to torture your peer with repeated PAP Authenticate-Request messages as long as one was accepted. There's no reduction in security caused by proceeding at this point. -- James Carlson, Internet Engineering 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 "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Thu Aug 31 03:17:55 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01116 for ; Thu, 31 Aug 2000 03:17:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6641B5DDA6; Thu, 31 Aug 2000 03:15:36 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1659F5DDB4; Thu, 31 Aug 2000 03:15:36 -0400 (EDT) Received: from smtp2.mail.yahoo.com (smtp2.mail.yahoo.com [128.11.68.32]) by segue.merit.edu (Postfix) with SMTP id E9F765DDA6 for ; Thu, 31 Aug 2000 03:15:29 -0400 (EDT) Received: from unknown (HELO muralidharan) (203.199.38.56) by smtp2.mail.yahoo.com with SMTP; 31 Aug 2000 07:15:28 -0000 X-Apparently-From: Message-ID: <003301c0131b$7d6e4fc0$1000a8c0@muralidharan> Reply-To: "R. Muralidharan" From: "R. Muralidharan" To: Subject: Idle state data for octet syn HDLC frames in SONET Date: Thu, 31 Aug 2000 12:47:10 +0530 Organization: OSS Systems (India) Pvt Ltd/IEEE Bombay section MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0030_01C01349.93F940A0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu This is a multi-part message in MIME format. ------=_NextPart_000_0030_01C01349.93F940A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Would appreciate clarification on the following: In the case of Packet over SONET ( PoS, RFC 2615) implementation using PPP with Octet synchronous HDLC framing, what data pattern is to be sent out to the SONET payloads when there is no packet data? i.e.. what is the data pattern for idle states? Thanks in advance muralidharan ------=_NextPart_000_0030_01C01349.93F940A0 Content-Type: text/x-vcard; name="R. Muralidharan.vcf" Content-Disposition: attachment; filename="R. Muralidharan.vcf" Content-Transfer-Encoding: quoted-printable BEGIN:VCARD VERSION:2.1 N:Muralidharan;Raghavan FN:R. Muralidharan ORG:OSS Systems (India) Pvt Ltd ADR;WORK:;;111 Janki Centre, Andheri(W);Bombay;;400053;India LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:111 Janki Centre, = Andheri(W)=3D0D=3D0ABombay 400053=3D0D=3D0AIndia EMAIL;PREF;INTERNET:r.muralidharan@ieee.org EMAIL;INTERNET:r.muralidharan@computer.org REV:20000831T071710Z END:VCARD ------=_NextPart_000_0030_01C01349.93F940A0-- __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-ietf-ppp-outgoing@merit.edu Thu Aug 31 05:55:08 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02493 for ; Thu, 31 Aug 2000 05:55:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D55BB5DDFE; Thu, 31 Aug 2000 05:54:42 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id B6F685DDFD; Thu, 31 Aug 2000 05:54:42 -0400 (EDT) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 12CFE5DDB5 for ; Thu, 31 Aug 2000 05:54:41 -0400 (EDT) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.9.3/8.9.3) id FAA23754; Thu, 31 Aug 2000 05:54:29 -0400 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14766.11092.467254.228973@h006008986325.ne.mediaone.net> Date: Thu, 31 Aug 2000 05:54:28 -0400 (EDT) To: "R. Muralidharan" Cc: Subject: Re: Idle state data for octet syn HDLC frames in SONET In-Reply-To: R. Muralidharan's message of 31 August 2000 12:47:10 References: <003301c0131b$7d6e4fc0$1000a8c0@muralidharan> X-Mailer: VM 6.75 under Emacs 20.6.1 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit R. Muralidharan writes: > Would appreciate clarification on the following: > In the case of Packet over SONET ( PoS, RFC 2615) implementation using > PPP with Octet synchronous HDLC framing, what data pattern is to be sent out > to the SONET payloads when there is no packet data? > i.e.. what is the data pattern for idle states? 7E. See RFC 1662 section 4.4. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp