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