Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bitswap/httpnet: request with CDN-Loop (RFC 8586) #862

Open
lidel opened this issue Feb 28, 2025 · 2 comments
Open

bitswap/httpnet: request with CDN-Loop (RFC 8586) #862

lidel opened this issue Feb 28, 2025 · 2 comments
Labels
need/triage Needs initial labeling and prioritization topic/bitswap topic/gateway Issues related to HTTP Gateway

Comments

@lidel
Copy link
Member

lidel commented Feb 28, 2025

We need to find a solution to situation where defunct gateways start returning redirects back to ipfs.io and dweb.link, effectively acting as amplification vector.

There is some prior art solution in form of CDN-Loop header which helps in avoiding unintended HTTP loops like that:

This document defines the CDN-Loop request header field for HTTP.
CDN-Loop addresses an operational need that occurs when an HTTP
request is intentionally forwarded between Content Delivery Networks
(CDNs), but is then accidentally or maliciously re-routed back into
the original CDN causing a non-terminating loop. The new header
field can be used to identify the error and terminate the loop.

Ref.

I think in case of Rainbow, we could leverage SEED and have all nodes set CDN-Loop to the same deterministic hash value, and refuse to process requests with matching one. This way HTTP traffic looped/proxied back to our infra is ignored.

cc @hsanjuan for feedback, maybe there a better way?

@lidel lidel added need/triage Needs initial labeling and prioritization topic/bitswap topic/gateway Issues related to HTTP Gateway labels Feb 28, 2025
@hsanjuan
Copy link
Contributor

hsanjuan commented Mar 3, 2025

@lidel we could simply not support redirects... Our urls come from content provider records, which, iirc, have expirations and need to be renewed regularly. If an endpoint changes, the action to take is to update the provider record, rather than setting a redirect.

It's also not even about loops, its also about redirect hops (1 hop means opening a new connection somewhere else which is already expensive by itself in our context).

@lidel
Copy link
Member Author

lidel commented Mar 4, 2025

@hsanjuan good point. not following redirects sounds ok to me.

interpreting 3XX as 404 will force people to update announcements rather than keeping dead domains alive and then breaking months/years later.
take a look at proposed spec clarification in ipfs/specs#494

still, the utility of CDN-Loop goes beyond redirects. we've seen people setting up dumb Nginx-based proxies that blindly forwarded (not redirected) requests to ipfs.io with all original headers (cough rogue Rhea/Saturn nodes).

perhaps for now, disable following redirects, and keep this issue about CDN-Loop as low priority (P3) until we actually need it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
need/triage Needs initial labeling and prioritization topic/bitswap topic/gateway Issues related to HTTP Gateway
Projects
None yet
Development

No branches or pull requests

2 participants