[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IPSEC WORKING GROUP LAST CALL
Alex Alten writes:
> 4. The design is too complex
> B. The desire to use a proven cipher, i.e. DES.
>
> This decision has had a profound impact on the design. Because
> DES is slow, it has forced encryption & decryption to the edge
> hosts, requiring the SA construct to allow the packets to traverse
> intervening routers.
I'm not certain how valid a point this really is. If we want routers
(security gateways) to protect traffic for the hosts behind them, then
we need to take the additional security processing into account. It
doesn't make much sense to design a security protocol around existing
hardware because that hardware was rarely designed with security in mind
and doesn't usually have the extra horsepower needed to handle _any_
sort of crypto processing. The core IPsec protocol (AH and ESP) was
closely monitored by a number of router vendors, and has been (IMHO)
optimized for speed as much as is possible given certain unavoidable
constrants. Note that there is nothing inherent in ESP which prevents
vendors from utilizing faster encryption algorithms.
> C. The desire to use a public key algorithm.
>
> This decision has also had an impact on the design. Because PK is
> so slow this has also contributed to the use of the SA construct
> instead of other methods which could more closely match how
> IP routing really works. It makes the management of trust more
> difficult, for example deleting untrustworthy hosts in a timely
> manner.
Note that this can be sidestepped by using pre-shared keys in ISAKMP.
Depending on your security needs, this may be an entirely adequate
solution, and would not carry the extra baggage of the PK computations
and the Certificate management. However, for many of the proposed uses
of ISAKMP, keeping a database of pre-shared keys is simply out of the
question, as this database will be much too large.
> D. The desire to distribute policy storage and enforcement.
>
> By distributing policy storage and enforcement across all the
> participating hosts and routers it has made it almost impossible
> to scale this design to very large numbers.
I guess I don't see this as a real problem, given that it would be a
much more messy problem to try and figure out how to securely bootstrap
a system from a policy server. There is nothing inherent in the
protocol which prevents such a server from being used, however, and you
will probably find that the support of such a concept is not orthogonal
to IPsec, but will probably mesh nicely.
ben
Follow-Ups:
References: