Subject: L2TPEXT Minutes

From: "David Allan" <[email-masked]>
Date: Wed, 5 Apr 2000 11:11:32 -0500

Any comments before I submit to ietf.org?

L2TPEXT Minutes for IETF 47

Chair:		Mark Townsley [email-masked]
Minutes: 	Dave Allan, [email-masked]

Draft-ietf-pppext-l2tp-atmext-01
Yves T'Jones/Alcatel
		Draft stable for quite some time. Yves provided a quick
review of the problem space. Extending incoming call procedures for ATM. 

		Q: What is the called number? Resolution is that use of
called number and service name needs to be more specific. 
		Q: What about adding VPI/VCI for where service name is not
available?
		Discussion focused around incoming call. Useful for
diagnostic reasons. To be added to the text.

		Changes: minor editorial changes, broadband bearer bits are
not a separate AVP. IANA type codes requested are in the IANA queue.
		Proposal do last call. Called number should be all zeros in
PVC case.

Draft ietf-pppext-l2tp-mpls-03
Pat Calhoun/Sun Microsystems

		Draft renamed for L2TPEXT

		Goal: How can two peers negotiate an LSPID.
		Document describes a new L2TP AVP 
		May be present in ICRQ, ICRP OCRQ and OCRP
		Because LSPs are unidirectional, can do both directions.
		Issue: There is discussion as whether the L2TP devices
should be inside or outside the MPLS network, If the latter, this may not be
useful.
		Suggestion: Put the LSPID in the result code.

		Consensus was group does not understand the utility or
appropriateness of this.
		George pointed out that DSCPs can be in the EXP bits, such
than a single LSPID was insufficient info to do diffserv.

Draft-ietf-pppext-l2tp-ds.02
		Provide an AVP to communicate DSCPs. All traffic for a
specific tunnel is bound to a specific DSCP. Permits per user class of
service differentiation in a tunnel. 

		Q: How does this work when there are user marked DSCPs? This
breaks the DS tunneling spec.

		What if it is PPP compressed or encrypted, is the LAC going
to pull everything apart to examine the DSCPs. Belief that there will be
tunnels across domain boundaries. 

		Resolution, add language to the draft, if compressed or
encrypted then use the session DSCP otherwise use the DSCP marking in the
session packets.

		Currently draft defines a vendor specific AVP. If people are
going to implement it, we'll get an IANA number.

		Q: Is this really a policy thing and DSCP is a bit too far
down.

		Q: Is this really a LAC/LNS thing or should there be a third
entity policy wise. In other words, is L2TP signaling not the right place
for this.

		It may be useful to allow something in the enterprise to do
a policy decision.

Draft-ietf-l2tpext-security-00
Bernard Aboba/UUNet

		Goal: Secure L2TP against threats to control channel and
data. Want to support floating source ports and IP addresses.

		Fragmentation issue: Addition of L2TP and IPSEC headers can
cause fragmentation. 
		Solution: Provide PPP with the MTU of ingress/egress
interface minus header overhead.
			- should occur after L2TP tunnel set up, before LCP
negotiation

		Teardown:
		IPSEC and PPP/L2TP teardown need to be coordinated.
		PPP: LCP term req/graceful else LCP keepalive for
non-graceful
		L2TP: StopCCN/graceful L2TP hello/non-graceful
		IKE/IPSEC SA: Once L2TP tunnel is deleted, then any phase 1
and phase 2 SA s should be deleted.
		Q: Why delete the phase 1 SA? Seems to be an arbitrary
linkage.
		A: OK, You may want to use it in the future. Not clear if an
LNS is aware of compulsory tunneling. Much discussion
		Suggested text to be posted to the list to resolve this
issue.

		Filter issues: 
		L2TP- implementations may use a dynamically assigned UDP
port.
		Address may change.
		Need IKE phase 1 and 2 to protect initial SCCRQ
		Then new IKE p1/2 to protect new SCCRQ on IP address
		New ike phase 2 for port number change.
		Filter Installation: L2TP needs to inject filters into the
IPSEC filter database.
		Certificate Handling: Cut to the chase. You are
authenticating a tunnel or PPP end point. How do you control the user base.
You can add PPP filters at the LNS.

		Q: A lot of effort put into running L2TP through a NAT. What
about IPSEC.
		Some things can be done if you turn off UDP checksum (which
you can configure with L2TP).

Draft-ietf-l2tpext-mib-00
Ross Wheeler/Wind River

	Has anyone implemented the recent draft....no!   anybody read it?

		Changes: detailed in the draft, mostly cosmetic
		Dave Thaler did the SNMP review.
		2 weeks to review then move to WG last call.
		Pat: Experience dictates that unless we put it directly to
WG last call, no comments will come.

		"It does compile by the way."

L2TP v2 draft discussion

		Proposed clarifications
		Recommend at least 16 octet tunnel auth challenge.
		When dropping out of order control packets, update Nr first.
		Zero should be send in the connect speed AVP if the speed is
indeterminable or no physical link.

		Pat: Call it something other than v2. Like "bis" or "son of
L2TP"

		More clarifications:
		Framing and bearer capabilities,
			Bearer for outgoing calls only.
			Do we need to be strict about framing capabilities
for incoming calls?
		SLI/ACCM race condition.
				Upon receipt of an SLI a LAC may apply a new
ACCM value before finishing tunneling LCP which if the client is strict on
ACCM, may lead to a non-converging race condition.
			Answer is SLI must traverse LAC-LNS-LAC before
applying it.
		Source IP address change
				Text is ambiguous as to whether this is
allowed. Some implementations currently change the source IP address of the
SCCRP based on local routing decisions.
		Current goals and milestones:
			Missed first two, may miss rest.
				Propose, may L2TP MIB, june L2TP security,
may L2TP over ATM and FR all to proposed standard. Dec 00, L2TP to draft
standard.

				Glen Zorn: we need 8 months? You have five
edits to do there. A: Want a bakeoff and implementation experience.;-)

		Current drafts:
				L2TP alternate data channel ADC, Securing
L2TP with IPSEC, SESINFO, ATM extensions, AAL5 and FUNI, Link Extensions,
header compression, diffserv, MPLS extension, MIB

Regards
Dave Allan

---------------------------------
Sr. Advisor Access Evolution
[email-masked]

---

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 05 Apr 2000 20:50:27 -0400

> Any comments before I submit to ietf.org?

Please do not send to ietf.org, this is the only list you need to
publish this to.

- Mark

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 06 Apr 2000 01:48:09 -0400

David,

You probably meant [email-masked], I misinterpreted this as
[email-masked] (which of course would be silly). I will forward them on
to [email-masked] if there are no objections.

Thanks,

- Mark