Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 7 Feb 2002 11:29:39 -0800
From:      "R.P. Aditya" <aditya@grot.org>
To:        "James F. Hranicky" <jfh@cise.ufl.edu>
Cc:        security@freebsd.org
Subject:   Re: Questions (Rants?) About IPSEC
Message-ID:  <20020212021147.6E7089EE58@okeeffe.bestweb.net>

next in thread | raw e-mail | index | archive | help
On Thu, Feb 07, 2002 at 11:33:47AM -0500, James F. Hranicky wrote:
> After reading up on IPSEC, I have one major question: Is it really
> a good protocol?

It has it's uses, yes.

> 	- IPSEC routers don't seem to be able to advertise routes
> 	  for an arbitrary number of networks behind them

IPSEC defines a standard for authentication and encryption of IP packets and
doesn't participate in routing per se, so this quibble is not really "a
problem".

> 	- IPSEC routers have to basically be the border router for
> 	  a site, as there is no post-decryption NAT protocol to
> 	  get packets back to a router on the inside of the network
> 	  (Apparently, Cisco VPN boxes have this capability, but
> 	  it's an add-on to IPSEC AFAICT).

If you use AH then this is a problem, with just ESP, it should not be a
problem, however, given the intrinsic dependence on "static" IP addresses to
base policy, using it with NAT is not "standardly supported".

> 	- Clients with dynamic IPs are poorly supported. 
> 
> 	  AFAICT, what I want is to be able to issuce x509 certs to
> 	  any of my remote users for key exchange, and accept any
> 	  cert from any client that was signed by my CA. That's what
> 	  PKI is all about, right? Checking the racoon.conf man pages
> 	  and sample racoon.conf files shows that I need to have the
> 	  client's *private* key for a *specific* IP address.
> 
> 	    o Is this really the case, or am I just wrong here?

yes, this is really the case.

> 	    o Isn't requiring the server to have the private cert
> 	      key the same as having a shared secret?

yes.

> 	    o If I'm not wrong, and cert's private keys are required per
> 	      IP address, is there some problem with the scheme I detailed
> 	      above? As a comparison, isn't the whole point of the
> 	      ssh_known_hosts file to keep only the public keys on the
> 	      remote server? I mean, wouldn't it be great if ssh supported
> 	      x509 certs, obviating the need for even the ssh_known_hosts
> 	      file, as host keys would be signed by the CA? 
> 
> 	      Isn't this what we want for IPSEC???

This is what is wanted from a general VPN protocol, but IPSEC wasn't designed
to solve that problem alone.

> Is there another VPN solution (mpd-netgraph+PPTP) that would suit my needs
> any better?

probably. Unfortunately, they are not entirely IETF standards based and it's
hard to find one that supports a wide variety of client OSes.

> Any enlightenment I can receive that can convince me IPSEC is anything
> more than an alpha-quality protocol that requires vendors (a la Cisco)
> to fix it would be most appreciated. It's entirely possible I have
> no idea what I'm talking about.

It's not so simple -- you want IPSEC to do things it wasn't designed to do.
There are efforts to extend it to do things like you want, but don't hold your
breath. Depending on your clients, you should probably pick a commercial VPN
vendor at this point or teach your user base to use ssh (close to impossible,
I know).

Hope that helps,
Adi

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020212021147.6E7089EE58>