From owner-ietf-ppp-outgoing@merit.edu Wed Oct 4 08:19:11 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16983 for ; Wed, 4 Oct 2000 08:19:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2480B5DFCB; Wed, 4 Oct 2000 08:16:15 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D18485DFBB; Wed, 4 Oct 2000 08:15:50 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by segue.merit.edu (Postfix) with ESMTP id 42E685DF04 for ; Wed, 4 Oct 2000 06:55:11 -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 GAA14888; Wed, 4 Oct 2000 06:55:10 -0400 (EDT) Message-Id: <200010041055.GAA14888@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-pppmux-01.txt Date: Wed, 04 Oct 2000 06:55:10 -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 : PPP Multiplexed Author(s) : R. Pazhyannur, I. Ali, G. Fox Filename : draft-ietf-pppext-pppmux-01.txt Pages : 8 Date : 03-Oct-00 This draft describes a method to reduce the PPP framing overhead used to transport small packets over slow links. The method, PPP Multiplexing, sends multiple PPP encapsulated packets in a single PPP frame. As a result, the PPP overhead per packet is reduced. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-pppext-pppmux-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-pppext-pppmux-01.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-pppmux-01.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: <20001003122907.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-pppmux-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-pppmux-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001003122907.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-ppp-outgoing@merit.edu Thu Oct 5 06:00:05 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA24309 for ; Thu, 5 Oct 2000 06:00:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8C1CE5DDA9; Thu, 5 Oct 2000 05:59:28 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 74D115DDA6; Thu, 5 Oct 2000 05:59:28 -0400 (EDT) Received: from arianne.in.ishoni.com (unknown [164.164.83.132]) by segue.merit.edu (Postfix) with ESMTP id 4D53E5DD99 for ; Thu, 5 Oct 2000 05:59:23 -0400 (EDT) Received: from rohit ([192.168.1.133]) by arianne.in.ishoni.com (8.9.3/8.9.3) with SMTP id PAA12420 for ; Thu, 5 Oct 2000 15:33:35 +0530 Reply-To: From: "Rohit Khosla" To: Subject: IPSec test suite Date: Thu, 5 Oct 2000 15:40:29 +0530 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi, I am looking for some freely available test tool or test suites to test the IPSec implementation. Thanks, Rohit. From owner-ietf-ppp-outgoing@merit.edu Thu Oct 5 08:55:01 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28023 for ; Thu, 5 Oct 2000 08:55:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 404625DDE3; Thu, 5 Oct 2000 08:54:32 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 287085DDFB; Thu, 5 Oct 2000 08:54:32 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 4173E5DDE3 for ; Thu, 5 Oct 2000 08:54:30 -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 GAA28455; Thu, 5 Oct 2000 06:54:26 -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 IAA07367; Thu, 5 Oct 2000 08:54:26 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id IAA05080; Thu, 5 Oct 2000 08:54:29 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14812.31236.973520.711575@gargle.gargle.HOWL> Date: Thu, 5 Oct 2000 08:54:28 -0400 (EDT) From: James Carlson To: Cc: , Subject: Re: IPSec test suite In-Reply-To: Rohit Khosla's message of 5 October 2000 15:40:29 References: 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 Rohit Khosla writes: > I am looking for some freely available test tool or test suites to test the > IPSec implementation. The message you sent wasn't appropriate for either of the two lists to which you sent it. IPSec isn't L2TP nor is it PPP. For a free one, you might try: http://www.antd.nist.gov/antd/html/wit.html Empirix (nee Teradyne, nee Hammer, nee Midnight Networks) claims to have what you want, though it's not free: http://www.hammer.com/p_datacom.htm -- 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 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Oct 23 07:50:54 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05668 for ; Mon, 23 Oct 2000 07:50:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 794945DD8E; Mon, 23 Oct 2000 07:50:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 5D2F15DD91; Mon, 23 Oct 2000 07:50:24 -0400 (EDT) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by segue.merit.edu (Postfix) with ESMTP id 28F9B5DD8E for ; Mon, 23 Oct 2000 07:50:22 -0400 (EDT) Received: from mailsv4.nec.co.jp ([10.7.68.93]) by TYO201.gate.nec.co.jp (8.9.3/3.7W00052210) with ESMTP id UAA12757 for ; Mon, 23 Oct 2000 20:50:20 +0900 (JST) Received: from swb026.swd.abk.nec.co.jp (swb026.swd.abk.nec.co.jp [10.40.71.26]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP id UAA09318 for ; Mon, 23 Oct 2000 20:50:16 +0900 (JST) Received: from mailsv1.swd.abk.nec.co.jp (swb030.swd.abk.nec.co.jp [10.40.71.30]) by swb026.swd.abk.nec.co.jp (8.9.3/3.7W00031610) with ESMTP id UAA24739 for ; Mon, 23 Oct 2000 20:50:19 +0900 (JST) Received: from swj179 [10.40.78.179] by mailsv1.swd.abk.nec.co.jp (SMTPD32-4.10) id A6F9268A0150; Mon, 23 Oct 2000 20:50:17 +0900 Date: Mon, 23 Oct 2000 20:52:54 +0900 From: Osamu YONEMURA To: ietf-ppp@merit.edu Cc: ochi@swd.abk.nec.co.jp, yonemura@swd.abk.nec.co.jp Subject: Question about 32bit FCS calculation in RFC1662 Message-Id: <39F4269628A.7D6BYONEMURA@mailsv1.swd.abk.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.26 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Hi all. I have a few questions about the 32bit FCS calculation in RFC1662. Please tell me about following questions. (1)I try to calculate a FCS value using sample C code in the Appendix and I checked the FCS results with the example values of the AAL5 in ITU-T Recommendation I.363. But the calculated FCS result is not the same with example value. Is the FCS calculate method of PPP is different from the one of AAL5 ? (2)And also, I want to use the 32bit FCS calculation of PPP for the one of the Ethernet. Is the FCS calculate method of PPP the same with the one of Ethernet ? And is it possible that I use the sample C code for the FCS calculation of Ethernet ? Regards, Osamu Yonemura ---- Osamu Yonemura E-mail: o-yonemura@ay.jp.nec.com NEC Corporation. From owner-ietf-ppp-outgoing@merit.edu Mon Oct 23 08:49:53 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA20613 for ; Mon, 23 Oct 2000 08:49:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A0FFA5DDB1; Mon, 23 Oct 2000 08:49:24 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 8D55F5DDA5; Mon, 23 Oct 2000 08:49:24 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by segue.merit.edu (Postfix) with ESMTP id C68645DD9B for ; Mon, 23 Oct 2000 08:49:22 -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 FAA02888; Mon, 23 Oct 2000 05:49:18 -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 IAA17124; Mon, 23 Oct 2000 08:49:17 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id IAA00373; Mon, 23 Oct 2000 08:49:22 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14836.13265.842089.216540@gargle.gargle.HOWL> Date: Mon, 23 Oct 2000 08:49:21 -0400 (EDT) From: James Carlson To: Osamu YONEMURA Cc: ietf-ppp@merit.edu, ochi@swd.abk.nec.co.jp Subject: Re: Question about 32bit FCS calculation in RFC1662 In-Reply-To: Osamu YONEMURA's message of 23 October 2000 20:52:54 References: <39F4269628A.7D6BYONEMURA@mailsv1.swd.abk.nec.co.jp> 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 Osamu YONEMURA writes: > (1)I try to calculate a FCS value using sample C code in the Appendix > and I checked the FCS results with the example values of the AAL5 > in ITU-T Recommendation I.363. > But the calculated FCS result is not the same with example value. > > Is the FCS calculate method of PPP is different from the one of AAL5 ? It's the same; the bits are just reversed. You can pick up useful examples here: http://cell-relay.indiana.edu/cell-relay/publications/software/CRC/32bitCRC.html If you calculate AAL-5 CRC-32 over 40 octets of 0xff plus AAL-5 framing (00 00 00 28), it comes up with a CRC-32 of 0xc55e457a. To run the same data through PPP FCS, reverse all of the bits in each byte of the input (the final 28 changes to 14), and calculate 0xa3 0x7a 0xa2 0x5e. Reverse each byte to produce 0xc5 0x5e 0x45 0x7a. > (2)And also, I want to use the 32bit FCS calculation of PPP for the one > of the Ethernet. > > Is the FCS calculate method of PPP the same with the one of Ethernet ? > And is it possible that I use the sample C code for the FCS calculation > of Ethernet ? The PPP 32 bit FCS is the same as the Ethernet FCS. It's also the same as the AAL-5 CRC-32. -- 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 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Oct 23 10:12:02 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11979 for ; Mon, 23 Oct 2000 10:12:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F0E585DDA5; Mon, 23 Oct 2000 10:11:32 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id D8DAA5DDB2; Mon, 23 Oct 2000 10:11:32 -0400 (EDT) Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214]) by segue.merit.edu (Postfix) with ESMTP id 3A17B5DDA5 for ; Mon, 23 Oct 2000 10:11:30 -0400 (EDT) Received: from mailsv4.nec.co.jp ([10.7.68.93]) by TYO201.gate.nec.co.jp (8.9.3/3.7W00052210) with ESMTP id XAA18773; Mon, 23 Oct 2000 23:11:26 +0900 (JST) Received: from swb026.swd.abk.nec.co.jp (swb026.swd.abk.nec.co.jp [10.40.71.26]) by mailsv4.nec.co.jp (8.9.3/3.7W-MAILSV4-NEC) with ESMTP id XAA00651; Mon, 23 Oct 2000 23:11:22 +0900 (JST) Received: from mailsv1.swd.abk.nec.co.jp (swb030.swd.abk.nec.co.jp [10.40.71.30]) by swb026.swd.abk.nec.co.jp (8.9.3/3.7W00031610) with ESMTP id XAA27824; Mon, 23 Oct 2000 23:11:25 +0900 (JST) Received: from swj179 [10.40.78.179] by mailsv1.swd.abk.nec.co.jp (SMTPD32-4.10) id A80930DD0148; Mon, 23 Oct 2000 23:11:21 +0900 Date: Mon, 23 Oct 2000 23:13:52 +0900 From: Osamu YONEMURA To: james.d.carlson@east.sun.com Cc: ietf-ppp@merit.edu, ochi@swd.abk.nec.co.jp, yonemura@swd.abk.nec.co.jp Subject: Re: Question about 32bit FCS calculation in RFC1662 In-Reply-To: <14836.13265.842089.216540@gargle.gargle.HOWL> References: <39F4269628A.7D6BYONEMURA@mailsv1.swd.abk.nec.co.jp> <14836.13265.842089.216540@gargle.gargle.HOWL> Reply-To: ietf-ppp@merit.edu Message-Id: <39F447A012C.7D70YONEMURA@mailsv1.swd.abk.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver 1.26 Sender: owner-ietf-ppp@merit.edu Precedence: bulk Errors-To: owner-ietf-ppp-outgoing@merit.edu Content-Transfer-Encoding: 7bit Dear James, Thank you for your reply. On Mon, 23 Oct 2000 08:49:21 -0400 (EDT) James Carlson wrote: > Osamu YONEMURA writes: > > (1)I try to calculate a FCS value using sample C code in the Appendix > > and I checked the FCS results with the example values of the AAL5 > > in ITU-T Recommendation I.363. > > But the calculated FCS result is not the same with example value. > > > > Is the FCS calculate method of PPP is different from the one of AAL5 ? > > It's the same; the bits are just reversed. You can pick up useful > examples here: > > http://cell-relay.indiana.edu/cell-relay/publications/software/CRC/32bitCRC.html > > If you calculate AAL-5 CRC-32 over 40 octets of 0xff plus AAL-5 > framing (00 00 00 28), it comes up with a CRC-32 of 0xc55e457a. To > run the same data through PPP FCS, reverse all of the bits in each > byte of the input (the final 28 changes to 14), and calculate 0xa3 > 0x7a 0xa2 0x5e. Reverse each byte to produce 0xc5 0x5e 0x45 0x7a. I got the correct result using this method. I want to confirm the data input and output methods. Please check the following methods. In AAL5 CRC-32 Calculation using the PPP FCS code, I need to reverse all of the bits in each byte of the input and the result. > > > (2)And also, I want to use the 32bit FCS calculation of PPP for the one > > of the Ethernet. > > > > Is the FCS calculate method of PPP the same with the one of Ethernet ? > > And is it possible that I use the sample C code for the FCS calculation > > of Ethernet ? > > The PPP 32 bit FCS is the same as the Ethernet FCS. It's also the > same as the AAL-5 CRC-32. In the PPP and Ethernet FCS calculation using the PPP FCS code, I don't need to reverse all bit of the input and the output. Is this correct? Thanks and regards, Osamu Yonemura ---- Osamu Yonemura E-mail: o-yonemura@ay.jp.nec.com NEC Corporation. From owner-ietf-ppp-outgoing@merit.edu Mon Oct 23 10:29:52 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16216 for ; Mon, 23 Oct 2000 10:29:52 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2EB2F5DDEE; Mon, 23 Oct 2000 10:29:27 -0400 (EDT) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 1BB0D5DDEC; Mon, 23 Oct 2000 10:29:27 -0400 (EDT) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by segue.merit.edu (Postfix) with ESMTP id 825725DDB4 for ; Mon, 23 Oct 2000 10:29:24 -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 IAA13067 for ; Mon, 23 Oct 2000 08:29:23 -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 KAA17820; Mon, 23 Oct 2000 10:23:36 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.9.3+Sun/8.9.3) id KAA00590; Mon, 23 Oct 2000 10:23:40 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14836.18924.326408.440878@gargle.gargle.HOWL> Date: Mon, 23 Oct 2000 10:23:40 -0400 (EDT) From: James Carlson To: ietf-ppp@merit.edu Cc: ochi@swd.abk.nec.co.jp, yonemura@swd.abk.nec.co.jp Subject: Re: Question about 32bit FCS calculation in RFC1662 In-Reply-To: Osamu YONEMURA's message of 23 October 2000 23:13:52 References: <39F4269628A.7D6BYONEMURA@mailsv1.swd.abk.nec.co.jp> <14836.13265.842089.216540@gargle.gargle.HOWL> <39F447A012C.7D70YONEMURA@mailsv1.swd.abk.nec.co.jp> 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 Osamu YONEMURA writes: > I got the correct result using this method. > > I want to confirm the data input and output methods. > Please check the following methods. > > In AAL5 CRC-32 Calculation using the PPP FCS code, > I need to reverse all of the bits in each byte of the input and the result. Yes, assuming you're using the PPP FCS code. The reverse is true if you're using the AAL-5 code. They're equivalent. > In the PPP and Ethernet FCS calculation using the PPP FCS code, > I don't need to reverse all bit of the input and the output. > Is this correct? Yes. AAL-5 uses big-endian format; the others use little-endian. This is because of the way the bits are sent on the wire. ATM sends bits in big-endian (MSB first) format. Ethernet always sends the bits little-endian (LSB first). PPP normally runs on media (most async and sync links) that also send bytes in little-endian mode. As a side issue, when PPP runs over SONET/SDH, the CRC is unfortunately still calculated as though the octets were sent with LSB-first order, even though SONET/SDH defines transmission so that the bytes are in MSB-first order. This is a bug in the spec. -- 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 Second Edition now available - http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Oct 30 00:09:50 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05286 for ; Mon, 30 Oct 2000 00:09:50 -0500 (EST) Received: by segue.merit.edu (Postfix) id BFFEB5DDA8; Mon, 30 Oct 2000 00:09:15 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AEBDC5DDA7; Mon, 30 Oct 2000 00:09:15 -0500 (EST) Received: from fsnt.future.futsoft.com (unknown [203.197.140.35]) by segue.merit.edu (Postfix) with ESMTP id F061D5DD94 for ; Mon, 30 Oct 2000 00:09:11 -0500 (EST) Received: from kailash.future.futsoft.com (unverified) by fsnt.future.futsoft.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Mon, 30 Oct 2000 10:41:43 +0530 Received: from aruljp (aruljp.future.futsoft.com [10.0.12.18]) by kailash.future.futsoft.com (8.7.1/8.7.1) with SMTP id KAA25416 for ; Mon, 30 Oct 2000 10:25:45 +0530 Received: by localhost with Microsoft MAPI; Mon, 30 Oct 2000 10:32:50 +0530 Message-Id: <01C0425C.C0EDAC80.aruljp@future.futsoft.com> From: Arul J P Reply-To: "aruljp@future.futsoft.com" To: "'ietf-ppp@merit.edu'" Subject: Clarification regarding encryption and compression in PPP Date: Mon, 30 Oct 2000 10:32:49 +0530 Organization: Future Software X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211 MIME-Version: 1.0 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, Can LCP echo request packets or CHAP challenge packets be encrypted or compressed. regards Arul. From owner-ietf-ppp-outgoing@merit.edu Mon Oct 30 06:42:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA12721 for ; Mon, 30 Oct 2000 06:42:35 -0500 (EST) Received: by segue.merit.edu (Postfix) id B96CC5DDA5; Mon, 30 Oct 2000 06:41:58 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id A7E365DD95; Mon, 30 Oct 2000 06:41:58 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 1B7185DD8E for ; Mon, 30 Oct 2000 06:41:57 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id e9UBfnD07440; Mon, 30 Oct 2000 06:41:49 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14845.24188.634283.44048@h006008986325.ne.mediaone.net> Date: Mon, 30 Oct 2000 06:41:48 -0500 (EST) To: "aruljp@future.futsoft.com" Cc: "'ietf-ppp@merit.edu'" Subject: Re: Clarification regarding encryption and compression in PPP In-Reply-To: Arul J P's message of 30 October 2000 10:32:49 References: <01C0425C.C0EDAC80.aruljp@future.futsoft.com> 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 Arul J P writes: > Can LCP echo request packets or CHAP challenge packets be > encrypted or compressed. That's up to the encryption or compression algorithm in use. ECP and CCP define the negotiation method; they don't determine which protocols are actually passed through the encoding method chosen. I would expect normal implementations to encrypt at least the CHAP Challenge and possibly also LCP Echo-Request, but compress neither. (DESE-bis [RFC 2419] prohibits encryption of LCP. It wouldn't surprise me to find that in some implementations, LCP packets with code numbers above 4 are encrypted anyway.) The underlying rule is that compression of infrequently used things, such as NCP negotiation messages, is unlikely to be helpful and could, if errors occur, be harmful (at least to accurate logging). Encryption, once negotiated, is mandatory. They only time you don't encrypt is when you're restarting the link. -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Oct 30 11:58:16 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21695 for ; Mon, 30 Oct 2000 11:58:15 -0500 (EST) Received: by segue.merit.edu (Postfix) id CCD4B5DDCF; Mon, 30 Oct 2000 11:57:47 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id AA2185DDE3; Mon, 30 Oct 2000 11:57:47 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 289885DDCF for ; Mon, 30 Oct 2000 11:57:43 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id e9UGvgG19858; Mon, 30 Oct 2000 11:57:42 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14845.43142.11532.481892@h006008986325.ne.mediaone.net> Date: Mon, 30 Oct 2000 11:57:42 -0500 (EST) To: pppext Subject: Follow-up on encrypt/compress 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 In private email, another reader pointed out that I should have been clearer. In referring to "CHAP Challenge" in my reply, I was referring to periodic rechallenges. Since ECP is negotiated after the initial authentication is done, any CHAP Challenge done during Authenticate phase can't be encrypted. (Notably, this means that PAP Authenticate-Request, with its cleartext passwords, can't be encrypted with ECP.) -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp From owner-ietf-ppp-outgoing@merit.edu Mon Oct 30 15:39:33 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04016 for ; Mon, 30 Oct 2000 15:39:32 -0500 (EST) Received: by segue.merit.edu (Postfix) id 86A015DD8E; Mon, 30 Oct 2000 15:38:57 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 6FDE05DDBA; Mon, 30 Oct 2000 15:38:57 -0500 (EST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by segue.merit.edu (Postfix) with ESMTP id C23DD5DD8E for ; Mon, 30 Oct 2000 15:38:55 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id PAA46656 for ; Mon, 30 Oct 2000 15:38:24 -0500 From: jmartz@us.ibm.com Received: from RCHASA28.RCHLAND.IBM.COM (d27ml103.rchland.ibm.com [9.5.39.110]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id PAA65642 for ; Mon, 30 Oct 2000 15:38:01 -0500 Importance: Normal Subject: PPP and password maintenance To: ietf-ppp@merit.edu X-Mailer: Lotus Notes Release 5.0.3 (Intl) 21 March 2000 Message-ID: Date: Mon, 30 Oct 2000 15:40:17 -0500 X-MIMETrack: Serialize by Router on d27ml103/27/M/IBM(Release 5.0.5 |September 22, 2000) at 10/30/2000 02:40:23 PM 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 Good folk of the PPP mailing list, I was recently forwarded a customer comment about how our PPP implementation handles passwords. The customer was annoyed because we "require" him to maintain two password databases. One password database is for the system signon userids. System signon passwords are always stored using a non-reversible hash/encryption. However, the ids used for PPP authentication are stored using a reversible encryption. We do it this way for historical reasons, of course. The security for the signon userids was implemented before PPP was. (Heck, it was probably implemented before the Internet was implemented ;-). I cannot see a way to implement CHAP (for example) without being able to extract the original password so that it can be hashed with the CHAP challenge. (Am I overlooking something ???) What I'm curious about is how passwords are handled in other PPP implementations. I hope I can get some feedback from the mailing list about this. I have a nearly 20 year old memory that UNIX also uses a one way encryption scheme to store its system signon passwords. If that is still true then I would expect a UNIX PPP implementations to have the same "multiple maintenance" password concerns. Is this true? If so, is using RADIUS the most common way used to consolidate userid/password maintenance? I'm also curious what Windows does. My guess is that non-NT versions of windows always store passwords with a reversible encryption. Perhaps this is also how NT/Win2K windows systems do it, at least by default. I have seen a Win2K Professional local security policy with the title "Store password using reversible encryption for all users in the domain". On my Win2K system this policy is enabled. I'm not sure if there are any consequences to Windows Dial Up Networking if this security policy is disabled. -john martz, 8-852-5539, jmartz@us.ibm.com IBM AS/400 TCP/IP PPP development (and stuff) From owner-ietf-ppp-outgoing@merit.edu Mon Oct 30 15:56:36 2000 Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07062 for ; Mon, 30 Oct 2000 15:56:36 -0500 (EST) Received: by segue.merit.edu (Postfix) id 5797E5DDC6; Mon, 30 Oct 2000 15:56:06 -0500 (EST) Delivered-To: ietf-ppp-outgoing@merit.edu Received: by segue.merit.edu (Postfix, from userid 56) id 339465DDC1; Mon, 30 Oct 2000 15:56:06 -0500 (EST) Received: from h006008986325.ne.mediaone.net (h006008986325.ne.mediaone.net [24.218.16.153]) by segue.merit.edu (Postfix) with ESMTP id 3B7125DDA7 for ; Mon, 30 Oct 2000 15:56:04 -0500 (EST) Received: (from carlson@localhost) by h006008986325.ne.mediaone.net (8.11.0/8.11.0) id e9UKtiW18618; Mon, 30 Oct 2000 15:55:44 -0500 From: James Carlson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14845.57424.49911.739920@h006008986325.ne.mediaone.net> Date: Mon, 30 Oct 2000 15:55:44 -0500 (EST) To: jmartz@us.ibm.com Cc: ietf-ppp@merit.edu Subject: Re: PPP and password maintenance In-Reply-To: jmartz@us.ibm.com's message of 30 October 2000 15:40:17 References: 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 jmartz@us.ibm.com writes: > using a non-reversible hash/encryption. However, the ids used for PPP > authentication are stored using a reversible encryption. Using reversible encryption for something like this is, in my opinion, worthless; it's essentially no security at all. > We do it this way for historical reasons, of course. The security for the > signon userids was implemented before PPP was. (Heck, it was probably > implemented before the Internet was implemented ;-). I cannot see a way to > implement CHAP (for example) without being able to extract the original > password so that it can be hashed with the CHAP challenge. (Am I > overlooking something ???) That's correct. You need access to a cleartext passphrase in order to authenticate a peer using CHAP. PAP, however, does not require this. You can authenticate a peer with PAP through the regular AIX /etc/security/shadow (or NIS) interfaces (or whatever it is that an AS/400 does for user validation). > What I'm curious about is how passwords are handled in other PPP > implementations. I hope I can get some feedback from the mailing list about > this. All that I've seen have two databases for this. It's a rather standard problem. > I have a nearly 20 year old memory that UNIX also uses a one way encryption > scheme to store its system signon passwords. If that is still true then I > would expect a UNIX PPP implementations to have the same "multiple > maintenance" password concerns. Is this true? If so, is using RADIUS the > most common way used to consolidate userid/password maintenance? It's true if you're using CHAP. Note that if you do RADIUS, you can authenticate the peer, but you cannot authenticate yourself *to* the peer using the same mechanism. Also note that RADIUS doesn't actually fix the problem -- it just moves it to another location. > I'm also curious what Windows does. My guess is that non-NT versions of > windows always store passwords with a reversible encryption. Perhaps this > is also how NT/Win2K windows systems do it, at least by default. NT, at least, has two databases -- one is an MD4 hash of a user's password. This is used for validating PAP users and is also used (essentially) as a cleartext key for the MS-CHAP variants. For CHAP on NT, there's a completely separate registry of cleartext passphrases. Non-NT Windows systems are supposed to be "clients" only, and I think they simply query the user for the necessary information (and optionally store a single peer name / passphrase combination to make theft easier). > I have > seen a Win2K Professional local security policy with the title "Store > password using reversible encryption for all users in the domain". On my > Win2K system this policy is enabled. I'm not sure if there are any > consequences to Windows Dial Up Networking if this security policy is > disabled. It's often hard to map from menu text to actual implementation ... -- James Carlson "PPP Design and Debugging" --- http://people.ne.mediaone.net/carlson/ppp