L2TPExt WG 15:30 2AUG00 Pittsburgh Chair: Mark Townsley Minute-taker: Dory Leifer Agenda Bashing No changes suggested to the prepared agenda VPN Bakeoff announcement San Diego bakeoff announcement was given by Mark in Anita's absence l2tp-bis-00 presented by Mark slides "l2tp-bis-00" presented: Ambiguity in bearer capabilities discovered in workshop and required clarification. - New codepoints may need to be assigned by IANA - Bearer-capabilities should only be used for dial-out - New "V" bit for virtual bearer - if no bits are set, it's something we don't know - Will followup at September workshop to see how well the "V" bit helps, it may come out draft-ietf-l2tpext-ppp-discinfo-00.txt Madhvi Verma, James Carlson, Rohit Verma Slides presented with Madhvi Verma - New proposed optional AVP in call disconnect - Can be sent by LAC or LNS - Motivated by lack of disconnection information - Disconnect code broken into 3 parts - Would be desirable to log AVP in RADIUS accounting message - Desire to move draft to proposed standard WG unpassionately agreed that the draft was useful. No additional comments. draft-ietf-l2tpext-l2tp-security-01.txt Presented by William Dixon - Would like to go to working group last call - Presented overview slides summarizing draft - MTU changes are possible and observed - Highlighted issue Filter proposed in IKE Quick Mode ProxyID (establish and rekey) - Filter that is property of IPSEC SA - post decrypt check to be sure received traffic is what was expected for SA (useful for NAT) - Issue from list: teardown slide "teardown" presented - Need to coordinate IPSEC state after teardown - Certificate Handling - Separate users from machines- WG discussion: - User credentials may need to be prompted but is implementation specific but not part of the protocol - Question about xoff, inconfig - not addressed by this draft - Using standard IPSEC transport mode to secure L2TP - Using user credential is better than using machine credential - Certs dont know if they are machine or user - its a matter of policy to decide which is acceptable - This is typically only a problem from a client - How should the draft be worded "MUST accept machine credentials?" Zorn: customers do see the difference between the two cases referenced in "question" on certificate handling. WG consenus is that it is a matter of local policy if machine or user cert (and MAY is ok) Mark: ready for last call? Steve Belovin has reportedly determined that there may be security problems but nobody has seen them posted Would be nice to see this to see if we can improve the security Mark L2TP MIB last call on May 31st atmext - 03 ready for last call l2tphc - significant changes Andy posted another draft - no comments on list - ready for Last Call sessinfo - 01 ready for last call linkinfo - needs resubmission - nice thing to have but have not seen interest. - Mark may resubmit - someone says nice to have also adc - stalled diffserv - Ken plans to resubmit with changes Suhail Nanji took over Rene Tio's draft on atm - ready for last call there We're not going to talk about L2TP/IPsec NAT because has been presented in two other working groups already. Time 16:30 -------------------------------- Ethernet over L2TP draft-nanji-l2tp-eth-00.txt Suhail Nanji Tunnel should be able to support PPP and eth over L2TP ppp/pppoe/802.3/l2tp (two other configurations) Explained motivation in slide "PPPoE with Ethernet over L2TP" - Need to carry the PPPoE traffic - Doesn't seem useful for voluntary but Ross pointed out you can use PPPoe and L2tp on the same client - There are other alternative for doing the tunneling - There is a standard way to do this with BCP - why not. - Issue with MTU and with mixed non-ethernet media where MAC address has different ordering. -------------------------------- l2tp Circuit Emulation Services (CES) Extension draft-mcpherson-l2tp-es-01.txt Danny McPherson Slides presented Motivation payload may be other frame services (???) Service type AVP may be needed Goal provide IP-based circuit emulation services Jim Boyle is presenting STS services over IP and RTP definition. They don't specify IP tunneling protocol. It is preferable to use L2TP vs. GRE because of session aggregation and call setup (signaling) Tunnel frame relay over IP infrastructure GRE does support multiple sessions in single tunnel. Argument about the above and current deposition of GRE RFC and key/sequence field More discussion about whether GRE or L2TP is better for this application Discussion about RTP, GRE, MPLS L2TP work over MPLS is still ongoing and could be useful to the applications. Boyle's draft explains service provider specifics over IP (will post reference to the list) Doesn't RTP give you what you want? L2TP provides RTP and the signaling information (may need to exchange circuit parameters like low-layer framing[??]) Why not use a PPP NCP? Scalability could be a problem If there is interest may come up with applicability statement What should the working group do? The products are coming out. Do we want to open L2TP to protocols other than PPP? The CES is way beyond the scope of this working group. Maybe there should be a CES working group? Signaling mechanisms could be used with RTP but "seemed heavy". Plan to publish an informational document describing Danny's implementation. Mark asks "this is how you transport things other than PPP over L2TP" should we take that on in this working group? Other protocols could use AVP for service-specific items This is better done inside RTP or protocol carried inside L2TP - just need a single AVP Glen asked who else is doing this or is going to do this? Maybe Redback but that is for something else. 3 vendors are at least interested now Debating if should go to bakeoff ethernet over L2TP Glen suggests that both parties create a single draft Need to bound to changes to call setup AVP Mark asked if reasonable for us to take on service-type AVP on call setup and handle non-ppp frames Will try to get consensus from the list Charter will need to get modified Should this be informational on the first pass. Glen says he would like it "vendor-specific standards track" if there is sufficient interest, it can progress Meeting end 17:30 None of the below talked about. draft-adoba-nat-ipsec-01.txt Bernard Aboba, et al WG draft status draft-ietf-l2tpext-fr-00.txt draft-ietf-l2tpext-l2tp-atm-01.txt Suhail Nanji