[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AH/ESP & Replay Protection
>I am concerned about the potentially exponential increase in header
>combinations that would be encouraged by having a separate replay
>protection header.
What's wrong with lots of permissible header combinations? It's easy
to support an arbitrary sequence of headers, you just parse and decode
each one in sequence.
>I'd MUCH rather see a trend towards ESP transforms that provide more
>capabilities (such as the combined transform that provides both
>integrity and confidentiality) than towards more headers.
I mildly agree that I'd like to see some more capable ESP modes, but
for a different reason -- reduced total header overhead compared to
combining separate protocols in modular tinker-toy fashion.
The big problem with integrated authentication/encryption ESP modes,
and the reason I don't support them as strongly as I used to, is that
here's where you can get the real explosion of implementation
complexity. I already support six different ESP transforms in my code
-- DES and 3DES, each with 0-bit, 32-bit and 64-bit IVs. Most of my
esp_input and esp_output routines consist of switch statements on the
encapsulation mode, and its likely to get much worse when I start
folding in authentication. For starters it will double the total
number of modes to 12, the six I already support plus those six with
MD5 authentication. Then somebody will want to add SHA for extra
security, and somebody else will probably want a "shortened MD5" for
less overhead on slow links. And *then* somebody will want IDEA and
SAFER cipher support... you get the idea?
Phil
References: