[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: L2TP + IPSEC question
>Sorry if this subject has already been done-to-death:
>I've just been reading the draft on using IPSEC to defend L2TP.
>Of the two models proposed, (compulsory and voluntarily), the
'Voluntarily' options feels safer to me (from a security management point
of view).
>So, if my clients are IP-only, why do I need IPSEC AND L2TP? Why not
just IPSEC tunnel?
1. AH and ESP are simply headers. ISAKMP is the one IPSec protocol that
allows information exchange between communicating parties. There is no
defined way to establish outgoing calls (LNS initiated calls) using ISAKMP.
2. L2TP offloads PPP processing (especially CPU consuming CCP and ECP) to
the ISP's customer.
3. L2TP allows user authentication and configuration to be left to the
ISP's customer.
4. Call statistics can be forwarded from the LAC to the LNS.
>Here are a few cases :
>1) PPP on client, L2TP LAC at ISP POP:- Unprotected L2TP exchange
>not secure, hence the draft.
>2) PPP on client, L2TP LAC at ISP POP + IPSEC encapsulation:- L2TP
>secure, but means sharing security information
I don't think I understand. If the LAC establishes a SA with the LNS, it
will not share the SA information with the client. If the client is using
AH/ESP to protect its traffic, it will be transparent to the LAC and the
LNS since AH/ESP happen at the IP layer. Hence the client does not have to
do
any security info sharing with the LAC or the LNS.
BTW, securing L2TP does not in any way protect the dial-up line.
>3) L2TP on Client :- as for 1) and tunnel server address has to be
>known by the client, no longer available from the ISP
I'm assuming that you mean the dial-up client here. Why would the client
do L2TP? L2TP is a layer 2 tunneling protocol that defines how to tunnel
PPP
packets received from the client. It would not make sense for the client
to encapsulate PPP packets in L2TP and then encapsulate L2TP in PPP.
The client simply runs PPP and L2TP happens between the LAC and the LNS.
Neither the LAC, nor the LNS ever pass the tunnel server endpoint back to
the client.
>4) L2TP on Client + IPSEC:- secure, but why use L2TP when PPP in IPSEC
would do, and for IP-Only, not even PPP.
PPP is a layer 2 protocol for point-to-point links. IP is layer 3. How
can you run IP directly over, say, a dial-up link? So, you would need PPP.
If you want to use ESP with PPP, you'd have to define a new PPP protocol
like CCP or ECP.
The PPP session would still have to terminate at the ISP's NAS. The NAS
would have to extract the layer 3 packet from the PPP packet, and then
somehow get it to the tunnel server endpoint.
ECP already allows PPP encryption.
>5) IPSEC on Client:- secure, but how can the tunnel server address be
>discovered?
The client does not need to know anything about tunnel servers. It may be
doing AH/ESP, but that happens at the IP layer and is hidden from the LAC
and LNS.
As far as how the client discovers a security gateway, that's still an
unresolved issue.
The LAC can find the tunnel server (LNS) address in a few different ways:
1. During user authentication, the RADIUS server could return the tunnel
server endpoint along with the rest of the user configuration.
2. A NAS port may be hardwired to tunnel all incoming calls to a configured
LNS.
3. The DNIS for the incoming call could indicate the LNS address.
>Option 5) seems to be the best answer for IP-Only and there seems to be a
PPP in IPSEC option for other requirements.
>If there is a requirement for the tunnel server address to be discovered
by the client, no pre-configured, then the ISPs could provide a PPP-based
tunnel server >address via PPP_IPCP. The IPSEC code could then use DHCP to
acquire the Intranet address if not static.
One way to do things would be for the client to run IPSec end-to-end. L2TP
(protected by some security mechanism) would be used to tunnel PPP from the
LAC to the LNS. This would protect the dial-up line and the channel
between the LAC and the LNS. And, the client would not have to trust the
LAC (which may belong to an ISP).
>If there any comments on this, can someone copy me directly - just joined
the distribution lists.
>Thanks, Steve.
Sumit A. Vakil
Security and Mobility Advanced Development
3Com, Corp.