Subject: Minutes from 48th IETF l2tpext WG meeting

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 04 Aug 2000 18:22:44 -0400

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

---

From: Danny McPherson <[email-masked]>
Date: Fri, 04 Aug 2000 20:51:16 -0600

References to the two drafts related to IP CES stuff that I mentioned during the WG session are provided below.  Both are available via the IETF ftp server.

draft-boyle-sts-ip-00.txt
draft-white-sonet-format-rtp-00.txt

-danny