diff options
Diffstat (limited to 'presentations')
23 files changed, 746 insertions, 0 deletions
diff --git a/presentations/Makefile b/presentations/Makefile new file mode 100644 index 00000000..a568b5e4 --- /dev/null +++ b/presentations/Makefile @@ -0,0 +1,15 @@ +# $Id$ + +all: repository-engine-objects.pdf bpki.pdf + +bpki.pdf: bpki-symmetric.pdf bpki-asymmetric.pdf + +.SUFFIXES: .pdf .dot .tex + +.dot.pdf: + dot -Tps2 $< | ps2pdf - $@ + +.tex.pdf: + pdflatex $< + pdflatex $< + rm -f $*.log $*.aux diff --git a/presentations/README b/presentations/README new file mode 100644 index 00000000..26bc0688 --- /dev/null +++ b/presentations/README @@ -0,0 +1,27 @@ +$Id$ + +Ok, there's getting to be enough stuff in this directory to be +confusing. + +README This file + +entity-decompose.pdf An overview presentation + +images Some old pictures + +left-right-protocol Pseudo-code for left-right protocol + +left-right-xml XML samples of left-right protocol + +presentations More presentations + +publication-protocol Pseudo-code for publication protocol + +repository-engine-objects.dot Objects in the RPKI engine (PDF) +repository-engine-objects.pdf Graphviz source for " + +repository-structure.txt Old notes on repository structure + +signed-manifests ASN.1 for signed manifests + +up-down-protocol Pointer to up-down protocol specification diff --git a/presentations/bpki-asymmetric.dot b/presentations/bpki-asymmetric.dot new file mode 100644 index 00000000..739cd6ee --- /dev/null +++ b/presentations/bpki-asymmetric.dot @@ -0,0 +1,84 @@ +// $Id$ +// +// Color code: +// Black: Hosting entity +// Blue: Hosted entity +// Red: Cross-certified peer +// +// Shape code: +// Octagon: TA +// Diamond: CA +// Record: EE + +digraph bpki_asymmetric { + rotate = 90; size = "11,8.5"; splines = true; ratio = fill; + + // Hosting entity + node [ color = black, shape = record ]; + TA [ shape = octagon ]; + rpkid [ label = "rpkid|{HTTPS server|HTTPS left-right client|CMS left-right}" ]; + irdbd [ label = "irdbd|{HTTPS left-right server|CMS left-right}" ]; + irbe [ label = "IRBE|{HTTPS left-right client|CMS left-right}" ]; + + // Hosted entities + node [ color = blue, fontcolor = blue ]; + Alice_CA [ shape = diamond ]; + Ellen_CA [ shape = diamond ]; + + // Peers + node [ color = red, fontcolor = red, shape = diamond ]; + Bob_CA; + Carol_CA; + Dave_CA; + Frank_CA; + Ginny_CA; + Harry_CA; + + // EE certs issued to us by peers + node [ color = red, fontcolor = red, shape = record ]; + Alice_Bob_EE [ label = "Alice-Bob\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + Alice_Carol_EE [ label = "Alice-Carol\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + Alice_Dave_EE [ label = "Alice-Dave\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + Ellen_Frank_EE [ label = "Ellen-Frank\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + Ellen_Ginny_EE [ label = "Ellen-Ginny\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + Ellen_Harry_EE [ label = "Ellen-Harry\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + Bob_EE [ label = "Bob\nEE|{HTTPS up-down|CMS up-down}" ]; + Carol_EE [ label = "Carol\nEE|{HTTPS up-down|CMS up-down}" ]; + Dave_EE [ label = "Dave\nEE|{HTTPS up-down|CMS up-down}" ]; + Frank_EE [ label = "Frank\nEE|{HTTPS up-down|CMS up-down}" ]; + Ginny_EE [ label = "Ginny\nEE|{HTTPS up-down|CMS up-down}" ]; + Harry_EE [ label = "Bob\nEE|{HTTPS up-down|CMS up-down}" ]; + + edge [ color = black, style = solid ]; + TA -> Alice_CA; + TA -> Ellen_CA; + + edge [ color = black, style = dotted ]; + TA -> rpkid; + TA -> irdbd; + TA -> irbe; + + edge [ color = blue, style = solid ]; + Alice_CA -> Bob_CA; + Alice_CA -> Carol_CA; + Alice_CA -> Dave_CA; + Ellen_CA -> Frank_CA; + Ellen_CA -> Ginny_CA; + Ellen_CA -> Harry_CA; + + edge [ color = red, style = dotted ]; + Bob_CA -> Alice_Bob_EE; + Carol_CA -> Alice_Carol_EE; + Dave_CA -> Alice_Dave_EE; + Frank_CA -> Ellen_Frank_EE; + Ginny_CA -> Ellen_Ginny_EE; + Harry_CA -> Ellen_Harry_EE; + + edge [ color = red, style = solid ]; + Bob_CA -> Bob_EE; + Carol_CA -> Carol_EE; + Dave_CA -> Dave_EE; + Frank_CA -> Frank_EE; + Ginny_CA -> Ginny_EE; + Harry_CA -> Harry_EE; +} diff --git a/presentations/bpki-asymmetric.pdf b/presentations/bpki-asymmetric.pdf Binary files differnew file mode 100644 index 00000000..fbd0362d --- /dev/null +++ b/presentations/bpki-asymmetric.pdf diff --git a/presentations/bpki-symmetric.dot b/presentations/bpki-symmetric.dot new file mode 100644 index 00000000..48e89483 --- /dev/null +++ b/presentations/bpki-symmetric.dot @@ -0,0 +1,74 @@ +// $Id$ +// +// Color code: +// Black: Hosting entity +// Blue: Hosted entity +// Red: Cross-certified peer +// +// Shape code: +// Octagon: TA +// Diamond: CA +// Record: EE + +digraph bpki_symmetric { + rotate = 90; size = "11,8.5"; splines = true; ratio = fill; + + // Hosting entity + node [ color = black, shape = record ]; + TA [ shape = octagon ]; + rpkid [ label = "rpkid|{HTTPS server|HTTPS left-right client|CMS left-right}" ]; + irdbd [ label = "irdbd|{HTTPS left-right server|CMS left-right}" ]; + irbe [ label = "IRBE|{HTTPS left-right client|CMS left-right}" ]; + + // Hosted entities + node [ color = blue, fontcolor = blue ]; + Alice_CA [ shape = diamond ]; + Alice_EE [ label = "Alice\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + Ellen_CA [ shape = diamond ]; + Ellen_EE [ label = "Ellen\nBSC EE|{HTTPS up-down client|CMS up-down}" ]; + + // Peers + node [ color = red, fontcolor = red, shape = diamond ]; + Bob_CA; + Carol_CA; + Dave_CA; + Frank_CA; + Ginny_CA; + Harry_CA; + node [ shape = record ]; + Bob_EE [ label = "Bob\nEE|{HTTPS up-down|CMS up-down}" ]; + Carol_EE [ label = "Carol\nEE|{HTTPS up-down|CMS up-down}" ]; + Dave_EE [ label = "Dave\nEE|{HTTPS up-down|CMS up-down}" ]; + Frank_EE [ label = "Frank\nEE|{HTTPS up-down|CMS up-down}" ]; + Ginny_EE [ label = "Ginny\nEE|{HTTPS up-down|CMS up-down}" ]; + Harry_EE [ label = "Bob\nEE|{HTTPS up-down|CMS up-down}" ]; + + edge [ color = black, style = solid ]; + TA -> Alice_CA; + TA -> Ellen_CA; + + edge [ color = black, style = dotted ]; + TA -> rpkid; + TA -> irdbd; + TA -> irbe; + + edge [ color = blue, style = solid ]; + Alice_CA -> Bob_CA; + Alice_CA -> Carol_CA; + Alice_CA -> Dave_CA; + Ellen_CA -> Frank_CA; + Ellen_CA -> Ginny_CA; + Ellen_CA -> Harry_CA; + + edge [ color = blue, style = dotted ]; + Alice_CA -> Alice_EE; + Ellen_CA -> Ellen_EE; + + edge [ color = red, style = solid ]; + Bob_CA -> Bob_EE; + Carol_CA -> Carol_EE; + Dave_CA -> Dave_EE; + Frank_CA -> Frank_EE; + Ginny_CA -> Ginny_EE; + Harry_CA -> Harry_EE; +} diff --git a/presentations/bpki-symmetric.pdf b/presentations/bpki-symmetric.pdf Binary files differnew file mode 100644 index 00000000..9db46451 --- /dev/null +++ b/presentations/bpki-symmetric.pdf diff --git a/presentations/bpki.pdf b/presentations/bpki.pdf Binary files differnew file mode 100644 index 00000000..979c1380 --- /dev/null +++ b/presentations/bpki.pdf diff --git a/presentations/bpki.tex b/presentations/bpki.tex new file mode 100644 index 00000000..c07c6534 --- /dev/null +++ b/presentations/bpki.tex @@ -0,0 +1,80 @@ +% $Id$ +% +\documentclass[11pt]{article} +\usepackage[pdftex]{graphicx} +\usepackage{palatino} +\usepackage{color} +\DeclareGraphicsExtensions{.pdf} +\setlength{\topmargin}{0in} +\setlength{\headheight}{0in} +\setlength{\headsep}{0in} +\setlength{\oddsidemargin}{0in} +\setlength{\evensidemargin}{0in} +\setlength{\textheight}{9in} +\setlength{\textwidth}{6.5in} +\setlength{\parskip}{2ex} +\setlength{\parindent}{0in} +\hyphenpenalty=5000 +\tolerance=1000 +\hbadness=9999 +\sloppy +\pagestyle{plain} +% +\begin{document} + +\section*{Implementation experience with the two BPKI models} + +Having recently converted my code base to the single-trust-anchor +model Russ recommended, I thought it might be useful to share what +I've learned. This may not apply to all implementations, but it does +apply to mine, and given what I understand of RIPE's business model, +it will probably apply to RIPE's implementation as well. + +In spite of a strong desire to do so, I was not able to use exactly +the same BPKI keys and certificates for HTTPS and CMS. The reason for +this is simple: each hosted entity in my engine has its own BPKI, as +does the hosting entity, but the HTTPS listener is shared. The only +ways I know of to avoid this would be to use separate listeners for +each hosted entity, which scales poorly, or to rely on the TLS +``Server Name Indication'' extension (RFC 4366 3.1) which is not yet +widely implemented. + +\begin{figure}[hbp] +\includegraphics[width = 6.5in]{bpki-symmetric} +\caption{Symmetric BPKI model} +\label{bpki-symmetric} +\end{figure} + +Figure \ref{bpki-symmetric} shows my engine's view of the BPKI tree in +the symmetric model. Black objects belong to the hosting entity, blue +objects belong to the hosted entities, red objects are cross-certified +objects from peers. The arrows indicate certificate issuance: solid +arrows are the ones that my own RPKI engine will care about during +certificate validation, dotted arrows show the origin of EE +certificates my engine uses to sign things. ``BSC'' stands for +``business signing context,'' which is a database object in my +implementation representing the context needed to sign a CMS message +or TLS session. + +Other than the above-mentioned annoyance with the HTTPS server +certificate, the ``symmetric'' BPKI model worked out pretty much as +expected here. The certificate tree looks complicated, but the set of +certificates needed to build a particular validation chain is obvious, +again excepting the HTTPS server case, where client certificate is the +first hint that the engine has of the client's identity, so the server +must be prepared to accept any current client certificate. + +\begin{figure}[hbp] +\includegraphics[width = 6.5in]{bpki-asymmetric} +\caption{Asymmetric BPKI model} +\label{bpki-asymmetric} +\end{figure} + +Figure \ref{bpki-asymmetric} shows my engine's view of the BPKI tree +in the asymmetric model. Note that not much has changed here from the +symmetric case. As far as I can tell, the asymmetric model is just as +complex for my engine as the symmetric model; the only real difference +is that the engine has to keep track of a larger number of BSC EE +certificates in the asymmetric case. + +\end{document} diff --git a/presentations/entity-decompose.pdf b/presentations/entity-decompose.pdf Binary files differnew file mode 100644 index 00000000..afde3c27 --- /dev/null +++ b/presentations/entity-decompose.pdf diff --git a/presentations/images/prague-whiteboard-2007-03-21-02-29-14.jpg b/presentations/images/prague-whiteboard-2007-03-21-02-29-14.jpg Binary files differnew file mode 100644 index 00000000..79c0a807 --- /dev/null +++ b/presentations/images/prague-whiteboard-2007-03-21-02-29-14.jpg diff --git a/presentations/images/prague-whiteboard-2007-03-22-21-50-26.jpg b/presentations/images/prague-whiteboard-2007-03-22-21-50-26.jpg Binary files differnew file mode 100644 index 00000000..4c3c828d --- /dev/null +++ b/presentations/images/prague-whiteboard-2007-03-22-21-50-26.jpg diff --git a/presentations/images/prague-whiteboard-2007-03-22-23-15-01.jpg b/presentations/images/prague-whiteboard-2007-03-22-23-15-01.jpg Binary files differnew file mode 100644 index 00000000..7b973ab0 --- /dev/null +++ b/presentations/images/prague-whiteboard-2007-03-22-23-15-01.jpg diff --git a/presentations/images/repository-structure.dot b/presentations/images/repository-structure.dot new file mode 100644 index 00000000..7154202d --- /dev/null +++ b/presentations/images/repository-structure.dot @@ -0,0 +1,42 @@ +// $URL$ +// $Id$ +// +// Pictures to go with repository-structure.txt. First picture is rekeying b with +// a g(ski)/g(ski)/g(ski).cer model, second is with stable meaningless identifiers. + +graph rekeying_ski { + rotate=90; size="11,8.5"; splines=true; ratio=fill; + node [ shape=box ]; + a [ color=black, label="rsync://host/foo/g(ski(a)).cer" ] + b [ color=red, label="rsync://host/foo/g(ski(a))/g(ski(b)).cer" ] + c [ color=red, label="rsync://host/foo/g(ski(a))/g(ski(b))/g(ski(c)).cer" ] + d [ color=red, label="rsync://host/foo/g(ski(a))/g(ski(b))/g(ski(c))/g(ski(d)).cer" ] + a -- b [ color=red ]; + b -- c [ color=red ]; + c -- d [ color=red ]; + b_ [ color=green, label="rsync://host/foo/g(ski(a))/g(ski(b')).cer" ] + c_ [ color=green, label="rsync://host/foo/g(ski(a))/g(ski(b'))/g(ski(c)).cer" ] + d_ [ color=green, label="rsync://host/foo/g(ski(a))/g(ski(b'))/g(ski(c))/g(ski(d)).cer" ] + a -- b_ [ color=green ]; + b_ -- c_ [ color=green ]; + c_ -- d_ [ color=green ]; +} + +graph rekeying_gensym { + rotate=90; size="11,8.5"; splines=true; ratio=fill; + node [ shape=box ]; + a [ color=black, label="rsync://host/foo/g(ski(a)).cer" ] + b [ color=red, label="rsync://host/foo/G001/g(ski(b)).cer" ] + c [ color=black, label="rsync://host/foo/G001/G002/g(ski(c)).cer" ] + d [ color=black, label="rsync://host/foo/G001/G002/G003/g(ski(d)).cer" ] + a -- b [ color=red ]; + b -- c [ color=red ]; + c -- d [ color=black ]; + b_ [ color=green, label="rsync://host/foo/G001/g(ski(b')).cer" ] + a -- b_ [ color=green ]; + b_ -- c [ color=green ]; +} + +// Local Variables: +// compile-command: "dot -Tps2 repository-structure.dot | ps2pdf - repository-structure.pdf" +// End: diff --git a/presentations/images/repository-structure.pdf b/presentations/images/repository-structure.pdf Binary files differnew file mode 100644 index 00000000..0fcc7615 --- /dev/null +++ b/presentations/images/repository-structure.pdf diff --git a/presentations/images/whiteboard-object-model.dot b/presentations/images/whiteboard-object-model.dot new file mode 100644 index 00000000..3c61f3ab --- /dev/null +++ b/presentations/images/whiteboard-object-model.dot @@ -0,0 +1,65 @@ +// $URL$ +// $Id$ + +// This is an attempt to capture +// http://subvert-rpki.hactrn.net/docs/prague-whiteboard-2007-03-22-23:15:01.jpg + +// {arrowhead,arrowtail} shapes to use for database object relationships: +// 1- none +// m- crow +// Color code: +// Blue: visible in left-right protocol +// Green: created on the fly + +// Explanation for many-many mapping beween CA and child objects +// (courtesy of RobL): Each child is an entity; each CA can have +// multiple children, and each child can hold certs from multiple CAs. + +digraph rpki_engine_objects { + rotate=90; size="11,8.5"; splines=true; ratio=fill; + node [ shape=record ]; + + // Objects visible in left-to-right protocol + node [ color=blue ]; + self [ label="Self|{Preferences}" ]; + parent [ label="Parent|{URI|TA}" ]; + repo [ label="Repository|{URI|TA}" ]; + child [ label="Child|{TA}" ]; + biz_sign [ label="Business\nSigning Context|{Keypair|CertChain}" ]; + + // Objects created on the fly by the RPKI engine + node [ color=green ]; + ca [ label="CA|{CRL #|Last Issued Serial #}" ]; + child_cert [ label="Child Certificate" ]; + ee_cert [ label="EE Certificate|{ROA}" ]; + ca_key_pair [ label="CA Key Pair|{Latest CA Certificate|Latest CRL}" ]; + + // One-many mappings + edge [ color=blue, arrowtail=none, arrowhead=crow ]; + biz_sign -> child; + biz_sign -> parent; + biz_sign -> repo; + self -> child; + self -> parent; + repo -> parent; + + // Many-many mappings + edge [ color=green, arrowtail=crow, arrowhead=crow ]; + ca -> child; + + // One-many mappings + edge [ color=green, arrowtail=none, arrowhead=crow ]; + ca -> ca_key_pair; + child -> child_cert; + self -> ca; + parent -> ca; + + // Weird one-many + edge [ color=green, arrowtail=none, arrowhead=crow, style=dashed ]; + ca_key_pair -> child_cert; + ca_key_pair -> ee_cert; +} + +// Local Variables: +// compile-command: "neato -Tps2 whiteboard-object-model.dot | ps2pdf - whiteboard-object-model.pdf" +// End: diff --git a/presentations/images/whiteboard-object-model.pdf b/presentations/images/whiteboard-object-model.pdf Binary files differnew file mode 100644 index 00000000..9b7da850 --- /dev/null +++ b/presentations/images/whiteboard-object-model.pdf diff --git a/presentations/presentations/070523.lacnic-pki.pdf b/presentations/presentations/070523.lacnic-pki.pdf Binary files differnew file mode 100644 index 00000000..5ab83fa3 --- /dev/null +++ b/presentations/presentations/070523.lacnic-pki.pdf diff --git a/presentations/repository-engine-objects.dot b/presentations/repository-engine-objects.dot new file mode 100644 index 00000000..24abc8dd --- /dev/null +++ b/presentations/repository-engine-objects.dot @@ -0,0 +1,86 @@ +// $URL$ +// $Id$ +// +// {arrowhead,arrowtail} shapes indicate database object relationships: +// 1- none +// m- crow +// +// Color code: +// Blue: visible in left-right protocol +// Green: created on the fly + +digraph rpki_engine_objects { + rotate=90; size="11,8.5"; splines=true; ratio=fill; + node [ shape=record ]; + + // Objects visible in left-to-right protocol + node [ color=blue ]; + self [ label="Self|{Preferences}" ]; + parent [ label="Parent|{URI|TA|SIA Base}" ]; + repo [ label="Repository|{URI|TA}" ]; + child [ label="Child|{TA}" ]; + biz_sign [ label="Business\nSigning Context|{Keypair|CertChain}" ]; + route_origin [ label="Route\nOrigin|{AS Number}" ]; + + // Objects which left-right protocol sees as part of other + // objects but which SQL needs to be separate for + // normalization. + + addr_set [ label="Address\nPrefix", color=purple ]; + + // Objects created on the fly by the RPKI engine + node [ color=green ]; + ca [ label="CA|{Last CRL #|Next CRL Date|Last Issued Serial #|Last Manifest #|Next Manifest Date|SIA URI}" ]; + ca_detail [ label="CA Detail|{CA Private Key Handle|CA Public Key|Latest CA Certificate|Manifest EE Private Key Handle|Manifest EE Public Key|Latest Manifest EE Certificate|Latest Manifest|Latest CRL}" ]; + + // Some question whether these objects need to be in database + // per se or are just properties hanging on some other object + // like ca or ca_detail. For manifests, we need last serial, + // same as for CRL. + roa [ label="ROA|{EE Certificate|ROA}" ]; + + // This one is a table of everything we have ever issued to + // this child, not to be confused with what's -currently- + // issued to this child. Some question whether this hangs off + // ca or ca_detail, but we -think- hanging off of ca_detail is + // correct because certificates are issued by a particular + // keypair. + + child_cert [ label="Child CA Certificate" ]; + + // One-many mappings + edge [ color=blue, arrowtail=none, arrowhead=crow ]; + self -> biz_sign; + biz_sign -> child; + biz_sign -> parent; + biz_sign -> repo; + self -> child; + self -> parent; + repo -> parent; + self -> route_origin; + + route_origin -> addr_set [ color=purple, arrowtail=none, arrowhead=crow ]; + + // This is many-many because each child is an entity, each CA + // can have multiple children, and each child can hold certs + // from multiple CAs (thanks, RobL). + // + ca -> child [ color=green, arrowtail=crow, arrowhead=crow ]; + + // One-many mappings + edge [ color=green, arrowtail=none, arrowhead=crow ]; + ca -> ca_detail; + child -> child_cert; + parent -> ca; + ca_detail -> child_cert; + ca_detail -> roa; + + // One-one mapping -- separate object to highlight dynamic nature + edge [ color=green, arrowtail=none, arrowhead=none, style=solid ]; + route_origin -> roa; + +} + +// Local Variables: +// compile-command: "dot -Tps2 repository-engine-objects.dot | ps2pdf - repository-engine-objects.pdf" +// End: diff --git a/presentations/repository-engine-objects.pdf b/presentations/repository-engine-objects.pdf Binary files differnew file mode 100644 index 00000000..68c6d2d6 --- /dev/null +++ b/presentations/repository-engine-objects.pdf diff --git a/presentations/repository-structure.txt b/presentations/repository-structure.txt new file mode 100644 index 00000000..327663b7 --- /dev/null +++ b/presentations/repository-structure.txt @@ -0,0 +1,111 @@ +$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. + + +This note is an attempt to write up the conclusions that several of us +came to at the RPKI meeting in Prague, March 2007. + +We currently have two examples of possible repository structure, +neither of which is quite what at least some of us think we want yet. + +APNIC's hierarchy of directories named by the g(SKI) function applied +to the public keys has some nice properties: in particular, the +hierarchical structure (subjects being stored underneath their issuers +when sharing a repository) has very nice scaling properties with +rsync. With this structure, a top-down walk such as rcynic uses will +pick up an entire tree as a side effect of fetching the top-most +issuer's SIA collection. Combined with a trivial memory cache to let +rcynic keep track of which URIs it has already fetched, this speeds up +rcynic's runtime by nearly two orders of magnitude in testing late +last year. The reason for this turns out to be simple: rsync is a +reasonably fast protocol, so one rsync connection to fetch an SIA +collection that hasn't changed takes approximately 500ms on not +terribly exciting hardware -- but in a system with more than 40,000 +objects, the cumulative total of all those half-second rsync +connections becomes significant. + +There is, however, one problem with the current APNIC structure: the +g(SKI) naming scheme means that the URIs associated with every +decendent of a particular node in the tree will change when that +node's key changes. This means that a key rollover event near the +root of the tree (eg, when APNIC's own key changes) will require a +painfully large number of certificates to be reissued. NB: only one +key is rolling in this scenario, the rest of the certificates are +being reissued with the same key, and the only reason why they need to +be reissued at all is that the path has changed. + +At the same time, the g(SKI) naming scheme has good properties for +naming certificates and CRLs, as it means that we can perform "make +before break" rollovers, leaving the old certificate path in place +until the new one is fully operational. + +So the goal here is to preserve the nice hierarchical structure of +APNIC's model, and preserve the nice properties of the g(SKI) naming +for certificates and CRLs, while avoiding the need to reissue every +desendent after a key rollover. We think that we can do this by using +static names for the directories and g(SKI)-based names for the files. + +This immediately begs the question of what the static names should be. +Some of us were tempted to make them organization names, but others of +us felt strongly that they should be completely meaningless, as they +only need to be unique within a particular parent directory and as we +really want to avoid all the "identity" issues that we have thus far +carefully avoided. We did not achieve consensus on this point, but I +(sra) am firmly in the meaningless name camp on this one. + +The upshot of all this is that I expect to be using URIs like: + + rsync://hostname/g0001/g0002/g0003/ + rsync://hostname/g0001/g0002/g0003/g(ski).cer + rsync://hostname/g0001/g0002/g0003/g(ski).crl + +where "gNNNN" indicates a generated symbol with no significance other +than that it is unique enough to avoid collisions. In this particular +case, the scope in which the symbol must be unique is just the +directory in which it appears. + +We haven't yet discussed how to name ROAs, but since we expect ROAs to +be tied to particular single-use EE certs, my guess is that a g(SKI) +name based on the key of the EE cert would be appropriate, so either +of the following forms would probably work: + + rsync://hostname/g0001/g0002/g0003/g0004/g(ski).roa + rsync://hostname/g0001/g0002/g0003/g(ski)/g(ski).roa + +The latter violates the rule of only using g(SKI) names for files, +never for directories, but in this case it'd probably be ok. + +This assumes that we're generating a new key for each ROA; if we're +reusing keys (dunno), we'd need a naming scheme like: + + rsync://hostname/g0001/g0002/g0003/g(ski)/g0004.roa + +For those unfamiliar with the notation (borrowed from Lisp): g0001 etc +are just "gensym" symbols, ie, the output of some function whose sole +purpose is to generate meaningless symbols. + +See images/repository-structure.pdf for an illustration of the problem +and solution. + +There may be compromise-driven rollover cases in which we will need to +reissue all of the children of a node whose key has been compromised. +Whether or not this is necessary depends on whether the master copy of +the authoritative data is safe somewhere else; if it is, and the +resource certificates are just a signed representation of an +authoritative database that has not been compromised, reissuing all of +the descendants may not be necessary, but if the resource certificates +-are- the database, and one level in it has been compromised, it's +probably advisable to reissue all the descendants. diff --git a/presentations/sample-irdb-data.sql b/presentations/sample-irdb-data.sql new file mode 100644 index 00000000..df24b48f --- /dev/null +++ b/presentations/sample-irdb-data.sql @@ -0,0 +1,80 @@ +-- $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. + +INSERT INTO registrant (IRBE_mapped_id) VALUES ('ARIN'); +INSERT INTO registrant (IRBE_mapped_id) VALUES ('TIER1_ISP1'); +INSERT INTO registrant (IRBE_mapped_id) VALUES ('TIER1_ISP2'); +INSERT INTO registrant (IRBE_mapped_id) VALUES ('JOES_PIZZA'); + +INSERT INTO resource_class (subject_name, valid_until, registrant_id) +SELECT 'All ARIN resources', '2099-12-31', registrant_id +FROM registrant WHERE IRBE_mapped_id = 'ARIN'; + +INSERT INTO resource_class (subject_name, valid_until, registrant_id) +SELECT 'Tier 1 ISP foo subject name', '2008-12-31', registrant_id +FROM registrant WHERE IRBE_mapped_id = 'TIER1_ISP1'; + +INSERT INTO resource_class (subject_name, valid_until, registrant_id) +SELECT 'Tier 1 ISP foo subject name', '2009-06-30', registrant_id +FROM registrant WHERE IRBE_mapped_id = 'TIER1_ISP1'; + +INSERT INTO resource_class (subject_name, valid_until, registrant_id) +SELECT 'Tier 1 ISP bar subject name', '2007-07-31', registrant_id +FROM registrant WHERE IRBE_mapped_id = 'TIER1_ISP2'; + +INSERT INTO resource_class (subject_name, valid_until, registrant_id) +SELECT 'arbitrary characters', '2007-12-31', registrant_id +FROM registrant WHERE IRBE_mapped_id = 'JOES_PIZZA'; + +INSERT INTO net (start_ip, end_ip, version, resource_class_id) +SELECT 'DEAD:BEEF:0000:0000:0000:0000:0000:0000', 'DFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF', 6, resource_class_id +FROM resource_class WHERE subject_name = 'All ARIN resources'; + +INSERT INTO net (start_ip, end_ip, version, resource_class_id) +SELECT 'DEAD:BEEF:FACE:0000:0000:0000:0000:0000', 'DEAD:BEEF:FACE:FFFF:FFFF:FFFF:FFFF:FFFF', 6, resource_class_id +FROM resource_class WHERE subject_name = 'TIER 1 ISP foo subject name' AND valid_until = '2009-06-30'; + +INSERT INTO net (start_ip, end_ip, version, resource_class_id) +SELECT 'DEAD:BEEF:FACE:FADE:0000:0000:0000:0000', 'DEAD:BEEF:FACE:FADE:FFFF:FFFF:FFFF:FFFF', 6, resource_class_id +FROM resource_class WHERE subject_name = 'arbitrary characters' AND valid_until = '2007-12-31'; + +INSERT INTO net(start_ip, end_ip, version, resource_class_id) +SELECT '010.000.000.000', '010.255.255.255', 4, resource_class_id +FROM resource_class WHERE subject_name = 'All ARIN resources'; + +INSERT INTO net(start_ip, end_ip, version, resource_class_id) +SELECT '010.128.000.000', '010.191.255.255', 4, resource_class_id +FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2009-06-30'; + +INSERT INTO net(start_ip, end_ip, version, resource_class_id) +SELECT '010.000.000.000', '010.063.255.255', 4, resource_class_id +FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2009-06-30'; + +INSERT INTO net(start_ip, end_ip, version, resource_class_id) +SELECT '010.128.000.000', '010.191.255.255', 4, resource_class_id +FROM resource_class WHERE subject_name = 'arbitrary characters'; + +INSERT INTO asn(start_as, end_as, resource_class_id) +SELECT 12345, 12345, resource_class_id +FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2009-06-30'; + +INSERT INTO asn(start_as, end_as, resource_class_id) +SELECT 23456, 23457, resource_class_id +FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2009-06-30'; + +INSERT INTO asn(start_as, end_as, resource_class_id) +SELECT 34567, 34567, resource_class_id +FROM resource_class WHERE subject_name = 'Tier 1 ISP foo subject name' AND valid_until = '2008-12-31'; diff --git a/presentations/signed-manifests b/presentations/signed-manifests new file mode 100644 index 00000000..d1bd3f5e --- /dev/null +++ b/presentations/signed-manifests @@ -0,0 +1,74 @@ +-- $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. + +-- Signed manifests for RPKI repositories. Relying parties use object +-- (as opposed to channel) security for everything in this design +-- repository, which is the right thing to do for various reasons but +-- leaves us open to attacks which intercept the rsync connection and +-- drop valid objects out of an SIA collection. At present this is +-- not detectable, so we need a mechanism. +-- +-- Manifests as described here are modeled on CRLs, because the issues +-- involved in detecting stale manifests, manifest replays, etc are +-- similar to those for CRLs. So we want many of the fields that a +-- CRL has. Syntax differs, though, since RPKI repositories can +-- contain objects not covered by CRLs (eg, ROAs), and reuse CMS as +-- the manifest signature format rather than inventing another one. +-- +-- See RFC 3280 section 5 for CRL layout and extensions. +-- +-- We're only trying to cover objects in the same SIA collection +-- (directory) as the manifest. We will probably want to name the +-- manifest itself with a name derived from the g(ski) of the cert of +-- which this is the SIA collection. We'll need an EE cert to sign +-- the manifest; the EE cert should probably just use RFC 3779 +-- inheritance to cover all the resources that its issuer holds. If we +-- use CMS, we might just want to include the EE cert in the CMS +-- bag of certs. +-- +-- Lisp pseudo-code version of my original proposal for what goes +-- inside the CMS wrapper: +-- +-- (manifest :version 1 +-- :collection-uri "rsync://foo.example/wombat/" +-- :this-update timestamp +-- :next-update timestamp +-- :manifest-serial 17 +-- :hash-algorithm :sha256 +-- (:name foo.cer :hash aabbccdd...) +-- (:name bar.cer :hash bbccddee...) +-- (:name foo.roa :hash ccddeeff...) +-- (:name baz.crl :hash ddeeff00...) +-- ...) +-- +-- Steve Kent came up with something very similar in ASN.1. At this +-- point I think that Steve and I have converged, so here is Steve's +-- ASN.1, which, absent new issues, I expect to implement with +-- OpenSSL's ASN.1 engine. + +Manifest ::= SEQUENCE { + version [0] INTEGER DEFAULT 0, -- first version is 0 + manifestNumber INTEGER, -- to identify unscheduled manifest issuance + thisUpdate GeneralizedTime, -- this manifest issuance time + nextUpdate GeneralizedTime, -- next scheduled manifest issuance time + fileHashAlg OBJECT IDENTIFIER, -- algorithm used to generate file content hash values + fileList SEQUENCE OF FileAndHash -- list of file name and content hash pairs +} + +FileAndHash ::= SEQUENCE { + file IA5String -- file name + hash BIT STRING -- hash of file content +} diff --git a/presentations/up-down-protocol b/presentations/up-down-protocol new file mode 100644 index 00000000..4e4aa86c --- /dev/null +++ b/presentations/up-down-protocol @@ -0,0 +1,8 @@ +$Id$ + +The master copy of the up-down protocol currently lives in a wiki at +APNIC. A flat text mirror of this document can be found at: + +http://subvert-rpki.hactrn.net/wiki-mirror/text/mirin.apnic.net/resourcecerts/wiki/index.php/IR-ISP_Definition + +(ie, ../wiki-mirror/text/mirin.apnic.net/resourcecerts/wiki/index.php/IR-ISP_Definition within this repository). |
