[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP and AH used in tunnel mode by a Security Gateway
Daniel Harkins <dharkins@cisco.com> writes:
> I thought a "protection suite" was an ISAKMP notion not an IPSec notion.
> Each protection suite is, in fact, represented as an offer by a single
> transform which contains the attributes to describe the protection suite:
> encryption algorithm, hash algorithm, authentication method, group. Protection
> suites are not logically related to each other.
Oops.
> For IPSec we have SA bundles and there is verbage in the IKE document that
> states the all offers in a single Quick Mode are logically related. The
> example given is for PFS and it states that each offer must have the same
> group attribute, and that client identities, when passed, apply to all SAs.
> Unfortunately this does not explicitly spell out the encapsulation attribute.
> Sigh. Since that is not an IKE attribute perhaps it shouldn't, but something
> should.
Hmm... it makes more sense for this to be in draft-ietf-ipsec-isakmp.
I expect to find most of the details for generating IPsec SAs in
either DOI or ISAKMP. (Key material generation being the one piece
tied necessarily to IKE.) The DOI probably ought to define which
transform attributes need to be consistent across the proposal.
> > Yes. That situation is necessarily unambiguous (and is, in fact two
> > protection suites). However, the following:
> >
> > H1 ---- SG1 ============== SG2 ---- H2
> > <-- AH + ESP -->
> >
> > is not. There, if we only allow the options enumerated in the
> > Architecture document, and follow the "Security Gateways must always
> > use tunnel mode" rule, we end up with the following bloated packet:
> >
> > IP(SG1->SG2) AH IP(SG1->SG2) ESP IP(H1->H2) Data
>
> I thought we had agreed that that is not necessary and that in
> IP AH ESP IP DATA, AH is in tunnel mode. The two protocols are negotiated
> together, they have the same retrictions (from the ID payloads), and,
> if PFS is negotiated their keys are related. They're functionally a unit;
> a bundle.
Great. Derrell -- can we get this into the DOI document as soon as
the RFCs are cut?
[Lots of my rambling cut out.]
> I thought we already did. In <h03ebsz4ke.fsf@carp.morningstar.com> on the
> 23rd of July you responded to my point that AH is for all intents and
> purposes in tunnel mode by saying "I agree wholeheartedly". No one has
> said anything to the contrary. And I don't think adding new payloads or
> fields to existing payloads is necessary. If anything we just need some
> further clarification about the relatedness of proposals and the transforms
> they encompass.
I guess I'm just beating a dead horse. I'll stop now.
> Or we could solve this problem by just doing away with AH.... :-)
Unless, of course, you start _that_ conversation up again... :) :)
ben
References: