Subject: RE: Comments/questions to l2tp over ipsec draft

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 24 May 2000 07:07:03 -0700

FW: Comments/questions to l2tp over ipsec draft > 1. I think sometimes L2TP
is unnecessarily tightly coupled with IPSEC.

  We discussed this during the L2TPEXT WG meeting in Adelaide and

  I believe we came to the same conclusion.

   > If the L2TP tunnel goes down, there wouldn't be anymore L2TP traffic on
that
   > IPSEC SA. IPSEC will detect such idleness through some idle timer and
bring
   > down that SA or its SA lifetime will eventually expire (the idle timer
is of
   > course more efficient).

  The concern was about leaving lots of zombie IPSEC SAs on the LNS.

  I think that the idle timer idea handles this though.

   > In other words, we don't need L2TP and IPSEC to communicate with one
another
   > when either one goes down.

  I agree that this is not a requirement. Should we change

  the language in the draft to MAY?

   > Can't the initiator have "src Any-Port" in its outbound-1 filter?

  This would mean that the client would *always* speak IPSEC

  to the LNS, on any port. It is simpler, as you state. Can anyone

  think of a scenario in which this would cause problems?

   > 2. Sections 9.2.x. Could you rename the word "filter" to "security
policy"
   > or "IPSEC policy"?

  Yes. This language would be clearer.

   > 3. Definition of "Voluntary Tunneling".
   > Why is the "gateway to gateway scenario" considered voluntary
tunneling?
   > Shouldn't it be compulsory tunneling?

  I think it should be considered compulsory tunneling, yes.

   > 4. Does L2TP really allow a responder to select any IP addr?

  Yes.

  > Do you know of any vendors doing it?

  Not at the moment.

   > Also, what would their reasons be?

  To support load balancing between LNSes?

   > I guess not using 1701 as the port is also unusual, isn't it?

  There are vendors who float the LNS port, though I think it is

  fair to say they are in the minority. Floating the client source

  port is quite common (though Windows 2000 doesn't do this).

   > For load balancing, if the IP addresses are different, you would end
   > up with more than one IKE phase 1, won't you?

  Yes.

  > So I don't see why the L2TP IP addr changing is related to load
balancing.

  Perhaps someone who is using this or intends to do so could explain the
utility?

   > 6. How come the draft doesn't require that IPSEC in transport mode be
used
   > (unless i missed it)? It's probably worth mentioning for
interoperability.

  This is indeed required, though the words "transport mode" are not used in

  the draft. I agree that it is probably worth mentioning.

   > 7. Section 9.2.3. Why not disallow the responder from modifying an IP
   > address when running L2TP over IPSEC? How about treating this as a
   > misconfiguration? If we rarely run into such situation, it may not be
worth
   > supporting some IP addr change detection, dynamically manipulating the
IPSEC
   > filters, etc.

   I'll leave it to those who feel they need this feature to respond.

---

From: Skip Booth <[email-masked]>
Date: Fri, 26 May 2000 00:10:26 -0400 (EDT)

Responses inline.

>   I think that the idle timer idea handles this though.

The idle timer is not anything which is standardized and it should not be
assumed that an implementation has such a mechanism within IPsec.  In the remote
access space where you are terminating lots of voluntary tunnels, I believe it
is very useful to teardown the phase 2 SA after receiving notification from
either L2TP that the L2TP tunnel no longer exists.  If you don't you this
mechanism than you leave dangling SA's until you try to perform a refresh.  If
your refresh time is long than the amount of Phase 2 SA's sitting around could
conceivably become very large, especially when the traditional model for remote
access has been relatively short connect times.  In my mind, this is clearly an
area where L2TP/PPP add value to the current IPsec and IKE specifications.

>   the language in the draft to MAY?

I could live with a MAY, however I really prefer a SHOULD.  Is there a
convincing argument why we wouldn't want to make this a SHOULD?

>   think of a scenario in which this would cause problems?

The reason this was a specific port is to handle the case where the responder
(i.e. LNS), choose to float it's port.  In this case, a new phase 2 will start
from the LNS to the LAC and the LAC must be prepared to accept the quick mode
id's proposed.  In this case, I don't think it's wise for the LAC to have a
responder filter of ANY for it's dest port.  This should be the specific port
that was chosen by the LAC as it's source port for the L2TP Tunnel.

>   I think it should be considered compulsory tunneling, yes.

I always referred to L2TP gateway to gateway tunneling as voluntary tunneling
because the PPP stack and the L2TP stack reside in the same device.  This seems
to me almost the same paradigm as the client to gateway case.  Why would you use
the term compulsory to describe this scenario.

>   Perhaps someone who is using this or intends to do so could explain the

For instance, I may want a different LNS to terminate the tunnel.  In the
STOPCCN, the LNS has the ability to propose an alternate address (in the result
and error code AVP, "try another").  This alternate address could be the address
of a less-utilized LNS.

>   the draft. I agree that it is probably worth mentioning.

Yes.  We also need to add a section on what are the requirements to run
L2TP/IPsec through a NAT.  This all should make it into the next rev of the
draft.

>    I'll leave it to those who feel they need this feature to respond.

It can be removed at the expense of having to solve this problem at some future
point.  I think this could be a very nice feature for L2TP, and I feel we should
build in support for this now and not later.  This is a MAY to start with, so if
you don't support it, that's fine.  But at least there is a documented mechanism
for how this should be done.  If this never gets implemented then assuming we
make it to proposed standard we can remove this before moving to draft standard.

-Skip