CURRENT MEETING REPORT Minutes of the Point-to-Point Protocol Extensions (pppext) Reported by Fred Baker, Cisco Systems We are forwarding a variance request for CCP/ECP that indicates that we will accept Motorola's letter of intent on these and advance these documents. Frank has posted an Internet Draft of the variance to this end. There will be an extended last call to consider this, going into January. We should expect acceptance of the existing CCP/ECP documents for Proposed Standard status in February. Motorola's letter of intent states that Motorola will license the use of its patents to all who apply for reasonable terms. The problem in the variance proposal is the dependence on Motorola carrying out its promise to reasonably license its patents. Vendors who deal with Motorola should report their experience to the PPP list as a test of this, as this report will be considered in taking the CCP and ECP to Draft Standard. IPCP Update to Draft Standard (Pall) draft-ietf-pppext-ipcp- network-00.txt Update to the IPCP left some ambiguity in RFC 1332. This draft primarily clarifies RFC 1332 without adding new features. Option 3 (IP address negotiation) is at issue. Announcing an IP Address Peer announces IP Address; you may: o Ack the address o Nak with a different (non-zero) address o Reject the option (in effect accepting the address) Peer requests 0.0.0.0; you may o Nak with an address, assigning that address o Reject the option (saying the link is unnumbered) In addition, please add text to say that folks should not Ack this packet. Peer requests with no option; you may o Say nothing in the Ack o Nak 0.0.0.0; Ack with their own address or router ID. This permits the system to ask its neighbor what its router ID is. It was agreed that a note will be added pointing to other IP options, such as the address of the DNS server. Those which may be negotiated should use the DHCP INFORM option. Updates to Draft Standard (Simpson) o draft-ietf-pppext-chap-ds-00.txt o draft-ietf-pppext-lqm-ds-00.txt We are going to draft standard on these two, and these drafts are clarification edits. Implementors of these protocols are requested to send a note to the chair identifying their CHAP implementations, and say with whom they have tested interoperability. US Robotics, Compatible Systems, Cisco, Bay Networks, Xyplex, and 3COM have done LQM implementations, but need an interoperability test. LCP Extensions o Endpoint ID (Xyplex, Cisco, Network Systems): This is a go. o Callback (Compatible, Cisco, Combinet, Digiboard): This needs further updates for time before callback occurs. We also need to discuss the option on the list o Compound Frames: Let's drop this extension. o Multiple FCS: Let's drop this extension o Self Describing Pad: SGI? Multilink: (Sklower) o draft-ietf-pppext-des-multi-12.txt There have been clarifying updates, requiring no operational changes. Discussion of those edits will have to happen on the list, however. Ascend MP+ There was a general consensus in the room that proposals made to incorporate features from Ascend MP+ (which has advocates) should not hold up revision and republishing of the Multilink Specification; rather that these features should become additional control protocols that might be useful on any dial line and not just a multilink dial line. Multilink should target any line group, not specifically dial or ISDN lines or any other specific line type. Craig Richards (Shiva) will post a draft describing new control protocols to implement the functionality of Ascend MP+. This will differ from Ascend's proprietary implementation. EAP Authentication: (Blunk et al) o draft-ietf-pppext-eap-auth-01.txt MD5 is the default authentication approach for EAP, and various updates have been made per comments from Stockholm. One issue raised there was the user interface definition in the specification, which was too much. This was entirely removed in the current draft, and that appears to be too much. The right level is a hint that says that the password is a secret or something else, and therefore should or should not be echoed. Token Card Type is debated; it may not be useful. Network Express and Soliton Systems have implemented the RSA implementation and interoperate. Dave Carrel mentioned mutual authentication; there is a "man in the middle" attack possible in CHAP, which would be obviated by one peer requiring that the other peer also authenticate him. This is relevant to Kerberos 5, which includes an IP Address in the credential. One suggestion is to deal with this by using timing and challenges subsequent to the authentication phase. Another suggestion is that when A receives an LCP request from B which does not require authentication and wants mutual authentication, it could LCP Nak with an authentication option on the LCP Nak. o draft-ietf-pppext-eaprsa-00.txt Bill Whelan RSA Type 9 Public Key Authentication proposal, using the ISO X.509 certificate. Network Express and Soliton Systems have implemented the RSA implementation and interoperate. Certificate format appears to be problematic. The certificate needs a type, preferably a well-known type, that is revocable and is available to anyone with an RSA license and/or internet access. The issue here is the purchase of ISO X.509. Alternative Compression Proposal (Mader) o draft-ietf-pppext-wcp-00.txt Bay Networks Compression Protocol is a lightweight reliable compression protocol. The issue is the perceived heaviness of LAPB. Given the variance on CCP, it is not clear that this fills a real need, but it has many good ideas. Keith will confer with Dave Rand on a follow- on to CCP with the additional options. He continues to believe that WCP itself should become a standard protocol, and is invited to make that case on the list. LZS-DCP Compression (Schneider, Friend) o draft-ietf-pppext-lzs-dcp-01.txt Add a bit to support moving the check field to the end of the packet, as used by Stac's new hardware. Option 23 padding - this should be done using self describing pad if padding is required. This was taken to the list. PPP/FR and the Data Encapsulation Draft A lunch meeting was held to discuss the future of these drafts, which was attended by Keith Sklower, Keith Mader, Bill Simpson, Joel Halpern, Andy Malis, Fred Baker, and Frank Kastenholtz. We agreed that the basis of discussion should be a set of criteria. The criteria we chose were: Both drafts should be advanced as Proposed Standard if and only if they had clearly differentiated applicability-if there were two or more different problems and neither approach solved all of them. Since the Frame Relay Forum has its own compression/encryption specification, one or both should advance to Proposed Standard if and only if additional PPP features are in view. There has been an assertion that Data Encapsulation is the preferable approach because it preserves the same data encapsulation. Implementation experience is a guide to determining whether vendors feel that this is a real issue. We observed that three vendors, Xyplex and two unnamed vendors, have implementations or implementations in progress of PPP/FR, and no vendor has indicated plans to implement Data Encapsulation. Therefore, we determined that preservation of the data encapsulation is not a vendor concern. We also noted that Authentication has always been mentioned as a reason for parameter negotiation, and that some vendors already implement Van Jacobsen Header Compression on Frame Relay. Therefore, there is additional purpose. We also note that all vendors present report market demand, and that this demand specifically references PPP/FR. We could not identify a set of applications where one would clearly prefer Data Encapsulation given that PPP/FR was implemented. Therefore, the consensus reached was that PPP/FR should advance with all due haste to Proposed Standard, and that Joel and Keith Mader would discuss the possible need for Data Encapsulation, and would be free to publish it as an experimental RFC if they so choose.