> One abstraction that might be useful is the idea of a "reachability matrix"
> -- what end hosts and applications/services should be able to talk to each
> other. This gets at a network-wide view of reachability control, rather
My own naive view sounds something like this; express the graph
that is the network, and express what is and is not doable within the
graph because of the security policy. Derive the ACLs from the
specification of the network. As you alude to, other objects within
the network drive who can communicate with whom and are just as
important to specify.
> of ACLs. We've worked out one simple example in Section 2.1 of
>
> http://www.cs.princeton.edu/~jrex/papers/4D-report.pdf
>
> that might be of interest. More broadly, I think it would be great to have
> an integrated view of the effects of ACLs, routing, and NATs on who can
> communicate with whom.
Sounds delightful, exactly the kind of concrete I want to hear
about. Thanks!
Longer term, one of the things I'm interested in/concerned about
with any kind of network configuration automation is that it can
express the brain surgery on self problem: without really good
(preferably proovably good) out of band management, a network
configuration manager can trivially destroy the network's ability to
communicate with itself.
Worse, it can be directed to do such destruction in an oblique way
by its user: how is a network configuration tool any good at all if I
can *insist* that I know something it doesn't, and please produce a
configuration that appears completely irrational to the poor little
computer program, and no, I don't have time to prove its rationality
to the tool?
This sort of problem comes down to what prompted Steve Traugott to
write the Turing equivelance paper. While I don't agree with 100% of
the upshot there, the point remains that deep computer science lurks
within this seemingly simple "perfectly doable".
References:
|
|
