(In reply to Lubomir Rintel from comment #2)
> Contacted web about the endpoint URI: SN Incident INC0522976

https://redhat.service-now.com/help?id=rh_ticket&table=incident&sys_id=d7ca494e13f9be40daa77b304244b0c1


This was closed as unresolved, 2 years ago.


However, we do now have http://static.redhat.com/test/rhel-networkmanager.txt


Lubomir, do you know where is the discussion that lead to the creation of this URL?


Major problem:

 - static.redhat.com does not resolve IPv6 (which is a serious problem with 1.16 where we do connectivity check per-AF)

Minor problems:

 - possibly, the URL should also set "X-NetworkManager-Status: online\r\n" in the HTTP header. That is what http://connectivity-check.ubuntu.com/ does.

 - note that NM only does a prefix-match of connectivity.responese. http://static.redhat.com/test/rhel-networkmanager.txt returns "OK". But NM would also match "OKanything". I wonde, whether we should instead rely on the "X-NetworkManger-Status" header and instead return an empty response with 204 status code.

So...


there were concerns setting loosen rp-filter in RHEL (by default).
At that point, it doesn't matter which package is responsible to loosen the rp-filter, none of them is supposed to do it by default.

But strict rp-filter breaks connectivity checking (in common scenarios).

The solution now is to have a separate package NetworkManager-config-connectivity-redhat that configures connectivity checking for NetworkManager and loosens pr-filter. But this package would not be installed by default, instead it's available when the user wishes to do this.

Since it's not installed by default and only provides configuration knobs that are available anyway, this has lower priority and gets moved to rhel-8.2.

Dropping from RPL-8.1


TODO: ensure that Red Hats connectivity check URI is IPv6 capable and that the DNS name resolves for IPv4 and IPv6 addresses. See comment 7.

New request: https://redhat.service-now.com/help?id=rh_ticket&table=sc_request&sys_id=4a084281db05d810c4db45e81396198b#fresh=false

Hey Thomas,

My team is going to stand up a redhat.{com,io} resource to serve this need. I want to clarify the logging/tracking issue however. We will make this URI highly available and very fast. We will ensure it removes cookies and sends none. However, it is going to be impossible to log /nothing/ about the client because things like web app firewalls have some state in them to do rate limiting and prevent DDoS attacks. 

How sensitive are we here to logging? It would be very strange to have a web server log absolutely nothing while be open to the entire web for potential abuse.

(In reply to Chris Bredesen from comment #14)

Hi Chris, thank you very much for moving this forward!!

The connectivity check URL would (maybe) be used by a wide range of RHEL systems which opt in to the connectivity check.
Connectivity check makes mostly sense for captive portals, that is on machines like a workstation/notebook.
It's hence not a standard server use-case, but still: we do have users who run RHEL on their notebook (like RHEL CSB).

It means, those machines would periodically request this URL. The default poll interval here is 5 minutes,
but when connectivity changes, NetworkManager makes the first checks more frequently (to recover faster from
a momentary connectivity loss).

While NetworkManager's HTTP request sets no special cookies or identifying informations, it still
reveals the IP of the user, that the user was online at a certain time, and (possibly) which version of
RHEL/NetworkManager the user is using. It seems hence very important to be careful about what we log. Especially,
if we are going to enable this on a wider scale on behalf for our users (for certain setups, e.g. Workstation). 

For Fedora we do something similar, and use the URI http://fedoraproject.org/static/hotspot.txt .
I don't know who setup that machine, I only hope it does takes care to protect users' privacy.
If you are familiar/involved with Fedora infrastructure, I would be interested about how it's handled
for that URL.

I am sure you know better than me, but suffice to say, that it is *very* important to behave in a trustworthy
manner about our user's privacy.


I would not think that this URL is an interesting target for abuse. What could an attacker possibly
gain by DOS the server??

Hi Chris. Do you have further thoughts about this? Thank you.

Thomas - I've got a thread going on the internal JIRA; you're tagged on it. Replaying my response here for visibility:'

Thomas Haller the more I think of this the more i want to simply host an untracked, un-chromed file in the Customer Portal. This is for RHEL systems meaning they already have other possible services hitting the a.r.c domain (RHSM is the obvious one) and this would be a pretty simple add. it won't have any analytics on it but it will have the basic apache-style access logs along with it b/c everything we host at the edge has this. There is no PII or personal tracking – you can ensure that in the client, though sending a sensible user agent would be awfully courteous.

Thoughts?

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.