diff options
| -rw-r--r-- | rpkid/README | 222 |
1 files changed, 117 insertions, 105 deletions
diff --git a/rpkid/README b/rpkid/README index 7fabfe9c..17f95192 100644 --- a/rpkid/README +++ b/rpkid/README @@ -52,22 +52,12 @@ $Revision$ TO DO: - - Update business trust anchor model to what was defined in Amsterdam. This - was a direct result of security review by Kent and Housley. + - Update BPKI model to what was defined in Amsterdam. This was + a direct result of security review by Kent and Housley. Much of this is now done. Remaining tasks: - Add CRL to BSC - Check for CRL in received CMS - Check chain length in received CMS Check chain length in received TLS - Check EE vs CA during validation - If CMS cert in SQL is EE: - Disallow certs in CMS - Disallow CRLs in CMS - Else: - Expect exactly one EE cert in CMS - Expect exactly one CRL in CMS If TLS cert in SQL is EE: EE cert in SQL must be same as EE cert received from TLS @@ -78,14 +68,16 @@ TO DO: STATUS: Started - - rcynic handling of RPKI trust anchors needs updating, per discussions - over previous months of how RPKI trust anchors work, how we package them, - and how we roll them over. The last (TA rollover) is the driver for this. + - rcynic handling of RPKI trust anchors needs updating, per + discussions over previous months of how RPKI trust anchors + work, how we package them, and how we roll them over. The last + (TA rollover) is the driver for this. - APNIC is now proposing a CMS-signed ASN.1 blob containing a version - number and an RPKI certificate. Kent and Housley have not bought into - this yet. Need to do analysis to make sure this is adequate for our - needs, if so just use it. This would involve minor changes to rcynic. + APNIC is now proposing a CMS-signed ASN.1 blob containing a + version number and an RPKI certificate. Kent and Housley have + not bought into this yet. Need to do analysis to make sure + this is adequate for our needs, if so just use it. This would + involve minor changes to rcynic. PRIORITY: Required for pilot (usability issue for relying parties) @@ -94,28 +86,30 @@ TO DO: STATUS: Not started - - Publication protocol and implementation thereof. Desirable although not - strictly required that protocol be agreed upon among the RIRs. Tricky bit - is making sure that repository receives enough information to know whether - parent has authorized child to use parent's namespace in nesting case; in + - Publication protocol and implementation thereof. Desirable + although not strictly required that protocol be agreed upon + among the RIRs. Tricky bit is making sure that repository + receives enough information to know whether parent has + authorized child to use parent's namespace in nesting case; in theory this is straightforward but requires careful checking. - ARIN can't host output of non-hosted RPKI engines without this, and that's - critical both to the security model as discussed with ARIN staff in late 2006, - hence this is a required capability even for testing. + ARIN can't host output of non-hosted RPKI engines without + this, and that's critical both to the security model as + discussed with ARIN staff in late 2006, hence this is a + required capability even for testing. PRIORITY: Required for pilot - TIME REQUIRED: 3-4 weeks for implementation once protocol settled, depending on - how much of the existing left-right protocol design and implementation can be - reused. + TIME REQUIRED: 3-4 weeks for implementation once protocol + settled, depending on how much of the existing left-right + protocol design and implementation can be reused. STATUS: Started - - Resource subsetting (req_* attributes in up-down protocol), minimal - implementation. Recognize this as correct protocol and signal an - internal server error if ever used. + - Resource subsetting (req_* attributes in up-down protocol), + minimal implementation. Recognize this as correct protocol + and signal an internal server error if ever used. PRIORITY: Required for pilot. @@ -124,9 +118,9 @@ TO DO: STATUS: Not started - - ROA generation code. First cut at this seems to work and output looks - right, but this hasn't been tested properly yet due to lack of a ROA - validation tool. + - ROA generation code. First cut at this seems to work and + output looks right, but this hasn't been tested properly yet + due to lack of a ROA validation tool. For reasons that presumably made sense at the time, the left-right protocol for route_origin objects allows ranges as @@ -135,6 +129,11 @@ TO DO: prefixes. So left-right schema should only allow prefixes, and SQL should only store prefixes. + Current ROA code implements current draft. Upcoming draft + will probably change ROA format to remove per-ROA exactMatch + field and add a per-prefix maxLength field; implementing this + will require mods to <route_origin/>. + PRIORITY: Required for pilot TIME REQUIRED: One week (remaining) @@ -142,11 +141,12 @@ TO DO: STATUS: Started - - rcynic does not yet handle manifests. This is both a real problem - (manifests were added to plug a security hole) and a user acceptance - problem (without manifest support rcynic checks old certs that are supposed - to fail because they've been revoked, resulting in what appear to be - spurious errors, which just annoy the user). + - rcynic does not yet handle manifests. This is both a real + problem (manifests were added to plug a security hole) and a + user acceptance problem (without manifest support rcynic + checks old certs that are supposed to fail because they've + been revoked, resulting in what appear to be spurious errors, + which just annoy the user). PRIORITY: Required for pilot @@ -155,9 +155,10 @@ TO DO: STATUS: Not started - - User validation tool: fetch and validate certs and ROA for a prefix that - the user wants to accept in a router filter the user is building. This - probably uses rcynic's output as one of its inputs. + - User validation tool: fetch and validate certs and ROA for a + prefix that the user wants to accept in a router filter the + user is building. This probably uses rcynic's output as one of + its inputs. PRIORITY: Required @@ -168,8 +169,9 @@ TO DO: STATUS: Not started - - Make rpkid fully event-driven (async tasking model), except for SQL - queries. This probably involves the "twisted" framework. + - Make rpkid fully event-driven (async tasking model), except + for SQL queries. This probably involves the "twisted" + framework. PRIORITY: Required (to implement scalable hosting model) @@ -178,10 +180,10 @@ TO DO: STATUS: Not started - - Error handling: make sure that exceptions map correctly to up-down error - codes, flesh out left-right error codes. Note that the same exception may - produce different error codes depending on which up-down PDU we're - processing (sigh). + - Error handling: make sure that exceptions map correctly to + up-down error codes, flesh out left-right error codes. Note + that the same exception may produce different error codes + depending on which up-down PDU we're processing (sigh). Will require code audit for coherency, which is most of the work. @@ -189,16 +191,18 @@ TO DO: TIME REQUIRED: Two weeks - DEPENDS ON: almost everything else, as almost any code change can raise new - exceptions that we'd need to handle. + DEPENDS ON: almost everything else, as almost any code change + can raise new exceptions that we'd need to handle. STATUS: Not started - - db.commit(), db.rollback(), code audit for data integrity issues, fix any - data integrity issues that turn up. Among other issues, need to handle loss - of connection to database server and other MySQL errors. Need to be careful - about recovery action depending on whether we had uncommitted changes. + - db.commit(), db.rollback(), code audit for data integrity + issues, fix any data integrity issues that turn up. Among + other issues, need to handle loss of connection to database + server and other MySQL errors. Need to be careful about + recovery action depending on whether we had uncommitted + changes. PRIORITY: Required @@ -206,16 +210,16 @@ TO DO: TIME REQUIRED (data integrity audit): 1 week - TIME REQUIRED (fix data integrity): Unknown, depends on code audit and results - of runtime testing. + TIME REQUIRED (fix data integrity): Unknown, depends on code + audit and results of runtime testing. DEPENDS ON: async tasking model rollback. STATUS: Not started - - Test framework for multiple self-instances per engine-instance (single - self-instance per engine-instance is already done). + - Test framework for multiple self-instances per engine-instance + (single self-instance per engine-instance is already done). PRIORITY: Required for testing @@ -226,16 +230,17 @@ TO DO: STATUS: Not started - - Current TLS code (tlslite) appeared to be flakey under heavy use back - in November, and doesn't support all the required certificate - checks out of the box. + - Current TLS code (tlslite) appeared to be flakey under heavy + use back in November, and doesn't support all the required + certificate checks out of the box. - Certificate checker has now been replaced with something based on - OpenSSL/POW, and the result seems to work. If the TLS code itself is - still unstable, best bet would be to replace it with a Tls class cloned - from the existing POW Ssl class; the current Ssl class isn't adaquate - either, but there's documentation (eg, the O'Reilly OpenSSL book) that - explains in some detail what this code would need to do. + Certificate checker has now been replaced with something based + on OpenSSL/POW, and the result seems to work. If the TLS code + itself is still unstable, best bet would be to replace it with + a Tls class cloned from the existing POW Ssl class; the + current Ssl class isn't adaquate either, but there's + documentation (eg, the O'Reilly OpenSSL book) that explains in + some detail what this code would need to do. PRIORITY: Required for pilot (cert checking is a security issue). @@ -246,9 +251,9 @@ TO DO: STATUS: Not started - - Resource subsetting (req_* attributes in up-down protocol), full - implementation. Requires expanding SQL child_cert table to hold subset - masks and rewriting a fair amount of code. + - Resource subsetting (req_* attributes in up-down protocol), + full implementation. Requires expanding SQL child_cert table + to hold subset masks and rewriting a fair amount of code. PRIORITY: Required for full implementation. @@ -262,9 +267,9 @@ TO DO: STATUS: Not started - - Clean up rootd.py to be usable in a production system. Most urgent issue is - handling of private keys. May not need much else, as this is not a - high-traffic server. + - Clean up rootd.py to be usable in a production system. Most + urgent issue is handling of private keys. May not need much + else, as this is not a high-traffic server. PRIORITY: Highly desirable (not strictly needed for pilot testing) @@ -273,10 +278,11 @@ TO DO: STATUS: Not started - - Update internals docs (Doxygen). Mostly this means updating function - comments in the Python code, as the rest is automatic. May require a bit of - overview text to explain the workings of the code, this overview text may - well turn out to be just the current flat text documents marked up for + - Update internals docs (Doxygen). Mostly this means updating + function comments in the Python code, as the rest is + automatic. May require a bit of overview text to explain the + workings of the code, this overview text may well turn out to + be just the current flat text documents marked up for inclusion by Doxygen. PRIORITY: Desirable @@ -286,11 +292,12 @@ TO DO: STATUS: Ongoing - - Reorganize code (directory names, module names, which objects are in which - modules, add gctx pointers to objects to avoid passing explicit gctx - pointers in almost every function call) to make it easier to understand and - maintain. Portions of the existing code were done in extreme haste to meet - testing deadlines, and it shows. + - Reorganize code (directory names, module names, which objects + are in which modules, add gctx pointers to objects to avoid + passing explicit gctx pointers in almost every function call) + to make it easier to understand and maintain. Portions of the + existing code were done in extreme haste to meet testing + deadlines, and it shows. PRIORITY: Highly desirable @@ -311,13 +318,13 @@ TO DO: STATUS: Not started - - Installation packaging, so that rpkid can be built and installed like a - normal package. + - Installation packaging, so that rpkid can be built and + installed like a normal package. PRIORITY: Desirable - TIME REQUIRED: One week, longer if installation for many platforms is - required + TIME REQUIRED: One week, longer if installation for many + platforms is required STATUS: Not started @@ -332,21 +339,24 @@ TO DO: - Rethink exposing SQL primary indices in protocols. Right now, - auto-incremented SQL indices are used in many places in the left-right - protocol, and are even exposed in a few places in our implementation of the - up-down protocol. This is nice and unique but may be operationally fragile, - since up-down usage means that URLs contain mechanically assigned - identifiers rather than an identifier negotiated between the two parties + auto-incremented SQL indices are used in many places in the + left-right protocol, and are even exposed in a few places in + our implementation of the up-down protocol. This is nice and + unique but may be operationally fragile, since up-down usage + means that URLs contain mechanically assigned identifiers + rather than an identifier negotiated between the two parties during contract setup. - The RIPE NCC suggested that we should instead use something like a hash of the - client's name, which would be probabilistically unique, would not expose - information, but would be stable even if we had to rebuild the database. + The RIPE NCC suggested that we should instead use something + like a hash of the client's name, which would be + probabilistically unique, would not expose information, but + would be stable even if we had to rebuild the database. PRIORITY: Rethinking desirable; reworking unknown - TIME REQUIRED: One week to evaluate. Implementation time if we decide to make a - change unknown, but probably on the order of another week. + TIME REQUIRED: One week to evaluate. Implementation time if we + decide to make a change unknown, but probably on the order of + another week. STATUS: Not started @@ -361,10 +371,11 @@ TO DO: STATUS: Not started - - IETF SIDR WG is still talking about ROAs with multiple signatures. No - obvious need for this but IETF may mandate it anyway. Full implementation - would require significant work revising current SQL table relations and - upgrading CMS support. + - IETF SIDR WG is still talking about ROAs with multiple + signatures. No obvious need for this but IETF may mandate it + anyway. Full implementation would require significant work + revising current SQL table relations and upgrading CMS + support. PRIORITY: Minimal, IETF feeping creaturism @@ -373,10 +384,11 @@ TO DO: STATUS: Not started - - Deaddrop of incoming messages, for audit. Absent a better theory, - steal existing tech for this: preface with minimal RFC 2822 header - and drop it into a Maildir folder using built-in Python Maildir - library code, at which point it becomes soebody else's problem. + - Deaddrop of incoming messages, for audit. Absent a better + theory, steal existing tech for this: preface with minimal RFC + 2822 header and drop it into a Maildir folder using built-in + Python Maildir library code, at which point it becomes soebody + else's problem. STATUS: Not started |