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

Mailman List Mirror (Read Only)
1

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.

So when one receives an update, which part is it that you verify with
the certificate derived from the RIR chain and which part is it that you
verify with the certificate derived from the web-of-trust? I'm guessing
the answer in part is that there's a signature attesting to the
prefix origination based on the RIR-rooted certificate, but I'm not
certain what you are suggesting you would sign with the web-of-trust
based ISP identity certificate (the origination announcement, indicating
that it is not only authorization to originate but also source
authentication?)

If the RIR-rooted certificate says that ISP XYZ is allocated prefix P,
does the web-of-trust ISP identify certificate have to say exactly
"ISP XYZ"? Is that exact match the link between what the RIR-rooted
cert is proving and what the web-of-trust identify cert is proving?

--Sandy

2

So when one receives an update, which part is it that you verify with
the certificate derived from the RIR chain and which part is it that you
verify with the certificate derived from the web-of-trust? I'm guessing
the answer in part is that there's a signature attesting to the
prefix origination based on the RIR-rooted certificate, but I'm not
certain what you are suggesting you would sign with the web-of-trust
based ISP identity certificate (the origination announcement, indicating
that it is not only authorization to originate but also source
authentication?)

something like

the rir attests to the delegation of the prefix and an asn to the
identified isp.

the isp signs, using their isp identity to
  o originating from the asn
  o originating that prefix (in sbgp, toward another isp)
  o possibly delegating a subset of that prefix
  o passing other prefixes on (in sbgp, toward ...)

but either you, smb, or jis should be able to get it more correctly
than i.

randy

3

According to what I understand, there have to be two certificates per
entity:

  one is the CA-bit enabled certificate, used to sign subsidiary
  certificates about resources being given to other people to use.

  the other is a self-signed NON-CA certificate, used to sign
  route assertions you are attesting to yourself: you make this
  cert using the CA cert you get from your logical parent.

-George

4

So how is the 2nd one different from the first? In both cases you give
permission to certain use of a resource under your control. If you look
at it the only difference is:
  - To authorize reallocations you sign request based on another entity's
    ORG object,
  - To authorize announcement you sign request based on another entity's
    ASN object (can be your own ASN).

But in general ASN object is also basically a type of ORG with extra data
(i.e. ASN# and ASN name), so I don't see why you can't use one cert (if
somebody does not list AS# for their org I guess they can't route independently).

5

the important distinction is that the certificate used to sign resource
assertions doesn't have the CA bit set.

-George

6

According to what I understand, there have to be two certificates per
entity:

  one is the CA-bit enabled certificate, used to sign subsidiary
  certificates about resources being given to other people to use.

  the other is a self-signed NON-CA certificate, used to sign
  route assertions you are attesting to yourself: you make this
  cert using the CA cert you get from your logical parent.

probably more. smb has convinced me that the (possibly ca[0]) cert
i get from the rir, with which i do business with the rir (dns,
ip requests, billing), should be different than that which i use
for routing info.

randy

7

> According to what I understand, there have to be two certificates
> per entity:
>
> one is the CA-bit enabled certificate, used to sign
> subsidiary certificates about resources being given to other people
> to use.
>
> the other is a self-signed NON-CA certificate, used to sign
> route assertions you are attesting to yourself: you make
> this cert using the CA cert you get from your logical parent.

probably more. smb has convinced me that the (possibly ca[0]) cert
i get from the rir, with which i do business with the rir (dns,
ip requests, billing), should be different than that which i use
for routing info.

At APNIC the cert we expect you to identify yourself with to transact
with the registry is not the same as the cert which identifies resource
utilization. But we (APNIC) also expect to use a different root CA for
these 'identity' certs anyway.

the test APNIC resource certificates are using an interim self-signed
CA, and will be moving to a hardware-token secured CA shortly. The
hardware is the same as our identity certificates used in MyAPNIC, but
a different trust anchor and CA identity will be used for resource
certificate processes.

We probably need to make this explict in our policies in this area.
We've always

cheers
  -George

randy

---

[0] - i'll want the business cert to have the ca bit if i am
      large enough to have internal authorization process, and
      thus want to create and manage different certs for dns,
      billing, ...

We are discussing how we can do subsidiary certificate services like
this in APNIC but I think this goes outside of routing policy and into
registry business practices which are unlikely to be common for all RIR
and NIR in the ways that resource certificates *have* to be.

cheers
  -George

8

[0] - i'll want the business cert to have the ca bit if i am
      large enough to have internal authorization process, and
      thus want to create and manage different certs for dns,
      billing, ...

We are discussing how we can do subsidiary certificate services like
this in APNIC but I think this goes outside of routing policy and into
registry business practices which are unlikely to be common for all RIR
and NIR in the ways that resource certificates *have* to be.

if it is not common across registries, and if my certs do not
work across registries, then something is very very broken,
and a major pita at the isps', aka your members', expense.

randy

9

If you want to see member-certificates which gate access to RIR/NIR
specific services common across all registries, I think you want to get
that onto an RIR meeting agenda Randy.

We currently have no cross-certification activity in member identity.

cheers

-George

10

We are discussing how we can do subsidiary certificate services like
this in APNIC but I think this goes outside of routing policy and
into registry business practices which are unlikely to be common
for all RIR and NIR in the ways that resource certificates *have*
to be.

if it is not common across registries, and if my certs do not
work across registries, then something is very very broken,
and a major pita at the isps', aka your members', expense.

If you want to see member-certificates which gate access to
RIR/NIR specific services common across all registries, I think
you want to get that onto an RIR meeting agenda Randy.

i have been whining about the problems of cross-registry operation
for over a decade, formally, informally, presos, ... i have had it
on every rir's meeting agenda (except lacnic) for many years. do i
need to iterate for every ort of service the registries provide?

we are the registries' customers. many of us, especially the ones
who pay the registries the most, have to deal with multiple
registries. can the registries please get over the inter-registry
rivalry and make life more reasonable for us, the paying members?

We currently have no cross-certification activity in member identity.

where as before i was merely inclined, this has just made me an
extremely strong proponent of the isp web of trust identity model.

randy

11

I was arguing for this when RIPE was introducing the X.509 auth for the LIR portal. And I clearly remember multi-RIR customers asking for the same thing for exactly the same reason (I think it was Nigel and Neil), as was Randy. So it's certainly been on the agenda...

- kurtis -

12

i have been whining about the problems of cross-registry operation
for over a decade, formally, informally, presos, ... i have had it
on every rir's meeting agenda (except lacnic) for many years. do i
need to iterate for every ort of service the registries provide?

Sometimes I think you are right about this and sometimes I think you are wrong about this. It just may be that you are thinking only about the "right" half, but "operation" of the registry to some means the policy process too.

Where I see this as "wrong" is: There are five distinct RIRs for a reason, to be attuned to local needs. The domain name industry has one "RIR" asserting authority and we see the political fallout of that. Having the five RIRs locked together would certainly benefit (usually the larger) organizations that deal across RIR boundaries, most likely (and I say that without certainty or accusation) to the detriment of smaller organizations tuned to the needs within one RIR.

I think it's very important that we keep the policy processes - the decision making part, and even discussion - separate. Yes, that means it takes a long time to get a "global" (effectively, one involving IANA) policy through.

On the other hand, you are "right" when it comes to the technical services rendered and the interfaces used. That's because the use of the data is global, no doubt about that. A student sending mail from Africa to Asia will traverse two or three RIR area networks, just to show how 1 consumer can cause a cross-RIR event.

One of the dynamics I see happening now is that the RIRs are independently developing some advanced services. RIPE into DNSSEC, APNIC into certificates, LACNIC into IRIS and unifying the RIR WhoIs data. These advancements happen locally much faster than globally, as is true with any innovation. "Failed" attempts at advancement will be easier to recover from too. Eventually we want these services to be global, but in development I expect differences.

we are the registries' customers. many of us, especially the ones
who pay the registries the most, have to deal with multiple
registries. can the registries please get over the inter-registry
rivalry and make life more reasonable for us, the paying members?

Keep in mind that the RIRs were originally cobbled together out of different cloth. Unifying the service interface will take an investment in doing that. This is why I have made comments at ARIN meetings about providing technical input to ARIN - trying to define a way to have the community, or even just the membership, inform ARIN on what service interfaces we would like to see in an open, reviewable arena. ARIN has this for policies, but the path towards service upgrades is not as well defined.

It's one thing to lay heat at the feet of organizations, it's another to make clear the reason for the heat.

where as before i was merely inclined, this has just made me an
extremely strong proponent of the isp web of trust identity model.

The upside of this is that it directly addresses the routing problem - ISPs get to determine who they trust for the data they rely on. On the other hand, ultimately a web of trust has to fair to newcomers, not rely on superficial "popularity", and obviously scaleable.