[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP and AH used in tunnel mode by a Security Gateway
I really don't want to open this can-of-worms but it has some
interoperability implications.
On 23 Jul 1998 13:58:28 EDT you wrote
> Stephen Waters <Stephen.Waters@digital.com> writes:
>
> > I seem to remember asking this question before, but....
> >
> > Although not covered in the IPSEC architecture, is there any
> > restriction on a Security Gateway
> > applying both ESP and AH in tunnel mode?
>
> You could do this. However, you'll want to be a little more precise
> with your terminology.
>
> ESP and AH in tunnel mode:
>
> IP AH IP ESP IP DATA
>
> You probably intended to apply ESP in tunnel mode and AH in transport
> mode on top of that:
>
> 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.)
I don't remember agreeing to that. In fact, the only mention of this
I remember came up during the IPCOMP and IPSEC thread. On May 28, in
<199805282040.NAA01397@orna.mentat.com> Marc Hasson wrote:
>
> I guess you could say that ESP is in transport mode, but what about the
> case where both AH and ESP are applied to the same packet:
>
> [IP2][AH][ESP][IP1][data]
>
> Is AH in transport mode?
Good point. I can hear people arguing it both ways and am sorry I
raised that side tidbit. Whats more important is that we all understand
how to process the above, which I think is pretty clear in the specs.
Yes, I feel we can all process this but it's now apparent that we can't all
negotiate it.
The next header in AH is not IPinIP so I understand the point being made.
But these two SAs are the result of a single rule. If PFS is also part of
the rule it applies to both and the ID payloads passed in the QM exchange
also apply to both. They are a single unit.
If we have:
H1 ------ SG1 ---------- SG2 ------- H2
|<-- secured -->| |
|__ H3
the rules I've applied to SG1 (vice versa for SG2) is:
For traffic from H1 to H2, apply AH and ESP and peer with SG2
If AH is in transport mode the rule becomes:
For traffic from H1 to H2, apply ESP and peer with SG2
For ESP traffic from SG1 to SG2 apply AH and peer with SG2
But if I want my packets from H1 to H2 to look like:
IP[SG1-SG2] AH ESP IP[H1-H2]
and from H1 to H3 to look like:
IP[SG1-SG2] ESP [H1-H2]
That'll break down because my packets ESP packets will match the rule
being applied for H1-H2 traffic and it'll have AH applied. There'd be some
ugly code to prevent this from happening. SG2 would also have some ugly
spagetti code to make sure that, at decaps, AH is only applied to an ESP
packet that was applied to H1-H2 traffic. That would be necessary since the
AH+ESP negotiation specified H1-H2 and to use AH on an ESP packet that was
H1-H3 would be in violation of that.
Transport mode can't be applied by a SG to a packet in transit-- in the
example a packet from H1 to H2. But if AH was treated as being in transport
mode in IP AH ESP IP DATA then that's exactly what you'd be saying in your
Quick Mode message. So you'd have to do two separate negotiations, one for
ESP on IP between H1 and H2 and another for AH on ESP packets between SG1
and SG2, and that would have problems too because you would be unable to
specify that traffic from H1 to H3 *not* have AH applied.
I think it's better to treat AH as being in tunnel mode in this case.
It precludes lots of ugly, hard-to-maintain code, it makes UI much simpler,
and it allows for a wider array of rules to be applied to various sorts of
traffic.
I'm not suggesting doing IP AH IP ESP IP DATA. I'm just suggesting that
when we want to do IP AH ESP IP DATA that we negotiate it using the same
encapsulation attribute-- tunnel mode-- in both the AH and ESP proposals.
This would also apply to IP ESP PCP IP DATA or IP AH ESP PCP IP DATA too.
Dan.
Follow-Ups:
References: