Subject: L2TP Minutes from VPN interoperability workshop town meeting

From: "W. Mark Townsley" <[email-masked]>
Date: Sun, 16 Jan 2000 22:44:44 -0500

In general, L2TP interoperability was quite good. There are some issues 
for clarification:

Recommend at least 16 byte challenge in tunnel authentication

No one admitted to using Proxy LCP Initial Confreq AVP to change PPP
behavior now. 

When dropping out of order packets, it is a good idea to update Nr
first.

There was some question about whether or not to send a StopCCN when
Tunnel Authentication fails. Recommendation is to send the StopCCN.

Meaning of Framing Capabilities needs some clarification when sent from
an LNS that does not have any physical interfaces available for dialout.
The RFC currently makes a general statement disallowing any bit in the
Framing or Bearer Type AVPs to be set if the corresponding bit is not
set in the Capabilities AVP advertised by a peer. For outgoing calls
this makes good sense as framing is performed at the physical PPP link
connection point. For incoming calls, it does not make sense to be so
strict as, at best, the Framing Type is used to decide whether or not to
negotiate PPP options such as ACCM. While it may be important to dictate
whether or not to negotiate such link options, it is a bit strict to not
allow the call to even be placed.

It was noted that liberal implementations currently ignore the Framing
Capabilities AVP from an LNS when placing an incoming call request. Some
more strict implementations will not allow the call to be placed if the
corresponding bit is not set. The former promotes better
interoperability. In order to work with the more strict implementations,
it would be best for the LNS to always set both framing capabilities
bits.

The crux of the problem is that the text regarding the framing
capacities advertisement is overloaded for dialin and dialout.

Voluntary tunneling is even more confusing here as there is really no
physical connection point.

More clarification is necessary here. We will solicit opinions on what
is necessary now and for future extension.

Text will be clarified to allow only one bit to be set in the Framing
type and Bearer type AVPs.

SLI/ACCM race condition
Upon receipt of an SLI, an LAC might apply a new ACCM value before it
finishes tunneling LCP packets to the PPP client. If the PPP client is
strict about ACCM (as some are), the LCP packet could be dropped due to
invalid escaping, causing PPP negotiation to never converge.

Proposed fix for the SLI/ACCM race condition:
An SLI that is not clearing any ACCM bits at the LAC can always be
immediately applied If an SLI is received that will clear any ACCM bits,
the LAC goes into ACCM Pending state.  It sniffs all outgoing packets
until it sees a packet (from the LNS) with a Protocol ID less than
0xC000. LCP and the authentication protocols are all greater than
0xC000. Likewise, all of the NCPs and data protocols are less than
0xC000. Thus a packet with a Protocol ID less than 0xC000 indicates that
LCP is Open at both ends of the connection. At this point, the new ACCM
mask may be applied

Noted that we should still allow the source address to float during
tunnel setup. Need to pass this by the IESG. 

L2TP+IPSec

Skip Booth of cisco gave a presentation on IKE negotiation with L2TP, 
particularly in light of UDP port and IP address changes during L2TP 
tunnel establishment. 

Not a lot of comment as this was a lot to digest in this short meeting. 
Authors of draft-ietf-l2tp-security have agreed on this proposal and it 
will be included in the next rev of the draft to be posted shortly. 
Request was made to have the IPSec WG review what we are proposing. 
Further, this behavior is not unique to L2TP, there are other protocols 
which float UDP ports and the like which would exhibit the same
problems. 
Could this be handled more generically in IKE?