XFF original IP detection extension: Private IP ranges no longer trusted by default

[nareddyt]

Background

The XFF original IP detection extension states:

When the remote IP address matches a trusted CIDR and the x-forwarded-for header was sent, each entry in the x-forwarded-for header is evaluated from right to left and the first public non-trusted address is used as the original client address.

Source: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/http/original_ip_detection/xff/v3/xff.proto

Problem

The statement "the first public non-trusted address" is no longer true.

I believe Envoy v1.33 changed the default HCM implementation to skip private IP range parsing by default in XFF. The change is documented in the HCM-level internal_address_config field in HCM config.

However, this warning and documentation change is missing in the envoy.extensions.http.original_ip_detection.xff config in https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/http/original_ip_detection/xff/v3/xff.proto

It is now confusing. We expected Envoy to parse the first public (non-private) IP, but it parsed the private one.

Config

            "original_ip_detection_extensions": [
             {
              "name": "envoy.extensions.http.original_ip_detection.xff",
              "typed_config": {
               "@type": "type.googleapis.com/envoy.extensions.http.original_ip_detection.xff.v3.XffConfig",
               "xff_trusted_cidrs": {
                "cidrs": [
                 {
                  "address_prefix": "35.1.2.3",
                  "prefix_len": 32
                 },
                ]
               },
               "skip_xff_append": false
              }
             }
            ],

Verification

With envoy.extensions.http.original_ip_detection.xff enabled, the following request:

source ip = 35.1.2.3
XFF = 208.4.5.6,10.1.1.1

with XFF config

                 {
                  "address_prefix": "35.1.2.3",
                  "prefix_len": 32
                 },

Results in Envoy reporting the remote address as 10.1.1.1.
Based on the documentation, we expected a downstream remote address of 208.4.5.6.

Workaround

Adding private IP ranges to the XFF trusted_cidrs configs works, and it reports the address as 208.4.5.6

Ask

Let's update https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/http/original_ip_detection/xff/v3/xff.proto with the same notice about needing to manually trust private IP address ranges.

I am happy to help make a PR.

[agrawroh]

cc @wbpcode Could you please help take a look?

[wbpcode]

SGTM to fix with a bool flag or a private address cidr to skip the private addresses.

[nareddyt]

@wbpcode I think this is mostly a documentation fix instead of actual code change in the extension.

Do you have the context on why HCM IP detection does not automatically parse over private IPs anymore? Whatever reasoning they have there would also apply to this extension.

[wbpcode]

Do you have the context on why HCM IP detection does not automatically parse over private IPs anymore? Whatever reasoning they have there would also apply to this extension.

Not sure. Long time ago @alyssawilk did that if my memory is correct but I am not clear the context. I think initially we added the internal_address_config to make the internal address detection be configurable. And then we hope to make it more robust by disabled automatic private address based detection.

[wbpcode]

SGTM to fix with a bool flag or a private address cidr to skip the private addresses.

I think we can also address this by configure the private address cidr at the xff_trusted_cidrs?

[nareddyt]

I think we can also address this by configure the private address cidr at the xff_trusted_cidrs?

Correct. That is why I just want to make a doc update asking users to configure private cidrs into that field.