[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deprecation of AH header from the IPSEC tool kit
Paul Koning writes:
> The issue is that the bit you're describing is actually the only
> essential difference between AH and ESP. In other words, you can
> think of it as the "do AH" bit.
>
> You can't just "protect the outside headers too". You have to be
> selective about it, protecting only immutable ones, skipping fields
> and headers that change in transit, mumble mumble mumble. That's the
> "hair" of AH I'm referring to. It doesn't matter what you call it or
> how you encode it. The hypothetical "ESP with the bit" you describe
> has to do the same thing so it has to contain the same amount of hair.
Sure. Doing AH-like functionality is a pain; if you
have to do it, you have to do it -- that's just a
given. What I don't like is having a completely
separate header with its associated complexity and
(especially) overhead. Right now though, if I had
a flow which for some reason need privacy and outer
header protection (ie, AH functionality), you'd have
to put on an AH and ESP header. This means that the
SPI and the Sequence are completely redundant, as
well as having to burn another longword for the
redundant header, thus I'm having to add yet another
12 bytes per packet. If we're talking about something
like RTP audio, that's probably significant.
Then of course there's the issue of, say, CRTP. I don't think
that a profile for crypto for CRTP has been done to
compress the predictable parts of the crypto headers,
(ie, SPI, SEQ, next header), but having to contend
with *both* AH and ESP would make crypto-aware CRTP
an even uglier proposition. The same, incidentally,
goes for normal header compression, and the coming
IP enabled cellular stuff is going to absolutely
demand both compression as well as security.
Whether it is wise to open up this debate yet again
is questionable, but life is only going to get more
complicated if AH stays around. Pick your poison.
Mike
References: