[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Require AH?
At 9:17 AM -0700 8/16/01, Michael Thomas wrote:
>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).
If we do away with AH, then this discussion is moot re AH+ESP. In the
early days of deployment, I saw folks doing both AH+ESP, but today I
think this is rarely the case, i.e., most traffic is just ESP (auth +
encrypt). As noted earlier, the most credible requirement for AH
seems to be an IPv6 mobility one. if I understand this requirement
correctly, one would have to employ different keys for encryption and
endpoint integrity/authentication vs. intermediate node
authentication, assuming a desire for normal e-t-e security as well,
and this would make for a pretty complex individual protocol and a
matching, complex key management activity.
> 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.
the decision to make compression separate from encryption was one
that this WG, and the security ADs, made a long time ago. modularity
does have a price, as you noted, but it's a price we have often
elected to accept in Internet protocols.
Steve
Follow-Ups:
References: