[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ESP and AH used in tunnel mode by a Security Gateway
Bryan,
> > I'm guessing that since the encapsulation mode attribute is optional,
> > the wildcard would be the absence of this attribute. I think that it
> > is a valuable thing to do on a Security Gateway which can also act as
> > a Host implementation. That way, communication between hosts behind
> > the SG to the remote end is in tunnel mode and between the SG and the
> > remote end is in transport mode. This is the most efficient way to
> > handle bandwidth in this case, since an unnecessary IP header is not
> > added.
>
> The spec says that an omitted encapsulation mode attribute means
> "unspecified (host-dependent)". If the "host-dependent" qualifier
> wasn't there I would have taken this to mean "wildcard", but
> because it is there I'm so sure. What is host-dependent about the
> semantics of wildcard as defined in the architecture spec? Isn't
> it just that transport and tunnel mode packets can be carried on
> the same SA?
Perhaps it makes sense to add a wildcard value for this attribute?
I've been treating it as host-dependent on my system, but would like
to have the ability to configure this mode with other vendors.
> > Yes, as long as the proposal numbers are distinct. Otherwise, the two
> > proposals are AND'ed together. I really don't know how you would
> > perform ESP AND ESP on a packet and call this a single Security
> > Policy. This seems to be a necessary evil in order to allow the full
> > AND/OR semantic described in ISAKMP 4.2.
> >
>
> Seems unfortunate that the protocol allows exactly the same semantics
> to be encoded in two different ways, as it increases the chances of
> interoperability problems and the amount of code needed. I don't think
> there would be any reduction in the range of things it is possible to
> express if there was a rule that proposals with different proposal
> numbers had to have distinct (bundles of) protocol-ids.
Hmm.. There is a reduction, but I don't know if it is necessary. You
need the flexibility to negotiate the following policy:
(ESP(DES) and AH(MD5-HMAC)) or (ESP(CAST) and AH(SHA1-HMAC))
(which does not permit DES to be used with SHA1 nor CAST to be used
with MD5). I can't see why this would be a particulary valuable
proposal unless a class of encryption/authentication algorithms is
found which interact poorly with one another (ie. authenticating using
algorithm A1 the data encrypted using algorithm E1 leaks key bits for
either A1 or E1, while A1 works fine with E2 and E1 works fine with
A2).
But, given that our current knowledge is necessarily uncomplete, I
wouldn't want to throw this away just yet.
ben
References: