[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ESP and AH used in tunnel mode by a Security Gateway
Dan, Tim
> > 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.
I agree that regarding the encapsulation mode as an attribute
of the bundle, rather than as an attribute of the SA, is the
cleanest way of looking at this. Should this imply that for a
bundle, all the encapsulation mode values for each protocol
(encoded in the Transform payloads) should have the same value,
i.e. all transport or all tunnel, and that mixing them should
be prohibited ?
A couple of other questions for clarification
The architecture spec talks about a wildcard value for the
encapsulation mode, allowing a single SA to be used for
both tunnel and transport, and says that a host must support
this. However there is no codepoint assigned in the IPSEC DOI
for "wildcard". How would I set up an IPSEC SA to use a wildcard
encapsulation mode, and why would I ever want to do this ?
Although it is spelled out clearly that for an ISAKMP SA,
there cannot be two proposals with the same protocol-id (i.e.
ISAKMP), I didn't spot any such restriction for Phase 2 SA
negotiation. Does this imply that if I want to negotiate an
ESP SA, using either DES or 3DES, I've got a choice in encoding
this as 1 proposal with two transforms, or 2 proposals each
with one transform ?
Bryan Gleeson
Shasta Networks.
Follow-Ups: