CURRENT_MEETING_REPORT_ Reported by Fred Baker/cisco Systems Minutes of the Point-to-Point Protocol Extensions Working Group (PPPEXT) Agenda o Intellectual Property Rights -- Frank Kastenholtz o Implications for Compression -- Fred Baker o Encryption/DES -- Gerry Meyer and Keith Sklower o Multilink Procedure -- Keith Sklower o Authentication Protocols -- Dave Carrels Frank Kastenholtz: Motorola Patent Claim Motorola has not met the requirements of RFC 1602; they have not given the IESG a blanket license for the use of their patent claims. Within the context of RFC 1602, the working group has two choices: continue to hope that the situation will change, or change the CCP and ECP drafts so that they do not infringe on the patent claims. The consensus of the working group is to remove references to the HISTORY RESET REQUEST and HISTORY RESET RESPONSE from the CCP and the ECP, and indicate that CCP should run over reliable PPP (LAPB). Removing all reference to resetting the history buffer is believed to obviate any claim Motorola has regarding these drafts. Actions: Dave Rand to modify the CCP draft accordingly. The authors of the compression algorithm drafts to update drafts if necessary. Gerry Meyer to modify the ECP draft accordingly. Keith Sklower: DES Electronic Codebook Encryption Algorithm Keith described his draft. The consensus was that the draft was acceptable and standardization of ECP should continue based on it. DESE is an informational draft supporting ECP. Keith indicates that the key is ``derived'' from the authentication/EID information; it is ``derived'' in the sense that one of some number of perviously configured keys is selected on the basis of that information. Consensus was to change the word to ``selected''. If there are no other more substantive changes required (and at this point there does not appear to be) this can be handled by the RFC Editor. Dave Carrel suggested that we need a way to specify and perhaps execute a key exchange algorithm in ECP; we discussed an option of the general form: +-------+-------+-------+------- | Type | Length| Code | 0 or more bytes of data +-------+-------+-------+------- Code = 1 use hard coded keys, perhaps selected via authentication/EID information (default) Code = 2 key exchange algorithm involving the data If there are several possible key exchange algorithms, they should be enumerated. This detail to be clarified in list discussion. The draft explicitly does not define a key exchange algorithm, and we do not particularly want to get into defining the key exchange; the objective is to enable a key exchange defined by the IPSEC Working Group to be used. There is some belief that the EBC Mode is inadequate, that Cypher Block Feedback should be used or at least defined. This will be discussed on the list. Actions: Dave to discuss key exchange on the list; if favorable consensus is formed, Gerry to update draft appropriately. Upon closure of this item, Updated ECP draft to Proposed Standard and DESE to Informational RFC. Keith Sklower: PPP Multilink Revision Keith reported that the California Multilink/ISDN interoperability testing prior to the Danvers meeting indicated the desirability of a call-back control protocol to mitigate line-flapping when different systems have different criteria of when a second B-channel is needed. (Keith had volunteered to participate in such work, but not do it unilaterally). No progress has been made. Vern Schryver, in a private communication, suggested to Keith that Ascend be contacted to see if they would be willing to disclose their protocol to be used (even if only as a basis for discussion). Consensus was not to hold up RFC 1717bis for inclusion of any such protocol. Revisions that the current draft embodies: o Clarify: must use MMRU or MMRU+SSNHF: cannot use SSNHF alone to negotiate M/L o Sequence numbers start from zero o No default for MMRU; implementations MUST support MMRU=1500 o No NAK of EID o Must use same SNHF on all links to same peer; other links may use same or different SNHF Revisions needed: o OK to stop using M/L headers if only one link up in certain cases. o When second link passes LCP and Authentication, must use M/L headers and assign next fragment number to new link. o Draft specifies one anonymous bundle to be used in the case of no authentication and no EID provided. RK Hariram commented on the list that this would fail in the case of one system connected to two others. The consensus already had been to allow (multiple) manually configured bundles, but the draft did not actually say this. The draft should be changed to make this clear. Kevin Pierce's MP ISDN Modes Comment Kevin sent a longish note to the list asking for clarification of certain operating modes in PPP M/L. Some of the modes are problematic, and there seems to be no reason to include the discussion in the draft itself. Action: Keith and Kevin to correspond and settle issues. Dave Carrel: EAP Draft An EAP draft was posted too late to discuss at the IETF, and the relevant people were for the most part not present. Action: This will be taken to the list.