-*- Text -*- $Id$ Copyright (C) 2007--2008 American Registry for Internet Numbers ("ARIN") Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS" AND ARIN DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ARIN BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. @section Terminology - IRBE: Internet Registry Back End - IRDB: Internet Registry Data Base - BPKI: Business PKI - RPKI: Resource PKI @section Protocol operations between IRBE and RPKI engine The left-right protocol is really two separate client/server protocols over separate channels. The IRBE is the client for one of the subprotocols, the RPKI engine is the client for the other. @subsection Operations initiated by the IRBE This part of the protcol uses a kind of message-passing. Each object that the RPKI engine knows about takes five messages: "create", "set", "get", "list", and "destroy". Actions which are not just data operations on objects are handled via an SNMP-like mechanism, as if they were fields to be set. For example, to generate a keypair one "sets" the "generate-keypair" field of a BSC object, even though there is no such field in the object itself as stored in SQL. This is a bit of a kludge, but the reason for doing it as if these were variables being set is to allow composite operations such as creating a BSC, populating all of its data fields, and generating a keypair, all as a single operation. With this model, that's trivial, otherwise it's at least two round trips. Fields can be set in either "create" or "set" operations, the difference just being whether the object already exists. A "get" operation returns all visible fields of the object. A "list" operation returns a list containing what "get" would have returned on each of those objects. Left-right protocol objects are encoded as signed CMS messages containing XML as eContent and using an eContentType OID of id-ct-xml (1.2.840.113549.1.9.16.1.28). These CMS messages are in turn passed as the data for HTTPS POST operations, with an HTTP content type of "application/x-rpki" for both the POST data and the response data. All operations allow an optional "tag" attribute which can be any alphanumeric token. The main purpose of the tag attribute is to allow @subsubsection object A object represents one virtual RPKI engine. In simple cases where the RPKI engine operator operates the engine only on their own behalf, there will only be one object, representing the engine operator's organization, but in environments where the engine operator hosts other entities, there will be one object per hosted entity (probably including the engine operator's own organization, considered as a hosted customer of itself). Some of the RPKI engine's configured parameters and data are shared by all hosted entities, but most are tied to a specific object. Data which are shared by all hosted entities are referred to as "per-engine" data, data which are specific to a particular object are "per-self" data. Since all other RPKI engine objects refer to a object via a "self_id" value, one must create a object before one can usefully configure any other left-right protocol objects. Every object has a self_id attribute, which must be specified for the "set", "get", and "destroy" actions. Payload data which can be configured in a object: @li use_hsm (attribute) Whether to use a Hardware Signing Module. At present this option has no effect, as the implementation does not yet support HSMs. @li crl_interval (attribute) Positive integer representing the planned lifetime of an RPKI CRL for this , measured in seconds. @li regen_margin (attribute) Positive integer representing how long before expiration of an RPKI certificiate a new one should be generated, measured in seconds. At present this only affects the one-off EE certificates associated with ROAs. @li bpki_cert (subelement) BPKI CA certificate for this . This is used as part of the certificate chain when validating incoming TLS and CMS messages, and should be the issuer of cross-certification BPKI certificates used in , , and objects. If the bpki_glue certificate is in use (below), the bpki_cert certificate should be issued by the bpki_glue certificate; otherwise, the bpki_cert certificate should be issued by the per-engine bpki_ta certificate. @li bpki_glue (subelement) Another BPKI CA certificate for this , usually not needed. Certain pathological cross-certification cases require a two-certificate chain due to issuer name conflicts. If used, the bpki_glue certificate should be the issuer of the bpki_cert certificate and should be issued by the per-engine bpki_ta certificate; if not needed, the bpki_glue certificate should be left unset. Control attributes that can be set to "yes" to force actions: @li rekey Start a key rollover for every RPKI CA associated with every object associated with this object. This is the first phase of a key rollover operation. @li revoke Revoke any remaining certificates for any expired key associated with any RPKI CA for any object associated with this object. This is the second (cleanup) phase for a key rollover operation; it's separate from the first phase to leave time for new RPKI certificates to propegate and be installed. @li reissue Not implemented, may be removed from protocol. Original theory was that this operation would force reissuance of any object with a changed key, but as that happens automatically as part of the key rollover mechanism this operation seems unnecessary. @li run_now Force immediate processing for all tasks associated with this object that would ordinarily be performed under cron. Not currently implemented. @li publish_world_now Force (re)publication of every publishable object for this object. Not currently implemented. Intended to aid in recovery if RPKI engine and publication engine somehow get out of sync. @subsubsection object The ("business signing context") object represents all the BPKI data needed to sign outgoing CMS or HTTPS messages. Various other objects include pointers to a object. Whether a particular uses only one or multiple is a configuration decision based on external requirements: the RPKI engine code doesn't care, it just cares that, for any object representing a relationship for which it must sign messages, there be a object that it can use to produce that signature. Every object has a bsc_id, which must be specified for the "get", "set", and "destroy" actions. Every also has a self_id attribute which indicates the object with which this object is associated. Payload data which can be configured in a object: @li signing_cert (subelement) BPKI certificate to use when generating a signature. @li signing_cert_crl (subelement) CRL which would list signing_cert if it had been revoked. Control attributes that can be set to "yes" to force actions: @li generate_keypair Generate a new BPKI keypair and return a PKCS #10 certificate request. The resulting certificate, once issued, should be configured as this object's signing_cert. Additional attributes which may be specified when specifying "generate_keypair": @li key_type Type of BPKI keypair to generate. "rsa" is both the default and, at the moment, the only allowed value. @li hash_alg Cryptographic hash algorithm to use with this keypair. "sha256" is both the default and, at the moment, the only allowed value. @li key_length Length in bits of the keypair to be generated. "2048" is both the default and, at the moment, the only allowed value. Replies to "create" and "set" actions that specify "generate-keypair" include a subelement, as do replies to "get" and "list" actions for a object for which a "generate-keypair" command has been issued. The RPKI engine stores the PKCS #10 request, which allows the IRBE to reuse the request if and when it needs to reissue the corresponding BPKI signing certificate. @subsubsection object The object represents the RPKI engine's view of a particular parent of the current object in the up-down protocol. Due to the way that the resource hierarchy works, a given may obtain resources from multiple parents, but it will always have at least one; in the case of IANA or an RIR, the parent RPKI engine may be a trivial stub. Every object has a parent_id, which must be specified for the "get", "set", and "destroy" actions. Every also has a self_id attribute which indicates the object with which this object is associated, a bsc_id attribute indicating the object to be used when signing messages sent to this parent, and a repository_id indicating the object to be used when publishing issued by the certificate issued by this parent. Payload data which can be configured in a object: @li sia_base (attribute) The leading portion of an rsync URI that the RPKI engine should use when composing the publication URI for objects issued by the RPKI certificate issued by this parent. @li sender_name (attribute) Sender name to use in the up-down protocol when talking to this parent. The RPKI engine doesn't really care what this value is, but other implementations of the up-down protocol do care. @li recipient_name (attribute) Recipient name to use in the up-down protocol when talking to this parent. The RPKI engine doesn't really care what this value is, but other implementations of the up-down protocol do care. @li bpki_cms_cert (subelement) BPKI CMS CA certificate for this . This is used as part of the certificate chain when validating incoming CMS messages If the bpki_cms_glue certificate is in use (below), the bpki_cms_cert certificate should be issued by the bpki_cms_glue certificate; otherwise, the bpki_cms_cert certificate should be issued by the bpki_cert certificate in the object. @li bpki_cms_glue (subelement) Another BPKI CMS CA certificate for this , usually not needed. Certain pathological cross-certification cases require a two-certificate chain due to issuer name conflicts. If used, the bpki_cms_glue certificate should be the issuer of the bpki_cms_cert certificate and should be issued by the bpki_cert certificate in the object; if not needed, the bpki_cms_glue certificate should be left unset. @li bpki_https_cert (subelement) BPKI HTTPS CA certificate for this . This is like the bpki_cms_cert object, only used for validating incoming TLS messages rather than CMS. @li bpki_cms_glue (subelement) Another BPKI HTTPS CA certificate for this , usually not needed. This is like the bpki_cms_glue certificate, only used for validating incoming TLS messages rather than CMS. Control attributes that can be set to "yes" to force actions: @li rekey This is like the rekey command in the object, but limited to RPKI CAs under this parent. @li reissue This is like the reissue command in the object, but limited to RPKI CAs under this parent. @li revoke This is like the revoke command in the object, but limited to RPKI CAs under this parent. @subsubsection object The object represents the RPKI engine's view of particular child of the current in the up-down protocol. Every object has a parent_id, which must be specified for the "get", "set", and "destroy" actions. Every also has a self_id attribute which indicates the object with which this object is associated. Payload data which can be configured in a object: @li bpki_cert (subelement) BPKI CA certificate for this . This is used as part of the certificate chain when validating incoming TLS and CMS messages. If the bpki_glue certificate is in use (below), the bpki_cert certificate should be issued by the bpki_glue certificate; otherwise, the bpki_cert certificate should be issued by the bpki_cert certificate in the object. @li bpki_glue (subelement) Another BPKI CA certificate for this , usually not needed. Certain pathological cross-certification cases require a two-certificate chain due to issuer name conflicts. If used, the bpki_glue certificate should be the issuer of the bpki_cert certificate and should be issued by the bpki_cert certificate in the object; if not needed, the bpki_glue certificate should be left unset. Control attributes that can be set to "yes" to force actions: @li reissue Not implemented, may be removed from protocol. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; Repository context -- represents one repository in which this RPKI engine ;; publishes objects it signs. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (repository :action :create :self-id 42 (:uri uri) (:ta ta) (:biz-signing-context biz-signing-context)) => (repository :repository-id 120) (repository :action :set :self-id 42 :repository-id 120 (:uri uri) (:ta ta) (:biz-signing-context biz-signing-context)) => (repository :repository-id 120) (repository :action :get :self-id 42 :repository-id 120) => (repository :repository-id 120 (:uri uri) (:ta ta) (:biz-signing-context biz-signing-context)) (repository :action :list :self-id 42 :repository-id 120) => ((repository :repository-id 120 (:uri uri) (:ta ta) (:biz-signing-context biz-signing-context))) (repository :action :destroy :self-id 42 :repository-id 120) => (repository :repository-id 120) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; Route Origin objects (prototype and control for ROAs) ;; ;; Previous versions of this protocol handled this via queries from ;; the RPKI engine back into the IRBE, but the design group now believes that ;; an imperative interface makes more sense. We stick to the same ;; general object model used above because ROAs are published objects, ;; thus the IRBE presumably wants some kind of handle on the ROA. ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (route-origin :action :create :self-id 42) => (route-origin :route-origin-id 88) (route-origin :action :set :self-id 42 :route-origin-id 88 :as-number 12345 :publish :yes (:ipv4-prefix 10.0.0.44 32) (:ipv4-range 10.2.0.6 10.2.0.77) (:ipv6-prefix 2002:a00:: 48) (:ipv6-range 2002:a02:6:: 2002:a02:4d::)) => (route-origin :route-origin-id 88) (route-origin :action :get :self-id 42 :route-origin-id 88) => (route-origin :route-origin-id 88 (:as-number 12345) (:ipv4-prefix 10.0.0.44 32) (:ipv4-range 10.2.0.6 10.2.0.77) (:ipv6-prefix 2002:a00:: 48) (:ipv6-range 2002:a02:6:: 2002:a02:4d::)) (route-origin :action :list :self-id 42) => ((route-origin :route-origin-id 88 (:as-number 12345) (:ipv4-prefix 10.0.0.44 32) (:ipv4-range 10.2.0.6 10.2.0.77) (:ipv6-prefix 2002:a00:: 48) (:ipv6-range 2002:a02:6:: 2002:a02:4d::))) (route-origin :action :destroy :self-id 42 :route-origin-id 88) => (route-origin :route-origin-id 88) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; ;; "Blind object signing" would probably be another imperative message ;; to be added above, similar to (route-origin). ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; Protocol operations between IRBE and RPKI engine. ;;; ;;; This is really two separate protocols over channels that might or ;;; not be the same. Both are client/server protocols, but for some ;;; the rpki engine and for others the irbe is the client. ;;; ;;; This set of operations are initiated by the RPKI engine. ;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (list-resources :self-id 42 ; issuer id :child id) ; subject id => (resources :valid-until 2008-04-01T00:00:00Z ((:ipv4-prefix 10.0.0.44 32) (:ipv4-prefix 10.3.0.44 32) (:ipv6-prefix fe80:dead:beef:: 48) (:as-number 666)) ((:subject-name "wombats are us") ; Allowed in protocol, but RPKI engine may reject with error (:ipv4-prefix 10.2..0.6 32) (:ipv6-prefix fe80:dead:beef:: 48) (:ipv6-range fe80:dead:beef:: fe80:dead:beef::49) (:as-number 666)) ...) (report-error :self-id 42 :error-token :your-hair-is-on-fire :bag-of-data whatever) => ()