Maxmind support for Coraza v3 and WASM project

[tojewel]

Hi @jptosso,

I am looking to support Maxmind in the Coraza WASM project. I saw there is a Plugin for v2 but since the WASM is using the Coraza v3, that's not usable.

I saw you added the code for Maxmind in Coraza v3 but later on removed it.

I am wondering what's the plan for this feature to eventually make it available in the WASM project. I wanted to be aligned with your thought before making any changes by myself.

Many thanks for the nice work!

Jewe K

[jptosso]

Hey! We appreciate your interest.

We are not vendor-locking the solution for maxmind or liteip so that it might stay as plugins.

We have to update the plugin, but as we haven't released the stable plugin API it hasn't happened. Also there is no plugin api for directives yet.

I'm going to add this discussion to next week's monthly meeting, feel free to join! #582

[tojewel]

Cool! Before everything is sorted out with the Plugin API if I want to use this feature quickly in the WASM, do you think your PR is the right starting point b834204

[jptosso]

It will require a few modifications into the new directives and operators apis but it should totally work

[tojewel]

Thanks!

[jcchavezs]

My 2p: This is a very interesting feature and more so if the plan is to implement in proxy-wasm. A few reasons here:

1. proxy wasm filters can't access filesystem, hence we probably need to embed the db in the WASM itself (I think it is around 200MB according to https://stackoverflow.com/a/37493561) and I am curious about the size of the resulting image.
2. If we embed the db into filesystem we still need to load the DB in memory, meaning that in istio case we will have many instances of sidecars loading 200MB in memory.
3. Not sure what is the limit of WASM memory for envoy but consider every wasm extension will load the db in memory. Will this affect the bootstrap? Will this affect the processing memory available?

One idea would be to deploy a maxmind server and wasm extensions to connect to it and resolve IPs, it would introduce latency but we could use the timeout as described in https://github.com/tetratelabs/proxy-wasm-go-sdk/blob/main/proxywasm/hostcall.go#L107 and do a best effort to resolve it. Going beyond we could implement a very simple cache to solve repetitive calls an maintain the eviction through the OnTick API (see https://github.com/tetratelabs/proxy-wasm-go-sdk/blob/main/examples/dispatch_call_on_tick/main.go#L79)

In sum, I think this is interesting but maybe we want to discuss first these details before rushing the plugin API cc @anuraaga @M4tteoP