Subject: l2tpext minutes reformatted

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 05 Apr 2000 21:34:30 -0400

Reformatted to be 72 column friendly. A couple of small editorial
corrections included as well (e.g. Bernard still works for Microsoft,
yes?).

Thanks,

- Mark

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
OCRPBecause 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/Microsoft

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
SAs 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 will do 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 (for L2TP)? 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]