NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
W. Mark Townsley <townsley@cisco.com>
Internet Area Director(s):
Thomas Narten <narten@raleigh.ibm.com>
Erik Nordmark <nordmark@eng.sun.com>
Internet Area Advisor:
Thomas Narten <narten@raleigh.ibm.com>
Mailing Lists:
General Discussion:l2tp@ipsec.org
To Subscribe: l2tp-request@ipsec.org
Archive: http://www.ipsec.org/email/l2tp/
Description of Working Group:
The Layer 2 Tunneling Protocol (L2TP), defined in RFC2661 (http://www.ietf.org/rfc/rfc2661.txt) is a protocol for tunneling PPP (RFC 1661) sessions over various network types. The group will provide a forum for discussion and development of extensions to L2TP, and actively advance the L2TP base protocol to Internet Standard.
The group will:
Define and advance standard MIB for L2TP management.
Produce documents describing how L2TP operates over link types other than IP (e.g., ATM, Frame Relay, etc.)
Identify and define specific parameters and modes of IPsec in order to aid interoperability when IPsec is used to secure L2TP traffic.
Define and review the definition of any additional IETF AVPs which are of interest to the group.
Goals and Milestones:
Oct 99 |
|
Advance L2TP MIB to Proposed Standard |
Feb 00 |
|
Advance L2TP Security to Proposed Standard |
May 00 |
|
Advance L2TP over ATM and Frame Relay to Proposed Standard |
Sep 00 |
|
Advance L2TP to Draft Standard |
Internet-Drafts:
· L2TP Session Information (``SESINFO'')
· Layer Two Tunnelling Protocol : ATM access network extensions.
· L2TP Header Compression ('L2TPHC')
· Layer Two Tunneling Protocol 'L2TP' IP Differentiated Services Extension
· Layer Two Tunneling Protocol 'L2TP' Multi-Protocol Label Switching Extension
· Layer Two Tunneling Protocol 'L2TP' Management Information Base
· L2TP Disconnect Cause Information
No Request For Comments
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.
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
None received.