Support log-specific bastions in litewitness

[niels-moller]

Hi,

I'd like to implement support for using one bastion per log in lite witness. And I need a bit of advice before I start.

How should it be configured?

It will be unwieldy to do on the command line, so bastion config should probably go in the sqlite database. Should that be a separate table (say, origin (primary key) and bastion host), or an additional field in the log table?

How to limit bastion traffic to relevant log?

When connecting to a log-specific bastion, I think that connection should exclusively accept add-checkpoint requests from that log. And if there's a one or more catch-all bastions configured as well, those should only accept add-checkpoint requests from logs that don't have their own bastion.

So for each bastion connection, there should be a filter on acceptable origin lines. How to organize that? Either we would need to read the request close to the bastion connection, and decide whether to forward it to the witness or not. Alternatively, attach expected origin line(s) as metadata on the request context before it is passed to Witness.ServeHTTP ? Maybe there are other options as well?

Rate limit?

It would be nice to have some way configure rate limit for each bastion, and disconnect from the bastion (to reconnect sometime later) in case we get flooded with traffic.

[FiloSottile]

It will be unwieldy to do on the command line, so bastion config should probably go in the sqlite database. Should that be a separate table (say, origin (primary key) and bastion host), or an additional field in the log table?

Yeah, it's definitely switching to being a per-log property. It's probably easiest to make a new bastion table, like the key table. (Also has the advantage of making the transition ~free: it's a CREATE TABLE IF NOT EXISTS query we can run on every startup.)

Then we can have a witnessctl add-bastion -db <path> -origin <origin> -addr <address> command (and del-bastion).

When connecting to a log-specific bastion, I think that connection should exclusively accept add-checkpoint requests from that log.

Agreed.

And if there's a one or more catch-all bastions configured as well, those should only accept add-checkpoint requests from logs that don't have their own bastion.

I would actually deprecate and remove the global -bastion flag. I like the model of per-log bastions better, and it's all already a bit complex to think about, I don't want to confuse users with two different models for the same goal.

Alternatively, attach expected origin line(s) as metadata on the request context before it is passed to Witness.ServeHTTP ?

I like this option. Just attach the bastion address to the request context before passing it to Witness.ServeHTTP, and then when the origin becomes available it can be used to look up the allowed bastions.

This also makes it easier to open one connection per bastion, instead of one per log, if multiple logs share the same bastion.

It would be nice to have some way configure rate limit for each bastion, and disconnect from the bastion (to reconnect sometime later) in case we get flooded with traffic.

Let's start with a simpler implementation, we can figure out what's needed here better in the future.

[niels-moller]

See #35 for a first iteration.

[niels-moller]

Fixed with #35 (rate limits etc for later). Closing.