[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 Gleeson <BGleeson@shastanets.com> writes:
> 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 ?
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.
> 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 ?
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.
ben
Follow-Ups:
References: