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

RE: inbound policy verification



Charlie, thanks for your thoughts re my questions!

> First, in the common cases, I do not think one should get into the
> state described in the example you presented.  What has never been
> mentioned in any of the discussion on this topic that I've seen, was
> how the lower precedence "net" policy SA for the host specified in the
> higher precedence "host" policy was created.  It seems to me that the
> policy module should have told ISAKMP, or whatever KMP was used, to
> reject the net policy setup, since the ordered search of the inbound
> SPD (at SA setup time) would have first found the matching host entry
> and never proceeded to find the net one.

Let me restate the example, for those who've forgotten it:
the inbound SPD in host H1 contains two policies. Policy P1
has a source address selector for a specific host H2.
Policy P2 has a source address selector specifying
a net N2. Host H2 belongs to net N2. Finally, the selectors
in both policies are "take from policy" NOT "take from packet".
So there is one inbound SAD entry corresponding to each policy.

The idea is that all hosts in net N2 (except for host H2) should
share a single SA1 when sending to host H1.
Host H2 should use a different SA2 when sending to H1.

I think this inbound policy on H1 should *enforce* this.
If somehow H2 should use SA1 to send to H1 (maliciously or accidentally),
then H1 should reject the packets.

> Do you agree that it net SA should never have been created?  If not,
> what scenario occurred to create it?

My understanding of ISAKMP is very incomplete, but from what I understand,
it would not let this situation occur because it can't
negotiate an SA that multiple senders can use. So for my example,
assume manual configuration or some other KMP.

> The basic problem, in my opinion, is that the architecture describes a
> unidirectional model, but the KMP uses a bidirectional one.  Where are
> the mechanisms needed to reconcile these perspectives defined?

I agree, the fact the architecture is more general than what ISAKMP
can support is a source of confusion.

> A third piece of the problem is the desire for "protocol, not
> implementation" that we all desire.  At one point, there was a SAM and
> backpointers to the SPD entries.  I think that was removed as being
> "implementation", not "protocol".  Given that an SA may be shared
> between bundles, and a bundle may be used by multiple policies (or SPD
> entries), there may well be lists of lists that would need to be
> searched (at least if we want to allow sharing either now or in the
> future).  I guess there is an engineering tradeoff between searching
> the SPD until one finds something acceptable and maintaining the
> backpointer lists and searching them.  Maybe the architecture document
> made the wrong choice.
> 
> Assuming that the security implications are the same, what do you
> think we should do?  The architecture document could specify the
> backpointers (whether or not that is how an vendor chose to implement
> the functionality they describe).
> 
> However, are the security implications the same?  Your point is that
> it might be possible to exploit the "keep searching" rule.  Would
> that, or related, vulnerabilities be reduced by using backpointers?
> We'll have to think a bit about that, I suspect.  The answer may
> depend, in your example, on whether the KMP could have correctly setup
> that net SA.

I think the security implications are not the same.
With the "keep searching" rule, the inbound SPD will not
enforce the desired policy for H2 in the above example.

I think the architecture should define the desired semantics.
Then implementations would be free to achieve those semantics
using any optimizations they care to.

Here's a modification of the example that might be simpler:
suppose inbound policy P1 (for packets from H2)
has an IPsec action of "discard"
and inbound policy P2 (for packets from N2)
has an IPsec action of "bypass".
No SAs or KMP involved, just filtering.

Then clearly when I receive a packet from H2, I want to stop
at the first matching policy (P1) and discard the packet, right?

Thanks,
Rich