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

RE: DataStructure for Storing SPD,SA Entries

At 9:23 PM -0700 10/18/01, William Dixon wrote:
>Deconflicting overlapping policy (e.g. port ranges, subnets, all TCP to
>Any IP vs. All traffic to 1.1.1.1) was the main point why RFC 2401 says
>filters must be manually ordered.

As the author of the standard, I think I can provide a somewhat 
better characterization of the rationale for ordering.

The 5 selectors used in the SPD correspond to what one finds in many 
forms of network access control enforcement devices that operate at 
the IP and transport layers. They define a lattice, not a total 
order, and thus they must be ordered so that the effect of the 
security policy they define, in aggregate, is deterministic. This too 
is characteristic of all ACL-style enforcement mechanisms that deal 
with entries which forma lattice.  (Go back and look at the Multices 
time sharing system and its ACLs in the early 70s, for example. This 
is not new stuff.)

>However, I'll posit that, when talking about IP packet filters that are
>matched only at the IP level (or below), manual ordering is enforceable
>only if your policy comes from one source.  Clearly if policy comes from
>two sources, and if it overlaps, it would be impossible to guarantee the
>outcome of each original manual ordering.  If your run-time effective
>policy comes from a static policy definition, then enhanced from a local
>command line, possibly enhanced by local service or application API
>calls to protect their traffic, and perhaps filters are generated by a
>default response policy (accept whatever is proposed by the initiator)
>when nothing else matches inbound IKE QM requests, then you must have an
>automatic, total ordering, decorrelation algorithm.
>
>With many new IETF protocols specifying their traffic to be protected by
>IPsec, and some like iFCP in the IP Storage group requiring tunneling
>mode instead of transport mode, enforcing strict admin manual ordering
>of filters in the static policy he applied last week does not appear to
>be feasible for an end-system.

I disagree. There always has to be one, accountable entity 
responsible for the SPD associated with any device. If there are to 
be multiple sources of SPD entries, someone has to make sure that 
they don't conflict, and this is more that just an ordering issue.

>To the extent possible, I've encouraged other protocols to request IPSec
>transport mode 5-tuple specific IPsec SA pairs.  This is how L2TP
>requests IKE quick mode to establish an SA pair for src me, dst gw, UDP,
>src <specific>, dst 1701.

This seems like a discussion of how to use a TLI request for an SA, 
which is distinct from the SPD requirement. Even as an individual 
user, I would generally like to specify a policy for my traffic that 
cannot be overridden by applications.  This is the whole notion 
behind personal firewalls.

>  However, many people have argued that they want an IPSec SA established
>for TCP src <any>, dst <their port>, so they don't get additional
>overhead of QM's & IPSec SA pairs per new connection.  I see their
>point.  However, different source ports could imply different
>applications or even identities connecting to the same service port at
>the destination IP.  In L2TP's case, a new UDP source port connecting to
>the same destination port could mean a new L2TP tunnel (L2TP can do new
>tunnel sessions across the same port pair with session IDs).  The IKE
>identity used is that of the machine, thus it could have requested src
><any>, dst 1701 in QM.  We just had to decide, and chose the "safer"
>full 5-tuple.  L2TP itself identifies the user for each tunnel in it's
>PPP negotiation completely independent of IPsec.
>
>Anyway, decorrelation ordering based on most specific seems reasonable,
>since IP will see a full 5-tuple outbound and inbound.  Just hope the
>other guy implements the same ordering, so the return traffic doesn't
>use a different IPSec SA than the pair you initially established...

Decorrelation does not depend on any sense of "most specific." 
Decorrelated SPD entries do not overlap with one another, which is 
why there is no requirement for ordered searching of a decorrelated 
SPD.

Steve
References: