L2TP Extensions WG Washintgon D.C. Thursday, November 11, 1999 64 people signed the blue sheet. Chaired by Mark Townsley (townsley@cisco.com) Reported by Matt Holdrege (holdrege@lucent.com) Welcome to l2tpext and Agenda Bashing The agenda was accepted. Anita Freeman PPP/L2TP/IPsec Workshop announcement VPN Interoperability workshop announcement. Jan 9th 14th in San Diego. Bill Palter L2TP Alternate Data Channel draft-ietf-l2tpext-adc-02.txt The author asked if anyone cared if this draft was moved forward as an RFC. No comments. It was asked if there are any implementations of this protocol. There were none. Bill Palter L2TP Session Info draft-ietf-l2tpext-sesinfo-00.txt The author asked if anyone cared if this draft was moved forward as an RFC. No comments. This was compared with extending the bearer types and using bearer capability. We discussed the pros and cons without a clear resolution It was asked if this would affect dial-out. Could this draft be expanded to have the LNS choose the dial-out bearer type. This will be discussed further on the list. Andy Valencia L2TP Header Compression draft-ietf-valencia-l2tphc-00.txt The objective is to reduce the overhead within the header. It's not VJ-style, it's stateless and it's based on raw IP (not UDP). So you effectively have a 1 byte header. But that would only support one PPP session per tunnel. This model is generally for voluntary tunneling where there generally be only one session per tunnel. There aren't much savings in the general sense. There are some benefits for asymmetric data rate applications (TCP ack ratio). But RTP streams (as used in VoIP) over IPCP over L2TP may benefit significantly. It was mentioned that this scheme would be very useful when using L2TP over ATM over ADSL. Glen Zorn Securing L2TP Using IP Security draft-ietf-pppext-l2tp-security-05.txt Goals are interoperability. Specify parameters and modes for IPsec when used with L2TP. Advancement to proposed standard by February 2000. Proposed extensions to L2TP will not be considered. It is hoped this draft can be tested at the VPN bakeoff in January. L2TP has little or no security on it's own and it relies on Ipsec. The requirements are that we MUST be able to provide integrity and replay protections for control packets. You SHOULD provide confidentiality for control packets. You MUST provide integrity and replay protection of data packets. You SHOULD provide confidentiality for data packets. MUST implement ESP for control packets, and consequently you MUST implement ESP for securing L2TP data packets. All mandated cipher suites including NULL encryption MUST be supported. IKE is a MUST. Stateful PPP compression and encryption should be avoided over an IP network that might have packet loss. But they may work over a non-IP network such as ATM or Frame Relay. MUST use transport mode rather than tunnel mode. We need to take this to the list to see if anyone has a reason for using tunnel mode. L2TP needs to be able to now whether there is an IPsec SA protecting a given L2TP tunnel (thus, API's need to exist between L2TP and IPsec). There are many details in this draft that need to be sorted out between the L2TP WG and the IPsec WG. This will be taken to the list. Yves T'Joens L2TP ATM access network extensions draft-ietf-l2tpext-atmext-02.txt Complications during tunnel establishment phase were discussed. The author will propose a solution on the list. This draft maintains the broadband bearer bits. Introduces calling/called sub address handling Practically rewritten to match RFC 2661. The author was concerned about ATM devices which do not support F4 and F5 cells and cannot report a PVC down. He has proposed an LNS echo mechanism. People in the room said that both ATM and PPP have standards such as F4 and F5 cells and PPP LQM and they should be used. This issue will be taken to the list. Paolo Crivellari Paolo.Crivellari@alcatel.be Implementation feedback on L2TP over ATM Mark asked Paolo to work with Andy regarding L2TP header compression. Further work will take place on the list to cover efficiency considerations, header considerations, and specific recommendations for usage of L2TP over ATM. W. Mark Townlsey Status of l2tpext drafts L2TP over Frame Relay and ATM are still being worked on. The diff-serv and MPLS drafts need to see if they are still alive. Mobile PPP may move to the L2TP group. Secure Remote Access will be removed. The L2TP link info draft will be resubmitted into the L2TP WG. Draft authors that need IANA numbers will apply for them as soon as possible.