[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IVs, summary of discussion
>I would prefer one protocol data unit format that is appropriate for the
>use with IPv4 and IPv6. I understand Phil's overhead concerns, but I think
>that the mandatory option set must work in both IPv4 and IPv6.
Once again, I don't know of any IPv4 transport protocol, existing or
proposed, that won't require *some* changes to operate over IPv6.
IPSEC won't be any worse. A totally interchangeable IPSEC is a
chimera.
>That said, I would prefer that the mandatory option set include the best
>possible security principles. After all, we are designing a security
>protocol. In some environments, less security may be traded off for
>improved performance, but in my opinion, less security should not be the
>default.
"Best possible?" *Everything* in security is a tradeoff between
security and performance, because security is never "perfect", nor is
it ever "free". Example: all other things being equal, the longer an
authentication sequence, the stronger the security provided. Keyed
MD5 provides a 16 byte MAC. SHA provides 20. Why stop there? Why not
100-byte MACs? 200 bytes?
Maybe this example is a little extreme, but it still supports my
point. *Some* balance has to be struck between these mutually
conflicting goals in any given situation, and I think it unlikely that
any particular default we happen to pick in IPSEC is going to satisfy
everybody. That's why things *must* be negotiable.
That said, remember we are discussing one particular scheme that,
although not perfect, should satisfy enough of the user population
that we want to make it a mandatory part of the standard to guarantee
at least some minimum degree of interoperability. Those who consider
it inadequate can always negotiate something more to their liking.
But for now I'd be happy if we can solve 90% of the need with 10% of
the effort while leaving the door open for future improvements once we
have some real experience. That philosophy has served the Internet
very well in the past and I think it's just as applicable here.
Phil
Follow-Ups:
References: