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

Re: ESP and AH used in tunnel mode by a Security Gateway


Steve,

Stephen Kent <kent@bbn.com> writes:

> >And that's not a problem.  The issue is that if two Security Gateways
> >want to speak both AH and ESP simultaneously (even though this isn't a
> >requirement), they ought to be able to negotiate it with ISAKMP.
> 
> No argument in principle, but the Arch Doc notes that such support is not
> required, and this admonition was made at the request of the implementor
> community.

Who are in turn getting pressure from their customers.  We have
several large customers who want to use AH as a strong integrity check
for the packet and who don't much care about authenticity.  Unless the
authenticator in ESP can be modified to (optionally?) cover the outer
IP header, we're going to be pretty well stuck with the concept of the
combined transform for the Security Gateway.

> >Clearly, this is most accurately described by ESP in tunnel mode
> >followed by AH in transport mode.  However, as Dan points out, there
> >are some serious configuration issues if you do this -- the least of
> >which is the requirement to define two different entries in the SPD
> >(an ESP, tunnel mode for the traffic between H1 and H2 and an AH
> >transport mode for ESP traffic between SG1 and SG2).
> 
> I don't agree with the suggestion that AH should be in trnasport mode.  As
> I said, any transit traffic SA involing an SG is in tunnel mode, for the
> reasons cited above. It is not the case that two SPD entries are required.
> If this combination of tunnel mode SAs were supported, it would be
> described as an SA bundle, since the requirement is that both AH and ESP be
> applied to each packet and both would be negotiated at the same time.   The
> Arch Doc descibes this situation in section 4.4.3, page 18 in the July 98
> draft.

Then we're not talking about pure AH and pure ESP, but about a funny
protocol called IPsec (which further breaks the layering model, AND
has two distinct protocol numbers).  If you look at the following
packet:

IP AH ESP IP Data

from the perspective of the AH, you are clearly talking about
transport mode because there is not an IP header immediately following
the AH.

It seems that you are now talking about the AH ESP pair as a single
block (SA bundle) which has either a tunnel or transport attribute.
In this case, the way that we negotiate the bundle in ISAKMP doesn't
make any sense because the attributes seem to be bound to individual
transforms instead of to the entire bundle.

Perhaps we need to change our description from (AH ESP in tunnel mode)
to (AH ESP IP-in-IP) which is less ambiguous and more accurately meets
the IP "Next Header" model.  (And doesn't provide a second definition
of IP-in-IP to boot!)

> >It would be simpler, as a result, to negotiate both the AH and ESP as
> >a single ISAKMP proposal, AND to negotiate both with tunnel attributes.
> 
> No argument there!

Great!  Does anyone protest, or can we claim "rough consensus"?

> >It doesn't seem that anyone has many strong feelings either way
> >(especially since this isn't a requirement), but it would be nice to
> >have an agreement documented somewhere in the working group drafts (my
> >feeling is that ipsec-doi is most appropriate).  It may also be
> >helpful to describe this special-case use of transport mode AH by
> >Security Gateways as a "MAY" in the arch-sec document.
> 
> Oh, please, let's not start introducing special cases of this sort :-(.
> IPsec processing is already complicated, and it will become even more so if
> we start introducing special cases of this sort.

Hmm...  Is it not best to describe the current running systems?  If we
were to describe the way that AH+ESP is negotiated between Security
Gateways, it would pretty much require having a pointer to somewhere
in the Arch document.

As a side note, I guess I missed the rationale for adding the
complication beyond RFC1825.  Defining a strict bond (currently called
the SA bundle) inherently caused a combinitoric explosion in
complexity.  Anyone feel like enlightening me on a bit of ancient
history?  %)


ben
Follow-Ups: References: