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

Re: Deprecation of AH header from the IPSEC tool kit



>>>>> "Michael" == Michael Thomas <mat@cisco.com> writes:

 Michael> Paul Koning writes: What keeps nagging at me is the overhead
 Michael> of both AH and ESP, not to mention the added complexity.
 >>
 Michael> This might be water well under the bridge, but has the
 Michael> thought of having a mode to ESP which protects the outer
 Michael> headers?
 >>  That's no help, because that is exactly the difference that makes
 >> AH so much harder than ESP.  (Well, there's details like having
 >> the MAC in the header rather than the trailer.  Then again, ESP
 >> puts the NextHeader value in the wrong place, so they're even...)
 >> 
 >> The reason I like ESP authentication is precisely the fact that it
 >> doesn't contain all the hair needed to protect a subset of IP
 >> header fields.

 Michael> Maybe you're misunderstanding me: if ESP had a bit which
 Michael> said "I'm protecting the outside headers too", it could be
 Michael> either signaled or potentially even done on an as-needed
 Michael> basis by the IPsec stack for IP headers which would
 Michael> otherwise require AH. I'm all for not protecting things that
 Michael> don't need protection otherwise.

I think I understood.

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.

    paul



Follow-Ups: References: