Ive been in this game for almost 10 years and have never really been involved with firewalls and VPNs much. I am now and reviewing our policy on tunnels.
What do you guys use for minimum tunnel settings for phase 1 and 2?
Im of the mindset to crank it up as high as supported for both sides but I dont know what this does to hardware performance.
Right now, AES 128 is actually more secure than AES 256. Fun fact. Cranking it up is not necessarily the best sort of thing to do.
Interesting!
AES still a better choice over 3DES? Any performance hits between them?
AES128 will spin more cycles, but it's the best way to go. Just provision appropriately.
Quote from: deanwebb on January 09, 2015, 03:48:50 PM
Right now, AES 128 is actually more secure than AES 256. Fun fact. Cranking it up is not necessarily the best sort of thing to do.
Are you referring to the "key schedule" problem with AES256, or something else? Unless you have to meet government requirements I would think 128 is good enough technically. However, perception of management is that double is better.
-Otanx
Yep, crank it up as high as possible as supported by both sides, with the assumption that AES256 is better than AES128, DH 5 being better than the groups, and SHA being better than MD5. We even go as far as turning on PFS.
As for performance implications, we don't have enough VPNs (or demand for VPN connectivity) to really worry about performance implications. This also helps troubleshooting because we're looking at one or two policies vs multiple.
Certs vs static keys is a biggie - total PITA and requires L3 engineers to do any intervention, also renewal time is super fun. But with an internal CA (that you control) its not as bad, the huge bonus is that you can revoke a spoke cert. Also if you grow to DMVPN, certs are basically mandatory as otherwise you have a single static shared key for the entire DMVPN.
I don't reckon turning on pfs is going far, I mean its one line and I've never seen it cause an issue, just gotta remember it on both sides :) (damned if I remember specifically what its doing though, that exam was a long time ago lol).
There's also the use of IKEv2 vs iKEv1. To be honest I've not done any production implementations of IKEv2 but obviously that's the standard now, though plenty of people still using IKEv1.
Thanks for the tip re: AES128
Finally, tunnel ACLs and two-factor auth for client IPSEC/SSL. There was an article recently detailing the famous Las vegas Sands casino hack where the attack vector was a keylogger on a web exposed dev server, that captured a network admin's login credentials, then they just merrily VPNed in. With two factor that would not have happned.
The thing with using an internal CA is that you need to have an OCSP server that is reachable by the spokes before the tunnel comes up. That also means the spokes have to have a DNS server reachable without the tunnel as well to resolve the name of the OCSP server.
-Otanx
Most enterprises use a SCEP server on their internet edge routers. I guess I should clarify, by internal CA I mean a CA you control (not verisign etc.), not necessarily one on your internal LAN.
You only need the SCEP server accessible to the internet for signing/enrolment. Once you've enrolled the spoke, the spoke will exchange its signed cert with the hub and all is hunky dory as it is signed by a CA already trusted by the hub. In an enterprise a CRL is not that bad as you're not dealing with a massive number of sites/certs
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/PKI-security.html#wp1078557 (http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Security/PKI-security.html#wp1078557)
I am aware that OSCP is a better solution than CRL for revocation purposes but i don't know much about it and I've not seen it in enterprise VPN before