Subject: [L2tpext] Draft l2tpext minutes

From: "W. Mark Townsley" <[email-masked]>
Date: Wed, 19 Dec 2001 23:57:55 -0500

Please submit any inaccuracies ASAP. Of note, are incorrect or incomplete names
on some comments. It is often very difficult to understand the mumbling of one's
name at the microphone, so the poor minute-taker had to guess or use
descriptions at times. Feel free to respond and say, "That was me!" (privately
or publicly).

Thanks,

- Mark

L2TP Extensions Working Group
Minutes of the 52th IETF meeting, Salt Lake City
1:00 PM, December 11, 2001

Mark reviewed the agenda.

Mark reviewed the drafts.

General questions:

- Elwin asked about the use of vague AVPs in the IETF space. Specifically, the
use of the Sub Address AVP in the Diff Serv draft. Mark answered ... (something
I didn't write down).

- William Dixon asked for a poll on who is using L2TP for remote access. A
handful of hands were raised.
William urged the group to check out IPSRA requirements to see if L2TP is
getting a fair assessment. He reported that current documents in IPSRA suggest
that the PPP/L2TP/IPsec solution was "not secure".

Vipin Jain: Fail-over

- Alexander asked about fail-over proposals in other protocols and how they
relate to the L2TP proposal. 
Vipin replied that one distinction is that other protocols try to notify the
peer that a failure is about to happen. The L2TP proposal is unplanned
fail-over. Mark pointed out that the volatile Nr/Ns state is hard to keep on hot
standby.

- Pat Calhoun asked about spoofing possibilities. Vipin replied that local and
remote tunnel ID were included to annoy the spoofers with 16 extra bits.

- Some discussion ensued about IPsec - is it addressed, how would you deal with
failover at that layer. William suggested setting up an SA with the hot standby.
Pat says a peer would have to know the address of the standby in advance.[?]
Ignacio Goyret emphasized that only the primary and the standby know about each
other. The peer does not have a-priori knowledge of the standby. Sense of the
room was to accept this draft as a WG document.

Elwin Eliazer: PPVPN extensions to L2TP

- Mark acknowledged that the work is on the fringe of the charter.

- Reinaldo Penno said it is a good idea but that the MPLS point is
over-simplified as it brings other things to the table. He expressed worry about
tunnel explosion.

- [Man in suit] alluded to a draft that sunk because it was tied to MPLS. He
really liked this proposal.

- [Asian guy in cranberry polo] emphasized the security difference between L2TP
and IPsec. He was 
reminded that IPsec is the sanctioned solution for L2TP security.

- Greg Burns asked if draft was targeting L2 or L3VPNs. Elwin replied either or
both.

Elwin Eliazer:  IP Services

- Vipin asked why proposed information exchange is not in the session
establishment messages themselves (as opposed to the proposed notification
messages) and noted that early packets might not be secured. Elwin answered that
you might not have identified the user at session setup time.

- Mark cautioned that the draft is 00, has a lot of stuff, some new, some
recycled ideas, and probably should be split into multiple drafts.

Mark Townsley:  L2TPv3

- Vipin asked Why is the tunnel ID not in the header? Mark explained that the 32
bit session ID on the data plane covers the combined session/tunnel space from
the control plane.

- Tom Mistrella[sp?] expressed happiness that v2/v3 auto-discovery was covered.

Vipin Jain:  Tunnel Switching

- no comments

Ignacio Goyret:  V.92 Modem On-Hold Signaling on L2TP

- Mark said he would like to see recommendations for LNS behaviour. Pat also
wondered what an LNS should do?  Buffer or drop?  What's the point of buffering?
Ignacio replied that the LNS might stop sending PPP echoreqs. He added that
another use might be for accounting - don't pay while on hold.

- Vipin Jain stated that the client behaviour is unpredictable vis-a-vis
timeouts. Ignacio responded that the client modem (V.92) knows it is on hold.

- Sense of the room is that this draft will become a WG document.

Mark Townsley:  PPP tunneling using L2TPv3

- no comments

Ron da Silva:  PPPoE Relay

- Reinaldo stated that the draft monkeys around too much with PPPoE. There is no
MAC address visibility to LNS, needed when an LNS that applies policy based on
MAC address. 

- Mark responded that the charter covers integration with other PPP tunneling
protocols. 

- Renaldo replied that we are not allowed to change the Relay Session ID. 

- Ross Wheeler stated that the PPPoE RFC is vague about changing the RSI. 

- Renaldo expressed his preference for an L2TP-only solution with no assumptions
on PPPoE. 

- Thomas [?] pointed out that policy decisions on the LAC will result in very
different behaviours among implementations.  E.g.  Will LAC relay to one LNS or
all of them? He suggested implementations should be configurable to select among
defined behaviours.

- Thomas asked if state machines would be included/revised in the draft.

_______________________________________________
L2tpext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2tpext