<big snip :) >
> The constraints are simple text files and parsed in a restricted > subprocess. Operators can trivially disable the imposition of > constraints by deleting /etc/rpki/*.constraints, if need be. Mmm.... I fully get your sentiment & concern and agree with it. The biggest problem simply lies in the "allow all" effectively, that should have been only the specific prefixes. Due to transfers etc that is likely hard to encode there. With this problem we are moving the problem from "trusting 5 RIRs" that are publicly accountable to "trust the code", at that point rpki-client could just produce the RPKI summary it would generate anyway, and at each update release it and people can consume (console.rpki-client.org <http://console.rpki-client.org/> etc can already in a way be used for that :). The question becomes: Who keeps the constraints files up-to-date... (next to how do we trust&verify this big original research/entry) At least, it becomes easily tracked who changed it and likely with a decent commit message, why and when. Is there a tool that can generate the list, could we run that tool distributed locally on a system? Or to alleviate the 'trust the code'. We could do something similar to Certificate Transparency: have multiple places (that you have to trust) generate and publish the constraint files, then one can say "I need 3 out of 5 to agree to a change" and if you poll them and they change take that update. And of course a big giant alert when something does not add up (which we can also do when the constraint constraints something issued by a RIR. ==> btw, did you verify that the constraints in the file constraint something today? Though, one could also say "I trust rpki-client coders" (they can circumvent it in code if they wanted to be evil) and call it a day ,then, your big diff is then quite fine ;) Greets, Jeroen
