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