[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Discovery of tunnel server from ISP POP



On Tue, 10 Feb 1998, Stephen Waters wrote:
> 
> A number of short-comings are leveled at IPSEC regarding address
> assignment mechanisms.  The DHCP+ISAKMP draft covers the allocation of
> an Intranet address,  but how does an IPSEC client discover the Internet
> address of the IPSEC Security Gateway?

Sure, this is a problem.
> 
> In the L2TP model, the tunnel is connected by the ISP 'LAC'  once the
> client has been authenticated via PPP PAP/CHAP.  The LAC knows where the
> appropriate tunnel end-point is.
> 
> For IPSEC, could the ISP also offer security gateway address resolution?
> For example, an extension to the PPP IPCP NCP could allow the ISP to
> deliver the Internet address of the IPSEC security Gateway for a given
> client (identified in the same way, PAP/CHAP).  Ideally, this support
> would allow a list of addresses to be supplied in a similar way to the
> passing of Primary and Secondary DNS servers via IPCP.  This would allow
> the client to re-connect should a primary server fail or become
> unreachable.
> 
> Is this worth a (very short) draft proposing an extension to IPCP?
> Since this exchange provides Internet addresses,  is there any need to
> protect/encrypt this information?  If there is, then things start to get
> messy (arranging encrypted sessions with the ISP POP).  The L2TP LAC
> model avoids this sticky issue of IPCP exchanges in the clear since PPP
> encryption has picked in with the tunnel server by the time IPCP
> starts-up.
> 

This might be worth doing. You may want to run this idea through the
pppext WG?

Anyway, I do not see how this helps you with the DHCP+ISAKMP draft. An
extension to IPCP in the way you propose may benefit L2TP tunneling
since PPP (and IPCP) run on top of it. I do not see how this helps IPSEC!
Do I miss something? Also, I think you are on the wrong side of the
network, the DHCP+ISAKMP draft talks about a host on the Internet trying
to enter an Intranet *though it could work the other way around). You are
talking about accessing an ISP and the ISP to provide you with the address
of the secure gateway.

What you propose might be worthwile; I just try to clarify
what it solves.

> Regards, Steve.

Thanks
George
-----------------------------
Internet Transport Research |
BTLABS                      |
--------------------------------------------------------------------------
Notice: This contribution is the personal view of the author and does not
necessarily reflect the technical nor commercial direction of British
Telecommunications plc.
--------------------------------------------------------------------------




References: