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

Mailman List Mirror (Read Only)
1

Actually, I don't do certs; it's my evil-minded friends...

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.

Furthermore, given that a trust algebra may yield a trust value, rather
than a simple 0/1, is it reasonable to use that assessment as a BGP
preference selector? That would tie the security very deeply -- too
deeply? -- into BGP's guts.

    --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

2

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

the bottom line is which would i trust more in the latter sense, an
asn cert signed by an external hierarchy or a cert signed by one or
more of 70x, 1239, 2914, ...?

it seems more natural if the identity trust is congruent with the
trust of business relationships. a similar reason for my prefering
sbgp-like architectures, the attestation model is congruent with
the routing model.

it turns out most folk have a business relationsip with an rir.
but some don't, e.g. jis. and those who do not have become very
worried about their ability to route on the internet being at the
mercy of organizations some of which have specifically said that
legacy cert renewal would be tied directly to the isp or entity
paying the rir as if they had gotten the legacy address space from
the rir (i think i have sensed some backing off from this rather
extreme position). but the point is that some folk are not happy
with their identity being controlled by an external party with no
skin in the game with whom they would otherwise have no
relationship.

[ before you say it, i have suggested that a pseudo-rir be created
  for legacy asns and prefixes ]

in particular, i have a business relationship with 1239 and 2914,
but no business relationship with ripe. should i trust ripe's
signing the identity of anja's asn more or less than 666 signing it
and 666's identity being attested to by 1239 and 701, the latter
likely being cross-signed by 1239 and 2914?

Furthermore, given that a trust algebra may yield a trust value,
rather than a simple 0/1, is it reasonable to use that assessment
as a BGP preference selector? That would tie the security very
deeply -- too deeply? -- into BGP's guts.

i am aware of other research proposals where routing trust is
ordinal or even real depending on various distances.

randy

3

Randy:

>for how many years have i been asking you and your evil-minded cert
>designing friends for a pgp-like web of trust cert that could be
>used for just this application?
>

Steven B:

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.

Well, there's the rub. You know who runs AS701 and AS702. Presumably most
of us do (although I don't know who runs 702 off the top of my head. 701
is UUNET/MCI, no? I don't do BGP).

I like the web 'o' trust idea, but the idea is that the *end-user* is
supposed to know what's legit and what isn't. In most cases, we're not the
end-users.

4

I also seem to remember Bill Woodcock suggesting this at some ARIN
meeting in 2001 or 2002. If I recall he proposed that this be somewhat like a document trust with no operations (beyond providing NS service)
and when somebody needs a service the ip block would have to be moved
to regional RIR.

If your proposal for separate legacy RIR is different, then you need
to have a model on how it would be run and how its operations would
be financed (especially security procedures associated with assigning certs, etc).

5

Right. The idea was to lock down things which were in the legacy space,
unless people were prepared to undergo the full scrutiny of having them
transferred into an RIR (basically dampen the rash of hijackings), give
ARIN a clear way around the free-services-to-legacy-holders issue, and
give legacy holders a way around the threat-of-ARIN-trying-to-charge-
them issue. Seemed like a good idea to a lot of ARIN folks at the time,
and it was starting to get some headway, when the RIPE and APNIC folks
realized that it would deprive them of the future possiblity of reclaiming
legacy space, which they promptly nabbed using the extraordinarily
ill-considered ERX policy, which just took the problem and multiplied it
by five. Basically irreversibly.

So as nice an idea as it was, I'm not sure it has legs in this post-ERX
world.

                                -Bill

6

the idea is that the *end-user* is supposed to know what's legit
and what isn't.

no. all asn admins, including tier 1 through tier 42 and leaf
asns.

users are not involved in routing, except of course when the
ivtf is desperate to shim up v6.

randy

7

Bah. Forgive my stupidity, please. We got into the discussion of PKI and
PGP-style trust models and I failed to remember the TLA in the subject.
You're right, my comment doesn't apply to BGP (at least not for most
end-users I know).

8

What happened to responsibility? Where does it fit in to the issue? And if not, why not?

Pushback comes to mind :wink:

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

9

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?

responsibility for what?

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.

uh, i really do not follow what you are saying. the point is that
the trust model for attestation of identity need not be the same
trust model for the attestation of prefix ownership or of as-path.

in operation, this means that there could be isp- (or ufo-)centric
isp identity certification (a la web of trust, for example) which
could have a very separate cert chain from that of address space
allocation, which, aside from the legacy issue, could come via the
rirs.

randy

10

sorry to be slow/cryptic.

My issue is that if ISPs a) only announce networks that they know (for different values of know - but hopefully based on some kind of trust in the RIR's data) they are authorized to announce, and b) took responsibility for the behavior of the paths or prefixes they announce, and the bits that are originated in those paths or prefixes, and took action to stop the bad behavior, the issue of trust paths might not be so critical.

I am not arguing in any way with your views or thoughts related to trust models. I was merely drifting back to the original issue of rogue players in the path, and suggesting that there is an alternative method of mitigating the problems caused by those players that doesn't require protocol work. Ignore the deviation in the thread.

/rlj

11

My issue is that if ISPs a) only announce networks that they know
(for different values of know - but hopefully based on some kind of
trust in the RIR's data) they are authorized to announce, and b) took
responsibility for the behavior of the paths or prefixes they
announce, and the bits that are originated in those paths or
prefixes, and took action to stop the bad behavior, the issue of
trust paths might not be so critical.

agreed up to the last clause. but my base concern is not
config problems, but rather intentional attacks on the routing
system. not to deny that there are config problems, they're
rife and a major pita. but i suspect that the most agregious
will be dealt with by direct approaches to the security issues,
e.g. ip address ownership, as-path intent, etc.

randy

12

Rodney Joffe wrote:

As another thought: - Love 'em or hate 'em, the PSTN doesn't have this problem.

Uh, PSTN does have this problem too. If you are part of SS7 you can totally
fake call origination information. This has been and still is abused for
criminal-malicous activities and 'billing-optimization'. Remember the lawsuit
of SBC et al against WCOM regarding termination charge misrepresentation?

In the actual PSTN routing of a call the destination information is not
authenticated either. The national regulators run registries where the
carrier-owner of each number block is registered. Very much like in the
RIR system. Depends on country a bit though. In some it's more strict
and in others less.

13

* Steven M. Bellovin:

Furthermore, given that a trust algebra may yield a trust value, rather
than a simple 0/1, is it reasonable to use that assessment as a BGP
preference selector? That would tie the security very deeply -- too
deeply? -- into BGP's guts.

Wouldn't this provide significant economic incentive towards gaining a
high value on this metric? I'm not sure if this a good idea because
even if you call it a "trust metric", it does not have to correspond
to ethical behavior.

14

* Bill Woodcock:

Right. The idea was to lock down things which were in the legacy space,
unless people were prepared to undergo the full scrutiny of having them
transferred into an RIR (basically dampen the rash of hijackings),

In the end, this boils down to disappropriation. Early address space
is owned, not assigned, as far as I can tell.

15

Wrong concept of "trust". There exist vendors that I *expect* will
treat me in an unethical way, while being totally open as to their identity.

Think of it as going to buy a used car, and *knowing* that there are shady
and unethical dealings going on, but knowing to a high degree of certainty
that the salesmen perpetrating the fraud are in fact authorized and are acting
on behalf of the dealership, and aren't somebody in a cheap suit that came in
off the street and borrowed the office while the real salesman was out for a
few days for a family emergency....

(And yes, there actually *was* somebody who pulled that fraud a while back nearby
here - I wish I could find a citation...)

16

* Valdis Kletnieks:

Wouldn't this provide significant economic incentive towards gaining a
high value on this metric? I'm not sure if this a good idea because
even if you call it a "trust metric", it does not have to correspond
to ethical behavior.

Wrong concept of "trust". There exist vendors that I *expect* will
treat me in an unethical way, while being totally open as to their
identity.

But ensuring identity is a good measure of trust, either. Identity
only matters if you want to do something to the perpetrator in the
real world. This seems to be the rare exception, not the norm. I
expect people just to tweak their filters and move on.

(It would be more interesting if each real-world entity could only
have one digital entity, but this is impossible to achieve, especially
in context of IP routing.)