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

Re: AH and ESP Orthogonality

Bill,

        Having orthogonal transformations was not necessarily a bad idea,
but there are benefits to having a better division of responsibility
between AH and ESP.  For example, the current definition of AH is messy
because either AH covers the entirity of an IP datagram (minus mutuable IP
header fields) or it covers just upper layer protocols.  The distinction is
a function of where AH appears relative to ESP.  Several of us would prefer
a verison of AH that applied to the whole datagram (as described above),
period.

        ESP, if it omits integrity and authenticity facilities, creates a
potential need for the embeded use of AH.  However, if one were to redefine
ESP to include optional authentication and integrity facilities, then there
would be no need to embed AH when the required services spanned those now
provided separately.  This would be more efficient from a bandwidth
standpoint, since a single header (ESP) could embody the fields necessary
for this larger set of services.  As it stands, ESP is a shell and all the
detail is added in each transform defintion.  This is unfortunate from a
document structuring standpoint.  It might be preferable if ESP defined
optional, variable length fields for carrying the necessary data to support
confidentiality and authentication and integrity.  The specific fields used
for a given SA would be defined at SA establishment, nailing this down for
efficient per-packet processing.  The result would be to make transform
definition documents more modular.

        Several folks, including yours truly, have expressed a desire to
add an anti-replay feature into the IPSEC suite.  This could be useful in
either AH or ESP, or both.  The motivation is to process and drop replayed
datagrams at an encrypting router, prior to letting them into a local net
environment.  (At a host this doesn't offer as much protection from a
denial of service perspective, so it is most attractive in the context I
cited.)    This is a reasonable service to offer either in the context of
AH or ESP.  The former is especially appropriate if AH is used as an outer
layer of protection that is stripped off at a firewall (perhaps with an
inner ESP layer that goes all the way to the destination host), and the
latter is especially appropriate of an ESP layer (used in tunnel mode) is
stripped off at the firewall, with no inner layer IPSEC.  The observation
that anti-replay is a reasonable feature for both AH and ESP further
motivates the creation of a single header that can provide all of the
services of AH and ESP, or any subset of the services.

        I disagree with Perry about opacity being an important feature of
ESP.  I participated in the Toronto WG meetings and hallway discussions and
I don't reacall opacity as a big deal, but I'm getting older so maybe my
memory ain't what it should be ;-).  In fact, I don't like the fact that
the ESP spec is so detail-free and I'm not convinced that we can't have a
header that allows for a wide range of combinations of confidentiality,
integrity/authenticity, and anti-replay mechanisms, all of which can be
optional, combined in a mix-and-match fashion.  I think that a new header,
providing such a set of features, might be what we should aim for.

Steve