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

From: Ly Loi <[email-masked]>
Date: Thu, 25 May 2000 18:07:52 -0700

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'. 
 
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.
 
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? 
 
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: Thu, 25 May 2000 23:44:23 -0400 (EDT)

> tunnel mode be used since the L2TP pkts will be considered 'transiting

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).

> 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.

> 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