Add X-Real-IP header when querying the backend

[Yoda-BZH]

Hello,

Would it be possible to have the header X-Real-IP when sozu requests the backend ?

Relying on X-Forwarded-For is unsecure as it may be forged by the client.

A typical request would look like :

GET / HTTP/1.1
X-Real-IP: xxxx:xxxxx:xx:x::xxxx:xxxx
X-Forwarded-Proto: https
accept: */*
user-agent: Python/3.10 aiohttp/3.9.3
X-Forwarded-For: xxxx:xxx:xxxx:x::xxxx:xxxx, 127.0.0.1
Host: example.com
Accept-Encoding: gzip

Typical nginx configuration to declare X-Real-IP:

proxy_set_header X-Real-IP $remote_addr;

If the header already exists in the request, the field should be overwritten.

[Keksoj]

This is a good idea! It would help debugging traffic, by being more succint than the X-Forwarded-For header.

The X-Real-Ip is not part of any RFC, however, and seems to be used mainly by Nginx, and Apache too.
We can fear that backends served by Sōzu will look into this X-Real-Ip header and behave in unpredictible ways. They may, for instance, compare its value with the list of IPs in the X-Forwarder-For header (not itself part of the HTTP RFC) and decide to deny the traffic for whatever reason.

We could use a X-Real-Ip-like header, but with a different name, unique to Sōzu (in the spirit of Sozu-Id). How about X-Sozu-Remote-Addr ?

The behaviour would be:

• if the X-Sozu-Remote-Addr header is not present in the request, write it
• if the X-Sozu-Remote-Addr is already present, overwrite it

(commented after a discussion with @FlorentinDUBOIS and @Yoda-BZH)

[Yoda-BZH]

sounds good :)

[marc-barry]

I think defining your own header is the correct decision. There is lots of confusion over X-Real-IP and the usage of X-Forwarder-For. As a proxy operator I use X-Forwarder-For when I have a multi-level trusted reverse proxy setup to identify the levels of proxy's involved and on the edge proxies (i.e. the ones facing the client) I do drop the X-Forwarder-For so that the origination of this header cannot be a client (i.e. spoofed) or some other untrusted proxy in the path. Knowledge about the proxies in the path is very helpful, from an operational perspective.

Note that the Forwarded header is considered more "standard" and I have sought to use it due to the data it is able to convey.

Note that providers like Cloudflare do much the same what you have proposed here in that they have their own header called CF-Connecting-IP. Fastly calls theirs Fastly-Client-IP.