Re: [quicwg/base-drafts] address-based access control (#2279)
Kazuho Oku <notifications@github.com> Mon, 31 December 2018 08:37 UTC
Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B68C71277D2 for <quic-issues@ietfa.amsl.com>; Mon, 31 Dec 2018 00:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtbbc0gICWfH for <quic-issues@ietfa.amsl.com>; Mon, 31 Dec 2018 00:37:21 -0800 (PST)
Received: from out-7.smtp.github.com (out-7.smtp.github.com [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D34AE126CB6 for <quic-issues@ietf.org>; Mon, 31 Dec 2018 00:37:20 -0800 (PST)
Date: Mon, 31 Dec 2018 00:37:19 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546245439; bh=+S6FRa84/zN3HbJgr0k99Uh/aU1/qHXFsC1+2baTvyI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Nb0WOpM9Omk8iM9t60bsmC9TegHChFgg9430ejXDGHj9WIrKr7Razoo9CqpNEO5rv hIQFNtTzEm0bwC3p62kDaCrfM1q1YrOQGA3BRaAoXOkX8ITb40lrvUktMIxpM5UozX gwvVyd+CbJ+HH/vt56MJr1AMyL0S3ssb+vxJHKy8=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab387667a8e8df1e8c6a8b07d2a2782d422a86f72492cf000000011841973f92a169ce178a34b7@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/450620468@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_5c29d53fc623b_58b13feba0cd45bc100021f"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/eZiH891weEo8ImBL73DW1-oD_UM>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Dec 2018 08:37:23 -0000
@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 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". 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
- [quicwg/base-drafts] address-based access control… Kazuho Oku
- Re: [quicwg/base-drafts] address-based access con… Martin Thomson
- Re: [quicwg/base-drafts] address-based access con… Kazuho Oku
- Re: [quicwg/base-drafts] address-based access con… janaiyengar
- Re: [quicwg/base-drafts] address-based access con… ianswett
- Re: [quicwg/base-drafts] address-based access con… Kazuho Oku
- Re: [quicwg/base-drafts] address-based access con… Mike Bishop