I'm wondering what all is at scope here.
ie, what is a firewall engine? Is this WAF like functionality?

I assume that attaching firewall engines to a Gateway is leaving the default of said engine to the implementation?

I also assume that Enable simple IP allow/deny lists means that at minimum, any/all firewall engines will support some kind of IP allow/deny lists.

I'm wondering what all is at scope here. ie, what is a firewall engine? Is this WAF like functionality?

Yes. I added a definition of "Firewall Engine". The engine itself is not in scope, but providing the extension points to integrate it are.

I assume that attaching firewall engines to a Gateway is leaving the default of said engine to the implementation?

For now, I think its a yes. Alternatively, we could decide that we want to take a deeper and more actively role in defining the engines and their rules themselves, as opposed to just providing the extension points where they can be added. I'm open to suggestions about adding more scope in this way, but I would need to see pretty strong support from stakeholders that this is what they want.

I also assume that Enable simple IP allow/deny lists means that at minimum, any/all firewall engines will support some kind of IP allow/deny lists.

This was called out as a specific example due to feedback from interested folks, but no I don't think we can say definitively that any extension must support this. I've removed this as a goal, since it's covered and further implied by the user stories.

• As a gateway operator I want to be able to block traffic to gateways based on custom logic provided as portable scripts e.g. https://github.com/jcchavezs/coraza-exec-action-wasm

I actually would like to wait on this one as I have every expectation this one will be contentious if we were to add any specific allowances in our specification for it. I think it would be best as a separate, follow-up iteration so that it can get its own focus and discussion.

QQ: I'm not 100% familiar with the naming used, but does "payloads" in this context include everything from the corresponding layer? E.g. layer7/http would include headers and not only body, right?

Yes, correct.

I am concerned about the ability to actually fulfill the goals in this GEP. Just from reading the title, I was worried about running into the lowest-common-denominator problem: that there is almost no overlap between each firewall configuration surface, so we end up with an API that is not useful (or, we end up debating the API surface indefinitely).

Gateway API actually does already have a solution for this, with policy attachment. I suspect you may disagree, but when we are faced with a problem set that doesn't have much overlap, policy attachment of implementation specific policies is a much better experience for users than attempting to make an API that doesn't work.

After reading the GEP, my concerns are far greater, though. This set of goals is impossible to reasonable tackle. While the title if "Firewall", in typical products the feature set here actually spans 3-4 API surfaces: WAF, Authorization (typically separate from WAF!!), rate limiting, auditing, DLP. And I saw in the AI WG, LLM guardrails was also something of interest as part of this effort (which, again, differs from traditional WAF). I am very worried we are biting off way to much work with this effort and it will make it impossible to proceed.

Just as an anecdote, even just rate limiting is ridiculously complex to design an API around. I suspect it would be harder than BackendTLSPolicy was...

I am concerned about the ability to actually fulfill the goals in this GEP. Just from reading the title, I was worried about running into the lowest-common-denominator problem: that there is almost no overlap between each firewall configuration surface, so we end up with an API that is not useful (or, we end up debating the API surface indefinitely).

I am anticipating that we wont actually try to add significant API surface for this, see this conversation for some context.

In any case, I'm open to the possibility that this GEP moves to Withdrawn if we can't find the right stakeholders, and common surface.

Gateway API actually does already have a solution for this, with policy attachment. I suspect you may disagree, but when we are faced with a problem set that doesn't have much overlap, policy attachment of implementation specific policies is a much better experience for users than attempting to make an API that doesn't work.

This is getting into the "How?" we do things, which we're not ready for yet.

After reading the GEP, my concerns are far greater, though. This set of goals is impossible to reasonable tackle. While the title if "Firewall", in typical products the feature set here actually spans 3-4 API surfaces: WAF, Authorization (typically separate from WAF!!), rate limiting, auditing, DLP. And I saw in the AI WG, LLM guardrails was also something of interest as part of this effort (which, again, differs from traditional WAF). I am very worried we are biting off way to much work with this effort and it will make it impossible to proceed.

I will make sure you are considered a stakeholder for reviews, and that your concerns are incorporated 👍

Just as an anecdote, even just rate limiting is ridiculously complex to design an API around. I suspect it would be harder than BackendTLSPolicy was...

Agreed.

This is getting into the "How?", which we will get stuck on if we discuss this now. The important thing for this iteration is to align on the motivation and goals at a high level. If we do that, and then we move to the implementation details and we simply can not produce something that's effective within a reasonable scope, and is supported by multiple stakeholders, it is OK to consider this Withdrawn and keep it for posterity so that the community knows we looked into it, and what our reasons were for not continuing.

I am anticipating that we wont actually try to add significant API surface for this

In this case, I'm also wondering how this provides value that is not already available through HTTPRoute extensionRef custom filters or policy attachment, or what is missing from the current extension points to support this use case?

Something like first-class support for OWASP CRS configuration rules to provide WAF functionality in Gateway API might feel contentious and a scope stretch, but would at least feel more aligned with standardizing functionality within the Gateway API specification.

This does feel like it could be a valuable proprietary feature or product positioning for a Gateway API implementation, but I don't really see a purpose-built extension point enabling this as appropriate for the spec, when existing generic extension points may be sufficient (and potentially support the same or related use cases, such as using WASM modules to mutate or drop requests or responses as @jcchavezs mentioned in #4148 (comment)).

In this case, I'm also wondering how this provides value that is not already available through HTTPRoute
extensionRef custom filters

Filters could be viable, we need to decide. This is an important part of the exercise of this GEP. There could be challenges. One challenge is the should language around the order of processing filters, which is not conducive to security systems.

or policy attachment

Policy Attachment could be viable, we need to decide. This too is an important part of the exercise. There will be challenges, as it comes with many caveats. Ordering policies is one thing that can be challenging to get right, among others.

We are into implementation details however.

I want to be extra clear that if we get to the "How?" and there is no consensus, I am not shy about slapping a Withdrawn on it and providing a written explanation as to why. That way people who are looking at least know that we've tried, what we've tried, and what the difficulties are.

If possible however, the bare minimum I would like for this effort to result in a memorandum that provides some guidance to implementations that want to integrate firewalls with their Gateways, as I see this as a pretty common desire from users.