Subject: [quicwg/base-drafts] address-based access control (#2279)

From: Kazuho Oku <[email-masked]>
Date: Sun, 30 Dec 2018 21:57:50 -0800

In HTTP, we often deploy access control based on client's IP address. What's new in H3 is that the client's IP address might change mid-connection.

The questions are:
* How does the server apply address-based ACL? Should it grant (or reject) access based on client's initial address? Or should it use the source address of the packet that contained the HTTP request?
* If we are to validate access credentials using the initial address, should we suggest H3 client seeing a 4xx response (e.g. 401, 403, 404) to reconnect and retry the request using the current IP address?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2279

---

From: Martin Thomson <[email-masked]>
Date: Sun, 30 Dec 2018 22:32:48 -0800

Marking editorial because I don't see a concrete change as a result of this, more likely just advice, but this could flip.

One of the greatest pieces of baggage in HTTP is source-address-based ACLs.  I understand their value in DoS mitigation, but this issue implies something greater than that.  I hope that you don't mean as a substitute for authentication, but more part of a more comprehensive "your IP address is bad and you should feel bad, so here's a 4xx/5xx".

If we are talking about reputation for DoS mitigation, and a connection on a "good" address moves to a "bad" address, I would probably recommend against a change in treatment in all but extreme cases.

If you are using IP address as a proxy for physical location - which is a bad idea in general, but might be justifiable in terms of defense-in-depth strategies for high-value resources under conditions you control.  If your client moved outside that area, then you will need to consult your local policy.  Some policies could say "don't accept the packets", which is the most robust response, but it makes the HTTP status code somewhat irrelevant.  Clients in those contexts will want to be locked to the one network interface somehow.

The question is whether we might want to help the client avoid accidental address changes with an explicit signal.  I'm going to suggest that the answer is "no".

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2279#issuecomment-450612881

---

From: Kazuho Oku <[email-masked]>
Date: Mon, 31 Dec 2018 00:37:19 -0800

@martinthomson Thank you for elaborating.

> One of the greatest pieces of baggage in HTTP is source-address-based ACLs. I understand their value in DoS mitigation, but this issue implies something greater than that. I hope that you don't mea…

Yes. I think I should have mentioned that the issue relates to logging and the Forward header field ([RFC 7239](https://tools.ietf.org/html/rfc7239)) as well. They also tie addresses to a request.

> The question is whether we might want to help the client avoid accidental address changes with an explicit signal. I'm going to suggest that the answer is "no".

That works for me.

Though I also think that we should encourage server implementations to tie "current client address" (instead of the initial address) for logging, Forward header field, address-based ACL, because that would be the least inconsistent behavior from what the user would expect.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/2279#issuecomment-450620468