[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Require AH?

Stephen Kent writes:
 > At 7:44 AM -0700 8/15/01, Michael Thomas wrote:
 > >    Actually, what would make me most happy would be to
 > >    have a single IPsec extension header which does
 > >    *everything*. This helps on the code/message
 > >    compactness front, as well as simplifying the
 > >    number of SADB entries, different protocols
 > >    handling, header traversal, etc. It seems to me
 > >    that if we had modes like gzip-aes-cbc-sha1 for
 > >    ESP transforms, we could get rid of both AH and
 > >    IPCOMP.
 > >
 > >		Mike
 > 
 > This has been suggested before, and rejected. In large part AH is 
 > ugly because it tries to cover the IP header, but there are so many 
 > fields that cannot be covered. this makes processing slower than ESP 
 > auth only. tunnel mode of auth only ESP addresses essentially all of 
 > the IPv4 motivations for having AH. The only open question is what 
 > IPv6 requirements are met by AH and not by this mode.
 > 
 > So, if we don't find a really good reason to retain AH, there is no 
 > good reason to create a new, different protocol to accommodate this 
 > combination of features. Also, this sort of new protocol would be 
 > more complex than either AH or ESP alone, which raises questions 
 > about whether we have achieved anything.  One can argue that two 
 > protocols, each of which is relatively simple, are better than one 
 > protocol that is more complex.

   There's quite a bit of complexity added by the
   addition and processing of multiple headers, both
   on the keying front and the kernel tasks. Interaction
   between the modes/headers requires a lot of explanation in
   2401, for example, and is frankly pretty confusing.
   To my simple mind a single header and a single 
   transform of, say, compress-encrypt-hash would be
   a lot more straighforward both on the understanding
   and coding parts. As is right now, there are many
   different ways to do the same thing, and it's possible
   to get into non-sensical combinations such as compression
   after encryption (even if the spec proscribes it). 
   Clearly, you could do such a bone headed thing with
   a single spec, but right now you have to look and 
   understand many RFC's to grasp that proscription. 
   I doubt this is the only example. Also the degrees
   of freedom afforded by multiple headers introduce
   their own level of interoperability problems. An
   implementation may very well, for example, have a
   nice modular way of plugging in new crypto algorithms,
   where it would be relatively simple to add a new
   transform which, say, does aes/lzw. Adding IPCOMP,
   however, has to be integrated into all of the 
   places that ESP was integrated. In my mind, that's
   a false modularity since it leads to duplicated
   processing (and the resultant possibility for
   mistakes) with no substantive differention of
   the code other than that of the gratuitous
   design-by-committee kind.

       Mike
Follow-Ups: References: