1 / 6

IPsec Enhancements for High Speed Networks

IPsec Enhancements for High Speed Networks. Stephen Kent. Current Constraints. Sequence number space exhaustion Encryption performance Integrity (and authentication) performance. Sequence Number Exhaustion.

melva
Download Presentation

IPsec Enhancements for High Speed Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IPsec Enhancements forHigh Speed Networks Stephen Kent

  2. Current Constraints • Sequence number space exhaustion • Encryption performance • Integrity (and authentication) performance

  3. Sequence Number Exhaustion • At very high speeds (10 Gb/s), the 32 bit sequence space can be exhausted by small packets in a few minutes • With the use of AES and new modes, that readily tolerate large traffic volumes, bigger sequence spaces are appropriate • Proposal: • Allow IKE to negotiate a 48-bit sequence number, but transmit only the low order 32 bits on each packet • Include high order 16 bits in integrity check at each end, and maintain local counters to track these high order bits • Receive window management is still a local matter • No change to format of bits on wire, enhanced IPsec implementations are backward compatible, per-SA flexibility

  4. Encryption Performance • AES is faster than 3DES • But, CBC mode minimizes opportunities for parallel and pipelined implementations • Counter modes (first developed for ATM encryption) offer parallelism and pipelining opportunities • For IPsec, a counter mode must accommodate lost packets and out of order arrival, efficiently

  5. A Proposed Counter Encryption Mode • Counter for 16-byte block AES should be 128 bits, yield different value for each packet on each SA • Low order 32 bits count AES blocks within a packet, bigger than needed, even for IPv6 jumbogram • Next 48 bits are a packet counter, using the expanded ESP sequence number (but only low order 32 bits are carried in each packet) • Next 16 bits contain a secret value extracted from SKEYID, for per SA uniqueness and keeping counter secret • Top 32 bits are a per packet IV (unpredictable input to the counter, but half the size of the current IV) IV (32 bits) X (16 bits) ESP Sequence Number (48 bits) block counter (32 bits)

  6. Integrity Performance • With fast encryption, the integrity & authentication computation now becomes a bottleneck, i.e., HMAC (MD5 or SHA-1) is slow • Modes that combine encryption & integrity may be good choices, but • some are not consistent with ESP processing and syntax (authenticate first, then decrypt) • some impose noticeable penalties for small packets • there may be intellectual property problems as well • Moreover, we require a fast, stand-alone integrity algorithm for ESP, when it is used in lieu of AH • As a start, let’s adopt AES-MAC (with a reduced 96 bit output) as a default • Simple, faster than HMAC, secure, ...

More Related