[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re[2]: IVs, summary of discussion
Phil:
>>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.
Phil, you advocated the use of the ID field as an IV. You further
advocated that this technique be part of the mandatory set of options. In
fact, you said, that it must be implemented, but that it did not have to be
used on a particular security association.
I say that such a technique should be dropped if it cannot be supported in
both IPv4 and IPv6. Steve has already posted a message saying that the ID
filed is not present in IPv6.
>>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?
Okay, I should have chosen my words more carefully. I do not think that
the one scheme that must be included in all IPSP implementations should
have 3/4ths of its bits constant and known. I object to this on principle.
I would rather carry a 64 bit IV.
As Steve Kent suggests, we can couple compression with encryption in
environments where bandwidth is a concern.
Russ