FR: nested network filter chains

[kyessenov]

Currently, listener inspectors and transport sockets are forced to reside at one-level: first inspect, then match, then use a transport socket. This is quite inflexible, and leads to situations where a whole expensive listener is needed (e.g. #4076). The proposal is to add a oneof that allows (inspectors + filter chains) to reside within the filter chains next to filters. The semantics is that processing is staged where once a filter chain is selected, transport socket is applied, and then inspector + filter chain matching restart.

This solves a bunch of issues:

1. Proxy protocol can be placed within TLS on server-side.
2. TLS-within-TLS can be matched provided outer TLS is prior knowledge.
3. HTTP-within-TLS can be sniffed provided outer TLS is prior knowledge.

[mattklein123]

@kyessenov I'm having trouble quickly understanding the API shape of the proposal. Can you do a quick API mock up to share and discuss? Thank you.

[kyessenov]

@mattklein123 Opened PR #18079 with a minimal change.

[mattklein123]

Thanks, that makes sense to me at a high level.

[soulxu]

@kyessenov let me know if you need any volunteer :)

[lizan]

Yeah at high level that makes sense to me. It also reminds whether we want FCDS / filter chain references to avoid duplicated filter chain configs.

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.

[kyessenov]

I can pick it up after the peek change gets in. There's some useful refactor in there.

[kyessenov]

This is probably still a useful feature, but we can do something better with matcher API and aligned transport / regular sockets.

[kyessenov]

Some additional thoughts that we had in this area:

• delaying inspectors until middle of the decision tree in the unified matchers: helps with reducing duplication with per-listener filter conditions
• this feels a lot like internal redirect in HTTP; perhaps, a better way to frame it is as a re-evaluation of the matcher tree.

[mattklein123]

Reopening and marking design proposal needed. I think this would benefit from a short design doc.