search

open-mpic / aws-lambda-python

An implementation of the Open MPIC API using AWS-Lambda serverless fucntions written in Python as well as AWS API Gateway.
MIT License
6 stars 1 forks source link

Retry and cohort logic implementation #5

Open sciros opened 4 weeks ago

sciros commented 4 weeks ago

Refers to implementing the retry logic discussed here: https://github.com/open-mpic/open-mpic-specification/issues/3 and picks up where that discussion left off regarding what to do when the number of perspectives P can yield N disjoint "cohorts" of perspective-count C and N = 1 vs N >= 1.

I fully agree that cohort selection should be deterministic based on the validation target (currently identifier -- I'd like to rename that to domain-or-ip-target but we can save that for a separate discussion).

The thing I want to dive deeper into is the suggestion for a max-perspective-sets limit. Should we have an internal value that sets max-perspective-sets to a specific, small number, e.g. 2? (So that, for example, if the number of known perspectives P is 15, (|P| = 15) and perspective count C is 5, then there will only be 2 unique, disjoint perspective sets interrogated regardless of how many retries are attempted.)

My view on this depends on how perspectives in this AWS-region-oriented implementation are uniquely identified. If the current implementation allows for multiple perspectives to be deployed to the same region, then you are indeed in theory not limited at all in how many perspectives you create and therefore how many disjoint perspectives sets you can divide those into, and a max-perspective-sets internal limit is compelling.

If, on the other hand, "rir-name.aws-region-name" is going to uniquely identify a perspective, then you're effectively limited by how many regions AWS has. Which today is approximately 30, although that number is expected to grow over time to around 50. Today, with the eventual expectation that the minimum perspective count for MPIC will be 5 or 6 (let's conservatively say 5), that means a practical limit of 5 deterministically-constructed, disjoint perspective sets even if a CA tries to deploy to every AWS region they can (minus -gov regions). Then a max-perspective-sets internal limit is really only useful if we feel like 5 unique corroboration attempts is too much to allow in the reference implementation for CAs that are comfortable deploying across all of AWS. Which, practically speaking, doesn't seem all that necessary, but I can be convinced otherwise. I don't speak for any actual CA in this case, but my personal thinking is that |P|=20, C=6, N=3, and having 3 resulting cohorts (deterministic, disjoint) to cycle through for MPIC is kind of the "sweet spot" to try out but I also think that real-world usage down the road will provide some useful insight here. But since that means your proposal of a max-perspective-sets of 2 simply removes one set, I don't have that strong an opinion on this.

Should rir-name.aws-region-name uniquely identify a perspective? Whether it does or doesn't materially affects how the perspective selection logic is written, especially since we care not just about RIR diversity but also the 500km minimum distance between DNS resolvers requirement.

sciros commented 2 weeks ago

We should align on details here next, and also decide how we want to expose the parameter. It's probably part of orchestration_parameters and is an open-mpic specific, optional argument that would not be found in the IETF proposed API. It extends that API, in other words. (I don't know of a formal way to document that... maybe an x-extends field or something.)