Date: Sun, 30 Dec 2018 22:32:48 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+0166e4ab6cab891472e01cb399798c8da74d8fa790c6b6f892cf0000000118417a1092a169ce178a34b7@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2279/450612881@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2279@github.com>
References: <quicwg/base-drafts/issues/2279@github.com>
Subject: Re: [quicwg/base-drafts] address-based access control (#2279)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5c29b8102901c_4e333fbef2ed45b81048155";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/j1ghYZji91nov4-P57GLlepLNOw>


----==_mimepart_5c29b8102901c_4e333fbef2ed45b81048155
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

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
----==_mimepart_5c29b8102901c_4e333fbef2ed45b81048155
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p>Marking editorial because I don't see a concrete change as a result of=
 this, more likely just advice, but this could flip.</p>
<p>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 addre=
ss is bad and you should feel bad, so here's a 4xx/5xx".</p>
<p>If we are talking about reputation for DoS mitigation, and a connectio=
n on a "good" address moves to a "bad" address, I would probably recommen=
d against a change in treatment in all but extreme cases.</p>
<p>If you are using IP address as a proxy for physical location - which i=
s 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 you=
r local policy.  Some policies could say "don't accept the packets", whic=
h 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.</p>
<p>The question is whether we might want to help the client avoid acciden=
tal address changes with an explicit signal.  I'm going to suggest that t=
he answer is "no".</p>

<p style=3D"font-size:small;-webkit-text-size-adjust:none;color:#666;">&m=
dash;<br />You are receiving this because you are subscribed to this thre=
ad.<br />Reply to this email directly, <a href=3D"https://github.com/quic=
wg/base-drafts/issues/2279#issuecomment-450612881">view it on GitHub</a>,=
 or <a href=3D"https://github.com/notifications/unsubscribe-auth/AWbkqyeK=
qrYAfS7JAVDck8In3Z2jJjErks5u-a-QgaJpZM4ZlOJ-">mute the thread</a>.<img sr=
c=3D"https://github.com/notifications/beacon/AWbkqzqx7drp-0wyrkDGtHPx0-_D=
GLtuks5u-a-QgaJpZM4ZlOJ-.gif" height=3D"1" width=3D"1" alt=3D"" /></p>
<script type=3D"application/json" data-scope=3D"inboxmarkup">{"api_versio=
n":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name"=
:"GitHub"},"entity":{"external_key":"github/quicwg/base-drafts","title":"=
quicwg/base-drafts","subtitle":"GitHub repository","main_image_url":"http=
s://github.githubassets.com/images/email/message_cards/header.png","avata=
r_image_url":"https://github.githubassets.com/images/email/message_cards/=
avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/q=
uicwg/base-drafts"}},"updates":{"snippets":[{"icon":"PERSON","message":"@=
martinthomson in #2279: Marking editorial because I don't see a concrete =
change as a result of this, more likely just advice, but this could flip.=
\r\n\r\nOne of the greatest pieces of baggage in HTTP is source-address-b=
ased ACLs.  I understand their value in DoS mitigation, but this issue im=
plies something greater than that.  I hope that you don't mean as a subst=
itute 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\".\r\n\r\nIf=
 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.\r\n\r\nIf you ar=
e 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 strate=
gies for high-value resources under conditions you control.  If your clie=
nt moved outside that area, then you will need to consult your local poli=
cy.  Some policies could say \"don't accept the packets\", which is the m=
ost robust response, but it makes the HTTP status code somewhat irrelevan=
t.  Clients in those contexts will want to be locked to the one network i=
nterface somehow.\r\n\r\nThe question is whether we might want to help th=
e client avoid accidental address changes with an explicit signal.  I'm g=
oing to suggest that the answer is \"no\"."}],"action":{"name":"View Issu=
e","url":"https://github.com/quicwg/base-drafts/issues/2279#issuecomment-=
450612881"}}}</script>
<script type=3D"application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/2279#issuecomment=
-450612881",
"url": "https://github.com/quicwg/base-drafts/issues/2279#issuecomment-45=
0612881",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>=

----==_mimepart_5c29b8102901c_4e333fbef2ed45b81048155--