PPP Extensions Working Group Minutes Monday, December 08, 1997, Tuesday, December 9th, 1997. Minutes - Matt Holdrege - matt@ascend.com Chair - Karl Fox - karl@Ascend.com The PPP Triple-DES Encryption Protocol (3DESE) Draft-ietf-pppext-3des-encrypt-00.txt Sent to IESG on Dec. 3rd. Informational RFC PPP over AAL5 draft-ietf-pppext-aal5-03.txt Draft Status Last Call until Dec. 10th Andy Malis and George Gross discussed LLC encapsulation. No resolution. PPP over FUNI draft-ietf-pppext-funi-03.txt Draft Status Last Call until Dec. 10th PPP LCP Extensions draft-ietf-pppext-lcpext-ds-02.txt Draft Status Sent to IESG PPP LCP CallBack draft-ietf-pppext-callback-ds-01.txt Call for Interoperability Experience PPP LCP Self Describing Padding draft-ietf-pppext-padding-ds-00.txt Call for Interoperability Experience No one has claimed to have implemented this protocol. Multi-link Multi-node PPP Draft-ietf-pppext-mmp-discovery-00.txt Gary Malkin - gmalkin@baynetworks.com Gary discussed certain points of his draft. Mechanism needed to randomize the bundle head. The point was brought up that different vendors handle LCP negotiation differently and remote peers may have difficulties. Security was brought up since a big denial of service hole exists. Packets need to be authenticated to prevent this. Multicast should be required for efficiency. IANA would need to issue a multicast number. Next CIUG Interoperability Workshop Week of February 23rd Anita Freeman - anfreema@cisco.com Park Plaza Motel - San Francisco Fee of $300 per person. EAP, CCP, BACP and L2TP will be tested. PPP Consistent Overhead Byte Stuffing (COBS) Draft-ietf-pppext-cobs-00.txt James Carlson - jcarlson@andr.ub.com Stuart Cheshire - cheshire@dsg.stanford.edu Stuart presented his draft. There are no intellectual property restrictions (patents) for COBS. L2TP MIB Draft-ietf-pppext-l2tp-mib-01.txt Pat Calhoun - pcalhoun@usr.com Pat presented his draft. L2TP Security Extensions for Non-IP networks Draft-ietf-pppext-l2tp-sec-02.txt Pat Calhoun - pcalhoun@usr.com Many changes were to simplify the implementation. L2TP Draft-ietf-pppext-l2tp-08.txt Mark Townsley - townsley@cisco.com Congestion Control will be clarified in draft -09 which will be out before the end of 1997. The next interoperability workshop in February will be based on draft -09. Should sequence numbers be MUST or SHOULD? Mark will put text in the next draft for MUST but allow for it to be administratively disabled. L2TP Header Compression Draft-ietf-pppext-l2tphc-00.txt Mark Townsley - townsley@cisco.com Mark described the draft and answered questions. L2TP Alternate Data Channel Draft-ietf-pppext-l2tpadc-00.txt Bill Palter - palter@cisco.com Bill presented his draft. Securing L2TP using IPSEC Draft-ietf-pppext-l2tp-security-00.txt Baiju Patel - baiju@ideal.jf.intel.com Baiju presented his draft. ISAKMP/Oakley for authentication and key management. IPSEC ESP for protection of traffic. Integrity using ESP with NULL encryption. Confidentiality using ESP with DES (or others). The objective is to provide adequate protection for L2TP control traffic. Integrity is MUST. Confidentiality is SHOULD. Provide protection for L2TP data traffic. Integrity is SHOULD. Confidentiality is MAY. For L2TP over non-IP networks, non-IP networks must transport packets. They must carry UDP packets of ISAKMP/Oakley in band or out of band (need to specify in media specific document). Carry ESP payload (no need for IP header). Next header of ESP is 0 (or we can require a new protocol type). In summary, one protocol for securing L2TP traffic over IP and non-IP networks. Proven solution. Must comply with this document to claim L2TP security requirement compliant implementation. Pat Calhoun said that Ipsec shouldn't be mandated for non-ip. Some questioned that this method is a proven solution. Bill Simpson said that null ESP may not be desirable. RTP Compression Carsten Borman - Steve Casner Changes suggested in Munich have been made. Minutes said request would be approved if no objections. They have a set of numbers to propose and are seeking approval. FULL_HEADER 0061 COMPRESSED_TCP 0063 COMPRESSED_NON_TCP 0065 COMPRESSED_UDP_8 0067 COMPRESSED_RTP_8 0069 COMPRESSED_TCP_NODELTA 8063 CONTEXT_STATE 8065 COMPRESSED_UDP_16 8067 COMPRESSED_RTP_16 8069 ISSLOW also requests LCP options, 25 Multilink Header Format (different from 18 as it has a parameter), 26 Prefix elision option I draft-ietf-issll-isslow-02.txt (In WG last call) PS draft-ietf-issll-isslow-mcml-02.txt (In WG last call) PS draft-ietf-issll-isslow-rtf-02.txt (to go to WG last call after IETF) Bill Simpson said to use the 8000 range rather than 2000. Craig Fox said that the 4000 range would be better to handle old code. 8000 range was the rough consensus. PPP EAP TLS Authentication Protocol draft-ietf-pppext-eaptls-02.txt Bernard Aboba Bernard discussed the draft. Bill said that EAP doesn't have a good match as a key negotiation protocol. Bill is against fragmentation here. This will be taken to the list. PPP with Framing Conversion draft-ietf-pppext-conversion-00.txt Bill Simpson This is to cover async/sync converters. Recommended to go forward as BCP. PPP in Frame Relay draft-ietf-pppext-framerelay-ds-00.txt Bill Simpson Same as RFC 1973 except it adds a reference to frame conversion. Need to get a list of implementers to advance to draft standard. Cisco and Ascend were noted as the only current implementers present. PPP in X.25 draft-ietf-pppext-x25-ds-00.txt Bill Simpson Simplification of wording in current RFC. Bill will ask on the list for implementations. PPP for Asynchronous PAD to Synchronous X.25 access draft-rfced-info-khana-01.txt Bill Simpson Bill said this work should fall under the domain of the ITU since it involves ITU numbers. Bill said details of PPP through PAD's should be handled as an appendix to the PPP in X.25 RFC. Bill also suggested that we submit this to the ITU Study Group 7. PPP EAP KEA Public Key Authentication Protocol Draft-ietf-pppext-eapkea-01.txt Jim Zmuda - jzmuda@spyrus.com Pat Calhoun raised a possible IBM patent issue. PPP Certificate Exchange Protocol Draft-ietf-pppext-crtxcgh-01.txt Jim Zmuda - jzmuda@spyrus.com Bernard asked why anyone would use EAP if they had this protocol. PPP Fortezza Encryption Encapsulation Protocol Draft-ietf-pppext-feep-01.txt Jim Zmuda - jzmuda@spyrus.com Fortezza is currently classified. Bill Simpson said that ISAKMP was originally designed for Fortezza and that we should use ISAKMP rather than Fortezza. Jim said he would look into it.