Date: Thu, 07 Feb 2002 14:40:28 -0500 From: Dexter Coffin <idnopheq@home.com> To: security@freebsd.org Subject: Re: Questions (Rants?) About IPSEC Message-ID: <3C62D82C.7070507@home.com> References: <20020207163347.51C606B29@mail.cise.ufl.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Here are some thoughts. YMMV. Anyone, please feel free to confirm or
denounce my info ... anyway, I HTH ...
Please note that all of my IPSec experience comes from COTS products
like CheckPoint, Cisco, Nokia, and Nortel. Never used S/WAN or racoon ...
James F. Hranicky wrote:
> After reading up on IPSEC, I have one major question: Is it really
> a good protocol?
Yes. Room for improvement abounds, tho. See the end of this reply for
some more thoughts.
>
> 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
>
Stuff like OSPF, which uses a multicast address IIRC cannot work through
IPSec, a definite shortcoming. The exception is like a Cisco to Cisco
that both agree on a non-standard (read: not part of the IPSec standard
which, for multicast, there is none) way of doing it. All routes must
otherwise be static.
> - 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).
Cisco's add on also breaks some compatibility with other IPSec devices,
like CheckPoint FireWall-1 4.0- IIRC. But, yes, the IPSec gateway does
have to function as a router to some degree whether or not it is an
actual router. This can be a real PITA if you have lots of incongrous
and/or non-sequential networks behind it (like the RFC 1918 private
addresses and some poorly chosen public networks that really are private
... if you get my meaning).
One could do a one-legged IPSec device and let a router handle routing.
~~~~~~~~~~~~
~ Internet ~
~~~~~~~~~~~~
|
| <------------------ default route, hopefully w/ FW in between
|
+---A----+ +-------+
| router B-+-C IPSec | <- outbound route for assigned client addresses
+---D----+ | +-------+ or static gateway addresses (& protected
| | LANs via remote gateway); device default
| | routes to router interface B
| | +-------+
| +-| DHCP | <- for inbound IPSec client IP assignment (maybe
| +-------+ not a seperate host)
|
| <------------------ OSPF, BGP, etc. ... maybe FW here, too
|
~~~~~~~~~~~~
~ Private ~
~ LAN ~
~~~~~~~~~~~~
... where
interface A = public Internet routable address for all Internet traffic
interface B = public Internet routable address for IPSec traffic
interface C = public Internet routable address for IPSec traffic
interface D = private address for unencrypted traffic
and whatever network/pool you use for clients defaut routes from the
internal LAN to the IPSec gateway w/ maybe static NAT involved.
...
I have to admit that I don't know if one can have dynamic routing on but
one router interface. I think you can specify trusted routers for OSPF,
etc ...
And, of course, don't forget a firewall (or two).
>
> - Clients with dynamic IPs are poorly supported.
True. IPSec is too dependent upon static IPs for gateway to gateway
connections (tunnel mode, I believe). Transport mode, the client to
gateway stuff, works with DHCP or is supposed to. My experience shows
that if a client's DHCP lease expires and they do not get the same IP
back, they do have to either renegotiate or reauthenticate depending
upon the flexibility of both peers.
SSL does a nicer job in this regard ...
Best case it (dynamic IPs and IPSec) consumes time and worse case the
connection is lost.
If I have transport and tunnel swapped please forgive.
>
> 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?
A predefined static IP is required for tunnel (gateway) mode, not
transport (client). But you have the PKI thing right. It should be the
client's public key, not private, that is exchanged.
>
> o Isn't requiring the server to have the private cert
> key the same as having a shared secret?
With a shared secret, it would theoretically be possible to launch a
man-in-the-middle attack, because the math for the IPSec would be based
partially on a known value.
If I can find my Cisco IPSec class notes, I can send the formulas.
Something like the remote public key is hashed with the local private
key and there's a remainder/mod in there somewhere which is common to
both, but never sent over the wire, to which the encryption is based.
The authentication is somewhat independent and based off of the common
root certifier ... CRLs and whatnot come into play.
With shared secret, the secret is hashed and that is the basis for the
encrytion *AND* authentication.
Also, managing loads of shared secrets is a pain if you have lots of
peers. ANX (Automotive Network eXchange, a huge IPSec network of auto
manufacturers and suppliers) uses only shared secret at the moment
(years after implementation ... but that is another story).
>
> 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???
I think the private key thing in the racoon man page is a typo. Private
keys are never shared, nor should ever be shared.
>
> 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
True. Bad form unless it is unavoidable. And, the sharing of the
shared secret would need to be done over an OOB trusted media (like
heavily encrypted email, trusted phone call, face to face, etc.).
Tracking and troubleshooting also become exponetially more difficult in
this scenario. Imagine having to change the secret if it is compromised!
>
> - Different shared secrets for all users/client machines.
>
> Key management nightmare.
Indeed. See note above.
>
> - Different x509 certs for all users/client machines.
>
> See above.
Well, a good PKI takes care of that. As long as the certs have a common
root, everything should be good. That's what I'm doing with an 1100
user base, but all commercial software and hardware.
Some combine other authentication methods, like S/Key or smartcards,
into the mix.
>
> - 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.
>
Beyond me on this one.
> 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.
Well, an okay closed system is from Nokia that's relatively inexpensive.
But they are negotiating with CheckPoint and the cost may well rise.
>
> ----------------------------------------------------------------------
> | 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
>
>
IMHO, it'd be great if IPSec had SSL's flexibility (NAT is no problem,
dynamic IPs are ~usually~ no problem, highly portable, light weight) and
SSL had IPSec's robustness (better encryption, (w/ public key) better
authentication and integrity, gateway to gateway tunnel-like mode for
network to network connectivity).
I don't know if SSL handles multicast, but IPSec certainly needs to.
As I said at the top, YMMV. HTH!!! :^D
--
(
)) >===<--. Dexter Coffin - America's Favorite Ne'er-Do-Well
C|~~| | = |-' idnopheq@home.com - http://www.members.home.com/idnopheq
`--' `-----' idnopheq@perlmonk.org - http://idnopheq.perlmonk.org
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?3C62D82C.7070507>