Subject: RE: Question on draft-ietf-l2tpext-security-02.txt

From: "Chen, David" <[email-masked]>
Date: Fri, 25 May 2001 10:01:25 -0400

From L2tp's view seems no difference using IPSec Tunnel mode or Transport
mode for
security. 
The transport mode is chosen for l2tp due to its less header.

For non-tunneling packets (wish all the HOPs knows this),
the tunnel mode is used (at SG).
 
It is complex to maintain two modes in the IPSec.

I certainly go for one simple IPSec mode that will take care of l2tp's
efficiency.  

This is not this WG's work and let's wait.  :-)

--- David

-----Original Message-----
From: William Dixon [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 10:55 PM
To: Chen, David; W. Mark Townsley
Cc: [email-masked]; Jhilmil Kochar; [email-masked]
Subject: RE: Question on draft-ietf-l2tpext-security-02.txt

David, were your issues addressed by the other comments ?  If not, I'll
try here to explain why IPSec transport mode instead of tunnel mode.  

Summary:
In re-reading the draft, somewhere we lost the specification that IPSec
transport mode SHOULD be used.  I'm sure someone argued that it could
technically be either and thus one chosen over the other was arbitrary
and not required to be specified.  Technically the IPSec protocol can
allow tunnel mode or transport mode.  I believe using transport mode is
more interoperable, less overhead and easier in the end to support for
the following reasons:

1. No security gain for tunnel mode vs. transport mode.  No security
lost for transport mode instead of tunnel mode.

Consider this scenario:

LAC [IP1] <==== L2TP tunnel ====> [IP2] LNS

The L2TP IP packet without any IPSec protection between these two looks
like:
  [IP1,IP2][UDP][L2TP][PPP][Ip internal packet]

The IPSec transport security for this packet could look like:
  [IP1,IP2][AH][ESP][UDP][L2TP][PPP][Ip internal packet]

The IPSec tunnel mode security for this packet could look like:
  [IP1,IP2][AH][ESP][IP1,IP2][UDP][L2TP][PPP][Ip internal packet]

Using IPSec transport mode or IPSec tunnel mode to secure this packet
makes no security difference, unless you care about the "mutable" fields
in the original (left most) non-IPSec L2TP IP header [IP1,IP2].  I say
only the mutable fields because those are the ones incapable of
protection by AH, which would be protected if the entire packet were
encapsulated in the tunnel.  I submit that you don't care about those
mutable fields - they certainly are not security relevant to L2TP.  And
since both IPSec and L2TP terminate on the same source & dest boxes,
those boxes don't care about the mutable fields either.  And you don't
care about the IP1 and IP2 being visible because they are visible anyway
for IKE to establish the IPSec SA.  Even if you manually keyed the IPSec
Sas, using either transport mode or tunnel mode between LAC and LNS
would expose the left most pair of IP addresses, IP1 and IP2.

2. Extra packet overhead using RFC tunnel mode.  
Since tunnel mode adds an extra 20 bytes of IP header, using the tunnel
form is undesirable.

3. No functional management gain using IPSec tunnel mode.
There is a small advantage mgmt advantage to go though IPSec aware NATs
in the manual keying case, but IKE still isn't NAT friendly.  So using
tunnel mode doesn't enable something that transport mode doesn't. 

4. Bruce's paper wasn't making a security comment on transport mode vs
tunnel mode, rather on reducing complexity.

Bruce suggested a modified version of tunnel mode that accommodated AH
functionality to protect the header, and did header compression to avoid
full duplication of the inner IP header as the outer IP header, thus
getting rid of transport mode and AH.  Good suggestions, would have
simplified things quite a bit, but work for a future IPSec WG.  We have
what we have now.

If you still think that tunnel mode is more secure, please explain the
attacks possible using transport mode, that are not possible using
tunnel mode.

5. Transport mode is easier to support, interoperate.  
I'd think many implementations would make management a pain by using
tunnel mode, particularly if they implement tunnel mode as routable
interface with a separate IP address from the IP1 that the L2TP packets
have as source IP.  Now if you support port floating, and address
floating, adding tunnels vs. transport Sas for these could be quite
complex.  My experience is that telling people to use tunnel mode to
protect another tunnel just makes it really confusing, they don't
understand why (only for interop, not for security), and makes it hard
to clarify which tunnel you are referring to during discussion, and thus
it's all that more difficult for support engineers to explain over the
phone to customers. To make it as efficient in encapsulation as
transport mode would require tweaks to tunnel mode that are not standard
or in a working draft.

-----Original Message-----
From: Chen, David [mailto:[email-masked]] 
Sent: Thursday, May 24, 2001 3:17 PM
To: 'W. Mark Townsley'; Chen, David
Cc: [email-masked]'; Jhilmil Kochar; [email-masked]
Subject: RE: Question on draft-ietf-l2tpext-security-02.txt

The Transport mode can not encrypt the source and destination IP
address. It is less secure than tunnel mode (that encrypt entire packet)
by it's design.

To secure IP packet and preserve IP related routing service, 
the security on l2tp is the best answer for both world.

In addition, the Counterpane (www.counterpane.com) has an article about
evaluting the IPSec and suggest using only tunnel mode.
  
I think the consent was at tunnel mode side.

--- David

-----Original Message-----
From: W. Mark Townsley [mailto:[email-masked]]
Sent: Thursday, May 24, 2001 6:07 PM
To: Chen, David
Cc: [email-masked]'; Jhilmil Kochar; [email-masked]
Subject: Re: Question on draft-ietf-l2tpext-security-02.txt

"Chen, David" wrote:
> 
> Since the L2tp depands on the IPSec's transport mode which is an 
> "eval" among IPSec community and they prefer IPSec tunnel mode that 
> more secure but has headache. Why this WG does not draw up a few AVP 
> exchanges to implement DH key exchange, Public key certification, and 
> encryption algorithm to satisfy both IPSec's tunnel mode and l2tp's 
> security requirement?

We did (well, some of us did) a long time ago, before the L2TPEXT WG
existed, but it was rejected. 

Also, many contend that IPsec tunnel mode is *not* more secure than L2TP
secured by IPsec.

- Mark

> 
> --- David
> 
> -----Original Message-----
> From: Skip Booth [mailto:[email-masked]]
> Sent: Thursday, May 24, 2001 1:22 PM
> To: Jhilmil Kochar
> Cc: W. Mark Townsley; [email-masked]
> Subject: Re: Question on draft-ietf-l2tpext-security-02.txt
> 
> Jhilmil Kochar writes:
> > Hi,
> >     I had 2 questions on this draft.
> > 1.section 7.1
> > "The L2TP security protocol MUST provide authentication, integrity 
> > and replay protection for control packets. In addition, it SHOULD 
> > protect confidentiality of control packets. It MUST provide 
> > integrity and replay protection of data packets, and MAY protect 
> > confidentiality of data packets. An L2TP security protocol MUST also

> > provide a scalable approach to key management." The draft does not 
> > talk of requirement of authentication of data
packets.
> Why?
> 
> "It MUST provide integrity and replay protection of data packets"
> 
> I believe integrity at least in the sense of IPsec implies 
> authentication. Would it make you happy if this sentence where worded:
> 
> "It MUST provide authentication, integrity and replay protection of 
> data packets"
> 
> >
> > 2. what happens to control plane security as defined in L2TP draft 
> > using
H
> > bit, Random vector and MD5 hashing in the presence of IPSEC 
> > security?
The
> > draft does not talk of this. Taking care of  both would mean 
> > duplicating
> the
> > effort so that should mean that data hiding in control plane should 
> > be disabled by default when IPSEC is enabled.
> 
> I personally don't think this is an area that the draft needs to focus

> on. Just because the L2TP packets are being protected by IPsec doesn't
rule
> out the need to do AVP hiding.  For instance, the IPsec SA may only be

> providing authentication/integrity checking of the control packets and
thus
> it's still desirable to use AVP hiding for confidentiality of AVPs.
> 
> -Skip
> 
> >
> > Thanks in advance
> > Jhilmil Kochar
> >
> > --
> >
> > ------------------------------
> > Jhilmil Kochar
> > Technical Manager
> > Globespan India
> > E-mail:mailto:[email-masked]
> > Web: http://www.globespan.net
> >
> >
> >
> > ******************Legal Disclaimer**************************
> > "This email message is for the sole use of the intended recipient(s)

> > and
> may contain confidential, proprietary or legally privileged 
> information.
No
> confidentiality or privilege is waived or lost by any mistransmission.

> If you receive this message in error, please immediately delete it and

> all copies of it from your system, destroy any hard copies of it and 
> notify
the
> sender by reply email.  You must not, directly or indirectly, use,
disclose,
> distribute, print, or copy any part of this message if you are not the

> intended recipient.  Any views expressed in this message are those of 
> the individual sender, except where the message states otherwise and 
> the
sender
> is authorised to state them to be the views of GLOBESPAN, INC. or any 
> of
its
> subsidiaries."
> > ****************************************************************

---

From: Skip Booth <[email-masked]>
Date: Fri, 25 May 2001 10:14:20 -0400

Chen, David writes:
> mode for security.  The transport mode is chosen for l2tp due to its less
> header.

That's definitely true.  As William mentions, the only reason we've been
able to identify that tunnel mode may be needed is in some NAT scenarios.

> I certainly go for one simple IPSec mode that will take care of l2tp's

Well, I've always felt that IPsec was a much better security protocol than
a tunneling protocol.  Personally I'd prefer that IPsec just provide
security and leave the tunneling to the plethora of IP tunneling protocols
out there (GRE, IPnIP, L2TP, etc).  That would basically regulate IPsec to
just needed transport mode.  I usually don't get very far with this
argument though, and even if I did, I doubt much is going to change anytime
soon wrt to IPsec.

> This is not this WG's work and let's wait.  :-)

You are right about that.  We have what we have.  Given that, the l2tp
security draft states how IPsec should be used today given the way it's
specificied in the respective RFCs.

-Skip