[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: use of client IDs
Dan,
> Under what circumstances would you use the outbound SA that was
> created with this inbound SA? Your inbound SA is "anyone to me"; your
> outbound is "me to anyone". If what you mean by "it should not imply
> a single route" is that under some circumstances you would not apply
> this SA to outbound traffic then why did you negotiate such policy?
A Quick Mode exchange to set up an IPSEC SA does not exist in isolation,
but is relative to a previously negotiated ISAKMP SA. Thus the semantics
of an absent client ID are "anyone behind this trusted gateway", not
"anyone". You seem to be implying that the security policy must be
symmetric, which I did not think to be the case, given that as SA is
explicitly defined to be simplex.
> The client identities identify traffic to which security is applied.
> What you seem to want is to protect everything that's routed through
> some particular route. I don't see the point and that's real ugly.
> Routing updates would have to modify your security policy. Hmmm. Not
> too secure considering routing protocols aren't secure (yet).
I think that forcing the inclusion of the client ID actually ties the
security policy more tightly to routing than otherwise. If I have a site
which is multihomed to the Internet via a number (n) of security
gateways,
and internally uses m subnets, then I need to cater for a host on any
subnet being reachable via any gateway, leading to a total of M*N SAs,
between this site another remote gateway. As routing changed, a host
could "move" from being behind one gateway to another, so the security
policy has to take that into account.
I still haven't seen a convincing reason for precluding the semantics
of "any host reachable via this trusted gateway" to be conveyed in an
IPSEC SA establishment. I would think that this would be a common
part of many security policies, and that the identity of the trusted
gateway would be sufficient to determine the matching SPD entries at
a gateway that received an incoming establishment request.
Bryan