Date: Thu, 07 Feb 2002 11:33:47 -0500 From: "James F. Hranicky" <jfh@cise.ufl.edu> To: security@freebsd.org Subject: Questions (Rants?) About IPSEC Message-ID: <20020212021140.7AEDB9F269@okeeffe.bestweb.net>
next in thread | raw e-mail | index | archive | help
After reading up on IPSEC, I have one major question: Is it really a good protocol? It may be that I don't understand it well enough, or that the implementations I've looked at are lacking in features that I want, but it seems to me that it simply isn't a good solution for anything more than a small number of users. Here are the problems I have with IPSEC: - IPSEC routers don't seem to be able to advertise routes for an arbitrary number of networks behind them - 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). - 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? o Isn't requiring the server to have the private cert key the same as having a shared secret? 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??? In the end, if I go with a FreeBSD racoon or isakmpd solution, am I limited to the following setups ? : - One shared secret for all my users in the interest of manageability. I can only assume this means any user could theoretically listen in on the key exchange and thus be able to decrypt another's IPSEC communications - Different shared secrets for all users/client machines. Key management nightmare. - Different x509 certs for all users/client machines. See above. - GSSAPI Auth . Does this even work? Does it work with w2k clients and an MIT KDC? If it does, this would probably do what I need for any w2k boxes out there, but all the info I read said it didn't work with w2k yet. Never mind any other IPSEC client software. Is there another VPN solution (mpd-netgraph+PPTP) that would suit my needs any better? 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. ---------------------------------------------------------------------- | Jim Hranicky, Senior SysAdmin UF/CISE Department | | E314D CSE Building Phone (352) 392-1499 | | jfh@cise.ufl.edu http://www.cise.ufl.edu/~jfh | ---------------------------------------------------------------------- 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?20020212021140.7AEDB9F269>