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

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

On 26 Jul 1998 23:53:59 EDT you wrote
> 
> Tim  Jenkins <tjenkins@TimeStep.com> wrote (with removed MIME headers):
> 
> > Why has no one referred to "protection suites" as defined in the DOI
> > document and Oakley or "SA bundles" as defined in the architecture
> > document?
> > 
> > Use of these concepts would simplify these discussions, since it would
> > reduce the ambiguity of application. For example, a gateway could apply
> > an IPCOMP-ESP-AH bundle as
> > 
> > 	IP [AH ESP PCP] IP DATA
> > 
> > where a host could do either
> > 
> > 	IP [AH ESP PCP] IP DATA	(tunnel mode)
> >   or  IP [AH ESP PCP] DATA	(transport mode)
> > 
> > In this case, there's no argument about whether AH and ESP are tunnel or
> > transport; they are part of a bundle that is tunnel or transport.
> 
> Unfortunately, in ISAKMP, there is no way to attach an attribute to a
> protection suite, but only to a transform.  (We could resolve this by
> standardizing on including the same attribute in each transform of the
> suite, or some such solution.)

  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.

  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.

> 
> > An example:
> > 
> >   H1 --- SG1 ----- H2
> >           <-- AH --> (tunnel mode)
> >    <---- ESP ------> (either mode)
> 
> 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.

> which contains no more information than the slimmer:
> 
> IP(SG1->SG2)  AH  ESP  IP(H1->H2)  Data

  Which, provide you're talking about IPv4 and the non-deprecated transforms
is no more secure than the even slimmer:

IP(SG1->SG2) ESP IP(H1->H2) Data.

> Technically AH is in transport mode here, while ESP is in tunnel mode
> if you look at the individual transforms, or we are using an AH+ESP
> protection suite which is itself in tunnel mode if you use the
> protection suite concept.

  It's an SA bundle, not a protection suite, but that's the idea. AH isn't
in transport mode.

> In theory, to accurately represent all possible situations, you'd need
> ISAKMP messages of the following form:
> 
> Proposal 1
>   Propsal attributes (*)
>   Protocol 1
>     Transform 1
>       Transform attributes
>     Transform 2
>       Transform attributes
>     [...]
>   Protocol 2
>   [...]
> Proposal 2
> [...]
> 
> where the proposal attributes (*) field is the only fundamental
> difference from what we've got right now.  We can emulate this in our
> current language by playing tricks with the Transform attributes.  The
> only problem is getting consensus on how to do this.

  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.

  Or we could solve this problem by just doing away with AH.... :-)

  Dan.
Follow-Ups: References: