From pppext-bounces@ietf.org Mon Oct 10 14:45:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2e1-0005Rv-Bu; Mon, 10 Oct 2005 14:45:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP2dz-0005Qb-9e for pppext@megatron.ietf.org; Mon, 10 Oct 2005 14:45:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12029 for ; Mon, 10 Oct 2005 14:44:59 -0400 (EDT) Received: from rt.icann.org ([192.0.34.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP2np-0004js-RC for pppext@ietf.org; Mon, 10 Oct 2005 14:55:18 -0400 Received: from rt.icann.org (localhost.icann.org [127.0.0.1]) by rt.icann.org (8.13.1/8.13.1) with ESMTP id j9AIipZs076935 for ; Mon, 10 Oct 2005 11:44:51 -0700 (PDT) (envelope-from www@rt.icann.org) Received: (from www@localhost) by rt.icann.org (8.13.1/8.13.1/Submit) id j9AIipHY076934; Mon, 10 Oct 2005 11:44:51 -0700 (PDT) (envelope-from www) Date: Mon, 10 Oct 2005 11:44:51 -0700 (PDT) From: "Michelle Cotton via RT" In-Reply-To: Message-ID: Precedence: bulk X-RT-Loop-Prevention: rt.icann.org RT-Ticket: rt.icann.org #3528 Managed-by: RT 3.2.2 (http://www.bestpractical.com/rt/) RT-Originator: michelle.cotton@icann.org Cc: pppext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by rt.icann.org id j9AIipZs076935 X-Spam-Score: 0.0 (/) X-Scan-Signature: 27f32072baa9c4fb41949212e86ea6d2 Content-Transfer-Encoding: quoted-printable Subject: [Pppext] [rt.icann.org #3528] FW: General Request for Assignments (ppp-numbers) X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Reply-To: iana-prot-param@icann.org List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org PPPEXT Working Group: This is a follow-up to a recent request you were reviewing for IANA. The Working Group Chair requested that the group wanted to see the I-D=20 before making a decision. Below, please find the I-D sent to IANA by=20 the requestor. We will await your response. Thank you, Michelle Cotton IANA **************************************************************** As requested, please find the I-D about our PPP extension. It is called=20 "Quantum Key Destribution within Point to Point Protocol (Q3P)" written=20 by Solange Ghernaouti-H=C3=A9lie and Mohamed Ali Sfaxi. > Network Working Group Solange Ghernaouti-H=C3=A9l= ie > INTERNET-DRAFT Mohamed Ali=20 Sfaxi > University=20 of Lausanne > Expires: April, 29 2006 =20 October 2005=20 >=20 >=20 >=20 > Quantum Key Destribution within Point=20 > to Point Protocol (Q3P) > draft-ghernaouti-sfaxi-ppp-qkd-00.txt >=20 >=20 > Status of this Memo >=20 > By submitting this Internet-Draft, we certify that any applicable > patent or other IPR claims of which we are aware have been=20 disclosed, > or will be disclosed, and any of which we become aware will be > disclosed, in accordance with RFC 3668. >=20 > 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. >=20 > 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." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/1id-abstracts.html >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html >=20 >=20 > Abstract >=20 > The aim of this paper is to analyse the use of quantum > cryptography within PPP. We propose a solution that integrates=20 > quantum key distribution into PPP.=20 >=20 >=20 > Terminology >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL=20 > NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20 > "OPTIONAL" in this document are to be interpreted as described in=20 > RFC 2119 [9]. >=20 >=20 >=20 >=20 >=20 >=20 > Ghernaouti and Sfaxi [Page 1] > =0C > INTERNET-DRAFT Expires: April, 29 2006 >=20 >=20 >=20 > 1. Introduction >=20 > The point to point protocol (PPP) [RFC1661] is a data-layer=20 > protocol ensuring a reliable data exchange over a point to point=20 > link. When the connection is established and configured, the PPP=20 > allows the data transfer of many protocols (IP, IPX, AppleTalk=C2=85= ).=20 > That's why; PPP is widely used in Internet environment. >=20 > The unique security of PPP as specified in the RFC 1661 is limited=20 > to the authentication phase. The two nodes use an authentication=20 > protocol such as Password Authentication Protocol (PAP) [RFC1334]=20 > or Challenge Handshake Authentication Protocol (CHAP)[RFC1994]. In=20 > 1996, Meyer published an additional security protocol for PPP=20 > called ECP (Encryption Control Protocol) [RFC1968]. This protocol=20 > allows the use of the encryption in PPP frame. The ECP gives the=20 > possibility to select the encryption algorithm and its parameters.=20 > This ensures the confidentiality and the integrity of the PPP=20 > frame. The weakness of this use resides in the way of generating=20 > and exchanging the encryption key. In fact, for all the encryption=20 > algorithms the secret key is assumed to be already shared between=20 > the communicating parties. So to enhance security, we propose the=20 > use of quantum cryptography to generate and to share the secret=20 > key between the two nodes. >=20 > Quantum cryptography is the only method allowing the distribution=20 > of a secret key between two distant parties without transmitting=20 > any secret over unsecure channel [1, 4]. the emitter and the=20 > receiver will be able to share an encryption key for enciphering=20 > confidential data. The secrecy of this shared key is=20 unconditional =20 > [8] by the fact that the secret is generated and exchanged based=20 > on physic laws (instead of mathematical functions). That=C2=92s why = we=20 > propose to integrate the quantum key distribution (QKD) process to=20 > share secret key between two nodes. >=20 >=20 > 2. Encryption Control Protocol (ECP) for Quantum Key Distribution=20 > (QKD) >=20 > The Encryption Control Protocol (ECP) defines the negotiation of > the encryption over PPP links. After using LCP to establish and=20 > configure the data link, the encryption options and mechanisms=20 > could be negotiated. The ECP packets exchange mechanism is nearly > the same as the LCP mechanism. The ECP packets are encapsulating=20 > into PPP frame (a packet per frame). The type is 0x8053 to=20 > indicate the Encryption Control Protocol. Two additional messages=20 > are added to the code field: the Reset-Request and Reset-Ack=20 > message. These two messages are used to restart the encryption=20 > negotiation. An encrypted packet is encapsulated in the PPP=20 > information field where the PPP protocol field indicates type=20 > 0x0053 (encrypted datagram). The ECP packet is presented in=20 > figure 1 >=20 >=20 > 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 | Values... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >=20 > Figure 1 - The Encryption Type Configuration Option format >=20 >=20 > Ghernaouti and Sfaxi [Page 2] > =0C >=20 > INTERNET-DRAFT Expires: April, 29 2006 >=20 >=20 > ECP packet, the type represents the encryption protocol option to > be negotiated (for instance type 1 is DES encryption). The number=20 > of octets in the packet is contained in the length field. The=20 > values field gives additional data or option needed for the=20 > encryption protocol. Up to now, there are only 4 encryption > algorithms (type 0 =3D OUI, type 1 =3D DES, type 2 =3D 3DES, type 3 = =3D > DES modified) that could be used [5]. >=20 > 3. Integrating QKD in PPP: QKD-PPP (Q3P) >=20 > In order to exchange the encryption key, a key exchange protocol > is necessary. In this section, we present how to integrate QKD in=20 > PPP >=20 >=20 > 3.1 ECP-QKD format >=20 > To establish and configure the quantum key distribution between=20 > the two nodes, it is necessary to exchange some data between=20 > them. We propose a specific ECP packet format to carry QKD=20 > parameters (Figure 2): >=20 >=20 > 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 | Key-Length > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | TTL |T| =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >=20 > Figure 2 - ECP packet carrying a QKD protocol >=20 >=20 > Type field: > As in the ECP standard packet the type field gives information=20 > about the option of encryption protocol negotiated. For this=20 > case, we will use an unassigned number for the QKD protocol. The=20 > selected QKD protocol is BB84 and the request to obtain an=20 > assigned number for this protocol is on going in IANA =20 > organisation [5]. >=20 > Length field: > The length is number of octets in the packet and it is more than=20 > =C2=945=C2=94 octets (1 octet for the type, 1 octet for the packet = length,=20 > 2 octets for the key length and one octet for the TTL and the T=20 > field). >=20 > Key-length field: > This field indicates the length of the encryption key. It is=20 > ended on 16 bits and represents the size of the key in octet. The=20 > key size is comprised between 1 to 65535 octets. The size can be=20 > viewed as huge but we consider the possibility to use the One=20 > Time Pad function as the encryption algorithm. In this case, the > key size must be equal to the PPP-data size [11]. >=20 >=20 > Ghernaouti and Sfaxi [Page 3] > =0C > INTERNET-DRAFT Expires: April, 29 2006 >=20 > TTL field: > This field can represent either the number of messages or the=20 > amount of time (in second) during which a key could be used in=20 > the encryption mechanism. When the max number of messages is=20 > reached or the deadline expires, the QKD starts. >=20 > T field: > The T field specifies if the TTL field concerns the number of > messages or the amount of time. If the value is =C2=941=C2=94, the = TTL=20 > field corresponds to the amount of time in second. If it is =C2=940= =C2=94,=20 > the TTL is the number of messages per key. >=20 > 3.2 The Q3P operating mode >=20 > We adapt PPP connection steps [RFC1661] to integrate QKD process > as shown Figure 3. The three first steps of Q3P are identical=20 > with PPP (phase 1 to 3). After authenticating the two nodes, the=20 > negotiation of the encryption parameters starts. In this phase,=20 > the encryption algorithm with its parameters is negotiated. > If the two nodes do not need to use encryption, then the network=20 > phase starts. Else, if an encryption key is required, a QKD=20 phase =20 > begins. For Encryption negotiation (4) the nodes negotiate the=20 > key length and the TTL by sending an adequate ECP packet. After=20 > that (in 5), a quantum cryptography exchange starts. At the end=20 > of the quantum key distribution phase, both nodes share a secret=20 > key, the encryption algorithm and the TTL of the key. This key is > used in the network phase (6) while sending data. The data is=20 > enciphered thanks to the encryption key and the algorithm. When=20 > the TTL is expired, a new QKD phase starts. The end of the =20 > communication is the same as the PPP.=20 > (1) (2) (3)=20 > +------+ +-----------+ +--------------+ > | | UP | | OPENED | |SUCCESS/NONE > | Dead |------->| Establish |----------->| Authenticate |---+ > | | | | | | | > +------+ +-----------+ +--------------+ | > ^ | | | > | FAIL | FAIL | | > +<--------------+ +----------+ | > | | (4) | > | | +--------------+ | > | | | Encryption |<-+=20 > | | | Negotiation | > | | +--------------+ > | | | > | | TLL | Key needed/None > | | expires \|/=20 > | | +---------+ > | | +---->| QKD |----+ > | | | (5) +---------+ | > | | | | > | | | | > | +-----------+ | | +---------+ | > | DOWN | | | +-------| | | > +-------------| Terminate | | | Network |<-+ > | |<---+<-----------| | Key > +-----------+ CLOSING +---------+ generated/ > (7) (6) None >=20 > Figure 3 - Proposed Q3P steps and operating mode >=20 > Ghernaouti and Sfaxi [Page 4] > =0C > INTERNET-DRAFT Expires: April, 29 2006 >=20 >=20 > The Figure 4 gives more details about Q3P operating mode. The=20 > modification are little so that the adaptation of the PPP=20 > operating mode is easy to realise. >=20 >=20 > 1- Dead state (Initial state): > a. When detecting an Up event then go the Establish phase > 2- Establish phase: > a. Configuration packets are exchanged (LCP) > b. When finishing configuring the link connection go to the > Authentication phase > 3- Authentication phase: > a. If required, the peer has to authenticate himself. > b. If the authentication succeed or it is not required then go=20 > to Encryption negotiation phase else go to terminate phase > 4- Encryption Negotiation phase: > a. If required, the two nodes negotiate the encryption protocol=20 > parameters and the quantum key exchange parameters (such as=20 > TTL, Key length). If not required, go the Network phase > b. After the end of the negotiation, go to QKD phase > 5- QKD phase:=09 > a. The source and the detector share a secret key exchanged=20 > using quantum cryptography > b. When the secret key is ready go to Network phase > 6- Network phase: > a. The two node exchange data > b. When the encryption TTL expires go to QKD phase > c. If the communication is finished, go to terminate phase (a=20 > close event is generated) > 7- Terminate phase: > a. Terminate messages are exchange, when finish go to Dead state >=20 > Figure 4 : The Q3P algorithm >=20 > 4. Conclusion >=20 > For some needs, it is important to have the option to secure=20 > efficiently the data transmission between two adjacent nodes.=20 > Using quantum cryptography in conjunction with PPP offer a higher=20 > level of security. Our study points out the adaptation of=20 > the PPP protocol to integrate quantum key exchange (Q3P). The > modifications to PPP are identified (packet format and operating=20 > mode). > Applying quantum key exchange and one-time-pad function at OSI=20 > layer 2 is not only possible but will upgrade considerably, with a=20 > low cost and less effort (modification, performances,), the=20 > security level of a transmission between two adjacent nodes. >=20 >=20 > 5. Security considerations >=20 > Our proposition do not damage PPP security mechanism but enhance=20 > if by the use of quantum key echange.=20 > The unconditional security of quantum key distribution has been=20 > already proven.=20 >=20 > Ghernaouti and Sfaxi [Page 5] > =0C > INTERNET-DRAFT Expires: April, 29 2006 >=20 > 6. Authors Address >=20 > Solange Ghernaouti-Helie > HEC,=20 > University of Lausanne > 1015 Lausanne, Switzerland. > EMail: sgh@unil.ch >=20 >=20 > Mohamed Ali Sfaxi > HEC,=20 > University of Lausanne > 1015 Lausanne, Switzerland. > EMail: mohamedali.sfaxi@unil.ch >=20 >=20 >=20 > 7 . References >=20 > [1] Bennet, C; Brassard, G (1984). IEEE International Conference=20 > on Computers, Systems, and Signal Processing. IEEE Press, LOS=20 > ALAMITOS >=20 > [2] Elliott, C (2002). =C2=94Building the quantum network=C2=94. New= Journal=20 > of Physics 4 (46.1-46.12) >=20 > [3] Elliott, C; Pearson, D; Troxel, G (2003). =C2=94Quantum > Cryptography in Practice=C2=94. >=20 > [4] Gisin, N; Ribordy, G; Tittel, W; Zbinden, H. (2002). =C2=94Quant= um=20 > Cryptography=C2=94. Reviews of Modern Physics 74 (2002). > =20 >=20 > [5] Ghernaouti H=C2=B4elie, S; Sfaxi, M.A; Ribordy, G; Gay, O (2005)= .=20 > =C2=93Using Quantum Key Distribution within IPSEC to secure MAN=20 > communications=C2=94. MAN 2005 conference. >=20 > [6] Guenther, C (2003) =C2=94The Relevance of Quantum Cryptography i= n > Modern Cryptographic Systems=C2=94. GSEC Partical Requirements=20 > (v1.4b). > http://www.giac.org/practical/GSEC/Christoph_Guenther_GSEC.pdf >=20 >=20 > [7] Internet Assigned Numbers Authority - IANA (2005). > http://www.iana.org/numbers.html >=20 > [8] Paterson, K.G; Piper, f; Schack, R (2004). =C2=94Why Quantum=20 > Cryptography?=C2=94. http://eprint.iacr.org/2004/156.pdf >=20 >=20 > Ghernaouti and Sfaxi [Page 6] > =0C > INTERNET-DRAFT Expires: April, 29 2006 >=20 >=20 > [9] Bradner, S., "Key words for use in RFCs to Indicate=20 > Requirement Levels", BCP 14, RFC 2119, Internet Engineering=20 > Task Force, March 1997. >=20 > [10]Schneier, B (1996). =C2=94Applied Cryptography=C2=94 Second Edit= ion. New=20 > York: John Wiley & Sons, 1996 >=20 > [11]Shannon, C.E (1949). =C2=94Communication theory of secrecy > systems=C2=94. Bell System Technical Journal 28-4.=20 > =20 >=20 >=20 > Intellectual Property Statement >=20 > The IETF takes no position regarding the validity or scope of any > Intellectual Property Rights or other rights that might be claimed > to pertain to the implementation or use of the technology=20 > described in this document or the extent to which any license=20 > under such rights might or might not be available; nor does it=20 > represent that it has made any independent effort to identify any=20 > such rights. >=20 > Information on the procedures with respect to rights in RFC > documents can be found in BCP 78 and BCP 79. >=20 > Copies of IPR disclosures made to the IETF Secretariat and any > assurances of licenses to be made available, or the result of an > attempt made to obtain a general license or permission for the use > of such proprietary rights by implementers or users of this > specification can be obtained from the IETF on-line IPR repository > at http://www.ietf.org/ipr. >=20 > The IETF invites any interested party to bring to its attention=20 > any copyrights, patents or patent applications, or other=20 > proprietary rights that may cover technology that may be required=20 > to implement this standard. Please address the information to the=20 > IETF at ietf-ipr@ietf.org. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ghernaouti and Sfaxi [Page 7] > =0C > INTERNET-DRAFT Expires: April, 29 2006 >=20 >=20 > Full Copyright Statement >=20 > Copyright (C) The Internet Society (2005). This document is > subject to the rights, licenses and restrictions contained in BCP > 78, and except as set forth therein, the authors retain all their > rights. >=20 > This document and the information contained herein are provided on > an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE > REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND > THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, > EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT > THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR > ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A > PARTICULAR PURPOSE. >=20 >=20 > Acknowledgement >=20 > Funding for the RFC Editor function is currently provided by the > Internet Society. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Ghernaouti and Sfaxi [Page 8] >=20 >=20 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Mon Oct 10 18:41:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP6KR-0003cK-7I; Mon, 10 Oct 2005 18:41:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EP6KO-0003aY-Vl for pppext@megatron.ietf.org; Mon, 10 Oct 2005 18:41:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00245 for ; Mon, 10 Oct 2005 18:41:01 -0400 (EDT) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EP6UO-0003wb-5R for pppext@ietf.org; Mon, 10 Oct 2005 18:51:24 -0400 Received: from calcite.rhyolite.com ([192.188.61.3]) by mx2.foretec.com with esmtp (Exim 4.24) id 1EP6KO-0008UG-Bo for pppext@ietf.org; Mon, 10 Oct 2005 18:41:04 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j9AMZUOj047924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Mon, 10 Oct 2005 16:35:30 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j9AMZUgf047923; Mon, 10 Oct 2005 16:35:30 -0600 (MDT) Date: Mon, 10 Oct 2005 16:35:30 -0600 (MDT) From: Vernon Schryver Message-Id: <200510102235.j9AMZUgf047923@calcite.rhyolite.com> To: iana-prot-param@icann.org Subject: Re: [Pppext] [rt.icann.org #3528] FW: General Request for Assignments (ppp-numbers) In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > Date: Mon, 10 Oct 2005 11:44:51 -0700 (PDT) > From: "Michelle Cotton via RT" > Cc: pppext@ietf.org > PPPEXT Working Group: > > This is a follow-up to a recent request you were reviewing for IANA. > The Working Group Chair requested that the group wanted to see the I-D > before making a decision. Below, please find the I-D sent to IANA by > the requestor. > > We will await your response. Judging from the last time I tried to reply to you, you may wait a long time for a response from me. I am reluctant to leap through Challenge-Response hoops, because Challenge-Response system are an abuse of the network. Either they do no good because the incoming message was perfectly legitimate, or they generally send noise to innocent third parties whose addresses are forged in spam. I have seen far more unsolicited, unprovoked substantially identical (i.e. bulk) C-R challenges due to forged mail than legitimate C-R challenges resulting from mail I've sent. > > draft-ghernaouti-sfaxi-ppp-qkd-00.txt Why isn't that draft in the familiar place on ftp.isi.edu? Why can't I find it at https://datatracker.ietf.org/public/idindex.cgi?command=search_id Is it a real (i.e. officiall published) I-D? It has no substance except this place keeper: > 5- QKD phase: > a. The source and the detector share a secret key exchanged > using quantum cryptography > b. When the secret key is ready go to Network phase All standards must contain sufficiently detailed specifications to allow people to build independent but interoperable implementations. Those words contain essentially no technical information. If they represent the design behind the proposed registry, the proposed registry must be rejected with prejudice. It is hard to see how ECP and quantum cryptography could interact directly. I can see how one might use quantum cryptography to choose a key that could then be used with PPP-ECP, but I don't see why PPP needs any changes. What is the difference as far as PPP is concerned between exchanging keys with quantum cryptography and with plain old telephones? Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Oct 11 02:25:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPDaE-0008QH-H2; Tue, 11 Oct 2005 02:25:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPDaD-0008OZ-25 for pppext@megatron.ietf.org; Tue, 11 Oct 2005 02:25:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01965 for ; Tue, 11 Oct 2005 02:25:51 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPDkE-0005vL-Hg for pppext@ietf.org; Tue, 11 Oct 2005 02:36:16 -0400 Received: by wproxy.gmail.com with SMTP id i12so801979wra for ; Mon, 10 Oct 2005 23:25:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=Gn7C+DVCB1E0HbX4KkEi1O+ZRvTcz2BOwcc0LxAxBPwiYbYEwslA3zeIqF6bwlbkC4r5tVVeA6yLnxb1cyND5TvcwHdFE4hiiMRWO7ng9ik8G55WDX4FA827sDgmdSS38+1yRXvMg0HKXolhxgvUhlqvDlBrOdiGLk8Yc1T1d/A= Received: by 10.54.34.30 with SMTP id h30mr665893wrh; Mon, 10 Oct 2005 23:25:39 -0700 (PDT) Received: by 10.54.119.19 with HTTP; Mon, 10 Oct 2005 23:25:39 -0700 (PDT) Message-ID: Date: Tue, 11 Oct 2005 11:55:39 +0530 From: Hariharasubramanian CS To: pppext@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: quoted-printable Subject: [Pppext] Doubt in rfc 1990.. X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org I went through RFC 1990 (MP)... It doesn't state clearly if IP packets MUST be encapsulated in Multilink Headers.... There is roundabout statement in the RFC : "Note that network protocols that are not sent using multilink headers cannot be sequenced. (And consequently will be delivered in any=20 convenient way). " What is the ietf's stand ? Can somebody cast some light? Thanks Hari. _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Oct 11 03:41:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPEld-0006Gi-8V; Tue, 11 Oct 2005 03:41:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPElb-0006Ga-CJ for pppext@megatron.ietf.org; Tue, 11 Oct 2005 03:41:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05681 for ; Tue, 11 Oct 2005 03:41:41 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPEvd-0007p1-IN for pppext@ietf.org; Tue, 11 Oct 2005 03:52:07 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 11 Oct 2005 00:41:32 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9B7fT4V027987; Tue, 11 Oct 2005 00:41:30 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 00:41:29 -0700 Received: from [198.18.159.207] ([10.21.121.154]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Oct 2005 00:41:28 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1CC580DB-75F2-4388-A2FC-F7953105FA0A@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: [Pppext] Doubt in rfc 1990.. Date: Tue, 11 Oct 2005 03:41:26 -0400 To: Hariharasubramanian CS X-Mailer: Apple Mail (2.734) X-OriginalArrivalTime: 11 Oct 2005 07:41:28.0882 (UTC) FILETIME=[30E5D920:01C5CE37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org it is perfectly legal to send some packets in PPP headers and some packets in Multilink headers. You'll find my name in the Acknowledgments; I (among others) spent a lot of time and email in discussion with the authors getting this right. When we designed PPP Multilink, we recognized that there were applications that might send IP packets that were small enough to not need fragmentation and for which the delays imposed by the fragmentation and reassembly procedures might be detrimental - voice on IP being the obvious example. We explicitly chose to permit them to be sent around the multilink channel. I think you will find several implementations that literally do that. Cisco's is called "Low Latency Queuing" by the marketing folks. On Oct 11, 2005, at 2:25 AM, Hariharasubramanian CS wrote: > I went through RFC 1990 (MP)... > > It doesn't state clearly if IP packets MUST be encapsulated in > Multilink Headers.... > > There is roundabout statement in the RFC : > > "Note that network protocols that are not sent using multilink headers > cannot be sequenced. (And consequently will be delivered in any > convenient way). " > > > What is the ietf's stand ? > Can somebody cast some light? > > Thanks > Hari. > > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www1.ietf.org/mailman/listinfo/pppext > _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Oct 11 07:15:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPI6R-0003nK-UE; Tue, 11 Oct 2005 07:15:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPI6P-0003nF-Rp for pppext@megatron.ietf.org; Tue, 11 Oct 2005 07:15:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14788 for ; Tue, 11 Oct 2005 07:15:20 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPIGQ-0004qp-Ok for pppext@ietf.org; Tue, 11 Oct 2005 07:25:50 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9BBFIHT009075 for ; Tue, 11 Oct 2005 04:15:18 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j9BBFHsr012211 for ; Tue, 11 Oct 2005 07:15:17 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j9BBFHMl014500; Tue, 11 Oct 2005 07:15:17 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j9BBFHM7014497; Tue, 11 Oct 2005 07:15:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17227.40645.354467.719125@gargle.gargle.HOWL> Date: Tue, 11 Oct 2005 07:15:17 -0400 From: James Carlson To: Fred Baker Subject: Re: [Pppext] Doubt in rfc 1990.. In-Reply-To: Fred Baker's message of 11 October 2005 03:41:26 References: <1CC580DB-75F2-4388-A2FC-F7953105FA0A@cisco.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Fred Baker writes: > it is perfectly legal to send some packets in PPP headers and some > packets in Multilink headers. More generally, with most PPP options, successful negotiation of the option allows but does not compel the sender to use the feature. If you negotiate away the HDLC Address and Control fields, or use PPP Protocol Field compression, or enable data compression via CCP, you may still send uncompressed data if you have a need to do so. The exceptions are fairly rare and straightforward, such as the use of ECP, where unencrypted packets are very likely to be dropped by the receiver for security reasons. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Tue Oct 11 07:29:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIK6-0006oY-U2; Tue, 11 Oct 2005 07:29:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPIK5-0006oO-Gt for pppext@megatron.ietf.org; Tue, 11 Oct 2005 07:29:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15539 for ; Tue, 11 Oct 2005 07:29:32 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPIU9-0005G9-CJ for pppext@ietf.org; Tue, 11 Oct 2005 07:39:59 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9BBTT1L022830 for ; Tue, 11 Oct 2005 05:29:29 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j9BBTSsp014125 for ; Tue, 11 Oct 2005 07:29:29 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j9BBTSot014549; Tue, 11 Oct 2005 07:29:28 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j9BBTSd3014546; Tue, 11 Oct 2005 07:29:28 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17227.41496.698960.152249@gargle.gargle.HOWL> Date: Tue, 11 Oct 2005 07:29:28 -0400 From: James Carlson To: Vernon Schryver Subject: Re: [Pppext] [rt.icann.org #3528] FW: General Request for Assignments (ppp-numbers) In-Reply-To: Vernon Schryver's message of 10 October 2005 16:35:30 References: <200510102235.j9AMZUgf047923@calcite.rhyolite.com> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org [Dropping IANA from the discussion until we have consensus; they're plenty busy as it is.] [Vern: please consider adding sgh@unil.ch and mohamedali.sfaxi@unil.ch to your response. Though you did post on an open list, I'm reluctant to add addresses to the cc list without permission. My response, though, can be copied freely.] Vernon Schryver writes: > Judging from the last time I tried to reply to you, you may wait a long > time for a response from me. I am reluctant to leap through Don't worry about it. I asked IANA to forward the information along to this list for comment. Once there's some consensus (and I suspect this will be quickly enough), I'll send a reply back, and I'll deal with whatever crufty spam-elimination nonsense they're using. > > > draft-ghernaouti-sfaxi-ppp-qkd-00.txt > > Why isn't that draft in the familiar place on ftp.isi.edu? > Why can't I find it at > https://datatracker.ietf.org/public/idindex.cgi?command=search_id > Is it a real (i.e. officiall published) I-D? I believe we're looking at the only copy of it. > > 5- QKD phase: > > a. The source and the detector share a secret key exchanged > > using quantum cryptography > > b. When the secret key is ready go to Network phase Well, that's not quite true. There's also the completely baffling ECP-QKD key option. If you're using some external mechanism to exchange keys, I don't see how or why you need to pass the key along as a configuration option. That makes no sense. It clearly destroys whatever goodness you might have hoped to get from the original key exchange, because you've just revealed the shared secret. Worse still, it specifies a key with no algorithm! How on Earth can a key be used without some agreed algorithm? And even more mysterious: of what possible use is a "one time pad?" This implies that you could send up to 64KB worth of payload on the link. Period. That's a pittance of data. How is it ever useful? > It is hard to see how ECP and quantum cryptography could interact > directly. I can see how one might use quantum cryptography to choose > a key that could then be used with PPP-ECP, but I don't see why PPP > needs any changes. What is the difference as far as PPP is concerned > between exchanging keys with quantum cryptography and with plain old > telephones? Exactly. That's what I said at the start: since it clearly requires careful installation of special-purpose hardware dedicated between the two peers, I don't see why it can't be settled by mutual consent, rather than requiring negotiation. Anyway, I agree that the submitter hasn't even approached the burden of disclosing what the new option might do, and thus we can't say it has received any sort of review. Any disagreement amongst those reading? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Oct 13 03:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxNe-0000cC-Jn; Thu, 13 Oct 2005 03:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPxNd-0000c7-EZ for pppext@megatron.ietf.org; Thu, 13 Oct 2005 03:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28489 for ; Thu, 13 Oct 2005 03:19:54 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPxY5-0001Us-MQ for pppext@ietf.org; Thu, 13 Oct 2005 03:30:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 13 Oct 2005 00:07:00 -0700 Message-ID: Thread-Topic: ACFC Thread-Index: AcXPxLUh3Zlo+yUNQ+y8kPG6j+gLVA== From: "Vishwas Manral" To: X-Spam-Score: 0.1 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [Pppext] ACFC X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0372886872==" Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org This is a multi-part message in MIME format. --===============0372886872== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5CFC4.43E678C2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5CFC4.43E678C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a doubt about ACFC.=20 =20 RFC1661 clearly states the reasons why PFC is not done for LCP frames. I wanted to know if ACFC can be done for NCP frames(or for any other control frames). Besides, what is the reason ACFC is not done for LCP frames? =20 Thanks, Vishwas ------_=_NextPart_001_01C5CFC4.43E678C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a doubt about ACFC. =

 

RFC1661 clearly states the reasons why PFC is not = done for LCP frames. I wanted to know if ACFC can be done for NCP frames(or for = any other control frames). Besides, what is the reason ACFC is not done for = LCP frames?

 

Thanks,

Vishwas

------_=_NextPart_001_01C5CFC4.43E678C2-- --===============0372886872== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --===============0372886872==-- From pppext-bounces@ietf.org Thu Oct 13 08:15:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ1uN-0003Bc-BD; Thu, 13 Oct 2005 08:10:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ1o2-00010Z-6I for pppext@megatron.ietf.org; Thu, 13 Oct 2005 08:03:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13177 for ; Thu, 13 Oct 2005 08:03:24 -0400 (EDT) Received: from uldns1.unil.ch ([130.223.8.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ1yW-0001D8-KA for pppext@ietf.org; Thu, 13 Oct 2005 08:14:21 -0400 Received: from hec170-187.unil.ch ([130.223.170.187]) by uldns1.unil.ch with esmtp (Exim 4.44) id 1EQ1nb-0004At-Rk; Thu, 13 Oct 2005 14:03:03 +0200 Message-ID: <434E4D01.5030400@unil.ch> Date: Thu, 13 Oct 2005 14:03:13 +0200 From: Mohamed Ali SFAXI User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson References: <17229.15711.955152.614897@gargle.gargle.HOWL> In-Reply-To: <17229.15711.955152.614897@gargle.gargle.HOWL> X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d48d865303330c98a6e90d450cf2ff2 X-Mailman-Approved-At: Thu, 13 Oct 2005 08:10:02 -0400 Cc: pppext@ietf.org, sgh@unil.ch Subject: [Pppext] Re: your ECP-QKD draft X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0890758624==" Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org This is a multi-part message in MIME format. --===============0890758624== Content-Type: multipart/alternative; boundary="------------080208080101060509090902" This is a multi-part message in MIME format. --------------080208080101060509090902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA13177 Dear James Carlson, Thank you for your comments here is our answer : =20 How: =20 To exchange the quantum key , both nodes must have some special features=20 (quantum devices) or simply a quantum modem (these modems like are=20 already sold by some companies such as IdQuantique (www.idquantique.com)=20 and MagiQ (http://www.magiqtech.com/)) =20 Here are some requirements to perform a quantum key distribution: =20 a- An optical channel: the optical channel is the physical link between=20 two adjacent nodes. Nowadays, there are two means able to carry a=20 quantum cryptography transmission: the optical fibber or the free space=20 (the air) [6]. As the quantum cryptography uses photons to encode the=20 information no other channel could be used up to now. However, as the=20 quantum physics are experimenting the use of atoms and electrons as a=20 quantum particle [7, 5] maybe other kind of channel could be used in the=20 future. =20 b- A Q3P modem: this modem has to polarize, send and detect photons; it=20 has to include a photon detector and a laser with a single photon=20 emitter and photon polariser. The source and the detector are widely=20 commercialised and many techniques are employed1. However, these devices=20 are used to exchange the quantum key but could also used to send and=20 receive simple data depending on how encoding the information. The modem=20 in this case is a simple optical fiber modem. =20 c- QKD protocol: in order to establish an unconditional secure key, a=20 quantum key distribution protocol is needed. This protocol must be=20 implemented in the Q3P modem. The protocol will deliver a secure key=20 after distilling the key and error correction [3]. The key is stored in=20 a flash buffer memory and used when enciphering the data. The QKD=20 protocols BB84 and B92 [1, 2] are nowadays the quantum cryptographic=20 protocols widely used. These protocols are securely proven and largely=20 experimented [4]. =20 =20 =20 Why: =20 All encryption algorithms used in PPP assume that there is an already=20 shared secret between the two nodes as cited in [RFC2419]: "The means by=20 which the secret becomes known to both communicating elements is beyond=20 the scope of this document; usually some form of manual configuration is=20 involved". We don't know how this key is generated, shared nor installed=20 in the PPP devices. Using the Q3P (and especially the QKD), we solve all the secure key=20 exchange problems. In fact, we could exchange an unconditional secure=20 key, on-demand and dynamically. =20 =20 =20 What might be done by this key : - can be used for instance in DESE [RFC2420] as the "initial nonce". - Can also be used in other encryption algorithms such as "One Time Pad"=20 function which need a new key for each message =20 =20 =20 =20 =20 References: =20 1. Bennet, C; Brassard, G (1984). IEEE International Conference on=20 Computers, Systems, and Signal Processing. IEEE Press, LOS ALAMITOS =20 2. Bennet, (1992). C Quantum Cryptography: Uncertainty in the Service of=20 Privacy. Science 257. =20 3. Gisin, N; Ribordy, G; Tittel, W; Zbinden, H. (2002). "Quantum=20 Cryptography". Reviews of Modern Physics 74 =20 4 Guenther, C (2003) "The Relevance of Quantum Cryptography in Modern=20 Cryptographic Systems". GSEC Partical Requirements (v1.4b).=20 http://www.giac.org/practical/GSEC/Christoph Guenther GSEC.pdf =20 5. Knight, P (2005). "Manipulating cold atoms for quantum information=20 processing". QUPON conference Vienna 2005. =20 6. R.Hughes,J.Nordholt,D.Derkacs,C.Peterson, (2002). "Practical=20 free-space quantum key distribution over 10km in daylight and at night".=20 New journal of physics 4 (2002)43.1-43.14. =20 7. Tonomura, A (2005). "Quantum phenomena observed using electrons".=20 QUPON conference Vienna 2005. *Mohamed Ali SFAXI* Assistant Dipl=F4m=E9 Inforge - HEC University of Lausanne tel. + 4121 692 34 22 Website : http://www.hec.unil.ch/sfaxi/ =20 James Carlson wrote: >This is currently being discussed on pppext@ietf.org. I encourage you >to participate in the discussion. > >The current concern is that the draft appears to have an explicit key >exchange (as part of the negotiation), but that the draft doesn't >explain how or why this key exchange exists, or what might be done >with those keys. (Clearly, they cannot be used for ECP, as they've >already been exposed to attackers by the negotiation itself.) > >Because of the lack of clarity in the specification, it seems likely >that the consensus will be to deny the request for a new ECP code >point, unless you can successfully argue your case. > > =20 > --------------080208080101060509090902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Dear James Carlson,


Thank you for your comments here is our answer :

 

How:

 

To exchange the quantum key , both nodes must have some special features (quantum devices) or simply a quantum modem (these modems like are already sold by some companies such as IdQuantique (www.idquantique.com) and MagiQ (http://www.magiqtech.com/))

 

Here are some requirements to perform a quantum key distribution:

 

a- An optical channel: the optical channel is the physical link between two adjacent nodes. Nowadays, there are two means able to carry a quantum cryptography transmission: the optical fibber or the free space (the air) [6]. As the quantum cryptography uses photons to encode the information no other channel could be used up to now. However, as the quantum physics are experimenting the use of atoms and electrons as a quantum particle [7, 5] maybe other kind of channel could be used in the future.

 

b- A Q3P modem: this modem has to polarize, send and detect photons; it has to include a photon detector and a laser with a single photon emitter and photon polariser. The source and the detector are widely commercialised and many techniques are employed1. However, these devices are used to exchange the quantum key but could also used to send and receive simple data depending on how encoding the information. The modem in this case is a simple optical fiber modem.

 

c- QKD protocol: in order to establish an unconditional secure key, a quantum key distribution protocol is needed. This protocol must be implemented in the Q3P modem. The protocol will deliver a secure key after distilling the key and error correction [3]. The key is stored in a flash buffer memory and used when enciphering the data. The QKD protocols BB84 and B92 [1, 2] are nowadays the quantum cryptographic protocols widely used. These protocols are securely proven and largely experimented [4].

 

      

 

Why:

 

All encryption algorithms used in PPP assume that there is an already shared secret between the two nodes as cited in [RFC2419]: “The means by which the secret becomes known to both communicating elements is beyond the scope of this document; usually some form of manual configuration is involved”. We don’t know how this key is generated, shared nor installed in the PPP devices.

Using the Q3P (and especially the QKD), we solve all the secure key exchange problems. In fact, we could exchange an unconditional secure key, on-demand and dynamically.

 

 

 

What might be done by this key :

- can be used for instance in DESE  [RFC2420] as the “initial nonce”.

- Can also be used in other encryption algorithms such as “One Time Pad” function which need a new key for each message

 

 

 

 

 

References:

 

1. Bennet, C; Brassard, G (1984). IEEE International Conference on Computers, Systems, and Signal Processing. IEEE Press, LOS ALAMITOS

 

2. Bennet, (1992). C Quantum Cryptography: Uncertainty in the Service of Privacy. Science 257.

 

3. Gisin, N; Ribordy, G; Tittel, W; Zbinden, H. (2002). ”Quantum Cryptography”. Reviews of Modern Physics 74

 

4 Guenther, C (2003) ”The Relevance of Quantum Cryptography in Modern Cryptographic Systems”. GSEC Partical Requirements (v1.4b). http://www.giac.org/practical/GSEC/Christoph Guenther GSEC.pdf

 

 5. Knight, P (2005). “Manipulating cold atoms for quantum information processing”. QUPON conference Vienna 2005.

 

6. R.Hughes,J.Nordholt,D.Derkacs,C.Peterson, (2002). ”Practical free-space quantum key distribution over 10km in daylight and at night”. New journal of physics 4 (2002)43.1-43.14.

 

7. Tonomura, A (2005). “Quantum phenomena observed using electrons”. QUPON conference Vienna 2005.



Mohamed Ali SFAXI

Mohamed Ali SFAXI
Assistant Diplômé
Inforge - HEC
University of Lausanne
tel. + 4121 692 34 22

Website : http://www.hec.unil.ch/sfaxi/

 



James Carlson wrote: 
This is currently being discussed on pppext@ietf.org.  I encourage you
to participate in the discussion.

The current concern is that the draft appears to have an explicit key
exchange (as part of the negotiation), but that the draft doesn't
explain how or why this key exchange exists, or what might be done
with those keys.  (Clearly, they cannot be used for ECP, as they've
already been exposed to attackers by the negotiation itself.)

Because of the lack of clarity in the specification, it seems likely
that the consensus will be to deny the request for a new ECP code
point, unless you can successfully argue your case.
--------------080208080101060509090902-- --===============0890758624== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --===============0890758624==-- From pppext-bounces@ietf.org Thu Oct 13 08:50:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2XT-0004nF-EF; Thu, 13 Oct 2005 08:50:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2XR-0004n4-Sl for pppext@megatron.ietf.org; Thu, 13 Oct 2005 08:50:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15476 for ; Thu, 13 Oct 2005 08:50:18 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ2hs-0002PQ-9V for pppext@ietf.org; Thu, 13 Oct 2005 09:01:16 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9DCoHvD019253 for ; Thu, 13 Oct 2005 06:50:17 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j9DCoHsn028003 for ; Thu, 13 Oct 2005 08:50:17 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j9DCoHij023102; Thu, 13 Oct 2005 08:50:17 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j9DCoHTm023099; Thu, 13 Oct 2005 08:50:17 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17230.22537.27198.851536@gargle.gargle.HOWL> Date: Thu, 13 Oct 2005 08:50:17 -0400 From: James Carlson To: Vishwas Manral Subject: Re: [Pppext] ACFC In-Reply-To: Vishwas Manral's message of 13 October 2005 00:07:00 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Vishwas Manral writes: > RFC1661 clearly states the reasons why PFC is not done for LCP frames. I > wanted to know if ACFC can be done for NCP frames(or for any other > control frames). For NCP? Sure. It can't be done for LCP, because LCP is *how* you negotiate ACFC. If you allow it there, you end up with a chicken-and-egg problem. > Besides, what is the reason ACFC is not done for LCP > frames? The above. If you want a formal reason, the options negotiated by any xCP (including NCPs and LCP itself) are not put into effect until the xCP reaches Opened state. Until that point is reached, all optional features must be in the defined "default" state. Thus, until you've negotiated ACFC via LCP and LCP is in Opened state, you can't actually do ACFC compression, and if you leave Opened state (by sending a new LCP Configure-Request message to start renegotiation), then you must revert to the defaults as well. I suppose there's an edge case here: one could possibly argue that there's no reason to disallow ACFC on non-Configure-* LCP frames sent while in Opened state, such as LCP Echo-Request. However, it's not as though LCP is itself very high rate traffic that would benefit from removing just two octets from any message, and it's nearly impossible to justify that level of complexity. It's much simpler to just say that LCP messages are never compressed with ACFC. In addition, it is necessarily the case with almost all PPP options that they merely *permit* the sender to use the requested feature, and do not *compel* the sender to use it. In other words, if you negotiate ACFC, you don't actually have to compress out those fields if you don't want to, and the receiver *MUST* handle frames that contain the HDLC Address and Control fields at all times. Thus, including those fields does not do harm, and it does good by reducing complexity. (And, obviously, as LCP is protocol C021, PFC cannot possibly apply. PFC works only if the upper octet is 00.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Oct 13 09:17:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2xq-0003GW-23; Thu, 13 Oct 2005 09:17:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ2xn-0003GH-Ua for pppext@megatron.ietf.org; Thu, 13 Oct 2005 09:17:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16731 for ; Thu, 13 Oct 2005 09:17:34 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ38K-00037Q-1J for pppext@ietf.org; Thu, 13 Oct 2005 09:28:32 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9DDHbHT014959 for ; Thu, 13 Oct 2005 06:17:38 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j9DDHbsn004321 for ; Thu, 13 Oct 2005 09:17:37 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j9DDHbtx023253; Thu, 13 Oct 2005 09:17:37 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j9DDHbWv023250; Thu, 13 Oct 2005 09:17:37 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=unknown Content-Transfer-Encoding: quoted-printable Message-ID: <17230.24177.218809.473754@gargle.gargle.HOWL> Date: Thu, 13 Oct 2005 09:17:37 -0400 From: James Carlson To: Mohamed Ali SFAXI Subject: Re: [Pppext] Re: your ECP-QKD draft In-Reply-To: Mohamed Ali SFAXI's message of 13 October 2005 14:03:13 References: <17229.15711.955152.614897@gargle.gargle.HOWL> <434E4D01.5030400@unil.ch> X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org, sgh@unil.ch X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Mohamed Ali SFAXI writes: > To exchange the quantum key , both nodes must have some special featu= res=20 > (quantum devices) or simply a quantum modem (these modems like are=20= > already sold by some companies such as IdQuantique (www.idquantique.c= om)=20 > and MagiQ (http://www.magiqtech.com/)) Yes, understood. However, none of the explanation you've offered actually addresses the questions I've asked. Please examine this feature from your proposed draft: > To establish and configure the quantum key distribution between=20= > the two nodes, it is necessary to exchange some data between=20 > them. We propose a specific ECP packet format to carry QKD=20 > parameters (Figure 2): >=20 >=20 > 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 | Key-Length > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= > | TTL |T| =20 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- [...] > Length field: > The length is number of octets in the packet and it is more than=20= > =945=94 octets (1 octet for the type, 1 octet for the packet leng= th,=20 > 2 octets for the key length and one octet for the TTL and the T=20= > field). This appears to describe a new option for ECP that exchanges keys between the peers, and does the exchange in the clear. Why does it do that? What does it have to do with quantum key exchange? Moreover, the draft does not explain how the key to be used with the chosen algorithm is actually derived, nor what algorithms are possible, so there's essentially no hope of interoperability. As IETF documents have the explicit goal of producing interoperable implementations, this draft falls short of what's needed. --=20 James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 208= 4 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 167= 7 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Oct 13 10:23:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3zD-00069R-CV; Thu, 13 Oct 2005 10:23:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ3zB-00069M-Bd for pppext@megatron.ietf.org; Thu, 13 Oct 2005 10:23:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20760 for ; Thu, 13 Oct 2005 10:23:05 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQ49g-00058I-Mo for pppext@ietf.org; Thu, 13 Oct 2005 10:34:02 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j9DEMbAb027494 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) env-from ; Thu, 13 Oct 2005 08:22:37 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j9DEMbK2027493; Thu, 13 Oct 2005 08:22:37 -0600 (MDT) Date: Thu, 13 Oct 2005 08:22:37 -0600 (MDT) From: Vernon Schryver Message-Id: <200510131422.j9DEMbK2027493@calcite.rhyolite.com> To: MohamedAli.Sfaxi@unil.ch Subject: Re: [Pppext] Re: your ECP-QKD draft In-Reply-To: <434E4D01.5030400@unil.ch> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: pppext@ietf.org, sgh@unil.ch X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > From: Mohamed Ali SFAXI > To: James Carlson > Cc: pppext@ietf.org, sgh@unil.ch > Thank you for your comments here is our answer : Your answer is not responsive. Perhaps the best way to answer the objections to the I-D and the proposed IANA registry would be for you to build a complete prototype implementation of the idea or at least a design complete in all aspects. Given your claim that quantum cryptography is a settled technology (never mind http://www.idquantique.com/news/files/june-05.pdf ), it should be easy to make a complete design including writing software. You could base such an effort on one of the open-source implementations of PPP with encryption and add whatever is needed to work with your quantum encryption hardware. You would not need to buy quantum cryptography hardware but could write code to specifictions obtained from id Quantique or MagiQ. > To exchange the quantum key , both nodes must have some special features=20 > (quantum devices) or simply a quantum modem (these modems like are=20 > already sold by some companies such as IdQuantique (www.idquantique.com)=20 > and MagiQ (http://www.magiqtech.com/)) As far as PPP is concerned, exactly the same is true of any use of PPP encryption. In general one does not change PPP when one uses new kinds of modems. > Here are some requirements to perform a quantum key distribution: > > a- An optical channel: the optical channel is the physical link between=20 > two adjacent nodes. Nowadays, there are two means able to carry a=20 > quantum cryptography transmission: the optical fibber or the free space=20 > (the air) [6]. As the quantum cryptography uses photons to encode the=20 > information no other channel could be used up to now. However, as the=20 > quantum physics are experimenting the use of atoms and electrons as a=20 > quantum particle [7, 5] maybe other kind of channel could be used in the=20 > future. That fact does not affect PPP, and does not answer the questions that have been raised about your I-D. > b- A Q3P modem: this modem has to polarize, send and detect photons; it=20 > has to include a photon detector and a laser with a single photon=20 > emitter and photon polariser. The source and the detector are widely=20 > commercialised and many techniques are employed1. However, these devices=20 > are used to exchange the quantum key but could also used to send and=20 > receive simple data depending on how encoding the information. The modem=20 > in this case is a simple optical fiber modem. That also does not affect PPP, and does not answer the questions raised about your I-D. > c- QKD protocol: in order to establish an unconditional secure key, a=20 > quantum key distribution protocol is needed. This protocol must be=20 > implemented in the Q3P modem. The protocol will deliver a secure key=20 > after distilling the key and error correction [3]. The key is stored in=20 > a flash buffer memory and used when enciphering the data. The QKD=20 > protocols BB84 and B92 [1, 2] are nowadays the quantum cryptographic=20 > protocols widely used. These protocols are securely proven and largely=20 > experimented [4]. That also has nothing to do with PPP. Never mind that I disagree with the claim that anything about quantum cryptography is settled technology. Except that the encryption key is negoiated with quantum cryptography, that description fits existing PPP encryption implementations. In fact, your description fits existing PPP implementations better than a system involving quantum cryptography, because I doubt that one would want to store keys negotiated with quantum cryptogrpah in a flash buffer memory. > Why: > > All encryption algorithms used in PPP assume that there is an already=20 > shared secret between the two nodes as cited in [RFC2419]: "The means by=20 > which the secret becomes known to both communicating elements is beyond=20 > the scope of this document; usually some form of manual configuration is=20 > involved". We don't know how this key is generated, shared nor installed=20 > in the PPP devices. > > Using the Q3P (and especially the QKD), we solve all the secure key=20 > exchange problems. In fact, we could exchange an unconditional secure=20 > key, on-demand and dynamically. Yes, but that has nothing to do with PPP itself. well, I'm not quite right. Anyone who understands PPP sees an opportunity to write a real I-D saying when to use quantum cryptography to negoiate a new key PPP encryption key based on certain PPP state changes. That would not involve a change to PPP beyond a pause for obtaining new random numbers (keys) and negotiating exchanging them over the (presumably relatively slow) quantum cryptography channel before continuing PPP as usual. > What might be done by this key : > > - can be used for instance in DESE [RFC2420] as the "initial nonce". > > - Can also be used in other encryption algorithms such as "One Time Pad"=20 > function which need a new key for each message The only positive way I understand that statement is as proposing to use quantum cryptography not exchange keys before IPCP starts but to carry all PPP bits. As such it still has nothing to do with PPP, because you are proposing a new channel above which would be PPP. In other words, do MagiQ (http://www.magiqtech.com/) and id Quantique (http://www.idquantique.com/) agree with your claim that PPP must be changed to use their modems? PPP often does not change to use new kinds of conventional modems. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Oct 13 18:50:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBuK-0008HU-Mb; Thu, 13 Oct 2005 18:50:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQBtk-0007vQ-GR; Thu, 13 Oct 2005 18:50:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24901; Thu, 13 Oct 2005 18:50:00 -0400 (EDT) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQC4J-0004EE-SI; Thu, 13 Oct 2005 19:01:00 -0400 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1EQBth-0007hR-ML; Thu, 13 Oct 2005 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 13 Oct 2005 18:50:01 -0400 X-Spam-Score: 0.4 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: pppext@ietf.org Subject: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Point-to-Point Protocol Extensions Working Group of the IETF. Title : Accommodating an MTU/MRU greater than 1492 in PPPoE Author(s) : P. Arberg, et al. Filename : draft-arberg-pppoe-mtu-gt1492-01.txt Pages : 7 Date : 2005-10-13 Point-to-Point Protocol Over Ethernet (PPPoE), as described in RFC 2516 [1], mandates a maximum negotiated MRU of 1492. This document outlines a solution to relax that restriction and allow a maximum negotiated MRU greater than 1492 to minimize fragmentation in next generation broadband networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-arberg-pppoe-mtu-gt1492-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-arberg-pppoe-mtu-gt1492-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-arberg-pppoe-mtu-gt1492-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-10-13163925.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-arberg-pppoe-mtu-gt1492-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-arberg-pppoe-mtu-gt1492-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-10-13163925.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --NextPart-- From pppext-bounces@ietf.org Thu Oct 13 20:47:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQDjK-0004kU-Ky; Thu, 13 Oct 2005 20:47:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQDjI-0004kI-J7 for pppext@megatron.ietf.org; Thu, 13 Oct 2005 20:47:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA07045 for ; Thu, 13 Oct 2005 20:47:19 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQDtu-0001DO-L2 for pppext@ietf.org; Thu, 13 Oct 2005 20:58:23 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j9E0l9CT004762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Thu, 13 Oct 2005 18:47:09 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j9E0l9SJ004761 for pppext@ietf.org; Thu, 13 Oct 2005 18:47:09 -0600 (MDT) Date: Thu, 13 Oct 2005 18:47:09 -0600 (MDT) From: Vernon Schryver Message-Id: <200510140047.j9E0l9SJ004761@calcite.rhyolite.com> To: pppext@ietf.org Subject: Re: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > http://www.ietf.org/internet-drafts/draft-arberg-pppoe-mtu-gt1492-01.txt I'm not sure what I think of the new version of this proposal, because I'm somewhat confused by the text. The text may be much better and I may have a much better understanding, because my intuitive reaction is not the horror produced by the first version. Page 3 says: In the network design shown in figure 2, fragmentation becomes a major problem since the subscriber session is a combination of IPoE and PPPoE. The IPoE typically negotiates a MTU of 1500 bytes. However, when the Residential Gateway and the Edge Aggregation Router are the PPPoE session endpoints, and therefore negotiate a MTU/MRU of 1492 bytes resulting in a large number of fragmented packets in the network. I cannot find "Edge Aggregation Router" in Figure 2. Perhaps it is the "BRAS," which section 1 says means "Broadband Remote Access Server." There are similar problems on the bottom of page 3 which talks about "DSL Routers " without saying whether they are "CPE", "RG", "BRAS," or something else. Then there is whatever a "PPPoE server" might be. The last paragraph contains what I suspect is an incorrect statement: The subscriber session is a PPP session running over a combination of PPPoA and PPPoE. I suspect it should say something like The subscriber session is a ***pair of*** PPP sessions running over a combination of PPPoA and PPPoE. The difference is significant because of the number of PPP state machines involved and so what might be practical. If a single PPP session is involved, then there is no fragmentation problem in the second network diagrammed in Figure 3, because it is the same as the network in Figure 1. If there are two PPP sessions in the second network in Figure 3, why is there fragmentation problem? The PPP state machine in the BRAS can ask for and get presumably both MTU and MRU of 1492 from PPP state machine in the PC. If there are two PPP sessions as the diagram suggests, then the PPP state machine in the DSLAM can anticipate the need for 1492 and ask for and get 1492 MRU and MTU. However, maybe that is the point of the third paragraphs on page 4. If so, that text needs to be improved. Does that third paragraph conflict with the first and second?--I think so. Perhaps the first two paragraphs could be moved to after the current third paragraph. Perhaps Figure 3 should be divided into 2 figures. One would be the first network, where something might need to be done to prevent IP fragmentation. The other would be the second network where nothing but common sense is needed. The fourth paragraph on page 4 and section 4 need to define terms including "PPPoE client" and "PPPoE server." It is not clear to me whether the text is confused about the fact the PPP world there are no such things as "servers" or "clients" or it is following RFC 2516. Section 3 of RFC 2516 defines "a Host (the client)" and "an Access Concentrator (the server)." If those notions are intended in this document, then perhaps it should use those terms instead of inventing new terms. It should at elast related them to the boxes defined in this document such as "PC", "DSLAM", and "BRAS." Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Oct 13 22:58:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQFmB-0004Q0-5r; Thu, 13 Oct 2005 22:58:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQFm9-0004Pu-LH for pppext@megatron.ietf.org; Thu, 13 Oct 2005 22:58:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12195 for ; Thu, 13 Oct 2005 22:58:25 -0400 (EDT) Received: from prattle.redback.com ([155.53.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQFwn-0004O3-1N for pppext@ietf.org; Thu, 13 Oct 2005 23:09:29 -0400 Received: from localhost (localhost [127.0.0.1]) by prattle.redback.com (Postfix) with ESMTP id D6550BE3487; Thu, 13 Oct 2005 19:58:15 -0700 (PDT) Received: from prattle.redback.com ([127.0.0.1]) by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12310-09; Thu, 13 Oct 2005 19:58:15 -0700 (PDT) Received: from PARBETM2XP (login002.redback.com [155.53.12.54]) by prattle.redback.com (Postfix) with ESMTP id 5317DBE3486; Thu, 13 Oct 2005 19:58:15 -0700 (PDT) From: "Peter Arberg" To: "'Vernon Schryver'" , Subject: RE: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt Date: Thu, 13 Oct 2005 19:58:12 -0700 Organization: Redback Networks MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcXQWdcjqXu26eXmS6e1D+pl0iorOwADOSyQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <200510140047.j9E0l9SJ004761@calcite.rhyolite.com> Message-Id: <20051014025815.5317DBE3486@prattle.redback.com> X-Virus-Scanned: by amavisd-new at redback.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Content-Transfer-Encoding: 7bit Cc: X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: parberg@redback.com List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Vernon, thanks for the feedback, I have included comments/answers inline in the email. > > I'm not sure what I think of the new version of this proposal, because > I'm somewhat confused by the text. The text may be much better and I > may have a much better understanding, because my intuitive reaction > is not the horror produced by the first version. that's good. > > Page 3 says: > > In the network design shown in figure 2, fragmentation becomes a > major problem since the subscriber session is a combination of > IPoE and PPPoE. The IPoE typically negotiates a MTU of 1500 bytes. > However, when the Residential Gateway and the Edge Aggregation > Router are the PPPoE session endpoints, and therefore negotiate > a MTU/MRU of 1492 bytes resulting in a large number of fragmented > packets in the network. > > I cannot find "Edge Aggregation Router" in Figure 2. Perhaps it is > the "BRAS," which section 1 says means "Broadband Remote > Access Server." Agree, I used wrong names, and will correct it. You are correct where I say Edge Aggregation Router, it is the same as the BRAS > > There are similar problems on the bottom of page 3 which talks about > "DSL Routers " without saying whether they are "CPE", "RG", "BRAS," > or something else. Then there is whatever a "PPPoE server" might be. Agree, again wrong use of names, I will make sure to update it to say CPE equipment. The DSL router term is used instead of CPE or RG in the document. > The last paragraph contains what I suspect is an incorrect statement: > > The subscriber session is a PPP session running over a > combination of PPPoA and PPPoE. > > I suspect it should say something like > > The subscriber session is a ***pair of*** PPP sessions > running over a combination of PPPoA and PPPoE. No it is suppose to show 1 PPP session here. > > The difference is significant because of the number of PPP > state machines > involved and so what might be practical. If a single PPP session is > involved, then there is no fragmentation problem in the second network > diagrammed in Figure 3, because it is the same as the network > in Figure 1. Fig. 3 is suppose to illustrate the situation where customer equipment, either a CPE or a PC is a PPPoA host, but the BRAS is a PPPoE access concentrator. Many PPPoA hosts deployed today will not allow a MRU negotiation less than 1500, and since in this diagram the DSLAM is a "media" converter, converting the PPPoA session to a PPPoE session, the way it is doing this, is when it sees a PPPoA session setup (conf. req.) the DSLAM will initiate a PPPoE discovery state towards the BRAS, and as such the BRAS now is in RFC2516 land, and will restrict the MRU/MTU to 1492 bytes. As soon as the PPPoE discovery state initiated by the DSLAM is done, the DSLAM will forward the lcp confreq and then pass through all PPP control packets in both directions between the customer equipment (CPE or PC) and the BRAS. As such 1 PPP session end-2-end is running, but if MRU has not been negotiated they will have different views of the world since it is a PPPoA host and a PPPoE access concentrator. If MRU is negotiated the session will proabably end up being dropped since they can't agree on the MRU negotiation. > If there are two PPP sessions in the second network in Figure 3, > why is there fragmentation problem? The PPP state machine in the BRAS > can ask for and get presumably both MTU and MRU of 1492 from PPP state > machine in the PC. There is only 1 session > If there are two PPP sessions as the diagram suggests, then the PPP > state machine in the DSLAM can anticipate the need for 1492 > and ask for and get 1492 MRU and MTU. However, maybe that is > the point of the third > paragraphs on page 4. If so, that text needs to be improved. Does > that third paragraph conflict with the first and second?--I think so. > Perhaps the first two paragraphs could be moved to after the current > third paragraph. Not sure I follow you. The PPP state machine in the DSLAM is not really existing, all the DSLAM is doing is initiate a PPPoE discovery state when a PPP host sends a LCP conf.req. and as soon as the PPPoE discover statge is done, it will forward the conf.req. after this the DSLAM's PPP involvement is done, and it will forward all ppp control packets. > > Perhaps Figure 3 should be divided into 2 figures. One would be the > first network, where something might need to be done to prevent IP > fragmentation. The other would be the second network where nothing > but common sense is needed. Agree the picture could be divided into 2, one where fragmentation for sure could be an issue, and one where PPP session setup might not be able to happen. I simply combined it into one picture since the idea is to show that problems can exist in a setup where a DSLA is working as a PPPoA/oE translation. > The fourth paragraph on page 4 and section 4 need to define terms > including "PPPoE client" and "PPPoE server." It is not clear to me > whether the text is confused about the fact the PPP world there are > no such things as "servers" or "clients" or it is following RFC 2516. > Section 3 of RFC 2516 defines "a Host (the client)" and "an Access > Concentrator (the server)." If those notions are intended in this > document, then perhaps it should use those terms instead of inventing > new terms. It should at elast related them to the boxes defined in > this document such as "PC", "DSLAM", and "BRAS." Good comment, I will make sure to change the client to host since I wrongly use client for both a PPPoA as well as a PPPoE host. The PPPoE server I can either put into terminology, or simply change to access concentrator (bras), since client-server is defined in RFC2516, and as such I did not see a need to define it again. --- RFC 2516 snip ---- While PPP defines a peer-to-peer relationship, Discovery is inherently a client-server relationship. In the Discovery process, a Host (the client) discovers an Access Concentrator (the server) ----------------------- thanks for your comments. Peter > > > Vernon Schryver vjs@rhyolite.com > > _______________________________________________ > Pppext mailing list > Pppext@ietf.org > https://www1.ietf.org/mailman/listinfo/pppext _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Thu Oct 13 23:43:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGU9-0001TT-MA; Thu, 13 Oct 2005 23:43:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQGU9-0001SL-0Q for pppext@megatron.ietf.org; Thu, 13 Oct 2005 23:43:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13891 for ; Thu, 13 Oct 2005 23:43:53 -0400 (EDT) Received: from calcite.rhyolite.com ([192.188.61.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQGel-0005JJ-Rr for pppext@ietf.org; Thu, 13 Oct 2005 23:54:57 -0400 Received: from calcite.rhyolite.com (localhost [127.0.0.1]) by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j9E3hffk037308 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for env-from ; Thu, 13 Oct 2005 21:43:41 -0600 (MDT) Received: (from vjs@localhost) by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j9E3hfBZ037307 for pppext@ietf.org; Thu, 13 Oct 2005 21:43:41 -0600 (MDT) Date: Thu, 13 Oct 2005 21:43:41 -0600 (MDT) From: Vernon Schryver Message-Id: <200510140343.j9E3hfBZ037307@calcite.rhyolite.com> To: pppext@ietf.org Subject: RE: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt In-Reply-To: <20051014025815.5317DBE3486@prattle.redback.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org > From: "Peter Arberg" > > The subscriber session is a ***pair of*** PPP sessions > > running over a combination of PPPoA and PPPoE. > > No it is suppose to show 1 PPP session here. > less than 1500, and since in this diagram the DSLAM is a "media" > converter, converting the PPPoA session to a PPPoE session, the All of that belongs in the draft, not least because it is not exactly, precisely true that exactly 1 PPP session is involved. > Not sure I follow you. The PPP state machine in the DSLAM is not > really existing, all the DSLAM is doing is initiate a PPPoE discovery > state when a PPP host sends a LCP conf.req. and as soon as the > PPPoE discover statge is done, it will forward the conf.req. Is the configure-request potentially modified with the appropriate MRU? If not, then I don't see any point in the PPPoE discovery. If so, then it is wrong to say that only 1 PPP session is involved. Maybe fewer than 2 sessions, such as 1.2 sessions or 1 perverted/NAT-like PPP session, but not one, real, clean, pure PPP session. Vernon Schryver vjs@rhyolite.com _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Oct 14 01:18:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQHxZ-0005nI-NG; Fri, 14 Oct 2005 01:18:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQHxY-0005nB-06 for pppext@megatron.ietf.org; Fri, 14 Oct 2005 01:18:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17932 for ; Fri, 14 Oct 2005 01:18:18 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQI8C-0007c7-A2 for pppext@ietf.org; Fri, 14 Oct 2005 01:29:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] ACFC Date: Thu, 13 Oct 2005 22:21:22 -0700 Message-ID: Thread-Topic: [Pppext] ACFC Thread-Index: AcXP9KrIFxJYPwUyQOqEsZJNHkVvSQAigadg From: "Vishwas Manral" To: "James Carlson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi James, Thanks a lot for the reply. I had another small follow up question. When would we (if we ever would) have data traffic having uncompressed fields, even when compression was negotiated (both ACFC and PFC)? I know the RFC states that we should treat both un-compressed and compressed header fields in the same way when compression is negotiated. Thanks, Vishwas -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com]=20 Sent: Thursday, October 13, 2005 6:20 PM To: Vishwas Manral Cc: pppext@ietf.org Subject: Re: [Pppext] ACFC Vishwas Manral writes: > RFC1661 clearly states the reasons why PFC is not done for LCP frames. I > wanted to know if ACFC can be done for NCP frames(or for any other > control frames). For NCP? Sure. It can't be done for LCP, because LCP is *how* you negotiate ACFC. If you allow it there, you end up with a chicken-and-egg problem. > Besides, what is the reason ACFC is not done for LCP > frames? The above. If you want a formal reason, the options negotiated by any xCP (including NCPs and LCP itself) are not put into effect until the xCP reaches Opened state. Until that point is reached, all optional features must be in the defined "default" state. Thus, until you've negotiated ACFC via LCP and LCP is in Opened state, you can't actually do ACFC compression, and if you leave Opened state (by sending a new LCP Configure-Request message to start renegotiation), then you must revert to the defaults as well. I suppose there's an edge case here: one could possibly argue that there's no reason to disallow ACFC on non-Configure-* LCP frames sent while in Opened state, such as LCP Echo-Request. However, it's not as though LCP is itself very high rate traffic that would benefit from removing just two octets from any message, and it's nearly impossible to justify that level of complexity. It's much simpler to just say that LCP messages are never compressed with ACFC. In addition, it is necessarily the case with almost all PPP options that they merely *permit* the sender to use the requested feature, and do not *compel* the sender to use it. In other words, if you negotiate ACFC, you don't actually have to compress out those fields if you don't want to, and the receiver *MUST* handle frames that contain the HDLC Address and Control fields at all times. Thus, including those fields does not do harm, and it does good by reducing complexity. (And, obviously, as LCP is protocol C021, PFC cannot possibly apply. PFC works only if the upper octet is 00.) --=20 James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Oct 14 08:52:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQP2Y-0004dr-EZ; Fri, 14 Oct 2005 08:52:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQP2W-0004ZA-PL for pppext@megatron.ietf.org; Fri, 14 Oct 2005 08:52:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07799 for ; Fri, 14 Oct 2005 08:51:53 -0400 (EDT) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQPDB-0002LH-87 for pppext@ietf.org; Fri, 14 Oct 2005 09:03:03 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9ECps1L000325 for ; Fri, 14 Oct 2005 06:51:54 -0600 (MDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j9ECps0t024022 for ; Fri, 14 Oct 2005 08:51:54 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j9ECpsp1027702; Fri, 14 Oct 2005 08:51:54 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j9ECpsfr027699; Fri, 14 Oct 2005 08:51:54 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17231.43497.973063.374425@gargle.gargle.HOWL> Date: Fri, 14 Oct 2005 08:51:53 -0400 From: James Carlson To: Vishwas Manral Subject: RE: [Pppext] ACFC In-Reply-To: Vishwas Manral's message of 13 October 2005 22:21:22 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Vishwas Manral writes: > I had another small follow up question. When would we (if we ever would) > have data traffic having uncompressed fields, even when compression was > negotiated (both ACFC and PFC)? Any time the sender feels like it. Perhaps I'm not understanding the question correctly. If you're actually asking whether this is "common" or not, or if there are particular deployment scenarios in which it happens, I don't know. If your goal here is somehow to avoid implementing this correctly, so that all your system handles is header-compressed messages, then I'd strongly caution against that. Being more strict than what the RFC requires is a good way to end up with interoperability problems. > I know the RFC states that we should treat both un-compressed and > compressed header fields in the same way when compression is negotiated. And, indeed, you must. If you don't like that, then you can always refuse to use these options instead. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Oct 14 09:23:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPWk-0006z4-Du; Fri, 14 Oct 2005 09:23:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPWi-0006yz-Pj for pppext@megatron.ietf.org; Fri, 14 Oct 2005 09:23:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09330 for ; Fri, 14 Oct 2005 09:23:07 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQPhQ-00038k-PU for pppext@ietf.org; Fri, 14 Oct 2005 09:34:18 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Pppext] ACFC Date: Fri, 14 Oct 2005 06:26:09 -0700 Message-ID: Thread-Topic: [Pppext] ACFC Thread-Index: AcXQvg68N0n/M+nBTkmj9Bir/zWuIQABFuHw From: "Vishwas Manral" To: "James Carlson" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Hi James, You rightly guessed it. It is the "common" case, I was enquiring about. I was wondering if cases where we had uncompressed fields even when ACFC and PFC were configured, we may not necessarily handle it in the fast path and yet handle it in the slow path. Thanks, Vishwas -----Original Message----- From: James Carlson [mailto:james.d.carlson@sun.com]=20 Sent: Friday, October 14, 2005 6:22 PM To: Vishwas Manral Cc: pppext@ietf.org Subject: RE: [Pppext] ACFC Vishwas Manral writes: > I had another small follow up question. When would we (if we ever would) > have data traffic having uncompressed fields, even when compression was > negotiated (both ACFC and PFC)? Any time the sender feels like it. Perhaps I'm not understanding the question correctly. If you're actually asking whether this is "common" or not, or if there are particular deployment scenarios in which it happens, I don't know. If your goal here is somehow to avoid implementing this correctly, so that all your system handles is header-compressed messages, then I'd strongly caution against that. Being more strict than what the RFC requires is a good way to end up with interoperability problems. > I know the RFC states that we should treat both un-compressed and > compressed header fields in the same way when compression is negotiated. And, indeed, you must. If you don't like that, then you can always refuse to use these options instead. --=20 James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Oct 14 09:28:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPbV-00084z-8b; Fri, 14 Oct 2005 09:28:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPbU-00084u-07 for pppext@megatron.ietf.org; Fri, 14 Oct 2005 09:28:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09527 for ; Fri, 14 Oct 2005 09:28:02 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQPmC-0003Fr-2h for pppext@ietf.org; Fri, 14 Oct 2005 09:39:13 -0400 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j9EDS52B014879 for ; Fri, 14 Oct 2005 06:28:05 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j9EDS40t001836 for ; Fri, 14 Oct 2005 09:28:04 -0400 (EDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j9EDS3xN000066; Fri, 14 Oct 2005 09:28:03 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j9EDS3dT000063; Fri, 14 Oct 2005 09:28:03 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17231.45667.259701.76664@gargle.gargle.HOWL> Date: Fri, 14 Oct 2005 09:28:03 -0400 From: James Carlson To: Vishwas Manral Subject: RE: [Pppext] ACFC In-Reply-To: Vishwas Manral's message of 14 October 2005 06:26:09 References: X-Mailer: VM 7.01 under Emacs 21.3.1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: pppext@ietf.org X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org Vishwas Manral writes: > You rightly guessed it. It is the "common" case, I was enquiring about. > > I was wondering if cases where we had uncompressed fields even when ACFC > and PFC were configured, we may not necessarily handle it in the fast > path and yet handle it in the slow path. The standards say nothing about "fast" or "slow" -- those are implementation and customer acceptance issues. They say only that it must work. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext From pppext-bounces@ietf.org Fri Oct 14 09:29:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPcv-0008Kx-Lt; Fri, 14 Oct 2005 09:29:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPX2-00071z-0o for pppext@megatron.ietf.org; Fri, 14 Oct 2005 09:23:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09354 for ; Fri, 14 Oct 2005 09:23:26 -0400 (EDT) Received: from uldns1.unil.ch ([130.223.8.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQPhi-000392-40 for pppext@ietf.org; Fri, 14 Oct 2005 09:34:36 -0400 Received: from hec170-187.unil.ch ([130.223.170.187]) by uldns1.unil.ch with esmtp (Exim 4.44) id 1EQPWb-0003kd-Lt; Fri, 14 Oct 2005 15:23:05 +0200 Message-ID: <434FB143.4040507@unil.ch> Date: Fri, 14 Oct 2005 15:23:15 +0200 From: Mohamed Ali SFAXI User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Carlson Subject: Re: [Pppext] Re: your ECP-QKD draft References: <17229.15711.955152.614897@gargle.gargle.HOWL> <434E4D01.5030400@unil.ch> <17230.24177.218809.473754@gargle.gargle.HOWL> In-Reply-To: <17230.24177.218809.473754@gargle.gargle.HOWL> X-Spam-Score: 0.2 (/) X-Scan-Signature: bdfdd9dd835c9bb499f7c92933fef080 X-Mailman-Approved-At: Fri, 14 Oct 2005 09:29:36 -0400 Cc: pppext@ietf.org, sgh@unil.ch X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1848671263==" Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org This is a multi-part message in MIME format. --===============1848671263== Content-Type: multipart/alternative; boundary="------------040301070101070809060707" This is a multi-part message in MIME format. --------------040301070101070809060707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA09354 Dear All, James Carlson wrote: >Mohamed Ali SFAXI writes: > =20 > >>To exchange the quantum key , both nodes must have some special feature= s=20 >>(quantum devices) or simply a quantum modem (these modems like are=20 >>already sold by some companies such as IdQuantique (www.idquantique.com= )=20 >>and MagiQ (http://www.magiqtech.com/)) >> =20 >> > >Yes, understood. > >However, none of the explanation you've offered actually addresses the >questions I've asked. Please examine this feature from your proposed >draft: > > =20 > >> To establish and configure the quantum key distribution between=20 >> the two nodes, it is necessary to exchange some data between=20 >> them. We propose a specific ECP packet format to carry QKD=20 >> parameters (Figure 2): >> >> >> 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 | Key-Length >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | TTL |T| =20 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- >> =20 >> >[...] > =20 > >> Length field: >> The length is number of octets in the packet and it is more than=20 >> ?5? octets (1 octet for the type, 1 octet for the packet length,=20 >> 2 octets for the key length and one octet for the TTL and the T=20 >> field). >> =20 >> > >This appears to describe a new option for ECP that exchanges keys >between the peers, and does the exchange in the clear. > =20 > Yes >Why does it do that? What does it have to do with quantum key >exchange? > =20 > In order to have a valid key, we need some negotiation before. The=20 negotiation is done thanks to ECP. The two peers have to agree on the=20 key length, TTL and perhaps additional option not described in our draft. when these parameters are fixed, a QKD starts. This is done out of the=20 PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to=20 show that the network phase will start after the key is shared. after that, the key is delivered to the network phase to encrypt data >Moreover, the draft does not explain how the key to be used with the >chosen algorithm is actually derived, nor what algorithms are >possible, so there's essentially no hope of interoperability. As IETF >documents have the explicit goal of producing interoperable >implementations, this draft falls short of what's needed. > =20 > We didn't propose any encryption algorithm that could be used because=20 all the encryption algorithms that are already recognized by PPP could=20 be used. In fact, we have introduced only a new way to obtain the=20 encryption key. I think that our draft do not harm the interoperability. Best regards, *Mohamed Ali SFAXI* Assistant Dipl=F4m=E9 Inforge - HEC University of Lausanne tel. + 4121 692 34 22 Website : http://www.hec.unil.ch/sfaxi/ =20 --------------040301070101070809060707 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear All,

James Carlson wrote: 
Mohamed Ali SFAXI writes:
  
To exchange the quantum key , both nodes must have some special features 
(quantum devices) or simply a quantum modem (these modems like are 
already sold by some companies such as IdQuantique (www.idquantique.com) 
and MagiQ (http://www.magiqtech.com/))
    

Yes, understood.

However, none of the explanation you've offered actually addresses the
questions I've asked.  Please examine this feature from your proposed
draft:

  
    To establish and configure the quantum key distribution between 
    the two nodes, it is necessary to exchange some data between 
    them. We propose a specific ECP packet format to carry QKD 
    parameters (Figure 2):


    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     |  Key-Length
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     TTL     |T|    
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
    
[...]
  
    Length field:
    The length is number of octets in the packet and it is more than 
    �5� octets (1 octet for the type, 1 octet for the packet length, 
    2 octets for the key length and one octet for the TTL and the T 
    field).
    

This appears to describe a new option for ECP that exchanges keys
between the peers, and does the exchange in the clear.
Yes 
Why does it do that?  What does it have to do with quantum key
exchange?
In order to have a valid key, we need some negotiation before. The negotiation is done thanks to ECP. The two peers have to agree on the key length, TTL and perhaps additional option not described in our draft.
when these parameters are fixed, a QKD starts. This is done out of the PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to show that the network phase will start after the key is shared.
after that, the key is delivered to the network phase to encrypt data

Moreover, the draft does not explain how the key to be used with the
chosen algorithm is actually derived, nor what algorithms are
possible, so there's essentially no hope of interoperability.  As IETF
documents have the explicit goal of producing interoperable
implementations, this draft falls short of what's needed.
We didn't propose any encryption algorithm that could be used because all the encryption algorithms that are already recognized by PPP could be used. In fact, we have  introduced only a new way to obtain the encryption key. I think that our draft do not harm the interoperability.


Best regards,


Mohamed Ali SFAXI

Mohamed Ali SFAXI
Assistant Diplômé
Inforge - HEC
University of Lausanne
tel. + 4121 692 34 22

Website : http://www.hec.unil.ch/sfaxi/

 


--------------040301070101070809060707-- --===============1848671263== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Pppext mailing list Pppext@ietf.org https://www1.ietf.org/mailman/listinfo/pppext --===============1848671263==-- From pppext-bounces@ietf.org Fri Oct 14 09:36:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPjr-00034T-H0; Fri, 14 Oct 2005 09:36:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQPjp-00034I-E4 for pppext@megatron.ietf.org; Fri, 14 Oct 2005 09:36:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10135 for ; Fri, 14 Oct 2005 09:36:39 -0400 (EDT) Received: from uldns1.unil.ch ([130.223.8.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQPuX-0003Wi-Gc for pppext@ietf.org; Fri, 14 Oct 2005 09:47:50 -0400 Received: from hec170-187.unil.ch ([130.223.170.187]) by uldns1.unil.ch with esmtp (Exim 4.44) id 1EQPjc-0005Lh-F7; Fri, 14 Oct 2005 15:36:32 +0200 Message-ID: <434FB46A.2040706@unil.ch> Date: Fri, 14 Oct 2005 15:36:42 +0200 From: Mohamed Ali SFAXI User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Vernon Schryver Subject: Re: [Pppext] Re: your ECP-QKD draft References: <200510131422.j9DEMbK2027493@calcite.rhyolite.com> In-Reply-To: <200510131422.j9DEMbK2027493@calcite.rhyolite.com> X-Spam-Score: 0.8 (/) X-Scan-Signature: 578029c71870398e30dc7af6a1ae528d Cc: pppext@ietf.org, sgh@unil.ch X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0070891729==" Sender: pppext-bounces@ietf.org Errors-To: pppext-bounces@ietf.org This is a multi-part message in MIME format. --===============0070891729== Content-Type: multipart/alternative; boundary="------------060702000902090303080709" This is a multi-part message in MIME format. --------------060702000902090303080709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id JAA10135 Dear All, Vernon Schryver wrote: >>From: Mohamed Ali SFAXI >>To: James Carlson >>Cc: pppext@ietf.org, sgh@unil.ch >> =20 >> > > =20 > >>Thank you for your comments here is our answer : >> =20 >> > >Your answer is not responsive. > >Perhaps the best way to answer the objections to the I-D and the >proposed IANA registry would be for you to build a complete prototype >implementation of the idea or at least a design complete in all >aspects. Given your claim that quantum cryptography is a settled >technology (never mind http://www.idquantique.com/news/files/june-05.pdf= ), >it should be easy to make a complete design including writing software. >You could base such an effort on one of the open-source implementations >of PPP with encryption and add whatever is needed to work with your >quantum encryption hardware. You would not need to buy quantum >cryptography hardware but could write code to specifictions obtained >from id Quantique or MagiQ. > > > =20 > We are already in contact with Idquantique and maybe we will propose=20 something togother. > =20 > >>To exchange the quantum key , both nodes must have some special feature= s=3D20 >>(quantum devices) or simply a quantum modem (these modems like are=3D20 >>already sold by some companies such as IdQuantique (www.idquantique.com= )=3D20 >>and MagiQ (http://www.magiqtech.com/)) >> =20 >> > >As far as PPP is concerned, exactly the same is true of any use of=20 >PPP encryption. In general one does not change PPP when one uses >new kinds of modems. > > > =20 > You are right. However, the question was how to exchange the key so I=20 answered to that question. >>Here are some requirements to perform a quantum key distribution: >> >>a- An optical channel: the optical channel is the physical link between= =3D20 >>two adjacent nodes. Nowadays, there are two means able to carry a=3D20 >>quantum cryptography transmission: the optical fibber or the free space= =3D20 >>(the air) [6]. As the quantum cryptography uses photons to encode the=3D= 20 >>information no other channel could be used up to now. However, as the=3D= 20 >>quantum physics are experimenting the use of atoms and electrons as a=3D= 20 >>quantum particle [7, 5] maybe other kind of channel could be used in th= e=3D20 >>future. >> =20 >> > >That fact does not affect PPP, and does not answer the questions >that have been raised about your I-D. > > =20 > Same thing >>b- A Q3P modem: this modem has to polarize, send and detect photons; it= =3D20 >>has to include a photon detector and a laser with a single photon=3D20 >>emitter and photon polariser. The source and the detector are widely=3D= 20 >>commercialised and many techniques are employed1. However, these device= s=3D20 >>are used to exchange the quantum key but could also used to send and=3D= 20 >>receive simple data depending on how encoding the information. The mode= m=3D20 >>in this case is a simple optical fiber modem. >> =20 >> > >That also does not affect PPP, and does not answer the questions raised >about your I-D. > > =20 > Same thing >>c- QKD protocol: in order to establish an unconditional secure key, a=3D= 20 >>quantum key distribution protocol is needed. This protocol must be=3D20 >>implemented in the Q3P modem. The protocol will deliver a secure key=3D= 20 >>after distilling the key and error correction [3]. The key is stored in= =3D20 >>a flash buffer memory and used when enciphering the data. The QKD=3D20 >>protocols BB84 and B92 [1, 2] are nowadays the quantum cryptographic=3D= 20 >>protocols widely used. These protocols are securely proven and largely=3D= 20 >>experimented [4]. >> =20 >> > >That also has nothing to do with PPP. Never mind that I disagree with >the claim that anything about quantum cryptography is settled technology. >Except that the encryption key is negoiated with quantum cryptography, >that description fits existing PPP encryption implementations. > >In fact, your description fits existing PPP implementations better >than a system involving quantum cryptography, because I doubt that one >would want to store keys negotiated with quantum cryptogrpah in a flash >buffer memory. > > > =20 > >>Why: >> >>All encryption algorithms used in PPP assume that there is an already=3D= 20 >>shared secret between the two nodes as cited in [RFC2419]: "The means b= y=3D20 >>which the secret becomes known to both communicating elements is beyond= =3D20 >>the scope of this document; usually some form of manual configuration i= s=3D20 >>involved". We don't know how this key is generated, shared nor installe= d=3D20 >>in the PPP devices. >> >>Using the Q3P (and especially the QKD), we solve all the secure key=3D2= 0 >>exchange problems. In fact, we could exchange an unconditional secure=3D= 20 >>key, on-demand and dynamically. >> =20 >> > >Yes, but that has nothing to do with PPP itself. > >well, I'm not quite right. Anyone who understands PPP sees an opportuni= ty >to write a real I-D saying when to use quantum cryptography to negoiate >a new key PPP encryption key based on certain PPP state changes. That >would not involve a change to PPP beyond a pause for obtaining new >random numbers (keys) and negotiating exchanging them over the (presumab= ly >relatively slow) quantum cryptography channel before continuing PPP >as usual. > > > =20 > >>What might be done by this key : >> >>- can be used for instance in DESE [RFC2420] as the "initial nonce". >> >>- Can also be used in other encryption algorithms such as "One Time Pad= "=3D20 >>function which need a new key for each message >> =20 >> > >The only positive way I understand that statement is as proposing to >use quantum cryptography not exchange keys before IPCP starts but to >carry all PPP bits. As such it still has nothing to do with PPP, >because you are proposing a new channel above which would be PPP.=20 >In other words, do MagiQ (http://www.magiqtech.com/) and id Quantique >(http://www.idquantique.com/) agree with your claim that PPP must be >changed to use their modems? > >PPP often does not change to use new kinds of conventional modems. > > >Vernon Schryver vjs@rhyolite.com > =20 > Our idea was to create some kind of ECP negotiation to fix the key=20 exchange parameters and then start the QKD to share a secret key, So it=20 is normal that the existing PPP implementations fits well. The only=20 difference is that to start the network phase using an encryption=20 algorithm we can choose to use the QKD to share a secret key or to=20 assume that the key is already shared (i..e what is done now in PPP). Best regards, *Mohamed Ali SFAXI* Assistant Dipl=F4m=E9 Inforge - HEC University of Lausanne tel. + 4121 692 34 22 Website : http://www.hec.unil.ch/sfaxi/ =20 --------------060702000902090303080709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear All,


Vernon Schryver wrote: 
From: Mohamed Ali SFAXI <MohamedAli.Sfaxi@unil.ch>
To: James Carlson <james.d.carlson@sun.com>
Cc: pppext@ietf.org, sgh@unil.ch
    

  
Thank you for your comments here is our answer :
    

Your answer is not responsive.

Perhaps the best way to answer the objections to the I-D and the
proposed IANA registry would be for you to build a complete prototype
implementation of the idea or at least a design complete in all
aspects.  Given your claim that quantum cryptography is a settled
technology (never mind http://www.idquantique.com/news/files/june-05.pdf ),
it should be easy to make a complete design including writing software.
You could base such an effort on one of the open-source implementations
of PPP with encryption and add whatever is needed to work with your
quantum encryption hardware.  You would not need to buy quantum
cryptography hardware but could write code to specifictions obtained
from id Quantique or MagiQ.

We are already in contact with Idquantique and maybe we will propose something togother.
  
To exchange the quantum key , both nodes must have some special features=20
(quantum devices) or simply a quantum modem (these modems like are=20
already sold by some companies such as IdQuantique (www.idquantique.com)=20
and MagiQ (http://www.magiqtech.com/))
    

As far as PPP is concerned, exactly the same is true of any use of 
PPP encryption.  In general one does not change PPP when one uses
new kinds of modems.

You are right. However, the question was how to exchange the key so I answered to that question.


  

    
Here are some requirements to perform a quantum key distribution:

a- An optical channel: the optical channel is the physical link between=20
two adjacent nodes. Nowadays, there are two means able to carry a=20
quantum cryptography transmission: the optical fibber or the free space=20
(the air) [6]. As the quantum cryptography uses photons to encode the=20
information no other channel could be used up to now. However, as the=20
quantum physics are experimenting the use of atoms and electrons as a=20
quantum particle [7, 5] maybe other kind of channel could be used in the=20
future.
    

  

  

That fact does not affect PPP, and does not answer the questions
that have been raised about your I-D.

  





Same thing



  

  

    
b- A Q3P modem: this modem has to polarize, send and detect photons; it=20
has to include a photon detector and a laser with a single photon=20
emitter and photon polariser. The source and the detector are widely=20
commercialised and many techniques are employed1. However, these devices=20
are used to exchange the quantum key but could also used to send and=20
receive simple data depending on how encoding the information. The modem=20
in this case is a simple optical fiber modem.
    

  

  

That also does not affect PPP, and does not answer the questions raised
about your I-D.

  





Same thing





  

  

    
c- QKD protocol: in order to establish an unconditional secure key, a=20
quantum key distribution protocol is needed. This protocol must be=20
implemented in the Q3P modem. The protocol will deliver a secure key=20
after distilling the key and error correction [3]. The key is stored in=20
a flash buffer memory and used when enciphering the data. The QKD=20
protocols BB84 and B92 [1, 2] are nowadays the quantum cryptographic=20
protocols widely used. These protocols are securely proven and largely=20
experimented [4].
    

  

  

That also has nothing to do with PPP.  Never mind that I disagree with
the claim that anything about quantum cryptography is settled technology.
Except that the encryption key is negoiated with quantum cryptography,
that description fits existing PPP encryption implementations.

In fact, your description fits existing PPP implementations better
than a system involving quantum cryptography, because I doubt that one
would want to store keys negotiated with quantum cryptogrpah in a flash
buffer memory.


  







  

  

    
Why:

All encryption algorithms used in PPP assume that there is an already=20
shared secret between the two nodes as cited in [RFC2419]: "The means by=20
which the secret becomes known to both communicating elements is beyond=20
the scope of this document; usually some form of manual configuration is=20
involved". We don't know how this key is generated, shared nor installed=20
in the PPP devices.

Using the Q3P (and especially the QKD), we solve all the secure key=20
exchange problems. In fact, we could exchange an unconditional secure=20
key, on-demand and dynamically.
    

  

  

Yes, but that has nothing to do with PPP itself.

well, I'm not quite right.  Anyone who understands PPP sees an opportunity
to write a real I-D saying when to use quantum cryptography to negoiate
a new key PPP encryption key based on certain PPP state changes.  That
would not involve a change to PPP beyond a pause for obtaining new
random numbers (keys) and negotiating exchanging them over the (presumably
relatively slow) quantum cryptography channel before continuing PPP
as usual.


  

  

    
What might be done by this key :

- can be used for instance in DESE  [RFC2420] as the "initial nonce".

- Can also be used in other encryption algorithms such as "One Time Pad"=20
function which need a new key for each message
    

  

  

The only positive way I understand that statement is as proposing to
use quantum cryptography not exchange keys before IPCP starts but to
carry all PPP bits.  As such it still has nothing to do with PPP,
because you are proposing a new channel above which would be PPP. 
In other words, do MagiQ (http://www.magiqtech.com/) and id Quantique
(http://www.idquantique.com/) agree with your claim that PPP must be
changed to use their modems?

PPP often does not change to use new kinds of conventional modems.


Vernon Schryver    vjs@rhyolite.com
  





Our idea was to create some kind of ECP negotiation to fix the key
exchange parameters and then start the QKD to share a secret key, So it
is normal that the existing PPP implementations fits well. The only
difference is that to start the network phase using an encryption
algorithm we can choose to use the QKD to share a secret key or to
assume that the key is already shared (i..e what is done now in PPP).





Best regards,












Mohamed Ali SFAXI








Mohamed Ali SFAXI 

Assistant Diplômé 

Inforge - HEC 

University of Lausanne 

tel. + 4121 692 34 22



Website : http://www.hec.unil.ch/sfaxi/


 










--------------060702000902090303080709--


--===============0070891729==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext

--===============0070891729==--




From pppext-bounces@ietf.org Fri Oct 14 09:55:09 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQQ1d-00089c-BV; Fri, 14 Oct 2005 09:55:09 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQ1b-00088s-Gr
	for pppext@megatron.ietf.org; Fri, 14 Oct 2005 09:55:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11415
	for ; Fri, 14 Oct 2005 09:55:01 -0400 (EDT)
Received: from brmea-mail-4.sun.com ([192.18.98.36])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQCJ-00047t-HX
	for pppext@ietf.org; Fri, 14 Oct 2005 10:06:13 -0400
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j9EDt3vD015253
	for ; Fri, 14 Oct 2005 07:55:03 -0600 (MDT)
Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,
	v2.2) with ESMTP id j9EDt30t008274
	for ; Fri, 14 Oct 2005 09:55:03 -0400 (EDT)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1])
	by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id
	j9EDt26R000211; Fri, 14 Oct 2005 09:55:03 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j9EDt28p000206;
	Fri, 14 Oct 2005 09:55:02 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17231.47281.531782.709083@gargle.gargle.HOWL>
Date: Fri, 14 Oct 2005 09:54:57 -0400
From: James Carlson 
To: Mohamed Ali SFAXI 
Subject: Re: [Pppext] Re: your ECP-QKD draft
In-Reply-To: Mohamed Ali SFAXI's message of 14 October 2005 15:23:15
References: <17229.15711.955152.614897@gargle.gargle.HOWL>
	<434E4D01.5030400@unil.ch>
	<17230.24177.218809.473754@gargle.gargle.HOWL>
	<434FB143.4040507@unil.ch>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Content-Transfer-Encoding: 7bit
Cc: pppext@ietf.org, sgh@unil.ch
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

Mohamed Ali SFAXI writes:
> In order to have a valid key, we need some negotiation before. The 
> negotiation is done thanks to ECP. The two peers have to agree on the 
> key length,

The key length and how the key bits are manipulated is intimately tied
with the encryption algorithm chosen.  This is why I keep asking about
that problem.

For example, if you use 3DES (RFC 2420), you need three 56-bit
subkeys, each of which is normally stored in an 8-octet block, with
the 8 LSBs ignored (used as parity).  So, one plausible transform
would be to take exactly 24 octets from the quantum stream, and use
them directly as the three keys (k1, k2, and k3).  To do this, you
need to wipe out the LSBs (for use as parity) and reject any weak key
proposed by your peer.

But that's only *ONE* plausible transform among many, and it seems to
assume that the quantum stream itself is error-free.  If each
implementation chooses to do this a different way, you'll end up with
chaos.  It won't be interoperable.

Furthermore, once you've chosen the algorithm, at least in this case,
you no longer have the option of negotiating the key length.  The
algorithm dictates it.

In addition to that, the TTL appears to be unnecessary.  The simplest
way to deal with key expiry is to renegotiate ECP itself.  Why isn't
that the chosen method?

Or, if you can change the key on the fly without restarting ECP, then
why not just do it?  Why must the peers agree on this parameter at
all?

If it's a useful feature, wouldn't a key TTL be something that's
generally helpful for ECP, rather than a specific issue with quantum
key exchange?

> TTL and perhaps additional option not described in our draft.

Please explain the "additional option," or at least the intended
behavior.  How do we get interoperability if we have features that
aren't documented?

> when these parameters are fixed, a QKD starts. This is done out of the 
> PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to 
> show that the network phase will start after the key is shared.
> after that, the key is delivered to the network phase to encrypt data

I don't see how this requires any special negotiation.

Obviously, you must have prior arrangement to use these "Q3P modems"
on the two consenting peers.  Why is that by itself not sufficient to
indicate that this new key source is desired?  Why must the peers also
negotiate something that they already know to be true?

> We didn't propose any encryption algorithm that could be used because 
> all the encryption algorithms that are already recognized by PPP could 
> be used. In fact, we have  introduced only a new way to obtain the 
> encryption key. I think that our draft do not harm the interoperability.

See above.  That choice is an interoperability problem.

-- 
James Carlson, KISS Network                    
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext



From pppext-bounces@ietf.org Fri Oct 14 10:18:47 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQQOV-0007J5-8I; Fri, 14 Oct 2005 10:18:47 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EQQOT-0007Iq-KF
	for pppext@megatron.ietf.org; Fri, 14 Oct 2005 10:18:45 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13040
	for ; Fri, 14 Oct 2005 10:18:37 -0400 (EDT)
Received: from [67.103.19.118] (helo=lithik.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQQZ9-0004nh-3P
	for pppext@ietf.org; Fri, 14 Oct 2005 10:29:49 -0400
Received: from [192.168.2.1] (account karl HELO [172.30.1.172])
	by lithik.com (CommuniGate Pro SMTP 4.3.6)
	with ESMTPSA id 1097802; Fri, 14 Oct 2005 10:18:29 -0400
In-Reply-To: <17231.45667.259701.76664@gargle.gargle.HOWL>
References: 
	<17231.45667.259701.76664@gargle.gargle.HOWL>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: 
Content-Transfer-Encoding: 7bit
From: Karl Fox 
Subject: Re: [Pppext] ACFC
Date: Fri, 14 Oct 2005 10:18:57 -0400
To: Vishwas Manral 
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: de4f315c9369b71d7dd5909b42224370
Content-Transfer-Encoding: 7bit
Cc: pppext@ietf.org
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

Just make sure you don't reorder packets, or things will break.

Karl

On Oct 14, 2005, at 9:28 AM, James Carlson wrote:
> Vishwas Manral writes:
>> You rightly guessed it. It is the "common" case, I was enquiring  
>> about.
>>
>> I was wondering if cases where we had uncompressed fields even  
>> when ACFC
>> and PFC were configured, we may not necessarily handle it in the fast
>> path and yet handle it in the slow path.
>
> The standards say nothing about "fast" or "slow" -- those are
> implementation and customer acceptance issues.  They say only that it
> must work.

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext



From pppext-bounces@ietf.org Fri Oct 14 11:09:28 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQRBX-0002p8-Vo; Fri, 14 Oct 2005 11:09:27 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRBV-0002oi-KJ
	for pppext@megatron.ietf.org; Fri, 14 Oct 2005 11:09:25 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20185
	for ; Fri, 14 Oct 2005 11:09:21 -0400 (EDT)
Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQRME-0007nh-JV
	for pppext@ietf.org; Fri, 14 Oct 2005 11:20:31 -0400
Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 16:09:08 +0100
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 14 Oct 2005 16:09:08 +0100
Received: from juniper.net ([172.28.11.146] RDNS failed) by pi-smtp.jnpr.net
	with Microsoft SMTPSVC(5.0.2195.6713); 
	Fri, 14 Oct 2005 11:09:07 -0400
Message-ID: <434FCA16.9070402@juniper.net>
Date: Fri, 14 Oct 2005 11:09:10 -0400
From: "Paul W. Howard" 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vishwas Manral 
Subject: Re: [Pppext] ACFC
References: 
	<17231.45667.259701.76664@gargle.gargle.HOWL>
In-Reply-To: <17231.45667.259701.76664@gargle.gargle.HOWL>
X-OriginalArrivalTime: 14 Oct 2005 15:09:07.0365 (UTC)
	FILETIME=[390A5D50:01C5D0D1]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43
Cc: pppext@ietf.org
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0597105815=="
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0597105815==
Content-Type: multipart/alternative;
	boundary="------------030308010800080007050705"

This is a multi-part message in MIME format.
--------------030308010800080007050705
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Vishwas,

I think you will find that other implementations agree to ACFC and PFC 
primarily to increase their ability to connect with the plethora of PPP 
clients out there but have no intention of actually taking advantage of 
the permission.   As noted eariler Ack'ing these options is merely 
acknowledging that you have permission to do the compression, not that 
you are required to do the compression.   With today's higher speed 
links, there's very little value in doing this compression so it's 
fairly common to find it being acked and then not used.   You would 
probably regret treating the uncompressed as "slow" path frames in this 
situation.

Paul Howard

James Carlson wrote:

>Vishwas Manral writes:
>  
>
>>You rightly guessed it. It is the "common" case, I was enquiring about.
>>
>>I was wondering if cases where we had uncompressed fields even when ACFC
>>and PFC were configured, we may not necessarily handle it in the fast
>>path and yet handle it in the slow path.
>>    
>>
>
>The standards say nothing about "fast" or "slow" -- those are
>implementation and customer acceptance issues.  They say only that it
>must work.
>
>  
>

--------------030308010800080007050705
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Vishwas,



I think you will find that other implementations agree to ACFC and PFC
primarily to increase their ability to connect with the plethora of PPP
clients out there but have no intention of actually taking advantage of
the permission.   As noted eariler Ack'ing these options is merely
acknowledging that you have permission to do the compression, not that
you are required to do the compression.   With today's higher speed
links, there's very little value in doing this compression so it's
fairly common to find it being acked and then not used.   You would
probably regret treating the uncompressed as "slow" path frames in this
situation.



Paul Howard



James Carlson wrote:



  
Vishwas Manral writes:
  

  

    
You rightly guessed it. It is the "common" case, I was enquiring about.

I was wondering if cases where we had uncompressed fields even when ACFC
and PFC were configured, we may not necessarily handle it in the fast
path and yet handle it in the slow path.
    

  

  

The standards say nothing about "fast" or "slow" -- those are
implementation and customer acceptance issues.  They say only that it
must work.

  






--------------030308010800080007050705--



--===============0597105815==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext

--===============0597105815==--





From pppext-bounces@ietf.org Fri Oct 14 11:22:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQRNu-0007UV-Sh; Fri, 14 Oct 2005 11:22:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EQRNr-0007Sa-H3
	for pppext@megatron.ietf.org; Fri, 14 Oct 2005 11:22:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23470
	for ; Fri, 14 Oct 2005 11:22:07 -0400 (EDT)
Received: from calcite.rhyolite.com ([192.188.61.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQRYZ-0000ed-7O
	for pppext@ietf.org; Fri, 14 Oct 2005 11:33:17 -0400
Received: from calcite.rhyolite.com (localhost [127.0.0.1])
	by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j9EFLqjB058365
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	env-from ; 
	Fri, 14 Oct 2005 09:21:52 -0600 (MDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j9EFLqit058364;
	Fri, 14 Oct 2005 09:21:52 -0600 (MDT)
Date: Fri, 14 Oct 2005 09:21:52 -0600 (MDT)
From: Vernon Schryver 
Message-Id: <200510141521.j9EFLqit058364@calcite.rhyolite.com>
To: MohamedAli.Sfaxi@unil.ch, pppext@ietf.org, sgh@unil.ch
Subject: Re: [Pppext] Re: your ECP-QKD draft
In-Reply-To: <434FB143.4040507@unil.ch>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c
Cc: 
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

> From: Mohamed Ali SFAXI 


> In order to have a valid key, we need some negotiation before. The=20
> negotiation is done thanks to ECP. The two peers have to agree on the=20
> key length, TTL and perhaps additional option not described in our draft.

Your words "perhaps additional option not described in our draft" would
demand that your draft be rejected by the IESG until it is complete.

Have you read the RFCs on how to publish an I-D?


> when these parameters are fixed, a QKD starts. This is done out of the=20
> PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to=20
> show that the network phase will start after the key is shared.
> after that, the key is delivered to the network phase to encrypt data

Again, that seems to have nothing to do with QKD in particular.


> >Moreover, the draft does not explain how the key to be used with the
> >chosen algorithm is actually derived, nor what algorithms are
> >possible, so there's essentially no hope of interoperability.  As IETF
> >documents have the explicit goal of producing interoperable
> >implementations, this draft falls short of what's needed.
> >
> We didn't propose any encryption algorithm that could be used because=20
> all the encryption algorithms that are already recognized by PPP could=20
> be used. In fact, we have  introduced only a new way to obtain the=20
> encryption key. I think that our draft do not harm the interoperability.

Until and unless your draft does something to help interoperability,
the IESG should to reject it.  Guessing that some as yet unknown ECP
negotiations might be needed for QKP does not justify an RFC or
an IANA type assignment.



] From: Mohamed Ali SFAXI 


] We are already in contact with Idquantique and maybe we will propose 
] something togother.

It would be wise to withdraw now and return later when you have something
of substance to propose.


]>>Here are some requirements to perform a quantum key distribution:

] >As far as PPP is concerned, exactly the same is true of any use of=20
] >PPP encryption.  In general one does not change PPP when one uses
] >new kinds of modems.
]
] You are right. However, the question was how to exchange the key so I=20
] answered to that question.

I do not recall that anyone asked how quantum cryptography works
or how it might be used in a vague, hand waving theory to exchange
keys.  Perhaps you did not realize that people interested in moving
encrypted or otherwise secure data over long distances might already
be as aware of QKD as you seem to be.

More important, your document fails to specify how to exchange keys
using quantum crypography.  I suspect that there is more than one way,
and that some sort of negotiating might be useful.  That negotiating,
if needed, sounds like an appropriate subject of an RFC.  However,
your draft of an I-D does not in any way address such issues.


] >>Here are some requirements to perform a quantum key distribution:

] >That fact does not affect PPP, and does not answer the questions
] >that have been raised about your I-D.
]
] Same thing

Telling us things we already know about QKD does not answer questions
about you draft of an I-D.


] >>b- A Q3P modem: this modem has to polarize, send and detect photons; it=

] >That also does not affect PPP, and does not answer the questions raised
] >about your I-D.

] Same thing

Why do you assume we know nothing of quantum cryptography?


] >PPP often does not change to use new kinds of conventional modems.

] Our idea was to create some kind of ECP negotiation to fix the key=20
] exchange parameters 

According to your own words about possible additional options, your
draft of an I-D fails to do that.

]                                                                 So it=20
] is normal that the existing PPP implementations fits well. The only=20
] difference is that to start the network phase using an encryption=20
] algorithm we can choose to use the QKD to share a secret key or to=20
] assume that the key is already shared (i..e what is done now in PPP).

You do not need a special negotiation for QKD PPP to do that.  When
you install the quantum cryptography modems, you must configure them
and rest of your PPP machinery to use them.  Part of that installation
procedure can involve setting the parameters that are pecular to QKD.
Parameters that are common to other ECP schemes do not need a QKD RFC.
It might be that QKD will need some PPP negotiations, but they cannot
be standardized before they are specified.

You persist in not answering the question of how QKD differs from
plain old telephones for key distribution as far as PPP and ECP are
concerned.


This is all supposed to be about assigning an ECP type number to BB84.
I've been told by people actually working on quantum cryptography and
quantum computing that BB84 is an extremely unlikely choice.  Actually,
the words they used about this whole proposal were a lot stronger.

This should be rejected until something is actually proposed (i.e.
without any TBD holes for possible additional parameters) and with
support from people actually working with QKD.  It would be wrong to
tie the hands of people working on QKD by advancing something that is
only a place keeper.


Vernon Schryver    vjs@rhyolite.com

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext



From pppext-bounces@ietf.org Fri Oct 14 13:09:59 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQT4B-0002vU-CE; Fri, 14 Oct 2005 13:09:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EQT47-0002tr-CZ
	for pppext@megatron.ietf.org; Fri, 14 Oct 2005 13:09:55 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00891
	for ; Fri, 14 Oct 2005 13:09:48 -0400 (EDT)
Received: from brmea-mail-3.sun.com ([192.18.98.34])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQTEn-00048t-QB
	for pppext@ietf.org; Fri, 14 Oct 2005 13:21:00 -0400
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j9EH9n1L005010
	for ; Fri, 14 Oct 2005 11:09:49 -0600 (MDT)
Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,
	v2.2) with ESMTP id j9EH9m0t002623
	for ; Fri, 14 Oct 2005 13:09:48 -0400 (EDT)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1])
	by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id
	j9EH9mLq016020; Fri, 14 Oct 2005 13:09:48 -0400 (EDT)
Received: (from carlsonj@localhost)
	by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j9EH9msU016017;
	Fri, 14 Oct 2005 13:09:48 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17231.58972.724576.499929@gargle.gargle.HOWL>
Date: Fri, 14 Oct 2005 13:09:48 -0400
From: James Carlson 
To: Bill Manning 
Subject: Re: [Pppext] Re: your ECP-QKD draft
In-Reply-To: Bill Manning's message of 14 October 2005 09:54:01
References: <17229.15711.955152.614897@gargle.gargle.HOWL>
	<434E4D01.5030400@unil.ch>
	<17230.24177.218809.473754@gargle.gargle.HOWL>
	<434FB143.4040507@unil.ch>
	<038deb4f55e198651866a6da54fecfec@karoshi.com>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Cc: pppext@ietf.org, Mohamed Ali SFAXI , sgh@unil.ch,
	Rod Van Meter 
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

Bill Manning writes:
> a couple of things here:
> 
> 
> the I-D is in the DB at
> https://datatracker.ietf.org/public/idindex.cgi? 
> command=view_related_docs&id=13770
>   but clicking on the "view document" link gets nothing!

The only extant version of the document that I know of is the one that
IANA forwarded to the pppext list.

We asked specifically for a draft to review.  I don't know why the
submitter wasn't told to go through the normal I-D submission process,
but I'm guessing that either they didn't do it, or the publishing
process somehow failed.

In any event, we got the text we were asking about, so I'm less
concerned about the publication process.  We can revisit that issue
later _if_ anything substantive comes out of the discussion.

(Since I don't expect there to be any positive consensus on this
document, I'm a bit reluctant to raise their expectations by telling
the authors to jump through the I-D hoop first.  It's not as though
I-D publication is 'trivial' anymore.  :-<)

-- 
James Carlson, KISS Network                    
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext



From pppext-bounces@ietf.org Mon Oct 17 07:41:14 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERTMg-00077h-PE; Mon, 17 Oct 2005 07:41:14 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERTMd-00076U-VH
	for pppext@megatron.ietf.org; Mon, 17 Oct 2005 07:41:13 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05832
	for ; Mon, 17 Oct 2005 07:41:03 -0400 (EDT)
Received: from uldns1.unil.ch ([130.223.8.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERTXw-0002f2-Fx
	for pppext@ietf.org; Mon, 17 Oct 2005 07:52:54 -0400
Received: from hec170-187.unil.ch ([130.223.170.187])
	by uldns1.unil.ch with esmtp (Exim 4.44)
	id 1ERTMA-0000o6-Qp; Mon, 17 Oct 2005 13:40:42 +0200
Message-ID: <43538DBA.4080409@unil.ch>
Date: Mon, 17 Oct 2005 13:40:42 +0200
From: Mohamed Ali SFAXI 
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: James Carlson 
Subject: Re: [Pppext] Re: your ECP-QKD draft
References: <17229.15711.955152.614897@gargle.gargle.HOWL>	<434E4D01.5030400@unil.ch>	<17230.24177.218809.473754@gargle.gargle.HOWL>	<434FB143.4040507@unil.ch>	<038deb4f55e198651866a6da54fecfec@karoshi.com>
	<17231.58972.724576.499929@gargle.gargle.HOWL>
In-Reply-To: <17231.58972.724576.499929@gargle.gargle.HOWL>
X-Spam-Score: 1.0 (+)
X-Scan-Signature: 88f26d2f221431f6ca738c2250d28ac3
Cc: pppext@ietf.org, sgh@unil.ch, Bill Manning ,
	Rod Van Meter 
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============1860630742=="
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

This is a multi-part message in MIME format.
--===============1860630742==
Content-Type: multipart/alternative;
	boundary="------------060608020100010705080403"

This is a multi-part message in MIME format.
--------------060608020100010705080403
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id HAA05832

Dear All,

> James Carlson wrote:
>
>Bill Manning writes:
> =20
>
>>a couple of things here:
>>
>>
>>the I-D is in the DB at
>>https://datatracker.ietf.org/public/idindex.cgi?=20
>>command=3Dview_related_docs&id=3D13770
>>  but clicking on the "view document" link gets nothing!
>>   =20
>>
>
>The only extant version of the document that I know of is the one that
>IANA forwarded to the pppext list.
>
>We asked specifically for a draft to review.  I don't know why the
>submitter wasn't told to go through the normal I-D submission process,
>but I'm guessing that either they didn't do it, or the publishing
>process somehow failed.
>
>In any event, we got the text we were asking about, so I'm less
>concerned about the publication process.  We can revisit that issue
>later _if_ anything substantive comes out of the discussion.
>
>(Since I don't expect there to be any positive consensus on this
>document, I'm a bit reluctant to raise their expectations by telling
>the authors to jump through the I-D hoop first.  It's not as though
>I-D publication is 'trivial' anymore.  :-<)
> =20
>

We asked the IANA for a new type number and the IANA told us to publish=20
an I-D first. We have already submit our I-D according to the normal I-D=20
submission process. I don't know why the web link doesn't work !!


>
> Bill Manning wrote: a couple of things here:
>
>
>
> the I-D is in the DB at
> https://datatracker.ietf.org/public/idindex.cgi?command=3Dview_related_=
docs&id=3D13770=20
>
> but clicking on the "view document" link gets nothing!
>
> and one of my quantum computing cohorts makes this comment:
>
> >Mr. Sfaxi either misunderstands or fails to explain one VERY important
> >point: QKD REQUIRES an authenticated classical channel to operate
> >securely. Such a channel involves either PKI or a pre-shared secret.
> >

It is possible to have only one channel for the quantum communication=20
and for the classical communication. It is feasible (confirmed by=20
IdQuantique). IdQuantique and MagiQ use separate modules for quantum=20
communication and classical communication in their devices to improve=20
the QKD performances and because easy to implement that's why they use=20
two different channels (in my opinion).


> >See
> >http://rdvlivefromtokyo.blogspot.com/2005/10/stop-myth-qkd-doesnt-fix-=
what-shor.html=20
>
> >http://dabacon.org/pontiff/?p=3D1086
> >and especially
> >http://arxiv.org/abs/quant-ph/0406147
> >
> >As to id-quantique and MagiQ Technologies, they have been around for a
> >couple of years. I don't know anyone who has actually purchased and
> >used their equipment. If you know anyone who has, please ask them to
> >contact me; I would love to find out about their experiences!
> >
> >Feel free to forward this to the reflector, and include me on any
> >replies or further conversations, but I don't read pppext.
> >
> > --Rod
>



>Mohamed Ali SFAXI writes:
> =20
>
>>> In order to have a valid key, we need some negotiation before. The=20
>>> negotiation is done thanks to ECP. The two peers have to agree on the=
=20
>>> key length,
>>   =20
>>
>
>The key length and how the key bits are manipulated is intimately tied
>with the encryption algorithm chosen.  This is why I keep asking about
>that problem.
>
>For example, if you use 3DES (RFC 2420), you need three 56-bit
>subkeys, each of which is normally stored in an 8-octet block, with
>the 8 LSBs ignored (used as parity).  So, one plausible transform
>would be to take exactly 24 octets from the quantum stream, and use
>them directly as the three keys (k1, k2, and k3).  To do this, you
>need to wipe out the LSBs (for use as parity) and reject any weak key
>proposed by your peer.
>
>But that's only *ONE* plausible transform among many, and it seems to
>assume that the quantum stream itself is error-free.  If each
>implementation chooses to do this a different way, you'll end up with
>chaos.  It won't be interoperable.
>
>Furthermore, once you've chosen the algorithm, at least in this case,
>you no longer have the option of negotiating the key length.  The
>algorithm dictates it.
> =20
>
Negotiating the key length is a feasible way to be independent from the=20
encryption algorithm and to use the QKD for new algorithms and other=20
encryption mechanisms like the one-time-pad function.



>In addition to that, the TTL appears to be unnecessary.  The simplest
>way to deal with key expiry is to renegotiate ECP itself.  Why isn't
>that the chosen method?
>
>Or, if you can change the key on the fly without restarting ECP, then
>why not just do it?  Why must the peers agree on this parameter at
>all?
>
>If it's a useful feature, wouldn't a key TTL be something that's
>generally helpful for ECP, rather than a specific issue with quantum
>key exchange?
> =20
>
We have to use TTL for two reasons :

- security purpose (to have the possibility to refresh encryption key oft=
en)

- as we use the link as the quantum channel and the classical channel=20
the classical communication must stop (when the TTL expires) and the=20
quantum communication starts.

> =20
>
>>> TTL and perhaps additional option not described in our draft.
>>   =20
>>
>
>Please explain the "additional option," or at least the intended
>behavior.  How do we get interoperability if we have features that
>aren't documented?
> =20
>
"additional option" for us is a way to negotiate new QKD parameters.=20
This field is not used now but could be used if required by users and we=20
think that we may need a free field for the future use.



>>> when these parameters are fixed, a QKD starts. This is done out of th=
e=20
>>> PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to=
=20
>>> show that the network phase will start after the key is shared.
>>> after that, the key is delivered to the network phase to encrypt data
>>   =20
>>
>
>I don't see how this requires any special negotiation.
>
>Obviously, you must have prior arrangement to use these "Q3P modems"
>on the two consenting peers.  Why is that by itself not sufficient to
>indicate that this new key source is desired?  Why must the peers also
>negotiate something that they already know to be true?
>
> =20
>
>>> We didn't propose any encryption algorithm that could be used because=
=20
>>> all the encryption algorithms that are already recognized by PPP coul=
d=20
>>> be used. In fact, we have  introduced only a new way to obtain the=20
>>> encryption key. I think that our draft do not harm the interoperabili=
ty.
>>   =20
>>
>
>See above.  That choice is an interoperability problem.
>
> -- James Carlson, KISS Network  Sun=20
> Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS=20
> UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
>


>
>
> Vernon Schryver wrote:
>
>>From: Mohamed Ali SFAXI 
>>   =20
>>
>
>
> =20
>
>>In order to have a valid key, we need some negotiation before. The=3D20
>>negotiation is done thanks to ECP. The two peers have to agree on the=3D=
20
>>key length, TTL and perhaps additional option not described in our draf=
t.
>>   =20
>>
>
>Your words "perhaps additional option not described in our draft" would
>demand that your draft be rejected by the IESG until it is complete.
>
>Have you read the RFCs on how to publish an I-D?
> =20
>

As we said above : "

"additional option" for us is a way to negotiate new QKD parameters.=20
This field is not used now but could be used if required by users and we=20
think that we may need a free field for the future use.

"

>
> =20
>
>>when these parameters are fixed, a QKD starts. This is done out of the=3D=
20
>>PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to=3D=
20
>>show that the network phase will start after the key is shared.
>>after that, the key is delivered to the network phase to encrypt data
>>   =20
>>
>
>Again, that seems to have nothing to do with QKD in particular.
>
>
> =20
>
>>>Moreover, the draft does not explain how the key to be used with the
>>>chosen algorithm is actually derived, nor what algorithms are
>>>possible, so there's essentially no hope of interoperability.  As IETF
>>>documents have the explicit goal of producing interoperable
>>>implementations, this draft falls short of what's needed.
>>>
>>>     =20
>>>
>>We didn't propose any encryption algorithm that could be used because=3D=
20
>>all the encryption algorithms that are already recognized by PPP could=3D=
20
>>be used. In fact, we have  introduced only a new way to obtain the=3D20
>>encryption key. I think that our draft do not harm the interoperability.
>>   =20
>>
>
>Until and unless your draft does something to help interoperability,
>the IESG should to reject it.  Guessing that some as yet unknown ECP
>negotiations might be needed for QKP does not justify an RFC or
>an IANA type assignment.
>
>
>
>] From: Mohamed Ali SFAXI 
>
>
>] We are already in contact with Idquantique and maybe we will propose=20
>] something togother.
>
>It would be wise to withdraw now and return later when you have somethin=
g
>of substance to propose.
>
>
>]>>Here are some requirements to perform a quantum key distribution:
>
>] >As far as PPP is concerned, exactly the same is true of any use of=3D=
20
>] >PPP encryption.  In general one does not change PPP when one uses
>] >new kinds of modems.
>]
>] You are right. However, the question was how to exchange the key so I=3D=
20
>] answered to that question.
>
>I do not recall that anyone asked how quantum cryptography works
>or how it might be used in a vague, hand waving theory to exchange
>keys.  Perhaps you did not realize that people interested in moving
>encrypted or otherwise secure data over long distances might already
>be as aware of QKD as you seem to be.
>
>More important, your document fails to specify how to exchange keys
>using quantum crypography.  I suspect that there is more than one way,
>and that some sort of negotiating might be useful.  That negotiating,
>if needed, sounds like an appropriate subject of an RFC.  However,
>your draft of an I-D does not in any way address such issues.
> =20
>
The QKD negotiation depends mainly on the QKD protocols. We assume that=20
the modems and the software in these modems are the only concerned by=20
the negotiation. I completely agree with you to have a common=20
negotiation way in QKD.

