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

From: "Wang, Cliff" <[email-masked]>
Date: Mon, 26 Feb 2001 19:16:35 -0000

Well, the original question is on whether the L2TP tunnel and IPsec
SA (transport) should have a strong tie with each other, so that one
destruction results in the destruction of the other. The current draft
doesn't mandate such a tie. Instead, many implementations depend on
the L2TP packet filter to detect the loss of IPsec protection.

Admittedly, due to the lack of an IPsec keep alive mechanism,
it is hard, but not impossible, to tell whether an IPsec tunnel is alive.

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]]
Sent: Sunday, February 25, 2001 11:48 PM
To: Wang, Cliff; [email-masked]
Cc: [email-masked]; Beadles, Mark A; Burnett, Tony L
Subject: RE: A comment on draft-ietf-l2tpext-security-02.txt

Cliff Wang [mailto:[email-masked]] writes:

> I guess that we refer to two different scenarioes indeed.
> I would agree that an old SA deletion in a rekey case
> should not affect the L2TP tunnel.
>
> What about the case that an IPsec tunnel is torn down
> completely because of IKE and IPsec shut down?

There seems to be some misunderstanding here.  L2TP security doesn't use
IPSEC tunnel mode at all; it uses transport mode.  Perhaps you were thinking
of a different draft?

>
> It seems that you can't decide whether the delete message
> is the result of a rekey or a total destruction of the
> tunnel. Can the L2TP stack tell whether the tunnel is gone
> or not? Maybe you can tell from the filter checking.
> But in the case of a lost IPsec tunnel, it takes time
> to kick off a new tunnel. If you keeps the L2TP sessions,
> what happens to these L2TP packets during the gap when no
> IPsec SA is available?
>
> -----Original Message-----
> From: Skip Booth [mailto:[email-masked]]
> Sent: Wednesday, February 14, 2001 10:10 PM
> To: Wang, Cliff
> Cc: [email-masked]; Beadles, Mark A; Burnett, Tony L
> Subject: Re: A comment on draft-ietf-l2tpext-security-02.txt
>
>
>
> Wang, Cliff writes:
> > In section 7.5 of the draft:
> >
> > Anytime IKE receives a phase 1 or phase 2 delete message, IKE should
> > notify L2TP this event has occurred.
> >
> >
> > The word here is "should", but I think that a "MUST" should be used
> instead
> > since the IPsec tunnel is to protect the L2TP tunnel. If such protection
> is
> > gone, the L2TP should be torn down as well. This view is supported by
> > Section 7.7 of this draft, which mandates a "MUST" for IPsec tunnel
> > protection of a L2TP tunnel.
>
> Just because the SA has been deleted, doesn't imply that the protection
> provided by IPsec has disappeared.  Even after the SA has been
> deleted, the
> implementation still should have the policy and corresponding L2TP packet
> filters to guarentee that any L2TP traffic is protected and new SA's are
> kicked off if needed.  Since the work which results from a delete message
> is somewhat implementation dependent this was a SHOULD versus a MUST.
>
> As long as the L2TP tunnel is established, the security checks outlined in
> section 7.7 should be in place.  I don't perceive any dependency
> on section
> 7.5 for this requirement.
>
> -Skip
>
> >
> >
> > In Section 7.7
> > 7.7.  Per-packet Security Checks
> >
> > When a packet arrives from a tunnel which requires security, L2TP MUST:
> >
> > 1) check to ensure that the packet was decrypted and/or authenticated by
> > IPsec.  Since IPsec already verifies that the packet arrived in the
> > correct SA, L2TP can be assured that the packet was indeed sent by a
> > trusted peer and that it did not arrive in the clear.
> >
> > 2) verify that the IP addresses and UDP port values in the packet match
> > the socket information which was used to setup the L2TP tunnel.  This
> > step prevents malicious peers from spoofing packets into other tunnels.
>