Title: when network.rbac filter is used in combination with tcp_proxy, connection to the upstream is established in any case, even if RBAC decision is Deny

Description:

• apparently, network.rbac filter doesn't prevent tcp_proxy from establishing a connection to an upstream in case when RBAC decision is Deny
• I'm wondering, is it a good/intuitive default behaviour ?

Repro steps:

• configure Envoy listener with a combination of network.rbac and tcp_proxy filters

  static_resources:
    listeners:
    - name: listener_0
      address:
        socket_address:
          protocol: TCP
          address: 0.0.0.0
          port_value: 10000
      filter_chains:
      - filters:
        - name: envoy.filters.network.rbac
          typed_config:                   
            "@type": type.googleapis.com/envoy.config.filter.network.rbac.v2.RBAC
            rules: {}    # DENY everything
            stat_prefix: backend
        - name: envoy.tcp_proxy
          typedConfig:
            '@type': type.googleapis.com/envoy.config.filter.network.tcp_proxy.v2.TcpProxy
            statPrefix: backend
            cluster: backend

• use netcat as a simple backend implementation (most importantly, it responds before reading request stream):

  nc -lk -s 127.0.0.1 -p 8081 -e echo -e HTTP/1.1 200 OK\r\nContent-Length: 17\r\n\r\n{"version":"v1"}\n

• make a request to envoy

  curl localhost:10000
  

• apparently, despite the RBAC policy being deny everything, connection to the upstream is established anyway and a response from it is passed back to the downstream