>
>] >>Here are some requirements to perform a quantum key distribution:
>
>] >That fact does not affect PPP, and does not answer the questions
>] >that have been raised about your I-D.
>]
>] Same thing
>
>Telling us things we already know about QKD does not answer questions
>about you draft of an I-D.
>
>
>] >>b- A Q3P modem: this modem has to polarize, send and detect photons;=
 it=3D
>
>] >That also does not affect PPP, and does not answer the questions rais=
ed
>] >about your I-D.
>
>] Same thing
>
>Why do you assume we know nothing of quantum cryptography?
> =20
>
I don't assume that but I presented what we need to use quantum=20
cryptography.

>
>] >PPP often does not change to use new kinds of conventional modems.
>
>] Our idea was to create some kind of ECP negotiation to fix the key=3D2=
0
>] exchange parameters=20
>
>According to your own words about possible additional options, your
>draft of an I-D fails to do that.
> =20
>
please see above

>]                                                                 So it=3D=
20
>] is normal that the existing PPP implementations fits well. The only=3D=
20
>] difference is that to start the network phase using an encryption=3D20
>] algorithm we can choose to use the QKD to share a secret key or to=3D2=
0
>] assume that the key is already shared (i..e what is done now in PPP).
>
>You do not need a special negotiation for QKD PPP to do that.  When
>you install the quantum cryptography modems, you must configure them
>and rest of your PPP machinery to use them.  Part of that installation
>procedure can involve setting the parameters that are pecular to QKD.
>Parameters that are common to other ECP schemes do not need a QKD RFC.
>It might be that QKD will need some PPP negotiations, but they cannot
>be standardized before they are specified.
>
>You persist in not answering the question of how QKD differs from
>plain old telephones for key distribution as far as PPP and ECP are
>concerned.
> =20
>
The QKD is a solution to distribute keys.  We try to have an automatic =20
"on-line" way to share the secret key. We choose the QKD as it is an=20
unconditional secure mechanism to distribute secret. We need the ECP to=20
configure this exchange (not physical configuration but logical=20
configuration).

>
>This is all supposed to be about assigning an ECP type number to BB84.
>I've been told by people actually working on quantum cryptography and
>quantum computing that BB84 is an extremely unlikely choice.  Actually,
>the words they used about this whole proposal were a lot stronger.
>
>This should be rejected until something is actually proposed (i.e.
>without any TBD holes for possible additional parameters) and with
>support from people actually working with QKD.  It would be wrong to
>tie the hands of people working on QKD by advancing something that is
>only a place keeper.
>
> =20
>

We propose the BB84 as it is the initial QKD protocol and the most=20
famous. In addition, BB84 is still used by MagiQ and IdQuantique.

>Vernon Schryver    vjs@rhyolite.com
>
> =20
>


*Mohamed Ali SFAXI*
Assistant Dipl=F4m=E9
Inforge - HEC
University of Lausanne
tel. + 4121 692 34 22

Website : http://www.hec.unil.ch/sfaxi/

=20


> =20
>

--------------060608020100010705080403
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit




  
  


Dear All,




James Carlson wrote:
  
Bill Manning writes:
  

  

    
a couple of things here:


the I-D is in the DB at
https://datatracker.ietf.org/public/idindex.cgi? 
command=view_related_docs&id=13770
  but clicking on the "view document" link gets nothing!
    

  

  

The only extant version of the document that I know of is the one that
IANA forwarded to the pppext list.

We asked specifically for a draft to review.  I don't know why the
submitter wasn't told to go through the normal I-D submission process,
but I'm guessing that either they didn't do it, or the publishing
process somehow failed.

In any event, we got the text we were asking about, so I'm less
concerned about the publication process.  We can revisit that issue
later _if_ anything substantive comes out of the discussion.

(Since I don't expect there to be any positive consensus on this
document, I'm a bit reluctant to raise their expectations by telling
the authors to jump through the I-D hoop first.  It's not as though
I-D publication is 'trivial' anymore.  :-<)
  





We asked the IANA for a new type number and the IANA told us to publish
an I-D first. We have already submit our I-D according to the normal
I-D submission process. I don't know why the web link doesn't work !!








Bill Manning wrote:
a couple of things here: 

  

  

  

the I-D is in the DB at 

https://datatracker.ietf.org/public/idindex.cgi?command=view_related_docs&id=13770
  

but clicking on the "view document" link gets nothing! 

  

and one of my quantum computing cohorts makes this comment: 

  

>Mr. Sfaxi either misunderstands or fails to explain one VERY
important 

>point: QKD REQUIRES an authenticated classical channel to operate 

>securely. Such a channel involves either PKI or a pre-shared
secret. 

> 




It is possible to have only one
channel for
the quantum communication and for the classical communication. It is
feasible (confirmed
by IdQuantique). IdQuantique and MagiQ use separate modules for quantum
communication and classical communication in their devices to improve
the
QKD performances and because easy to implement that's why they use two
different channels (in my opinion). 





>See 

>http://rdvlivefromtokyo.blogspot.com/2005/10/stop-myth-qkd-doesnt-fix-what-shor.html
  

>http://dabacon.org/pontiff/?p=1086 

>and especially 

>http://arxiv.org/abs/quant-ph/0406147 

> 

>As to id-quantique and MagiQ Technologies, they have been around
for a 

>couple of years. I don't know anyone who has actually purchased and
  

>used their equipment. If you know anyone who has, please ask them
to 

>contact me; I would love to find out about their experiences! 

> 

>Feel free to forward this to the reflector, and include me on any 

>replies or further conversations, but I don't read pppext. 

> 

> --Rod 

  











  

  
Mohamed Ali SFAXI writes:
  

  

    
> In order to have a valid key, we need some negotiation before. The 
> negotiation is done thanks to ECP. The two peers have to agree on the 
> key length,
    

  

  

The key length and how the key bits are manipulated is intimately tied
with the encryption algorithm chosen.  This is why I keep asking about
that problem.

For example, if you use 3DES (RFC 2420), you need three 56-bit
subkeys, each of which is normally stored in an 8-octet block, with
the 8 LSBs ignored (used as parity).  So, one plausible transform
would be to take exactly 24 octets from the quantum stream, and use
them directly as the three keys (k1, k2, and k3).  To do this, you
need to wipe out the LSBs (for use as parity) and reject any weak key
proposed by your peer.

But that's only *ONE* plausible transform among many, and it seems to
assume that the quantum stream itself is error-free.  If each
implementation chooses to do this a different way, you'll end up with
chaos.  It won't be interoperable.

Furthermore, once you've chosen the algorithm, at least in this case,
you no longer have the option of negotiating the key length.  The
algorithm dictates it.
  

  




Negotiating the key length is a
feasible
way to be independent from the encryption algorithm and to use the QKD
for new
algorithms and other encryption mechanisms like the one-time-pad
function.







  

  
In addition to that, the TTL appears to be unnecessary.  The simplest
way to deal with key expiry is to renegotiate ECP itself.  Why isn't
that the chosen method?

Or, if you can change the key on the fly without restarting ECP, then
why not just do it?  Why must the peers agree on this parameter at
all?

If it's a useful feature, wouldn't a key TTL be something that's
generally helpful for ECP, rather than a specific issue with quantum
key exchange?
  

  




We have to use TTL for two
reasons :


- security purpose (to have the
possibility
to refresh encryption key often)


- as we use the link as the
quantum channel
and the classical channel the classical communication must stop (when
the TTL
expires) and the quantum communication starts.



  

  
  

  

    
> TTL and perhaps additional option not described in our draft.
    

  

  

Please explain the "additional option," or at least the intended
behavior.  How do we get interoperability if we have features that
aren't documented?
  

  




“additional option” for us is a
way to
negotiate new QKD parameters. This field is not used now but could be
used if required
by users and we think that we may need a free field for the future use.







  

  

  

    
> when these parameters are fixed, a QKD starts. This is done out of the 
> PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to 
> show that the network phase will start after the key is shared.
> after that, the key is delivered to the network phase to encrypt data
    

  

  

I don't see how this requires any special negotiation.

Obviously, you must have prior arrangement to use these "Q3P modems"
on the two consenting peers.  Why is that by itself not sufficient to
indicate that this new key source is desired?  Why must the peers also
negotiate something that they already know to be true?

  

  

    
> We didn't propose any encryption algorithm that could be used because 
> all the encryption algorithms that are already recognized by PPP could 
> be used. In fact, we have  introduced only a new way to obtain the 
> encryption key. I think that our draft do not harm the interoperability.
    

  

  

See above.  That choice is an interoperability problem.


-- 
James Carlson, KISS Network                    <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677




  










  

Vernon Schryver wrote:
  

    
From: Mohamed Ali SFAXI <MohamedAli.Sfaxi@unil.ch>
    

  

  


  

  

    
In order to have a valid key, we need some negotiation before. The=20
negotiation is done thanks to ECP. The two peers have to agree on the=20
key length, TTL and perhaps additional option not described in our draft.
    

  

  

Your words "perhaps additional option not described in our draft" would
demand that your draft be rejected by the IESG until it is complete.

Have you read the RFCs on how to publish an I-D?
  





As we said above : "


“additional option” for us is a
way to
negotiate new QKD parameters. This field is not used now but could be
used if required
by users and we think that we may need a free field for the future use.

"



  

  

  

    
when these parameters are fixed, a QKD starts. This is done out of the=20
PPP mechanism (i.e using Q3P modems). We mentioned it in the draft to=20
show that the network phase will start after the key is shared.
after that, the key is delivered to the network phase to encrypt data
    

  

  

Again, that seems to have nothing to do with QKD in particular.


  

  

    

      
Moreover, the draft does not explain how the key to be used with the
chosen algorithm is actually derived, nor what algorithms are
possible, so there's essentially no hope of interoperability.  As IETF
documents have the explicit goal of producing interoperable
implementations, this draft falls short of what's needed.

      

    

    
We didn't propose any encryption algorithm that could be used because=20
all the encryption algorithms that are already recognized by PPP could=20
be used. In fact, we have  introduced only a new way to obtain the=20
encryption key. I think that our draft do not harm the interoperability.
    

  

  

Until and unless your draft does something to help interoperability,
the IESG should to reject it.  Guessing that some as yet unknown ECP
negotiations might be needed for QKP does not justify an RFC or
an IANA type assignment.



] From: Mohamed Ali SFAXI <MohamedAli.Sfaxi@unil.ch>


] We are already in contact with Idquantique and maybe we will propose 
] something togother.

It would be wise to withdraw now and return later when you have something
of substance to propose.


]>>Here are some requirements to perform a quantum key distribution:

] >As far as PPP is concerned, exactly the same is true of any use of=20
] >PPP encryption.  In general one does not change PPP when one uses
] >new kinds of modems.
]
] You are right. However, the question was how to exchange the key so I=20
] answered to that question.

I do not recall that anyone asked how quantum cryptography works
or how it might be used in a vague, hand waving theory to exchange
keys.  Perhaps you did not realize that people interested in moving
encrypted or otherwise secure data over long distances might already
be as aware of QKD as you seem to be.

More important, your document fails to specify how to exchange keys
using quantum crypography.  I suspect that there is more than one way,
and that some sort of negotiating might be useful.  That negotiating,
if needed, sounds like an appropriate subject of an RFC.  However,
your draft of an I-D does not in any way address such issues.
  



The QKD negotiation depends mainly on the QKD protocols. We assume that
the modems and the software in these modems are the only concerned by
the negotiation. I completely agree with you to have a common
negotiation way in QKD.





  

] >>Here are some requirements to perform a quantum key distribution:

] >That fact does not affect PPP, and does not answer the questions
] >that have been raised about your I-D.
]
] Same thing

Telling us things we already know about QKD does not answer questions
about you draft of an I-D.


] >>b- A Q3P modem: this modem has to polarize, send and detect photons; it=

] >That also does not affect PPP, and does not answer the questions raised
] >about your I-D.

] Same thing

Why do you assume we know nothing of quantum cryptography?
  



I don't assume that but I presented what we need to use quantum
cryptography.





  

] >PPP often does not change to use new kinds of conventional modems.

] Our idea was to create some kind of ECP negotiation to fix the key=20
] exchange parameters 

According to your own words about possible additional options, your
draft of an I-D fails to do that.
  



please see above



  
]                                                                 So it=20
] is normal that the existing PPP implementations fits well. The only=20
] difference is that to start the network phase using an encryption=20
] algorithm we can choose to use the QKD to share a secret key or to=20
] assume that the key is already shared (i..e what is done now in PPP).

You do not need a special negotiation for QKD PPP to do that.  When
you install the quantum cryptography modems, you must configure them
and rest of your PPP machinery to use them.  Part of that installation
procedure can involve setting the parameters that are pecular to QKD.
Parameters that are common to other ECP schemes do not need a QKD RFC.
It might be that QKD will need some PPP negotiations, but they cannot
be standardized before they are specified.

You persist in not answering the question of how QKD differs from
plain old telephones for key distribution as far as PPP and ECP are
concerned.
  



The QKD is a solution to distribute keys.  We try to have an automatic 
"on-line" way to share the secret key. We choose the QKD as it is an
unconditional secure mechanism to distribute secret. We need the ECP to
configure this exchange (not physical configuration but logical
configuration).





  

This is all supposed to be about assigning an ECP type number to BB84.
I've been told by people actually working on quantum cryptography and
quantum computing that BB84 is an extremely unlikely choice.  Actually,
the words they used about this whole proposal were a lot stronger.

This should be rejected until something is actually proposed (i.e.
without any TBD holes for possible additional parameters) and with
support from people actually working with QKD.  It would be wrong to
tie the hands of people working on QKD by advancing something that is
only a place keeper.

  





We propose the BB84 as it is the initial QKD
protocol and the most famous. In addition, BB84 is still used by MagiQ
and
IdQuantique.


  
Vernon Schryver    vjs@rhyolite.com

  














Mohamed Ali SFAXI








Mohamed Ali SFAXI 

Assistant Diplômé 

Inforge - HEC 

University of Lausanne 

tel. + 4121 692 34 22



Website : http://www.hec.unil.ch/sfaxi/


 









  
  






--------------060608020100010705080403--


--===============1860630742==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext

--===============1860630742==--




From pppext-bounces@ietf.org Mon Oct 17 10:10:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERVhJ-0000S4-Hi; Mon, 17 Oct 2005 10:10:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERVhH-0000QG-50
	for pppext@megatron.ietf.org; Mon, 17 Oct 2005 10:10:39 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14465
	for ; Mon, 17 Oct 2005 10:10:32 -0400 (EDT)
Received: from calcite.rhyolite.com ([192.188.61.3])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERVsb-0007DF-7w
	for pppext@ietf.org; Mon, 17 Oct 2005 10:22:22 -0400
Received: from calcite.rhyolite.com (localhost [127.0.0.1])
	by calcite.rhyolite.com (8.13.4/8.13.4) with ESMTP id j9HEALC2066081
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	env-from ; 
	Mon, 17 Oct 2005 08:10:21 -0600 (MDT)
Received: (from vjs@localhost)
	by calcite.rhyolite.com (8.13.4/8.13.4/Submit) id j9HEALBt066080;
	Mon, 17 Oct 2005 08:10:21 -0600 (MDT)
Date: Mon, 17 Oct 2005 08:10:21 -0600 (MDT)
From: Vernon Schryver 
Message-Id: <200510171410.j9HEALBt066080@calcite.rhyolite.com>
To: bmanning@karoshi.com, MohamedAli.Sfaxi@unil.ch, pppext@ietf.org,
	rdv@tera.ics.keio.ac.jp, sgh@unil.ch
Subject: Re: [Pppext] Re: your ECP-QKD draft
In-Reply-To: <43538DBA.4080409@unil.ch>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: 
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

> From: Mohamed Ali SFAXI 


> Negotiating the key length is a feasible way to be independent from the=20
> encryption algorithm and to use the QKD for new algorithms and other=20
> encryption mechanisms like the one-time-pad function.

That not only does not address the point, it is wrong.

For example, to use a one-time pad, it would be necessary to specify
which pad, where you start using it, and how you use it.  Do you
use bit-wise XOR or something else such as byte-wise addition?
Is the idea is to XOR a stream of random bits carried on the quantum
channel with the bits on a conventional channel?  Perhaps you would
do that because the quantum channel is slow but runs continuously but
you'd run the conventional channel only there are PPP bits to carry.
But in that case, which bits on the conventional channel are encrypted?
link layer framing? LCP? I assume not ECP, but is that right?


In checking the draft to see if it says anything on that issue, I
noticed the T field which is defined as

     The T field specifies if the TTL field concerns the number of
     messages or the amount of time. If the value is 1, the TTL 
     field corresponds to the amount of time in second. If it is 0, 
     the TTL is the number of messages per key.
 
What is a "message"?  Is it a PPP packet for any NCP or something
else?  Are any PPP packets not counted, such as ECP packets carrying
TTL and T fields?  Or is a message a fixed block of bits or something 
else understood by the QKD modems and not known to PPP?

What, if any state change happens in the ECP state machine when the
TTL expires?


> >Please explain the "additional option," or at least the intended
> >behavior.  How do we get interoperability if we have features that
> >aren't documented?
> >
> "additional option" for us is a way to negotiate new QKD parameters.=20
> This field is not used now but could be used if required by users and we=20
> think that we may need a free field for the future use.

That does not answer the question of how to interoperability might
be achieved when there are unspecified additional parameters somewhere
on the fiber.

> "additional option" for us is a way to negotiate new QKD parameters.=20
> This field is not used now but could be used if required by users and we=20
> think that we may need a free field for the future use.

So that's why the diagram on page 4 just trails off.  I thought it was
a mere editoral problem.  It is instead intentional.  Implementors are
supposed to pick whatever length they like and need, and interoperability
be hanged.


Enough of this waste time of time.


Vernon Schryver    vjs@rhyolite.com

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext



From pppext-bounces@ietf.org Mon Oct 17 14:51:10 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERa4k-0002wa-2y; Mon, 17 Oct 2005 14:51:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERa4i-0002wS-5V
	for pppext@megatron.ietf.org; Mon, 17 Oct 2005 14:51:08 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00690
	for ; Mon, 17 Oct 2005 14:51:01 -0400 (EDT)
Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERaG5-00073j-2x
	for pppext@ietf.org; Mon, 17 Oct 2005 15:02:54 -0400
Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 19:50:52 +0100
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Mon, 17 Oct 2005 19:50:50 +0100
Received: from juniper.net ([172.28.11.169] RDNS failed) by pi-smtp.jnpr.net
	with Microsoft SMTPSVC(5.0.2195.6713); 
	Mon, 17 Oct 2005 14:50:49 -0400
