PPPEXT WG Chicago, IL Chair: Karl Fox Reported by: Matt Holdrege Day One, August 25th 1998 Anita Freeman (afreema@cisco.com) spoke on the next interoperability workshop covering IPSEC, IKE, L2TP and L2TP with IPSEC. It's in Binghamton,cNew York on October 27-30 and announcements have been sent to the list. Mark Townsley (townsley@cisco.com) and Bill Palter (palter@network-alchemy.com) gave an L2TP update. L2TP is not yet at Proposed Standard. The IESG is reviewing the standard and there will be a draft -12. The IESG is concerned with security and reserved numbers for IANA. IANA needs new section listing what numbers IANA should be concerned about 20 An IETF approved document must exist for the numbers to be assigned by IANA. For security, the floating IP address is an issue. The IESG says that the security threats outweigh the potential benefits. Text stating that an implementation MUST always respond to the source IP address will be removed. It was noted that if you use IPSEC, the problem with changing IP addresses is no longer a concern. It was asked whether IPSEC should be mandatory for L2TP, but the WG did not agree to do that. In congruence with no floating IP address, the UDP port will also remain fixed after tunnel establishment. In keeping with the TFTP model, the following exchanged is still permissible (x and y can be any port number, including 1701): =E0 SCCRQ (src=3Dx,dest=3D1701) =DF SCCRP (src=3Dy, dest=3Dx) =E0SCCCN (src=3Dx,dest=3Dy) The IESG is worried about NAT and firewalls with this arrangement. There was some discussion and it was resolved that we would take it to the list. Paolo Crivellari =20 draft-alcatel-pppext-l2tp-atmext-00.txt This is a draft for L2TP access over ATM over media such as XDSL. The LAC performs bridging of a PPP session between AAL5 and L2TP transport. A generic packet based network would connect the LAC and LNS. They need to add two extra bits to identify non-HDLC access network types. The other bit is to identify Broadband bearer capabilities. This is under the framing type AVP and the bearer type AVP Also a minimum bit per second upstream AVP and a maximum bit per second upstream AVP are needed. An ATM cause code AVP is needed to determine failure conditions. And the dial number AVP should be binary encoded. A Maximum Receive Unit AVP is also added. Bill Simpson covered the following drafts draft-ietf-pppext-lcpext-ds-03.txt draft-ietf-pppext-callback-ds-02.txt draft-ietf-pppext-padding-ds-01.txt draft-ietf-pppext-conversion-01.txt draft-ietf-pppext-framerelay-ds-01.txt draft-ietf-pppext-x25-ds-01.txt draft-ietf-pppext-ether-00.txt Bill said the first six of these drafts had expired and he wanted the IESG to put them forward. The LCP extensions draft had some comments from the IESG which Bill added to a new draft. SDP has zero implementations because it slows negotiation and because hardware doesn't appear to exist anymore that requires it. Bill said that other protocols refer to SDP. But he thinks it should be put out as proposed standard so people can use it in the future. PPP Framing conversion is waiting for the chair to forward the draft. PPP in Frame Relay has multiple implementations. The chair and AD's will check up on the status. PPP in X.25 hasn't been implemented much. Bill asked if anyone cared about this protocol. Someone said yes it is useful. Thomas Narten said to either advance it or make it historic. It is also referenced in the AO/DI protocol. PPP in Ether-like framing is new. The motivation behind this draft is to provide something simpler than HDLC for high-speed networks. Everything is on 32-bit boundaries to make it easier to implement in hardware. Bill wants this to go to proposed standard. Karl asked if this should go to ANSI since it seems to be about framing over Sonet. Lucent noted that hardware framers at OC-48 exist today. Rollins Turner rturner@eng.paradyne.com L2TP over ATM Draft-ietf-pppext-l2tp-atm-00.txt Based on RFC 1483. How to use ATM for the link between LAC and LNS. The draft suggests supporting large MTU's such as 9180 and the authors are looking for suggestions. QoS is an implementation decision. Two encapsulation methods, LLC and VC Mux. Method negotiated on SVC setup and pre-configured for PVC's. SVC signaling is based on RFC 2364. A BLLI IE specified by originators the desired encapulation. For detecting and recovering from unsolicited L2TP encaps transitions, LLC encapsulated frames always begin with a fixed 8 byte sequence. Upon change in encaps, tear down tunnel or if SVC terminate connection.=20 It was noted that this draft shouldn't reference a byte position but should follow the L2TP spec. It was asked what would happen if an intermediate ATM switch uses EPD or PPD. The author didn't see how this is different from L2TP over IP, but he would look into it. It was noted that RFC 1483 has been updated and it should be examined. Day 2 August, 26th 1998 Evan Caves L2TP MIB Draft-ietf-pppext-l2tp-mib-02.txt The changes from -01 include: - Added tunnel domain group (optional) - Removed redundant objects - More consistent object names - L2TP notifications - Removed UDP configuration table - Updated MIB relationships section Still to be done: - Update L2TP UDP stats table - Add shared secret to tunnel (and domain?) config tables - Finalize indexing session table This will be taken back to the list and updated over the next few weeks and then move to WG last call. Glen Zorn LCP Internationalization Config Option draft-ietf-pppext-charset-02.txt New LCP option has character set and language specification. It uses an enumerated value of updated country codes, but allows a string value for new languages. Glen Zorn MS-CHAP v2 This is the first public discussion of MS-CHAP v2 and it will result in a forthcoming draft. Features: - Mutual authentication - Asymmetric keying - Defeat of pre-computed dictionary attacks. - New algorithm number of 0x81 from IANA - 16 octet challenges - Peer challenge in response Authenticator authenticator in the success packet which is 40 hex digits in ASCII. It's ASCII so it could be printable in an error message. New password change protocol. It has a peer challenge in password change request. Auth Auth in success packet. The MPPE key derivation method is different. It's based on an NT password hash with master send/receive keys. Keys are changed on every packet. There should be a new Radius attribute to differentiate between MS-CHAP v1 and v2. Bill Simpson PPP over Sonet This adds ATM style payload scrambling and a draft ITU-T PPP indicator value of 0x16. 0x17 is reserved in the draft for ppp in etherlike framing which is another draft. For OC-48 and above, the default framing is etherlike. Below OC-48 can use octet stuffing and scrambling. The group debated whether to specify etherlike framing or HDLC for OC-48+. Most people in the room who had direct interest preferred HDLC. At least a couple of people wanted the option of using an alternative like etherlike framing if it becomes standardized. It was noted that this draft should coordinate with MPLS over PPP/Sonet to specify the location of the shim. Several questions and comments related to Sonet/SDH were made and commentators were urged to take their comments and questions to the main PPP list. Bill's goal is to resolve the Sonet and SDH interoperability issues. Others said that all we should do is document our issues with Sonet/SDH interoperability and that it is up to other forums to resolve the interoperability issues.