[Trust-router] How much are trust routers trusted?

[Sam Hartman <[e-mail]>]

Hi.

One obvious question folks who have worked on routing security ask when
they examine trust router is how well does it handle Byzantine failures.
most generally, a Byzantine failure is a failure in which some component
does not act according to spec. This can cover everything from hardware
failures to attack.

We've found that BGP speakers are compromised often enough that it is
desirable to investigate and specify solutions to some forms of BGP
attacks; SIDR is working on that now.

I'll first talk about the actual trust/threat model and then talk about
why we believe that's a reasonable model.

A trust router keeps track of which statements each of its peers are
authorized to make. These are roughly either requests to establish a
temporary identity so that a source realm can communicate with a target
realm or route announcements. These authorizations can be constrained on
a number of axes.

However within the set of authorized statements a trust router is
trusted not to have Byzantine failures. For example if trust router Byzantine2
authorizes  TR1 to request temporary identities on behalf of realm A,
then it trust TR1 not to request a temporary identity claiming to be on
behalf of realm A when it is really on behalf of realm B.

There are a number of differences between trust routers and Internet
routing. We imagine that fewer trust routers will be needed than BGP
speakers. Typically, if an organization needs a trust router, it will
only run more than one instance for redundancy and fault
tolerance. Trust routers can and should be deployed in secure data
centers and managed using the same procedures as AAA servers, Kerberos
KDCs and other critical security infrastructure.

Trust routers near the center of a trust connectivity graph will often
have significant authorizations and if compromised would be able to do
significant damage. However, trust routers on the edges of the graph and
clients on the edges of the graph will typically have very constrained
authorizations. These nodes may be able to act on behalf of one
organization or a small number of organizations.
While a compromise of these nodes might have significant consequences
for that organization, constraints in authorization will minimize the
impact globally.

Also, note that AAA servers, identity providers and other components of
the federation infrastructure that trust routers are designed to
facilitate already have a similar threat model.

Technology similar to SIDR could be applied to trust router in some
instances. However, one of the assumptions behind trust router is that
credentialing and security associations are maintained on a pairwise
basis between each set of trust routers. There is no assumption that a
set of trust anchors is shared across the graph or even across any
significant segment of the graph. Such common trust anchors are required
to make something like SIDR work. In addition, there is a specific
desire in some (but not all) deployments to insert trusted intermediates
that perform jobs such as attribute rewriting.

Finally, note that hardware security modules or other approaches
resistant to compromise can be used for the pairwise security between
trust routers. This will serve to limit the scope of a compromise. Once
any temporary identities established during the scope of the compromise
are expired, then the trust infrastructure is trustworthy again.