Resource Certification

By: Geoff Huston

Date: February 7, 2009

line break image

Opinions vary as to what aspect of the Internet’s 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’s infrastructure are the most insidious, and in that case the choice is probably between the Domain Name System (DNS) and the inter-domain 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 DNSSEC (DNS Security) as the technical solution to securing DNS resolution operations, and the focus of attention in this space has shifted from technical behaviour to issues relating to operational deployment. It has been a long haul for DNSSEC, and to say 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 there is still much to be done in order to achieve reasonable consensus on what technical measures to adopt, let alone the second step: the 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. Once the enumeration of requirements achieves a suitable level of consensus within the community, it will then be possible to commence work on standardising solutions. In the case of securing interdomain routing, the first steps were undertaken in 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 BGP (Border Gateway Protocol), the set of requirements for securing interdomain routing is now in a close-to-final state (draft-ietf-rpsec-bgpsecrec). The task of the Secure InterDomain Routing (SIDR) working group is to standardise technologies that can meet these requirements.

So where does resource certification come into the picture?

Public Key Cryptography

One commonly used security technology is public key cryptography. As long as a suitable amount of vague hand waving is used, the technique can be 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 vice versa, 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, while 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’ve sent (nonrepudiation), then I’ll generate a digital signature of the message by 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 that is used for signing 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.

While 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, then there is no comparable hierarchy to exploit. In such cases a common solution is to turn to digital certificates.

A digital certificate is a digitally signed public attestation by a certification authority that associates a subject’s public key value with some attribute of the subject. A very typical application is in identity certification, where the certification authority is attestation 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 because they are able to reduce the number of trust points in a security domain, so that each individual 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, 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 that last-use case that is relevant to resource certification.

Resource Certificates

A resource certificate is a conventional X.509 certificate that conforms to the 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) (RFC 3779).

These certificates attest that by virtue of an associated resource allocation, the certificate’s issuer has granted to the entity represented by the certificate’s subject a unique right-of-use of the associated set of IP number resources listed in the certificate’s extension. 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 (draft-ietf-sidr-arch).

By coupling the issuance of a certificate by a parent Certification Authority (CA) to the corresponding resource allocation, a test of a certificate’s validity 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 via the RIR’s issued certificate.

Unlike certificates that relate to attestations of identity, resource certificates are not necessarily longlived. 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 once 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’s a protocol message in a routing protocol or an administrative request to an ISP to route a prefix or an 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 are enumerated in this certificate. The resource certificate itself can be verified in the context of a resource certificate Public Key Infrastructure.

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). Instead, it 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).

resource allocation

The RPKI mirrors this allocation hierarchy. One interpretation of this model would see the IANA manage a root RPKI key, and using this key, the IANA would issue a selfsigned 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 issue resource certificates in a similar vein (figure 2).

resource allocation

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 corresponds to the allocation constraint that a registry cannot allocate resources that were not allocated to the registry in the first place. One implication of such 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 Certification Authority (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 that the IP number resources described in each certificate are 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 as well as marked as a critical extension. 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 is in a position to make further allocations of resources to other parties must be in a position 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 that 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 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 CA’s nominated CRL update cycle. A CA certificate may be revoked by an issuing authority for a number of reasons, including key rollover, the reduction in the resource set associated with the certificate’s subject, 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’s interdomain routing system that the entire RPKI information space be 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, and so all known resource certification outcomes must be available. In other words, the RPKI’s intended use 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 is able to issue RPKI objects and publish them using a locally managed publication point. It is incumbent upon relying parties to synchronise a locally managed cache of the entire RPKI information space at regular and relatively frequent intervals. For that reason, the RPKI has introduced an additional mechanism in its publication framework-namely, the use of a manifest to enable 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 whether 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 synchronisation comparison, so that a locally managed cache of the RPKI needs call for the uploading of only those objects that have been altered since the previous synchronisation 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 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 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) (RFC3852).

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

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 authorised the AS holder to originate a routing advertisement for this prefix?

Here an address holder is authorising a particular ISP to generate a route announcement for the address holder’s 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 would 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 Autonomous System number that is being authorised in this manner; a description of the range of prefixes that the prefix holder has authorised; and the EE certificate. The document would be signed by the EE certificate’s private key by using a CMS signing structure. The resultant object is published in the RPKI distributed publication repository as a Routing Origin Authorization (ROA). A relying party can validate the ROA by checking 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 that 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. This leads 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 with a new digital signature; and, as noted, the authority can be prematurely terminated through revocation of the EE certificate, so that at no stage is there a need to reuse the original signing private key. Once the private key has been used to sign this object, the key is destroyed, alleviating to some extent the total key management load.

In any security system, knowledge of what is authorised is helpful, but knowledge of what has not been authorised is perhaps even more helpful. For ROAs there is a situation analogous to DNSSEC, where DNSSEC is most effective from a client’s perspective once 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 subhierarchies. The same could apply to ROAs, in that in an environment where not every originated route object has a published ROA, the absence of an 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 Origin Attestation (BOA).

In this case, the prefix holder generates a signed attestation, or BOA, in a manner similar 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.

While this 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 is to use a relative priority rule that ROAs take precedence over BOAs, so that if both a valid ROA and a valid BOA exist that describe the origination component of a route, then the route can be regarded as authorised.

It should be noted, however, that at this stage these concepts are works 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 position regarding the decision to advance these proposals onward along the Internet Standards Process.

Also on the near-term horizon, SIDR is examining approaches to secure the AS Path in BGP updates. The RPSEC (Routing Protocol Security Requirements) 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 as an AS adds its own AS to the AS path prior to further 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 sBGP design 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 that checks 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. While 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. In many cases, 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 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 IRR object’s author.

One possible approach, being considered by the SIDR working group, is to implement the RPSS authentication models by 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 authorise the entry of a route object into the IRR. Translating this into an analogous model by 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 its authorisation 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’s also a possibility that the IRR itself can be folded into the RPKI distributed publication repository framework, as 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 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 recognised as valid to use and that the parties using these IP addresses and AS numbers are properly authorised 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 issue of validation of the AS Path and potentially to consider the most challenging task: that 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 issues here include not only a consideration of what can be secured and validated but also issues 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 on the part 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 work in progress, and while they are reflective of the areas of activity of the SIDR working group, they do not necessarily represent finished work.



[draft-ietf-rpsec-bgpsecrec] BGP Security Requirements, B. Christian, T. Tauber, eds., 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.


[draft-ietf-sidr-arch] An Infrastructure to Support Secure Internet Routing, M. Lepinski, S. Kent, 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

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

RPKI Repository Structure

[draft-ietf-sidr-repos-struct] A Profile for Resource Certificate Repository Structure, G. Huston, G. Michaelson, R. Loomans, 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.

[draft-ietf-sidr-rpki-manifests] Manifests for the Resource Public Key Infrastructure, R. Austein et al., 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 synchronised against the authoritative original publication point.

[draft-ietf-sidr-rescerts-provisioning] A Protocol for Provisioning Resource Certificates, G. Huston, R. Loomans, B. Ellacot, R. Austein, 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 synchronised. This 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

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

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

[draft-ietf-sidr-roa-validation] Validation of Route Origination in BGP Using the Resource Certificate PKI, G. Huston, G. Michaelson, 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

[draft-ietf-sidr-cp] Certificate Policy (CP) for the Resource PKI (RPKI), K. Seo, R. Watro, D. Kong, S. Kent, 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.

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

[draft-ietf-sidr-cps-isp] Template for an Internet Service Provider’s Certification Practice Statement (CPS) for the Resource PKI (RPKI), D. Kong, K. Seo, S. Kent, 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

[draft-huston-sidr-aao-profile] A Profile for AS Adjacency Attestation Objects, G, Huston, G. Michaelson, 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.

[draft-kisteleki-sidr-rpsl-sig] Securing RPSL Objects with RPKI Signatures, R. Kisteleki, J. Boumans, 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 Routing Registry.

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


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

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

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

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

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

About the Author

Geoff Huston is a co-chair of the IETF SIDR working group. He is also the programme lead for the APNIC Resource Certification programme, a project that has implemented resource certificate management for APNIC clients.

No Comments to Show

Leave a Reply

Your email address will not be published. Required fields are marked *