Message-ID: <4353F289.7070406@juniper.net>
Date: Mon, 17 Oct 2005 14:50:49 -0400
From: "Paul W. Howard" 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Arberg 
Subject: RE: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Oct 2005 18:50:49.0453 (UTC)
	FILETIME=[B0F129D0:01C5D34B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Content-Transfer-Encoding: 7bit
Cc: pppext@ietf.org
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

Peter,

I see a couple of items in the draft that are not what I expected given 
the notes I have from the DSL Forum meetings.   Can you comment on them?

Sec 4, para 2 - Server responding with tag. As I recall, this was going 
to be simply an echo of the tag received from the client to confirm the 
ability to server to handle the tag from the client. The draft is 
unclear on this, but it could be read as the server is generating a tag 
value based on local knowledge instead of just echoing the client's tag.

Sec 5.1, para 5? - "If a MRU option is not sent...". As I recall, we 
were not going to re-define the meaning of the absence MRU option, 
rather leave it at the standard value of 1500. It seems that this 
paragraph attempts to redefine the meaning of the absence as either 1492 
(if no PPP-MAX-PAYLOAD tag) or the value of the PPP-MAX-PAYLOAD tag if 
present.

Thanx,

Paul Howard



_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext



From pppext-bounces@ietf.org Tue Oct 18 08:53:00 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERqxg-0006Kx-Ml; Tue, 18 Oct 2005 08:53:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EQSp4-0004pE-U6
	for pppext@megatron.ietf.org; Fri, 14 Oct 2005 12:54:24 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00366
	for ; Fri, 14 Oct 2005 12:54:17 -0400 (EDT)
Received: from felix.hopcount.ca ([204.152.186.101] helo=felix.automagic.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EQSzm-0003qY-WE
	for pppext@ietf.org; Fri, 14 Oct 2005 13:05:29 -0400
Received: from [198.32.6.178] (helo=[198.32.6.178])
	by felix.automagic.org with esmtpsa (TLSv1:RC4-SHA:128)
	(Exim 4.42 (FreeBSD))
	id 1EQSoj-000DbK-FS; Fri, 14 Oct 2005 16:54:01 +0000
In-Reply-To: <434FB143.4040507@unil.ch>
References: <17229.15711.955152.614897@gargle.gargle.HOWL>	<434E4D01.5030400@unil.ch>
	<17230.24177.218809.473754@gargle.gargle.HOWL>
	<434FB143.4040507@unil.ch>
Mime-Version: 1.0 (Apple Message framework v623)
Message-Id: <038deb4f55e198651866a6da54fecfec@karoshi.com>
From: Bill Manning 
Subject: Re: [Pppext] Re: your ECP-QKD draft
Date: Fri, 14 Oct 2005 09:54:01 -0700
To: Mohamed Ali SFAXI 
X-Mailer: Apple Mail (2.623)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6
X-Mailman-Approved-At: Tue, 18 Oct 2005 08:52:59 -0400
Cc: pppext@ietf.org, sgh@unil.ch, James Carlson ,
	Rod Van Meter 
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0595984213=="
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org


--===============0595984213==
Content-Type: multipart/alternative; boundary=Apple-Mail-4-677786433


--Apple-Mail-4-677786433
Content-Type: text/plain;
	charset=UTF-8;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: quoted-printable

a couple of things here:


the I-D is in the DB at
https://datatracker.ietf.org/public/idindex.cgi?=20
command=3Dview_related_docs&id=3D13770
  but clicking on the "view document" link gets nothing!

and one of my quantum computing cohorts makes this comment:

 >Mr. Sfaxi either misunderstands or fails to explain one VERY important
 >point:  QKD REQUIRES an authenticated classical channel to operate
 >securely.  Such a channel involves either PKI or a pre-shared secret.
 >
 >See
 >http://rdvlivefromtokyo.blogspot.com/2005/10/stop-myth-qkd-doesnt-fix-=20=

what-shor.html
 >http://dabacon.org/pontiff/?p=3D1086
 >and especially
 >http://arxiv.org/abs/quant-ph/0406147
 >
 >As to id-quantique and MagiQ Technologies, they have been around for a
 >couple of years.  I don't know anyone who has actually purchased and
 >used their equipment.  If you know anyone who has, please ask them to
 >contact me; I would love to find out about their experiences!
 >
 >Feel free to forward this to the reflector, and include me on any
 >replies or further conversations, but I don't read pppext.
 >
 >               --Rod


On Oct 14, 2005, at 6:23, Mohamed Ali SFAXI wrote:

>  Dear All,
>
>  James Carlson wrote:Mohamed Ali SFAXI writes:
>>
>>> To exchange the quantum key , both nodes must have some special =20
>>> features
>>> (quantum devices) or simply a quantum modem (these modems like are
>>> already sold by some companies such as IdQuantique =20
>>> (www.idquantique.com)
>>> and MagiQ (http://www.magiqtech.com/))
>>>
>> Yes, understood.
>>
>> However, none of the explanation you've offered actually addresses =
the
>> questions I've asked.  Please examine this feature from your proposed
>> draft:
>>
>>
>>>     To establish and configure the quantum key distribution between
>>>     the two nodes, it is necessary to exchange some data between
>>>     them. We propose a specific ECP packet format to carry QKD
>>>     parameters (Figure 2):
>>>
>>>
>>>     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     |  Key-Length
>>>     =
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>     |     TTL     |T|
>>>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>>>
>> [...]
>>
>>>     Length field:
>>>     The length is number of octets in the packet and it is more than
>>>     =EF=BF=BD5=EF=BF=BD octets (1 octet for the type, 1 octet for =
the packet length,
>>>     2 octets for the key length and one octet for the TTL and the T
>>>     field).
>>>
>> This appears to describe a new option for ECP that exchanges keys
>> between the peers, and does the exchange in the clear.
>>
>
>> Why does it do that?  What does it have to do with quantum key
>> exchange?
>>
>
>  when these parameters are fixed, a QKD starts. This is done out of =20=

> the PPP mechanism (i.e using Q3P modems). We mentioned it in the draft =
=20
> to show that the network phase will start after the key is shared.
>  after that, the key is delivered to the network phase to encrypt data
>
>> Moreover, the draft does not explain how the key to be used with the
>> chosen algorithm is actually derived, nor what algorithms are
>> possible, so there's essentially no hope of interoperability.  As =
IETF
>> documents have the explicit goal of producing interoperable
>> implementations, this draft falls short of what's needed.
>>
>
>
>
>  Best regards,
>
>
>
> Mohamed Ali SFAXI
> Assistant Dipl=C3=B4m=C3=A9
> Inforge - HEC
> University of Lausanne
> tel. + 4121 692 34 22
> Website=C2=A0: http://www.hec.unil.ch/sfaxi/
> =C2=A0
>
> _______________________________________________
> Pppext mailing list
> Pppext@ietf.org
> https://www1.ietf.org/mailman/listinfo/pppext

--Apple-Mail-4-677786433
Content-Type: text/enriched;
	charset=UTF-8
Content-Transfer-Encoding: quoted-printable

a couple of things here:


=20

the I-D is in the DB at

=
https://datatracker.ietf.org/public/idindex.cgi?command=3Dview_related_doc=
s&id=3D13770                                                             =
=20

 but clicking on the "view document" link gets nothing!=20


and one of my quantum computing cohorts makes this comment:


>Mr. Sfaxi either misunderstands or fails to explain one VERY important

>point:  QKD REQUIRES an authenticated classical channel to operate

>securely.  Such a channel involves either PKI or a pre-shared secret.

>

>See

=
>http://rdvlivefromtokyo.blogspot.com/2005/10/stop-myth-qkd-doesnt-fix-wha=
t-shor.html                                                           =20=


>http://dabacon.org/pontiff/?p=3D1086                                    =
                                                                         =
=20

>and especially

>http://arxiv.org/abs/quant-ph/0406147                                   =
                                                                       =20=


>

>As to id-quantique and MagiQ Technologies, they have been around for a

>couple of years.  I don't know anyone who has actually purchased and

>used their equipment.  If you know anyone who has, please ask them to

>contact me; I would love to find out about their experiences!

>

>Feel free to forward this to the reflector, and include me on any

>replies or further conversations, but I don't read pppext.

>

>               --Rod



On Oct 14, 2005, at 6:23, Mohamed Ali SFAXI wrote:


 Dear All,


 James Carlson wrote:Mohamed Ali SFAXI writes:

  

To exchange the quantum key , both nodes must have
some special features=20

(quantum devices) or simply a quantum modem (these modems like are=20

already sold by some companies such as IdQuantique
(0000,0000,FFFFwww.idquantique.com)=20

and MagiQ
(0000,0000,FFFFhttp://www.magiqtech.com/))

    

Yes, understood.


However, none of the explanation you've offered actually addresses the

questions I've asked.  Please examine this feature from your proposed

draft:


  

    To establish and configure the quantum key
distribution between=20

    the two nodes, it is necessary to exchange some data between=20

    them. We propose a specific ECP packet format to carry QKD=20

    parameters (Figure 2):



    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     |  Key-Length

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    |     TTL     |T|   =20

    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

    

[...]

  

    Length field:

    The length is number of octets in the packet and it is more than=20

  =20
=
LastResort=EF=BF=BD<=
/fontfamily>5LastResort=
=EF=BF=BD
octets (1 octet for the type, 1 octet for the packet length,=20

    2 octets for the key length and one octet for the TTL and the T=20

    field).

    

This appears to describe a new option for ECP that
exchanges keys

between the peers, and does the exchange in the clear.

  



Why does it do that?  What does it have to do with
quantum key

exchange?

  



 when these parameters are fixed, a QKD starts. This is done out of
the PPP mechanism (i.e using Q3P modems). We mentioned it in the draft
to show that the network phase will start after the key is shared.=20

 after that, the key is delivered to the network phase to encrypt data


Moreover, the draft does not explain how the key to be
used with the

chosen algorithm is actually derived, nor what algorithms are

possible, so there's essentially no hope of interoperability.  As IETF

documents have the explicit goal of producing interoperable

implementations, this draft falls short of what's needed.

  





 Best regards,



=20

Courier NewMohamed
Ali
SFAXITimes =
New Roman 

Courier NewAssistant
Dipl=C3=B4m=C3=A9Ti=
mes New Roman 

Courier NewInforge -
HECTimes New =
Roman 

Courier NewUniversity
of
LausanneTimes New =
Roman 

Courier Newtel. + 4121
692 34
22Times New =
Roman 

Times New RomanWebsite=C2=A0:
=
0000,0000,FFFFhttp://www.hec.unil.ch/sfaxi/<=
/bigger>

Times New =
Roman=C2=A0


_______________________________________________

Pppext mailing list

Pppext@ietf.org

https://www1.ietf.org/mailman/listinfo/pppext

=

--Apple-Mail-4-677786433--



--===============0595984213==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext

--===============0595984213==--





From pppext-bounces@ietf.org Tue Oct 18 08:53:01 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERqxh-0006Ln-8A; Tue, 18 Oct 2005 08:53:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERUnn-0003cp-Tv
	for pppext@megatron.ietf.org; Mon, 17 Oct 2005 09:13:20 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11399
	for ; Mon, 17 Oct 2005 09:13:12 -0400 (EDT)
Received: from maro.tera.ics.keio.ac.jp ([131.113.71.3]
	helo=smtp.tera.ics.keio.ac.jp)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ERUz0-0005ap-S5
	for pppext@ietf.org; Mon, 17 Oct 2005 09:25:02 -0400
Received: (qmail 84750 invoked from network); 17 Oct 2005 22:12:47 +0900
X-Authentication: rdv was authenticated by 0
 at  17 Oct 2005 22:12:47 +0900
Received: from unknown (HELO ?192.168.1.4?) (210.138.128.52)
	by 0 with SMTP; 17 Oct 2005 22:12:47 +0900
Subject: Re: [Pppext] Re: your ECP-QKD draft
From: Rod Van Meter 
To: Mohamed Ali SFAXI 
In-Reply-To: <43538DBA.4080409@unil.ch>
References: <17229.15711.955152.614897@gargle.gargle.HOWL>
	<434E4D01.5030400@unil.ch>	<17230.24177.218809.473754@gargle.gargle.HOWL>
	<434FB143.4040507@unil.ch>	<038deb4f55e198651866a6da54fecfec@karoshi.com>
	<17231.58972.724576.499929@gargle.gargle.HOWL>
	<43538DBA.4080409@unil.ch>
Content-Type: text/plain
Date: Mon, 17 Oct 2005 22:18:11 +0900
Message-Id: <1129555092.3820.34.camel@pokhara.tera.ics.keio.ac.jp>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 (2.2.3-2.fc4) 
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Tue, 18 Oct 2005 08:53:00 -0400
Cc: pppext@ietf.org, sgh@unil.ch, Bill Manning ,
	James Carlson , vjs@calcite.rhyolite.com
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rdv@tera.ics.keio.ac.jp
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org


> > 
> > More important, your document fails to specify how to exchange keys
> > using quantum crypography.  I suspect that there is more than one way,
> > and that some sort of negotiating might be useful.  That negotiating,
> > if needed, sounds like an appropriate subject of an RFC.  However,
> > your draft of an I-D does not in any way address such issues.
> >   
> The QKD negotiation depends mainly on the QKD protocols. We assume
> that the modems and the software in these modems are the only
> concerned by the negotiation. I completely agree with you to have a
> common negotiation way in QKD.

But there is a great deal more to negotiate about a QKD exchange than I
see specified in your document.

A quick glance at http://arxiv.org/abs/0503058/ shows at least the
following levels of the protocol that must be software-selected; I
believe the selection must be the same at both ends, therefore, they
seem like good candidates for a negotiation (and getting that
negotiation right so that a man in the middle can't "dumb down" the
protocol and create a vulnerability to exploit would be the fun and
tricky part):

* Authentication (BBN has implemented two methods)
* Privacy amplification (one method so far)
* entropy estimation (four methods) (this might be local info only, not
sure)
* error detection and correction (two methods)
* sifting (two methods)

That's just what BBN has implemented so far, and I know there are
further methods for various portions of the protocol.  There are dozens
-- maybe a hundred -- good papers on QKD, many of which propose some
slight variant to the protocol that enhances some characteristic that
the authors care about.  Many of those will ultimately fall by the
wayside (some will be *shoved* aside -- QKD researchers, like security
researchers everywhere, delight in attempting to prove each other
wrong), but some will ultimately be negotiable parameters.

> > This is all supposed to be about assigning an ECP type number to BB84.
> > I've been told by people actually working on quantum cryptography and
> > quantum computing that BB84 is an extremely unlikely choice.  Actually,
> > the words they used about this whole proposal were a lot stronger.

> >   
> 
> We propose the BB84 as it is the initial QKD protocol and the most
> famous. In addition, BB84 is still used by MagiQ and IdQuantique. 

Indeed, somewhat to my surprise, it does seem that both are still using
BB84.  Bennett92 requires the creation of only two polarized states,
compared to BB84's four, so it would seem that it should be easier to
implement in hardware, but I'm not building it, so what do I know?  Some
of the further, more modern variants I'm less familiar with.  BBN also
is using BB84 at the moment, but claims to be working on newer protocols
(B92? Lo-Chau?).  I'm not sure which, if either, is actually more
bandwidth- or photon-efficient.

This choice will be made by the modem hardware (actually, modem is a
misnomer, but we'll work with it), and will probably be as fundamentally
unchangeable as the wavelength (though even here I could be wrong, given
flexible enough hardware).  I know the modems have to be "trained up" to
match corresponding states, and I know that has to be repeated on a
regular basis because phases drift with the temperature of the fiber.  I
don't know if there is a need for a classical control protocol here, or
if it's all handled in-band (e.g., by simply selecting some of the bits
as state maintenance bits).

It should be obvious that I know quite a bit about QKD.  It should be
equally obvious that I know nowhere near enough to write an RFC about
how to control it and integrate it with either IPSEC or PPP.  If it were
me, I would leave this to the folks actually doing the work -- or,
perhaps, attempt to create an alliance with them to co-write it, if they
are able to contribute technically but lack either the time or
proficiency to generate the complete RFC by themselves.  RFCs should be
written by the people doing the work; even the proxy method I just
described is a poor substitute for it.

		--Rod



_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext



From pppext-bounces@ietf.org Tue Oct 18 10:18:36 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERsIW-0003bG-Rw; Tue, 18 Oct 2005 10:18:36 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ERsIV-0003b8-Te
	for pppext@megatron.ietf.org; Tue, 18 Oct 2005 10:18:35 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03431
	for ; Tue, 18 Oct 2005 10:18:28 -0400 (EDT)
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ERsU2-0006ta-JA
	for pppext@ietf.org; Tue, 18 Oct 2005 10:30:32 -0400
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP
	id 28CBD6F8A19; Tue, 18 Oct 2005 07:18:25 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1])
	by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 21211-06; Tue, 18 Oct 2005 07:18:25 -0700 (PDT)
Received: from PARBETM2XP (login-1-300.redback.com [155.53.12.153])
	by prattle.redback.com (Postfix) with ESMTP
	id 952576F8A18; Tue, 18 Oct 2005 07:18:23 -0700 (PDT)
From: "Peter Arberg" 
To: "'Paul W. Howard'" 
Subject: RE: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt
Date: Tue, 18 Oct 2005 16:18:15 +0200
Organization: Redback Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <4353F289.7070406@juniper.net>
Thread-Index: AcXTS7OmI/ijTGTBSD6t/7j4UL2QPQAoRTYQ
Message-Id: <20051018141823.952576F8A18@prattle.redback.com>
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Cc: pppext@ietf.org
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: parberg@redback.com
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

Hi Paul,

answers inline.
 

> I see a couple of items in the draft that are not what I 
> expected given the notes I have from the DSL Forum meetings.
> Can you comment on them?
> 
> Sec 4, para 2 - Server responding with tag. As I recall, this 
> was going to be simply an echo of the tag received from the 
> client to confirm the 
> ability to server to handle the tag from the client. The draft 
> is unclear on this, but it could be read as the server is 
> generating a tag value based on local knowledge instead of 
> just echoing the client's tag.

correct, since the BRAS typical will be able to support any MRU,
it will in real life proabably always be an echo of the 
pppoe-clients tag.

But I did not want to limit the draft, and say it must be an echo,
because in the unlikely event that the pppoe-server do not support
as high a maximum-MRU as the client suggest, the server now have 
the option to reject the maximum-MRU (no tag included in PADO, PADS)
or to include it's own tag value with a maximum-MRU it supports.


> 
> Sec 5.1, para 5? - "If a MRU option is not sent...". As I recall, we 
> were not going to re-define the meaning of the absence MRU option, 
> rather leave it at the standard value of 1500. It seems that this 
> paragraph attempts to redefine the meaning of the absence as 
> either 1492 (if no PPP-MAX-PAYLOAD tag) or the value of the 
> PPP-MAX-PAYLOAD tag if present.


No it was not the intention to redefine any default MRU value, it will
be according to RFC1661, 1500 bytes, but this paragraph was simply to
say if no tag received, then RFC 2516 defines a maximum MRU for 
PPPoE sessions at 1492, and as such the maximum MRU will still be 1492.

hope this make it more clear.
Peter


> 
> Thanx,
> 
> Paul Howard
> 
> 
> 



_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext



From pppext-bounces@ietf.org Fri Oct 21 16:56:05 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET3vo-0002Iq-W3; Fri, 21 Oct 2005 16:56:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1ET3vo-0002IW-5D
	for pppext@megatron.ietf.org; Fri, 21 Oct 2005 16:56:04 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03775
	for ; Fri, 21 Oct 2005 16:55:52 -0400 (EDT)
Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ET480-0000rk-Sy
	for pppext@ietf.org; Fri, 21 Oct 2005 17:08:41 -0400
Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 21:55:53 +0100
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Oct 2005 21:55:52 +0100
Received: from juniper.net ([172.28.11.169] RDNS failed) by pi-smtp.jnpr.net
	with Microsoft SMTPSVC(5.0.2195.6713); 
	Fri, 21 Oct 2005 16:55:51 -0400
Message-ID: <435955D9.2070606@juniper.net>
Date: Fri, 21 Oct 2005 16:55:53 -0400
From: "Paul W. Howard" 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: parberg@redback.com
Subject: Re: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt
References: <20051018141823.952576F8A18@prattle.redback.com>
In-Reply-To: <20051018141823.952576F8A18@prattle.redback.com>
X-OriginalArrivalTime: 21 Oct 2005 20:55:51.0455 (UTC)
	FILETIME=[D222D2F0:01C5D681]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 515708a075ffdf0a79d1c83b601e2afd
Cc: pppext@ietf.org
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============0608839706=="
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0608839706==
Content-Type: multipart/alternative;
	boundary="------------010301070009020304080605"

This is a multi-part message in MIME format.
--------------010301070009020304080605
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter,

Thanx for your responses.   I think there is still some lack of clarity 
in this issues that needs to be addressed in the draft.

1) For the tag response (Sec 4, para 2).   We can't allow the server a 
choice in what it sends.   The draft needs to explicitly state that it 
either (a) sends back what it received (i.e. just a basic ack of support 
for the tag) or (b) sends back it's own max MRU (i.e. an ack of support 
for the tag and an indication of it's max MRU).   If we were to leave 
the draft as written, then the client upon receiving the tag would have 
no way to interpret the tag value in the situation where the server's 
max happens to be the same as the client's max - it can not tell whether 
it's just an ack (i.e. choice (a)) or an ack and an indicaiton of the 
server's max (i.e. choice (b)).   Thus it would seem that we must pick 
one of these two definitions for the tag value.

Further, it would seem that in a situation where the column is dynamic, 
then the PPP interface likely doesn't exist at the time the tag must be 
transmitted by the server.   As such, requiring the server to respond 
with choice (b) seems problematic as an accurate determination of the 
true max MRU may be impossible at this point.    Given this and the fact 
that there isn't any real value to reporting the server's max MRU at 
this time (it's going to be reported during PPP negotiation), then it 
would seem the draft should specify choice (a).

2) On the missing MRU option (Sec 5.1, para 5).   I think this paragraph 
clearly attempts to redefine the meaning of the "default" MRU (i.e. the 
value of the MRU when the option is not preseent):

"If a MRU option is not sent by one end of the PPP negotiation, a  
maximum MRU size of 1492 bytes MUST be assumed and used, unless the 
PPP-Max-Payload tag was present in the PPPoE Discovery Stage, in which 
case this value MUST be used as the maximum MRU value.".

It seems to be extremely inadvisable to change the meaning of a missing 
PPP LCP option.   If the MRU option is not sent, then PPP must use its 
current behavior regardless of whether or not the PPPoE tag was 
present.   Thus when the PPP MRU option is missing, the MRU is assumed 
to be 1500 octets (per the PPP RFC) regardless of the underlying 
layers.   It would be a very bad idea to assume a higher MRU just 
because this tag was present in the PPPoE packets since the client has 
not given permission to use a value greater than 1500.

Thanx,

Paul Howard

Peter Arberg wrote:

>Hi Paul,
>
>answers inline.
> 
>
>  
>
>>I see a couple of items in the draft that are not what I 
>>expected given the notes I have from the DSL Forum meetings.
>>Can you comment on them?
>>
>>Sec 4, para 2 - Server responding with tag. As I recall, this 
>>was going to be simply an echo of the tag received from the 
>>client to confirm the 
>>ability to server to handle the tag from the client. The draft 
>>is unclear on this, but it could be read as the server is 
>>generating a tag value based on local knowledge instead of 
>>just echoing the client's tag.
>>    
>>
>
>correct, since the BRAS typical will be able to support any MRU,
>it will in real life proabably always be an echo of the 
>pppoe-clients tag.
>
>But I did not want to limit the draft, and say it must be an echo,
>because in the unlikely event that the pppoe-server do not support
>as high a maximum-MRU as the client suggest, the server now have 
>the option to reject the maximum-MRU (no tag included in PADO, PADS)
>or to include it's own tag value with a maximum-MRU it supports.
>
>
>  
>
>>Sec 5.1, para 5? - "If a MRU option is not sent...". As I recall, we 
>>were not going to re-define the meaning of the absence MRU option, 
>>rather leave it at the standard value of 1500. It seems that this 
>>paragraph attempts to redefine the meaning of the absence as 
>>either 1492 (if no PPP-MAX-PAYLOAD tag) or the value of the 
>>PPP-MAX-PAYLOAD tag if present.
>>    
>>
>
>
>No it was not the intention to redefine any default MRU value, it will
>be according to RFC1661, 1500 bytes, but this paragraph was simply to
>say if no tag received, then RFC 2516 defines a maximum MRU for 
>PPPoE sessions at 1492, and as such the maximum MRU will still be 1492.
>
>hope this make it more clear.
>Peter
>
>
>  
>
>>Thanx,
>>
>>Paul Howard
>>
>>
>>
>>    
>>
>
>
>  
>

--------------010301070009020304080605
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  




Peter,



Thanx for your responses.   I think there is still some lack of clarity
in this issues that needs to be addressed in the draft.



1) For the tag response (Sec 4, para 2).   We can't allow the server a
choice in what it sends.   The draft needs to explicitly state that it
either (a) sends back what it received (i.e. just a basic ack of
support for the tag) or (b) sends back it's own max MRU (i.e. an ack of
support for the tag and an indication of it's max MRU).   If we were to
leave the draft as written, then the client upon receiving the tag
would have no way to interpret the tag value in the situation where the
server's max happens to be the same as the client's max - it can not
tell whether it's just an ack (i.e. choice (a)) or an ack and an
indicaiton of the server's max (i.e. choice (b)).   Thus it would seem
that we must pick one of these two definitions for the tag value.



Further, it would seem that in a situation where the column is dynamic,
then the PPP interface likely doesn't exist at the time the tag must be
transmitted by the server.   As such, requiring the server to respond
with choice (b) seems problematic as an accurate determination of the
true max MRU may be impossible at this point.    Given this and the
fact that there isn't any real value to reporting the server's max MRU
at this time (it's going to be reported during PPP negotiation), then
it would seem the draft should specify choice (a).



2) On the missing MRU option (Sec 5.1, para 5).   I think this
paragraph clearly attempts to redefine the meaning of the "default" MRU
(i.e. the value of the MRU when the option is not preseent):



"If a MRU option is not sent by one end of the PPP negotiation, a 
maximum MRU size of 1492 bytes MUST be assumed and used, unless the
PPP-Max-Payload tag was present in the PPPoE Discovery Stage, in which
case this value MUST be used as the maximum MRU value.".



It seems to be extremely inadvisable to change the meaning of a missing
PPP LCP option.   If the MRU option is not sent, then PPP must use its
current behavior regardless of whether or not the PPPoE tag was
present.   Thus when the PPP MRU option is missing, the MRU is assumed
to be 1500 octets (per the PPP RFC) regardless of the underlying
layers.   It would be a very bad idea to assume a higher MRU just
because this tag was present in the PPPoE packets since the client has
not given permission to use a value greater than 1500.



Thanx,



Paul Howard



Peter Arberg wrote:



  
Hi Paul,

answers inline.
 

  

  

    
I see a couple of items in the draft that are not what I 
expected given the notes I have from the DSL Forum meetings.
Can you comment on them?

Sec 4, para 2 - Server responding with tag. As I recall, this 
was going to be simply an echo of the tag received from the 
client to confirm the 
ability to server to handle the tag from the client. The draft 
is unclear on this, but it could be read as the server is 
generating a tag value based on local knowledge instead of 
just echoing the client's tag.
    

  

  

correct, since the BRAS typical will be able to support any MRU,
it will in real life proabably always be an echo of the 
pppoe-clients tag.

But I did not want to limit the draft, and say it must be an echo,
because in the unlikely event that the pppoe-server do not support
as high a maximum-MRU as the client suggest, the server now have 
the option to reject the maximum-MRU (no tag included in PADO, PADS)
or to include it's own tag value with a maximum-MRU it supports.


  

  

    
Sec 5.1, para 5? - "If a MRU option is not sent...". As I recall, we 
were not going to re-define the meaning of the absence MRU option, 
rather leave it at the standard value of 1500. It seems that this 
paragraph attempts to redefine the meaning of the absence as 
either 1492 (if no PPP-MAX-PAYLOAD tag) or the value of the 
PPP-MAX-PAYLOAD tag if present.
    

  

  


No it was not the intention to redefine any default MRU value, it will
be according to RFC1661, 1500 bytes, but this paragraph was simply to
say if no tag received, then RFC 2516 defines a maximum MRU for 
PPPoE sessions at 1492, and as such the maximum MRU will still be 1492.

hope this make it more clear.
Peter


  

  

    
Thanx,

Paul Howard



    

  

  


  






--------------010301070009020304080605--



--===============0608839706==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext

--===============0608839706==--





From pppext-bounces@ietf.org Wed Oct 26 10:08:08 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUlwm-0001T0-3t; Wed, 26 Oct 2005 10:08:08 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUlwk-0001Pq-TO
	for pppext@megatron.ietf.org; Wed, 26 Oct 2005 10:08:07 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22027
	for ; Wed, 26 Oct 2005 10:07:51 -0400 (EDT)
Received: from prattle.redback.com ([155.53.12.9])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUm9u-0002xl-6t
	for pppext@ietf.org; Wed, 26 Oct 2005 10:21:43 -0400
Received: from localhost (localhost [127.0.0.1])
	by prattle.redback.com (Postfix) with ESMTP
	id 85BF91583; Wed, 26 Oct 2005 07:07:55 -0700 (PDT)
Received: from prattle.redback.com ([127.0.0.1])
	by localhost (prattle [127.0.0.1]) (amavisd-new, port 10024) with ESMTP
	id 19236-08; Wed, 26 Oct 2005 07:07:55 -0700 (PDT)
Received: from PARBETM2XP (login002.redback.com [155.53.12.54])
	by prattle.redback.com (Postfix) with ESMTP
	id 16FA81580; Wed, 26 Oct 2005 07:07:54 -0700 (PDT)
From: "Peter Arberg" 
To: "'Paul W. Howard'" 
Subject: RE: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt
Date: Wed, 26 Oct 2005 16:07:45 +0200
Organization: Redback Networks
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Thread-Index: AcXWgdVwMcZc8XHDTry0tlGuCHnyogDs7VGw
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <435955D9.2070606@juniper.net>
Message-Id: <20051026140754.16FA81580@prattle.redback.com>
X-Virus-Scanned: by amavisd-new at redback.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
Cc: pppext@ietf.org
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: parberg@redback.com
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

Hi Paul,

I have included some answers inline in your email, hope this
will clarify the intention of the mentioned sections in the 
draft.

> ------------
> Peter,
>	
> Thanx for your responses.   I think there is still some lack 
> of clarity in this issues that needs to be addressed in the draft.
>	
> 1) For the tag response (Sec 4, para 2).   We can't allow the 
> server a choice in what it sends.   The draft needs to 
> explicitly state that it either (a) sends back what it received 
> (i.e. just a basic ack of support for the tag) or (b) sends 
> back it's own max MRU (i.e. an ack of support for the tag and 
> an indication of it's max MRU).   If we were to leave the draft 
> as written, then the client upon receiving the tag would have no 
> way to interpret the tag value in the situation where the server's 
> max happens to be the same as the client's max - it can not tell 
> whether it's just an ack (i.e. choice (a)) or an ack and an indicaiton 
> of the server's max (i.e. choice (b)).   Thus it would seem that we 
> must pick one of these two definitions for the tag value. 
>	 
> Further, it would seem that in a situation where the column is dynamic, 
> then the PPP interface likely doesn't exist at the time the tag must 
> be transmitted by the server.   As such, requiring the server to respond 
> with choice (b) seems problematic as an accurate determination of the 
> true max MRU may be impossible at this point.    Given this and the 
> fact that there isn't any real value to reporting the server's max MRU 
> at this time (it's going to be reported during PPP negotiation), then 
> it would seem the draft should specify choice (a).


I agree on your point, and I will update the draft to specific say that
the BRAS, PPPoE server will echo back the clients pppoe-tag if the
server support a MRU negotiation greater than 1492.

As I see it now, it will be easier and still support all options if 
we do as you suggest, so in short:
 1. pppoe client include "maximum-payload" tag
 2. pppoe server will echo the "maximum-payload" tag if it supports
    larger than 1492 bytes MRU.
 3. pppoe server will not include tag in PADO and PADS response if
    pppoe server do not support the greater than 1492 MRU.
 4. the value send/received in pppoe tag will be used as the possible
    maximum-payload when setting MTU and negotiating MRU.



> 2) On the missing MRU option (Sec 5.1, para 5).   I think this 
> paragraph clearly attempts to redefine the meaning of the "default" 
> MRU (i.e. the value of the MRU when the option is not present):
>
> "If a MRU option is not sent by one end of the PPP negotiation, a  
> maximum MRU size of 1492 bytes MUST be assumed and used, unless the 
> PPP-Max-Payload tag was present in the PPPoE Discovery Stage, in 
> which case this value MUST be used as the maximum MRU value.".
>
> It seems to be extremely inadvisable to change the meaning of a 
> missing PPP LCP option.   If the MRU option is not sent, then PPP 
> must use its current behavior regardless of whether or not the 
> PPPoE tag was present.   Thus when the PPP MRU option is missing, 
> the MRU is assumed to be 1500 octets (per the PPP RFC) regardless 
> of the underlying layers.   It would be a very bad idea to assume 
> a higher MRU just because this tag was present in the PPPoE packets 
> since the client has not given permission to use a value greater 
> than 1500.

I actually did not intended to change the default MRU, but I can
reword it in the next version, if this wording is causing confusion.

The intention is the following:
1. when a "maximum-payload" tag is received, 
 a. then the value in this tag will indicate the maximum allowed 
    MRU to accept and suggest in a MRU negotiation, 
 b. if MRU is not negotiated then RFC1661 will set the default 
    MRU at 1500
 c. so this will say that the maximum-payload tag can have a greater
    value than 1500, but in this case RFC1661 sets default MRU = 1500, 
    and only if MRU is negotiated higher (up to maximum-payload) will
    it be used.

2. when a "maximum-payload" tag is not received by either end,
   then RFC2516 sets the rule.

If we can agree that this should be the intended behavior, then 
I will try and reword the section, and maybe you can proof read it ?

thanks,
Peter
 



_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext



From pppext-bounces@ietf.org Wed Oct 26 11:49:41 2005
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUnX3-0008In-If; Wed, 26 Oct 2005 11:49:41 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EUnX2-0008Id-9S
	for pppext@megatron.ietf.org; Wed, 26 Oct 2005 11:49:40 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02772
	for ; Wed, 26 Oct 2005 11:49:24 -0400 (EDT)
Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUnkB-0007og-HG
	for pppext@ietf.org; Wed, 26 Oct 2005 12:03:18 -0400
Received: from emailemea1.jnpr.net ([172.26.192.140]) by up-smtp.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 16:49:28 +0100
Received: from pi-smtp.jnpr.net ([10.10.2.36]) by emailemea1.jnpr.net with
	Microsoft SMTPSVC(6.0.3790.211); Wed, 26 Oct 2005 16:49:28 +0100
Received: from juniper.net ([172.28.11.131] RDNS failed) by pi-smtp.jnpr.net
	with Microsoft SMTPSVC(5.0.2195.6713); 
	Wed, 26 Oct 2005 11:49:26 -0400
Message-ID: <435FA587.3080007@juniper.net>
Date: Wed, 26 Oct 2005 11:49:27 -0400
From: "Paul W. Howard" 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: parberg@redback.com
Subject: Re: [Pppext] I-D ACTION:draft-arberg-pppoe-mtu-gt1492-01.txt
References: <20051026140754.16FA81580@prattle.redback.com>
In-Reply-To: <20051026140754.16FA81580@prattle.redback.com>
X-OriginalArrivalTime: 26 Oct 2005 15:49:26.0874 (UTC)
	FILETIME=[D82323A0:01C5DA44]
X-Spam-Score: 0.5 (/)
X-Scan-Signature: 850245b51c39701e2700a112f3032caa
Cc: pppext@ietf.org
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: multipart/mixed; boundary="===============2122230938=="
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

This is a multi-part message in MIME format.
--===============2122230938==
Content-Type: multipart/alternative;
	boundary="------------040903000405030208070000"

This is a multi-part message in MIME format.
--------------040903000405030208070000
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter,

Thanx.   I think this addresses my concerns.

Paul

Peter Arberg wrote:

>Hi Paul,
>
>I have included some answers inline in your email, hope this
>will clarify the intention of the mentioned sections in the 
>draft.
>
>  
>
>>------------
>>Peter,
>>	
>>Thanx for your responses.   I think there is still some lack 
>>of clarity in this issues that needs to be addressed in the draft.
>>	
>>1) For the tag response (Sec 4, para 2).   We can't allow the 
>>server a choice in what it sends.   The draft needs to 
>>explicitly state that it either (a) sends back what it received 
>>(i.e. just a basic ack of support for the tag) or (b) sends 
>>back it's own max MRU (i.e. an ack of support for the tag and 
>>an indication of it's max MRU).   If we were to leave the draft 
>>as written, then the client upon receiving the tag would have no 
>>way to interpret the tag value in the situation where the server's 
>>max happens to be the same as the client's max - it can not tell 
>>whether it's just an ack (i.e. choice (a)) or an ack and an indicaiton 
>>of the server's max (i.e. choice (b)).   Thus it would seem that we 
>>must pick one of these two definitions for the tag value. 
>>	 
>>Further, it would seem that in a situation where the column is dynamic, 
>>then the PPP interface likely doesn't exist at the time the tag must 
>>be transmitted by the server.   As such, requiring the server to respond 
>>with choice (b) seems problematic as an accurate determination of the 
>>true max MRU may be impossible at this point.    Given this and the 
>>fact that there isn't any real value to reporting the server's max MRU 
>>at this time (it's going to be reported during PPP negotiation), then 
>>it would seem the draft should specify choice (a).
>>    
>>
>
>
>I agree on your point, and I will update the draft to specific say that
>the BRAS, PPPoE server will echo back the clients pppoe-tag if the
>server support a MRU negotiation greater than 1492.
>
>As I see it now, it will be easier and still support all options if 
>we do as you suggest, so in short:
> 1. pppoe client include "maximum-payload" tag
> 2. pppoe server will echo the "maximum-payload" tag if it supports
>    larger than 1492 bytes MRU.
> 3. pppoe server will not include tag in PADO and PADS response if
>    pppoe server do not support the greater than 1492 MRU.
> 4. the value send/received in pppoe tag will be used as the possible
>    maximum-payload when setting MTU and negotiating MRU.
>
>
>
>  
>
>>2) On the missing MRU option (Sec 5.1, para 5).   I think this 
>>paragraph clearly attempts to redefine the meaning of the "default" 
>>MRU (i.e. the value of the MRU when the option is not present):
>>
>>"If a MRU option is not sent by one end of the PPP negotiation, a  
>>maximum MRU size of 1492 bytes MUST be assumed and used, unless the 
>>PPP-Max-Payload tag was present in the PPPoE Discovery Stage, in 
>>which case this value MUST be used as the maximum MRU value.".
>>
>>It seems to be extremely inadvisable to change the meaning of a 
>>missing PPP LCP option.   If the MRU option is not sent, then PPP 
>>must use its current behavior regardless of whether or not the 
>>PPPoE tag was present.   Thus when the PPP MRU option is missing, 
>>the MRU is assumed to be 1500 octets (per the PPP RFC) regardless 
>>of the underlying layers.   It would be a very bad idea to assume 
>>a higher MRU just because this tag was present in the PPPoE packets 
>>since the client has not given permission to use a value greater 
>>than 1500.
>>    
>>
>
>I actually did not intended to change the default MRU, but I can
>reword it in the next version, if this wording is causing confusion.
>
>The intention is the following:
>1. when a "maximum-payload" tag is received, 
> a. then the value in this tag will indicate the maximum allowed 
>    MRU to accept and suggest in a MRU negotiation, 
> b. if MRU is not negotiated then RFC1661 will set the default 
>    MRU at 1500
> c. so this will say that the maximum-payload tag can have a greater
>    value than 1500, but in this case RFC1661 sets default MRU = 1500, 
>    and only if MRU is negotiated higher (up to maximum-payload) will
>    it be used.
>
>2. when a "maximum-payload" tag is not received by either end,
>   then RFC2516 sets the rule.
>
>If we can agree that this should be the intended behavior, then 
>I will try and reword the section, and maybe you can proof read it ?
>
>thanks,
>Peter
> 
>
>
>  
>

