diff options
| -rw-r--r-- | myrpki.rototill/PLAN | 404 | ||||
| -rw-r--r-- | myrpki.rototill/testbed-rootcert.py (renamed from myrpki.rototill/arin-rootcert.py) | 10 |
2 files changed, 3 insertions, 411 deletions
diff --git a/myrpki.rototill/PLAN b/myrpki.rototill/PLAN deleted file mode 100644 index 37a64c02..00000000 --- a/myrpki.rototill/PLAN +++ /dev/null @@ -1,404 +0,0 @@ --*- Text -*- -$Id$ - -plan for new myrpki setup tools. need better name for them, among -other things. - -- dig out old proposed better names for myrpki and myirbe, use those. - bpki.myrpki => bpki.resources (or perhaps bpki/resources) - bpki.myirbe => bpki.servers - - bpki.resources is used for tls client and all cms in up-down and - object publication. - - bpki.servers is used for all tls server certs, and is also used for - tls client and all cms in left-right and publication control. - - had proposed new names for .py scripts, dig those out but will also - be creating a bunch of new scripts here to confuse the issue. - -- for the moment i'm completely ignoring security of the new setup - protcol. this clearly will not fly even in the short run, but let's - start by figuring out who needs to do what to whom before worrying - about how to prove that everybody is who they claim to be. - -- need a script to create new self (resource holding identity). this - creates bpki.resources, takes that and [myrpki]handle variable, - packages that as an xml blob. - -- send self xml blob to parent, current theory seems to be upload to a - web form. parent responds with a lot of the stuff currently in - parents.csv, and perhaps also with a hint about where to publish, - all packaged as an xml blob. well, maybe (also?) a link to - publication service that i can click on? - - current fields in parents.csv: - - # Syntax: <parent_handle> <service_uri> <cms_bpki_cert_filename> <https_bpki_cert_filename> <myhandle> <sia_base> - - <parent_handle> is a private matter, that probably turns into name - of the parent xml blob when i store it on disk, nobody else's - business what i call it - - <service_uri> and <myhandle> are supplied by parent, based on - whatever name parent uses for itself and what name it uses for me. - i've told it what i call myself, but parent probably has its own - name for me. - - <cms_bpki_cert_filename> and <https_bpki_cert_filename> parent just - supplies, nothing complex there (well, except for boostrap process - for rootd, but that's a separate mess). - - <sia_base> still makes my head hurt. not just me. - -- also send self xml blob to hosting, who may or may not be another - aspect of myself. hosting entity supplies (new? update of mine?) - xml blob containing bpki.servers and rpkid service url - ([myirbe]rpkid_base url value). will need to supply all of this to - any children. - - [myirbe]pubd_base makes my head hurt. why is <sia_base> in - parents.csv while pubd_base is in [myirbe] ? gah.... along with - everything else, this seems like really weird db normalization. - - kind of seems like <sia_base> goes with [myirbe]pubd_base and both - really need to be supplied by resource holder via negotiation with a - publication service. - -- a lot of the data for rpkid and pubd operator can be pulled from - config file, no need for separate configuration. perhaps in this - brave new world we lock people using this ui into one big config - file for everything so we can avoid making them type everything - three times? still some icky stuff with [rpkid], [irdbd], etc - sections linking to each other, not immediately obvious how to fix - that without losing generality in core daemons, but maybe inspect - these sections again and there will be some simple approach. - -- when answering setup request from child, we need to save xml blob - they sent us as replacement for a line that's now in children.csv. - well, but we also need expiration date, how fun. - - # Syntax: <child_handle> <validitydate> <bpki_cert_filename> - - <child_handle> becomes name of xml blob file: children/foo.xml or - whatever. it's a private matter except that we have to tell the - child what we picked so they can use it in up-down protocol. this - same name goes into service url we cons up for this child. - - <validitydate> we need to deduce, invent, or look up, somehow. in - real production we would have this on file as it's tied to contract - expiration. in testing we've just been saying "one year from - today". - - <bpki_cert_filename> is the child's bpki.resources cert, which they - just handed us, yay. - -- when answering setup request from publication client, we need to - save xml blob, same as parent saving child. - - # Syntax: <client_handle> <bpki_cert_filename> <sia_base> - - <client_handle> is what we call this client, name of xml blob file - we save, we get to chose it but we have to tell client what we chose - so they can use it. this same name goes into service url we cons up - for this client. - - <bpki_cert_filename> is the client's bpki.resources cert, which they - just handed us, yay. - - <sia_base> is making my head hurt yet again. this time it is what - we will allow this client to use, so it'd better not conflict with - any other publication client. oh, wait, i said this was zero - security at the moment, ok. - -- i should write converters from the current parents.csv, - children.csv, and pubclients.csv into the new format, both to - simplify migration and also as a clue as to what i've forgotten. - -- the above story is weak on publication setup. among other things, - the linkage between parent and repository that publishes things that - come from classes derived from that parent is weak, perhaps because - that linkage doesn't make any particular sense outside of rpkid's - object model. the real restriction in rpkid is that all the resource - classes derived from a single parent object share a repository - object. - -- oh yeah, and, unrelated to any of the above, i should check the - syntax restrictions on up-down resource class names, and perhaps - replace the numeric (last vestige of sql-derived identifiers) - resource class names we're using with resource class names extruded - from irdb. which might involve hacking left-right protocol, and - might create a uniqueness problem when publishing children under - self, but would be nice to get rid of the sql-derived ids. - - - -To: RPKI Testbed <rpki@rpki.net> -Subject: plan for new rpki setup tools -From: Rob Austein <sra@hactrn.net> -X-Original-To: sra@cyteen.hactrn.net -Delivered-To: sra@cyteen.hactrn.net -Date: Sat, 30 Jan 2010 02:00:02 -0500 -Mime-Version: 1.0 -Content-Transfer-Encoding: 7bit -Message-Id: <20100130070003.7706715F382@angband.hactrn.net> - -per findings of the tokyo rpki workshop, here's an outline of the -current plan for revised setup tools for the rpki code. - -step 1: user run a new "initialize" script. this reads the .conf file - and creates the resource-holding "self" bpki identity (what - we've been calling bpki.myrpki/ca.cer, although that name - should change and the user shouldn't need to know it anymore). - if the .conf file says that this user will be running any - servers at all (rpkid, irdbd, pubd, rootd), this script also - creates what we've been calling bpki.myirbe/ca.cer and issues - bpki ee certificates for all the servers we will be running. - it bundles up the "self" identity (bpki.myrpki/ca.cer and the - "handle" value from the [myrpki] section of the .conf file) as - an xml blob, which it writes out to some filename (call it - me.xml for now). - - the general idea here is to start with all the setup that we - can do based just on the .conf file without talking to anybody - else. - -step 2: user sends me.xml to parent, who saves it in a file - children/foo.xml (where foo is the parent's name for this - child). parent also feeds this file and and parent's own - me.xml into another new script (call it "setup_child" for now, - since the parent uses it to set up its child). this script - writes out a customized parent record (another xml blob) - tailored to this particular child (service url including - parent's and child's names, parent's rpkid server bpki cert, - etc -- most of the data that goes into a line in parents.csv - now). this xml blob can (and usually does) also include - either an offer of publication service (if the parent runs - pubd and is willing to act as repository for this child) or a - hint pointing to some other repository (probably the one the - parent itself uses). the distinction between offer and hint - here is that the parent can only offer a pubd server it runs; - for anything else it can only hint. parent sends this xml - result blob back to child, who stores at in a parents/ - directory with a name corresponding to the current - parent_handle (ie, the filename is the child's name for the - parent, eg, arin.xml). - -step 3: user sends me.xml to a publication service (probably the one - offered or hinted by the parent); publication service feeds - that and its own me.xml into yet another new script (call it - "setup_client") for now. this script does essentially the - same for things for the publication service as the setup_child - script does for the parent: it generates a customized xml blob - to be returned to the client, telling the client what service - url, pubd bpki cert, etc to use when talking to this - repository. - -step 4: user sends all of the stuff collected so far to whatever - entity is going to host it (run rpkid for it), who then runs a - "setup_hosting" script; in the common case where this user - hosts itself, this just means that the user runs setup_hosting - for itself. in either case, this fills in the last missing - bits (service url and bpki cert for children of this user to - use when talking to its rpkid, etc). result of this is an - updated me.xml file. - -step 2 repeats for multiple parents. in theory, step 3 could repeat -for multiple publication services, in practice that's less likely - -after performing the above steps, the user should have all the data -necessary to start running the current my{rpki,irbe} scripts. -we'll probably want to integrate all off this a bit better with the -current code (which will need some rewriting in any case). - -rootd is a special case, in this as in all else. when we're running -rootd, the initalize script should probably just create everything -needed for rootd and for rpkid to know about rootd as its parent. -rootd is always operated by the same entity as the rpkid that uses -this rootd as its parent, so this is a bit tedious but should be -straightforward. similarly, i think it's ok for us to insist that the -operator running rootd must also run its own pubd. - -the sequence of events in the numbered steps above matters: we have -nothing to talk about until we create our own identity, and we don't -know which publication service to talk to until we have talked to our -parent. it may not be necessary to postpone hosting setup until last, -but it's probably harmless and may make it easier to merge all or part -of this last step into the my{rpki,irbe} dialog. - -i don't really know yet whether all of the new scripts above are -really new scripts or are calls to a smaller number of scripts with -more arguments. don't feel strongly about it, most important -criterion is to minimize user confusion. - -comments welcome. i may not get to them for a few weeks, as it's ski -season :) - - - -To: RPKI Testbed <rpki@rpki.net> -Subject: Re: renaming some of the obscure bits of myrpki -From: Rob Austein <sra@hactrn.net> -X-Original-To: sra@cyteen.hactrn.net -Delivered-To: sra@cyteen.hactrn.net -Date: Sun, 04 Oct 2009 16:34:57 -0400 -In-Reply-To: <m2eipknqxp.wl%randy@psg.com> -User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) -Mime-Version: 1.0 -Content-Transfer-Encoding: 7bit -Message-Id: <20091004203457.740F822807@thrintun.hactrn.net> - -briefly going back to the original topic of this thread (before randy -hijacked it to beat me up about missing documentation :) - -At Sun, 04 Oct 2009 05:49:38 +0900, Randy Bush wrote: -> -> > bpki.myrpki/ => bpki.resources/ -> > bpki.myirbe/ => bpki.daemons/ -> -> make sense -> -> > myrpki.py => update_resources.py -> -> update which resources? mine by fetching from parent? -> -> > myirbe.py => update_daemons.py -> -> get new code from svn repository? - -how about: - -myrpki.py => configure_resources.py -myirbe.py => configure_daemons.py - -? - -per yesterday's conversation, there are a couple of missing scripts, -perhaps with names like: - -do_initial_setup.py -run_servers.py - - -thrintun.hactrn.net:/u/sra/rpki/subvert-rpki.hactrn.net/myrpki.rototill/PLAN, 26-Feb-2010 16:03:29, sra - -Current theory on out-of-band XML-based setup protocol. - -Step 1: initialize.py generates lots of stuff (see previous pages), - writes initial self.xml containing handle and - bpki/myrpki/ca.cer - -Step 2: setup_child.py ... and sends back xml containing: - - parent's bpki/myrpki/ca.cer - parent's (or parent's host's) bpki/myirbe/ca.cer - service url, up-down sender/recipient names - and either: - - A publication offer, which contains just the service url - (because server ca is same as rpkid's? i think so. not - allowed to offer when we're not running pubd. well, ok, - i suppose we could be running pubd without running rpkid, - kind of perverse but if it should be legal we need to pass - back the bpki/myirbe/ca.cer in this case); or - - A publication hint, which would include the - bpki/myirbe/ca.cer of the publication server and a signed - (cms blob wrapping something) authorization for - publication server to grant part of parent's publication - space to child (which would also need to identify the - child, so would need to include child bpki/myrpki/ca.cer). - - This does kind of sound like we should just always include - publication server's bpki/myirbe/ca.cer and not worry about - optimizing that. - - From parent's point of view, an offer could just be a referral - that the parent knows it's willing to accept, but maybe the - distinction matters to the child. Semantics should probably - follow biz practice rather than implemntation arcana, and in - biz practice there certainly is a difference between and offer - and a hint to use a third party, so keep distinction. - -Step 3: setup_client.py (icky name) reads, um, self.xml and parent's - response (from step 2) and spits out, um, just contact URL I - think, as client appears to have bpki/myirbe/ca.cer already. - -Step 4: Have not yet completely worked out whether publication data - from step 3 becomes part of self.xml object. Perhaps. - - -long comment from do_configure_publication_client(), so long that it -was obscuring the code: - - # Critical thing at this point is to figure out what client's - # sia_base value should be. Three cases: - # - # - client has no particular relationship to any other client: - # sia_base is top-level, or as close as we can make it taking - # rsyncd module into account (maybe homed under us, hmm, how do - # we detect case where we are talking to ourself?) - # - # - client is a direct child of ours to whom we (in our parent - # role) made an offer of publication service. client homes - # under us, presumably. - # - # - client is a child of a client of ours who referred the new - # client to us, along with a signed referral. signed referral - # includes sia_base of referring client, new client homes under - # that per referring client's wishes. - # - # ... which implies that there's a fourth case, where we are both - # the client and the server. - - # Checking of signed referrals goes somewhere around here. Must - # be after reading client's XML, but before deciding what the - # client's sia_base and handle will be. - - # Ok, so we end up with four cases in terms of our checking: - # - # - Signed referral provided. Must be signed by existing client - # (somebody already listed in entitydb/pubclients/, suggesting - # that it might be useful to include ski there as an XML field? - # or maybe just outer unsigned XML wrapper that expresses the - # referral include handle of referrer so we can look up - # directly? yeah, that). sia_base offered (within inner signed - # referral XML) must be underneath signing client's space (so - # we'd have to look up the signing client entitydb data for that - # anyway). - # - # Case trivially detectable by presence of signed referral. - # - # - Client is direct child of entity running pubd, so entity - # running pubd clearly has the right to offer service to its - # children. So just assign publication location to child after - # checking that this really is a child of ours (ie, must be in - # entitydb/children). - # - # Detectable by handle being listed in entitydb/children, - # not to mention @parent_handle == self.handle. - # - # - Client is self, ie, entity that runs pubd is its own client. - # Trivial to check (handle and BPKI match). This gets top-level - # (rsyncd module) name. - # - # Detectable by handle matching ours. - # - # - All other cases get top-level directories of their own, no - # nesting. I guess such can go under an APNIC-style customers - # rsyncd module, or something like that. - # - # Detectable by none of the other cases matching. - - # All of which would be OK except that I don't know how to map it - # into Randy's view of a single pubd running multiple rsyncd - # modules. Part of the problem there is that rsyncd.conf has to - # be updated whenever a new module is added, we can't do it - # automatically. - # - # Perhaps (just suggested on testbed list) our rsync URIs should look like: - # - # rsync://host[:port]/arbitrarymodule/client_handle - # - # where arbitrarymodule defaults to "rpki" and has no particular - # relationship to any client_handle. diff --git a/myrpki.rototill/arin-rootcert.py b/myrpki.rototill/testbed-rootcert.py index 41369056..54d1480c 100644 --- a/myrpki.rototill/arin-rootcert.py +++ b/myrpki.rototill/testbed-rootcert.py @@ -24,11 +24,7 @@ PERFORMANCE OF THIS SOFTWARE. import csv, myrpki, sys -holder = "arin" - -if len(sys.argv) == 2: - holder = sys.argv[1] -elif len(sys.argv) > 1: +if len(sys.argv) != 2: raise RuntimeError, "Usage: %s [holder]" % sys.argv[0] print '''\ @@ -52,8 +48,8 @@ sbgp-autonomousSysNum = critical,@rfc3779_asns sbgp-ipAddrBlock = critical,@rfc3997_addrs [rfc3779_asns] -''' % { "holder" : holder.lower(), - "HOLDER" : holder.upper() } +''' % { "holder" : sys.argv[1].lower(), + "HOLDER" : sys.argv[1].upper() } for i, asn in enumerate(asn for handle, asn in myrpki.csv_reader("asns.csv", columns = 2)): print "AS.%d = %s" % (i, asn) |