The Internet Protocol Journal, Volume 12, No.1

Resource Certification

by Geoff Huston, APNIC

Opinions vary as to what aspect of the Internet infrastructure represents the greatest common vulnerability to the security and safety of Internet users, but it is generally regarded that attacks that are directed at the network infrastructure are the most insidious, and in that case the choice is probably between the Domain Name System (DNS) and the interdomain routing system.

The question of how to improve the robustness of these functions has been a longstanding topic of study. For the DNS it appears that there is convergence on Domain Name System Security Extensions (DNSSEC) as the technical solution to securing DNS resolution operations, and the focus of attention in this space has shifted from technical behavior to topics relating to operational deployment. It has been a difficult time for DNSSEC and to say that there is an end in sight may well be premature at this stage, but there are definite signs of progress in this space. The same cannot be said of progress with securing routing, and particularly in securing interdomain routing. Here much remains to be done in order to achieve reasonable consensus on what technical measures to adopt, let alone the second step of study of how such measures could be deployed across the Internet.

The IETF's approach to addressing the topic of securing interdomain routing has followed a conventional IETF path. The first step has been to consider the nature of various vulnerabilities that exist within today's interdomain routing system and then develop a set of requirements that should be addressed in any solution space, without necessarily defining what such a solution may be. When the enumeration of requirements achieves a suitable level of consensus from the community, it is then possible to commence work on standardizing solutions. In the case of securing interdomain routing, the first steps were undertaken in Birds of a Feather (BOF) sessions and in the subsequently formed Routing Protocol Security Requirements (RPSEC) Working Group. This work is almost complete, and apart from some definitive statement relating to a requirement for securing the Autonomous System (AS) Path attribute in Border Gateway Protocol (BGP), the set of requirements for securing interdomain routing is now in an almost final state [1]. The task of the Securing Inter-Domain Routing (SIDR) Working Group is to standardize technologies that can meet these requirements.

So where does "Resource Certification" fit in?

Public Key Cryptography

One commonly used security technology is Public Key Cryptography, a technique that is easily explained. The approach uses a pair of keys, A and B. Anything enciphered with key A can be deciphered only with key B, and conversely, and knowledge of the value of one key does not lead to discovery of the value of the other key. Key A is kept as a closely guarded secret, whereas key B is openly published. If I want to send you a message that only you can decipher and read, I should encrypt it using your public key. If I want to send you a message that only I could have sent (nonrepudiation), then I will generate a digital signature of the message using my private key. That way any attempts to alter the message will also be detectable.

This latter approach, of using keys to generate digital signatures of messages, lies at the heart of DNSSEC, because DNSSEC adds public keys and digital signatures to the DNS. A DNS query can generate a response that lists both the DNS answer and the digital signature of that answer. The DNS can also be queried to retrieve the public key used to sign all the components of that zone, so that the digital signature can be verified and the query agent can be assured that the response is a genuine one. But how can the key itself be verified? In DNSSEC the hierarchical nature of the DNS itself is exploited by having each zone "parent" sign the keys of its delegated "children." So the zone key can be verified by retrieving the parent's signature across that zone key, and so on to the root of the DNS. As long as the query agent knows beforehand the value of the public key used to sign the root zone of the DNS, and as long as DNSSEC is used universally, all DNS responses can be verified in DNSSEC.

Although this approach works in the interlocked hierarchical structure of the DNS, when we turn our attention to securing the use of IP addresses and AS numbers in the context of interdomain routing, there is no comparable hierarchy to exploit. In such cases a common solution is to turn to Digital Certificates.

Digital Certificates are digitally signed public attestations by a certification authority that associate a subject's public key value with some attribute of the subject. A typical application is in identity certification, where the certification authority is attesting that the holder of the private key whose matching public key is provided in the certificate has met the authority's certification criteria to be identified by a particular name. Digital certificates are useful in that they can reduce the number of trust points in a security domain, so that each member of the domain does not have to validate identity and exchange public keys with every other member of the domain, but can undertake a single transaction with a certification authority that is trusted by all the members of the domain. As long as every member of the domain carries the public key of the certification authority and can access all issued digital certificates, then the members of the domain can verify each other's attestations and digital signatures.

Of course digital certificates are used for far more than attestations of identity, and can encompass the authority to perform specific tasks, undertake particular roles, or grant permissions and right-of-use authorities. It is this latter use case that is relevant to resource certification.

Resource Certificates

A Resource Certificate is a conventional X.509 certificate that conforms to the Public Key Infrastructure Working Group (PKIX) profile (RFC 5280) with one critical component, namely a certificate extension that lists a collection of IP number resources (IPv4 addresses, IPv6 addresses, and AS numbers) [17].

These certificates attest that the certificate issuer has granted to the entity represented by the certificate subject a unique "right-of-use" of the associated set of IP number resources listed in the certificate extension, by virtue of an associated resource allocation. The unique "right-of-use" concept mirrors the resource allocation framework, where the certificate provides a means of third-party validation of assertions related to resource allocations [2].

By coupling the issuance of a certificate by a parent Certification Authority (CA) to the corresponding resource allocation, a test of the validity of a certificate, including the IP number resource extension, can also be interpreted as validation of that resource allocation. Signing operations that descend from that certificate can therefore be held to be testable, under the corresponding hierarchy of allocation. In other words, if you received your address block from a particular Regional Internet Registry (RIR), then only that RIR can issue a Resource Certificate for you that includes your public key and the allocated number resources. Anything you sign using your private key can be verified through the RIR's issued certificate.

Unlike certificates that relate to attestations of identity, Resource Certificates are not necessarily long-lived. When an additional allocation action occurs, the associated Resource Certificate is reissued with an IP number resource extension that matches the new allocation state. In the case of a reduction in allocated resources, the previously issued certificates are explicitly revoked when the new certificate is issued. In other cases there is no explicit revocation of the older certificates.

The intention here is that any instrument signed by the subject's private key that relates to an assertion of resource control, whether it is a protocol message in a routing protocol or an administrative request to an Internet Service Provider (ISP) to route a prefix or as assertion of title over the "right-of-use" of a number resource, can be validated through the matching public key contained in the certificate and the IP number resource that is enumerated in this certificate. The Resource Certificate itself can be verified in the context of a Resource Certificate Public Key Infrastructure (PKI).

The Resource Certificate Public Key Infrastructure

The Resource Certificate Public Key Infrastructure (RPKI) describes the structure of the certification framework used by Resource Certificates. The intent of the RPKI is to construct a robust hierarchy of X.509 certificates that allows relying parties to validate assertions about IP addresses and AS numbers, and their use.

The structure of the RPKI as it relates to public use of IP number resources is designed to precisely mirror the structure of the distribution of addresses and ASs in the Internet, so a brief description of this distribution structure is appropriate. The Internet Assigned Numbers Authority (IANA) manages the central pool of number resources. The IANA publishes a registry of all current allocations. The IANA does not make direct allocations of number resources to end users or Local Internet Registries (LIRs), and instead allocates blocks of number resources to the RIRs. The RIRs perform the next level of distribution, allocating number resources to LIRs, National Internet Registries (NIRs), and end users. NIRs perform allocations to LIRs and end users, and LIRs allocate resources to end users (Figure 1).

Figure 1: Address Distribution Hierarchy for the Internet

The RPKI mirrors this allocation hierarchy. One interpretation of this model would send the IANA manager a root RPKI key, and using this key the IANA would issue a self-signed "root" certificate, and also issue subordinate certificates to each of the RIRs, describing in the resource extension to the certificate the complete set of number resources that have been allocated to that RIR at the time of issuance. The certificate would also hold the public key of the RIR and would be signed by the private key of the IANA. Each RIR would issue certificates that correspond to allocations made by that RIR, where the resource extension to those certificates lists all the allocated resources, and the certificate includes the public key of the recipient of the resource allocation, signed with the private key of the RIR. If the recipient of the resource allocation is an LIR or an NIR, then it too would also similarly issue resources certificates (Figure 2).

Figure 2: RPKI Resource Certificate Hierarchy

The common constraint within this certificate structure is that an issued certificate must contain a resource extension that contains a subset of the resources that are described in the resource extension of the issuing authority's certificate. This requirement corresponds to the allocation constraint than a registry cannot allocate resources that were not allocated to the registry in the first place. One implication of this constraint is that if any party holds resources allocated from two or more registries, then it will hold two or more Resource Certificates in order to describe the complete set of its resource holdings.

Validation of a certificate within this RPKI is similar to conventional certificate validation within any PKI, namely establishing a chain of valid certificates that are linked by issuer and subject from a nominated trust anchor CA to the certificate in question. The only additional constraints in the RPKI are that every certificate in this validation path must be a valid Resource Certificate, and the IP number of resources described in each certificate must be a subset of the resources described in the issuing authority's certificate.

Within this RPKI all Resource Certificates must have the IP addresses and AS resources present, and marked as critical extensions. The contents of these extensions correspond exactly to the current state of IP address and AS number allocations from the issuer to the subject.

Any holder of a resource who can make further allocations of resources to other parties must be able to issue Resource Certificates that correspond to these allocations. Similarly, any holder who wishes to use the RPKI to digitally sign an attestation needs to be able to issue an End Entity (EE) certificate to perform the digital signing operation.

For this reason all issued certificates that correspond to allocations are certificates with the CA capability enabled, and each CA certificate is capable of issuing subordinate CA certificates that correspond to further sub-allocations and subordinate EE certificates that correspond to a generation of digital signatures on attestations.

The RPKI makes conventional use of Certificate Revocation Lists (CRLs) to control the validity of issued certificates, and every CA certificate in the RPKI must issue a CRL according to the nominated CRL update cycle of the CA. A CA certificate may be revoked by an issuing authority for numerous reasons, including key rollover, the reduction in the resource set associated with the subject of the certificate, or termination of the resource allocation. To invalidate the authority or attestation that was signed by a given EE certificate, the CA issuing authority that issued the EE certificate simply revokes the EE certificate.

Resource Certificates are intended to be public documents, and all certificates and objects in the RPKI are published in openly accessible repositories. The set of all such repositories forms a complete information space, and it is fundamental to the model of securing the public Internet interdomain routing system that the entire RPKI information space is available. Other uses of the RPKI might permit use of subsets, such as the single chain from a given end-entity certificate to a trust anchor, but routing security is considered against all known publicly routable addresses and AS numbers, so all known resource certification outcomes must be available. In other words the intended use of the RPKI in routing contexts is not a case where each relying party may make specific requests for RPKI objects in order to validate a single object, but one where each relying party will perform a regular sweep across the entire set of RPKI objects in order to ensure that the relying party has a complete picture of the RPKI information space.

This aspect of the RPKI represents some interesting challenges, in that rather than having a single CA publish all the certificates produced in a security application at a single point, the RPKI permits the use of many publication points in a widely distributed fashion. Each CA can issue RPKI objects and publish them using a locally managed publication point. It is incumbent upon relying parties to synchronize a locally managed cache of the entire RPKI information space at regular and relatively frequent intervals.

For this reason the RPKI has introduced an additional mechanism in its publication framework, namely the use of a "manifest" to allow relying parties to determine whether they have been able to retrieve the entire set of RPKI published objects from each RPKI repository publication point, or if there has been some attempt to disrupt the relying party's access to the entire RPKI information set.

It also implies that the RPKI publication point access protocols should support the efficient function of a synchronization comparison, so that a locally managed cache of the RPKI need only call for the uploading of those objects that have been altered since the previous synchronization operation.

Signed Attestations and Authorities

The underlying intent of digital certificates, and Resource Certificates in particular, is in terms of supporting a transitive trust relationship that allows a relying party to verify the authenticity of a signed artefact through verification of the signer's key using the PKI. So the obvious question is: what artefacts are useful to sign?

Much of the motivation for Resource Certificates has come from a desire to underpin efforts in securing aspects of interdomain routing. This effort goes well beyond securing the individual point-to-point connection used between BGP speakers, and refers to the matter of verifying the authenticity of the payload of the BGP protocol exchange. The specific question that may be posed is: how can a BGP speaker validate the authenticity of the route object being presented to it?

The approach being studied by the SIDR Working Group is to use structured attestations, where, like the digital certificate itself, the attestation is structured in an ASN.1 digital object, and this object is signed using a signing formation that is itself a piece of structured ASN.1, namely the Cryptographic Message Syntax (CMS) [18].

The first of these attestations relates to the ability to verify the authenticity of the "origination" of an interdomain routing object. This verification refers to the address prefix and the originating AS, and the questions that this verification function is intended to answer include:

  • Is this a valid address prefix and AS number? Have these resources been allocated through the IP number resource allocation process?
  • Has the holder of the title of "right-of-use" for the address prefix authorized the AS holder to originate a routing advertisement for this prefix?

Here an address holder is authorizing a particular ISP to generate a route announcement for its particular address prefix. In this case the prefix holder would generate an EE Resource Certificate with the IP number resource extension spanning the set of addresses that match the address prefixes that are the intended subject of the routing authority, and place validity dates in the EE certificate that correspond to the intended validity dates of the routing authority.

The signed authority document would contain the AS number that is being authorized in this manner, a description of the range of prefixes that the prefix holder has authorized, and the EE certificate. The document would be signed by the EE certificate private key using a CMS signing structure. The resultant object is published in the RPKI distributed publication repository as a Routing Origination Authorization (ROA). A relying party can validate the ROA by checking to ensure that the digital signature in the ROA is correct, indicating that the authority document has not been tampered with in any way since it was signed, that the resources in the associated EE certificate encompass the prefixes specified in the document, and the EE certificate itself is valid in the context of the RPKI by verifying that there is an issuer-subject chain of valid certificates that link one of the relying party's nominated trust anchors to the EE certificate.

The ROA itself is valid as long as the signing EE certificate is valid. To withdraw the authority prior to the expiration of the EE certificate, the ROA publisher can simply revoke the EE certificate, leading to the concept of "one-off-use" EE certificates in the RPKI, where a key pair and a corresponding EE certificate are generated in order to sign a single attestation or authority. If the authority's lifetime is extended, the authority is reissued with a new EE certificate and a new digital signature, and, as noted, the authority can be prematurely terminated through revocation of the EE certificate, so at no stage is there a need to reuse the original signing private key. After the private key is used to sign this object, the key is destroyed, alleviating to some extent the key management load.

In any security system knowledge of what is authorized is helpful, but knowledge of what has not been authorized is perhaps even more helpful. For ROAs there is an analogous situation to DNSSEC, where DNSSEC is most effective from a client's perspective after the entire DNS space is DNSSEC signed. Where there are gaps in the DNSSEC signing chains the client is left in an uncertain state regarding the verification outcomes of the unlinked DNS sub-hierarchies. The same could apply to ROAs, in that in an environment where not every originated route object has a published ROA, the absence of a ROA does not necessarily indicate an unauthorized route origination. If one of the objectives of this study is to define a framework that can unambiguously identify the unauthorized use of IP number resources in routing (route "hijacks") even in a world where ROAs are used in a piecemeal fashion, then one possible refinement to the ROA model is the introduction of a comparable negative authority, the Bogon Origination Attestation (BOA).

In this case the prefix holder generates a signed attestation, or BOA, in a similar manner to the ROA, but does not provide any originating AS. Instead the BOA refers to "all originating ASs," and has the semantic interpretation that any use in the routing space of this address prefix described in the BOA, or any more specific address prefix, should be regarded as unauthorized and the route should be discarded.

Although this process makes the detection of route hijacks more direct in a world of piecemeal use of ROAs, there is now the added complication of having both "positive" and "negative" authorities. The proposed resolution of this dilemma is to use a relative priority rule that ROAs take precedence over BOAs, so that if a valid ROA and a valid BOA both exist that describe the origination component of a route, then the route can be regarded as authorized.

It should be noted, however, that at this stage these concepts are "work in progress," and are part of the SIDR Working Group's agenda of study, and the working group has not as yet reached any consensus regarding the decision to advance these proposals onward along the Internet Standards Process.

Also on the near-term horizon for SIDR is examining approaches to secure the AS path in BGP updates. The RPSEC Working Group has explored two approaches in this space. One involves an incremental multiple signature technique that allows a receiver of a BGP update to verify that the AS path described in the update is matched by a sequence of interlocking AS digital signatures using the RPKI. At the same time that an AS adds its own AS to the AS path prior to further External Border Gateway Protocol (eBGP) propagation of the route update, the AS would digitally sign over an analogous sequence of AS signatures. This approach allows a receiver to perform a match of the AS sequence in the AS path with the AS number sequence identified in the AS signature block. A match here would indicate that the BGP update has indeed been sequentially passed along the sequence identified by the AS path. This approach was originally proposed in the Secure BGP (sBGP) design [21] and has attracted some comment related to the computation overhead associated with the application and validation of these AS path signature sequences. An alternative approach has been one that is described by RPSEC as being less rigorous, and refers to a "feasibility" check, which checks to ensure that each pair of ASs represented in the AS path has an associated verifiable assertion of inter-AS adjacency that is digitally signed by both ASs.

It should also be noted that this activity of addressing aspects of improving the robustness of interdomain routing has some previous context. In many parts of the Internet, some degree of routing integrity is managed through the use of Internet Routing Registries (IRRs) and the publication of routing policies through the use of Routing Policy Specification Language (RPSL) objects.

Although opinions vary as to the robustness of the security offered by the IRR approach, at the very least it can mitigate some weakness in the routing system through the use of a "second check" that can be used to filter the information that is being provided in a BGP feed.

The weaknesses in the IRR system tend to relate to the consistency, completeness, and authenticity of the IRR data, and in many cases the trust in the integrity of the data relies on the admission practices of the IRR itself, and individual data objects cannot be verified by clients of the IRR. One possible way to address this situation has been through the use of Routing Policy System Security (RPSS) measures, but the adoption of these measures has not been widespread, and the question still remains for the client that even if an IRR object was authenticated upon admission, it does not mean that when the object is subsequently used by an IRR client the information reflects the current situation, and the information could well be invalid or not reflect the current policies of the author of the IRR object.

One possible approach being considered by the SIDR Working Group is to implement the RPSS authentication models using object signing in the context of the RPKI. For example, the RPSS assumption that routes should be announced only with the consent of the holder of the origin AS number of the announcement and with the consent of the holder of the address space implies in RPSS that both parties should authorize the entry of a route object into the IRR. Translating this stipulation into an analogous model using the RPKI would require that a route object be signed with the digital signatures of both the AS holder and the address space holder, and a IRR client can verify this route object at the time of use by verifying both digital signatures. Either the address space holder or the AS holder can revoke authorization by revoking the EE certificate used to sign the route object, and the verification is independent of the particular IRR that has published the route object. It is also a possibility that the IRR itself can be folded into the RPKI distributed publication repository framework, because there is no particular requirement in such an environment for a disparate collection of IRRs with their own partial collections of routing policy information, although at this stage this discussion is heading into the realm of more advanced speculation about the potential for application of Resource Certificates and digital signatures to RPSL and the IRR framework.

Putting Resource Certificates into Context

Resource Certificates and the associated RPKI represent a major part of any effort to construct a secure interdomain routing framework. An RPKI, even partially populated with signed information, allows BGP speakers to make preferential selections to use routing information where the IP address block and the AS numbers being used are recognized as valid to use, and the parties using these IP addresses and AS numbers are properly authorized to so do. The RPKI can also be used to identify instances of unauthorized use of IP addresses and attempts to hijack routes.

However, the RPKI represents only one part of a larger framework of securing interdomain routing, and the next step is that of applying the RPKI to the local BGP processing framework. There is also the need to move beyond validation of route origination and look at the associated topic of validation of the AS path, and potentially to consider the most challenging task, of attempting to validate whether the initial forwarding decision associated with a route object actually represents the correct first hop along a usable forwarding path for packets to reach the network destination.

The concerns here include not only a consideration of what can be secured and validated, but matters of scalability and efficiency in terms of deployment cost. The various approaches to routing security studied so far offer a wide variety of outcomes in terms of the amount of routing information that is validated, the level of trust that can be placed in a validation outcome, and the overheads of generating and validating digital signatures on routing information. The next step appears to include the task of establishing an appropriate balance between the overheads of operating the security framework and the extent to which efforts to disrupt the routing system can be successfully deflected by such measures.

The RPKI has been designed as a robust, simple framework. As far as possible existing technologies and processes have been exploited, reflecting to some extent a level of conservatism of the routing community and the difficulty in securing widespread acceptance of novel technologies.

References and Further Reading

The following documents provide further detail about the IETF work on resource certification. The Internet Drafts listed here are still a "work in progress," and although they are reflective of the areas of activity of the SIDR Working Group, they do not necessarily represent finished work.

Requirements:

[1] B. Christian, T. Tauber, eds., "BGP Security Requirements," work in progress, Internet Draft, draft-ietf-rpsec-10.txt, November 2008. The report of the consensus outcomes of the RPSEC Working Group in enumerating the requirements for securing interdomain routing. The outstanding topic in this report remains in the area of AS path validation and the level of requirement associated with the two approaches described in the report.

Architecture:

[2] M. Lepinski, S. Kent, "An Infrastructure to Support Secure Internet Routing," work in progress, Internet Draft, draft-ietf-sidr-arch-04.txt, November 2008. An overview of the RPKI approach, describing the RPKI, the distributed repository structure, and common operations.

Resource Certificates:

[3] G. Huston, G. Michaelson, R. Loomans, "A Profile for X.509 PKIX Resource Certificates," work in progress, Internet Draft, draft-ietf-sidr-res-certs-15.txt, November 2008. The specification of the Resource Certificate.

RPKI Repository Structure:

[4] G. Huston, G. Michaelson, R. Loomans, "A Profile for Resource Certificate Repository Structure," work in progress, Internet Draft, draft-ietf-sidr-repos-struct-01.txt, October 2008. A description of the proposed distributed publication repository structure for the RPKI, including contents, access protocols, and object name conventions.

[5] R. Austein et al., "Manifests for the Resource Public Key Infrastructure," work in progress, Internet Draft, draft-ietf-sidr-rpki-manifests-04.txt, October 2008. A specification for repository manifests. Manifests are signed constructs that describe all the objects currently loaded into a repository publication point, and are used by relying parties as a means of ensuring that a local RPKI repository cache is correctly synchronized against the authoritative original publication point.

[6] G. Huston, R. Loomans, B. Ellacot, R. Austein, "A Protocol for Provisioning Resource Certificates," work in progress, Internet Draft, draft-ietf-sidr-rescerts-provisioning-03.txt, August 2008. A proposed protocol for use between a subject and a certificate issuer to ensure that certificate requests, the IP number resource allocation state, and the issued certificate status are correctly synchronized. This synchronization extends the conventional certificate request model into a transaction protocol that also includes the ability to perform certificate revocation requests and status queries from the subject.

RPKI Signed Objects:

[7] M. Lepinski, S. Kent, D. Kong, "A Profile for Route Origin Authorizations (ROAs)," work in progress, Internet Draft, draft-ietf-sidr-roa-format-04.txt, November 2008. The specification of the syntax for signed ROAs.

[8] G. Huston, T. Manderson, G. Michaelson, "A Profile for Bogon Origin Attestations (BOAs)," work in progress, Internet Draft, draft-ietf-sidr-bogons-02.txt, October 2008. The specification of the syntax for signed BOAs.

[9] G. Huston, G. Michaelson, "Validation of Route Origination in BGP Using the Resource Certificate PKI," work in progress, Internet Draft, draft-ietf-sidr-roa-validation-01.txt, October 2008. The specification of the semantics of ROAs and BOAs and the manner in which these objects may be interpreted in terms of the integration of these origination security credentials onto a BGP route-selection process.

Certificate Policy and Practice Statements:

[10] K. Seo, R. Watro, D. Kong, S. Kent, "Certificate Policy (CP) for the Resource PKI (RPKI)," work in progress, Internet Draft, draft-ietf-sidr-cp-04.txt, November 2008. A description of the certificate policy that applies to all certificates issued within the RPKI framework.

[11] D. Kong, K. Seo, S. Kent, "Template for an Internet Registry's Certification Practice Statement (CPS) for the Resource PKI (RPKI)," work in progress, Internet Draft, draft-ietf-sidr-cps-irs-04.txt, November 2008. A template for the Practice Statement used by Internet Registries (IRs) to describe their operational practices in the issuance and management of Resource Certificates.

[12] D. Kong, K. Seo, S. Kent, "Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Resource PKI (RPKI)," work in progress, Internet Draft, draft-ietf-sidr-cps-isp-03.txt, November 2008. A template for the Practice Statement used by ISPs to describe their operational practices in the issuance and management of Resource Certificates.

Individual Submissions:

[13] G, Huston, G. Michaelson, "A Profile for AS Adjacency Attestation Objects," work in progress, Internet Draft, draft-huston-sidr-aao-profile-00.txt, September 2008. The specification of the syntax for a pairwise inter-AS routing adjacency attestation.

[14] R. Kisteleki, J. Boumans, "Securing RPSL Objects with RPKI Signatures," work in progress, Internet Draft, draft-kisteleki- sidr-rpsl-sig-00.txt, October 2008. The specification of the addition of RPKI digital signatures to RPSL Objects in the context of an Internet Route Registry.

[15] T. Manderson, G. Michaelson, "RPKI Repository Retrieval Mechanism," work in progress, Internet Draft, draft-manderson- sidr-fetch-00, October 2008. A proposed mechanism to use the manifest as the basis for performing a synchronization operation between a local RPKI cache and a source point.

RFCs:

[16] D. Cooper et al., "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile," RFC 5280, May 2008.

[17] C. Lynn, S. Kent and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers," RFC 3779, June 2004.

[18] R. Housley, "Cryptographic Message Syntax (CMS)," RFC 3852, July 2004.

[19] C. Alaettinoglu, et al., "Routing Policy Specification Language (RPSL)," RFC 2622, June 1999.

[20] C. Villamizar et al., "Routing Policy System Security," RFC 2725, December 1999.

Other Documents:

[21] Kent, S., "Securing BGP: S-BGP," The Internet Protocol Journal, Volume 6, No. 3, September 2003.

GEOFF HUSTON holds a B.Sc. and a M.Sc. from the Australian National University. He has been closely involved with the development of the Internet for many years, particularly within Australia, where he was responsible for the initial build of the Internet within the Australian academic and research sector. The author of numerous Internet-related books, he is currently the Chief Scientist at APNIC, the Regional Internet Registry serving the Asia Pacific region. He was a member of the Internet Architecture Board from 1999 until 2005, and served on the Board of the Internet Society from 1992 until 2001. E-mail: gih@apnic.net