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
straight.



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
question.




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?



/rlj