[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Require AH?
At 7:44 AM -0700 8/15/01, Michael Thomas wrote:
>Dan McDonald writes:
> > Some HW folks didn't think you could do AH in hardware. I've
>heard other HW
> > folks (but only after the fact) say that you can indeed do AH in hardware.
>
> I have great confidence that hardware guys can
> do just about anything you set them out to do.
> It's only the final transistor count that tells
> you whether it is worth the effort.
>
> > ESP authentication was a knee-jerk reaction to Bellovin's analysis of
> > 1825-1827. He stated the threats of unauthenticated CBC
>encryption + replay
> > problems. The knee-jerk reaction was to add both of these
>properties to ESP,
> > without first thinking that requiring a fixed AH with replay
>protection could
> > do the trick.
>
> 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.
Steve
Follow-Ups:
References: