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

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

Ben,

> > 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.

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? 
 
> > 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.
> 

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.
 
Bryan
Follow-Ups: