[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inbound policy verification
Hi Valery,
> So, if I have policy with some SPD entries that demand secure
> communication with some number of specific hosts/networks and with
> last entry, that allows insecure communication with the rest of the
> internet, does this mean, that such policy will allow *any* host,
> including those specific, to communicate with me insecurely?
If the matching entry specifying strong security parameters for particular
hosts/nets precedes the wildcard bypass-IPsec entry, then the SPD lookup
settles on that matching entry (strong security with specific hosts).
In Rich's example the incoming packet's selector did not match the selector for
the host-specific SPD entry. So the lookup dropped through to the later entry
(for a whole network) in the SPD.
IMHO having a very permissive wildcarded entry at the end of the SPD can be
slightly risky, from a s/w engineering perspective. A small error in a
host/net-specific entry might cause that specific entry not to match in some
situation when it should have. So instead the wildcarded bypass entry matches,
and traffic on that connection transparently bypasses IPsec processing.
(Packets are sent in the clear and no alarm bells ring....)
If there had been no wildcarded bypass entry at the end of the SPD, then the
connection would have failed and (presumably) someone would notice the
communication failure relatively quickly.
[...]
> > > 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.)
>
> In this case, what is the purpose of total ordering of SPD entries
> (which architecture draft requires), if we still need to look
> through all of them?
(See my comment above about Rich's example.)
You need to keep looking until you find one that matches (or you run out of
entries to examine). More than one entry might have a selector that matches
the packet -- the first matching entry (if any) in the SPD is used.
-Lewis
Follow-Ups:
References: