[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AH/ESP & Replay Protection
% 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.
One of the problems is figuring out what the effective protections were
on the data, passing that information to the policy engine, and informing
the application of what protections it got. Also, there is kernel bloat
and increased per-packet processing cost as compared with a more integrated
solution.
% >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.
Yes. You traditionally worry much more about bandwidth than about
processing costs, so I'm not surprised. Integrated approaches will
generally reduce both bandwidth and processing costs.
% 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?
A conforming implementation doesn't have to support all of those modes.
There is a minimum set that is mandatory. Implementing more than that
is essentially a decision to add features. By contrast, my concern has
to do with items that are mandatory to implement.
In the NRL code, which supports DES-CBC with 32-bit and 64-bit IVs,
the variable IV length costs two if/else statements and an increment
in the normal case (add a call to random() in the case where the increment
causes the IV to be all zeros). This isn't expensive. It certainly
isn't the case that one has lots of redundant code lying around.
If you're concerned about complexity, I'd suggest removing the support
for confidentiality without strong integrity (once better transforms
appear) since that is known to be vulnerable to active attacks described
in past IPsec meetings. Talk of "SHA" or "shortened MD5" or other
hypothetical combinations just tells me that the WG needs to come up
with a single well chosen pair of mandatory transforms (one each for
AH and ESP). We have already got a single set at Proposed Standard. The
others (e.g. SHA for AH, 3DES for ESP) are all experimental and aren't
required. Just because someone wants IDEA doesn't mean that everyone
has to implement it.
You've mixed apples (complexity that is mandatory to implement) and oranges
(complexity that one chose to implement but is not mandatory), IMHO.
Ran
rja@cisco.com
Follow-Ups: