BGP Security and PKI Hierarchies (was: Re: Wifi Security)
Rodney Joffe
rjoffe at centergate.com
Wed Nov 23 16:23:52 UTC 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
More information about the NANOG
mailing list