[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,
>> >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.
I'm very confused by this statement. The context we were discussing was
that of SAs terminating at an SG. There was agreement that there was at
least one inner IP header, consistent with ESP use in tunnel mode. The
argument seemed to be about use of AH in conjunction with this tunnel mode
ESP, and whether it too was in tunnel mode or whether transport mode was
applicable, in an effort to save an extra IP header. Under these
circumstances, what exactly do your clients feel they will gain fro use of
AH? The only difference between the tunnel mode ESP authentcation (assuing
they have elected to employ HMAC in ESP, as most folks seem to) and the AH
authentication is coverage of the external IP header. But we discard that
header and use the inner one for the packet that is passed to the ultimate
destination. We can still discuss the header issue, but it would be nice
to understand why people this this config, which was removed before has now
become "important."
>
>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!)
I haven't examined it carefully, but I might not have big problem with
viewing the AH-ESP bundle (with just one inner IP header) as being a valid
tunnel, since they were noth applied at the same time and will be
decapsulated together. The critical issue is how fragmentation is handled
and what headers are checked upon decapsulation. (We stopped using the
term "transform" a long time ago, so I don't know how to reconcile some of
what you said, but ...) Yes, we've tried to move toward an IP-in-IP tunnel
notion over time. Ran used to argue that there was a fundamental difference
between what we were doing and IP-in-IPf tunneling, but I've not been able
to really understand what the differences were, so they have tended to blur
over time.
>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.
The current crop of running suystems embody a variety of characteristics,
not all of which are consistent with one another, or with the specs. Also,
none of the ones I;ve seen is completely compliant with the specs, despite
receiving ICSA certification! So, no, I don't want to change the spec to
match what the current crop is doing, if that deviates from what this WG
has labored long and hard to agree upon. The last time we adopted this
rationale we deleted the ability for ESP to have null encryption because
the "then current" crop of implementations didn't support it; this feature
was rediscovered as important a number of months later, and added back at
that time. Let's not repeat history.
>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? %)
At this point, not me!'
Steve
Follow-Ups:
References: