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

From: Ly Loi <[email-masked]>
Date: Fri, 26 May 2000 08:40:17 -0700

Skip, I was referring to the case where the LAC and the ipsec tunnel
initiator didn't reside on the same device:
LAC---gateway(ipsec tunnel initiator)---------------LNS(ipsec tunnel
terminator)

Is the draft supposed to cover this case too? This case would be considered
compulsory tunneling, ipsec tunneling :-)
If L2TP and IPSEC reside on the same device, then yes, we all agree IPSEC
would run in transport mode and I trust this will be stated in a future
version of the draft, thanks.

- Ly

-----Original Message-----
From: Skip Booth [mailto:[email-masked]]
Sent: Thursday, May 25, 2000 8:44 PM
To: Ly Loi
Cc: [email-masked]'; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: Comments/questions to l2tp over ipsec draft

On Thu, 25 May 2000, Ly Loi wrote:

> Bernard, thanks for the reply.
> Actually, ipsec in transport mode would apply only to voluntary tunneling.
> For compulsory tunneling, section 4.1 of RFC 2401 mandates that ipsec in
> tunnel mode be used since the L2TP pkts will be considered 'transiting
> traffic'. 

Not sure what you mean here.  L2TP packets, regardless of compulsory or
voluntary tunneling, are always locally originated/destined packets.  Thus
if
IPsec resides in the same device as the L2TP stack then it makes perfect
sense
to protect these packets using transport mode (and very little sense to use
tunnel mode, other than some of the NAT issues).

>  
> A note aside, compulsory tunneling would be another reason why L2TP and
> IPSEC shouldn't be tightly coupled. In compulsory tunneling, the L2TP
> initiator isn't on the same box as the IPSEC initiator.

When we are talking about L2TP security, yes it is.  The draft describes how
to
protect L2TP using IPSEC.  So in the compulsory case, IPsec protects all
L2TP
traffic between the LAC and the LNS.  L2TP is completely unaware of whether
the
PPP client being tunneld is using IPsec to protect the IP traffic.

>  
> Section 7.1 of the l2tp over ipsec draft states that one MUST use IPSEC
ESP
> for securing L2TP control pkts and SHOULD use it for L2TP data pkts. IPSEC
> policies cannot distinguish L2TP control pkts from L2TP data pkts,
therefore
> the negotiated IPSEC policies are shared by both control and data pkts. So
> how can we have a MUST for the control pkts but not a MUST for the data
> pkts? Why even suggest a distinction between control pkts and data pkts?

In the compulsory tunneling case, it might be very useful to protect just
the
control channel and not the data channel (especially in the event that the
client is already protecting its IP traffic using IPsec).  However, as you
mention IPsec has no mechanism for distinguishing between these traffic
types.
I think these statements may have been added with the foresight of either
L2TP
ADC or L2TP HC becoming a reality, and in that case, you could protect the
control channel differently than the data channel.

-Skip

>  
> Thanks,
>  
> - Ly
> 
>  -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Wednesday, May 24, 2000 7:07 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: 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 15:36:16 -0400 (EDT)

> compulsory tunneling, ipsec tunneling :-)

The draft discusses security concerns in the compulsory model.  Specifically, it
talks about how the link between the client and the LAC is potentially not
secure and that clients may require end to end security.  If the client is
running end to end security than potentially no encryption is required for L2TP
data packets between the LAC and LNS, but authentication may be.  As you noted
however, currently there is no way standardized method for IPsec to
differentiate between L2TP data and control packets.

Does the draft need to go into more detail in this area?  If so what more would
you like to be discussed?

Yes.

-Skip

> - Ly

[rest of text snipped]