--------------040903000405030208070000
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit




  
  


Peter,



Thanx.   I think this addresses my concerns.



Paul



Peter Arberg wrote:



  
Hi Paul,

I have included some answers inline in your email, hope this
will clarify the intention of the mentioned sections in the 
draft.

  

  

    
------------
Peter,
	
Thanx for your responses.   I think there is still some lack 
of clarity in this issues that needs to be addressed in the draft.
	
1) For the tag response (Sec 4, para 2).   We can't allow the 
server a choice in what it sends.   The draft needs to 
explicitly state that it either (a) sends back what it received 
(i.e. just a basic ack of support for the tag) or (b) sends 
back it's own max MRU (i.e. an ack of support for the tag and 
an indication of it's max MRU).   If we were to leave the draft 
as written, then the client upon receiving the tag would have no 
way to interpret the tag value in the situation where the server's 
max happens to be the same as the client's max - it can not tell 
whether it's just an ack (i.e. choice (a)) or an ack and an indicaiton 
of the server's max (i.e. choice (b)).   Thus it would seem that we 
must pick one of these two definitions for the tag value. 
	 
Further, it would seem that in a situation where the column is dynamic, 
then the PPP interface likely doesn't exist at the time the tag must 
be transmitted by the server.   As such, requiring the server to respond 
with choice (b) seems problematic as an accurate determination of the 
true max MRU may be impossible at this point.    Given this and the 
fact that there isn't any real value to reporting the server's max MRU 
at this time (it's going to be reported during PPP negotiation), then 
it would seem the draft should specify choice (a).
    

  

  


I agree on your point, and I will update the draft to specific say that
the BRAS, PPPoE server will echo back the clients pppoe-tag if the
server support a MRU negotiation greater than 1492.

As I see it now, it will be easier and still support all options if 
we do as you suggest, so in short:
 1. pppoe client include "maximum-payload" tag
 2. pppoe server will echo the "maximum-payload" tag if it supports
    larger than 1492 bytes MRU.
 3. pppoe server will not include tag in PADO and PADS response if
    pppoe server do not support the greater than 1492 MRU.
 4. the value send/received in pppoe tag will be used as the possible
    maximum-payload when setting MTU and negotiating MRU.



  

  

    
2) On the missing MRU option (Sec 5.1, para 5).   I think this 
paragraph clearly attempts to redefine the meaning of the "default" 
MRU (i.e. the value of the MRU when the option is not present):

"If a MRU option is not sent by one end of the PPP negotiation, a  
maximum MRU size of 1492 bytes MUST be assumed and used, unless the 
PPP-Max-Payload tag was present in the PPPoE Discovery Stage, in 
which case this value MUST be used as the maximum MRU value.".

It seems to be extremely inadvisable to change the meaning of a 
missing PPP LCP option.   If the MRU option is not sent, then PPP 
must use its current behavior regardless of whether or not the 
PPPoE tag was present.   Thus when the PPP MRU option is missing, 
the MRU is assumed to be 1500 octets (per the PPP RFC) regardless 
of the underlying layers.   It would be a very bad idea to assume 
a higher MRU just because this tag was present in the PPPoE packets 
since the client has not given permission to use a value greater 
than 1500.
    

  

  

I actually did not intended to change the default MRU, but I can
reword it in the next version, if this wording is causing confusion.

The intention is the following:
1. when a "maximum-payload" tag is received, 
 a. then the value in this tag will indicate the maximum allowed 
    MRU to accept and suggest in a MRU negotiation, 
 b. if MRU is not negotiated then RFC1661 will set the default 
    MRU at 1500
 c. so this will say that the maximum-payload tag can have a greater
    value than 1500, but in this case RFC1661 sets default MRU = 1500, 
    and only if MRU is negotiated higher (up to maximum-payload) will
    it be used.

2. when a "maximum-payload" tag is not received by either end,
   then RFC2516 sets the rule.

If we can agree that this should be the intended behavior, then 
I will try and reword the section, and maybe you can proof read it ?

thanks,
Peter
 


  






--------------040903000405030208070000--



--===============2122230938==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext

--===============2122230938==--





From pppext-bounces@ietf.org Mon Oct 31 07:52:37 2005
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EWZ9R-00004x-6m; Mon, 31 Oct 2005 07:52:37 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32) id 1EWZ9O-0008VK-Kg
	for pppext@megatron.ietf.org; Mon, 31 Oct 2005 07:52:35 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05127
	for ; Mon, 31 Oct 2005 07:52:13 -0500 (EST)
Received: from nwkea-mail-2.sun.com ([192.18.42.14])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EWZNT-0000lN-ON
	for pppext@ietf.org; Mon, 31 Oct 2005 08:07:12 -0500
Received: from eastmail2bur.East.Sun.COM ([129.148.13.40])
	by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j9VCqP4u004013
	for ; Mon, 31 Oct 2005 04:52:25 -0800 (PST)
Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143])
	by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,
	v2.2) with ESMTP id j9VCqOWc001869
	for ; Mon, 31 Oct 2005 07:52:25 -0500 (EST)
Received: from phorcys.East.Sun.COM (localhost [127.0.0.1])
	by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id
	j9VCqOM7009792; Mon, 31 Oct 2005 07:52:24 -0500 (EST)
Received: (from carlsonj@localhost)
	by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id j9VCqOCJ009789;
	Mon, 31 Oct 2005 07:52:24 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <17254.5000.186499.433892@gargle.gargle.HOWL>
Date: Mon, 31 Oct 2005 07:52:24 -0500
From: James Carlson 
To: rdv@tera.ics.keio.ac.jp
Subject: Re: [Pppext] Re: your ECP-QKD draft
In-Reply-To: Rod Van Meter's message of 17 October 2005 22:18:11
References: <17229.15711.955152.614897@gargle.gargle.HOWL>
	<434E4D01.5030400@unil.ch>
	<17230.24177.218809.473754@gargle.gargle.HOWL>
	<434FB143.4040507@unil.ch>
	<038deb4f55e198651866a6da54fecfec@karoshi.com>
	<17231.58972.724576.499929@gargle.gargle.HOWL>
	<43538DBA.4080409@unil.ch>
	<1129555092.3820.34.camel@pokhara.tera.ics.keio.ac.jp>
X-Mailer: VM 7.01 under Emacs 21.3.1
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Content-Transfer-Encoding: 7bit
Cc: pppext@ietf.org, Mohamed Ali SFAXI ,
	Bill Manning , sgh@unil.ch, vjs@calcite.rhyolite.com
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: PPP Extensions 
List-Unsubscribe: ,
	
List-Post: 
List-Help: 
List-Subscribe: ,
	
Sender: pppext-bounces@ietf.org
Errors-To: pppext-bounces@ietf.org

Last call for consensus: it seems to me that the general agreement
I've seen on the list so far is that the draft as specified lacks
sufficient information to produce interoperable implementations and
does not appear to be relevant for PPP ECP.

If this is inaccurate, please let me know.  Otherwise, I'll report
back to ICANN/IANA stating that we do not believe the assignment
should be granted.

-- 
James Carlson, KISS Network                    
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

_______________________________________________
Pppext mailing list
Pppext@ietf.org
https://www1.ietf.org/mailman/listinfo/pppext