[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inbound policy verification
Hi Rich,
> The part I don't understand is the provision that if the SAs don't match,
> then the implementation should continue searching the inbound SPD until it
> either finds a policy that accepts the packet, or it's checked all the
> policies in the inbound SPD.
>
> This would seem to make it impossible to enforce a more-restrictive policy
> in the inbound SPD when there is also a more general policy.
I suspect you're confused about the general semantics of the IPsec policy
assertions. The basic conservative security principle is that everything is
prohibited unless it is explicitly allowed. In the absence of policy assertions,
nothing is allowed. Each policy assertion makes a purely *positive* statement --
some particular set of actions is allowed. Negative statements aren't needed
in this framework because anything not explicitly mentioned by the policy
assertions is banned by default.
> For example, suppose I'm a host H1 and I expect to receive packets from a
> network N2, but there's a particular host H2 in N2 for which I have
> different security requirements. So I create two policies in my inbound SPD
> - first one with source address selector H2, and the second one with source
> address selector N2 (an address prefix or range). The first policy results
> in a SAD entry with security association SA1, and the second results in a
> SAD entry with security association SA2.
The policy entries you're creating in this hypothetical example don't mean
what I think you intend. The policy using N2 as a selector allows certain
kinds of security associations to be established with any host matching the
N2 selector, *regardless* of what other policy assertions are in the SPD.
Meanwhile the policy that selects on H2 allows certain other kinds of
security associations to be set up with H2, *in addition to* any other
kinds of security associations that may be allowed by other policies in the
SPD.
> Now suppose I receive a packet from H2 with the "wrong" security headers. I
> process the packet and discover SA2 from the destination
> address/SPI/protocol triple and do the required authentication/decryption.
> Now I search the SPD. The packet's selectors match the first policy but the
> wrong SA was used to receive the packet. I want to reject this packet.
>
> However this provision says I should continue searching the inbound SPD. I
> find the second policy; the packet's selectors match it also. SA2 is the
> right SA for this policy, so I accept the packet.
Your policy entry for N2 needs to be narrowed to achieve the exclusion you
want. Instead of a policy entry that specifies that the "wrong" parameters can
be used in communicating with *any* host in network N2, that entry needs to
specify that the "wrong" parameters can be used in communicating with hosts
X2, Y2, Z2, etc. (Recently there's been some discussion on the list about
increasing the expressiveness of the ID syntax to make it simpler to specify
policies covering nontrivial combinations of hosts, subnets, etc.)
Hope this helps,
-Lewis
<mailto:pseudonym@acm.org>
Follow-Ups:
References: