From: Mark Lewis (markl11@hotmail.com)
Date: Wed May 26 2004 - 13:11:24 GMT-3
Anthony,
There are obviously four basic choices for IPSec encryption: DES, 3DES, AES
(128,192,256), and SEAL. AES is available in 12.2(13)T and SEAL (the
Software Encryption Algorithm) is available in 12.3(7)T. AES is optimized to
run quickly in software (it runs much faster than 3DES in software). SEAL
also runs very quickly in software - SEAL is a stream cipher, and stream
ciphers run faster than block ciphers such as DES and AES in software.
Having said that, SEAL *only* runs in software, whereas DES, and (soon) AES
run on Cisco hardware accelerator cards.
But assuming you are 'stuck' with DES or 3DES, then the choice is DES
(obviously).
Another important factor to consider with IPSec (and other tunneling
protocols) is the packet overhead that they impose. This is important
because the overhead can cause large packets to be fragmented (causing very
high CPU utilization on the receiving IPSec gateway if the fragmentation is
done after IPSec encapsulation). And large IPSec packets can even be dropped
on intermediate routers between the IPSec gateways (if Path MTU Discovery is
broken).
The packet overhead imposed on a 1500 byte user packet by ESP-auth (either
MD5 or SHA-1) with DES or 3DES in tunnel mode is 52 bytes (so a total of
1552 bytes).
For the really technically curious, this 52 byte packet overhead varies with
the user packet size due to the amount of ESP padding that has to be added
to: 1. be a multiple of the encryption algorithm block size (64bits with DES
[though 8 bits are used for parity, giving the 56-bit DES often quoted]),
and 2. ensure that the Pad length and Next Header fields in the ESP packet
header are right aligned with a 32-bit boundary. But that's probably waaaay
too much info :) The maximum packet overhead for ESP-auth/encrypt is
actually 58 bytes.
So, prevent fragmentation of large packets after IPSec encap at all costs!
There is a book coming out from Cisco Press that discusses MTU issues with
IPSec and other VPN technologies:
http://www.ciscopress.com/1587051044
But I do have to declare a very strong interest there :)
Anyway, hope that helped,
Mark
>From: "Anthony Pace" <anthonypace@fastmail.fm>
>Reply-To: "Anthony Pace" <anthonypace@fastmail.fm>
>To: ccielab@groupstudy.com
>CC: tpace@futuretrade.com
>Subject: IPSEC paramenters with least overhead???
>Date: Wed, 26 May 2004 07:13:33 -0700
>
>I am trying to find a combination of IPSEC parameters, which would have
>the least amount of processor overhead. Maximum security is not a huge
>requirement so simple encryption would be ok. For this reason I am
>replacing IPSEC with GRE (where possible) but where IPSEC is the "lowest
>common denominator" I want to use the simplest "flavor".
>
>I have a 3-way full mesh of IPSEC tunnels between a Cisco-806,
>Cisco-1605, and a Computer running Checkpoint Firewall-1. The processor
>utilization on the 806 and 1605 is very high.
>
>- I will replace the IPSEC with GRE between the 806 and 1605
>
>- I will not use Triple-DES
>
>What are the "leanest" IPSEC parameters? I am researching this using
>books and the Internet but it seemed like something that someone on this
>list might have some insights into.
>
>Anthony Pace CCIE 10349
>
>--
> Anthony Pace
> anthonypace@fastmail.fm
>
>--
>http://www.fastmail.fm - Or how I learned to stop worrying and
> love email again
>
>_______________________________________________________________________
>Please help support GroupStudy by purchasing your study materials from:
>http://shop.groupstudy.com
>
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:17 GMT-3