North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: BGP Security and PKI Hierarchies (was: Re: Wifi Security)

  • From: Rodney Joffe
  • Date: Wed Nov 23 12:38:17 2005

On Nov 22, 2005, at 2:59 PM, Randy Bush wrote:

[ you know all this, but i think it is worth going through the
  exercise ]

That said, I think the problem is that we need an algebra of trust
that will let a program, not a human, decide whether or not to trust a
certficate. You don't want to accept something if it's a twisty loop
of subsidiaries or allied evil ASs vouching for each other. OTOH,
there are some situations where we know that absolute trust is
indicated -- say, 701 signing 702's certificate, or an upstream
signing the address certificate for a customer.

And it's not just honesty, it's competence you're assessing -- we've
all seen problems when major ISPs didn't get their filters
not exactly.  there are two trusts here.  i have to accept that
asns as incompetent at configuration as i are attesting to prefixes
and paths or i won't be able to get to a large part of the net.

but this is orthogonal to my trust in their competence to attest to
the identity of other asns by cross-signing others' certs.  i could
have a business relationship with an asn whose routing competence i
What happened to responsibility? Where does it fit in to the issue? And if not, why not?

Pushback comes to mind ;-)

As much as they enjoy sharing brew sessions, I don't think I've often seen or heard of 701 and 2914 ever having to point out downstream misbehavior to each other. And I *think* they both have sticks that are big enough that they never have to be waved. So if we can assume that this is true of the other folks of "similar" size, then which are the large parts of the net you can't or won't be able to reach? Or are your peers not prepared to own responsibility for their announcements? And if not, why not? And I refuse to accept the reasoning that seems to have smothered pushback - Networks don't have to deploy new code or equipment or capabilities to control internal or downstream announcements.

To save some resulting noise on the list; Pointing to the example of spam is mostly a red herring. Today's spam is mostly generated by the hundreds of thousands of compromised machines that originate most of it, which creates its own difficult problems for the geeks who work at that layer. Nonetheless, to a large extent enforced responsibilty has worked for spam. The problem has changed. Paths and prefixes are a lot different to the current spam problem.

NOTE: This is *not* an invitation to start a thread on spam or the botnets that enable them. It doesn't belong on this list, so take it elsewhere.

As another thought: - Love 'em or hate 'em, the PSTN doesn't have this problem. Is there anything helpful to learn from there, ignoring the perennial layer9 discussion ratholes?