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

From: "Chen, David" <[email-masked]>
Date: Thu, 24 May 2001 18:16:58 -0400

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: Jeff Mcadams <[email-masked]>
Date: Thu, 24 May 2001 18:49:16 -0400

Also sprach Chen, David
>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.

If you're talking about the original IP addresses in the original
packet, then IPSec in transport mode on an L2TP tunnel *does* encrypt
the source and destination IP address.  The transport mode encryption is
transport from the perspective of the L2TP tunnel endpoints, IPSec in
tunnel mode encrypts the full data portion of the packet, and original
IP header is fully contained within the data portion of the IP packet
that is being transported (ie, the L2TP/UDP/IP packet).

-- 
Jeff McAdams                            Email: [email-masked]
Head Network Administrator              Voice: (502) 966-3848
IgLou Internet Services                        (800) 436-4456

---

From: Jeff Mcadams <[email-masked]>
Date: Thu, 24 May 2001 18:55:17 -0400

Also sprach Jeff Mcadams
>tunnel mode encrypts the full data portion of the packet, and original
 ^^^^^^
Gack...I meant transport mode here, of course.

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 24 May 2001 19:08:28 -0400

> suggest using only tunnel mode.

And if they told you to jump off a bridge... 

Take this in context.

L2TP+IPsec transport protects the inner IP packet (within PPP). Tunnel
mode would just protect that yet again. If you argue that this is needed
for security, where do you stop? after 3, 4, ... n encapsulations?

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 24 May 2001 19:32:34 -0400

"W. Mark Townsley" wrote:
> mode would just protect that yet again. 

Gack. By "that" here I, of course, meant the outer IP header yet again.

> If you argue that this is needed