From ietf-ppp-request@MERIT.EDU Mon Dec 2 00:38:17 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id AAA15567; Mon, 2 Dec 1996 00:38:17 -0500 (EST) Resent-Date: Mon, 2 Dec 1996 00:38:17 -0500 (EST) From: Indhu Message-Id: <199612020543.AAA22682@m-net.arbornet.org> To: ietf-ppp@MERIT.EDU Date: Mon, 2 Dec 1996 00:43:17 -0500 (EST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"-pE8v.0.to3.giceo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU Subject: Unidentified subject! X-Mailing-List: archive/latest/2238 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Parden me Can someone tell me how to join the ietf-ppp mailing list please. Thanking you Indhu - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 2 12:19:09 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id MAA23886; Mon, 2 Dec 1996 12:19:09 -0500 (EST) Resent-Date: Mon, 2 Dec 1996 12:19:09 -0500 (EST) Message-Id: <199612021717.MAA08244@home.merit.edu> To: Gonzalo Chain cc: "'glennz@microsoft.com'" , "'ljb@merit.edu'" , "'Kyle Farnsworth'" , "'karl@ascend.com'" , "'ietf-ppp@merit.edu'" , "'jrv@home.merit.edu'" , "'bwhelan@nei.com'" Subject: Re: PPP Extensible Authentication Protocol (EAP) - Working Group Last Call In-reply-to: Your message of "Wed, 27 Nov 1996 09:38:31 PST." Date: Mon, 02 Dec 1996 12:17:34 -0500 From: "John R. Vollbrecht" Resent-Message-ID: <"If8IW2.0.Zq5.Mzmeo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2239 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU EAP was designed to support token authentication, as well as other authentication types. Some EAP Request/response types have been included in the standard, and others can be added by doing an addon rfc. The EAP types included in the proposed rfc are Identity, Notification, Nak, MD%-Challenge, S/Key, and Generic Token Card. The Generic token card type as defined in the proposed rfc is unformatted, and therefore can have whatever is required for token card. The proposal for change adds some formatting to the message. The formatting could be added to messages sent by the generic token card protocol, and each vendor could use a different format. It is then up to the user to know which type is being used. The proposed change is to add some specific format to the message to handle what are considered "generic" requirements. Most of these seem like "good things" in some sense. They would allow some standardization of how to deal with these messages in the client, and so make implementation easier for a set of similar authentication services. However, we did propose a type with very similar features, and there was considerable concern about the fact that these might encourage sending pw in the clear. We removed this in the interest of getting the rfc approved, with the idea that an addon rfc could deal with this if people feel strongly. I personally would like to see this rfc get started on standards track, and deal with the issue as with an addon rfc proposal. - John In message , GonT zalo Chain writes: >Yes, I will give my two cents on this matter. > >I am a product Manager at AssureNet Pathways. I think you are right >Kyle, Security Dynamics and AssureNet Pathways have around 80-90% of the >market share of token authentication products. I am very interested in >making sure asynchronous token authentication is included in EAP. > >In order to work, we only require the user ID at the beginning, then we >check the Defender Security Server to see what kind of security >requirements are needed for that user ID, we then request the user for >either a response to a challenge or static password or a combination of >both. > >I believe the token authentication market is growing at a rate of about >65%. > >EAP should support a method of authentication that is growing at this >rate. Due to the fact that two companies "own" the token authentication >market, it should be advantageous to include their method of >authentication in EAP. > >Gonzalo J. Chain > >------------------------------------------ >Gonzalo J. Chain >Product Manager > >AssureNet Pathways, Inc. >Direct: +415-526-2224 >Fax: +415-961-7487 >e-mail: gonzalo@anpi.com >http: www.anpi.com > >>---------- >>From: Kyle Farnsworth[SMTP:kfarnsworth@adtran.com] >>Sent: Wednesday, November 27, 1996 7:30 AM >>To: glennz@microsoft.com; ljb@merit.edu >>Cc: karl@ascend.com; ietf-ppp@merit.edu; jrv@home.merit.edu; bwhelan@nei.co >m >>Subject: RE: PPP Extensible Authentication Protocol (EAP) - Working Grou >p >>Last Call >> >>What percentage of the token card market do you think Security Dynamics and >>AssureNet Pathways has? I would guess at least 80%. I've never even heard >>of any other token card vendor. So EAP's "Generic Token Card" scheme won't >>work for the majority of the cases. Is that what we want? >> >>Is there anybody on the list from Security Dynamics or AssureNet Pathways >>that has any opinion on this? It seems it is in your best interest to have >>a compatible protocol to support your product. >> >>Kyle >> >>At 09:44 PM 11/26/96 -0800, Glen Zorn wrote: >>>It seems to me that the "Generic Token Card" requests are just that: >>>generic. If you have a token card that doesn't fit the "generic" mold >>>(and I would include SecurID in that category), it makes more sense to >>>me to extend EAP (what a concept) to support the special case, rather >>>than trying to stretch "generic" into "one-size-fits-all". >>> >>>>---------- >>>>Sent: Tuesday, November 26, 1996 10:10 AM >>>>To: Larry J. Blunk >>>>Cc: Karl Fox; ietf-ppp@MERIT.EDU; jrv@home.merit.edu; Whelan, Bill >>>>Subject: Re: PPP Extensible Authentication Protocol (EAP) - Working Grou >p >>>>Last Call >>>> >>>>At 11:41 AM 11/26/96 -0500, Larry J. Blunk wrote: >>>>> >>>>> You mentioned that hiding PIN numbers is one requirement. I could >>>>>potentially see the PIN number being entered in response to the EAP >>>>>"Identity" >>>>>request. The could be problematic as the "Identity" request currently >>>>>makes no provision for hiding user input. Do you forsee Token card >>>>>users using their PIN as their identity, or would they typically have >>>>>a different label to identify themselves if prompted with an >>>>>"Identity" request. The EAP spec currently does not mandate an >>>>>initial "Identity" request, but I would suspect that most implementation >>>>>would use this. >>>>> >>>>Both Token cards I mentioned require a username. The SecurID requires the >>>>PIN to be entered with the token. The AssureNet Pathways will send a >>>>challenge to the user which is used with the PIN as input to the token >>>>card. >>>> >>>>> As far as the option of echoing "*"'s. Although I'm not particularly >>>>>opposed to this option, I think I'd prefer to leave the choice of the >>>>>blanking character up to the implementation. >>>>> >>>>The point is the token card authentication server will attempt to have a >>>>dialog with the remote user. It needs to control when the characters on >>>>the >>>>user repsonse are to blanked and when they need to be "*"ed. >>>> >>>>I think what we are talking about is a terminal mode which I am beginning >>>>to >>>>think is wrong for PPP to handle. I've heard it suggested that this type >>>>of >>>>authentication could be handled using a UNIX terminal mode (I think it's >>>>called 'getty') above IPCP. But what if the link is an IPXCP link? I >>>>don't >>>>have any answers but I know the Generic Token Card request packets will be >>>>a >>>>restriction on what the token card vendors really want. >>>> >>>>Kyle >>>>-------------------------------------------------------- >>>> Kyle Farnsworth ADTRAN Inc. >>>> (205)971-8583 kfarnsworth@adtran.com >>>>-------------------------------------------------------- >>>> >>>> >>>> >>> >>> >>> >>-------------------------------------------------------- >> Kyle Farnsworth ADTRAN Inc. >> (205)971-8583 kfarnsworth@adtran.com >>-------------------------------------------------------- >> >> >> >> >>Original Recipient: GONZALO.DVSEMAIL @ DPMAIL >> - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 2 12:37:12 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id MAA24327; Mon, 2 Dec 1996 12:37:12 -0500 (EST) Resent-Date: Mon, 2 Dec 1996 12:37:12 -0500 (EST) Date: Mon, 2 Dec 96 11:35:26 CST Message-Id: <9612021735.AA06149@adtrn-ws01.adtran.com> X-Sender: kfrnswrt@mail Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "John R. Vollbrecht" , Gonzalo Chain From: kfarnsworth@adtran.com (Kyle Farnsworth) Subject: Re: PPP Extensible Authentication Protocol (EAP) - Working Group Last Call Cc: "'glennz@microsoft.com'" , "'ljb@merit.edu'" , "'karl@ascend.com'" , "'ietf-ppp@merit.edu'" , "'jrv@home.merit.edu'" , "'bwhelan@nei.com'" X-Mailer: Resent-Message-ID: <"ne4o8.0.nx5.3Fneo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2240 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU John, Fine. Let's handle the Token card stuff with an "addon" rfc. I don't want to hold up EAP but I believe that the "addon" to the generic token card needs to be done now in order to support the two big token card vendors. Kyle At 12:17 PM 12/2/96 -0500, John R. Vollbrecht wrote: >EAP was designed to support token authentication, as well as other >authentication types. Some EAP Request/response types have been included >in the standard, and others can be added by doing an addon rfc. > >The EAP types included in the proposed rfc are Identity, Notification, >Nak, MD%-Challenge, S/Key, and Generic Token Card. > >The Generic token card type as defined in the proposed rfc is >unformatted, and therefore can have whatever is required for token card. > >The proposal for change adds some formatting to the message. The >formatting could be added to messages sent by the generic token card protocol, >and each vendor could use a different format. It is then up to the user >to know which type is being used. > >The proposed change is to add some specific format to the message to >handle what are considered "generic" requirements. Most of these seem >like "good things" in some sense. They would allow some standardization >of how to deal with these messages in the client, and so make >implementation easier for a set of similar authentication services. > >However, we did propose a type with very similar features, and there was >considerable concern about the fact that these might encourage sending >pw in the clear. We removed this in the interest of getting the rfc >approved, with the idea that an addon rfc could deal with this if people >feel strongly. > >I personally would like to see this rfc get started on standards track, >and deal with the issue as with an addon rfc proposal. > >- John > >In message , GonT >zalo Chain writes: >>Yes, I will give my two cents on this matter. >> >>I am a product Manager at AssureNet Pathways. I think you are right >>Kyle, Security Dynamics and AssureNet Pathways have around 80-90% of the >>market share of token authentication products. I am very interested in >>making sure asynchronous token authentication is included in EAP. >> >>In order to work, we only require the user ID at the beginning, then we >>check the Defender Security Server to see what kind of security >>requirements are needed for that user ID, we then request the user for >>either a response to a challenge or static password or a combination of >>both. >> >>I believe the token authentication market is growing at a rate of about >>65%. >> >>EAP should support a method of authentication that is growing at this >>rate. Due to the fact that two companies "own" the token authentication >>market, it should be advantageous to include their method of >>authentication in EAP. >> >>Gonzalo J. Chain >> >>------------------------------------------ >>Gonzalo J. Chain >>Product Manager >> >>AssureNet Pathways, Inc. >>Direct: +415-526-2224 >>Fax: +415-961-7487 >>e-mail: gonzalo@anpi.com >>http: www.anpi.com >> >>>---------- >>>From: Kyle Farnsworth[SMTP:kfarnsworth@adtran.com] >>>Sent: Wednesday, November 27, 1996 7:30 AM >>>To: glennz@microsoft.com; ljb@merit.edu >>>Cc: karl@ascend.com; ietf-ppp@merit.edu; jrv@home.merit.edu; bwhelan@nei.co >>m >>>Subject: RE: PPP Extensible Authentication Protocol (EAP) - Working Grou >>p >>>Last Call >>> >>>What percentage of the token card market do you think Security Dynamics and >>>AssureNet Pathways has? I would guess at least 80%. I've never even heard >>>of any other token card vendor. So EAP's "Generic Token Card" scheme won't >>>work for the majority of the cases. Is that what we want? >>> >>>Is there anybody on the list from Security Dynamics or AssureNet Pathways >>>that has any opinion on this? It seems it is in your best interest to have >>>a compatible protocol to support your product. >>> >>>Kyle >>> >>>At 09:44 PM 11/26/96 -0800, Glen Zorn wrote: >>>>It seems to me that the "Generic Token Card" requests are just that: >>>>generic. If you have a token card that doesn't fit the "generic" mold >>>>(and I would include SecurID in that category), it makes more sense to >>>>me to extend EAP (what a concept) to support the special case, rather >>>>than trying to stretch "generic" into "one-size-fits-all". >>>> >>>>>---------- > >>>>>Sent: Tuesday, November 26, 1996 10:10 AM >>>>>To: Larry J. Blunk >>>>>Cc: Karl Fox; ietf-ppp@MERIT.EDU; jrv@home.merit.edu; Whelan, Bill >>>>>Subject: Re: PPP Extensible Authentication Protocol (EAP) - Working Grou >>p >>>>>Last Call >>>>> >>>>>At 11:41 AM 11/26/96 -0500, Larry J. Blunk wrote: >>>>>> >>>>>> You mentioned that hiding PIN numbers is one requirement. I could >>>>>>potentially see the PIN number being entered in response to the EAP >>>>>>"Identity" >>>>>>request. The could be problematic as the "Identity" request currently >>>>>>makes no provision for hiding user input. Do you forsee Token card >>>>>>users using their PIN as their identity, or would they typically have >>>>>>a different label to identify themselves if prompted with an >>>>>>"Identity" request. The EAP spec currently does not mandate an >>>>>>initial "Identity" request, but I would suspect that most implementation >>>>>>would use this. >>>>>> >>>>>Both Token cards I mentioned require a username. The SecurID requires the >>>>>PIN to be entered with the token. The AssureNet Pathways will send a >>>>>challenge to the user which is used with the PIN as input to the token >>>>>card. >>>>> >>>>>> As far as the option of echoing "*"'s. Although I'm not particularly >>>>>>opposed to this option, I think I'd prefer to leave the choice of the >>>>>>blanking character up to the implementation. >>>>>> >>>>>The point is the token card authentication server will attempt to have a >>>>>dialog with the remote user. It needs to control when the characters on >>>>>the >>>>>user repsonse are to blanked and when they need to be "*"ed. >>>>> >>>>>I think what we are talking about is a terminal mode which I am beginning >>>>>to >>>>>think is wrong for PPP to handle. I've heard it suggested that this type >>>>>of >>>>>authentication could be handled using a UNIX terminal mode (I think it's >>>>>called 'getty') above IPCP. But what if the link is an IPXCP link? I >>>>>don't >>>>>have any answers but I know the Generic Token Card request packets will be >>>>>a >>>>>restriction on what the token card vendors really want. >>>>> >>>>>Kyle >>>>>-------------------------------------------------------- >>>>> Kyle Farnsworth ADTRAN Inc. >>>>> (205)971-8583 kfarnsworth@adtran.com >>>>>-------------------------------------------------------- >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>-------------------------------------------------------- >>> Kyle Farnsworth ADTRAN Inc. >>> (205)971-8583 kfarnsworth@adtran.com >>>-------------------------------------------------------- >>> >>> >>> >>> >>>Original Recipient: GONZALO.DVSEMAIL @ DPMAIL >>> > > -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 2 13:22:15 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id NAA25404; Mon, 2 Dec 1996 13:22:15 -0500 (EST) Resent-Date: Mon, 2 Dec 1996 13:22:15 -0500 (EST) Date: Mon, 2 Dec 1996 11:21:53 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612021821.LAA04132@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: IPCP draft Resent-Message-ID: <"feobR2.0.dC6.Fvneo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2241 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU What is happening with the IPCP draft? That last words I saw needed work. Because of the importance and the history of this issue, any voting at the San Jose meeting can be considered only a straw poll. There has been far too much controversy for anything decided only by those at the San Jose meeting to be defined as the consensus without polling the mailing list. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 2 13:46:29 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id NAA25958; Mon, 2 Dec 1996 13:46:29 -0500 (EST) Resent-Date: Mon, 2 Dec 1996 13:46:29 -0500 (EST) 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-bacp-05.txt Date: Mon, 02 Dec 1996 11:29:17 -0500 Sender: cclark@ietf.org Message-ID: <9612021129.aa06458@ietf.org> Resent-Message-ID: <"5FY4P2.0.EL6.0Goeo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2242 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised 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. Note: This revision reflects comments received during the last call period. Title : The PPP Bandwidth Allocation Protocol (BAP) The PPP Bandwidth Allocation Control Protocol (BACP) Author(s) : C. Richards, K. Smith Filename : draft-ietf-pppext-bacp-05.txt Pages : 21 Date : 11/27/1996 This document proposes a method to manage the dynamic bandwidth allocation of implementations supporting the PPP multilink protocol [2]. This is done by defining the Bandwidth Allocation Protocol (BAP), as well as its associated control protocol, the Bandwidth Allocation Control Protocol (BACP). BAP can be used to manage the number of links in a multilink bundle. BAP defines datagrams to co-ordinate adding and removing individual links in a multilink bundle, as well as specifying which peer is responsible for which decisions regarding managing bandwidth during a multilink connection. Internet-Drafts are 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-bacp-05.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-bacp-05.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-bacp-05.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19961127163719.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-bacp-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-bacp-05.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961127163719.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 2 14:19:34 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id OAA26755; Mon, 2 Dec 1996 14:19:34 -0500 (EST) Resent-Date: Mon, 2 Dec 1996 14:19:34 -0500 (EST) Message-ID: From: Gonzalo Chain To: "'ietf-ppp@merit.edu'" Subject: RE: PPP Extensible Authentication Protocol (EAP) - Working Group Last Call Date: Mon, 2 Dec 1996 11:19:42 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ssDbG3.0.kX6.1loeo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2243 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I will also like to get started ASAP with the "addon" RFC for token authentication. Gonzalo ------------------------------------------ Gonzalo J. Chain Product Manager AssureNet Pathways, Inc Direct: +415-526-2224 Fax: +415-961-7487 e-mail: gonzalo@anpi.com http: www.anpi.com >---------- >From: Kyle Farnsworth[SMTP:kfarnsworth@adtran.com] >Sent: Monday, December 02, 1996 9:35 AM >To: Gonzalo Chain; jrv@merit.edu >Cc: glennz@microsoft.com; ljb@merit.edu; karl@ascend.com; >ietf-ppp@merit.edu; jrv@home.merit.edu; bwhelan@nei.com >Subject: Re: PPP Extensible Authentication Protocol (EAP) - Working Group >Last Call > >John, > >Fine. Let's handle the Token card stuff with an "addon" rfc. I don't want >to hold up EAP but I believe that the "addon" to the generic token card >needs to be done now in order to support the two big token card vendors. > >Kyle > >At 12:17 PM 12/2/96 -0500, John R. Vollbrecht wrote: >>EAP was designed to support token authentication, as well as other >>authentication types. Some EAP Request/response types have been included >>in the standard, and others can be added by doing an addon rfc. >> >>The EAP types included in the proposed rfc are Identity, Notification, >>Nak, MD%-Challenge, S/Key, and Generic Token Card. >> >>The Generic token card type as defined in the proposed rfc is >>unformatted, and therefore can have whatever is required for token card. >> >>The proposal for change adds some formatting to the message. The >>formatting could be added to messages sent by the generic token card >>protocol, >>and each vendor could use a different format. It is then up to the user >>to know which type is being used. >> >>The proposed change is to add some specific format to the message to >>handle what are considered "generic" requirements. Most of these seem >>like "good things" in some sense. They would allow some standardization >>of how to deal with these messages in the client, and so make >>implementation easier for a set of similar authentication services. >> >>However, we did propose a type with very similar features, and there was >>considerable concern about the fact that these might encourage sending >>pw in the clear. We removed this in the interest of getting the rfc >>approved, with the idea that an addon rfc could deal with this if people >>feel strongly. >> >>I personally would like to see this rfc get started on standards track, >>and deal with the issue as with an addon rfc proposal. >> >>- John >> >>In message , >GonT >>zalo Chain writes: >>>Yes, I will give my two cents on this matter. >>> >>>I am a product Manager at AssureNet Pathways. I think you are right >>>Kyle, Security Dynamics and AssureNet Pathways have around 80-90% of the >>>market share of token authentication products. I am very interested in >>>making sure asynchronous token authentication is included in EAP. >>> >>>In order to work, we only require the user ID at the beginning, then we >>>check the Defender Security Server to see what kind of security >>>requirements are needed for that user ID, we then request the user for >>>either a response to a challenge or static password or a combination of >>>both. >>> >>>I believe the token authentication market is growing at a rate of about >>>65%. >>> >>>EAP should support a method of authentication that is growing at this >>>rate. Due to the fact that two companies "own" the token authentication >>>market, it should be advantageous to include their method of >>>authentication in EAP. >>> >>>Gonzalo J. Chain >>> >>>------------------------------------------ >>>Gonzalo J. Chain >>>Product Manager >>> >>>AssureNet Pathways, Inc. >>>Direct: +415-526-2224 >>>Fax: +415-961-7487 >>>e-mail: gonzalo@anpi.com >>>http: www.anpi.com >>> >>>>---------- >>>>From: Kyle Farnsworth[SMTP:kfarnsworth@adtran.com] >>>>Sent: Wednesday, November 27, 1996 7:30 AM >>>>To: glennz@microsoft.com; ljb@merit.edu >>>>Cc: karl@ascend.com; ietf-ppp@merit.edu; jrv@home.merit.edu; >>>>bwhelan@nei.co >>>m >>>>Subject: RE: PPP Extensible Authentication Protocol (EAP) - Working Grou >>>p >>>>Last Call >>>> >>>>What percentage of the token card market do you think Security Dynamics >>>>and >>>>AssureNet Pathways has? I would guess at least 80%. I've never even >>>>heard >>>>of any other token card vendor. So EAP's "Generic Token Card" scheme >>>>won't >>>>work for the majority of the cases. Is that what we want? >>>> >>>>Is there anybody on the list from Security Dynamics or AssureNet Pathways >>>>that has any opinion on this? It seems it is in your best interest to >>>>have >>>>a compatible protocol to support your product. >>>> >>>>Kyle >>>> >>>>At 09:44 PM 11/26/96 -0800, Glen Zorn wrote: >>>>>It seems to me that the "Generic Token Card" requests are just that: >>>>>generic. If you have a token card that doesn't fit the "generic" mold >>>>>(and I would include SecurID in that category), it makes more sense to >>>>>me to extend EAP (what a concept) to support the special case, rather >>>>>than trying to stretch "generic" into "one-size-fits-all". >>>>> >>>>>>---------- >> >>>>>>Sent: Tuesday, November 26, 1996 10:10 AM >>>>>>To: Larry J. Blunk >>>>>>Cc: Karl Fox; ietf-ppp@MERIT.EDU; jrv@home.merit.edu; Whelan, Bill >>>>>>Subject: Re: PPP Extensible Authentication Protocol (EAP) - Working >>>>>>Grou >>>p >>>>>>Last Call >>>>>> >>>>>>At 11:41 AM 11/26/96 -0500, Larry J. Blunk wrote: >>>>>>> >>>>>>> You mentioned that hiding PIN numbers is one requirement. I could >>>>>>>potentially see the PIN number being entered in response to the EAP >>>>>>>"Identity" >>>>>>>request. The could be problematic as the "Identity" request currently >>>>>>>makes no provision for hiding user input. Do you forsee Token card >>>>>>>users using their PIN as their identity, or would they typically have >>>>>>>a different label to identify themselves if prompted with an >>>>>>>"Identity" request. The EAP spec currently does not mandate an >>>>>>>initial "Identity" request, but I would suspect that most >>>>>>>implementation >>>>>>>would use this. >>>>>>> >>>>>>Both Token cards I mentioned require a username. The SecurID requires >>>>>>the >>>>>>PIN to be entered with the token. The AssureNet Pathways will send a >>>>>>challenge to the user which is used with the PIN as input to the token >>>>>>card. >>>>>> >>>>>>> As far as the option of echoing "*"'s. Although I'm not >>>>>>>particularly >>>>>>>opposed to this option, I think I'd prefer to leave the choice of the >>>>>>>blanking character up to the implementation. >>>>>>> >>>>>>The point is the token card authentication server will attempt to have a >>>>>>dialog with the remote user. It needs to control when the characters on >>>>>>the >>>>>>user repsonse are to blanked and when they need to be "*"ed. >>>>>> >>>>>>I think what we are talking about is a terminal mode which I am >>>>>>beginning >>>>>>to >>>>>>think is wrong for PPP to handle. I've heard it suggested that this >>>>>>type >>>>>>of >>>>>>authentication could be handled using a UNIX terminal mode (I think it's >>>>>>called 'getty') above IPCP. But what if the link is an IPXCP link? I >>>>>>don't >>>>>>have any answers but I know the Generic Token Card request packets will >>>>>>be >>>>>>a >>>>>>restriction on what the token card vendors really want. >>>>>> >>>>>>Kyle >>>>>>-------------------------------------------------------- >>>>>> Kyle Farnsworth ADTRAN Inc. >>>>>> (205)971-8583 kfarnsworth@adtran.com >>>>>>-------------------------------------------------------- >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>-------------------------------------------------------- >>>> Kyle Farnsworth ADTRAN Inc. >>>> (205)971-8583 kfarnsworth@adtran.com >>>>-------------------------------------------------------- >>>> >>>> >>>> >>>> >>>>Original Recipient: GONZALO.DVSEMAIL @ DPMAIL >>>> >> >> >-------------------------------------------------------- > Kyle Farnsworth ADTRAN Inc. > (205)971-8583 kfarnsworth@adtran.com >-------------------------------------------------------- > > > > >Original Recipient: GONZALO.DVSEMAIL @ DPMAIL > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 5 17:11:14 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id RAA25584; Thu, 5 Dec 1996 17:11:14 -0500 (EST) Resent-Date: Thu, 5 Dec 1996 17:11:14 -0500 (EST) Date: Thu, 5 Dec 1996 17:10:00 -0500 From: eallen@BayNetworks.COM (Ed Allen) Message-Id: <199612052210.RAA05407@pobox.BayNetworks.com> To: ietf-ppp@MERIT.EDU Subject: PPP WG agenda? Resent-Message-ID: <"o8tzB.0.JF6.RXqfo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2244 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Apologies if I've simply missed it.... Has a tentative agenda for the PPP meetings been established? Last thing I saw was Karl's request for agenda suggestions. - Ed - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 6 10:02:37 1996 Received: (from slist@localhost) by merit.edu (8.7.6/merit-2.0) id KAA05349; Fri, 6 Dec 1996 10:02:37 -0500 (EST) Resent-Date: Fri, 6 Dec 1996 10:02:37 -0500 (EST) Date: Fri, 6 Dec 1996 07:01:57 -0800 Message-Id: <199612061501.HAA11454@spud.ascend.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Subject: Agenda for San Jose PPPEXT meetings Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"Xq_Au.0.GJ1.gL3go"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2245 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU We will meet on Tuesday from 1300-1500 and on Wednesday from 1530-1730. We'll work down the agenda in order until we run out of time on Tuesday and finish up on Wednesday. If you don't see your favorite item on the list, let me know and I'll add it on to the end. I've stuck some people on the list who didn't ask to be added, but who are responsible for items important to the group. Hopefully they'll all attend! I look forward to seeing you all in San Jose. -- IETF PPP Extensions Working Group Agenda -- San Jose L2TP Andy Valencia, Gurdeep Singh Pall L2TP Security Baiju Patel PPP over SONET/SDH Bill Simpson RFC 1619 PPP Vendor Extensions Bill Simpson draft-ietf-pppext-vendor-00.txt Protocol Spoofing Randy Sales Packet type assignments for IPv6 and RTP header compression Steve Casner and Mikael Degermark draft-degermark-ipv6-hc-02.txt draft-ietf-avt-crtp-01.txt BACP Craig Richards and Kevin Smith draft-ietf-pppext-bacp-05.txt IPCP Glenn McGregor and Gurdeep Singh Pall RFC 1332 -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 13 18:16:38 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA18152; Fri, 13 Dec 1996 18:16:38 -0500 (EST) Resent-Date: Fri, 13 Dec 1996 18:16:38 -0500 (EST) Posted-Date: Fri, 13 Dec 1996 18:19:46 -0500 (EST) Date: Fri, 13 Dec 1996 18:15:05 -0500 From: eallen@BayNetworks.COM (Ed Allen) Message-Id: <199612132315.SAA08690@pobox.BayNetworks.com> To: ietf-ppp@MERIT.EDU Subject: Multi-chassis PPP Multilink Resent-Message-ID: <"-Iv1d2.0.FR4.wEUio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2246 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi all, At the IETF PPP working group meeting this week I took an informal poll to gauge interest in a standards-based approach to solving the problem of PPP Multilink members which terminate on different boxes (the so-called "cross-box multilink problem"). There was a fair amount of interest in a standard. It was suggested that we devote a separate email list to this topic, rather than use the general ietf-ppp@MERIT.EDU list. I'm in the process of creating a separate (hopefully majordomo) list and mail archive. I'll send more mail to this list, with directions on how to subscribe, when this has been done. Thanks, - Ed - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 13 18:49:56 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA18683; Fri, 13 Dec 1996 18:49:56 -0500 (EST) Resent-Date: Fri, 13 Dec 1996 18:49:56 -0500 (EST) Date: Fri, 13 Dec 1996 16:49:40 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612132349.QAA08969@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Multi-chassis PPP Multilink Resent-Message-ID: <"C2tR_3.0.cZ4.WkUio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2247 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: eallen@BayNetworks.COM (Ed Allen) > At the IETF PPP working group meeting this week > I took an informal poll to gauge interest in > a standards-based approach to solving the problem of > PPP Multilink members which terminate on different > boxes (the so-called "cross-box multilink problem"). > > There was a fair amount of interest in a standard. > It was suggested that we devote a separate email list > to this topic, rather than use the general > ietf-ppp@MERIT.EDU list. > ... Isn't the explicit and only current justification for BACP solving the same cross-box multilink problem? (I think everyone has agreed that both peers are equally able to count bits/sec in either direction on ISDN links so that BACP has nothing to offer for bandwidth-allocation. I think everyone agrees that BACP is not the right kind of solution for call-back, even if there were not already a call-back protocol.) Isn't the L2TP tunneling protocol an obvious solution for the cross-box multilink problem that (unlike BACP) would require no changes on clients? Does PPP have so few extensions and optional sub-protocols that another one is desired? Or has the L2TP protocol become so entangled in using non-IP transports (e.g. SNA) and complicated by obscure security and mobile-IP problems that people feel that it is ruined for solving the cross-box multilink problem? (I am only an observer of the L2TP or BACP efforts, see no need to add either protocol to SGI's PPP implmentation, and so have no direct interest or direct objection to yet another solution to the cross-box multilink problem. I still think that BACP's communicationg phone numbers is not a solution for the cross-box multilink problem, because it requires each box to reserve ports, which has fatal economic problems. There is also the hassle of getting BACP into clients.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 13 20:01:12 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA19410; Fri, 13 Dec 1996 20:01:12 -0500 (EST) Resent-Date: Fri, 13 Dec 1996 20:01:12 -0500 (EST) Message-Id: <199612140103.AA29856@seegiri.NSD.3Com.COM> To: ietf-ppp@MERIT.EDU Subject: Callback option Organization: 3Com, 5400 Bayfront Plaza, P.O.Box 58145, Santa Clara, CA 95052 Phone.......: (408) 764-6333 (Office) (415) 969-4400 (General Office) Date: Fri, 13 Dec 1996 17:03:55 -0800 From: "Podi Kuruppu" Resent-Message-ID: <"UEsKV.0.xk4.KnVio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2248 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, It seems to me that the support for the Callback option as per RFC1570 can cause one to break the normal PPP rules. I'm specifically referring to this paragraph taken from RFC1570: Implementation Notes: >> A peer which agrees to this option SHOULD request the >> Authentication-Protocol Configuration Option. The user information learned during authentication can be used to determine the user location, or to limit a user to certain locations, or merely to determine whom to bill for the service. Let us say that A calls B and includes the Callback option in his initial Config Request to B. Let us assume that this Config Request is lost, and in the meantime, B sends a Config Request _without_ the Authentication option. When A re-transmits the original Config Request with the Callback option, B realizes he needs to authenticate A before he can agree to honor callback request. This would force B to change the content of the original Config Request to include the authentication option, which, it seems to me, is not legal. A B ----------------------------- -------------------------------------- CR(Callback) ->(lost) <---------- CR(No Authentication) CR(Callback),CA---> (too late to ask for authentication!) <-----------CA One can refrain from originating a Config Requests on a dial-in link as a solution I suppose, but what is the recommended way to handle this situation if I wish to honor callback only with authentication? Thanks, -Podibanda Kuruppu - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 13 21:16:35 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA20218; Fri, 13 Dec 1996 21:16:35 -0500 (EST) Resent-Date: Fri, 13 Dec 1996 21:16:35 -0500 (EST) Date: Fri, 13 Dec 1996 18:16:24 -0800 Message-Id: <199612140216.SAA17169@spud.ascend.com> From: Karl Fox To: ietf-ppp@MERIT.EDU Cc: minutes@ietf.org, kasten@ftp.com, jburgan@baynetworks.com Subject: PPPEXT minutes for San Jose 12/10/96 and 12/11/96 meetings Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"NPsgQ2.0.Yx4._tWio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2249 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Thanks to Matt Holdrege and Scot Wasson for taking these minutes. ----------------------------------------------------------------------------- IETF PPP Extensions Working Group San Jose, 12/10/96 Minutes taken by Matt Holdrege L2TP - Andy Valencia, Gurdeep Singh Pall (absent) Consensus on all pending issues Transport independence - Not dependent on TCP/IP Security Attribute numbering Control message delivery via small LAPD-like reliable protocol Organization of attribute-value pair number required several iterations Consensus on number globally document locally Where possible, share a common description For IP tunnel media, L2TP recommends IPsec Next: Edit and insert markups submitted Andy will publish draft hopefully in 4 weeks Implement! Initial interoperability testing at CIUG in May 1997 John Shriver (Shiva) wants authentication to occur earlier before the tunnel begins to accommodate users with older protocols. This issue will move to the list. L2TP Security - Baiju Patel Basically it was recommended to use IPSEC. PPP over Sonet/SDH - RFC 1619 - Bill Simpson pppsdh@greendragon.com is the new list for this protocol. [New information: listserv@watervalley.net is the address to subscribe to pppsdh. In the body of the message, say subscribe pppsdh YOUR NAME] PPP Vendors Extensions - Bill Simpson - draft-ietf-pppext-vendor-00.txt Recommended to move to an Informational RFC. All implementors should review before requesting numbers from IANA. Protocol Spoofing - Randy Sales of Novell - draft-ietf-pppext-spoof-00.txt Novell has a current implementation in their lab. Randy said that the draft author (Ian - Not Present) has not been able to further refine the draft. Novell would like the PPPEXT WG to help further refine this protocol. It was brought up that this draft has a scalability issue in reference to callback numbers. Novell said that they hope to use tunneling protocols to aid this scaling issue. Further work on timer negotiation needs to be done. John Shriver from Shiva requested that Novell publish a paper detailing just how to spoof NCP. Novell agreed. Bill Simpson noted that IPXCP already covers IPX spoofing. Bill also noted that we have too many protocols that use callback. Bill hopes that we can make whatever changes are necessary to IPXCP to satisfy needs. LCP extensions & callback. Bill sent two drafts out after the deadline. BACP - Craig Richards (absent), Kevin Smith (absent) - draft-ietf-pppext-bacp-05.txt Change the number for BAP so that it doesn't compress. Recommend to create a new version of this draft. Karl will request new numbers from IANA. Ascend is the only vendor in the room shipping BACP. ISSLOW - Carsten Bormann They want to provide fragmentation and suspend/resume mechanisms, header compression, and obtain compressability hints from the application. Big packets can be fragmented by MP, small packets would be sent outside of MP. As for suspending, they need something like H.324 or DSVD. The V.80 modem standard has much lower latency than V.34 and was recommended for RTP applications. They want to make use of the reserved bits in MP header to define classes of priority. They want to define a scheme where the fragmenters and suspenders can happily interoperate. Refer to isslow-fragment-ext-00.txt and draft-ietf-issll-isslow-mcml-00.txt Anita Freeman noted that the next Pac Bell PPP interoperability testing would take place from May 12-16th. ----------------------------------------------------------------------------- IETF PPP Extensions Working Group San Jose, 12/11/96 Minutes taken by Scott Wasson Steve Casner, IP/UDP/RTP Compression - Steve gives a presentation of RTP compression, which is similar to VJ TCP/IP Header Compression. - Need PPP packet types assigned, to differentiate between the IPv4 compression, and several new flavors to support compressed RTP and UDP. - Desire is to combine IPv4 and IPv6 compression into one document. - Discussion about whether both compressions should/would run concurrently. Both NCPs could be Open, allowing independence. Decision was to not allow concurrence so that the existing VJ Protocol ID's could be recycled. John Vollbrecht, Larry Blunk, EAP - No changes needed to the current draft; any new additions to go into a new add-on draft. IP Address option negotiation - None of the original protagonists were present, so the group discussed the issue in their absence. Anything "decided" obviously has to be taken to the mailing list to reach full consensus. - If unit sends: Req(0) -> and peer sends back: <- Nak(addr) ;That's OK. <- Nak(0) ;Prohibited! Never do! <- Rej() ;take default value, "Not Configured". <- Ack(0) ;Prohibited! Never do! Question is: What is the default value of this option? Unnumbered? Manually configured? Not configured? Decided "Not configured" should be the default. This is no change from before. - Discussion about adding a 2-byte "Numbered/Unnumbered" option. - We found that some vendors send cr-0, expecting the peer to supply an IP address. They hoped that the peer would send ca-0, meaning, "I don't have an address to give you, so if you really do have an address but were just trying to be polite and let me pick it, and since I don't have one to give you, now send me yours." - Consensus was that the originator shouldn't have attempted to be so polite. Just send its address. - Frank K. stepped up and pointed out that we were going in circles on the numbered/unnumbered issue, and that we should write up our discussion and bring it to the mailing list. - Brief mention of the next L2TP draft - hope to have it by the end of January. ----------------------------------------------------------------------------- -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 13 21:18:41 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA20266; Fri, 13 Dec 1996 21:18:41 -0500 (EST) Resent-Date: Fri, 13 Dec 1996 21:18:41 -0500 (EST) Posted-Date: Fri, 13 Dec 1996 21:22:08 -0500 (EST) Date: Fri, 13 Dec 1996 21:17:27 -0500 From: eallen@BayNetworks.COM (Ed Allen) Message-Id: <199612140217.VAA12227@pobox.BayNetworks.com> To: vjs@mica.denver.sgi.com Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199612132349.QAA08969@mica.denver.sgi.com> (vjs@mica.denver.sgi.com) Subject: Re: Multi-chassis PPP Multilink Resent-Message-ID: <"WtPQa.0.Ly4.zvWio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2250 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>>>> Vernon Schryver writes: VS> Isn't the L2TP tunneling protocol an obvious solution for the cross-box VS> multilink problem that (unlike BACP) would require no changes on clients? Perhaps L2TP can be used for this purpose. This certainly is not the primary goal of L2TP however, and I doubt there is much support for slowing down the momentum L2TP has by adding anything new, if required for the multi-system multilink issue. If it turns out that L2TP can solve this problem cleanly and securely then this effort will dry up and wither away as it should, with no resulting new protocol. Apparently it's not obvious to everyone that this is the case. In any event, I'd like to suggest that anyone interested in continuing discussion either wait until next week, when your thoughts can be captured in the archive, or just send private email. Thanks, - Ed - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 13 21:37:21 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA20797; Fri, 13 Dec 1996 21:37:21 -0500 (EST) Resent-Date: Fri, 13 Dec 1996 21:37:21 -0500 (EST) Date: Fri, 13 Dec 1996 18:36:42 -0800 (PST) From: Andy Valencia Message-Id: <199612140236.SAA07660@vandys-lap.cisco.com> To: vjs@mica.denver.sgi.com Cc: ietf-ppp@MERIT.EDU Subject: Re: Multi-chassis PPP Multilink Newsgroups: cisco.external.ietf.ppp References: <199612132349.QAA08969@mica.denver.sgi.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Resent-Message-ID: <"2MJTx.0.e45.TBXio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2251 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In cisco.external.ietf.ppp you write: >Isn't the L2TP tunneling protocol an obvious solution for the cross-box >multilink problem that (unlike BACP) would require no changes on clients? I think their intent here is to nail down the protocol which dynamically detects the cross-box problem, and chooses who gets tunneled where. Yes, I believe the actual tunneling would be your garden variety PPP tunnel. In any case, that's how *we* solved the problem. >Does PPP have so few extensions and optional sub-protocols that another >one is desired? No comment! >Or has the L2TP protocol become so entangled in using non-IP transports >(e.g. SNA) and complicated by obscure security and mobile-IP problems >that people feel that it is ruined for solving the cross-box multilink >problem? Hmmm, does SGI need an SNA transport for L2TP? ;-) Seriously, I think all of that is nailed down. The only remaining issue is for me to fold in all the comments and get out the next draft. The good news is I'm tagged for jury duty next week, so I have visions of sitting in a dank courtroom basement with nothing but my laptop and hours of free time.... Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 13 21:39:17 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA20840; Fri, 13 Dec 1996 21:39:17 -0500 (EST) Resent-Date: Fri, 13 Dec 1996 21:39:17 -0500 (EST) Date: Fri, 13 Dec 1996 19:38:59 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612140238.TAA09359@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Multi-chassis PPP Multilink Resent-Message-ID: <"QNOg73.0.I55.HDXio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2252 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: eallen@BayNetworks.COM (Ed Allen) > VS> Isn't the L2TP tunneling protocol an obvious solution for the cross-box > VS> multilink problem that (unlike BACP) would require no changes on clients? > > Perhaps L2TP can be used for this purpose. This certainly is not > the primary goal of L2TP however, and I doubt there is much > support for slowing down the momentum L2TP has by adding > anything new, if required for the multi-system multilink issue. > > If it turns out that L2TP can solve this problem cleanly and > securely then this effort will dry up and wither away as it > should, with no resulting new protocol. > Apparently it's not obvious to everyone that this is the case. > ... How is it not obvious? What have I misunderstood? As I understand L2TP, the idea is that the client has no idea that the server on the other end of the phone line is (or is not) the client's home server. Consider what that means for multilink. Say a client dials a phone number twice, and gets either two ports on one box or two ports, one on each of two boxes. In either case, let each (or the) box authenticate the client on each LCP connection and start a tunnel to the home box of the client. The home box could be dynamically determined (e.g. radius server notes the first box that answers and makes it the home for the duration), or the home box could be static defined as part of the client's profile. The home box could be (one of) the box(es) terminating the two phone lines, or the home box could be a third box. In any case, the client ends with a pair LCP connections to the single home box. The client then starts negotiating RFC 1717 MP, and everything works find, because only the single server home box knows or cares that MP is involved. As for security--if L2TP is good enough a single PPP channel without any MP involvement, then it must be secure enough for MP over two or more PPP channels. In all cases, as with all MP bundles, each individual link in the bundle is individually authenticated. I think a protocol designed to solve only the MP multi-chassis problem would be simpler than either BACP or what L2TP has become, but having L2TP and BACP is always going to be simpler than L2TP and BACP plus any third protocol, no matter how simple the third protocol. The biggest technical problem in the PPP protocols is the enormous number of choices not made by the working group. It is as if we'd looked at the OSI TP0-TP4 and CLNS/CONS towers of babel and decided show those guys up for pikers and really pile on the options, extensions, and alternatives. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 13 21:48:48 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA21040; Fri, 13 Dec 1996 21:48:48 -0500 (EST) Resent-Date: Fri, 13 Dec 1996 21:48:48 -0500 (EST) Date: Fri, 13 Dec 1996 19:48:33 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612140248.TAA09390@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Multi-chassis PPP Multilink Resent-Message-ID: <"1m3tm.0.R85.CMXio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2253 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Andy Valencia > >Isn't the L2TP tunneling protocol an obvious solution for the cross-box > >multilink problem that (unlike BACP) would require no changes on clients? > > I think their intent here is to nail down the protocol which dynamically > detects the cross-box problem, and chooses who gets tunneled where. Yes, > I believe the actual tunneling would be your garden variety PPP tunnel. In > any case, that's how *we* solved the problem. > ... Why do you need to detect the cross-box problem and do any choosing? Why not just open the tunnels and let the home box sort it out, just as if no tunnels were involved? Even for a single LCP link, with no cross-box problems, what are you doing in L2TP to find the home box? When a PPP L2TP server answers the phone and somehow decides to open a tunnel to the client's home, how does the server know the client's home? There must be some kind of distributed database for finding the client's home box. What is the difference between finding the home box for one tunnel and finding the home for two tunnels? Why not use radius or whatever you are already using for centralized authentication? Why would you want to spend more time exchanging more packets, have more databases to maintain, recover from crashes, etc., and have more protocols specify, argue, code, argue, debug, argue, and document? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 13 22:48:30 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id WAA22039; Fri, 13 Dec 1996 22:48:30 -0500 (EST) Resent-Date: Fri, 13 Dec 1996 22:48:30 -0500 (EST) Date: Fri, 13 Dec 1996 19:47:46 -0800 (PST) From: Andy Valencia Message-Id: <199612140347.TAA07839@vandys-lap.cisco.com> To: vjs@mica.denver.sgi.com Cc: ietf-ppp@MERIT.EDU Subject: Re: Multi-chassis PPP Multilink Newsgroups: cisco.external.ietf.ppp References: <199612140248.TAA09390@mica.denver.sgi.com> X-Newsreader: NN version 6.5.0 #1 (NOV) Resent-Message-ID: <"VO-nL2.0.-N5.AEYio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2254 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In cisco.external.ietf.ppp you write: >> I think their intent here is to nail down the protocol which dynamically >> detects the cross-box problem, and chooses who gets tunneled where. Yes, >> I believe the actual tunneling would be your garden variety PPP tunnel. In >> any case, that's how *we* solved the problem. >Why do you need to detect the cross-box problem and do any choosing? >Why not just open the tunnels and let the home box sort it out, just >as if no tunnels were involved? Inevitably, you'll need more than one home box, and the problem is back. >... >Why not use radius or whatever you are already using for centralized >authentication? Why would you want to spend more time exchanging more >packets, have more databases to maintain, recover from crashes, etc., >and have more protocols specify, argue, code, argue, debug, argue, and >document? There are two levels to my answer. From a pure IETF perspective, I'd be fine on saying this approach is the way to solve the problem. Note that the RADIUS solution still begs the question of database consistency, especially consistency across network interruptions and server crashes. The current RADIUS protocol is not well suited to maintaining and/or reestablishing a consistent view of NAS state from a given RADIUS daemon. Fixing this might be the cleanest architectural approach to the multiple NAS problem. When we created the Cisco product, we were told that it would be better if the NAS's themselves solved the problem, so the authentication server could be any code, any protocol, at any revision level without concern. This is not an unimpeachable argument for pursuing a new standards track protocol, admittedly. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Dec 14 19:25:38 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA27746; Sat, 14 Dec 1996 19:25:38 -0500 (EST) Resent-Date: Sat, 14 Dec 1996 19:25:38 -0500 (EST) Date: 14 Dec 96 19:23:42 EST From: "Mark A. Beadles" To: "ietf-ppp@MERIT.EDU" Subject: Re: Multi-chassis PPP Multilink Message-ID: Resent-Message-ID: <"GTPZV3.0.nm6.ULqio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2255 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: vjs@mica.denver.sgi.com (Vernon Schryver) >Why do you need to detect the cross-box problem and do any choosing? >Why not just open the tunnels and let the home box sort it out, just >as if no tunnels were involved? >Even for a single LCP link, with no cross-box problems, what are you >doing in L2TP to find the home box? When a PPP L2TP server answers the >phone and somehow decides to open a tunnel to the client's home, how >does the server know the client's home? There must be some kind of >distributed database for finding the client's home box. What is the >difference between finding the home box for one tunnel and finding the >home for two tunnels? This is great when there is one home box. However, it could very likely be the case that there are two home boxes at the other end of the tunnels. In this case, the multilink problem is still there. The problem with your analysis is assuming that there is "THE home box". There may very well be multiple home boxes, with selection among them for load balancing, for example. How the home box is arrived at is immaterial. What matters is that there is no way for the second PPP L2TP Server answering the phone to know that it should connect to the same home box that the first PPP L2TP Server did, when there are multiple possiblities for the home box. +---------------------------+ | Mark Anthony Beadles | |CompuServe Network Services| |Network Product Engineering| +---------------------------+ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Dec 14 20:34:01 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA28420; Sat, 14 Dec 1996 20:34:01 -0500 (EST) Resent-Date: Sat, 14 Dec 1996 20:34:01 -0500 (EST) From: "Shoou J. Yiu" Message-Id: <199612150133.RAA01463@puli.cisco.com> Subject: Re: Multi-chassis PPP Multilink To: ietf-ppp@MERIT.EDU Date: Sat, 14 Dec 1996 17:33:24 -0800 (PST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"epwb51.0.lx6.5Mrio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2256 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From: vjs@mica.denver.sgi.com (Vernon Schryver) > Why do you need to detect the cross-box problem and do any choosing? > Why not just open the tunnels and let the home box sort it out, just > as if no tunnels were involved? > > Even for a single LCP link, with no cross-box problems, what are you > doing in L2TP to find the home box? When a PPP L2TP server answers the > phone and somehow decides to open a tunnel to the client's home, how > does the server know the client's home? There must be some kind of > distributed database for finding the client's home box. What is the > difference between finding the home box for one tunnel and finding the > home for two tunnels? > > Why not use radius or whatever you are already using for centralized > authentication? Why would you want to spend more time exchanging more > packets, have more databases to maintain, recover from crashes, etc., > and have more protocols specify, argue, code, argue, debug, argue, and > document? > It might be useful to draw a distinction here. In a L2F or L2TP environment where the user is statically mapped from the NAS to a particular Home-gateway (aka home box), you are correct in saying that it does not matter where the first, second or Nth call ends up received on whichever NAS - they all terminate on a single home-box for the same user. Multilink kicks in as a normal part of PPP negotiation on the Home-box - in that sense - Multichassis multilink works without any additional tweaks to Radius or any other authentication server. However, if the model were a grouping of boxes at a single site with scalability of ports in mind (in effect, they are all NASes) and no predisposed notion of which user terminates at which box, then Radius or any authentication server has to serve as more than an authentication server if this method is pursued. We ourselves have pursued it from another angle. Shoou - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Dec 15 00:56:22 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id AAA29635; Sun, 15 Dec 1996 00:56:22 -0500 (EST) Resent-Date: Sun, 15 Dec 1996 00:56:22 -0500 (EST) Date: Sat, 14 Dec 1996 22:56:04 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612150556.WAA12884@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Multi-chassis PPP Multilink Resent-Message-ID: <"fby5X3.0.kE7.0Cvio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2257 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Mark A. Beadles" > ... > >Why do you need to detect the cross-box problem and do any choosing? > >Why not just open the tunnels and let the home box sort it out, just > >as if no tunnels were involved? > > >Even for a single LCP link, with no cross-box problems, what are you > >doing in L2TP to find the home box? When a PPP L2TP server answers the > >phone and somehow decides to open a tunnel to the client's home, how > >does the server know the client's home? There must be some kind of > >distributed database for finding the client's home box. What is the > >difference between finding the home box for one tunnel and finding the > >home for two tunnels? > > This is great when there is one home box. However, it could very likely > be the case that there are two home boxes at the other end of the tunnels. > In this case, the multilink problem is still there. The problem with your > analysis is assuming that there is "THE home box". There may very well be > multiple home boxes, with selection among them for load balancing, for > example. How the home box is arrived at is immaterial. What matters is > that there is no way for the second PPP L2TP Server answering the phone > to know that it should connect to the same home box that the first PPP > L2TP Server did, when there are multiple possiblities for the home box. I don't see the issue. I'm not assuming there is a permanent, unique home box. As I wrote more than once, "THE home box" necessarily exists at any given instant (else MP cannot work), but can and must be dynamically chosen. Ignore MP for the moment. For load balancing and other reasons, you want more than one home box for a single client link, but not more than one home box in any short interval. How do you handle the dynamic allocation of the single home box for lines not using MP? For a single, non-MP link, you need stability and global state for things like routing; the whole ISP network of boxes must know which is home box for the client tonight. The load balancer must know to balance load. The other boxes must know to forward IP packets. The accounting system must know to generate bills. Etc. If the client gets disconnected and then dials in again (e.g. modems, an external ISDN TA with flakey cable, or someone using one 1 B channel with call-bumping and taking an analog call), a minimally good ISP solution for the single link problem gives the client the same IP address it had on its recent call so that the user's TCP/IP connections can continue (e.g. FTP or telnet sessions). That means that the (temporally) second connection must somehow find the current "THE home box" to make routing (or proxy-ARP) work tolerably. Again, this is for a single channel client not using MP. It is clear that if you solve all of that for a single client link, you will have incidentally solved the multilink problem, with no special PPP protocol extending. Maybe more protocol work is needed. I suspect it belongs in Radius, and will eventually be there (or in a replacement for Radius) for the single link reasons, but never mind. The big danger of charging off into yet another special purpose PPP extension protocol is that it will be as successful, widely used, and generally a good use of people's time and their employer's money as most PPP extensions. Does anyone implement more than 10% of the current PPP protocols and extensions? Have you finished removing self-describing padding from your code? How many of the compression protocols do you support? It is not good to reason "X has something to do with PPP, PPP is a protocol, therefore X must be a PPP extension." That a mechanism is needed for PPP does not imply that the mechanism is a PPP or even IETF protocol. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sun Dec 15 01:30:29 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id BAA29937; Sun, 15 Dec 1996 01:30:29 -0500 (EST) Resent-Date: Sun, 15 Dec 1996 01:30:29 -0500 (EST) To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: Re: Multi-chassis PPP Multilink In-Reply-To: Your message of "Sat, 14 Dec 1996 22:56:04 MST." <199612150556.WAA12884@mica.denver.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 14 Dec 1996 22:30:08 -0800 Message-Id: <15815.850631408@dumbcat.codewright.com> From: Marco S Hyman Resent-Message-ID: <"xp8e03.0.QJ7.1ivio"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2258 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > Ignore MP for the moment. For load balancing and other reasons, you > want more than one home box for a single client link, but not more than > one home box in any short interval. How do you handle the dynamic > allocation of the single home box for lines not using MP? For a I think there are (at least) two models in use here. One model is to make the box handling the current call the "home" box and migrate any state kept for the user to that box. This model requires a method for a box to find out if there is any other box holding state for the user, e.g. assigned IP addresses, filters, whatever; and a method to get that state to the current "home" box. As I understand the model you are writing about there is a "home" box for every user and there must be a way, RADIUS, TACACS+, whatever, to find out what the home box is. Once that problem is solved, then a simple L2TP tunnel to the home box is enough and need no new PPP protocol/options/etc. I agree with what I think you said :-) The 2nd model scales better, and is a problem that I believe has to be solved anyway. // marc - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 16 10:59:05 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA11044; Mon, 16 Dec 1996 10:59:05 -0500 (EST) Resent-Date: Mon, 16 Dec 1996 10:59:05 -0500 (EST) Date: Mon, 16 Dec 1996 08:58:00 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612161558.IAA14953@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Multi-chassis PPP Multilink Resent-Message-ID: <"YjOIP.0.7i2.N6Njo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2259 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Marco S Hyman > > Ignore MP for the moment. For load balancing and other reasons, you > > want more than one home box for a single client link, but not more than > > one home box in any short interval. How do you handle the dynamic > > allocation of the single home box for lines not using MP? For a > > I think there are (at least) two models in use here. One model is to > make the box handling the current call the "home" box and migrate any > state kept for the user to that box. This model requires a method for > a box to find out if there is any other box holding state for the user, > e.g. assigned IP addresses, filters, whatever; and a method to get that > state to the current "home" box. > > As I understand the model you are writing about there is a "home" box > for every user and there must be a way, RADIUS, TACACS+, whatever, > to find out what the home box is. Once that problem is solved, then > a simple L2TP tunnel to the home box is enough and need no new PPP > protocol/options/etc. > > I agree with what I think you said :-) The 2nd model scales better, > and is a problem that I believe has to be solved anyway. Call the first model "stocastic home box assignment" and the second "manually configured home box assignment." Both both require global state shared among all boxes even for non-MP, single-link clients. There is always one home box for every client, and tunnels to the home box are desirable even for single-link clients. The only difference is whether the home box can change without manual intervention. In the stocastic home model for a single-link client, that first box must tell all of the other boxes that the client is connected. If the client has a flat-rate deal, then the ISP must ensure that there is never more than one connection. Otherwise ISPs would quickly find thousands of people simultaneously sharing flat-rate accounts. (If you have an account with Netcom, try logging in twice.) Consider what should happen in the first model if a single-link client is inadvertently disconnected by a modem hiccup, say a call-waiting beep or someone picking up a phone extension. People at least at some vendors will realize that users prefer having their TCP/IP/single-link-PPP connections remain alive despite hiccups because the boxes at their ISP do the right things. As soon as they ship product, all of their colleagues will also realize it. At least routing or proxy-ARP would prefer opening a tunnel between the box that answers the 2nd phone call and the box that had the original phone call. Once you really solve the multi-box non-MP problem, adding MP is a small addition that requires no new protocols. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 16 16:22:28 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA16463; Mon, 16 Dec 1996 16:22:28 -0500 (EST) Resent-Date: Mon, 16 Dec 1996 16:22:28 -0500 (EST) Message-ID: From: Al Longyear To: "'ietf-ppp@merit.edu'" Subject: infinite loop (new condition) Date: Mon, 16 Dec 1996 13:22:15 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"BYLyn1.0.t04.FsRjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2260 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I have a problem with what seems to be a contradiction. The problem is similar to the one which Archie Cobbs reported earlier in that the LCP protocol seems to be breaking down and the two systems fail to reach a common configuration. The problem is happening with several different platforms, with several different people. I am including the trace log which shows the local system sending and receiving the frames sent to it by a commercial terminal server product. In respect for Mr. Schryver, I shall not mention the names of the two products here. (I will if you ask in private email.) I would like to point out that the LCP configure request frames are being received by the local system. They are, in turn, being validly acknowledged. The local system sends out a LCP configure request frame which never seems to be acknowledged. The local system then retransmits the frame at the time out interval of three seconds for a total of ten different attempts before it considers the link invalid and terminates. The peer system is sending the LCP configure request frames, over and over again. Each has a different magic number and a different ID. The IDs are being validly acknowledged, to my knowledge they should be received, yet they never seem to be accepted. I checked the local's side code and the ACK processing does check the ID value against what is expected and will toss the invalid ACK. (Of course, since I never see an ACK to the local's configure request frame, that code is never reached.) The local system sees the frames with a valid FCS (or they would never have made it this far through the driver) so the peer system is sending all bits in the octet. (It is not configured to send only seven data bits per octet with the MSB being a parity value.) The peer system is not retransmitting the frames since the ID values change and the magic numbers are different. Yet, they do come at what is a common timeout interval of three seconds as suggested by the RFC. Is there any help that anyone can provide as to what may be wrong with this configuration? I am at a loss to explain just what is wrong. Yet, it is happening on several different vendors and several different connections. Many thanks. Dec 11 11:47:21 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:24 local pppd[135]: rcvd [LCP ConfReq id=0x2 ] Dec 11 11:47:24 local pppd[135]: sent [LCP ConfAck id=0x2 ] Dec 11 11:47:24 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:27 local pppd[135]: rcvd [LCP ConfReq id=0x3 ] Dec 11 11:47:27 local pppd[135]: sent [LCP ConfAck id=0x3 ] Dec 11 11:47:27 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:30 local pppd[135]: rcvd [LCP ConfReq id=0x4 ] Dec 11 11:47:30 local pppd[135]: sent [LCP ConfAck id=0x4 ] Dec 11 11:47:30 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:33 local pppd[135]: rcvd [LCP ConfReq id=0x5 ] Dec 11 11:47:33 local pppd[135]: sent [LCP ConfAck id=0x5 ] Dec 11 11:47:33 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:36 local pppd[135]: rcvd [LCP ConfReq id=0x6 ] Dec 11 11:47:36 local pppd[135]: sent [LCP ConfAck id=0x6 ] Dec 11 11:47:36 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:39 local pppd[135]: rcvd [LCP ConfReq id=0x7 ] Dec 11 11:47:39 local pppd[135]: sent [LCP ConfAck id=0x7 ] Dec 11 11:47:39 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:42 local pppd[135]: rcvd [LCP ConfReq id=0x8 ] Dec 11 11:47:42 local pppd[135]: sent [LCP ConfAck id=0x8 ] Dec 11 11:47:42 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:45 local pppd[135]: rcvd [LCP ConfReq id=0x9 ] Dec 11 11:47:45 local pppd[135]: sent [LCP ConfAck id=0x9 ] Dec 11 11:47:45 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:48 local pppd[135]: rcvd [LCP ConfReq id=0xa ] Dec 11 11:47:48 local pppd[135]: sent [LCP ConfAck id=0xa ] Dec 11 11:47:48 local pppd[135]: sent [LCP ConfReq id=0x1 ] Dec 11 11:47:51 local pppd[135]: rcvd [LCP ConfReq id=0xb ] Dec 11 11:47:51 local pppd[135]: sent [LCP ConfAck id=0xb ] Dec 11 11:47:51 local pppd[135]: LCP: timeout sending Config-Requests Dec 11 11:47:51 local pppd[135]: Connection terminated. Dec 11 11:47:51 local pppd[135]: Exit. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 16 19:02:54 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA19355; Mon, 16 Dec 1996 19:02:54 -0500 (EST) Resent-Date: Mon, 16 Dec 1996 19:02:54 -0500 (EST) From: Archie Cobbs Message-Id: <199612170001.QAA12256@bubba.whistle.com> Subject: Re: infinite loop (new condition) In-Reply-To: from Al Longyear at "Dec 16, 96 01:22:15 pm" To: longyear@sii.com (Al Longyear) Date: Mon, 16 Dec 1996 16:01:38 -0800 (PST) Cc: ietf-ppp@MERIT.EDU X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0-aSn1.0.5k4.cCUjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2261 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I have a problem with what seems to be a contradiction. The problem is > similar to the one which Archie Cobbs reported earlier in that the LCP > protocol seems to be breaking down and the two systems fail to reach a > common configuration. > > The problem is happening with several different platforms, with several > different people. Looks pretty mysterious, although it is consistent with your connection being "one way", ie., you are able to recieve frames but not transmit them, although the software thinks that it transmitted them... What (hardware) components do all of the test cases have in common? That is, could it be something as simple as a bad serial cable or modem? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 16 19:43:57 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA20216; Mon, 16 Dec 1996 19:43:57 -0500 (EST) Resent-Date: Mon, 16 Dec 1996 19:43:57 -0500 (EST) Date: Mon, 16 Dec 1996 17:43:42 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612170043.RAA17835@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: infinite loop (new condition) Resent-Message-ID: <"xBXfy.0.Vx4.8pUjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2262 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Al Longyear > ... > I am including the trace log which shows the local system sending and > receiving the frames sent to it by a commercial terminal server product. > In respect for Mr. Schryver, I shall not mention the names of the two > products here. (I will if you ask in private email.) I do not recall complaining about naming names when the names are relevant to an explicit problem and not part of a witch hunt, an effort to get revenge, or prospecting/blackmailing in search of clients for consulting services. When the names aren't relevant, not naming names is handy since it reduces the number of what might be called strongly stated counter-statements. Note that /var/log/messages entries (such as those quoted) are often all but the same as naming one of the names. > ... > The peer system is not retransmitting the frames since the ID values > change and the magic numbers are different. Yet, they do come at what is > a common timeout interval of three seconds as suggested by the RFC. On the contrary, a retransmitted LCP Configure-Request might well have a different ID value. The word is "MAY" in the following text in section 5.1 of RFC 1661: ] The Identifier field MUST be changed whenever the contents of the ] Options field changes, and whenever a valid reply has been ] received for a previous request. For retransmissions, the ] Identifier MAY remain unchanged. Years ago I argued for using a constant ID for retransmissions. I was wrong. It doesn't speed things up on a slow link as I thought, since the retransmissions and the responses to the retransmissions trigger state changes. My guess about this problem is the same as everyone else's, that the link is unidirectional. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 04:42:00 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id EAA24441; Tue, 17 Dec 1996 04:42:00 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 04:42:00 -0500 (EST) Mime-Version: 1.0 Date: Tue, 17 Dec 1996 09:39:38 +0000 Message-ID: <2b66a720@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re: infinite loop (new condition) To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"16Ukd3.0.Yz5.Vhcjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2263 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes (in response to Al Longyear): > On the contrary, a retransmitted LCP Configure-Request might well > have a different ID value. The word is "MAY" in the following text > in section 5.1 of RFC 1661: >] The Identifier field MUST be changed whenever the contents of the >] Options field changes, and whenever a valid reply has been >] received for a previous request. For retransmissions, the >] Identifier MAY remain unchanged. >Years ago I argued for using a constant ID for retransmissions. I was >wrong. It doesn't speed things up on a slow link as I thought, since >the retransmissions and the responses to the retransmissions trigger >state changes. In my view, leaving the ID the same for a retransmission is a BAD IDEA. Consider the case if the RTO is too short, say due to a temporary processing hiatus in the peer: <--------- CfgReq RCR+: tld,scr,sca/8 CfgReq (1) ---------> CfgAck ---------> TO+: scr/8 CfgReq (1) ---------> <--------- CfgAck (1) RCA: irc,tlu/9 <--------- CfgAck (1) RCA: tld,scr/6x CfgReq (1) ---------> (etc. possibly leading to infinite loop) If the ID is changed on each retransmission, then CfgReq (1) ---------> TO+: scr/8 CfgReq (2) ---------> <--------- CfgAck (1) (ignored) <--------- CfgAck (2) RCA: irc,tlu/9 Much better. > My guess about this problem is the same as everyone else's, that the > link is unidirectional. Quite - it's fairly obvious that the peer isn't receiving anything, because it hasn't sent any response to the Configure Requests - the only states in which it wouldn't send anything for the RCR+ and RCR- events are states 0, 1, 4 & 5, and it can't be in any of those states if it has sent its own Configure Request. Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 10:42:08 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA28110; Tue, 17 Dec 1996 10:42:08 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 10:42:08 -0500 (EST) From: Craig Fox Message-Id: <199612171540.HAA08286@greatdane.cisco.com> Subject: Re: infinite loop (new condition) To: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Date: Tue, 17 Dec 96 7:40:18 PST Cc: ietf-ppp@MERIT.EDU In-Reply-To: <2b66a720@rdl.co.uk>; from "Jonathan Goodchild" at Dec 17, 96 9:39 am X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"RgkBw.0.ps6.dyhjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2264 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > Vernon Schryver writes (in response to Al Longyear): > > > On the contrary, a retransmitted LCP Configure-Request might well > > have a different ID value. The word is "MAY" in the following text > > in section 5.1 of RFC 1661: > > >] The Identifier field MUST be changed whenever the contents of the > >] Options field changes, and whenever a valid reply has been > >] received for a previous request. For retransmissions, the > >] Identifier MAY remain unchanged. > > >Years ago I argued for using a constant ID for retransmissions. I was > >wrong. It doesn't speed things up on a slow link as I thought, since > >the retransmissions and the responses to the retransmissions trigger > >state changes. > > In my view, leaving the ID the same for a retransmission is a BAD IDEA. > Consider the case if the RTO is too short, say due to a temporary > processing hiatus in the peer: > > <--------- CfgReq > RCR+: tld,scr,sca/8 > CfgReq (1) ---------> > CfgAck ---------> > TO+: scr/8 > CfgReq (1) ---------> > <--------- CfgAck (1) > RCA: irc,tlu/9 > <--------- CfgAck (1) > RCA: tld,scr/6x > CfgReq (1) ---------> (etc. possibly leading to infinite loop) > It does not lead to an infinite loop unless the RTO is too short for all of the packets. It just leads to a thrashing as LCP appears to be Open for an instant and then drops back into a negotiating state. No big deal. PPP is fairly robust in this respect. Sooner or later it will recover from this problem. And it will take no longer than the solution below. Craig > If the ID is changed on each retransmission, then > > CfgReq (1) ---------> > TO+: scr/8 > CfgReq (2) ---------> > <--------- CfgAck (1) > (ignored) > <--------- CfgAck (2) > RCA: irc,tlu/9 > > Much better. > > > > My guess about this problem is the same as everyone else's, that the > > link is unidirectional. > > Quite - it's fairly obvious that the peer isn't receiving anything, > because it hasn't sent any response to the Configure Requests - the > only states in which it wouldn't send anything for the RCR+ and RCR- > events are states 0, 1, 4 & 5, and it can't be in any of those states > if it has sent its own Configure Request. > > Jonathan.Goodchild@rdl.co.uk > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 11:03:07 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA28876; Tue, 17 Dec 1996 11:03:07 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 11:03:07 -0500 (EST) From: "Steven A. Bade" Message-Id: <199612171602.KAA24014@r1100rs.austin.ibm.com> Subject: Question on RFC 2023 IP V6 over PPP To: ietf-ppp@MERIT.EDU Date: Tue, 17 Dec 1996 10:02:57 -0600 (CST) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"dTykf2.0.s27.tGijo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2265 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I've got a question on the text in RFC 2023 (IP Version 6 over PPP). On page 5 (where it talks about the protocol exchange) it states "If the two Interface-Tokens are different, but the received Interface-Token is zero, a Configure-Ack is sent with a non-zero Interface-Token value suggested for use by the remote peer...." I believe this to be in error, I think it should read Configure-Nak since the response is suggesting a value, not acknowledging the the request... Any comments? -- Steven A. Bade -- IBM Risc 6000 Division WAN Communications Software Engineer bade@austin.ibm.com ** All opinions are my own.. ** (512)838-8207 (T/L 678) Fax (512)838-3509 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 13:53:29 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA02005; Tue, 17 Dec 1996 13:53:29 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 13:53:29 -0500 (EST) Date: Tue, 17 Dec 1996 10:59:00 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: ietf-ppp@MERIT.EDU Subject: RFC 1968 / RFC1969 (Encryption) Padding Question Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"584y-3.0.zU.amkjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2266 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU BackGround =========== When DES encryption is used, it may be necessary to increase the size of data being encrypted to be a multiple of 8 bytes so that DES encryption can work correctly. When the block is decrypted the receiver is unable to determine if padding of the pdu took place unless self described padding has been negotiated. Note: if stac lzs compression was being used and could be assumed on every frame (false assumption) the real length would be determined when the frame was decompressed provider the end-maker of zero was always explicitly sent. This is not true for the Ascend version of STAC compression due to its encoding. There is no problem unless the length of extended data block matters to the receiver. In the case of IP, IPX, etc there is no problem since the real length is contained in the protocol, however there may be a problem when bridging is preformed since some protocols may not contain the explicit length of the pdu. If this is the case than the RFC recommends the use of Self Described Padding (SDP). Questions ========= Is anyone aware of a protocol where the length cannot be deduced by the receiver where SDP would be required? I am asking this since on Ethernet, the minimum packet size can be more than the user sent, thus making use of such a protocol difficult. We always recompute the CRC when sending bridged frames. Is there any reason why we should not change the RFC to allow the negotiation of an extra byte in the header to indicate the number of pad bytes added so that the use of SDP would not be necessary. This seems to me a cleaner approach, since if padding is needed it takes a lot less bytes to encode in the header then using SDP. regards, Philip Rakity FlowPoint Tel (408) 364-8300 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 14:31:34 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA03093; Tue, 17 Dec 1996 14:31:34 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 14:31:34 -0500 (EST) Date: Tue, 17 Dec 1996 11:30:20 -0800 Message-Id: <199612171930.LAA25010@spud.ascend.com> From: Karl Fox To: Philip Rakity Cc: ietf-ppp@MERIT.EDU Subject: RFC 1968 / RFC1969 (Encryption) Padding Question In-Reply-To: References: Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"U6vlH1.0.-l.HKljo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2268 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Philip Rakity writes: > Is there any reason why we should not change the RFC to allow the > negotiation of an extra byte in the header to indicate the number of pad > bytes added so that the use of SDP would not be necessary. This seems to > me a cleaner approach, since if padding is needed it takes a lot less > bytes to encode in the header then using SDP. It may indeed be cleaner, but we already have a specification; your argument should have been brought up earlier, before DESE became an Informational RFC. As it is written, the existing specification works properly, and although changes sometimes are made to protocols to correct defects, they are seldom changed to add minor performance enhancements. Actually, I'm not sure a single length byte that is always included is better than self-describing pad. I suspect they're about the same. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 14:30:22 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA02997; Tue, 17 Dec 1996 14:30:22 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 14:30:22 -0500 (EST) Date: Tue, 17 Dec 1996 14:26:47 -0500 (EST) From: John Shriver Message-Id: <199612171926.OAA12617@shiva-dev.shiva.com> To: pmr@flowpoint.com CC: ietf-ppp@MERIT.EDU In-reply-to: (message from Philip Rakity on Tue, 17 Dec 1996 10:59:00 -0800 (PST)) Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question Resent-Message-ID: <"L2Udq.0.Vk.9Jljo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2267 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Well, yeah, any PPP implementation is free to pad the packet at the physical level. A lot of HDLC chips used to insist on doing this. In general, the specifications for X over PPP have added a length field if X doesn't have one. The specific example I was very involved with is DECnet Phase IV over PPP, where there is a length field. The exception appears to be Multilink. There is no length field preceeding the individual fragments. Now, this would only be an issue for ECP when running it under Multilink. If running ECP on top of Multilink, that problem doesn't happen. So, you really only need to negotiate self-decribing padding for ECP under Multilink. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 14:58:29 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA03888; Tue, 17 Dec 1996 14:58:29 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 14:58:29 -0500 (EST) Posted-Date: Tue, 17 Dec 1996 15:02:04 -0500 (EST) Date: Tue, 17 Dec 1996 14:57:20 -0500 From: eallen@BayNetworks.COM (Ed Allen) Message-Id: <199612171957.OAA08443@pobox.BayNetworks.com> To: bade@austin.ibm.com Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199612171602.KAA24014@r1100rs.austin.ibm.com> (bade@austin.ibm.com) Subject: Re: Question on RFC 2023 IP V6 over PPP Resent-Message-ID: <"rBjzg1.0.Ry.Wjljo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2269 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>>>> Steven A Bade writes: SAB> I've got a question on the text in RFC 2023 (IP Version 6 over PPP). SAB> On page 5 (where it talks about the protocol exchange) it states SAB> "If the two Interface-Tokens are different, but the received SAB> Interface-Token is zero, a Configure-Ack is sent with a non-zero SAB> Interface-Token value suggested for use by the remote peer...." SAB> I believe this to be in error, I think it should read Configure-Nak since SAB> the response is suggesting a value, not acknowledging the the request... Steven, This is for the case of a box which wants its peer to assign an Interface-Token for it. The idea here is that one round-trip time can be saved by the exchange: CR(0) --- <--- CA (xyz) Instead of: CR(0) --- <--- CN (xyz) CR(xyz) --- <--- CA (xyz) This has been in common use by IPCP for a similar purpose. Granted it's been the source of confusion with IPCP. But with IPv6CP the rules will be consistent from the start. Thanks, - Ed - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 15:04:04 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA04364; Tue, 17 Dec 1996 15:04:04 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 15:04:04 -0500 (EST) From: sullivan@gandalf.ca (Chris Sullivan) Message-Id: <9612172002.AA12381@hobbit.gandalf.ca> Subject: CCP with multiple compression types (again) To: ietf-ppp@MERIT.EDU (IETF PPP) Date: Tue, 17 Dec 1996 15:02:48 -0500 (EST) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"UaRxR3.0.l31.loljo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2270 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Pardon me for rehashing what might be old information, but since the > CCP spec is extremely vague on this issue, I have little choice but > to ask. > >There really isn't a very graceful way in the protocol to negotiate if >you support many compressors, but only one at a time. This is a hole. > >There are other ways it could have been designed to make this work >more smoothly. (Too late.) > > By way of example, if vendor #1 supports options A, B, and C and > vendor #2 supports options B, C, and D, the negotiation could > look something like this: > > Vendor #1 Vendor #2 > > Config-req (A, B, C) ---> > <---------- Config-rej (A) > Config-req (B, C) ------> > <---------- Config-nak (empty) * > Config-req (B) ---------> > <---------- Config-ack (B) > >I think in this case, if I was vendor 2, I would send config-nak (B) >at the point I've put in an asterisk. The above is from an exchange of last May between Ron Stoughton and John Shriver. Sorry if I am rehashing old rehash. I seem to recall some discussion of the "primary/secondary compression protocol" issue at CIUG in October but I can't find any minutes of it. Is it wrong in the slightly windy context of CCP to Config-rej the ones you don't want to do, even though you might be willing to if they were proposed all by themselves? Vendor #1 Vendor #2 Config-req (A, B, C, D, E, F) ---> <---------Config-rej (A, C, D, E, F) Config-req (B) ---> <---------Config-ack (B) Also, if Vendor #2 acks (A, B, C) is Vendor #2 free to use any of them (since they are after all separate independent Configuration Options)? How is the receiver expected to distinguish between them? Or is there some unwritten law which says Vendor #2 *must* only compress using A? If so, why A and not B or C? -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 15:51:56 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA05483; Tue, 17 Dec 1996 15:51:56 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 15:51:56 -0500 (EST) Date: Tue, 17 Dec 1996 13:50:41 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612172050.NAA19368@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question Resent-Message-ID: <"jet2Z.0.ML1.dVmjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2271 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > Well, yeah, any PPP implementation is free to pad the packet at the > physical level. A lot of HDLC chips used to insist on doing this. Is that still true? I've yet to see a single Configure-Request for self-describing padding in traces over ISDN. > In general, the specifications for X over PPP have added a length > field if X doesn't have one. The specific example I was very involved > with is DECnet Phase IV over PPP, where there is a length field. > > The exception appears to be Multilink. There is no length field > preceeding the individual fragments. You can avoid that problem even for network protocls without their own length without using self-describing padding by being smart in the choice of fragment lengths, and if that is not enough, adding leading zeros to the inner protocol field. > Now, this would only be an issue for ECP when running it under > Multilink. > > If running ECP on top of Multilink, that problem doesn't happen. > > So, you really only need to negotiate self-decribing padding for ECP > under Multilink. What happened to the decision to delete the self-describing padding extension? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 16:06:27 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA05841; Tue, 17 Dec 1996 16:06:27 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 16:06:27 -0500 (EST) Posted-Date: Tue, 17 Dec 1996 16:10:02 -0500 (EST) Date: Tue, 17 Dec 1996 16:05:16 -0500 From: eallen@BayNetworks.COM (Ed Allen) Message-Id: <199612172105.QAA12276@pobox.BayNetworks.com> To: ietf-ppp@MERIT.EDU, ietf_msml@BayNetworks.COM Subject: multi-system PPP Multilink email list Resent-Message-ID: <"ZrvR82.0.uQ1.Ejmjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2272 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The email list for multi-system PPP Multilink discussions has been created. To join, send email to ietf_msml-request@baynetworks.com You'll be manually added quickly. To contribute to the discussion, send email to ietf_msml@baynetworks.com (Employees of Bay can subscribe by emailing "majordom" with no subject line and "subscribe ietf_msml" only in the body.) The list is being archived, details regarding how to view the archive will follow on the ietf_msml list. Thanks, - Ed - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 16:17:41 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA06323; Tue, 17 Dec 1996 16:17:41 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 16:17:41 -0500 (EST) Sender: mrobidas@nabu.isg.mot.com Message-ID: <32B70DDE.2AEE@nabu.isg.mot.com> Date: Tue, 17 Dec 1996 16:17:18 -0500 From: Marc Robidas Organization: Motorola ISG X-Mailer: Mozilla 3.0Gold (X11; I; HP-UX A.09.05 9000/715) MIME-Version: 1.0 To: Ed Allen CC: ietf-ppp@MERIT.EDU, ietf_msml@BayNetworks.COM Subject: Re: multi-system PPP Multilink email list References: <199612172105.QAA12276@pobox.BayNetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-Message-ID: <"s5q63.0.RY1.htmjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2273 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU My e-mail bounced off the Bay Network's mail server: ietf_msml-request@baynetworks.com is an unknown user --Marc Ed Allen wrote: > > The email list for multi-system PPP Multilink discussions > has been created. > To join, send email to ietf_msml-request@baynetworks.com > You'll be manually added quickly. > To contribute to the discussion, send email to ietf_msml@baynetworks.com > > (Employees of Bay can subscribe by emailing "majordom" with no subject line > and "subscribe ietf_msml" only in the body.) > > The list is being archived, details regarding how to view > the archive will follow on the ietf_msml list. > > Thanks, > > - Ed - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 16:18:33 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA06412; Tue, 17 Dec 1996 16:18:33 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 16:18:33 -0500 (EST) From: Craig Fox Message-Id: <199612172116.NAA23841@greatdane.cisco.com> Subject: Re: Question on RFC 2023 IP V6 over PPP To: eallen@BayNetworks.COM (Ed Allen) Date: Tue, 17 Dec 96 13:16:47 PST Cc: bade@austin.ibm.com, ietf-ppp@MERIT.EDU In-Reply-To: <199612171957.OAA08443@pobox.BayNetworks.com>; from "Ed Allen" at Dec 17, 96 2:57 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"ByY8M2.0.tZ1.Zumjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2275 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > >>>>> Steven A Bade writes: > > SAB> I've got a question on the text in RFC 2023 (IP Version 6 over PPP). > SAB> On page 5 (where it talks about the protocol exchange) it states > > SAB> "If the two Interface-Tokens are different, but the received > SAB> Interface-Token is zero, a Configure-Ack is sent with a non-zero > SAB> Interface-Token value suggested for use by the remote peer...." > > SAB> I believe this to be in error, I think it should read Configure-Nak since > SAB> the response is suggesting a value, not acknowledging the the request... > > Steven, > This is for the case of a box which wants its peer to > assign an Interface-Token for it. > The idea here is that one round-trip time can be saved > by the exchange: > CR(0) --- > <--- CA (xyz) > > Instead of: > CR(0) --- > <--- CN (xyz) > CR(xyz) --- > <--- CA (xyz) > > This has been in common use by IPCP for a similar purpose. > Granted it's been the source of confusion with IPCP. Where has it been commonly used in IPCP? Please provide an example, a documentation reference and/or the name of the implementation. There has been a rule in PPP expressed in the earliest PPP RFCs that stated that a Config Ack packet must be identical to a Config Request packet with the obvious exception of the function code. This was expressed in the first PPP RFC (1171) and in every one since. All NCP RFCs have referenced the current PPP RFC for the basic negotiation rules. BTW, this will break many of the automated logic implementations that compare the Config Ack to the outgoing Config Request to validate the response. Craig > But with IPv6CP the rules will be consistent from the start. > > Thanks, > > - Ed > > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 16:18:14 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA06375; Tue, 17 Dec 1996 16:18:14 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 16:18:14 -0500 (EST) Date: Tue, 17 Dec 1996 13:17:54 -0800 (PST) From: Mike Thornburg Reply-To: Mike Thornburg To: Ed Allen cc: bade@austin.ibm.com, ietf-ppp@MERIT.EDU Subject: Re: Question on RFC 2023 IP V6 over PPP In-Reply-To: <199612171957.OAA08443@pobox.BayNetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cKnDB2.0.DZ1.Humjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2274 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Tue, 17 Dec 1996, Ed Allen wrote: > This is for the case of a box which wants its peer to > assign an Interface-Token for it. > The idea here is that one round-trip time can be saved > by the exchange: > CR(0) --- > <--- CA (xyz) > > Instead of: > CR(0) --- > <--- CN (xyz) > CR(xyz) --- > <--- CA (xyz) > > This has been in common use by IPCP for a similar purpose. > Granted it's been the source of confusion with IPCP. > But with IPv6CP the rules will be consistent from the start. > As I read RFC 1332 on IPCP, it specifies the second type of exchange, not the first. The first type of exchange also violates the usual convention about Config-Acks that the options "MUST NOT be reordered or modified in any way" (quote from RFC 1661, and note the word "modified"). This convention is explicitly stated about LCP, but the NCP standards usually include this LCP convention by reference. And, indeed, I note these words in RFC 2023: "IPV6CP uses the same packet exchange mechanism as the Link Control Protocol (LCP)." It then proceeds to specify use of the first exchange mechanism in the example, which explicitly violates the LCP packet exchange mechanism that it made a particular point of stating that it follows. I assume that RFC 2023 can establish its own, unusual, conventions if it wants to, but why be deliberately different from everything else just to save two packets that are only exchanged once at the start of a connection? Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 16:22:32 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA06706; Tue, 17 Dec 1996 16:22:32 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 16:22:32 -0500 (EST) Message-Id: <199612172122.QAA06678@merit.edu> Date: 17 Dec 1996 16:10 EST Sender: "Tim Jenkins" To: ietf-ppp@MERIT.EDU From: "Tim Jenkins" Subject: ACCM Usage in PPP Resent-Message-ID: <"xgr5S3.0.Te1.Kymjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2276 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Greetings, I'm confused about how the ACCMs in PPP are supposed to work. From RFC 1662 ... The Configuration Option is used to inform the peer which control characters MUST remain mapped when the peer sends them. I interpret this to mean that a device that performs async-to-sync PPP conversion must use the ACCM passed in a Configure-Ack for all packets that it sends in the same direction that the Configure-Ack is going. Is this correct? If so, Trumpet Winsock may have a bug, in that it appears to use the ACCM that it sent in a Configure-Request for packets it sends. At the same time, it never sends to its peer a Configure-Ack containing an ACCM. When we applied the ACCM based on the assumption above, any further packets received from the async end were in error, since the ACCM no longer matched what was being transmitted. My guess is that the peer is a synchronous device, so in general does not care, so does not use the ACCM. Should the asynchronous end not have sent a Configure-Nak containing an ACCM before it started using an ACCM that was not the default? And based on RFC 1662, the synchronous end should return the ACCM in its next Configure-Request. The result would be that the async end would send the ACCM in its Configure-Ack, allowing it to send packets with that ACCM. To enable this functionality, synchronous PPP implementations MUST always respond to the Async-Control-Character-Map Configuration Option with the LCP Configure-Ack. However, acceptance of the Configuration Option does not imply that the synchronous implementation will do any ACCM mapping. Instead, all such octet mapping will be performed by the asynchronous-to-synchronous converter. Is this correct? And is it done? What about Windows 95 dial-up adapter? If the operation I've observed is wrong, but common practise, would it be acceptable for a device that performs async-to-sync conversion to apply the single ACCM that is Acked to both directions of its link? My apologies if this has been asked before, or is too poorly presented to be understood, but any assistance in this is appreciated. Thanks in advance, Tim Jenkins tjj@bnr.ca - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 16:52:00 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA08096; Tue, 17 Dec 1996 16:52:00 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 16:52:00 -0500 (EST) Message-ID: From: Al Longyear To: "'Jonathan.Goodchild@rdl.co.uk'" , "'ietf-ppp@merit.edu'" Subject: Re: infinite loop (new condition) Date: Tue, 17 Dec 1996 13:51:43 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"nlTXG2.0.B-1.wNnjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2277 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Ok. Let's suppose that we do change the ID value with every transmission message, whether it is the result of a new configuration or a retransmission for a moment. RFC 1661, section 5.1 says that the identifier must be changed whenever the contents of the options field changes. In this case, since the magic number changed, the identifier must be changed. In addition, it says that for retransmissions, the identifier may remain unchanged. To put that in other words, the sentence could have read "For retransmissions, the identifier MAY be changed." Let's suppose that the magic number is not a valid option to the peer. It has rejected it or it was never sent in the original configure request frame. Let's further suppose that one side generated a RTO event. The response would be to retransmit the configure request or the terminate request frame again. Since the same parameters would be used, and since the magic number is not valid to the peer, the only thing that will be changed from one transmission packet to its retransmission is the identifier. Do I understand you correctly? Then, let's open it up a little bit. Let's suppose that the magic number _WAS_ acceptable and was in the configure request packet. Is it required, or even recommended, that it be regenerated for the retransmission packet? (I am not trying to debate the issue. I am only seeking to understand the full ramifications of your comments.) Jonathan.Goodchild@rdl.co.uk writes: >In my view, leaving the ID the same for a retransmission is a BAD IDEA. >Consider the case if the RTO is too short, say due to a temporary >processing hiatus in the peer: > > <--------- CfgReq > RCR+: tld,scr,sca/8 > CfgReq (1) ---------> > CfgAck ---------> > TO+: scr/8 > CfgReq (1) ---------> > <--------- CfgAck (1) > RCA: irc,tlu/9 > <--------- CfgAck (1) > RCA: tld,scr/6x > CfgReq (1) ---------> (etc. possibly leading to infinite loop) This may explain some other strange events that I have seen when I do get valid ACKs for the configure requests but it never seems to synchronize. Yet, when I change the time value associated with restart timer from three seconds to four, it works. >If the ID is changed on each retransmission, then > > CfgReq (1) ---------> > TO+: scr/8 > CfgReq (2) ---------> > <--------- CfgAck (1) > (ignored) > <--------- CfgAck (2) > RCA: irc,tlu/9 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 17:08:30 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA08498; Tue, 17 Dec 1996 17:08:30 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 17:08:30 -0500 (EST) From: Archie Cobbs Message-Id: <199612172207.OAA15737@bubba.whistle.com> Subject: Re: Question on RFC 2023 IP V6 over PPP In-Reply-To: <199612172116.NAA23841@greatdane.cisco.com> from Craig Fox at "Dec 17, 96 01:16:47 pm" To: fox@cisco.com (Craig Fox) Date: Tue, 17 Dec 1996 14:07:47 -0800 (PST) Cc: eallen@BayNetworks.COM, bade@austin.ibm.com, ietf-ppp@MERIT.EDU X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"8WJab3.0.942.Ldnjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2278 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > CR(0) --- > > <--- CA (xyz) > > > > Instead of: > > CR(0) --- > > <--- CN (xyz) > > CR(xyz) --- > > <--- CA (xyz) > > > been a rule in PPP expressed in the earliest PPP RFCs that stated that a > Config Ack packet must be identical to a Config Request packet with the > obvious exception of the function code. This was expressed in the first > PPP RFC (1171) and in every one since. All NCP RFCs have referenced the > current PPP RFC for the basic negotiation rules. > > BTW, this will break many of the automated logic implementations that > compare the Config Ack to the outgoing Config Request to validate the > response. I agree... from a programmer's point of view (among others) doing this is a bad idea. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 17:22:57 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA08923; Tue, 17 Dec 1996 17:22:57 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 17:22:57 -0500 (EST) From: "Brad Wilson" To: Subject: Re: Question on RFC 2023 IP V6 over PPP Date: Tue, 17 Dec 1996 17:22:46 -0500 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <19961217222221881.AAA88@ragnar> Resent-Message-ID: <"iuTB13.0.6B2.yqnjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2279 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > The idea here is that one round-trip time can be saved > by the exchange: > CR(0) --- > <--- CA (xyz) > > Instead of: > CR(0) --- > <--- CN (xyz) > CR(xyz) --- > <--- CA (xyz) > > This has been in common use by IPCP for a similar purpose. Um, since when? -- Brad Wilson Custom software development & solutions crucial@pobox.com Internet and intranet consulting services The Brads' Consulting Windows NT/Windows 95 software development http://www.thebrads.com Web site planning, development and maintenance Content (C) 1996 Brad Wilson; no reproduction without authorization - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 17:27:25 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA09000; Tue, 17 Dec 1996 17:27:25 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 17:27:25 -0500 (EST) Date: Tue, 17 Dec 1996 17:25:08 -0500 (EST) From: John Shriver Message-Id: <199612172225.RAA00752@shiva-dev.shiva.com> To: sullivan@gandalf.ca CC: ietf-ppp@MERIT.EDU In-reply-to: <9612172002.AA12381@hobbit.gandalf.ca> (sullivan@gandalf.ca) Subject: Re: CCP with multiple compression types (again) Resent-Message-ID: <"wtPKS3.0.JC2.9vnjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2280 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU If you config-ACK (A, B, C), you are saying that you will accept compression A on the primary compression protocol ID (00FD), and the other compression protocols on their secondary compression protocol ID (for instance 4021 for Stac LZS). That said, I've yet to find anyone who has implemented multiple simultaneous compression protocols. I suspect that this feature of CCP will be deleted (for lack of multiple interoperable implementations) when it progresses along the standards track from Proposed Standard to Draft Standard. It is perfectly legal to Config-Reject the ones you don't want to speak, to leave only one as the primary compression protocol. You do have to be careful about doing this. If the one compressor you are not Config-Rejecting does not have acceptable options, you may wind up unable to negotiate it with the correct options, and have no compression at all. Unfortunately, if you don't implement multiple compressors, you can't send a Config-NAK with all the compressors, but with the options on one changed. That's because you are obligated to accept any set of options you send as a Config-NAK if you receive them as a Config-Request. So the best you can do is Config-NAK with just the one you would like to see different options on. (It would also be much easier if Stac LZS didn't have the typo that changed the intended bitfield of check types into an enumeration. Then you could know that the peer supported the option that you wanted. Instead you have to go through Config-NAK cycles to figure out what you wanted.) Given that we are finding near-zero interest in implementing simultaneous compression protocols (where's Occam's Razor when we need it?), it's too bad that CCP has this difficult negotiation model designed for it. If it was a single option like LCP authentication type, people could use the established stragies used for that in LCP. The current model is rather intractible in the case where you do not implement multiple simultaneous compressors. But, we are rather stuck with it. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 17:31:46 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA09316; Tue, 17 Dec 1996 17:31:46 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 17:31:46 -0500 (EST) Message-Id: <3.0.32.19961217163139.006ad008@mail> X-Sender: kfrnswrt@mail X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 17 Dec 1996 16:31:47 -0600 To: "Tim Jenkins" From: Kyle Farnsworth Subject: Re: ACCM Usage in PPP Cc: ietf-ppp@MERIT.EDU Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"YQ9M32.0.FH2.Eznjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2281 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 04:10 PM 12/17/96 EST, Tim Jenkins wrote: >Greetings, > >I'm confused about how the ACCMs in PPP are supposed to work. From >RFC 1662 > ... The > Configuration Option is used to inform the peer which control > characters MUST remain mapped when the peer sends them. > >I interpret this to mean that a device that performs async-to-sync >PPP conversion must use the ACCM passed in a Configure-Ack for all >packets that it sends in the same direction that the Configure-Ack >is going. Is this correct? > Yes. >If so, Trumpet Winsock may have a bug, in that it appears to use the >ACCM that it sent in a Configure-Request for packets it sends. At the >same time, it never sends to its peer a Configure-Ack containing an >ACCM. When we applied the ACCM based on the assumption above, any further >packets received from the async end were in error, since the ACCM no >longer matched what was being transmitted. > That is one of multiple bugs in Trumpet. What do want for free? No PPP implementation should ever send the ACCM in the Conf-Ack if it never received it in a Conf-Req. What it should do is send a Conf-Nak with the ACCM it wants to receive. >My guess is that the peer is a synchronous device, so in general does >not care, so does not use the ACCM. Should the asynchronous end not >have sent a Configure-Nak containing an ACCM before it started using >an ACCM that was not the default? And based on RFC 1662, the synchronous >end should return the ACCM in its next Configure-Request. The result >would be that the async end would send the ACCM in its Configure-Ack, >allowing it to send packets with that ACCM. > If the async PPP does not send a Conf-Nak with ACCM it wants it will be stuck with the default. There is a company out there (I won't name them but they like to use a plumbing fixture in their product names) that sells a ton of ISDN routers and it does not send the ACCM in it's conf-req. I have had to "spoof" the ACCM option in my terminal adapters because of this. > To enable this functionality, synchronous PPP implementations MUST > always respond to the Async-Control-Character-Map Configuration > Option with the LCP Configure-Ack. However, acceptance of the > Configuration Option does not imply that the synchronous > implementation will do any ACCM mapping. Instead, all such octet > mapping will be performed by the asynchronous-to-synchronous > converter. > >Is this correct? And is it done? What about Windows 95 dial-up adapter? > I think a sync device should always send an ACCM=00000000 in case there is an async device somewhere in the path. >If the operation I've observed is wrong, but common practise, would >it be acceptable for a device that performs async-to-sync conversion >to apply the single ACCM that is Acked to both directions of its link? > No. It is bi-directional. The ACCM that should be used for Tx'ing should be the ACCM sent in a Conf-Ack. The Rx'ing ACCM should use the ACCM received in a Conf-Ack. >My apologies if this has been asked before, or is too poorly presented >to be understood, but any assistance in this is appreciated. > >Thanks in advance, > >Tim Jenkins >tjj@bnr.ca > > > > -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 17:43:24 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA09871; Tue, 17 Dec 1996 17:43:24 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 17:43:24 -0500 (EST) Date: Tue, 17 Dec 1996 17:41:10 -0500 (EST) From: John Shriver Message-Id: <199612172241.RAA01999@shiva-dev.shiva.com> To: jas@shiva.com CC: sullivan@gandalf.ca, ietf-ppp@MERIT.EDU In-reply-to: <199612172225.RAA00752@shiva-dev.shiva.com> (message from John Shriver on Tue, 17 Dec 1996 17:25:08 -0500 (EST)) Subject: Re: CCP with multiple compression types (again) Resent-Message-ID: <"_NfMI.0.wP2.88ojo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2283 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Come think of it, how can secondary compression protocols work if they only have one protocol ID? There's 00FD for Multilink bundle, and 00FB for Multilink link. Yet (in Stac LZS), there is only ONE protocol ID (4021) for Stac as a secondary. What if Stac LZS is negotiated as a secondary at the link and bundle level? (Perfectly legal, if silly.) Well, I suppose you can say you gotta sort it out by context, which is possible. More evidence of a lack of implementations of secondary compressors -- holes in the RFC... - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 17:40:11 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA09672; Tue, 17 Dec 1996 17:40:11 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 17:40:11 -0500 (EST) Date: Tue, 17 Dec 1996 17:37:10 -0500 (EST) From: John Shriver Message-Id: <199612172237.RAA01661@shiva-dev.shiva.com> To: vjs@mica.denver.sgi.com CC: ietf-ppp@MERIT.EDU In-reply-to: <199612172050.NAA19368@mica.denver.sgi.com> (vjs@mica.denver.sgi.com) Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question Resent-Message-ID: <"wpsbi2.0.nM2.65ojo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2282 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Well, yes, I don't know of any ISDN PPP impelementation that adds physical layer padding. However, you are not required to use self-describing padding when you send a PPP packet with padding. (I've never implemented it.) That's an option. You may pad with garbage instead if self-describing padding is not negotiated. When we were originally designing PPP, plenty of vendors had hardware that could only send packets with lengths that were multiples of 2 or 4 bytes. The SBE COM/2, which both Cisco and Proteon used, had a 2 byte length multiple, because they were kludging a byte-oriented Rockwell chip to a short-word oriented Motorola 68450 DMA controller, or something suitably ugly like that. The then-current ACC products could only send multiples of 4 bytes. Sure, those damn fool chip and hardware designers don't make mistakes like this anymore. (Well, the chip designers can, but nobody would design in the chip!) This is the same fundamental reason we have FF03 at the front the the packet, some Motorola serial controller with integral X.25 absolutely required it. We didn't consider the padding to be a big issue. None of the protocols we were familiar with at the time lacked a length field. Besides, padding (to 64 bytes) was working just fine on Ethernet. PPP had to work on the hardware available at the time it was standardized. If it hadn't, it never would have happened (implementation), the key vendors would only participate in implementation if the standard didn't require any hardware changes for them. Thus, we now have baggage to deal with due to this now obsolete and un-supported hardware. You can't just ban padding on ISDN and other new PPP media. That ISDN may really be from a Cisco AGS-1 running 8.2 on a COM-2 through a sync/ISDN TA! - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 17:45:46 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA10036; Tue, 17 Dec 1996 17:45:46 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 17:45:46 -0500 (EST) Date: Tue, 17 Dec 1996 15:45:29 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612172245.PAA19929@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: IP Address option negotiation Resent-Message-ID: <"oBvpV.0.PS2.MAojo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2284 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From the minutes: ] IP Address option negotiation ] ] - None of the original protagonists were present, so the group ] discussed the issue in their absence. Anything "decided" obviously ] has to be taken to the mailing list to reach full consensus. ] ] - If unit sends: ] ] Req(0) -> ] ] and peer sends back: ] ] <- Nak(addr) ;That's OK. ] <- Nak(0) ;Prohibited! Never do! ] <- Rej() ;take default value, "Not Configured". ] <- Ack(0) ;Prohibited! Never do! ] ] Question is: What is the default value of this option? Unnumbered? ] Manually configured? Not configured? Decided "Not configured" ] should be the default. This is no change from before. ] ] - Discussion about adding a 2-byte "Numbered/Unnumbered" option. ] ] - We found that some vendors send cr-0, expecting the peer to supply ] an IP address. They hoped that the peer would send ca-0, meaning, ] "I don't have an address to give you, so if you really do have an ] address but were just trying to be polite and let me pick it, and ] since I don't have one to give you, now send me yours." ] ] - Consensus was that the originator shouldn't have attempted to be so ] polite. Just send its address. I claim the consensus is that: - the extremely polite tactic mentioned above is only one of several advocated meanings for Ack(0). - there is no consensus for what Nak(0)-after-Req(0) or Ack(0) can or should mean, or that either one should be legal. - there is no widespread use of Ack(0) or Nak(0). - there is no compelling purpose for Ack(0) or Nak(0)-after-Req(0) that cannot be done instead with other means, particularly Rej(). There is another case of Nak(0) that must be addressed. That is when the peer did not send Req() of anything. I claim Nak(0) historically meant "since you didn't send me a Req() for anything and since I don't know your IP address, please send me Req(addr)." Because LCP does not ride a reliable transport, there is no way for both peers to distinquish "Nak(0)-out-of-the-blue" from "Nak(0)-after-Req(0)" or even "Nak(0)-after-Req(addr)." The Req(x) might have been lost. As others have said, all systems that would respond useful to Nak(0)-out-of-the-blue will have already sent Req(x) Therefore, Nak(0)-out-of-the-blue is not needed. Therefore, why don't we just outlaw that which is not useful, redundant, and/or controversial, and do approximately as proposed in the minutes: Req(0) means "I don't know my address--please tell me" Req(addr) means "I want to use addr on my end of the link" Nak(addr) means "I want you to use addr on your end of the link" Nak(0) "SHOULD NOT" be sent Ack(0) "SHOULD NOT" be sent "Unnumbered mode" can be done by either: 1. the common, de facto standard practice of negotiating IP address(es) that just happen to be the host address(es) of of the peer(s). 2. Rej() Notice that I said nothing about the context, the preceding options/packets, if any. Because LCP is unreliable, it is hard to write specifications that work. In the case of the ADDR option, I claim the context can and should be irrelevant. I claim this will require no immediate change for any implementation, and that it is as good as we are going to get. vjs - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 18:03:51 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA11191; Tue, 17 Dec 1996 18:03:51 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 18:03:51 -0500 (EST) Message-Id: <01BBEC2B.64AF9CC0@ws107.flowpoint.com> From: Philippe Roger To: "'Kyle Farnsworth'" Cc: "ietf-ppp@MERIT.EDU" Subject: RE: ACCM Usage in PPP Date: Tue, 17 Dec 1996 15:02:58 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"FAwYG.0.Yk2.HRojo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2285 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle, Our products used to do that but it was deemed inappropriate at one of the PacBell-sponsored PPP interoperability workshops (PPP over ISDN) over a year ago. Since then, we no longer send the ACCM option in a Config-Req and reject it if we receive it in a Config-Req. The rationale presented was that a synchronous device may not even understand the concept of ACCM and might as well reject the option: don't send it and you might save a round of negotiation. If an asynchronous device is in the path, it might want to add the ACCM option when sending its own Config-Req to its asynchronous peer and implement the mapping on its own, without having the synchronous device ever being aware of this going on. Philippe Roger roger@flowpoint.com ---------- From: Kyle Farnsworth[SMTP:kfarnsworth@adtran.com] Sent: Tuesday, December 17, 1996 2:31 PM To: Tim Jenkins Cc: ietf-ppp@MERIT.EDU Subject: Re: ACCM Usage in PPP I think a sync device should always send an ACCM=00000000 in case there is an async device somewhere in the path. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 18:42:50 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA12237; Tue, 17 Dec 1996 18:42:50 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 18:42:50 -0500 (EST) Date: Tue, 17 Dec 1996 16:42:35 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612172342.QAA20081@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question Resent-Message-ID: <"cN6r21.0.u-2.r_ojo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2286 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: John Shriver > Well, yes, I don't know of any ISDN PPP impelementation that adds > physical layer padding. However, you are not required to use > self-describing padding when you send a PPP packet with padding. > (I've never implemented it.) That's an option. You may pad with > garbage instead if self-describing padding is not negotiated. (This year I ripped support for self-describing padding out of my code, based on the reports from the meeting where it was decided that self-describing padding was dead, and its complete lack of use.) > ... > We didn't consider the padding to be a big issue. None of the > protocols we were familiar with at the time lacked a length field. > Besides, padding (to 64 bytes) was working just fine on Ethernet. > ... > Thus, we now have baggage to deal with due to this now obsolete and > un-supported hardware. > > You can't just ban padding on ISDN and other new PPP media. That ISDN > may really be from a Cisco AGS-1 running 8.2 on a COM-2 through a > sync/ISDN TA! The nice thing about obsolete and un-supported hardware is that it usually runs obsolete and un-supported software. Why can't you ban (self-describing) padding on ISDN, at least in this latest case (encryption beneath multilink)? Does the AGS-1 support more than IP, which does not care about padding? Does an AGS-1 support self-describing padding, multilink, or encryption? How many implementations request self-describing padding? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 18:48:37 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA12343; Tue, 17 Dec 1996 18:48:37 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 18:48:37 -0500 (EST) Message-Id: <3.0.32.19961217174824.006b9028@mail> X-Sender: kfrnswrt@mail X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Tue, 17 Dec 1996 17:48:25 -0600 To: Philippe Roger From: Kyle Farnsworth Subject: RE: ACCM Usage in PPP Cc: "ietf-ppp@MERIT.EDU" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"LxXPm.0.W03.H5pjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2287 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Roger, The most common type of application I know of is PPP running on PC or MAC connected to a ISDN TA dialing into a sync router. It sounds like your saying that an async-to-sync TA should never allow the ACCM option to go to the sync router. And that it should be an option that is negotiated between the PC/MAC and the TA. However, that's not true for some TA's so why not just agree to the ACCM option and Ack it? And why not just send it in a Conf-Request? It seems like an easy thing to do and will eliminate some Tech Support calls where the customer wants to know why his or her binary file transfer is taking twice as long as it should. Kyle At 03:02 PM 12/17/96 -0800, Philippe Roger wrote: >Kyle, > >Our products used to do that but it was deemed inappropriate at one of the >PacBell-sponsored PPP interoperability workshops (PPP over ISDN) over a >year ago. Since then, we no longer send the ACCM option in a Config-Req >and reject it if we receive it in a Config-Req. > >The rationale presented was that a synchronous device may not even >understand the concept of ACCM and might as well reject the option: don't >send it and you might save a round of negotiation. > >If an asynchronous device is in the path, it might want to add the ACCM option >when sending its own Config-Req to its asynchronous peer and implement >the mapping on its own, without having the synchronous device ever being >aware of this going on. > >Philippe Roger >roger@flowpoint.com > > >---------- >From: Kyle Farnsworth[SMTP:kfarnsworth@adtran.com] >Sent: Tuesday, December 17, 1996 2:31 PM >To: Tim Jenkins >Cc: ietf-ppp@MERIT.EDU >Subject: Re: ACCM Usage in PPP > > >I think a sync device should always send an ACCM=00000000 in case there is >an async device somewhere in the path. > > > > > > > > -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 19:42:00 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA13364; Tue, 17 Dec 1996 19:42:00 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 19:42:00 -0500 (EST) To: ietf-ppp@MERIT.EDU Subject: Re: IP Address option negotiation In-Reply-To: Your message of "Tue, 17 Dec 1996 15:45:29 MST." <199612172245.PAA19929@mica.denver.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 17 Dec 1996 16:41:51 -0800 Message-Id: <2282.850869711@dumbcat.codewright.com> From: Marco S Hyman Resent-Message-ID: <"b3POV3.0.UG3.Ktpjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2288 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > Therefore, why don't we just outlaw that which is not useful, redundant, > and/or controversial, and do approximately as proposed in the minutes: > > Req(0) means "I don't know my address--please tell me" > Req(addr) means "I want to use addr on my end of the link" > Nak(addr) means "I want you to use addr on your end of the link" > Nak(0) "SHOULD NOT" be sent > Ack(0) "SHOULD NOT" be sent > > "Unnumbered mode" can be done by either: > 1. the common, de facto standard practice of negotiating IP address(es) > that just happen to be the host address(es) of of the peer(s). > 2. Rej() There was some rumbling in San Jose from people who said they need explicit negotiation of numbered vs unnumbered mode. Karl (or was it Craig?) asked "why do you really need to know?". No answer. Does anybody have a reason? > I claim this will require no immediate change for any implementation, > and that it is as good as we are going to get. Concur. It's not perfect, but acceptable. // marc - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 19:50:50 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA13453; Tue, 17 Dec 1996 19:50:50 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 19:50:50 -0500 (EST) Date: Wed, 18 Dec 1996 00:50:08 +0000 (GMT) From: Malcolm Campbell To: ietf-ppp@MERIT.EDU Subject: Re: Question on RFC 2023 IP V6 over PPP In-Reply-To: <199612172116.NAA23841@greatdane.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"k2UsE3.0.rH3.b_pjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2289 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Tue, 17 Dec 1996, Craig Fox wrote: > BTW, this will break many of the automated logic implementations that > compare the Config Ack to the outgoing Config Request to validate the > response. Indeed - I feel its very important that we don't change this basic mechanism of PPP. A Configure-Ack MUST contain exactly the same options as the Request. To do otherwise not only breaks the logic, but removes the control from the requesting system. A value suggested in a Nak may not be acceptable, and the requestor has to be free not to request it. --- Malcolm ------------------------- malcolmc@europe.shiva.com ------------------------- Malcolm Campbell, Project Consultant | Shiva Europe Ltd., Tel: +44 131 561 4234 | Shiva Park, Stanwell Street Fax: +44 131 561 4001 | Edinburgh, EH6 5NG, Scotland - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 20:16:05 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA14098; Tue, 17 Dec 1996 20:16:05 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 20:16:05 -0500 (EST) Date: Tue, 17 Dec 1996 18:15:50 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612180115.SAA20326@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: ACCM Usage in PPP Resent-Message-ID: <"AXT1b2.0.zR3.GNqjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2290 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Kyle Farnsworth > ... > If the async PPP does not send a Conf-Nak with ACCM it wants it will be > stuck with the default. There is a company out there (I won't name them > but they like to use a plumbing fixture in their product names) that sells > a ton of ISDN routers and it does not send the ACCM in it's conf-req. I > have had to "spoof" the ACCM option in my terminal adapters because of this. Isn't that company, whichever it is, is doing what is both common and correct according to the PPP RFC's? > ... > I think a sync device should always send an ACCM=00000000 in case there is > an async device somewhere in the path. I strongly disagree (although my code used to send ACCM=0 over ISDN and if manually configured, will send ACCM!=0 over ISDN). - The ACCM is not the only PPP option a sync-async converter must be prepared to spoof. Consider authentication and multilink. - The PPP RFC's discourage sending Configure-Requests containing default values (I think the words are in 1661). Besides ACCM, the classic example is MRU(1500). Not sending redundant information is good, defensive programming. The peer is less likely to do something "distinctive" with what you don't send. - The obvious main design principle for a sync-async converter is the same as for other kinds of tricky boxes, from FDDI repeater to Ethernet-802.5 bridges. The ends must not be able to tell (not to mention care) that the trickery is happening. The onus is on the tricky box to make its tricks work, not the innocent, standards compliant bystanders. - it is many years too late to impose such a requirement on sync PPP implementations. It would not be reasonable to expect existing installation to magically change, so such a requirement could not possilby help the implementors of sync-async converters. Any usable sync-async convertor must be prepared to spoof ACCM options, since there will always be old sync PPP installations that will not be sending ACCM options. > >If the operation I've observed is wrong, but common practise, would > >it be acceptable for a device that performs async-to-sync conversion > >to apply the single ACCM that is Acked to both directions of its link? > > > No. It is bi-directional. The ACCM that should be used for Tx'ing should > be the ACCM sent in a Conf-Ack. The Rx'ing ACCM should use the ACCM > received in a Conf-Ack. > ... Yes, except that common sense and section 7.1 of RFC 1662 say that the TX ACCM actually used should be the union of the two negoitated ACCM's. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 20:34:00 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA14495; Tue, 17 Dec 1996 20:34:00 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 20:34:00 -0500 (EST) From: Archie Cobbs Message-Id: <199612180133.RAA16373@bubba.whistle.com> Subject: Re: ACCM Usage in PPP In-Reply-To: <3.0.32.19961217174824.006b9028@mail> from Kyle Farnsworth at "Dec 17, 96 05:48:25 pm" To: kfarnsworth@adtran.com (Kyle Farnsworth) Date: Tue, 17 Dec 1996 17:33:14 -0800 (PST) Cc: roger@flowpoint.com, ietf-ppp@MERIT.EDU X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"_rxLa3.0.AY3.3eqjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2291 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > The most common type of application I know of is PPP running on PC or MAC > connected to a ISDN TA dialing into a sync router. It sounds like your > saying that an async-to-sync TA should never allow the ACCM option to go to > the sync router. And that it should be an option that is negotiated > between the PC/MAC and the TA. However, that's not true for some TA's so > why not just agree to the ACCM option and Ack it? And why not just send it > in a Conf-Request? It seems like an easy thing to do and will eliminate > some Tech Support calls where the customer wants to know why his or her > binary file transfer is taking twice as long as it should. Sorry, I couldn't help jumping in as a concerned listener... :-) IMHO, synchronous links have no sense dealing at all with ACCM. What does the "A" in ACCM stand for after all? In some sense, the synchronous PPP came before asynchronous PPP, because PPP is a frame based, HDLC-like protocol. You wouldn't expect the ACCM option on a synchronous link any more than you would expect to send or receive bytes escaped with 0x7e (ie., you wouldn't). If you're going to build an async-to-sync converter, part of your job is spoofing the ACCM option. That's just what you get to do because you're converting from one to the other. It's actually part of the value-add of the product. This is my (over-simplistic?) view. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 17 21:19:23 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA15035; Tue, 17 Dec 1996 21:19:23 -0500 (EST) Resent-Date: Tue, 17 Dec 1996 21:19:23 -0500 (EST) Posted-Date: Tue, 17 Dec 1996 21:22:26 -0500 (EST) Date: Tue, 17 Dec 1996 21:17:41 -0500 From: eallen@BayNetworks.COM (Ed Allen) Message-Id: <199612180217.VAA24644@pobox.BayNetworks.com> To: mthorn@frigate.com Cc: bade@austin.ibm.com, ietf-ppp@MERIT.EDU In-Reply-To: (message from Mike Thornburg on Tue, 17 Dec 1996 13:17:54 -0800 (PST)) Subject: Re: Question on RFC 2023 IP V6 over PPP Resent-Message-ID: <"4eWBd.0.bg3.cIrjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2292 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>>>> Mike Thornburg writes: MT> I assume that RFC 2023 can establish its own, unusual, conventions if it MT> wants to, but why be deliberately different from everything else just to MT> save two packets that are only exchanged once at the start of a MT> connection? OK. I see by this and later messages that there is a strong consensus that the saving of a round-trip time has no real merit. (I admit to the error, but with the semi-excuse that quite a few members of the WG itself have been confused by "folklore" associated with IPCP Config-ACK address assignment, a similar process. Why just last week at the IETF I heard this very idea of saving the round-trip proposed for IPCP by a presenter at the front of the room. Ultimately it was disallowed, as the minutes show.) Anyway, I'll work with my co-author to get revised language into a new draft real soon. Thanks to Steve BAde and the others who contributed to the discussion. - Ed - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 01:44:21 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id BAA17011; Wed, 18 Dec 1996 01:44:21 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 01:44:21 -0500 (EST) From: Craig Fox Message-Id: <199612180643.WAA18270@greatdane.cisco.com> Subject: Re: IP Address option negotiation To: marc@dumbcat.codewright.com (Marco S Hyman) Date: Tue, 17 Dec 96 22:43:40 PST Cc: ietf-ppp@MERIT.EDU In-Reply-To: <2282.850869711@dumbcat.codewright.com>; from "Marco S Hyman" at Dec 17, 96 4:41 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"nLMRo1.0.U94.-Avjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2293 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Vernon Schryver writes: > > > Therefore, why don't we just outlaw that which is not useful, redundant, > > and/or controversial, and do approximately as proposed in the minutes: > > > > Req(0) means "I don't know my address--please tell me" > > Req(addr) means "I want to use addr on my end of the link" > > Nak(addr) means "I want you to use addr on your end of the link" > > Nak(0) "SHOULD NOT" be sent > > Ack(0) "SHOULD NOT" be sent > > > > "Unnumbered mode" can be done by either: > > 1. the common, de facto standard practice of negotiating IP address(es) > > that just happen to be the host address(es) of of the peer(s). > > 2. Rej() 3. not sending an IP Address option With the exception of adding 3, I agree with Vernon's suggestion. > > There was some rumbling in San Jose from people who said they need > explicit negotiation of numbered vs unnumbered mode. Karl (or was > it Craig?) asked "why do you really need to know?". No answer. Does > anybody have a reason? > It was Craig. I am always willing to take credit for not knowing something. :-) Seriously... One last time, is there any reason that you need to know how the peer is configured (numbered vs unnumbered)? Or need to set it so? > > I claim this will require no immediate change for any implementation, > > and that it is as good as we are going to get. > > Concur. It's not perfect, but acceptable. > Could it be consensus forming? Craig > // marc > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 02:16:30 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA17384; Wed, 18 Dec 1996 02:16:30 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 02:16:30 -0500 (EST) From: Craig Fox Message-Id: <199612180715.XAA19192@greatdane.cisco.com> Subject: Re: ACCM Usage in PPP To: archie@whistle.com (Archie Cobbs) Date: Tue, 17 Dec 96 23:15:27 PST Cc: kfarnsworth@adtran.com, roger@flowpoint.com, ietf-ppp@MERIT.EDU In-Reply-To: <199612180133.RAA16373@bubba.whistle.com>; from "Archie Cobbs" at Dec 17, 96 5:33 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"Elmwa2.0.HF4.8fvjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2294 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > > The most common type of application I know of is PPP running on PC or MAC > > connected to a ISDN TA dialing into a sync router. It sounds like your > > saying that an async-to-sync TA should never allow the ACCM option to go to > > the sync router. And that it should be an option that is negotiated > > between the PC/MAC and the TA. However, that's not true for some TA's so > > why not just agree to the ACCM option and Ack it? And why not just send it > > in a Conf-Request? It seems like an easy thing to do and will eliminate > > some Tech Support calls where the customer wants to know why his or her > > binary file transfer is taking twice as long as it should. > > Sorry, I couldn't help jumping in as a concerned listener... :-) > > > > IMHO, synchronous links have no sense dealing at all with ACCM. > What does the "A" in ACCM stand for after all? In some sense, the > synchronous PPP came before asynchronous PPP, because PPP is a frame > based, HDLC-like protocol. > The SLIPpers in the early PPP meetings would strongly disagree with this statement. Ten points for those who remember the other group's nickname. :-) > You wouldn't expect the ACCM option on a synchronous link any more > than you would expect to send or receive bytes escaped with 0x7e > (ie., you wouldn't). > I would expect this since I have read the PPP RFCs (1172, 1331 and 1662) in which the proper rules are spelled out. A synchronous PPP implementation MUST always ACK a peer's ACCM option. I believe that the PPP RFCs have also recommended that a sync PPP not send the ACCM option in its Config Requests but I do not remember if it was ever written as a MUST. > If you're going to build an async-to-sync converter, part of your job > is spoofing the ACCM option. That's just what you get to do because > you're converting from one to the other. It's actually part of the > value-add of the product. This is my (over-simplistic?) view. > In all honesty, I don't think the PPP Neanderthals considered some of the spoofing techniques now employed. I think the assumption was that the async/sync converter would monitor but not intrude on the negotiations. However, there are lots of implementations that have tried to follow the rules. Unless there is a pressing need for a change to these rules, I suggest we leave them alone. Craig > > > -Archie > > ___________________________________________________________________________ > Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 05:52:35 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id FAA18629; Wed, 18 Dec 1996 05:52:35 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 05:52:35 -0500 (EST) Mime-Version: 1.0 Date: Wed, 18 Dec 1996 10:38:23 +0000 Message-ID: <2b7ccb10@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: BAP protocol number change To: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"cmMVE1.0.RY4.Cpyjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2295 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Extract from working group minutes: ]BACP - Craig Richards (absent), Kevin Smith (absent) - ]draft-ietf-pppext-bacp-05.txt ] ]Change the number for BAP so that it doesn't compress. Recommend to create ]a new version of this draft. Karl will request new numbers from IANA. ]Ascend is the only vendor in the room shipping BACP. I am correct in interpreting that as meaning the numbers for both BAP and BACP will be changed ? (I hope it's not going to be BAP only.) Also, any idea when this is likely to happen ? Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 06:14:17 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id GAA19034; Wed, 18 Dec 1996 06:14:17 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 06:14:17 -0500 (EST) Date: Wed, 18 Dec 1996 11:13:02 +0000 (GMT) From: Malcolm Campbell To: Craig Fox cc: ietf-ppp@MERIT.EDU Subject: Re: IP Address option negotiation In-Reply-To: <199612180643.WAA18270@greatdane.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"sSif2.0.5f4.58zjo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2296 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Tue, 17 Dec 1996, Craig Fox wrote: > > Seriously... One last time, is there any reason that you need to know how > the peer is configured (numbered vs unnumbered)? Or need to set it so? My feeling is - whether the link is numbered or unnumbered is irrelevant to PPP. IPCP Address negotiation is only one way of getting an IP address, you may be running in any number of modes, e.g.: 1. numbered, using IP Address to exchange addresses 2. numbered, using DHCP or other higher layer protocol to get an address 3. unnumbered, using IP Address to exchange an arbitrary 'router id' token which may or may not be an IP address 4. unnumbered, using some higher layer protocol to get a 'router id' for the other end of the link Unless anyone has a compelling reason why we explicitly need to use IP Address to spell out the difference between cases 2. and 4., neither of which wish to negotiate an IP address in IPCP, that we should just leave the lack of negotiated IP Address as meaning "No address configured via IPCP" --- Malcolm ------------------------- malcolmc@europe.shiva.com ------------------------- Malcolm Campbell, Project Consultant | Shiva Europe Ltd., Tel: +44 131 561 4234 | Shiva Park, Stanwell Street Fax: +44 131 561 4001 | Edinburgh, EH6 5NG, Scotland - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 08:52:45 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id IAA20525; Wed, 18 Dec 1996 08:52:45 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 08:52:45 -0500 (EST) Date: Wed, 18 Dec 1996 05:52:27 -0800 Message-Id: <199612181352.FAA19007@spud.ascend.com> From: Karl Fox To: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Cc: ietf-ppp@MERIT.EDU Subject: BAP protocol number change In-Reply-To: <2b7ccb10@rdl.co.uk> References: <2b7ccb10@rdl.co.uk> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"gsEU1.0.O05.eS_jo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2297 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Jonathan Goodchild writes: > I am correct in interpreting that as meaning the numbers for both BAP and > BACP will be changed? Yes. > Also, any idea when this is likely to happen ? Soon. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 10:01:56 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21693; Wed, 18 Dec 1996 10:01:56 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 10:01:56 -0500 (EST) 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-l2f-03.txt Date: Wed, 18 Dec 1996 09:39:51 -0500 Sender: cclark@ietf.org Message-ID: <9612180939.aa17149@ietf.org> Resent-Message-ID: <"6CeSa3.0.dI5.VT0ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2298 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised 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 : Layer Two Forwarding (Protocol) "L2F" Author(s) : A. Valencia, M. Littlewood, T. Kolar Filename : draft-ietf-pppext-l2f-03.txt Pages : 28 Date : 12/17/1996 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. Previous RFCs have specified protocols for supporting IP dial-up via SLIP [1] and multiprotocol dial-up via PPP [2]. This document describes the Layer Two Forwarding protocol (L2F) which permits the tunneling of the link layer (i.e., HDLC, async HDLC, or SLIP frames) of higher level protocols. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. Internet-Drafts are 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-l2f-03.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2f-03.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2f-03.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19961217164415.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2f-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2f-03.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961217164415.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 10:53:02 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA22866; Wed, 18 Dec 1996 10:53:02 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 10:53:02 -0500 (EST) Message-Id: <3.0.32.19961218095357.006b2260@mail> X-Sender: kfrnswrt@mail X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Wed, 18 Dec 1996 09:53:59 -0600 To: ietf-ppp@MERIT.EDU From: Kyle Farnsworth Subject: Re: ACCM Usage in PPP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"V6_mR2.0.ya5.QD1ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2299 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 11:15 PM 12/17/96 PST, Craig Fox wrote: >> >> >> > The most common type of application I know of is PPP running on PC or MAC >> > connected to a ISDN TA dialing into a sync router. It sounds like your >> > saying that an async-to-sync TA should never allow the ACCM option to go to >> > the sync router. And that it should be an option that is negotiated >> > between the PC/MAC and the TA. However, that's not true for some TA's so >> > why not just agree to the ACCM option and Ack it? And why not just send it >> > in a Conf-Request? It seems like an easy thing to do and will eliminate >> > some Tech Support calls where the customer wants to know why his or her >> > binary file transfer is taking twice as long as it should. >> >> Sorry, I couldn't help jumping in as a concerned listener... :-) >> >> >> >> IMHO, synchronous links have no sense dealing at all with ACCM. >> What does the "A" in ACCM stand for after all? In some sense, the >> synchronous PPP came before asynchronous PPP, because PPP is a frame >> based, HDLC-like protocol. >> >The SLIPpers in the early PPP meetings would strongly disagree with >this statement. Ten points for those who remember the other group's >nickname. :-) > >> You wouldn't expect the ACCM option on a synchronous link any more >> than you would expect to send or receive bytes escaped with 0x7e >> (ie., you wouldn't). >> >I would expect this since I have read the PPP RFCs (1172, 1331 and 1662) >in which the proper rules are spelled out. A synchronous PPP implementation >MUST always ACK a peer's ACCM option. > I too have expected the sync PPP to Conf-Ack the ACCM option. RFC1172 states: There may be some use of synchronous-to-asynchronous converters (some built into modems) in Point-to-point links resulting in a synchronous PPP implementation on one end of a link and an asynchronous implemention on the other. It is the responsibility of the converter to do all mapping conversions during operation. To enable this functionality, synchronous PPP implementations MUST always accept a Async-Control-Character-Map Configuration Option (it MUST always respond to an LCP Configure-Request specifying this Configuration Option with an LCP Configure-Ack). However, acceptance of this Configuration Option does not imply that the synchronous implementation will do any character mapping, since synchronous PPP uses bit-stuffing rather than character-stuffing. Instead, all such character mapping will be performed by the asynchronous-to-synchronous converter. >I believe that the PPP RFCs have also recommended that a sync PPP not >send the ACCM option in its Config Requests but I do not remember if it >was ever written as a MUST. > You are probably correct. But that is OK for my TA's since I spoof it in the sync to async. What I don't handle is the case where the sync device Conf-Rejects the ACCM option coming form the async device. But because it appears some sync devices will flat out reject the ACCM option I now have to modify my code once again in the name of compatibility. >> If you're going to build an async-to-sync converter, part of your job >> is spoofing the ACCM option. That's just what you get to do because >> you're converting from one to the other. It's actually part of the >> value-add of the product. This is my (over-simplistic?) view. >> >In all honesty, I don't think the PPP Neanderthals considered some of >the spoofing techniques now employed. I think the assumption was that >the async/sync converter would monitor but not intrude on the negotiations. > That is the way it started out because their is no telling what LCP options where going to crop up in the future. >However, there are lots of implementations that have tried to follow the >rules. Unless there is a pressing need for a change to these rules, I >suggest we leave them alone. > There is also the case where two TA's are back-to-back providing service between two async PPP implementations. -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 11:08:01 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA23127; Wed, 18 Dec 1996 11:08:01 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 11:08:01 -0500 (EST) Message-Id: <22407.9612181607@vulcan.xylogics.com> To: Kyle Farnsworth Cc: ietf-ppp@MERIT.EDU Subject: Re: ACCM Usage in PPP In-Reply-To: Your message of "Wed, 18 Dec 1996 09:53:59 CST." <3.0.32.19961218095357.006b2260@mail> Date: Wed, 18 Dec 1996 11:07:20 -0500 From: James Carlson Resent-Message-ID: <"IiKpW3.0.ze5.SR1ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2300 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Kyle Farnsworth writes: > >I believe that the PPP RFCs have also recommended that a sync PPP not > >send the ACCM option in its Config Requests but I do not remember if it > >was ever written as a MUST. > > > You are probably correct. But that is OK for my TA's since I spoof it in > the sync to async. What I don't handle is the case where the sync device > Conf-Rejects the ACCM option coming form the async device. But because it > appears some sync devices will flat out reject the ACCM option I now have > to modify my code once again in the name of compatibility. If there are such sync devices out there, then they are horribly broken. RFC 1662 (std 51) says: 6. Asynchronous to Synchronous Conversion There may be some use of asynchronous-to-synchronous converters (some built into modems and cellular interfaces), resulting in an asynchronous PPP implementation on one end of a link and a synchronous implementation on the other. It is the responsibility of the converter to do all stuffing conversions during operation. To enable this functionality, synchronous PPP implementations MUST always respond to the Async-Control-Character-Map Configuration Option with the LCP Configure-Ack. However, acceptance of the Configuration Option does not imply that the synchronous implementation will do any ACCM mapping. Instead, all such octet mapping will be performed by the asynchronous-to-synchronous converter. Note the "MUST". There's no getting around this one. Any device that does it any other way is just plain broken. > There is also the case where two TA's are back-to-back providing service > between two async PPP implementations. In which case they negotiate transparency parameters over the link just as they would with a straight serial cable. What's the problem with that? --- James Carlson Tel: +1 617 272 8140 Annex Interface Development / Xylogics, Inc. +1 800 225 3317 53 Third Avenue / Burlington MA 01803-4491 Fax: +1 617 272 2618 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 11:24:12 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA23708; Wed, 18 Dec 1996 11:24:12 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 11:24:12 -0500 (EST) From: "Wasson, Scott" To: ietf-ppp-request , marc Cc: ietf-ppp Subject: Re: IP Address option negotiation Date: Wed, 18 Dec 96 11:21:00 E Message-Id: <32B81A5D@corvette.xyplex.com> Encoding: 32 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"gwVlF2.0.wn5.1g1ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2301 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I think we can live with this. Does anyone feel we need a numbered/unnumbered option by which we negotiate state with the peer? That would eliminate any ambiguities. Personally I think it would just add complexity and we can live without it. Other opinions? -Scott ---------- From: ietf-ppp-request To: marc Cc: ietf-ppp Subject: Re: IP Address option negotiation Date: Tuesday, December 17, 1996 10:43PM Seriously... One last time, is there any reason that you need to know how the peer is configured (numbered vs unnumbered)? Or need to set it so? > > I claim this will require no immediate change for any implementation, > > and that it is as good as we are going to get. > > Concur. It's not perfect, but acceptable. > Could it be consensus forming? Craig > // marc > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 11:30:49 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA24104; Wed, 18 Dec 1996 11:30:49 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 11:30:49 -0500 (EST) Message-Id: <3.0.32.19961218103140.006b7980@mail> X-Sender: kfrnswrt@mail X-Mailer: Windows Eudora Pro Version 3.0 Demo (32) Date: Wed, 18 Dec 1996 10:31:42 -0600 To: James Carlson From: Kyle Farnsworth Subject: Re: ACCM Usage in PPP Cc: ietf-ppp@MERIT.EDU Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Resent-Message-ID: <"NnWlL1.0.Hu5.qm1ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2302 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 11:07 AM 12/18/96 -0500, James Carlson wrote: >Kyle Farnsworth writes: >> >I believe that the PPP RFCs have also recommended that a sync PPP not >> >send the ACCM option in its Config Requests but I do not remember if it >> >was ever written as a MUST. >> > >> You are probably correct. But that is OK for my TA's since I spoof it in >> the sync to async. What I don't handle is the case where the sync device >> Conf-Rejects the ACCM option coming form the async device. But because it >> appears some sync devices will flat out reject the ACCM option I now have >> to modify my code once again in the name of compatibility. > >If there are such sync devices out there, then they are horribly broken. > >Note the "MUST". There's no getting around this one. Any device that does >it any other way is just plain broken. > It's not a matter of who is "wrong" or "right" in this case. What it boils down to is if a customer buys a $10K ISDN router and a $300 TA to dial in to it who do you think they are going to blame for bad performance and compatibility? The TA vendor of course. If sync PPP implementors feel that strongly that the ACCM should be rejected on a sync link then it will be here for a long time. >> There is also the case where two TA's are back-to-back providing service >> between two async PPP implementations. > >In which case they negotiate transparency parameters over the link just >as they would with a straight serial cable. What's the problem with that? > No problem. I was just giving you another example that some might not be aware of. -------------------------------------------------------- Kyle Farnsworth ADTRAN Inc. (205)971-8583 kfarnsworth@adtran.com -------------------------------------------------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 12:34:56 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA25634; Wed, 18 Dec 1996 12:34:56 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 12:34:56 -0500 (EST) Date: Wed, 18 Dec 1996 10:34:17 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612181734.KAA21316@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: IP Address option negotiation Resent-Message-ID: <"f5K4A3.0.9G6.ai2ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2303 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU As the proposal stands: Req(0) means "I don't know my address--please tell me" Req(addr) means "I want to use addr on my end of the link" Nak(addr) means "I want you to use addr on your end of the link" Nak(0) "SHOULD NOT" be sent Ack(0) "SHOULD NOT" be sent "Unnumbered mode" can be done by any of: 1. the common, de facto standard practice of negotiating IP address(es) that just happen to be the host address(es) of of the peer(s). 2. Rej() 3. not sending an IP Address option After reviewing my own code, I've found a small problem. Like most BSD-derived systems, IRIX will not tolerate an IP network interface that lacks an IP address. (Unnumbered mode is handled by #1.) My PPP code has a bunch of configuration modes, from the commonly used "numbered with the IP address of the primary LAN interface" to "use only whatever the peer says." What should I do in that last case when the peer either does not send any Request or sends a Req(0)? My inclination is to send Nak(0) until the retry counter kills the link. The only alternative I can see is to kill the link immediately. I agree the link is going to fail, but sending Nak(0) lets the peer know (and record in its log) that this end needs an address that it is not getting. Just killing the link might be mysterious to the peer. I think sending 10 Nak(0)'s in this case is compliant with "'Nak(0) "SHOULD NOT" be sent', since the peer should be configured to send an address when needed. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 12:40:52 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA25750; Wed, 18 Dec 1996 12:40:52 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 12:40:52 -0500 (EST) Date: Wed, 18 Dec 1996 17:39:49 +0000 (GMT) From: Malcolm Campbell To: Vernon Schryver cc: ietf-ppp@MERIT.EDU Subject: Re: IP Address option negotiation In-Reply-To: <199612181734.KAA21316@mica.denver.sgi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"VY_Yo.0.rH6.Vo2ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2304 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Wed, 18 Dec 1996, Vernon Schryver wrote: > I think sending 10 Nak(0)'s in this case is compliant with "'Nak(0) > "SHOULD NOT" be sent', since the peer should be configured to send an > address when needed. This is what my code does. If i _require_ an address, and the peer doesnt send a Request, and I cant make a valid suggestion, I send Nak(0). However, Ive never seen this converge, so I dont really have a problem if it was decided that the correct behavior was to give up on IPCP at this point. --- Malcolm ------------------------- malcolmc@europe.shiva.com ------------------------- Malcolm Campbell, Project Consultant | Shiva Europe Ltd., Tel: +44 131 561 4234 | Shiva Park, Stanwell Street Fax: +44 131 561 4001 | Edinburgh, EH6 5NG, Scotland - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 12:54:55 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA26279; Wed, 18 Dec 1996 12:54:55 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 12:54:55 -0500 (EST) From: Archie Cobbs Message-Id: <199612181753.JAA18652@bubba.whistle.com> Subject: Re: ACCM Usage in PPP In-Reply-To: <199612180715.XAA19192@greatdane.cisco.com> from Craig Fox at "Dec 17, 96 11:15:27 pm" To: fox@cisco.com (Craig Fox) Date: Wed, 18 Dec 1996 09:53:45 -0800 (PST) Cc: archie@whistle.com, kfarnsworth@adtran.com, roger@flowpoint.com, ietf-ppp@MERIT.EDU X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"nrPpW1.0.CQ6.e_2ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2305 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Craig Fox writes: > However, there are lots of implementations that have tried to follow the > rules. Unless there is a pressing need for a change to these rules, I > suggest we leave them alone. Amen to that.. :-) -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 13:20:12 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA27780; Wed, 18 Dec 1996 13:20:12 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 13:20:12 -0500 (EST) From: Craig Fox Message-Id: <199612181819.KAA19518@greatdane.cisco.com> Subject: Re: IP Address option negotiation To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Wed, 18 Dec 96 10:19:30 PST Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199612181734.KAA21316@mica.denver.sgi.com>; from "Vernon Schryver" at Dec 18, 96 10:34 am X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"GzC4Z.0.ln6.MN3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2307 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > As the proposal stands: > > Req(0) means "I don't know my address--please tell me" > Req(addr) means "I want to use addr on my end of the link" > Nak(addr) means "I want you to use addr on your end of the link" > Nak(0) "SHOULD NOT" be sent > Ack(0) "SHOULD NOT" be sent > > "Unnumbered mode" can be done by any of: > 1. the common, de facto standard practice of negotiating IP address(es) > that just happen to be the host address(es) of of the peer(s). > 2. Rej() > 3. not sending an IP Address option > > After reviewing my own code, I've found a small problem. Like most > BSD-derived systems, IRIX will not tolerate an IP network interface > that lacks an IP address. (Unnumbered mode is handled by #1.) My PPP > code has a bunch of configuration modes, from the commonly used > "numbered with the IP address of the primary LAN interface" to "use > only whatever the peer says." > > What should I do in that last case when the peer either does not send > any Request or sends a Req(0)? My inclination is to send Nak(0) until > the retry counter kills the link. The only alternative I can see is to > kill the link immediately. I agree the link is going to fail, but > sending Nak(0) lets the peer know (and record in its log) that this end > needs an address that it is not getting. Just killing the link might > be mysterious to the peer. > > I think sending 10 Nak(0)'s in this case is compliant with "'Nak(0) > "SHOULD NOT" be sent', since the peer should be configured to send an > address when needed. > I feel very uncomfortable using this mechanism to inform the peer of the incompatibility. I would prefer that you send an IPCP Terminate Request with an informational message and simultaneously issue a local debug/warning to explain the problem. The peer is as likely to log the Terminate Request and it will be less confusing. Moreover, an implementation is likely to first record that you are NAKing with the same value sent in the Request. Craig > > Vernon Schryver, vjs@sgi.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 13:10:21 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA27072; Wed, 18 Dec 1996 13:10:21 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 13:10:21 -0500 (EST) From: "Wasson, Scott" To: ietf-ppp Subject: Re: IP Address option negotiation Date: Wed, 18 Dec 96 13:09:00 E Message-Id: <32B83361@corvette.xyplex.com> Encoding: 25 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"02NQQ.0.Sc6.5E3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2306 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > After reviewing my own code, I've found a small problem. Like most > BSD-derived systems, IRIX will not tolerate an IP network interface > that lacks an IP address. (Unnumbered mode is handled by #1.) My PPP > code has a bunch of configuration modes, from the commonly used > "numbered with the IP address of the primary LAN interface" to "use > only whatever the peer says." > > What should I do in that last case when the peer either does not send > any Request or sends a Req(0)? My inclination is to send Nak(0) until > the retry counter kills the link. The only alternative I can see is to > kill the link immediately. I agree the link is going to fail, but > sending Nak(0) lets the peer know (and record in its log) that this end > needs an address that it is not getting. Just killing the link might > be mysterious to the peer. > > Vernon Schryver, vjs@sgi.com You could configure the "peer's IP address" in your box. It is used in the advent that the peer sends a Req(0), or doesn't send the option at all. Just send a Nak("peer's IP address") and that should elicit a Req("peer's IP address") from him. Basically you're just giving him what he's looking for. From then on you're golden. -Scott Wasson, swasson@xyplex.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 13:28:47 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA28367; Wed, 18 Dec 1996 13:28:47 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 13:28:47 -0500 (EST) Message-Id: <01BBECCE.106E41E0@ws107.flowpoint.com> From: Philippe Roger To: Craig Fox , "'Malcolm Campbell'" Cc: "ietf-ppp@MERIT.EDU" Subject: RE: IP Address option negotiation Date: Wed, 18 Dec 1996 10:27:25 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"0leig3.0.mw6.PV3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2309 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The only caveat is that in order to reach a point where 2 and 4 can apply, IPCP must reach the open state, which means an ACK of something must have been exchanged in each direction. Given the fact that IP addresses are pretty much all that is negotiated (forgive me for not including the Van Jacobson compression in this discussion), you might end up with no option acknowledged, which means that no address is explicitly given to the link: it is either preconfigured, unnumbered or will be defined later via 2 or 4. All that is fine, as long as implementations of IPCP agree to move IPCP to the open state even when they don't have an explicit IP address yet for the interface and/or the other side of the link, hoping that one will be assigned later via some other mechanism. Note that this scenario could also apply to terminals for which the PPP link is the only IP interface, so in that case, DHCP or equivalent had better provide an address later... Given that, why would sending an empty Config-Req (with no option) or receiving the corresponding empty Config-Ack be a problem ? Now, if a system receiving an empty Config-Req must be told the IP address of its peer (for whatever reason), how does it achieve that, short of sending a Nak(0), thereby adding an option that had been missing, but is required ? Philippe Roger roger@flowpoint.com ---------- From: Malcolm Campbell[SMTP:malcolmc@europe.shiva.com] Sent: Wednesday, December 18, 1996 3:13 AM To: Craig Fox Cc: ietf-ppp@MERIT.EDU Subject: Re: IP Address option negotiation On Tue, 17 Dec 1996, Craig Fox wrote: > > Seriously... One last time, is there any reason that you need to know how > the peer is configured (numbered vs unnumbered)? Or need to set it so? My feeling is - whether the link is numbered or unnumbered is irrelevant to PPP. IPCP Address negotiation is only one way of getting an IP address, you may be running in any number of modes, e.g.: 1. numbered, using IP Address to exchange addresses 2. numbered, using DHCP or other higher layer protocol to get an address 3. unnumbered, using IP Address to exchange an arbitrary 'router id' token which may or may not be an IP address 4. unnumbered, using some higher layer protocol to get a 'router id' for the other end of the link Unless anyone has a compelling reason why we explicitly need to use IP Address to spell out the difference between cases 2. and 4., neither of which wish to negotiate an IP address in IPCP, that we should just leave the lack of negotiated IP Address as meaning "No address configured via IPCP" --- Malcolm ------------------------- malcolmc@europe.shiva.com ------------------------- Malcolm Campbell, Project Consultant | Shiva Europe Ltd., Tel: +44 131 561 4234 | Shiva Park, Stanwell Street Fax: +44 131 561 4001 | Edinburgh, EH6 5NG, Scotland - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 13:28:43 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA28346; Wed, 18 Dec 1996 13:28:43 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 13:28:43 -0500 (EST) From: Craig Fox Message-Id: <199612181828.KAA19938@greatdane.cisco.com> Subject: Re: IP Address option negotiation To: swasson@xyplex.com (Wasson, Scott) Date: Wed, 18 Dec 96 10:28:00 PST Cc: ietf-ppp@MERIT.EDU In-Reply-To: <32B83361@corvette.xyplex.com>; from "Wasson, Scott" at Dec 18, 96 1:09 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"ul8QG1.0.Kw6.LV3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2308 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > > After reviewing my own code, I've found a small problem. Like most > > BSD-derived systems, IRIX will not tolerate an IP network interface > > that lacks an IP address. (Unnumbered mode is handled by #1.) My PPP > > code has a bunch of configuration modes, from the commonly used > > "numbered with the IP address of the primary LAN interface" to "use > > only whatever the peer says." > > > > What should I do in that last case when the peer either does not send > > any Request or sends a Req(0)? My inclination is to send Nak(0) until > > the retry counter kills the link. The only alternative I can see is to > > kill the link immediately. I agree the link is going to fail, but > > sending Nak(0) lets the peer know (and record in its log) that this end > > needs an address that it is not getting. Just killing the link might > > be mysterious to the peer. > > > > Vernon Schryver, vjs@sgi.com > > You could configure the "peer's IP address" in your box. It is used in > the advent that the peer sends a Req(0), or doesn't send the option > at all. Just send a Nak("peer's IP address") and that should elicit a > Req("peer's IP address") from him. Basically you're just giving him > what he's looking for. From then on you're golden. > This raises an interesting question. We have often talked about the unsolicited NAK as if it were necessary. I think we have almost killed the concept of the unsolicited Nak(0). Now you have mentioned the unsolicited Nak(addr) (where addr is non-zero). First, does anybody send this? Second, why would anybody send this? If I sent an IPCP Config Request without an Address option, why should you care to tell me to use an Address in the next Request or you won't Ack it? Third, who will ignore such a suggestion? I think that our implementation will always ignore it. But it may not be applicable because we will always send an IPCP Address option in our first Config Request. Fourth, who would trust the peer and reconfigure internally? Craig > -Scott Wasson, swasson@xyplex.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 13:40:10 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA28826; Wed, 18 Dec 1996 13:40:10 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 13:40:10 -0500 (EST) From: Craig Fox Message-Id: <199612181832.KAA20356@greatdane.cisco.com> Subject: RE: IP Address option negotiation To: roger@flowpoint.com (Philippe Roger) Date: Wed, 18 Dec 96 10:32:29 PST Cc: fox@cisco.com, "'Malcolm, Campbell'"@cisco.com, malcolmc@europe.shiva.com, ietf-ppp@MERIT.EDU In-Reply-To: <01BBECCE.106E41E0@ws107.flowpoint.com>; from "Philippe Roger" at Dec 18, 96 10:27 am X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"sZXAG1.0.s17.Rf3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2310 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > The only caveat is that in order to reach a point where 2 and 4 can apply, > IPCP must reach the open state, which means an ACK of something must > have been exchanged in each direction. Given the fact that IP addresses > are pretty much all that is negotiated (forgive me for not including the > Van Jacobson compression in this discussion), you might end up with > no option acknowledged, which means that no address is explicitly given > to the link: it is either preconfigured, unnumbered or will be defined later > via 2 or 4. All that is fine, as long as implementations of IPCP agree to > move IPCP to the open state even when they don't have an explicit IP > address yet for the interface and/or the other side of the link, hoping that > one will be assigned later via some other mechanism. Note that this > scenario could also apply to terminals for which the PPP link is the only > IP interface, so in that case, DHCP or equivalent had better provide an > address later... > > Given that, why would sending an empty Config-Req (with no option) or > receiving the corresponding empty Config-Ack be a problem ? Now, if > a system receiving an empty Config-Req must be told the IP address of > its peer (for whatever reason), how does it achieve that, short of sending > a Nak(0), thereby adding an option that had been missing, but is required ? > Is this a specific problem you are trying to solve. I have heard reference to the idea that you must know the peer's address. Why? Craig > Philippe Roger > roger@flowpoint.com > > ---------- > From: Malcolm Campbell[SMTP:malcolmc@europe.shiva.com] > Sent: Wednesday, December 18, 1996 3:13 AM > To: Craig Fox > Cc: ietf-ppp@MERIT.EDU > Subject: Re: IP Address option negotiation > > On Tue, 17 Dec 1996, Craig Fox wrote: > > > > Seriously... One last time, is there any reason that you need to know how > > the peer is configured (numbered vs unnumbered)? Or need to set it so? > > My feeling is - whether the link is numbered or unnumbered is irrelevant > to PPP. IPCP Address negotiation is only one way of getting an IP > address, you may be running in any number of modes, e.g.: > > 1. numbered, using IP Address to exchange addresses > 2. numbered, using DHCP or other higher layer protocol to get an address > 3. unnumbered, using IP Address to exchange an arbitrary 'router id' token > which may or may not be an IP address > 4. unnumbered, using some higher layer protocol to get a 'router id' > for the other end of the link > > Unless anyone has a compelling reason why we explicitly need to > use IP Address to spell out the difference between cases 2. and 4., > neither of which wish to negotiate an IP address in IPCP, that we should > just leave the lack of negotiated IP Address as meaning "No address > configured via IPCP" > > --- Malcolm > > ------------------------- malcolmc@europe.shiva.com ------------------------- > Malcolm Campbell, Project Consultant | Shiva Europe Ltd., > Tel: +44 131 561 4234 | Shiva Park, Stanwell Street > Fax: +44 131 561 4001 | Edinburgh, EH6 5NG, Scotland > > > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 13:47:44 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA29693; Wed, 18 Dec 1996 13:47:44 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 13:47:44 -0500 (EST) Date: Wed, 18 Dec 1996 13:44:21 -0500 (EST) From: John Shriver Message-Id: <199612181844.NAA14514@shiva-dev.shiva.com> To: Jonathan.Goodchild@rdl.co.uk CC: ietf-ppp@MERIT.EDU In-reply-to: <2b7ccb10@rdl.co.uk> (Jonathan.Goodchild@rdl.co.uk) Subject: Re: BAP protocol number change Resent-Message-ID: <"REflH3.0.bF7.Bn3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2311 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU My understanding is that the intent was that BACP will get a C000 series protocol number, and BAP will get a 4000 series protocol number. However, this doesn't really address the problem of "don't compress BAP". The reason is that what packets are compressible are individually defined by the different compression protocols, that these definitions are inconsistent, and at times ambiguous: RFC 1967 (LZS-DCP): PPP Link Control Protocol packets MUST NOT be sent within LZS-DCP packets. PPP Network Control Protocol packets MUST NOT be sent within LZS-DCP packets. RFC 1974 (Stac LZS): PPP Link Control Protocol packets MUST NOT be sent within Stac LZS packets. PPP Network Control Protocol packets MUST NOT be sent within Stac LZS packets. RFC 1977 (BSD): Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF and neither 0xFD nor 0xFB are compressed. Other PPP packets are always sent uncompressed. Control packets are infrequent and should not be compressed for robustness. RFC 1978 (Predictor): PPP Link Control Protocol packets MUST NOT be send within compressed data. RFC 1979 (Deflate): Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF and neither 0xFD nor 0xFB are compressed. Other PPP packets are always sent uncompressed. Control packets are infrequent and should not be compressed for robustness. In particular, as I read it, "Network Control Protocol" means protocol numbers 8000 and greater. That's not going to protect BAP on 4xxx. The 4000 series is "low volume protocols." If we want to do this, we really should move the "what is compressible" defintion to CCP, and make it be the 0000 - 3FFF range. Still, since the 4000 range is really data protocols (if infrequently used ones), do we really want to deny it the benefits of compression? It's not immediately obvious to me that you do not want to compress the 4000 series. The other alternative is to assign two 8000 series numbers to BACP and BAP, but then one violates the rule that BAP can only be sent if BACP open. Also, the automatons may assume that anything in the 8000's is a control protocol, to feed the FSM. There really isn't a PPP protocol number range for "command" protocols, which is what BAP is. Or, we leave it as is, and make BAP a special case in compression engines... (Geez, this brings up another silly question, are we allowed to do primary compression of a packet in Stac LZS, and then secondary compression of it in Predictor? At least BSD and Deflate disallow nested compression, the others don't.) - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 13:52:21 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA29836; Wed, 18 Dec 1996 13:52:21 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 13:52:21 -0500 (EST) Date: Wed, 18 Dec 1996 13:50:02 -0500 (EST) From: John Shriver Message-Id: <199612181850.NAA15039@shiva-dev.shiva.com> To: vjs@mica.denver.sgi.com CC: ietf-ppp@MERIT.EDU In-reply-to: <199612172342.QAA20081@mica.denver.sgi.com> (vjs@mica.denver.sgi.com) Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question Resent-Message-ID: <"SGfvq1.0.oH7.Ur3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2313 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Yeah, our real mistake was defining Multilink to care about padding. Better to require the non-end fragments to not be padded at the physical layer. That's awfully easy, and I don't think that there is any REAL hardware that would need to care about it. (Well, god forbid that there is any TA that changes packet lengths!) Since I don't think that there is any hardware getting current software development with the padding requirement, we really want to avoid adding anything "mandatory" to the protocol (like self-describing padding) that is only needed when it happens. Perhaps we should say that "PPP transmitters SHOULD NOT pad packets at the physical layer. It is allowable at all only for reasons of compatability with early implementations." However, it is not totally invalid, and "PPP receivers MUST allow for the fact that a packet may have been padded at the physical layer." With that "SHOULD NOT" above, we can stop designing around this problem in future PPP extensions. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 13:51:26 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA29777; Wed, 18 Dec 1996 13:51:26 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 13:51:26 -0500 (EST) Date: Wed, 18 Dec 1996 18:49:15 +0000 (GMT) From: Malcolm Campbell To: Craig Fox cc: Philippe Roger , "'Malcolm, Campbell'"@cisco.com, ietf-ppp@MERIT.EDU Subject: RE: IP Address option negotiation In-Reply-To: <199612181832.KAA20356@greatdane.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"VUriO.0.wG7.fq3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2312 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Wed, 18 Dec 1996, Craig Fox wrote: > Is this a specific problem you are trying to solve. I have heard reference > to the idea that you must know the peer's address. > > Why? Reasons Ive seen implementations want to know the peer's IP address: You use the peer as a default router, and want to be able to insist on knowing the other guy's IP address so you can use it as a next-hop. or so you can check his IP address against authentication data. Or so that you can route traffic to him? Or so that you can choose one of your own multi-homed IP addresses that shares a virtual subnet with the peers address, if thats possible. or.. countless reasons, really.. --- Malcolm - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 13:55:32 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA29940; Wed, 18 Dec 1996 13:55:32 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 13:55:32 -0500 (EST) From: "Wasson, Scott" To: fox , "Scott)" , swasson )> Cc: ietf-ppp Subject: Re: IP Address option negotiation Date: Wed, 18 Dec 96 13:52:00 E Message-Id: <32B83DDD@corvette.xyplex.com> Encoding: 37 TEXT X-Mailer: Microsoft Mail V3.0 Resent-Message-ID: <"x1Msf1.0.RJ7.Vu3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2314 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > I think we have almost killed the concept of the unsolicited Nak(0). Amen. > Now you have mentioned the unsolicited Nak(addr) (where addr is non-zero). > First, does anybody send this? Not unsolicited; only if we receive a Req(0.0.0.0) AND we have a peer's IP address configured to give to him. If I don't have an address to give him then I Rej() the option. > Second, why would anybody send this? If I sent an IPCP Config Request > without an Address option, why should you care to tell me to use an Address > in the next Request or you won't Ack it? I don't know. Think we should make this a "SHOULD NOT"? > Third, who will ignore such a suggestion? I think that our implementation > will always ignore it. But it may not be applicable because we will always > send an IPCP Address option in our first Config Request. We'll never send Req(0.0.0.0) -- asking to be taught your IP address seems to be more useful to dial-in hosts than it is to routers and access servers. > Fourth, who would trust the peer and reconfigure internally? Most likely a host, unlikely a router or access server. > Craig -Scott Wasson, swasson@xyplex.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 14:01:34 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA01080; Wed, 18 Dec 1996 14:01:34 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 14:01:34 -0500 (EST) From: Craig Fox Message-Id: <199612181859.KAA22314@greatdane.cisco.com> Subject: RE: IP Address option negotiation To: malcolmc@europe.shiva.com (Malcolm Campbell) Date: Wed, 18 Dec 96 10:59:44 PST Cc: fox@cisco.com, roger@flowpoint.com, "'Malcolm, Campbell'"@cisco.com, ietf-ppp@MERIT.EDU In-Reply-To: ; from "Malcolm Campbell" at Dec 18, 96 6:49 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"82BPk3.0.ZG.A-3ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2315 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > On Wed, 18 Dec 1996, Craig Fox wrote: > > Is this a specific problem you are trying to solve. I have heard reference > > to the idea that you must know the peer's address. > > > > Why? I am no IP expert. That is for sure. I hope someone corrects my mistaken beliefs. > > Reasons Ive seen implementations want to know the peer's IP address: > > You use the peer as a default router, and want to be able to > insist on knowing the other guy's IP address so you can use it as a > next-hop. > I thought IP contained the (final) destination address and not the next-hop. I realize that you would need to know that the interface pointed to the next-hop or default gateway, but there is static configuration and routing protocols. What am I misunderstanding? > or so you can check his IP address against authentication data. > Sigh. IP addresses are not useful for security checks, but I can understand there use to avoid misconfiguration. But you are saying that you would prefer not to come up if the peer does not tell you his address? > Or so that you can route traffic to him? > Static routing configuration or routing protocols are much better for going past the peer and I would argue that only a foolish host would connect and not provide an IP address. Whereas a router might have reasons to be configured thus. > Or so that you can choose one of your own multi-homed IP addresses that > shares a virtual subnet with the peers address, if thats possible. > Guessing subnets? Awesome. I assume this method supports classless addresses. > or.. > > countless reasons, really.. > I am not convinced. But as I said, I can barely spell IP. Craig > > --- Malcolm > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 14:21:31 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA02519; Wed, 18 Dec 1996 14:21:31 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 14:21:31 -0500 (EST) Date: Wed, 18 Dec 1996 19:19:05 +0000 (GMT) From: Malcolm Campbell To: Craig Fox cc: roger@flowpoint.com, "'Malcolm, Campbell'"@cisco.com, ietf-ppp@MERIT.EDU Subject: RE: IP Address option negotiation In-Reply-To: <199612181859.KAA22314@greatdane.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"B3Mps1.0.2d.sG4ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2316 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Wed, 18 Dec 1996, Craig Fox wrote: > I am no IP expert. That is for sure. I hope someone corrects my mistaken > beliefs. Well, I didnt say these were all GOOD reasons, but they are reasons people out there are doing this. My code is configurable either way, but.. > > You use the peer as a default router, and want to be able to > > insist on knowing the other guy's IP address so you can use it as a > > next-hop. > > > I thought IP contained the (final) destination address and not the next-hop. > I realize that you would need to know that the interface pointed to the > next-hop or default gateway, but there is static configuration and routing > protocols. What am I misunderstanding? Not all IP implementations can route-by-interface, some of them need to know a next hop to choose which interface to use to send the data on. Yes, IP SHOULD be able to just know that the PPP interface is the default route, but if it cant..? > > > or so you can check his IP address against authentication data. > > > Sigh. IP addresses are not useful for security checks, but I can understand > there use to avoid misconfiguration. But you are saying that you would prefer > not to come up if the peer does not tell you his address? This isnt so much for security, as to check that the peer is using the IP address corresponding to the node he just authenticated as. Quite a few implementations allow you to restrict IP address by authenticated node. It's really just a way for you to tell the peer its misconfigured. In my experience most of the systems that do this dont filter out your packets if you use some other IP address anyway when sending data, so its not a security thing. > > Or so that you can route traffic to him? > > > Static routing configuration or routing protocols are much better for going > past the peer and I would argue that only a foolish host would connect and > not provide an IP address. Whereas a router might have reasons to be > configured thus. I agree that static routing and routing protocols are better for this. But if you arent using them, and the host hasnt provided an IP address, he's sitting on one of your dialin ports, hogging it. You may well want to be able to insist dialin hosts provide an IP address, and the way to negotiate that is to Nak for it (allocating them an address). One particular example that springs to mind is a mobile host. If a mobile or nomadic host connects to you, it may not know what method it needs to use to get its care-of address. At the time of doing IPCP, it cant tell that you dont support DHCP, and dont have a foreign agent running. It may prefer to use these methods If so, I think its valid for it to connect using no IP Address option, and for the dialin server to give it an address if no other method is available. > > Or so that you can choose one of your own multi-homed IP addresses that > > shares a virtual subnet with the peers address, if thats possible. > > > Guessing subnets? Awesome. I assume this method supports classless addresses. No. Its a solution to working around certain broken implementations. > I am not convinced. But as I said, I can barely spell IP. I think there are reasons for implementations to want to use unsolicited Nak(addr). It's a useful tool in some situations, and its been in the drafts for a long time. I see no compelling reason for removing it. --- Malcolm ------------------------- malcolmc@europe.shiva.com ------------------------- Malcolm Campbell, Project Consultant | Shiva Europe Ltd., Tel: +44 131 561 4234 | Shiva Park, Stanwell Street Fax: +44 131 561 4001 | Edinburgh, EH6 5NG, Scotland - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 14:52:27 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA03846; Wed, 18 Dec 1996 14:52:27 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 14:52:27 -0500 (EST) Date: Wed, 18 Dec 1996 11:57:53 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: Karl Fox Cc: ietf-ppp@MERIT.EDU Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question In-Reply-To: <199612171930.LAA25010@spud.ascend.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"ClvRm.0.dx.sj4ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2317 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Karl, I am sorry that I was not participating when the encryption spec was being discussed. Concerning my request for a padding option to be added to the RFC, I do not understand what the issue is. If the option is not understood, it would be rejected and ecp packets would have the same format as today. If the option was accepted than a one byte padding field would be added after the ecp sequence number. Self described padding will add on average 3 bytes to each packet compared to one byte for the padding field, there is a through put advantage by enhancing the spec. Concerning the issue of adding another option to the ecp configure request, this is what I do today when requesting SDP as per the LCP extensions RFC. Philip Rakity FlowPoint Corporation (40*) 364-8300 On Tue, 17 Dec 1996, Karl Fox wrote: > Philip Rakity writes: > > Is there any reason why we should not change the RFC to allow the > > negotiation of an extra byte in the header to indicate the number of pad > > bytes added so that the use of SDP would not be necessary. This seems to > > me a cleaner approach, since if padding is needed it takes a lot less > > bytes to encode in the header then using SDP. > > It may indeed be cleaner, but we already have a specification; your > argument should have been brought up earlier, before DESE became an > Informational RFC. As it is written, the existing specification works > properly, and although changes sometimes are made to protocols to > correct defects, they are seldom changed to add minor performance > enhancements. > > Actually, I'm not sure a single length byte that is always included is > better than self-describing pad. I suspect they're about the same. > -- > Karl Fox, servant of God, employee of Ascend Communications > 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 15:30:35 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA04863; Wed, 18 Dec 1996 15:30:35 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 15:30:35 -0500 (EST) Date: Wed, 18 Dec 1996 12:29:56 -0800 Message-Id: <199612182029.MAA07204@spud.ascend.com> From: Karl Fox To: John Shriver Cc: Jonathan.Goodchild@rdl.co.uk, ietf-ppp@MERIT.EDU Subject: Re: BAP protocol number change In-Reply-To: <199612181844.NAA14514@shiva-dev.shiva.com> References: <2b7ccb10@rdl.co.uk> <199612181844.NAA14514@shiva-dev.shiva.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"Pl7Eg3.0.cB1.dH5ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2318 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU John Shriver writes: > My understanding is that the intent was that BACP will get a C000 > series protocol number, and BAP will get a 4000 series protocol > number. Someone mentioned this in the meeting, but I don't think that's the way we should go. > There really isn't a PPP protocol number range for "command" > protocols, which is what BAP is. Actually, I think both BACP and BAP are Link Control Protocols, since BAP controls the link, and BACP controls BAP. Or maybe BACP is an NCP; I'm not sure. > Or, we leave it as is, and make BAP a special case in compression > engines... No way! :-) -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 16:28:37 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA06039; Wed, 18 Dec 1996 16:28:37 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 16:28:37 -0500 (EST) Date: Wed, 18 Dec 1996 14:28:14 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612182128.OAA21911@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: IP Address option negotiation Resent-Message-ID: <"ZWFNb.0.2U1.086ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2319 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: "Wasson, Scott" > ... > > What should I do in that last case when the peer either does not send > > any Request or sends a Req(0)? My inclination is to send Nak(0) until > > the retry counter kills the link. The only alternative I can see is to > > kill the link immediately. I agree the link is going to fail, but > > sending Nak(0) lets the peer know (and record in its log) that this end > > needs an address that it is not getting. Just killing the link might > > be mysterious to the peer. > You could configure the "peer's IP address" in your box. I'm talking about a configuration error, where the operators of one box have configured it to get the address from the other box, and the operators of it have not done the obverse. > It is used in > the advent that the peer sends a Req(0), or doesn't send the option > at all. Just send a Nak("peer's IP address") and that should elicit a > Req("peer's IP address") from him. Basically you're just giving him > what he's looking for. From then on you're golden. There are real life cases where the IP address of the local box must not be used for the local end of a PPP link, and in those cases it is better to kill the link that to let it come up. For example, people sometimes use net-10, net-66, net-89 or other bogus addresses for a local Ethernet. Yes, they should not, but they do. ] From: Craig Fox ] ... ] I feel very uncomfortable using this mechanism to inform the peer of the ] incompatibility. I would prefer that you send an IPCP Terminate Request ] with an informational message and simultaneously issue a local debug/warning ] to explain the problem. The peer is as likely to log the Terminate Request ] and it will be less confusing. I disagree about the likelihood of peers logging Terminate Request strings. From what I've seen, many, probably most do not log the Terminate Request string. ] Moreover, an implementation is likely to first record that you are NAKing ] with the same value sent in the Request. That would be also be ok. I'm just hoping for something that the peer will log that has something to do with IP addresses. There are also political issues. In this case the error is as likely on the other box as mine, but the system that sends the TR is the one that is blamed by the operators. After all, - by definition of this scenario, the operators are clue challenged. - PPP is supposed to be idiot-tolerant - most people using PPP, including many at Internet Service Providers, are clue challenged about PPP--read comp.protocols.ppp if you need proof. | From: Craig Fox | ... | This raises an interesting question. We have often talked about the | unsolicited NAK as if it were necessary. | | I think we have almost killed the concept of the unsolicited Nak(0). You've convinced me. | Now you have mentioned the unsolicited Nak(addr) (where addr is non-zero). | | First, does anybody send this? My code does. The purpose of PPP for the half of the working group not interested in the goal of breaking the monopolies of leased-line router vendors in the 1980s wanted something more resistant to misconfiguration than SLIP. Being able to verify that the peer is running the right IP address is and was a primary design goal for the replacement for SLIP. | Second, why would anybody send this? If I sent an IPCP Config Request | without an Address option, why should you care to tell me to use an Address | in the next Request or you won't Ack it? Why?--to see if that your system is correctly configured. If your system has a different IP address than my system thinks it does, then many things will not work. Yes, these are hosty things, but today even routers understand telnet. | Third, who will ignore such a suggestion? I think that our implementation | will always ignore it. But it may not be applicable because we will always | send an IPCP Address option in our first Config Request. If the peer ignores a Nak(0), and you have a default address, you can stop sending Nak(0) and send Ack(). | Fourth, who would trust the peer and reconfigure internally? Mine will. The configuration stuff for my code involves several options for picking IP addresses. One lets the peer pick its own subject to a mask-and-match constraint, with a default if the peer is clueless. Yes, this means that my code cannot finish configuring the kernel IP interface until after IPCP reaches OPEN(), and the peer cannot change it's mind about its IP address after that. ] From: "Wasson, Scott" ] ... ] > Second, why would anybody send this? If I sent an IPCP Config Request ] > without an Address option, why should you care to tell me to use an ] Address ] > in the next Request or you won't Ack it? ] ] I don't know. Think we should make this a "SHOULD NOT"? Let's not get carried away while simplifying things. Why should the IP address option be so special that you cannot Nak() it? ] ... ] We'll never send Req(0.0.0.0) -- asking to be taught your IP address seems ] to be more useful to dial-in hosts than it is to routers and access servers. On the contrary, imagine a small router with an Ethernet connector and an ISDN U interface. Consider an ISP with routers that do NAT, and use RFC 1957 networks on the remote Ethernet. Let the dial-in router connect to the ISP's hub, get an IP address, and then let the hub do address translating to and from net-10. This allows dial-in hosts to be more than dumb terminals. It lets ISP's sell connectivity to people who have home networks, without permanently dedicating an IP address to each customer. ] > Fourth, who would trust the peer and reconfigure internally? ] ] Most likely a host, unlikely a router or access server. Not so! Consider the reasons for knowing the IP addresses on the ends of a PPP link. One set of reasons is just for routing IP packets or having a handle or label for the link. There is another set. If you want to telnet to a router on the other end of a PPP link, you need to know it's IP address. IP routing can work just fine without either peer knowing the other's IP address, but telnet, SNMP, DHCP, and so forth generally want IP addresses for the aspects of the PPP peer that is a host. Today, aren't all routers and access servers also hosts? ] From: Malcolm Campbell ] ... ] You may well want to be able to insist dialin hosts provide an IP address, ] and the way to negotiate that is to Nak for it (allocating them ] an address). That's a compelling reason for an unsolicted Nak(), and for refusing to go to OPEN unless they Req(). Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 16:31:04 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA06106; Wed, 18 Dec 1996 16:31:04 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 16:31:04 -0500 (EST) From: sullivan@gandalf.ca (Chris Sullivan) Message-Id: <199612182128.QAA03153@jester.gandalf.ca> Subject: Re: BAP protocol number change To: karl@ascend.com Date: Wed, 18 Dec 1996 16:28:19 -0500 (EST) Cc: ietf-ppp@MERIT.EDU (IETF PPP) In-Reply-To: <199612182029.MAA07204@spud.ascend.com> from "Karl Fox" at Dec 18, 96 12:29:56 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"mfq_X2.0.3V1.KA6ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2320 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU :-) > There really isn't a PPP protocol number range for "command" :-) > protocols, which is what BAP is. :-) :-) Actually, I think both BACP and BAP are Link Control Protocols, since :-) BAP controls the link, and BACP controls BAP. Or maybe BACP is an :-) NCP; I'm not sure. BACP is an NCP. It configures for running BAP to control the links in a multilink bundle. BAP packets do that. They are link control packets, if any are. BAP packets should not be compressed. Neither should BACP packets. It makes it easier to see them on a trace. -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 18:47:01 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA08589; Wed, 18 Dec 1996 18:47:01 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 18:47:01 -0500 (EST) Date: Wed, 18 Dec 1996 15:46:49 -0800 Message-Id: <199612182346.PAA16278@spud.ascend.com> From: Karl Fox To: Philip Rakity Cc: ietf-ppp@MERIT.EDU Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question In-Reply-To: References: <199612171930.LAA25010@spud.ascend.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"t1IgV.0.u52.m98ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2321 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Philip Rakity writes: > Self described padding will add on average 3 bytes to each packet > compared to one byte for the padding > field, there is a through put advantage by enhancing the spec. Perhaps *I* am the one who misunderstood. Here is how I understand the two padding techiniques; please correct me if I'm wrong. Each packet is padded out to a multiple of 8 bytes before being encrypted. The probabilities displayed assume uniform distribution in both packet length and the values of the final data byte. 1) Self-describing padding adds between 0 and 8 bytes of padding, depending on the length of the unencrypted data and on the byte values at the end. In the following table, `yy' indicates any value in the range from 1 through MPV (the negotiated Maximum-Pad-Value, which in this case should be 8), and `xx' indicates any value outside that range. Data Padding Probability xx 01 02 03 04 05 06 07 .125 xx xx 01 02 03 04 05 06 .125 xx xx xx 01 02 03 04 05 .125 xx xx xx xx 01 02 03 04 .125 xx xx xx xx xx 01 02 03 .125 xx xx xx xx xx xx 01 02 .125 xx xx xx xx xx xx xx 01 .125 xx xx xx xx xx xx xx xx ] .12109375 xx xx xx xx xx xx xx yy 01 02 03 04 05 06 07 08 .00390625 Average number of pads = 3.53125 2) One-byte padding adds at least one and at most 8 bytes of padding, depending on the length of the unencrypted data. I don't know where you intended to put the pad length byte (it doesn't matter), so I put it at the end. In the following table, `xx' indicates any value. Data Padding Probability xx xx xx xx xx xx xx 06 .125 xx xx xx xx xx xx xx 05 .125 xx xx xx xx xx xx xx 04 .125 xx xx xx xx xx xx xx 03 .125 xx xx xx xx xx xx xx 02 .125 xx xx xx xx xx xx xx 01 .125 xx xx xx xx xx xx xx 00 .125 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 07 .125 Average number of pads = 4.5 This is why I considered your padding mechanism more expensive than SDP. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 18:55:15 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA08745; Wed, 18 Dec 1996 18:55:15 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 18:55:15 -0500 (EST) Date: Wed, 18 Dec 96 18:53:28 EST From: "Whelan, Bill" Message-Id: <9611188509.AA850964084@netx.nei.com> To: ietf-ppp@MERIT.EDU Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question Resent-Message-ID: <"pomLH2.0.I82.VH8ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2322 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Philip, >BackGround >=========== > >When DES encryption is used, it may be necessary to increase the size >of data being encrypted to be a multiple of 8 bytes so that DES >encryption can work correctly. > >When the block is decrypted the receiver is unable to determine if >padding of the pdu took place unless self described padding has been >negotiated. Don't confuse the padding which must be added to plain text to obtain a multiple of eight bytes with the LCP negotiated self described padding option. When you negotiate SDP, you negotiate padding which may appear on the communication line. When you pad plain text before encrypting, that exact padding does NOT appear on the line; only the resulting ciphertext appears on the line. >regards, > >Philip Rakity >FlowPoint > >Tel (408) 364-8300 Bill Whelan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 18 21:22:34 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA10405; Wed, 18 Dec 1996 21:22:34 -0500 (EST) Resent-Date: Wed, 18 Dec 1996 21:22:34 -0500 (EST) Message-Id: <01BBED10.3F88A500@ws107.flowpoint.com> From: Philippe Roger To: Philip Rakity , "'Karl Fox'" Cc: "ietf-ppp@MERIT.EDU" Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question Date: Wed, 18 Dec 1996 18:21:11 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"hLSx01.0.GY2.cRAko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2323 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Karl, The method you suggest as an alternative to SDP is not what Philip Rakity had in mind. The clear-text needs to be padded to a multiple of 8 bytes before encryption, but this can be anything (including a known quantity like say, 0s). His proposal was to indicate in each ECP packet (type 0x53) the number of 0s that have been added to the clear-text before encryption, thus allowing the receiver to remove those extra characters after recovering the clear-text from the cipher-text, resulting in an identical payload as would have otherwise been sent, in absence of encryption. Obviously, only 3 bits are necessary to carry that padding information in the encrypted packet, which could be done by changing the sequence number space to 12 bits instead of the current 16 bits (make it look like Multilink short sequence numbers) or by adding an extra field in the 0x53 PPP packets if it is believed that 16 bits of sequence space is absolutely necessary. Compare this to the average of 3.5 bytes for Self-Described-Padding... As RFC1969 mentions, the recovery of the padded characters is only necessary when carrying protocols that don't include a length field, such as bridged frames when the LAN CRC is included. The question to the list was: are there any other protocols that would fall under that category (read don't include a length field and consider that the PDU size is what is received by the hardware, i.e. frame size greater than 64 bytes on Ethernet) ? Philippe Roger roger@flowpoint.com ---------- From: Karl Fox[SMTP:karl@ascend.com] Sent: Wednesday, December 18, 1996 3:46 PM To: Philip Rakity Cc: ietf-ppp@MERIT.EDU Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question Philip Rakity writes: > Self described padding will add on average 3 bytes to each packet > compared to one byte for the padding > field, there is a through put advantage by enhancing the spec. Perhaps *I* am the one who misunderstood. Here is how I understand the two padding techiniques; please correct me if I'm wrong. Each packet is padded out to a multiple of 8 bytes before being encrypted. The probabilities displayed assume uniform distribution in both packet length and the values of the final data byte. 1) Self-describing padding adds between 0 and 8 bytes of padding, depending on the length of the unencrypted data and on the byte values at the end. In the following table, `yy' indicates any value in the range from 1 through MPV (the negotiated Maximum-Pad-Value, which in this case should be 8), and `xx' indicates any value outside that range. Data Padding Probability xx 01 02 03 04 05 06 07 .125 xx xx 01 02 03 04 05 06 .125 xx xx xx 01 02 03 04 05 .125 xx xx xx xx 01 02 03 04 .125 xx xx xx xx xx 01 02 03 .125 xx xx xx xx xx xx 01 02 .125 xx xx xx xx xx xx xx 01 .125 xx xx xx xx xx xx xx xx ] .12109375 xx xx xx xx xx xx xx yy 01 02 03 04 05 06 07 08 .00390625 Average number of pads = 3.53125 2) One-byte padding adds at least one and at most 8 bytes of padding, depending on the length of the unencrypted data. I don't know where you intended to put the pad length byte (it doesn't matter), so I put it at the end. In the following table, `xx' indicates any value. Data Padding Probability xx xx xx xx xx xx xx 06 .125 xx xx xx xx xx xx xx 05 .125 xx xx xx xx xx xx xx 04 .125 xx xx xx xx xx xx xx 03 .125 xx xx xx xx xx xx xx 02 .125 xx xx xx xx xx xx xx 01 .125 xx xx xx xx xx xx xx 00 .125 xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx 07 .125 Average number of pads = 4.5 This is why I considered your padding mechanism more expensive than SDP. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 07:23:51 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id HAA16751; Thu, 19 Dec 1996 07:23:51 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 07:23:51 -0500 (EST) Mime-Version: 1.0 Date: Thu, 19 Dec 1996 12:16:21 +0000 Message-ID: <2b9339f0@rdl.co.uk> From: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Subject: Re[2]: BAP protocol number change To: jas@shiva.com, Karl Fox Cc: ietf-ppp@MERIT.EDU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Resent-Message-ID: <"eATN22.0.L54.vEJko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2324 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Karl Fox writes (in response to John Shriver): >> My understanding is that the intent was that BACP will get a C000 >> series protocol number, and BAP will get a 4000 series protocol >> number. > >Someone mentioned this in the meeting, but I don't think that's the >way we should go. Umm, does that mean that it's not been decided which range the new numbers should be in ? Chris Sullivan writes: ]BACP is an NCP. It configures for running BAP to control the links ]in a multilink bundle. BAP packets do that. They are link control ]packets, if any are. BAP packets should not be compressed. Neither ]should BACP packets. It makes it easier to see them on a trace. If BACP is an NCP then it should have an 8000 series number. And if BAP is a link control protocol, it should have a C000 series number. But then this combination would then be inconsistent with other NCP/protocol pairs. Maybe both BACP and BAP should have C000 series numbers. I guess that whatever is chosen it's going to end up being inconsistent in some way or another. BTW, I hope the 8071 and 0071 are going to be reserved so that they are never assigned to future protocols (or will IANA do that automatically ?). Jonathan.Goodchild@rdl.co.uk - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 10:06:07 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA20492; Thu, 19 Dec 1996 10:06:07 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 10:06:07 -0500 (EST) From: Craig Fox Message-Id: <199612191502.HAA17540@greatdane.cisco.com> Subject: Re: Re[2]: BAP protocol number change To: Jonathan.Goodchild@rdl.co.uk (Jonathan Goodchild) Date: Thu, 19 Dec 96 7:02:55 PST Cc: jas@shiva.com, karl@ascend.com, ietf-ppp@MERIT.EDU In-Reply-To: <2b9339f0@rdl.co.uk>; from "Jonathan Goodchild" at Dec 19, 96 12:16 pm X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"vkcid2.0.P_4.ecLko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2325 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > > Karl Fox writes (in response to John Shriver): > >> My understanding is that the intent was that BACP will get a C000 > >> series protocol number, and BAP will get a 4000 series protocol > >> number. > > > >Someone mentioned this in the meeting, but I don't think that's the > >way we should go. > My understanding matched John Shriver's. > Umm, does that mean that it's not been decided which range the new > numbers should be in ? > > Chris Sullivan writes: > ]BACP is an NCP. It configures for running BAP to control the links > ]in a multilink bundle. BAP packets do that. They are link control > ]packets, if any are. BAP packets should not be compressed. Neither > ]should BACP packets. It makes it easier to see them on a trace. > > If BACP is an NCP then it should have an 8000 series number. And if > BAP is a link control protocol, it should have a C000 series number. > But then this combination would then be inconsistent with other > NCP/protocol pairs. Maybe both BACP and BAP should have C000 series > numbers. I guess that whatever is chosen it's going to end up being > inconsistent in some way or another. > It isn't clear to me that range of numbers really matters much. Does anyone do something special for one range vs. another (with the obvious exception that 0x00yy is compressible)? I see BACP as being an NCP for BAP. I see BAP as being a data protocol since its traffic bypasses the PPP state machine and is directed to the dialer software that sits in parallel (or wherever you want it) to PPP. BAP is not a Link Control Protocol because it does not affect the current link's FSM (please correct me if I am wrong). We discussed putting BAP in the 4xxx range because it is a limited traffic, special case protocol. I argued for putting BACP at (0x8000 + BAP) to reduce the number of special case checks in the PPP protocol parsing routines. However, none of the arguments for selecting an address range for the two protocols (including mine) is worth arguing about if it delays the selection of the appropriate protocol numbers. Let's reach some consensus and go. I think that firming up the rules about which protocols are compressible is probably more important in this case. > BTW, I hope the 8071 and 0071 are going to be reserved so that they > are never assigned to future protocols (or will IANA do that > automatically ?). > IANA never does anything automatically. But I would argue for a timelimit instead of 'never' on the handing out of 0071 and 8071 only because we are rapidly running out of desirable protocol space. PPP may be with us for a very long time. Craig > Jonathan.Goodchild@rdl.co.uk > > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 11:46:41 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA29274; Thu, 19 Dec 1996 11:46:41 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 11:46:41 -0500 (EST) Date: Thu, 19 Dec 1996 11:43:30 -0500 (EST) From: John Shriver Message-Id: <199612191643.LAA09195@shiva-dev.shiva.com> To: Jonathan.Goodchild@rdl.co.uk CC: karl@ascend.com, ietf-ppp@MERIT.EDU In-reply-to: <2b9339f0@rdl.co.uk> (Jonathan.Goodchild@rdl.co.uk) Subject: Re: Re[2]: BAP protocol number change Resent-Message-ID: <"3z2gR1.0.397.i5Nko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2326 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Yes, C071 and 0071 (especially the former) must be reserved for all time. It was my understanding at the IETF that this would be so. I suupose one could recycle 0071, but the matching NCP C071 would never be available. Perhaps 0071 could be used as one of the IPv6 compression numbers, they need a lot! I don't think anytone will have IPv6 compression and old BACP in the same box... - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 12:22:31 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA00411; Thu, 19 Dec 1996 12:22:31 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 12:22:31 -0500 (EST) Message-Id: <199612191721.JAA25358@vandys-lap.cisco.com> X-Authentication-Warning: vandys-lap.cisco.com: Host localhost.cisco.com [127.0.0.1] didn't use HELO protocol To: Cynthia Clark cc: ietf-ppp@MERIT.EDU Subject: Re: I-D ACTION:draft-ietf-pppext-l2f-03.txt In-reply-to: Your message of "Thu, 19 Dec 1996 10:59:44 EST." <9612191059.aa04559@ietf.org> Date: Thu, 19 Dec 1996 09:21:52 -0800 From: Andy Valencia Resent-Message-ID: <"ul-0w1.0.56.IdNko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2327 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU [Cynthia Clark writes:] > > Shome Mishtake Shurely? Shouldn't it be L2TP? >Thank you for bringing this to my attention. > >Since I doubt that this is an error, >I would like to hear this from one of the >authors Andy Valencia regarding this matter. > >In the future, if there is a problem or concern then >please contact me directly at >instead of L2TP is the work of merging PPTP and L2F. It was pointed out (repeatedly) to me that L2F had disappeared off the IETF archives (due to the 6-month expiration), which made it hard for people to compare the input material to the output. I had some pending minor markups, so it seemed opportunistic to submit the text, get the latest/cleanest version out there, and help those who wanted to view the L2F/PPTP material as well as L2TP. The markups were done months ago, so pushing this to the secretary is a no-op WRT the schedule of the next L2TP draft. I've copied PPPEXT, as it would be nice to nip this in the bud. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 12:32:31 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA00888; Thu, 19 Dec 1996 12:32:31 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 12:32:31 -0500 (EST) From: Craig Fox Message-Id: <199612191730.JAA21121@greatdane.cisco.com> Subject: Re: Re[2]: BAP protocol number change To: jas@shiva.com (John Shriver) Date: Thu, 19 Dec 96 9:30:17 PST Cc: Jonathan.Goodchild@rdl.co.uk, karl@ascend.com, ietf-ppp@MERIT.EDU In-Reply-To: <199612191643.LAA09195@shiva-dev.shiva.com>; from "John Shriver" at Dec 19, 96 11:43 am X-Mailer: ELM [version 2.3 PL11] Resent-Message-ID: <"uZyps1.0.VD.gmNko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2328 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > > Yes, C071 and 0071 (especially the former) must be reserved for all > time. It was my understanding at the IETF that this would be so. > 0071 and 8071 > I suupose one could recycle 0071, but the matching NCP C071 would > never be available. Perhaps 0071 could be used as one of the IPv6 > compression numbers, they need a lot! I don't think anytone will have > IPv6 compression and old BACP in the same box... > Actually, it is a good idea to use it in this way because then the 8071 number would never be needed. Even if a box supporting IPv6 tries to negotiate with an old BACP box, both the old 8071 and the IPv6 NCPs will be rejected and thus there will be no collisions on the use of 0071. This idea may be extended to help us recover the other 'reserved' number, 0037, which is listed as being reserved until 1993. Craig - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 13:18:24 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA02174; Thu, 19 Dec 1996 13:18:24 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 13:18:24 -0500 (EST) From: Archie Cobbs Message-Id: <199612191817.KAA22093@bubba.whistle.com> Subject: Re: Re[2]: BAP protocol number change In-Reply-To: <199612191502.HAA17540@greatdane.cisco.com> from Craig Fox at "Dec 19, 96 07:02:55 am" To: fox@cisco.com (Craig Fox) Date: Thu, 19 Dec 1996 10:17:18 -0800 (PST) Cc: Jonathan.Goodchild@rdl.co.uk, jas@shiva.com, karl@Ascend.COM, ietf-ppp@MERIT.EDU X-Mailer: ELM [version 2.4ME+ PL25 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"RwZ5c1.0.fX.hROko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2329 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > It isn't clear to me that range of numbers really matters much. Does > anyone do something special for one range vs. another (with the obvious > exception that 0x00yy is compressible)? While not too familiar with BACP/BAP, here is how my multi-link code uses the protocol "range" to make decisions. I don't think there are any surprises here... These macros are defined: #define PROT_LOW_VOLUME(p) (((p) & 0xC000) == 0x4000) #define PROT_NETWORK_CTRL(p) (((p) & 0xC000) == 0x8000) #define PROT_LINK_LAYER(p) (((p) & 0xC000) == 0xC000) #define PROT_COMPRESSIBLE(p) (((p) & 0xFF00) == 0x0000) These decisions are made at various points using these macros: * If a PROT_LINK_LAYER(p) packet comes in over the multi-link bundle (over the "virtual link") treat it specially (only stuff like LCP protocol-reject, echo-request, etc. is valid). * When an ECHO packet comes in (not necessarily LCP), if not PROT_LINK_LAYER(p), then don't validate the magic number. If multi-link is active, there may be no magic number. * Only PROT_COMPRESSIBLE(p) packets are candidates for protocol field compression. * Only PROT_NETWORK_DATA(p) packets are candidates for CCP compression. Does this sound right? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 13:35:09 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA02758; Thu, 19 Dec 1996 13:35:09 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 13:35:09 -0500 (EST) From: sullivan@gandalf.ca (Chris Sullivan) Message-Id: <9612191833.AA09565@hobbit.gandalf.ca> Subject: Re: Re[2]: BAP protocol number change To: archie@whistle.com (Archie Cobbs) Date: Thu, 19 Dec 1996 13:33:11 -0500 (EST) Cc: ietf-ppp@MERIT.EDU (IETF PPP) In-Reply-To: <199612191817.KAA22093@bubba.whistle.com> from "Archie Cobbs" at Dec 19, 96 10:17:18 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"ojWPG.0.ng.OhOko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2330 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU :-) #define PROT_COMPRESSIBLE(p) (((p) & 0xFF00) == 0x0000) :-) :-) * Only PROT_NETWORK_DATA(p) packets are candidates for CCP :-) compression. You would have to treat 0071 (old-BAP) as a special case and not compress it. We now have added some code that handles compressed old-BAP packets in case they are received. So the only issue for us is that they are not readable on a trace, if compressed. -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 14:15:08 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA04295; Thu, 19 Dec 1996 14:15:08 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 14:15:08 -0500 (EST) Date: Thu, 19 Dec 1996 11:13:52 -0800 Message-Id: <199612191913.LAA20265@spud.ascend.com> From: Karl Fox To: Philippe Roger Cc: Philip Rakity , "ietf-ppp@MERIT.EDU" Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question In-Reply-To: <01BBED10.3F88A500@ws107.flowpoint.com> References: <01BBED10.3F88A500@ws107.flowpoint.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"M3yue1.0.f21.tGPko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2331 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Philippe Roger writes: > Karl, > > The method you suggest as an alternative to SDP is not what Philip Rakity > had in mind. The clear-text needs to be padded to a multiple of 8 bytes > before encryption, but this can be anything (including a known quantity > like say, 0s). His proposal was to indicate in each ECP packet (type 0x53) > the number of 0s that have been added to the clear-text before encryption, > thus allowing the receiver to remove those extra characters after recovering > the clear-text from the cipher-text, resulting in an identical payload as would > have otherwise been sent, in absence of encryption. I'm apparently confused about something then, because that's precisely what I thought I was describing. > Obviously, only 3 bits are necessary to carry that padding information in the > encrypted packet, which could be done by changing the sequence number > space to 12 bits instead of the current 16 bits (make it look like Multilink short > sequence numbers) or by adding an extra field in the 0x53 PPP packets if it > is believed that 16 bits of sequence space is absolutely necessary. > > Compare this to the average of 3.5 bytes for Self-Described-Padding... Ok then, the `3 free bits' method would pad packets like this: In the following table, `xx' indicates any value. Data Padding Probability xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 Average number of pads = 3.5 Thus SDP, at 3.53125 bytes per packet, compares pretty favorably with this ideal padding scheme. I don't see the need for changing away from SDP, which is 1) already published, 2) works, and 3) is a standard. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 14:36:19 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA05568; Thu, 19 Dec 1996 14:36:19 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 14:36:19 -0500 (EST) Date: Thu, 19 Dec 1996 12:36:04 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612191936.MAA02382@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question Resent-Message-ID: <"2BKwG2.0.cM1.kaPko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2332 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Karl Fox > ... > > The method you suggest as an alternative to SDP is not what Philip Rakity > > had in mind. The clear-text needs to be padded to a multiple of 8 bytes > > before encryption, but this can be anything (including a known quantity > > like say, 0s). His proposal was to indicate in each ECP packet (type 0x53) > > the number of 0s that have been added to the clear-text before encryption, > > thus allowing the receiver to remove those extra characters after recovering > > the clear-text from the cipher-text, resulting in an identical payload as would > > have otherwise been sent, in absence of encryption. > > I'm apparently confused about something then, because that's precisely > what I thought I was describing. No, I think one thing described are schemes to send padding over the wire, while the other thing involves sending an indication of padding that needs to be added to a message by the receiver before the message is decrypted. In the second thing, only the indication of the padding and not the padding bytes themselves are sent over the wire, while the padding bytes themselves need never waste bandwidth. The purpose of the padding in this case is not to make hardware happy, but to satisfy the needs of software. The receiver of the message can add arbitrary padding to the message after it is received and before it is handed to the decrypting software. > ... > Ok then, the `3 free bits' method would pad packets like this: > ... > Average number of pads = 3.5 > > Thus SDP, at 3.53125 bytes per packet, compares pretty favorably with > this ideal padding scheme. Yes, but only if the padding bytes themselves must be sent over the wire. If the padding bytes can be computed by the receiver without sending them over the wire, then this "ideal padding scheme" has far less overhead than SDP. However, I think there are some encryption schemes where the padding bytes must be sent over the wire, where the formation in the cleartext is spread over the entire block. The common notion of not sending padding over the wire (e.g. the RIPv2 MD5 authentication scheme) might not be useful here. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 14:57:26 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA06530; Thu, 19 Dec 1996 14:57:26 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 14:57:26 -0500 (EST) From: sullivan@gandalf.ca (Chris Sullivan) Message-Id: <199612191955.OAA22511@jester.gandalf.ca> Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question To: vjs@mica.denver.sgi.com (Vernon Schryver) Date: Thu, 19 Dec 1996 14:55:12 -0500 (EST) Cc: ietf-ppp@MERIT.EDU In-Reply-To: <199612191936.MAA02382@mica.denver.sgi.com> from "Vernon Schryver" at Dec 19, 96 12:36:04 pm X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Ao2rU2.0.Xb1.WuPko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2333 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU :-) > > The method you suggest as an alternative to SDP is not what Philip Rakity :-) > > had in mind. The clear-text needs to be padded to a multiple of 8 bytes :-) > > before encryption, but this can be anything (including a known quantity :-) > > like say, 0s). His proposal was to indicate in each ECP packet (type 0x53) :-) > > the number of 0s that have been added to the clear-text before encryption, :-) > > thus allowing the receiver to remove those extra characters after recovering :-) > > the clear-text from the cipher-text, resulting in an identical payload as would :-) > > have otherwise been sent, in absence of encryption. :-) No, I think one thing described are schemes to send padding over the :-) wire, while the other thing involves sending an indication of padding :-) that needs to be added to a message by the receiver before the message :-) is decrypted. In the second thing, only the indication of the padding :-) and not the padding bytes themselves are sent over the wire, while the :-) padding bytes themselves need never waste bandwidth. The purpose of :-) the padding in this case is not to make hardware happy, but to satisfy :-) the needs of software. The receiver of the message can add arbitrary :-) padding to the message after it is received and before it is handed to :-) the decrypting software. I don't think so. Reading the top paragraph, the steps would be: 1. Pad the packet using SDP or nulls or whatever. (needed by encryptor) 2. Encrypt the packet. Not clear to me whether SDP or null pads grow the encrypted packet, since I don't know the details. If they do, then an encrypted version of the pads is indeed sent over the wire. 3. Add header, with or without the 3 bits of pad-length info. 4. Send it. 5. Receive it. 6. Decrypt it. 7. Strip it, using 3 bits from header, or SDP method. -- Chris Sullivan Gandalf Data Limited sullivan@gandalf.ca does not necessarily share my opinions, including this one - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 15:25:53 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA07685; Thu, 19 Dec 1996 15:25:53 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 15:25:53 -0500 (EST) Date: Thu, 19 Dec 1996 12:25:41 -0800 Message-Id: <199612192025.MAA23270@spud.ascend.com> From: Karl Fox To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: ietf-ppp@MERIT.EDU Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question In-Reply-To: <199612191936.MAA02382@mica.denver.sgi.com> References: <199612191936.MAA02382@mica.denver.sgi.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"1NjJY2.0.lt1.DJQko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2334 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon Schryver writes: > > From: Karl Fox > > Average number of pads = 3.5 > > > > Thus SDP, at 3.53125 bytes per packet, compares pretty favorably with > > this ideal padding scheme. > > Yes, but only if the padding bytes themselves must be sent over the > wire. If the padding bytes can be computed by the receiver without > sending them over the wire, then this "ideal padding scheme" has far > less overhead than SDP. True. In the context of block encryption schemes though, where the cleartext must be padded out to a multiple of the block size, the padding is applied before encryption and the entire resulting series of encrypted blocks must be transmitted. DES is certainly this way, as are all block encryption schemes I'm aware of. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 15:35:18 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA08042; Thu, 19 Dec 1996 15:35:18 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 15:35:18 -0500 (EST) Message-Id: <01BBEDA8.ED3E6AC0@ws107.flowpoint.com> From: Philippe Roger To: "'Karl Fox'" Cc: Philip Rakity , "ietf-ppp@MERIT.EDU" Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question Date: Thu, 19 Dec 1996 12:34:06 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Kd5Wr2.0.Hz1.1SQko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2335 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Karl, As Chris Sullivan (sullivan@gandalf.ca) puts it: >1. Pad the packet using SDP or nulls or whatever. (needed by encryptor) >2. Encrypt the packet. Not clear to me whether SDP or null pads grow the > encrypted packet, since I don't know the details. If they do, then an > encrypted version of the pads is indeed sent over the wire. >3. Add header, with or without the 3 bits of pad-length info. >4. Send it. >5. Receive it. >6. Decrypt it. >7. Strip it, using 3 bits from header, or SDP method. I was wrong comparing the sizes of 3 bits to 3.5 bytes because the DES encryption algorithm produces the same number of bits as output as the number of bits fed in, including the necessary padding, whatever the pattern of input bits happens to be. However, including this 3 bits field representing the padding length in each type 0x53 packet and making it mandatory in the next revision to RFC1969 (entitled "The PPP DES Encryption Protocol (DESE)" is consistent with the Cipher Block Chaining method of the DES algorithm chosen for this protocol. This would make the ECP/DES protocol self-contained and not relying on an other protocol and would eliminate the need for negotiating SDP within the ECP protocol. This would also eliminate the cases where an extra 8 bytes of padding are generated by SDP, when the data being padded is already a multiple of 8 bytes but terminates in a sequence similar to an SDP pattern (like 1,2,3). I am not suggesting that SDP is bad, except that it adds complexity and most likely incompatibility situations since not everyone supports it. I am saying ECP/DES would be better without it. Philippe Roger roger@flowpoint.com ---------- From: Karl Fox[SMTP:karl@ascend.com] Sent: Thursday, December 19, 1996 11:13 AM To: Philippe Roger Cc: Philip Rakity; ietf-ppp@MERIT.EDU Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question Philippe Roger writes: > Karl, > > The method you suggest as an alternative to SDP is not what Philip Rakity > had in mind. The clear-text needs to be padded to a multiple of 8 bytes > before encryption, but this can be anything (including a known quantity > like say, 0s). His proposal was to indicate in each ECP packet (type 0x53) > the number of 0s that have been added to the clear-text before encryption, > thus allowing the receiver to remove those extra characters after recovering > the clear-text from the cipher-text, resulting in an identical payload as would > have otherwise been sent, in absence of encryption. I'm apparently confused about something then, because that's precisely what I thought I was describing. > Obviously, only 3 bits are necessary to carry that padding information in the > encrypted packet, which could be done by changing the sequence number > space to 12 bits instead of the current 16 bits (make it look like Multilink short > sequence numbers) or by adding an extra field in the 0x53 PPP packets if it > is believed that 16 bits of sequence space is absolutely necessary. > > Compare this to the average of 3.5 bytes for Self-Described-Padding... Ok then, the `3 free bits' method would pad packets like this: In the following table, `xx' indicates any value. Data Padding Probability xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 xx xx xx xx xx xx xx xx .125 Average number of pads = 3.5 Thus SDP, at 3.53125 bytes per packet, compares pretty favorably with this ideal padding scheme. I don't see the need for changing away from SDP, which is 1) already published, 2) works, and 3) is a standard. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 16:41:28 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA10296; Thu, 19 Dec 1996 16:41:28 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 16:41:28 -0500 (EST) Date: Thu, 19 Dec 1996 13:41:04 -0800 Message-Id: <199612192141.NAA26681@spud.ascend.com> From: Karl Fox To: Philippe Roger Cc: Philip Rakity , "ietf-ppp@MERIT.EDU" Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question In-Reply-To: <01BBEDA8.ED3E6AC0@ws107.flowpoint.com> References: <01BBEDA8.ED3E6AC0@ws107.flowpoint.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"xCXeF3.0.ZW2.2QRko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2336 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Philippe Roger writes: > However, including this 3 bits field representing the padding length in each > type 0x53 packet and making it mandatory in the next revision to RFC1969 > (entitled "The PPP DES Encryption Protocol (DESE)" is consistent with the > Cipher Block Chaining method of the DES algorithm chosen for this protocol. > This would make the ECP/DES protocol self-contained and not relying > on an other protocol and would eliminate the need for negotiating SDP > within the ECP protocol. This would also eliminate the cases where an > extra 8 bytes of padding are generated by SDP, when the data being > padded is already a multiple of 8 bytes but terminates in a sequence > similar to an SDP pattern (like 1,2,3). > > I am not suggesting that SDP is bad, except that it adds complexity and > most likely incompatibility situations since not everyone supports it. I am > saying ECP/DES would be better without it. I wouldn't think it would be necessary to negotiate SDP; just put it in the spec. Worrying about the 8-byte-pad case is a red herring; it only occurs in 0.39% of all packets, a negligible amount. Why do you say SDP adds complexity? Every scheme takes code, and the different methods don't look all that different to me in terms of complexity. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 16:47:18 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA10612; Thu, 19 Dec 1996 16:47:18 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 16:47:18 -0500 (EST) Date: Thu, 19 Dec 1996 13:46:41 -0800 Message-Id: <199612192146.NAA26814@spud.ascend.com> From: Karl Fox To: inads@research.ftp.com, rfc-editor@isi.edu Cc: Steve Coya , ietf-ppp@MERIT.EDU Subject: Advancement of PPP Vendor Extensions to Informational Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"ZuuPH2.0.Ub2.XVRko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2337 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU It is the consensus of the PPP Working Group that draft-ietf-pppext-vendor-00.txt should be advanced to Informational RFC. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 17:02:50 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA11381; Thu, 19 Dec 1996 17:02:50 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 17:02:50 -0500 (EST) Message-Id: <96Dec19.170214est.30796-1@janus.border.com> To: Philippe Roger cc: "'Karl Fox'" , Philip Rakity , "ietf-ppp@MERIT.EDU" Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question References: <01BBEDA8.ED3E6AC0@ws107.flowpoint.com> In-reply-to: roger's message of "Thu, 19 Dec 1996 15:34:06 -0500". <01BBEDA8.ED3E6AC0@ws107.flowpoint.com> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 19 Dec 1996 17:02:28 -0500 Sender: chk@border.com Resent-Message-ID: <"rABEJ2.0.Wn2.5kRko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2339 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In message <01BBEDA8.ED3E6AC0@ws107.flowpoint.com>, Philippe Roger writes: > > This would make the ECP/DES protocol self-contained and not relying > on an other protocol and would eliminate the need for negotiating SDP > within the ECP protocol. One does not "negotiate" padding for DES; it's required, and pads to a fixed-size boundary. -- C. Harald Koch chk@border.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 17:02:10 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA11200; Thu, 19 Dec 1996 17:02:10 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 17:02:10 -0500 (EST) Message-Id: <96Dec19.170131est.30796-2@janus.border.com> To: sullivan@gandalf.ca (Chris Sullivan) cc: vjs@mica.denver.sgi.com (Vernon Schryver), ietf-ppp@MERIT.EDU Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question References: <199612191955.OAA22511@jester.gandalf.ca> In-reply-to: sullivan's message of "Thu, 19 Dec 1996 14:55:12 -0500". <199612191955.OAA22511@jester.gandalf.ca> From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 19 Dec 1996 17:01:49 -0500 Sender: chk@border.com Resent-Message-ID: <"eXm163.0.fk2.UjRko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2338 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Some (brief) crypto notes: Block ciphers, such as DES, Triple DES, RC5, and so on, can be used in multiple different modes, that have different padding requirements. However, the most common mode used is CBC (Cipher Block Chaining), which outputs data that is a multiple of the blocksize in length, *and* requires input that is a multiple of the block size in length. In the case of DES and Triple DES, the block size is 64 bits (8 bytes). A good cipher distributes information from the input throughout the output block; therefore, even in a block containing one byte of data and 7 bytes of padding, the "information" in the one byte of data is distributed throughout the block. As a result, the *enture* block must be transmitted, in order to recover the plaintext. After decryption, the padding must be removed again. In summary, The padding is always transmitted (in encrypted form). It is not possible to "save bandwidth" by "not transmitting the padding". P.S. For reference, RFC1829 (The ESP DES-CBC Transform) describes yet another form of padding used by the IPsec protocols for DES based encryption. -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6 +1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change." +1 416 813 2001 (fax) | -Karen Murphy - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 17:09:35 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA12294; Thu, 19 Dec 1996 17:09:35 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 17:09:35 -0500 (EST) Date: Thu, 19 Dec 1996 14:14:54 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: Vernon Schryver Cc: ietf-ppp@MERIT.EDU Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question In-Reply-To: <199612191936.MAA02382@mica.denver.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"Sdrzi.0.j_2.QqRko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2340 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Vernon, You need the pad bytes SENT, since DES operates on 8 byte chunks and those "PAD" bytes are the cypher block for decrypting the next packet. Philip Rakity On Thu, 19 Dec 1996, Vernon Schryver wrote: > > From: Karl Fox > > > ... > > > The method you suggest as an alternative to SDP is not what Philip Rakity > > > had in mind. The clear-text needs to be padded to a multiple of 8 bytes > > > before encryption, but this can be anything (including a known quantity > > > like say, 0s). His proposal was to indicate in each ECP packet (type 0x53) > > > the number of 0s that have been added to the clear-text before encryption, > > > thus allowing the receiver to remove those extra characters after recovering > > > the clear-text from the cipher-text, resulting in an identical payload as would > > > have otherwise been sent, in absence of encryption. > > > > I'm apparently confused about something then, because that's precisely > > what I thought I was describing. > > No, I think one thing described are schemes to send padding over the > wire, while the other thing involves sending an indication of padding > that needs to be added to a message by the receiver before the message > is decrypted. In the second thing, only the indication of the padding > and not the padding bytes themselves are sent over the wire, while the > padding bytes themselves need never waste bandwidth. The purpose of > the padding in this case is not to make hardware happy, but to satisfy > the needs of software. The receiver of the message can add arbitrary > padding to the message after it is received and before it is handed to > the decrypting software. > > > > ... > > Ok then, the `3 free bits' method would pad packets like this: > > > ... > > Average number of pads = 3.5 > > > > Thus SDP, at 3.53125 bytes per packet, compares pretty favorably with > > this ideal padding scheme. > > Yes, but only if the padding bytes themselves must be sent over the > wire. If the padding bytes can be computed by the receiver without > sending them over the wire, then this "ideal padding scheme" has far > less overhead than SDP. > > > However, I think there are some encryption schemes where the padding > bytes must be sent over the wire, where the formation in the cleartext > is spread over the entire block. The common notion of not sending > padding over the wire (e.g. the RIPv2 MD5 authentication scheme) might > not be useful here. > > > Vernon Schryver, vjs@sgi.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 17:17:00 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA13309; Thu, 19 Dec 1996 17:17:00 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 17:17:00 -0500 (EST) Date: Thu, 19 Dec 1996 15:16:34 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612192216.PAA02797@mica.denver.sgi.com> Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"lILHz3.0.eF3.OxRko"@merit.edu> To: ietf-ppp@MERIT.EDU Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2341 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Philip Rakity > Vernon, > > You need the pad bytes SENT, since DES operates on 8 byte chunks and > those "PAD" bytes are the cypher block for decrypting the next packet. Ok. That's why I also wrote, but at least 3 people did not read: > > However, I think there are some encryption schemes where the padding > > bytes must be sent over the wire, where the formation in the cleartext [information] > > is spread over the entire block. The common notion of not sending > > padding over the wire (e.g. the RIPv2 MD5 authentication scheme) might > > not be useful here. Vernon Schryver, vjs@sgi.com ¾ï1$ýùdOI .pdefaults .loc-cshrc .nevotinit .gamtables .signature .sgihelprc .insightrc .Xdefaults - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 18:10:49 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA17013; Thu, 19 Dec 1996 18:10:49 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 18:10:49 -0500 (EST) Message-Id: <01BBEDBE.88528860@ws107.flowpoint.com> From: Philippe Roger To: Philippe Roger , "'C. Harald Koch'" Cc: "'Karl Fox'" , Philip Rakity , "ietf-ppp@MERIT.EDU" Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question Date: Thu, 19 Dec 1996 15:08:45 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"woKdU1.0.O94.qjSko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2342 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I understand that some form of padding of the clear-text is needed for the CBC method of DES. As far as the DES algorithm is concerned, any pad data can do. If it is agreed by everyone that SDP is *THE* way to do padding in that context (and I argue that the method we propose is better), then RFC1969 or its replacement, should make it a MUST that the padded data takes the SDP format, although no negotiation of SDP takes place in LCP or ECP, *AS IF THE SDP OPTION HAD BEEN NEGOTIATED WITH A MPV VALUE OF 8*. Note that unless SDP is *ALWAYS* applied, even in cases where it is not strictly needed such as IP (which has a detrimental effect as packets can grow by 8 bytes), a new version of the ECP/DES specification should also specify when the SDP method is applied. For most cases garbage padding is adequate, so how does the receiver know whether garbage padding or SDP was used ? At present, this is not my understanding of RFC1969: instead it says that SDP is an option (defined in reference [4]: i.e. RFC1570). This makes it all but impossible to have interoperable implementations of ECP/DES when requiring the decrypted text to match the original clear-text in size. One such use, as mentioned before, is the transport of bridged frames with LAN CRC preserved. Our suggested alternative: make it mandatory to describe the padding of the clear-text with 3 bits in the type 0x53 ECP/DES packet header. It has no bandwidth overhead (not even the occasional additional 8 bytes) and is trivial to implement. It does not even matter what characters you use for padding: garbage, SDP, nulls, whatever... The pad characters are needed by the decryptor to proceed with the next packet, but the layers above PPP, use the decrypted payloads, do not need to know what the pad characters were, just how many there was. Philippe Roger roger@flowpoint.com ---------- From: C. Harald Koch[SMTP:chk@border.com] Sent: Thursday, December 19, 1996 2:02 PM To: Philippe Roger Cc: 'Karl Fox'; Philip Rakity; ietf-ppp@MERIT.EDU Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question In message <01BBEDA8.ED3E6AC0@ws107.flowpoint.com>, Philippe Roger writes: > > This would make the ECP/DES protocol self-contained and not relying > on an other protocol and would eliminate the need for negotiating SDP > within the ECP protocol. One does not "negotiate" padding for DES; it's required, and pads to a fixed-size boundary. -- C. Harald Koch chk@border.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 18:49:47 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA18105; Thu, 19 Dec 1996 18:49:47 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 18:49:47 -0500 (EST) Date: Thu, 19 Dec 1996 15:49:11 -0800 (PST) From: Mike Thornburg To: Philippe Roger cc: "'C. Harald Koch'" , "'Karl Fox'" , Philip Rakity , "ietf-ppp@MERIT.EDU" Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question In-Reply-To: <01BBEDBE.88528860@ws107.flowpoint.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"is7cq3.0.aQ4.NITko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2343 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I'm not enough of a cryptographer to know if the easily-predicted form of SDP opens you up to any known-cleartext types of attacks, but I'd advise asking the opinions of experts before requiring SDP in this sort of situation. Mike -------------- Mike Thornburg frigate networks 415.903.2266 mthorn@frigate.com http://www.frigate.com/ On Thu, 19 Dec 1996, Philippe Roger wrote: > > I understand that some form of padding of the clear-text is needed for the > CBC method of DES. As far as the DES algorithm is concerned, any pad data can do. > > If it is agreed by everyone that SDP is *THE* way to do padding in that > context (and I argue that the method we propose is better), then RFC1969 > or its replacement, should make it a MUST that the padded data takes the > SDP format, although no negotiation of SDP takes place in LCP or ECP, > *AS IF THE SDP OPTION HAD BEEN NEGOTIATED WITH A MPV VALUE > OF 8*. Note that unless SDP is *ALWAYS* applied, even in cases where > it is not strictly needed such as IP (which has a detrimental effect as packets > can grow by 8 bytes), a new version of the ECP/DES specification should > also specify when the SDP method is applied. For most cases garbage > padding is adequate, so how does the receiver know whether garbage > padding or SDP was used ? > > At present, this is not my understanding of RFC1969: instead it says that > SDP is an option (defined in reference [4]: i.e. RFC1570). This makes it > all but impossible to have interoperable implementations of ECP/DES when > requiring the decrypted text to match the original clear-text in size. One > such use, as mentioned before, is the transport of bridged frames with > LAN CRC preserved. > > Our suggested alternative: make it mandatory to describe the padding of the > clear-text with 3 bits in the type 0x53 ECP/DES packet header. It has > no bandwidth overhead (not even the occasional additional 8 bytes) and > is trivial to implement. It does not even matter what characters you use for > padding: garbage, SDP, nulls, whatever... The pad characters are needed > by the decryptor to proceed with the next packet, but the layers above PPP, > use the decrypted payloads, do not need to know what the pad characters > were, just how many there was. > > Philippe Roger > roger@flowpoint.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 19:23:17 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA18700; Thu, 19 Dec 1996 19:23:17 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 19:23:17 -0500 (EST) Message-Id: <01BBEDC8.6736B020@ws107.flowpoint.com> From: Philippe Roger To: "'Mike Thornburg'" Cc: "'ietf-ppp@merit.edu'" Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question Date: Thu, 19 Dec 1996 16:19:25 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"qY8vJ3.0.qZ4.mnTko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2345 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Mike, I am not an encryption expert either but I know enough to say that the real test of the strength of an encryption algorithm is measured by how hard it is to find out the keys used to encrypt/decrypt knowing all the following: the algorithm, the clear-text *and* the cipher-text. Besides I am not arguing in *favor* of SDP: I'd rather have 0s instead (with a count of them in the ECP/DES packet header), which for the purpose of known clear-text attacks is the same thing. SDP is mentioned already in RFC1969 and given the fact that padding of some sort is *mandatory* for the CBC form of DES, it does not matter what you use. It is assumed that the attacker knows what it is: you don't make the encryption any stronger by performing garbage padding! Philippe Roger roger@flowpoint.com ---------- From: Mike Thornburg[SMTP:mthorn@frigate.com] Sent: Thursday, December 19, 1996 7:49 AM To: Philippe Roger Cc: 'C. Harald Koch'; 'Karl Fox'; Philip Rakity; ietf-ppp@MERIT.EDU Subject: RE: RFC 1968 / RFC1969 (Encryption) Padding Question I'm not enough of a cryptographer to know if the easily-predicted form of SDP opens you up to any known-cleartext types of attacks, but I'd advise asking the opinions of experts before requiring SDP in this sort of situation. Mike - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 19:23:11 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA18666; Thu, 19 Dec 1996 19:23:11 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 19:23:11 -0500 (EST) Date: Thu, 19 Dec 1996 16:21:50 -0800 (PST) From: Keith Sklower Message-Id: <199612200021.QAA27932@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: Re: purported ambiguity in RFC 1969 Resent-Message-ID: <"KLK0G3.0.DZ4.gnTko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2344 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU On Thu, 19 Dec 1996, Philippe Roger wrote: > > At present, this is not my understanding of RFC1969: instead it says that > SDP is an option (defined in reference [4]: i.e. RFC1570). This makes it > all but impossible to have interoperable implementations of ECP/DES when > requiring the decrypted text to match the original clear-text in size. One > such use, as mentioned before, is the transport of bridged frames with > LAN CRC preserved. > However, RFC1969 states quite unambiguously the following: For certain cases, such as the PPP bridging protocol when the trailing CRC is forwarded or when any bridging is being applied to protocols not having explicit length fields, adding garbage changes the interpretation of the packet. The self-describing padding option [4] permits unambiguous removal of padded bytes; although it should only be used when absolutely necessary as it may inadvertently require adding as many as 8 octets to packets that could otherwise be left unaltered. Consider a packet, which by unlucky circumstance is already a multiple of 8 octets, but terminates in the sequence 0x1, 0x2. Self-describing padding would otherwise remove the trailing two bytes. For purposes of coexistence with archaic HDLC chips where it is necessary to transmit packets of even length, one would normally only have to add an additional two octets (0x1, 0x2), which could then be removed. However, since the packet was initially a multiple of 8 bytes, an additional 8 bytes would need to be added. How is it "all but impossible" to determine that SDP is required in the case of bridged protocols with CRC? Seems self-evident to me! There was discussion on the list a long time ago proposing padding by multiple leading zeroes in the protocol field. I thought it was a good idea then, and still think so, but the consensus at the time was not to use anything other than that already agreed-to method of padding. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 21:59:53 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA20554; Thu, 19 Dec 1996 21:59:53 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 21:59:53 -0500 (EST) Date: Thu, 19 Dec 1996 18:59:40 -0800 Message-Id: <199612200259.SAA08847@spud.ascend.com> From: Karl Fox To: iana@isi.edu Cc: ietf-ppp@MERIT.EDU Subject: PPP Protocol Assignments for BAP/BACP Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"-kii_2.0.r05.a4Wko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2346 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The IETF PPPEXT Working Group requests that you make the following assignments in the PPP DLL PROTOCOL NUMBERS: 1) Mark 0071 and 8071 as `reserved'. They were assigned to BAP/BACP in a draft that will not advance. 8071 should never be reassigned. 2) Assign two new protocol numbers for BAP and BACP; BAP, being a protocol that controls aspects of the link, should come from the range c001-feff, and BACP, being a Network Control Protocol, should come from the range 8001-beff. Please select these two values such that (BAP-BACP)==0xc000-0x8000, i.e. essentially they should end in the same three digits. The entries should appear as follows, with the X's replaced with the values you assign: 8XXX Bandwidth Allocation Control Protocol [Richards] cXXX Bandwidth Allocation Protocol [Richards] Thank you! -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 22:04:23 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id WAA20649; Thu, 19 Dec 1996 22:04:23 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 22:04:23 -0500 (EST) Date: Thu, 19 Dec 1996 19:04:12 -0800 Message-Id: <199612200304.TAA08879@spud.ascend.com> From: Karl Fox To: "Podi Kuruppu" Cc: ietf-ppp@MERIT.EDU Subject: Callback option In-Reply-To: <199612140103.AA29856@seegiri.NSD.3Com.COM> References: <199612140103.AA29856@seegiri.NSD.3Com.COM> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"CUReT3.0.625.o8Wko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2347 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Podi Kuruppu writes: > Let us say that A calls B and includes the Callback option in his initial Config > Request to B. Let us assume that this Config Request is lost, and > in the meantime, B sends a Config Request _without_ the Authentication > option. When A re-transmits the original Config Request with the > Callback option, B realizes he needs to authenticate A before he can > agree to honor callback request. This would force B to change the > content of the original Config Request to include the authentication > option, which, it seems to me, is not legal. Why would it not be legal? It seems OK to me. Actually, I'd expect most answering systems that would *ever* care about authentication would *always* care about authentication, including it in the first LCP Configure-Request of every dial-in PPP call. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 22:04:28 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id WAA20678; Thu, 19 Dec 1996 22:04:28 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 22:04:28 -0500 (EST) Message-Id: <01BBEDDF.538781A0@ws107.flowpoint.com> From: Philippe Roger To: "ietf-ppp@MERIT.EDU" , "'Keith Sklower'" Subject: RE: purported ambiguity in RFC 1969 Date: Thu, 19 Dec 1996 19:03:30 -0800 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Resent-Message-ID: <"TsK6i2.0.Z25.s8Wko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2348 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Keith, It's interesting to see how different people can interpret the same text differently. I wholeheartedly agree that bridge frames with LAN CRC is an obvious case that requires padding and that this fact is clearly spelled out in RFC1969. The key text to me is: "The self-describing padding option [4] permits unambiguous removal of padded bytes" Where does it say that you MUST use self-described-padding in such a case and HOW the receiver determines whether SPD was used or not ? The section that follow the sentence above describes those rare albeit possible cases where SPD expands the data by an additional 8 bytes (original data was multiple of 8 and ended in the same byte pattern as SPD). This is the reason given for not doing SPD all the time as most protocols, like IP, have their own length field in the PDU, they can be padded with garbage without having to the remove the padding of the clear-text after decrypting it. My statement "all but impossible..." may have been a bit too strong, but by that I meant that *if* SPD is to be negotiated as an option (instead of being mandatory), you can bet that some implementations won't support it and will forward those padded bridged frames (or any other protocols that does not have a length field) with the pad characters, thereby changing the data. As for a "new" method of padding like the 3 bits field we propose, it is (slightly) better than SPD because it does not have the overhead of the extra 8 bytes once in a while and is easier to implement. Furthermore, it only applies in the context of ECP/DES and does not affect anything else. It's too bad that RFC1969 has already reached the status of informational RFC but it would not be the first time that an RFC is obsoleted/improved upon by a newer version (PPP itself is one such instance)... Can you blame me for not following this list (or the ECP/DES topic) "a long time ago" ? Philippe Roger roger@flowpoint.com ---------- From: Keith Sklower[SMTP:sklower@CS.Berkeley.EDU] Sent: Thursday, December 19, 1996 8:21 AM To: ietf-ppp@MERIT.EDU Subject: Re: purported ambiguity in RFC 1969 On Thu, 19 Dec 1996, Philippe Roger wrote: > > At present, this is not my understanding of RFC1969: instead it says that > SDP is an option (defined in reference [4]: i.e. RFC1570). This makes it > all but impossible to have interoperable implementations of ECP/DES when > requiring the decrypted text to match the original clear-text in size. One > such use, as mentioned before, is the transport of bridged frames with > LAN CRC preserved. > However, RFC1969 states quite unambiguously the following: For certain cases, such as the PPP bridging protocol when the trailing CRC is forwarded or when any bridging is being applied to protocols not having explicit length fields, adding garbage changes the interpretation of the packet. The self-describing padding option [4] permits unambiguous removal of padded bytes; although it should only be used when absolutely necessary as it may inadvertently require adding as many as 8 octets to packets that could otherwise be left unaltered. Consider a packet, which by unlucky circumstance is already a multiple of 8 octets, but terminates in the sequence 0x1, 0x2. Self-describing padding would otherwise remove the trailing two bytes. For purposes of coexistence with archaic HDLC chips where it is necessary to transmit packets of even length, one would normally only have to add an additional two octets (0x1, 0x2), which could then be removed. However, since the packet was initially a multiple of 8 bytes, an additional 8 bytes would need to be added. How is it "all but impossible" to determine that SDP is required in the case of bridged protocols with CRC? Seems self-evident to me! There was discussion on the list a long time ago proposing padding by multiple leading zeroes in the protocol field. I thought it was a good idea then, and still think so, but the consensus at the time was not to use anything other than that already agreed-to method of padding. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 19 22:39:04 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id WAA21497; Thu, 19 Dec 1996 22:39:04 -0500 (EST) Resent-Date: Thu, 19 Dec 1996 22:39:04 -0500 (EST) Message-Id: <96Dec19.223833est.30785-1@janus.border.com> To: Mike Thornburg cc: Philippe Roger , "'Karl Fox'" , Philip Rakity , "ietf-ppp@MERIT.EDU" Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question References: In-reply-to: mthorn's message of "Thu, 19 Dec 1996 18:49:11 -0500". From: "C. Harald Koch" Organization: Secure Computing Canada Ltd. Phone: +1 416 813 2054 X-uri: X-Face: )@F:jK?*}hv!eJ}*r*0DD"k8x1.d#i>7`ETe2;hSD2T!:Fh#wu`0pW7lO|Dfe'AbyNy[\Pw z'.bAtgTM!+iq2$yXiv4gf<:D*rZ-|f$\YQi7"D"=CG!JB?[^_7v>8Mm;z:NJ7pss)l__Cw+.>xUJ) did@Pr9 Date: Thu, 19 Dec 1996 22:38:47 -0500 Sender: chk@border.com Resent-Message-ID: <"UHaHL.0.aF5.KfWko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2349 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In message , Mike Thornburg writes: > I'm not enough of a cryptographer to know if the easily-predicted form of > SDP opens you up to any known-cleartext types of attacks, but I'd advise > asking the opinions of experts before requiring SDP in this sort of > situation. I'm not a cryptographer, and I don't play one on TV, but I do implement cryptographic code... The arguments I've seen have gone both ways. Some claim that the padding should be random data, to thwart known-plaintext attacks on the last block (although with CBC this is difficult). Others claim that the ciphers used should be resistant to known-plaintext attacks, and thus the padding should be well-known values; this allows the receiver to verify that the sender is not forgetting to pad. (If the sender forgets to pad, then they could potentially be leaking sensitive data in the padding.) Random padding *requires* a length field somewhere. I'm currently of the opinion that random padding isn't critical, and so I'd go with SDP. However, if you put a length field anywhere, then random padding is better under the "be paranoid" rule in cryptography. [ Yes, I'm undecided >:] -- C. Harald Koch | Senior System Developer, Secure Computing Canada Ltd. chk@border.com | 100 University Ave., 7th Floor, Toronto ON M5J 1V6 +1 416 813 2054 (voice) | "Madness takes its toll. Please have exact change." +1 416 813 2001 (fax) | -Karen Murphy - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 05:40:35 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id FAA24405; Fri, 20 Dec 1996 05:40:35 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 05:40:35 -0500 (EST) From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) To: vandys@cisco.com (Andy Valencia) Cc: Ietf-Ppp@MERIT.EDU (Ietf-ppp) Message-ID: <1996Dec20.083552.1281.341506@eurohub.europe.shiva.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Fri, 20 Dec 1996 10:37:34 GMT Subject: Re: I-D ACTION:draft-ietf-pppext-l2f-03.txt Resent-Message-ID: <"mO-IH2.0.vy5.2qcko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2350 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Andy, >L2TP is the work of merging PPTP and L2F. It was pointed out (repeatedly) >to me that L2F had disappeared off the IETF archives (due to the 6-month >expiration), which made it hard for people to compare the input material to >the output. I had some pending minor markups, so it seemed opportunistic to >submit the text, get the latest/cleanest version out there, and help those >who wanted to view the L2F/PPTP material as well as L2TP. The markups were >done months ago, so pushing this to the secretary is a no-op WRT the >schedule of the next L2TP draft. I agree it is a worthwhile exercise publishing L2F as an RFC but as "Ciscos's L2F". But by leaving in text and retaining numbering which makes it appear to be a PPP WG activity sends a confusing message about L2TP - and seems to be inviting comment/input which can only delay its (L2F's) publication.. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 06:13:19 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id GAA24742; Fri, 20 Dec 1996 06:13:19 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 06:13:19 -0500 (EST) Date: Fri, 20 Dec 96 06:05:00 EST From: "Don Vincent" Message-Id: <9611208510.AA851091237@smtphost.dca.com> To: IETF-PPP@MERIT.EDU Subject: RE: RFC 1968 / RFC1969 (Encryption) Padd Resent-Message-ID: <"5Z2AJ3.0.H26.BJdko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2351 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Bill... Just another snapshot of the DES encryption discussion. Note that it is getting a lot of discussion. I think people are getting interested in this, possibly to use as the encryption method over PPTP/L2F much as we are thinking. Don ---------- From: Ietf-ppp@merit.edu Sent: Thursday, December 19, 1996 9:13PM Subject: RE: RFC 1968 / RFC1969 (Encryption) Padd I understand that some form of padding of the clear-text is needed for the CBC method of DES. As far as the DES algorithm is concerned, any pad data can do. If it is agreed by everyone that SDP is *THE* way to do padding in that context (and I argue that the method we propose is better), then RFC1969 or its replacement, should make it a MUST that the padded data takes the SDP format, although no negotiation of SDP takes place in LCP or ECP, *AS IF THE SDP OPTION HAD BEEN NEGOTIATED WITH A MPV VALUE OF 8*. Note that unless SDP is *ALWAYS* applied, even in cases where it is not strictly needed such as IP (which has a detrimental effect as packets can grow by 8 bytes), a new version of the ECP/DES specification should also specify when the SDP method is applied. For most cases garbage padding is adequate, so how does the receiver know whether garbage padding or SDP was used ? At present, this is not my understanding of RFC1969: instead it says that SDP is an option (defined in reference [4]: i.e. RFC1570). This makes it all but impossible to have interoperable implementations of ECP/DES when requiring the decrypted text to match the original clear-text in size. One such use, as mentioned before, is the transport of bridged frames with LAN CRC preserved. Our suggested alternative: make it mandatory to describe the padding of the clear-text with 3 bits in the type 0x53 ECP/DES packet header. It has no bandwidth overhead (not even the occasional additional 8 bytes) and is trivial to implement. It does not even matter what characters you use for padding: garbage, SDP, nulls, whatever... The pad characters are needed by the decryptor to proceed with the next packet, but the layers above PPP, use the decrypted payloads, do not need to know what the pad characters were, just how many there was. Philippe Roger roger@flowpoint.com ---------- From: C. Harald Koch[SMTP:chk@border.com] Sent: Thursday, December 19, 1996 2:02 PM To: Philippe Roger Cc: 'Karl Fox'; Philip Rakity; ietf-ppp@MERIT.EDU Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question In message <01BBEDA8.ED3E6AC0@ws107.flowpoint.com>, Philippe Roger writes: > > This would make the ECP/DES protocol self-contained and not relying > on an other protocol and would eliminate the need for negotiating SDP > within the ECP protocol. One does not "negotiate" padding for DES; it's required, and pads to a fixed-size boundary. -- C. Harald Koch chk@border.com --------------- End of text item --------------- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 08:52:51 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id IAA26090; Fri, 20 Dec 1996 08:52:51 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 08:52:51 -0500 (EST) Subject: ECP-padding and VanJacobson To: ietf-ppp@MERIT.EDU Date: Fri, 20 Dec 1996 14:55:04 +0100 (MET) From: "Holger Kummert" Reply-To: Holger Kummert X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-ID: <32ba9ab90.6957@gin.conware.de> Content-Transfer-Encoding: 7bit Resent-Message-ID: <"JOLNE2.0.HN6.gefko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2352 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hello, we found another point concerning padding in ECP: When transmitting VJ-compressed TCP/IP-packets, the content of the field "total length" in the IP-Header will be computed on the receiver's site as the sum of the length of the TCP/IP-Header (exactly reconstructed) and the length of the TCP-Data (including ECP-padding). So it's impossible for the receiver to reconstruct the original length of the packet unless someone will tell him (e.g. SDP). rfc1144 says: One can scavenge a few more bytes by noting that any reasonable link-level framing protocol will tell the receiver the length of a received message so total length (bytes 2 and 3) is redundant. So should this be mentioned in a revision of RFC1969, if there will be one? Another question: As Bill Whelan mentioned before, SDP is a link-level option. When it's negotiated and be used in context with ECP, it should be applied _twice_ to the received data: - One time for the received packet/fragment - One time for the unencrypted packet. Is this the intention of SDP? If not I would like an extension of RFC1969 according to Philip Rakity's suggestion. Many thanks, Holger Kummert -- Holger Kummert email: kummert@conware.de Conware Computer Consulting GmbH www: http://www.conware.de/ Killisfeldstrasse 64 Tel.: +49 721 9495-0 D-76227 Karlsruhe/Germany - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 10:48:33 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA28065; Fri, 20 Dec 1996 10:48:33 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 10:48:33 -0500 (EST) From: Jim_Troxel/PA/3Com_at_3COMPO@priacc.com Date: Fri, 20 Dec 96 07:46:00 PST Message-Id: <9611208510.AA851096927@smtplink.priacc.com> To: ietf-ppp@MERIT.EDU Subject: remove Resent-Message-ID: <"6VUlr1.0.Cs6.CLhko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2353 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 11:49:23 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA29845; Fri, 20 Dec 1996 11:49:23 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 11:49:23 -0500 (EST) Date: Fri, 20 Dec 96 11:47:57 EST From: "Whelan, Bill" Message-Id: <9611208511.AA851111331@netx.nei.com> To: ietf-ppp@MERIT.EDU, Holger Kummert Subject: Re: ECP-padding and VanJacobson Resent-Message-ID: <"KhrLL2.0.0I7.EEiko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2354 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Holger Kummert writes: >As Bill Whelan mentioned before, SDP is a link-level option. >When it's negotiated and be used in context with ECP, >it should be applied _twice_ to the received data: >- One time for the received packet/fragment >- One time for the unencrypted packet. Actually, my point was slightly different. If you negotiate SDP through LCP, you are obligated to provide/recognize self described padding on the transmitted/received packet/fragment. The SDP LCP option says nothing (nor should it) about the padding of plain text prior to encryption. Therefore, negotiating SDP through LCP does nothing to solve the problem of how to pad plain text prior to encrypting. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 11:55:35 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA29953; Fri, 20 Dec 1996 11:55:35 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 11:55:35 -0500 (EST) Date: Fri, 20 Dec 96 11:53:11 EST From: Robert Candela Message-Id: <9612201653.AA22110@bac.xyplex.com> To: ietf-ppp@MERIT.EDU Subject: remove Reply-To: rcandela@xyplex.com Resent-Message-ID: <"mOjCS1.0.fJ7.2Kiko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2355 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 12:42:27 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA01630; Fri, 20 Dec 1996 12:42:27 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 12:42:27 -0500 (EST) From: nkrishna@wipro.com (Krishna_Narasimhan) Message-Id: <9612200242.AA23727@taj.wipro.com.wipro.com> Subject: remove To: ietf-ppp@MERIT.EDU Date: Fri, 20 Dec 1996 09:42:13 +0700 (GMT) X-Mailer: ELM [version 2.4 PL21] Content-Type: text Resent-Message-ID: <"QeKWG3.0.9P.-_iko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2356 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 13:01:33 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA02402; Fri, 20 Dec 1996 13:01:33 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 13:01:33 -0500 (EST) Message-Id: <2.2.32.19961220175145.002e0830@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Dec 1996 09:51:45 -0800 To: From: "Eric L. Michelsen" Subject: Re: RFC 1968 / RFC1969 (Encryption) Padding Question Resent-Message-ID: <"zoN4J3.0.6b.uHjko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2357 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 10:38 PM 12/19/96 -0500, C. Harald Koch wrote: >In message , Mike Thornburg writes: ... > Others claim that the ciphers used >should be resistant to known-plaintext attacks, and thus the padding should >be well-known values; As I understand it, an encryption method which gives attackers any useful information given any (realistic) number of plain-text,cyphertext pairs, is considered worthless. I don't believe there is any cryptographic concern about known padding. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 13:02:43 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA02475; Fri, 20 Dec 1996 13:02:43 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 13:02:43 -0500 (EST) Message-Id: <2.2.32.19961220180306.002e0d5c@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Dec 1996 10:03:06 -0800 To: Holger Kummert , ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: ECP-padding and VanJacobson Resent-Message-ID: <"0sepw2.0.Kc.-Ijko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2358 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 02:55 PM 12/20/96 +0100, Holger Kummert wrote: > ... >rfc1144 says: > > One can scavenge a few more bytes by noting that any reasonable > link-level framing protocol will tell the receiver the length of a > received message so total length (bytes 2 and 3) is redundant. > I agree that link-level framing should be able to tell the receiver the message length. Therefore, all modifications to the link-level framing (including things like encryption) should also be required to provide the original message length. The standard service of the link layer, including all its sublayers, should always include both the message and its length. While it may be a little late for some methods, adopting this from now forward will save lots of headaches. As an aside, note that by RFC-1144's definition, Ethernet II is not "reasonable," but IEEE 802.3 is. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 13:03:51 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA02699; Fri, 20 Dec 1996 13:03:51 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 13:03:51 -0500 (EST) Message-Id: <199612201806.AA15675@seegiri.NSD.3Com.COM> To: Karl Fox Cc: "Podi Kuruppu" , ietf-ppp@MERIT.EDU Subject: Re: Callback option Organization: 3Com, 5400 Bayfront Plaza, P.O.Box 58145, Santa Clara, CA 95052 Phone.......: (408) 764-6333 (Office) (415) 969-4400 (General Office) In-Reply-To: Mail from Karl Fox dated Thu, 19 Dec 1996 19:04:12 PST <199612200304.TAA08879@spud.ascend.com> Date: Fri, 20 Dec 1996 10:06:28 -0800 From: "Podi Kuruppu" Resent-Message-ID: <"jbHZ01.0.sf.2Kjko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2359 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >>>>> "KF" == Karl Fox writes: > Podi Kuruppu writes: >> Let us say that A calls B and includes the Callback option in his initial Config >> Request to B. Let us assume that this Config Request is lost, and >> in the meantime, B sends a Config Request _without_ the Authentication >> option. When A re-transmits the original Config Request with the >> Callback option, B realizes he needs to authenticate A before he can >> agree to honor callback request. This would force B to change the >> content of the original Config Request to include the authentication >> option, which, it seems to me, is not legal. > Why would it not be legal? It seems OK to me. From RFC1661: Options The options field is variable in length, and contains the list of zero or more Configuration Options that the sender desires to ---> negotiate. All Configuration Options are always negotiated ---> simultaneously. The format of Configuration Options is further described in a later chapter. Because I interpreted the above line, "...negotiated simultaneously", to mean that all options one needs to have in effect must be present in the first Configure-Request. Since an implementation may not care how a link comes up, by answering or originating a call, the answering side could have sent a Configure-Request without the Authentication Option. And now, after it receives the peer's Configure- Request, it realizes it needs authentication to allow Callback. Two points here: 1) As you point out, if you answer a call, you also care about Authentication regardless of Callback 2) Craig already pointed out that LCP re-negotiation permits what I need to do above. > -- > Karl Fox, servant of God, employee of Ascend Communications > 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 -Podi Kuruppu, podi@nsd.3com.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 13:54:07 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA04834; Fri, 20 Dec 1996 13:54:07 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 13:54:07 -0500 (EST) Message-Id: <2.2.32.19961220185428.002fe7cc@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Dec 1996 10:54:28 -0800 To: "Podi Kuruppu" , Karl Fox From: "Eric L. Michelsen" Subject: Re: Callback option Cc: "Podi Kuruppu" , ietf-ppp@MERIT.EDU Resent-Message-ID: <"DvMQH1.0.DB1.A3kko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2360 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 10:06 AM 12/20/96 -0800, Podi Kuruppu wrote: ... >From RFC1661: > > Options > > The options field is variable in length, and contains the list of > zero or more Configuration Options that the sender desires to >---> negotiate. All Configuration Options are always negotiated >---> simultaneously. The format of Configuration Options is further > described in a later chapter. > >Because I interpreted the above line, "...negotiated simultaneously", >to mean that all options one needs to have in effect must be present >in the first Configure-Request. I interpret that to mean that each Configure-Request stands alone. A peer interprets Configure-Request options without regard to any previous Configure-Requests. But when a peer Naks a Configure-Request, the requestor can try a different request. The new request may be anything at all, with options added or deleted. One negotiation method, then, is for a simple requestor to simply step through a short list of proposals until one is Ack'd. If none are accepted, the link fails. (Of course, the requestor might want to retry the proposals, since any given one may have been corrupted.) -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 14:46:59 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA06389; Fri, 20 Dec 1996 14:46:59 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 14:46:59 -0500 (EST) Date: Fri, 20 Dec 96 19:10:07 GMT From: "William Allen Simpson" Message-ID: <5563.wsimpson@greendragon.com> To: Karl Fox CC: iana@isi.edu Cc: ietf-ppp@MERIT.EDU Subject: Re: PPP Protocol Assignments for BAP/BACP Resent-Message-ID: <"rP1D-2.0.UZ1.jqkko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2361 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Karl Fox > 2) Assign two new protocol numbers for BAP and BACP; BAP, being a > protocol that controls aspects of the link, should come from the > range c001-feff, and BACP, being a Network Control Protocol, > should come from the range 8001-beff. Actually, Karl, BACP is _not_ a Network Control Protocol, as it does not affect any network-layer that I am aware of. I would prefer that both BACP and BAP come from C*** (or D or E or F) -- sequentially would be good. Using 8*** would keep some real network CP from using 0***, reducing efficiency. Please don't. WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson@MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 15:13:32 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA07474; Fri, 20 Dec 1996 15:13:32 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 15:13:32 -0500 (EST) Date: Fri, 20 Dec 1996 12:12:56 -0800 Message-Id: <199612202012.MAA07562@spud.ascend.com> From: Karl Fox To: "Eric L. Michelsen" Cc: "Podi Kuruppu" , ietf-ppp@MERIT.EDU Subject: Re: Callback option In-Reply-To: <2.2.32.19961220185428.002fe7cc@coppermountain.com> References: <2.2.32.19961220185428.002fe7cc@coppermountain.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"mC3yQ3.0.Sq1.dDlko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2362 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Eric L. Michelsen writes: > At 10:06 AM 12/20/96 -0800, Podi Kuruppu wrote: > ... > >From RFC1661: > > > > Options > > > > The options field is variable in length, and contains the list of > > zero or more Configuration Options that the sender desires to > >---> negotiate. All Configuration Options are always negotiated > >---> simultaneously. The format of Configuration Options is further > > described in a later chapter. > > > >Because I interpreted the above line, "...negotiated simultaneously", > >to mean that all options one needs to have in effect must be present > >in the first Configure-Request. > > I interpret that to mean that each Configure-Request stands alone. A peer > interprets Configure-Request options without regard to any previous > Configure-Requests. But when a peer Naks a Configure-Request, the requestor > can try a different request. The new request may be anything at all, with > options added or deleted. Good point. Let's also remember the well established techniques of sending an unsolicited option in a Nak to prompt the peer to include it in the next Configure-Request, plus the alternate CCP negotiation method of sequentially suggesting different compression algorithms. -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 15:41:37 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA08307; Fri, 20 Dec 1996 15:41:37 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 15:41:37 -0500 (EST) Date: Fri, 20 Dec 1996 12:41:14 -0800 Message-Id: <199612202041.MAA08698@spud.ascend.com> From: Karl Fox To: iana@isi.edu Cc: "William Allen Simpson" , ietf-ppp@MERIT.EDU Subject: Re: PPP Protocol Assignments for BAP/BACP In-Reply-To: <5561.wsimpson@greendragon.com> References: <5561.wsimpson@greendragon.com> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"rb_t02.0.O12.xdlko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2363 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Good point, Bill. IANA folks, please forgive me for all this confusion. Please assign BACP and BAP sequential values from the c0ff-feff range. William Allen Simpson writes: > > From: Karl Fox > > 2) Assign two new protocol numbers for BAP and BACP; BAP, being a > > protocol that controls aspects of the link, should come from the > > range c001-feff, and BACP, being a Network Control Protocol, > > should come from the range 8001-beff. > > Actually, Karl, BACP is _not_ a Network Control Protocol, as it does not > affect any network-layer that I am aware of. > > I would prefer that both BACP and BAP come from C*** (or D or E or F) > -- sequentially would be good. > > Using 8*** would keep some real network CP from using 0***, reducing > efficiency. Please don't. > > WSimpson@UMich.edu > Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 > BSimpson@MorningStar.com > Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2 -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 15:55:17 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA08662; Fri, 20 Dec 1996 15:55:17 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 15:55:17 -0500 (EST) Date: Fri, 20 Dec 1996 15:52:50 -0500 (EST) From: John Shriver Message-Id: <199612202052.PAA21554@shiva-dev.shiva.com> To: emichelsen@coppermountain.com CC: kummert@conware.de, ietf-ppp@MERIT.EDU In-reply-to: <2.2.32.19961220180306.002e0d5c@coppermountain.com> (emichelsen@coppermountain.com) Subject: Re: ECP-padding and VanJacobson Resent-Message-ID: <"2JppK.0.q62.lqlko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2364 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Well, as I've noted, PPP historically is a link layer that does NOT preserve length. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 16:22:54 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA09742; Fri, 20 Dec 1996 16:22:54 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 16:22:54 -0500 (EST) Message-Id: <2.2.32.19961220212327.002e0cd8@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Dec 1996 13:23:27 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: ECP-padding and VanJacobson Resent-Message-ID: <"VzgVL3.0.vN2.gEmko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2365 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 03:52 PM 12/20/96 -0500, John Shriver wrote: >Well, as I've noted, PPP historically is a link layer that does NOT >preserve length. > > That's clear, at least for some options. Although it seems that basic RFC-1662 type framing can preserve length. SDP is clearly an attempt to preserve length. My suggestion is that we learn from history, and from now on (to the extent possible given existing standards), define PPP and its extensions specifically to preserve length. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 16:28:51 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA09868; Fri, 20 Dec 1996 16:28:51 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 16:28:51 -0500 (EST) Message-Id: <2.2.32.19961220212925.002e42e4@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 20 Dec 1996 13:29:25 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: PPP in Frame Relay and HDLC Resent-Message-ID: <"ZE2R93.0.tP2.FKmko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2366 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RFC 1973, sec 1 par. 4, says "At one time, it had been hoped that PPP in HDLC-like frames and Frame Relay would co-exist on the same links. Unfortunately, the Q.922 method for expanding the address from 1 to 2 to 4 octets is not indistinguishable from the ISO 3309 method, due to the structure of its Data Link Connection Identifier (DLCI) subfields. Co-existance is precluded." It's not clear to me what the ambiguity is. Can someone clarify this for me? -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 18:22:47 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA13855; Fri, 20 Dec 1996 18:22:47 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 18:22:47 -0500 (EST) From: Jim_Troxel@3mail.3Com.COM X-Lotus-Fromdomain: 3COM To: ietf-ppp@MERIT.EDU Message-Id: <88256406.007E9751.00@hqoutbound.ops.3com.com> Date: Fri, 20 Dec 1996 07:59:29 -0700 Subject: remove Mime-Version: 1.0 Resent-Message-ID: <"Z-xS-3.0.AO3.1_nko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2367 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 19:42:03 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA15032; Fri, 20 Dec 1996 19:42:03 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 19:42:03 -0500 (EST) Message-Id: <199612210041.QAA00743@vandys-lap.cisco.com> X-Authentication-Warning: vandys-lap.cisco.com: Host localhost.cisco.com [127.0.0.1] didn't use HELO protocol To: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) cc: Ietf-Ppp@MERIT.EDU (Ietf-ppp) Subject: Re: I-D ACTION:draft-ietf-pppext-l2f-03.txt In-reply-to: Your message of "Fri, 20 Dec 1996 10:37:34 GMT." <1996Dec20.083552.1281.341506@eurohub.europe.shiva.com> Date: Fri, 20 Dec 1996 16:41:24 -0800 From: Andy Valencia Resent-Message-ID: <"dsqU72.0.Vg3.M9pko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2368 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU [gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) writes:] >I agree it is a worthwhile exercise publishing L2F as an RFC but as "Ciscos's >L2F". It's an "Internet Draft". I always figured that I'd shunt it into an informational state, but perhaps you'd have been happier if that had been sooner rather than later? >But by leaving in text and retaining numbering which makes it appear to be a >PPP >WG activity sends a confusing message about L2TP - and seems to be inviting >comment/input which can only delay its (L2F's) publication.. Er, um, L2TP's publication, right? :-) To that point, please find: ftp://ftp.zendo.com/pub/vandys/draft-ietf-pppext-l2tp-01.02 which is the latest edit of the specification. This has also been submitted to the Internet Drafts editor, so should show up in the usual places presently. This markup reflects as much of the comments from the interim meetings and mailing list comments as I was able to comprehend. :-) Some comments which arrived in the last week are not reflected. The AVP's are now globally numbered; there is still extensive duplication. I have some further detailed comments for Allan and Dory with respect to their outstanding editing work; at their preference I can copy the list or handle closure in private E-mail. Regards, Andy Valencia - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 20 23:48:50 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id XAA17814; Fri, 20 Dec 1996 23:48:50 -0500 (EST) Resent-Date: Fri, 20 Dec 1996 23:48:50 -0500 (EST) From: satish@multitech.com (Satish M. M.) To: ietf-ppp@MERIT.EDU (PPP mailing list) X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Organization: Multi-Tech Systems, Inc. Date: Fri, 20 Dec 1996 22:49:03 -0600 Subject: remove Message-Id: <96Dec20.230250cst.20737@gateway.multitech.com> Resent-Message-ID: <"T23en.0.1M4.gmsko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2369 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Sat Dec 21 10:04:17 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA22141; Sat, 21 Dec 1996 10:04:17 -0500 (EST) Resent-Date: Sat, 21 Dec 1996 10:04:17 -0500 (EST) Message-Id: <199612211501.HAA08761@rs6a.wln.com> From: "Jim Ryan" To: Subject: remove Date: Sat, 21 Dec 1996 07:03:48 -0800 X-MSMail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resent-Message-ID: <"MHME3.0.dP5.Mn_ko"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2370 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 05:44:04 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id FAA06131; Mon, 23 Dec 1996 05:44:04 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 05:44:04 -0500 (EST) Date: Mon, 23 Dec 1996 10:33:21 GMT From: Gerry Meyer Message-Id: <199612231033.KAA21267@orbweb.spider.co.uk> To: vandys@cisco.com Subject: Re: I-D ACTION:draft-ietf-pppext-l2f-03.txt Newsgroups: from.ietf-ppp In-Reply-To: <21Dec9600585312156@crab.spider.co.uk> Organization: Shiva Europe Limited Cc: ietf-ppp@MERIT.EDU Resent-Message-ID: <"7WXwg3.0.OV1.A9clo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2371 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In article <21Dec9600585312156@crab.spider.co.uk> you write: >[gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) writes:] > >>I agree it is a worthwhile exercise publishing L2F as an RFC but as "Ciscos's >>L2F". > >It's an "Internet Draft". I always figured that I'd shunt it into an >informational state, but perhaps you'd have been happier if that had been >sooner rather than later? > >>But by leaving in text and retaining numbering which makes it appear to be a >>PPP >>WG activity sends a confusing message about L2TP - and seems to be inviting >>comment/input which can only delay its (L2F's) publication.. > >Er, um, L2TP's publication, right? :-) I did mean L2F. Though it applies to both. >To that point, please find: > > ftp://ftp.zendo.com/pub/vandys/draft-ietf-pppext-l2tp-01.02 > >which is the latest edit of the specification. This has also been submitted >to the Internet Drafts editor, so should show up in the usual places >presently. This markup reflects as much of the comments from the interim >meetings and mailing list comments as I was able to comprehend. :-) Some >comments which arrived in the last week are not reflected. The AVP's are >now globally numbered; there is still extensive duplication. It is good that a new L2TP draft will be coming out from Internet-Draft in a couple of days. It is a mistake to put it on an FTP site with an identifying name which will be different from the name it will have when issued (draft-ietf-pppext-l2tp-01.txt ??). Will the contents be the same? >I have some further detailed comments for Allan and Dory with respect to >their outstanding editing work; at their preference I can copy the list or >handle closure in private E-mail. > > Regards, > Andy Valencia > Perhaps I'm perhaps not making myself clear. After your initial presentation to the PPP WG on L2F in the spring, the consensus was that a combined effort on L2F and PPTP, namely L2TP, would be worked on in the PPP WG. At that point L2F ceased to be a WG activity. Despite that there IS interest in L2F being published. However it can NOT be a product of the IETF/PPP WG. It can only be "Cisco's L2F" (in the same way that RFC 1934 is Ascend's MP+). I'm trying to encourage you to publish it that way. Gerry - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 12:29:06 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA10784; Mon, 23 Dec 1996 12:29:06 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 12:29:06 -0500 (EST) Date: Mon, 23 Dec 1996 09:34:08 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: ietf-ppp@MERIT.EDU Subject: RFC 1969 DES Encryption Issues Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"6lq2a3.0.7e2.75ilo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2372 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Folks, Let me try to restate the problems as I see them and perhaps some solutions will be possible. 1. DES requires that the clear text be expanded to a multiple of 8 bytes before encryption. Eg The original data is expanded. 2. RFC 1969 does NOT explicitly pass the amount of this padding to the receiver. 3. Some protocols require that the original data size be recovered by the receiver inorder to process correctly the frame. Some examples are bridging and TCP/IP using VJ compression. (Perhaps IPX with header compression is in this catagory. 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. 5. Requesting the use of self described padding during ECPNCP negotiation states that the encrypted text is padded (NOT the plain text before encryption as per point 1. 6. For SDP to work it requires that the receiver receive what the sender believes has been sent. Eg there was no H/W padding of the data when the data was sent. Some folks have given examples of HDLC chips that pad out frame to be an even number of bytes. Since with SDP one looks are the last byte in the frame and checks if it is an SDP character and removes padding accordingly, any artifical pads would make SDP not work. IF my understanding of the issues is correct than for two independent implementations to work an agreement on how cleartext padding is done is required. Possible solutions. 1. Successful negotiation of SDP with ECPNCP implies that the receiver will check for SDP padding in the clear text; it also requires the transmitter to add SDP padding to the clear text before encryption. 2. Make the RFC require that the clear text be expanded using SDP before encryption. eg NO SDP negotiation is required. 3. Add a number of pad byte added byte to the ECP header as per my previous note and require its use. Philip Rakity FlowPoint (408) 364-8300 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 12:50:43 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA11316; Mon, 23 Dec 1996 12:50:43 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 12:50:43 -0500 (EST) Message-Id: <2.2.32.19961223175112.002fd56c@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Dec 1996 09:51:12 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: RFC 1969 DES Encryption Issues Resent-Message-ID: <"KhBOE.0.Vm2.kPilo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2373 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 09:34 AM 12/23/96 -0800, Philip Rakity wrote: > >Folks, ... > >6. For SDP to work it requires that the receiver receive what the sender > believes has been sent. Eg there was no H/W padding of the data when the > data was sent. Some folks have given examples of HDLC chips that pad out > frame to be an even number of bytes. Since with SDP one looks are the > last byte in the frame and checks if it is an SDP character and removes > padding accordingly, any artifical pads would make SDP not work. > I would expect that any software running with such HDLC controllers would be aware of the controller's requirement, and could add SDP to an even number of bytes. > >IF my understanding of the issues is correct than for two independent >implementations to work an agreement on how cleartext padding is done is >required. Yes. > >Possible solutions. > >1. Successful negotiation of SDP with ECPNCP implies that the receiver >will check for SDP padding in the clear text; it also requires the >transmitter to add SDP padding to the clear text before encryption. This seems incomplete: it does not *require* SDP negotiation, nor say what is to be done if SDP is not negotiated. I think it also mixes SDP in an unnatural way with ECP. > >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. This is at least internally consistent and self-contained for ECP. > >3. Add a number of pad byte added byte to the ECP header as per my >previous note and require its use. I think this is the simplest, and therefore best, solution. > > > >Philip Rakity >FlowPoint >(408) 364-8300 > > > > -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 14:01:19 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA12325; Mon, 23 Dec 1996 14:01:19 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 14:01:19 -0500 (EST) Date: Mon, 23 Dec 96 13:59:23 EST From: "Whelan, Bill" Message-Id: <9611238513.AA851378449@netx.nei.com> To: ietf-ppp@MERIT.EDU Subject: Re: RFC 1969 DES Encryption Issues Resent-Message-ID: <"NB_wt2.0.F03.xRjlo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2374 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >IF my understanding of the issues is correct than for two independent >implementations to work an agreement on how cleartext padding is done is >required. > >Possible solutions. > >1. Successful negotiation of SDP with ECPNCP implies that the receiver >will check for SDP padding in the clear text; it also requires the >transmitter to add SDP padding to the clear text before encryption. > This one is clearly wrong. SDP negotiation implies the ciphertext is padded. As you've pointed out, the problem is that the plain text must be padded. >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. This is the best solution. I suspect it was the actual intent of the RFC to "require" such padding in instances when it was needed. Any implementation which currently does this is in compliance with the RFC. > >3. Add a number of pad byte added byte to the ECP header as per my >previous note and require its use. > No, I actually prefer this solution. But anyone implementing it today would be in violation of the existing RFC. > > >Philip Rakity >FlowPoint >(408) 364-8300 > Bill Whelan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 17:20:36 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA14883; Mon, 23 Dec 1996 17:20:36 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 17:20:36 -0500 (EST) Date: Mon, 23 Dec 1996 14:26:08 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: "Whelan, Bill" Cc: ietf-ppp@MERIT.EDU Subject: Re: RFC 1969 DES Encryption Issues In-Reply-To: <9611238513.AA851378449@netx.nei.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"TpsZx2.0.Ee3.kMmlo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2375 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Since the RFC does not completely define all the cases necessary to have independent implemenations really, there should be no problem with implementing either item 2) or 3) below. Item 2) is perhaps better as it keeps the basic format of the packets by simply requiring SDP be the method of padding the clear text, but considering the lack of implementations, I would prefer item 3). In addition, does anyone know if there were any independent implementations running before RFC 1969 was progressed to its current RFC status? Philip Rakity On Mon, 23 Dec 1996, Whelan, Bill wrote: > > >IF my understanding of the issues is correct than for two independent > >implementations to work an agreement on how cleartext padding is done is > >required. > > > >Possible solutions. > > > >1. Successful negotiation of SDP with ECPNCP implies that the receiver > >will check for SDP padding in the clear text; it also requires the > >transmitter to add SDP padding to the clear text before encryption. > > > This one is clearly wrong. SDP negotiation implies the ciphertext is > padded. As you've pointed out, the problem is that the plain text must be > padded. > > >2. Make the RFC require that the clear text be expanded using SDP before > >encryption. eg NO SDP negotiation is required. > > This is the best solution. I suspect it was the actual intent of the RFC > to "require" such padding in instances when it was needed. Any > implementation which currently does this is in compliance with the RFC. > > > >3. Add a number of pad byte added byte to the ECP header as per my > >previous note and require its use. > > > No, I actually prefer this solution. But anyone implementing it today > would be in violation of the existing RFC. > > > > > >Philip Rakity > >FlowPoint > >(408) 364-8300 > > > > Bill Whelan > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 17:26:35 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA14967; Mon, 23 Dec 1996 17:26:35 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 17:26:35 -0500 (EST) Date: Mon, 23 Dec 1996 14:32:07 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: Rob Friend Cc: ietf-ppp@MERIT.EDU Subject: STAC LZS Extended mode question In-Reply-To: <31338780@smtpgateway.stac.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"J3kF-.0.Xf3.MSmlo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2376 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Does anyone know why protocol field compression is explicitly disallowed in extended mode. I can understand why one might not want to do PFC on the frame being compressed, but I cannot understand why the compressed frame must be sent without PFC if it has been negotiated. Eg Why not send 0xFD, itstead of 0x00FD as the PPP protocol Regards, Philip Rakity FlowPoint - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 18:04:49 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA15670; Mon, 23 Dec 1996 18:04:49 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 18:04:49 -0500 (EST) Date: Mon, 23 Dec 1996 15:03:25 -0800 (PST) From: Keith Sklower Message-Id: <199612232303.PAA25819@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU, pmr@flowpoint.com Subject: Re: RFC 1969 DES Encryption Issues Resent-Message-ID: <"x4AzW2.0.Xq3.D0nlo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2377 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU From ietf-ppp-request@MERIT.EDU Mon Dec 23 09:32:27 1996 Resent-Date: Mon, 23 Dec 1996 12:29:06 -0500 (EST) Date: Mon, 23 Dec 1996 09:34:08 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: ietf-ppp@MERIT.EDU Subject: RFC 1969 DES Encryption Issues Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2372 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Folks, Let me try to restate the problems as I see them and perhaps some solutions will be possible. 1. DES requires that the clear text be expanded to a multiple of 8 bytes before encryption. Eg The original data is expanded. Yes. 2. RFC 1969 does NOT explicitly pass the amount of this padding to the receiver. Yes. 3. Some protocols require that the original data size be recovered by the receiver inorder to process correctly the frame. Some examples are bridging If you were bridging 802.3, only then it has a length field. and TCP/IP using VJ compression. (Perhaps IPX with header compression is in this catagory. 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. I disagree. 5. Requesting the use of self described padding during ECPNCP negotiation states that the encrypted text is padded (NOT the plain text before encryption as per point 1. That was not my understanding when I proposed the RFC. 6. For SDP to work it requires that the receiver receive what the sender believes has been sent. Eg there was no H/W padding of the data when the data was sent. Some folks have given examples of HDLC chips that pad out frame to be an even number of bytes. Since with SDP one looks are the last byte in the frame and checks if it is an SDP character and removes padding accordingly, any artifical pads would make SDP not work. The only hardware issues that I was aware of where even/odd. Certainly PFC says you *may* omit the leading 0 but are *not required* to. You can force a PPP packet to be of even length by chosing whether or not to include the leading 0. IF my understanding of the issues is correct than for two independent implementations to work an agreement on how cleartext padding is done is required. Possible solutions. 1. Successful negotiation of SDP with ECPNCP implies that the receiver will check for SDP padding in the clear text; it also requires the transmitter to add SDP padding to the clear text before encryption. This is certainly what I had in mind, and I think that the RFC editor/process should allow clarifications of original intent. 2. Make the RFC require that the clear text be expanded using SDP before encryption. eg NO SDP negotiation is required. I am opposed to this; why should you penalize performance of routers any more in the situations where you don't have to pad -- e.g. you are doing IPCP only over a T1 or T3 line, but you chose to encrypt. 3. Add a number of pad byte added byte to the ECP header as per my previous note and require its use. DESE is not the end-all and be all of encryption protocols. Propose another one, and include your explicit padding byte there. Use triple DES or md5 or whatever you like, but just assign a different code; we've only assigned 2 code points of a possbile 255. Philip Rakity FlowPoint (408) 364-8300 Keith Sklower University of CA, Berkeley (510) 642 9587 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 18:25:22 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA15972; Mon, 23 Dec 1996 18:25:22 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 18:25:22 -0500 (EST) Date: Mon, 23 Dec 96 18:24:09 EST From: "Whelan, Bill" Message-Id: <9611238513.AA851394289@netx.nei.com> To: ietf-ppp@MERIT.EDU, pmr@flowpoint.com Subject: Re[2]: RFC 1969 DES Encryption Issues Resent-Message-ID: <"DSI201.0.Bv3.UJnlo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2378 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. > >I am opposed to this; why should you penalize performance of routers any more >in the situations where you don't have to pad -- e.g. you are doing IPCP only >over a T1 or T3 line, but you chose to encrypt. I don't understand this objection. DES will require padding every time the plain text is not a multiple of eight bytes. The only times SDP would add unneeded padding is when the last byte of the ciphertext could be mistaken for SDP padding (approximately 1 chance in 256). >Keith Sklower >University of CA, Berkeley >(510) 642 9587 Bill Whelan - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 19:07:02 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA16608; Mon, 23 Dec 1996 19:07:02 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 19:07:02 -0500 (EST) Date: Mon, 23 Dec 1996 16:05:37 -0800 (PST) From: Keith Sklower Message-Id: <199612240005.QAA26016@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Resent-Message-ID: <"1a3X11.0.734.Xwnlo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2379 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU PMR wrote: :2. Make the RFC require that the clear text be expanded using SDP before : encryption. eg NO SDP negotiation is required. I wrote: }I am opposed to this; why should you penalize performance of routers any more }in the situations where you don't have to pad -- e.g. you are doing IPCP only }over a T1 or T3 line, but you chose to encrypt. Bill Whelan wrote: :I don't understand this objection. DES will require padding every time the :plain text is not a multiple of eight bytes. The only times SDP would add :unneeded padding is when the last byte of the ciphertext could be mistaken :for SDP padding (approximately 1 chance in 256). To which I respond: First, my intent was that SDP would be applied *before* encrypting. (Having the same model of a link-within-a-link that Multilink uses). so that Bill's statement should be "when the last byte of the plaintext could be mistaken" and the probability is a little more than just 1 in 256; you also have to check for terminating sequences 2 preceded by 1 or ... Thus, when SDP is in effect, you have to do a certain amount of computation per packet, and, in certain cases you have to add 8 more bytes, thus wasting bandwidth. As was asserted by me in the RFC, for a large class of protocols, SDP is wasted effort. If you are transporting vanilla IP packets, padding by garbage or zeroes works fine, because the packets have a built-in length indicator. Likewise for IPX. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 19:37:25 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA17251; Mon, 23 Dec 1996 19:37:25 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 19:37:25 -0500 (EST) Date: Mon, 23 Dec 1996 16:36:01 -0800 (PST) From: Keith Sklower Message-Id: <199612240036.QAA26076@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: Re: DESE context issues Resent-Message-ID: <"WWc8T2.0.DD4.1Nolo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2380 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU PMR wrote: 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. I wrote: I disagree. PMR wrote: Could you explain why you disagree? I think I might be missing something. To which I respond: While the consensus of the PPP comunity seems to be that it shouldn't matter *in which order* various options and protocols are negotiated, the consensus is far less clear that you aren't allowed to take survey after the negotiation process is complete. You can't transmit any encrypted Bridge data packets until both of ECP (with the DESE option) has completed, and the BCP has completed. You can't even negotiate *either* of ECP or BCP until LCP has completed, and SDP is (was) an LCP option. So, if SDP was not negotiated, you could issue a warning at the time the first encrypted bridge packet was sent. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 20:31:38 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA17753; Mon, 23 Dec 1996 20:31:38 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 20:31:38 -0500 (EST) Date: Mon, 23 Dec 1996 17:17:15 -0800 (PST) From: Philip Rakity X-Sender: pmr@royal To: Keith Sklower Cc: ietf-ppp@MERIT.EDU Subject: Re: DESE context issues In-Reply-To: <199612240036.QAA26076@vangogh.CS.Berkeley.EDU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"fQgPQ2.0.4L4.s9plo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2381 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Keith, SDP is allowed to be independently Bnegotiated on each NCP according to the LCP extensions RFC. But the point is mute since SDP is not negotiated in the context of 1969 since the plain text is padded not the encrypted text. The issue I have with the way the RFC as currently defined is that it allows two implementations to NOT work together without bilateral agreement as to whether SDP was applied to the clear text before encryption is applied. Philip Rakity FlowPoint Corporation On Mon, 23 Dec 1996, Keith Sklower wrote: > PMR wrote: > 4. Since the NCPs are negotiated in parallel, ECPNCP does not know > what options have been negotiated by the other NCPs. > > I wrote: > > I disagree. > > > PMR wrote: > > > Could you explain why you disagree? I think I might be missing something. > > To which I respond: > > While the consensus of the PPP comunity seems to be that it shouldn't > matter *in which order* various options and protocols are negotiated, > the consensus is far less clear that you aren't allowed to take survey > after the negotiation process is complete. > > You can't transmit any encrypted Bridge data packets until both of > ECP (with the DESE option) has completed, and the BCP has completed. > > You can't even negotiate *either* of ECP or BCP until LCP has completed, > and SDP is (was) an LCP option. > > So, if SDP was not negotiated, you could issue a warning at the time > the first encrypted bridge packet was sent. > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 20:51:02 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA18017; Mon, 23 Dec 1996 20:51:02 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 20:51:02 -0500 (EST) Date: Mon, 23 Dec 1996 18:50:43 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612240150.SAA15118@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: DESE context issues Resent-Message-ID: <"tKOKf1.0.CP4.1Splo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2382 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Keith Sklower > ... > While the consensus of the PPP comunity seems to be that it shouldn't > matter *in which order* various options and protocols are negotiated, > the consensus is far less clear that you aren't allowed to take survey > after the negotiation process is complete. > > You can't transmit any encrypted Bridge data packets until both of > ECP (with the DESE option) has completed, and the BCP has completed. > > You can't even negotiate *either* of ECP or BCP until LCP has completed, > and SDP is (was) an LCP option. > > So, if SDP was not negotiated, you could issue a warning at the time > the first encrypted bridge packet was sent. There's some truth to that. The various state machines have implicit dependencies. However, if I've understood what has been said, whether SDP is negotiated as an LCP option has nothing to do with any padding of the plaintext before it is encrypted. The padding of the plaintext is to make DES happy. The padding of the cyphertext is satisfy the HDLC hardware on the sending system. SDP as an LCP option would be added by the sender to the cyphertext after it has been encrupted, and removed by the receiver before it is decrypted. There would be no reason to emit a warning for ECP if LCP SDP is or is not negoiated. If you used SDP to pad the plaintext to run it through DES, the resulting cyphertext will have a length 0(mod 8), but it also might end with bytes that look like SDP padding. Thus, you might have - a plaintext of the 8 bytes 01 02 03 04 05 06 07 08 -that is padded by SDP for DES into plaintext 01 02 03 04 05 06 07 08 01 02 03 04 05 06 07 08 - before being encrypted into cyphertext that might be of the form xx xx xx xx xx xx xx xx xx xx xx xx xx xx 01 02 - that is padded into xx xx xx xx xx xx xx xx xx xx xx xx xx xx 01 02 01 02 03 04 05 06 07 08 for LCP and the HDLC hardware. That expansion of 8 plaintext bytes into 24 bytes on the wire should be quite unlikely, and so is not an argument against SDP. I'm pointing this out only to repeat the point that two different and completely independent paddings are at issue. If you had a different encryption scheme, one with a different or variable sized block, you would not need to pad the plaintext before encrypting, but you might still have to pad to satisfy that (I hope by now) mythical and semi-braindead HDLC hardware. And vice versa. ++++ For ECP, why can't you pad the plaintext protocol number with leading zeros? When padding the protocol number with leading zeros was suggested as an alternative for SDP for LCP for braindead HDLC hardware, it was shot down by the claim that such HDLC hardware insists on adding the HDLC header including the protocol number. That objection obviously does not apply to ECP. With any luck, the ECP implementors have learned from the MP implementors, and will tolerate redundant (and non-standard) leading zeros on the encrypted protocol byte. If so, why not pad the protocol byte of the cleartext ECP packets with from 0 to bytes of zeros? That costs less than SDP, and is quicker to compute for both sender and receiver. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 20:56:16 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA18321; Mon, 23 Dec 1996 20:56:16 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 20:56:16 -0500 (EST) Date: Mon, 23 Dec 1996 17:54:51 -0800 (PST) From: Keith Sklower Message-Id: <199612240154.RAA26278@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: Re[2]: DESE context Resent-Message-ID: <"BxmJi2.0.yT4.xWplo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2383 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Philip Rakity writes: SDP is allowed to be independently Bnegotiated on each NCP according to the LCP extensions RFC. But the point is mute since SDP is not negotiated in the context of 1969 since the plain text is padded not the encrypted text. The issue I have with the way the RFC as currently defined is that it allows two implementations to NOT work together without bilateral agreement as to whether SDP was applied to the clear text before encryption is applied. To which I respond: Now it's my turn to say that I don't understand and may be missing something. Could you supply a sample negotation and example packets which have been encoded by one side and decoding by the other in a non-interoperable way? While I admit that I had overlooked the following paragraph in 1570, my interpretation is that not that "SDP is .. independently negotatied on each NCP", but rather SDP is negotiated *ONCE* and each NCP standard specifies whether or not SDP is to be applied to packets in that protocol *if it had been negotiated at the LCP level at all*: Quotation from [Page 8] of RFC 1570, second through fourth paragraphs of section 2.2 under Description: This option is most likely to be used when some protocols, such as network-layer or compression protocols, are configured which require detection and removal of any trailing padding. Such special protocols are identified in their respective documents. If the option is Rejected, the peer MUST NOT add any padding to the identified special protocols, but MAY add padding to other protocols. If the option is Ack'd, the peer MUST follow the procedures for adding self-describing pads, but only to the specifically identified protocols. The peer is not required to add any padding to other protocols. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 21:38:03 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA19115; Mon, 23 Dec 1996 21:38:03 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 21:38:03 -0500 (EST) Message-Id: <2.2.32.19961224023834.00302798@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 23 Dec 1996 18:38:34 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: Re: DESE context issues Resent-Message-ID: <"LiStF.0.Ig4.78qlo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2384 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 05:17 PM 12/23/96 -0800, Philip Rakity wrote: >Keith, > >SDP is allowed to be independently Bnegotiated on each NCP according to the >LCP extensions RFC. I don't see this. RFC-1570 says that SDP is negotiated with LCP, but MUST be provided only to those NCPs which identify themselves as requiring detection and removal of trailing padding. I don't see that you can separately negotiate SDP on each NCP. >... -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Mon Dec 23 21:52:18 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA19464; Mon, 23 Dec 1996 21:52:18 -0500 (EST) Resent-Date: Mon, 23 Dec 1996 21:52:18 -0500 (EST) Date: Mon, 23 Dec 1996 18:50:53 -0800 (PST) From: Keith Sklower Message-Id: <199612240250.SAA26403@vangogh.CS.Berkeley.EDU> To: ietf-ppp@MERIT.EDU Subject: Re: DESE padding, before and after Resent-Message-ID: <"-5yKo3.0.pl4.TLqlo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2385 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Inspired by Vern's contribution, let me see if I can make this all a bit clearer. Revising history a little bit (being previously unaware that there was not a blanket requirement to uniformly pad *all* packets, but only those whose NCP's said that SDP applied to them), what I had intended to say in RFC1969 was: "If any NCP is negotiated on the link which specifies the use of SDP for prevervation of the interpretation of its data packets in the face of padding, then SDP MUST be negotiated as an LCP option, and SDP must be used to pad the plaintext to be a length which is a multiple of 8 bytes as specified in the corresponding NCP spec." The phrase "it should only be used when absolutely necessary", should have been "it should only be negotiated when absolutely necessary". If SDP has been negotiated and multilink has been negotiated, and DESE is encrypting the multilink headers, then SDP removal should only be done on fragments bearing the (E)nd bit, as is specified in the multilink document under Padding considerations there. As far as Vern's observation that we need to concern ourselves not only about the padding of the payload for DESE, but possibly padding the complete DESE "data" packet for hardware considerations (Unless you want to negotiate encrypting for both below and above the multilink arrange mean --- arghghghghghg!!!! ) and as noted in RFC1969, the payload is already a multiple of 8 bytes, so it is pretty easy to acheive even/oddness without the use of SDP. As far as permitting leading zero insertion/removal as a means of padding to 8 bytes - I think its a good idea, and thought it was a good idea back when we were discussing DESE, but don't know what the IETF rules are at this point. DESE is *not* standards track; its merely informational (and was partially intended to be illustrative of how to specify a "bearer" protocol for ECP in the same way that there are many compression "bearer" protocols which use CCP. I don't recall anybody besides flowpoint having reported implementing it... - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 00:28:46 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id AAA20527; Tue, 24 Dec 1996 00:28:46 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 00:28:46 -0500 (EST) Date: Mon, 23 Dec 1996 21:28:33 -0800 Message-Id: <199612240528.VAA03033@spud.ascend.com> From: Karl Fox To: Keith Sklower Cc: ietf-ppp@MERIT.EDU Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues In-Reply-To: <199612240005.QAA26016@vangogh.CS.Berkeley.EDU> References: <199612240005.QAA26016@vangogh.CS.Berkeley.EDU> Reply-To: Karl Fox Organization: Ascend Communications Resent-Message-ID: <"uyJ3T1.0.Q05.9eslo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2386 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Keith Sklower writes: > First, my intent was that SDP would be applied *before* encrypting. > (Having the same model of a link-within-a-link that Multilink uses). > so that Bill's statement should be > "when the last byte of the plaintext could be mistaken" > > and the probability is a little more than just 1 in 256; you also have to > check for terminating sequences 2 preceded by 1 or ... All you have to do is check if the last byte is between 1 and 8, inclusive (see RFC 1570 section 2.2). -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 10:29:33 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA24246; Tue, 24 Dec 1996 10:29:33 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 10:29:33 -0500 (EST) From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) To: sklower@cs.berkeley.edu (Keith Sklower) Cc: Ietf-Ppp@MERIT.EDU (Ietf-Ppp) Message-ID: <1996Dec24.142534.1281.343716@eurohub.europe.shiva.com> X-Conversion-ID: X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Date: Tue, 24 Dec 1996 15:26:57 GMT Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Resent-Message-ID: <"t4Uz-2.0.Xw5.1R_lo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2387 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU >As was asserted by me in the RFC, for a large class of protocols, >SDP is wasted effort. If you are transporting vanilla IP packets, >padding by garbage or zeroes works fine, because the packets have >a built-in length indicator. Likewise for IPX. I must admit when we wrote the DESE RFC, never having come across hardware which required SDP, I didn't think that SDP would in practise be required within DESE. S o I didn't think a great deal about it at the time. In my view the problem with SDP is that it is ill-defined as to which packets it should be applied/removed ; and you have to negotiate it before you know if you will need it. In short, I don't like it. I am coming round (belatedly) to the technique of prepending sufficient zeros (prior to encryption) to complete a cypher block and to ensure that the length can be unambiguously determined. This is a simple, effective, unambiguous, no-brainer way of fixing the length of a packet - and at no additioanl cost in terms of packet length.. Does anyone object to this technique now? Gerry - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 10:41:31 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA24388; Tue, 24 Dec 1996 10:41:31 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 10:41:31 -0500 (EST) 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-l2tp-01.txt Date: Tue, 24 Dec 1996 09:47:13 -0500 Sender: cclark@ietf.org Message-ID: <9612240947.aa07207@ietf.org> Resent-Message-ID: <"WFEPR3.0.hy5.dc_lo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2388 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU --NextPart A Revised 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 : Layer Two Tunneling Protocol "L2TP" Author(s) : K. Hamzeh, T. Kolar, M. Littlewood, G. Pall, J. Taarud, A. Valencia, W. Verthein Filename : draft-ietf-pppext-l2tp-01.txt Pages : 75 Date : 12/23/1996 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. Internet-Drafts are 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-l2tp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19961223135209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961223135209.I-D@ietf.org> --OtherAccess-- --NextPart-- - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 11:30:34 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA25276; Tue, 24 Dec 1996 11:30:34 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 11:30:34 -0500 (EST) Date: Tue, 24 Dec 1996 09:30:20 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612241630.JAA16311@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Resent-Message-ID: <"FrhZ01.0.dA6.cK0mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2389 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) > ... > I am coming round (belatedly) to the technique of prepending sufficient zeros > (prior to > encryption) to complete a cypher block and to ensure that the length can be > unambiguously > determined. This is a simple, effective, unambiguous, no-brainer way of > fixing the length of > a packet - and at no additioanl cost in terms of packet length.. > l.. Do you mean the hack--er, technique of extending the "inner" PPP protocol number with leading zeros? Besides being optimally dense (using exactly the minimal padding) and denser than self-describing padding, that technique has a major non-technical advantage. It prevents confusion among implementors and users between the SDP required by DES and inside the encryption from the other SDP that can simultaneously be present outside the encryption to cater to the (I hope) mythical braindead HDLC chips. The DES padding would be of zeros, while the LCP padding would be SDP. What is the overall size of an ECP data packet? The info field has a length of 0(mod 8) thanks to the DES block size. If address, control, and protocol field compressions are negotiated by LCP, then I think the HDLC packet will have a length of 3(mod 8) (counting the FCS) and so require SDP. But I suppose the braindead HDLC chips that require SDP did not do handle address and control filed compression, making the length 5(mod 8)--assuming they did protocol field compression. Did they? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 13:42:06 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA27185; Tue, 24 Dec 1996 13:42:06 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 13:42:06 -0500 (EST) Date: Tue, 24 Dec 1996 10:27:40 -0800 (PST) From: Philip Rakity X-Sender: pmr@royal To: sklower@cs.berkeley.edu Cc: ietf-ppp@MERIT.EDU Subject: Real life ECP example Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"cDWbQ.0.Se6.wF2mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2390 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU The real life example comes from our testing with Holger using encryption with TCP/IP and VJ compression (No CCP). Neither of us were able to get telnet to receive the correct data either when talking with ourselves or with each other. See below for the explanation. Concerning SDP negotiation, the implemenation note in section 2.2 states that "To avoid unnecessary configuration handshakes, an implementation which generates padding, and has a protocol configured which requires padding to be known, SHOULD include this option in its Configuration-Request, and SHOULD Configure-Nak with this Option when it is not present in the peer's Request." I took this to mean that SDP was negotiated on each NCP that required it (no need to do LCP negotiation). Is the rule for using SDP the following. 1. Negotiate its general availability using LCP. 2. Negotiate the specific protocols that use SDP on each NCP Philip Rakity FlowPoint ---------- Forwarded message ---------- Date: Fri, 20 Dec 1996 14:55:04 +0100 (MET) From: Holger Kummert To: ietf-ppp@MERIT.EDU Subject: ECP-padding and VanJacobson Hello, we found another point concerning padding in ECP: When transmitting VJ-compressed TCP/IP-packets, the content of the field "total length" in the IP-Header will be computed on the receiver's site as the sum of the length of the TCP/IP-Header (exactly reconstructed) and the length of the TCP-Data (including ECP-padding). So it's impossible for the receiver to reconstruct the original length of the packet unless someone will tell him (e.g. SDP). rfc1144 says: One can scavenge a few more bytes by noting that any reasonable link-level framing protocol will tell the receiver the length of a received message so total length (bytes 2 and 3) is redundant. So should this be mentioned in a revision of RFC1969, if there will be one? Another question: As Bill Whelan mentioned before, SDP is a link-level option. When it's negotiated and be used in context with ECP, it should be applied _twice_ to the received data: - One time for the received packet/fragment - One time for the unencrypted packet. Is this the intention of SDP? If not I would like an extension of RFC1969 according to Philip Rakity's suggestion. Many thanks, Holger Kummert -- Holger Kummert email: kummert@conware.de Conware Computer Consulting GmbH www: http://www.conware.de/ Killisfeldstrasse 64 Tel.: +49 721 9495-0 D-76227 Karlsruhe/Germany - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 15:13:50 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA28426; Tue, 24 Dec 1996 15:13:50 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 15:13:50 -0500 (EST) Date: Tue, 24 Dec 1996 10:32:42 -0800 (PST) From: Philip Rakity X-Sender: pmr@royal To: CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva Cc: Keith Sklower , Ietf-Ppp Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues In-Reply-To: <1996Dec24.142534.1281.343716@eurohub.europe.shiva.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"x_-eA3.0.rx6.wb3mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2391 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU I like this method of prepending 0's to the protocol field before encryption to ensure the size is a multiple of 8. However, the STAC LZS RFC explicitly states that the protocol field is 2 bytes (0x00FD) long when option 4 (extended mode) has been negotiated. Eg I cannot remove one of the bytes of get to a multiple of 8. Philip Rakity FlowPoint On Tue, 24 Dec 1996, CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva wrote: > >As was asserted by me in the RFC, for a large class of protocols, > >SDP is wasted effort. If you are transporting vanilla IP packets, > >padding by garbage or zeroes works fine, because the packets have > >a built-in length indicator. Likewise for IPX. > > I must admit when we wrote the DESE RFC, never having come across hardware > which required SDP, I didn't think that SDP would in practise be required > within DESE. > S o I didn't think a great deal about it at the time. > In my view the problem with SDP is that it is ill-defined as to which packets > it should be > applied/removed ; and you have to negotiate it before you know if you will > need it. > In short, I don't like it. > > I am coming round (belatedly) to the technique of prepending sufficient zeros > (prior to > encryption) to complete a cypher block and to ensure that the length can be > unambiguously > determined. This is a simple, effective, unambiguous, no-brainer way of > fixing the length of > a packet - and at no additioanl cost in terms of packet length.. > > Does anyone object to this technique now? > > Gerry > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 15:22:19 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA28517; Tue, 24 Dec 1996 15:22:19 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 15:22:19 -0500 (EST) Date: Tue, 24 Dec 1996 13:22:03 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612242022.NAA17560@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: Real life ECP example Resent-Message-ID: <"o31aE2.0.Cz6.tj3mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2392 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Philip Rakity > ... > Concerning SDP negotiation, the implemenation note in section 2.2 states > that > > "To avoid unnecessary configuration handshakes, an implementation which > generates padding, and has a protocol configured which requires padding > to be known, SHOULD include this option in its Configuration-Request, and > SHOULD Configure-Nak with this Option when it is not present in the > peer's Request." > > I took this to mean that SDP was negotiated on each NCP that required > it (no need to do LCP negotiation). I do not understand that reasoning. How do you negotiate SDP on an NCP? > Is the rule for using SDP the following. > > 1. Negotiate its general availability using LCP. > 2. Negotiate the specific protocols that use SDP on each NCP #1 makes sense. I do not understand #2. How can you negotiate SDP for a single NCP? You cannot put the SDP option into a Configure-Request for any NCP. You can put the SDP option into <<>> an LCP Configure-Request. After the Configure-Ack for SDP, how would either PPP peer know which NCP needs SDP and which does not? > ... > As Bill Whelan mentioned before, SDP is a link-level option. > When it's negotiated and be used in context with ECP, > it should be applied _twice_ to the received data: > - One time for the received packet/fragment > - One time for the unencrypted packet. How can there be any alternative, given a cypher with a fixed block size of 8 and data without its own length? Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 15:39:27 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA28643; Tue, 24 Dec 1996 15:39:27 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 15:39:27 -0500 (EST) Date: Tue, 24 Dec 1996 13:39:12 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612242039.NAA17611@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Resent-Message-ID: <"i1Jkn1.0.B_6.wz3mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2393 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Philip Rakity > I like this method of prepending 0's to the protocol field before > encryption to ensure the size is a multiple of 8. However, the STAC LZS > RFC explicitly states that the protocol field is 2 bytes (0x00FD) long > when option 4 (extended mode) has been negotiated. Eg I cannot remove > one of the bytes of get to a multiple of 8. So what? Why would you want to pad the bits inside STAC LZS type 4? I get irritated with people blindly following the layering religion, but this is a case when layering must be considered. There are three protocol fields: 1. The outer-most protocol field specifies ECP. The size of this protocol field is <<>> specified by ECP nor by LZS. The size of this protocol field is determined only from the LCP negotiation. No matter what ECP and/or LZS want or say, the LCP protocol field is beyond their ken. 2. The middle protocol field tells ECP the protocol of the inner-most protocol. This protocol is 0xfd when compression is being used. The size of this protocol field is determined ONLY by the ECP standard. Neither LZS nor LCP have anything to say about the size of this protocol field. 3. The innermost protocol filed tells LZS the protocol of the real data. This size of this protocol field is determined by the LZS CCP standard. LCP and ECP have nothing to say about the size of this protocol field. You must pad #1 or use SDP if and only if your HDLC hardware is braindead, regardless of whether you are using LZS and/or ECP. If you do not have stupid HDLC hardware, there is no reason to pad #2 or #3. #3 has nothing to do ECP. LZS must figure out the correct length of VJ-header compressed packets before delivering them to the VJ-decompressor regardless of whether you are using ECP #2 is the only protocol field at issue. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 17:26:50 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA29411; Tue, 24 Dec 1996 17:26:50 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 17:26:50 -0500 (EST) Date: Tue, 24 Dec 1996 14:32:20 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: Vernon Schryver Cc: ietf-ppp@MERIT.EDU Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues In-Reply-To: <199612242039.NAA17611@mica.denver.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"QRmIj2.0.AB7.YY5mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2394 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Sorry about the incomplete paraphrase of the STAC LZS RFC. To be exact, the statement is (section 5.1) When a compression protocol is successfully negotiated by the PPP compression control protocol, the value is hex 00FD. Protocol field compression MUST NOT be used on this value when extended mode is negotiated on the link, even if protocol field compression was successfully negotiated before data compression. From this statement, I take it that I must pass to the decompressor code a 2 byte protocol id of 0x00FD, whether or not I have been using ECP. Similarly, I must send these two bytes inside the ECP packet since I would have sent these bytes on the wire if ECP was not negotiated. I believe that the requirement in the RFC to ignore PFC negotation rules is a bad choice, but my opinion is NOT what is in the STAC LZS RFC. See below for responses. Philip Rakity FlowPoint On Tue, 24 Dec 1996, Vernon Schryver wrote: > > From: Philip Rakity > > > I like this method of prepending 0's to the protocol field before > > encryption to ensure the size is a multiple of 8. However, the STAC LZS > > RFC explicitly states that the protocol field is 2 bytes (0x00FD) long > > when option 4 (extended mode) has been negotiated. Eg I cannot remove > > one of the bytes of get to a multiple of 8. > > So what? Why would you want to pad the bits inside STAC LZS type 4? Since the cleartext must be a multiple of 8 bytes for DES encryption to work, the cleartext must be padded. It can be padded at the end using SDP or as was suggested by someone else, it could be padded in the front by prepending 0's to the protocol value. If the cleartext was 1 byte too long for DES encryption and the protocol being encrypted was CCP LZS, than one could remove the 00 byte from the protocol id (0x00FD), however this is NOT allowed according to the RFC if extended mode was negotiated. > > I get irritated with people blindly following the layering religion, > but this is a case when layering must be considered. > > There are three protocol fields: > > 1. The outer-most protocol field specifies ECP. > The size of this protocol field is <<>> specified by ECP > nor by LZS. The size of this protocol field is determined only > from the LCP negotiation. No matter what ECP and/or LZS want > or say, the LCP protocol field is beyond their ken. Really? Is the STAC LZS RFC wrong in saying that PFC does not apply. > > 2. The middle protocol field tells ECP the protocol of the inner-most > protocol. This protocol is 0xfd when compression is being used. > The size of this protocol field is determined ONLY by the ECP > standard. Neither LZS nor LCP have anything to say about the size > of this protocol field. If PFC was not negotiated implicitly or explicitly, I thought that it was NOT allowed to apply PFC. Where in the RFCs does it say you can PFC compress protocol id's when PFC was not negotiated. Note: A reasonable implemenation should ALWAYS be able to decode PFC, but I am taking about what the RFC says, not what is reasonable. PPP requires PFC be negotiated, while MLP implies that it has been implicitly agreed to. > > 3. The innermost protocol filed tells LZS the protocol of the real > data. This size of this protocol field is determined by the LZS > CCP standard. LCP and ECP have nothing to say about the size of > this protocol field. > > You must pad #1 or use SDP if and only if your HDLC hardware is > braindead, regardless of whether you are using LZS and/or ECP. If you > do not have stupid HDLC hardware, there is no reason to pad #2 or #3. > > #3 has nothing to do ECP. LZS must figure out the correct length of > VJ-header compressed packets before delivering them to the VJ-decompressor > regardless of whether you are using ECP > > #2 is the only protocol field at issue. > We agree. > > Vernon Schryver, vjs@sgi.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 17:31:37 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA29777; Tue, 24 Dec 1996 17:31:37 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 17:31:37 -0500 (EST) Date: Tue, 24 Dec 1996 14:37:08 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: Vernon Schryver Cc: ietf-ppp@MERIT.EDU Subject: re: Real life ECP example In-Reply-To: <199612242022.NAA17560@mica.denver.sgi.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"4BxtT2.0.vG7.4d5mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2395 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU One can add to the configure request the option for SDP. Eg Option 10, length 3. as per the LCP extensions RFC, thus informing the remote that one is able to receive SDP. I do not understand how one implements the statement I quoted from the RFC below unless one sends the request for SDP on each NCP that needs it. So, Exactly how does one negotiate SDP on a per protocol basis ??? Philip Rakity FlowPoint On Tue, 24 Dec 1996, Vernon Schryver wrote: > > From: Philip Rakity > > > ... > > Concerning SDP negotiation, the implemenation note in section 2.2 states > > that > > > > "To avoid unnecessary configuration handshakes, an implementation which > > generates padding, and has a protocol configured which requires padding > > to be known, SHOULD include this option in its Configuration-Request, and > > SHOULD Configure-Nak with this Option when it is not present in the > > peer's Request." > > > > I took this to mean that SDP was negotiated on each NCP that required > > it (no need to do LCP negotiation). > > I do not understand that reasoning. > How do you negotiate SDP on an NCP? > > > > Is the rule for using SDP the following. > > > > 1. Negotiate its general availability using LCP. > > 2. Negotiate the specific protocols that use SDP on each NCP > > #1 makes sense. > > I do not understand #2. How can you negotiate SDP for a single NCP? > You cannot put the SDP option into a Configure-Request for any NCP. > You can put the SDP option into <<>> an LCP Configure-Request. > After the Configure-Ack for SDP, how would either PPP peer know which > NCP needs SDP and which does not? > > > > ... > > As Bill Whelan mentioned before, SDP is a link-level option. > > When it's negotiated and be used in context with ECP, > > it should be applied _twice_ to the received data: > > - One time for the received packet/fragment > > - One time for the unencrypted packet. > > How can there be any alternative, given a cypher with a fixed block > size of 8 and data without its own length? > > > Vernon Schryver, vjs@sgi.com > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 17:51:59 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA00199; Tue, 24 Dec 1996 17:51:59 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 17:51:59 -0500 (EST) Date: Tue, 24 Dec 1996 15:51:44 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612242251.PAA18099@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Resent-Message-ID: <"Ux5B83.0.o2.Bw5mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2396 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Philip Rakity > Sorry about the incomplete paraphrase of the STAC LZS RFC. To be exact, > the statement is (section 5.1) > > When a compression protocol is successfully negotiated by the PPP > compression control protocol, the value is hex 00FD. Protocol field > compression MUST NOT be used on this value when extended mode is > negotiated on the link, even if protocol field compression was > successfully negotiated before data compression. > > >From this statement, I take it that I must pass to the decompressor code > a 2 byte protocol id of 0x00FD, whether or not I have been using ECP. > Similarly, I must send these two bytes inside the ECP packet since I > would have sent these bytes on the wire if ECP was not negotiated. > > I believe that the requirement in the RFC to ignore PFC negotation rules > is a bad choice, but my opinion is NOT what is in the STAC LZS RFC. > ... Instead of that, I hope that the LZS RFC wording is muddled, that it is refering to both protocol fields in that quoted paragraph, that the first sentence says the protocol number in the 1st byte or bytes after the address and control fields (if any) that begin the packet are 0x00fd or 0xfd, while the second protocol field after the Coherency Count is always two bytes. That hope is consistent with the penultimate sentence in section 5.1 of RFC 1974 which is clearly talking about the inner protocol number. See also sections 2 and 2.5.1 that say the 0x00fd can be compressed to 0xfd. On the other hand, I vaguely seem to recall talk about limitations in early versions of Stac Electronics hardware couldn't handle some alignments or maybe it was protocol field compression. Isn't Type 4 or Extended mode the old, deprecated version? Isn't Type 3 the required mode, and because of sections 2 and 2.5.1 of RFC 1974, 0xfd compressable if and only if LCP says it is? > ... > > 2. The middle protocol field tells ECP the protocol of the inner-most > > protocol. This protocol is 0xfd when compression is being used. > > The size of this protocol field is determined ONLY by the ECP > > standard. Neither LZS nor LCP have anything to say about the size > > of this protocol field. > > If PFC was not negotiated implicitly or explicitly, I thought that it was > NOT allowed to apply PFC. Where in the RFCs does it say you can PFC > compress protocol id's when PFC was not negotiated. Note: A reasonable > implemenation should ALWAYS be able to decode PFC, but I am taking about > what the RFC says, not what is reasonable. PPP requires PFC be > negotiated, while MLP implies that it has been implicitly agreed to. I did not say that protocol field compression can be done willy-nilly, but that how the 0xfd of LZS is handled is not a matter for LCP to determine. Just as with MP (RFC 1717), whether address, control, and protocol field compression is negoiated with LCP Configure-Requests is irrelevant to what happens elsewhere. LCP Configure-Requests control the first 1-4 bytes of the packet on the wire. Other bytes are controlled otherwise. (Yes, I know of the suggestion that to preserve byte alignment and reduce implementor confusion, the inner protocol field of MP packets should be padded with zeros depending on whether LCP protocol field compression has not been negotiated.) Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 18:02:19 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA00473; Tue, 24 Dec 1996 18:02:19 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 18:02:19 -0500 (EST) Date: Tue, 24 Dec 1996 16:02:05 -0700 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199612242302.QAA18152@mica.denver.sgi.com> To: ietf-ppp@MERIT.EDU Subject: re: Real life ECP example Resent-Message-ID: <"scMLa2.0.47.t36mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2397 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU > From: Philip Rakity > One can add to the configure request the option for SDP. > > Eg Option 10, length 3. as per the LCP extensions RFC, thus informing the > remote that one is able to receive SDP. I do not understand those words. To what Configure-Request are you adding the SDP option? If you are adding to an LCP Configure-Request, then what does it have to do with any single NCP? (Nothing, by my lights.) > I do not understand how one implements the statement I quoted from the > RFC below unless one sends the request for SDP on each NCP that needs it. > > So, > > Exactly how does one negotiate SDP on a per protocol basis ??? You do not negotiate SDP on a per protocol basis, because by design it cannot be done. > ... > > > Concerning SDP negotiation, the implemenation note in section 2.2 states > > > that > > > > > > "To avoid unnecessary configuration handshakes, an implementation which > > > generates padding, and has a protocol configured which requires padding > > > to be known, SHOULD include this option in its Configuration-Request, and > > > SHOULD Configure-Nak with this Option when it is not present in the > > > peer's Request." > > > > > > I took this to mean that SDP was negotiated on each NCP that required > > > it (no need to do LCP negotiation). There is nothing in those words that say or suggest anything about negotiating SDP on a per protocol basis. Those words say you SHOULD turn on SDP if you might need it. They don't say you should turn it on partially if you need it only partially. I think the rest of us take RFC 1570 to be about LCP extensions instead of network protocols, and to be saying "If your HDLC hardware is braindead and requires padding, and if your system anticipates sending any network protocols that lack their own lengths (e.g.bly bridging and IP with VJ-header compression), then you SHOULD cause your LCP code to negotiate self-describing padding for all PPP packets (of course with the usual exceptions--control packets which may or may not be padded at the sender's whim)." I think the rest of us would also agree that you MAY renegoiate SDP on or off if your anticipations turn out to be wrong, but that renegotiating anything with LCP tends to stumble on broken PPP implementations. Vernon Schryver, vjs@sgi.com - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 19:36:10 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA01014; Tue, 24 Dec 1996 19:36:10 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 19:36:10 -0500 (EST) Message-Id: <2.2.32.19961225003645.002fcd90@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 24 Dec 1996 16:36:45 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: re: Real life ECP example Resent-Message-ID: <"ZogfI1.0.TF.rR7mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2398 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU SDP is negotiated with LCP, and only LCP, per RFC-1570. I think some confusion may arise, though, because of the wording of sec 2.2, par 2: "This option is most likely to be used when some protocols, such as network-layer or compression protocols, are configured which require detection and removal of any trailing padding. SUCH SPECIAL PROTOCOLS ARE IDENTIFIED IN THEIR RESPECTIVE DOCUMENTS." (Emphasis added). I take this to mean that any protocol which requires information field length preservation must say so in its defining RFC. Bridging Control Protocol (RFC-1638) makes a passing reference to SDP (sec 4.2, subsec "Optional Data Link Layer Padding", par 2), but if you blink you might miss it. So RFC-1570 defines a "special protocol" as one requiring length preservation. Then sec 2.2, par 4 says that an implementation "MUST follow the procedures for adding self-describing pads, but only to the specifically identified [i.e., "special"] protocols. The [implementation] is not required to add any padding to other protocols." So one doesn't negotiate SDP for each NCP, but if negotiated, one MUST use SDP only on "special" protocols. On other protocols, you are free to not pad, regardless of whether SDP was negotiated. This whole concept seems like a subtle point, buried in RFC-1570, and often forgotten when other NCP RFCs are written. Even BCP's reference to SDP is fairly terse, and easily missed. I haven't checked the CCP or ECP specs to see if they identify themselves as "special" in the RFC-1570 sense. -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 24 21:17:46 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA01434; Tue, 24 Dec 1996 21:17:46 -0500 (EST) Resent-Date: Tue, 24 Dec 1996 21:17:46 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250217.DAA22985@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 03:17:14 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"tiimU.0.5M.5x8mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2399 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2082D27A24DEC199602091431 UA content ID: Re[2]: DESE context Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 02:09 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2082D27A24DEC199602091431 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[2]: DESE context Precedence: 1 To: WATERS@AM_MARVIN Philip Rakity writes: SDP is allowed to be independently Bnegotiated on each NCP according to the LCP extensions RFC. But the point is mute since SDP is not negotiated in the context of 1969 since the plain text is padded not the encrypted text. The issue I have with the way the RFC as currently defined is that it allows two implementations to NOT work together without bilateral agreement as to whether SDP was applied to the clear text before encryption is applied. To which I respond: Now it's my turn to say that I don't understand and may be missing something. Could you supply a sample negotation and example packets which have been encoded by one side and decoding by the other in a non-interoperable way? While I admit that I had overlooked the following paragraph in 1570, my interpretation is that not that "SDP is .. independently negotatied on each NCP", but rather SDP is negotiated *ONCE* and each NCP standard specifies whether or not SDP is to be applied to packets in that protocol *if it had been negotiated at the LCP level at all*: Quotation from [Page 8] of RFC 1570, second through fourth paragraphs of section 2.2 under Description: This option is most likely to be used when some protocols, such as network-layer or compression protocols, are configured which require detection and removal of any trailing padding. Such special protocols are identified in their respective documents. If the option is Rejected, the peer MUST NOT add any padding to the identified special protocols, but MAY add padding to other protocols. If the option is Ack'd, the peer MUST follow the procedures for adding self-describing pads, but only to the specifically identified protocols. The peer is not required to add any padding to other protocols. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA08005 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:08:49 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA24791 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:10:58 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id DAA02136 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:12:03 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA18305; Mon, 23 Dec 1996 20:56:12 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 20:56:12 -0500 (EST) % Date: Mon, 23 Dec 1996 17:54:51 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240154.RAA26278@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re[2]: DESE context % Resent-Message-ID: <"BxmJi2.0.yT4.xWplo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2383 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:06:02 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02679; Wed, 25 Dec 1996 02:06:02 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:06:02 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250705.IAA00701@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:05:31 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"oIJ0r.0.Yf.L9Dmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2400 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20820CE024DEC199602520368 UA content ID: Re: DESE context issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 02:52 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20820CE024DEC199602520368 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE context issues Precedence: 1 To: WATERS@AM_MARVIN At 05:17 PM 12/23/96 -0800, Philip Rakity wrote: >Keith, > >SDP is allowed to be independently Bnegotiated on each NCP according to the >LCP extensions RFC. I don't see this. RFC-1570 says that SDP is negotiated with LCP, but MUST be provided only to those NCPs which identify themselves as requiring detection and removal of trailing padding. I don't see that you can separately negotiate SDP on each NCP. >... -- Eric L. Michelsen, Copper Mountain Networks, Inc. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA08950 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:51:38 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA26944 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:53:47 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id DAA00976 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:54:52 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA19099; Mon, 23 Dec 1996 21:38:00 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 21:38:00 -0500 (EST) % Message-Id: <2.2.32.19961224023834.00302798@coppermountain.com> % X-Sender: "Eric Michelsen" % X-Mailer: Windows Eudora Pro Version 2.2 (32) % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Mon, 23 Dec 1996 18:38:34 -0800 % To: ietf-ppp@MERIT.EDU % From: "Eric L. Michelsen" % Subject: Re: DESE context issues % Resent-Message-ID: <"LiStF.0.Ig4.78qlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2384 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:06:29 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02717; Wed, 25 Dec 1996 02:06:29 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:06:29 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250705.IAA00731@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:05:57 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"ed0fh2.0.8g.l9Dmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2401 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20820CE024DEC199602591842 UA content ID: Re: DESE context issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 02:59 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20820CE024DEC199602591842 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE context issues Precedence: 1 To: WATERS@AM_MARVIN PMR wrote: 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. I wrote: I disagree. PMR wrote: Could you explain why you disagree? I think I might be missing something. To which I respond: While the consensus of the PPP comunity seems to be that it shouldn't matter *in which order* various options and protocols are negotiated, the consensus is far less clear that you aren't allowed to take survey after the negotiation process is complete. You can't transmit any encrypted Bridge data packets until both of ECP (with the DESE option) has completed, and the BCP has completed. You can't even negotiate *either* of ECP or BCP until LCP has completed, and SDP is (was) an LCP option. So, if SDP was not negotiated, you could issue a warning at the time the first encrypted bridge packet was sent. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA09211 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:58:44 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA22203 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:52:21 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id BAA13000 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:53:26 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA17234; Mon, 23 Dec 1996 19:37:22 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 19:37:22 -0500 (EST) % Date: Mon, 23 Dec 1996 16:36:01 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240036.QAA26076@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re: DESE context issues % Resent-Message-ID: <"WWc8T2.0.DD4.1Nolo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2380 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:06:51 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02786; Wed, 25 Dec 1996 02:06:51 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:06:51 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250706.IAA00758@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:06:20 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"-XNAu1.0.Bh.5ADmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2402 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022E96F24DEC199603004857 UA content ID: Re: DESE context issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:01 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022E96F24DEC199603004857 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE context issues Precedence: 1 To: WATERS@AM_MARVIN Keith, SDP is allowed to be independently Bnegotiated on each NCP according to the LCP extensions RFC. But the point is mute since SDP is not negotiated in the context of 1969 since the plain text is padded not the encrypted text. The issue I have with the way the RFC as currently defined is that it allows two implementations to NOT work together without bilateral agreement as to whether SDP was applied to the clear text before encryption is applied. Philip Rakity FlowPoint Corporation On Mon, 23 Dec 1996, Keith Sklower wrote: > PMR wrote: > 4. Since the NCPs are negotiated in parallel, ECPNCP does not know > what options have been negotiated by the other NCPs. > > I wrote: > > I disagree. > > > PMR wrote: > > > Could you explain why you disagree? I think I might be missing something. > > To which I respond: > > While the consensus of the PPP comunity seems to be that it shouldn't > matter *in which order* various options and protocols are negotiated, > the consensus is far less clear that you aren't allowed to take survey > after the negotiation process is complete. > > You can't transmit any encrypted Bridge data packets until both of > ECP (with the DESE option) has completed, and the BCP has completed. > > You can't even negotiate *either* of ECP or BCP until LCP has completed, > and SDP is (was) an LCP option. > > So, if SDP was not negotiated, you could issue a warning at the time > the first encrypted bridge packet was sent. > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA09276 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:00:09 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id CAA23622 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 02:46:41 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id CAA09653 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 02:47:46 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA17737; Mon, 23 Dec 1996 20:31:34 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 20:31:34 -0500 (EST) % Date: Mon, 23 Dec 1996 17:17:15 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@royal % To: Keith Sklower % Cc: ietf-ppp@MERIT.EDU % Subject: Re: DESE context issues % In-Reply-To: <199612240036.QAA26076@vangogh.CS.Berkeley.EDU> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"fQgPQ2.0.4L4.s9plo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2381 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Keith Sklower VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:07:05 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02870; Wed, 25 Dec 1996 02:07:05 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:07:05 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250706.IAA00774@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:06:34 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"xE7R72.0.rh.EADmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2403 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022E96F24DEC199603054477 UA content ID: Re: DESE padding, before and after Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:06 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022E96F24DEC199603054477 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE padding, before and after Precedence: 1 To: WATERS@AM_MARVIN Inspired by Vern's contribution, let me see if I can make this all a bit clearer. Revising history a little bit (being previously unaware that there was not a blanket requirement to uniformly pad *all* packets, but only those whose NCP's said that SDP applied to them), what I had intended to say in RFC1969 was: "If any NCP is negotiated on the link which specifies the use of SDP for prevervation of the interpretation of its data packets in the face of padding, then SDP MUST be negotiated as an LCP option, and SDP must be used to pad the plaintext to be a length which is a multiple of 8 bytes as specified in the corresponding NCP spec." The phrase "it should only be used when absolutely necessary", should have been "it should only be negotiated when absolutely necessary". If SDP has been negotiated and multilink has been negotiated, and DESE is encrypting the multilink headers, then SDP removal should only be done on fragments bearing the (E)nd bit, as is specified in the multilink document under Padding considerations there. As far as Vern's observation that we need to concern ourselves not only about the padding of the payload for DESE, but possibly padding the complete DESE "data" packet for hardware considerations (Unless you want to negotiate encrypting for both below and above the multilink arrange mean --- arghghghghghg!!!! ) and as noted in RFC1969, the payload is already a multiple of 8 bytes, so it is pretty easy to acheive even/oddness without the use of SDP. As far as permitting leading zero insertion/removal as a means of padding to 8 bytes - I think its a good idea, and thought it was a good idea back when we were discussing DESE, but don't know what the IETF rules are at this point. DESE is *not* standards track; its merely informational (and was partially intended to be illustrative of how to specify a "bearer" protocol for ECP in the same way that there are many compression "bearer" protocols which use CCP. I don't recall anybody besides flowpoint having reported implementing it... % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA09463 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:05:14 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA27513 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:07:20 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id EAA16319 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:08:25 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA19448; Mon, 23 Dec 1996 21:52:14 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 21:52:14 -0500 (EST) % Date: Mon, 23 Dec 1996 18:50:53 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240250.SAA26403@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re: DESE padding, before and after % Resent-Message-ID: <"-5yKo3.0.pl4.TLqlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2385 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:08:00 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03088; Wed, 25 Dec 1996 02:08:00 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:08:00 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250707.IAA00812@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:07:13 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"Pt0tT1.0.ok.sADmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2407 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2082B5E224DEC199604105111 UA content ID: STAC LZS Extended mode question Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 04:11 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2082B5E224DEC199604105111 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: STAC LZS Extended mode question Precedence: 1 To: WATERS@AM_MARVIN Does anyone know why protocol field compression is explicitly disallowed in extended mode. I can understand why one might not want to do PFC on the frame being compressed, but I cannot understand why the compressed frame must be sent without PFC if it has been negotiated. Eg Why not send 0xFD, itstead of 0x00FD as the PPP protocol Regards, Philip Rakity FlowPoint % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id FAA11883 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 05:10:12 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA16130 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:41:36 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA09262 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:42:42 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA14950; Mon, 23 Dec 1996 17:26:31 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 17:26:31 -0500 (EST) % Date: Mon, 23 Dec 1996 14:32:07 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: Rob Friend % Cc: ietf-ppp@MERIT.EDU % Subject: STAC LZS Extended mode question % In-Reply-To: <31338780@smtpgateway.stac.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"J3kF-.0.Xf3.MSmlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2376 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Rob Friend VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:07:14 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02908; Wed, 25 Dec 1996 02:07:14 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:07:14 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250706.IAA00784@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:06:41 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"IgGnl2.0.fi.NADmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2404 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20820CE024DEC199603232660 UA content ID: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:24 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20820CE024DEC199603232660 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN PMR wrote: :2. Make the RFC require that the clear text be expanded using SDP before : encryption. eg NO SDP negotiation is required. I wrote: }I am opposed to this; why should you penalize performance of routers any more }in the situations where you don't have to pad -- e.g. you are doing IPCP only }over a T1 or T3 line, but you chose to encrypt. Bill Whelan wrote: :I don't understand this objection. DES will require padding every time the :plain text is not a multiple of eight bytes. The only times SDP would add :unneeded padding is when the last byte of the ciphertext could be mistaken :for SDP padding (approximately 1 chance in 256). To which I respond: First, my intent was that SDP would be applied *before* encrypting. (Having the same model of a link-within-a-link that Multilink uses). so that Bill's statement should be "when the last byte of the plaintext could be mistaken" and the probability is a little more than just 1 in 256; you also have to check for terminating sequences 2 preceded by 1 or ... Thus, when SDP is in effect, you have to do a certain amount of computation per packet, and, in certain cases you have to add 8 more bytes, thus wasting bandwidth. As was asserted by me in the RFC, for a large class of protocols, SDP is wasted effort. If you are transporting vanilla IP packets, padding by garbage or zeroes works fine, because the packets have a built-in length indicator. Likewise for IPX. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA10121 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:22:53 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA21516 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:21:51 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id BAA21095 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:22:56 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA16588; Mon, 23 Dec 1996 19:06:58 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 19:06:58 -0500 (EST) % Date: Mon, 23 Dec 1996 16:05:37 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240005.QAA26016@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"1a3X11.0.734.Xwnlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2379 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:07:42 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03012; Wed, 25 Dec 1996 02:07:42 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:07:42 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250707.IAA00799@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:07:02 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"hLt9e1.0.-j.iADmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2406 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022D54624DEC199603494990 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:50 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022D54624DEC199603494990 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN From ietf-ppp-request@MERIT.EDU Mon Dec 23 09:32:27 1996 Resent-Date: Mon, 23 Dec 1996 12:29:06 -0500 (EST) Date: Mon, 23 Dec 1996 09:34:08 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: ietf-ppp@MERIT.EDU Subject: RFC 1969 DES Encryption Issues Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2372 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Folks, Let me try to restate the problems as I see them and perhaps some solutions will be possible. 1. DES requires that the clear text be expanded to a multiple of 8 bytes before encryption. Eg The original data is expanded. Yes. 2. RFC 1969 does NOT explicitly pass the amount of this padding to the receiver. Yes. 3. Some protocols require that the original data size be recovered by the receiver inorder to process correctly the frame. Some examples are bridging If you were bridging 802.3, only then it has a length field. and TCP/IP using VJ compression. (Perhaps IPX with header compression is in this catagory. 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. I disagree. 5. Requesting the use of self described padding during ECPNCP negotiation states that the encrypted text is padded (NOT the plain text before encryption as per point 1. That was not my understanding when I proposed the RFC. 6. For SDP to work it requires that the receiver receive what the sender believes has been sent. Eg there was no H/W padding of the data when the data was sent. Some folks have given examples of HDLC chips that pad out frame to be an even number of bytes. Since with SDP one looks are the last byte in the frame and checks if it is an SDP character and removes padding accordingly, any artifical pads would make SDP not work. The only hardware issues that I was aware of where even/odd. Certainly PFC says you *may* omit the leading 0 but are *not required* to. You can force a PPP packet to be of even length by chosing whether or not to include the leading 0. IF my understanding of the issues is correct than for two independent implementations to work an agreement on how cleartext padding is done is required. Possible solutions. 1. Successful negotiation of SDP with ECPNCP implies that the receiver will check for SDP padding in the clear text; it also requires the transmitter to add SDP padding to the clear text before encryption. This is certainly what I had in mind, and I think that the RFC editor/process should allow clarifications of original intent. 2. Make the RFC require that the clear text be expanded using SDP before encryption. eg NO SDP negotiation is required. I am opposed to this; why should you penalize performance of routers any more in the situations where you don't have to pad -- e.g. you are doing IPCP only over a T1 or T3 line, but you chose to encrypt. 3. Add a number of pad byte added byte to the ECP header as per my previous note and require its use. DESE is not the end-all and be all of encryption protocols. Propose another one, and include your explicit padding byte there. Use triple DES or md5 or whatever you like, but just assign a different code; we've only assigned 2 code points of a possbile 255. Philip Rakity FlowPoint (408) 364-8300 Keith Sklower University of CA, Berkeley (510) 642 9587 % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA11118 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:49:14 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA18373 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:19:51 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA10580 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:20:56 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA15654; Mon, 23 Dec 1996 18:04:46 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 18:04:46 -0500 (EST) % Date: Mon, 23 Dec 1996 15:03:25 -0800 (PST) % From: Keith Sklower % Message-Id: <199612232303.PAA25819@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU, pmr@flowpoint.com % Subject: Re: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"x4AzW2.0.Xq3.D0nlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2377 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU, pmr@flowpoint.com Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:09:11 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03325; Wed, 25 Dec 1996 02:09:11 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:09:11 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250708.IAA00910@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:08:14 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"zxYJG1.0.Jo.rBDmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2410 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2020944E24DEC199605430392 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 05:43 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020944E24DEC199605430392 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN At 09:34 AM 12/23/96 -0800, Philip Rakity wrote: > >Folks, ... > >6. For SDP to work it requires that the receiver receive what the sender > believes has been sent. Eg there was no H/W padding of the data when the > data was sent. Some folks have given examples of HDLC chips that pad out > frame to be an even number of bytes. Since with SDP one looks are the > last byte in the frame and checks if it is an SDP character and removes > padding accordingly, any artifical pads would make SDP not work. > I would expect that any software running with such HDLC controllers would be aware of the controller's requirement, and could add SDP to an even number of bytes. > >IF my understanding of the issues is correct than for two independent >implementations to work an agreement on how cleartext padding is done is >required. Yes. > >Possible solutions. > >1. Successful negotiation of SDP with ECPNCP implies that the receiver >will check for SDP padding in the clear text; it also requires the >transmitter to add SDP padding to the clear text before encryption. This seems incomplete: it does not *require* SDP negotiation, nor say what is to be done if SDP is not negotiated. I think it also mixes SDP in an unnatural way with ECP. > >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. This is at least internally consistent and self-contained for ECP. > >3. Add a number of pad byte added byte to the ECP header as per my >previous note and require its use. I think this is the simplest, and therefore best, solution. > > > >Philip Rakity >FlowPoint >(408) 364-8300 > > > > -- Eric L. Michelsen, Copper Mountain Networks, Inc. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id GAA14859 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 06:42:31 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id TAA01716 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 19:07:08 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id TAA16827 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 19:08:13 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA11300; Mon, 23 Dec 1996 12:50:39 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 12:50:39 -0500 (EST) % Message-Id: <2.2.32.19961223175112.002fd56c@coppermountain.com> % X-Sender: "Eric Michelsen" % X-Mailer: Windows Eudora Pro Version 2.2 (32) % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Mon, 23 Dec 1996 09:51:12 -0800 % To: ietf-ppp@MERIT.EDU % From: "Eric L. Michelsen" % Subject: Re: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"KhBOE.0.Vm2.kPilo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2373 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:07:21 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02929; Wed, 25 Dec 1996 02:07:21 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:07:21 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250706.IAA00794@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:06:49 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"k7ugI1.0.9j.TADmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2405 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022D54524DEC199603452701 UA content ID: Re[2]: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:46 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022D54524DEC199603452701 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[2]: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. > >I am opposed to this; why should you penalize performance of routers any more >in the situations where you don't have to pad -- e.g. you are doing IPCP only >over a T1 or T3 line, but you chose to encrypt. I don't understand this objection. DES will require padding every time the plain text is not a multiple of eight bytes. The only times SDP would add unneeded padding is when the last byte of the ciphertext could be mistaken for SDP padding (approximately 1 chance in 256). >Keith Sklower >University of CA, Berkeley >(510) 642 9587 Bill Whelan % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA10923 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:44:56 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA19025 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:40:12 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA12809 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:41:18 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA15956; Mon, 23 Dec 1996 18:25:19 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 18:25:19 -0500 (EST) % Date: Mon, 23 Dec 96 18:24:09 EST % From: "Whelan, Bill" % Message-Id: <9611238513.AA851394289@netx.nei.com> % To: ietf-ppp@MERIT.EDU, pmr@flowpoint.com % Subject: Re[2]: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"DSI201.0.Bv3.UJnlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2378 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU, pmr@flowpoint.com Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:08:36 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03212; Wed, 25 Dec 1996 02:08:36 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:08:36 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250707.IAA00883@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:07:55 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"0K47k1.0.hn.aBDmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2409 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022F28D24DEC199605231520 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 05:23 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022F28D24DEC199605231520 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN >IF my understanding of the issues is correct than for two independent >implementations to work an agreement on how cleartext padding is done is >required. > >Possible solutions. > >1. Successful negotiation of SDP with ECPNCP implies that the receiver >will check for SDP padding in the clear text; it also requires the >transmitter to add SDP padding to the clear text before encryption. > This one is clearly wrong. SDP negotiation implies the ciphertext is padded. As you've pointed out, the problem is that the plain text must be padded. >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. This is the best solution. I suspect it was the actual intent of the RFC to "require" such padding in instances when it was needed. Any implementation which currently does this is in compliance with the RFC. > >3. Add a number of pad byte added byte to the ECP header as per my >previous note and require its use. > No, I actually prefer this solution. But anyone implementing it today would be in violation of the existing RFC. > > >Philip Rakity >FlowPoint >(408) 364-8300 > Bill Whelan % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id GAA14296 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 06:22:42 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id UAA05728 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 20:19:34 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id UAA19026 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 20:20:39 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA12309; Mon, 23 Dec 1996 14:01:16 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 14:01:16 -0500 (EST) % Date: Mon, 23 Dec 96 13:59:23 EST % From: "Whelan, Bill" % Message-Id: <9611238513.AA851378449@netx.nei.com> % To: ietf-ppp@MERIT.EDU % Subject: Re: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"NB_wt2.0.F03.xRjlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2374 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:08:18 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03164; Wed, 25 Dec 1996 02:08:18 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:08:18 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250707.IAA00827@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:07:22 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"ha_Yd2.0.Ql.2BDmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2408 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022E97F24DEC199604121993 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 04:12 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022E97F24DEC199604121993 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN Since the RFC does not completely define all the cases necessary to have independent implemenations really, there should be no problem with implementing either item 2) or 3) below. Item 2) is perhaps better as it keeps the basic format of the packets by simply requiring SDP be the method of padding the clear text, but considering the lack of implementations, I would prefer item 3). In addition, does anyone know if there were any independent implementations running before RFC 1969 was progressed to its current RFC status? Philip Rakity On Mon, 23 Dec 1996, Whelan, Bill wrote: > > >IF my understanding of the issues is correct than for two independent > >implementations to work an agreement on how cleartext padding is done is > >required. > > > >Possible solutions. > > > >1. Successful negotiation of SDP with ECPNCP implies that the receiver > >will check for SDP padding in the clear text; it also requires the > >transmitter to add SDP padding to the clear text before encryption. > > > This one is clearly wrong. SDP negotiation implies the ciphertext is > padded. As you've pointed out, the problem is that the plain text must be > padded. > > >2. Make the RFC require that the clear text be expanded using SDP before > >encryption. eg NO SDP negotiation is required. > > This is the best solution. I suspect it was the actual intent of the RFC > to "require" such padding in instances when it was needed. Any > implementation which currently does this is in compliance with the RFC. > > > >3. Add a number of pad byte added byte to the ECP header as per my > >previous note and require its use. > > > No, I actually prefer this solution. But anyone implementing it today > would be in violation of the existing RFC. > > > > > >Philip Rakity > >FlowPoint > >(408) 364-8300 > > > > Bill Whelan > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id FAA11949 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 05:11:42 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA16172 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:35:41 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA04885 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:36:46 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA14867; Mon, 23 Dec 1996 17:20:31 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 17:20:31 -0500 (EST) % Date: Mon, 23 Dec 1996 14:26:08 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: "Whelan, Bill" % Cc: ietf-ppp@MERIT.EDU % Subject: Re: RFC 1969 DES Encryption Issues % In-Reply-To: <9611238513.AA851378449@netx.nei.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"TpsZx2.0.Ee3.kMmlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2375 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: "Whelan, Bill" VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 02:09:22 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03363; Wed, 25 Dec 1996 02:09:22 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 02:09:22 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612250708.IAA00937@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 08:08:27 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"PpMyU.0.1p.5CDmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2411 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022D4B924DEC199606075570 UA content ID: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 06:08 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022D4B924DEC199606075570 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN Folks, Let me try to restate the problems as I see them and perhaps some solutions will be possible. 1. DES requires that the clear text be expanded to a multiple of 8 bytes before encryption. Eg The original data is expanded. 2. RFC 1969 does NOT explicitly pass the amount of this padding to the receiver. 3. Some protocols require that the original data size be recovered by the receiver inorder to process correctly the frame. Some examples are bridging and TCP/IP using VJ compression. (Perhaps IPX with header compression is in this catagory. 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. 5. Requesting the use of self described padding during ECPNCP negotiation states that the encrypted text is padded (NOT the plain text before encryption as per point 1. 6. For SDP to work it requires that the receiver receive what the sender believes has been sent. Eg there was no H/W padding of the data when the data was sent. Some folks have given examples of HDLC chips that pad out frame to be an even number of bytes. Since with SDP one looks are the last byte in the frame and checks if it is an SDP character and removes padding accordingly, any artifical pads would make SDP not work. IF my understanding of the issues is correct than for two independent implementations to work an agreement on how cleartext padding is done is required. Possible solutions. 1. Successful negotiation of SDP with ECPNCP implies that the receiver will check for SDP padding in the clear text; it also requires the transmitter to add SDP padding to the clear text before encryption. 2. Make the RFC require that the clear text be expanded using SDP before encryption. eg NO SDP negotiation is required. 3. Add a number of pad byte added byte to the ECP header as per my previous note and require its use. Philip Rakity FlowPoint (408) 364-8300 % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id HAA15603 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 07:07:22 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id SAA00952 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 18:47:00 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id SAA22402 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 18:48:04 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA10768; Mon, 23 Dec 1996 12:28:40 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 12:28:40 -0500 (EST) % Date: Mon, 23 Dec 1996 09:34:08 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: ietf-ppp@MERIT.EDU % Subject: RFC 1969 DES Encryption Issues % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"6lq2a3.0.7e2.75ilo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2372 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 09:02:19 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id JAA04646; Wed, 25 Dec 1996 09:02:19 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 09:02:19 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612251401.PAA15169@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 15:01:34 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"YBpXg.0.D81.IFJmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2412 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2021F55624DEC199611293887 UA content ID: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 11:30 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2021F55624DEC199611293887 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN Keith Sklower writes: > First, my intent was that SDP would be applied *before* encrypting. > (Having the same model of a link-within-a-link that Multilink uses). > so that Bill's statement should be > "when the last byte of the plaintext could be mistaken" > > and the probability is a little more than just 1 in 256; you also have to > check for terminating sequences 2 preceded by 1 or ... All you have to do is check if the last byte is between 1 and 8, inclusive (see RFC 1570 section 2.2). -- Karl Fox, servant of God, employee of Ascend Communications 3518 Riverside Drive, Suite 101, Columbus, Ohio 43221 +1 614 326 6841 % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id MAA27666 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 12:28:56 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id GAA31187 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 06:43:41 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id GAA00808 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 06:44:47 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id AAA20511; Tue, 24 Dec 1996 00:28:42 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 00:28:42 -0500 (EST) % Date: Mon, 23 Dec 1996 21:28:33 -0800 % Message-Id: <199612240528.VAA03033@spud.ascend.com> % From: Karl Fox % To: Keith Sklower % Cc: ietf-ppp@MERIT.EDU % Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % In-Reply-To: <199612240005.QAA26016@vangogh.CS.Berkeley.EDU> % References: <199612240005.QAA26016@vangogh.CS.Berkeley.EDU> % Reply-To: Karl Fox % Organization: Ascend Communications % Resent-Message-ID: <"uyJ3T1.0.Q05.9eslo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2386 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Keith Sklower VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 10:48:26 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA05119; Wed, 25 Dec 1996 10:48:26 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 10:48:26 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612251547.QAA18297@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 16:47:52 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"fwlMq3.0.gF1.6pKmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2413 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022A5A224DEC199615425709 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 15:43 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022A5A224DEC199615425709 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN >As was asserted by me in the RFC, for a large class of protocols, >SDP is wasted effort. If you are transporting vanilla IP packets, >padding by garbage or zeroes works fine, because the packets have >a built-in length indicator. Likewise for IPX. I must admit when we wrote the DESE RFC, never having come across hardware which required SDP, I didn't think that SDP would in practise be required within DESE. S o I didn't think a great deal about it at the time. In my view the problem with SDP is that it is ill-defined as to which packets it should be applied/removed ; and you have to negotiate it before you know if you will need it. In short, I don't like it. I am coming round (belatedly) to the technique of prepending sufficient zeros (prior to encryption) to complete a cypher block and to ensure that the length can be unambiguously determined. This is a simple, effective, unambiguous, no-brainer way of fixing the length of a packet - and at no additioanl cost in terms of packet length.. Does anyone object to this technique now? Gerry % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA05649 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:42:32 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA30948 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:44:41 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id QAA20807 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:45:47 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA24230; Tue, 24 Dec 1996 10:29:06 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 10:29:06 -0500 (EST) % From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) % To: sklower@CS.Berkeley.EDU (Keith Sklower) % Cc: Ietf-Ppp@MERIT.EDU (Ietf-Ppp) % Message-ID: <1996Dec24.142534.1281.343716@eurohub.europe.shiva.com> % X-Conversion-ID: % X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT % Mime-Version: 1.0 % Content-Type: text/plain; charset="US-ASCII" % Date: Tue, 24 Dec 1996 15:26:57 GMT % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"t4Uz-2.0.Xw5.1R_lo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2387 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: sklower@CS.Berkeley.EDU (Keith Sklower) VMSmail CC information: Ietf-Ppp@MERIT.EDU (Ietf-Ppp) Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 10:58:58 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA05234; Wed, 25 Dec 1996 10:58:58 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 10:58:58 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612251558.QAA18551@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 16:58:26 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"nwuDj.0.PH1.-yKmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2414 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084700824DEC199615544715 UA content ID: I-D ACTION:draft-ietf-pppext-l2tp-01.txt Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 15:55 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084700824DEC199615544715 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: I-D ACTION:draft-ietf-pppext-l2tp-01.txt Precedence: 1 To: WATERS@AM_MARVIN --NextPart A Revised 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 : Layer Two Tunneling Protocol "L2TP" Author(s) : K. Hamzeh, T. Kolar, M. Littlewood, G. Pall, J. Taarud, A. Valencia, W. Verthein Filename : draft-ietf-pppext-l2tp-01.txt Pages : 75 Date : 12/23/1996 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. Internet-Drafts are 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-l2tp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19961223135209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961223135209.I-D@ietf.org> --OtherAccess-- --NextPart-- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA06016 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:54:21 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA32036 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:56:27 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id QAA00408 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:57:30 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA24372; Tue, 24 Dec 1996 10:41:28 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 10:41:28 -0500 (EST) % 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-l2tp-01.txt % Date: Tue, 24 Dec 1996 09:47:13 -0500 % Sender: cclark@ietf.org % Message-ID: <9612240947.aa07207@ietf.org> % Resent-Message-ID: <"WFEPR3.0.hy5.dc_lo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2388 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: IETF-Announce:; VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 11:48:55 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA05493; Wed, 25 Dec 1996 11:48:55 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 11:48:55 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612251648.RAA20227@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 17:48:31 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"XTnnb2.0.WL1.phLmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2415 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084F90624DEC199616433873 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 16:44 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F90624DEC199616433873 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN > From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) > ... > I am coming round (belatedly) to the technique of prepending sufficient zeros > (prior to > encryption) to complete a cypher block and to ensure that the length can be > unambiguously > determined. This is a simple, effective, unambiguous, no-brainer way of > fixing the length of > a packet - and at no additioanl cost in terms of packet length.. > l.. Do you mean the hack--er, technique of extending the "inner" PPP protocol number with leading zeros? Besides being optimally dense (using exactly the minimal padding) and denser than self-describing padding, that technique has a major non-technical advantage. It prevents confusion among implementors and users between the SDP required by DES and inside the encryption from the other SDP that can simultaneously be present outside the encryption to cater to the (I hope) mythical braindead HDLC chips. The DES padding would be of zeros, while the LCP padding would be SDP. What is the overall size of an ECP data packet? The info field has a length of 0(mod 8) thanks to the DES block size. If address, control, and protocol field compressions are negotiated by LCP, then I think the HDLC packet will have a length of 3(mod 8) (counting the FCS) and so require SDP. But I suppose the braindead HDLC chips that require SDP did not do handle address and control filed compression, making the length 5(mod 8)--assuming they did protocol field compression. Did they? Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA08036 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 17:43:11 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA00946 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 17:45:19 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id RAA29966 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 17:46:25 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA25260; Tue, 24 Dec 1996 11:30:30 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 11:30:30 -0500 (EST) % Date: Tue, 24 Dec 1996 09:30:20 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612241630.JAA16311@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"FrhZ01.0.dA6.cK0mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2389 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 13:59:54 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA06067; Wed, 25 Dec 1996 13:59:54 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 13:59:54 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612251859.TAA23843@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 19:59:29 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"eCrBH.0.UU1.bcNmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2416 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084F90624DEC199618551751 UA content ID: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 18:55 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F90624DEC199618551751 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN The real life example comes from our testing with Holger using encryption with TCP/IP and VJ compression (No CCP). Neither of us were able to get telnet to receive the correct data either when talking with ourselves or with each other. See below for the explanation. Concerning SDP negotiation, the implemenation note in section 2.2 states that "To avoid unnecessary configuration handshakes, an implementation which generates padding, and has a protocol configured which requires padding to be known, SHOULD include this option in its Configuration-Request, and SHOULD Configure-Nak with this Option when it is not present in the peer's Request." I took this to mean that SDP was negotiated on each NCP that required it (no need to do LCP negotiation). Is the rule for using SDP the following. 1. Negotiate its general availability using LCP. 2. Negotiate the specific protocols that use SDP on each NCP Philip Rakity FlowPoint ---------- Forwarded message ---------- Date: Fri, 20 Dec 1996 14:55:04 +0100 (MET) From: Holger Kummert To: ietf-ppp@MERIT.EDU Subject: ECP-padding and VanJacobson Hello, we found another point concerning padding in ECP: When transmitting VJ-compressed TCP/IP-packets, the content of the field "total length" in the IP-Header will be computed on the receiver's site as the sum of the length of the TCP/IP-Header (exactly reconstructed) and the length of the TCP-Data (including ECP-padding). So it's impossible for the receiver to reconstruct the original length of the packet unless someone will tell him (e.g. SDP). rfc1144 says: One can scavenge a few more bytes by noting that any reasonable link-level framing protocol will tell the receiver the length of a received message so total length (bytes 2 and 3) is redundant. So should this be mentioned in a revision of RFC1969, if there will be one? Another question: As Bill Whelan mentioned before, SDP is a link-level option. When it's negotiated and be used in context with ECP, it should be applied _twice_ to the received data: - One time for the received packet/fragment - One time for the unencrypted packet. Is this the intention of SDP? If not I would like an extension of RFC1969 according to Philip Rakity's suggestion. Many thanks, Holger Kummert -- Holger Kummert email: kummert@conware.de Conware Computer Consulting GmbH www: http://www.conware.de/ Killisfeldstrasse 64 Tel.: +49 721 9495-0 D-76227 Karlsruhe/Germany % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id TAA12039 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 19:54:48 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id TAA04954 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 19:56:56 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id TAA06173 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 19:58:02 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA27169; Tue, 24 Dec 1996 13:42:03 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 13:42:03 -0500 (EST) % Date: Tue, 24 Dec 1996 10:27:40 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@royal % To: sklower@CS.Berkeley.EDU % Cc: ietf-ppp@MERIT.EDU % Subject: Real life ECP example % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"cDWbQ.0.Se6.wF2mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2390 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: sklower@CS.Berkeley.EDU VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 15:35:11 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA06575; Wed, 25 Dec 1996 15:35:11 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 15:35:11 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612252034.VAA27057@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 21:34:45 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"l9VyA1.0.Qc1.w_Omo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2417 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084722724DEC199620283754 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 20:29 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084722724DEC199620283754 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN I like this method of prepending 0's to the protocol field before encryption to ensure the size is a multiple of 8. However, the STAC LZS RFC explicitly states that the protocol field is 2 bytes (0x00FD) long when option 4 (extended mode) has been negotiated. Eg I cannot remove one of the bytes of get to a multiple of 8. Philip Rakity FlowPoint On Tue, 24 Dec 1996, CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva wrote: > >As was asserted by me in the RFC, for a large class of protocols, > >SDP is wasted effort. If you are transporting vanilla IP packets, > >padding by garbage or zeroes works fine, because the packets have > >a built-in length indicator. Likewise for IPX. > > I must admit when we wrote the DESE RFC, never having come across hardware > which required SDP, I didn't think that SDP would in practise be required > within DESE. > S o I didn't think a great deal about it at the time. > In my view the problem with SDP is that it is ill-defined as to which packets > it should be > applied/removed ; and you have to negotiate it before you know if you will > need it. > In short, I don't like it. > > I am coming round (belatedly) to the technique of prepending sufficient zeros > (prior to > encryption) to complete a cypher block and to ensure that the length can be > unambiguously > determined. This is a simple, effective, unambiguous, no-brainer way of > fixing the length of > a packet - and at no additioanl cost in terms of packet length.. > > Does anyone object to this technique now? > > Gerry > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA14322 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:28:12 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA08690 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:30:20 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id VAA31798 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:31:26 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA28410; Tue, 24 Dec 1996 15:13:46 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 15:13:46 -0500 (EST) % Date: Tue, 24 Dec 1996 10:32:42 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@royal % To: CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva % Cc: Keith Sklower , Ietf-Ppp % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % In-Reply-To: <1996Dec24.142534.1281.343716@eurohub.europe.shiva.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"x_-eA3.0.rx6.wb3mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2391 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva VMSmail CC information: Keith Sklower , Ietf-Ppp Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 15:39:27 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA06668; Wed, 25 Dec 1996 15:39:27 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 15:39:27 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612252039.VAA27136@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 21:39:02 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"IYhlS2.0.jd1.w3Pmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2418 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022EA7E24DEC199620363887 UA content ID: re: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 20:37 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022EA7E24DEC199620363887 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: re: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN > From: Philip Rakity > ... > Concerning SDP negotiation, the implemenation note in section 2.2 states > that > > "To avoid unnecessary configuration handshakes, an implementation which > generates padding, and has a protocol configured which requires padding > to be known, SHOULD include this option in its Configuration-Request, and > SHOULD Configure-Nak with this Option when it is not present in the > peer's Request." > > I took this to mean that SDP was negotiated on each NCP that required > it (no need to do LCP negotiation). I do not understand that reasoning. How do you negotiate SDP on an NCP? > Is the rule for using SDP the following. > > 1. Negotiate its general availability using LCP. > 2. Negotiate the specific protocols that use SDP on each NCP #1 makes sense. I do not understand #2. How can you negotiate SDP for a single NCP? You cannot put the SDP option into a Configure-Request for any NCP. You can put the SDP option into <<>> an LCP Configure-Request. After the Configure-Ack for SDP, how would either PPP peer know which NCP needs SDP and which does not? > ... > As Bill Whelan mentioned before, SDP is a link-level option. > When it's negotiated and be used in context with ECP, > it should be applied _twice_ to the received data: > - One time for the received packet/fragment > - One time for the unencrypted packet. How can there be any alternative, given a cypher with a fixed block size of 8 and data without its own length? Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA14509 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:36:09 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA08834 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:38:15 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id VAA30713 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:39:22 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA28501; Tue, 24 Dec 1996 15:22:16 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 15:22:16 -0500 (EST) % Date: Tue, 24 Dec 1996 13:22:03 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612242022.NAA17560@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: re: Real life ECP example % Resent-Message-ID: <"o31aE2.0.Cz6.tj3mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2392 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 16:00:03 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA06844; Wed, 25 Dec 1996 16:00:03 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 16:00:03 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612252059.VAA27652@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 21:59:39 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"T5lpo3.0.dg1.FNPmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2419 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2023205124DEC199620534672 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 20:54 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2023205124DEC199620534672 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN > From: Philip Rakity > I like this method of prepending 0's to the protocol field before > encryption to ensure the size is a multiple of 8. However, the STAC LZS > RFC explicitly states that the protocol field is 2 bytes (0x00FD) long > when option 4 (extended mode) has been negotiated. Eg I cannot remove > one of the bytes of get to a multiple of 8. So what? Why would you want to pad the bits inside STAC LZS type 4? I get irritated with people blindly following the layering religion, but this is a case when layering must be considered. There are three protocol fields: 1. The outer-most protocol field specifies ECP. The size of this protocol field is <<>> specified by ECP nor by LZS. The size of this protocol field is determined only from the LCP negotiation. No matter what ECP and/or LZS want or say, the LCP protocol field is beyond their ken. 2. The middle protocol field tells ECP the protocol of the inner-most protocol. This protocol is 0xfd when compression is being used. The size of this protocol field is determined ONLY by the ECP standard. Neither LZS nor LCP have anything to say about the size of this protocol field. 3. The innermost protocol filed tells LZS the protocol of the real data. This size of this protocol field is determined by the LZS CCP standard. LCP and ECP have nothing to say about the size of this protocol field. You must pad #1 or use SDP if and only if your HDLC hardware is braindead, regardless of whether you are using LZS and/or ECP. If you do not have stupid HDLC hardware, there is no reason to pad #2 or #3. #3 has nothing to do ECP. LZS must figure out the correct length of VJ-header compressed packets before delivering them to the VJ-decompressor regardless of whether you are using ECP #2 is the only protocol field at issue. Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA14884 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:53:19 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA08199 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:55:23 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id VAA14427 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:56:30 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA28624; Tue, 24 Dec 1996 15:39:23 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 15:39:23 -0500 (EST) % Date: Tue, 24 Dec 1996 13:39:12 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612242039.NAA17611@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"i1Jkn1.0.B_6.wz3mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2393 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 17:45:33 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA07349; Wed, 25 Dec 1996 17:45:33 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 17:45:33 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612252245.XAA01232@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 23:45:07 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"UjbtJ1.0.Uo1.8wQmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2420 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2085598624DEC199622395620 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 22:40 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2085598624DEC199622395620 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN Sorry about the incomplete paraphrase of the STAC LZS RFC. To be exact, the statement is (section 5.1) When a compression protocol is successfully negotiated by the PPP compression control protocol, the value is hex 00FD. Protocol field compression MUST NOT be used on this value when extended mode is negotiated on the link, even if protocol field compression was successfully negotiated before data compression. From this statement, I take it that I must pass to the decompressor code a 2 byte protocol id of 0x00FD, whether or not I have been using ECP. Similarly, I must send these two bytes inside the ECP packet since I would have sent these bytes on the wire if ECP was not negotiated. I believe that the requirement in the RFC to ignore PFC negotation rules is a bad choice, but my opinion is NOT what is in the STAC LZS RFC. See below for responses. Philip Rakity FlowPoint On Tue, 24 Dec 1996, Vernon Schryver wrote: > > From: Philip Rakity > > > I like this method of prepending 0's to the protocol field before > > encryption to ensure the size is a multiple of 8. However, the STAC LZS > > RFC explicitly states that the protocol field is 2 bytes (0x00FD) long > > when option 4 (extended mode) has been negotiated. Eg I cannot remove > > one of the bytes of get to a multiple of 8. > > So what? Why would you want to pad the bits inside STAC LZS type 4? Since the cleartext must be a multiple of 8 bytes for DES encryption to work, the cleartext must be padded. It can be padded at the end using SDP or as was suggested by someone else, it could be padded in the front by prepending 0's to the protocol value. If the cleartext was 1 byte too long for DES encryption and the protocol being encrypted was CCP LZS, than one could remove the 00 byte from the protocol id (0x00FD), however this is NOT allowed according to the RFC if extended mode was negotiated. > > I get irritated with people blindly following the layering religion, > but this is a case when layering must be considered. > > There are three protocol fields: > > 1. The outer-most protocol field specifies ECP. > The size of this protocol field is <<>> specified by ECP > nor by LZS. The size of this protocol field is determined only > from the LCP negotiation. No matter what ECP and/or LZS want > or say, the LCP protocol field is beyond their ken. Really? Is the STAC LZS RFC wrong in saying that PFC does not apply. > > 2. The middle protocol field tells ECP the protocol of the inner-most > protocol. This protocol is 0xfd when compression is being used. > The size of this protocol field is determined ONLY by the ECP > standard. Neither LZS nor LCP have anything to say about the size > of this protocol field. If PFC was not negotiated implicitly or explicitly, I thought that it was NOT allowed to apply PFC. Where in the RFCs does it say you can PFC compress protocol id's when PFC was not negotiated. Note: A reasonable implemenation should ALWAYS be able to decode PFC, but I am taking about what the RFC says, not what is reasonable. PPP requires PFC be negotiated, while MLP implies that it has been implicitly agreed to. > > 3. The innermost protocol filed tells LZS the protocol of the real > data. This size of this protocol field is determined by the LZS > CCP standard. LCP and ECP have nothing to say about the size of > this protocol field. > > You must pad #1 or use SDP if and only if your HDLC hardware is > braindead, regardless of whether you are using LZS and/or ECP. If you > do not have stupid HDLC hardware, there is no reason to pad #2 or #3. > > #3 has nothing to do ECP. LZS must figure out the correct length of > VJ-header compressed packets before delivering them to the VJ-decompressor > regardless of whether you are using ECP > > #2 is the only protocol field at issue. > We agree. > > Vernon Schryver, vjs@sgi.com > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA17212 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:39:22 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA12147 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:41:30 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA26590 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:42:37 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA29395; Tue, 24 Dec 1996 17:26:43 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 17:26:43 -0500 (EST) % Date: Tue, 24 Dec 1996 14:32:20 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: Vernon Schryver % Cc: ietf-ppp@MERIT.EDU % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % In-Reply-To: <199612242039.NAA17611@mica.denver.sgi.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"QRmIj2.0.AB7.YY5mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2394 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Vernon Schryver VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 17:49:55 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA07525; Wed, 25 Dec 1996 17:49:55 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 17:49:55 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612252249.XAA01398@vbormc.vbo.dec.com> Date: Wed, 25 Dec 96 23:49:30 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"6k2xZ.0.Gr1.E-Qmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2421 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2020AC9124DEC199622444345 UA content ID: re: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 22:45 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020AC9124DEC199622444345 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: re: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN One can add to the configure request the option for SDP. Eg Option 10, length 3. as per the LCP extensions RFC, thus informing the remote that one is able to receive SDP. I do not understand how one implements the statement I quoted from the RFC below unless one sends the request for SDP on each NCP that needs it. So, Exactly how does one negotiate SDP on a per protocol basis ??? Philip Rakity FlowPoint On Tue, 24 Dec 1996, Vernon Schryver wrote: > > From: Philip Rakity > > > ... > > Concerning SDP negotiation, the implemenation note in section 2.2 states > > that > > > > "To avoid unnecessary configuration handshakes, an implementation which > > generates padding, and has a protocol configured which requires padding > > to be known, SHOULD include this option in its Configuration-Request, and > > SHOULD Configure-Nak with this Option when it is not present in the > > peer's Request." > > > > I took this to mean that SDP was negotiated on each NCP that required > > it (no need to do LCP negotiation). > > I do not understand that reasoning. > How do you negotiate SDP on an NCP? > > > > Is the rule for using SDP the following. > > > > 1. Negotiate its general availability using LCP. > > 2. Negotiate the specific protocols that use SDP on each NCP > > #1 makes sense. > > I do not understand #2. How can you negotiate SDP for a single NCP? > You cannot put the SDP option into a Configure-Request for any NCP. > You can put the SDP option into <<>> an LCP Configure-Request. > After the Configure-Ack for SDP, how would either PPP peer know which > NCP needs SDP and which does not? > > > > ... > > As Bill Whelan mentioned before, SDP is a link-level option. > > When it's negotiated and be used in context with ECP, > > it should be applied _twice_ to the received data: > > - One time for the received packet/fragment > > - One time for the unencrypted packet. > > How can there be any alternative, given a cypher with a fixed block > size of 8 and data without its own length? > > > Vernon Schryver, vjs@sgi.com > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA17309 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:44:09 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA11084 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:46:18 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA16553 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:47:24 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA29758; Tue, 24 Dec 1996 17:31:33 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 17:31:33 -0500 (EST) % Date: Tue, 24 Dec 1996 14:37:08 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: Vernon Schryver % Cc: ietf-ppp@MERIT.EDU % Subject: re: Real life ECP example % In-Reply-To: <199612242022.NAA17560@mica.denver.sgi.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"4BxtT2.0.vG7.4d5mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2395 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Vernon Schryver VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 18:10:39 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA07668; Wed, 25 Dec 1996 18:10:39 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 18:10:39 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612252310.AAA02279@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 00:10:13 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"bYD7i3.0.Rt1.gHRmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2422 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2020AC9124DEC199623050667 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 23:05 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020AC9124DEC199623050667 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN > From: Philip Rakity > Sorry about the incomplete paraphrase of the STAC LZS RFC. To be exact, > the statement is (section 5.1) > > When a compression protocol is successfully negotiated by the PPP > compression control protocol, the value is hex 00FD. Protocol field > compression MUST NOT be used on this value when extended mode is > negotiated on the link, even if protocol field compression was > successfully negotiated before data compression. > > >From this statement, I take it that I must pass to the decompressor code > a 2 byte protocol id of 0x00FD, whether or not I have been using ECP. > Similarly, I must send these two bytes inside the ECP packet since I > would have sent these bytes on the wire if ECP was not negotiated. > > I believe that the requirement in the RFC to ignore PFC negotation rules > is a bad choice, but my opinion is NOT what is in the STAC LZS RFC. > ... Instead of that, I hope that the LZS RFC wording is muddled, that it is refering to both protocol fields in that quoted paragraph, that the first sentence says the protocol number in the 1st byte or bytes after the address and control fields (if any) that begin the packet are 0x00fd or 0xfd, while the second protocol field after the Coherency Count is always two bytes. That hope is consistent with the penultimate sentence in section 5.1 of RFC 1974 which is clearly talking about the inner protocol number. See also sections 2 and 2.5.1 that say the 0x00fd can be compressed to 0xfd. On the other hand, I vaguely seem to recall talk about limitations in early versions of Stac Electronics hardware couldn't handle some alignments or maybe it was protocol field compression. Isn't Type 4 or Extended mode the old, deprecated version? Isn't Type 3 the required mode, and because of sections 2 and 2.5.1 of RFC 1974, 0xfd compressable if and only if LCP says it is? > ... > > 2. The middle protocol field tells ECP the protocol of the inner-most > > protocol. This protocol is 0xfd when compression is being used. > > The size of this protocol field is determined ONLY by the ECP > > standard. Neither LZS nor LCP have anything to say about the size > > of this protocol field. > > If PFC was not negotiated implicitly or explicitly, I thought that it was > NOT allowed to apply PFC. Where in the RFCs does it say you can PFC > compress protocol id's when PFC was not negotiated. Note: A reasonable > implemenation should ALWAYS be able to decode PFC, but I am taking about > what the RFC says, not what is reasonable. PPP requires PFC be > negotiated, while MLP implies that it has been implicitly agreed to. I did not say that protocol field compression can be done willy-nilly, but that how the 0xfd of LZS is handled is not a matter for LCP to determine. Just as with MP (RFC 1717), whether address, control, and protocol field compression is negoiated with LCP Configure-Requests is irrelevant to what happens elsewhere. LCP Configure-Requests control the first 1-4 bytes of the packet on the wire. Other bytes are controlled otherwise. (Yes, I know of the suggestion that to preserve byte alignment and reduce implementor confusion, the inner protocol field of MP packets should be padded with zeros depending on whether LCP protocol field compression has not been negotiated.) Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA17755 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:04:41 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA13010 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:06:49 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA01197 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:07:56 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA00183; Tue, 24 Dec 1996 17:51:56 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 17:51:56 -0500 (EST) % Date: Tue, 24 Dec 1996 15:51:44 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612242251.PAA18099@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"Ux5B83.0.o2.Bw5mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2396 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 18:21:15 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA07764; Wed, 25 Dec 1996 18:21:15 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 18:21:15 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612252320.AAA02757@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 00:20:45 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"UBuH1.0._u1.cRRmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2423 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084F90624DEC199623151992 UA content ID: re: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 23:15 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F90624DEC199623151992 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: re: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN > From: Philip Rakity > One can add to the configure request the option for SDP. > > Eg Option 10, length 3. as per the LCP extensions RFC, thus informing the > remote that one is able to receive SDP. I do not understand those words. To what Configure-Request are you adding the SDP option? If you are adding to an LCP Configure-Request, then what does it have to do with any single NCP? (Nothing, by my lights.) > I do not understand how one implements the statement I quoted from the > RFC below unless one sends the request for SDP on each NCP that needs it. > > So, > > Exactly how does one negotiate SDP on a per protocol basis ??? You do not negotiate SDP on a per protocol basis, because by design it cannot be done. > ... > > > Concerning SDP negotiation, the implemenation note in section 2.2 states > > > that > > > > > > "To avoid unnecessary configuration handshakes, an implementation which > > > generates padding, and has a protocol configured which requires padding > > > to be known, SHOULD include this option in its Configuration-Request, and > > > SHOULD Configure-Nak with this Option when it is not present in the > > > peer's Request." > > > > > > I took this to mean that SDP was negotiated on each NCP that required > > > it (no need to do LCP negotiation). There is nothing in those words that say or suggest anything about negotiating SDP on a per protocol basis. Those words say you SHOULD turn on SDP if you might need it. They don't say you should turn it on partially if you need it only partially. I think the rest of us take RFC 1570 to be about LCP extensions instead of network protocols, and to be saying "If your HDLC hardware is braindead and requires padding, and if your system anticipates sending any network protocols that lack their own lengths (e.g.bly bridging and IP with VJ-header compression), then you SHOULD cause your LCP code to negotiate self-describing padding for all PPP packets (of course with the usual exceptions--control packets which may or may not be padded at the sender's whim)." I think the rest of us would also agree that you MAY renegoiate SDP on or off if your anticipations turn out to be wrong, but that renegotiating anything with LCP tends to stumble on broken PPP implementations. Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA17998 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:14:53 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA11886 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:17:00 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA15872 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:18:06 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA00457; Tue, 24 Dec 1996 18:02:16 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 18:02:16 -0500 (EST) % Date: Tue, 24 Dec 1996 16:02:05 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612242302.QAA18152@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: re: Real life ECP example % Resent-Message-ID: <"scMLa2.0.47.t36mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2397 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 19:51:41 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA08102; Wed, 25 Dec 1996 19:51:41 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 19:51:41 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260051.BAA05961@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 01:51:14 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"mvTWf3.0.D-1.PmSmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2424 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084EA5525DEC199600492739 UA content ID: re: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 00:49 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084EA5525DEC199600492739 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: re: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN SDP is negotiated with LCP, and only LCP, per RFC-1570. I think some confusion may arise, though, because of the wording of sec 2.2, par 2: "This option is most likely to be used when some protocols, such as network-layer or compression protocols, are configured which require detection and removal of any trailing padding. SUCH SPECIAL PROTOCOLS ARE IDENTIFIED IN THEIR RESPECTIVE DOCUMENTS." (Emphasis added). I take this to mean that any protocol which requires information field length preservation must say so in its defining RFC. Bridging Control Protocol (RFC-1638) makes a passing reference to SDP (sec 4.2, subsec "Optional Data Link Layer Padding", par 2), but if you blink you might miss it. So RFC-1570 defines a "special protocol" as one requiring length preservation. Then sec 2.2, par 4 says that an implementation "MUST follow the procedures for adding self-describing pads, but only to the specifically identified [i.e., "special"] protocols. The [implementation] is not required to add any padding to other protocols." So one doesn't negotiate SDP for each NCP, but if negotiated, one MUST use SDP only on "special" protocols. On other protocols, you are free to not pad, regardless of whether SDP was negotiated. This whole concept seems like a subtle point, buried in RFC-1570, and often forgotten when other NCP RFCs are written. Even BCP's reference to SDP is fairly terse, and easily missed. I haven't checked the CCP or ECP specs to see if they identify themselves as "special" in the RFC-1570 sense. -- Eric L. Michelsen, Copper Mountain Networks, Inc. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA20296 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 01:48:52 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA14979 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 01:51:00 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id BAA00640 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 01:52:05 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA00998; Tue, 24 Dec 1996 19:36:07 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 19:36:07 -0500 (EST) % Message-Id: <2.2.32.19961225003645.002fcd90@coppermountain.com> % X-Sender: "Eric Michelsen" % X-Mailer: Windows Eudora Pro Version 2.2 (32) % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Tue, 24 Dec 1996 16:36:45 -0800 % To: ietf-ppp@MERIT.EDU % From: "Eric L. Michelsen" % Subject: re: Real life ECP example % Resent-Message-ID: <"ZogfI1.0.TF.rR7mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2398 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Wed Dec 25 21:38:06 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA08577; Wed, 25 Dec 1996 21:38:06 -0500 (EST) Resent-Date: Wed, 25 Dec 1996 21:38:06 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260237.DAA10748@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 03:37:38 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"hjUSR.0.i52.8KUmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2425 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084EA5525DEC199602305768 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 02:31 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084EA5525DEC199602305768 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2082D27A24DEC199602091431 UA content ID: Re[2]: DESE context Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 02:09 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2082D27A24DEC199602091431 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[2]: DESE context Precedence: 1 To: WATERS@AM_MARVIN Philip Rakity writes: SDP is allowed to be independently Bnegotiated on each NCP according to the LCP extensions RFC. But the point is mute since SDP is not negotiated in the context of 1969 since the plain text is padded not the encrypted text. The issue I have with the way the RFC as currently defined is that it allows two implementations to NOT work together without bilateral agreement as to whether SDP was applied to the clear text before encryption is applied. To which I respond: Now it's my turn to say that I don't understand and may be missing something. Could you supply a sample negotation and example packets which have been encoded by one side and decoding by the other in a non-interoperable way? While I admit that I had overlooked the following paragraph in 1570, my interpretation is that not that "SDP is .. independently negotatied on each NCP", but rather SDP is negotiated *ONCE* and each NCP standard specifies whether or not SDP is to be applied to packets in that protocol *if it had been negotiated at the LCP level at all*: Quotation from [Page 8] of RFC 1570, second through fourth paragraphs of section 2.2 under Description: This option is most likely to be used when some protocols, such as network-layer or compression protocols, are configured which require detection and removal of any trailing padding. Such special protocols are identified in their respective documents. If the option is Rejected, the peer MUST NOT add any padding to the identified special protocols, but MAY add padding to other protocols. If the option is Ack'd, the peer MUST follow the procedures for adding self-describing pads, but only to the specifically identified protocols. The peer is not required to add any padding to other protocols. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA08005 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:08:49 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA24791 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:10:58 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id DAA02136 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:12:03 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA18305; Mon, 23 Dec 1996 20:56:12 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 20:56:12 -0500 (EST) % Date: Mon, 23 Dec 1996 17:54:51 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240154.RAA26278@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re[2]: DESE context % Resent-Message-ID: <"BxmJi2.0.yT4.xWplo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2383 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA23286 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 03:30:31 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA18830 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 03:32:38 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id DAA32194 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 03:33:45 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA01418; Tue, 24 Dec 1996 21:17:42 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 21:17:42 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250217.DAA22985@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 03:17:14 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"tiimU.0.5M.5x8mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2399 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:23:40 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA09951; Thu, 26 Dec 1996 02:23:40 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:23:40 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260723.IAA25333@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:23:13 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"Irg511.0.9R2.tVYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2426 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20835E1425DEC199607193573 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:19 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20835E1425DEC199607193573 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20820CE024DEC199602520368 UA content ID: Re: DESE context issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 02:52 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20820CE024DEC199602520368 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE context issues Precedence: 1 To: WATERS@AM_MARVIN At 05:17 PM 12/23/96 -0800, Philip Rakity wrote: >Keith, > >SDP is allowed to be independently Bnegotiated on each NCP according to the >LCP extensions RFC. I don't see this. RFC-1570 says that SDP is negotiated with LCP, but MUST be provided only to those NCPs which identify themselves as requiring detection and removal of trailing padding. I don't see that you can separately negotiate SDP on each NCP. >... -- Eric L. Michelsen, Copper Mountain Networks, Inc. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA08950 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:51:38 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA26944 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:53:47 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id DAA00976 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:54:52 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA19099; Mon, 23 Dec 1996 21:38:00 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 21:38:00 -0500 (EST) % Message-Id: <2.2.32.19961224023834.00302798@coppermountain.com> % X-Sender: "Eric Michelsen" % X-Mailer: Windows Eudora Pro Version 2.2 (32) % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Mon, 23 Dec 1996 18:38:34 -0800 % To: ietf-ppp@MERIT.EDU % From: "Eric L. Michelsen" % Subject: Re: DESE context issues % Resent-Message-ID: <"LiStF.0.Ig4.78qlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2384 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01754 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:19:06 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22561 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:11 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA03619 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:18 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02663; Wed, 25 Dec 1996 02:05:57 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:05:57 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250705.IAA00701@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:05:31 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"oIJ0r.0.Yf.L9Dmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2400 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:24:17 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10064; Thu, 26 Dec 1996 02:24:17 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:24:17 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260723.IAA25389@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:23:48 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"Hq5TA2.0.tS2.SWYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2428 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084F12B25DEC199607202524 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:20 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F12B25DEC199607202524 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022E96F24DEC199603004857 UA content ID: Re: DESE context issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:01 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022E96F24DEC199603004857 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE context issues Precedence: 1 To: WATERS@AM_MARVIN Keith, SDP is allowed to be independently Bnegotiated on each NCP according to the LCP extensions RFC. But the point is mute since SDP is not negotiated in the context of 1969 since the plain text is padded not the encrypted text. The issue I have with the way the RFC as currently defined is that it allows two implementations to NOT work together without bilateral agreement as to whether SDP was applied to the clear text before encryption is applied. Philip Rakity FlowPoint Corporation On Mon, 23 Dec 1996, Keith Sklower wrote: > PMR wrote: > 4. Since the NCPs are negotiated in parallel, ECPNCP does not know > what options have been negotiated by the other NCPs. > > I wrote: > > I disagree. > > > PMR wrote: > > > Could you explain why you disagree? I think I might be missing something. > > To which I respond: > > While the consensus of the PPP comunity seems to be that it shouldn't > matter *in which order* various options and protocols are negotiated, > the consensus is far less clear that you aren't allowed to take survey > after the negotiation process is complete. > > You can't transmit any encrypted Bridge data packets until both of > ECP (with the DESE option) has completed, and the BCP has completed. > > You can't even negotiate *either* of ECP or BCP until LCP has completed, > and SDP is (was) an LCP option. > > So, if SDP was not negotiated, you could issue a warning at the time > the first encrypted bridge packet was sent. > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA09276 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:00:09 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id CAA23622 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 02:46:41 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id CAA09653 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 02:47:46 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA17737; Mon, 23 Dec 1996 20:31:34 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 20:31:34 -0500 (EST) % Date: Mon, 23 Dec 1996 17:17:15 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@royal % To: Keith Sklower % Cc: ietf-ppp@MERIT.EDU % Subject: Re: DESE context issues % In-Reply-To: <199612240036.QAA26076@vangogh.CS.Berkeley.EDU> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"fQgPQ2.0.4L4.s9plo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2381 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Keith Sklower VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01800 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:19:51 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22698 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:53 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA08956 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:00 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02770; Wed, 25 Dec 1996 02:06:47 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:06:47 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250706.IAA00758@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:06:20 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"-XNAu1.0.Bh.5ADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2402 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:30:09 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10259; Thu, 26 Dec 1996 02:30:09 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:30:09 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260729.IAA25936@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:29:39 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"WcLMA3.0.zV2.wbYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2431 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2020AC9125DEC199607203676 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020AC9125DEC199607203676 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022E96F24DEC199603054477 UA content ID: Re: DESE padding, before and after Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:06 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022E96F24DEC199603054477 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE padding, before and after Precedence: 1 To: WATERS@AM_MARVIN Inspired by Vern's contribution, let me see if I can make this all a bit clearer. Revising history a little bit (being previously unaware that there was not a blanket requirement to uniformly pad *all* packets, but only those whose NCP's said that SDP applied to them), what I had intended to say in RFC1969 was: "If any NCP is negotiated on the link which specifies the use of SDP for prevervation of the interpretation of its data packets in the face of padding, then SDP MUST be negotiated as an LCP option, and SDP must be used to pad the plaintext to be a length which is a multiple of 8 bytes as specified in the corresponding NCP spec." The phrase "it should only be used when absolutely necessary", should have been "it should only be negotiated when absolutely necessary". If SDP has been negotiated and multilink has been negotiated, and DESE is encrypting the multilink headers, then SDP removal should only be done on fragments bearing the (E)nd bit, as is specified in the multilink document under Padding considerations there. As far as Vern's observation that we need to concern ourselves not only about the padding of the payload for DESE, but possibly padding the complete DESE "data" packet for hardware considerations (Unless you want to negotiate encrypting for both below and above the multilink arrange mean --- arghghghghghg!!!! ) and as noted in RFC1969, the payload is already a multiple of 8 bytes, so it is pretty easy to acheive even/oddness without the use of SDP. As far as permitting leading zero insertion/removal as a means of padding to 8 bytes - I think its a good idea, and thought it was a good idea back when we were discussing DESE, but don't know what the IETF rules are at this point. DESE is *not* standards track; its merely informational (and was partially intended to be illustrative of how to specify a "bearer" protocol for ECP in the same way that there are many compression "bearer" protocols which use CCP. I don't recall anybody besides flowpoint having reported implementing it... % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA09463 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:05:14 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA27513 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:07:20 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id EAA16319 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:08:25 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA19448; Mon, 23 Dec 1996 21:52:14 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 21:52:14 -0500 (EST) % Date: Mon, 23 Dec 1996 18:50:53 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240250.SAA26403@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re: DESE padding, before and after % Resent-Message-ID: <"-5yKo3.0.pl4.TLqlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2385 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01822 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:02 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22796 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:09 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA32226 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:16 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02813; Wed, 25 Dec 1996 02:06:57 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:06:57 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250706.IAA00774@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:06:34 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"xE7R72.0.rh.EADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2403 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:30:57 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10499; Thu, 26 Dec 1996 02:30:57 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:30:57 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260730.IAA25985@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:30:05 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"EyYOn.0.rX2.KcYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2434 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20835E1425DEC199607222042 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:22 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20835E1425DEC199607222042 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022F28D24DEC199605231520 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 05:23 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022F28D24DEC199605231520 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN >IF my understanding of the issues is correct than for two independent >implementations to work an agreement on how cleartext padding is done is >required. > >Possible solutions. > >1. Successful negotiation of SDP with ECPNCP implies that the receiver >will check for SDP padding in the clear text; it also requires the >transmitter to add SDP padding to the clear text before encryption. > This one is clearly wrong. SDP negotiation implies the ciphertext is padded. As you've pointed out, the problem is that the plain text must be padded. >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. This is the best solution. I suspect it was the actual intent of the RFC to "require" such padding in instances when it was needed. Any implementation which currently does this is in compliance with the RFC. > >3. Add a number of pad byte added byte to the ECP header as per my >previous note and require its use. > No, I actually prefer this solution. But anyone implementing it today would be in violation of the existing RFC. > > >Philip Rakity >FlowPoint >(408) 364-8300 > Bill Whelan % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id GAA14296 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 06:22:42 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id UAA05728 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 20:19:34 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id UAA19026 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 20:20:39 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA12309; Mon, 23 Dec 1996 14:01:16 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 14:01:16 -0500 (EST) % Date: Mon, 23 Dec 96 13:59:23 EST % From: "Whelan, Bill" % Message-Id: <9611238513.AA851378449@netx.nei.com> % To: ietf-ppp@MERIT.EDU % Subject: Re: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"NB_wt2.0.F03.xRjlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2374 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01961 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:53 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22580 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:01 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA10338 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:25:08 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03186; Wed, 25 Dec 1996 02:08:21 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:08:21 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250707.IAA00883@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:07:55 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"0K47k1.0.hn.aBDmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2409 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:29:57 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10220; Thu, 26 Dec 1996 02:29:57 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:29:57 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260729.IAA25914@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:29:31 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"tH__o3.0.NV2.mbYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2430 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022A5CF25DEC199607213046 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022A5CF25DEC199607213046 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2082B5E224DEC199604105111 UA content ID: STAC LZS Extended mode question Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 04:11 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2082B5E224DEC199604105111 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: STAC LZS Extended mode question Precedence: 1 To: WATERS@AM_MARVIN Does anyone know why protocol field compression is explicitly disallowed in extended mode. I can understand why one might not want to do PFC on the frame being compressed, but I cannot understand why the compressed frame must be sent without PFC if it has been negotiated. Eg Why not send 0xFD, itstead of 0x00FD as the PPP protocol Regards, Philip Rakity FlowPoint % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id FAA11883 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 05:10:12 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA16130 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:41:36 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA09262 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:42:42 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA14950; Mon, 23 Dec 1996 17:26:31 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 17:26:31 -0500 (EST) % Date: Mon, 23 Dec 1996 14:32:07 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: Rob Friend % Cc: ietf-ppp@MERIT.EDU % Subject: STAC LZS Extended mode question % In-Reply-To: <31338780@smtpgateway.stac.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"J3kF-.0.Xf3.MSmlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2376 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Rob Friend VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01889 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:59 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22415 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:07 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA10505 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:14 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02999; Wed, 25 Dec 1996 02:07:36 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:36 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250707.IAA00812@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:07:13 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"Pt0tT1.0.ok.sADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2407 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:29:40 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10182; Thu, 26 Dec 1996 02:29:40 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:29:40 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260728.IAA25822@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:29:10 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"mpeBc2.0.nU2.WbYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2429 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084F12B25DEC199607204973 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F12B25DEC199607204973 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20820CE024DEC199603232660 UA content ID: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:24 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20820CE024DEC199603232660 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN PMR wrote: :2. Make the RFC require that the clear text be expanded using SDP before : encryption. eg NO SDP negotiation is required. I wrote: }I am opposed to this; why should you penalize performance of routers any more }in the situations where you don't have to pad -- e.g. you are doing IPCP only }over a T1 or T3 line, but you chose to encrypt. Bill Whelan wrote: :I don't understand this objection. DES will require padding every time the :plain text is not a multiple of eight bytes. The only times SDP would add :unneeded padding is when the last byte of the ciphertext could be mistaken :for SDP padding (approximately 1 chance in 256). To which I respond: First, my intent was that SDP would be applied *before* encrypting. (Having the same model of a link-within-a-link that Multilink uses). so that Bill's statement should be "when the last byte of the plaintext could be mistaken" and the probability is a little more than just 1 in 256; you also have to check for terminating sequences 2 preceded by 1 or ... Thus, when SDP is in effect, you have to do a certain amount of computation per packet, and, in certain cases you have to add 8 more bytes, thus wasting bandwidth. As was asserted by me in the RFC, for a large class of protocols, SDP is wasted effort. If you are transporting vanilla IP packets, padding by garbage or zeroes works fine, because the packets have a built-in length indicator. Likewise for IPX. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA10121 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:22:53 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA21516 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:21:51 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id BAA21095 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:22:56 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA16588; Mon, 23 Dec 1996 19:06:58 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 19:06:58 -0500 (EST) % Date: Mon, 23 Dec 1996 16:05:37 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240005.QAA26016@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"1a3X11.0.734.Xwnlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2379 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01833 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:15 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22429 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:18 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA29654 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:25 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02866; Wed, 25 Dec 1996 02:07:04 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:04 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250706.IAA00784@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:06:41 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"IgGnl2.0.fi.NADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2404 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:24:00 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA09989; Thu, 26 Dec 1996 02:24:00 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:24:00 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260723.IAA25358@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:23:28 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"W6_4-2.0.mR2.BWYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2427 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20835E1425DEC199607194821 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:20 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20835E1425DEC199607194821 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20820CE024DEC199602591842 UA content ID: Re: DESE context issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 02:59 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20820CE024DEC199602591842 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE context issues Precedence: 1 To: WATERS@AM_MARVIN PMR wrote: 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. I wrote: I disagree. PMR wrote: Could you explain why you disagree? I think I might be missing something. To which I respond: While the consensus of the PPP comunity seems to be that it shouldn't matter *in which order* various options and protocols are negotiated, the consensus is far less clear that you aren't allowed to take survey after the negotiation process is complete. You can't transmit any encrypted Bridge data packets until both of ECP (with the DESE option) has completed, and the BCP has completed. You can't even negotiate *either* of ECP or BCP until LCP has completed, and SDP is (was) an LCP option. So, if SDP was not negotiated, you could issue a warning at the time the first encrypted bridge packet was sent. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA09211 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:58:44 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA22203 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:52:21 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id BAA13000 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:53:26 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA17234; Mon, 23 Dec 1996 19:37:22 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 19:37:22 -0500 (EST) % Date: Mon, 23 Dec 1996 16:36:01 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240036.QAA26076@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re: DESE context issues % Resent-Message-ID: <"WWc8T2.0.DD4.1Nolo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2380 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01772 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:19:20 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA21545 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:28 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA10702 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:35 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02701; Wed, 25 Dec 1996 02:06:24 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:06:24 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250705.IAA00731@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:05:57 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"ed0fh2.0.8g.l9Dmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2401 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:31:22 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10564; Thu, 26 Dec 1996 02:31:22 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:31:22 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260730.IAA26009@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:30:23 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"zZF8x2.0.GZ2.ccYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2436 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20835E1425DEC199607225446 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:23 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20835E1425DEC199607225446 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022D4B924DEC199606075570 UA content ID: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 06:08 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022D4B924DEC199606075570 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN Folks, Let me try to restate the problems as I see them and perhaps some solutions will be possible. 1. DES requires that the clear text be expanded to a multiple of 8 bytes before encryption. Eg The original data is expanded. 2. RFC 1969 does NOT explicitly pass the amount of this padding to the receiver. 3. Some protocols require that the original data size be recovered by the receiver inorder to process correctly the frame. Some examples are bridging and TCP/IP using VJ compression. (Perhaps IPX with header compression is in this catagory. 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. 5. Requesting the use of self described padding during ECPNCP negotiation states that the encrypted text is padded (NOT the plain text before encryption as per point 1. 6. For SDP to work it requires that the receiver receive what the sender believes has been sent. Eg there was no H/W padding of the data when the data was sent. Some folks have given examples of HDLC chips that pad out frame to be an even number of bytes. Since with SDP one looks are the last byte in the frame and checks if it is an SDP character and removes padding accordingly, any artifical pads would make SDP not work. IF my understanding of the issues is correct than for two independent implementations to work an agreement on how cleartext padding is done is required. Possible solutions. 1. Successful negotiation of SDP with ECPNCP implies that the receiver will check for SDP padding in the clear text; it also requires the transmitter to add SDP padding to the clear text before encryption. 2. Make the RFC require that the clear text be expanded using SDP before encryption. eg NO SDP negotiation is required. 3. Add a number of pad byte added byte to the ECP header as per my previous note and require its use. Philip Rakity FlowPoint (408) 364-8300 % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id HAA15603 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 07:07:22 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id SAA00952 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 18:47:00 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id SAA22402 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 18:48:04 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA10768; Mon, 23 Dec 1996 12:28:40 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 12:28:40 -0500 (EST) % Date: Mon, 23 Dec 1996 09:34:08 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: ietf-ppp@MERIT.EDU % Subject: RFC 1969 DES Encryption Issues % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"6lq2a3.0.7e2.75ilo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2372 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA02002 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:30 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA23012 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:35 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA06964 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:25:42 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03270; Wed, 25 Dec 1996 02:08:55 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:08:55 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250708.IAA00937@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:08:27 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"PpMyU.0.1p.5CDmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2411 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:31:18 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10557; Thu, 26 Dec 1996 02:31:18 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:31:18 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260730.IAA25998@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:30:16 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"K4RG5.0.vY2.XcYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2435 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084F12B25DEC199607215384 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:22 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F12B25DEC199607215384 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022E97F24DEC199604121993 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 04:12 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022E97F24DEC199604121993 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN Since the RFC does not completely define all the cases necessary to have independent implemenations really, there should be no problem with implementing either item 2) or 3) below. Item 2) is perhaps better as it keeps the basic format of the packets by simply requiring SDP be the method of padding the clear text, but considering the lack of implementations, I would prefer item 3). In addition, does anyone know if there were any independent implementations running before RFC 1969 was progressed to its current RFC status? Philip Rakity On Mon, 23 Dec 1996, Whelan, Bill wrote: > > >IF my understanding of the issues is correct than for two independent > >implementations to work an agreement on how cleartext padding is done is > >required. > > > >Possible solutions. > > > >1. Successful negotiation of SDP with ECPNCP implies that the receiver > >will check for SDP padding in the clear text; it also requires the > >transmitter to add SDP padding to the clear text before encryption. > > > This one is clearly wrong. SDP negotiation implies the ciphertext is > padded. As you've pointed out, the problem is that the plain text must be > padded. > > >2. Make the RFC require that the clear text be expanded using SDP before > >encryption. eg NO SDP negotiation is required. > > This is the best solution. I suspect it was the actual intent of the RFC > to "require" such padding in instances when it was needed. Any > implementation which currently does this is in compliance with the RFC. > > > >3. Add a number of pad byte added byte to the ECP header as per my > >previous note and require its use. > > > No, I actually prefer this solution. But anyone implementing it today > would be in violation of the existing RFC. > > > > > >Philip Rakity > >FlowPoint > >(408) 364-8300 > > > > Bill Whelan > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id FAA11949 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 05:11:42 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA16172 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:35:41 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA04885 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:36:46 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA14867; Mon, 23 Dec 1996 17:20:31 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 17:20:31 -0500 (EST) % Date: Mon, 23 Dec 1996 14:26:08 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: "Whelan, Bill" % Cc: ietf-ppp@MERIT.EDU % Subject: Re: RFC 1969 DES Encryption Issues % In-Reply-To: <9611238513.AA851378449@netx.nei.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"TpsZx2.0.Ee3.kMmlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2375 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: "Whelan, Bill" VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01915 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:19 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA23112 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:24 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA30113 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:31 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03044; Wed, 25 Dec 1996 02:07:50 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:50 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250707.IAA00827@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:07:22 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"ha_Yd2.0.Ql.2BDmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2408 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:31:27 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10577; Thu, 26 Dec 1996 02:31:27 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:31:27 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260730.IAA26022@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:30:30 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"axQ3d1.0.6a2.lcYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2437 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022A5CF25DEC199607225256 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:23 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022A5CF25DEC199607225256 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2020944E24DEC199605430392 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 05:43 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020944E24DEC199605430392 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN At 09:34 AM 12/23/96 -0800, Philip Rakity wrote: > >Folks, ... > >6. For SDP to work it requires that the receiver receive what the sender > believes has been sent. Eg there was no H/W padding of the data when the > data was sent. Some folks have given examples of HDLC chips that pad out > frame to be an even number of bytes. Since with SDP one looks are the > last byte in the frame and checks if it is an SDP character and removes > padding accordingly, any artifical pads would make SDP not work. > I would expect that any software running with such HDLC controllers would be aware of the controller's requirement, and could add SDP to an even number of bytes. > >IF my understanding of the issues is correct than for two independent >implementations to work an agreement on how cleartext padding is done is >required. Yes. > >Possible solutions. > >1. Successful negotiation of SDP with ECPNCP implies that the receiver >will check for SDP padding in the clear text; it also requires the >transmitter to add SDP padding to the clear text before encryption. This seems incomplete: it does not *require* SDP negotiation, nor say what is to be done if SDP is not negotiated. I think it also mixes SDP in an unnatural way with ECP. > >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. This is at least internally consistent and self-contained for ECP. > >3. Add a number of pad byte added byte to the ECP header as per my >previous note and require its use. I think this is the simplest, and therefore best, solution. > > > >Philip Rakity >FlowPoint >(408) 364-8300 > > > > -- Eric L. Michelsen, Copper Mountain Networks, Inc. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id GAA14859 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 06:42:31 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id TAA01716 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 19:07:08 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id TAA16827 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 19:08:13 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA11300; Mon, 23 Dec 1996 12:50:39 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 12:50:39 -0500 (EST) % Message-Id: <2.2.32.19961223175112.002fd56c@coppermountain.com> % X-Sender: "Eric Michelsen" % X-Mailer: Windows Eudora Pro Version 2.2 (32) % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Mon, 23 Dec 1996 09:51:12 -0800 % To: ietf-ppp@MERIT.EDU % From: "Eric L. Michelsen" % Subject: Re: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"KhBOE.0.Vm2.kPilo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2373 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01996 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:23 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22432 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:31 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA29048 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:25:38 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03224; Wed, 25 Dec 1996 02:08:41 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:08:41 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250708.IAA00910@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:08:14 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"zxYJG1.0.Jo.rBDmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2410 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:30:53 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10489; Thu, 26 Dec 1996 02:30:53 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:30:53 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260729.IAA25963@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:29:57 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"FH0sA.0.cX2.HcYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2433 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2020AC9125DEC199607212732 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020AC9125DEC199607212732 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022D54624DEC199603494990 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:50 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022D54624DEC199603494990 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN From ietf-ppp-request@MERIT.EDU Mon Dec 23 09:32:27 1996 Resent-Date: Mon, 23 Dec 1996 12:29:06 -0500 (EST) Date: Mon, 23 Dec 1996 09:34:08 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: ietf-ppp@MERIT.EDU Subject: RFC 1969 DES Encryption Issues Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2372 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Folks, Let me try to restate the problems as I see them and perhaps some solutions will be possible. 1. DES requires that the clear text be expanded to a multiple of 8 bytes before encryption. Eg The original data is expanded. Yes. 2. RFC 1969 does NOT explicitly pass the amount of this padding to the receiver. Yes. 3. Some protocols require that the original data size be recovered by the receiver inorder to process correctly the frame. Some examples are bridging If you were bridging 802.3, only then it has a length field. and TCP/IP using VJ compression. (Perhaps IPX with header compression is in this catagory. 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. I disagree. 5. Requesting the use of self described padding during ECPNCP negotiation states that the encrypted text is padded (NOT the plain text before encryption as per point 1. That was not my understanding when I proposed the RFC. 6. For SDP to work it requires that the receiver receive what the sender believes has been sent. Eg there was no H/W padding of the data when the data was sent. Some folks have given examples of HDLC chips that pad out frame to be an even number of bytes. Since with SDP one looks are the last byte in the frame and checks if it is an SDP character and removes padding accordingly, any artifical pads would make SDP not work. The only hardware issues that I was aware of where even/odd. Certainly PFC says you *may* omit the leading 0 but are *not required* to. You can force a PPP packet to be of even length by chosing whether or not to include the leading 0. IF my understanding of the issues is correct than for two independent implementations to work an agreement on how cleartext padding is done is required. Possible solutions. 1. Successful negotiation of SDP with ECPNCP implies that the receiver will check for SDP padding in the clear text; it also requires the transmitter to add SDP padding to the clear text before encryption. This is certainly what I had in mind, and I think that the RFC editor/process should allow clarifications of original intent. 2. Make the RFC require that the clear text be expanded using SDP before encryption. eg NO SDP negotiation is required. I am opposed to this; why should you penalize performance of routers any more in the situations where you don't have to pad -- e.g. you are doing IPCP only over a T1 or T3 line, but you chose to encrypt. 3. Add a number of pad byte added byte to the ECP header as per my previous note and require its use. DESE is not the end-all and be all of encryption protocols. Propose another one, and include your explicit padding byte there. Use triple DES or md5 or whatever you like, but just assign a different code; we've only assigned 2 code points of a possbile 255. Philip Rakity FlowPoint (408) 364-8300 Keith Sklower University of CA, Berkeley (510) 642 9587 % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA11118 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:49:14 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA18373 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:19:51 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA10580 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:20:56 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA15654; Mon, 23 Dec 1996 18:04:46 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 18:04:46 -0500 (EST) % Date: Mon, 23 Dec 1996 15:03:25 -0800 (PST) % From: Keith Sklower % Message-Id: <199612232303.PAA25819@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU, pmr@flowpoint.com % Subject: Re: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"x4AzW2.0.Xq3.D0nlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2377 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU, pmr@flowpoint.com Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01884 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:56 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22551 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:04 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA22826 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:11 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02947; Wed, 25 Dec 1996 02:07:28 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:28 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250707.IAA00799@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:07:02 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"hLt9e1.0.-j.iADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2406 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 02:30:31 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10367; Thu, 26 Dec 1996 02:30:31 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 02:30:31 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612260729.IAA25947@vbormc.vbo.dec.com> Date: Thu, 26 Dec 96 08:29:49 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"KoVM-1.0.7X2.BcYmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2432 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084CD3D25DEC199607205549 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084CD3D25DEC199607205549 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022D54524DEC199603452701 UA content ID: Re[2]: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:46 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022D54524DEC199603452701 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[2]: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. > >I am opposed to this; why should you penalize performance of routers any more >in the situations where you don't have to pad -- e.g. you are doing IPCP only >over a T1 or T3 line, but you chose to encrypt. I don't understand this objection. DES will require padding every time the plain text is not a multiple of eight bytes. The only times SDP would add unneeded padding is when the last byte of the ciphertext could be mistaken for SDP padding (approximately 1 chance in 256). >Keith Sklower >University of CA, Berkeley >(510) 642 9587 Bill Whelan % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA10923 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:44:56 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA19025 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:40:12 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA12809 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:41:18 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA15956; Mon, 23 Dec 1996 18:25:19 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 18:25:19 -0500 (EST) % Date: Mon, 23 Dec 96 18:24:09 EST % From: "Whelan, Bill" % Message-Id: <9611238513.AA851394289@netx.nei.com> % To: ietf-ppp@MERIT.EDU, pmr@flowpoint.com % Subject: Re[2]: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"DSI201.0.Bv3.UJnlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2378 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU, pmr@flowpoint.com Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01849 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:24 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA21385 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:27 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA21018 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:34 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02897; Wed, 25 Dec 1996 02:07:11 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:11 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250706.IAA00794@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:06:49 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"k7ugI1.0.9j.TADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2405 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 14:31:55 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA15011; Thu, 26 Dec 1996 14:31:55 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 14:31:55 -0500 (EST) From: "Steven A. Bade" Message-Id: <199612261930.NAA35074@r1100rs.austin.ibm.com> Subject: PPP testing at connectathon 97 To: ietf-ppp@MERIT.EDU Date: Thu, 26 Dec 1996 13:30:58 -0600 (CST) Cc: audrey@avbconsulting.com (Audrey Van Belleghem) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"JjJyF1.0.xf3.8Ajmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2438 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU To date I have recieved only one other indication of interest in doing PPP interoperability testing at connectathon. As this takes a significant amount of time to coordinate and plan if there is no other interest I'm going to suggest to the connectathon planners that the technology be removed from the event. The proposed (note anything can be tested) PPP technologies to be tested are. 1. Async Multilink 2. Fundamental ISDN support (not to be confused with the California ISDN Users Group testing which requires that Multilink be functioning). 2a. ISDN Multilink. 3. IP V6 over PPP support (I'd be interested in how many are interested in this particular item). 4. Compression (Stac, BSD, Predictor... any others that can be done between attendees). this is the short list, any function that testing is desired is possible assuming that 2 implementations attend. -- Steven A. Bade -- IBM Risc 6000 Division WAN Communications Software Engineer bade@austin.ibm.com ** All opinions are my own.. ** (512)838-8207 (T/L 678) Fax (512)838-3509 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 14:47:35 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA15149; Thu, 26 Dec 1996 14:47:35 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 14:47:35 -0500 (EST) Date: Thu, 26 Dec 1996 11:53:01 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: "Eric L. Michelsen" Cc: ietf-ppp@MERIT.EDU Subject: re: SDP In-Reply-To: <2.2.32.19961225003645.002fcd90@coppermountain.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-Message-ID: <"D3H6J1.0.Mi3.IPjmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2439 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Many thanks for the clarification on how one uses SDP. I was completely mislead by what I read in RFC 1570. So, to rephrase the rules. 1. If an NCP needs SDP, negotiate SDP using LCP. 2. NCPs use SDP as needed. Each NCP knows if it needs SDP and this information is implicit; no negotiation is used. Is there any point in having a section in the front of each new RFC that applies stating that this RFC uses SDP or not; eg a section similar to security aspects? Philip Rakity FlowPoint On Tue, 24 Dec 1996, Eric L. Michelsen wrote: > SDP is negotiated with LCP, and only LCP, per RFC-1570. I think some > confusion may arise, though, because of the wording of sec 2.2, par 2: > > "This option is most likely to be used when some protocols, such as > network-layer or compression protocols, are configured which > require detection and removal of any trailing padding. SUCH > SPECIAL PROTOCOLS ARE IDENTIFIED IN THEIR RESPECTIVE DOCUMENTS." > > (Emphasis added). I take this to mean that any protocol which requires > information field length preservation must say so in its defining RFC. > Bridging Control Protocol (RFC-1638) makes a passing reference to SDP (sec > 4.2, subsec "Optional Data Link Layer Padding", par 2), but if you blink you > might miss it. > > So RFC-1570 defines a "special protocol" as one requiring length > preservation. Then sec 2.2, par 4 says that an implementation "MUST follow > the procedures for adding self-describing pads, but only to the specifically > identified [i.e., "special"] protocols. The [implementation] is not > required to add any padding to other protocols." > > So one doesn't negotiate SDP for each NCP, but if negotiated, one MUST use > SDP only on "special" protocols. On other protocols, you are free to not > pad, regardless of whether SDP was negotiated. > > This whole concept seems like a subtle point, buried in RFC-1570, and often > forgotten when other NCP RFCs are written. Even BCP's reference to SDP is > fairly terse, and easily missed. I haven't checked the CCP or ECP specs to > see if they identify themselves as "special" in the RFC-1570 sense. > -- > Eric L. Michelsen, Copper Mountain Networks, Inc. > > - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 16:51:29 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id QAA15995; Thu, 26 Dec 1996 16:51:29 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 16:51:29 -0500 (EST) Message-Id: <2.2.32.19961226215204.00301c78@coppermountain.com> X-Sender: "Eric Michelsen" X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 26 Dec 1996 13:52:04 -0800 To: ietf-ppp@MERIT.EDU From: "Eric L. Michelsen" Subject: re: SDP Resent-Message-ID: <"a-pvF3.0.cv3.TDlmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2440 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU At 11:53 AM 12/26/96 -0800, Philip Rakity wrote: > ... >Is there any point in having a section in the front of each new RFC that >applies stating that this RFC uses SDP or not; eg a section similar to >security aspects? I think this is a good idea for NCP RFCs. I also think that RFC-1570's (i.e., PPP's) requirement for NCPs to identify themselves as needing SDP or not ought to be amplified in the PPP standard itself, in sec 2, "Padding". In fact, it would be helpful if all of RFC-1570 were included in the next version of PPP. > > > Philip Rakity >FlowPoint -- Eric L. Michelsen, Copper Mountain Networks, Inc. - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Thu Dec 26 17:01:28 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA16149; Thu, 26 Dec 1996 17:01:28 -0500 (EST) Resent-Date: Thu, 26 Dec 1996 17:01:28 -0500 (EST) Posted-Date: Thu, 26 Dec 1996 13:59:39 -0800 (PST) Date: Thu, 26 Dec 1996 16:59:37 -0500 From: eallen@BayNetworks.COM (Ed Allen) Message-Id: <199612262159.QAA21713@pobox.engeast.BayNetworks.COM> To: bade@austin.ibm.com Cc: ietf-ppp@MERIT.EDU, audrey@avbconsulting.com, dhaskin@pobox In-Reply-To: <199612261930.NAA35074@r1100rs.austin.ibm.com> (bade@austin.ibm.com) Subject: Re: PPP testing at connectathon 97 Resent-Message-ID: <"K-ty61.0.0y3.qMlmo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2441 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Steven, Bay will be attending. We're interested in interoperability testing of IPv6 over PPP. Thanks, - Ed >>>>> Steven A Bade writes: SAB> To date I have recieved only one other indication of interest SAB> in doing PPP interoperability testing at connectathon. As this SAB> takes a significant amount of time to coordinate and plan if there SAB> is no other interest I'm going to suggest to the connectathon planners SAB> that the technology be removed from the event. SAB> The proposed (note anything can be tested) PPP technologies to be SAB> tested are. SAB> 1. Async Multilink SAB> 2. Fundamental ISDN support (not to be confused with the California ISDN SAB> Users Group testing which requires that Multilink be functioning). SAB> 2a. ISDN Multilink. SAB> 3. IP V6 over PPP support (I'd be interested in how many are interested SAB> in this particular item). SAB> 4. Compression (Stac, BSD, Predictor... any others that can be done SAB> between attendees). SAB> this is the short list, any function that testing is desired is possible SAB> assuming that 2 implementations attend. SAB> -- SAB> Steven A. Bade -- IBM Risc 6000 Division SAB> WAN Communications Software Engineer SAB> bade@austin.ibm.com ** All opinions are my own.. ** SAB> (512)838-8207 (T/L 678) Fax (512)838-3509 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:27:13 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21052; Fri, 27 Dec 1996 10:27:13 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:27:13 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271526.QAA00382@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:26:31 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"W4K4N3.0.V85.Ch-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2444 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G202348B525DEC199617021581 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 17:02 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G202348B525DEC199617021581 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084F90624DEC199616433873 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 16:44 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F90624DEC199616433873 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN > From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) > ... > I am coming round (belatedly) to the technique of prepending sufficient zeros > (prior to > encryption) to complete a cypher block and to ensure that the length can be > unambiguously > determined. This is a simple, effective, unambiguous, no-brainer way of > fixing the length of > a packet - and at no additioanl cost in terms of packet length.. > l.. Do you mean the hack--er, technique of extending the "inner" PPP protocol number with leading zeros? Besides being optimally dense (using exactly the minimal padding) and denser than self-describing padding, that technique has a major non-technical advantage. It prevents confusion among implementors and users between the SDP required by DES and inside the encryption from the other SDP that can simultaneously be present outside the encryption to cater to the (I hope) mythical braindead HDLC chips. The DES padding would be of zeros, while the LCP padding would be SDP. What is the overall size of an ECP data packet? The info field has a length of 0(mod 8) thanks to the DES block size. If address, control, and protocol field compressions are negotiated by LCP, then I think the HDLC packet will have a length of 3(mod 8) (counting the FCS) and so require SDP. But I suppose the braindead HDLC chips that require SDP did not do handle address and control filed compression, making the length 5(mod 8)--assuming they did protocol field compression. Did they? Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA08036 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 17:43:11 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA00946 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 17:45:19 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id RAA29966 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 17:46:25 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA25260; Tue, 24 Dec 1996 11:30:30 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 11:30:30 -0500 (EST) % Date: Tue, 24 Dec 1996 09:30:20 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612241630.JAA16311@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"FrhZ01.0.dA6.cK0mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2389 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id SAA20548 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 18:01:49 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id SAA01170 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 18:03:54 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id SAA28303 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 18:05:02 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA05477; Wed, 25 Dec 1996 11:48:52 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 11:48:52 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612251648.RAA20227@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 17:48:31 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"XTnnb2.0.WL1.phLmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2415 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:27:02 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21012; Fri, 27 Dec 1996 10:27:02 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:27:02 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271525.QAA00342@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:25:49 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"l_XBm1.0.R75.Xg-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2442 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2085704725DEC199616024174 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 16:02 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2085704725DEC199616024174 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022A5A224DEC199615425709 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 15:43 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022A5A224DEC199615425709 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN >As was asserted by me in the RFC, for a large class of protocols, >SDP is wasted effort. If you are transporting vanilla IP packets, >padding by garbage or zeroes works fine, because the packets have >a built-in length indicator. Likewise for IPX. I must admit when we wrote the DESE RFC, never having come across hardware which required SDP, I didn't think that SDP would in practise be required within DESE. S o I didn't think a great deal about it at the time. In my view the problem with SDP is that it is ill-defined as to which packets it should be applied/removed ; and you have to negotiate it before you know if you will need it. In short, I don't like it. I am coming round (belatedly) to the technique of prepending sufficient zeros (prior to encryption) to complete a cypher block and to ensure that the length can be unambiguously determined. This is a simple, effective, unambiguous, no-brainer way of fixing the length of a packet - and at no additioanl cost in terms of packet length.. Does anyone object to this technique now? Gerry % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA05649 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:42:32 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA30948 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:44:41 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id QAA20807 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:45:47 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA24230; Tue, 24 Dec 1996 10:29:06 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 10:29:06 -0500 (EST) % From: gerry@europe.shiva.com (CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva) % To: sklower@CS.Berkeley.EDU (Keith Sklower) % Cc: Ietf-Ppp@MERIT.EDU (Ietf-Ppp) % Message-ID: <1996Dec24.142534.1281.343716@eurohub.europe.shiva.com> % X-Conversion-ID: % X-Mailer: Lotus Notes via PostalUnion/SMTP for Windows NT % Mime-Version: 1.0 % Content-Type: text/plain; charset="US-ASCII" % Date: Tue, 24 Dec 1996 15:26:57 GMT % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"t4Uz-2.0.Xw5.1R_lo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2387 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: sklower@CS.Berkeley.EDU (Keith Sklower) VMSmail CC information: Ietf-Ppp@MERIT.EDU (Ietf-Ppp) Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA18631 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 17:02:13 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA32026 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 17:04:20 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id RAA02801 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 17:05:27 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA05103; Wed, 25 Dec 1996 10:48:23 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 10:48:23 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612251547.QAA18297@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 16:47:52 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"fwlMq3.0.gF1.6pKmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2413 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:26:59 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21007; Fri, 27 Dec 1996 10:26:59 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:26:59 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271526.QAA00357@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:26:08 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"nA_PI3.0.t75.pg-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2443 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20833C8025DEC199616122468 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 16:12 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20833C8025DEC199616122468 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084700824DEC199615544715 UA content ID: I-D ACTION:draft-ietf-pppext-l2tp-01.txt Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 15:55 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084700824DEC199615544715 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: I-D ACTION:draft-ietf-pppext-l2tp-01.txt Precedence: 1 To: WATERS@AM_MARVIN --NextPart A Revised 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 : Layer Two Tunneling Protocol "L2TP" Author(s) : K. Hamzeh, T. Kolar, M. Littlewood, G. Pall, J. Taarud, A. Valencia, W. Verthein Filename : draft-ietf-pppext-l2tp-01.txt Pages : 75 Date : 12/23/1996 Virtual dial-up allows many separate and autonomous protocol domains to share common access infrastructure including modems, Access Servers, and ISDN routers. RFC1661 specifies multiprotocol dial-up via PPP [1]. This document describes the Layer Two Tunneling Protocol (L2TP) which permits the tunneling of the link layer (i.e., HDLC, async HDLC) of PPP. Using such tunnels, it is possible to divorce the location of the initial dial-up server from the location at which the dial-up protocol connection is terminated and access to the network provided. Internet-Drafts are 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-l2tp-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-pppext-l2tp-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-pppext-l2tp-01.txt". NOTE: The mail server at ds.internic.net 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@ds.internic.net" Content-Type: text/plain Content-ID: <19961223135209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-pppext-l2tp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-pppext-l2tp-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961223135209.I-D@ietf.org> --OtherAccess-- --NextPart-- % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA06016 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:54:21 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id QAA32036 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:56:27 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id QAA00408 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 16:57:30 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA24372; Tue, 24 Dec 1996 10:41:28 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 10:41:28 -0500 (EST) % 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-l2tp-01.txt % Date: Tue, 24 Dec 1996 09:47:13 -0500 % Sender: cclark@ietf.org % Message-ID: <9612240947.aa07207@ietf.org> % Resent-Message-ID: <"WFEPR3.0.hy5.dc_lo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2388 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: IETF-Announce:; VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA19125 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 17:11:52 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id RAA31500 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 17:13:59 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id RAA04694 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 17:15:07 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA05218; Wed, 25 Dec 1996 10:58:54 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 10:58:54 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612251558.QAA18551@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 16:58:26 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"nwuDj.0.PH1.-yKmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2414 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:29:54 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21180; Fri, 27 Dec 1996 10:29:54 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:29:54 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271529.QAA00602@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:29:18 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"DkrTH3.0.dA5.ij-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2447 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G202339CC25DEC199620524147 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 20:52 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G202339CC25DEC199620524147 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022EA7E24DEC199620363887 UA content ID: re: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 20:37 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022EA7E24DEC199620363887 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: re: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN > From: Philip Rakity > ... > Concerning SDP negotiation, the implemenation note in section 2.2 states > that > > "To avoid unnecessary configuration handshakes, an implementation which > generates padding, and has a protocol configured which requires padding > to be known, SHOULD include this option in its Configuration-Request, and > SHOULD Configure-Nak with this Option when it is not present in the > peer's Request." > > I took this to mean that SDP was negotiated on each NCP that required > it (no need to do LCP negotiation). I do not understand that reasoning. How do you negotiate SDP on an NCP? > Is the rule for using SDP the following. > > 1. Negotiate its general availability using LCP. > 2. Negotiate the specific protocols that use SDP on each NCP #1 makes sense. I do not understand #2. How can you negotiate SDP for a single NCP? You cannot put the SDP option into a Configure-Request for any NCP. You can put the SDP option into <<>> an LCP Configure-Request. After the Configure-Ack for SDP, how would either PPP peer know which NCP needs SDP and which does not? > ... > As Bill Whelan mentioned before, SDP is a link-level option. > When it's negotiated and be used in context with ECP, > it should be applied _twice_ to the received data: > - One time for the received packet/fragment > - One time for the unencrypted packet. How can there be any alternative, given a cypher with a fixed block size of 8 and data without its own length? Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA14509 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:36:09 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA08834 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:38:15 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id VAA30713 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:39:22 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA28501; Tue, 24 Dec 1996 15:22:16 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 15:22:16 -0500 (EST) % Date: Tue, 24 Dec 1996 13:22:03 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612242022.NAA17560@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: re: Real life ECP example % Resent-Message-ID: <"o31aE2.0.Cz6.tj3mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2392 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA27473 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 21:52:09 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA03548 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 21:54:17 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id VAA10899 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 21:55:25 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA06649; Wed, 25 Dec 1996 15:39:23 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 15:39:23 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612252039.VAA27136@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 21:39:02 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"IYhlS2.0.jd1.w3Pmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2418 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:29:40 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21140; Fri, 27 Dec 1996 10:29:40 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:29:40 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271529.QAA00591@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:29:05 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"yqX_w1.0.x95.Uj-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2446 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084EE1C25DEC199620481192 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 20:48 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084EE1C25DEC199620481192 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084722724DEC199620283754 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 20:29 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084722724DEC199620283754 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN I like this method of prepending 0's to the protocol field before encryption to ensure the size is a multiple of 8. However, the STAC LZS RFC explicitly states that the protocol field is 2 bytes (0x00FD) long when option 4 (extended mode) has been negotiated. Eg I cannot remove one of the bytes of get to a multiple of 8. Philip Rakity FlowPoint On Tue, 24 Dec 1996, CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva wrote: > >As was asserted by me in the RFC, for a large class of protocols, > >SDP is wasted effort. If you are transporting vanilla IP packets, > >padding by garbage or zeroes works fine, because the packets have > >a built-in length indicator. Likewise for IPX. > > I must admit when we wrote the DESE RFC, never having come across hardware > which required SDP, I didn't think that SDP would in practise be required > within DESE. > S o I didn't think a great deal about it at the time. > In my view the problem with SDP is that it is ill-defined as to which packets > it should be > applied/removed ; and you have to negotiate it before you know if you will > need it. > In short, I don't like it. > > I am coming round (belatedly) to the technique of prepending sufficient zeros > (prior to > encryption) to complete a cypher block and to ensure that the length can be > unambiguously > determined. This is a simple, effective, unambiguous, no-brainer way of > fixing the length of > a packet - and at no additioanl cost in terms of packet length.. > > Does anyone object to this technique now? > > Gerry > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA14322 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:28:12 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA08690 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:30:20 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id VAA31798 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:31:26 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA28410; Tue, 24 Dec 1996 15:13:46 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 15:13:46 -0500 (EST) % Date: Tue, 24 Dec 1996 10:32:42 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@royal % To: CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva % Cc: Keith Sklower , Ietf-Ppp % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % In-Reply-To: <1996Dec24.142534.1281.343716@eurohub.europe.shiva.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"x_-eA3.0.rx6.wb3mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2391 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: CN=Gerry Meyer/OU=Eng/OU=EDI/O=Shiva VMSmail CC information: Keith Sklower , Ietf-Ppp Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA27373 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 21:47:48 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA03898 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 21:49:57 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id VAA25588 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 21:51:05 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA06559; Wed, 25 Dec 1996 15:35:07 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 15:35:07 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612252034.VAA27057@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 21:34:45 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"l9VyA1.0.Qc1.w_Omo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2417 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:31:04 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21223; Fri, 27 Dec 1996 10:31:04 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:31:04 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271530.QAA00656@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:30:20 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"qtjld2.0.HB5.ok-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2448 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20834A6225DEC199621133003 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 21:13 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20834A6225DEC199621133003 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2023205124DEC199620534672 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 20:54 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2023205124DEC199620534672 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN > From: Philip Rakity > I like this method of prepending 0's to the protocol field before > encryption to ensure the size is a multiple of 8. However, the STAC LZS > RFC explicitly states that the protocol field is 2 bytes (0x00FD) long > when option 4 (extended mode) has been negotiated. Eg I cannot remove > one of the bytes of get to a multiple of 8. So what? Why would you want to pad the bits inside STAC LZS type 4? I get irritated with people blindly following the layering religion, but this is a case when layering must be considered. There are three protocol fields: 1. The outer-most protocol field specifies ECP. The size of this protocol field is <<>> specified by ECP nor by LZS. The size of this protocol field is determined only from the LCP negotiation. No matter what ECP and/or LZS want or say, the LCP protocol field is beyond their ken. 2. The middle protocol field tells ECP the protocol of the inner-most protocol. This protocol is 0xfd when compression is being used. The size of this protocol field is determined ONLY by the ECP standard. Neither LZS nor LCP have anything to say about the size of this protocol field. 3. The innermost protocol filed tells LZS the protocol of the real data. This size of this protocol field is determined by the LZS CCP standard. LCP and ECP have nothing to say about the size of this protocol field. You must pad #1 or use SDP if and only if your HDLC hardware is braindead, regardless of whether you are using LZS and/or ECP. If you do not have stupid HDLC hardware, there is no reason to pad #2 or #3. #3 has nothing to do ECP. LZS must figure out the correct length of VJ-header compressed packets before delivering them to the VJ-decompressor regardless of whether you are using ECP #2 is the only protocol field at issue. Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA14884 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:53:19 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id VAA08199 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:55:23 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id VAA14427 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 21:56:30 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA28624; Tue, 24 Dec 1996 15:39:23 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 15:39:23 -0500 (EST) % Date: Tue, 24 Dec 1996 13:39:12 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612242039.NAA17611@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"i1Jkn1.0.B_6.wz3mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2393 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id WAA28038 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 22:13:02 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id WAA04611 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 22:15:09 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id WAA30610 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 22:16:17 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id PAA06828; Wed, 25 Dec 1996 16:00:00 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 16:00:00 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612252059.VAA27652@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 21:59:39 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"T5lpo3.0.dg1.FNPmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2419 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:29:34 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21110; Fri, 27 Dec 1996 10:29:34 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:29:34 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271528.QAA00574@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:28:46 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"vUvkA3.0.P95.Nj-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2445 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20852CB025DEC199619130732 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 19:13 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20852CB025DEC199619130732 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084F90624DEC199618551751 UA content ID: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 18:55 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F90624DEC199618551751 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN The real life example comes from our testing with Holger using encryption with TCP/IP and VJ compression (No CCP). Neither of us were able to get telnet to receive the correct data either when talking with ourselves or with each other. See below for the explanation. Concerning SDP negotiation, the implemenation note in section 2.2 states that "To avoid unnecessary configuration handshakes, an implementation which generates padding, and has a protocol configured which requires padding to be known, SHOULD include this option in its Configuration-Request, and SHOULD Configure-Nak with this Option when it is not present in the peer's Request." I took this to mean that SDP was negotiated on each NCP that required it (no need to do LCP negotiation). Is the rule for using SDP the following. 1. Negotiate its general availability using LCP. 2. Negotiate the specific protocols that use SDP on each NCP Philip Rakity FlowPoint ---------- Forwarded message ---------- Date: Fri, 20 Dec 1996 14:55:04 +0100 (MET) From: Holger Kummert To: ietf-ppp@MERIT.EDU Subject: ECP-padding and VanJacobson Hello, we found another point concerning padding in ECP: When transmitting VJ-compressed TCP/IP-packets, the content of the field "total length" in the IP-Header will be computed on the receiver's site as the sum of the length of the TCP/IP-Header (exactly reconstructed) and the length of the TCP-Data (including ECP-padding). So it's impossible for the receiver to reconstruct the original length of the packet unless someone will tell him (e.g. SDP). rfc1144 says: One can scavenge a few more bytes by noting that any reasonable link-level framing protocol will tell the receiver the length of a received message so total length (bytes 2 and 3) is redundant. So should this be mentioned in a revision of RFC1969, if there will be one? Another question: As Bill Whelan mentioned before, SDP is a link-level option. When it's negotiated and be used in context with ECP, it should be applied _twice_ to the received data: - One time for the received packet/fragment - One time for the unencrypted packet. Is this the intention of SDP? If not I would like an extension of RFC1969 according to Philip Rakity's suggestion. Many thanks, Holger Kummert -- Holger Kummert email: kummert@conware.de Conware Computer Consulting GmbH www: http://www.conware.de/ Killisfeldstrasse 64 Tel.: +49 721 9495-0 D-76227 Karlsruhe/Germany % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id TAA12039 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 19:54:48 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id TAA04954 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 19:56:56 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id TAA06173 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 19:58:02 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA27169; Tue, 24 Dec 1996 13:42:03 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 13:42:03 -0500 (EST) % Date: Tue, 24 Dec 1996 10:27:40 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@royal % To: sklower@CS.Berkeley.EDU % Cc: ietf-ppp@MERIT.EDU % Subject: Real life ECP example % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"cDWbQ.0.Se6.wF2mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2390 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: sklower@CS.Berkeley.EDU VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id UAA24094 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 20:12:44 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id UAA01264 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 20:14:52 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id UAA19252 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 20:16:00 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA06051; Wed, 25 Dec 1996 13:59:50 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 13:59:50 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612251859.TAA23843@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 19:59:29 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"eCrBH.0.UU1.bcNmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2416 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:34:52 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21477; Fri, 27 Dec 1996 10:34:52 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:34:52 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271533.QAA00883@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:34:01 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"z6Ejd2.0.GF5.Mo-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2450 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G20230DC225DEC199623355439 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 23:36 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20230DC225DEC199623355439 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084F90624DEC199623151992 UA content ID: re: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 23:15 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F90624DEC199623151992 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: re: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN > From: Philip Rakity > One can add to the configure request the option for SDP. > > Eg Option 10, length 3. as per the LCP extensions RFC, thus informing the > remote that one is able to receive SDP. I do not understand those words. To what Configure-Request are you adding the SDP option? If you are adding to an LCP Configure-Request, then what does it have to do with any single NCP? (Nothing, by my lights.) > I do not understand how one implements the statement I quoted from the > RFC below unless one sends the request for SDP on each NCP that needs it. > > So, > > Exactly how does one negotiate SDP on a per protocol basis ??? You do not negotiate SDP on a per protocol basis, because by design it cannot be done. > ... > > > Concerning SDP negotiation, the implemenation note in section 2.2 states > > > that > > > > > > "To avoid unnecessary configuration handshakes, an implementation which > > > generates padding, and has a protocol configured which requires padding > > > to be known, SHOULD include this option in its Configuration-Request, and > > > SHOULD Configure-Nak with this Option when it is not present in the > > > peer's Request." > > > > > > I took this to mean that SDP was negotiated on each NCP that required > > > it (no need to do LCP negotiation). There is nothing in those words that say or suggest anything about negotiating SDP on a per protocol basis. Those words say you SHOULD turn on SDP if you might need it. They don't say you should turn it on partially if you need it only partially. I think the rest of us take RFC 1570 to be about LCP extensions instead of network protocols, and to be saying "If your HDLC hardware is braindead and requires padding, and if your system anticipates sending any network protocols that lack their own lengths (e.g.bly bridging and IP with VJ-header compression), then you SHOULD cause your LCP code to negotiate self-describing padding for all PPP packets (of course with the usual exceptions--control packets which may or may not be padded at the sender's whim)." I think the rest of us would also agree that you MAY renegoiate SDP on or off if your anticipations turn out to be wrong, but that renegotiating anything with LCP tends to stumble on broken PPP implementations. Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA17998 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:14:53 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA11886 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:17:00 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA15872 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:18:06 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA00457; Tue, 24 Dec 1996 18:02:16 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 18:02:16 -0500 (EST) % Date: Tue, 24 Dec 1996 16:02:05 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612242302.QAA18152@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: re: Real life ECP example % Resent-Message-ID: <"scMLa2.0.47.t36mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2397 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA03291 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:35:25 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA06115 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:37:33 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA31185 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:38:41 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA07748; Wed, 25 Dec 1996 18:21:11 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 18:21:11 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612252320.AAA02757@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 00:20:45 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"UBuH1.0._u1.cRRmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2423 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:36:12 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21589; Fri, 27 Dec 1996 10:36:12 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:36:12 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271535.QAA00931@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:35:09 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"9lmob1.0.iG5.Yp-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2451 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2085543026DEC199601083118 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 01:08 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2085543026DEC199601083118 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084EA5525DEC199600492739 UA content ID: re: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 00:49 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084EA5525DEC199600492739 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: re: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN SDP is negotiated with LCP, and only LCP, per RFC-1570. I think some confusion may arise, though, because of the wording of sec 2.2, par 2: "This option is most likely to be used when some protocols, such as network-layer or compression protocols, are configured which require detection and removal of any trailing padding. SUCH SPECIAL PROTOCOLS ARE IDENTIFIED IN THEIR RESPECTIVE DOCUMENTS." (Emphasis added). I take this to mean that any protocol which requires information field length preservation must say so in its defining RFC. Bridging Control Protocol (RFC-1638) makes a passing reference to SDP (sec 4.2, subsec "Optional Data Link Layer Padding", par 2), but if you blink you might miss it. So RFC-1570 defines a "special protocol" as one requiring length preservation. Then sec 2.2, par 4 says that an implementation "MUST follow the procedures for adding self-describing pads, but only to the specifically identified [i.e., "special"] protocols. The [implementation] is not required to add any padding to other protocols." So one doesn't negotiate SDP for each NCP, but if negotiated, one MUST use SDP only on "special" protocols. On other protocols, you are free to not pad, regardless of whether SDP was negotiated. This whole concept seems like a subtle point, buried in RFC-1570, and often forgotten when other NCP RFCs are written. Even BCP's reference to SDP is fairly terse, and easily missed. I haven't checked the CCP or ECP specs to see if they identify themselves as "special" in the RFC-1570 sense. -- Eric L. Michelsen, Copper Mountain Networks, Inc. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA20296 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 01:48:52 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA14979 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 01:51:00 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id BAA00640 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 01:52:05 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA00998; Tue, 24 Dec 1996 19:36:07 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 19:36:07 -0500 (EST) % Message-Id: <2.2.32.19961225003645.002fcd90@coppermountain.com> % X-Sender: "Eric Michelsen" % X-Mailer: Windows Eudora Pro Version 2.2 (32) % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Tue, 24 Dec 1996 16:36:45 -0800 % To: ietf-ppp@MERIT.EDU % From: "Eric L. Michelsen" % Subject: re: Real life ECP example % Resent-Message-ID: <"ZogfI1.0.TF.rR7mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2398 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id CAA07054 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 02:08:02 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id CAA06700 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 02:10:10 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id CAA06094 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 02:11:18 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA08086; Wed, 25 Dec 1996 19:51:38 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 19:51:38 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260051.BAA05961@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 01:51:14 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"mvTWf3.0.D-1.PmSmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2424 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:32:25 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21277; Fri, 27 Dec 1996 10:32:25 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:32:25 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271531.QAA00728@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:31:25 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"GJRJJ.0.6C5.3m-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2449 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2023393A25DEC199623031434 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 23:03 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2023393A25DEC199623031434 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2020AC9124DEC199622444345 UA content ID: re: Real life ECP example Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 22:45 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020AC9124DEC199622444345 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: re: Real life ECP example Precedence: 1 To: WATERS@AM_MARVIN One can add to the configure request the option for SDP. Eg Option 10, length 3. as per the LCP extensions RFC, thus informing the remote that one is able to receive SDP. I do not understand how one implements the statement I quoted from the RFC below unless one sends the request for SDP on each NCP that needs it. So, Exactly how does one negotiate SDP on a per protocol basis ??? Philip Rakity FlowPoint On Tue, 24 Dec 1996, Vernon Schryver wrote: > > From: Philip Rakity > > > ... > > Concerning SDP negotiation, the implemenation note in section 2.2 states > > that > > > > "To avoid unnecessary configuration handshakes, an implementation which > > generates padding, and has a protocol configured which requires padding > > to be known, SHOULD include this option in its Configuration-Request, and > > SHOULD Configure-Nak with this Option when it is not present in the > > peer's Request." > > > > I took this to mean that SDP was negotiated on each NCP that required > > it (no need to do LCP negotiation). > > I do not understand that reasoning. > How do you negotiate SDP on an NCP? > > > > Is the rule for using SDP the following. > > > > 1. Negotiate its general availability using LCP. > > 2. Negotiate the specific protocols that use SDP on each NCP > > #1 makes sense. > > I do not understand #2. How can you negotiate SDP for a single NCP? > You cannot put the SDP option into a Configure-Request for any NCP. > You can put the SDP option into <<>> an LCP Configure-Request. > After the Configure-Ack for SDP, how would either PPP peer know which > NCP needs SDP and which does not? > > > > ... > > As Bill Whelan mentioned before, SDP is a link-level option. > > When it's negotiated and be used in context with ECP, > > it should be applied _twice_ to the received data: > > - One time for the received packet/fragment > > - One time for the unencrypted packet. > > How can there be any alternative, given a cypher with a fixed block > size of 8 and data without its own length? > > > Vernon Schryver, vjs@sgi.com > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA17309 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:44:09 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA11084 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:46:18 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA16553 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:47:24 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA29758; Tue, 24 Dec 1996 17:31:33 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 17:31:33 -0500 (EST) % Date: Tue, 24 Dec 1996 14:37:08 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: Vernon Schryver % Cc: ietf-ppp@MERIT.EDU % Subject: re: Real life ECP example % In-Reply-To: <199612242022.NAA17560@mica.denver.sgi.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"4BxtT2.0.vG7.4d5mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2395 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Vernon Schryver VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA01908 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:02:47 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA05459 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:04:55 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA10375 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:06:03 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA07509; Wed, 25 Dec 1996 17:49:51 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 17:49:51 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612252249.XAA01398@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 23:49:30 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"6k2xZ.0.Gr1.E-Qmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2421 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:37:43 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21715; Fri, 27 Dec 1996 10:37:43 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:37:43 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271536.QAA00982@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:36:35 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"GwNUm3.0.-I5.zq-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2453 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2081408626DEC199607370784 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:37 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2081408626DEC199607370784 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20835E1425DEC199607194821 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:20 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20835E1425DEC199607194821 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20820CE024DEC199602591842 UA content ID: Re: DESE context issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 02:59 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20820CE024DEC199602591842 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE context issues Precedence: 1 To: WATERS@AM_MARVIN PMR wrote: 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. I wrote: I disagree. PMR wrote: Could you explain why you disagree? I think I might be missing something. To which I respond: While the consensus of the PPP comunity seems to be that it shouldn't matter *in which order* various options and protocols are negotiated, the consensus is far less clear that you aren't allowed to take survey after the negotiation process is complete. You can't transmit any encrypted Bridge data packets until both of ECP (with the DESE option) has completed, and the BCP has completed. You can't even negotiate *either* of ECP or BCP until LCP has completed, and SDP is (was) an LCP option. So, if SDP was not negotiated, you could issue a warning at the time the first encrypted bridge packet was sent. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA09211 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:58:44 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA22203 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:52:21 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id BAA13000 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:53:26 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA17234; Mon, 23 Dec 1996 19:37:22 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 19:37:22 -0500 (EST) % Date: Mon, 23 Dec 1996 16:36:01 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240036.QAA26076@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re: DESE context issues % Resent-Message-ID: <"WWc8T2.0.DD4.1Nolo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2380 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01772 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:19:20 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA21545 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:28 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA10702 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:35 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02701; Wed, 25 Dec 1996 02:06:24 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:06:24 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250705.IAA00731@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:05:57 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"ed0fh2.0.8g.l9Dmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2401 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA26608 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:36:43 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA12410 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:38:52 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA28977 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:40:00 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA09973; Thu, 26 Dec 1996 02:23:56 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:23:56 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260723.IAA25358@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:23:28 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"W6_4-2.0.mR2.BWYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2427 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:39:31 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21809; Fri, 27 Dec 1996 10:39:31 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:39:31 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271538.QAA01123@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:38:25 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"16cVh3.0.MK5.ds-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2454 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022820926DEC199607433984 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:43 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022820926DEC199607433984 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084CD3D25DEC199607205549 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084CD3D25DEC199607205549 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022D54524DEC199603452701 UA content ID: Re[2]: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:46 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022D54524DEC199603452701 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[2]: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. > >I am opposed to this; why should you penalize performance of routers any more >in the situations where you don't have to pad -- e.g. you are doing IPCP only >over a T1 or T3 line, but you chose to encrypt. I don't understand this objection. DES will require padding every time the plain text is not a multiple of eight bytes. The only times SDP would add unneeded padding is when the last byte of the ciphertext could be mistaken for SDP padding (approximately 1 chance in 256). >Keith Sklower >University of CA, Berkeley >(510) 642 9587 Bill Whelan % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA10923 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:44:56 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA19025 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:40:12 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA12809 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:41:18 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA15956; Mon, 23 Dec 1996 18:25:19 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 18:25:19 -0500 (EST) % Date: Mon, 23 Dec 96 18:24:09 EST % From: "Whelan, Bill" % Message-Id: <9611238513.AA851394289@netx.nei.com> % To: ietf-ppp@MERIT.EDU, pmr@flowpoint.com % Subject: Re[2]: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"DSI201.0.Bv3.UJnlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2378 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU, pmr@flowpoint.com Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01849 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:24 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA21385 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:27 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA21018 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:34 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02897; Wed, 25 Dec 1996 02:07:11 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:11 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250706.IAA00794@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:06:49 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"k7ugI1.0.9j.TADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2405 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA27286 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:43:18 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA12811 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:45:27 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA16976 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:46:36 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10318; Thu, 26 Dec 1996 02:30:21 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:30:21 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260729.IAA25947@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:29:49 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"KoVM-1.0.7X2.BcYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2432 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:36:58 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21668; Fri, 27 Dec 1996 10:36:58 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:36:58 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271535.QAA00952@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:35:48 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"mUmbk.0.EI5.Iq-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2452 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G202309EE26DEC199607370166 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:37 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G202309EE26DEC199607370166 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20835E1425DEC199607193573 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:19 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20835E1425DEC199607193573 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20820CE024DEC199602520368 UA content ID: Re: DESE context issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 02:52 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20820CE024DEC199602520368 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE context issues Precedence: 1 To: WATERS@AM_MARVIN At 05:17 PM 12/23/96 -0800, Philip Rakity wrote: >Keith, > >SDP is allowed to be independently Bnegotiated on each NCP according to the >LCP extensions RFC. I don't see this. RFC-1570 says that SDP is negotiated with LCP, but MUST be provided only to those NCPs which identify themselves as requiring detection and removal of trailing padding. I don't see that you can separately negotiate SDP on each NCP. >... -- Eric L. Michelsen, Copper Mountain Networks, Inc. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA08950 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:51:38 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA26944 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:53:47 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id DAA00976 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:54:52 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA19099; Mon, 23 Dec 1996 21:38:00 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 21:38:00 -0500 (EST) % Message-Id: <2.2.32.19961224023834.00302798@coppermountain.com> % X-Sender: "Eric Michelsen" % X-Mailer: Windows Eudora Pro Version 2.2 (32) % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Mon, 23 Dec 1996 18:38:34 -0800 % To: ietf-ppp@MERIT.EDU % From: "Eric L. Michelsen" % Subject: Re: DESE context issues % Resent-Message-ID: <"LiStF.0.Ig4.78qlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2384 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01754 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:19:06 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22561 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:11 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA03619 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:18 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02663; Wed, 25 Dec 1996 02:05:57 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:05:57 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250705.IAA00701@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:05:31 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"oIJ0r.0.Yf.L9Dmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2400 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA26597 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:36:38 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA12175 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:38:47 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA10199 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:39:55 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA09934; Thu, 26 Dec 1996 02:23:36 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:23:36 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260723.IAA25333@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:23:13 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"Irg511.0.9R2.tVYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2426 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:40:23 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA21895; Fri, 27 Dec 1996 10:40:23 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:40:23 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271539.QAA01238@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:39:52 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"aAIuj2.0.mL5.Yt-mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2455 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G208520A926DEC199607430575 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:43 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G208520A926DEC199607430575 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022A5CF25DEC199607213046 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022A5CF25DEC199607213046 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2082B5E224DEC199604105111 UA content ID: STAC LZS Extended mode question Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 04:11 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2082B5E224DEC199604105111 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: STAC LZS Extended mode question Precedence: 1 To: WATERS@AM_MARVIN Does anyone know why protocol field compression is explicitly disallowed in extended mode. I can understand why one might not want to do PFC on the frame being compressed, but I cannot understand why the compressed frame must be sent without PFC if it has been negotiated. Eg Why not send 0xFD, itstead of 0x00FD as the PPP protocol Regards, Philip Rakity FlowPoint % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id FAA11883 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 05:10:12 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA16130 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:41:36 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA09262 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:42:42 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA14950; Mon, 23 Dec 1996 17:26:31 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 17:26:31 -0500 (EST) % Date: Mon, 23 Dec 1996 14:32:07 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: Rob Friend % Cc: ietf-ppp@MERIT.EDU % Subject: STAC LZS Extended mode question % In-Reply-To: <31338780@smtpgateway.stac.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"J3kF-.0.Xf3.MSmlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2376 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Rob Friend VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01889 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:59 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22415 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:07 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA10505 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:14 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02999; Wed, 25 Dec 1996 02:07:36 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:36 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250707.IAA00812@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:07:13 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"Pt0tT1.0.ok.sADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2407 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA27214 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:42:41 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA11833 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:44:50 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA03565 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:45:58 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10204; Thu, 26 Dec 1996 02:29:53 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:29:53 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260729.IAA25914@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:29:31 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"tH__o3.0.NV2.mbYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2430 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:59:03 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA22329; Fri, 27 Dec 1996 10:59:03 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:59:03 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271558.QAA02319@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:58:31 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"mWqJH1.0.aS5.29_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2456 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2085554D25DEC199622584829 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 22:59 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2085554D25DEC199622584829 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2085598624DEC199622395620 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 22:40 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2085598624DEC199622395620 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN Sorry about the incomplete paraphrase of the STAC LZS RFC. To be exact, the statement is (section 5.1) When a compression protocol is successfully negotiated by the PPP compression control protocol, the value is hex 00FD. Protocol field compression MUST NOT be used on this value when extended mode is negotiated on the link, even if protocol field compression was successfully negotiated before data compression. From this statement, I take it that I must pass to the decompressor code a 2 byte protocol id of 0x00FD, whether or not I have been using ECP. Similarly, I must send these two bytes inside the ECP packet since I would have sent these bytes on the wire if ECP was not negotiated. I believe that the requirement in the RFC to ignore PFC negotation rules is a bad choice, but my opinion is NOT what is in the STAC LZS RFC. See below for responses. Philip Rakity FlowPoint On Tue, 24 Dec 1996, Vernon Schryver wrote: > > From: Philip Rakity > > > I like this method of prepending 0's to the protocol field before > > encryption to ensure the size is a multiple of 8. However, the STAC LZS > > RFC explicitly states that the protocol field is 2 bytes (0x00FD) long > > when option 4 (extended mode) has been negotiated. Eg I cannot remove > > one of the bytes of get to a multiple of 8. > > So what? Why would you want to pad the bits inside STAC LZS type 4? Since the cleartext must be a multiple of 8 bytes for DES encryption to work, the cleartext must be padded. It can be padded at the end using SDP or as was suggested by someone else, it could be padded in the front by prepending 0's to the protocol value. If the cleartext was 1 byte too long for DES encryption and the protocol being encrypted was CCP LZS, than one could remove the 00 byte from the protocol id (0x00FD), however this is NOT allowed according to the RFC if extended mode was negotiated. > > I get irritated with people blindly following the layering religion, > but this is a case when layering must be considered. > > There are three protocol fields: > > 1. The outer-most protocol field specifies ECP. > The size of this protocol field is <<>> specified by ECP > nor by LZS. The size of this protocol field is determined only > from the LCP negotiation. No matter what ECP and/or LZS want > or say, the LCP protocol field is beyond their ken. Really? Is the STAC LZS RFC wrong in saying that PFC does not apply. > > 2. The middle protocol field tells ECP the protocol of the inner-most > protocol. This protocol is 0xfd when compression is being used. > The size of this protocol field is determined ONLY by the ECP > standard. Neither LZS nor LCP have anything to say about the size > of this protocol field. If PFC was not negotiated implicitly or explicitly, I thought that it was NOT allowed to apply PFC. Where in the RFCs does it say you can PFC compress protocol id's when PFC was not negotiated. Note: A reasonable implemenation should ALWAYS be able to decode PFC, but I am taking about what the RFC says, not what is reasonable. PPP requires PFC be negotiated, while MLP implies that it has been implicitly agreed to. > > 3. The innermost protocol filed tells LZS the protocol of the real > data. This size of this protocol field is determined by the LZS > CCP standard. LCP and ECP have nothing to say about the size of > this protocol field. > > You must pad #1 or use SDP if and only if your HDLC hardware is > braindead, regardless of whether you are using LZS and/or ECP. If you > do not have stupid HDLC hardware, there is no reason to pad #2 or #3. > > #3 has nothing to do ECP. LZS must figure out the correct length of > VJ-header compressed packets before delivering them to the VJ-decompressor > regardless of whether you are using ECP > > #2 is the only protocol field at issue. > We agree. > > Vernon Schryver, vjs@sgi.com > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA17212 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:39:22 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA12147 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:41:30 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA26590 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 23:42:37 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA29395; Tue, 24 Dec 1996 17:26:43 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 17:26:43 -0500 (EST) % Date: Tue, 24 Dec 1996 14:32:20 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: Vernon Schryver % Cc: ietf-ppp@MERIT.EDU % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % In-Reply-To: <199612242039.NAA17611@mica.denver.sgi.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"QRmIj2.0.AB7.YY5mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2394 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Vernon Schryver VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA01713 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 23:58:19 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA05195 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:00:26 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA09439 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:01:34 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA07331; Wed, 25 Dec 1996 17:45:29 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 17:45:29 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612252245.XAA01232@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 23:45:07 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"UjbtJ1.0.Uo1.8wQmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2420 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 10:59:18 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id KAA22368; Fri, 27 Dec 1996 10:59:18 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 10:59:18 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271558.QAA02336@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:58:45 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"GcPmQ2.0.AT5.I9_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2457 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G208121A725DEC199623241994 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 23:24 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G208121A725DEC199623241994 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2020AC9124DEC199623050667 UA content ID: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 23:05 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020AC9124DEC199623050667 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN > From: Philip Rakity > Sorry about the incomplete paraphrase of the STAC LZS RFC. To be exact, > the statement is (section 5.1) > > When a compression protocol is successfully negotiated by the PPP > compression control protocol, the value is hex 00FD. Protocol field > compression MUST NOT be used on this value when extended mode is > negotiated on the link, even if protocol field compression was > successfully negotiated before data compression. > > >From this statement, I take it that I must pass to the decompressor code > a 2 byte protocol id of 0x00FD, whether or not I have been using ECP. > Similarly, I must send these two bytes inside the ECP packet since I > would have sent these bytes on the wire if ECP was not negotiated. > > I believe that the requirement in the RFC to ignore PFC negotation rules > is a bad choice, but my opinion is NOT what is in the STAC LZS RFC. > ... Instead of that, I hope that the LZS RFC wording is muddled, that it is refering to both protocol fields in that quoted paragraph, that the first sentence says the protocol number in the 1st byte or bytes after the address and control fields (if any) that begin the packet are 0x00fd or 0xfd, while the second protocol field after the Coherency Count is always two bytes. That hope is consistent with the penultimate sentence in section 5.1 of RFC 1974 which is clearly talking about the inner protocol number. See also sections 2 and 2.5.1 that say the 0x00fd can be compressed to 0xfd. On the other hand, I vaguely seem to recall talk about limitations in early versions of Stac Electronics hardware couldn't handle some alignments or maybe it was protocol field compression. Isn't Type 4 or Extended mode the old, deprecated version? Isn't Type 3 the required mode, and because of sections 2 and 2.5.1 of RFC 1974, 0xfd compressable if and only if LCP says it is? > ... > > 2. The middle protocol field tells ECP the protocol of the inner-most > > protocol. This protocol is 0xfd when compression is being used. > > The size of this protocol field is determined ONLY by the ECP > > standard. Neither LZS nor LCP have anything to say about the size > > of this protocol field. > > If PFC was not negotiated implicitly or explicitly, I thought that it was > NOT allowed to apply PFC. Where in the RFCs does it say you can PFC > compress protocol id's when PFC was not negotiated. Note: A reasonable > implemenation should ALWAYS be able to decode PFC, but I am taking about > what the RFC says, not what is reasonable. PPP requires PFC be > negotiated, while MLP implies that it has been implicitly agreed to. I did not say that protocol field compression can be done willy-nilly, but that how the 0xfd of LZS is handled is not a matter for LCP to determine. Just as with MP (RFC 1717), whether address, control, and protocol field compression is negoiated with LCP Configure-Requests is irrelevant to what happens elsewhere. LCP Configure-Requests control the first 1-4 bytes of the packet on the wire. Other bytes are controlled otherwise. (Yes, I know of the suggestion that to preserve byte alignment and reduce implementor confusion, the inner protocol field of MP packets should be padded with zeros depending on whether LCP protocol field compression has not been negotiated.) Vernon Schryver, vjs@sgi.com % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA17755 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:04:41 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA13010 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:06:49 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA01197 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 00:07:56 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA00183; Tue, 24 Dec 1996 17:51:56 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 17:51:56 -0500 (EST) % Date: Tue, 24 Dec 1996 15:51:44 -0700 % From: vjs@mica.denver.sgi.com (Vernon Schryver) % Message-Id: <199612242251.PAA18099@mica.denver.sgi.com> % To: ietf-ppp@MERIT.EDU % Subject: Re: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"Ux5B83.0.o2.Bw5mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2396 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA02882 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:23:56 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA06162 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:26:02 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA21273 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 00:27:10 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA07652; Wed, 25 Dec 1996 18:10:35 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 18:10:35 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612252310.AAA02279@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 00:10:13 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"bYD7i3.0.Rt1.gHRmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2422 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 11:00:09 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA22519; Fri, 27 Dec 1996 11:00:09 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 11:00:09 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271559.QAA02380@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:59:26 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"eEFL63.0.QV5.3A_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2458 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022FE4326DEC199602513377 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 02:51 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022FE4326DEC199602513377 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084EA5525DEC199602305768 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 02:31 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084EA5525DEC199602305768 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2082D27A24DEC199602091431 UA content ID: Re[2]: DESE context Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 02:09 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2082D27A24DEC199602091431 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[2]: DESE context Precedence: 1 To: WATERS@AM_MARVIN Philip Rakity writes: SDP is allowed to be independently Bnegotiated on each NCP according to the LCP extensions RFC. But the point is mute since SDP is not negotiated in the context of 1969 since the plain text is padded not the encrypted text. The issue I have with the way the RFC as currently defined is that it allows two implementations to NOT work together without bilateral agreement as to whether SDP was applied to the clear text before encryption is applied. To which I respond: Now it's my turn to say that I don't understand and may be missing something. Could you supply a sample negotation and example packets which have been encoded by one side and decoding by the other in a non-interoperable way? While I admit that I had overlooked the following paragraph in 1570, my interpretation is that not that "SDP is .. independently negotatied on each NCP", but rather SDP is negotiated *ONCE* and each NCP standard specifies whether or not SDP is to be applied to packets in that protocol *if it had been negotiated at the LCP level at all*: Quotation from [Page 8] of RFC 1570, second through fourth paragraphs of section 2.2 under Description: This option is most likely to be used when some protocols, such as network-layer or compression protocols, are configured which require detection and removal of any trailing padding. Such special protocols are identified in their respective documents. If the option is Rejected, the peer MUST NOT add any padding to the identified special protocols, but MAY add padding to other protocols. If the option is Ack'd, the peer MUST follow the procedures for adding self-describing pads, but only to the specifically identified protocols. The peer is not required to add any padding to other protocols. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA08005 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:08:49 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA24791 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:10:58 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id DAA02136 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 03:12:03 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA18305; Mon, 23 Dec 1996 20:56:12 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 20:56:12 -0500 (EST) % Date: Mon, 23 Dec 1996 17:54:51 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240154.RAA26278@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re[2]: DESE context % Resent-Message-ID: <"BxmJi2.0.yT4.xWplo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2383 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA23286 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 03:30:31 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA18830 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 03:32:38 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id DAA32194 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 03:33:45 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA01418; Tue, 24 Dec 1996 21:17:42 -0500 (EST) % Resent-Date: Tue, 24 Dec 1996 21:17:42 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250217.DAA22985@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 03:17:14 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"tiimU.0.5M.5x8mo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2399 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA11316 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 03:51:04 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id DAA09094 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 03:53:11 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id DAA09656 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 03:54:19 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA08561; Wed, 25 Dec 1996 21:38:01 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 21:38:01 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260237.DAA10748@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 03:37:38 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"hjUSR.0.i52.8KUmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2425 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 11:01:03 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA22647; Fri, 27 Dec 1996 11:01:03 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 11:01:03 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271600.RAA02450@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 17:00:32 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"iPnvF1.0.YX5.xA_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2461 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022820926DEC199607432368 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:43 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022820926DEC199607432368 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2020AC9125DEC199607203676 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020AC9125DEC199607203676 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022E96F24DEC199603054477 UA content ID: Re: DESE padding, before and after Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:06 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022E96F24DEC199603054477 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE padding, before and after Precedence: 1 To: WATERS@AM_MARVIN Inspired by Vern's contribution, let me see if I can make this all a bit clearer. Revising history a little bit (being previously unaware that there was not a blanket requirement to uniformly pad *all* packets, but only those whose NCP's said that SDP applied to them), what I had intended to say in RFC1969 was: "If any NCP is negotiated on the link which specifies the use of SDP for prevervation of the interpretation of its data packets in the face of padding, then SDP MUST be negotiated as an LCP option, and SDP must be used to pad the plaintext to be a length which is a multiple of 8 bytes as specified in the corresponding NCP spec." The phrase "it should only be used when absolutely necessary", should have been "it should only be negotiated when absolutely necessary". If SDP has been negotiated and multilink has been negotiated, and DESE is encrypting the multilink headers, then SDP removal should only be done on fragments bearing the (E)nd bit, as is specified in the multilink document under Padding considerations there. As far as Vern's observation that we need to concern ourselves not only about the padding of the payload for DESE, but possibly padding the complete DESE "data" packet for hardware considerations (Unless you want to negotiate encrypting for both below and above the multilink arrange mean --- arghghghghghg!!!! ) and as noted in RFC1969, the payload is already a multiple of 8 bytes, so it is pretty easy to acheive even/oddness without the use of SDP. As far as permitting leading zero insertion/removal as a means of padding to 8 bytes - I think its a good idea, and thought it was a good idea back when we were discussing DESE, but don't know what the IETF rules are at this point. DESE is *not* standards track; its merely informational (and was partially intended to be illustrative of how to specify a "bearer" protocol for ECP in the same way that there are many compression "bearer" protocols which use CCP. I don't recall anybody besides flowpoint having reported implementing it... % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA09463 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:05:14 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA27513 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:07:20 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id EAA16319 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:08:25 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id VAA19448; Mon, 23 Dec 1996 21:52:14 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 21:52:14 -0500 (EST) % Date: Mon, 23 Dec 1996 18:50:53 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240250.SAA26403@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re: DESE padding, before and after % Resent-Message-ID: <"-5yKo3.0.pl4.TLqlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2385 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01822 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:02 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22796 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:09 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA32226 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:16 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02813; Wed, 25 Dec 1996 02:06:57 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:06:57 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250706.IAA00774@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:06:34 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"xE7R72.0.rh.EADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2403 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA27243 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:42:59 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA12374 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:45:08 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA30484 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:46:15 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10242; Thu, 26 Dec 1996 02:30:04 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:30:04 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260729.IAA25936@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:29:39 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"WcLMA3.0.zV2.wbYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2431 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 11:02:27 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA22860; Fri, 27 Dec 1996 11:02:27 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 11:02:27 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271601.RAA02521@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 17:01:48 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"5Xlm82.0.na5.7C_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2466 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2084CCAF26DEC199607444734 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:45 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084CCAF26DEC199607444734 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20835E1425DEC199607225446 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:23 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20835E1425DEC199607225446 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022D4B924DEC199606075570 UA content ID: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 06:08 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022D4B924DEC199606075570 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN Folks, Let me try to restate the problems as I see them and perhaps some solutions will be possible. 1. DES requires that the clear text be expanded to a multiple of 8 bytes before encryption. Eg The original data is expanded. 2. RFC 1969 does NOT explicitly pass the amount of this padding to the receiver. 3. Some protocols require that the original data size be recovered by the receiver inorder to process correctly the frame. Some examples are bridging and TCP/IP using VJ compression. (Perhaps IPX with header compression is in this catagory. 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. 5. Requesting the use of self described padding during ECPNCP negotiation states that the encrypted text is padded (NOT the plain text before encryption as per point 1. 6. For SDP to work it requires that the receiver receive what the sender believes has been sent. Eg there was no H/W padding of the data when the data was sent. Some folks have given examples of HDLC chips that pad out frame to be an even number of bytes. Since with SDP one looks are the last byte in the frame and checks if it is an SDP character and removes padding accordingly, any artifical pads would make SDP not work. IF my understanding of the issues is correct than for two independent implementations to work an agreement on how cleartext padding is done is required. Possible solutions. 1. Successful negotiation of SDP with ECPNCP implies that the receiver will check for SDP padding in the clear text; it also requires the transmitter to add SDP padding to the clear text before encryption. 2. Make the RFC require that the clear text be expanded using SDP before encryption. eg NO SDP negotiation is required. 3. Add a number of pad byte added byte to the ECP header as per my previous note and require its use. Philip Rakity FlowPoint (408) 364-8300 % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id HAA15603 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 07:07:22 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id SAA00952 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 18:47:00 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id SAA22402 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 18:48:04 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA10768; Mon, 23 Dec 1996 12:28:40 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 12:28:40 -0500 (EST) % Date: Mon, 23 Dec 1996 09:34:08 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: ietf-ppp@MERIT.EDU % Subject: RFC 1969 DES Encryption Issues % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"6lq2a3.0.7e2.75ilo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2372 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA02002 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:30 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA23012 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:35 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA06964 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:25:42 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03270; Wed, 25 Dec 1996 02:08:55 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:08:55 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250708.IAA00937@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:08:27 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"PpMyU.0.1p.5CDmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2411 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA27393 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:44:25 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA11756 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:46:33 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA01501 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:47:40 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10454; Thu, 26 Dec 1996 02:30:51 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:30:51 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260730.IAA26009@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:30:23 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"zZF8x2.0.GZ2.ccYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2436 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 11:01:42 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA22736; Fri, 27 Dec 1996 11:01:42 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 11:01:42 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271600.RAA02475@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 17:01:03 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"RD2Pi1.0.lY5.TB_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2463 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022820926DEC199607443907 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:44 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022820926DEC199607443907 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084F12B25DEC199607215384 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:22 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F12B25DEC199607215384 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022E97F24DEC199604121993 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 04:12 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022E97F24DEC199604121993 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN Since the RFC does not completely define all the cases necessary to have independent implemenations really, there should be no problem with implementing either item 2) or 3) below. Item 2) is perhaps better as it keeps the basic format of the packets by simply requiring SDP be the method of padding the clear text, but considering the lack of implementations, I would prefer item 3). In addition, does anyone know if there were any independent implementations running before RFC 1969 was progressed to its current RFC status? Philip Rakity On Mon, 23 Dec 1996, Whelan, Bill wrote: > > >IF my understanding of the issues is correct than for two independent > >implementations to work an agreement on how cleartext padding is done is > >required. > > > >Possible solutions. > > > >1. Successful negotiation of SDP with ECPNCP implies that the receiver > >will check for SDP padding in the clear text; it also requires the > >transmitter to add SDP padding to the clear text before encryption. > > > This one is clearly wrong. SDP negotiation implies the ciphertext is > padded. As you've pointed out, the problem is that the plain text must be > padded. > > >2. Make the RFC require that the clear text be expanded using SDP before > >encryption. eg NO SDP negotiation is required. > > This is the best solution. I suspect it was the actual intent of the RFC > to "require" such padding in instances when it was needed. Any > implementation which currently does this is in compliance with the RFC. > > > >3. Add a number of pad byte added byte to the ECP header as per my > >previous note and require its use. > > > No, I actually prefer this solution. But anyone implementing it today > would be in violation of the existing RFC. > > > > > >Philip Rakity > >FlowPoint > >(408) 364-8300 > > > > Bill Whelan > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id FAA11949 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 05:11:42 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id XAA16172 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:35:41 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id XAA04885 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 23:36:46 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id RAA14867; Mon, 23 Dec 1996 17:20:31 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 17:20:31 -0500 (EST) % Date: Mon, 23 Dec 1996 14:26:08 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@zeus % To: "Whelan, Bill" % Cc: ietf-ppp@MERIT.EDU % Subject: Re: RFC 1969 DES Encryption Issues % In-Reply-To: <9611238513.AA851378449@netx.nei.com> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"TpsZx2.0.Ee3.kMmlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2375 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: "Whelan, Bill" VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01915 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:19 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA23112 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:24 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA30113 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:31 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03044; Wed, 25 Dec 1996 02:07:50 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:50 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250707.IAA00827@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:07:22 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"ha_Yd2.0.Ql.2BDmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2408 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA27374 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:44:17 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA13178 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:46:26 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA07864 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:47:34 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10433; Thu, 26 Dec 1996 02:30:44 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:30:44 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260730.IAA25998@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:30:16 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"K4RG5.0.vY2.XcYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2435 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 11:00:31 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA22566; Fri, 27 Dec 1996 11:00:31 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 11:00:31 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271559.QAA02409@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 16:59:52 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"yPb601.0.GW5.QA_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2459 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2081408626DEC199607372030 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:37 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2081408626DEC199607372030 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084F12B25DEC199607202524 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:20 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F12B25DEC199607202524 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022E96F24DEC199603004857 UA content ID: Re: DESE context issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:01 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022E96F24DEC199603004857 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: DESE context issues Precedence: 1 To: WATERS@AM_MARVIN Keith, SDP is allowed to be independently Bnegotiated on each NCP according to the LCP extensions RFC. But the point is mute since SDP is not negotiated in the context of 1969 since the plain text is padded not the encrypted text. The issue I have with the way the RFC as currently defined is that it allows two implementations to NOT work together without bilateral agreement as to whether SDP was applied to the clear text before encryption is applied. Philip Rakity FlowPoint Corporation On Mon, 23 Dec 1996, Keith Sklower wrote: > PMR wrote: > 4. Since the NCPs are negotiated in parallel, ECPNCP does not know > what options have been negotiated by the other NCPs. > > I wrote: > > I disagree. > > > PMR wrote: > > > Could you explain why you disagree? I think I might be missing something. > > To which I respond: > > While the consensus of the PPP comunity seems to be that it shouldn't > matter *in which order* various options and protocols are negotiated, > the consensus is far less clear that you aren't allowed to take survey > after the negotiation process is complete. > > You can't transmit any encrypted Bridge data packets until both of > ECP (with the DESE option) has completed, and the BCP has completed. > > You can't even negotiate *either* of ECP or BCP until LCP has completed, > and SDP is (was) an LCP option. > > So, if SDP was not negotiated, you could issue a warning at the time > the first encrypted bridge packet was sent. > > % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA09276 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:00:09 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id CAA23622 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 02:46:41 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id CAA09653 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 02:47:46 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id UAA17737; Mon, 23 Dec 1996 20:31:34 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 20:31:34 -0500 (EST) % Date: Mon, 23 Dec 1996 17:17:15 -0800 (PST) % From: Philip Rakity % X-Sender: pmr@royal % To: Keith Sklower % Cc: ietf-ppp@MERIT.EDU % Subject: Re: DESE context issues % In-Reply-To: <199612240036.QAA26076@vangogh.CS.Berkeley.EDU> % Message-Id: % Mime-Version: 1.0 % Content-Type: TEXT/PLAIN; charset=US-ASCII % Resent-Message-ID: <"fQgPQ2.0.4L4.s9plo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2381 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: Keith Sklower VMSmail CC information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01800 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:19:51 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22698 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:53 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA08956 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:00 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02770; Wed, 25 Dec 1996 02:06:47 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:06:47 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250706.IAA00758@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:06:20 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"-XNAu1.0.Bh.5ADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2402 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA26640 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:36:59 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA12932 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:39:08 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA26147 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:40:14 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10048; Thu, 26 Dec 1996 02:24:13 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:24:13 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260723.IAA25389@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:23:48 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"Hq5TA2.0.tS2.SWYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2428 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 11:02:14 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA22826; Fri, 27 Dec 1996 11:02:14 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 11:02:14 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271601.RAA02511@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 17:01:33 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"uv52n.0.Ha5.yB_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2465 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G208520A926DEC199607444284 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:44 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G208520A926DEC199607444284 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022A5CF25DEC199607225256 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:23 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022A5CF25DEC199607225256 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2020944E24DEC199605430392 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 05:43 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020944E24DEC199605430392 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN At 09:34 AM 12/23/96 -0800, Philip Rakity wrote: > >Folks, ... > >6. For SDP to work it requires that the receiver receive what the sender > believes has been sent. Eg there was no H/W padding of the data when the > data was sent. Some folks have given examples of HDLC chips that pad out > frame to be an even number of bytes. Since with SDP one looks are the > last byte in the frame and checks if it is an SDP character and removes > padding accordingly, any artifical pads would make SDP not work. > I would expect that any software running with such HDLC controllers would be aware of the controller's requirement, and could add SDP to an even number of bytes. > >IF my understanding of the issues is correct than for two independent >implementations to work an agreement on how cleartext padding is done is >required. Yes. > >Possible solutions. > >1. Successful negotiation of SDP with ECPNCP implies that the receiver >will check for SDP padding in the clear text; it also requires the >transmitter to add SDP padding to the clear text before encryption. This seems incomplete: it does not *require* SDP negotiation, nor say what is to be done if SDP is not negotiated. I think it also mixes SDP in an unnatural way with ECP. > >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. This is at least internally consistent and self-contained for ECP. > >3. Add a number of pad byte added byte to the ECP header as per my >previous note and require its use. I think this is the simplest, and therefore best, solution. > > > >Philip Rakity >FlowPoint >(408) 364-8300 > > > > -- Eric L. Michelsen, Copper Mountain Networks, Inc. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id GAA14859 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 06:42:31 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id TAA01716 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 19:07:08 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id TAA16827 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 19:08:13 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id MAA11300; Mon, 23 Dec 1996 12:50:39 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 12:50:39 -0500 (EST) % Message-Id: <2.2.32.19961223175112.002fd56c@coppermountain.com> % X-Sender: "Eric Michelsen" % X-Mailer: Windows Eudora Pro Version 2.2 (32) % Mime-Version: 1.0 % Content-Type: text/plain; charset="us-ascii" % Date: Mon, 23 Dec 1996 09:51:12 -0800 % To: ietf-ppp@MERIT.EDU % From: "Eric L. Michelsen" % Subject: Re: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"KhBOE.0.Vm2.kPilo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2373 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01996 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:23 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22432 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:31 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA29048 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:25:38 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03224; Wed, 25 Dec 1996 02:08:41 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:08:41 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250708.IAA00910@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:08:14 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"zxYJG1.0.Jo.rBDmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2410 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA27382 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:44:20 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA12755 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:46:29 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA26281 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:47:37 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10507; Thu, 26 Dec 1996 02:30:57 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:30:57 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260730.IAA26022@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:30:30 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"axQ3d1.0.6a2.lcYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2437 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 11:00:52 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA22609; Fri, 27 Dec 1996 11:00:52 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 11:00:52 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271600.RAA02432@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 17:00:13 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"BDeED3.0.xW5.lA_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2460 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022820926DEC199607430322 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:43 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022820926DEC199607430322 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2084F12B25DEC199607204973 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2084F12B25DEC199607204973 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20820CE024DEC199603232660 UA content ID: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:24 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20820CE024DEC199603232660 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues Precedence: 1 To: WATERS@AM_MARVIN PMR wrote: :2. Make the RFC require that the clear text be expanded using SDP before : encryption. eg NO SDP negotiation is required. I wrote: }I am opposed to this; why should you penalize performance of routers any more }in the situations where you don't have to pad -- e.g. you are doing IPCP only }over a T1 or T3 line, but you chose to encrypt. Bill Whelan wrote: :I don't understand this objection. DES will require padding every time the :plain text is not a multiple of eight bytes. The only times SDP would add :unneeded padding is when the last byte of the ciphertext could be mistaken :for SDP padding (approximately 1 chance in 256). To which I respond: First, my intent was that SDP would be applied *before* encrypting. (Having the same model of a link-within-a-link that Multilink uses). so that Bill's statement should be "when the last byte of the plaintext could be mistaken" and the probability is a little more than just 1 in 256; you also have to check for terminating sequences 2 preceded by 1 or ... Thus, when SDP is in effect, you have to do a certain amount of computation per packet, and, in certain cases you have to add 8 more bytes, thus wasting bandwidth. As was asserted by me in the RFC, for a large class of protocols, SDP is wasted effort. If you are transporting vanilla IP packets, padding by garbage or zeroes works fine, because the packets have a built-in length indicator. Likewise for IPX. % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA10121 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:22:53 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id BAA21516 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:21:51 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id BAA21095 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 01:22:56 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA16588; Mon, 23 Dec 1996 19:06:58 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 19:06:58 -0500 (EST) % Date: Mon, 23 Dec 1996 16:05:37 -0800 (PST) % From: Keith Sklower % Message-Id: <199612240005.QAA26016@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU % Subject: Re[3]: RFC 1969 DES Encryption (and Padding) Issues % Resent-Message-ID: <"1a3X11.0.734.Xwnlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2379 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01833 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:15 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22429 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:22:18 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA29654 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:25 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02866; Wed, 25 Dec 1996 02:07:04 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:04 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250706.IAA00784@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:06:41 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"IgGnl2.0.fi.NADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2404 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA27203 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:42:38 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA12402 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:44:46 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA10428 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:45:55 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10166; Thu, 26 Dec 1996 02:29:37 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:29:37 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260728.IAA25822@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:29:10 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"mpeBc2.0.nU2.WbYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2429 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 11:01:36 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA22712; Fri, 27 Dec 1996 11:01:36 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 11:01:36 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271600.RAA02459@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 17:00:49 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"f0VQr3.0.HY5.NB_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2462 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G208520A926DEC199607441430 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:44 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G208520A926DEC199607441430 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2020AC9125DEC199607212732 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:21 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2020AC9125DEC199607212732 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022D54624DEC199603494990 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 03:50 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022D54624DEC199603494990 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN From ietf-ppp-request@MERIT.EDU Mon Dec 23 09:32:27 1996 Resent-Date: Mon, 23 Dec 1996 12:29:06 -0500 (EST) Date: Mon, 23 Dec 1996 09:34:08 -0800 (PST) From: Philip Rakity X-Sender: pmr@zeus To: ietf-ppp@MERIT.EDU Subject: RFC 1969 DES Encryption Issues Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2372 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Folks, Let me try to restate the problems as I see them and perhaps some solutions will be possible. 1. DES requires that the clear text be expanded to a multiple of 8 bytes before encryption. Eg The original data is expanded. Yes. 2. RFC 1969 does NOT explicitly pass the amount of this padding to the receiver. Yes. 3. Some protocols require that the original data size be recovered by the receiver inorder to process correctly the frame. Some examples are bridging If you were bridging 802.3, only then it has a length field. and TCP/IP using VJ compression. (Perhaps IPX with header compression is in this catagory. 4. Since the NCPs are negotiated in parallel, ECPNCP does not know what options have been negotiated by the other NCPs. I disagree. 5. Requesting the use of self described padding during ECPNCP negotiation states that the encrypted text is padded (NOT the plain text before encryption as per point 1. That was not my understanding when I proposed the RFC. 6. For SDP to work it requires that the receiver receive what the sender believes has been sent. Eg there was no H/W padding of the data when the data was sent. Some folks have given examples of HDLC chips that pad out frame to be an even number of bytes. Since with SDP one looks are the last byte in the frame and checks if it is an SDP character and removes padding accordingly, any artifical pads would make SDP not work. The only hardware issues that I was aware of where even/odd. Certainly PFC says you *may* omit the leading 0 but are *not required* to. You can force a PPP packet to be of even length by chosing whether or not to include the leading 0. IF my understanding of the issues is correct than for two independent implementations to work an agreement on how cleartext padding is done is required. Possible solutions. 1. Successful negotiation of SDP with ECPNCP implies that the receiver will check for SDP padding in the clear text; it also requires the transmitter to add SDP padding to the clear text before encryption. This is certainly what I had in mind, and I think that the RFC editor/process should allow clarifications of original intent. 2. Make the RFC require that the clear text be expanded using SDP before encryption. eg NO SDP negotiation is required. I am opposed to this; why should you penalize performance of routers any more in the situations where you don't have to pad -- e.g. you are doing IPCP only over a T1 or T3 line, but you chose to encrypt. 3. Add a number of pad byte added byte to the ECP header as per my previous note and require its use. DESE is not the end-all and be all of encryption protocols. Propose another one, and include your explicit padding byte there. Use triple DES or md5 or whatever you like, but just assign a different code; we've only assigned 2 code points of a possbile 255. Philip Rakity FlowPoint (408) 364-8300 Keith Sklower University of CA, Berkeley (510) 642 9587 % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id EAA11118 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 04:49:14 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id AAA18373 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:19:51 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id AAA10580 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 00:20:56 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id SAA15654; Mon, 23 Dec 1996 18:04:46 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 18:04:46 -0500 (EST) % Date: Mon, 23 Dec 1996 15:03:25 -0800 (PST) % From: Keith Sklower % Message-Id: <199612232303.PAA25819@vangogh.CS.Berkeley.EDU> % To: ietf-ppp@MERIT.EDU, pmr@flowpoint.com % Subject: Re: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"x4AzW2.0.Xq3.D0nlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2377 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU, pmr@flowpoint.com Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01884 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:20:56 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22551 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:23:04 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA22826 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:11 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA02947; Wed, 25 Dec 1996 02:07:28 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:07:28 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250707.IAA00799@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:07:02 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"hLt9e1.0.-j.iADmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2406 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA27342 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:43:52 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA10547 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:46:01 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA14778 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:47:08 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10348; Thu, 26 Dec 1996 02:30:27 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:30:27 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260729.IAA25963@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:29:57 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"FH0sA.0.cX2.HcYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2433 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 11:01:57 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id LAA22784; Fri, 27 Dec 1996 11:01:57 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 11:01:57 -0500 (EST) From: "rdgeng::mrgate"@rdgeng.enet.dec.com Message-Id: <199612271601.RAA02496@vbormc.vbo.dec.com> Date: Fri, 27 Dec 96 17:01:19 MET To: "ietf-ppp@merit.edu"@vbormc.vbo.dec.com Apparently-To: ietf-ppp@MERIT.EDU Subject: Message Router delivery notification message Resent-Message-ID: <"B2su71.0.XZ5.hB_mo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2464 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU RE Message ID: G2022820926DEC199607440944 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 27-DEC-1996 07:44 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022820926DEC199607440944 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G20835E1425DEC199607222042 UA content ID: Message Router delivery notification message Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 26-DEC-1996 07:22 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G20835E1425DEC199607222042 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Message Router delivery notification message Precedence: 1 To: WATERS@AM_MARVIN RE Message ID: G2022F28D24DEC199605231520 UA content ID: Re: RFC 1969 DES Encryption Issues Attempted delivery to: Route : @AM_MARVIN <-- Userid : WATERS Arrival date : 25-DEC-1996 05:23 This delivery failed. Failure reason was "transfer failure". Diagnostic was "max time expired". Message-id: G2022F28D24DEC199605231520 From: NAME: ietf-ppp@MERIT.EDU <"ietf-ppp@MERIT.EDU"@VBORMC@MRGATE@RDGENG@REO> Subject: Re: RFC 1969 DES Encryption Issues Precedence: 1 To: WATERS@AM_MARVIN >IF my understanding of the issues is correct than for two independent >implementations to work an agreement on how cleartext padding is done is >required. > >Possible solutions. > >1. Successful negotiation of SDP with ECPNCP implies that the receiver >will check for SDP padding in the clear text; it also requires the >transmitter to add SDP padding to the clear text before encryption. > This one is clearly wrong. SDP negotiation implies the ciphertext is padded. As you've pointed out, the problem is that the plain text must be padded. >2. Make the RFC require that the clear text be expanded using SDP before >encryption. eg NO SDP negotiation is required. This is the best solution. I suspect it was the actual intent of the RFC to "require" such padding in instances when it was needed. Any implementation which currently does this is in compliance with the RFC. > >3. Add a number of pad byte added byte to the ECP header as per my >previous note and require its use. > No, I actually prefer this solution. But anyone implementing it today would be in violation of the existing RFC. > > >Philip Rakity >FlowPoint >(408) 364-8300 > Bill Whelan % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id GAA14296 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Tue, 24 Dec 1996 06:22:42 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id UAA05728 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 20:19:34 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id UAA19026 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Mon, 23 Dec 1996 20:20:39 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA12309; Mon, 23 Dec 1996 14:01:16 -0500 (EST) % Resent-Date: Mon, 23 Dec 1996 14:01:16 -0500 (EST) % Date: Mon, 23 Dec 96 13:59:23 EST % From: "Whelan, Bill" % Message-Id: <9611238513.AA851378449@netx.nei.com> % To: ietf-ppp@MERIT.EDU % Subject: Re: RFC 1969 DES Encryption Issues % Resent-Message-ID: <"NB_wt2.0.F03.xRjlo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2374 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 25-Dec-1996 Posted-date: 25-Dec-1996 VMSmail To information: ietf-ppp@MERIT.EDU Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA01961 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:21:53 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA22580 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:24:01 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA10338 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Wed, 25 Dec 1996 08:25:08 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA03186; Wed, 25 Dec 1996 02:08:21 -0500 (EST) % Resent-Date: Wed, 25 Dec 1996 02:08:21 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612250707.IAA00883@vbormc.vbo.dec.com> % Date: Wed, 25 Dec 96 08:07:55 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"0K47k1.0.hn.aBDmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2409 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 26-Dec-1996 Posted-date: 26-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon % ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ====== % Received: from mail.vbo.dec.com (mail.vbo.dec.com [16.36.208.34]) by vbormc.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA27332 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:43:48 +0100 % Received: from server21.digital.fr (server21.digital.fr [193.56.15.21]) by mail.vbo.dec.com (8.7.3/8.7) with ESMTP id IAA12736 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:45:56 +0100 (MET) % Received: from merit.edu (merit.edu [35.1.1.42]) by server21.digital.fr (8.7.5/8.7) with ESMTP id IAA11935 for <"rdgeng::mrgate::am_marvin::waters"@rdgeng.enet.dec.com>; Thu, 26 Dec 1996 08:47:05 +0100 (MET) % Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id CAA10363; Thu, 26 Dec 1996 02:30:30 -0500 (EST) % Resent-Date: Thu, 26 Dec 1996 02:30:30 -0500 (EST) % From: "rdgeng::mrgate"@rdgeng.enet.dec.com % Message-Id: <199612260730.IAA25985@vbormc.vbo.dec.com> % Date: Thu, 26 Dec 96 08:30:05 MET % To: "ietf-ppp@merit.edu" % Apparently-To: ietf-ppp@MERIT.EDU % Subject: Message Router delivery notification message % Resent-Message-ID: <"EyYOn.0.rX2.KcYmo"@merit.edu> % Resent-From: ietf-ppp@MERIT.EDU % X-Mailing-List: archive/latest/2434 % X-Loop: ietf-ppp@MERIT.EDU % Precedence: list % Resent-Sender: ietf-ppp-request@MERIT.EDU Date: 27-Dec-1996 Posted-date: 27-Dec-1996 VMSmail To information: "ietf-ppp@merit.edu" Sender's personal name: MAIL-11 Daemon - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 13:11:27 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id NAA25330; Fri, 27 Dec 1996 13:11:27 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 13:11:27 -0500 (EST) To: ietf-ppp@MERIT.EDU Path: anchor!not-for-mail From: lars@anchor.RNS.COM (Lars Poulsen) Newsgroups: ietf.ppp Subject: Re: DESE context issues Date: 27 Dec 1996 10:10:42 -0800 Organization: RNS / Meret Communications Lines: 31 Message-ID: <5a13f2$mnn@anchor.rns.com> References: <199612240150.SAA15118@mica.denver.sgi.com> Resent-Message-ID: <"wXKEX2.0.TB6.B51no"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2467 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU In article <199612240150.SAA15118@mica.denver.sgi.com> vjs@mica.denver.sgi.com (Vernon Schryver) writes: > When padding the protocol number with leading zeros was >suggested as an alternative for SDP for LCP for braindead HDLC >hardware, it was shot down by the claim that such HDLC hardware insists >on adding the HDLC header including the protocol number. That objection >obviously does not apply to ECP. I am aware of two types of hardware with restrictions: 1) "intelligent" HDLC framers, which insist on providing the address and control fields of the HDLC frame, but have no restrictions on frame lengths. To support these, LCP_ACFC is off by default. (In all the devices of this type that I have seen, there have been provisions for a "transparent mode", but I haven't seen them all). 2) byte-mode HDLC framers driven by word-mode DMA controllers which insist that frames must be an even number of bytes in length and aligned on a word boundary. The optional 00 prefix on the protocol number helps with the word alignment, SDP may save you from in-memory copying of the packet to satisfy the length requirement. (This kind of penny-pinching is more common than you'd think. The margins are slim at the low end.) Do we need an inventory of known brokenness ? -- / Lars Poulsen Internet E-mail: lars@OSICOM.COM OSICOM Technologies (Internet Business Unit, formerly RNS) 7402 Hollister Avenue Telefax: +1-805-968-8256 Santa Barbara, CA 93117 Telephone: +1-805-562-3158 - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Fri Dec 27 14:17:29 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id OAA26229; Fri, 27 Dec 1996 14:17:29 -0500 (EST) Resent-Date: Fri, 27 Dec 1996 14:17:29 -0500 (EST) Posted-Date: Fri, 27 Dec 1996 11:16:46 -0800 (PST) Date: Fri, 27 Dec 1996 14:16:44 -0500 From: eallen@BayNetworks.COM (Ed Allen) Message-Id: <199612271916.OAA20730@pobox.engeast.BayNetworks.COM> To: ietf-ppp@MERIT.EDU Cc: dhaskin@pobox, eallen@pobox Subject: IPv6 CP draft Resent-Message-ID: <"00PAM1.0.RP6.432no"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2468 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Hi, We've made the changes suggested by the PPP WG and the IPng WG and here is the new IPv6 CP draft. The changes are: 1. disallow Interface-Token assignment by means of Config-Ack, and now allow only assignment by Config-Nak. This change appears in paragraph 5 of section 4.1. This was the original issue brought up on the list. 2. added text which recommends consistent use of the same value for Interface-Token on a link. Added rationale for doing so. This change appears in paragraph 2 of section 4.1 3. streamlined some text which describes random number generation and made explicit reference to RFC 1661 discussion of random number generation. 4. replaced boilerplate under "Security Considerations" with a more explicit statement. Thanks, Ed Allen Dimitry Haskin ------------------8<------------------------- Internet Engineering Task Force INTERNET-DRAFT Dimitry Haskin Expires July 1997 Ed Allen Bay Networks, Inc. December 1996 IP Version 6 over PPP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract The Point-to-Point Protocol (PPP) [1] provides a standard method of encapsulating Network Layer protocol information over point-to-point links. PPP also defines an extensible Link Control Protocol, and proposes a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document defines the method for transmission of IP Version 6 [2] packets over PPP links as well as the Network Control Protocol (NCP) for establishing and configuring the IPv6 over PPP. It also specifies the method of forming IPv6 link-local addresses on PPP links. Table of Contents 1. Introduction .......................................... 2 1.1. Specification of Requirements ...................... 2 2. Sending IPv6 Datagrams ................................ 3 3. A PPP Network Control Protocol for IPv6 ............... 3 4. IPV6CP Configuration Options .......................... 4 4.1. Interface-Token ................................... 4 4.2. IPv6-Compression-Protocol.......................... 7 5. Stateless Autoconfiguration and Link-Local Addresses .. 9 A. IPV6CP Recommended Options ............................. 9 Security Considerations ....................................... 10 References .................................................... 10 Acknowledgments ............................................... 10 Authors' Addresses ............................................ 10 Haskin & Allen [Page 1] Draft IP Version 6 over PPP December 1996 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. In order to establish communications over a point-to-point link, each end of the PPP link must first send LCP packets to configure and test the data link. After the link has been established and optional facilities have been negotiated as needed by the LCP, PPP must send NCP packets to choose and configure one or more network-layer protocols. Once each of the chosen network-layer protocols has been configured, datagrams from each network-layer protocol can be sent over the link. In this document, the NCP for establishing and configuring the IPv6 over PPP is referred as the IPv6 Control Protocol (IPV6CP). The link will remain configured for communications until explicit LCP or NCP packets close the link down, or until some external event occurs (power failure at the other end, carrier drop, etc.). 1.1. Specification of Requirements In this document, several words are used to signify the requirements of the specification. These words are often capitalized. MUST This word, or the adjective "required", means that the definition is an absolute requirement of the specification. MUST NOT This phrase means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "recommended", means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications must be understood and carefully weighed before choosing a different course. MAY This word, or the adjective "optional", means that this item is one of an allowed set of alternatives. An implementation which does not include this option MUST be Haskin & Allen [Page 2] Draft IP Version 6 over PPP December 1996 prepared to inter-operate with another implementation which does include the option. 2. Sending IPv6 Datagrams Before any IPv6 packets may be communicated, PPP must reach the Network-Layer Protocol phase, and the IPv6 Control Protocol must reach the Opened state. Exactly one IPv6 packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 0057 (Internet Protocol Version 6). The maximum length of an IPv6 packet transmitted over a PPP link is the same as the maximum length of the Information field of a PPP data link layer frame. PPP links supporting IPv6 must allow at least 576 octets in the information field of a data link layer frame. 3. A PPP Network Control Protocol for IPv6 The IPv6 Control Protocol (IPV6CP) is responsible for configuring, enabling, and disabling the IPv6 protocol modules on both ends of the point-to-point link. IPV6CP uses the same packet exchange mechanism as the Link Control Protocol (LCP). IPV6CP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. IPV6CP packets received before this phase is reached should be silently discarded. The IPv6 Control Protocol is exactly the same as the Link Control Protocol [1] with the following exceptions: Data Link Layer Protocol Field Exactly one IPV6CP packet is encapsulated in the Information field of PPP Data Link Layer frames where the Protocol field indicates type hex 8057 (IPv6 Control Protocol). Code field Only Codes 1 through 7 (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject) are used. Other Codes should be treated as unrecognized and should result in Code-Rejects. Haskin & Allen [Page 3] Draft IP Version 6 over PPP December 1996 Timeouts IPV6CP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase. An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time. Configuration Option Types IPV6CP has a distinct set of Configuration Options, which are defined below. 4. IPV6CP Configuration Options IPV6CP Configuration Options allow negotiation of desirable IPv6 parameters. IPV6CP uses the same Configuration Option format defined for LCP [1], with a separate set of Options. If a Configuration Option is not included in a Configure-Request packet, the default value for that Configuration Option is assumed. Up-to-date values of the IPV6CP Option Type field are specified in the most recent "Assigned Numbers" RFC [5]. Current values are assigned as follows: 1 Interface-Token 2 IPv6-Compression-Protocol 4.1. Interface-Token Description This Configuration Option provides a way to negotiate a unique 32-bit interface token to be used for the address autoconfiguration [3] at the local end of the link (see section 5). The interface token MUST be unique within the PPP link; i.e. upon completion of the negotiation different Interface-Token values are to be selected for the ends of the PPP link. Before this Configuration Option is requested, an implementation chooses its tentative Interface-Token. The non-zero value of the tentative Interface-Token SHOULD be chosen such that the value is both unique to the link and, if possible, consistently reproducible across initializations of the IPV6CP finite state machine (administrative Close and reOpen, reboots, etc). The rationale for preferring a consistently reproducible unique token to a completely random token is to provide stability to global scope addresses that can be formed from the interface token. Suggested sources of uniqueness include machine serial numbers, link-layer addresses, et cetera. Haskin & Allen [Page 4] Draft IP Version 6 over PPP December 1996 If a good source of uniqueness cannot be found, it is recommended that a random number be generated. Good sources [1] of uniqueness or randomness are required for the Interface-Token negotiation to succeed. If neither a unique number or a random number can be generated it is recommended that a zero value be used for the Interface-Token transmitted in the Configure-Request. In this case the PPP peer may provide a valid non-zero Interface-Token in its response as described below. Note that if at least one of the PPP peers is able to generate separate non-zero numbers for itself and its peer, the token negotiation will succeed. When a Configure-Request is received with the Interface-Token Configuration Option and the receiving peer implements this option, the received Interface-Token is compared with the Interface-Token of the last Configure-Request sent to the peer. Depending on the result of the comparison an implementation MUST respond in one of the following ways: If the two Interface-Tokens are different but the received Interface-Token is zero, a Configure-Nak is sent with a non-zero Interface-Token value suggested for use by the remote peer. Such a suggested Interface-Token MUST be different from the Interface- Token of the last Configure-Request sent to the peer. It is recommended that the value suggested be consistently reproducible across initializations of the IPV6CP finite state machine (administrative Close and reOpen, reboots, etc). If the two Interface-Tokens are different and the received Interface-Token is not zero, the Interface-Token MUST be acknowledged, i.e. a Configure-Ack is sent with the requested Interface-Token, meaning that the responding peer agrees with the Interface-Token requested. If the two Interface-Tokens are equal and are not zero, a Configure-Nak MUST be sent specifying a different non-zero Interface-Token value suggested for use by the remote peer. If the two Interface-Tokens are equal to zero, the Interface- Tokens negotiation MUST be terminated by transmitting the Configure-Reject with the Interface-Token value set to zero. In this case a unique Interface-Token can not be negotiated. If a Configure-Request is received with the Interface-Token Configuration Option and the receiving peer does not implement this option, Configure-Rej is sent. Haskin & Allen [Page 5] Draft IP Version 6 over PPP December 1996 A new Configure-Request SHOULD NOT be sent to the peer until normal processing would cause it to be sent (that is, until a Configure-Nak is received or the Restart timer runs out). A new Configure-Request MUST NOT contain the Interface-Token option if a valid Interface-Token Configure-Reject is received. Reception of a Configure-Nak with a suggested Interface-Token different from that of the last Configure-Nak sent to the peer indicates a unique Interface-Token. In this case a new Configure-Request MUST be sent with the token value suggested in the last Configure-Nak from the peer. But if the received Interface-Token is equal to the one sent in the last Configure- Nak, a new Interface-Token MUST be chosen. In this case, a new Configure-Request SHOULD be sent with the new tentative Interface-Token. This sequence (transmit Configure-Request, receive Configure-Request, transmit Configure-Nak, receive Configure-Nak) might occur a few times, but it is extremely unlikely to occur repeatedly. More likely, the Interface-Tokens chosen at either end will quickly diverge, terminating the sequence. If negotiation of the Interface-Token is required, and the peer did not provide the option in its Configure-Request, the option SHOULD be appended to a Configure-Nak. The tentative value of the Interface-Token given must be acceptable as the remote Interface- Token; i.e. should be different from the token value selected for the local end of the PPP link. The next Configure-Request from the peer may include this option. If the next Configure-Request does not include this option the peer MUST NOT send another Configure-Nak with this option included. It should assume that the peer's implementation does not support this option. By default, an implementation SHOULD attempt to negotiate the Interface-Token for its end of the PPP connection. Haskin & Allen [Page 6] Draft IP Version 6 over PPP December 1996 A summary of the Interface-Token Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Interface-Token +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Interface-Token (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length 6 Interface-Token The 32-bit Interface-Token which is very likely to be unique on the link or zero if a good source of uniqueness can not be found. Default Token Value If no valid interface token can be successfully negotiated, no default Interface-Token value should be assumed. The procedures for recovering from such a case are unspecified. One approach is to manually configure the interface token of the interface. 4.2. IPv6-Compression-Protocol Description This Configuration Option provides a way to negotiate the use of a specific IPv6 packet compression protocol. The IPv6-Compression- Protocol Configuration Option is used to indicate the ability to receive compressed packets. Each end of the link must separately request this option if bi-directional compression is desired. By default, compression is not enabled. IPv6 compression negotiated with this option is specific to IPv6 datagrams and is not to be confused with compression resulting from negotiations via Compression Control Protocol (CCP), which potentially effect all datagrams. Haskin & Allen [Page 7] Draft IP Version 6 over PPP December 1996 A summary of the IPv6-Compression-Protocol Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | IPv6-Compression-Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ... +-+-+-+-+ Type 2 Length >= 4 IPv6-Compression-Protocol The IPv6-Compression-Protocol field is two octets and indicates the compression protocol desired. Values for this field are always the same as the PPP Data Link Layer Protocol field values for that same compression protocol. Up-to-date values of the IPv6-Compression-Protocol field are specified in the most recent "Assigned Numbers" RFC [5]. Current values are assigned as follows: Value (in hex) Protocol 004f IPv6 Header Compression Data The Data field is zero or more octets and contains additional data as determined by the particular compression protocol. Default No IPv6 compression protocol enabled. Haskin & Allen [Page 8] Draft IP Version 6 over PPP December 1996 5. Stateless Autoconfiguration and Link-Local Addresses The interface token, which is used for forming IPv6 addresses of a PPP interface, SHOULD be negotiated in the IPV6CP phase of the PPP connection setup (see section 4.1). If no valid interface token has been successfully negotiated, procedures for recovering from such a case are unspecified. One approach is to manually configure the interface token of the interface. As long as the interface token is negotiated in the IPV6CP phase of the PPP connection setup, it is redundant to perform duplicate address detection as a part of the IPv6 Stateless Autoconfiguration protocol [3]. Therefore it is recommended that for PPP links with the IPV6CP Interface-Token option enabled the default value of the DupAddrDetectTransmits autoconfiguration variable [3] be zero. Link-local addresses of PPP interfaces have the following format: | 10 bits | 86 bits | 32 bits | +----------+--------------+---------------------+-----------------+ |1111111010| 0 | Interface Token | +----------+--------------+---------------------+-----------------+ The most significant 10 bits of the address is the Link-Local prefix FE80::. 86 zero bits pad out the address between the Link-Local prefix and the Interface Token fields. A. IPV6CP Recommended Options The following Configurations Options are recommended: Interface-Token IPv6-Compression-Protocol Haskin & Allen [Page 9] Draft IP Version 6 over PPP December 1996 Security Considerations The IPv6 Control Protocol extension to PPP can be used with all defined PPP authentication and encryption mechanisms. References [1] Simpson, W., "The Point-to-Point Protocol", STD 51, RFC 1661, July 1994. [2] Deering, S., and R. Hinden, Editors, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883, December 1995. [2] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 1884, December 1995. [3] Thomson, S., and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 1971, August 1996. [4] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996. [5] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. Acknowledgments This document borrows from the Magic-Number LCP option and as such is partially based on previous work done by the PPP working group. Authors' Addresses Dimitry Haskin Bay Networks, Inc. 2 Federal Street Billerica, MA 01821 email: dhaskin@baynetworks.com Ed Allen Bay Networks, Inc. 2 Federal Street Billerica, MA 01821 email: eallen@baynetworks.com Haskin & Allen [Page 10] - - - - - - - - - - - - - - - - - From ietf-ppp-request@MERIT.EDU Tue Dec 31 19:24:55 1996 Received: (from slist@localhost) by merit.edu (8.8.4/merit-2.0) id TAA17529; Tue, 31 Dec 1996 19:24:55 -0500 (EST) Resent-Date: Tue, 31 Dec 1996 19:24:55 -0500 (EST) To: IETF PPP Mailing List Subject: L2TP draft 01 comments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 31 Dec 1996 16:23:59 -0800 Message-Id: <2348.852078239@dumbcat.codewright.com> From: Marco S Hyman Resent-Message-ID: <"n-i5G2.0.WH4.bwQoo"@merit.edu> Resent-From: ietf-ppp@MERIT.EDU X-Mailing-List: archive/latest/2469 X-Loop: ietf-ppp@MERIT.EDU Precedence: list Resent-Sender: ietf-ppp-request@MERIT.EDU Comments through section 5. 1.2 Terminology There is no definition if PSTN (and related terms). May I suggest ISDN Integrated Services Digital Network. A switched digital telephone service. POTS Plain Old Telephone Service. The existing analog telephone service infrastructure. PSTN The Public Switched Telephone Network. The PSTN encompases all public switched services, including POTS, ISDN, DDS, etc. 2.2 Topology The section uses PSTN where it means "async" and ISDN where it means "sync". The statement: Shown below is a generic Internet with Public switched Telephone Net- work (PSTN) access (i.e., async PPP via modems) and Integrated Ser- vices Digital Network (ISDN) access (i.e., synchronous PPP access). is incorrect. The PSTN is not limited to async PPP via modems and includes ISDN. A better statement would be: Shown below is a generic Internet providing both asynchronous (modem via POTS, V.120 rate adaption via ISDN) and synchronous (ISDN, DDS) access via the the PSTN. The diagram is also incorrect. The ISDN cloud is part of the PSTN cloud. 2.3 Providing Virtual dial-up Services--a walk-through 2nd paragraph: remove "or ISDN" from the 1st sentance. 4.0 Protocol Overview The second paragraph of this section starts out discussing fields in a message that have not yet been defined. I'd suggest an introductory sentence, such as: L2TP messages (see sections 5.2 and 5.3) may contain transmit and receive sequence numbers. 4.1 Control Message Overview Paragraph three states: "For the cases where a Call ID has not yet been assigned from the peer (i.e., during call establishment of a new session), the Call ID field is sent as 0, and further fields within the message are used to identify the session." Perhaps the text should reinforce that control messages with a zero Call ID relate to the tunnel and maintain their own sequence number space here? 5.1 AVP Second paragraph, under the header description states: The first four bits ... Either the diagram is wrong or the text should read "The first six bit ...". The section on encryption looks like it was lifted out of another doc and needs editing. I think you want to gs/password/value to encrypt/ at a minimum. Also, the text says: If necessary, this operation is repeated, with each XOR result being used along with the shared secret to generate the next hash to XOR the next segment of the password, to no more than 128 characters. Is there any reason withing L2TP to limit a hidden value to 128 characters? 5.2 Control Message Format The 6th paragraph says: Nr and Ns reflect the currently transmitted packet and latest received packet respectively. See section 4.0. Nr reflects the transmitted packet? Ns reflects the received packet? Didn't section 4.0 state that Nr reflect the next packet to be received? (I think the text for these fields in section 5.3 is correct). - - - - - - - - - - - - - - - - -