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

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

Ben,

>> >IP AH IP ESP IP DATA
>> >
>> >You probably intended to apply ESP in tunnel mode and AH in transport
>> >mode on top of that:
>>
>> Steve cited an SG as the IPsec site in question, so transport mode is not
>> applicable, since ALL transit traffic SAs at an SG are tunnel mode.
>
>Even if it is on top of a tunnel mode header?  Given the network:
>
>		      H1-----SG1------SG2-----H2
>
>If we first do tunnel mode ESP:
>
>IP(SG1->SG2) ESP IP(H1->H2) DATA
>
>we are now sending a packet to the other end of the "tunnel" and can
>legally encapasulate it with AH in transport mode by absorbing a
>little bit of extra functionality.

No, I'm afraid we can't.  This is not just an issue of what IKE can
negotiate. The Arch Doc is very clear on this point.  Tunnel mode is needed
at SGs to ensure unambiguous processing with regard to frammentation and
with regard to what headers are checked against which SA selectors.  In
your example, the SA in question has selectors that are applicable to the
inner IP header, not the outer header.  Uniform processing for transport
mode would call for the selectors to be matched against the outer IP
header, which is not the intent here.

>> >IP AH ESP IP DATA
>> >
>> >Note that in an ISAKMP negotiation, you would negotiate a single
>> >proposal containing an ESP transform with the tunnel mode attribute
>> >and an AH transform with the transport mode attribute.  (This is
>> >something we agreed to some time ago but which might not have made it
>> >into the docs yet.)
>>
>> The arch doc does call for tunnel+transport mode support at hosts, not SGs.
>
>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.

>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.

>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!

>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.

Steve
Follow-Ups: References: