Subject: Re: [sidr] One potential work item.

From: Stephen Kent <[email-masked]>
Date: Mon, 3 Apr 2006 20:41:18 -0400

At 10:41 PM +0100 3/24/06, Henk Uijterwaal wrote:
>All,
>
>Since Geoff asked about work items for this group...
>
>One thing that I'd find particularly useful, is a requirements document
>for RIRs.   Assume that the RIRs will set up a PKI and hand out a (or more)
>certificate(s) for each IP/AS allocation.
>
>* Vendors/protocol designers
>   = Requirements that will allow the certificates to be used with
>     {s|so|ps|...}BGP.  I don't want to choose a protocol, but I do want
>     to make sure that we don't force people into a certain direction
>     before the various technologies are fully mature.

SBGP called for use of X.509 certs with an extension equivalent to 
what was later defined in RFC 3779. soBGP dfeines several types of 
certs in the I-Ds that have been published, but none of them make use 
of IETF/ITU standard formats. So, the soBGP designers have to respond 
to the question of whether they are comfortable using IETF standards 
for certs, and whether the RFC 3779 extension representation of 
addresses and ASNs meets their requirements. psBGP assumes use of 
certs issued by registries to represent ASNs and addresses, and I 
don't think they have any problem with using X.509 certs and the 3779 
extension.

>
>* LIRs/ISPs
>   = How do they see themselves use these certificates
>   = What would make them useful/useless.
>   = What happens if a block is transferred to a customer.
>   = What happens if resources are exchanged (traded) between ISPs.
>   = What should be common amongst all 5 RIRs.
>   = Interaction with IRRs and such
>   = Can they use certificates from other bodies, who controls their
>     identity.

There are a lot of good questions here.  I'll suggest some answers to 
some of them.

A primary, near-term use of this data by ISPs is to use it to 
generate higher assurance route filters. By downloading certs, CRLs, 
and signed objects that address block holders use to declare which 
ASes are authorized to originate routes, each ISP can independently 
verify these route origination assertions, these can then be used to 
generate route filters.  As holders of address space each ISP should 
sign objects that declare itself as the authorized originator of 
routes to its address space. An ISP also can request/require 
subscribers with portable address space (or address space originally 
allocated to another ISP) to present a signed object authorizing the 
ISP to advertise this address space that it does not hold, and to 
prove that the subscriber is the holder of the cert associated with 
the address space. this would help prevent social engineering attacks 
against ISPs re originating routes not held by subscribers. I'm sure 
others can describe additional ways ISPs can make use of the data.

An ISP could transfer a block to a customer by issuing a cert to that 
customer. alternatively, the ISP could relinquish the block to a 
registry and have it transferred to the subscriber. both mechanisms 
can be accommodated via a PKI and it is more an operational (and 
political) decision as to which model should be employed.

For transfer between ISPs, the same sort of mechanisms apply, 
although I'd suggest a registry-mediated transfer to keep things as 
clean as possible.

all registries and ISPs need to follow a common cert policy for the 
PKI to have uniform semantics. however, each registry and ISP can 
adopt it's own procedures for cert issuance/renewal/revocation for 
its clients. I'd strongly suggest a unified, largely centralized 
repository system for certs, CRLs, and signed objects that attest to 
resource holdings. if every ISP needs to retrieve all of this data, 
then having it scattered over every ISP makes life awfully hard for 
the ISPs themselves.

IRRs could hold the signed objects that represent authorizations to 
originate routes, as an adjunct to their current data.  There may be 
other things IRRs could do with this data too.

The PKI model I've suggested does not attest to identity. So trying 
to incorporate certs that attest to identity, but not to resource 
holdings, doesn't work very well. It's a case of mixing credentials. 
For example, I can use my passport ort my driver's license  to 
identify myself as part of airport security. But, if I show the 
passport to the rental car folks they are not happy, because it is 
not a license to drive.

>* Government bodies:
>   = Requirements on the PKI (EU, DHS, ...)
>     (We will hand out certificates that are used world-wide, so we better
>      make sure that they confirm to all relevant local regulations).

there are no US regulations re issuance of certs used for 
authorization (vs. identification & authentication). EU regulations 
focus on identification & authentication as well, and specifically 
the use of certs for non-repudiation; the EU digital signature 
directive does not apply to these certs. so I don't know of any 
regulations that apply to issuance of these certs, because they are 
not for identification, and they definitely NOT for non-repudiation 
(which is the common focus of such regulation).

>* Other expected use cases

I suggest we focus exclusively on applications that want to make use of
a PKI to verify claims of resource holdings allocated by the registry 
system, i.e., address space and ASNs.  That is consistent with the 
charter of this WG re IDR security, and helps us avoid distractions.

Steve

_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr