From nobody Tue Aug 1 21:38:42 2017 Return-Path: X-Original-To: captive-portals@ietf.org Delivered-To: captive-portals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE03131771 for ; Tue, 1 Aug 2017 21:38:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150164872051.12130.17459157542546503686.idtracker@ietfa.amsl.com> Date: Tue, 01 Aug 2017 21:38:40 -0700 From: IETF Secretariat Archived-At: Subject: [Captive-portals] Milestones changed for capport WG X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 04:38:40 -0000 Deleted milestone "Captive Portal Industry Survey". Deleted milestone "Captive Portal Taxonomy". Changed milestone "Protocol to discover and interact with a Captive Portal", set due date to August 2018 from December 2016. URL: https://datatracker.ietf.org/wg/capport/about/ From nobody Tue Aug 1 21:49:10 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7376131C2D; Tue, 1 Aug 2017 21:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 0Y37_B5dis6T; Tue, 1 Aug 2017 21:49:07 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D4E131A7C; Tue, 1 Aug 2017 21:49:07 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id c74so15919418iod.4; Tue, 01 Aug 2017 21:49:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EqWh2vXV81Bhn27tYPvakWdDILzFYBp5rVUpZ5ZJrzE=; b=ofUNQYxcLErCtfqx/4F/7XR/5X+3KWAkA7fKVLSaf464UCLufefbxItMTH7Gl4pDK+ fyEhKXFyhTVMhi76o899i248TK2h1ReLWcrnxmcIAPadAoLMr+MdwzrhYSXoQXu4kXe8 pcf26zXYfljEFHy0VJE6VHepc4fgJ+Sio7t3VLoc4yebcHn7MzvrufnYQpuLeP+y7q/J 5ZV9kA3Xl54v7bN63r3pAbTCFplYZOveT+nraaVbJR3PR7MPqUXb3R5liyEMctGKNRCq VRP0ZOOCfoUbg5FPf+jkgr8G8UsqyQ9UyWhYoxF6h4/ADNHONR5+G6vTqfVhhzIeGxIT Gixw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EqWh2vXV81Bhn27tYPvakWdDILzFYBp5rVUpZ5ZJrzE=; b=QTPU34vKKQyMIIAlp49mVDnpWN+CrOmacm7VLYQlGlCjFSjXWvox/QV0yq8l+YlaDf ou8jxVyC6uyADvZxbRI1zrUTUYCM2uielfWLjVejua8sY5NcTF4LeXPGeCPAW7jFUKGW tYXyPv3MvEdRQ80xb1pZWnFS9+GWrMbkJqo4Jcy6AiruxReQ5aHPlL2VWBLX9i47v4zZ C3OYFCuPsc3Nc0NRiflH7Ut7z5CoWP5tHy7yzUsPIBqwSeoacMit2XCDV1i0yl79zNmN fS8gvmrrqnfCSBAvN52JmL7UUg2NNYaBSNA/bApdUOhdSTdch4ISENtfWCyiXnOny5xA VigA== X-Gm-Message-State: AIVw112Ovpn9TcZcKis2KLfYNNuu7e5zEJQPD0z2v5FNB64i7/6xshEy DPB9BRraa3BjJ14zyq0gFmknzR1T3MxB X-Received: by 10.107.134.196 with SMTP id q65mr24448086ioi.193.1501649346444; Tue, 01 Aug 2017 21:49:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.164.42 with HTTP; Tue, 1 Aug 2017 21:49:05 -0700 (PDT) In-Reply-To: <150164872051.12130.17459157542546503686.idtracker@ietfa.amsl.com> References: <150164872051.12130.17459157542546503686.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 2 Aug 2017 14:49:05 +1000 Message-ID: To: IETF Secretariat Cc: captive-portals@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Captive-portals] Milestones changed for capport WG X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 04:49:08 -0000 As discussed, Erik and I have proposed new milestones. These aren't yet approved, but I've spoken to Adam about this. Also, the tool seems to have made a hash of the notification. The new milestones will be: Aug 2018 - Capture Portal Architecture Aug 2018 - API for Captive Portal Interaction As you can see, we've removed the discovery piece from the API. As mentioned if we conclude that we're doing something with the ICMP work - something that is still uncertain - we will revise milestones at that point. Expect confirmation of the adoption questions we asked at the meeting shortly. On 2 August 2017 at 14:38, IETF Secretariat wrote: > Deleted milestone "Captive Portal Industry Survey". > > Deleted milestone "Captive Portal Taxonomy". > > Changed milestone "Protocol to discover and interact with a Captive Portal", > set due date to August 2018 from December 2016. > > URL: https://datatracker.ietf.org/wg/capport/about/ > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals From nobody Tue Aug 1 21:56:43 2017 Return-Path: X-Original-To: captive-portals@ietf.org Delivered-To: captive-portals@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC89131C2B for ; Tue, 1 Aug 2017 21:56:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.58.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150164980176.12209.2893279097733617350.idtracker@ietfa.amsl.com> Date: Tue, 01 Aug 2017 21:56:41 -0700 From: IETF Secretariat Archived-At: Subject: [Captive-portals] Milestones changed for capport WG X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 04:56:42 -0000 Changed milestone "API for Captive Portal Interaction", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/capport/about/ From nobody Wed Aug 2 06:21:03 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE971320B8 for ; Wed, 2 Aug 2017 06:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netcologne.de 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 8PyRaZVWgFN6 for ; Wed, 2 Aug 2017 06:21:01 -0700 (PDT) Received: from cc-smtpout3.netcologne.de (cc-smtpout3.netcologne.de [89.1.8.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 335C3126BF3 for ; Wed, 2 Aug 2017 06:20:59 -0700 (PDT) Received: from cc-smtpin2.netcologne.de (cc-smtpin2.netcologne.de [89.1.8.202]) by cc-smtpout3.netcologne.de (Postfix) with ESMTP id D4CBB127A9; Wed, 2 Aug 2017 15:20:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1501680057; bh=ReOoZOfOkqOl4u+jevJr474J1oMo/oLEcgM0qPHzrTo=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To:From; b=LFFa2hznHP07eCADAJwtUblo95qwb9p9UyMLkATV6GR7dg4f236cldSKlvaDv04Qt 04uk/haJ0NzrTTrgJ4k0g14ywIOCsvk9LgOQ/me5/bA8gf+QaZB/UgJCKxHqmmeH9p +zXcfzECtiYoNh1miGgRjB550Sk0fdNamXivB0ig/nYsyZerL6yy5qz3bRudjxwF83 iNV68UKRXVa9Mf4xJQEyknZmofG72oPvhjoUN3/cL3N8aTvSNWZP/GXjJpWLfHzv54 VX6k1ZN2UKXlNQ2fcJIPVb/h38sYm658HrxWosjuWkmNDCe4GrEQjo/0LPju8K21H9 oJlPFpzO5e/Cg== Received: from localhost (localhost [127.0.0.1]) by cc-smtpin2.netcologne.de (Postfix) with ESMTP id CF6FC11DF5; Wed, 2 Aug 2017 15:20:57 +0200 (CEST) Received: from [2001:4dd0:0:193:222::] (helo=cc-smtpin2.netcologne.de) by localhost with ESMTP (eXpurgate 4.1.9) (envelope-from ) id 5981d1b9-02b8-7f0000012729-7f000001a8e1-1 for ; Wed, 02 Aug 2017 15:20:57 +0200 Received: from [IPv6:2001:4dd0:0:193:222::] (sys-222.netcologne.de [IPv6:2001:4dd0:0:193:222::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by cc-smtpin2.netcologne.de (Postfix) with ESMTPSA; Wed, 2 Aug 2017 15:20:56 +0200 (CEST) To: Erik Kline , captive-portals@ietf.org Cc: "martin.thomson@gmail.com" References: From: Gunther Nitzsche Message-ID: <3b2141fd-fd5a-dd88-cddb-b66ca5d8fc81@netcologne.de> Date: Wed, 2 Aug 2017 15:20:56 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Archived-At: Subject: Re: [Captive-portals] IETF 99 minutes X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 13:21:03 -0000 Hi and thanks for the meeting minutes. I have two (no..three :) small comments on that: There is an uncontradicted comment saying: David Dolson: need to notify non-http-80 Tommy Pauly: expect to interact with web pages Martin: considers status code 511 to be dead until new information. I am wondering why the complete discussion in the last weeks regarding 511 - status on this mailing list seems to be completely ignored? At least for me it is still the preferred way to go as I mention= ed earlier here. And: Martin: Some feedback I got was (a) there are far too many bits & messages (maybe dest= unreach is enough), you allow provider to provide discriminatory services= =2E David B: That's what walled garden does. We shouldn't go there. =2E.and I thought, we had the consensus that walled garden is a perfect topic for this ml? Further down: Tommy: today, we wait for capport probe to complete until allowing network access. That is not what we do. Download of antivirus -patterns or self- reenabling after abuse block is a valid reason to reach parts of the network even when the customer is blocked. Thanks Gunther On 31.07.2017 03:00, Erik Kline wrote: > FYI: I have uploaded the meeting minutes as captured in Etherpad. > Many thanks to David Dolson (and any others) for taking notes. > > You can find the minutes on the wg meetings page: > > https://datatracker.ietf.org/group/capport/meetings/ > https://datatracker.ietf.org/meeting/99/minutes/capport > > and in the wg-materials repo on github: > > https://github.com/capport-wg/wg-materials > > I have not edited this initial upload of the minutes in any way. > > Please review if/when you get a chance; we can post corrections/clarifi= cations. > NetCologne Systemadministration --=20 NetCologne Gesellschaft f=C3=BCr Telekommunikation mbH Am Coloneum 9 ; 50829 K=C3=B6ln Gesch=C3=A4ftsf=C3=BChrer: =20 Timo von Lepel, Mario Wilhelm =20 Vorsitzender des Aufsichtsrates: Dr. Andreas Cerbe HRB 25580, AG K=C3=B6ln From nobody Wed Aug 2 08:08:35 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD15C13211D for ; Wed, 2 Aug 2017 08:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 Yud6I7rBK8dv for ; Wed, 2 Aug 2017 08:08:31 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C65124207 for ; Wed, 2 Aug 2017 08:08:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1501686510; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=KbyfMt2WnobaCtllvHOSbqabC+d+20wCf0mEMbseGyc=; b=2oj0zy1SFtZPkn1SPtNzBamu+FdG+/RNPiTJs1ONjV2+yfwEDoW+o2T/jgJPzbM4 6gpwiRIkRCSxGigzalCWHtzqmy4M9MLvNipH8nQdqIXtyXbzUOB2updEAXEZHjhY z65sQdEG2wa17MqWdHeUi9YL4RPJuyQLmvuRmWKaDtSV4IQv7AF93MCNnyOF7QZ+ 6NgJA14k3dBtMTfQdAhygelFaH6TPlE/qv1iIaoX3Pui4tOVMjEkXbLTdqDSqs9C rRsfeO5Hi+Af9eGAhpJorJvu67Uew+4fKk7w5OYXz8C5qv6uvblQjx2Ei5yNi2zp iHcgBKg5X/fmn9c7S/WO0Q==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 51.21.06336.EEAE1895; Wed, 2 Aug 2017 08:08:30 -0700 (PDT) X-AuditID: 11973e12-0ffd89c0000018c0-cb-5981eaeedf9c Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay7.apple.com (Apple SCV relay) with SMTP id AD.7E.07283.EEAE1895; Wed, 2 Aug 2017 08:08:30 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_xfHt+dSB7wzKxrnX8fdM7g)" Received: from [17.234.78.76] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OU2003P0CQ6AV00@nwk-mmpp-sz13.apple.com>; Wed, 02 Aug 2017 08:08:30 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <457896D7-EAFB-4938-BB9C-45E18F8A21CA@apple.com> Date: Wed, 02 Aug 2017 08:08:29 -0700 In-reply-to: <3b2141fd-fd5a-dd88-cddb-b66ca5d8fc81@netcologne.de> Cc: Erik Kline , captive-portals@ietf.org, "martin.thomson@gmail.com" To: Gunther Nitzsche References: <3b2141fd-fd5a-dd88-cddb-b66ca5d8fc81@netcologne.de> X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUi2FCYqvvuVWOkwcodZhZzZzWwWny+PY/d YsbL86wW1878Y3Rg8dg56y67x4JNpR5Llvxk8lh47jFjAEsUl01Kak5mWWqRvl0CV8bU5rOM BWsuM1W0XjrI2sD4dxVTFyMnh4SAicSSpQ9Yuxi5OIQE1jBJnH36Dy6xel4TM0TiEKPEv+X9 7CAJXgFBiR+T77F0MXJwMAuESbxbVQlR84VRonnpDyaQuLCAhMTmPYkg5WwCKhLHv21gBgnz CthI/LwbDhIWFtCT2Ln/LViYRUBV4t5jDxCTU8BR4uABJ5AKZoFCiXnrV4AdIwJUPf/2Xagr OxklVjx9CbZIQkBWYumfEJC4hMA8dokbP44zTWAUmoXkzlkId0KY6hJTpuTOAtugLfHk3QVW CFtNYuHvRUzI4gsY2VYxCuUmZuboZuaZ6CUWFOSk6iXn525iBMXKdDuhHYynVlkdYhTgYFTi 4e240RgpxJpYVlyZe4hRmoNFSZzX2QYoJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVGy1e+A uN2GxH6VEzNMdYxFUjzMJl0o1T0fcv7LrT9Wv3fneCi8dlolbvrafXVENnvMpKQ3PYINPOKK D0/o1l7XdKztF+YIlT3KuLKyrHmxiNT1Lg29uddYfOQmhm9Z07pn5TwNi1eMvyRUv+8/f0T9 tnfuzlTXF9/0Mz9mSTflafrcvH/2kRJLcUaioRZzUXEiAA3wxgd2AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRmVeSWpSXmKPExsUi2FB8Q/fdq8ZIg1s7DS3mzmpgtfh8ex67 xYyX51ktrp35x+jA4rFz1l12jwWbSj2WLPnJ5LHw3GPGAJYoa5u0/KLyxKIUhaLkghJbpeKM xJT88nhLYyNTh8SCgpxUveT8XCV9O5uU1JzMstQiZFaCdcbU5rOMBWsuM1W0XjrI2sD4dxVT FyMnh4SAicTqeU3MXYxcHEIChxgl/i3vZwdJ8AoISvyYfI+li5GDg1kgTOLdqkqImi+MEs1L fzCBxIUFJCQ270kEKWcTUJE4/m0DM0iYV8BG4ufdcJCwsICexM79b8HCLAKqEvcee4CYnAKO EgcPOIFUMAsUSsxbvwLsGBGg6vm377JCLOpklFjx9CXYIgkBWYmlf0ImMPLPQnLaLITTIEx1 iSlTcmeBDdWWePLuAiuErSax8PciJmTxBYxsqxgFilJzEivN9eBht4kRHD2FqTsYG5dbHWIU 4GBU4uHtuNEYKcSaWFZcmQsMHg5mJRFe8+dAId6UxMqq1KL8+KLSnNTiQ4z7GYE+nMgsJZqc D4ztvJJ4Q2MLY0sTCwMDE0szE8LCJiYGJsbGZsbG5ibmtBRWEuf1EAC6XyA9sSQ1OzW1ILUI 5gUmDk6pBsbms9LZ4cLZz18nsi48dLOhciez0od+K5/oeVJ+4n8PL3bZ0NX42l7cuzuEVXPb l2qL6ttib+0yN6jZ2ecuWDTbddLhy0WX1u34eYxzXuM/afX4KTI8H6bprls5xy33dp1J98qd XA/vfUqdYT3p/TuWZRf0X/na3HN98uJNscAn8S/r1gfyR/MosQBTtqEWc1FxIgCa0D2CPwMA AA== Archived-At: Subject: Re: [Captive-portals] IETF 99 minutes X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:08:33 -0000 --Boundary_(ID_xfHt+dSB7wzKxrnX8fdM7g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Aug 2, 2017, at 6:20 AM, Gunther Nitzsche = wrote: >=20 > Hi >=20 > and thanks for the meeting minutes. >=20 > I have two (no..three :) small comments on that: > There is an uncontradicted comment saying: >=20 >=20 > David Dolson: need to > notify non-http-80 > Tommy Pauly: expect to interact with web pages > Martin: > considers status code 511 to be dead until new information. >=20 >=20 > I am wondering why the complete discussion in the last weeks > regarding 511 - status on this mailing list seems to be completely > ignored? At least for me it is still the preferred way to go as I = mentioned > earlier here. >=20 > And: >=20 > Martin: Some > feedback I got was (a) there are far too many bits & messages (maybe = dest > unreach is enough), you allow provider to provide discriminatory = services. > David > B: That's what walled garden does. We shouldn't go there. >=20 >=20 > ..and I thought, we had the consensus that walled garden > is a perfect topic for this ml? >=20 > Further down: >=20 > Tommy: today, we wait for capport > probe to complete until allowing network access. >=20 >=20 > That is not what we do. Download of antivirus -patterns or > self- reenabling after abuse block is a valid reason to > reach parts of the network even when the customer is blocked. Hi Gunther, I was referring to what the behavior on Apple operating systems is. When = a Wi-Fi network is joined, the captive portal probe is a generally a = precondition for allowing the Wi-Fi network to be marked as the default = route for the system. While traffic may still be allowed over that = network when scoped, general networking traffic is not allowed until the = probe completes. Thanks, Tommy >=20 >=20 > Thanks >=20 > Gunther >=20 > On 31.07.2017 03:00, Erik Kline wrote: >> FYI: I have uploaded the meeting minutes as captured in Etherpad. >> Many thanks to David Dolson (and any others) for taking notes. >>=20 >> You can find the minutes on the wg meetings page: >>=20 >> https://datatracker.ietf.org/group/capport/meetings/ >> https://datatracker.ietf.org/meeting/99/minutes/capport >>=20 >> and in the wg-materials repo on github: >>=20 >> https://github.com/capport-wg/wg-materials >>=20 >> I have not edited this initial upload of the minutes in any way. >>=20 >> Please review if/when you get a chance; we can post = corrections/clarifications. >>=20 >=20 >=20 >=20 > NetCologne Systemadministration > --=20 > NetCologne Gesellschaft f=C3=BCr Telekommunikation mbH > Am Coloneum 9 ; 50829 K=C3=B6ln > Gesch=C3=A4ftsf=C3=BChrer: =20 > Timo von Lepel, > Mario Wilhelm =20 > Vorsitzender des Aufsichtsrates: > Dr. Andreas Cerbe > HRB 25580, AG K=C3=B6ln >=20 >=20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals = --Boundary_(ID_xfHt+dSB7wzKxrnX8fdM7g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Aug 2, 2017, at 6:20 AM, Gunther Nitzsche <gnitzsche@netcologne.de> wrote:

Hi

and thanks for the meeting minutes.
I have two (no..three :) small comments on = that:
There is an uncontradicted comment = saying:


David Dolson: need to
notify non-http-80
Tommy Pauly: expect to interact = with web pages
Martin:
considers status code 511 to be = dead until new information.

I am wondering why the complete discussion in = the last weeks
regarding  511 - status on this = mailing list seems to be completely
ignored? At least for me it is = still the preferred way to go as I mentioned
earlier here.

And:

Martin: <hat off> Some
feedback I got was (a) there are far too many = bits & messages (maybe dest
unreach is enough), you allow = provider to provide discriminatory services.
David
B: That's what walled garden = does. We shouldn't go there.

..and I thought, we had the consensus that = walled garden
is a perfect topic for this ml?
Further down:

Tommy: today, we wait for capport
probe to complete until allowing network = access.


That is not what we do. Download of antivirus = -patterns or
self- reenabling after abuse block is a = valid reason to
reach parts of the network even when the = customer is blocked.

Hi = Gunther,

I was referring to what the = behavior on Apple operating systems is. When a Wi-Fi network is joined, = the captive portal probe is a generally a precondition for allowing the = Wi-Fi network to be marked as the default route for the system. While = traffic may still be allowed over that network when scoped, general = networking traffic is not allowed until the probe = completes.

Thanks,
Tommy

Thanks

Gunther

On 31.07.2017 03:00, Erik Kline wrote:
FYI: I have uploaded the = meeting minutes as captured in Etherpad.
Many thanks to = David Dolson (and any others) for taking notes.

You can find the minutes on the wg meetings page:

   https://datatracker.ietf.org/group/capport/meetings/
   https://datatracker.ietf.org/meeting/99/minutes/capport

and in the wg-materials repo on github:

   https://github.com/capport-wg/wg-materials

I have not edited this initial upload of the = minutes in any way.

Please review if/when = you get a chance; we can post corrections/clarifications.



NetCologne Systemadministration
-- 
NetCologne Gesellschaft f=C3=BCr = Telekommunikation mbH
Am Coloneum 9 ; 50829 = K=C3=B6ln
Gesch=C3=A4ftsf=C3=BChrer: =   
 Timo von Lepel,
 Mario Wilhelm  
Vorsitzender des Aufsichtsrates:
 Dr. Andreas Cerbe
 HRB 25580, AG K=C3=B6ln
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
=

= --Boundary_(ID_xfHt+dSB7wzKxrnX8fdM7g)-- From nobody Wed Aug 2 08:44:28 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD29C124B18 for ; Wed, 2 Aug 2017 08:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 ECA8U5vPmBwl for ; Wed, 2 Aug 2017 08:44:24 -0700 (PDT) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA5B13214C for ; Wed, 2 Aug 2017 08:44:22 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id h199so26649188ith.1 for ; Wed, 02 Aug 2017 08:44:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WiLNu0hAecA2W93l/77FuZKy/vQXUtitJ5nQGqiSG1s=; b=iNWWFyVnEYB5DaPkx51SN/M/tdMHAjU4AvSqEQZUayg0nrMHR6kK7u4EmCM3w36wA2 hvjTnBJimPzlBl+ggXXVw3CYDU2YYSbaL3EEIuniZUfCnCsJB2/o3H0c2YMUmf2rw+N2 y+CClnkLC628H5fHHkqPTGPl4Dww3SmWwrzI0348rjXtFbPbrhbzPNVkhLpsbeIa62G3 Yf7oxrMw+PPLDCi4GIIiNzyzuuWTAZZf2HcMLU2YrPC806y4Cnk/GiZL+4gRQolW1lWc JQPBJeAwt7tX6HFlCwOc//QUPc3TO268XEfEGLj6UU0fYXnmfefS7SlktbUVuYNxU8w5 sOag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WiLNu0hAecA2W93l/77FuZKy/vQXUtitJ5nQGqiSG1s=; b=RZyKffyPTnPJMzRktXSuTzZfZjiYdoktc0xvuX77btvx758PvoQFVEIR4A57y5JV/+ cFyNKIy84IoSc9hBFfkaPd//rkSDTvOfn5kznMmDlCuocAJ++z6us6/u4kQ0ZD04vC1F duJRUUe3Q8WFDt5rXw02/rWbsp8EoHH1gX+S2Xo/4mgdteJPTOWrhdcVJSOpOBzWqgFt Yl5vx4dSL81Jdfxvt3yvwG/a+KnVXrEocFO0lJK7YqfpFRbavVC9h2lewwcdFywzCPqZ L3CSnHWkdawjQdGT6II/5sl24gmCh+zDjSBwf3pnwR4PAnlqvWikRP6dfdbUNsmVSOK5 DJkQ== X-Gm-Message-State: AIVw112h5qZ+AqmU6HBnbvowGuEP34M+BWppzbPqX7XEOIe9yT5nV2HU gKyVWeWiuH2ViFgAQqcTeQy9qlVIFMu8 X-Received: by 10.36.228.202 with SMTP id o193mr6287545ith.130.1501688661468; Wed, 02 Aug 2017 08:44:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.140 with HTTP; Wed, 2 Aug 2017 08:44:20 -0700 (PDT) In-Reply-To: <3b2141fd-fd5a-dd88-cddb-b66ca5d8fc81@netcologne.de> References: <3b2141fd-fd5a-dd88-cddb-b66ca5d8fc81@netcologne.de> From: David Bird Date: Wed, 2 Aug 2017 08:44:20 -0700 Message-ID: To: Gunther Nitzsche Cc: Erik Kline , captive-portals@ietf.org, "martin.thomson@gmail.com" Content-Type: multipart/alternative; boundary="94eb2c123f003bacef0555c72377" Archived-At: Subject: Re: [Captive-portals] IETF 99 minutes X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 15:44:27 -0000 --94eb2c123f003bacef0555c72377 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't believe "We shouldn't go there." were my words... We are already there! Concerns about net neutrality and 'discriminatory services' is often used (by the chairs) to raise concerns about ICMP... however, a walled garden itself is 'discriminatory services' and should we review Dest-Unreach/Admin-Prohibited or TCP Reset (used today by some NASs when enforcing walled garden discriminatory services') ? Yet, I haven't once seen this same concern raised about API methods of delivering walled garden information. I agree 100% that this WG does the "work" NOT on the mailing list... rather, behind closed doors then votes in the in-person meeting... We need more implementors, deployers, and vendors (specifically the Guest/Public access business units) to be represented, not just on the mailing list, but in WG voting and even WG leadership. On Wed, Aug 2, 2017 at 6:20 AM, Gunther Nitzsche wrote: > Hi > > and thanks for the meeting minutes. > > I have two (no..three :) small comments on that: > There is an uncontradicted comment saying: > > > David Dolson: need to > notify non-http-80 > Tommy Pauly: expect to interact with web pages > Martin: > considers status code 511 to be dead until new information. > > > I am wondering why the complete discussion in the last weeks > regarding 511 - status on this mailing list seems to be completely > ignored? At least for me it is still the preferred way to go as I mention= ed > earlier here. > > And: > > Martin: Some > feedback I got was (a) there are far too many bits & messages (maybe dest > unreach is enough), you allow provider to provide discriminatory services= . > David > B: That's what walled garden does. We shouldn't go there. > > > ..and I thought, we had the consensus that walled garden > is a perfect topic for this ml? > > Further down: > > Tommy: today, we wait for capport > probe to complete until allowing network access. > > > That is not what we do. Download of antivirus -patterns or > self- reenabling after abuse block is a valid reason to > reach parts of the network even when the customer is blocked. > > > Thanks > > Gunther > > On 31.07.2017 03:00, Erik Kline wrote: > > FYI: I have uploaded the meeting minutes as captured in Etherpad. > > Many thanks to David Dolson (and any others) for taking notes. > > > > You can find the minutes on the wg meetings page: > > > > https://datatracker.ietf.org/group/capport/meetings/ > > https://datatracker.ietf.org/meeting/99/minutes/capport > > > > and in the wg-materials repo on github: > > > > https://github.com/capport-wg/wg-materials > > > > I have not edited this initial upload of the minutes in any way. > > > > Please review if/when you get a chance; we can post > corrections/clarifications. > > > > > > NetCologne Systemadministration > -- > NetCologne Gesellschaft f=C3=BCr Telekommunikation mbH > Am Coloneum 9 ; 50829 K=C3=B6ln > Gesch=C3=A4ftsf=C3=BChrer: > Timo von Lepel, > Mario Wilhelm > Vorsitzender des Aufsichtsrates: > Dr. Andreas Cerbe > HRB 25580, AG K=C3=B6ln > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > --94eb2c123f003bacef0555c72377 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't believe "We shouldn't go there." were my words... We are already there!

Concerns about net neutrality and 'discriminatory services' is often used (by th= e chairs) to raise concerns about ICMP... however, a walled garden itself i= s 'discriminatory services'= and should we review Dest-Unreach/Admin-Prohibited or TCP Reset (used toda= y by some NASs when enforcing walled garden discriminatory services') ?= =C2=A0

<= div>Yet, I haven't once seen this same= concern raised about API methods of delivering walled garden information. = =C2=A0

<= div>I agree 100% that this WG does the &qu= ot;work" NOT on the mailing list... rather, behind closed doors then v= otes in the in-person meeting...=C2=A0

We nee= d more implementors, deployers, and vendors (specifically the Guest/Public = access business units) to be represented, not just on the mailing list, but= in WG voting and even WG leadership.=C2=A0

= =C2=A0

On Wed, Aug 2, 2017 at 6:20 AM, Gunther Nitzsche = <gnitzsche@= netcologne.de> wrote:
Hi
and thanks for the meeting minutes.

I have two (no..three :) small comments on that:
There is an uncontradicted comment saying:


David Dolson: need to
notify non-http-80
Tommy Pauly: expect to interact with web pages
Martin:
considers status code 511 to be dead until new information.


I am wondering why the complete discussion in the last weeks
regarding=C2=A0 511 - status on this mailing list seems to be completely ignored? At least for me it is still the preferred way to go as I mentioned=
earlier here.

And:

Martin: <hat off> Some
feedback I got was (a) there are far too many bits & messages (maybe de= st
unreach is enough), you allow provider to provide discriminatory services.<= br> David
B: That's what walled garden does. We shouldn't go there.


..and I thought, we had the consensus that walled garden
is a perfect topic for this ml?

Further down:

Tommy: today, we wait for capport
probe to complete until allowing network access.


That is not what we do. Download of antivirus -patterns or
self- reenabling after abuse block is a valid reason to
reach parts of the network even when the customer is blocked.


Thanks

Gunther

On 31.07.2017 03= :00, Erik Kline wrote:
> FYI: I have uploaded the meeting minutes as captured in Etherpad.
> Many thanks to David Dolson (and any others) for taking notes.
>
> You can find the minutes on the wg meetings page:
>
>=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf= .org/group/capport/meetings/
>=C2=A0 =C2=A0 =C2=A0https://datatracker.i= etf.org/meeting/99/minutes/capport
>
> and in the wg-materials repo on github:
>
>=C2=A0 =C2=A0 =C2=A0https://github.com/capport-wg/wg-materials
>
> I have not edited this initial upload of the minutes in any way.
>
> Please review if/when you get a chance; we can post corrections/clarif= ications.
>



NetCologne Systemadministration
--
NetCologne Gesellschaft f=C3=BCr Telekommunikation mbH
Am Coloneum 9 ; 50829 K=C3=B6ln
Gesch=C3=A4ftsf=C3=BChrer:
=C2=A0 Timo von Lepel,
=C2=A0 Mario Wilhelm
Vorsitzender des Aufsichtsrates:
=C2=A0 Dr. Andreas Cerbe
=C2=A0 HRB 25580, AG K=C3=B6ln


_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/capt= ive-portals

--94eb2c123f003bacef0555c72377-- From nobody Wed Aug 2 10:36:11 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322E412EC4B for ; Wed, 2 Aug 2017 10:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 X4p9Fla3tWmg for ; Wed, 2 Aug 2017 10:36:08 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 544D0129B61 for ; Wed, 2 Aug 2017 10:36:08 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id 77so27360097itj.1 for ; Wed, 02 Aug 2017 10:36:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=tqlQMBMe60c2AkvwJ6vUu/rD2aTdcErzHb3A0kPksdU=; b=d44q3gWfNnpR/vNzHOXE5H0fdblECmUJdqbfWjEMDUEdZhUfzmO+Da8KTBM8n8Fjd/ FZjgJeTu78De27ailqVudK0szOwXDlu8ZCoPM7mMriAzG4ofDy1BnLDlqoG8woBV3ei8 WPYq6757GthfiyjcKDNf2GWV5V7EKBorE8qbTivvuy63xbLPq8jyN+5nfihebYLRDKtK n3z4AQ7zKEx9mjuztNhwGlzb46O8umqWUFLPamQi/PmlSqF2q8lC5ADcDR8bZ42KdWMR V/s9Wid2et6a8LBAAu9Ofys7vG1+5fFaVxk8Eg3JRxYfHpfMHdbYam1qryx0RAjwpF9m 56PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tqlQMBMe60c2AkvwJ6vUu/rD2aTdcErzHb3A0kPksdU=; b=iUqpGJqgs129IpwtC3uHdzrB0l1Waq8ENl6+pKXMmM+9MYBKyFdOJrDKsf3xF1mxKS QEcNoMNLPv8lcbYl2ku8m0aZ7cOldhbeS1ehs5YkfOEwEA8rEGJLPQ998a26p5o0gYdR CsVKiV2nl8zd1uSGGd8x2B1Oo/cvQIBhsq5tWsgzXQ4lOevWZMVx6seKjFr55Q353O3A p7+wIVnVN0LGvsdUtNH7kfKkaKhhUAZFrVCMjOmHX5qnJUrG/CBoUegRsSoLNMabOlz9 dkNtNk79rK8v4lhPRfO9L7EXcsLxKbxgLjLFoOvR8jzwa6yqNBVKO1BaxQBXKXbJSr5g Vw3A== X-Gm-Message-State: AIVw112WhxPytpzLnba6k98nDX8c+QoH4ywIWemlMzeLnbjsowegd9ro 5pTtxdxIU3z4ZH3CclWKTixkiE7hyAZUIBXavw== X-Received: by 10.36.175.65 with SMTP id l1mr6700713iti.2.1501695367141; Wed, 02 Aug 2017 10:36:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.6.140 with HTTP; Wed, 2 Aug 2017 10:36:06 -0700 (PDT) From: David Bird Date: Wed, 2 Aug 2017 10:36:06 -0700 Message-ID: To: captive-portals@ietf.org Content-Type: multipart/alternative; boundary="f403045da086ec0d6a0555c8b21f" Archived-At: Subject: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Aug 2017 17:36:10 -0000 --f403045da086ec0d6a0555c8b21f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Could an author of PvD help me understand the following questions for each of the diagrams below I found on the Internet -- which represent some typical hotspot configurations out there... - Where would the API reside? - Who 'owns' the API? - How does the API keep in-sync with the NAS? Who's responsible for that (possibly multi-vendor, multi-AAA) integration? 1) Typical Hotspot service company outsourcing: http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolution= _beta2b.png 2) Same as above, except venue owns portal: http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspots-co-worki= ng-cloudessa_2p1.png 3) Now consider the above, but the venue has more roaming partners and multi-realm RADIUS setup in their *Cisco* NAS: http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b= _cg83/b_cg83_chapter_0100111.html describes many options -- including separate MAC authentication sources, optional portals for 802.1x (RADIUS) authenticated users, and so much more... *"Cisco ISE supports internal and external identity sources. Both sources can be used as an authentication source for sponsor-user and guest-user authentication."* Also note this interesting article: the section Information *About Captive Bypassing* and how it describes how to avoid Apple captive portal detection!!! *"If no response is received, then the Internet access is assumed to be blocked by the captive portal and Apple=E2=80=99s Captive Net= work Assistant (CNA) auto-launches the pseudo-browser to request portal login in a controlled window. The CNA may break when redirecting to an ISE captive portal. The controller prevents this pseudo-browser from popping up."* --f403045da086ec0d6a0555c8b21f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Could an author of PvD help me understand the followi= ng questions for each of the diagrams below I found on the Internet -- whic= h represent some typical hotspot configurations out there...

=
- Where would the API reside?

- Who = 9;owns' the API?

- How does the API keep in-sy= nc with the NAS? Who's responsible for that (possibly multi-vendor, mul= ti-AAA) integration?


3) N= ow consider the above, but the venue has more roaming partners and multi-re= alm RADIUS setup in their Cisco NAS:=C2=A0http://www.cisco.com/c/en/us/td/docs/wireless/controlle= r/8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html describes many op= tions -- including separate MAC authentication sources, optional portals fo= r 802.1x (RADIUS) authenticated users, and so much more...=C2=A0
=
"Cisco ISE supports internal and exte= rnal identity sources. Both sources can be used as an authentication source= for sponsor-user and guest-user authentication."

Also note this interesting article: =C2=A0the section Infor= mation About Captive Bypassing and how it describes how to avoid App= le captive portal detection!!! "If no response is re= ceived, then the Internet access is assumed to be blocked by the captive po= rtal and Apple=E2=80=99s Captive Network Assistant (CNA) auto-launches the = pseudo-browser to request portal login in a controlled window. The CNA may = break when redirecting to an ISE captive portal. The controller prevents th= is pseudo-browser from popping up."


--f403045da086ec0d6a0555c8b21f-- From nobody Tue Aug 15 17:19:48 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3BD1323FD for ; Tue, 15 Aug 2017 17:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 PZtdNNAgqLi3 for ; Tue, 15 Aug 2017 17:19:42 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FB68132400 for ; Tue, 15 Aug 2017 17:19:34 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id p68so14007619ywg.0 for ; Tue, 15 Aug 2017 17:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kLd2eVJlHkR+2pu6fR88xr0zRyMPGqm58AsTXa/HpDU=; b=AmVVS0cD0q3bsP+7UjzoxDjY7AuIDc619jmLqiU0Xefr9Fn+C/Q+wnf1mq/TlnCyEL NIVg4a+Qc75JEVv0puz+IwIBw20w+/O4PjMU+nmMtflkUvf/+CxETZBMjPowYMxUfFka 9wRi2tKlnQVkYQIVCH0MLBec6aCojkkTlwrrzr/FsG4+mceqqTnMXu22WgVDEiD3kVm/ g/Gi1ZXOhpj4Q/B9aX/qmiESDVLsVIKBivkN9/iVdA+Q/Gw0ZL6+TaM1MqUaZ6J8yDcR TgLrMPEYgqcedx3hMTqeyGDIK03GwQWkCgMGuo2Jljrs4OkQzk58WE80n4CmgjqNgyGk CvoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kLd2eVJlHkR+2pu6fR88xr0zRyMPGqm58AsTXa/HpDU=; b=mKQE2iwqbIFwd7SLBHduqa0t40RkerC/g1kO0YkYguEey9uSPYei3Cuf3ehYVBftZi pYi8mL4qJkQx+JOqfl5cG+BfNIGyE2CWDLYQ6ZX1PEUc0qz1cvPQoXkqAJzuHWLUGEXq CONCsz4oWnsXCylZdMlAYSZMZbAJYjj6dofM8t25CPlt2fW2rtSb2nb0EWky/1/XOH49 1N4PyJoS/GakeS289bq4d4OBie+y73IKs+Le0qs7xqKPr0TSyJlVuMVakDFaTUBJcoev 5jHbJ72RX7qktu+v3COlBEYYaX1+Hw5lyWzq3gCcaGJSx37cFb1jG1EfC93jLMeYPeAo vFfA== X-Gm-Message-State: AHYfb5gz4tnc3Tw/WnuHtK7rruMh/NkCo2zc6PoiV3tZLaY7WfHqLc4x N3trMoIFaJYEq7Y1X7iIue//GISnKKvtivc= X-Received: by 10.129.101.196 with SMTP id z187mr19499554ywb.293.1502842773544; Tue, 15 Aug 2017 17:19:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.38.74 with HTTP; Tue, 15 Aug 2017 17:19:12 -0700 (PDT) In-Reply-To: References: From: Erik Kline Date: Tue, 15 Aug 2017 17:19:12 -0700 Message-ID: To: David Bird , Tommy Pauly Cc: captive-portals@ietf.org, "Eric Vyncke (evyncke)" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114c86bab3a4af0556d3d9af" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 00:19:48 -0000 --001a114c86bab3a4af0556d3d9af Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Randomly selecting Tommy and Eric so this bubbles up in their inbox. On 2 August 2017 at 10:36, David Bird wrote: > Could an author of PvD help me understand the following questions for eac= h > of the diagrams below I found on the Internet -- which represent some > typical hotspot configurations out there... > > - Where would the API reside? > > - Who 'owns' the API? > > - How does the API keep in-sync with the NAS? Who's responsible for that > (possibly multi-vendor, multi-AAA) integration? > > 1) Typical Hotspot service company outsourcing: > http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSoluti= on_beta2b.png > > 2) Same as above, except venue owns portal: > http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspots-co-wor= king-cloudessa_2p1.png > > 3) Now consider the above, but the venue has more roaming partners and > multi-realm RADIUS setup in their Cisco NAS: > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide= /b_cg83/b_cg83_chapter_0100111.html > describes many options -- including separate MAC authentication sources, > optional portals for 802.1x (RADIUS) authenticated users, and so much > more... > > "Cisco ISE supports internal and external identity sources. Both sources = can > be used as an authentication source for sponsor-user and guest-user > authentication." > > Also note this interesting article: the section Information About Captiv= e > Bypassing and how it describes how to avoid Apple captive portal > detection!!! "If no response is received, then the Internet access is > assumed to be blocked by the captive portal and Apple=E2=80=99s Captive N= etwork > Assistant (CNA) auto-launches the pseudo-browser to request portal login = in > a controlled window. The CNA may break when redirecting to an ISE captive > portal. The controller prevents this pseudo-browser from popping up." > > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > --001a114c86bab3a4af0556d3d9af Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgSwStLnRNe1WDHIi/429RoHgK/G050hbh HQzqQDP6LPMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODE2 MDAxOTM0WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAKNcOA4FFkjlZjXh+yFqYDnPMLnsi7ZXG3ngJ47qJTZ8AN7LwHlM La6eGP4trlDv/7pEnWLfvGS3MiQuKR7QoHs6uuykvJ8A8xTEEgb3OUXAtr1N9gFUlqE025e/5/Wx bur9uMKX+RtHVe82qHQrfKBc6yXguB3iU4uUGiLa2/YkLSXawKV9ckI5dzl+bW/XF3xfti/MfS7a oVVvv31L1V7DgzETglS+YCwYgIxCWcxp7XOdl4Vz2Zc/4Wj3WqvOnciAXWSWGQOSB/hI9ChNR2Ug Nwv41dKKCUjQYQQBQevBB/WGbc6hOM+oweGiBrmyHKOVGoyxHhZDy87DHfQxfKw= --001a114c86bab3a4af0556d3d9af-- From nobody Wed Aug 16 01:40:52 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C15BA132656 for ; Wed, 16 Aug 2017 01:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_WP_DIRINDEX=1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Q6phXOxuB_3Q for ; Wed, 16 Aug 2017 01:40:49 -0700 (PDT) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 933A2124207 for ; Wed, 16 Aug 2017 01:40:49 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id c74so10910504iod.4 for ; Wed, 16 Aug 2017 01:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KF4rZO0t6uEbzkDeZoqFrLVOthb+hkLlv0Fg4ul/qfA=; b=v5XhDiru1dqPC+3YYcDnmBL+4htovZtw6q2QIM7uepx/x2068Kaf4piEwumK+CDQ1N 2R4eeXE7lm1WqY7FpY1Pwqtr0GemYIQNWubt5gLgbrlZKrK28gqBaLE3bVIc3i/PKnpq 1gDBcb+QUWHshnSwImxsufQON++cv7IuoQTIIb2OouzuAAi3NaN+iKbA4Xbg/vDeFKvi RVuNwRF8E74zTnqigIHYkKYENKpaSAkh0LYHwoQK/OBe3hA9haoP0owCMBGUBkhxbob+ RZXjgUMoj6gklDQxu/ejC3msuHi4enK5jb7DxIyffPRLspopQSBoBvUbteDo3JRHwC1h Ej8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KF4rZO0t6uEbzkDeZoqFrLVOthb+hkLlv0Fg4ul/qfA=; b=mpmAeJEXbYxUJoM7wH2Ke7L/yNJ+FX56IYQBcPpiBt03/qehnEyxr6RjQp2dropVq9 gGSq4syHIjyVtxvisFd2DmKfp4hGulAy0QxbhciV9W3+2BC2r83axKJ2Nzm6w3GbPax3 FHjxmw4SyIpddoxC/R29LgolH5+/3axgwl2bJ2PGiNFh3Q3etV6ECv4V1hSl8uJGKhHy jgpqfFnRb89Rzg3MUBkf292Zgs2sTEkuyr0K2LJaoZYr2jQXxxxG84mr2NLWmGhqoZxh ErOmI5R0d6kVvs8iozihg0ElkcYU8/Y/oR4zZxNT+a4wY65kZyH8l0qVDyF2aRknkspA TNaA== X-Gm-Message-State: AHYfb5iQca6wQteB6vcJQsUJiCpvp5XQjebPwb6d9uLcoNBNvbPh1y+R zojuN7OXZGurOmgvMuzsAIEJypGoxzBb X-Received: by 10.107.9.195 with SMTP id 64mr769264ioj.72.1502872848639; Wed, 16 Aug 2017 01:40:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Wed, 16 Aug 2017 01:40:27 -0700 (PDT) In-Reply-To: References: From: Lorenzo Colitti Date: Wed, 16 Aug 2017 17:40:27 +0900 Message-ID: To: Erik Kline Cc: David Bird , Tommy Pauly , "Eric Vyncke (evyncke)" , captive-portals@ietf.org Content-Type: multipart/alternative; boundary="001a113eb69649a6470556dadafa" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 08:40:52 -0000 --001a113eb69649a6470556dadafa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Per my understanding, the part of the system that returns the PVD information needs to be in sync with the network elements that are responsible for dropping unauthenticated users' packets and redirecting plaintext HTTP requests to the portal login page. If the two are not in sync then it is a configuration error. To the untrained eye, this does not seem different from saying that the part of the system that handles billing and authentication needs to be in sync with the network elements. For example, it would be bad if the user paid for service and then couldn't use the network. On Wed, Aug 16, 2017 at 9:19 AM, Erik Kline wrote: > Randomly selecting Tommy and Eric so this bubbles up in their inbox. > > On 2 August 2017 at 10:36, David Bird wrote: > > Could an author of PvD help me understand the following questions for > each > > of the diagrams below I found on the Internet -- which represent some > > typical hotspot configurations out there... > > > > - Where would the API reside? > > > > - Who 'owns' the API? > > > > - How does the API keep in-sync with the NAS? Who's responsible for tha= t > > (possibly multi-vendor, multi-AAA) integration? > > > > 1) Typical Hotspot service company outsourcing: > > http://cloudessa.com/wp-content/uploads/2013/08/shema- > CaptivePortalSolution_beta2b.png > > > > 2) Same as above, except venue owns portal: > > http://cloudessa.com/wp-content/uploads/2013/07/ > solutions_hotspots-co-working-cloudessa_2p1.png > > > > 3) Now consider the above, but the venue has more roaming partners and > > multi-realm RADIUS setup in their Cisco NAS: > > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8- > 3/config-guide/b_cg83/b_cg83_chapter_0100111.html > > describes many options -- including separate MAC authentication sources= , > > optional portals for 802.1x (RADIUS) authenticated users, and so much > > more... > > > > "Cisco ISE supports internal and external identity sources. Both source= s > can > > be used as an authentication source for sponsor-user and guest-user > > authentication." > > > > Also note this interesting article: the section Information About > Captive > > Bypassing and how it describes how to avoid Apple captive portal > > detection!!! "If no response is received, then the Internet access is > > assumed to be blocked by the captive portal and Apple=E2=80=99s Captive= Network > > Assistant (CNA) auto-launches the pseudo-browser to request portal logi= n > in > > a controlled window. The CNA may break when redirecting to an ISE capti= ve > > portal. The controller prevents this pseudo-browser from popping up." > > > > > > > > _______________________________________________ > > Captive-portals mailing list > > Captive-portals@ietf.org > > https://www.ietf.org/mailman/listinfo/captive-portals > > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > --001a113eb69649a6470556dadafa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Per my understanding, the part of the system that returns = the PVD information needs to be in sync with the network elements that are = responsible for dropping unauthenticated users' packets and redirecting= plaintext HTTP requests to the portal login page. If the two are not in sy= nc then it is a configuration error.

To the untrained eye= , this does not seem different from saying that the part of the system that= handles billing and authentication needs to be in sync with the network el= ements. For example, it would be bad if the user paid for service and then = couldn't use the network.

On Wed, Aug 16, 2017 at 9:19 AM, Erik K= line <ek@google.com> wrote:
Ra= ndomly selecting Tommy and Eric so this bubbles up in their inbox.

On 2 August 2017 at 10:36, David Bird <dbird@google.com> wrote:
> Could an author of PvD help me understand the following questions for = each
> of the diagrams below I found on the Internet -- which represent some<= br> > typical hotspot configurations out there...
>
> - Where would the API reside?
>
> - Who 'owns' the API?
>
> - How does the API keep in-sync with the NAS? Who's responsible fo= r that
> (possibly multi-vendor, multi-AAA) integration?
>
> 1) Typical Hotspot service company outsourcing:
> http://cl= oudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolutio= n_beta2b.png
>
> 2) Same as above, except venue owns portal:
> = http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspot= s-co-working-cloudessa_2p1.png
>
> 3) Now consider the above, but the venue has more roaming partners and=
> multi-realm RADIUS setup in their Cisco NAS:
> http://www.cisco.com/c/en/us/td/docs/wireless/controller/= 8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html
> describes many options -- including separate MAC authentication source= s,
> optional portals for 802.1x (RADIUS) authenticated users, and so much<= br> > more...
>
> "Cisco ISE supports internal and external identity sources. Both = sources can
> be used as an authentication source for sponsor-user and guest-user > authentication."
>
> Also note this interesting article:=C2=A0 the section Information Abou= t Captive
> Bypassing and how it describes how to avoid Apple captive portal
> detection!!! "If no response is received, then the Internet acces= s is
> assumed to be blocked by the captive portal and Apple=E2=80=99s Captiv= e Network
> Assistant (CNA) auto-launches the pseudo-browser to request portal log= in in
> a controlled window. The CNA may break when redirecting to an ISE capt= ive
> portal. The controller prevents this pseudo-browser from popping up.&q= uot;
>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinf= o/captive-portals
>

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/capt= ive-portals


--001a113eb69649a6470556dadafa-- From nobody Wed Aug 16 05:58:24 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7441F13219A for ; Wed, 16 Aug 2017 05:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.74 X-Spam-Level: X-Spam-Status: No, score=-1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 slZxjH2pAWFG for ; Wed, 16 Aug 2017 05:58:19 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D9731326B0 for ; Wed, 16 Aug 2017 05:58:19 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id t37so20031944qtg.5 for ; Wed, 16 Aug 2017 05:58:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=R4lBzDFDoTxO5JEpXFApxjDm/ziQ2sjm0+1ag9DoVZ0=; b=S1os0IdKaZGM1zsUJ48jgCL6lhorPAzmPPgT3MUCeqRxFmwqldj5H+ekT+mflYnZEQ q0hR+7K1dhJv20uJ8qzR//rUSiYy/E5KVrnp+dC7XFFIGkXwaawBqmb0D3md4SaY/873 wOfWDVnvrSuUVLXgeV8j1izM4Dfr2gOMzdxBh156Vo0fsLj5jrbtpK2jNfDud8f2UsXC iqjCaixVUuRDq8FVqic5kL8F+0lDyDYfdOk75UwFE+y72UH87vS0oXeZXDhakjZ7MO9i 7TBzKKHbMPzunOMrYzyOWgKe4ciGdAXVWi5OeqkF/eNFVUum1Nle6dih+W2qi2dC3blD S0jQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=R4lBzDFDoTxO5JEpXFApxjDm/ziQ2sjm0+1ag9DoVZ0=; b=TY5jddVELe34P+Z/cYtvcH/OR3TegNJY/xPFqV8n0ds3wiG4THlx2vD4g1cVVExkae DV5a/q90+9frlFtywCUO0sWNXsgbzPhxkAMnxzW0jKSPrbu5A932Xnudgr9LpeCg0k37 PRN9V/qDk84U3hrijPJh/zxajMa0p65fAGXKBNk8aG2yRozYUtzN61YShcIz+YStgBjk J5glNfZBH2A0O7k7aWNPQsfDBhHG6CFgiGg6Zo3sgdB6uNE8EFX5Xajz0FKxrcXzlVuf X64+qd795Ye+6Lx9fYqM5hfi7PiIDjd5mnYDKwiZ/Vv9sNrldr0xoPdlM3ICaAFuN2kA Eo2Q== X-Gm-Message-State: AHYfb5hLECOGN+bTdl8krNI9g1uojTcx26CSqf2RLJzivdlO7BorY/Ga NVodERzwDIDXIkHNRo2qFAJwxOoRBc3E X-Received: by 10.200.52.56 with SMTP id u53mr2193497qtb.217.1502888298211; Wed, 16 Aug 2017 05:58:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.149.58 with HTTP; Wed, 16 Aug 2017 05:58:17 -0700 (PDT) In-Reply-To: References: From: David Bird Date: Wed, 16 Aug 2017 05:58:17 -0700 Message-ID: To: Lorenzo Colitti Cc: Erik Kline , Tommy Pauly , "Eric Vyncke (evyncke)" , captive-portals@ietf.org Content-Type: multipart/alternative; boundary="001a11455776276d480556de7390" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 12:58:22 -0000 --001a11455776276d480556de7390 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have no doubt that PvD _could_ be setup and configured to work well. My concern is that if it is difficult to implement/setup correctly, plenty of locations will have a broken PvD. At that point, I wonder what the UE vendors will do... Keep using the PvD (and get user complaints) or start ignoring the PvD and doing 'legacy' portal detection anyway. In 3GPP terms, PvD is like asking the UE to connect directly to the PCRF (or systems like a captive portal that talks to PCRF) and not the PCEF. The PCEF is analogous to the "NAS" and connects to PCRF using Diameter for AAA (in WiFi the NAS typically uses RADIUS for AAA). The PCEF might be talking to multiple PCRFs... It would make more sense if the UE only interacted with the PCEF and never directly with the PCRF(s). PvD _could_ live in the PCEF (or NAS), but would that be the common way to deploy PvD? Perhaps in 3GPP is would make sense to put PvD in the PCEF (assuming PCEF is centralized, more or less, in their network). However, in WiFi, the "NAS" can often be in the AP itself (so there are many of them) and often are not physically owned by the same party running the AAA/Portal (a hotspot services company). I don't think a hotspot services company wants to put their SSL cert on other peoples devices... On Wed, Aug 16, 2017 at 1:40 AM, Lorenzo Colitti wrote= : > Per my understanding, the part of the system that returns the PVD > information needs to be in sync with the network elements that are > responsible for dropping unauthenticated users' packets and redirecting > plaintext HTTP requests to the portal login page. If the two are not in > sync then it is a configuration error. > > To the untrained eye, this does not seem different from saying that the > part of the system that handles billing and authentication needs to be in > sync with the network elements. For example, it would be bad if the user > paid for service and then couldn't use the network. > > On Wed, Aug 16, 2017 at 9:19 AM, Erik Kline wrote: > >> Randomly selecting Tommy and Eric so this bubbles up in their inbox. >> >> On 2 August 2017 at 10:36, David Bird wrote: >> > Could an author of PvD help me understand the following questions for >> each >> > of the diagrams below I found on the Internet -- which represent some >> > typical hotspot configurations out there... >> > >> > - Where would the API reside? >> > >> > - Who 'owns' the API? >> > >> > - How does the API keep in-sync with the NAS? Who's responsible for th= at >> > (possibly multi-vendor, multi-AAA) integration? >> > >> > 1) Typical Hotspot service company outsourcing: >> > http://cloudessa.com/wp-content/uploads/2013/08/shema-Captiv >> ePortalSolution_beta2b.png >> > >> > 2) Same as above, except venue owns portal: >> > http://cloudessa.com/wp-content/uploads/2013/07/solutions_ >> hotspots-co-working-cloudessa_2p1.png >> > >> > 3) Now consider the above, but the venue has more roaming partners and >> > multi-realm RADIUS setup in their Cisco NAS: >> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3 >> /config-guide/b_cg83/b_cg83_chapter_0100111.html >> > describes many options -- including separate MAC authentication source= s, >> > optional portals for 802.1x (RADIUS) authenticated users, and so much >> > more... >> > >> > "Cisco ISE supports internal and external identity sources. Both >> sources can >> > be used as an authentication source for sponsor-user and guest-user >> > authentication." >> > >> > Also note this interesting article: the section Information About >> Captive >> > Bypassing and how it describes how to avoid Apple captive portal >> > detection!!! "If no response is received, then the Internet access is >> > assumed to be blocked by the captive portal and Apple=E2=80=99s Captiv= e Network >> > Assistant (CNA) auto-launches the pseudo-browser to request portal >> login in >> > a controlled window. The CNA may break when redirecting to an ISE >> captive >> > portal. The controller prevents this pseudo-browser from popping up." >> > >> > >> > >> > _______________________________________________ >> > Captive-portals mailing list >> > Captive-portals@ietf.org >> > https://www.ietf.org/mailman/listinfo/captive-portals >> > >> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals >> >> > --001a11455776276d480556de7390 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have no doubt that PvD _could_ be setup and configured t= o work well. My concern is that if it is difficult to implement/setup corre= ctly, plenty of locations will have a broken PvD. At that point, I wonder w= hat the UE vendors will do... Keep using the PvD (and get user complaints) = or start ignoring the PvD and doing 'legacy' portal detection anywa= y.=C2=A0

In 3GPP terms, PvD is like asking the UE to con= nect directly to the PCRF (or systems like a captive portal that talks to P= CRF) and not the PCEF. The PCEF is analogous to the "NAS" and con= nects to PCRF using Diameter for AAA (in WiFi the NAS typically uses RADIUS= for AAA). The PCEF might be talking to multiple PCRFs... It would make mor= e sense if the UE only interacted with the PCEF and never directly with the= PCRF(s). PvD _could_ live in the PCEF (or NAS), but would that be the comm= on way to deploy PvD? Perhaps in 3GPP is would make sense to put PvD in the= PCEF (assuming PCEF is centralized, more or less, in their network). Howev= er, in WiFi, the "NAS" can often be in the AP itself (so there ar= e many of them) and often are not physically owned by the same party runnin= g the AAA/Portal (a hotspot services company). I don't think a hotspot = services company wants to put their SSL cert on other peoples devices...=C2= =A0


On Wed, Aug 16, 2017 at 1:40 AM, Lorenzo Colitt= i <lorenzo@google.com> wrote:
Per my understanding, the part of the system that ret= urns the PVD information needs to be in sync with the network elements that= are responsible for dropping unauthenticated users' packets and redire= cting plaintext HTTP requests to the portal login page. If the two are not = in sync then it is a configuration error.

To the untraine= d eye, this does not seem different from saying that the part of the system= that handles billing and authentication needs to be in sync with the netwo= rk elements. For example, it would be bad if the user paid for service and = then couldn't use the network.

On Wed, Aug 16, 2017 at 9:19 AM, Erik Kline <ek@google.com> wrote:
Randomly selecting Tommy and Eri= c so this bubbles up in their inbox.

On 2 August 2017 at 10:36, David Bird <dbird@google.com> wrote:
> Could an author of PvD help me understand the following questions for = each
> of the diagrams below I found on the Internet -- which represent some<= br> > typical hotspot configurations out there...
>
> - Where would the API reside?
>
> - Who 'owns' the API?
>
> - How does the API keep in-sync with the NAS? Who's responsible fo= r that
> (possibly multi-vendor, multi-AAA) integration?
>
> 1) Typical Hotspot service company outsourcing:
> http://cl= oudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolutio= n_beta2b.png
>
> 2) Same as above, except venue owns portal:
> = http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspot= s-co-working-cloudessa_2p1.png
>
> 3) Now consider the above, but the venue has more roaming partners and=
> multi-realm RADIUS setup in their Cisco NAS:
> http://www.cisco.com/c/en/us/td/docs/wireless/controller/= 8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html
> describes many options -- including separate MAC authentication source= s,
> optional portals for 802.1x (RADIUS) authenticated users, and so much<= br> > more...
>
> "Cisco ISE supports internal and external identity sources. Both = sources can
> be used as an authentication source for sponsor-user and guest-user > authentication."
>
> Also note this interesting article:=C2=A0 the section Information Abou= t Captive
> Bypassing and how it describes how to avoid Apple captive portal
> detection!!! "If no response is received, then the Internet acces= s is
> assumed to be blocked by the captive portal and Apple=E2=80=99s Captiv= e Network
> Assistant (CNA) auto-launches the pseudo-browser to request portal log= in in
> a controlled window. The CNA may break when redirecting to an ISE capt= ive
> portal. The controller prevents this pseudo-browser from popping up.&q= uot;
>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-= portals@ietf.org
> https://www.ietf.org/mailman/listinf= o/captive-portals
>

_______________________________________________
Captive-portals mailing list
Captive-porta= ls@ietf.org
https://www.ietf.org/mailman/listinfo/capt= ive-portals



--001a11455776276d480556de7390-- From nobody Wed Aug 16 06:52:04 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3401A1320B5 for ; Wed, 16 Aug 2017 06:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URI_WP_DIRINDEX=1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 u8Df0a_-ebh1 for ; Wed, 16 Aug 2017 06:52:00 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1B21241FC for ; Wed, 16 Aug 2017 06:52:00 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id d145so20478466qkc.2 for ; Wed, 16 Aug 2017 06:51:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4kDIfzjGSKK2f+ZlieTNGl1LkxNOUZqccd81OdrbL98=; b=YzKBnD1kYSb5xQh8vY5GCUJgHRq+1ZfPEoRPKN1iBdFHFo888L3jQLYUEr7qUrX0GH SL+7BaiF69eg0yjhysHAZKwdf+ME0dmDeheCzGCqPey/fQNNga5/e+uV9qogVNbq9uLK zvmSfmLyJFJuB17Ho9iBNPvgnVbBmGIsaSeZlCOLOIumhwIRhz10jJqJUogiLpbKQX/O +O30iBzi7v5Vehma4doh8Fa8WB72fTuvwz0bKmFDCtVWz97+hYL0KjpNeUK753NjKy51 0zwiQFWf5D2Ja0hj0V525ge0vxoTbD9ngmbHRRrMpgiFWrYx7y92GCu68Xhu2pBKvQPs mx9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4kDIfzjGSKK2f+ZlieTNGl1LkxNOUZqccd81OdrbL98=; b=P2TwzaHUJuvAzm/avCndoKHv7LfwEX4IEeCyMD5312a4cqXpThAxftAk5CXmBevX5C 3JsaDjfudEfi4Mct8cjzMM0wP2MUexeRXYljpAYcn1513LCDpBiqM9JyoLjp4ZQ7bxyT jnk5QY3fFcV8jRt4jZtMmf4X8mWA1y7gOVRHVxaRe2jCmJgCzEdSpeobGtx+Ly71lp6M GB15sWRgNY1TDHUg6MnbqMfuiTIwa1T/XU1K1KHv5d+0vTEYVHJ4mO19P7ly32Zq1PGQ 7NNrohjkgM6Ux7UCCrCYDg78HH4Xz/AaC0SjtoMlZYLrcqa9PYLGmPhGTmnXGoMB/C7r XPeQ== X-Gm-Message-State: AHYfb5j/G7egwDttZ45isCy/R+FpeaFLHUXbpwVq1B5l0G7PzrF0Chzs b3AhzoegSmqQuvJJsZj1Rag7sIW5b7cy X-Received: by 10.55.192.79 with SMTP id o76mr2278393qki.312.1502891518908; Wed, 16 Aug 2017 06:51:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.149.58 with HTTP; Wed, 16 Aug 2017 06:51:58 -0700 (PDT) In-Reply-To: References: From: David Bird Date: Wed, 16 Aug 2017 06:51:58 -0700 Message-ID: To: Erik Kline Cc: Tommy Pauly , captive-portals@ietf.org, "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary="001a1149aeb61f89210556df3392" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 13:52:02 -0000 --001a1149aeb61f89210556df3392 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My question about where the PvD API resides was somewhat rhetorical. In reality, I'm sure you will find all of the above - In the NAS (e.g. Cisco), at the hotspot services provider, and something hosted next to the venues website. It depends mostly on how this URL is configured, and by whom. (One could imagine people doing all sorts of things). My question more specifically for the authors is, how would Cisco implement PvD for Guest/Public access and would it actively stop avoiding Apple captive portal detection? Or, would turning on PvD just make that 'feature' easier to implement? On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline wrote: > Randomly selecting Tommy and Eric so this bubbles up in their inbox. > > On 2 August 2017 at 10:36, David Bird wrote: > > Could an author of PvD help me understand the following questions for > each > > of the diagrams below I found on the Internet -- which represent some > > typical hotspot configurations out there... > > > > - Where would the API reside? > > > > - Who 'owns' the API? > > > > - How does the API keep in-sync with the NAS? Who's responsible for tha= t > > (possibly multi-vendor, multi-AAA) integration? > > > > 1) Typical Hotspot service company outsourcing: > > http://cloudessa.com/wp-content/uploads/2013/08/shema- > CaptivePortalSolution_beta2b.png > > > > 2) Same as above, except venue owns portal: > > http://cloudessa.com/wp-content/uploads/2013/07/ > solutions_hotspots-co-working-cloudessa_2p1.png > > > > 3) Now consider the above, but the venue has more roaming partners and > > multi-realm RADIUS setup in their Cisco NAS: > > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8- > 3/config-guide/b_cg83/b_cg83_chapter_0100111.html > > describes many options -- including separate MAC authentication sources= , > > optional portals for 802.1x (RADIUS) authenticated users, and so much > > more... > > > > "Cisco ISE supports internal and external identity sources. Both source= s > can > > be used as an authentication source for sponsor-user and guest-user > > authentication." > > > > Also note this interesting article: the section Information About > Captive > > Bypassing and how it describes how to avoid Apple captive portal > > detection!!! "If no response is received, then the Internet access is > > assumed to be blocked by the captive portal and Apple=E2=80=99s Captive= Network > > Assistant (CNA) auto-launches the pseudo-browser to request portal logi= n > in > > a controlled window. The CNA may break when redirecting to an ISE capti= ve > > portal. The controller prevents this pseudo-browser from popping up." > > > > > > > > _______________________________________________ > > Captive-portals mailing list > > Captive-portals@ietf.org > > https://www.ietf.org/mailman/listinfo/captive-portals > > > --001a1149aeb61f89210556df3392 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My question about where the PvD API resides was somewhat r= hetorical. In reality, I'm sure you will find all of the above - In the= NAS (e.g. Cisco), at the hotspot services provider, and something hosted n= ext to the venues website. It depends mostly on how this URL is configured,= and by whom. (One could imagine people doing all sorts of things).=C2=A0
My question more specifically for the authors is, how wou= ld Cisco implement PvD for Guest/Public access and would it actively stop a= voiding Apple captive portal detection? Or, would turning on PvD just make = that 'feature' easier to implement?

On Tue, Aug 15, 2017 at 5:19 PM, Erik= Kline <ek@google.com> wrote:
= Randomly selecting Tommy and Eric so this bubbles up in their inbox.

On 2 August 2017 at 10:36, David Bird <dbird@google.com> wrote:
> Could an author of PvD help me understand the following questions for = each
> of the diagrams below I found on the Internet -- which represent some<= br> > typical hotspot configurations out there...
>
> - Where would the API reside?
>
> - Who 'owns' the API?
>
> - How does the API keep in-sync with the NAS? Who's responsible fo= r that
> (possibly multi-vendor, multi-AAA) integration?
>
> 1) Typical Hotspot service company outsourcing:
> http://cl= oudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolutio= n_beta2b.png
>
> 2) Same as above, except venue owns portal:
> = http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspot= s-co-working-cloudessa_2p1.png
>
> 3) Now consider the above, but the venue has more roaming partners and=
> multi-realm RADIUS setup in their Cisco NAS:
> http://www.cisco.com/c/en/us/td/docs/wireless/controller/= 8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html
> describes many options -- including separate MAC authentication source= s,
> optional portals for 802.1x (RADIUS) authenticated users, and so much<= br> > more...
>
> "Cisco ISE supports internal and external identity sources. Both = sources can
> be used as an authentication source for sponsor-user and guest-user > authentication."
>
> Also note this interesting article:=C2=A0 the section Information Abou= t Captive
> Bypassing and how it describes how to avoid Apple captive portal
> detection!!! "If no response is received, then the Internet acces= s is
> assumed to be blocked by the captive portal and Apple=E2=80=99s Captiv= e Network
> Assistant (CNA) auto-launches the pseudo-browser to request portal log= in in
> a controlled window. The CNA may break when redirecting to an ISE capt= ive
> portal. The controller prevents this pseudo-browser from popping up.&q= uot;
>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinf= o/captive-portals
>

--001a1149aeb61f89210556df3392-- From nobody Wed Aug 16 09:20:20 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4185C1320BE for ; Wed, 16 Aug 2017 09:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 j9StqkkbVCOI for ; Wed, 16 Aug 2017 09:20:16 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5274B132626 for ; Wed, 16 Aug 2017 09:20:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1502900416; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=IXr919pMv4PkohhYmJ4RqtnlbGAUL3Y2ivd82QebMAw=; b=Yvv1tnH0BkbXfHYc4yKE8EV3PG/WOQXiiBANWtZlbCvfB/T5+cwCYiv3zjll/1U4 ZSJ0sYmL3ChzgFcEEhrBhiP2qJFwT/S49wlcziR35Gadz2kaob9JE8AcOLNsmBEI Avlf0TkCSk/FXa6U4ruIZbE8Ne8nJCx5ZVVtf/fATO047jGEqcWOYeP7HZLb4jqn BV/M2DVs/oNYFUr4bP9dLH5CT3YSeh07P6ODuChesy5gHsLkz7RusAgTJepdONFW 7B76oj7kFr1XyFgM6OqWz+iX5fXAmvQnwXRPBgQJWsLWfC25VlvnSjn2+Vau8oyQ BT1K/8GbDEGVMhM6GOWWuw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 0A.DF.30368.0C074995; Wed, 16 Aug 2017 09:20:16 -0700 (PDT) X-AuditID: 11973e13-821a09c0000076a0-a0-599470c0ce4f Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay2.apple.com (Apple SCV relay) with SMTP id 67.CF.09069.FB074995; Wed, 16 Aug 2017 09:20:15 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_fkT6S1//At6VENOK84T78A)" Received: from [17.234.116.8] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUS000JJDDR8460@nwk-mmpp-sz11.apple.com>; Wed, 16 Aug 2017 09:20:15 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Wed, 16 Aug 2017 09:20:14 -0700 In-reply-to: Cc: Erik Kline , captive-portals@ietf.org, "Eric Vyncke (evyncke)" To: David Bird References: X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUi2FDorHugYEqkwa6ljBZzZzWwWnz6sZ3R 4vPteewWX/YvYHRg8ZjyeyOrx4JNpR5LlvxkCmCO4rJJSc3JLEst0rdL4MpYv28Vc8HEdsaK tUuWsDYwri3sYuTkkBAwkXiw7ChrFyMXh5DAaiaJk1dvscIkGjZPZ4RIHGKUmPGiiwUkwSsg KPFj8j0wm1kgTOL5giYmEFtI4AujxIn/Jl2MHBzCAhISm/ckgoTZBFQkjn/bwAzRaiPxcPE3 sFZhATOJPU0fwFpZBFQlmjqOgtmcAsESJ1buZoYYny7x5fMRsHoRAUWJU9eOM0Hc84BR4sfK b4wguyQEZCWW/gkBiUsITGaXuPG1l3ECo9AsJKfOQnLqLKAWZgF1iSlTciHC2hJP3l1ghbDV JBb+XsSELL6AkW0Vo1BuYmaObmaeqV5iQUFOql5yfu4mRlCcTLcT3sF4epXVIUYBDkYlHt6I vCmRQqyJZcWVuYcYpTlYlMR5bSwmRQoJpCeWpGanphakFsUXleakFh9iZOLglGpglPZ/fE1m 0ev/DjZXrO9sf76s+6Tc6z8mz3KfqyfZbRVO92dtO732tY1kZamcsPJ05cDvB5dIvBezd1J/ Fr7UZmFu+Y1Oibkm61efTfw0YdonxV+7xNX0Z2hW/2hz+J3B/nz6ildCTft63f7wGVx6sEJU dmHSfnuW7GrFFOENkm5pnH+DL557r8RSnJFoqMVcVJwIACo2VPd0AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUi2FA8W3d/wZRIg3nvLC3mzmpgtfj0Yzuj xefb89gtvuxfwOjA4jHl90ZWjwWbSj2WLPnJFMAcZW2Tll9UnliUolCUXFBiq1SckZiSXx5v aWxk6pBYUJCTqpecn6ukb2eTkpqTWZZahMxKsM5Yv28Vc8HEdsaKtUuWsDYwri3sYuTkkBAw kWjYPJ2xi5GLQ0jgEKPEjBddLCAJXgFBiR+T74HZzAJhEs8XNDGB2EICXxglTvw36WLk4BAW kJDYvCcRJMwmoCJx/NsGZohWG4mHi7+BtQoLmEnsafoA1soioCrR1HEUzOYUCJY4sXI3M8T4 dIkvn4+A1YsIKEqcunacCeKeB4wSP1Z+YwTZJSEgK7H0T8gERv5ZSK6bheS6WUBVzALqElOm 5EKEtSWevLvACmGrSSz8vYgJWXwBI9sqRoGi1JzESiM9ePBtYgRHTqHzDsZjy6wOMQpwMCrx 8AZYT44UYk0sK67MBQYRB7OSCG9N/pRIId6UxMqq1KL8+KLSnNTiQ4z7GYGenMgsJZqcD4zr vJJ4Q2MLY0sTCwMDE0szE8LCJiYGJsbGZsbG5ibmtBRWEueVKQJ6SSA9sSQ1OzW1ILUI5gUm Dk6pBsaSs8U/PtkyZQecV/r9XnW9ZbjceQPWY0l1x8/xR2Q4zvyXPl3tzUkOztgj6q4ujq95 uKsZpswXyRO+w+UZ/kTkX092cK6uHn9CgqjXzeaFatPvyVXcnnVee4vf/pDD+7YXv21+uONB 0sSquH6blOMrlviveyrMJL9pRaK1rW+houruzff+1CmxABO3oRZzUXEiAJHmmi89AwAA Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Aug 2017 16:20:18 -0000 --Boundary_(ID_fkT6S1//At6VENOK84T78A) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi David, You mention in one of your emails that you'd expect there to be many = "broken PvD" deployments, which would either necessitate ignoring PvD = and using legacy mechanisms, or else having the user face a broken = portal. My impression is that if client-side deployments fail = closed=E2=80=94that is, if there is a PvD advertised, but it does not = work well, then we treat the network as broken. If this client behavior = is consistent from the start of deployment, then I would think that = deployments would notice very quickly if they are broken. The = fundamental part of the PvD being advertised is in the RAs=E2=80=94if = our DHCP or RAs are broken on a network, we generally are going to be = broken anyhow. As far as where the API resides, I appreciate your explanation of the = various complexities. My initial take is this: - Where a PvD is being served is up to the deployment, and determined by = the entity that is providing the RAs. To that end, the server that hosts = the API for extended PvD information may be very different for = enterprise/carrier scenarios than in captive portals for coffee shops. - For the initial take for Captive Portals, I would co-locate the "PvD = API" server with the "Captive API" and "Captive Web Server". Presumably, = the device that was previously doing the HTTP redirects would be able to = do the similar coordination of making sure the PvD ID that is given out = to clients matches the PvD API server (which is the same as the "Captive = Web Server"). For the captive use-case, I see the integration of PvDs as an = incremental step: 1. Today, we join a network, always do a probe, which may get redirected = to a captive web server 2. With RFC 7710, we would join a network and do the same as (1), unless = the captive URL is given in the DHCP/RA and we just make a connection = directly. 3. With the Captive API draft, we can interact with the portal other = than just showing a webpage; but this may still be bootstrapped by 7710 = if not using another mechanism 4. With PvDs, the mechanism in 7710 is generalized to support APIs other = than just captive, and can indicate that no captive portal or other = extended info is present; and the PvD API in this form is just a more = generic version of the captive API that allows us to use the same = mechanism for other network properties that aren't specifically captive = (like enterprise network extended info, or walled gardens) Getting into the arms race of people avoiding the captive probes: if = someone doesn't want to interact with the client OS's captive portal = system, they can and likely will not change anything and just keep = redirecting pages. Hopefully if a better solution becomes prevalent = enough in the future, client OS's will be able to just ignore and reject = any network that redirects traffic, and the only supported captive = portals would be ones that interact in specified ways and advertise = themselves as captive networks. In order to get to this point, there = certainly needs to be a carrot to incentivize adoption. My goal with the = more flexible interaction supported by PvD is that we will allow the = networks to provide a better user experience to people joining their = networks, and integrate with client OS's to streamline the joining = process (notification of the network being available, who owns it, how = to accept and how to pay), the maintenance process (being able to = integrate time left or bytes left on the network into the system UI), = and what is allowed or not on the network. Thanks, Tommy > On Aug 16, 2017, at 6:51 AM, David Bird wrote: >=20 > My question about where the PvD API resides was somewhat rhetorical. = In reality, I'm sure you will find all of the above - In the NAS (e.g. = Cisco), at the hotspot services provider, and something hosted next to = the venues website. It depends mostly on how this URL is configured, and = by whom. (One could imagine people doing all sorts of things).=20 >=20 > My question more specifically for the authors is, how would Cisco = implement PvD for Guest/Public access and would it actively stop = avoiding Apple captive portal detection? Or, would turning on PvD just = make that 'feature' easier to implement? >=20 > On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline > wrote: > Randomly selecting Tommy and Eric so this bubbles up in their inbox. >=20 > On 2 August 2017 at 10:36, David Bird > wrote: > > Could an author of PvD help me understand the following questions = for each > > of the diagrams below I found on the Internet -- which represent = some > > typical hotspot configurations out there... > > > > - Where would the API reside? > > > > - Who 'owns' the API? > > > > - How does the API keep in-sync with the NAS? Who's responsible for = that > > (possibly multi-vendor, multi-AAA) integration? > > > > 1) Typical Hotspot service company outsourcing: > > = http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolutio= n_beta2b.png = > > > > 2) Same as above, except venue owns portal: > > = http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspots-co-work= ing-cloudessa_2p1.png = > > > > 3) Now consider the above, but the venue has more roaming partners = and > > multi-realm RADIUS setup in their Cisco NAS: > > = http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/= b_cg83/b_cg83_chapter_0100111.html = > > describes many options -- including separate MAC authentication = sources, > > optional portals for 802.1x (RADIUS) authenticated users, and so = much > > more... > > > > "Cisco ISE supports internal and external identity sources. Both = sources can > > be used as an authentication source for sponsor-user and guest-user > > authentication." > > > > Also note this interesting article: the section Information About = Captive > > Bypassing and how it describes how to avoid Apple captive portal > > detection!!! "If no response is received, then the Internet access = is > > assumed to be blocked by the captive portal and Apple=E2=80=99s = Captive Network > > Assistant (CNA) auto-launches the pseudo-browser to request portal = login in > > a controlled window. The CNA may break when redirecting to an ISE = captive > > portal. The controller prevents this pseudo-browser from popping = up." > > > > > > > > _______________________________________________ > > Captive-portals mailing list > > Captive-portals@ietf.org > > https://www.ietf.org/mailman/listinfo/captive-portals = > > >=20 --Boundary_(ID_fkT6S1//At6VENOK84T78A) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = David,

You mention = in one of your emails that you'd expect there to be many "broken PvD" = deployments, which would either necessitate ignoring PvD and using = legacy mechanisms, or else having the user face a broken portal. My = impression is that if client-side deployments fail closed=E2=80=94that = is, if there is a PvD advertised, but it does not work well, then we = treat the network as broken. If this client behavior is consistent from = the start of deployment, then I would think that deployments would = notice very quickly if they are broken. The fundamental part of the PvD = being advertised is in the RAs=E2=80=94if our DHCP or RAs are broken on = a network, we generally are going to be broken anyhow.

As far as where the API = resides, I appreciate your explanation of the various complexities. My = initial take is this:

- Where a PvD is being served is up to the deployment, and = determined by the entity that is providing the RAs. To that end, the = server that hosts the API for extended PvD information may be very = different for enterprise/carrier scenarios than in captive portals for = coffee shops.
- For the initial take for Captive = Portals, I would co-locate the "PvD API" server with the "Captive API" = and "Captive Web Server". Presumably, the device that was previously = doing the HTTP redirects would be able to do the similar coordination of = making sure the PvD ID that is given out to clients matches the PvD API = server (which is the same as the "Captive Web Server").

For the captive = use-case, I see the integration of PvDs as an incremental = step:

1. = Today, we join a network, always do a probe, which may get redirected to = a captive web server
2. With RFC 7710, we would = join a network and do the same as (1), unless the captive URL is given = in the DHCP/RA and we just make a connection directly.
3. With the Captive API draft, we can interact with the = portal other than just showing a webpage; but this may still be = bootstrapped by 7710 if not using another mechanism
4. With PvDs, the mechanism in 7710 is generalized to support = APIs other than just captive, and can indicate that no captive portal or = other extended info is present; and the PvD API in this form is just a = more generic version of the captive API that allows us to use the same = mechanism for other network properties that aren't specifically captive = (like enterprise network extended info, or walled gardens)

Getting into the arms = race of people avoiding the captive probes: if someone doesn't want to = interact with the client OS's captive portal system, they can and likely = will not change anything and just keep redirecting pages. Hopefully if a = better solution becomes prevalent enough in the future, client OS's will = be able to just ignore and reject any network that redirects traffic, = and the only supported captive portals would be ones that interact in = specified ways and advertise themselves as captive networks. In order to = get to this point, there certainly needs to be a carrot to incentivize = adoption. My goal with the more flexible interaction supported by PvD is = that we will allow the networks to provide a better user experience to = people joining their networks, and integrate with client OS's to = streamline the joining process (notification of the network being = available, who owns it, how to accept and how to pay), the maintenance = process (being able to integrate time left or bytes left on the network = into the system UI), and what is allowed or not on the = network.

Thanks,
Tommy

On Aug = 16, 2017, at 6:51 AM, David Bird <dbird@google.com> wrote:

My question about where the PvD API resides was somewhat = rhetorical. In reality, I'm sure you will find all of the above - In the = NAS (e.g. Cisco), at the hotspot services provider, and something hosted = next to the venues website. It depends mostly on how this URL is = configured, and by whom. (One could imagine people doing all sorts of = things). 

My = question more specifically for the authors is, how would Cisco implement = PvD for Guest/Public access and would it actively stop avoiding Apple = captive portal detection? Or, would turning on PvD just make that = 'feature' easier to implement?

On Tue, Aug 15, 2017 at 5:19 PM, = Erik Kline <ek@google.com> wrote:
Randomly selecting Tommy and Eric so this = bubbles up in their inbox.

On 2 August 2017 at 10:36, David Bird <dbird@google.com> = wrote:
> Could an author of PvD help me understand the following questions = for each
> of the diagrams below I found on the Internet -- which represent = some
> typical hotspot configurations out there...
>
> - Where would the API reside?
>
> - Who 'owns' the API?
>
> - How does the API keep in-sync with the NAS? Who's responsible for = that
> (possibly multi-vendor, multi-AAA) integration?
>
> 1) Typical Hotspot service company outsourcing:
> http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolution_beta2b.png
>
> 2) Same as above, except venue owns portal:
> http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspots-co-working-cloudessa_2p1.png
>
> 3) Now consider the above, but the venue has more roaming partners = and
> multi-realm RADIUS setup in their Cisco NAS:
> http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html
> describes many options -- including separate MAC authentication = sources,
> optional portals for 802.1x (RADIUS) authenticated users, and so = much
> more...
>
> "Cisco ISE supports internal and external identity sources. Both = sources can
> be used as an authentication source for sponsor-user and = guest-user
> authentication."
>
> Also note this interesting article:  the section Information = About Captive
> Bypassing and how it describes how to avoid Apple captive portal
> detection!!! "If no response is received, then the Internet access = is
> assumed to be blocked by the captive portal and Apple=E2=80=99s = Captive Network
> Assistant (CNA) auto-launches the pseudo-browser to request portal = login in
> a controlled window. The CNA may break when redirecting to an ISE = captive
> portal. The controller prevents this pseudo-browser from popping = up."
>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>


= --Boundary_(ID_fkT6S1//At6VENOK84T78A)-- From nobody Fri Aug 18 17:52:25 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD17132408 for ; Fri, 18 Aug 2017 17:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 VlYikjEgBAiy for ; Fri, 18 Aug 2017 17:52:19 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61200132223 for ; Fri, 18 Aug 2017 17:52:19 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id o124so52807688qke.3 for ; Fri, 18 Aug 2017 17:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ti/mL/stEnGyh4H+v4Zd7JEYEJHZDWzA4ssjRbYqysQ=; b=bRMxfLEcyI9UESu+lboTqwf4O02uhlBQ74f8iJ2zrL9XTe5GfmleP4hEEzOuXKqTGQ dndYUX/OYv8CdWOzT1mPzvkI9hFkJ0G13re9WNHli4WKI20MCuU/Jxzi0wp43yqSgehS 5yl01Vhtb4A5wBhvsAQkiFEURZe1zBkeBjebrlfhzdASmXGwbtVHq+aedWD6Ywtyt3tL 8skJYzHQCl5xqrU0U8EkpYQICroMHDvquP7CiPnpGAUboYiF7Ecd/nwcGvJhnQgxR6uw yjMt9a22CrTiZAIsZA4jU59YVB+a0DOEOP734yiKtZ/YNhtv1Uhnl3ju8F12wFgtLz4S 0tCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ti/mL/stEnGyh4H+v4Zd7JEYEJHZDWzA4ssjRbYqysQ=; b=Ik/LozibXKts12U+bqeJsmtEDpe+kyRwnxPk/FakGYDcE/ig/ISNfDcR6luNavQBu8 5VrS2Vr6UBBhsdA3MWnJUWGZDSNvD3sWKTBmoGMXaxDzVByGjczXkOoEMQ1x59JOyzUy iA4e8jZ6qOhRogHGUbJgtWunpP+2kwGNNAz3aAQNTWCAR3ElRM2VFI7omo6QWRf8qfc1 W14hlZpP8MjPCUq2ZvCfWRxLI6iqzUIft2wWFYnSl1OTBmokvs0vyeECOtH22WZ3dBnz PZMfM/RGn5ZVtK1pvtKDQaptCc3xoOuBUrEuHeeabaG7udmbAIxUACseSG4Jf7tZS3Mq 9cug== X-Gm-Message-State: AHYfb5ikEMHwVsSQXQcIF3Jx4hrzcnCr7BXRXKGFqMn4mce6CWFAOp5I LfFmtZw10HUGGwmY1am3ZWROC5OdSx4O X-Received: by 10.55.198.25 with SMTP id b25mr4967998qkj.280.1503103938184; Fri, 18 Aug 2017 17:52:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.148.217 with HTTP; Fri, 18 Aug 2017 17:52:17 -0700 (PDT) In-Reply-To: References: From: David Bird Date: Fri, 18 Aug 2017 17:52:17 -0700 Message-ID: To: Tommy Pauly Cc: Erik Kline , captive-portals@ietf.org, "Eric Vyncke (evyncke)" Content-Type: multipart/alternative; boundary="001a11479ae84c41c3055710a880" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 00:52:23 -0000 --001a11479ae84c41c3055710a880 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Tommy, I don't dispute that PvD provides an elegant set of solutions -- particularly in enterprise and other 'private' networks. I question, however, the value in public(/guest) access -- where everyone wants you to access their network over others, for 'retail analytic' or branding/attribution(/exploit) purposes. Another way to see the PvD integration/deployment: 1. Today, we join a network, always do a probe, which redirects to captive portal 2. A PvD URL is provide, so a captive portal notification is generated to the user (is that what 'we just make a connection directly' means?) 3. We may have also gotten RFC7710 URL, there are potentially two APIs in play at the same time, which is extra confusing (?) 4. The first NAS vendor release products with support, venues deploy and start 'fiddling' with the new feature and URL to PvD end-points 5. The first UE vendor releases products with support, start using it at said venues... complain to vendor about problems unique to this new device 6. In some networks, users complain that *only* their new PvD device is seeing a captive portal, while all their other devices do not. Staff at the coffee shop don't believe me; all their devices work too. I think there are fundamental issues in splitting what should be 'network notification' into web APIs.... 1. Tomorrow, we join a network, always do a probe, which redirects to captive portal It wasn't clear in your e-mail if RFC7710 can be used *without* providing a URL, or is there a PvD specific DHCP option? Thanks, David On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly wrote: > Hi David, > > You mention in one of your emails that you'd expect there to be many > "broken PvD" deployments, which would either necessitate ignoring PvD and > using legacy mechanisms, or else having the user face a broken portal. My > impression is that if client-side deployments fail closed=E2=80=94that is= , if there > is a PvD advertised, but it does not work well, then we treat the network > as broken. If this client behavior is consistent from the start of > deployment, then I would think that deployments would notice very quickly > if they are broken. The fundamental part of the PvD being advertised is i= n > the RAs=E2=80=94if our DHCP or RAs are broken on a network, we generally = are going > to be broken anyhow. > > As far as where the API resides, I appreciate your explanation of the > various complexities. My initial take is this: > > - Where a PvD is being served is up to the deployment, and determined by > the entity that is providing the RAs. To that end, the server that hosts > the API for extended PvD information may be very different for > enterprise/carrier scenarios than in captive portals for coffee shops. > - For the initial take for Captive Portals, I would co-locate the "PvD > API" server with the "Captive API" and "Captive Web Server". Presumably, > the device that was previously doing the HTTP redirects would be able to = do > the similar coordination of making sure the PvD ID that is given out to > clients matches the PvD API server (which is the same as the "Captive Web > Server"). > > For the captive use-case, I see the integration of PvDs as an incremental > step: > > 1. Today, we join a network, always do a probe, which may get redirected > to a captive web server > 2. With RFC 7710, we would join a network and do the same as (1), unless > the captive URL is given in the DHCP/RA and we just make a connection > directly. > 3. With the Captive API draft, we can interact with the portal other than > just showing a webpage; but this may still be bootstrapped by 7710 if not > using another mechanism > 4. With PvDs, the mechanism in 7710 is generalized to support APIs other > than just captive, and can indicate that no captive portal or other > extended info is present; and the PvD API in this form is just a more > generic version of the captive API that allows us to use the same mechani= sm > for other network properties that aren't specifically captive (like > enterprise network extended info, or walled gardens) > > Getting into the arms race of people avoiding the captive probes: if > someone doesn't want to interact with the client OS's captive portal > system, they can and likely will not change anything and just keep > redirecting pages. Hopefully if a better solution becomes prevalent enoug= h > in the future, client OS's will be able to just ignore and reject any > network that redirects traffic, and the only supported captive portals > would be ones that interact in specified ways and advertise themselves as > captive networks. In order to get to this point, there certainly needs to > be a carrot to incentivize adoption. My goal with the more flexible > interaction supported by PvD is that we will allow the networks to provid= e > a better user experience to people joining their networks, and integrate > with client OS's to streamline the joining process (notification of the > network being available, who owns it, how to accept and how to pay), the > maintenance process (being able to integrate time left or bytes left on t= he > network into the system UI), and what is allowed or not on the network. > > Thanks, > Tommy > > > On Aug 16, 2017, at 6:51 AM, David Bird wrote: > > My question about where the PvD API resides was somewhat rhetorical. In > reality, I'm sure you will find all of the above - In the NAS (e.g. Cisco= ), > at the hotspot services provider, and something hosted next to the venues > website. It depends mostly on how this URL is configured, and by whom. (O= ne > could imagine people doing all sorts of things). > > My question more specifically for the authors is, how would Cisco > implement PvD for Guest/Public access and would it actively stop avoiding > Apple captive portal detection? Or, would turning on PvD just make that > 'feature' easier to implement? > > On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline wrote: > >> Randomly selecting Tommy and Eric so this bubbles up in their inbox. >> >> On 2 August 2017 at 10:36, David Bird wrote: >> > Could an author of PvD help me understand the following questions for >> each >> > of the diagrams below I found on the Internet -- which represent some >> > typical hotspot configurations out there... >> > >> > - Where would the API reside? >> > >> > - Who 'owns' the API? >> > >> > - How does the API keep in-sync with the NAS? Who's responsible for th= at >> > (possibly multi-vendor, multi-AAA) integration? >> > >> > 1) Typical Hotspot service company outsourcing: >> > http://cloudessa.com/wp-content/uploads/2013/08/shema-Captiv >> ePortalSolution_beta2b.png >> > >> > 2) Same as above, except venue owns portal: >> > http://cloudessa.com/wp-content/uploads/2013/07/solutions_ >> hotspots-co-working-cloudessa_2p1.png >> > >> > 3) Now consider the above, but the venue has more roaming partners and >> > multi-realm RADIUS setup in their Cisco NAS: >> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3 >> /config-guide/b_cg83/b_cg83_chapter_0100111.html >> > describes many options -- including separate MAC authentication source= s, >> > optional portals for 802.1x (RADIUS) authenticated users, and so much >> > more... >> > >> > "Cisco ISE supports internal and external identity sources. Both >> sources can >> > be used as an authentication source for sponsor-user and guest-user >> > authentication." >> > >> > Also note this interesting article: the section Information About >> Captive >> > Bypassing and how it describes how to avoid Apple captive portal >> > detection!!! "If no response is received, then the Internet access is >> > assumed to be blocked by the captive portal and Apple=E2=80=99s Captiv= e Network >> > Assistant (CNA) auto-launches the pseudo-browser to request portal >> login in >> > a controlled window. The CNA may break when redirecting to an ISE >> captive >> > portal. The controller prevents this pseudo-browser from popping up." >> > >> > >> > >> > _______________________________________________ >> > Captive-portals mailing list >> > Captive-portals@ietf.org >> > https://www.ietf.org/mailman/listinfo/captive-portals >> > >> > > > --001a11479ae84c41c3055710a880 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Tommy,

I don't dispute that = PvD provides an elegant set of solutions -- particularly in enterprise and = other 'private' networks. I question, however, the value in public(= /guest) access -- where everyone wants you to access their network over oth= ers, for 'retail analytic' or branding/attribution(/exploit) purpos= es.=C2=A0

Another way to see the PvD integration/d= eployment:

1. Today, we join a network, always do = a probe, which redirects to captive portal
2. A PvD URL is provid= e, so a captive portal notification is generated to the user (is that what = 'we just make a connection directly' means?)
3. We may ha= ve also gotten RFC7710 URL, there are potentially two APIs in play at the s= ame time, which is extra confusing (?)
4. The first NAS vendor re= lease products with support, venues deploy and start 'fiddling' wit= h the new feature and URL to PvD end-points
5. The first UE vendo= r releases products with support, start using it at said venues... complain= to vendor about problems unique to this new device
6. In some ne= tworks, users complain that *only* their new PvD device is seeing a captive= portal, while all their other devices do not. Staff at the coffee shop don= 't believe me; all their devices work too.

I think there are fundamental issues in splitting what should be 'net= work notification' into web APIs....

1. Tomorr= ow, we join a network, always do a probe, which redirects to captive portal=

It wasn't clear in your e-mail if RFC77= 10 can be used *without* providing a URL, or is there a PvD specific DHCP o= ption?

Thanks,
David

<= /div>

On Wed= , Aug 16, 2017 at 9:20 AM, Tommy Pauly <tpauly@apple.com> wro= te:
Hi David,

You mention in one= of your emails that you'd expect there to be many "broken PvD&quo= t; deployments, which would either necessitate ignoring PvD and using legac= y mechanisms, or else having the user face a broken portal. My impression i= s that if client-side deployments fail closed=E2=80=94that is, if there is = a PvD advertised, but it does not work well, then we treat the network as b= roken. If this client behavior is consistent from the start of deployment, = then I would think that deployments would notice very quickly if they are b= roken. The fundamental part of the PvD being advertised is in the RAs=E2=80= =94if our DHCP or RAs are broken on a network, we generally are going to be= broken anyhow.

As far as where the API resides, I= appreciate your explanation of the various complexities. My initial take i= s this:

- Where a PvD is being served is up to the= deployment, and determined by the entity that is providing the RAs. To tha= t end, the server that hosts the API for extended PvD information may be ve= ry different for enterprise/carrier scenarios than in captive portals for c= offee shops.
- For the initial take for Captive Portals, I would = co-locate the "PvD API" server with the "Captive API" a= nd "Captive Web Server". Presumably, the device that was previous= ly doing the HTTP redirects would be able to do the similar coordination of= making sure the PvD ID that is given out to clients matches the PvD API se= rver (which is the same as the "Captive Web Server").
<= br>
For the captive use-case, I see the integration of PvDs as an= incremental step:

1. Today, we join a network, al= ways do a probe, which may get redirected to a captive web server
2. With RFC 7710, we would join a network and do the same as (1), unless t= he captive URL is given in the DHCP/RA and we just make a connection direct= ly.
3. With the Captive API draft, we can interact with the porta= l other than just showing a webpage; but this may still be bootstrapped by = 7710 if not using another mechanism
4. With PvDs, the mechanism i= n 7710 is generalized to support APIs other than just captive, and can indi= cate that no captive portal or other extended info is present; and the PvD = API in this form is just a more generic version of the captive API that all= ows us to use the same mechanism for other network properties that aren'= ;t specifically captive (like enterprise network extended info, or walled g= ardens)

Getting into the arms race of people avoid= ing the captive probes: if someone doesn't want to interact with the cl= ient OS's captive portal system, they can and likely will not change an= ything and just keep redirecting pages. Hopefully if a better solution beco= mes prevalent enough in the future, client OS's will be able to just ig= nore and reject any network that redirects traffic, and the only supported = captive portals would be ones that interact in specified ways and advertise= themselves as captive networks. In order to get to this point, there certa= inly needs to be a carrot to incentivize adoption. My goal with the more fl= exible interaction supported by PvD is that we will allow the networks to p= rovide a better user experience to people joining their networks, and integ= rate with client OS's to streamline the joining process (notification o= f the network being available, who owns it, how to accept and how to pay), = the maintenance process (being able to integrate time left or bytes left on= the network into the system UI), and what is allowed or not on the network= .

Thanks,
Tommy

On Aug 16, 2017, at 6:51 AM, Davi= d Bird <dbird@goog= le.com> wrote:

My question about where the PvD API res= ides was somewhat rhetorical. In reality, I'm sure you will find all of= the above - In the NAS (e.g. Cisco), at the hotspot services provider, and= something hosted next to the venues website. It depends mostly on how this= URL is configured, and by whom. (One could imagine people doing all sorts = of things).=C2=A0

My question more specifically for the = authors is, how would Cisco implement PvD for Guest/Public access and would= it actively stop avoiding Apple captive portal detection? Or, would turnin= g on PvD just make that 'feature' easier to implement?
<= div class=3D"gmail_extra">
On Tue, Aug 15, 20= 17 at 5:19 PM, Erik Kline <ek@google.com> wrote:
Randomly selecting Tommy and Eric so this bubbles up in = their inbox.

On 2 August 2017 at 10:36, David Bird <dbird@google.com> wrote:
> Could an author of PvD help me understand the following questions for = each
> of the diagrams below I found on the Internet -- which represent some<= br> > typical hotspot configurations out there...
>
> - Where would the API reside?
>
> - Who 'owns' the API?
>
> - How does the API keep in-sync with the NAS? Who's responsible fo= r that
> (possibly multi-vendor, multi-AAA) integration?
>
> 1) Typical Hotspot service company outsourcing:
> http://cl= oudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolutio= n_beta2b.png
>
> 2) Same as above, except venue owns portal:
> = http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspot= s-co-working-cloudessa_2p1.png
>
> 3) Now consider the above, but the venue has more roaming partners and=
> multi-realm RADIUS setup in their Cisco NAS:
> http://www.cisco.com/c/en/us/td/docs/wireless/controller/= 8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html
> describes many options -- including separate MAC authentication source= s,
> optional portals for 802.1x (RADIUS) authenticated users, and so much<= br> > more...
>
> "Cisco ISE supports internal and external identity sources. Both = sources can
> be used as an authentication source for sponsor-user and guest-user > authentication."
>
> Also note this interesting article:=C2=A0 the section Information Abou= t Captive
> Bypassing and how it describes how to avoid Apple captive portal
> detection!!! "If no response is received, then the Internet acces= s is
> assumed to be blocked by the captive portal and Apple=E2=80=99s Captiv= e Network
> Assistant (CNA) auto-launches the pseudo-browser to request portal log= in in
> a controlled window. The CNA may break when redirecting to an ISE capt= ive
> portal. The controller prevents this pseudo-browser from popping up.&q= uot;
>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-= portals@ietf.org
> https://www.ietf.org/mailman/listinf= o/captive-portals
>


--001a11479ae84c41c3055710a880-- From nobody Fri Aug 18 19:23:14 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2AA132472 for ; Fri, 18 Aug 2017 19:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 vTdhMsocQLSx for ; Fri, 18 Aug 2017 19:23:08 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FFE81243F6 for ; Fri, 18 Aug 2017 19:23:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1503109387; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HvO6D5Mf9XbB8U5UtElb45I7O6G8ezFmyZm4bq2CX1I=; b=HkThUJih1nI4YaiQgb8o+Sn1b6YOWHfAiE08wdCj19QBh4OViBMz7gASFtvZHpF0 wAqNqwg5xDbTI5YjPM07HRak8KMMW6Er4hhq4P/+3aIiJoegepQ63WFa0hK54Nfx IzKSm49m2qFh63hRudFeFr+v90Q8Vgr4pVHE8EAb8QdGaIqe6dozaj4h5Qnjkv2P uPAiSmXShG9+CCqoE6bM15yxlNffF+At2jPCYVp3GETbtIEHuUN1vaHBvLdpDp9Z zRL3fxUZ0R0isNAMY8zpaLClog1ViH1ydNw02Xz2XTYFgEFBTqtGluVMOKsn6VHH +mOGfG2ZXsPUWfmJP/aFDA==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id CF.E2.29949.B01A7995; Fri, 18 Aug 2017 19:23:07 -0700 (PDT) X-AuditID: 11973e12-5e5ff700000074fd-9d-5997a10b953f Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay2.apple.com (Apple SCV relay) with SMTP id 5B.62.09069.B01A7995; Fri, 18 Aug 2017 19:23:07 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_F/9sHGfh8bUvGIIWAfADPg)" Received: from [17.234.96.37] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OUW006N0UMGPI40@nwk-mmpp-sz10.apple.com>; Fri, 18 Aug 2017 19:23:07 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> Date: Fri, 18 Aug 2017 19:23:04 -0700 In-reply-to: Cc: Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org To: David Bird References: X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUi2FDorMu9cHqkwaUvxhZzZzWwWnz6sZ3R 4vPteewWX/YvYHRg8ZjyeyOrx4JNpR5LlvxkCmCO4rJJSc3JLEst0rdL4Mp49OsAW8H0z4wV j9v+MDYw3jvF2MXIySEhYCJxeXczWxcjF4eQwGomiR/rdrB2MXKAJba2ekLEDzFKtH/qZwZp 4BUQlPgx+R4LiM0sECZxunM3I0TRF0aJrkvPwZqFBSQkNu9JBKlhE1CROP5tA1SvjcTajT+Y QGxhATOJPU0fwGwWAVWJG2uPgtVwCgRLnPvSzQYxP11iz/mzYLaIgKLEqWvHmSB23WKSOPCi kQniUFmJpX9CQOISApPZJRa17GeZwCg0C8mts5DcOguohVlAXWLKlFyIsLbEk3cXWCFsNYmF vxcxIYsvYGRbxSiUm5iZo5uZZ6KXWFCQk6qXnJ+7iREUKdPthHYwnlpldYhRgINRiYf3xc9p kUKsiWXFlbmHGKU5WJTEeS/aAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwss2sL/BSFVJ9 ErA3+GDAjWMr3n08/OXf58ehfdwHj3HyXFX7KclmOoX9VphBxIWLm0Ub/985qJjwc30gb/PH rat9VLbunj7/vIOXrk2bumT/vPNf159Yssez+NQ3tr31Mvs+C7IXha+0ejNFKqN9W/E2BQMG RoXbZ9cKTn53RXSylPfqWCcGASWW4oxEQy3mouJEAMmTK+J1AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUi2FBcpcu9cHqkwdMuPYu5sxpYLT792M5o 8fn2PHaLL/sXMDqweEz5vZHVY8GmUo8lS34yBTBHWduk5ReVJxalKBQlF5TYKhVnJKbkl8db GhuZOiQWFOSk6iXn5yrp29mkpOZklqUWIbMSrDMe/TrAVjD9M2PF47Y/jA2M904xdjFycEgI mEhsbfXsYuTiEBI4xCjR/qmfuYuRk4NXQFDix+R7LCA2s0CYxOnO3YwQRV8YJbouPWcFaRYW kJDYvCcRpIZNQEXi+LcNUL02Ems3/mACsYUFzCT2NH0As1kEVCVurD0KVsMpECxx7ks3G8T8 dIk958+C2SICihKnrh1ngth1i0niwItGJohDZSWW/gmZwMg/C8l5s5CcNwuoillAXWLKlFyI sLbEk3cXWCFsNYmFvxcxIYsvYGRbxShQlJqTWGmkBw+/TYzg2Cl03sF4bJnVIUYBDkYlHt4X P6dFCrEmlhVX5gLDiINZSYSXLXB6pBBvSmJlVWpRfnxRaU5q8SHG/YxAT05klhJNzgdGdl5J vKGxhbGliYWBgYmlmQlhYRMTAxNjYzNjY3MTc1oKK4nzyhRNjhQSSE8sSc1OTS1ILYJ5gYmD U6qBUanD5tPXSZfOrW8XET5e3PnO2enPN5MTW2dOWHQ7w0/chkmRVy/+SQHjI9/n/Susvpfb p69Z7/FcofpVwovldg525YF3azrd7h5nZ/d0sJHkcQjPX/t75vEHmm3rjvO9zZrT9fl6EZ/l 62dm7pdELA7prapzv/TriWPHi4IQnwVqhTXNjTEdSizA1G2oxVxUnAgAOQGEtD4DAAA= Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 02:23:12 -0000 --Boundary_(ID_F/9sHGfh8bUvGIIWAfADPg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi David, My thoughts with regards to RFC 7710 is that it is not deployed as far = as I know, and no client stack respects the value sent in 7710. Without = some API extensions, it isn't directly better than what we currently = have. Ideally, this would not be an API that would get deployed if we = were also using PvDs. My concern is that if PvDs are used for enterprise = and private networks, we'll have a very similar but less complete path = based on RFC 7710. We could end up deprecating or replacing that RFC, = which was mentioned in our last meeting. I don't think RFC 7710 can be = used without a URL, which is why I think we need a solution that does a = better job of indicating the lack of captive or other extended network = info. I would hope that since both iOS and Android stack developers are = working on the UE side, we would actually see UE deployment of PvDs = before any captive vendors adopt PvDs, and we'd be standardizing around = Cisco/etc enterprise deployments. By the time there were NAS vendors = deploying, they would test with both iOS and Android devices to validate = support. Basing our standards on the idea that devices (either networks or UE's) = may implement the RFCs incorrectly seems to be a difficult starting = point. I like the point you bring up of splitting network notifications from = web APIs. There is a need to be judicious about what properties fall = into each category. I think you're saying that the fact that there is a = captive network can be signaled via ICMP, etc, as a network-level = property. While ICMP is a fine solution for giving the UE hints when = something has expired, I am concerned that (possibly unsolicited) = network signaling is not the correct mechanism for the content details = of the network, whether that is the enterprise network properties, or = the captive network Terms & Conditions, tokens, expiration timers, and = URLs for various kinds of user interaction. An JSON API is one form of = grabbing information=E2=80=94I don't think we should necessarily = interpret that as something that is a high-level Web interaction. We = could create some custom protocol over UDP like DNS records to get the = information (that would be a lot of new protocol work here that people = may not be willing to get into), but the key is that it needs to be the = choice of a UE device that understands how to request and parse content = that initiates a lookup, and can fetch information from the network = infrastructure. With regards to your assertion that we'll always revert to doing a = probe, I still would like to believe that if we have a network that = advertises a PvD with no extended information, or extended information = that doesn't include a captive portal, we can avoid the probe = altogether. Will we still have networks that redirect HTTP requests? = Yes. But that's no different from the scenario today in which a network = whitelists our captive detection probes. We can still get to a captive = portal once the user goes into the browser. We can stop doing probes = whenever the RA on the network indicates that it supports explicit = signaling about network properties. If a network operator wants to = invoke the system-level captive interaction, then they will follow the = RFCs we come up in the CAPPORT group as long as UEs end up deploying = support first. If they want to avoid it, or they have a broken network, = things will be like networks that whitelist our probes today. Not great, = but still possible for the user to get through. My main goal in these = standards is to make it possible for a network to give the user a good = experience; not to make it impossible for the user to have a sub-par = experience (since I don't think that goal is achievable). Best, Tommy=20 > On Aug 18, 2017, at 5:52 PM, David Bird wrote: >=20 > Thanks Tommy, >=20 > I don't dispute that PvD provides an elegant set of solutions -- = particularly in enterprise and other 'private' networks. I question, = however, the value in public(/guest) access -- where everyone wants you = to access their network over others, for 'retail analytic' or = branding/attribution(/exploit) purposes.=20 >=20 > Another way to see the PvD integration/deployment: >=20 > 1. Today, we join a network, always do a probe, which redirects to = captive portal > 2. A PvD URL is provide, so a captive portal notification is generated = to the user (is that what 'we just make a connection directly' means?) > 3. We may have also gotten RFC7710 URL, there are potentially two APIs = in play at the same time, which is extra confusing (?) > 4. The first NAS vendor release products with support, venues deploy = and start 'fiddling' with the new feature and URL to PvD end-points > 5. The first UE vendor releases products with support, start using it = at said venues... complain to vendor about problems unique to this new = device > 6. In some networks, users complain that *only* their new PvD device = is seeing a captive portal, while all their other devices do not. Staff = at the coffee shop don't believe me; all their devices work too. >=20 > I think there are fundamental issues in splitting what should be = 'network notification' into web APIs.... >=20 > 1. Tomorrow, we join a network, always do a probe, which redirects to = captive portal >=20 > It wasn't clear in your e-mail if RFC7710 can be used *without* = providing a URL, or is there a PvD specific DHCP option? >=20 > Thanks, > David >=20 >=20 > On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly > wrote: > Hi David, >=20 > You mention in one of your emails that you'd expect there to be many = "broken PvD" deployments, which would either necessitate ignoring PvD = and using legacy mechanisms, or else having the user face a broken = portal. My impression is that if client-side deployments fail = closed=E2=80=94that is, if there is a PvD advertised, but it does not = work well, then we treat the network as broken. If this client behavior = is consistent from the start of deployment, then I would think that = deployments would notice very quickly if they are broken. The = fundamental part of the PvD being advertised is in the RAs=E2=80=94if = our DHCP or RAs are broken on a network, we generally are going to be = broken anyhow. >=20 > As far as where the API resides, I appreciate your explanation of the = various complexities. My initial take is this: >=20 > - Where a PvD is being served is up to the deployment, and determined = by the entity that is providing the RAs. To that end, the server that = hosts the API for extended PvD information may be very different for = enterprise/carrier scenarios than in captive portals for coffee shops. > - For the initial take for Captive Portals, I would co-locate the "PvD = API" server with the "Captive API" and "Captive Web Server". Presumably, = the device that was previously doing the HTTP redirects would be able to = do the similar coordination of making sure the PvD ID that is given out = to clients matches the PvD API server (which is the same as the "Captive = Web Server"). >=20 > For the captive use-case, I see the integration of PvDs as an = incremental step: >=20 > 1. Today, we join a network, always do a probe, which may get = redirected to a captive web server > 2. With RFC 7710, we would join a network and do the same as (1), = unless the captive URL is given in the DHCP/RA and we just make a = connection directly. > 3. With the Captive API draft, we can interact with the portal other = than just showing a webpage; but this may still be bootstrapped by 7710 = if not using another mechanism > 4. With PvDs, the mechanism in 7710 is generalized to support APIs = other than just captive, and can indicate that no captive portal or = other extended info is present; and the PvD API in this form is just a = more generic version of the captive API that allows us to use the same = mechanism for other network properties that aren't specifically captive = (like enterprise network extended info, or walled gardens) >=20 > Getting into the arms race of people avoiding the captive probes: if = someone doesn't want to interact with the client OS's captive portal = system, they can and likely will not change anything and just keep = redirecting pages. Hopefully if a better solution becomes prevalent = enough in the future, client OS's will be able to just ignore and reject = any network that redirects traffic, and the only supported captive = portals would be ones that interact in specified ways and advertise = themselves as captive networks. In order to get to this point, there = certainly needs to be a carrot to incentivize adoption. My goal with the = more flexible interaction supported by PvD is that we will allow the = networks to provide a better user experience to people joining their = networks, and integrate with client OS's to streamline the joining = process (notification of the network being available, who owns it, how = to accept and how to pay), the maintenance process (being able to = integrate time left or bytes left on the network into the system UI), = and what is allowed or not on the network. >=20 > Thanks, > Tommy >=20 >=20 >> On Aug 16, 2017, at 6:51 AM, David Bird > wrote: >>=20 >> My question about where the PvD API resides was somewhat rhetorical. = In reality, I'm sure you will find all of the above - In the NAS (e.g. = Cisco), at the hotspot services provider, and something hosted next to = the venues website. It depends mostly on how this URL is configured, and = by whom. (One could imagine people doing all sorts of things).=20 >>=20 >> My question more specifically for the authors is, how would Cisco = implement PvD for Guest/Public access and would it actively stop = avoiding Apple captive portal detection? Or, would turning on PvD just = make that 'feature' easier to implement? >>=20 >> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline > wrote: >> Randomly selecting Tommy and Eric so this bubbles up in their inbox. >>=20 >> On 2 August 2017 at 10:36, David Bird > wrote: >> > Could an author of PvD help me understand the following questions = for each >> > of the diagrams below I found on the Internet -- which represent = some >> > typical hotspot configurations out there... >> > >> > - Where would the API reside? >> > >> > - Who 'owns' the API? >> > >> > - How does the API keep in-sync with the NAS? Who's responsible for = that >> > (possibly multi-vendor, multi-AAA) integration? >> > >> > 1) Typical Hotspot service company outsourcing: >> > = http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolutio= n_beta2b.png = >> > >> > 2) Same as above, except venue owns portal: >> > = http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspots-co-work= ing-cloudessa_2p1.png = >> > >> > 3) Now consider the above, but the venue has more roaming partners = and >> > multi-realm RADIUS setup in their Cisco NAS: >> > = http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/= b_cg83/b_cg83_chapter_0100111.html = >> > describes many options -- including separate MAC authentication = sources, >> > optional portals for 802.1x (RADIUS) authenticated users, and so = much >> > more... >> > >> > "Cisco ISE supports internal and external identity sources. Both = sources can >> > be used as an authentication source for sponsor-user and guest-user >> > authentication." >> > >> > Also note this interesting article: the section Information About = Captive >> > Bypassing and how it describes how to avoid Apple captive portal >> > detection!!! "If no response is received, then the Internet access = is >> > assumed to be blocked by the captive portal and Apple=E2=80=99s = Captive Network >> > Assistant (CNA) auto-launches the pseudo-browser to request portal = login in >> > a controlled window. The CNA may break when redirecting to an ISE = captive >> > portal. The controller prevents this pseudo-browser from popping = up." >> > >> > >> > >> > _______________________________________________ >> > Captive-portals mailing list >> > Captive-portals@ietf.org >> > https://www.ietf.org/mailman/listinfo/captive-portals = >> > >>=20 >=20 >=20 > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals --Boundary_(ID_F/9sHGfh8bUvGIIWAfADPg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = David,

My thoughts = with regards to RFC 7710 is that it is not deployed as far as I know, = and no client stack respects the value sent in 7710. Without some API = extensions, it isn't directly better than what we currently have. = Ideally, this would not be an API that would get deployed if we were = also using PvDs. My concern is that if PvDs are used for enterprise and = private networks, we'll have a very similar but less complete path based = on RFC 7710. We could end up deprecating or replacing that RFC, which = was mentioned in our last meeting. I don't think RFC 7710 can be used = without a URL, which is why I think we need a solution that does a = better job of indicating the lack of captive or other extended network = info.

I would = hope that since both iOS and Android stack developers are working on the = UE side, we would actually see UE deployment of PvDs before any captive = vendors adopt PvDs, and we'd be standardizing around Cisco/etc = enterprise deployments. By the time there were NAS vendors deploying, = they would test with both iOS and Android devices to validate = support.

Basing = our standards on the idea that devices (either networks or UE's) may = implement the RFCs incorrectly seems to be a difficult starting = point.

I like = the point you bring up of splitting network notifications from web APIs. = There is a need to be judicious about what properties fall into each = category. I think you're saying that the fact that there is a captive = network can be signaled via ICMP, etc, as a network-level property. = While ICMP is a fine solution for giving the UE hints when something has = expired, I am concerned that (possibly unsolicited) network signaling is = not the correct mechanism for the content details of the network, = whether that is the enterprise network properties, or the captive = network Terms & Conditions, tokens, expiration timers, and URLs for = various kinds of user interaction. An JSON API is one form of grabbing = information=E2=80=94I don't think we should necessarily interpret that = as something that is a high-level Web interaction. We could create some = custom protocol over UDP like DNS records to get the information (that = would be a lot of new protocol work here that people may not be willing = to get into), but the key is that it needs to be the choice of a UE = device that understands how to request and parse content that initiates = a lookup, and can fetch information from the network = infrastructure.

With regards to your assertion that we'll always revert to = doing a probe, I still would like to believe that if we have a network = that advertises a PvD with no extended information, or extended = information that doesn't include a captive portal, we can avoid the = probe altogether. Will we still have networks that redirect HTTP = requests? Yes. But that's no different from the scenario today in which = a network whitelists our captive detection probes. We can still get to a = captive portal once the user goes into the browser. We can stop doing = probes whenever the RA on the network indicates that it supports = explicit signaling about network properties. If a network operator wants = to invoke the system-level captive interaction, then they will follow = the RFCs we come up in the CAPPORT group as long as UEs end up deploying = support first. If they want to avoid it, or they have a broken network, = things will be like networks that whitelist our probes today. Not great, = but still possible for the user to get through. My main goal in these = standards is to make it possible for a network to give the user a good = experience; not to make it impossible for the user to have a sub-par = experience (since I don't think that goal is achievable).

Best,
Tommy 

On Aug 18, 2017, at 5:52 PM, = David Bird <dbird@google.com> wrote:

Thanks Tommy,

I don't dispute that PvD provides an elegant set of solutions = -- particularly in enterprise and other 'private' networks. I question, = however, the value in public(/guest) access -- where everyone wants you = to access their network over others, for 'retail analytic' or = branding/attribution(/exploit) purposes. 

Another way to see the PvD = integration/deployment:

1. Today, we join a network, always do a probe, which = redirects to captive portal
2. A PvD URL is = provide, so a captive portal notification is generated to the user (is = that what 'we just make a connection directly' means?)
3. We may have also gotten RFC7710 URL, there are potentially = two APIs in play at the same time, which is extra confusing = (?)
4. The first NAS vendor release products with = support, venues deploy and start 'fiddling' with the new feature and URL = to PvD end-points
5. The first UE vendor releases = products with support, start using it at said venues... complain to = vendor about problems unique to this new device
6. = In some networks, users complain that *only* their new PvD device is = seeing a captive portal, while all their other devices do not. Staff at = the coffee shop don't believe me; all their devices work too.

I think = there are fundamental issues in splitting what should be 'network = notification' into web APIs....

1. Tomorrow, we join a network, always = do a probe, which redirects to captive portal

It wasn't clear in your = e-mail if RFC7710 can be used *without* providing a URL, or is there a = PvD specific DHCP option?

Thanks,
David


On Wed, = Aug 16, 2017 at 9:20 AM, Tommy Pauly <tpauly@apple.com> wrote:
Hi = David,

You mention = in one of your emails that you'd expect there to be many "broken PvD" = deployments, which would either necessitate ignoring PvD and using = legacy mechanisms, or else having the user face a broken portal. My = impression is that if client-side deployments fail closed=E2=80=94that = is, if there is a PvD advertised, but it does not work well, then we = treat the network as broken. If this client behavior is consistent from = the start of deployment, then I would think that deployments would = notice very quickly if they are broken. The fundamental part of the PvD = being advertised is in the RAs=E2=80=94if our DHCP or RAs are broken on = a network, we generally are going to be broken anyhow.

As far as where the API = resides, I appreciate your explanation of the various complexities. My = initial take is this:

- Where a PvD is being served is up to the deployment, and = determined by the entity that is providing the RAs. To that end, the = server that hosts the API for extended PvD information may be very = different for enterprise/carrier scenarios than in captive portals for = coffee shops.
- For the initial take for Captive = Portals, I would co-locate the "PvD API" server with the "Captive API" = and "Captive Web Server". Presumably, the device that was previously = doing the HTTP redirects would be able to do the similar coordination of = making sure the PvD ID that is given out to clients matches the PvD API = server (which is the same as the "Captive Web Server").

For the captive = use-case, I see the integration of PvDs as an incremental = step:

1. = Today, we join a network, always do a probe, which may get redirected to = a captive web server
2. With RFC 7710, we would = join a network and do the same as (1), unless the captive URL is given = in the DHCP/RA and we just make a connection directly.
3. With the Captive API draft, we can interact with the = portal other than just showing a webpage; but this may still be = bootstrapped by 7710 if not using another mechanism
4. With PvDs, the mechanism in 7710 is generalized to support = APIs other than just captive, and can indicate that no captive portal or = other extended info is present; and the PvD API in this form is just a = more generic version of the captive API that allows us to use the same = mechanism for other network properties that aren't specifically captive = (like enterprise network extended info, or walled gardens)

Getting into the arms = race of people avoiding the captive probes: if someone doesn't want to = interact with the client OS's captive portal system, they can and likely = will not change anything and just keep redirecting pages. Hopefully if a = better solution becomes prevalent enough in the future, client OS's will = be able to just ignore and reject any network that redirects traffic, = and the only supported captive portals would be ones that interact in = specified ways and advertise themselves as captive networks. In order to = get to this point, there certainly needs to be a carrot to incentivize = adoption. My goal with the more flexible interaction supported by PvD is = that we will allow the networks to provide a better user experience to = people joining their networks, and integrate with client OS's to = streamline the joining process (notification of the network being = available, who owns it, how to accept and how to pay), the maintenance = process (being able to integrate time left or bytes left on the network = into the system UI), and what is allowed or not on the = network.

Thanks,
Tommy


On Aug 16, 2017, at 6:51 AM, = David Bird <dbird@google.com> wrote:

My question about where the PvD = API resides was somewhat rhetorical. In reality, I'm sure you will find = all of the above - In the NAS (e.g. Cisco), at the hotspot services = provider, and something hosted next to the venues website. It depends = mostly on how this URL is configured, and by whom. (One could imagine = people doing all sorts of things). 

My question more specifically for the = authors is, how would Cisco implement PvD for Guest/Public access and = would it actively stop avoiding Apple captive portal detection? Or, = would turning on PvD just make that 'feature' easier to = implement?

On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline <ek@google.com> wrote:
Randomly selecting = Tommy and Eric so this bubbles up in their inbox.

On 2 August 2017 at 10:36, David Bird <dbird@google.com> wrote:
> Could an author of PvD help me understand the following questions = for each
> of the diagrams below I found on the Internet -- which represent = some
> typical hotspot configurations out there...
>
> - Where would the API reside?
>
> - Who 'owns' the API?
>
> - How does the API keep in-sync with the NAS? Who's responsible for = that
> (possibly multi-vendor, multi-AAA) integration?
>
> 1) Typical Hotspot service company outsourcing:
> http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolution_beta2b.png
>
> 2) Same as above, except venue owns portal:
> http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspots-co-working-cloudessa_2p1.png
>
> 3) Now consider the above, but the venue has more roaming partners = and
> multi-realm RADIUS setup in their Cisco NAS:
> http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html
> describes many options -- including separate MAC authentication = sources,
> optional portals for 802.1x (RADIUS) authenticated users, and so = much
> more...
>
> "Cisco ISE supports internal and external identity sources. Both = sources can
> be used as an authentication source for sponsor-user and = guest-user
> authentication."
>
> Also note this interesting article:  the section Information = About Captive
> Bypassing and how it describes how to avoid Apple captive portal
> detection!!! "If no response is received, then the Internet access = is
> assumed to be blocked by the captive portal and Apple=E2=80=99s = Captive Network
> Assistant (CNA) auto-launches the pseudo-browser to request portal = login in
> a controlled window. The CNA may break when redirecting to an ISE = captive
> portal. The controller prevents this pseudo-browser from popping = up."
>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>



_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

= --Boundary_(ID_F/9sHGfh8bUvGIIWAfADPg)-- From nobody Sat Aug 19 07:12:31 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12632132822 for ; Sat, 19 Aug 2017 07:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RpnxofriWGHw for ; Sat, 19 Aug 2017 07:12:27 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C195D13281F for ; Sat, 19 Aug 2017 07:12:26 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id a77so65668450qkb.0 for ; Sat, 19 Aug 2017 07:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tYG02dPbNJG1VuLgHqhU1AcGoJxCzhkOMyibKZxLk+g=; b=C3csmEUipObsGe7pE1WP9IcPKRSMKQ7ahK1tCB5ra/6wa+jMek+npLWSRC/B2d8p29 KF1tA4dKvXxXW6dsLKSkvGA9gaVdibt0UnlqqcHSOGEGUshH9DNETVyNCny5dtaHqVnw CWGqKpiLNmbjDTdPYjgG06v6cURen3augwusQ3YsUq829BdBWIFlWcWRk6IGOwiTnZeE lWaTv5spNmhNKtEoIQg78YaPzhAJ8MyOj2YIEI5L2E6gIfnxoccL7VSlFDNzHAVV8Ttw QeY0+T8JrJg3/Q7RUWCG0orB6iPMcEPgtenUMkNMIfoR/WFhK4NuXXntGVkyaSnQbo5/ J3rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tYG02dPbNJG1VuLgHqhU1AcGoJxCzhkOMyibKZxLk+g=; b=hAucdpulpg8Rc33y+4OnLOAgE5SpBQNZlr+MMc1T/eTFFULsFXtLDCsngZtqJpgoIM Q5CHgmlqMuho2cY3oMNGg2gu1+YRPcCybPhYwNLn7rUkylir4XWPmh/ye3XjSgg7+oTg qUc1DsfZRcCKqJRlcy0lYdqVczgyWCiU/K1baX2OZoG5uDvtWy3FO1TmnIOCiqcrL87C TJpyISpCsEPKMB175Llmu0U+vcFFhnlMWnBcE/cyvJE2HReu/46emki5maRJ5Nz72w0R 0BHiMbc0V1yidTv6ZuUIcuuHY7wvoEFcAdij2cNAg4ycZolcaGI0AA7RUFDIi5+kRkDX k7Nw== X-Gm-Message-State: AHYfb5iatCSUv8CVpgLiFAuwICLnNVTDvZ3VYZxv/VZJGNNa/eZyUujp 1o1M9wsbRVkyw4ZHgu4rH61bzORe7U7/ X-Received: by 10.55.5.10 with SMTP id 10mr15360539qkf.343.1503151945489; Sat, 19 Aug 2017 07:12:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.148.217 with HTTP; Sat, 19 Aug 2017 07:12:24 -0700 (PDT) In-Reply-To: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> From: David Bird Date: Sat, 19 Aug 2017 07:12:24 -0700 Message-ID: To: Tommy Pauly Cc: Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org Content-Type: multipart/alternative; boundary="001a114c491ac1b6d205571bd546" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Aug 2017 14:12:30 -0000 --001a114c491ac1b6d205571bd546 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable HI Tommy, Agreed that RFC7710 is lacking notification of captive portal existence, it only provides configuration information. ICMP would provide the notification, as it does today for other forms of destination unreachable, port unreachable, etc. In your first reply, I thought you were suggesting that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clear what you meant by DHCP/RA). I think we both also agree that taking about both a Capport API *and* PvD is adding to the confusion and we ultimately will not want two "APIs". ICMP today delivers more than hints... it provides signaling that can directly influence traffic. Yes, there are security concerns around ICMP, which is why it is common for it to be filtered out of networks (which is a good think for Capport ICMP, it is only for the edge network). Regarding ICMP and the "content details of the network" ... I think that statement conflates policy and enforcement. ICMP provides (as today) notification of enforcement, and RFC7710 provides where to find out about the policy (ToS, etc). The JSON API becomes a "web service" when it has a http(s):// in front of it :) .. but, indeed, my concern is in the transport protocol. It being a URL signals that this is meant to be deployed alongside the portal, or otherwise 'remotely'... Vendors will likely have a "PvD URL: " configuration dialog ... and there will be many hotspot services companies updating their "Howto" instructions with their PvD URL info... it is a web service. I welcome suggestions that put that JSON API into a lower layer network protocol. We could stuff JSON into ICMP :) Maybe there is a way to merge ICMP and PvD -- to where ICMP provides the notification (with tokens) and PvD provides the policy (based on these tokens) (?) With regard to vendor (NAS/UE) cooperation, perhaps PvD could be a new start, but thus far (as my quote of Cisco documentation suggests), it is more about what users/venues want. Cisco already today actively avoids iOS captive portal detection because the "pseudo-browser" (as they call it) does work with their portal. That is a problem that could be solve today by Apple/Cisco, couldn't it? Just by not using the pseudo browser... introducing PvD doesn't resolve the core problem there, but does make it easier to avoid that pseudo browser. You also said "We can still get to a captive portal once the user goes into the browser." ... However, this is increasingly untrue as the work moves to https... So, doing this avoidance of detection will still be a problem. Cheers, David On Fri, Aug 18, 2017 at 7:23 PM, Tommy Pauly wrote: > Hi David, > > My thoughts with regards to RFC 7710 is that it is not deployed as far as > I know, and no client stack respects the value sent in 7710. Without some > API extensions, it isn't directly better than what we currently have. > Ideally, this would not be an API that would get deployed if we were also > using PvDs. My concern is that if PvDs are used for enterprise and privat= e > networks, we'll have a very similar but less complete path based on RFC > 7710. We could end up deprecating or replacing that RFC, which was > mentioned in our last meeting. I don't think RFC 7710 can be used without= a > URL, which is why I think we need a solution that does a better job of > indicating the lack of captive or other extended network info. > > I would hope that since both iOS and Android stack developers are working > on the UE side, we would actually see UE deployment of PvDs before any > captive vendors adopt PvDs, and we'd be standardizing around Cisco/etc > enterprise deployments. By the time there were NAS vendors deploying, the= y > would test with both iOS and Android devices to validate support. > > Basing our standards on the idea that devices (either networks or UE's) > may implement the RFCs incorrectly seems to be a difficult starting point= . > > I like the point you bring up of splitting network notifications from web > APIs. There is a need to be judicious about what properties fall into eac= h > category. I think you're saying that the fact that there is a captive > network can be signaled via ICMP, etc, as a network-level property. While > ICMP is a fine solution for giving the UE hints when something has expire= d, > I am concerned that (possibly unsolicited) network signaling is not the > correct mechanism for the content details of the network, whether that is > the enterprise network properties, or the captive network Terms & > Conditions, tokens, expiration timers, and URLs for various kinds of user > interaction. An JSON API is one form of grabbing information=E2=80=94I do= n't think > we should necessarily interpret that as something that is a high-level We= b > interaction. We could create some custom protocol over UDP like DNS recor= ds > to get the information (that would be a lot of new protocol work here tha= t > people may not be willing to get into), but the key is that it needs to b= e > the choice of a UE device that understands how to request and parse conte= nt > that initiates a lookup, and can fetch information from the network > infrastructure. > > With regards to your assertion that we'll always revert to doing a probe, > I still would like to believe that if we have a network that advertises a > PvD with no extended information, or extended information that doesn't > include a captive portal, we can avoid the probe altogether. Will we stil= l > have networks that redirect HTTP requests? Yes. But that's no different > from the scenario today in which a network whitelists our captive detecti= on > probes. We can still get to a captive portal once the user goes into the > browser. We can stop doing probes whenever the RA on the network indicate= s > that it supports explicit signaling about network properties. If a networ= k > operator wants to invoke the system-level captive interaction, then they > will follow the RFCs we come up in the CAPPORT group as long as UEs end u= p > deploying support first. If they want to avoid it, or they have a broken > network, things will be like networks that whitelist our probes today. No= t > great, but still possible for the user to get through. My main goal in > these standards is to make it possible for a network to give the user a > good experience; not to make it impossible for the user to have a sub-par > experience (since I don't think that goal is achievable). > > Best, > Tommy > > > On Aug 18, 2017, at 5:52 PM, David Bird wrote: > > Thanks Tommy, > > I don't dispute that PvD provides an elegant set of solutions -- > particularly in enterprise and other 'private' networks. I question, > however, the value in public(/guest) access -- where everyone wants you t= o > access their network over others, for 'retail analytic' or > branding/attribution(/exploit) purposes. > > Another way to see the PvD integration/deployment: > > 1. Today, we join a network, always do a probe, which redirects to captiv= e > portal > 2. A PvD URL is provide, so a captive portal notification is generated to > the user (is that what 'we just make a connection directly' means?) > 3. We may have also gotten RFC7710 URL, there are potentially two APIs in > play at the same time, which is extra confusing (?) > 4. The first NAS vendor release products with support, venues deploy and > start 'fiddling' with the new feature and URL to PvD end-points > 5. The first UE vendor releases products with support, start using it at > said venues... complain to vendor about problems unique to this new devic= e > 6. In some networks, users complain that *only* their new PvD device is > seeing a captive portal, while all their other devices do not. Staff at t= he > coffee shop don't believe me; all their devices work too. > > I think there are fundamental issues in splitting what should be 'network > notification' into web APIs.... > > 1. Tomorrow, we join a network, always do a probe, which redirects to > captive portal > > It wasn't clear in your e-mail if RFC7710 can be used *without* providing > a URL, or is there a PvD specific DHCP option? > > Thanks, > David > > > On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly wrote: > >> Hi David, >> >> You mention in one of your emails that you'd expect there to be many >> "broken PvD" deployments, which would either necessitate ignoring PvD an= d >> using legacy mechanisms, or else having the user face a broken portal. M= y >> impression is that if client-side deployments fail closed=E2=80=94that i= s, if there >> is a PvD advertised, but it does not work well, then we treat the networ= k >> as broken. If this client behavior is consistent from the start of >> deployment, then I would think that deployments would notice very quickl= y >> if they are broken. The fundamental part of the PvD being advertised is = in >> the RAs=E2=80=94if our DHCP or RAs are broken on a network, we generally= are going >> to be broken anyhow. >> >> As far as where the API resides, I appreciate your explanation of the >> various complexities. My initial take is this: >> >> - Where a PvD is being served is up to the deployment, and determined by >> the entity that is providing the RAs. To that end, the server that hosts >> the API for extended PvD information may be very different for >> enterprise/carrier scenarios than in captive portals for coffee shops. >> - For the initial take for Captive Portals, I would co-locate the "PvD >> API" server with the "Captive API" and "Captive Web Server". Presumably, >> the device that was previously doing the HTTP redirects would be able to= do >> the similar coordination of making sure the PvD ID that is given out to >> clients matches the PvD API server (which is the same as the "Captive We= b >> Server"). >> >> For the captive use-case, I see the integration of PvDs as an incrementa= l >> step: >> >> 1. Today, we join a network, always do a probe, which may get redirected >> to a captive web server >> 2. With RFC 7710, we would join a network and do the same as (1), unless >> the captive URL is given in the DHCP/RA and we just make a connection >> directly. >> 3. With the Captive API draft, we can interact with the portal other tha= n >> just showing a webpage; but this may still be bootstrapped by 7710 if no= t >> using another mechanism >> 4. With PvDs, the mechanism in 7710 is generalized to support APIs other >> than just captive, and can indicate that no captive portal or other >> extended info is present; and the PvD API in this form is just a more >> generic version of the captive API that allows us to use the same mechan= ism >> for other network properties that aren't specifically captive (like >> enterprise network extended info, or walled gardens) >> >> Getting into the arms race of people avoiding the captive probes: if >> someone doesn't want to interact with the client OS's captive portal >> system, they can and likely will not change anything and just keep >> redirecting pages. Hopefully if a better solution becomes prevalent enou= gh >> in the future, client OS's will be able to just ignore and reject any >> network that redirects traffic, and the only supported captive portals >> would be ones that interact in specified ways and advertise themselves a= s >> captive networks. In order to get to this point, there certainly needs t= o >> be a carrot to incentivize adoption. My goal with the more flexible >> interaction supported by PvD is that we will allow the networks to provi= de >> a better user experience to people joining their networks, and integrate >> with client OS's to streamline the joining process (notification of the >> network being available, who owns it, how to accept and how to pay), the >> maintenance process (being able to integrate time left or bytes left on = the >> network into the system UI), and what is allowed or not on the network. >> >> Thanks, >> Tommy >> >> >> On Aug 16, 2017, at 6:51 AM, David Bird wrote: >> >> My question about where the PvD API resides was somewhat rhetorical. In >> reality, I'm sure you will find all of the above - In the NAS (e.g. Cisc= o), >> at the hotspot services provider, and something hosted next to the venue= s >> website. It depends mostly on how this URL is configured, and by whom. (= One >> could imagine people doing all sorts of things). >> >> My question more specifically for the authors is, how would Cisco >> implement PvD for Guest/Public access and would it actively stop avoidin= g >> Apple captive portal detection? Or, would turning on PvD just make that >> 'feature' easier to implement? >> >> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline wrote: >> >>> Randomly selecting Tommy and Eric so this bubbles up in their inbox. >>> >>> On 2 August 2017 at 10:36, David Bird wrote: >>> > Could an author of PvD help me understand the following questions for >>> each >>> > of the diagrams below I found on the Internet -- which represent some >>> > typical hotspot configurations out there... >>> > >>> > - Where would the API reside? >>> > >>> > - Who 'owns' the API? >>> > >>> > - How does the API keep in-sync with the NAS? Who's responsible for >>> that >>> > (possibly multi-vendor, multi-AAA) integration? >>> > >>> > 1) Typical Hotspot service company outsourcing: >>> > http://cloudessa.com/wp-content/uploads/2013/08/shema-Captiv >>> ePortalSolution_beta2b.png >>> > >>> > 2) Same as above, except venue owns portal: >>> > http://cloudessa.com/wp-content/uploads/2013/07/solutions_ho >>> tspots-co-working-cloudessa_2p1.png >>> > >>> > 3) Now consider the above, but the venue has more roaming partners an= d >>> > multi-realm RADIUS setup in their Cisco NAS: >>> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3 >>> /config-guide/b_cg83/b_cg83_chapter_0100111.html >>> > describes many options -- including separate MAC authentication >>> sources, >>> > optional portals for 802.1x (RADIUS) authenticated users, and so much >>> > more... >>> > >>> > "Cisco ISE supports internal and external identity sources. Both >>> sources can >>> > be used as an authentication source for sponsor-user and guest-user >>> > authentication." >>> > >>> > Also note this interesting article: the section Information About >>> Captive >>> > Bypassing and how it describes how to avoid Apple captive portal >>> > detection!!! "If no response is received, then the Internet access is >>> > assumed to be blocked by the captive portal and Apple=E2=80=99s Capti= ve Network >>> > Assistant (CNA) auto-launches the pseudo-browser to request portal >>> login in >>> > a controlled window. The CNA may break when redirecting to an ISE >>> captive >>> > portal. The controller prevents this pseudo-browser from popping up." >>> > >>> > >>> > >>> > _______________________________________________ >>> > Captive-portals mailing list >>> > Captive-portals@ietf.org >>> > https://www.ietf.org/mailman/listinfo/captive-portals >>> > >>> >> >> >> > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > > --001a114c491ac1b6d205571bd546 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
HI Tommy,

Agreed that RFC7710 is lack= ing notification of captive portal existence, it only provides configuratio= n information. ICMP would provide the notification, as it does today for ot= her forms of destination unreachable, port unreachable, etc. In your first = reply, I thought you were suggesting that RFC7710 was at play along side Pv= D DHCP/RA (and I wasn't clear what you meant by DHCP/RA).

I think we both als= o agree that taking about both a Capport API *and* PvD is adding to the con= fusion and we ultimately will not want two "APIs".

ICMP today delivers = more than hints... it provides signaling that can directly influence traffi= c. Yes, there are security concerns around ICMP, which is why it is common = for it to be filtered out of networks (which is a good think for Capport IC= MP, it is only for the edge network).=C2=A0

Regarding ICMP and the "content details of the network"= ; ... I think that statement conflates policy and enforcement. ICMP provide= s (as today) notification of enforcement, and RFC7710 provides where to fin= d out about the policy (ToS, etc).

The JSON API becomes = a "web service" when it has a http(s):// in front of it :) .. but= , indeed, my concern is in the transport protocol. It being a URL signals t= hat this is meant to be deployed alongside the portal, or otherwise 're= motely'... Vendors will likely have a "PvD URL: " configurati= on dialog ... and there will be many hotspot services companies updating th= eir "Howto" instructions with their PvD URL info... it is a web s= ervice.

I welcome suggestions that put that JSON A= PI into a lower layer network protocol. We could stuff JSON into ICMP :)

Maybe there is a way to merge ICMP and PvD -- to= where ICMP provides the notification (with tokens) and PvD provides the po= licy (based on these tokens) (?)

With regard to ve= ndor (NAS/UE) cooperation, perhaps PvD could be a new start, but thus far (= as my quote of Cisco documentation suggests), it is more about what users/v= enues want. Cisco already today actively avoids iOS captive portal detectio= n because the "pseudo-browser" (as they call it) does work with t= heir portal. That is a problem that could be solve today by Apple/Cisco, co= uldn't it? Just by not using the pseudo browser... introducing PvD does= n't resolve the core problem there, but does make it easier to avoid th= at pseudo browser.

You also said "We can stil= l get to a captive portal once the user goes into the browser." ... Ho= wever, this is increasingly untrue as the work moves to https... So, doing = this avoidance of detection will still be a problem.

Cheers,
David

=C2=A0
On Fri, Aug 18, 2017 at 7:23 PM, Tommy Paul= y <tpauly@apple.com> wrote:
Hi David,

<= /div>
My thoughts with regards to RFC 7710 is that it is not deployed a= s far as I know, and no client stack respects the value sent in 7710. Witho= ut some API extensions, it isn't directly better than what we currently= have. Ideally, this would not be an API that would get deployed if we were= also using PvDs. My concern is that if PvDs are used for enterprise and pr= ivate networks, we'll have a very similar but less complete path based = on RFC 7710. We could end up deprecating or replacing that RFC, which was m= entioned in our last meeting. I don't think RFC 7710 can be used withou= t a URL, which is why I think we need a solution that does a better job of = indicating the lack of captive or other extended network info.
I would hope that since both iOS and Android stack developers = are working on the UE side, we would actually see UE deployment of PvDs bef= ore any captive vendors adopt PvDs, and we'd be standardizing around Ci= sco/etc enterprise deployments. By the time there were NAS vendors deployin= g, they would test with both iOS and Android devices to validate support.

Basing our standards on the idea that devices (eith= er networks or UE's) may implement the RFCs incorrectly seems to be a d= ifficult starting point.

I like the point you brin= g up of splitting network notifications from web APIs. There is a need to b= e judicious about what properties fall into each category. I think you'= re saying that the fact that there is a captive network can be signaled via= ICMP, etc, as a network-level property. While ICMP is a fine solution for = giving the UE hints when something has expired, I am concerned that (possib= ly unsolicited) network signaling is not the correct mechanism for the cont= ent details of the network, whether that is the enterprise network properti= es, or the captive network Terms & Conditions, tokens, expiration timer= s, and URLs for various kinds of user interaction. An JSON API is one form = of grabbing information=E2=80=94I don't think we should necessarily int= erpret that as something that is a high-level Web interaction. We could cre= ate some custom protocol over UDP like DNS records to get the information (= that would be a lot of new protocol work here that people may not be willin= g to get into), but the key is that it needs to be the choice of a UE devic= e that understands how to request and parse content that initiates a lookup= , and can fetch information from the network infrastructure.

=
With regards to your assertion that we'll always revert to d= oing a probe, I still would like to believe that if we have a network that = advertises a PvD with no extended information, or extended information that= doesn't include a captive portal, we can avoid the probe altogether. W= ill we still have networks that redirect HTTP requests? Yes. But that's= no different from the scenario today in which a network whitelists our cap= tive detection probes. We can still get to a captive portal once the user g= oes into the browser. We can stop doing probes whenever the RA on the netwo= rk indicates that it supports explicit signaling about network properties. = If a network operator wants to invoke the system-level captive interaction,= then they will follow the RFCs we come up in the CAPPORT group as long as = UEs end up deploying support first. If they want to avoid it, or they have = a broken network, things will be like networks that whitelist our probes to= day. Not great, but still possible for the user to get through. My main goa= l in these standards is to make it possible for a network to give the user = a good experience; not to make it impossible for the user to have a sub-par= experience (since I don't think that goal is achievable).
Best,
Tommy=C2=A0


On Aug 18, 2017, at 5:52 PM, David Bi= rd <dbird@google.c= om> wrote:

Thanks Tommy,

I don= 't dispute that PvD provides an elegant set of solutions -- particularl= y in enterprise and other 'private' networks. I question, however, = the value in public(/guest) access -- where everyone wants you to access th= eir network over others, for 'retail analytic' or branding/attribut= ion(/exploit) purposes.=C2=A0

Another way to see t= he PvD integration/deployment:

1. Today, we join a= network, always do a probe, which redirects to captive portal
2.= A PvD URL is provide, so a captive portal notification is generated to the= user (is that what 'we just make a connection directly' means?)
3. We may have also gotten RFC7710 URL, there are potentially two A= PIs in play at the same time, which is extra confusing (?)
4. The= first NAS vendor release products with support, venues deploy and start &#= 39;fiddling' with the new feature and URL to PvD end-points
5= . The first UE vendor releases products with support, start using it at sai= d venues... complain to vendor about problems unique to this new device
6. In some networks, users complain that *only* their new PvD device= is seeing a captive portal, while all their other devices do not. Staff at= the coffee shop don't believe me; all their devices work too.

I think there are fundamental issues in splitting wha= t should be 'network notification' into web APIs....

=
1. Tomorrow, we join a network, always do a probe, which redirec= ts to captive portal

It wasn't clear in = your e-mail if RFC7710 can be used *without* providing a URL, or is there a= PvD specific DHCP option?

Thanks,
D= avid


On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly <tpauly@apple.co= m> wrote:
Hi David,

You ment= ion in one of your emails that you'd expect there to be many "brok= en PvD" deployments, which would either necessitate ignoring PvD and u= sing legacy mechanisms, or else having the user face a broken portal. My im= pression is that if client-side deployments fail closed=E2=80=94that is, if= there is a PvD advertised, but it does not work well, then we treat the ne= twork as broken. If this client behavior is consistent from the start of de= ployment, then I would think that deployments would notice very quickly if = they are broken. The fundamental part of the PvD being advertised is in the= RAs=E2=80=94if our DHCP or RAs are broken on a network, we generally are g= oing to be broken anyhow.

As far as where the API = resides, I appreciate your explanation of the various complexities. My init= ial take is this:

- Where a PvD is being served is= up to the deployment, and determined by the entity that is providing the R= As. To that end, the server that hosts the API for extended PvD information= may be very different for enterprise/carrier scenarios than in captive por= tals for coffee shops.
- For the initial take for Captive Portals= , I would co-locate the "PvD API" server with the "Captive A= PI" and "Captive Web Server". Presumably, the device that wa= s previously doing the HTTP redirects would be able to do the similar coord= ination of making sure the PvD ID that is given out to clients matches the = PvD API server (which is the same as the "Captive Web Server").

For the captive use-case, I see the integration of = PvDs as an incremental step:

1. Today, we join a n= etwork, always do a probe, which may get redirected to a captive web server=
2. With RFC 7710, we would join a network and do the same as (1)= , unless the captive URL is given in the DHCP/RA and we just make a connect= ion directly.
3. With the Captive API draft, we can interact with= the portal other than just showing a webpage; but this may still be bootst= rapped by 7710 if not using another mechanism
4. With PvDs, the m= echanism in 7710 is generalized to support APIs other than just captive, an= d can indicate that no captive portal or other extended info is present; an= d the PvD API in this form is just a more generic version of the captive AP= I that allows us to use the same mechanism for other network properties tha= t aren't specifically captive (like enterprise network extended info, o= r walled gardens)

Getting into the arms race of pe= ople avoiding the captive probes: if someone doesn't want to interact w= ith the client OS's captive portal system, they can and likely will not= change anything and just keep redirecting pages. Hopefully if a better sol= ution becomes prevalent enough in the future, client OS's will be able = to just ignore and reject any network that redirects traffic, and the only = supported captive portals would be ones that interact in specified ways and= advertise themselves as captive networks. In order to get to this point, t= here certainly needs to be a carrot to incentivize adoption. My goal with t= he more flexible interaction supported by PvD is that we will allow the net= works to provide a better user experience to people joining their networks,= and integrate with client OS's to streamline the joining process (noti= fication of the network being available, who owns it, how to accept and how= to pay), the maintenance process (being able to integrate time left or byt= es left on the network into the system UI), and what is allowed or not on t= he network.

Thanks,
Tommy


<= div>On Aug 16, 2017, at 6:51 AM, David Bird <dbird@google.com> wrote:

My question about where the PvD API resides was = somewhat rhetorical. In reality, I'm sure you will find all of the abov= e - In the NAS (e.g. Cisco), at the hotspot services provider, and somethin= g hosted next to the venues website. It depends mostly on how this URL is c= onfigured, and by whom. (One could imagine people doing all sorts of things= ).=C2=A0

My question more specifically for the authors i= s, how would Cisco implement PvD for Guest/Public access and would it activ= ely stop avoiding Apple captive portal detection? Or, would turning on PvD = just make that 'feature' easier to implement?

On Tue, Aug 15, 2017 at 5:1= 9 PM, Erik Kline <ek@google.com> wrote:
Randomly selecting Tommy and Eric so this bubb= les up in their inbox.
On 2 August 2017 at 10:36, David Bird <dbird@google.com> wrote:
> Could an author of PvD help me understand the following questions for = each
> of the diagrams below I found on the Internet -- which represent some<= br> > typical hotspot configurations out there...
>
> - Where would the API reside?
>
> - Who 'owns' the API?
>
> - How does the API keep in-sync with the NAS? Who's responsible fo= r that
> (possibly multi-vendor, multi-AAA) integration?
>
> 1) Typical Hotspot service company outsourcing:
> http://cl= oudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalSolutio= n_beta2b.png
>
> 2) Same as above, except venue owns portal:
> = http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspot= s-co-working-cloudessa_2p1.png
>
> 3) Now consider the above, but the venue has more roaming partners and=
> multi-realm RADIUS setup in their Cisco NAS:
> http://www.cisco.com/c/en/us/td/docs/wireless/controller/= 8-3/config-guide/b_cg83/b_cg83_chapter_0100111.html
> describes many options -- including separate MAC authentication source= s,
> optional portals for 802.1x (RADIUS) authenticated users, and so much<= br> > more...
>
> "Cisco ISE supports internal and external identity sources. Both = sources can
> be used as an authentication source for sponsor-user and guest-user > authentication."
>
> Also note this interesting article:=C2=A0 the section Information Abou= t Captive
> Bypassing and how it describes how to avoid Apple captive portal
> detection!!! "If no response is received, then the Internet acces= s is
> assumed to be blocked by the captive portal and Apple=E2=80=99s Captiv= e Network
> Assistant (CNA) auto-launches the pseudo-browser to request portal log= in in
> a controlled window. The CNA may break when redirecting to an ISE capt= ive
> portal. The controller prevents this pseudo-browser from popping up.&q= uot;
>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-= portals@ietf.org
> https://www.ietf.org/mailman/listinf= o/captive-portals
>


_______________________________________________
Captive-portals mai= ling list
= Captive-portals@ietf.org
https://www.ietf.org/mailman/= listinfo/captive-portals


--001a114c491ac1b6d205571bd546-- From nobody Sun Aug 20 18:34:59 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD5B1323C7 for ; Sun, 20 Aug 2017 18:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8duyHG-DdWsE for ; Sun, 20 Aug 2017 18:34:56 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D082B131D19 for ; Sun, 20 Aug 2017 18:34:55 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id o196so1784638ioe.0 for ; Sun, 20 Aug 2017 18:34:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mqiZHpHqGMD4fVH/k0v+adDdeU+Dljr5YgThYh0L1ec=; b=LrE586/WtC2BmeOipDaeMpKlW+JO/4wSPLTetxRqMZBp78kIR9UxHjKXGB6mplmMdc eUaRXfMSFUD0SwuEuWJPiEmm/D1wNBg3bbAsi8M3TdRZIMhlTFUcZh41YyZaI3GNlCs/ S0Vcri9pFu+3ZTIy71nBTd9OPcFsYuNjn+oOWXf6MrfCguUPsbDkZ+7sDuWvG+ikX21T fjr/gQ+B29B1kEijC7U/RS+/yZ5uHzDsakVyL1BZ0VXrwbLhg2QYuWZV9xW5LqgmFpu4 sB3E1JXRazD3YWsEOco+5PoyCaxPkXZCl5k4T22CuhC7vTzp4ozZOisdUr8150ZWB+SA f7Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mqiZHpHqGMD4fVH/k0v+adDdeU+Dljr5YgThYh0L1ec=; b=r3M/E9gCBblJYGW5F3cuDrlG7lCadvTAOPg1/r57PMmAlQVSa4INL7dZG+tJSAaT1G Lbxk/aspS6eT1hSqz/lqTJcHD0nNN5cAHhVa6jXbq75KUsaPbeLLyfz1T34SHiGcpuRh VdCV+EL+AUz4D9N+D345va0iK9g144ycE1OYB8xzZ8584bRvnXgW8l2p4rPP5drxC4w5 3KqrwydbOj6YMQ2JulOwUhRKnjfD4MBjW5mRBCYcxJ0KJf0MgI7tcGuMydNMWx7tVf/d GDMN8OUcBFBm5Ol7ZFacszFTkf2yjl3oEjuQl97JWWW6hB5LdrIOQqKPZIj72iVrueMh TyIg== X-Gm-Message-State: AHYfb5jLV4v6KMGZOQQBuZUpiyGz2a3AipuME+2UJBmZ079FtXO11SjT kseeJLycWV7UvgLVUjBidUx2XdJDPA== X-Received: by 10.107.46.155 with SMTP id u27mr13906594iou.107.1503279294771; Sun, 20 Aug 2017 18:34:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Sun, 20 Aug 2017 18:34:54 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> From: Martin Thomson Date: Mon, 21 Aug 2017 11:34:54 +1000 Message-ID: To: David Bird Cc: Tommy Pauly , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Aug 2017 01:34:58 -0000 Hi David, Can you explain more about why you believe that a lower-layer protocol needs to be used? I remember a similar discussion about this about 10 years ago with GEOPRIV. Then it was asserted that DHCP was the only protocol that could deliver location information to user equipment. That discussion took a long time, but ultimately ended with an HTTP-based protocol. I have no desire to repeat that experience. It seems like this is - at least in part - based in how this might be configured. That is, you believe that a lower-layer protocol offers no option for misconfiguration. Is that correct? Have I missed something? On 20 August 2017 at 00:12, David Bird wrote: > HI Tommy, > > Agreed that RFC7710 is lacking notification of captive portal existence, = it > only provides configuration information. ICMP would provide the > notification, as it does today for other forms of destination unreachable= , > port unreachable, etc. In your first reply, I thought you were suggesting > that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clear what = you > meant by DHCP/RA). > > I think we both also agree that taking about both a Capport API *and* PvD= is > adding to the confusion and we ultimately will not want two "APIs". > > ICMP today delivers more than hints... it provides signaling that can > directly influence traffic. Yes, there are security concerns around ICMP, > which is why it is common for it to be filtered out of networks (which is= a > good think for Capport ICMP, it is only for the edge network). > > Regarding ICMP and the "content details of the network" ... I think that > statement conflates policy and enforcement. ICMP provides (as today) > notification of enforcement, and RFC7710 provides where to find out about > the policy (ToS, etc). > > The JSON API becomes a "web service" when it has a http(s):// in front of= it > :) .. but, indeed, my concern is in the transport protocol. It being a UR= L > signals that this is meant to be deployed alongside the portal, or otherw= ise > 'remotely'... Vendors will likely have a "PvD URL: " configuration dialog > ... and there will be many hotspot services companies updating their "How= to" > instructions with their PvD URL info... it is a web service. > > I welcome suggestions that put that JSON API into a lower layer network > protocol. We could stuff JSON into ICMP :) > > Maybe there is a way to merge ICMP and PvD -- to where ICMP provides the > notification (with tokens) and PvD provides the policy (based on these > tokens) (?) > > With regard to vendor (NAS/UE) cooperation, perhaps PvD could be a new > start, but thus far (as my quote of Cisco documentation suggests), it is > more about what users/venues want. Cisco already today actively avoids iO= S > captive portal detection because the "pseudo-browser" (as they call it) d= oes > work with their portal. That is a problem that could be solve today by > Apple/Cisco, couldn't it? Just by not using the pseudo browser... > introducing PvD doesn't resolve the core problem there, but does make it > easier to avoid that pseudo browser. > > You also said "We can still get to a captive portal once the user goes in= to > the browser." ... However, this is increasingly untrue as the work moves = to > https... So, doing this avoidance of detection will still be a problem. > > Cheers, > David > > > On Fri, Aug 18, 2017 at 7:23 PM, Tommy Pauly wrote: >> >> Hi David, >> >> My thoughts with regards to RFC 7710 is that it is not deployed as far a= s >> I know, and no client stack respects the value sent in 7710. Without som= e >> API extensions, it isn't directly better than what we currently have. >> Ideally, this would not be an API that would get deployed if we were als= o >> using PvDs. My concern is that if PvDs are used for enterprise and priva= te >> networks, we'll have a very similar but less complete path based on RFC >> 7710. We could end up deprecating or replacing that RFC, which was menti= oned >> in our last meeting. I don't think RFC 7710 can be used without a URL, w= hich >> is why I think we need a solution that does a better job of indicating t= he >> lack of captive or other extended network info. >> >> I would hope that since both iOS and Android stack developers are workin= g >> on the UE side, we would actually see UE deployment of PvDs before any >> captive vendors adopt PvDs, and we'd be standardizing around Cisco/etc >> enterprise deployments. By the time there were NAS vendors deploying, th= ey >> would test with both iOS and Android devices to validate support. >> >> Basing our standards on the idea that devices (either networks or UE's) >> may implement the RFCs incorrectly seems to be a difficult starting poin= t. >> >> I like the point you bring up of splitting network notifications from we= b >> APIs. There is a need to be judicious about what properties fall into ea= ch >> category. I think you're saying that the fact that there is a captive >> network can be signaled via ICMP, etc, as a network-level property. Whil= e >> ICMP is a fine solution for giving the UE hints when something has expir= ed, >> I am concerned that (possibly unsolicited) network signaling is not the >> correct mechanism for the content details of the network, whether that i= s >> the enterprise network properties, or the captive network Terms & >> Conditions, tokens, expiration timers, and URLs for various kinds of use= r >> interaction. An JSON API is one form of grabbing information=E2=80=94I d= on't think >> we should necessarily interpret that as something that is a high-level W= eb >> interaction. We could create some custom protocol over UDP like DNS reco= rds >> to get the information (that would be a lot of new protocol work here th= at >> people may not be willing to get into), but the key is that it needs to = be >> the choice of a UE device that understands how to request and parse cont= ent >> that initiates a lookup, and can fetch information from the network >> infrastructure. >> >> With regards to your assertion that we'll always revert to doing a probe= , >> I still would like to believe that if we have a network that advertises = a >> PvD with no extended information, or extended information that doesn't >> include a captive portal, we can avoid the probe altogether. Will we sti= ll >> have networks that redirect HTTP requests? Yes. But that's no different = from >> the scenario today in which a network whitelists our captive detection >> probes. We can still get to a captive portal once the user goes into the >> browser. We can stop doing probes whenever the RA on the network indicat= es >> that it supports explicit signaling about network properties. If a netwo= rk >> operator wants to invoke the system-level captive interaction, then they >> will follow the RFCs we come up in the CAPPORT group as long as UEs end = up >> deploying support first. If they want to avoid it, or they have a broken >> network, things will be like networks that whitelist our probes today. N= ot >> great, but still possible for the user to get through. My main goal in t= hese >> standards is to make it possible for a network to give the user a good >> experience; not to make it impossible for the user to have a sub-par >> experience (since I don't think that goal is achievable). >> >> Best, >> Tommy >> >> >> On Aug 18, 2017, at 5:52 PM, David Bird wrote: >> >> Thanks Tommy, >> >> I don't dispute that PvD provides an elegant set of solutions -- >> particularly in enterprise and other 'private' networks. I question, >> however, the value in public(/guest) access -- where everyone wants you = to >> access their network over others, for 'retail analytic' or >> branding/attribution(/exploit) purposes. >> >> Another way to see the PvD integration/deployment: >> >> 1. Today, we join a network, always do a probe, which redirects to capti= ve >> portal >> 2. A PvD URL is provide, so a captive portal notification is generated t= o >> the user (is that what 'we just make a connection directly' means?) >> 3. We may have also gotten RFC7710 URL, there are potentially two APIs i= n >> play at the same time, which is extra confusing (?) >> 4. The first NAS vendor release products with support, venues deploy and >> start 'fiddling' with the new feature and URL to PvD end-points >> 5. The first UE vendor releases products with support, start using it at >> said venues... complain to vendor about problems unique to this new devi= ce >> 6. In some networks, users complain that *only* their new PvD device is >> seeing a captive portal, while all their other devices do not. Staff at = the >> coffee shop don't believe me; all their devices work too. >> >> I think there are fundamental issues in splitting what should be 'networ= k >> notification' into web APIs.... >> >> 1. Tomorrow, we join a network, always do a probe, which redirects to >> captive portal >> >> It wasn't clear in your e-mail if RFC7710 can be used *without* providin= g >> a URL, or is there a PvD specific DHCP option? >> >> Thanks, >> David >> >> >> On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly wrote: >>> >>> Hi David, >>> >>> You mention in one of your emails that you'd expect there to be many >>> "broken PvD" deployments, which would either necessitate ignoring PvD a= nd >>> using legacy mechanisms, or else having the user face a broken portal. = My >>> impression is that if client-side deployments fail closed=E2=80=94that = is, if there >>> is a PvD advertised, but it does not work well, then we treat the netwo= rk as >>> broken. If this client behavior is consistent from the start of deploym= ent, >>> then I would think that deployments would notice very quickly if they a= re >>> broken. The fundamental part of the PvD being advertised is in the RAs= =E2=80=94if >>> our DHCP or RAs are broken on a network, we generally are going to be b= roken >>> anyhow. >>> >>> As far as where the API resides, I appreciate your explanation of the >>> various complexities. My initial take is this: >>> >>> - Where a PvD is being served is up to the deployment, and determined b= y >>> the entity that is providing the RAs. To that end, the server that host= s the >>> API for extended PvD information may be very different for >>> enterprise/carrier scenarios than in captive portals for coffee shops. >>> - For the initial take for Captive Portals, I would co-locate the "PvD >>> API" server with the "Captive API" and "Captive Web Server". Presumably= , the >>> device that was previously doing the HTTP redirects would be able to do= the >>> similar coordination of making sure the PvD ID that is given out to cli= ents >>> matches the PvD API server (which is the same as the "Captive Web Serve= r"). >>> >>> For the captive use-case, I see the integration of PvDs as an increment= al >>> step: >>> >>> 1. Today, we join a network, always do a probe, which may get redirecte= d >>> to a captive web server >>> 2. With RFC 7710, we would join a network and do the same as (1), unles= s >>> the captive URL is given in the DHCP/RA and we just make a connection >>> directly. >>> 3. With the Captive API draft, we can interact with the portal other th= an >>> just showing a webpage; but this may still be bootstrapped by 7710 if n= ot >>> using another mechanism >>> 4. With PvDs, the mechanism in 7710 is generalized to support APIs othe= r >>> than just captive, and can indicate that no captive portal or other ext= ended >>> info is present; and the PvD API in this form is just a more generic ve= rsion >>> of the captive API that allows us to use the same mechanism for other >>> network properties that aren't specifically captive (like enterprise ne= twork >>> extended info, or walled gardens) >>> >>> Getting into the arms race of people avoiding the captive probes: if >>> someone doesn't want to interact with the client OS's captive portal sy= stem, >>> they can and likely will not change anything and just keep redirecting >>> pages. Hopefully if a better solution becomes prevalent enough in the >>> future, client OS's will be able to just ignore and reject any network = that >>> redirects traffic, and the only supported captive portals would be ones= that >>> interact in specified ways and advertise themselves as captive networks= . In >>> order to get to this point, there certainly needs to be a carrot to >>> incentivize adoption. My goal with the more flexible interaction suppor= ted >>> by PvD is that we will allow the networks to provide a better user >>> experience to people joining their networks, and integrate with client = OS's >>> to streamline the joining process (notification of the network being >>> available, who owns it, how to accept and how to pay), the maintenance >>> process (being able to integrate time left or bytes left on the network= into >>> the system UI), and what is allowed or not on the network. >>> >>> Thanks, >>> Tommy >>> >>> >>> On Aug 16, 2017, at 6:51 AM, David Bird wrote: >>> >>> My question about where the PvD API resides was somewhat rhetorical. In >>> reality, I'm sure you will find all of the above - In the NAS (e.g. Cis= co), >>> at the hotspot services provider, and something hosted next to the venu= es >>> website. It depends mostly on how this URL is configured, and by whom. = (One >>> could imagine people doing all sorts of things). >>> >>> My question more specifically for the authors is, how would Cisco >>> implement PvD for Guest/Public access and would it actively stop avoidi= ng >>> Apple captive portal detection? Or, would turning on PvD just make that >>> 'feature' easier to implement? >>> >>> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline wrote: >>>> >>>> Randomly selecting Tommy and Eric so this bubbles up in their inbox. >>>> >>>> On 2 August 2017 at 10:36, David Bird wrote: >>>> > Could an author of PvD help me understand the following questions fo= r >>>> > each >>>> > of the diagrams below I found on the Internet -- which represent som= e >>>> > typical hotspot configurations out there... >>>> > >>>> > - Where would the API reside? >>>> > >>>> > - Who 'owns' the API? >>>> > >>>> > - How does the API keep in-sync with the NAS? Who's responsible for >>>> > that >>>> > (possibly multi-vendor, multi-AAA) integration? >>>> > >>>> > 1) Typical Hotspot service company outsourcing: >>>> > >>>> > http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePortalS= olution_beta2b.png >>>> > >>>> > 2) Same as above, except venue owns portal: >>>> > >>>> > http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspots-c= o-working-cloudessa_2p1.png >>>> > >>>> > 3) Now consider the above, but the venue has more roaming partners a= nd >>>> > multi-realm RADIUS setup in their Cisco NAS: >>>> > >>>> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/config-= guide/b_cg83/b_cg83_chapter_0100111.html >>>> > describes many options -- including separate MAC authentication >>>> > sources, >>>> > optional portals for 802.1x (RADIUS) authenticated users, and so muc= h >>>> > more... >>>> > >>>> > "Cisco ISE supports internal and external identity sources. Both >>>> > sources can >>>> > be used as an authentication source for sponsor-user and guest-user >>>> > authentication." >>>> > >>>> > Also note this interesting article: the section Information About >>>> > Captive >>>> > Bypassing and how it describes how to avoid Apple captive portal >>>> > detection!!! "If no response is received, then the Internet access i= s >>>> > assumed to be blocked by the captive portal and Apple=E2=80=99s Capt= ive >>>> > Network >>>> > Assistant (CNA) auto-launches the pseudo-browser to request portal >>>> > login in >>>> > a controlled window. The CNA may break when redirecting to an ISE >>>> > captive >>>> > portal. The controller prevents this pseudo-browser from popping up.= " >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > Captive-portals mailing list >>>> > Captive-portals@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/captive-portals >>>> > >>> >>> >>> >> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals >> >> > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > From nobody Tue Aug 22 13:09:20 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58F6132A1F for ; Tue, 22 Aug 2017 13:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_WP_DIRINDEX=1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 xaEK-av-r_-u for ; Tue, 22 Aug 2017 13:09:15 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02B1132A12 for ; Tue, 22 Aug 2017 13:09:14 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id u139so102901970qka.1 for ; Tue, 22 Aug 2017 13:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5LbDOO4g/cVbcoWdq6jclW2H/azFZ5x6ZCc7C09APiY=; b=KGPb3PxJCn87u8f1wegWOTb1o1tKNrYmS0kjhExUdmo4zvGKcVxkFqGQfqSxJefTVb kA0pOJKjmTGhCkikqQ1301GOZ7Ukz64nEKryYZp7CHTA5XpUHpM42Dh7RCRtTp22FaeO Bbea7b5KWVYBj+f8o8ApP6qCXHhAUbvWpI/QIVOUFgFvtf+10sAPtdq1QwtinR/aCfkf weC6+43J2X89+VJvNuWUWC6ajtZz4pBY1opIBAuUUkyIJprHIMTjHEE4/gT7cQraLGSv OQSEut8xPxrF1fML9ATbFVlRNj47PGPpJOXYUHUX2VqHZfcZSZnKgPs9JDwQAKMHzgZD vOlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5LbDOO4g/cVbcoWdq6jclW2H/azFZ5x6ZCc7C09APiY=; b=EEvPlB3neW99ZhLR8+L96KGaLS8tPM2NDdgkJCDZPMNjEWg8PIyQdFUEGzwayGsR30 3lLThWceJM2PPggwATJIaOF3ypMRPnuxkruqufnMjpbMLBnMoZ0o+9vDM/o/F2DNcFrh XP2jvLF/jDiiDRT4YjUWEiInL7/D2SSgQqy2AboUVvJk4fbT0zYtaacMoCNe/4mfGlgJ wK/YYX1+3ieiHkP5P1lgkhvZ5XiokVgTGVbLMHICnQdilt3+3uXn7tLqPoRESuBUHRvN SQExKfDiZsRySA7DYqjVuaWPeHrFh2BNYPr3LYwDfL7VBY1OGpK7qE5hDPpcWftaVDZX O0lA== X-Gm-Message-State: AHYfb5g0NOwWlg86Es7pxCWw5IPrYQwQjeDkaqR3y9gyD8Hiw93qemcs 8x0qRbNq3H+/DdbLoBpIOZBxUtBre0Nr X-Received: by 10.55.95.194 with SMTP id t185mr431369qkb.61.1503432553119; Tue, 22 Aug 2017 13:09:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Tue, 22 Aug 2017 13:09:12 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> From: David Bird Date: Tue, 22 Aug 2017 13:09:12 -0700 Message-ID: To: Martin Thomson Cc: Tommy Pauly , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org Content-Type: multipart/alternative; boundary="001a114dc83c4673ea05575d2be2" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 20:09:19 -0000 --001a114dc83c4673ea05575d2be2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think that is a fair comparison... Geolocation isn't anything enforced by the network... and clearly not designed for public/guest access networks (as they exists today). You might re-read some of the Security Consideration in the docs surrounding GEOPRIV. HTTP-Enabled Location Delivery (HELD) https://datatracker.ietf.org/doc/html/rfc5985#page-22 HELD is a location acquisition protocol whereby the client requests its location from a LIS. Specific requirements and security considerations for location acquisition protocols are provided in [RFC5687]. An in-depth discussion of the security considerations applicable to the use of Location URIs and by-reference provision of LI is included in [RFC5808]. By using the HELD protocol, the client and the LIS expose themselves to two types of risk: Accuracy: The client receives incorrect location information. Privacy: An unauthorized entity receives location information. The provision of an accurate and privacy- and confidentiality- protected location to the requestor depends on the success of five steps: 1. The client must determine the proper LIS. 2. The client must connect to the proper LIS. 3. The LIS must be able to identify the Device by its identifier (IP address). 4. The LIS must be able to return the desired location. 5. HELD messages must be transmitted unmodified between the LIS and the client. Of these, only steps 2, 3, and 5 are within the scope of this document. Step 1 is based on either manual configuration or on the LIS discovery defined in [RFC5986], in which appropriate security considerations are already discussed. Step 4 is dependent on the specific positioning capabilities of the LIS and is thus outside the scope of this document. Discovering the Local Location Information Server (LIS) https://datatracker.ietf.org/doc/html/rfc5986#page-11 The address of a *LIS is usually well-known within an access network*; therefore, interception of messages does not introduce any specific concerns. The primary attack against the methods described in this document is one that would lead to impersonation of a LIS. The LIS is responsible for providing location information, and this information is critical to a number of network services; furthermore, a Device does not necessarily have a prior relationship with a LIS. Several methods are described here that can limit the probability of, or provide some protection against, such an attack. These methods MUST be applied unless similar protections are in place, or in cases -- such as an emergency -- where location information of dubious origin is arguably better than none at all. An attacker could attempt to compromise LIS discovery at any of three stages: * 1. providing a falsified domain name to be used as input to U-NAPTR 2. altering the DNS records used in U-NAPTR resolution 3. impersonating the LIS* The domain name that used to authenticate the LIS is the domain name input to the U-NAPTR process, not the output of that process [RFC3958], [RFC4848]. As a result, the results of DNS queries do not need integrity protection. An HTTPS URI is authenticated using the method described in Section 3.1 of [RFC2818]. HTTP client implementations frequently do not provide a means to authenticate based on a domain name other than the one indicated in the request URI, namely the U-NAPTR output. To avoid having to authenticate the LIS with a domain name that is different from the one used to identify it, a client MAY choose to reject URIs that contain a domain name that is different to the U-NAPTR input. To support endpoints that enforce the above restriction on URIs, network administrators SHOULD ensure that the domain name in the DHCP option is the same as the one contained in the resulting URI. *Authentication of a LIS relies on the integrity of the domain name acquired from DHCP. An attacker that is able to falsify a domain name circumvents the protections provided. * To ensure that the access network domain name DHCP option can be relied upon, preventing DHCP messages from being modified or spoofed by attackers is necessary. *Physical- or link-layer security are commonly used to reduce the possibility of such an attack within an access network. * DHCP authentication [RFC3118] might also provide a degree of protection against modification or spoofing. A LIS that is identified by an HTTP URI cannot be authenticated. Use of unsecured HTTP also does not meet requirements in HELD for confidentiality and integrity. If an HTTP URI is the product of LIS discovery, this leaves Devices vulnerable to several attacks. *Lower- layer protections, such as Layer 2 traffic separation might be used to provide some guarantees.* Requirements for a Location-by-Reference Mechanism https://datatracker.ietf.org/doc/html/rfc5808#page-12 The method of constructing the location URI to include randomized components helps to prevent adversaries from obtaining location information without ever retrieving a location URI. In the possession model, a location URI, regardless of its construction, if made publicly available, implies no safeguard against anyone being able to dereference and get the location. Care has to be paid when distributing such a location URI to the *trusted location recipients*. When this aspect is of concern, the authorization model has to be chosen. *Even in this model, care has to be taken on how to construct the authorization policies to ensure that only those parties have access to location information that are considered trustworthy enough to enforce the basic rule set that is attached to location information in a PIDF-LO document.* Any location URI, by necessity, indicates the server (name) that hosts the location information. Knowledge of the server in some specific domain could therefore reveal something about the location of the Target. This kind of threat may be mitigated somewhat by introducing another layer of indirection: namely the use of a (remote) presence server. A covert channel for protocol message exchange is an important consideration, given an example scenario where user A subscribes to location information for user B, then every time A gets a location update, an (external) observer of the subscription notification may know that B has moved. One mitigation of this is to have periodic notification, so that user B may appear to have moved even when static. On Sun, Aug 20, 2017 at 6:34 PM, Martin Thomson wrote: > Hi David, > > Can you explain more about why you believe that a lower-layer protocol > needs to be used? > > I remember a similar discussion about this about 10 years ago with > GEOPRIV. Then it was asserted that DHCP was the only protocol that > could deliver location information to user equipment. That discussion > took a long time, but ultimately ended with an HTTP-based protocol. I > have no desire to repeat that experience. > > It seems like this is - at least in part - based in how this might be > configured. That is, you believe that a lower-layer protocol offers > no option for misconfiguration. Is that correct? Have I missed > something? > > > On 20 August 2017 at 00:12, David Bird wrote: > > HI Tommy, > > > > Agreed that RFC7710 is lacking notification of captive portal existence= , > it > > only provides configuration information. ICMP would provide the > > notification, as it does today for other forms of destination > unreachable, > > port unreachable, etc. In your first reply, I thought you were suggesti= ng > > that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clear wha= t > you > > meant by DHCP/RA). > > > > I think we both also agree that taking about both a Capport API *and* > PvD is > > adding to the confusion and we ultimately will not want two "APIs". > > > > ICMP today delivers more than hints... it provides signaling that can > > directly influence traffic. Yes, there are security concerns around ICM= P, > > which is why it is common for it to be filtered out of networks (which > is a > > good think for Capport ICMP, it is only for the edge network). > > > > Regarding ICMP and the "content details of the network" ... I think tha= t > > statement conflates policy and enforcement. ICMP provides (as today) > > notification of enforcement, and RFC7710 provides where to find out abo= ut > > the policy (ToS, etc). > > > > The JSON API becomes a "web service" when it has a http(s):// in front > of it > > :) .. but, indeed, my concern is in the transport protocol. It being a > URL > > signals that this is meant to be deployed alongside the portal, or > otherwise > > 'remotely'... Vendors will likely have a "PvD URL: " configuration dial= og > > ... and there will be many hotspot services companies updating their > "Howto" > > instructions with their PvD URL info... it is a web service. > > > > I welcome suggestions that put that JSON API into a lower layer network > > protocol. We could stuff JSON into ICMP :) > > > > Maybe there is a way to merge ICMP and PvD -- to where ICMP provides th= e > > notification (with tokens) and PvD provides the policy (based on these > > tokens) (?) > > > > With regard to vendor (NAS/UE) cooperation, perhaps PvD could be a new > > start, but thus far (as my quote of Cisco documentation suggests), it i= s > > more about what users/venues want. Cisco already today actively avoids > iOS > > captive portal detection because the "pseudo-browser" (as they call it) > does > > work with their portal. That is a problem that could be solve today by > > Apple/Cisco, couldn't it? Just by not using the pseudo browser... > > introducing PvD doesn't resolve the core problem there, but does make i= t > > easier to avoid that pseudo browser. > > > > You also said "We can still get to a captive portal once the user goes > into > > the browser." ... However, this is increasingly untrue as the work move= s > to > > https... So, doing this avoidance of detection will still be a problem. > > > > Cheers, > > David > > > > > > On Fri, Aug 18, 2017 at 7:23 PM, Tommy Pauly wrote: > >> > >> Hi David, > >> > >> My thoughts with regards to RFC 7710 is that it is not deployed as far > as > >> I know, and no client stack respects the value sent in 7710. Without > some > >> API extensions, it isn't directly better than what we currently have. > >> Ideally, this would not be an API that would get deployed if we were > also > >> using PvDs. My concern is that if PvDs are used for enterprise and > private > >> networks, we'll have a very similar but less complete path based on RF= C > >> 7710. We could end up deprecating or replacing that RFC, which was > mentioned > >> in our last meeting. I don't think RFC 7710 can be used without a URL, > which > >> is why I think we need a solution that does a better job of indicating > the > >> lack of captive or other extended network info. > >> > >> I would hope that since both iOS and Android stack developers are > working > >> on the UE side, we would actually see UE deployment of PvDs before any > >> captive vendors adopt PvDs, and we'd be standardizing around Cisco/etc > >> enterprise deployments. By the time there were NAS vendors deploying, > they > >> would test with both iOS and Android devices to validate support. > >> > >> Basing our standards on the idea that devices (either networks or UE's= ) > >> may implement the RFCs incorrectly seems to be a difficult starting > point. > >> > >> I like the point you bring up of splitting network notifications from > web > >> APIs. There is a need to be judicious about what properties fall into > each > >> category. I think you're saying that the fact that there is a captive > >> network can be signaled via ICMP, etc, as a network-level property. > While > >> ICMP is a fine solution for giving the UE hints when something has > expired, > >> I am concerned that (possibly unsolicited) network signaling is not th= e > >> correct mechanism for the content details of the network, whether that > is > >> the enterprise network properties, or the captive network Terms & > >> Conditions, tokens, expiration timers, and URLs for various kinds of > user > >> interaction. An JSON API is one form of grabbing information=E2=80=94I= don't > think > >> we should necessarily interpret that as something that is a high-level > Web > >> interaction. We could create some custom protocol over UDP like DNS > records > >> to get the information (that would be a lot of new protocol work here > that > >> people may not be willing to get into), but the key is that it needs t= o > be > >> the choice of a UE device that understands how to request and parse > content > >> that initiates a lookup, and can fetch information from the network > >> infrastructure. > >> > >> With regards to your assertion that we'll always revert to doing a > probe, > >> I still would like to believe that if we have a network that advertise= s > a > >> PvD with no extended information, or extended information that doesn't > >> include a captive portal, we can avoid the probe altogether. Will we > still > >> have networks that redirect HTTP requests? Yes. But that's no differen= t > from > >> the scenario today in which a network whitelists our captive detection > >> probes. We can still get to a captive portal once the user goes into t= he > >> browser. We can stop doing probes whenever the RA on the network > indicates > >> that it supports explicit signaling about network properties. If a > network > >> operator wants to invoke the system-level captive interaction, then th= ey > >> will follow the RFCs we come up in the CAPPORT group as long as UEs en= d > up > >> deploying support first. If they want to avoid it, or they have a brok= en > >> network, things will be like networks that whitelist our probes today. > Not > >> great, but still possible for the user to get through. My main goal in > these > >> standards is to make it possible for a network to give the user a good > >> experience; not to make it impossible for the user to have a sub-par > >> experience (since I don't think that goal is achievable). > >> > >> Best, > >> Tommy > >> > >> > >> On Aug 18, 2017, at 5:52 PM, David Bird wrote: > >> > >> Thanks Tommy, > >> > >> I don't dispute that PvD provides an elegant set of solutions -- > >> particularly in enterprise and other 'private' networks. I question, > >> however, the value in public(/guest) access -- where everyone wants yo= u > to > >> access their network over others, for 'retail analytic' or > >> branding/attribution(/exploit) purposes. > >> > >> Another way to see the PvD integration/deployment: > >> > >> 1. Today, we join a network, always do a probe, which redirects to > captive > >> portal > >> 2. A PvD URL is provide, so a captive portal notification is generated > to > >> the user (is that what 'we just make a connection directly' means?) > >> 3. We may have also gotten RFC7710 URL, there are potentially two APIs > in > >> play at the same time, which is extra confusing (?) > >> 4. The first NAS vendor release products with support, venues deploy a= nd > >> start 'fiddling' with the new feature and URL to PvD end-points > >> 5. The first UE vendor releases products with support, start using it = at > >> said venues... complain to vendor about problems unique to this new > device > >> 6. In some networks, users complain that *only* their new PvD device i= s > >> seeing a captive portal, while all their other devices do not. Staff a= t > the > >> coffee shop don't believe me; all their devices work too. > >> > >> I think there are fundamental issues in splitting what should be > 'network > >> notification' into web APIs.... > >> > >> 1. Tomorrow, we join a network, always do a probe, which redirects to > >> captive portal > >> > >> It wasn't clear in your e-mail if RFC7710 can be used *without* > providing > >> a URL, or is there a PvD specific DHCP option? > >> > >> Thanks, > >> David > >> > >> > >> On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly wrote: > >>> > >>> Hi David, > >>> > >>> You mention in one of your emails that you'd expect there to be many > >>> "broken PvD" deployments, which would either necessitate ignoring PvD > and > >>> using legacy mechanisms, or else having the user face a broken portal= . > My > >>> impression is that if client-side deployments fail closed=E2=80=94tha= t is, if > there > >>> is a PvD advertised, but it does not work well, then we treat the > network as > >>> broken. If this client behavior is consistent from the start of > deployment, > >>> then I would think that deployments would notice very quickly if they > are > >>> broken. The fundamental part of the PvD being advertised is in the > RAs=E2=80=94if > >>> our DHCP or RAs are broken on a network, we generally are going to be > broken > >>> anyhow. > >>> > >>> As far as where the API resides, I appreciate your explanation of the > >>> various complexities. My initial take is this: > >>> > >>> - Where a PvD is being served is up to the deployment, and determined > by > >>> the entity that is providing the RAs. To that end, the server that > hosts the > >>> API for extended PvD information may be very different for > >>> enterprise/carrier scenarios than in captive portals for coffee shops= . > >>> - For the initial take for Captive Portals, I would co-locate the "Pv= D > >>> API" server with the "Captive API" and "Captive Web Server". > Presumably, the > >>> device that was previously doing the HTTP redirects would be able to > do the > >>> similar coordination of making sure the PvD ID that is given out to > clients > >>> matches the PvD API server (which is the same as the "Captive Web > Server"). > >>> > >>> For the captive use-case, I see the integration of PvDs as an > incremental > >>> step: > >>> > >>> 1. Today, we join a network, always do a probe, which may get > redirected > >>> to a captive web server > >>> 2. With RFC 7710, we would join a network and do the same as (1), > unless > >>> the captive URL is given in the DHCP/RA and we just make a connection > >>> directly. > >>> 3. With the Captive API draft, we can interact with the portal other > than > >>> just showing a webpage; but this may still be bootstrapped by 7710 if > not > >>> using another mechanism > >>> 4. With PvDs, the mechanism in 7710 is generalized to support APIs > other > >>> than just captive, and can indicate that no captive portal or other > extended > >>> info is present; and the PvD API in this form is just a more generic > version > >>> of the captive API that allows us to use the same mechanism for other > >>> network properties that aren't specifically captive (like enterprise > network > >>> extended info, or walled gardens) > >>> > >>> Getting into the arms race of people avoiding the captive probes: if > >>> someone doesn't want to interact with the client OS's captive portal > system, > >>> they can and likely will not change anything and just keep redirectin= g > >>> pages. Hopefully if a better solution becomes prevalent enough in the > >>> future, client OS's will be able to just ignore and reject any networ= k > that > >>> redirects traffic, and the only supported captive portals would be > ones that > >>> interact in specified ways and advertise themselves as captive > networks. In > >>> order to get to this point, there certainly needs to be a carrot to > >>> incentivize adoption. My goal with the more flexible interaction > supported > >>> by PvD is that we will allow the networks to provide a better user > >>> experience to people joining their networks, and integrate with clien= t > OS's > >>> to streamline the joining process (notification of the network being > >>> available, who owns it, how to accept and how to pay), the maintenanc= e > >>> process (being able to integrate time left or bytes left on the > network into > >>> the system UI), and what is allowed or not on the network. > >>> > >>> Thanks, > >>> Tommy > >>> > >>> > >>> On Aug 16, 2017, at 6:51 AM, David Bird wrote: > >>> > >>> My question about where the PvD API resides was somewhat rhetorical. = In > >>> reality, I'm sure you will find all of the above - In the NAS (e.g. > Cisco), > >>> at the hotspot services provider, and something hosted next to the > venues > >>> website. It depends mostly on how this URL is configured, and by whom= . > (One > >>> could imagine people doing all sorts of things). > >>> > >>> My question more specifically for the authors is, how would Cisco > >>> implement PvD for Guest/Public access and would it actively stop > avoiding > >>> Apple captive portal detection? Or, would turning on PvD just make th= at > >>> 'feature' easier to implement? > >>> > >>> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline wrote: > >>>> > >>>> Randomly selecting Tommy and Eric so this bubbles up in their inbox. > >>>> > >>>> On 2 August 2017 at 10:36, David Bird wrote: > >>>> > Could an author of PvD help me understand the following questions > for > >>>> > each > >>>> > of the diagrams below I found on the Internet -- which represent > some > >>>> > typical hotspot configurations out there... > >>>> > > >>>> > - Where would the API reside? > >>>> > > >>>> > - Who 'owns' the API? > >>>> > > >>>> > - How does the API keep in-sync with the NAS? Who's responsible fo= r > >>>> > that > >>>> > (possibly multi-vendor, multi-AAA) integration? > >>>> > > >>>> > 1) Typical Hotspot service company outsourcing: > >>>> > > >>>> > http://cloudessa.com/wp-content/uploads/2013/08/shema- > CaptivePortalSolution_beta2b.png > >>>> > > >>>> > 2) Same as above, except venue owns portal: > >>>> > > >>>> > http://cloudessa.com/wp-content/uploads/2013/07/ > solutions_hotspots-co-working-cloudessa_2p1.png > >>>> > > >>>> > 3) Now consider the above, but the venue has more roaming partners > and > >>>> > multi-realm RADIUS setup in their Cisco NAS: > >>>> > > >>>> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8- > 3/config-guide/b_cg83/b_cg83_chapter_0100111.html > >>>> > describes many options -- including separate MAC authentication > >>>> > sources, > >>>> > optional portals for 802.1x (RADIUS) authenticated users, and so > much > >>>> > more... > >>>> > > >>>> > "Cisco ISE supports internal and external identity sources. Both > >>>> > sources can > >>>> > be used as an authentication source for sponsor-user and guest-use= r > >>>> > authentication." > >>>> > > >>>> > Also note this interesting article: the section Information About > >>>> > Captive > >>>> > Bypassing and how it describes how to avoid Apple captive portal > >>>> > detection!!! "If no response is received, then the Internet access > is > >>>> > assumed to be blocked by the captive portal and Apple=E2=80=99s Ca= ptive > >>>> > Network > >>>> > Assistant (CNA) auto-launches the pseudo-browser to request portal > >>>> > login in > >>>> > a controlled window. The CNA may break when redirecting to an ISE > >>>> > captive > >>>> > portal. The controller prevents this pseudo-browser from popping > up." > >>>> > > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > Captive-portals mailing list > >>>> > Captive-portals@ietf.org > >>>> > https://www.ietf.org/mailman/listinfo/captive-portals > >>>> > > >>> > >>> > >>> > >> > >> _______________________________________________ > >> Captive-portals mailing list > >> Captive-portals@ietf.org > >> https://www.ietf.org/mailman/listinfo/captive-portals > >> > >> > > > > > > _______________________________________________ > > Captive-portals mailing list > > Captive-portals@ietf.org > > https://www.ietf.org/mailman/listinfo/captive-portals > > > --001a114dc83c4673ea05575d2be2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I do= n't think that is a fair comparison...=C2=A0

Geolocation isn't anything e= nforced by the network... and clearly not designed for public/guest access = networks (as they exists today).=C2=A0

=
You might re-read some of the Security Con= sideration in the docs surrounding GEOPRIV.

HTTP-Enabled Location Delivery (HELD)
https://datatracker.ietf.org/doc= /html/rfc5985#page-22

=C2=A0 =C2=A0= HELD is a location acquisition protocol whereby the client requests
=C2= =A0 =C2=A0its location from a LIS.=C2=A0 Specific requirements and security=
=C2=A0 =C2=A0considerations for location acquisition protocols are prov= ided in
=C2=A0 =C2=A0[RFC5687].=C2=A0 An in-depth discussion of the secu= rity considerations
=C2=A0 =C2=A0applicable to the use of Location URIs = and by-reference provision of
=C2=A0 =C2=A0LI is included in [RFC5808].<= br>
=C2=A0 =C2=A0By using the HELD protocol, the client and the LIS expo= se themselves
=C2=A0 =C2=A0to two types of risk:

=C2=A0 =C2=A0Acc= uracy: =C2=A0The client receives incorrect location information.

=C2= =A0 =C2=A0Privacy: =C2=A0An unauthorized entity receives location informati= on.

=C2=A0 =C2=A0The provision of an accurate and privacy- and confi= dentiality-
=C2=A0 =C2=A0protected location to the requestor depends on = the success of five
=C2=A0 =C2=A0steps:

=C2=A0 =C2=A01.=C2=A0 The= client must determine the proper LIS.

=C2=A0 =C2=A02.=C2=A0 The cli= ent must connect to the proper LIS.

=C2=A0 =C2=A03.=C2=A0 The LIS mu= st be able to identify the Device by its identifier (IP
=C2=A0 =C2=A0 = =C2=A0 =C2=A0address).

=C2=A0 =C2=A04.=C2=A0 The LIS must be able to= return the desired location.

=C2=A0 =C2=A05.=C2=A0 HELD messages mu= st be transmitted unmodified between the LIS and
=C2=A0 =C2=A0 =C2=A0 = =C2=A0the client.

=C2=A0 =C2=A0Of these, only steps 2, 3, and 5 are = within the scope of this
=C2=A0 =C2=A0document.=C2=A0 Step 1 is based on= either manual configuration or on the
=C2=A0 =C2=A0LIS discovery define= d in [RFC5986], in which appropriate security
=C2=A0 =C2=A0consideration= s are already discussed.=C2=A0 Step 4 is dependent on the
=C2=A0 =C2=A0s= pecific positioning capabilities of the LIS and is thus outside the
=C2= =A0 =C2=A0scope of this document.

Disco= vering the Local Location Information Server (LIS) =C2=A0 =C2=A0 =C2=A0 https://= datatracker.ietf.org/doc/html/rfc5986#page-11

=C2=A0 =C2=A0The= address of a LIS is usually well-known within an access network;=C2=A0 =C2=A0therefore, interception of messages does not introduce any sp= ecific
=C2=A0 =C2=A0concerns.

=C2=A0 =C2=A0The primary attack aga= inst the methods described in this document is
=C2=A0 =C2=A0one that wou= ld lead to impersonation of a LIS.=C2=A0 The LIS is
=C2=A0 =C2=A0respons= ible for providing location information, and this information
=C2=A0 =C2= =A0is critical to a number of network services; furthermore, a Device
= =C2=A0 =C2=A0does not necessarily have a prior relationship with a LIS.=C2= =A0 Several
=C2=A0 =C2=A0methods are described here that can limit the p= robability of, or
=C2=A0 =C2=A0provide some protection against, such an = attack.=C2=A0 These methods MUST
=C2=A0 =C2=A0be applied unless similar = protections are in place, or in cases --
=C2=A0 =C2=A0such as an emergen= cy -- where location information of dubious origin
=C2=A0 =C2=A0is argua= bly better than none at all.

=C2=A0 =C2=A0An attacker could attempt = to compromise LIS discovery at any of three
=C2=A0 =C2=A0stages:
<= br>=C2=A0 =C2=A01. =C2=A0providing a falsified domain name to be used as in= put to U-NAPTR

=C2=A0 =C2=A02. =C2=A0altering the DNS records used i= n U-NAPTR resolution

=C2=A0 =C2=A03. =C2=A0impersonating the LIS=

=C2=A0 =C2=A0The domain name that used to authenticate the LIS is t= he domain name
=C2=A0 =C2=A0input to the U-NAPTR process, not the output= of that process
=C2=A0 =C2=A0[RFC3958], [RFC4848].=C2=A0 As a result, t= he results of DNS queries do not
=C2=A0 =C2=A0need integrity protection.=

=C2=A0 =C2=A0An HTTPS URI is authenticated using the method describ= ed in Section
=C2=A0 =C2=A03.1 of [RFC2818].=C2=A0 HTTP client implement= ations frequently do not
=C2=A0 =C2=A0provide a means to authenticate ba= sed on a domain name other than the
=C2=A0 =C2=A0one indicated in the re= quest URI, namely the U-NAPTR output.=C2=A0 To
=C2=A0 =C2=A0avoid having= to authenticate the LIS with a domain name that is
=C2=A0 =C2=A0differe= nt from the one used to identify it, a client MAY choose to
=C2=A0 =C2= =A0reject URIs that contain a domain name that is different to the
=C2= =A0 =C2=A0U-NAPTR input.=C2=A0 To support endpoints that enforce the above<= br>=C2=A0 =C2=A0restriction on URIs, network administrators SHOULD ensure t= hat the
=C2=A0 =C2=A0domain name in the DHCP option is the same as the o= ne contained in
=C2=A0 =C2=A0the resulting URI.

=C2=A0 =C2=A0A= uthentication of a LIS relies on the integrity of the domain name
=C2=A0= =C2=A0acquired from DHCP.=C2=A0 An attacker that is able to falsify a doma= in
=C2=A0 =C2=A0name circumvents the protections provided. =C2=A0To = ensure that the access
=C2=A0 =C2=A0network domain name DHCP option can = be relied upon, preventing DHCP
=C2=A0 =C2=A0messages from being modifie= d or spoofed by attackers is necessary.
=C2=A0 =C2=A0Physical- or lin= k-layer security are commonly used to reduce the
=C2=A0 =C2=A0possibilit= y of such an attack within an access network. =C2=A0DHCP
=C2=A0 =C2= =A0authentication [RFC3118] might also provide a degree of protection
= =C2=A0 =C2=A0against modification or spoofing.

=C2=A0 =C2=A0A LIS th= at is identified by an HTTP URI cannot be authenticated.=C2=A0 Use
=C2= =A0 =C2=A0of unsecured HTTP also does not meet requirements in HELD for
= =C2=A0 =C2=A0confidentiality and integrity.=C2=A0 If an HTTP URI is the pro= duct of LIS
=C2=A0 =C2=A0discovery, this leaves Devices vulnerable to se= veral attacks. =C2=A0Lower-
=C2=A0 =C2=A0layer protections, such as L= ayer 2 traffic separation might be used
=C2=A0 =C2=A0to provide some gua= rantees.

Requirements for a Location-by-Reference Mechan= ism
ht= tps://datatracker.ietf.org/doc/html/rfc5808#page-12

=C2=A0 =C2= =A0The method of constructing the location URI to include randomized
=C2= =A0 =C2=A0components helps to prevent adversaries from obtaining location=C2=A0 =C2=A0information without ever retrieving a location URI.=C2=A0 In= the
=C2=A0 =C2=A0possession model, a location URI, regardless of its co= nstruction, if
=C2=A0 =C2=A0made publicly available, implies no safeguar= d against anyone being
=C2=A0 =C2=A0able to dereference and get the loca= tion.=C2=A0 Care has to be paid when
=C2=A0 =C2=A0distributing such a lo= cation URI to the trusted location recipients.
=C2=A0 =C2=A0When = this aspect is of concern, the authorization model has to be
=C2=A0 =C2= =A0chosen. =C2=A0Even in this model, care has to be taken on how to cons= truct
=C2=A0 =C2=A0the authorization policies to ensure that only those = parties have
=C2=A0 =C2=A0access to location information that are consid= ered trustworthy enough
=C2=A0 =C2=A0to enforce the basic rule set that = is attached to location
=C2=A0 =C2=A0information in a PIDF-LO document.<= /b>

=C2=A0 =C2=A0Any location URI, by necessity, indicates the serve= r (name) that
=C2=A0 =C2=A0hosts the location information.=C2=A0 Knowled= ge of the server in some
=C2=A0 =C2=A0specific domain could therefore re= veal something about the location
=C2=A0 =C2=A0of the Target.=C2=A0 This= kind of threat may be mitigated somewhat by
=C2=A0 =C2=A0introducing an= other layer of indirection: namely the use of a
=C2=A0 =C2=A0(remote) pr= esence server.

=C2=A0 =C2=A0A covert channel for protocol message ex= change is an important
=C2=A0 =C2=A0consideration, given an example scen= ario where user A subscribes to
=C2=A0 =C2=A0location information for us= er B, then every time A gets a location
=C2=A0 =C2=A0update, an (externa= l) observer of the subscription notification may
=C2=A0 =C2=A0know that = B has moved.=C2=A0 One mitigation of this is to have periodic
=C2=A0 =C2= =A0notification, so that user B may appear to have moved even when
=C2= =A0 =C2=A0static.



On Sun, Aug 20, 2017 at 6:34 PM, Ma= rtin Thomson <martin.thomson@gmail.com> wrote:
Hi David,

Can you explain more about why you believe that a lower-layer protocol
needs to be used?

I remember a similar discussion about this about 10 years ago with
GEOPRIV.=C2=A0 Then it was asserted that DHCP was the only protocol that could deliver location information to user equipment.=C2=A0 That discussion=
took a long time, but ultimately ended with an HTTP-based protocol.=C2=A0 I=
have no desire to repeat that experience.

It seems like this is - at least in part - based in how this might be
configured.=C2=A0 That is, you believe that a lower-layer protocol offers no option for misconfiguration.=C2=A0 Is that correct?=C2=A0 Have I missed<= br> something?


On 20 August 2017 at 00:12, David Bird <dbird@google.com> wrote:
> HI Tommy,
>
> Agreed that RFC7710 is lacking notification of captive portal existenc= e, it
> only provides configuration information. ICMP would provide the
> notification, as it does today for other forms of destination unreacha= ble,
> port unreachable, etc. In your first reply, I thought you were suggest= ing
> that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clea= r what you
> meant by DHCP/RA).
>
> I think we both also agree that taking about both a Capport API *and* = PvD is
> adding to the confusion and we ultimately will not want two "APIs= ".
>
> ICMP today delivers more than hints... it provides signaling that can<= br> > directly influence traffic. Yes, there are security concerns around IC= MP,
> which is why it is common for it to be filtered out of networks (which= is a
> good think for Capport ICMP, it is only for the edge network).
>
> Regarding ICMP and the "content details of the network" ... = I think that
> statement conflates policy and enforcement. ICMP provides (as today) > notification of enforcement, and RFC7710 provides where to find out ab= out
> the policy (ToS, etc).
>
> The JSON API becomes a "web service" when it has a http(s):/= / in front of it
> :) .. but, indeed, my concern is in the transport protocol. It being a= URL
> signals that this is meant to be deployed alongside the portal, or oth= erwise
> 'remotely'... Vendors will likely have a "PvD URL: "= configuration dialog
> ... and there will be many hotspot services companies updating their &= quot;Howto"
> instructions with their PvD URL info... it is a web service.
>
> I welcome suggestions that put that JSON API into a lower layer networ= k
> protocol. We could stuff JSON into ICMP :)
>
> Maybe there is a way to merge ICMP and PvD -- to where ICMP provides t= he
> notification (with tokens) and PvD provides the policy (based on these=
> tokens) (?)
>
> With regard to vendor (NAS/UE) cooperation, perhaps PvD could be a new=
> start, but thus far (as my quote of Cisco documentation suggests), it = is
> more about what users/venues want. Cisco already today actively avoids= iOS
> captive portal detection because the "pseudo-browser" (as th= ey call it) does
> work with their portal. That is a problem that could be solve today by=
> Apple/Cisco, couldn't it? Just by not using the pseudo browser...<= br> > introducing PvD doesn't resolve the core problem there, but does m= ake it
> easier to avoid that pseudo browser.
>
> You also said "We can still get to a captive portal once the user= goes into
> the browser." ... However, this is increasingly untrue as the wor= k moves to
> https... So, doing this avoidance of detection will still be a problem= .
>
> Cheers,
> David
>
>
> On Fri, Aug 18, 2017 at 7:23 PM, Tommy Pauly <tpauly@apple.com> wrote:
>>
>> Hi David,
>>
>> My thoughts with regards to RFC 7710 is that it is not deployed as= far as
>> I know, and no client stack respects the value sent in 7710. Witho= ut some
>> API extensions, it isn't directly better than what we currentl= y have.
>> Ideally, this would not be an API that would get deployed if we we= re also
>> using PvDs. My concern is that if PvDs are used for enterprise and= private
>> networks, we'll have a very similar but less complete path bas= ed on RFC
>> 7710. We could end up deprecating or replacing that RFC, which was= mentioned
>> in our last meeting. I don't think RFC 7710 can be used withou= t a URL, which
>> is why I think we need a solution that does a better job of indica= ting the
>> lack of captive or other extended network info.
>>
>> I would hope that since both iOS and Android stack developers are = working
>> on the UE side, we would actually see UE deployment of PvDs before= any
>> captive vendors adopt PvDs, and we'd be standardizing around C= isco/etc
>> enterprise deployments. By the time there were NAS vendors deployi= ng, they
>> would test with both iOS and Android devices to validate support.<= br> >>
>> Basing our standards on the idea that devices (either networks or = UE's)
>> may implement the RFCs incorrectly seems to be a difficult startin= g point.
>>
>> I like the point you bring up of splitting network notifications f= rom web
>> APIs. There is a need to be judicious about what properties fall i= nto each
>> category. I think you're saying that the fact that there is a = captive
>> network can be signaled via ICMP, etc, as a network-level property= . While
>> ICMP is a fine solution for giving the UE hints when something has= expired,
>> I am concerned that (possibly unsolicited) network signaling is no= t the
>> correct mechanism for the content details of the network, whether = that is
>> the enterprise network properties, or the captive network Terms &a= mp;
>> Conditions, tokens, expiration timers, and URLs for various kinds = of user
>> interaction. An JSON API is one form of grabbing information=E2=80= =94I don't think
>> we should necessarily interpret that as something that is a high-l= evel Web
>> interaction. We could create some custom protocol over UDP like DN= S records
>> to get the information (that would be a lot of new protocol work h= ere that
>> people may not be willing to get into), but the key is that it nee= ds to be
>> the choice of a UE device that understands how to request and pars= e content
>> that initiates a lookup, and can fetch information from the networ= k
>> infrastructure.
>>
>> With regards to your assertion that we'll always revert to doi= ng a probe,
>> I still would like to believe that if we have a network that adver= tises a
>> PvD with no extended information, or extended information that doe= sn't
>> include a captive portal, we can avoid the probe altogether. Will = we still
>> have networks that redirect HTTP requests? Yes. But that's no = different from
>> the scenario today in which a network whitelists our captive detec= tion
>> probes. We can still get to a captive portal once the user goes in= to the
>> browser. We can stop doing probes whenever the RA on the network i= ndicates
>> that it supports explicit signaling about network properties. If a= network
>> operator wants to invoke the system-level captive interaction, the= n they
>> will follow the RFCs we come up in the CAPPORT group as long as UE= s end up
>> deploying support first. If they want to avoid it, or they have a = broken
>> network, things will be like networks that whitelist our probes to= day. Not
>> great, but still possible for the user to get through. My main goa= l in these
>> standards is to make it possible for a network to give the user a = good
>> experience; not to make it impossible for the user to have a sub-p= ar
>> experience (since I don't think that goal is achievable).
>>
>> Best,
>> Tommy
>>
>>
>> On Aug 18, 2017, at 5:52 PM, David Bird <dbird@google.com> wrote:
>>
>> Thanks Tommy,
>>
>> I don't dispute that PvD provides an elegant set of solutions = --
>> particularly in enterprise and other 'private' networks. I= question,
>> however, the value in public(/guest) access -- where everyone want= s you to
>> access their network over others, for 'retail analytic' or=
>> branding/attribution(/exploit) purposes.
>>
>> Another way to see the PvD integration/deployment:
>>
>> 1. Today, we join a network, always do a probe, which redirects to= captive
>> portal
>> 2. A PvD URL is provide, so a captive portal notification is gener= ated to
>> the user (is that what 'we just make a connection directly'= ; means?)
>> 3. We may have also gotten RFC7710 URL, there are potentially two = APIs in
>> play at the same time, which is extra confusing (?)
>> 4. The first NAS vendor release products with support, venues depl= oy and
>> start 'fiddling' with the new feature and URL to PvD end-p= oints
>> 5. The first UE vendor releases products with support, start using= it at
>> said venues... complain to vendor about problems unique to this ne= w device
>> 6. In some networks, users complain that *only* their new PvD devi= ce is
>> seeing a captive portal, while all their other devices do not. Sta= ff at the
>> coffee shop don't believe me; all their devices work too.
>>
>> I think there are fundamental issues in splitting what should be &= #39;network
>> notification' into web APIs....
>>
>> 1. Tomorrow, we join a network, always do a probe, which redirects= to
>> captive portal
>>
>> It wasn't clear in your e-mail if RFC7710 can be used *without= * providing
>> a URL, or is there a PvD specific DHCP option?
>>
>> Thanks,
>> David
>>
>>
>> On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly <tpauly@apple.com> wrote:
>>>
>>> Hi David,
>>>
>>> You mention in one of your emails that you'd expect there = to be many
>>> "broken PvD" deployments, which would either necessi= tate ignoring PvD and
>>> using legacy mechanisms, or else having the user face a broken= portal. My
>>> impression is that if client-side deployments fail closed=E2= =80=94that is, if there
>>> is a PvD advertised, but it does not work well, then we treat = the network as
>>> broken. If this client behavior is consistent from the start o= f deployment,
>>> then I would think that deployments would notice very quickly = if they are
>>> broken. The fundamental part of the PvD being advertised is in= the RAs=E2=80=94if
>>> our DHCP or RAs are broken on a network, we generally are goin= g to be broken
>>> anyhow.
>>>
>>> As far as where the API resides, I appreciate your explanation= of the
>>> various complexities. My initial take is this:
>>>
>>> - Where a PvD is being served is up to the deployment, and det= ermined by
>>> the entity that is providing the RAs. To that end, the server = that hosts the
>>> API for extended PvD information may be very different for
>>> enterprise/carrier scenarios than in captive portals for coffe= e shops.
>>> - For the initial take for Captive Portals, I would co-locate = the "PvD
>>> API" server with the "Captive API" and "Ca= ptive Web Server". Presumably, the
>>> device that was previously doing the HTTP redirects would be a= ble to do the
>>> similar coordination of making sure the PvD ID that is given o= ut to clients
>>> matches the PvD API server (which is the same as the "Cap= tive Web Server").
>>>
>>> For the captive use-case, I see the integration of PvDs as an = incremental
>>> step:
>>>
>>> 1. Today, we join a network, always do a probe, which may get = redirected
>>> to a captive web server
>>> 2. With RFC 7710, we would join a network and do the same as (= 1), unless
>>> the captive URL is given in the DHCP/RA and we just make a con= nection
>>> directly.
>>> 3. With the Captive API draft, we can interact with the portal= other than
>>> just showing a webpage; but this may still be bootstrapped by = 7710 if not
>>> using another mechanism
>>> 4. With PvDs, the mechanism in 7710 is generalized to support = APIs other
>>> than just captive, and can indicate that no captive portal or = other extended
>>> info is present; and the PvD API in this form is just a more g= eneric version
>>> of the captive API that allows us to use the same mechanism fo= r other
>>> network properties that aren't specifically captive (like = enterprise network
>>> extended info, or walled gardens)
>>>
>>> Getting into the arms race of people avoiding the captive prob= es: if
>>> someone doesn't want to interact with the client OS's = captive portal system,
>>> they can and likely will not change anything and just keep red= irecting
>>> pages. Hopefully if a better solution becomes prevalent enough= in the
>>> future, client OS's will be able to just ignore and reject= any network that
>>> redirects traffic, and the only supported captive portals woul= d be ones that
>>> interact in specified ways and advertise themselves as captive= networks. In
>>> order to get to this point, there certainly needs to be a carr= ot to
>>> incentivize adoption. My goal with the more flexible interacti= on supported
>>> by PvD is that we will allow the networks to provide a better = user
>>> experience to people joining their networks, and integrate wit= h client OS's
>>> to streamline the joining process (notification of the network= being
>>> available, who owns it, how to accept and how to pay), the mai= ntenance
>>> process (being able to integrate time left or bytes left on th= e network into
>>> the system UI), and what is allowed or not on the network.
>>>
>>> Thanks,
>>> Tommy
>>>
>>>
>>> On Aug 16, 2017, at 6:51 AM, David Bird <dbird@google.com> wrote:
>>>
>>> My question about where the PvD API resides was somewhat rheto= rical. In
>>> reality, I'm sure you will find all of the above - In the = NAS (e.g. Cisco),
>>> at the hotspot services provider, and something hosted next to= the venues
>>> website. It depends mostly on how this URL is configured, and = by whom. (One
>>> could imagine people doing all sorts of things).
>>>
>>> My question more specifically for the authors is, how would Ci= sco
>>> implement PvD for Guest/Public access and would it actively st= op avoiding
>>> Apple captive portal detection? Or, would turning on PvD just = make that
>>> 'feature' easier to implement?
>>>
>>> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline <ek@google.com> wrote:
>>>>
>>>> Randomly selecting Tommy and Eric so this bubbles up in th= eir inbox.
>>>>
>>>> On 2 August 2017 at 10:36, David Bird <dbird@google.com> wrote:
>>>> > Could an author of PvD help me understand the followi= ng questions for
>>>> > each
>>>> > of the diagrams below I found on the Internet -- whic= h represent some
>>>> > typical hotspot configurations out there...
>>>> >
>>>> > - Where would the API reside?
>>>> >
>>>> > - Who 'owns' the API?
>>>> >
>>>> > - How does the API keep in-sync with the NAS? Who'= ;s responsible for
>>>> > that
>>>> > (possibly multi-vendor, multi-AAA) integration?
>>>> >
>>>> > 1) Typical Hotspot service company outsourcing:
>>>> >
>>>> > http://cloudessa.com/wp-content/uploads/2013/08/shema-Cap= tivePortalSolution_beta2b.png
>>>> >
>>>> > 2) Same as above, except venue owns portal:
>>>> >
>>>> > http://cloudessa.com/wp-content/uploads/2013/07/= solutions_hotspots-co-working-cloudessa_2p1.png
>>>> >
>>>> > 3) Now consider the above, but the venue has more roa= ming partners and
>>>> > multi-realm RADIUS setup in their Cisco NAS:
>>>> >
>>>> > http://www.cisco.com/c/en/us/td/docs/wir= eless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_0100111.h= tml
>>>> > describes many options -- including separate MAC auth= entication
>>>> > sources,
>>>> > optional portals for 802.1x (RADIUS) authenticated us= ers, and so much
>>>> > more...
>>>> >
>>>> > "Cisco ISE supports internal and external identi= ty sources. Both
>>>> > sources can
>>>> > be used as an authentication source for sponsor-user = and guest-user
>>>> > authentication."
>>>> >
>>>> > Also note this interesting article:=C2=A0 the section= Information About
>>>> > Captive
>>>> > Bypassing and how it describes how to avoid Apple cap= tive portal
>>>> > detection!!! "If no response is received, then t= he Internet access is
>>>> > assumed to be blocked by the captive portal and Apple= =E2=80=99s Captive
>>>> > Network
>>>> > Assistant (CNA) auto-launches the pseudo-browser to r= equest portal
>>>> > login in
>>>> > a controlled window. The CNA may break when redirecti= ng to an ISE
>>>> > captive
>>>> > portal. The controller prevents this pseudo-browser f= rom popping up."
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________<= br> >>>> > Captive-portals mailing list
>>>> > Captive-p= ortals@ietf.org
>>>> > https://www.ietf.org/mail= man/listinfo/captive-portals
>>>> >
>>>
>>>
>>>
>>
>> _______________________________________________
>> Captive-portals mailing list
>> Captive-portals@ietf.o= rg
>> https://www.ietf.org/mailman/list= info/captive-portals
>>
>>
>
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinf= o/captive-portals
>

--001a114dc83c4673ea05575d2be2-- From nobody Tue Aug 22 16:38:52 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CF6132AD1 for ; Tue, 22 Aug 2017 16:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 S_XcfHVpteYF for ; Tue, 22 Aug 2017 16:38:46 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64DEB132ABB for ; Tue, 22 Aug 2017 16:38:44 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id y4so2103750iod.4 for ; Tue, 22 Aug 2017 16:38:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0fR3LpfBxKn+xA3XErAn/r2i7TolEATJFJXcOxeuQVU=; b=AgpfKuG9nQX02F88cwRopTIqozcyYfIDmpA3bf4hBJQ2fBLAzf/mGPivSyJpWikgS1 FRPKRkv5XluuEsMkWo3PGMqDqHjspG5JDz7BGLqr5ybcL49Vx5/mxxROVoSozX/QLz7E mE4aheEOZyNbs7MrdrlA8jSFT8MofS730TR/CFpsK69DcYYvG5MPiYbfwqyzm29wnmYn Zd5sjcVrXBOSLGqwtUoqYD86SIZBM7Q/xvx2wnbi8pQ0ViRtdDBE/T518Hx4rHKxQMJY b/i4u7fNA0O8LfI0clDielgxCmFCUA62lCBSHjMZdaxwx8yQM12rLbo4/GAQYf2XGwl0 kyEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0fR3LpfBxKn+xA3XErAn/r2i7TolEATJFJXcOxeuQVU=; b=BCgwzokk1rU905pGkqvOyZKgl7K8HdWbzjm76wQImrx+l22P5Yif4pO0PoAdEePzky 35wucesbbbTpPyGyjnmmSrP+QjBHozDNVm4K6pR4Flu3Sgdy/t2KUS1LhY+jC/54zBQ5 za1HlX2hVbj58uMOkepArRBCAhD5A6tBTyWti792du7jnlTNlJq+t5l1YJRlpA9EOKt7 EigvRAR+P2N37drrtAEvHjKY2CQtDikQniNv736SrqH0qJnnLlq8fWZXSj+QZWPLMUSX pOe5tEtsvC+TA2DSvW5lR7GGLsbuUy7Xvz73BAKooM08gNZPF4F+HGpYQb719CX9OBDl lmOQ== X-Gm-Message-State: AHYfb5gmeW/5qWDtgNujN184+ldktWWpmbdXnUZkcjS+Ovy+prGpbAGj uP6bvpOYI3EGReI22aR+GP5Is937ng== X-Received: by 10.107.180.72 with SMTP id d69mr473912iof.291.1503445123028; Tue, 22 Aug 2017 16:38:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Tue, 22 Aug 2017 16:38:42 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> From: Martin Thomson Date: Wed, 23 Aug 2017 09:38:42 +1000 Message-ID: To: David Bird Cc: Tommy Pauly , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Aug 2017 23:38:50 -0000 I wrote all of that text. I'm not sure that I get your point though. There's a discovery mechanism that is vulnerable to interception, etc..., but that (mostly) happens using network-local mechanisms (DHCP primarily). That's the only weak link. The identity is well known and authenticated once later interactions happen (the text on unsecured HTTP is a relic of a bygone era, no one actually implements that). In short, the design is to discover the identity of a service using those lower-layer primitives and then use that to bootstrap into something else. If your assertion is that PvD - as a discovery mechanism - is vulnerable, then the weakness is in the layer 3 parts, not in the bits that use HTTP. Those can (and should) be authenticated. Did I miss something? On 23 August 2017 at 06:09, David Bird wrote: > I don't think that is a fair comparison... > > Geolocation isn't anything enforced by the network... and clearly not > designed for public/guest access networks (as they exists today). > > You might re-read some of the Security Consideration in the docs surround= ing > GEOPRIV. > > HTTP-Enabled Location Delivery (HELD) > https://datatracker.ietf.org/doc/html/rfc5985#page-22 > > HELD is a location acquisition protocol whereby the client requests > its location from a LIS. Specific requirements and security > considerations for location acquisition protocols are provided in > [RFC5687]. An in-depth discussion of the security considerations > applicable to the use of Location URIs and by-reference provision of > LI is included in [RFC5808]. > > By using the HELD protocol, the client and the LIS expose themselves > to two types of risk: > > Accuracy: The client receives incorrect location information. > > Privacy: An unauthorized entity receives location information. > > The provision of an accurate and privacy- and confidentiality- > protected location to the requestor depends on the success of five > steps: > > 1. The client must determine the proper LIS. > > 2. The client must connect to the proper LIS. > > 3. The LIS must be able to identify the Device by its identifier (IP > address). > > 4. The LIS must be able to return the desired location. > > 5. HELD messages must be transmitted unmodified between the LIS and > the client. > > Of these, only steps 2, 3, and 5 are within the scope of this > document. Step 1 is based on either manual configuration or on the > LIS discovery defined in [RFC5986], in which appropriate security > considerations are already discussed. Step 4 is dependent on the > specific positioning capabilities of the LIS and is thus outside the > scope of this document. > > Discovering the Local Location Information Server (LIS) > https://datatracker.ietf.org/doc/html/rfc5986#page-11 > > The address of a LIS is usually well-known within an access network; > therefore, interception of messages does not introduce any specific > concerns. > > The primary attack against the methods described in this document is > one that would lead to impersonation of a LIS. The LIS is > responsible for providing location information, and this information > is critical to a number of network services; furthermore, a Device > does not necessarily have a prior relationship with a LIS. Several > methods are described here that can limit the probability of, or > provide some protection against, such an attack. These methods MUST > be applied unless similar protections are in place, or in cases -- > such as an emergency -- where location information of dubious origin > is arguably better than none at all. > > An attacker could attempt to compromise LIS discovery at any of three > stages: > > 1. providing a falsified domain name to be used as input to U-NAPTR > > 2. altering the DNS records used in U-NAPTR resolution > > 3. impersonating the LIS > > The domain name that used to authenticate the LIS is the domain name > input to the U-NAPTR process, not the output of that process > [RFC3958], [RFC4848]. As a result, the results of DNS queries do not > need integrity protection. > > An HTTPS URI is authenticated using the method described in Section > 3.1 of [RFC2818]. HTTP client implementations frequently do not > provide a means to authenticate based on a domain name other than the > one indicated in the request URI, namely the U-NAPTR output. To > avoid having to authenticate the LIS with a domain name that is > different from the one used to identify it, a client MAY choose to > reject URIs that contain a domain name that is different to the > U-NAPTR input. To support endpoints that enforce the above > restriction on URIs, network administrators SHOULD ensure that the > domain name in the DHCP option is the same as the one contained in > the resulting URI. > > Authentication of a LIS relies on the integrity of the domain name > acquired from DHCP. An attacker that is able to falsify a domain > name circumvents the protections provided. To ensure that the access > network domain name DHCP option can be relied upon, preventing DHCP > messages from being modified or spoofed by attackers is necessary. > Physical- or link-layer security are commonly used to reduce the > possibility of such an attack within an access network. DHCP > authentication [RFC3118] might also provide a degree of protection > against modification or spoofing. > > A LIS that is identified by an HTTP URI cannot be authenticated. Use > of unsecured HTTP also does not meet requirements in HELD for > confidentiality and integrity. If an HTTP URI is the product of LIS > discovery, this leaves Devices vulnerable to several attacks. Lower- > layer protections, such as Layer 2 traffic separation might be used > to provide some guarantees. > > Requirements for a Location-by-Reference Mechanism > https://datatracker.ietf.org/doc/html/rfc5808#page-12 > > The method of constructing the location URI to include randomized > components helps to prevent adversaries from obtaining location > information without ever retrieving a location URI. In the > possession model, a location URI, regardless of its construction, if > made publicly available, implies no safeguard against anyone being > able to dereference and get the location. Care has to be paid when > distributing such a location URI to the trusted location recipients. > When this aspect is of concern, the authorization model has to be > chosen. Even in this model, care has to be taken on how to construct > the authorization policies to ensure that only those parties have > access to location information that are considered trustworthy enough > to enforce the basic rule set that is attached to location > information in a PIDF-LO document. > > Any location URI, by necessity, indicates the server (name) that > hosts the location information. Knowledge of the server in some > specific domain could therefore reveal something about the location > of the Target. This kind of threat may be mitigated somewhat by > introducing another layer of indirection: namely the use of a > (remote) presence server. > > A covert channel for protocol message exchange is an important > consideration, given an example scenario where user A subscribes to > location information for user B, then every time A gets a location > update, an (external) observer of the subscription notification may > know that B has moved. One mitigation of this is to have periodic > notification, so that user B may appear to have moved even when > static. > > > > On Sun, Aug 20, 2017 at 6:34 PM, Martin Thomson > wrote: >> >> Hi David, >> >> Can you explain more about why you believe that a lower-layer protocol >> needs to be used? >> >> I remember a similar discussion about this about 10 years ago with >> GEOPRIV. Then it was asserted that DHCP was the only protocol that >> could deliver location information to user equipment. That discussion >> took a long time, but ultimately ended with an HTTP-based protocol. I >> have no desire to repeat that experience. >> >> It seems like this is - at least in part - based in how this might be >> configured. That is, you believe that a lower-layer protocol offers >> no option for misconfiguration. Is that correct? Have I missed >> something? >> >> >> On 20 August 2017 at 00:12, David Bird wrote: >> > HI Tommy, >> > >> > Agreed that RFC7710 is lacking notification of captive portal existenc= e, >> > it >> > only provides configuration information. ICMP would provide the >> > notification, as it does today for other forms of destination >> > unreachable, >> > port unreachable, etc. In your first reply, I thought you were >> > suggesting >> > that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clear wh= at >> > you >> > meant by DHCP/RA). >> > >> > I think we both also agree that taking about both a Capport API *and* >> > PvD is >> > adding to the confusion and we ultimately will not want two "APIs". >> > >> > ICMP today delivers more than hints... it provides signaling that can >> > directly influence traffic. Yes, there are security concerns around >> > ICMP, >> > which is why it is common for it to be filtered out of networks (which >> > is a >> > good think for Capport ICMP, it is only for the edge network). >> > >> > Regarding ICMP and the "content details of the network" ... I think th= at >> > statement conflates policy and enforcement. ICMP provides (as today) >> > notification of enforcement, and RFC7710 provides where to find out >> > about >> > the policy (ToS, etc). >> > >> > The JSON API becomes a "web service" when it has a http(s):// in front >> > of it >> > :) .. but, indeed, my concern is in the transport protocol. It being a >> > URL >> > signals that this is meant to be deployed alongside the portal, or >> > otherwise >> > 'remotely'... Vendors will likely have a "PvD URL: " configuration >> > dialog >> > ... and there will be many hotspot services companies updating their >> > "Howto" >> > instructions with their PvD URL info... it is a web service. >> > >> > I welcome suggestions that put that JSON API into a lower layer networ= k >> > protocol. We could stuff JSON into ICMP :) >> > >> > Maybe there is a way to merge ICMP and PvD -- to where ICMP provides t= he >> > notification (with tokens) and PvD provides the policy (based on these >> > tokens) (?) >> > >> > With regard to vendor (NAS/UE) cooperation, perhaps PvD could be a new >> > start, but thus far (as my quote of Cisco documentation suggests), it = is >> > more about what users/venues want. Cisco already today actively avoids >> > iOS >> > captive portal detection because the "pseudo-browser" (as they call it= ) >> > does >> > work with their portal. That is a problem that could be solve today by >> > Apple/Cisco, couldn't it? Just by not using the pseudo browser... >> > introducing PvD doesn't resolve the core problem there, but does make = it >> > easier to avoid that pseudo browser. >> > >> > You also said "We can still get to a captive portal once the user goes >> > into >> > the browser." ... However, this is increasingly untrue as the work mov= es >> > to >> > https... So, doing this avoidance of detection will still be a problem= . >> > >> > Cheers, >> > David >> > >> > >> > On Fri, Aug 18, 2017 at 7:23 PM, Tommy Pauly wrote: >> >> >> >> Hi David, >> >> >> >> My thoughts with regards to RFC 7710 is that it is not deployed as fa= r >> >> as >> >> I know, and no client stack respects the value sent in 7710. Without >> >> some >> >> API extensions, it isn't directly better than what we currently have. >> >> Ideally, this would not be an API that would get deployed if we were >> >> also >> >> using PvDs. My concern is that if PvDs are used for enterprise and >> >> private >> >> networks, we'll have a very similar but less complete path based on R= FC >> >> 7710. We could end up deprecating or replacing that RFC, which was >> >> mentioned >> >> in our last meeting. I don't think RFC 7710 can be used without a URL= , >> >> which >> >> is why I think we need a solution that does a better job of indicatin= g >> >> the >> >> lack of captive or other extended network info. >> >> >> >> I would hope that since both iOS and Android stack developers are >> >> working >> >> on the UE side, we would actually see UE deployment of PvDs before an= y >> >> captive vendors adopt PvDs, and we'd be standardizing around Cisco/et= c >> >> enterprise deployments. By the time there were NAS vendors deploying, >> >> they >> >> would test with both iOS and Android devices to validate support. >> >> >> >> Basing our standards on the idea that devices (either networks or UE'= s) >> >> may implement the RFCs incorrectly seems to be a difficult starting >> >> point. >> >> >> >> I like the point you bring up of splitting network notifications from >> >> web >> >> APIs. There is a need to be judicious about what properties fall into >> >> each >> >> category. I think you're saying that the fact that there is a captive >> >> network can be signaled via ICMP, etc, as a network-level property. >> >> While >> >> ICMP is a fine solution for giving the UE hints when something has >> >> expired, >> >> I am concerned that (possibly unsolicited) network signaling is not t= he >> >> correct mechanism for the content details of the network, whether tha= t >> >> is >> >> the enterprise network properties, or the captive network Terms & >> >> Conditions, tokens, expiration timers, and URLs for various kinds of >> >> user >> >> interaction. An JSON API is one form of grabbing information=E2=80=94= I don't >> >> think >> >> we should necessarily interpret that as something that is a high-leve= l >> >> Web >> >> interaction. We could create some custom protocol over UDP like DNS >> >> records >> >> to get the information (that would be a lot of new protocol work here >> >> that >> >> people may not be willing to get into), but the key is that it needs = to >> >> be >> >> the choice of a UE device that understands how to request and parse >> >> content >> >> that initiates a lookup, and can fetch information from the network >> >> infrastructure. >> >> >> >> With regards to your assertion that we'll always revert to doing a >> >> probe, >> >> I still would like to believe that if we have a network that advertis= es >> >> a >> >> PvD with no extended information, or extended information that doesn'= t >> >> include a captive portal, we can avoid the probe altogether. Will we >> >> still >> >> have networks that redirect HTTP requests? Yes. But that's no differe= nt >> >> from >> >> the scenario today in which a network whitelists our captive detectio= n >> >> probes. We can still get to a captive portal once the user goes into >> >> the >> >> browser. We can stop doing probes whenever the RA on the network >> >> indicates >> >> that it supports explicit signaling about network properties. If a >> >> network >> >> operator wants to invoke the system-level captive interaction, then >> >> they >> >> will follow the RFCs we come up in the CAPPORT group as long as UEs e= nd >> >> up >> >> deploying support first. If they want to avoid it, or they have a >> >> broken >> >> network, things will be like networks that whitelist our probes today= . >> >> Not >> >> great, but still possible for the user to get through. My main goal i= n >> >> these >> >> standards is to make it possible for a network to give the user a goo= d >> >> experience; not to make it impossible for the user to have a sub-par >> >> experience (since I don't think that goal is achievable). >> >> >> >> Best, >> >> Tommy >> >> >> >> >> >> On Aug 18, 2017, at 5:52 PM, David Bird wrote: >> >> >> >> Thanks Tommy, >> >> >> >> I don't dispute that PvD provides an elegant set of solutions -- >> >> particularly in enterprise and other 'private' networks. I question, >> >> however, the value in public(/guest) access -- where everyone wants y= ou >> >> to >> >> access their network over others, for 'retail analytic' or >> >> branding/attribution(/exploit) purposes. >> >> >> >> Another way to see the PvD integration/deployment: >> >> >> >> 1. Today, we join a network, always do a probe, which redirects to >> >> captive >> >> portal >> >> 2. A PvD URL is provide, so a captive portal notification is generate= d >> >> to >> >> the user (is that what 'we just make a connection directly' means?) >> >> 3. We may have also gotten RFC7710 URL, there are potentially two API= s >> >> in >> >> play at the same time, which is extra confusing (?) >> >> 4. The first NAS vendor release products with support, venues deploy >> >> and >> >> start 'fiddling' with the new feature and URL to PvD end-points >> >> 5. The first UE vendor releases products with support, start using it >> >> at >> >> said venues... complain to vendor about problems unique to this new >> >> device >> >> 6. In some networks, users complain that *only* their new PvD device = is >> >> seeing a captive portal, while all their other devices do not. Staff = at >> >> the >> >> coffee shop don't believe me; all their devices work too. >> >> >> >> I think there are fundamental issues in splitting what should be >> >> 'network >> >> notification' into web APIs.... >> >> >> >> 1. Tomorrow, we join a network, always do a probe, which redirects to >> >> captive portal >> >> >> >> It wasn't clear in your e-mail if RFC7710 can be used *without* >> >> providing >> >> a URL, or is there a PvD specific DHCP option? >> >> >> >> Thanks, >> >> David >> >> >> >> >> >> On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly wrote= : >> >>> >> >>> Hi David, >> >>> >> >>> You mention in one of your emails that you'd expect there to be many >> >>> "broken PvD" deployments, which would either necessitate ignoring Pv= D >> >>> and >> >>> using legacy mechanisms, or else having the user face a broken porta= l. >> >>> My >> >>> impression is that if client-side deployments fail closed=E2=80=94th= at is, if >> >>> there >> >>> is a PvD advertised, but it does not work well, then we treat the >> >>> network as >> >>> broken. If this client behavior is consistent from the start of >> >>> deployment, >> >>> then I would think that deployments would notice very quickly if the= y >> >>> are >> >>> broken. The fundamental part of the PvD being advertised is in the >> >>> RAs=E2=80=94if >> >>> our DHCP or RAs are broken on a network, we generally are going to b= e >> >>> broken >> >>> anyhow. >> >>> >> >>> As far as where the API resides, I appreciate your explanation of th= e >> >>> various complexities. My initial take is this: >> >>> >> >>> - Where a PvD is being served is up to the deployment, and determine= d >> >>> by >> >>> the entity that is providing the RAs. To that end, the server that >> >>> hosts the >> >>> API for extended PvD information may be very different for >> >>> enterprise/carrier scenarios than in captive portals for coffee shop= s. >> >>> - For the initial take for Captive Portals, I would co-locate the "P= vD >> >>> API" server with the "Captive API" and "Captive Web Server". >> >>> Presumably, the >> >>> device that was previously doing the HTTP redirects would be able to >> >>> do the >> >>> similar coordination of making sure the PvD ID that is given out to >> >>> clients >> >>> matches the PvD API server (which is the same as the "Captive Web >> >>> Server"). >> >>> >> >>> For the captive use-case, I see the integration of PvDs as an >> >>> incremental >> >>> step: >> >>> >> >>> 1. Today, we join a network, always do a probe, which may get >> >>> redirected >> >>> to a captive web server >> >>> 2. With RFC 7710, we would join a network and do the same as (1), >> >>> unless >> >>> the captive URL is given in the DHCP/RA and we just make a connectio= n >> >>> directly. >> >>> 3. With the Captive API draft, we can interact with the portal other >> >>> than >> >>> just showing a webpage; but this may still be bootstrapped by 7710 i= f >> >>> not >> >>> using another mechanism >> >>> 4. With PvDs, the mechanism in 7710 is generalized to support APIs >> >>> other >> >>> than just captive, and can indicate that no captive portal or other >> >>> extended >> >>> info is present; and the PvD API in this form is just a more generic >> >>> version >> >>> of the captive API that allows us to use the same mechanism for othe= r >> >>> network properties that aren't specifically captive (like enterprise >> >>> network >> >>> extended info, or walled gardens) >> >>> >> >>> Getting into the arms race of people avoiding the captive probes: if >> >>> someone doesn't want to interact with the client OS's captive portal >> >>> system, >> >>> they can and likely will not change anything and just keep redirecti= ng >> >>> pages. Hopefully if a better solution becomes prevalent enough in th= e >> >>> future, client OS's will be able to just ignore and reject any netwo= rk >> >>> that >> >>> redirects traffic, and the only supported captive portals would be >> >>> ones that >> >>> interact in specified ways and advertise themselves as captive >> >>> networks. In >> >>> order to get to this point, there certainly needs to be a carrot to >> >>> incentivize adoption. My goal with the more flexible interaction >> >>> supported >> >>> by PvD is that we will allow the networks to provide a better user >> >>> experience to people joining their networks, and integrate with clie= nt >> >>> OS's >> >>> to streamline the joining process (notification of the network being >> >>> available, who owns it, how to accept and how to pay), the maintenan= ce >> >>> process (being able to integrate time left or bytes left on the >> >>> network into >> >>> the system UI), and what is allowed or not on the network. >> >>> >> >>> Thanks, >> >>> Tommy >> >>> >> >>> >> >>> On Aug 16, 2017, at 6:51 AM, David Bird wrote: >> >>> >> >>> My question about where the PvD API resides was somewhat rhetorical. >> >>> In >> >>> reality, I'm sure you will find all of the above - In the NAS (e.g. >> >>> Cisco), >> >>> at the hotspot services provider, and something hosted next to the >> >>> venues >> >>> website. It depends mostly on how this URL is configured, and by who= m. >> >>> (One >> >>> could imagine people doing all sorts of things). >> >>> >> >>> My question more specifically for the authors is, how would Cisco >> >>> implement PvD for Guest/Public access and would it actively stop >> >>> avoiding >> >>> Apple captive portal detection? Or, would turning on PvD just make >> >>> that >> >>> 'feature' easier to implement? >> >>> >> >>> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline wrote: >> >>>> >> >>>> Randomly selecting Tommy and Eric so this bubbles up in their inbox= . >> >>>> >> >>>> On 2 August 2017 at 10:36, David Bird wrote: >> >>>> > Could an author of PvD help me understand the following questions >> >>>> > for >> >>>> > each >> >>>> > of the diagrams below I found on the Internet -- which represent >> >>>> > some >> >>>> > typical hotspot configurations out there... >> >>>> > >> >>>> > - Where would the API reside? >> >>>> > >> >>>> > - Who 'owns' the API? >> >>>> > >> >>>> > - How does the API keep in-sync with the NAS? Who's responsible f= or >> >>>> > that >> >>>> > (possibly multi-vendor, multi-AAA) integration? >> >>>> > >> >>>> > 1) Typical Hotspot service company outsourcing: >> >>>> > >> >>>> > >> >>>> > http://cloudessa.com/wp-content/uploads/2013/08/shema-CaptivePort= alSolution_beta2b.png >> >>>> > >> >>>> > 2) Same as above, except venue owns portal: >> >>>> > >> >>>> > >> >>>> > http://cloudessa.com/wp-content/uploads/2013/07/solutions_hotspot= s-co-working-cloudessa_2p1.png >> >>>> > >> >>>> > 3) Now consider the above, but the venue has more roaming partner= s >> >>>> > and >> >>>> > multi-realm RADIUS setup in their Cisco NAS: >> >>>> > >> >>>> > >> >>>> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-3/conf= ig-guide/b_cg83/b_cg83_chapter_0100111.html >> >>>> > describes many options -- including separate MAC authentication >> >>>> > sources, >> >>>> > optional portals for 802.1x (RADIUS) authenticated users, and so >> >>>> > much >> >>>> > more... >> >>>> > >> >>>> > "Cisco ISE supports internal and external identity sources. Both >> >>>> > sources can >> >>>> > be used as an authentication source for sponsor-user and guest-us= er >> >>>> > authentication." >> >>>> > >> >>>> > Also note this interesting article: the section Information Abou= t >> >>>> > Captive >> >>>> > Bypassing and how it describes how to avoid Apple captive portal >> >>>> > detection!!! "If no response is received, then the Internet acces= s >> >>>> > is >> >>>> > assumed to be blocked by the captive portal and Apple=E2=80=99s C= aptive >> >>>> > Network >> >>>> > Assistant (CNA) auto-launches the pseudo-browser to request porta= l >> >>>> > login in >> >>>> > a controlled window. The CNA may break when redirecting to an ISE >> >>>> > captive >> >>>> > portal. The controller prevents this pseudo-browser from popping >> >>>> > up." >> >>>> > >> >>>> > >> >>>> > >> >>>> > _______________________________________________ >> >>>> > Captive-portals mailing list >> >>>> > Captive-portals@ietf.org >> >>>> > https://www.ietf.org/mailman/listinfo/captive-portals >> >>>> > >> >>> >> >>> >> >>> >> >> >> >> _______________________________________________ >> >> Captive-portals mailing list >> >> Captive-portals@ietf.org >> >> https://www.ietf.org/mailman/listinfo/captive-portals >> >> >> >> >> > >> > >> > _______________________________________________ >> > Captive-portals mailing list >> > Captive-portals@ietf.org >> > https://www.ietf.org/mailman/listinfo/captive-portals >> > > > From nobody Thu Aug 24 06:40:57 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03021132944 for ; Thu, 24 Aug 2017 06:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_WP_DIRINDEX=1] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 rL4yVM4G7_BB for ; Thu, 24 Aug 2017 06:40:51 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 962B91326F4 for ; Thu, 24 Aug 2017 06:40:51 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id a1so3145822qti.0 for ; Thu, 24 Aug 2017 06:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q0ni60vmYC+VAyWL2w3GvGKPg0ol0jyyc/coIX+aDWw=; b=KjMOFUHvdV1F49pabFcxIv+HbRzJgprAUCDKwIFsieruFOoG1Oz/jLteRnlLYBUSIz DjUIrIfB0VsuHKq96CyeNMa6lTObHsfnCwHGLQHNDyAVK0XkLlzAlBUAPbphy6gSdJgm ZdpFo77l5O2GVxI+7kH5YgPeE7t7O24G6PW/yaxR1xXsgoIZUn304Da/x1s/KjtsC0mv bIhua7ZQM4qeESZPmeSPKoJ1643DYPXez0rRfyjvy1elAsZ9QbWohsN9OV5ARn5s1ySM dXJ/b+bvM0BupmW2/menS6I/Jxr5pywperNrv4KIl1oQPT7w2nT4b/9umZMe+bjSSEKF RF2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q0ni60vmYC+VAyWL2w3GvGKPg0ol0jyyc/coIX+aDWw=; b=D1+HZe8Fd6DfRge3763z8CiZwIZOKivddzpTf44rN5OYsxbPyYO4l57nrIOwW/l6y0 o9ChD0B1Fm3qRaR12fFlxDcyXSoU5Co26HNJ1dLlegw3dOqtUoJb54PA2knpiPT1RkB2 aqHlF3rPp/y5mEy9ms3c/bbhtYqodnw5mB2S9CEHss3oXLnHRzIDDIkJEngmAHliVNNd p3vGc4Jt29GE/IDFREOTwzdY1B5AFbPO47fwPd1RCKF9WYcIKk3Kwv8e0r+F5wgEcN+k NnOSEplzqHJ2fgNL5V5reSukna0pgdQ/8ExswOqbGkDWBvTdBipTlxMNfhzLZrkVoSQM yOUg== X-Gm-Message-State: AHYfb5jBoUhuEfS1rVsdXlODRaWv+YYBu0hd5jBGR4+veoaPhZkM2cXP fqUO5PMG3tX02nSK+ay7ShtrWqO8xfTi X-Google-Smtp-Source: ADKCNb7vI09D+XJ5zZJEeEJj4M6t8kOd8lH/4K1s1c7ezMWtOCSxJ3pvrIDVikrgdRxw3rVI9FHwVT4LMnJ+gQMYwwU= X-Received: by 10.237.35.47 with SMTP id h44mr9370040qtc.44.1503582049971; Thu, 24 Aug 2017 06:40:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Thu, 24 Aug 2017 06:40:48 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> From: David Bird Date: Thu, 24 Aug 2017 06:40:48 -0700 Message-ID: To: Martin Thomson Cc: Tommy Pauly , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org Content-Type: multipart/alternative; boundary="001a113568b4fb4d2d05577ff900" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 13:40:56 -0000 --001a113568b4fb4d2d05577ff900 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, that is more or less my point exactly... One problem people seem to have with ICMP and think PvD is the solution is around security. You brought up GEOPRIV as an example of that. However, as you said, "Those can (and should) be authenticated". In public access (where you can't punt security to "Lower-layer protections, such as Layer 2 traffic separation might be used to provide some guarantees."), maybe that statement would be upgraded to "Those MUST be authenticated". In RFC 5687 is says " The client MUST authenticate the discovered LIS." ... however, I'm not clear what "authenticate" means here. My assumption is that is means more than just a valid SSL cert of an unfamiliar hostname (like you would expect in public/guest access PvD). And, yes, I absolutely believe we will have a higher rate of misconfiguration using the L7/Application layer... To quote myself from earlier in the thread: Vendors will likely have a "PvD URL: " configuration dialog ... and there will be many hotspot services companies updating their "Howto" instructions with their PvD URL info... pretty darn easy to misconfigure. Can you give an example of how ICMP could be misconfigured? On Tue, Aug 22, 2017 at 4:38 PM, Martin Thomson wrote: > I wrote all of that text. I'm not sure that I get your point though. > There's a discovery mechanism that is vulnerable to interception, > etc..., but that (mostly) happens using network-local mechanisms (DHCP > primarily). That's the only weak link. The identity is well known > and authenticated once later interactions happen (the text on > unsecured HTTP is a relic of a bygone era, no one actually implements > that). > > In short, the design is to discover the identity of a service using > those lower-layer primitives and then use that to bootstrap into > something else. If your assertion is that PvD - as a discovery > mechanism - is vulnerable, then the weakness is in the layer 3 parts, > not in the bits that use HTTP. Those can (and should) be > authenticated. > > Did I miss something? > > On 23 August 2017 at 06:09, David Bird wrote: > > I don't think that is a fair comparison... > > > > Geolocation isn't anything enforced by the network... and clearly not > > designed for public/guest access networks (as they exists today). > > > > You might re-read some of the Security Consideration in the docs > surrounding > > GEOPRIV. > > > > HTTP-Enabled Location Delivery (HELD) > > https://datatracker.ietf.org/doc/html/rfc5985#page-22 > > > > HELD is a location acquisition protocol whereby the client requests > > its location from a LIS. Specific requirements and security > > considerations for location acquisition protocols are provided in > > [RFC5687]. An in-depth discussion of the security considerations > > applicable to the use of Location URIs and by-reference provision of > > LI is included in [RFC5808]. > > > > By using the HELD protocol, the client and the LIS expose themselves > > to two types of risk: > > > > Accuracy: The client receives incorrect location information. > > > > Privacy: An unauthorized entity receives location information. > > > > The provision of an accurate and privacy- and confidentiality- > > protected location to the requestor depends on the success of five > > steps: > > > > 1. The client must determine the proper LIS. > > > > 2. The client must connect to the proper LIS. > > > > 3. The LIS must be able to identify the Device by its identifier (I= P > > address). > > > > 4. The LIS must be able to return the desired location. > > > > 5. HELD messages must be transmitted unmodified between the LIS and > > the client. > > > > Of these, only steps 2, 3, and 5 are within the scope of this > > document. Step 1 is based on either manual configuration or on the > > LIS discovery defined in [RFC5986], in which appropriate security > > considerations are already discussed. Step 4 is dependent on the > > specific positioning capabilities of the LIS and is thus outside the > > scope of this document. > > > > Discovering the Local Location Information Server (LIS) > > https://datatracker.ietf.org/doc/html/rfc5986#page-11 > > > > The address of a LIS is usually well-known within an access network; > > therefore, interception of messages does not introduce any specific > > concerns. > > > > The primary attack against the methods described in this document is > > one that would lead to impersonation of a LIS. The LIS is > > responsible for providing location information, and this information > > is critical to a number of network services; furthermore, a Device > > does not necessarily have a prior relationship with a LIS. Several > > methods are described here that can limit the probability of, or > > provide some protection against, such an attack. These methods MUST > > be applied unless similar protections are in place, or in cases -- > > such as an emergency -- where location information of dubious origin > > is arguably better than none at all. > > > > An attacker could attempt to compromise LIS discovery at any of thre= e > > stages: > > > > 1. providing a falsified domain name to be used as input to U-NAPTR > > > > 2. altering the DNS records used in U-NAPTR resolution > > > > 3. impersonating the LIS > > > > The domain name that used to authenticate the LIS is the domain name > > input to the U-NAPTR process, not the output of that process > > [RFC3958], [RFC4848]. As a result, the results of DNS queries do no= t > > need integrity protection. > > > > An HTTPS URI is authenticated using the method described in Section > > 3.1 of [RFC2818]. HTTP client implementations frequently do not > > provide a means to authenticate based on a domain name other than th= e > > one indicated in the request URI, namely the U-NAPTR output. To > > avoid having to authenticate the LIS with a domain name that is > > different from the one used to identify it, a client MAY choose to > > reject URIs that contain a domain name that is different to the > > U-NAPTR input. To support endpoints that enforce the above > > restriction on URIs, network administrators SHOULD ensure that the > > domain name in the DHCP option is the same as the one contained in > > the resulting URI. > > > > Authentication of a LIS relies on the integrity of the domain name > > acquired from DHCP. An attacker that is able to falsify a domain > > name circumvents the protections provided. To ensure that the acces= s > > network domain name DHCP option can be relied upon, preventing DHCP > > messages from being modified or spoofed by attackers is necessary. > > Physical- or link-layer security are commonly used to reduce the > > possibility of such an attack within an access network. DHCP > > authentication [RFC3118] might also provide a degree of protection > > against modification or spoofing. > > > > A LIS that is identified by an HTTP URI cannot be authenticated. Us= e > > of unsecured HTTP also does not meet requirements in HELD for > > confidentiality and integrity. If an HTTP URI is the product of LIS > > discovery, this leaves Devices vulnerable to several attacks. Lower= - > > layer protections, such as Layer 2 traffic separation might be used > > to provide some guarantees. > > > > Requirements for a Location-by-Reference Mechanism > > https://datatracker.ietf.org/doc/html/rfc5808#page-12 > > > > The method of constructing the location URI to include randomized > > components helps to prevent adversaries from obtaining location > > information without ever retrieving a location URI. In the > > possession model, a location URI, regardless of its construction, if > > made publicly available, implies no safeguard against anyone being > > able to dereference and get the location. Care has to be paid when > > distributing such a location URI to the trusted location recipients. > > When this aspect is of concern, the authorization model has to be > > chosen. Even in this model, care has to be taken on how to construc= t > > the authorization policies to ensure that only those parties have > > access to location information that are considered trustworthy enoug= h > > to enforce the basic rule set that is attached to location > > information in a PIDF-LO document. > > > > Any location URI, by necessity, indicates the server (name) that > > hosts the location information. Knowledge of the server in some > > specific domain could therefore reveal something about the location > > of the Target. This kind of threat may be mitigated somewhat by > > introducing another layer of indirection: namely the use of a > > (remote) presence server. > > > > A covert channel for protocol message exchange is an important > > consideration, given an example scenario where user A subscribes to > > location information for user B, then every time A gets a location > > update, an (external) observer of the subscription notification may > > know that B has moved. One mitigation of this is to have periodic > > notification, so that user B may appear to have moved even when > > static. > > > > > > > > On Sun, Aug 20, 2017 at 6:34 PM, Martin Thomson < > martin.thomson@gmail.com> > > wrote: > >> > >> Hi David, > >> > >> Can you explain more about why you believe that a lower-layer protocol > >> needs to be used? > >> > >> I remember a similar discussion about this about 10 years ago with > >> GEOPRIV. Then it was asserted that DHCP was the only protocol that > >> could deliver location information to user equipment. That discussion > >> took a long time, but ultimately ended with an HTTP-based protocol. I > >> have no desire to repeat that experience. > >> > >> It seems like this is - at least in part - based in how this might be > >> configured. That is, you believe that a lower-layer protocol offers > >> no option for misconfiguration. Is that correct? Have I missed > >> something? > >> > >> > >> On 20 August 2017 at 00:12, David Bird wrote: > >> > HI Tommy, > >> > > >> > Agreed that RFC7710 is lacking notification of captive portal > existence, > >> > it > >> > only provides configuration information. ICMP would provide the > >> > notification, as it does today for other forms of destination > >> > unreachable, > >> > port unreachable, etc. In your first reply, I thought you were > >> > suggesting > >> > that RFC7710 was at play along side PvD DHCP/RA (and I wasn't clear > what > >> > you > >> > meant by DHCP/RA). > >> > > >> > I think we both also agree that taking about both a Capport API *and= * > >> > PvD is > >> > adding to the confusion and we ultimately will not want two "APIs". > >> > > >> > ICMP today delivers more than hints... it provides signaling that ca= n > >> > directly influence traffic. Yes, there are security concerns around > >> > ICMP, > >> > which is why it is common for it to be filtered out of networks (whi= ch > >> > is a > >> > good think for Capport ICMP, it is only for the edge network). > >> > > >> > Regarding ICMP and the "content details of the network" ... I think > that > >> > statement conflates policy and enforcement. ICMP provides (as today) > >> > notification of enforcement, and RFC7710 provides where to find out > >> > about > >> > the policy (ToS, etc). > >> > > >> > The JSON API becomes a "web service" when it has a http(s):// in fro= nt > >> > of it > >> > :) .. but, indeed, my concern is in the transport protocol. It being= a > >> > URL > >> > signals that this is meant to be deployed alongside the portal, or > >> > otherwise > >> > 'remotely'... Vendors will likely have a "PvD URL: " configuration > >> > dialog > >> > ... and there will be many hotspot services companies updating their > >> > "Howto" > >> > instructions with their PvD URL info... it is a web service. > >> > > >> > I welcome suggestions that put that JSON API into a lower layer > network > >> > protocol. We could stuff JSON into ICMP :) > >> > > >> > Maybe there is a way to merge ICMP and PvD -- to where ICMP provides > the > >> > notification (with tokens) and PvD provides the policy (based on the= se > >> > tokens) (?) > >> > > >> > With regard to vendor (NAS/UE) cooperation, perhaps PvD could be a n= ew > >> > start, but thus far (as my quote of Cisco documentation suggests), i= t > is > >> > more about what users/venues want. Cisco already today actively avoi= ds > >> > iOS > >> > captive portal detection because the "pseudo-browser" (as they call > it) > >> > does > >> > work with their portal. That is a problem that could be solve today = by > >> > Apple/Cisco, couldn't it? Just by not using the pseudo browser... > >> > introducing PvD doesn't resolve the core problem there, but does mak= e > it > >> > easier to avoid that pseudo browser. > >> > > >> > You also said "We can still get to a captive portal once the user go= es > >> > into > >> > the browser." ... However, this is increasingly untrue as the work > moves > >> > to > >> > https... So, doing this avoidance of detection will still be a > problem. > >> > > >> > Cheers, > >> > David > >> > > >> > > >> > On Fri, Aug 18, 2017 at 7:23 PM, Tommy Pauly > wrote: > >> >> > >> >> Hi David, > >> >> > >> >> My thoughts with regards to RFC 7710 is that it is not deployed as > far > >> >> as > >> >> I know, and no client stack respects the value sent in 7710. Withou= t > >> >> some > >> >> API extensions, it isn't directly better than what we currently hav= e. > >> >> Ideally, this would not be an API that would get deployed if we wer= e > >> >> also > >> >> using PvDs. My concern is that if PvDs are used for enterprise and > >> >> private > >> >> networks, we'll have a very similar but less complete path based on > RFC > >> >> 7710. We could end up deprecating or replacing that RFC, which was > >> >> mentioned > >> >> in our last meeting. I don't think RFC 7710 can be used without a > URL, > >> >> which > >> >> is why I think we need a solution that does a better job of > indicating > >> >> the > >> >> lack of captive or other extended network info. > >> >> > >> >> I would hope that since both iOS and Android stack developers are > >> >> working > >> >> on the UE side, we would actually see UE deployment of PvDs before > any > >> >> captive vendors adopt PvDs, and we'd be standardizing around > Cisco/etc > >> >> enterprise deployments. By the time there were NAS vendors deployin= g, > >> >> they > >> >> would test with both iOS and Android devices to validate support. > >> >> > >> >> Basing our standards on the idea that devices (either networks or > UE's) > >> >> may implement the RFCs incorrectly seems to be a difficult starting > >> >> point. > >> >> > >> >> I like the point you bring up of splitting network notifications fr= om > >> >> web > >> >> APIs. There is a need to be judicious about what properties fall in= to > >> >> each > >> >> category. I think you're saying that the fact that there is a capti= ve > >> >> network can be signaled via ICMP, etc, as a network-level property. > >> >> While > >> >> ICMP is a fine solution for giving the UE hints when something has > >> >> expired, > >> >> I am concerned that (possibly unsolicited) network signaling is not > the > >> >> correct mechanism for the content details of the network, whether > that > >> >> is > >> >> the enterprise network properties, or the captive network Terms & > >> >> Conditions, tokens, expiration timers, and URLs for various kinds o= f > >> >> user > >> >> interaction. An JSON API is one form of grabbing information=E2=80= =94I don't > >> >> think > >> >> we should necessarily interpret that as something that is a > high-level > >> >> Web > >> >> interaction. We could create some custom protocol over UDP like DNS > >> >> records > >> >> to get the information (that would be a lot of new protocol work he= re > >> >> that > >> >> people may not be willing to get into), but the key is that it need= s > to > >> >> be > >> >> the choice of a UE device that understands how to request and parse > >> >> content > >> >> that initiates a lookup, and can fetch information from the network > >> >> infrastructure. > >> >> > >> >> With regards to your assertion that we'll always revert to doing a > >> >> probe, > >> >> I still would like to believe that if we have a network that > advertises > >> >> a > >> >> PvD with no extended information, or extended information that > doesn't > >> >> include a captive portal, we can avoid the probe altogether. Will w= e > >> >> still > >> >> have networks that redirect HTTP requests? Yes. But that's no > different > >> >> from > >> >> the scenario today in which a network whitelists our captive > detection > >> >> probes. We can still get to a captive portal once the user goes int= o > >> >> the > >> >> browser. We can stop doing probes whenever the RA on the network > >> >> indicates > >> >> that it supports explicit signaling about network properties. If a > >> >> network > >> >> operator wants to invoke the system-level captive interaction, then > >> >> they > >> >> will follow the RFCs we come up in the CAPPORT group as long as UEs > end > >> >> up > >> >> deploying support first. If they want to avoid it, or they have a > >> >> broken > >> >> network, things will be like networks that whitelist our probes > today. > >> >> Not > >> >> great, but still possible for the user to get through. My main goal > in > >> >> these > >> >> standards is to make it possible for a network to give the user a > good > >> >> experience; not to make it impossible for the user to have a sub-pa= r > >> >> experience (since I don't think that goal is achievable). > >> >> > >> >> Best, > >> >> Tommy > >> >> > >> >> > >> >> On Aug 18, 2017, at 5:52 PM, David Bird wrote: > >> >> > >> >> Thanks Tommy, > >> >> > >> >> I don't dispute that PvD provides an elegant set of solutions -- > >> >> particularly in enterprise and other 'private' networks. I question= , > >> >> however, the value in public(/guest) access -- where everyone wants > you > >> >> to > >> >> access their network over others, for 'retail analytic' or > >> >> branding/attribution(/exploit) purposes. > >> >> > >> >> Another way to see the PvD integration/deployment: > >> >> > >> >> 1. Today, we join a network, always do a probe, which redirects to > >> >> captive > >> >> portal > >> >> 2. A PvD URL is provide, so a captive portal notification is > generated > >> >> to > >> >> the user (is that what 'we just make a connection directly' means?) > >> >> 3. We may have also gotten RFC7710 URL, there are potentially two > APIs > >> >> in > >> >> play at the same time, which is extra confusing (?) > >> >> 4. The first NAS vendor release products with support, venues deplo= y > >> >> and > >> >> start 'fiddling' with the new feature and URL to PvD end-points > >> >> 5. The first UE vendor releases products with support, start using = it > >> >> at > >> >> said venues... complain to vendor about problems unique to this new > >> >> device > >> >> 6. In some networks, users complain that *only* their new PvD devic= e > is > >> >> seeing a captive portal, while all their other devices do not. Staf= f > at > >> >> the > >> >> coffee shop don't believe me; all their devices work too. > >> >> > >> >> I think there are fundamental issues in splitting what should be > >> >> 'network > >> >> notification' into web APIs.... > >> >> > >> >> 1. Tomorrow, we join a network, always do a probe, which redirects = to > >> >> captive portal > >> >> > >> >> It wasn't clear in your e-mail if RFC7710 can be used *without* > >> >> providing > >> >> a URL, or is there a PvD specific DHCP option? > >> >> > >> >> Thanks, > >> >> David > >> >> > >> >> > >> >> On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly > wrote: > >> >>> > >> >>> Hi David, > >> >>> > >> >>> You mention in one of your emails that you'd expect there to be ma= ny > >> >>> "broken PvD" deployments, which would either necessitate ignoring > PvD > >> >>> and > >> >>> using legacy mechanisms, or else having the user face a broken > portal. > >> >>> My > >> >>> impression is that if client-side deployments fail closed=E2=80=94= that is, > if > >> >>> there > >> >>> is a PvD advertised, but it does not work well, then we treat the > >> >>> network as > >> >>> broken. If this client behavior is consistent from the start of > >> >>> deployment, > >> >>> then I would think that deployments would notice very quickly if > they > >> >>> are > >> >>> broken. The fundamental part of the PvD being advertised is in the > >> >>> RAs=E2=80=94if > >> >>> our DHCP or RAs are broken on a network, we generally are going to > be > >> >>> broken > >> >>> anyhow. > >> >>> > >> >>> As far as where the API resides, I appreciate your explanation of > the > >> >>> various complexities. My initial take is this: > >> >>> > >> >>> - Where a PvD is being served is up to the deployment, and > determined > >> >>> by > >> >>> the entity that is providing the RAs. To that end, the server that > >> >>> hosts the > >> >>> API for extended PvD information may be very different for > >> >>> enterprise/carrier scenarios than in captive portals for coffee > shops. > >> >>> - For the initial take for Captive Portals, I would co-locate the > "PvD > >> >>> API" server with the "Captive API" and "Captive Web Server". > >> >>> Presumably, the > >> >>> device that was previously doing the HTTP redirects would be able = to > >> >>> do the > >> >>> similar coordination of making sure the PvD ID that is given out t= o > >> >>> clients > >> >>> matches the PvD API server (which is the same as the "Captive Web > >> >>> Server"). > >> >>> > >> >>> For the captive use-case, I see the integration of PvDs as an > >> >>> incremental > >> >>> step: > >> >>> > >> >>> 1. Today, we join a network, always do a probe, which may get > >> >>> redirected > >> >>> to a captive web server > >> >>> 2. With RFC 7710, we would join a network and do the same as (1), > >> >>> unless > >> >>> the captive URL is given in the DHCP/RA and we just make a > connection > >> >>> directly. > >> >>> 3. With the Captive API draft, we can interact with the portal oth= er > >> >>> than > >> >>> just showing a webpage; but this may still be bootstrapped by 7710 > if > >> >>> not > >> >>> using another mechanism > >> >>> 4. With PvDs, the mechanism in 7710 is generalized to support APIs > >> >>> other > >> >>> than just captive, and can indicate that no captive portal or othe= r > >> >>> extended > >> >>> info is present; and the PvD API in this form is just a more gener= ic > >> >>> version > >> >>> of the captive API that allows us to use the same mechanism for > other > >> >>> network properties that aren't specifically captive (like enterpri= se > >> >>> network > >> >>> extended info, or walled gardens) > >> >>> > >> >>> Getting into the arms race of people avoiding the captive probes: = if > >> >>> someone doesn't want to interact with the client OS's captive port= al > >> >>> system, > >> >>> they can and likely will not change anything and just keep > redirecting > >> >>> pages. Hopefully if a better solution becomes prevalent enough in > the > >> >>> future, client OS's will be able to just ignore and reject any > network > >> >>> that > >> >>> redirects traffic, and the only supported captive portals would be > >> >>> ones that > >> >>> interact in specified ways and advertise themselves as captive > >> >>> networks. In > >> >>> order to get to this point, there certainly needs to be a carrot t= o > >> >>> incentivize adoption. My goal with the more flexible interaction > >> >>> supported > >> >>> by PvD is that we will allow the networks to provide a better user > >> >>> experience to people joining their networks, and integrate with > client > >> >>> OS's > >> >>> to streamline the joining process (notification of the network bei= ng > >> >>> available, who owns it, how to accept and how to pay), the > maintenance > >> >>> process (being able to integrate time left or bytes left on the > >> >>> network into > >> >>> the system UI), and what is allowed or not on the network. > >> >>> > >> >>> Thanks, > >> >>> Tommy > >> >>> > >> >>> > >> >>> On Aug 16, 2017, at 6:51 AM, David Bird wrote: > >> >>> > >> >>> My question about where the PvD API resides was somewhat rhetorica= l. > >> >>> In > >> >>> reality, I'm sure you will find all of the above - In the NAS (e.g= . > >> >>> Cisco), > >> >>> at the hotspot services provider, and something hosted next to the > >> >>> venues > >> >>> website. It depends mostly on how this URL is configured, and by > whom. > >> >>> (One > >> >>> could imagine people doing all sorts of things). > >> >>> > >> >>> My question more specifically for the authors is, how would Cisco > >> >>> implement PvD for Guest/Public access and would it actively stop > >> >>> avoiding > >> >>> Apple captive portal detection? Or, would turning on PvD just make > >> >>> that > >> >>> 'feature' easier to implement? > >> >>> > >> >>> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline wrote: > >> >>>> > >> >>>> Randomly selecting Tommy and Eric so this bubbles up in their > inbox. > >> >>>> > >> >>>> On 2 August 2017 at 10:36, David Bird wrote: > >> >>>> > Could an author of PvD help me understand the following questio= ns > >> >>>> > for > >> >>>> > each > >> >>>> > of the diagrams below I found on the Internet -- which represen= t > >> >>>> > some > >> >>>> > typical hotspot configurations out there... > >> >>>> > > >> >>>> > - Where would the API reside? > >> >>>> > > >> >>>> > - Who 'owns' the API? > >> >>>> > > >> >>>> > - How does the API keep in-sync with the NAS? Who's responsible > for > >> >>>> > that > >> >>>> > (possibly multi-vendor, multi-AAA) integration? > >> >>>> > > >> >>>> > 1) Typical Hotspot service company outsourcing: > >> >>>> > > >> >>>> > > >> >>>> > http://cloudessa.com/wp-content/uploads/2013/08/shema- > CaptivePortalSolution_beta2b.png > >> >>>> > > >> >>>> > 2) Same as above, except venue owns portal: > >> >>>> > > >> >>>> > > >> >>>> > http://cloudessa.com/wp-content/uploads/2013/07/ > solutions_hotspots-co-working-cloudessa_2p1.png > >> >>>> > > >> >>>> > 3) Now consider the above, but the venue has more roaming > partners > >> >>>> > and > >> >>>> > multi-realm RADIUS setup in their Cisco NAS: > >> >>>> > > >> >>>> > > >> >>>> > http://www.cisco.com/c/en/us/td/docs/wireless/controller/8- > 3/config-guide/b_cg83/b_cg83_chapter_0100111.html > >> >>>> > describes many options -- including separate MAC authentication > >> >>>> > sources, > >> >>>> > optional portals for 802.1x (RADIUS) authenticated users, and s= o > >> >>>> > much > >> >>>> > more... > >> >>>> > > >> >>>> > "Cisco ISE supports internal and external identity sources. Bot= h > >> >>>> > sources can > >> >>>> > be used as an authentication source for sponsor-user and > guest-user > >> >>>> > authentication." > >> >>>> > > >> >>>> > Also note this interesting article: the section Information > About > >> >>>> > Captive > >> >>>> > Bypassing and how it describes how to avoid Apple captive porta= l > >> >>>> > detection!!! "If no response is received, then the Internet > access > >> >>>> > is > >> >>>> > assumed to be blocked by the captive portal and Apple=E2=80=99s= Captive > >> >>>> > Network > >> >>>> > Assistant (CNA) auto-launches the pseudo-browser to request > portal > >> >>>> > login in > >> >>>> > a controlled window. The CNA may break when redirecting to an I= SE > >> >>>> > captive > >> >>>> > portal. The controller prevents this pseudo-browser from poppin= g > >> >>>> > up." > >> >>>> > > >> >>>> > > >> >>>> > > >> >>>> > _______________________________________________ > >> >>>> > Captive-portals mailing list > >> >>>> > Captive-portals@ietf.org > >> >>>> > https://www.ietf.org/mailman/listinfo/captive-portals > >> >>>> > > >> >>> > >> >>> > >> >>> > >> >> > >> >> _______________________________________________ > >> >> Captive-portals mailing list > >> >> Captive-portals@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/captive-portals > >> >> > >> >> > >> > > >> > > >> > _______________________________________________ > >> > Captive-portals mailing list > >> > Captive-portals@ietf.org > >> > https://www.ietf.org/mailman/listinfo/captive-portals > >> > > > > > > --001a113568b4fb4d2d05577ff900 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, that is more or less my point exactly...=C2=A0

One problem people seem to have with ICMP and think = PvD is the solution is around security. You brought up GEOPRIV as an exampl= e of that. However, as you said, "Those can (and should) be authentica= ted". In public access (where you can't punt security to=C2=A0&quo= t;Lower-layer protections, such as Layer 2 traffic separation might be used= to provide some guarantees."), maybe that statement would be upgraded= to "Those MUST be authenticated". In RFC 5687 is says " The client MUST authentic= ate the discovered LIS." ... however, I'm not clear what "aut= henticate" means here. My assumption is that is means more than just a= valid SSL cert of an unfamiliar hostname (like you would expect in public/= guest access PvD).

And, yes, I absolutely believe we will = have a higher rate of misconfiguration using the L7/Application layer... To= quote myself from earlier in the thread:=C2=A0=C2=A0Vendors will likely have= a "PvD URL: " configuration dialog ... and there will be many ho= tspot services companies updating their "Howto" instructions with= their PvD URL info... pretty darn easy to misconfigure. Can you give an ex= ample of how ICMP could be misconfigured?=C2=A0

=


On Tue, Aug 22, 2017 at 4:38 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I wrote all of that text.=C2=A0 I'm not sure that I get your poin= t though.
There's a discovery mechanism that is vulnerable to interception,
etc..., but that (mostly) happens using network-local mechanisms (DHCP
primarily).=C2=A0 That's the only weak link.=C2=A0 The identity is well= known
and authenticated once later interactions happen (the text on
unsecured HTTP is a relic of a bygone era, no one actually implements
that).

In short, the design is to discover the identity of a service using
those lower-layer primitives and then use that to bootstrap into
something else.=C2=A0 If your assertion is that PvD - as a discovery
mechanism - is vulnerable, then the weakness is in the layer 3 parts,
not in the bits that use HTTP.=C2=A0 Those can (and should) be
authenticated.

Did I miss something?

On 23 August 2017 at 06:09, David Bird <dbird@google.com> wrote:
> I don't think that is a fair comparison...
>
> Geolocation isn't anything enforced by the network... and clearly = not
> designed for public/guest access networks (as they exists today).
>
> You might re-read some of the Security Consideration in the docs surro= unding
> GEOPRIV.
>
> HTTP-Enabled Location Delivery (HELD)
> https://datatracker.ietf.org/doc/htm= l/rfc5985#page-22
>
>=C2=A0 =C2=A0 HELD is a location acquisition protocol whereby the clien= t requests
>=C2=A0 =C2=A0 its location from a LIS.=C2=A0 Specific requirements and = security
>=C2=A0 =C2=A0 considerations for location acquisition protocols are pro= vided in
>=C2=A0 =C2=A0 [RFC5687].=C2=A0 An in-depth discussion of the security c= onsiderations
>=C2=A0 =C2=A0 applicable to the use of Location URIs and by-reference p= rovision of
>=C2=A0 =C2=A0 LI is included in [RFC5808].
>
>=C2=A0 =C2=A0 By using the HELD protocol, the client and the LIS expose= themselves
>=C2=A0 =C2=A0 to two types of risk:
>
>=C2=A0 =C2=A0 Accuracy:=C2=A0 The client receives incorrect location in= formation.
>
>=C2=A0 =C2=A0 Privacy:=C2=A0 An unauthorized entity receives location i= nformation.
>
>=C2=A0 =C2=A0 The provision of an accurate and privacy- and confidentia= lity-
>=C2=A0 =C2=A0 protected location to the requestor depends on the succes= s of five
>=C2=A0 =C2=A0 steps:
>
>=C2=A0 =C2=A0 1.=C2=A0 The client must determine the proper LIS.
>
>=C2=A0 =C2=A0 2.=C2=A0 The client must connect to the proper LIS.
>
>=C2=A0 =C2=A0 3.=C2=A0 The LIS must be able to identify the Device by i= ts identifier (IP
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 address).
>
>=C2=A0 =C2=A0 4.=C2=A0 The LIS must be able to return the desired locat= ion.
>
>=C2=A0 =C2=A0 5.=C2=A0 HELD messages must be transmitted unmodified bet= ween the LIS and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 the client.
>
>=C2=A0 =C2=A0 Of these, only steps 2, 3, and 5 are within the scope of = this
>=C2=A0 =C2=A0 document.=C2=A0 Step 1 is based on either manual configur= ation or on the
>=C2=A0 =C2=A0 LIS discovery defined in [RFC5986], in which appropriate = security
>=C2=A0 =C2=A0 considerations are already discussed.=C2=A0 Step 4 is dep= endent on the
>=C2=A0 =C2=A0 specific positioning capabilities of the LIS and is thus = outside the
>=C2=A0 =C2=A0 scope of this document.
>
> Discovering the Local Location Information Server (LIS)
> https://datatracker.ietf.org/doc/htm= l/rfc5986#page-11
>
>=C2=A0 =C2=A0 The address of a LIS is usually well-known within an acce= ss network;
>=C2=A0 =C2=A0 therefore, interception of messages does not introduce an= y specific
>=C2=A0 =C2=A0 concerns.
>
>=C2=A0 =C2=A0 The primary attack against the methods described in this = document is
>=C2=A0 =C2=A0 one that would lead to impersonation of a LIS.=C2=A0 The = LIS is
>=C2=A0 =C2=A0 responsible for providing location information, and this = information
>=C2=A0 =C2=A0 is critical to a number of network services; furthermore,= a Device
>=C2=A0 =C2=A0 does not necessarily have a prior relationship with a LIS= .=C2=A0 Several
>=C2=A0 =C2=A0 methods are described here that can limit the probability= of, or
>=C2=A0 =C2=A0 provide some protection against, such an attack.=C2=A0 Th= ese methods MUST
>=C2=A0 =C2=A0 be applied unless similar protections are in place, or in= cases --
>=C2=A0 =C2=A0 such as an emergency -- where location information of dub= ious origin
>=C2=A0 =C2=A0 is arguably better than none at all.
>
>=C2=A0 =C2=A0 An attacker could attempt to compromise LIS discovery at = any of three
>=C2=A0 =C2=A0 stages:
>
>=C2=A0 =C2=A0 1.=C2=A0 providing a falsified domain name to be used as = input to U-NAPTR
>
>=C2=A0 =C2=A0 2.=C2=A0 altering the DNS records used in U-NAPTR resolut= ion
>
>=C2=A0 =C2=A0 3.=C2=A0 impersonating the LIS
>
>=C2=A0 =C2=A0 The domain name that used to authenticate the LIS is the = domain name
>=C2=A0 =C2=A0 input to the U-NAPTR process, not the output of that proc= ess
>=C2=A0 =C2=A0 [RFC3958], [RFC4848].=C2=A0 As a result, the results of D= NS queries do not
>=C2=A0 =C2=A0 need integrity protection.
>
>=C2=A0 =C2=A0 An HTTPS URI is authenticated using the method described = in Section
>=C2=A0 =C2=A0 3.1 of [RFC2818].=C2=A0 HTTP client implementations frequ= ently do not
>=C2=A0 =C2=A0 provide a means to authenticate based on a domain name ot= her than the
>=C2=A0 =C2=A0 one indicated in the request URI, namely the U-NAPTR outp= ut.=C2=A0 To
>=C2=A0 =C2=A0 avoid having to authenticate the LIS with a domain name t= hat is
>=C2=A0 =C2=A0 different from the one used to identify it, a client MAY = choose to
>=C2=A0 =C2=A0 reject URIs that contain a domain name that is different = to the
>=C2=A0 =C2=A0 U-NAPTR input.=C2=A0 To support endpoints that enforce th= e above
>=C2=A0 =C2=A0 restriction on URIs, network administrators SHOULD ensure= that the
>=C2=A0 =C2=A0 domain name in the DHCP option is the same as the one con= tained in
>=C2=A0 =C2=A0 the resulting URI.
>
>=C2=A0 =C2=A0 Authentication of a LIS relies on the integrity of the do= main name
>=C2=A0 =C2=A0 acquired from DHCP.=C2=A0 An attacker that is able to fal= sify a domain
>=C2=A0 =C2=A0 name circumvents the protections provided.=C2=A0 To ensur= e that the access
>=C2=A0 =C2=A0 network domain name DHCP option can be relied upon, preve= nting DHCP
>=C2=A0 =C2=A0 messages from being modified or spoofed by attackers is n= ecessary.
>=C2=A0 =C2=A0 Physical- or link-layer security are commonly used to red= uce the
>=C2=A0 =C2=A0 possibility of such an attack within an access network.= =C2=A0 DHCP
>=C2=A0 =C2=A0 authentication [RFC3118] might also provide a degree of p= rotection
>=C2=A0 =C2=A0 against modification or spoofing.
>
>=C2=A0 =C2=A0 A LIS that is identified by an HTTP URI cannot be authent= icated.=C2=A0 Use
>=C2=A0 =C2=A0 of unsecured HTTP also does not meet requirements in HELD= for
>=C2=A0 =C2=A0 confidentiality and integrity.=C2=A0 If an HTTP URI is th= e product of LIS
>=C2=A0 =C2=A0 discovery, this leaves Devices vulnerable to several atta= cks.=C2=A0 Lower-
>=C2=A0 =C2=A0 layer protections, such as Layer 2 traffic separation mig= ht be used
>=C2=A0 =C2=A0 to provide some guarantees.
>
> Requirements for a Location-by-Reference Mechanism
> https://datatracker.ietf.org/doc/htm= l/rfc5808#page-12
>
>=C2=A0 =C2=A0 The method of constructing the location URI to include ra= ndomized
>=C2=A0 =C2=A0 components helps to prevent adversaries from obtaining lo= cation
>=C2=A0 =C2=A0 information without ever retrieving a location URI.=C2=A0= In the
>=C2=A0 =C2=A0 possession model, a location URI, regardless of its const= ruction, if
>=C2=A0 =C2=A0 made publicly available, implies no safeguard against any= one being
>=C2=A0 =C2=A0 able to dereference and get the location.=C2=A0 Care has = to be paid when
>=C2=A0 =C2=A0 distributing such a location URI to the trusted location = recipients.
>=C2=A0 =C2=A0 When this aspect is of concern, the authorization model h= as to be
>=C2=A0 =C2=A0 chosen.=C2=A0 Even in this model, care has to be taken on= how to construct
>=C2=A0 =C2=A0 the authorization policies to ensure that only those part= ies have
>=C2=A0 =C2=A0 access to location information that are considered trustw= orthy enough
>=C2=A0 =C2=A0 to enforce the basic rule set that is attached to locatio= n
>=C2=A0 =C2=A0 information in a PIDF-LO document.
>
>=C2=A0 =C2=A0 Any location URI, by necessity, indicates the server (nam= e) that
>=C2=A0 =C2=A0 hosts the location information.=C2=A0 Knowledge of the se= rver in some
>=C2=A0 =C2=A0 specific domain could therefore reveal something about th= e location
>=C2=A0 =C2=A0 of the Target.=C2=A0 This kind of threat may be mitigated= somewhat by
>=C2=A0 =C2=A0 introducing another layer of indirection: namely the use = of a
>=C2=A0 =C2=A0 (remote) presence server.
>
>=C2=A0 =C2=A0 A covert channel for protocol message exchange is an impo= rtant
>=C2=A0 =C2=A0 consideration, given an example scenario where user A sub= scribes to
>=C2=A0 =C2=A0 location information for user B, then every time A gets a= location
>=C2=A0 =C2=A0 update, an (external) observer of the subscription notifi= cation may
>=C2=A0 =C2=A0 know that B has moved.=C2=A0 One mitigation of this is to= have periodic
>=C2=A0 =C2=A0 notification, so that user B may appear to have moved eve= n when
>=C2=A0 =C2=A0 static.
>
>
>
> On Sun, Aug 20, 2017 at 6:34 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> Hi David,
>>
>> Can you explain more about why you believe that a lower-layer prot= ocol
>> needs to be used?
>>
>> I remember a similar discussion about this about 10 years ago with=
>> GEOPRIV.=C2=A0 Then it was asserted that DHCP was the only protoco= l that
>> could deliver location information to user equipment.=C2=A0 That d= iscussion
>> took a long time, but ultimately ended with an HTTP-based protocol= .=C2=A0 I
>> have no desire to repeat that experience.
>>
>> It seems like this is - at least in part - based in how this might= be
>> configured.=C2=A0 That is, you believe that a lower-layer protocol= offers
>> no option for misconfiguration.=C2=A0 Is that correct?=C2=A0 Have = I missed
>> something?
>>
>>
>> On 20 August 2017 at 00:12, David Bird <dbird@google.com> wrote:
>> > HI Tommy,
>> >
>> > Agreed that RFC7710 is lacking notification of captive portal= existence,
>> > it
>> > only provides configuration information. ICMP would provide t= he
>> > notification, as it does today for other forms of destination=
>> > unreachable,
>> > port unreachable, etc. In your first reply, I thought you wer= e
>> > suggesting
>> > that RFC7710 was at play along side PvD DHCP/RA (and I wasn&#= 39;t clear what
>> > you
>> > meant by DHCP/RA).
>> >
>> > I think we both also agree that taking about both a Capport A= PI *and*
>> > PvD is
>> > adding to the confusion and we ultimately will not want two &= quot;APIs".
>> >
>> > ICMP today delivers more than hints... it provides signaling = that can
>> > directly influence traffic. Yes, there are security concerns = around
>> > ICMP,
>> > which is why it is common for it to be filtered out of networ= ks (which
>> > is a
>> > good think for Capport ICMP, it is only for the edge network)= .
>> >
>> > Regarding ICMP and the "content details of the network&q= uot; ... I think that
>> > statement conflates policy and enforcement. ICMP provides (as= today)
>> > notification of enforcement, and RFC7710 provides where to fi= nd out
>> > about
>> > the policy (ToS, etc).
>> >
>> > The JSON API becomes a "web service" when it has a = http(s):// in front
>> > of it
>> > :) .. but, indeed, my concern is in the transport protocol. I= t being a
>> > URL
>> > signals that this is meant to be deployed alongside the porta= l, or
>> > otherwise
>> > 'remotely'... Vendors will likely have a "PvD UR= L: " configuration
>> > dialog
>> > ... and there will be many hotspot services companies updatin= g their
>> > "Howto"
>> > instructions with their PvD URL info... it is a web service.<= br> >> >
>> > I welcome suggestions that put that JSON API into a lower lay= er network
>> > protocol. We could stuff JSON into ICMP :)
>> >
>> > Maybe there is a way to merge ICMP and PvD -- to where ICMP p= rovides the
>> > notification (with tokens) and PvD provides the policy (based= on these
>> > tokens) (?)
>> >
>> > With regard to vendor (NAS/UE) cooperation, perhaps PvD could= be a new
>> > start, but thus far (as my quote of Cisco documentation sugge= sts), it is
>> > more about what users/venues want. Cisco already today active= ly avoids
>> > iOS
>> > captive portal detection because the "pseudo-browser&quo= t; (as they call it)
>> > does
>> > work with their portal. That is a problem that could be solve= today by
>> > Apple/Cisco, couldn't it? Just by not using the pseudo br= owser...
>> > introducing PvD doesn't resolve the core problem there, b= ut does make it
>> > easier to avoid that pseudo browser.
>> >
>> > You also said "We can still get to a captive portal once= the user goes
>> > into
>> > the browser." ... However, this is increasingly untrue a= s the work moves
>> > to
>> > https... So, doing this avoidance of detection will still be = a problem.
>> >
>> > Cheers,
>> > David
>> >
>> >
>> > On Fri, Aug 18, 2017 at 7:23 PM, Tommy Pauly <tpauly@apple.com> wrote:
>> >>
>> >> Hi David,
>> >>
>> >> My thoughts with regards to RFC 7710 is that it is not de= ployed as far
>> >> as
>> >> I know, and no client stack respects the value sent in 77= 10. Without
>> >> some
>> >> API extensions, it isn't directly better than what we= currently have.
>> >> Ideally, this would not be an API that would get deployed= if we were
>> >> also
>> >> using PvDs. My concern is that if PvDs are used for enter= prise and
>> >> private
>> >> networks, we'll have a very similar but less complete= path based on RFC
>> >> 7710. We could end up deprecating or replacing that RFC, = which was
>> >> mentioned
>> >> in our last meeting. I don't think RFC 7710 can be us= ed without a URL,
>> >> which
>> >> is why I think we need a solution that does a better job = of indicating
>> >> the
>> >> lack of captive or other extended network info.
>> >>
>> >> I would hope that since both iOS and Android stack develo= pers are
>> >> working
>> >> on the UE side, we would actually see UE deployment of Pv= Ds before any
>> >> captive vendors adopt PvDs, and we'd be standardizing= around Cisco/etc
>> >> enterprise deployments. By the time there were NAS vendor= s deploying,
>> >> they
>> >> would test with both iOS and Android devices to validate = support.
>> >>
>> >> Basing our standards on the idea that devices (either net= works or UE's)
>> >> may implement the RFCs incorrectly seems to be a difficul= t starting
>> >> point.
>> >>
>> >> I like the point you bring up of splitting network notifi= cations from
>> >> web
>> >> APIs. There is a need to be judicious about what properti= es fall into
>> >> each
>> >> category. I think you're saying that the fact that th= ere is a captive
>> >> network can be signaled via ICMP, etc, as a network-level= property.
>> >> While
>> >> ICMP is a fine solution for giving the UE hints when some= thing has
>> >> expired,
>> >> I am concerned that (possibly unsolicited) network signal= ing is not the
>> >> correct mechanism for the content details of the network,= whether that
>> >> is
>> >> the enterprise network properties, or the captive network= Terms &
>> >> Conditions, tokens, expiration timers, and URLs for vario= us kinds of
>> >> user
>> >> interaction. An JSON API is one form of grabbing informat= ion=E2=80=94I don't
>> >> think
>> >> we should necessarily interpret that as something that is= a high-level
>> >> Web
>> >> interaction. We could create some custom protocol over UD= P like DNS
>> >> records
>> >> to get the information (that would be a lot of new protoc= ol work here
>> >> that
>> >> people may not be willing to get into), but the key is th= at it needs to
>> >> be
>> >> the choice of a UE device that understands how to request= and parse
>> >> content
>> >> that initiates a lookup, and can fetch information from t= he network
>> >> infrastructure.
>> >>
>> >> With regards to your assertion that we'll always reve= rt to doing a
>> >> probe,
>> >> I still would like to believe that if we have a network t= hat advertises
>> >> a
>> >> PvD with no extended information, or extended information= that doesn't
>> >> include a captive portal, we can avoid the probe altogeth= er. Will we
>> >> still
>> >> have networks that redirect HTTP requests? Yes. But that&= #39;s no different
>> >> from
>> >> the scenario today in which a network whitelists our capt= ive detection
>> >> probes. We can still get to a captive portal once the use= r goes into
>> >> the
>> >> browser. We can stop doing probes whenever the RA on the = network
>> >> indicates
>> >> that it supports explicit signaling about network propert= ies. If a
>> >> network
>> >> operator wants to invoke the system-level captive interac= tion, then
>> >> they
>> >> will follow the RFCs we come up in the CAPPORT group as l= ong as UEs end
>> >> up
>> >> deploying support first. If they want to avoid it, or the= y have a
>> >> broken
>> >> network, things will be like networks that whitelist our = probes today.
>> >> Not
>> >> great, but still possible for the user to get through. My= main goal in
>> >> these
>> >> standards is to make it possible for a network to give th= e user a good
>> >> experience; not to make it impossible for the user to hav= e a sub-par
>> >> experience (since I don't think that goal is achievab= le).
>> >>
>> >> Best,
>> >> Tommy
>> >>
>> >>
>> >> On Aug 18, 2017, at 5:52 PM, David Bird <dbird@google.com> wrote:
>> >>
>> >> Thanks Tommy,
>> >>
>> >> I don't dispute that PvD provides an elegant set of s= olutions --
>> >> particularly in enterprise and other 'private' ne= tworks. I question,
>> >> however, the value in public(/guest) access -- where ever= yone wants you
>> >> to
>> >> access their network over others, for 'retail analyti= c' or
>> >> branding/attribution(/exploit) purposes.
>> >>
>> >> Another way to see the PvD integration/deployment:
>> >>
>> >> 1. Today, we join a network, always do a probe, which red= irects to
>> >> captive
>> >> portal
>> >> 2. A PvD URL is provide, so a captive portal notification= is generated
>> >> to
>> >> the user (is that what 'we just make a connection dir= ectly' means?)
>> >> 3. We may have also gotten RFC7710 URL, there are potenti= ally two APIs
>> >> in
>> >> play at the same time, which is extra confusing (?)
>> >> 4. The first NAS vendor release products with support, ve= nues deploy
>> >> and
>> >> start 'fiddling' with the new feature and URL to = PvD end-points
>> >> 5. The first UE vendor releases products with support, st= art using it
>> >> at
>> >> said venues... complain to vendor about problems unique t= o this new
>> >> device
>> >> 6. In some networks, users complain that *only* their new= PvD device is
>> >> seeing a captive portal, while all their other devices do= not. Staff at
>> >> the
>> >> coffee shop don't believe me; all their devices work = too.
>> >>
>> >> I think there are fundamental issues in splitting what sh= ould be
>> >> 'network
>> >> notification' into web APIs....
>> >>
>> >> 1. Tomorrow, we join a network, always do a probe, which = redirects to
>> >> captive portal
>> >>
>> >> It wasn't clear in your e-mail if RFC7710 can be used= *without*
>> >> providing
>> >> a URL, or is there a PvD specific DHCP option?
>> >>
>> >> Thanks,
>> >> David
>> >>
>> >>
>> >> On Wed, Aug 16, 2017 at 9:20 AM, Tommy Pauly <tpauly@apple.com> wrote:
>> >>>
>> >>> Hi David,
>> >>>
>> >>> You mention in one of your emails that you'd expe= ct there to be many
>> >>> "broken PvD" deployments, which would eithe= r necessitate ignoring PvD
>> >>> and
>> >>> using legacy mechanisms, or else having the user face= a broken portal.
>> >>> My
>> >>> impression is that if client-side deployments fail cl= osed=E2=80=94that is, if
>> >>> there
>> >>> is a PvD advertised, but it does not work well, then = we treat the
>> >>> network as
>> >>> broken. If this client behavior is consistent from th= e start of
>> >>> deployment,
>> >>> then I would think that deployments would notice very= quickly if they
>> >>> are
>> >>> broken. The fundamental part of the PvD being adverti= sed is in the
>> >>> RAs=E2=80=94if
>> >>> our DHCP or RAs are broken on a network, we generally= are going to be
>> >>> broken
>> >>> anyhow.
>> >>>
>> >>> As far as where the API resides, I appreciate your ex= planation of the
>> >>> various complexities. My initial take is this:
>> >>>
>> >>> - Where a PvD is being served is up to the deployment= , and determined
>> >>> by
>> >>> the entity that is providing the RAs. To that end, th= e server that
>> >>> hosts the
>> >>> API for extended PvD information may be very differen= t for
>> >>> enterprise/carrier scenarios than in captive portals = for coffee shops.
>> >>> - For the initial take for Captive Portals, I would c= o-locate the "PvD
>> >>> API" server with the "Captive API" and= "Captive Web Server".
>> >>> Presumably, the
>> >>> device that was previously doing the HTTP redirects w= ould be able to
>> >>> do the
>> >>> similar coordination of making sure the PvD ID that i= s given out to
>> >>> clients
>> >>> matches the PvD API server (which is the same as the = "Captive Web
>> >>> Server").
>> >>>
>> >>> For the captive use-case, I see the integration of Pv= Ds as an
>> >>> incremental
>> >>> step:
>> >>>
>> >>> 1. Today, we join a network, always do a probe, which= may get
>> >>> redirected
>> >>> to a captive web server
>> >>> 2. With RFC 7710, we would join a network and do the = same as (1),
>> >>> unless
>> >>> the captive URL is given in the DHCP/RA and we just m= ake a connection
>> >>> directly.
>> >>> 3. With the Captive API draft, we can interact with t= he portal other
>> >>> than
>> >>> just showing a webpage; but this may still be bootstr= apped by 7710 if
>> >>> not
>> >>> using another mechanism
>> >>> 4. With PvDs, the mechanism in 7710 is generalized to= support APIs
>> >>> other
>> >>> than just captive, and can indicate that no captive p= ortal or other
>> >>> extended
>> >>> info is present; and the PvD API in this form is just= a more generic
>> >>> version
>> >>> of the captive API that allows us to use the same mec= hanism for other
>> >>> network properties that aren't specifically capti= ve (like enterprise
>> >>> network
>> >>> extended info, or walled gardens)
>> >>>
>> >>> Getting into the arms race of people avoiding the cap= tive probes: if
>> >>> someone doesn't want to interact with the client = OS's captive portal
>> >>> system,
>> >>> they can and likely will not change anything and just= keep redirecting
>> >>> pages. Hopefully if a better solution becomes prevale= nt enough in the
>> >>> future, client OS's will be able to just ignore a= nd reject any network
>> >>> that
>> >>> redirects traffic, and the only supported captive por= tals would be
>> >>> ones that
>> >>> interact in specified ways and advertise themselves a= s captive
>> >>> networks. In
>> >>> order to get to this point, there certainly needs to = be a carrot to
>> >>> incentivize adoption. My goal with the more flexible = interaction
>> >>> supported
>> >>> by PvD is that we will allow the networks to provide = a better user
>> >>> experience to people joining their networks, and inte= grate with client
>> >>> OS's
>> >>> to streamline the joining process (notification of th= e network being
>> >>> available, who owns it, how to accept and how to pay)= , the maintenance
>> >>> process (being able to integrate time left or bytes l= eft on the
>> >>> network into
>> >>> the system UI), and what is allowed or not on the net= work.
>> >>>
>> >>> Thanks,
>> >>> Tommy
>> >>>
>> >>>
>> >>> On Aug 16, 2017, at 6:51 AM, David Bird <dbird@google.com> wrote:
>> >>>
>> >>> My question about where the PvD API resides was somew= hat rhetorical.
>> >>> In
>> >>> reality, I'm sure you will find all of the above = - In the NAS (e.g.
>> >>> Cisco),
>> >>> at the hotspot services provider, and something hoste= d next to the
>> >>> venues
>> >>> website. It depends mostly on how this URL is configu= red, and by whom.
>> >>> (One
>> >>> could imagine people doing all sorts of things).
>> >>>
>> >>> My question more specifically for the authors is, how= would Cisco
>> >>> implement PvD for Guest/Public access and would it ac= tively stop
>> >>> avoiding
>> >>> Apple captive portal detection? Or, would turning on = PvD just make
>> >>> that
>> >>> 'feature' easier to implement?
>> >>>
>> >>> On Tue, Aug 15, 2017 at 5:19 PM, Erik Kline <ek@google.com> wrote:
>> >>>>
>> >>>> Randomly selecting Tommy and Eric so this bubbles= up in their inbox.
>> >>>>
>> >>>> On 2 August 2017 at 10:36, David Bird <dbird@google.com> wrote:
>> >>>> > Could an author of PvD help me understand th= e following questions
>> >>>> > for
>> >>>> > each
>> >>>> > of the diagrams below I found on the Interne= t -- which represent
>> >>>> > some
>> >>>> > typical hotspot configurations out there...<= br> >> >>>> >
>> >>>> > - Where would the API reside?
>> >>>> >
>> >>>> > - Who 'owns' the API?
>> >>>> >
>> >>>> > - How does the API keep in-sync with the NAS= ? Who's responsible for
>> >>>> > that
>> >>>> > (possibly multi-vendor, multi-AAA) integrati= on?
>> >>>> >
>> >>>> > 1) Typical Hotspot service company outsourci= ng:
>> >>>> >
>> >>>> >
>> >>>> > http://cloudessa.com/wp-content/uploads/2013/08/shema= -CaptivePortalSolution_beta2b.png
>> >>>> >
>> >>>> > 2) Same as above, except venue owns portal:<= br> >> >>>> >
>> >>>> >
>> >>>> > http://cloudessa.com/wp-content/uploads/2013= /07/solutions_hotspots-co-working-cloudessa_2p1.png
>> >>>> >
>> >>>> > 3) Now consider the above, but the venue has= more roaming partners
>> >>>> > and
>> >>>> > multi-realm RADIUS setup in their Cisco NAS:=
>> >>>> >
>> >>>> >
>> >>>> > http://www.cisco.com/c/en/us/td= /docs/wireless/controller/8-3/config-guide/b_cg83/b_cg83_chapter_= 0100111.html
>> >>>> > describes many options -- including separate= MAC authentication
>> >>>> > sources,
>> >>>> > optional portals for 802.1x (RADIUS) authent= icated users, and so
>> >>>> > much
>> >>>> > more...
>> >>>> >
>> >>>> > "Cisco ISE supports internal and extern= al identity sources. Both
>> >>>> > sources can
>> >>>> > be used as an authentication source for spon= sor-user and guest-user
>> >>>> > authentication."
>> >>>> >
>> >>>> > Also note this interesting article:=C2=A0 th= e section Information About
>> >>>> > Captive
>> >>>> > Bypassing and how it describes how to avoid = Apple captive portal
>> >>>> > detection!!! "If no response is receive= d, then the Internet access
>> >>>> > is
>> >>>> > assumed to be blocked by the captive portal = and Apple=E2=80=99s Captive
>> >>>> > Network
>> >>>> > Assistant (CNA) auto-launches the pseudo-bro= wser to request portal
>> >>>> > login in
>> >>>> > a controlled window. The CNA may break when = redirecting to an ISE
>> >>>> > captive
>> >>>> > portal. The controller prevents this pseudo-= browser from popping
>> >>>> > up."
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > _______________________________________= ________
>> >>>> > Captive-portals mailing list
>> >>>> > = Captive-portals@ietf.org
>> >>>> > https://www.ietf= .org/mailman/listinfo/captive-portals
>> >>>> >
>> >>>
>> >>>
>> >>>
>> >>
>> >> _______________________________________________
>> >> Captive-portals mailing list
>> >> Captive-porta= ls@ietf.org
>> >> https://www.ietf.org/mailman/= listinfo/captive-portals
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Captive-portals mailing list
>> > Captive-portals@i= etf.org
>> > https://www.ietf.org/mailman/listinfo/captive-portals
>> >
>
>

--001a113568b4fb4d2d05577ff900-- From nobody Thu Aug 24 07:02:06 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A7C132518 for ; Thu, 24 Aug 2017 07:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 nO32H69narto for ; Thu, 24 Aug 2017 07:02:03 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540DE13295E for ; Thu, 24 Aug 2017 07:02:03 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id r14so2497811iod.1 for ; Thu, 24 Aug 2017 07:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eAVXTYytX3RvrZ5gjzXdtdfSDoOAP/eIXLCCYfIiROs=; b=DFX+Nxpbn1c+54ZyffyLFeY23HytmZu9wjm9h1HIt2VOzlm2PBkEQIBFvtSsZWymLl 8MamSGQRC0FU1wULqaNUkjHbCZnaPlx4DCoJ+lFuny3mLoKUPc9H+CmQPHgO5TOBJp/F hryrQ/hJrF6RHxSSqIUlhz0IpLakNpygbSu6dPvyxz5fNESOOS+BrhftnSATH7sklclr TE5i+nfDXH7v6tvqgx6GOoBY2FCA9FSYZ5W9mJX+U0qZPlco0Gmz/HnBHJ8z/6S315VK 46dTDvhRKFLaq/RHZ3/x+ixpP9HGIwBSEOnf3CHh31R5ZtKjr7thWkbHWYIO80hOyyB8 BczQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eAVXTYytX3RvrZ5gjzXdtdfSDoOAP/eIXLCCYfIiROs=; b=ppy4badYB2Xxabw02XoI43J0dhDvHb5UybMvlZi0F38i/oRfGzCQQn21+/UqSx7WLK KCgUN1xtkbD8CNn3n9uYZK3PPj897kDueGzgCNdRwRZE/2ifEP0g+iMPRSEwYUKA0ysE rOq8J6M4eXq2SoNZkVE89z4ZThDXFdsABZfBU4c/o8ufWQaKr47JDPW+8keaHeGE6xz+ Yu4ZAJx+ffYz4/I/JnVqndfg2kQXPWz21JreixPis6abxqOXTOKvEuCWCtvDQCWTrg6C 85bsfSeWwSKzgQWH+XCn1FU3MMgXjn6lg9t9YYRxx8UWUy3el+xayvPnvyolH5mwp/9k fNtA== X-Gm-Message-State: AHYfb5iVZ8G7xHW+GotgVKnX/G+90e1VmELJvjwx42+aToooVxB2sECP R2z2GNbFcrIlZt07OBShH/WIep0VyIHa X-Google-Smtp-Source: ADKCNb4gysjrcXbeeyjWut0xlYtMMr5u9f2MQdsHkWoFvYYfrIw2yEShrPUP/Xoe0kCJm6ylGudkDXNMK7GDCYL21mU= X-Received: by 10.107.142.132 with SMTP id q126mr5264300iod.316.1503583322220; Thu, 24 Aug 2017 07:02:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Thu, 24 Aug 2017 07:01:41 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> From: Lorenzo Colitti Date: Thu, 24 Aug 2017 23:01:41 +0900 Message-ID: To: David Bird Cc: Martin Thomson , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org, Tommy Pauly Content-Type: multipart/alternative; boundary="94eb2c05c32cd03f5f055780455a" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 14:02:05 -0000 --94eb2c05c32cd03f5f055780455a Content-Type: text/plain; charset="UTF-8" On Thu, Aug 24, 2017 at 10:40 PM, David Bird wrote: > Can you give an example of how ICMP could be misconfigured? > It doesn't matter how hard it is to misconfigure, because it is trivial to forge. --94eb2c05c32cd03f5f055780455a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Aug 24, 2017 at 10:40 PM, David Bird <dbird@google.com> w= rote:
Can you give an example of how ICMP could be misconfi= gured?=C2=A0

It doesn= 9;t matter how hard it is to misconfigure, because it is trivial to forge.<= /div>
--94eb2c05c32cd03f5f055780455a-- From nobody Thu Aug 24 07:29:32 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A31D132976 for ; Thu, 24 Aug 2017 07:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5M_8wuvSZZvD for ; Thu, 24 Aug 2017 07:29:29 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C47132351 for ; Thu, 24 Aug 2017 07:29:29 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id w6so4034651qka.0 for ; Thu, 24 Aug 2017 07:29:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gTqyg9yGwXpMqXA5wUir/XfgXcQBYwtOUIYbA5rYF5M=; b=ByqwJIT6bu9dUN8YTpXJ/duI+f325tUEStrLnio2q2OH6iuPkT+yyPQ5QqntLo+cU9 velsld/zjCRqig+vg13oBQ8FOsMIPcgMWicJA1rrjLAbc3rlcRkJncGPVKDZ7L+EUtz0 SNkP8F4OWZ9pJuqbawT9VkDiSFUe6+P+KzIJlEeSxTcLNZgmCA2RweWGDHndJ44KRI2V DAZ7HBkF/yvV+f2sxUL1bQwyMpRx8HdM4NKGfGzxQOUs+2YU/YrT4pf52m57FpW1tB8E Hk9c8pUboHtt04wGDlLEOmD1dHLLeWvI6dIenArDWZur8O+KXOrejU5BHDgrCSmYefT1 pOVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gTqyg9yGwXpMqXA5wUir/XfgXcQBYwtOUIYbA5rYF5M=; b=lW8QeeJzctmOcaVj1pIrhpxtNEEPB8xlRD/G3OhpXtUR8HwwGLtO3uR5Ulv0UC/GJR 2gPB+nIG06EQ8EUAQb5el+HXfQJz2JL6zuWxWz7T3OSIqab2VgjWZQ+NkaSp2jFaTxZm yhqVwqm2dkAHDpBFHI6kXGF1JT/Fzaii6aO61//Tuj/DlLQW0TbdEIHkUhW1wZyjbhGb 3IdizwVh31e9nSeZrOQIPGOpl/KZ+PQZr8cOhT2TXJojCQD4CfVcadmu4wpXqC/9kWFS OLHYk3AxPeLm4xBDFW9GNDFNpMO9IDtH12b7kVU4XY+tA4Kh87il2sJ9I9XCFvwZzYv0 kmUw== X-Gm-Message-State: AHYfb5iD35WIv9oRnL8nYC3Kw81Yen89c9IW6pDZ+VHQwfEkYoy0kQZU 1ha6iSc/XRSyawBflFmsZX3uJpEpUbIa X-Google-Smtp-Source: ADKCNb65bxdTmiixLODcBaIB7O7a7t0rSqEKykbidBhvPygqKIU2QH3tzknFKs/GX/1YhYCAynSfCgVXGQd0TO6I/y0= X-Received: by 10.233.232.88 with SMTP id a85mr8427709qkg.330.1503584968181; Thu, 24 Aug 2017 07:29:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Thu, 24 Aug 2017 07:29:27 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> From: David Bird Date: Thu, 24 Aug 2017 07:29:27 -0700 Message-ID: To: Lorenzo Colitti Cc: Martin Thomson , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org, Tommy Pauly Content-Type: multipart/alternative; boundary="94eb2c112450eb9d30055780a716" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 14:29:31 -0000 --94eb2c112450eb9d30055780a716 Content-Type: text/plain; charset="UTF-8" Just like the rampant problem we see in ICMP Dest-Unreachable forgery attacks? On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti wrote: > On Thu, Aug 24, 2017 at 10:40 PM, David Bird wrote: > >> Can you give an example of how ICMP could be misconfigured? >> > > It doesn't matter how hard it is to misconfigure, because it is trivial to > forge. > --94eb2c112450eb9d30055780a716 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just like the rampant problem we see in ICMP Dest-Unreacha= ble forgery attacks?=C2=A0

On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <lorenz= o@google.com> wrote:
On Thu, Aug 24, 2017 at 10:40 PM, David Bird <<= a href=3D"mailto:dbird@google.com" target=3D"_blank">dbird@google.com&g= t; wrote:
Can you give an example of how ICMP could be= misconfigured?=C2=A0

=
It doesn't matter how hard it is to misconfigure, because it is tr= ivial to forge.

--94eb2c112450eb9d30055780a716-- From nobody Thu Aug 24 07:41:08 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BD9132940 for ; Thu, 24 Aug 2017 07:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Ml66LMjM5Zo9 for ; Thu, 24 Aug 2017 07:41:05 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 896BB132351 for ; Thu, 24 Aug 2017 07:41:05 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id r14so2913498iod.1 for ; Thu, 24 Aug 2017 07:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mxAQHhWToJY0gkpANWOjMDxZ4DBlmqwhxnTkqHNqJ24=; b=QVms4PYaNTEdLa4HPjNl9BTCeLpQtwcu+WXhwN9azA1ySD8sVsnL2fwk1TDedsk7fj Nk/8xvri+i+vhxdF3zzqhwEhDlCr9X/fTCllEeUtKNRjl1foJDtev+iEPJVxOI3V4tiJ 0JcvKO70YO/vglFz2SiioLOtlojA92mN8b/55IVl8UOkWQKOV7m7fGHz+w5iiPXLNong 1Ex923L/8huQpac672huPFGtB0wRNKlmIPPooFr9gmomt4TY0pjIMgSpYudCY3yldwuy Rb2KORuGYb4DSTsBqAgAzKLYcH7Am0sZvvUqM/HdwBzK9vNoZPYZzbFsxQxpX0LZW7Ad o9Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mxAQHhWToJY0gkpANWOjMDxZ4DBlmqwhxnTkqHNqJ24=; b=JENzYDcS/BhcKfp7JSJkT9WhtTjoYU0iuxafGJk7E805QUN5J+cJzTKxE3O15+8+Ij bASa+lCHFZGIuFq+a7LheyHc8rZ6/yUOn20Hnpq4PM4FFQBlms5OlHciTItSC44nr2iY w8VapGLW7yQhI5C8R/mQ01GGkdRFCAsHwJGvrmnxx2MXS6jBjs1tumiJ5puRnm4TqdxU EsYQlcK+tnTj+SaSi0PvrDroU6Xbs5Xdv7lEeXJ+Grv32ta+cm6CbMnyHrnk9P3xtik4 HRpyaqyIjVFidzEQoyymf6ii6vvWXsqcy3CujH9BIY5wxeFls2QWbk6jtfCgq/VXfMTC jUCg== X-Gm-Message-State: AHYfb5hxUIRJoxU3fUnGjS+4lSVE2NAE6XTp9UhhZDDjr46zM88VrtsU MboihWUF3TLDROJhdh/Nut/1zit+EP2x X-Google-Smtp-Source: ADKCNb4wnekK1fpQw7bcL14P6AvI0udUnNeDB8+gSom3xGL4xGsLpNtbB5mYMCujJ2f8HdwRq87AEjUe0MWWHzBD36k= X-Received: by 10.107.48.21 with SMTP id w21mr6431153iow.12.1503585664481; Thu, 24 Aug 2017 07:41:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Thu, 24 Aug 2017 07:40:43 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> From: Lorenzo Colitti Date: Thu, 24 Aug 2017 23:40:43 +0900 Message-ID: To: David Bird Cc: Martin Thomson , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org, Tommy Pauly Content-Type: multipart/alternative; boundary="001a114441286c6025055780d181" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 14:41:07 -0000 --001a114441286c6025055780d181 Content-Type: text/plain; charset="UTF-8" A forged destination unreachable can't cause someone else's device to think that wifi is a portal and switch to possibly expensive cellular data. On Thu, Aug 24, 2017 at 11:29 PM, David Bird wrote: > Just like the rampant problem we see in ICMP Dest-Unreachable forgery > attacks? > > On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti > wrote: > >> On Thu, Aug 24, 2017 at 10:40 PM, David Bird wrote: >> >>> Can you give an example of how ICMP could be misconfigured? >>> >> >> It doesn't matter how hard it is to misconfigure, because it is trivial >> to forge. >> > > --001a114441286c6025055780d181 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A forged destination unreachable can't cause someone e= lse's device to think that wifi is a portal and switch to possibly expe= nsive cellular data.

On Thu, Aug 24, 2017 at 11:29 PM, David Bird <= ;dbird@google.com= > wrote:
Just = like the rampant problem we see in ICMP Dest-Unreachable forgery attacks?= =C2=A0

On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo= Colitti <lorenzo@google.com> wrote:
On Thu, Aug 24, 2017 at 10:40 PM, David Bird <dbird@google.= com> wrote:
Can you give an example of how ICMP= could be misconfigured?=C2=A0

It doesn't matter how hard it is to misconfigure, because= it is trivial to forge.


--001a114441286c6025055780d181-- From nobody Thu Aug 24 08:14:42 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DE81329B7 for ; Thu, 24 Aug 2017 08:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 nlkxjPcdHQ2s for ; Thu, 24 Aug 2017 08:14:39 -0700 (PDT) Received: from mail-in21.apple.com (mail-out21.apple.com [17.171.2.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 980DC1321EB for ; Thu, 24 Aug 2017 08:14:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1503587678; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=C7je/KmqDpJnvidYUIfXPBJc52LlUCa7Ve2LhNm8XKo=; b=row4S+vX8QH8a1fntyENYYJ3FS6Fd5/rVSXae2yVW+VUqwAVjhH4bHlkq2gAlfX/ r6Nsh3/rK1SGmLW6G4xgOIKsSIAEOhpKvIZDlicyvylwAo8KBYNRlLEHf3aLfUpR Fgk1nEl91zrIy46gsf/18+A0VRLj6V0ML+kzc45d2gPaBh4yolFaGoxZ1yc6HmM4 FvcYG7t1Ob/DymMw+2oxXP0uNL4yZFt0da4wZgOKAlwnopvTWIkZ8paw9yw6RTio RUX3jH2y4TDs81NpEkHgrPz72V3NaYxg+wdgfAYKHAnPWPWvT0YMbjSluAZaWb+j p0DStQSwRSNP+xjxAQ9TRQ==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in21.apple.com (Apple Secure Mail Relay) with SMTP id AC.7A.21774.E5DEE995; Thu, 24 Aug 2017 08:14:38 -0700 (PDT) X-AuditID: 11ab0215-922009c00000550e-c5-599eed5e9c2a Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay7.apple.com (Apple SCV relay) with SMTP id 96.2D.07283.E5DEE995; Thu, 24 Aug 2017 08:14:38 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_gUHhec9nTlimM+ZoEQGcww)" Received: from [17.234.50.132] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OV700KD13ODNJ10@nwk-mmpp-sz13.apple.com>; Thu, 24 Aug 2017 08:14:38 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> Date: Thu, 24 Aug 2017 08:14:36 -0700 In-reply-to: Cc: David Bird , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org, Martin Thomson To: Lorenzo Colitti References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrELMWRmVeSWpSXmKPExsUi2FCYqhv3dl6kwZzZRhZzZzWwWnz6sZ3R 4vPteewWX/YvYLRYf/odo8W1M/8YHdg8pvzeyOqxc9Zddo8Fm0o9liz5yRTAEsVlk5Kak1mW WqRvl8CVcXLdVfaCTsOKR2/fMDUwbtfqYuTkkBAwkejtf8ncxcjFISSwlkmi9/JHZpjExM4f bBCJQ4wSa75cYAJJ8AoISvyYfI8FxGYWCJM4MHUHC0TRV0aJx+e/AXVzcAgLSEhs3pMIUsMm oCJx/NsGZoheG4nPDffZQGxhATOJPU0fwGayCKhKrDzaDGZzCgRL/Pp2mAlkJrPAZkaJP2uf MoIkRAQ0JB6sO84Esewou8T6n3OZQJZJCMhKLP0TAhKXENjFLnGks41lAqPQLCTHzkJyLISt JfH9USuQzQFky0scPC8LEdaUeHbvEzuErS3x5N0F1gWMbKsYhXMTM3N0M/OMDPUSCwpyUvWS 83M3MYIiaTWT6A7G+a8MDzEKcDAq8fBOeDAvUog1say4MvcQozQHi5I4r5ssUEggPbEkNTs1 tSC1KL6oNCe1+BAjEwenVANj95tzqq1XJjyRDol/IXSAa/una7vzKpilLivfOrRdxrfquLX+ fB0jdosV/k9tmzXn/Tq9vFs1seBiPOdVTo4zcqcl5TWuy4ooOLyzXy9ukPfHO6bJatM5ywpd 1cTSzVrsl/+q7Xkkdd6rxHjHlmlrJi7q2+h+4kZuS2Vv/XMF03crlzG6rcxUYinOSDTUYi4q TgQAhT4fk4UCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrFKsWRmVeSWpSXmKPExsUi2FB8Qzfu7bxIg8fNAhZzZzWwWnz6sZ3R 4vPteewWX/YvYLRYf/odo8W1M/8YHdg8pvzeyOqxc9Zddo8Fm0o9liz5yRTAEmVtk5ZfVJ5Y lKJQlFxQYqtUnJGYkl8eb2lsZOqQWFCQk6qXnJ+rpG9nk5Kak1mWWoTMSrDOOLnuKntBp2HF o7dvmBoYt2t1MXJySAiYSEzs/MHWxcjFISRwiFFizZcLTCAJXgFBiR+T77GA2MwCYRIHpu5g gSj6yijx+Pw35i5GDg5hAQmJzXsSQWrYBFQkjn/bwAzRayPxueE+G4gtLGAmsafpA9hMFgFV iZVHm8FsToFgiV/fDjOBzGQW2Mwo8WftU0aQhIiAhsSDdceZIJYdZZdY/3MuE8gyCQFZiaV/ QiYw8s9Cct8sJPdB2FoS3x+1AtkcQLa8xMHzshBhTYln9z6xQ9jaEk/eXWBdwMi2ilGgKDUn sdJcDx5+mxjBkVWYuoOxcbnVIUYBDkYlHt4bV+ZFCrEmlhVX5gIDiYNZSYR32wOgEG9KYmVV alF+fFFpTmrxIcb9jEBfTmSWEk3OB8Z9Xkm8obGFsaWJhYGBiaWZCWFhExMDE2NjM2NjcxNz WgorifP2H5kTKSSQnliSmp2aWpBaBPMCEwenVAMjE3+Kz3nLlcsP73lhp92dna9ftSVi4txn Efvjrn9++UH286adp60X5mR4RJyf+J51W4Fo1N+nrGW7ZZu06px9JE/UBHZpOH8JXfXQaZrS pN7pL6+9c/7Jd/fdQQWr328/J2cITbqt/PzsnqkBU4L9PvnN0XQ+G/PJ87VUsKn4IdGJWlL2 QuvuKbEAU7ehFnNRcSIA56DLPU0DAAA= Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:14:41 -0000 --Boundary_(ID_gUHhec9nTlimM+ZoEQGcww) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Right, I think the difference between an unreachable destination, and a captive portal or walled garden, is that we expect the captive portal style interaction to be an Operating System-level action, and one that will have consequences on everything the device does while associated to a given network. You can certain use spoofed ICMP to disrupt connections, but (a) the user would notice and (b) you're not causing the Operating System to change behavior. When the OS thinks it is on a captive network or not, it will change what network it considers primary/usable, which may potentially be invisible to the user other than an icon change. I would be able to go onto a captive network, start sending out ICMP messages, and potentially bump other people's connection off the network. Having the UE fetch some resource in order to determine captive state, especially if that resource can be somehow signed, makes it much harder for an attacker to cause the OS to take silent behavior. Tommy > On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti wrote: > > A forged destination unreachable can't cause someone else's device to think that wifi is a portal and switch to possibly expensive cellular data. > > On Thu, Aug 24, 2017 at 11:29 PM, David Bird > wrote: > Just like the rampant problem we see in ICMP Dest-Unreachable forgery attacks? > > On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti > wrote: > On Thu, Aug 24, 2017 at 10:40 PM, David Bird > wrote: > Can you give an example of how ICMP could be misconfigured? > > It doesn't matter how hard it is to misconfigure, because it is trivial to forge. > > > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals --Boundary_(ID_gUHhec9nTlimM+ZoEQGcww) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Right, I think the difference between an unreachable = destination, and a captive portal or walled garden, is that we expect = the captive portal style interaction to be an Operating System-level = action, and one that will have consequences on everything the device = does while associated to a given network. You can certain use spoofed = ICMP to disrupt connections, but (a) the user would notice and (b) = you're not causing the Operating System to change behavior. When the OS = thinks it is on a captive network or not, it will change what network it = considers primary/usable, which may potentially be invisible to the user = other than an icon change. I would be able to go onto a captive network, = start sending out ICMP messages, and potentially bump other people's = connection off the network. 

Having the UE fetch some resource in order to determine = captive state, especially if that resource can be somehow signed, makes = it much harder for an attacker to cause the OS to take silent = behavior.

Tommy

On Aug 24, 2017, at 7:40 AM, = Lorenzo Colitti <lorenzo@google.com> wrote:

A forged destination unreachable can't cause someone else's = device to think that wifi is a portal and switch to possibly expensive = cellular data.

On Thu, Aug 24, 2017 at 11:29 PM, David Bird <dbird@google.com> wrote:
Just like the rampant problem we see in ICMP Dest-Unreachable = forgery attacks? 

On Thu, = Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
On Thu, Aug 24, 2017 at 10:40 PM, David Bird <dbird@google.com> wrote:
Can= you give an example of how ICMP could be = misconfigured? 

It doesn't matter how hard it is = to misconfigure, because it is trivial to forge.


_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

= --Boundary_(ID_gUHhec9nTlimM+ZoEQGcww)-- From nobody Thu Aug 24 08:21:57 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2C5E13237B for ; Thu, 24 Aug 2017 08:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 YvvnAsrjHl5P for ; Thu, 24 Aug 2017 08:21:53 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74D67132BCE for ; Thu, 24 Aug 2017 08:21:53 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id x125so4801553qkc.3 for ; Thu, 24 Aug 2017 08:21:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VsHMfrTemcpSWZrJsGyXAD/wmhg9j8oNg+dinkYwXeI=; b=GC3xbP2LzB6uxpxtkPbby2C6extYhRSLf2P3AKZihme92AjOkDPWjwyOOvWCjfZDN3 Jv2wd3nEx/iaC5mquAKpKMG6tSuLRtT6wvdtrx023bxax3yLXYjOaIQ1VQAd0DyeGBNf IOue6DTmCnWURlqjl3AL5n2QPFk6GQgexZJQFEJKROxy6HCEhcyNz3uBpVnyFjGrUERr 0nXKeHSMXntDVdE+mMDDPrK21NB7T9VD5FAtye0+1erJbmCHVdDkTQcFu0okSp9kFZ0a /kUDUoyk3HdOwp//lZ4XXlEL1qAlOw5n1IFtgpwT+ohqPJKtO2+71eOls9WRMOobTCHi YIPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VsHMfrTemcpSWZrJsGyXAD/wmhg9j8oNg+dinkYwXeI=; b=AZWiI1Khdz99GWxWDijDQiPQSPZCtfjDkPI9jQnB2XhRznSllEX3oivhc2b7S3WJsw u1yDcJkL+xjchIzD4LMhGAtavwV0t9+A9zDxw46WEDA0XQQ7F2Y2zrjbUQsBqx7LXkz9 I1zvqYkL9Gado+xjWtBhbp7yYjSP4rTbEkM2rNPVAv1y+GjXXtP0AYqR3Cn2NDgKft0W 5UtdnMOnepHXvySQdpc2iGS6mNnXU85elECvaSQ6ChruX7xeV/nFixdP+8FPcbzUuPYN /9rVg5iFRrooBUMwo7AixVHDqEF0UQm9AaElEjDnCYpPJ4tQSis0oVLdfP5kFlUnBpYs DscQ== X-Gm-Message-State: AHYfb5izsaVIuBebOsHEbNXiJKNRJji3jelG+HGMCy1n8rV6F2ZIZ068 biIY8V9YJql/96i2y+52+YglLypBMEvx X-Google-Smtp-Source: ADKCNb7L9je2ilRGugHzb0FTkJ+tk9zuiWfKTGCkWYFApjq3Zvgpd9BqSDkJc22FLSzBAHiEItHM1c+imRm6Omh+yBc= X-Received: by 10.55.95.194 with SMTP id t185mr8564036qkb.61.1503588112341; Thu, 24 Aug 2017 08:21:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Thu, 24 Aug 2017 08:21:51 -0700 (PDT) In-Reply-To: <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> From: David Bird Date: Thu, 24 Aug 2017 08:21:51 -0700 Message-ID: To: Tommy Pauly Cc: Lorenzo Colitti , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org, Martin Thomson Content-Type: multipart/alternative; boundary="001a114dc83c53b552055781639d" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:21:56 -0000 --001a114dc83c53b552055781639d Content-Type: text/plain; charset="UTF-8" You are both describing decisions the UE makes... perhaps the UE waits for several flows (with same session-id) to indicate capport warning/errors before acting on it... especially when already connected. There were also proposals to link the ICMP messages to the DHCP message somehow so that ICMP is 'authenticated' against the original DHCP. Theses are solvable concerns, not road blocks. On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly wrote: > Right, I think the difference between an unreachable destination, and a > captive portal or walled garden, is that we expect the captive portal style > interaction to be an Operating System-level action, and one that will have > consequences on everything the device does while associated to a given > network. You can certain use spoofed ICMP to disrupt connections, but (a) > the user would notice and (b) you're not causing the Operating System to > change behavior. When the OS thinks it is on a captive network or not, it > will change what network it considers primary/usable, which may potentially > be invisible to the user other than an icon change. I would be able to go > onto a captive network, start sending out ICMP messages, and potentially > bump other people's connection off the network. > > Having the UE fetch some resource in order to determine captive state, > especially if that resource can be somehow signed, makes it much harder for > an attacker to cause the OS to take silent behavior. > > Tommy > > On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti wrote: > > A forged destination unreachable can't cause someone else's device to > think that wifi is a portal and switch to possibly expensive cellular data. > > On Thu, Aug 24, 2017 at 11:29 PM, David Bird wrote: > >> Just like the rampant problem we see in ICMP Dest-Unreachable forgery >> attacks? >> >> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti >> wrote: >> >>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird wrote: >>> >>>> Can you give an example of how ICMP could be misconfigured? >>>> >>> >>> It doesn't matter how hard it is to misconfigure, because it is trivial >>> to forge. >>> >> >> > _______________________________________________ > Captive-portals mailing list > Captive-portals@ietf.org > https://www.ietf.org/mailman/listinfo/captive-portals > > > --001a114dc83c53b552055781639d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You are both describing decisions the UE makes... perhaps = the UE waits for several flows (with same session-id) to indicate capport w= arning/errors before acting on it... especially when already connected. The= re were also proposals to link the ICMP messages to the DHCP message someho= w so that ICMP is 'authenticated' against the original DHCP. Theses= are solvable concerns, not road blocks.=C2=A0



On Thu, Au= g 24, 2017 at 8:14 AM, Tommy Pauly <tpauly@apple.com> wrote:<= br>
Right, I think the difference between an unreachabl= e destination, and a captive portal or walled garden, is that we expect the= captive portal style interaction to be an Operating System-level action, a= nd one that will have consequences on everything the device does while asso= ciated to a given network. You can certain use spoofed ICMP to disrupt conn= ections, but (a) the user would notice and (b) you're not causing the O= perating System to change behavior. When the OS thinks it is on a captive n= etwork or not, it will change what network it considers primary/usable, whi= ch may potentially be invisible to the user other than an icon change. I wo= uld be able to go onto a captive network, start sending out ICMP messages, = and potentially bump other people's connection off the network.=C2=A0
Having the UE fetch some resource in order to determine c= aptive state, especially if that resource can be somehow signed, makes it m= uch harder for an attacker to cause the OS to take silent behavior.

<= div>Tommy
<= div>
On Aug 24, 20= 17, at 7:40 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

A forged destination unreachable can't cause s= omeone else's device to think that wifi is a portal and switch to possi= bly expensive cellular data.

On Thu, Aug 24, 2017 at 11:29 PM, David Bird <dbird@google= .com> wrote:
Just like the rampant problem we see in ICMP Dest-Unreachable forgery at= tacks?=C2=A0

On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <lorenzo@googl= e.com> wrote:
On Thu, Aug= 24, 2017 at 10:40 PM, David Bird <dbird@google.com> wrote:
Can you give an example of how ICMP could be misconfigured?=C2= =A0

It doesn'= t matter how hard it is to misconfigure, because it is trivial to forge.


_______________________________________________
Captive-portals mai= ling list
= Captive-portals@ietf.org
https://www.ietf.org/mailman/= listinfo/captive-portals

<= /div>

--001a114dc83c53b552055781639d-- From nobody Thu Aug 24 08:34:14 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0E31321C7 for ; Thu, 24 Aug 2017 08:34:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7Ozuq2POEXjK for ; Thu, 24 Aug 2017 08:34:10 -0700 (PDT) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BA01321AA for ; Thu, 24 Aug 2017 08:34:09 -0700 (PDT) Received: by mail-io0-x230.google.com with SMTP id h205so3447375ioa.2 for ; Thu, 24 Aug 2017 08:34:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pgUAT/8OwIl2yxFb3Ggr4TBXAnUpQV3W196gH+8Inak=; b=KdXE54cmMg8usZrVH9eDyR+zHYvXoQFXkhbSLyA1mGiBcUJv5Sj/scqvTd63TzbgRQ zPDmms81hej8at8XYfWzEKqPbBs+/qikTCCMrYeXCUVmUusdSXC49j53zsidpwO1EWHP Kj7RKXxCnw7GNgc7nth/2xWorPIZ7VRsgs4WWQA3xHsgkdd/zVvljWeRnPH5MRpwdaNu utij/pnzgdtGWvuV6gclYkhc1BkED6N9OEUnKMGqh3CI2hrW/mKyYr5tJvCN1JDz4bu7 wtuftW+1SPyJKYV9WCxBiRUmVn5rjrjyG+oUW1xZBbfJaa7im8ZPv1YTwD5DL4HzPiww yhrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pgUAT/8OwIl2yxFb3Ggr4TBXAnUpQV3W196gH+8Inak=; b=lgP959jj6lKQhGtqvIFMTEisKs6X+si8ECjxp/SOIMu6Hhs2ZshjrqsEC91NPDLpAK 60HNwlUlho76ZskE72tv5U/Y/wwOMc9I8zbcusoTsyeH6UjSsrzyhEXRH3Z6t75cg47g NLceYaudlPh2EWyNPflAxWxS1MIpneSLGpQGeZimfofk3sfgCHbPlXdAOe+FkOSnIsQv I66UHTeWHDXCC5/kW+eU19QvPylbtwWqGBolh1PGhsnVAa2hUiQt4Td2uFBWxao848bK /TM7GeJrA+4jqvpQ43xmCQAwJgHUt+mkF2qP3hG/wOFhQF/jOJ2Dvf3RTR1SXgdSmGiK 7Tsw== X-Gm-Message-State: AHYfb5hjuPkruMefXSAXgBRw4g95lUCG3/l/Y+4Iu66iQEaPS29JfIjd H1X+JLHzoyHZMpf4FPOqIsmaf3lTc7Y8 X-Google-Smtp-Source: ADKCNb4i+wwZh0BAp6iGs64R5ESTm1DlinhEbEwgLZiGJN9T/aiJInqofoVZsd6zk1qN7vEo2UiMS6aYFh3HKFIarv8= X-Received: by 10.107.137.97 with SMTP id l94mr5570997iod.279.1503588848799; Thu, 24 Aug 2017 08:34:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.27.203 with HTTP; Thu, 24 Aug 2017 08:33:48 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> From: Lorenzo Colitti Date: Fri, 25 Aug 2017 00:33:48 +0900 Message-ID: To: David Bird Cc: Tommy Pauly , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org, Martin Thomson Content-Type: multipart/alternative; boundary="001a113eaff438f9ae0557818f4b" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:34:12 -0000 --001a113eaff438f9ae0557818f4b Content-Type: text/plain; charset="UTF-8" It seems to me that any solution involving coordination between two protocols is little different, in terms of your criticism that it will lead to "a higher rate of misconfiguration", from the PVD solution. (Personally I don't think that's a valid argument - saying that if you misconfigure the network it won't work well is pretty much a tautology - but you were the one that cited that argument in support of the ICMP solution.) As for several flows, I don't see what would stop an attacker from trying to spoof several flows. On Fri, Aug 25, 2017 at 12:21 AM, David Bird wrote: > You are both describing decisions the UE makes... perhaps the UE waits for > several flows (with same session-id) to indicate capport warning/errors > before acting on it... especially when already connected. There were also > proposals to link the ICMP messages to the DHCP message somehow so that > ICMP is 'authenticated' against the original DHCP. Theses are solvable > concerns, not road blocks. > > > > On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly wrote: > >> Right, I think the difference between an unreachable destination, and a >> captive portal or walled garden, is that we expect the captive portal style >> interaction to be an Operating System-level action, and one that will have >> consequences on everything the device does while associated to a given >> network. You can certain use spoofed ICMP to disrupt connections, but (a) >> the user would notice and (b) you're not causing the Operating System to >> change behavior. When the OS thinks it is on a captive network or not, it >> will change what network it considers primary/usable, which may potentially >> be invisible to the user other than an icon change. I would be able to go >> onto a captive network, start sending out ICMP messages, and potentially >> bump other people's connection off the network. >> >> Having the UE fetch some resource in order to determine captive state, >> especially if that resource can be somehow signed, makes it much harder for >> an attacker to cause the OS to take silent behavior. >> >> Tommy >> >> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti wrote: >> >> A forged destination unreachable can't cause someone else's device to >> think that wifi is a portal and switch to possibly expensive cellular data. >> >> On Thu, Aug 24, 2017 at 11:29 PM, David Bird wrote: >> >>> Just like the rampant problem we see in ICMP Dest-Unreachable forgery >>> attacks? >>> >>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti >>> wrote: >>> >>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird wrote: >>>> >>>>> Can you give an example of how ICMP could be misconfigured? >>>>> >>>> >>>> It doesn't matter how hard it is to misconfigure, because it is trivial >>>> to forge. >>>> >>> >>> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals >> >> >> > --001a113eaff438f9ae0557818f4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It seems to me that any solution involving coordinati= on between two protocols is little different, in terms of your criticism th= at it will lead to "a higher rate of misconfiguration", from the = PVD solution. (Personally I don't think that's a valid argument - s= aying that if you misconfigure the network it won't work well is pretty= much a tautology - but you were the one that cited that argument in suppor= t of the ICMP solution.)

As for several flows,= I don't see what would stop an attacker from trying to spoof several f= lows.

= On Fri, Aug 25, 2017 at 12:21 AM, David Bird <dbird@google.com> wrote:
You are both = describing decisions the UE makes... perhaps the UE waits for several flows= (with same session-id) to indicate capport warning/errors before acting on= it... especially when already connected. There were also proposals to link= the ICMP messages to the DHCP message somehow so that ICMP is 'authent= icated' against the original DHCP. Theses are solvable concerns, not ro= ad blocks.=C2=A0


<= div class=3D"h5">

= On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <tpauly@apple.com> wrote:
Right, I think the difference between an= unreachable destination, and a captive portal or walled garden, is that we= expect the captive portal style interaction to be an Operating System-leve= l action, and one that will have consequences on everything the device does= while associated to a given network. You can certain use spoofed ICMP to d= isrupt connections, but (a) the user would notice and (b) you're not ca= using the Operating System to change behavior. When the OS thinks it is on = a captive network or not, it will change what network it considers primary/= usable, which may potentially be invisible to the user other than an icon c= hange. I would be able to go onto a captive network, start sending out ICMP= messages, and potentially bump other people's connection off the netwo= rk.=C2=A0

Having the UE fetch some resource in order to = determine captive state, especially if that resource can be somehow signed,= makes it much harder for an attacker to cause the OS to take silent behavi= or.

Tommy

On Aug 24, = 2017, at 7:40 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

A fo= rged destination unreachable can't cause someone else's device to t= hink that wifi is a portal and switch to possibly expensive cellular data.<= /div>

On Thu, Aug = 24, 2017 at 11:29 PM, David Bird <dbird@google.com> wrote:
Just like the rampant prob= lem we see in ICMP Dest-Unreachable forgery attacks?=C2=A0

<= div class=3D"gmail_quote">On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti = <lorenzo@google.com> wrote:
<= span>On Thu, Aug 24, 2017 at 10:40 PM, David Bird <dbird@google.com>= wrote:
Can you give an example of how ICMP could be m= isconfigured?=C2=A0

It doesn't matter how hard it is to misconfigure, because it is triv= ial to forge.


_______________________________________________
Captive-portals mai= ling list
= Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

<= /div>

--001a113eaff438f9ae0557818f4b-- From nobody Thu Aug 24 08:55:20 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D97A13294B for ; Thu, 24 Aug 2017 08:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 gw2HPAb-MKt0 for ; Thu, 24 Aug 2017 08:55:17 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C9913239A for ; Thu, 24 Aug 2017 08:55:17 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id y77so5274848qka.4 for ; Thu, 24 Aug 2017 08:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/ZBODKIW/G0aqi82VkbB4xsYgJGMxoEXQc4AYJ082LQ=; b=ACfG7e1Q9Lj59eUR2pX+mYmN58D5WVu5Cfh9v6FM1qjc9hbu6p7XCoUZOwa308OCPq WsLOqhqKh00D1uQ2OnWAoElOCbPZ/Y++vzFHypszAVR5vjz2w/RkR5PsYRUefmYhbQd3 8GJpgjQ5/HC0RrvvXxh1o3XeSpiGkt4BthYc2ihtU9GI0yXXzsDOByv/GIuv50bi5kxF w31HO5E2QLbSHuXXe8LI0SVtfI/cHZFC/afiMpTp1UcvaneEzSKTc7jBt6Ecwik++A1O OmGPm7ke5rnKUChOXNx0XOODUdLGohaLO/2HFpmvwt8jUNx60gJIp3uBjALkmwMpRP4g 1o0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/ZBODKIW/G0aqi82VkbB4xsYgJGMxoEXQc4AYJ082LQ=; b=Hmwwqu8cg+TuGjN2NoJEsDk93MLx+Qc35HCFqX2JMrko3OPIdtCqUPlS9ALMeGRTAV 87V7me3cvqYUUJ45nUBAK/f8LGilfng0W6aJntgPDD46jobfBMyv4uH3fZs33IM+42AQ dSTVyGWhez+jVeqNIZxvtnxj7uSvgrqMjgBs6o+IqQpUMn6i6DgcbgmzvfI1s+h1x+SW 88ODTGAlPG1vIqHfHcOwuV17t5JGpUGcc7XFrcda36CsRD3EPNdWjsHRqjV65pKWbeAn f/TMJL6XmTWJbxNpx2W28bTzUWpCP8nDh0tkkDkgvii3Ynux91QG7NdWBBWvDwLbv5zn 6H3A== X-Gm-Message-State: AHYfb5gSFcIYXEzMIsYramZjjez/asruXukfaxW+7jsyi3l3h3lnHEIc JxS88Yf1lbmFL2urg4jdnvioIw4UEQ8K X-Google-Smtp-Source: ADKCNb7pCLulQsXX1yCE99S114HkC45Ji4yaZfvbuOIx3EPuGGji3lc82tY555lgM96IvISuSp7jW5Etgt4uBovj7ys= X-Received: by 10.55.207.21 with SMTP id e21mr8736957qkj.106.1503590115888; Thu, 24 Aug 2017 08:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Thu, 24 Aug 2017 08:55:14 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> From: David Bird Date: Thu, 24 Aug 2017 08:55:14 -0700 Message-ID: To: Lorenzo Colitti Cc: Tommy Pauly , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org, Martin Thomson Content-Type: multipart/alternative; boundary="001a11459986bf80ce055781dab8" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 15:55:19 -0000 --001a11459986bf80ce055781dab8 Content-Type: text/plain; charset="UTF-8" Indeed, one could just as easily misconfigure the "Captive Portal URL: " field in the NAS. A key difference is that this configuration is enforced the same way (with slight variation for capport) for all devices... It is not just a misconfiguration only visible to "First Vendor to Release PvD Client" products. I'm trying to figure out the value the attacker is gaining (e.g. the motivation) for putting others off the network using Capport ICMP. If they are off-network, chances are their attacks will not work because of firewalls. If they are on-network, particularly if this is Open SSID public access network, I'd say they are wasting their time... Sending 802.11 Disassoc would be easier. On Thu, Aug 24, 2017 at 8:33 AM, Lorenzo Colitti wrote: > It seems to me that any solution involving coordination between two > protocols is little different, in terms of your criticism that it will lead > to "a higher rate of misconfiguration", from the PVD solution. (Personally > I don't think that's a valid argument - saying that if you misconfigure the > network it won't work well is pretty much a tautology - but you were the > one that cited that argument in support of the ICMP solution.) > > As for several flows, I don't see what would stop an attacker from trying > to spoof several flows. > > On Fri, Aug 25, 2017 at 12:21 AM, David Bird wrote: > >> You are both describing decisions the UE makes... perhaps the UE waits >> for several flows (with same session-id) to indicate capport warning/errors >> before acting on it... especially when already connected. There were also >> proposals to link the ICMP messages to the DHCP message somehow so that >> ICMP is 'authenticated' against the original DHCP. Theses are solvable >> concerns, not road blocks. >> >> >> >> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly wrote: >> >>> Right, I think the difference between an unreachable destination, and a >>> captive portal or walled garden, is that we expect the captive portal style >>> interaction to be an Operating System-level action, and one that will have >>> consequences on everything the device does while associated to a given >>> network. You can certain use spoofed ICMP to disrupt connections, but (a) >>> the user would notice and (b) you're not causing the Operating System to >>> change behavior. When the OS thinks it is on a captive network or not, it >>> will change what network it considers primary/usable, which may potentially >>> be invisible to the user other than an icon change. I would be able to go >>> onto a captive network, start sending out ICMP messages, and potentially >>> bump other people's connection off the network. >>> >>> Having the UE fetch some resource in order to determine captive state, >>> especially if that resource can be somehow signed, makes it much harder for >>> an attacker to cause the OS to take silent behavior. >>> >>> Tommy >>> >>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti wrote: >>> >>> A forged destination unreachable can't cause someone else's device to >>> think that wifi is a portal and switch to possibly expensive cellular data. >>> >>> On Thu, Aug 24, 2017 at 11:29 PM, David Bird wrote: >>> >>>> Just like the rampant problem we see in ICMP Dest-Unreachable forgery >>>> attacks? >>>> >>>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti >>>> wrote: >>>> >>>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird wrote: >>>>> >>>>>> Can you give an example of how ICMP could be misconfigured? >>>>>> >>>>> >>>>> It doesn't matter how hard it is to misconfigure, because it is >>>>> trivial to forge. >>>>> >>>> >>>> >>> _______________________________________________ >>> Captive-portals mailing list >>> Captive-portals@ietf.org >>> https://www.ietf.org/mailman/listinfo/captive-portals >>> >>> >>> >> > --001a11459986bf80ce055781dab8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Indeed, one could just as easily misconfigure the "Ca= ptive Portal URL: " field in the NAS. A key difference is that this co= nfiguration is enforced the same way (with slight variation for capport) fo= r all devices... It is not just a misconfiguration only visible to "Fi= rst Vendor to Release PvD Client" products.=C2=A0

I= 'm trying to figure out the value the attacker is gaining (e.g. the mot= ivation) for putting others off the network using Capport ICMP. If they are= off-network, chances are their attacks will not work because of firewalls.= If they are on-network, particularly if this is Open SSID public access ne= twork, I'd say they are wasting their time... Sending 802.11 Disassoc w= ould be easier.

On Thu, Aug 24, 2017 at 8:33 AM, Lorenzo Colitti <lorenzo@googl= e.com> wrote:
It seems to me that any solution involving coordination between tw= o protocols is little different, in terms of your criticism that it will le= ad to "a higher rate of misconfiguration", from the PVD solution.= (Personally I don't think that's a valid argument - saying that if= you misconfigure the network it won't work well is pretty much a tauto= logy - but you were the one that cited that argument in support of the ICMP= solution.)

As for several flows, I don't = see what would stop an attacker from trying to spoof several flows.

=
On Fri, Aug 25, 2017 at 12:21 AM, David Bird <db= ird@google.com> wrote:
You are both describing decisions the UE makes... perhaps the = UE waits for several flows (with same session-id) to indicate capport warni= ng/errors before acting on it... especially when already connected. There w= ere also proposals to link the ICMP messages to the DHCP message somehow so= that ICMP is 'authenticated' against the original DHCP. Theses are= solvable concerns, not road blocks.=C2=A0



On Th= u, Aug 24, 2017 at 8:14 AM, Tommy Pauly <tpauly@apple.com> wr= ote:
Right, I think the difference between an unrea= chable destination, and a captive portal or walled garden, is that we expec= t the captive portal style interaction to be an Operating System-level acti= on, and one that will have consequences on everything the device does while= associated to a given network. You can certain use spoofed ICMP to disrupt= connections, but (a) the user would notice and (b) you're not causing = the Operating System to change behavior. When the OS thinks it is on a capt= ive network or not, it will change what network it considers primary/usable= , which may potentially be invisible to the user other than an icon change.= I would be able to go onto a captive network, start sending out ICMP messa= ges, and potentially bump other people's connection off the network.=C2= =A0

Having the UE fetch some resource in order to determ= ine captive state, especially if that resource can be somehow signed, makes= it much harder for an attacker to cause the OS to take silent behavior.

Tommy<= br>

On Aug 24, 2017, at 7:40 A= M, Lorenzo Colitti <lorenzo@google.com> wrote:

<= /div>
A forged destination unreachable can't cause s= omeone else's device to think that wifi is a portal and switch to possi= bly expensive cellular data.

On Thu, Aug 24, 2017 at 11:29 PM, David Bird <dbird@google= .com> wrote:
Just like the rampant problem we see in ICMP Dest-Unreachable forgery at= tacks?=C2=A0

On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <= lorenzo@google.com> wrote:
=
On Thu, Aug 24, 2017 at 10:40 PM, David Bird <dbird@google.com> wrote:
Can you give an example of how ICMP could be misc= onfigured?=C2=A0

= It doesn't matter how hard it is to misconfigure, because it is trivial= to forge.


_______________________________________________
Captive-portals mai= ling list
= Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

<= /div>



--001a11459986bf80ce055781dab8-- From nobody Thu Aug 24 09:03:48 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5119E132335 for ; Thu, 24 Aug 2017 09:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 L7m4g1vPvpdY for ; Thu, 24 Aug 2017 09:03:44 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9061320BD for ; Thu, 24 Aug 2017 09:03:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1503590623; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jVafiEctT9PSbSN0eqRN09fAeL91Pm2LXC92Fyoc2lg=; b=PJC5S/PEbR3dSwDSENUYUO2ZUQBw81d5SVSJS5AeDNxUAqCQTACcKfXBv+4Ztu3r DYefUmKjW8nb7WCRyddIyC+5QfMvjPQD7lvOE5DxFeXaiWNBREvPxravz+l0TeFS kWxU6ieGloLRM1p5Swb41wiYE082t7TIGAoqQM0m3pl/66oeVCrNvPM4V2noQx7a m9x8dT+Jqa5VCmHMmJM6bHMaI5X51l2JlTkrr0EwEOX1fviBCmPCjQ5mXycrmB4s ebVzydxkQWby7uHpF0M62YnerMVWImULZpU66IeyvS5dTjNUZedH9X2rcJSiqvrp BCzFc3y5oxfqgtMt89w1aw==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id E4.DC.28433.FD8FE995; Thu, 24 Aug 2017 09:03:43 -0700 (PDT) X-AuditID: 11973e11-c4e0f9c000006f11-a8-599ef8dfc839 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay8.apple.com (Apple SCV relay) with SMTP id 05.34.06978.FD8FE995; Thu, 24 Aug 2017 09:03:43 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Mz7+Xjg8CXbmmfwR8KhWVA)" Received: from [17.234.50.132] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170621 64bit (built Jun 21 2017)) with ESMTPSA id <0OV7002T15Y6EW40@nwk-mmpp-sz12.apple.com>; Thu, 24 Aug 2017 09:03:43 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Thu, 24 Aug 2017 09:03:41 -0700 In-reply-to: Cc: David Bird , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org, Martin Thomson To: Lorenzo Colitti References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> X-Mailer: Apple Mail (2.3439) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUi2FCYpnv/x7xIg1mvLCzmzmpgtfj0Yzuj xefb89gtvuxfwGix/vQ7RotrZ/4xOrB5TPm9kdVj56y77B4LNpV6LFnykymAJYrLJiU1J7Ms tUjfLoEro3PHB8aCXwkVnS9NGhi3B3cxcnJICJhI7Hv3nLmLkYtDSGANk8SPbRfYYBLXfx5i gUgcYpS41PWTGSTBKyAo8WPyPRYQm1kgTGL2x26ooq+MEn0n/gN1c3AIC0hIbN6TCFLDJqAi cfzbBqheG4nLN76ygtjCAmYSe5o+MIGUswioSuz6pwsS5hQIlni8uBVsJLPAZkaJP2ufMoIk RAQ0JB6sO84EsauNU2L3392sIM0SArISS/+EQBy9iV3i9s6qCYxCs5CcOgvJqRC2lsT3R61A NgeQLS9x8LwsRFhT4tm9T+wQtrbEk3cXWBcwsq1iFMpNzMzRzcwz0kssKMhJ1UvOz93ECIqg 6XaCOxiPr7I6xCjAwajEw3vjyrxIIdbEsuLK3EOM0hwsSuK8TLJAIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYys058139r27fV1b5O12442e8sZvS+3YV/KY77EiG3JnCuXlyx1nHdN9GHG ueUf21VS0100nxcYTjsp8rP+bFnV1KP3SlbtOZXq1DnrPZvK2jNfJ9fF+rxQvH5jz8Sgd4q7 f21ZvNbw5fag85e+n9lQdnZFqlXH1raUtMvHhI4+qDWbdLNt1gG1RiWW4oxEQy3mouJEAEbw ZzyBAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBKsWRmVeSWpSXmKPExsUi2FB8Rvf+j3mRBpsWmVjMndXAavHpx3ZG i8+357FbfNm/gNFi/el3jBbXzvxjdGDzmPJ7I6vHzll32T0WbCr1WLLkJ1MAS5S1TVp+UXli UYpCUXJBia1ScUZiSn55vKWxkalDYkFBTqpecn6ukr6dTUpqTmZZahEyK8E6o3PHB8aCXwkV nS9NGhi3B3cxcnJICJhIXP95iKWLkYtDSOAQo8Slrp/MIAleAUGJH5PvsYDYzAJhErM/dkMV fWWU6Dvxn62LkYNDWEBCYvOeRJAaNgEViePfNkD12khcvvGVFcQWFjCT2NP0gQmknEVAVWLX P12QMKdAsMTjxa1gI5kFNjNK/Fn7lBEkISKgIfFg3XEmiF1tnBK7/+5mBWmWEJCVWPonZAIj /ywk581Cch6ErSXx/VErkM0BZMtLHDwvCxHWlHh27xM7hK0t8eTdBdYFjGyrGAWKUnMSKy30 4KG3iREcVYVpOxibllsdYhTgYFTi4b1xZV6kEGtiWXFlLjCMOJiVRHi3PQAK8aYkVlalFuXH F5XmpBYfYtzPCPTkRGYp0eR8YMznlcQbGlsYW5pYGBiYWJqZEBY2MTEwMTY2MzY2NzGnpbCS OG/fkTmRQgLpiSWp2ampBalFMC8wcXBKNTAmvTtYYZb2IuXHzgq1221rgtkjrydM6pqxY/Wv 3XdNMn28Mouq8o/MmPKycErr2r1s3yaqvpfZ+5D7uYBkQVGOzmEt2/b2GSZ6Da9FdrELxbiz 3FLWvTRbyOim0YpGnbZKE/V4RxUHFwttsd01qVsDOO6b1xyeHqEhx/x4XdLyP4otmhwz7imx ANO2oRZzUXEiAMGqMMpLAwAA Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 16:03:46 -0000 --Boundary_(ID_Mz7+Xjg8CXbmmfwR8KhWVA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT If the client OS needs to add in heuristics to reach a certain volume of ICMP messages before trusting them, I think the design is flawed. Beyond that, the information we'd like to get isn't just as simple as a boolean value that can be aggregated (like unreachable would be). Among the problems we're trying to solve for CAPPORT is "how much time do I have left", and "when to re-join the portal". Having a source we can query about those properties seems to dramatically simplify the flow and trust model. However we do things, it seems like this information should be pull-able (even if it allows the client to open a connection on which changes are pushed or notified) rather than unsolicited pushes of ICMP by the network. > On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti wrote: > > It seems to me that any solution involving coordination between two protocols is little different, in terms of your criticism that it will lead to "a higher rate of misconfiguration", from the PVD solution. (Personally I don't think that's a valid argument - saying that if you misconfigure the network it won't work well is pretty much a tautology - but you were the one that cited that argument in support of the ICMP solution.) > > As for several flows, I don't see what would stop an attacker from trying to spoof several flows. > > On Fri, Aug 25, 2017 at 12:21 AM, David Bird > wrote: > You are both describing decisions the UE makes... perhaps the UE waits for several flows (with same session-id) to indicate capport warning/errors before acting on it... especially when already connected. There were also proposals to link the ICMP messages to the DHCP message somehow so that ICMP is 'authenticated' against the original DHCP. Theses are solvable concerns, not road blocks. > > > > On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly > wrote: > Right, I think the difference between an unreachable destination, and a captive portal or walled garden, is that we expect the captive portal style interaction to be an Operating System-level action, and one that will have consequences on everything the device does while associated to a given network. You can certain use spoofed ICMP to disrupt connections, but (a) the user would notice and (b) you're not causing the Operating System to change behavior. When the OS thinks it is on a captive network or not, it will change what network it considers primary/usable, which may potentially be invisible to the user other than an icon change. I would be able to go onto a captive network, start sending out ICMP messages, and potentially bump other people's connection off the network. > > Having the UE fetch some resource in order to determine captive state, especially if that resource can be somehow signed, makes it much harder for an attacker to cause the OS to take silent behavior. > > Tommy > >> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti > wrote: >> >> A forged destination unreachable can't cause someone else's device to think that wifi is a portal and switch to possibly expensive cellular data. >> >> On Thu, Aug 24, 2017 at 11:29 PM, David Bird > wrote: >> Just like the rampant problem we see in ICMP Dest-Unreachable forgery attacks? >> >> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti > wrote: >> On Thu, Aug 24, 2017 at 10:40 PM, David Bird > wrote: >> Can you give an example of how ICMP could be misconfigured? >> >> It doesn't matter how hard it is to misconfigure, because it is trivial to forge. >> >> >> _______________________________________________ >> Captive-portals mailing list >> Captive-portals@ietf.org >> https://www.ietf.org/mailman/listinfo/captive-portals > > > --Boundary_(ID_Mz7+Xjg8CXbmmfwR8KhWVA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
If the client OS needs to add in heuristics to reach a = certain volume of ICMP messages before trusting them, I think the design = is flawed. Beyond that, the information we'd like to get isn't just as = simple as a boolean value that can be aggregated (like unreachable would = be). Among the problems we're trying to solve for CAPPORT is "how much = time do I have left", and "when to re-join the portal". Having a source = we can query about those properties seems to dramatically simplify the = flow and trust model. However we do things, it seems like this = information should be pull-able (even if it allows the client to open a = connection on which changes are pushed or notified) rather than = unsolicited pushes of ICMP by the network.

On Aug = 24, 2017, at 8:33 AM, Lorenzo Colitti <lorenzo@google.com> = wrote:

It seems to me that any solution = involving coordination between two protocols is little different, in = terms of your criticism that it will lead to "a higher rate of = misconfiguration", from the PVD solution. (Personally I don't think = that's a valid argument - saying that if you misconfigure the network it = won't work well is pretty much a tautology - but you were the one that = cited that argument in support of the ICMP solution.)

As = for several flows, I don't see what would stop an attacker from trying = to spoof several flows.

On Fri, Aug 25, 2017 at 12:21 AM, = David Bird <dbird@google.com> wrote:
You are both describing decisions the UE makes... perhaps the = UE waits for several flows (with same session-id) to indicate capport = warning/errors before acting on it... especially when already connected. = There were also proposals to link the ICMP messages to the DHCP message = somehow so that ICMP is 'authenticated' against the original DHCP. = Theses are solvable concerns, not road blocks. 



On Thu, Aug 24, 2017 at 8:14 AM, = Tommy Pauly <tpauly@apple.com> wrote:
Right, I think the difference between an unreachable = destination, and a captive portal or walled garden, is that we expect = the captive portal style interaction to be an Operating System-level = action, and one that will have consequences on everything the device = does while associated to a given network. You can certain use spoofed = ICMP to disrupt connections, but (a) the user would notice and (b) = you're not causing the Operating System to change behavior. When the OS = thinks it is on a captive network or not, it will change what network it = considers primary/usable, which may potentially be invisible to the user = other than an icon change. I would be able to go onto a captive network, = start sending out ICMP messages, and potentially bump other people's = connection off the network. 

Having the UE fetch some resource in order to determine = captive state, especially if that resource can be somehow signed, makes = it much harder for an attacker to cause the OS to take silent = behavior.

Tommy

On Aug 24, 2017, at = 7:40 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

A forged = destination unreachable can't cause someone else's device to think that = wifi is a portal and switch to possibly expensive cellular = data.

On Thu, Aug 24, 2017 at 11:29 PM, David Bird <dbird@google.com> wrote:
Just like the rampant problem we see in ICMP Dest-Unreachable = forgery attacks? 

On Thu, = Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
On Thu, Aug 24, 2017 at 10:40 PM, David Bird <dbird@google.com> wrote:
Can= you give an example of how ICMP could be = misconfigured? 

It doesn't matter how hard it is = to misconfigure, because it is trivial to forge.


_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals




= --Boundary_(ID_Mz7+Xjg8CXbmmfwR8KhWVA)-- From nobody Thu Aug 24 12:34:46 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA23213213D for ; Thu, 24 Aug 2017 12:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 eRW4tiYPE-XV for ; Thu, 24 Aug 2017 12:34:42 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA42A132031 for ; Thu, 24 Aug 2017 12:34:41 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id v29so2266124qtv.3 for ; Thu, 24 Aug 2017 12:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PhRripqSXz8GYSwOVt3tPkAJGzYrWC4pjOkEbNt0mQ0=; b=AZJhuXhv8CcZHDZLor12BBkLTDk7kKCNGMQW0QAQbVxNAgq0l7sQE6RTBA8nqFEwr+ X1j8xf1TyTzcAj/kD0qQ/+4u6veArAv9WRZLZZif/XAyG316KtLtts+EqMdGel3b/hnw FjoCghBbq0GGlI91duM3+mvH2hPK7PxX67MHkWlXSaIu65EGPlTste9xHsI24Nsjkr0D dC4kbP9sBy572+a07ShB+9tkPof5crL7mNpSE/tjae20oQuyhgnA2QtNbINyfG8gzv3q 6nJk+YNhBt5Lb80x1ESS6pCmGvm749DDjpZn7voXTfgmk1rGsS/OO62woHhUtcA2maUA Vrrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PhRripqSXz8GYSwOVt3tPkAJGzYrWC4pjOkEbNt0mQ0=; b=nDrXpilA/ovj0NVJ4TK3CWRTlQuVtnaPC7yBetq6rXWe+lzyWXdv7uwrIKTxGc/7dV 2nNUEXpKEUJANnlZDekQ3W9hiwJRXAd51Cfs/JphHi5eqInUE6Ik12YgXXcjNxf/9FUu suEiDtq5YbtKYREH7RCJI/si1RXxg8qLbqd/LfZEP2Cm7bKhRzsS0h0Lhw2IAQdiPlXl dnLAEUFl8l13VbedpeXClqsBzMZsj7n/B9jWXv8uWd+JsTI5s4RYgArA6NftPizi8U2c vh4s9q7q02/8nZnzQSWayAIYSm2OIWpxfRR2qteoXxpOdD/lASb9rZ9l4fBj/Z71mNnJ wVQw== X-Gm-Message-State: AHYfb5i6+ovUUtS8T/qIkpBigEn4OheFp3T0jz6XwszGzw0fNN5ICig7 3CJ6Wcqfp/X44btFr7RJCL+zUEbxySaJ X-Google-Smtp-Source: ADKCNb5r3z+u9Du5f14y1pVFaVJRlUkbPLkuJ7X0lGSDj1FJCYGVdYpJGMpUHczLk8Blhi3u0IoxsdmHwpcrgF8vh7M= X-Received: by 10.200.47.118 with SMTP id k51mr3768889qta.46.1503603280577; Thu, 24 Aug 2017 12:34:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Thu, 24 Aug 2017 12:34:39 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> From: David Bird Date: Thu, 24 Aug 2017 12:34:39 -0700 Message-ID: To: Tommy Pauly Cc: Lorenzo Colitti , Erik Kline , "Eric Vyncke (evyncke)" , captive-portals@ietf.org, Martin Thomson Content-Type: multipart/alternative; boundary="001a11431cea6cb59a055784ebf9" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 19:34:45 -0000 --001a11431cea6cb59a055784ebf9 Content-Type: text/plain; charset="UTF-8" There are no unsolicited pushes of ICMP by the network; they all have a flow context and in response to traffic (in the latest draft). There isn't any need for an idle device to require notification (and should be left to go idle... stop session, lose lease, etc). The ICMP proposal does allow for "when to re-join the portal" warning notifications... and, when time does expire, the notification is immediate (assuming there is traffic). I'm not convinced this really improves the 'trust model' as the weakest link, as discussed, was in discovery. Having a source to query about information is a good idea, and some networks even already do such things [1]... However, the assumptions behind a PvD web service 'working' are huge.. It will *require* RADIUS Accounting integration such that this API knows when sessions start/stop. It will *require* knowing RADIUS Authorization logic to know, before hand, when the RADIUS server might be sending a CoA to stop the session (to provide the warnings) -- it would also need to be integrated with provisioning logic (be it in RADIUS, or a portal, or both) for situations where a CoA is sent for reasons other than Stop (to change walled garden, session parameters, etc). Should "First Vendor to Release PvD Client" products start getting complaints about their devices having problems at Hotspots, unseen by other devices, what will they do? I was only proposing the client heuristics as something the client _could_ do, should that _threat_ actually materialize... (which I doubt) [1] https://sourceforge.net/p/hotcakes/wiki/Coova%20Chilli%20JSON%20Interface/ On Thu, Aug 24, 2017 at 9:03 AM, Tommy Pauly wrote: > If the client OS needs to add in heuristics to reach a certain volume of > ICMP messages before trusting them, I think the design is flawed. Beyond > that, the information we'd like to get isn't just as simple as a boolean > value that can be aggregated (like unreachable would be). Among the > problems we're trying to solve for CAPPORT is "how much time do I have > left", and "when to re-join the portal". Having a source we can query about > those properties seems to dramatically simplify the flow and trust model. > However we do things, it seems like this information should be pull-able > (even if it allows the client to open a connection on which changes are > pushed or notified) rather than unsolicited pushes of ICMP by the network. > > On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti wrote: > > It seems to me that any solution involving coordination between two > protocols is little different, in terms of your criticism that it will lead > to "a higher rate of misconfiguration", from the PVD solution. (Personally > I don't think that's a valid argument - saying that if you misconfigure the > network it won't work well is pretty much a tautology - but you were the > one that cited that argument in support of the ICMP solution.) > > As for several flows, I don't see what would stop an attacker from trying > to spoof several flows. > > On Fri, Aug 25, 2017 at 12:21 AM, David Bird wrote: > >> You are both describing decisions the UE makes... perhaps the UE waits >> for several flows (with same session-id) to indicate capport warning/errors >> before acting on it... especially when already connected. There were also >> proposals to link the ICMP messages to the DHCP message somehow so that >> ICMP is 'authenticated' against the original DHCP. Theses are solvable >> concerns, not road blocks. >> >> >> >> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly wrote: >> >>> Right, I think the difference between an unreachable destination, and a >>> captive portal or walled garden, is that we expect the captive portal style >>> interaction to be an Operating System-level action, and one that will have >>> consequences on everything the device does while associated to a given >>> network. You can certain use spoofed ICMP to disrupt connections, but (a) >>> the user would notice and (b) you're not causing the Operating System to >>> change behavior. When the OS thinks it is on a captive network or not, it >>> will change what network it considers primary/usable, which may potentially >>> be invisible to the user other than an icon change. I would be able to go >>> onto a captive network, start sending out ICMP messages, and potentially >>> bump other people's connection off the network. >>> >>> Having the UE fetch some resource in order to determine captive state, >>> especially if that resource can be somehow signed, makes it much harder for >>> an attacker to cause the OS to take silent behavior. >>> >>> Tommy >>> >>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti wrote: >>> >>> A forged destination unreachable can't cause someone else's device to >>> think that wifi is a portal and switch to possibly expensive cellular data. >>> >>> On Thu, Aug 24, 2017 at 11:29 PM, David Bird wrote: >>> >>>> Just like the rampant problem we see in ICMP Dest-Unreachable forgery >>>> attacks? >>>> >>>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti >>>> wrote: >>>> >>>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird wrote: >>>>> >>>>>> Can you give an example of how ICMP could be misconfigured? >>>>>> >>>>> >>>>> It doesn't matter how hard it is to misconfigure, because it is >>>>> trivial to forge. >>>>> >>>> >>>> >>> _______________________________________________ >>> Captive-portals mailing list >>> Captive-portals@ietf.org >>> https://www.ietf.org/mailman/listinfo/captive-portals >>> >>> >>> >> > > --001a11431cea6cb59a055784ebf9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are no unsolicited pushes of ICMP by the network; th= ey all have a flow context and in response to traffic (in the latest draft)= . There isn't any need for an idle device to require notification (and = should be left to go idle... stop session, lose lease, etc). The ICMP propo= sal does allow for=C2=A0"when to re-j= oin the portal" warning notifications... and, when time does expire, t= he notification is immediate (assuming there is traffic).=C2=A0
=
I'm not convinced this really improves the 'trust= model' as the weakest link, as discussed, was in discovery. Having a s= ource to query about information is a good idea, and some networks even alr= eady do such things [1]...=C2=A0

However, the= assumptions behind a PvD web service 'working' are huge.. It will = *require* RADIUS Accounting integration such that this API knows when sessi= ons start/stop. It will *require* knowing RADIUS Authorization logic to kno= w, before hand, when the RADIUS server might be sending a CoA to stop the s= ession (to provide the warnings) -- it would also need to be integrated wit= h provisioning logic (be it in RADIUS, or a portal, or both) for situations= where a CoA is sent for reasons other than Stop (to change walled garden, = session parameters, etc).=C2=A0

Should=C2=A0<= /span>"First Vendor to Release PvD Cl= ient" products start getting complaints about their devices having pro= blems at Hotspots, unseen by other devices, what will they do?
=

I was only proposing the client heuristics as something t= he client _could_ do, should that _threat_ actually materialize... (which I= doubt)

=
<= br>
On Thu, Aug 24, 2017 at 9:03 AM, Tommy Pauly = <tpauly@apple.com> wrote:
<= div style=3D"word-wrap:break-word;line-break:after-white-space">
If the= client OS needs to add in heuristics to reach a certain volume of ICMP mes= sages before trusting them, I think the design is flawed. Beyond that, the = information we'd like to get isn't just as simple as a boolean valu= e that can be aggregated (like unreachable would be). Among the problems we= 're trying to solve for CAPPORT is "how much time do I have left&q= uot;, and "when to re-join the portal". Having a source we can qu= ery about those properties seems to dramatically simplify the flow and trus= t model. However we do things, it seems like this information should be pul= l-able (even if it allows the client to open a connection on which changes = are pushed or notified) rather than unsolicited pushes of ICMP by the netwo= rk.

On = Aug 24, 2017, at 8:33 AM, Lorenzo Colitti <lorenzo@google.com> wrote:

=
It seems to me that any solution involving coordination between two pr= otocols is little different, in terms of your criticism that it will lead t= o "a higher rate of misconfiguration", from the PVD solution. (Pe= rsonally I don't think that's a valid argument - saying that if you= misconfigure the network it won't work well is pretty much a tautology= - but you were the one that cited that argument in support of the ICMP sol= ution.)

As for several flows, I don't see = what would stop an attacker from trying to spoof several flows.
=

On Fri, Aug 25, 2= 017 at 12:21 AM, David Bird <dbird@google.com> wrote:
You are both describing decisio= ns the UE makes... perhaps the UE waits for several flows (with same sessio= n-id) to indicate capport warning/errors before acting on it... especially = when already connected. There were also proposals to link the ICMP messages= to the DHCP message somehow so that ICMP is 'authenticated' agains= t the original DHCP. Theses are solvable concerns, not road blocks.=C2=A0


<= div class=3D"gmail_quote">On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <tpa= uly@apple.com> wrote:
Right, I think = the difference between an unreachable destination, and a captive portal or = walled garden, is that we expect the captive portal style interaction to be= an Operating System-level action, and one that will have consequences on e= verything the device does while associated to a given network. You can cert= ain use spoofed ICMP to disrupt connections, but (a) the user would notice = and (b) you're not causing the Operating System to change behavior. Whe= n the OS thinks it is on a captive network or not, it will change what netw= ork it considers primary/usable, which may potentially be invisible to the = user other than an icon change. I would be able to go onto a captive networ= k, start sending out ICMP messages, and potentially bump other people's= connection off the network.=C2=A0

Having the UE fetch s= ome resource in order to determine captive state, especially if that resour= ce can be somehow signed, makes it much harder for an attacker to cause the= OS to take silent behavior.

Tommy

On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
A forged destinat= ion unreachable can't cause someone else's device to think that wif= i is a portal and switch to possibly expensive cellular data.

On Thu, Aug 24, 2017 at 1= 1:29 PM, David Bird <dbird@google.com> wrote:
Just like the rampant problem we see in= ICMP Dest-Unreachable forgery attacks?=C2=A0
<= div class=3D"gmail_extra">
On Thu, Aug 24, 20= 17 at 7:01 AM, Lorenzo Colitti <lorenzo@google.com> wrote:<= br>
On Thu, Aug 24, 2017 at 10:40 PM, David= Bird <dbird@google.com> wrote:
Can you give an= example of how ICMP could be misconfigured?=C2=A0

It doesn't matter how hard it is to m= isconfigure, because it is trivial to forge.


_______________________________________________
Captive-portals mai= ling list
= Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals

<= /div>




--001a11431cea6cb59a055784ebf9-- From nobody Thu Aug 24 13:58:15 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71A7E13238E for ; Thu, 24 Aug 2017 13:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 XZb3UllNWNVG for ; Thu, 24 Aug 2017 13:58:11 -0700 (PDT) Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D940C13235C for ; Thu, 24 Aug 2017 13:58:10 -0700 (PDT) Received: from BLR-EXCHP-2.sandvine.com (192.168.196.172) by WTL-EXCHP-2.sandvine.com (192.168.194.177) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 24 Aug 2017 16:58:08 -0400 Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([::1]) with mapi id 14.03.0319.002; Thu, 24 Aug 2017 16:58:08 -0400 From: Vincent van Dam To: Tommy Pauly , Lorenzo Colitti CC: Erik Kline , "Eric Vyncke (evyncke)" , Martin Thomson , "captive-portals@ietf.org" , David Bird Thread-Topic: [Captive-portals] Questions about PvD/API Thread-Index: AQHTC7XWxrFeE70lFk65jmltS0Fvk6KGdjQAgADjFgCAACltAIADs7qAgAAZXQCAAMYwAIACUQUAgALJqgCAADqIAIACfZ0AgAAF1YCAAAfCgIAAAyaAgAAJeACAAAIGgIAAA1cAgAAIWoCAAA7H5g== Date: Thu, 24 Aug 2017 20:58:06 +0000 Message-ID: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> , In-Reply-To: Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.141.1] x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: multipart/alternative; boundary="_000_D2A19ABBC0147C40BFBB83D1CF3E95F04010655Bwtlexchp2sandvi_" MIME-Version: 1.0 Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 20:58:13 -0000 --_000_D2A19ABBC0147C40BFBB83D1CF3E95F04010655Bwtlexchp2sandvi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree that the information you describe should be pulled from somewhere, = however, I am more concerned _when_ they should be pulled. In this working group we acknowledged (welcomed) use cases that go beyond c= onnecting to a network; the latest example: https://www.ietf.org/mail-archi= ve/web/captive-portals/current/msg00455.html If these use cases are indeed in scope; signalling, or a solution that allo= ws detection that the walled garden is (re)activated after joining the netw= ork, need to be in place. The alternative to a signal would be polling, or = doing some mitm on protocols that allow it. I think both mitm, and polling = regularly to see if the connection state is walled are bad. Just focussing on signalling (without the semantics/api); I think that leav= es us with three directions: * descope any solution that would improve the scenario where walled gardens= are (re-)activated * accept icmp is a valid direction, and think of a way on how we can use th= is securely in our use-case * invent a new signal? something the nas is allowed to send to the ue, but = not icmp? Gr., Vincent ________________________________ Van: Captive-portals [captive-portals-bounces@ietf.org] namens Tommy Pauly = [tpauly@apple.com] Verzonden: donderdag 24 augustus 2017 18:03 Aan: Lorenzo Colitti CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson; captive-portals@ietf= .org; David Bird Onderwerp: Re: [Captive-portals] Questions about PvD/API If the client OS needs to add in heuristics to reach a certain volume of IC= MP messages before trusting them, I think the design is flawed. Beyond that= , the information we'd like to get isn't just as simple as a boolean value = that can be aggregated (like unreachable would be). Among the problems we'r= e trying to solve for CAPPORT is "how much time do I have left", and "when = to re-join the portal". Having a source we can query about those properties= seems to dramatically simplify the flow and trust model. However we do thi= ngs, it seems like this information should be pull-able (even if it allows = the client to open a connection on which changes are pushed or notified) ra= ther than unsolicited pushes of ICMP by the network. On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti > wrote: It seems to me that any solution involving coordination between two protoco= ls is little different, in terms of your criticism that it will lead to "a = higher rate of misconfiguration", from the PVD solution. (Personally I don'= t think that's a valid argument - saying that if you misconfigure the netwo= rk it won't work well is pretty much a tautology - but you were the one tha= t cited that argument in support of the ICMP solution.) As for several flows, I don't see what would stop an attacker from trying t= o spoof several flows. On Fri, Aug 25, 2017 at 12:21 AM, David Bird > wrote: You are both describing decisions the UE makes... perhaps the UE waits for = several flows (with same session-id) to indicate capport warning/errors bef= ore acting on it... especially when already connected. There were also prop= osals to link the ICMP messages to the DHCP message somehow so that ICMP is= 'authenticated' against the original DHCP. Theses are solvable concerns, n= ot road blocks. On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly > wrote: Right, I think the difference between an unreachable destination, and a cap= tive portal or walled garden, is that we expect the captive portal style in= teraction to be an Operating System-level action, and one that will have co= nsequences on everything the device does while associated to a given networ= k. You can certain use spoofed ICMP to disrupt connections, but (a) the use= r would notice and (b) you're not causing the Operating System to change be= havior. When the OS thinks it is on a captive network or not, it will chang= e what network it considers primary/usable, which may potentially be invisi= ble to the user other than an icon change. I would be able to go onto a cap= tive network, start sending out ICMP messages, and potentially bump other p= eople's connection off the network. Having the UE fetch some resource in order to determine captive state, espe= cially if that resource can be somehow signed, makes it much harder for an = attacker to cause the OS to take silent behavior. Tommy On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti > wrote: A forged destination unreachable can't cause someone else's device to think= that wifi is a portal and switch to possibly expensive cellular data. On Thu, Aug 24, 2017 at 11:29 PM, David Bird > wrote: Just like the rampant problem we see in ICMP Dest-Unreachable forgery attac= ks? On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti > wrote: On Thu, Aug 24, 2017 at 10:40 PM, David Bird > wrote: Can you give an example of how ICMP could be misconfigured? It doesn't matter how hard it is to misconfigure, because it is trivial to = forge. _______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals --_000_D2A19ABBC0147C40BFBB83D1CF3E95F04010655Bwtlexchp2sandvi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I agree that the information you desc= ribe should be pulled from somewhere, however, I am more concerned _when_ t= hey should be pulled.


In this working group we acknowledged= (welcomed) use cases that go beyond connecting to a network; the latest ex= ample: https://www.ietf.org/mail-archive/web/captive-portals/current/msg004= 55.html


If these use cases are indeed in scop= e; signalling, or a solution that allows detection that the walled garden i= s (re)activated after joining the network, need to be in place. The alternative to a signal would be polling, or doin= g some mitm on protocols that allow it. I think both mitm, and polling regu= larly to see if the connection state is walled are bad. 


Just focussing on signalling (without= the semantics/api); I think that leaves us with three directions:


* descope any solution that would imp= rove the scenario where walled gardens are (re-)activated

* accept icmp is a valid direction, a= nd think of a way on how we can use this securely in our use-case

* invent a new signal? something the = nas is allowed to send to the ue, but not icmp?


Gr., Vincent


Van: Captive-portals [captive-portals-bou= nces@ietf.org] namens Tommy Pauly [tpauly@apple.com]
Verzonden: donderdag 24 augustus 2017 18:03
Aan: Lorenzo Colitti
CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson; captive-porta= ls@ietf.org; David Bird
Onderwerp: Re: [Captive-portals] Questions about PvD/API

If the client OS needs to add in heuristics to reach a cert= ain volume of ICMP messages before trusting them, I think the design is fla= wed. Beyond that, the information we'd like to get isn't just as simple as = a boolean value that can be aggregated (like unreachable would be). Among the problems we're trying to solve for = CAPPORT is "how much time do I have left", and "when to re-j= oin the portal". Having a source we can query about those properties s= eems to dramatically simplify the flow and trust model. However we do things, it seems like this information should be pull-able (= even if it allows the client to open a connection on which changes are push= ed or notified) rather than unsolicited pushes of ICMP by the network.

On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti <lorenzo@google.com= > wrote:

It seems to me that any solution involving coordination bet= ween two protocols is little different, in terms of your criticism that it = will lead to "a higher rate of misconfiguration", from the PVD so= lution. (Personally I don't think that's a valid argument - saying that if you misconfigure the network it won't work well = is pretty much a tautology - but you were the one that cited that argument = in support of the ICMP solution.)

As for several flows, I don't see what would stop an attack= er from trying to spoof several flows.

On Fri, Aug 25, 2017 at 12:21 AM, David Bird <dbird@= google.com> wrote:
You are both describing decisions the UE makes.= .. perhaps the UE waits for several flows (with same session-id) to indicat= e capport warning/errors before acting on it... especially when already con= nected. There were also proposals to link the ICMP messages to the DHCP message somehow so that ICMP is 'authen= ticated' against the original DHCP. Theses are solvable concerns, not road = blocks. 



On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <tpauly= @apple.com> wrote:

Having the UE fetch some resource in order to determine cap= tive state, especially if that resource can be somehow signed, makes it muc= h harder for an attacker to cause the OS to take silent behavior.
Tommy

On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti <lorenzo@google.com= > wrote:

A forged destination unreachable can't cause so= meone else's device to think that wifi is a portal and switch to possibly e= xpensive cellular data.

On Thu, Aug 24, 2017 at 11:29 PM, David Bird <dbird@= google.com> wrote:
Just like the rampant problem we see in ICMP De= st-Unreachable forgery attacks? 

On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti= <lore= nzo@google.com> wrote:
On Thu, Aug 24, 2017 at 10:40 P= M, David Bird <dbird@google.com> wrote:
Can you give an= example of how ICMP could be misconfigured? 
It doesn't matter how hard it is to misconfigure, because i= t is trivial to forge.


__________________________________________= _____
Captive-portals mailing list
Ca= ptive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/c= aptive-portals




--_000_D2A19ABBC0147C40BFBB83D1CF3E95F04010655Bwtlexchp2sandvi_-- From nobody Thu Aug 24 16:55:46 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08FA13295F for ; Thu, 24 Aug 2017 16:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BNGGrC1dc_cJ for ; Thu, 24 Aug 2017 16:55:42 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C07D13293A for ; Thu, 24 Aug 2017 16:55:42 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id s101so3380433ioe.0 for ; Thu, 24 Aug 2017 16:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lzK+8qU0CPy2h3LT4iJGRpbJGCzx+EvynSbYd0o3rrw=; b=Fri5ObOFAVrToyrVYElE+BBKddxCDpDjMjWipkSeaBbW4Ym15/vLINIro5O9nQdHBh 2eJt+rXHhgA2pY6cJCh4kFjw+OCJvbvjogzjI2Cr3MlYZTxnD6vzpBBY++uQa/lr7d8c A4IfPFzT1PG5tWjI1JiNHBPBhElPhDP+1N75DHnvAIBD3dpqD0D/JfsGiMVro7G+LC1x I/qiKVJFeFAQ79tRTOV75cFUEq+8hV1S6JQyWC6Nia26gvNK24S7BMUEmcnK7J9PDS9o eh5KI0O6nySdWMk4Qy1lYOZVBacmWaIGzhx/IdKKVGWYKn+6/eDprBiuRJENj9DZMXYs wfqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lzK+8qU0CPy2h3LT4iJGRpbJGCzx+EvynSbYd0o3rrw=; b=mC+ehWj/2lqlSQJpRrgbd++jeMmB8k7QDpLy62bV7T3nfBCLRARzoaEIxyn0C/R2aD 65D9e2W88N32/wI/Cp7+MQblaKDU6lnLsEcFebzvjknVxERIpVBs20Jg9DwCqMst6Vph ZctdyHJFQMdEC4Z14Bj8JVXcD7iV0lNYpx4fA/wmcZpZr+mBb6E+n3hFw10NgEu3fjNH WBsduXk6w1Xmszzge4g4lUGTPhBfBXm6IXrirtr7RMrJhrSZMlh3xQxgTbrxN4k+yUsu 0Q5DD9xxwIVX5FZqUS5+CXXpUtQN6U+wfkYZvB4kdThtgukVF1uta8SEQiNQvSsyPt+0 7RDw== X-Gm-Message-State: AHYfb5gtl2TUGaxupX7TTMTc+hQuIrW1OaT8lrRm2R64cHho6DLx2Yb0 8pwkNEbkFsDV7WWLU6tD1tiRu/9vCQ== X-Received: by 10.107.180.72 with SMTP id d69mr6686549iof.291.1503618941318; Thu, 24 Aug 2017 16:55:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Thu, 24 Aug 2017 16:55:40 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> From: Martin Thomson Date: Fri, 25 Aug 2017 09:55:40 +1000 Message-ID: To: Vincent van Dam Cc: Tommy Pauly , Lorenzo Colitti , Erik Kline , "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" , David Bird Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Aug 2017 23:55:45 -0000 What is interesting about Heiko's example here is that this transition is not necessarily visible to endpoints. Nor can they be forewarned (assuming they are ignorant of the botnet using their link). Endpoints were previously on a network without a captive portal, but one is suddenly interjected. I see several problems, different for each of the various solutions: * With 7710 or PvD, the original network would have to be provisioned with a captive portal, or the switch would happen and the endpoint won't have a URI to talk to. That seems relatively tractable, providing that this didn't lead to a false assumption of captivity (this is a problem with 7710, I think, because the existence of the option seems to imply captivity, though this is quite unclear from the RFC). * With ICMP, the signal comes from more than one hop away. An unmodified router in the home would receive the ICMP message, reduce the TTL and then it looks like a random Internet host was trying to deny service. So running through all the combinations: 7710/PvD + ICMP - you know where to go to get status information and the network can signal 7710/PvD - ICMP - you know where to go to get status information, but how would you decide to ask? Is there some other trigger you would use? (This is, I think Vincent's question.) ICMP - 7710/PvD - you get a signal, but is it legit? How do you validate it? Neither - that's the situation we have today. It seems that there are at least a few people who think that this use case is in scope. It doesn't seem materially different from the case where you run out of bytes (for networks that do accounting that way). Maybe this use case can inform the design a little better. Or maybe someone would like to argue that we don't need to worry about this. On 25 August 2017 at 06:58, Vincent van Dam wrote: > I agree that the information you describe should be pulled from somewhere, > however, I am more concerned _when_ they should be pulled. > > > In this working group we acknowledged (welcomed) use cases that go beyond > connecting to a network; the latest example: > https://www.ietf.org/mail-archive/web/captive-portals/current/msg00455.html > > > If these use cases are indeed in scope; signalling, or a solution that > allows detection that the walled garden is (re)activated after joining the > network, need to be in place. The alternative to a signal would be polling, > or doing some mitm on protocols that allow it. I think both mitm, and > polling regularly to see if the connection state is walled are bad. > > > Just focussing on signalling (without the semantics/api); I think that > leaves us with three directions: > > > * descope any solution that would improve the scenario where walled gardens > are (re-)activated > > * accept icmp is a valid direction, and think of a way on how we can use > this securely in our use-case > > * invent a new signal? something the nas is allowed to send to the ue, but > not icmp? > > > Gr., Vincent > > > ________________________________ > Van: Captive-portals [captive-portals-bounces@ietf.org] namens Tommy Pauly > [tpauly@apple.com] > Verzonden: donderdag 24 augustus 2017 18:03 > Aan: Lorenzo Colitti > CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson; > captive-portals@ietf.org; David Bird > Onderwerp: Re: [Captive-portals] Questions about PvD/API > > If the client OS needs to add in heuristics to reach a certain volume of > ICMP messages before trusting them, I think the design is flawed. Beyond > that, the information we'd like to get isn't just as simple as a boolean > value that can be aggregated (like unreachable would be). Among the problems > we're trying to solve for CAPPORT is "how much time do I have left", and > "when to re-join the portal". Having a source we can query about those > properties seems to dramatically simplify the flow and trust model. However > we do things, it seems like this information should be pull-able (even if it > allows the client to open a connection on which changes are pushed or > notified) rather than unsolicited pushes of ICMP by the network. > > On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti wrote: > > It seems to me that any solution involving coordination between two > protocols is little different, in terms of your criticism that it will lead > to "a higher rate of misconfiguration", from the PVD solution. (Personally I > don't think that's a valid argument - saying that if you misconfigure the > network it won't work well is pretty much a tautology - but you were the one > that cited that argument in support of the ICMP solution.) > > As for several flows, I don't see what would stop an attacker from trying to > spoof several flows. > > On Fri, Aug 25, 2017 at 12:21 AM, David Bird wrote: >> >> You are both describing decisions the UE makes... perhaps the UE waits for >> several flows (with same session-id) to indicate capport warning/errors >> before acting on it... especially when already connected. There were also >> proposals to link the ICMP messages to the DHCP message somehow so that ICMP >> is 'authenticated' against the original DHCP. Theses are solvable concerns, >> not road blocks. >> >> >> >> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly wrote: >>> >>> Right, I think the difference between an unreachable destination, and a >>> captive portal or walled garden, is that we expect the captive portal style >>> interaction to be an Operating System-level action, and one that will have >>> consequences on everything the device does while associated to a given >>> network. You can certain use spoofed ICMP to disrupt connections, but (a) >>> the user would notice and (b) you're not causing the Operating System to >>> change behavior. When the OS thinks it is on a captive network or not, it >>> will change what network it considers primary/usable, which may potentially >>> be invisible to the user other than an icon change. I would be able to go >>> onto a captive network, start sending out ICMP messages, and potentially >>> bump other people's connection off the network. >>> >>> Having the UE fetch some resource in order to determine captive state, >>> especially if that resource can be somehow signed, makes it much harder for >>> an attacker to cause the OS to take silent behavior. >>> >>> Tommy >>> >>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti wrote: >>> >>> A forged destination unreachable can't cause someone else's device to >>> think that wifi is a portal and switch to possibly expensive cellular data. >>> >>> On Thu, Aug 24, 2017 at 11:29 PM, David Bird wrote: >>>> >>>> Just like the rampant problem we see in ICMP Dest-Unreachable forgery >>>> attacks? >>>> >>>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti >>>> wrote: >>>>> >>>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird wrote: >>>>>> >>>>>> Can you give an example of how ICMP could be misconfigured? >>>>> >>>>> >>>>> It doesn't matter how hard it is to misconfigure, because it is trivial >>>>> to forge. >>>> >>>> >>> >>> _______________________________________________ >>> Captive-portals mailing list >>> Captive-portals@ietf.org >>> https://www.ietf.org/mailman/listinfo/captive-portals >>> >>> >> > > From nobody Thu Aug 24 18:49:11 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB0E1329DC for ; Thu, 24 Aug 2017 18:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 RKCx976ap8JG for ; Thu, 24 Aug 2017 18:49:04 -0700 (PDT) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96295132197 for ; Thu, 24 Aug 2017 18:49:03 -0700 (PDT) Received: by mail-qk0-x22c.google.com with SMTP id p67so5873955qkd.2 for ; Thu, 24 Aug 2017 18:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PI0jxBgFR2eHGqYNb0E9ITk+rU+DXab/RlF+924DXZA=; b=L6EA13aBMERSIfBnsWUdIQu4R9OFGM3QO9RvToR0SHE8oWBWFELRR+HC1PpLP8thL3 sR8iCNWjA1OKLDG2qPzA9Iy/PGRpltTMv2QwB5ieNigYlrI5omTxJ/rZXLshgR+O70c0 pu8ld/TcNhp2CRZxqG7F0aYtI04uIsHcHJPHH7JbzlTkLRanqGGslzG5e6SzPQNZh9mX fUA34Bw62nmoX3LHBentCZhKnnWWS6GaYNYJf/lSAFnQq9BBhQFRCA5mVtJJz+KNw7Oc 7WADUKJVYmbD9wKb+JSGofHsVD50TN5acTrZQndBkqV6EksheizMg7KHkxW+MtbCb25Z Q3Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PI0jxBgFR2eHGqYNb0E9ITk+rU+DXab/RlF+924DXZA=; b=Kzuedn2kwBisb6QZDeres4vn14NFcJVtOjnbVPTOJBWaRVFqJ7dgCSAmT2xsfrVXFi 5WPGTcxrNUyTGwkrf1etrJw6iiI/oJMQZiM0UzD3+0g0LzG6vxTF40QulXIHMukfFHdx 1lHQ5DuroloX4IbBS1/4WBR0xMtvpnXFM+CvOLJXjTuGJqPXSBfXVxFbahweOeI0wEYU bVxLOEYTyuzp0WZFJgQq+UNs2r2ociSuWo83Y1mrFp44+Xgh3S6tE16UW9cVQLISs1l9 5IEWl51JRu+DsoHHfRSR1Dxy2lLQDT68Vy+0bXsFGrYJcmcpD8pHolxPf5LVf535wt7R mJDg== X-Gm-Message-State: AHYfb5hveEleNvVCyPRscZ+PV7GbTxJSLiJyzW9Ghu3BD3AciprUL36j kJ1dgxIYIXE9ywHP42mJqR1ArvQVKU/W X-Google-Smtp-Source: ADKCNb4C9S8n1VmJ0ebfWT5jZ9KWPXAgcAkLBeU33n3W/qQ2N+Qp0GZGdbeqTc34b5xuFUXjI1xCZJJRkaPjF87yEFw= X-Received: by 10.55.212.18 with SMTP id l18mr12721969qki.42.1503625742303; Thu, 24 Aug 2017 18:49:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Thu, 24 Aug 2017 18:49:01 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> From: David Bird Date: Thu, 24 Aug 2017 18:49:01 -0700 Message-ID: To: Martin Thomson Cc: Vincent van Dam , Tommy Pauly , Lorenzo Colitti , Erik Kline , "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" Content-Type: multipart/alternative; boundary="001a11479db23f24c305578a26fd" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 01:49:08 -0000 --001a11479db23f24c305578a26fd Content-Type: text/plain; charset="UTF-8" I don't see RFC7710 grouped with PvD and vs ICMP. In fact, RFC7710 is required in the ICMP draft. So, it should be 7710 & ICMP vs PvD. Nobody is arguing 7710 should stand alone, or is useful by itself. There are unique considerations when the captive portal "client" is a router and not the UE... In this example, no clients get 'released' from captivity - so, it doesn't really have to trace clients by IP address. The CPE firmware needs updating to have RFC7710 configurable via their management system -- this might be a good opportunity to have a minimal Capport ICMP based captive portal implemented completely in CPE firmware, perhaps Linux iptables w/Capport ICMP support. Assuming they don't do that (but do get RFC 7710 supported), the CPE can be configuring clients for Capport and ICMP coming multiple hops away.. validated by (yet to be defined) material in the original DHCP/RA, is just fine... (better, maybe the CPE reconfigures into a bridge and has a L2 capport in the NOC, which can maybe help users identity exactly which machine has the virus....) There is no harm, btw, in having RFC7710 *always* configured in networks that support features like this... it could be a multi-purpose portal. RFC 7710 should always be ignored until (yet to be defined) notification is received. On Thu, Aug 24, 2017 at 4:55 PM, Martin Thomson wrote: > What is interesting about Heiko's example here is that this transition > is not necessarily visible to endpoints. Nor can they be forewarned > (assuming they are ignorant of the botnet using their link). > Endpoints were previously on a network without a captive portal, but > one is suddenly interjected. > > I see several problems, different for each of the various solutions: > > * With 7710 or PvD, the original network would have to be provisioned > with a captive portal, or the switch would happen and the endpoint > won't have a URI to talk to. That seems relatively tractable, > providing that this didn't lead to a false assumption of captivity > (this is a problem with 7710, I think, because the existence of the > option seems to imply captivity, though this is quite unclear from the > RFC). > > * With ICMP, the signal comes from more than one hop away. An > unmodified router in the home would receive the ICMP message, reduce > the TTL and then it looks like a random Internet host was trying to > deny service. > > So running through all the combinations: > > 7710/PvD + ICMP - you know where to go to get status information and > the network can signal > > 7710/PvD - ICMP - you know where to go to get status information, but > how would you decide to ask? Is there some other trigger you would > use? (This is, I think Vincent's question.) > > ICMP - 7710/PvD - you get a signal, but is it legit? How do you validate > it? > > Neither - that's the situation we have today. > > It seems that there are at least a few people who think that this use > case is in scope. It doesn't seem materially different from the case > where you run out of bytes (for networks that do accounting that way). > Maybe this use case can inform the design a little better. Or maybe > someone would like to argue that we don't need to worry about this. > > > > On 25 August 2017 at 06:58, Vincent van Dam wrote: > > I agree that the information you describe should be pulled from > somewhere, > > however, I am more concerned _when_ they should be pulled. > > > > > > In this working group we acknowledged (welcomed) use cases that go beyond > > connecting to a network; the latest example: > > https://www.ietf.org/mail-archive/web/captive-portals/ > current/msg00455.html > > > > > > If these use cases are indeed in scope; signalling, or a solution that > > allows detection that the walled garden is (re)activated after joining > the > > network, need to be in place. The alternative to a signal would be > polling, > > or doing some mitm on protocols that allow it. I think both mitm, and > > polling regularly to see if the connection state is walled are bad. > > > > > > Just focussing on signalling (without the semantics/api); I think that > > leaves us with three directions: > > > > > > * descope any solution that would improve the scenario where walled > gardens > > are (re-)activated > > > > * accept icmp is a valid direction, and think of a way on how we can use > > this securely in our use-case > > > > * invent a new signal? something the nas is allowed to send to the ue, > but > > not icmp? > > > > > > Gr., Vincent > > > > > > ________________________________ > > Van: Captive-portals [captive-portals-bounces@ietf.org] namens Tommy > Pauly > > [tpauly@apple.com] > > Verzonden: donderdag 24 augustus 2017 18:03 > > Aan: Lorenzo Colitti > > CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson; > > captive-portals@ietf.org; David Bird > > Onderwerp: Re: [Captive-portals] Questions about PvD/API > > > > If the client OS needs to add in heuristics to reach a certain volume of > > ICMP messages before trusting them, I think the design is flawed. Beyond > > that, the information we'd like to get isn't just as simple as a boolean > > value that can be aggregated (like unreachable would be). Among the > problems > > we're trying to solve for CAPPORT is "how much time do I have left", and > > "when to re-join the portal". Having a source we can query about those > > properties seems to dramatically simplify the flow and trust model. > However > > we do things, it seems like this information should be pull-able (even > if it > > allows the client to open a connection on which changes are pushed or > > notified) rather than unsolicited pushes of ICMP by the network. > > > > On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti wrote: > > > > It seems to me that any solution involving coordination between two > > protocols is little different, in terms of your criticism that it will > lead > > to "a higher rate of misconfiguration", from the PVD solution. > (Personally I > > don't think that's a valid argument - saying that if you misconfigure the > > network it won't work well is pretty much a tautology - but you were the > one > > that cited that argument in support of the ICMP solution.) > > > > As for several flows, I don't see what would stop an attacker from > trying to > > spoof several flows. > > > > On Fri, Aug 25, 2017 at 12:21 AM, David Bird wrote: > >> > >> You are both describing decisions the UE makes... perhaps the UE waits > for > >> several flows (with same session-id) to indicate capport warning/errors > >> before acting on it... especially when already connected. There were > also > >> proposals to link the ICMP messages to the DHCP message somehow so that > ICMP > >> is 'authenticated' against the original DHCP. Theses are solvable > concerns, > >> not road blocks. > >> > >> > >> > >> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly wrote: > >>> > >>> Right, I think the difference between an unreachable destination, and a > >>> captive portal or walled garden, is that we expect the captive portal > style > >>> interaction to be an Operating System-level action, and one that will > have > >>> consequences on everything the device does while associated to a given > >>> network. You can certain use spoofed ICMP to disrupt connections, but > (a) > >>> the user would notice and (b) you're not causing the Operating System > to > >>> change behavior. When the OS thinks it is on a captive network or not, > it > >>> will change what network it considers primary/usable, which may > potentially > >>> be invisible to the user other than an icon change. I would be able to > go > >>> onto a captive network, start sending out ICMP messages, and > potentially > >>> bump other people's connection off the network. > >>> > >>> Having the UE fetch some resource in order to determine captive state, > >>> especially if that resource can be somehow signed, makes it much > harder for > >>> an attacker to cause the OS to take silent behavior. > >>> > >>> Tommy > >>> > >>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti > wrote: > >>> > >>> A forged destination unreachable can't cause someone else's device to > >>> think that wifi is a portal and switch to possibly expensive cellular > data. > >>> > >>> On Thu, Aug 24, 2017 at 11:29 PM, David Bird wrote: > >>>> > >>>> Just like the rampant problem we see in ICMP Dest-Unreachable forgery > >>>> attacks? > >>>> > >>>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti > >>>> wrote: > >>>>> > >>>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird > wrote: > >>>>>> > >>>>>> Can you give an example of how ICMP could be misconfigured? > >>>>> > >>>>> > >>>>> It doesn't matter how hard it is to misconfigure, because it is > trivial > >>>>> to forge. > >>>> > >>>> > >>> > >>> _______________________________________________ > >>> Captive-portals mailing list > >>> Captive-portals@ietf.org > >>> https://www.ietf.org/mailman/listinfo/captive-portals > >>> > >>> > >> > > > > > --001a11479db23f24c305578a26fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't see RFC7710 grouped with PvD and vs ICMP. In f= act, RFC7710 is required in the ICMP draft.=C2=A0

So, it= should be 7710 & ICMP vs PvD. Nobody is arguing 7710 should stand alon= e, or is useful by itself.=C2=A0

There are unique = considerations when the captive portal "client" is a router and n= ot the UE... In this example, no clients get 'released' from captiv= ity - so, it doesn't really have to trace clients by IP address. The CP= E firmware needs updating to have RFC7710 configurable via their management= system -- this might be a good opportunity to have a minimal Capport ICMP = based captive portal implemented completely in CPE firmware, perhaps Linux = iptables w/Capport ICMP support. Assuming they don't do that (but do ge= t RFC 7710 supported), the CPE can be configuring clients for Capport and I= CMP coming multiple hops away.. validated by (yet to be defined) material i= n the original DHCP/RA, is just fine... (better, maybe the CPE reconfigures= into a bridge and has a L2 capport in the NOC, which can maybe help users = identity exactly which machine has the virus....)

= There is no harm, btw, in having RFC7710 *always* configured in networks th= at support features like this... it could be a multi-purpose portal. RFC 77= 10 should always be ignored until (yet to be defined) notification is recei= ved.=C2=A0






On Thu, Aug 24, 2017 at 4:55 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
What is= interesting about Heiko's example here is that this transition
is not necessarily visible to endpoints. Nor can they be forewarned
(assuming they are ignorant of the botnet using their link).
Endpoints were previously on a network without a captive portal, but
one is suddenly interjected.

I see several problems, different for each of the various solutions:

* With 7710 or PvD, the original network would have to be provisioned
with a captive portal, or the switch would happen and the endpoint
won't have a URI to talk to.=C2=A0 That seems relatively tractable,
providing that this didn't lead to a false assumption of captivity
(this is a problem with 7710, I think, because the existence of the
option seems to imply captivity, though this is quite unclear from the
RFC).

* With ICMP, the signal comes from more than one hop away.=C2=A0 An
unmodified router in the home would receive the ICMP message, reduce
the TTL and then it looks like a random Internet host was trying to
deny service.

So running through all the combinations:

7710/PvD + ICMP - you know where to go to get status information and
the network can signal

7710/PvD - ICMP - you know where to go to get status information, but
how would you decide to ask?=C2=A0 Is there some other trigger you would use?=C2=A0 (This is, I think Vincent's question.)

ICMP - 7710/PvD - you get a signal, but is it legit?=C2=A0 How do you valid= ate it?

Neither - that's the situation we have today.

It seems that there are at least a few people who think that this use
case is in scope.=C2=A0 It doesn't seem materially different from the c= ase
where you run out of bytes (for networks that do accounting that way).
Maybe this use case can inform the design a little better.=C2=A0 Or maybe someone would like to argue that we don't need to worry about this.



On 25 August 2017 at 06:58, Vincent van Dam <VvanDam@sandvine.com> wrote:
> I agree that the information you describe should be pulled from somewh= ere,
> however, I am more concerned _when_ they should be pulled.
>
>
> In this working group we acknowledged (welcomed) use cases that go bey= ond
> connecting to a network; the latest example:
> https://www.ietf.org= /mail-archive/web/captive-portals/current/msg00455.html
>
>
> If these use cases are indeed in scope; signalling, or a solution that=
> allows detection that the walled garden is (re)activated after joining= the
> network, need to be in place. The alternative to a signal would be pol= ling,
> or doing some mitm on protocols that allow it. I think both mitm, and<= br> > polling regularly to see if the connection state is walled are bad. >
>
> Just focussing on signalling (without the semantics/api); I think that=
> leaves us with three directions:
>
>
> * descope any solution that would improve the scenario where walled ga= rdens
> are (re-)activated
>
> * accept icmp is a valid direction, and think of a way on how we can u= se
> this securely in our use-case
>
> * invent a new signal? something the nas is allowed to send to the ue,= but
> not icmp?
>
>
> Gr., Vincent
>
>
> ________________________________
> Van: Captive-portals [captive-portals-bounces@ietf.org] namens Tommy Pauly
> [tpauly@apple.com]
> Verzonden: donderdag 24 augustus 2017 18:03
> Aan: Lorenzo Colitti
> CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson;
> captive-portals@ietf.org; David Bird
> Onderwerp: Re: [Captive-portals] Questions about PvD/API
>
> If the client OS needs to add in heuristics to reach a certain volume = of
> ICMP messages before trusting them, I think the design is flawed. Beyo= nd
> that, the information we'd like to get isn't just as simple as= a boolean
> value that can be aggregated (like unreachable would be). Among the pr= oblems
> we're trying to solve for CAPPORT is "how much time do I have= left", and
> "when to re-join the portal". Having a source we can query a= bout those
> properties seems to dramatically simplify the flow and trust model. Ho= wever
> we do things, it seems like this information should be pull-able (even= if it
> allows the client to open a connection on which changes are pushed or<= br> > notified) rather than unsolicited pushes of ICMP by the network.
>
> On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>
> It seems to me that any solution involving coordination between two > protocols is little different, in terms of your criticism that it will= lead
> to "a higher rate of misconfiguration", from the PVD solutio= n. (Personally I
> don't think that's a valid argument - saying that if you misco= nfigure the
> network it won't work well is pretty much a tautology - but you we= re the one
> that cited that argument in support of the ICMP solution.)
>
> As for several flows, I don't see what would stop an attacker from= trying to
> spoof several flows.
>
> On Fri, Aug 25, 2017 at 12:21 AM, David Bird <dbird@google.com> wrote:
>>
>> You are both describing decisions the UE makes... perhaps the UE w= aits for
>> several flows (with same session-id) to indicate capport warning/e= rrors
>> before acting on it... especially when already connected. There we= re also
>> proposals to link the ICMP messages to the DHCP message somehow so= that ICMP
>> is 'authenticated' against the original DHCP. Theses are s= olvable concerns,
>> not road blocks.
>>
>>
>>
>> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <tpauly@apple.com> wrote:
>>>
>>> Right, I think the difference between an unreachable destinati= on, and a
>>> captive portal or walled garden, is that we expect the captive= portal style
>>> interaction to be an Operating System-level action, and one th= at will have
>>> consequences on everything the device does while associated to= a given
>>> network. You can certain use spoofed ICMP to disrupt connectio= ns, but (a)
>>> the user would notice and (b) you're not causing the Opera= ting System to
>>> change behavior. When the OS thinks it is on a captive network= or not, it
>>> will change what network it considers primary/usable, which ma= y potentially
>>> be invisible to the user other than an icon change. I would be= able to go
>>> onto a captive network, start sending out ICMP messages, and p= otentially
>>> bump other people's connection off the network.
>>>
>>> Having the UE fetch some resource in order to determine captiv= e state,
>>> especially if that resource can be somehow signed, makes it mu= ch harder for
>>> an attacker to cause the OS to take silent behavior.
>>>
>>> Tommy
>>>
>>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>>>
>>> A forged destination unreachable can't cause someone else&= #39;s device to
>>> think that wifi is a portal and switch to possibly expensive c= ellular data.
>>>
>>> On Thu, Aug 24, 2017 at 11:29 PM, David Bird <dbird@google.com> wrote:
>>>>
>>>> Just like the rampant problem we see in ICMP Dest-Unreacha= ble forgery
>>>> attacks?
>>>>
>>>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti <lorenzo@google.com>
>>>> wrote:
>>>>>
>>>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird <dbird@google.com> wrote:
>>>>>>
>>>>>> Can you give an example of how ICMP could be misco= nfigured?
>>>>>
>>>>>
>>>>> It doesn't matter how hard it is to misconfigure, = because it is trivial
>>>>> to forge.
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Captive-portals mailing list
>>> Captive-portals@ie= tf.org
>>> https://www.ietf.org/mailman/= listinfo/captive-portals
>>>
>>>
>>
>
>

--001a11479db23f24c305578a26fd-- From nobody Thu Aug 24 19:09:17 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9911329F9 for ; Thu, 24 Aug 2017 19:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 feA77mNduvAC for ; Thu, 24 Aug 2017 19:09:12 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B2601329F6 for ; Thu, 24 Aug 2017 19:09:12 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id n5so1949730itb.1 for ; Thu, 24 Aug 2017 19:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=soyf2CS9HUyU9j9FtYp1brm1bmzAt7GbXLXZTGXCABs=; b=g+Ju89LRuMnNzxlAicTNC/3JDUAs28uACzTa0ySxmOetZpkVPPMSx7h5KDcvU8TU2L u6bx1TNmIQrVvln7MAu8PCj9/zJSEv15wp5+KST3pVDreGk7XTShui73bPShvJpzV/+4 r1wOS16eFvdlzFfseneK6n//o3vsbF5r7hqbc9tuTbo42pnm6I5Z0go3rTt1Fl39nCC8 oJChc9XvrCoRW0E4cwqT0a1bkS2NoZbCnAmxbYtTjjgS3AH7gpmLGNIFJqrRRgmlRpvY WPk6e+dy5NM1rLOmrePjPsGVE22HJvKzKzM1MqJTnhnrSwboGfdK9Wus4VemLy1Yrflg KxSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=soyf2CS9HUyU9j9FtYp1brm1bmzAt7GbXLXZTGXCABs=; b=Q2OYKHYXVbpInp3sN1+lyjsxG4yYTageyMrmJj7Cy4RHDcyhmPAffye8MDf7xU2KTS VOeLlSnUvmgU3mj2/CPfB6pS9GeibCRzCLoP7fgXPcdBb8Jqif/A56LmrQX6lFIvyF23 7i4TjTpDsOsUCGmwX9NaQk3u0AleVXRCDuN/GokH6NAE6jpGjC00TDGNUiKZp1C+khtF VCanenbv6R1h/pnuu7s82HsNBDlSbn+tcyhaUdDCEqJWKksmQOlJKNVCwtC8UJUlCosM CFhDXgnDm6UdmwFJBZLmB7oqRoPkvz0KiUXfYOOkzrWVWKTsusQHTefXWgfIKlLPZ97G J5mg== X-Gm-Message-State: AHYfb5j/vfJso5feJFA+2FK9+u1uFd5cIiaT93fvvIhFwL7OxA3Y8cwS vjFNN0mLpzf47mARNfEWv41LGlyOmA== X-Received: by 10.36.57.207 with SMTP id l198mr663900ita.44.1503626951397; Thu, 24 Aug 2017 19:09:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.133.37 with HTTP; Thu, 24 Aug 2017 19:09:10 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> From: Martin Thomson Date: Fri, 25 Aug 2017 12:09:10 +1000 Message-ID: To: David Bird Cc: Vincent van Dam , Tommy Pauly , Lorenzo Colitti , Erik Kline , "Eric Vyncke (evyncke)" , "captive-portals@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Captive-portals] Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Aug 2017 02:09:15 -0000 Hmm, maybe we understand this very differently then. I see PvD as providing configuration in exactly the same way as 7710 does. That is, * 7710 says "here is the URL you go to for ???" where "???" is one or both of "web browsing" and "API" (see the API doc). It doesn't really say whether the endpoint is currently captive or not (and nor can it do so). * PvD, as I understand it, would say the same, though it might provide separate "web browsing" and "API" URLs, if we accept that an API is valuable (see below). It *could* also act in the "API" role, and I think that Tommy in particular finds that idea appealing, but my understanding was that we would consider that to be a logically distinct function. If, as we seem to have agreed in Prague, consider API to be basically reduced to "am I captive? y/n" and maybe "for how long?

My = concern is that after all this work... UEs will still be doing legacy probi= ng...=C2=A0

On Thu, Aug 24, 2017 at 7:09 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
Hmm, maybe we understand this very differently then.=C2=A0 I se= e PvD as
providing configuration in exactly the same way as 7710 does.

That is,

* 7710 says "here is the URL you go to for ???"=C2=A0 where "= ;???" is one or
both of "web browsing" and "API" (see the API doc).=C2= =A0 It doesn't really
say whether the endpoint is currently captive or not (and nor can it
do so).

* PvD, as I understand it, would say the same, though it might provide
separate "web browsing" and "API" URLs, if we accept th= at an API is
valuable (see below).=C2=A0 It *could* also act in the "API" role= , and I
think that Tommy in particular finds that idea appealing, but my
understanding was that we would consider that to be a logically
distinct function.

If, as we seem to have agreed in Prague, consider API to be basically
reduced to "am I captive? y/n" and maybe "for how long? <= time>" for
now.

You seem to be most concerned about the potential for an API that
could make claims about whether a given host is captive or not.=C2=A0 Is that the source of your concerns here?

If we agree - as seem to, based on your comments here - that the
configuration of a URL has no effect until the host discovers that it
is captive (somehow), is this a concern more about the API than the
existence of a mechanism like PvD?

(NOC =3D=3D NIC?)

On 25 August 2017 at 11:49, David Bird <dbird@google.com> wrote:
> I don't see RFC7710 grouped with PvD and vs ICMP. In fact, RFC7710= is
> required in the ICMP draft.
>
> So, it should be 7710 & ICMP vs PvD. Nobody is arguing 7710 should= stand
> alone, or is useful by itself.
>
> There are unique considerations when the captive portal "client&q= uot; is a router
> and not the UE... In this example, no clients get 'released' f= rom captivity
> - so, it doesn't really have to trace clients by IP address. The C= PE
> firmware needs updating to have RFC7710 configurable via their managem= ent
> system -- this might be a good opportunity to have a minimal Capport I= CMP
> based captive portal implemented completely in CPE firmware, perhaps L= inux
> iptables w/Capport ICMP support. Assuming they don't do that (but = do get RFC
> 7710 supported), the CPE can be configuring clients for Capport and IC= MP
> coming multiple hops away.. validated by (yet to be defined) material = in the
> original DHCP/RA, is just fine... (better, maybe the CPE reconfigures = into a
> bridge and has a L2 capport in the NOC, which can maybe help users ide= ntity
> exactly which machine has the virus....)
>
> There is no harm, btw, in having RFC7710 *always* configured in networ= ks
> that support features like this... it could be a multi-purpose portal.= RFC
> 7710 should always be ignored until (yet to be defined) notification i= s
> received.
>
>
>
>
>
>
> On Thu, Aug 24, 2017 at 4:55 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>> What is interesting about Heiko's example here is that this tr= ansition
>> is not necessarily visible to endpoints. Nor can they be forewarne= d
>> (assuming they are ignorant of the botnet using their link).
>> Endpoints were previously on a network without a captive portal, b= ut
>> one is suddenly interjected.
>>
>> I see several problems, different for each of the various solution= s:
>>
>> * With 7710 or PvD, the original network would have to be provisio= ned
>> with a captive portal, or the switch would happen and the endpoint=
>> won't have a URI to talk to.=C2=A0 That seems relatively tract= able,
>> providing that this didn't lead to a false assumption of capti= vity
>> (this is a problem with 7710, I think, because the existence of th= e
>> option seems to imply captivity, though this is quite unclear from= the
>> RFC).
>>
>> * With ICMP, the signal comes from more than one hop away.=C2=A0 A= n
>> unmodified router in the home would receive the ICMP message, redu= ce
>> the TTL and then it looks like a random Internet host was trying t= o
>> deny service.
>>
>> So running through all the combinations:
>>
>> 7710/PvD + ICMP - you know where to go to get status information a= nd
>> the network can signal
>>
>> 7710/PvD - ICMP - you know where to go to get status information, = but
>> how would you decide to ask?=C2=A0 Is there some other trigger you= would
>> use?=C2=A0 (This is, I think Vincent's question.)
>>
>> ICMP - 7710/PvD - you get a signal, but is it legit?=C2=A0 How do = you validate
>> it?
>>
>> Neither - that's the situation we have today.
>>
>> It seems that there are at least a few people who think that this = use
>> case is in scope.=C2=A0 It doesn't seem materially different f= rom the case
>> where you run out of bytes (for networks that do accounting that w= ay).
>> Maybe this use case can inform the design a little better.=C2=A0 O= r maybe
>> someone would like to argue that we don't need to worry about = this.
>>
>>
>>
>> On 25 August 2017 at 06:58, Vincent van Dam <VvanDam@sandvine.com> wrote:
>> > I agree that the information you describe should be pulled fr= om
>> > somewhere,
>> > however, I am more concerned _when_ they should be pulled. >> >
>> >
>> > In this working group we acknowledged (welcomed) use cases th= at go
>> > beyond
>> > connecting to a network; the latest example:
>> >
>> > https://www= .ietf.org/mail-archive/web/captive-portals/current/msg00455.html<= /a>
>> >
>> >
>> > If these use cases are indeed in scope; signalling, or a solu= tion that
>> > allows detection that the walled garden is (re)activated afte= r joining
>> > the
>> > network, need to be in place. The alternative to a signal wou= ld be
>> > polling,
>> > or doing some mitm on protocols that allow it. I think both m= itm, and
>> > polling regularly to see if the connection state is walled ar= e bad.
>> >
>> >
>> > Just focussing on signalling (without the semantics/api); I t= hink that
>> > leaves us with three directions:
>> >
>> >
>> > * descope any solution that would improve the scenario where = walled
>> > gardens
>> > are (re-)activated
>> >
>> > * accept icmp is a valid direction, and think of a way on how= we can use
>> > this securely in our use-case
>> >
>> > * invent a new signal? something the nas is allowed to send t= o the ue,
>> > but
>> > not icmp?
>> >
>> >
>> > Gr., Vincent
>> >
>> >
>> > ________________________________
>> > Van: Captive-portals [captive-portals-bounces@ietf.org] namens Tommy
>> > Pauly
>> > [tpauly@apple.com] >> > Verzonden: donderdag 24 augustus 2017 18:03
>> > Aan: Lorenzo Colitti
>> > CC: Erik Kline; Eric Vyncke (evyncke); Martin Thomson;
>> > captive-portals@i= etf.org; David Bird
>> > Onderwerp: Re: [Captive-portals] Questions about PvD/API
>> >
>> > If the client OS needs to add in heuristics to reach a certai= n volume of
>> > ICMP messages before trusting them, I think the design is fla= wed. Beyond
>> > that, the information we'd like to get isn't just as = simple as a boolean
>> > value that can be aggregated (like unreachable would be). Amo= ng the
>> > problems
>> > we're trying to solve for CAPPORT is "how much time = do I have left", and
>> > "when to re-join the portal". Having a source we ca= n query about those
>> > properties seems to dramatically simplify the flow and trust = model.
>> > However
>> > we do things, it seems like this information should be pull-a= ble (even
>> > if it
>> > allows the client to open a connection on which changes are p= ushed or
>> > notified) rather than unsolicited pushes of ICMP by the netwo= rk.
>> >
>> > On Aug 24, 2017, at 8:33 AM, Lorenzo Colitti <lorenzo@google.com> wrote:
>> >
>> > It seems to me that any solution involving coordination betwe= en two
>> > protocols is little different, in terms of your criticism tha= t it will
>> > lead
>> > to "a higher rate of misconfiguration", from the PV= D solution.
>> > (Personally I
>> > don't think that's a valid argument - saying that if = you misconfigure
>> > the
>> > network it won't work well is pretty much a tautology - b= ut you were the
>> > one
>> > that cited that argument in support of the ICMP solution.) >> >
>> > As for several flows, I don't see what would stop an atta= cker from
>> > trying to
>> > spoof several flows.
>> >
>> > On Fri, Aug 25, 2017 at 12:21 AM, David Bird <dbird@google.com> wrote:
>> >>
>> >> You are both describing decisions the UE makes... perhaps= the UE waits
>> >> for
>> >> several flows (with same session-id) to indicate capport = warning/errors
>> >> before acting on it... especially when already connected.= There were
>> >> also
>> >> proposals to link the ICMP messages to the DHCP message s= omehow so that
>> >> ICMP
>> >> is 'authenticated' against the original DHCP. The= ses are solvable
>> >> concerns,
>> >> not road blocks.
>> >>
>> >>
>> >>
>> >> On Thu, Aug 24, 2017 at 8:14 AM, Tommy Pauly <tpauly@apple.com> wrote:
>> >>>
>> >>> Right, I think the difference between an unreachable = destination, and
>> >>> a
>> >>> captive portal or walled garden, is that we expect th= e captive portal
>> >>> style
>> >>> interaction to be an Operating System-level action, a= nd one that will
>> >>> have
>> >>> consequences on everything the device does while asso= ciated to a given
>> >>> network. You can certain use spoofed ICMP to disrupt = connections, but
>> >>> (a)
>> >>> the user would notice and (b) you're not causing = the Operating System
>> >>> to
>> >>> change behavior. When the OS thinks it is on a captiv= e network or not,
>> >>> it
>> >>> will change what network it considers primary/usable,= which may
>> >>> potentially
>> >>> be invisible to the user other than an icon change. I= would be able to
>> >>> go
>> >>> onto a captive network, start sending out ICMP messag= es, and
>> >>> potentially
>> >>> bump other people's connection off the network. >> >>>
>> >>> Having the UE fetch some resource in order to determi= ne captive state,
>> >>> especially if that resource can be somehow signed, ma= kes it much
>> >>> harder for
>> >>> an attacker to cause the OS to take silent behavior.<= br> >> >>>
>> >>> Tommy
>> >>>
>> >>> On Aug 24, 2017, at 7:40 AM, Lorenzo Colitti <lorenzo@google.com>
>> >>> wrote:
>> >>>
>> >>> A forged destination unreachable can't cause some= one else's device to
>> >>> think that wifi is a portal and switch to possibly ex= pensive cellular
>> >>> data.
>> >>>
>> >>> On Thu, Aug 24, 2017 at 11:29 PM, David Bird <dbird@google.com> wrote:
>> >>>>
>> >>>> Just like the rampant problem we see in ICMP Dest= -Unreachable forgery
>> >>>> attacks?
>> >>>>
>> >>>> On Thu, Aug 24, 2017 at 7:01 AM, Lorenzo Colitti = <lorenzo@google.com>
>> >>>> wrote:
>> >>>>>
>> >>>>> On Thu, Aug 24, 2017 at 10:40 PM, David Bird = <dbird@google.com>
>> >>>>> wrote:
>> >>>>>>
>> >>>>>> Can you give an example of how ICMP could= be misconfigured?
>> >>>>>
>> >>>>>
>> >>>>> It doesn't matter how hard it is to misco= nfigure, because it is
>> >>>>> trivial
>> >>>>> to forge.
>> >>>>
>> >>>>
>> >>>
>> >>> _______________________________________________<= br> >> >>> Captive-portals mailing list
>> >>> Captive-p= ortals@ietf.org
>> >>> https://www.ietf.org/mail= man/listinfo/captive-portals
>> >>>
>> >>>
>> >>
>> >
>> >
>
>

--001a11479db2b06302055793afb3-- From nobody Wed Aug 30 04:04:20 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A99132ED4 for ; Wed, 30 Aug 2017 04:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5S56t6chv3vP for ; Wed, 30 Aug 2017 04:04:17 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5378A132EB7 for ; Wed, 30 Aug 2017 04:04:17 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id t188so29517198ywb.1 for ; Wed, 30 Aug 2017 04:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=6ATa+3A+Qgg8wPlC+E4VKya+LldEs77Z/pFKL1xPfWQ=; b=VxoC+hXOkYrhqKUHv4zjpQOsO+29Hj16Q8oqAlXdEvsNfYN++3cC5SlmahD7ceSNfs 5Iq9CR1+OkvJUI0/g8TwYZu5aw3jW6Rz34mLkELlt9zTXgTOGjJSIxPdP/fqE4fqsXHh cRpzW+wt/Da3Pxy3G5XU6TVmgifPt38AcqFsInnGf0QljgKwyP60+v8xPvQA/GyzNzdG P73xFtuX9WJX/E1pmJFWd8TsuFSTgOOgpUMMh+WnWRrBNACdNoiIaIRXQMifaVaybsla vTEn/zHSM0KhXwYA0ANHREljSy7fyvqs2VJXv1u9M/6L4QggOBGfKlkqKa24zU/zMyrT fEmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=6ATa+3A+Qgg8wPlC+E4VKya+LldEs77Z/pFKL1xPfWQ=; b=bDqAaeczijiyO8Bvwk0BMslsO0/RBTQSX3A/oieHOvMvP+rVnNNSH8dQTteDdjPz5Q AKGT9bhya+J/ADw/ttFV7uVHTPCVM5cfhTFSGH//JqtxtZPp0fd/djRzigLCjPEjlA3Q JLf5S5Nsr7btYchoWmcBg46vrZUCf0Wnz1VSD/PhrE3mIXlLvXzFhRixLyOOUCVWhGiR PssyTvjfViFcDk0MwMq9n+BHgz0w0mYqWo8ehOARJnnwhF76fFkP/qSfwj8gB5+ammvJ vwxzb/mn2EdIjSxYztg7eQSit16VNPRjXuCKoPx4HymJXuUDlhgHnAYBiXZE9ogFzT2/ urQw== X-Gm-Message-State: AHYfb5hceSMGJFcM1GHmpbsv8JT6uFcoTWGpYxrYtfMwkCVcTqTE1Ken a/rF2NYrin4iNFZOMf9mIdMxeVi1G/piXZRBNg== X-Google-Smtp-Source: ADKCNb5yE/RFYEow5bQ/AWTlvb7T8FZ3tBjIY+T2yp7HRpTZCD0o/ndx26PNxy/XwLCncNUOUaMUXAHLZR877Rvb304= X-Received: by 10.129.80.68 with SMTP id e65mr844376ywb.293.1504091056165; Wed, 30 Aug 2017 04:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.207.84 with HTTP; Wed, 30 Aug 2017 04:03:55 -0700 (PDT) From: Erik Kline Date: Wed, 30 Aug 2017 20:03:55 +0900 Message-ID: To: captive-portals@ietf.org Cc: "martin.thomson@gmail.com" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a1147fa24242cfc0557f67d08" Archived-At: Subject: [Captive-portals] [adoption call] draft-larose-capport-architecture X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 11:04:19 -0000 --001a1147fa24242cfc0557f67d08 Content-Type: text/plain; charset="UTF-8" All, As indicated in the minutes from Prague [https://datatracker.ietf.org/doc/minutes-99-capport/], there was a general hum in favor of the architecture document: """ 1. for arch doc, do we want a milestone for architecture. Humming: in favor. 2. is the document a good basis for the milestone? Humming: in favor. """ This email is to initiate a two week adoption call for: https://datatracker.ietf.org/doc/draft-larose-capport-architecture/ Feedback requested, even if only to restate an opinion expressed in Prague. Thanks, -Erik --001a1147fa24242cfc0557f67d08 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgXpBbF7p2AVFSpVrRzEylJuN0w5iLdfYy XAkzTDSAx/cwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODMw MTEwNDE2WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAK5NIPaS7RzqLO4kuWvP975gxxZkkbpuolMJWJo5uyIuJtm8qQ7u IoLuIObnPjNmbQ6PLGIo7zMjpSiWA65sMFXmIKkv94+G7pnIGx/O4Z5Lez8X+dT13nyMRB5eK3qs jZWEtzC/DE5mNsE12h8KIJ35GlM9lLuIQjBMivGQKwIzcFBRFf64N+q8Td8uyOlj7ERJ0D9T5/CN ZY6/gA3AcK9T4UZoHNNyoZkf967gFPv+gv7BlGSpHJ9sK59B0dTB77LIffpGv51dHwbb6VSt/zjA ESN3Dta0ysOyIuMeVxSvsM6fAqmavOfGuCmHSCja4nJz1WUc1LqkuzpGL0FceRk= --001a1147fa24242cfc0557f67d08-- From nobody Wed Aug 30 04:04:30 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144DE132ED2 for ; Wed, 30 Aug 2017 04:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 o5i_7Yb8LtEF for ; Wed, 30 Aug 2017 04:04:19 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42DEA132EB7 for ; Wed, 30 Aug 2017 04:04:19 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id h127so29451511ywf.3 for ; Wed, 30 Aug 2017 04:04:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=L2SlgA0J1a8S5Gl247K17cphkkuk52yAyRKRXm1EqsA=; b=fwx3BbPkoh4VlnSNTVleAIHWxJdOkjsfVvGt1zBuplx3JR8UkRlExDicbLnuggpcRr x8GWMH9ZSX8ZrTa8lw5/0bVDZQhPriymdHY2C9kNC6o9UjJEpuuWDzd9Be32B8t9sdw0 cEVYB0u4PDQVVt1vQp72FI7v9H9s3rKu0c1QmP9ISbp6hnnnHW7f01JS+61asXZ33e1S 8+6yFpdAstH0MgnQ/xBk2yJA/KLcF4s6Q5eBbTX0muImznDHkbOxPY29iboRwx7KP8GY Jz/uCr7J9DgDCXHyTv8o0OX0NUX+VFCi/o16dgEC0VtZL9V7NTqRgQ1EeOgS/7DwFEwl 6o+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=L2SlgA0J1a8S5Gl247K17cphkkuk52yAyRKRXm1EqsA=; b=gTzYlOXt/GHUKMt/ktTuveHHUAPaLUsJ8F0kUOQGWY5i2wnbPxPgRj62ca0rLNOfX6 GvSReldOgcFv12m4WGBE8ag/JOgZ7eDvkmfPBaQjEUZLLPgZNmYmW4iQcI522v3+i8Lm 4ekoL2/VhTNqUkPEl603OwvuwX4Mkq6056/qGvCKKj+nxztiUtsMGMm+Bgnzem1wa79E XfYWJEjGKHN18JJBwJPUnFKby99hJAPXp2zilKICXFDP3ksBE3VgiBbNeZyCtRbmS2kA XQiObH02z8gYhtSRQOTN/R+vVEo+Y/Js32V9GoT4htaf0d8g8y56uoQlYbhyJBD0gMjv NO1Q== X-Gm-Message-State: AHYfb5iUl/Q8imxSlnNWhGzf4W2Gweq1yMcSn15GWBG7y9cdaNsy+V/M 87DoxqiH4Fw8fRjfo2uB6xFfgiJMBoWrOzbrUw== X-Google-Smtp-Source: ADKCNb7V5J/fZ+VR+oojIiQobHnmvjwC2HaPvPwlY0mnWP9P3uV6frBvcdWvV7YT1jYnUk2/6mKbW7i+L/eCStOinQE= X-Received: by 10.13.204.66 with SMTP id o63mr866420ywd.321.1504091057909; Wed, 30 Aug 2017 04:04:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.207.84 with HTTP; Wed, 30 Aug 2017 04:03:57 -0700 (PDT) From: Erik Kline Date: Wed, 30 Aug 2017 20:03:57 +0900 Message-ID: To: captive-portals@ietf.org Cc: "martin.thomson@gmail.com" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="001a114f25d24214430557f67d89" Archived-At: Subject: [Captive-portals] [adoption call] draft-donnelly-capport-detection X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Aug 2017 11:04:21 -0000 --001a114f25d24214430557f67d89 Content-Type: text/plain; charset="UTF-8" All, As indicated in the minutes from Prague [https://datatracker.ietf.org/doc/minutes-99-capport/], there was a general hum in favor of the API document: """ 4. API document: do we need a milestone? Humming: in favor. 5. Is this document a good basis. Humming in favor. """" This email is to initiate a two week call for adoption for: https://datatracker.ietf.org/doc/draft-donnelly-capport-detection/ Feedback requested, even if only to restate an opinion expressed in Prague. Thanks, -Erik --001a114f25d24214430557f67d89 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS3wYJKoZIhvcNAQcCoIIS0DCCEswCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBFMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMLW40/amma0pdhM03MA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDQyMTA2MzcwOFoXDTE3MTAx ODA2MzcwOFowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANkpCWrtscoTUN8levpjTbHB2K91tmHoRWYQKw9gpO311ZWwMvCFM1MY qnqJ8kCDOkIchn/DhRYgaiYfqPCcTI393/HTiham2lzcJP/Z/rlDV/EEwbSc7JOdw3yhzivBzTHo +fyVWMOlmmeqjihfSvdhTerFS6ykUNkKSSiWOt+eM0gzAkptrfjt8U0Qc/1Q5kbODKJo3F9Pw5Od zPgsTil6EduRaabU3yXpqRBaVf3wCf6gmuLO7lMMoIvWaOTCHu9CzQFnChYRroOL7UFfpJ9tzIfO W2pgHoU6+IMcc+LEpnyX4apiyAoJHYIPeVJklTImhcKNUeB0N2+HloqQAWcCAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBT9p+3Qyh0VNEyCfHoEMjpnOxE45DAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEAMgJgTvhpX3KHQqVVnccDEICRx7gk 6YK8IsQ0nRFU38nxR+GxH36IaZi7llzHgkX054q/w3obniT8XNlCKNvVc3WTsSlvUBHqAQsFRmjc 5wSViMHjZL27y3edn036HojnTcuWz+DAogDPDuy3umPRZZAaL0Bm4GuBoGBZ81gxcm8pPACfWLrQ mjhtPtFxj7ksjQt4xSzmNN6bYTQ1LCRmbcO9e6PolIl56KTaJpr5IsUD+9LgmfzPO49EnbuamnIM Ve143jXWDX8ftUZt5Qcj6MT62bNuRVBGzwQsCpbsQJJwJriB7Vb190YG3O4O9rAvvX0RPva4p1bC tjvJVITAfDGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDC1uNP2ppmtKXYTNNzAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQg1ga81nPx8NKhcVnYrF9O1ZwfmzuRTkmO hYfo6x13f74wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcwODMw MTEwNDE4WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAItAiU4RoW9wl19U1+i1lu4NrTy2g4WBw2W7drNXxkFpZGB0aTAb IUroKfjOplX5yPByoDmWnJ+eKaN1NdZtkJzL0saOilXbLVvUYZqQgB1Zt8jcbdeEbJpjQlyQFqYo FnsGt2CdrFUGQrspzd32iNtS4TPZH13Y3mhjyGne2MhqpOWsT2dASA51nCHL0WcQACV7Kmt9Am0r gJE1Q3t2aNkQjPBH4180+TkQw5zroNydUloj+HKD2/vopjOF0wdfElvPRYcrf1gHKcy8WL9sKiY0 5BdF3mFw/aj0S2VvhDCzxIhr7UytH4cHB6621L3r+HdjgmE0lKk7aPJ1dw0S1EI= --001a114f25d24214430557f67d89-- From nobody Wed Aug 30 18:27:31 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8E8E1321C8 for ; Wed, 30 Aug 2017 18:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CW4tWHvAT2FW for ; Wed, 30 Aug 2017 18:27:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E51A13218E for ; Wed, 30 Aug 2017 18:27:27 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A7911203CA for ; Wed, 30 Aug 2017 21:30:53 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DE2FB826A0 for ; Wed, 30 Aug 2017 21:27:25 -0400 (EDT) From: Michael Richardson To: captive-portals@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Captive-portals] [adoption call] draft-larose-capport-architecture X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:27:30 -0000 --=-=-= Content-Type: text/plain Erik Kline wrote: > This email is to initiate a two week adoption call for: > https://datatracker.ietf.org/doc/draft-larose-capport-architecture/ I read it before PRAGUE, and I liked it then... I assume I still like it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmnZf0ACgkQgItw+93Q 3WUrjAf+KP4EY2jW3PXljYujgN10DU1NTxCqSpK5RORAgxhHHtrd5YfnkI1O5V32 uTWd3laaZAbqtYO7Zjb5xV0GtKLtYiYonvxrBhQ1/XsauCtivXNjw1C+j7R5yhdC VYokaAPfZfi92SWoWP1wnO+/b1gLQDKW2CwK3RZpMNuR3WN5EM6PfKUiwTOF9g7r dqP5AqVll61yax4SZsic9/X+Q6PYsXxL14J56zxvhe3bv+KFcAitIKh0c6X1L4fN N5jTYthOxewnpMbJlGkmxwgo/zgNx7K8MyG056XhjfI3GmQd1Bk9jHGloecHyrwQ nQnsP30UJOLkhzwNr5NSYcmU57JkvQ== =A6jf -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 30 18:29:54 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DCBC1323B8 for ; Wed, 30 Aug 2017 18:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no 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 aBt64EcNC9jK for ; Wed, 30 Aug 2017 18:29:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC0D126BF0 for ; Wed, 30 Aug 2017 18:29:50 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B33DF203CA for ; Wed, 30 Aug 2017 21:33:17 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E69BE826A0 for ; Wed, 30 Aug 2017 21:29:49 -0400 (EDT) From: Michael Richardson To: captive-portals@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Captive-portals] [adoption call] draft-donnelly-capport-detection X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:29:52 -0000 --=-=-= Content-Type: text/plain Erik Kline wrote: > As indicated in the minutes from Prague > [https://datatracker.ietf.org/doc/minutes-99-capport/], there was a > general hum in favor of the API document: > """ > 4. API document: do we need a milestone? Humming: in favor. > 5. Is this document a good basis. Humming in favor. > """" > This email is to initiate a two week call for adoption for: > https://datatracker.ietf.org/doc/draft-donnelly-capport-detection/ I like the approach, please adopt it. After adoption, I think the WG should consider if describing the JSON in YANG would make sense. I've been through this in netconf/anima/6tisch now, and while it seems like a silly annoyance at first, it seems to have some advantages in the long run. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlmnZo0ACgkQgItw+93Q 3WVcTAgAntH79s3Nf0kO7YHLucx9kgQD+LdXtl7j1r3nHzL5t6m87XoE2TdH8DxX KY15ISzePfdDHHFHPRkn7uGmS8MhWta5QG1NKYJuSPM/OjLTS6cXC5MRvuZ/9QOj lqttcTom7RQPJ8OS0zdJNr1JmTtdlxNHxNKv59kIm9n8XB9pcxdoAiEbrZ85mLo5 WRb2a7Gw9Qfp7ASA9EfNMzO9vXr7nIpRUBM9fEBmnT7SKDDMmS+5CqdMa0AWoLrU JHpaDz6H3iAm9RwwTmsqSVpYtus339whBrBoOjPKTAlMkdCmlgjOLyChrWgeUsVt yIKdT30wvegMPRsG9EtTN8AD3iht5g== =2fes -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 30 18:53:43 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD9AD124207 for ; Wed, 30 Aug 2017 18:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 9Dcj_lsztooX for ; Wed, 30 Aug 2017 18:53:40 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E973912008A for ; Wed, 30 Aug 2017 18:53:39 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id k77so65024988oib.2 for ; Wed, 30 Aug 2017 18:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=VVm7hi894xJk2N8MG6/5TjhGuXf6JklXmJxqRge4iXM=; b=quOxAYhLHUOHEJmzI907Te5RdlQj2VInLjAXQWSYsLG/nPoWS2heNx3qRxHmLzGgSH K5MQGXhutfjOi88MlAJg5zJmEyc16v3euk//3uk5i+fBY77N+zxWdFC8wf2lSBnMhK9x 3+fcX1UFk8VXawarMJ3FOV8IryLoCYAGOlwOHWD+vLGjU4+q/pSHC7hUIH7p8Ejh1sCe frBx9ZJ8eWZvdNPpCcyYK8/vZwxU7JsmHlIYYJ9fbxSYs1Qyj4Ts5BhVt1ZmG3S1bKxG PWbm/8JtFz0fkxymgIzLzeNSo81cGTQH6WgAjhqi1LpL7th4XwywIlc61R/lEXDUUw5m 2GpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=VVm7hi894xJk2N8MG6/5TjhGuXf6JklXmJxqRge4iXM=; b=Ltx/sLSKnyBFdt1EWI9i7z0608yBV+XcZGaKS/UJln6w5kvWleyZK4j5/vws6bs6oZ MwFySzn++Garr6SwloMNZ1lhJsgQtIXHwjt/ZjpG7B6s0I3JBYAnAooD2JpiEoKH0a6G /LyR/8VLachaYklD1GVpMYGH87kNP1gDSg8F9+pkBqVH4R1U9d+qFZZurdYf2kxIEN1P 2/EOrJw92dtQi5GpuS7dYyEGTh+yUa+Dh+9MFDwWPHuhDPVv6Bfj4ngr8VUDsPmqiVQY BfnT4YzGg3jQfR5FyGE8bHkPxI7Fsz/tGywdbrYTpoRT9O5QIS7UEXO73zf6zjsBkc2f q9yg== X-Gm-Message-State: AHYfb5iOwkAe9k/FF2/BSoj37gkFF0ObAuNKjfqXvjfhhaZN3EMCH2yV nCy8KAwIh3QxliMlQt03ieXZUQb0nmQiRFg= X-Received: by 10.202.229.198 with SMTP id c189mr3024410oih.5.1504144419315; Wed, 30 Aug 2017 18:53:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.63.163 with HTTP; Wed, 30 Aug 2017 18:53:38 -0700 (PDT) From: Martin Thomson Date: Thu, 31 Aug 2017 11:53:38 +1000 Message-ID: To: Michael Richardson Cc: captive-portals@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Captive-portals] YANG schemas (was Re: [adoption call] draft-donnelly-capport-detection) X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 01:53:41 -0000 On Thu, Aug 31, 2017 at 11:29 AM, Michael Richardson wrote: > After adoption, I think the WG should consider if describing the JSON in YANG > would make sense. I've been through this in netconf/anima/6tisch now, and > while it seems like a silly annoyance at first, it seems to have some > advantages in the long run. Hi Michael, I've been YANG-averse for too long. I just looked and it seems like a pretty sensible design overall. Much more readable than the JSON content rules. Do you know if the outer object can be stripped off? Context is usually sufficient to avoid that extra layer (and HTTP provides content-type to provide that context). Reading https://datatracker.ietf.org/doc/html/rfc7951#section-4 it appears as though the obvious schema for capport [1] would end up with instance documents looking like this: { "capport:capport" { "captive": false, "end": "2017-01-01T12:22Z" } } That extra wrapping is a little annoying. Not fatal, of course. [1] module capport { yang-version 1.1; namespace "urn:...:ietf:...:capport"; prefix "capport"; import ietf-yang-types { prefix yang; } // ... metadata stuff container top { leaf captive { type boolean; } leaf end { type yang:date-and-time; } } } From nobody Wed Aug 30 19:20:57 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA3813219A for ; Wed, 30 Aug 2017 19:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CPm828-_QdJs for ; Wed, 30 Aug 2017 19:20:53 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D94411320BD for ; Wed, 30 Aug 2017 19:20:52 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Wed, 30 Aug 2017 22:20:51 -0400 From: Dave Dolson To: Erik Kline , "captive-portals@ietf.org" CC: "martin.thomson@gmail.com" Thread-Topic: [Captive-portals] [adoption call] draft-larose-capport-architecture Thread-Index: AQHTIX+9Ce2u4MYnik6fn8xDOFCSwKKdvIdD Date: Thu, 31 Aug 2017 02:20:49 +0000 Message-ID: <20170831022049.5124178.52717.30451@sandvine.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Captive-portals] [adoption call] draft-larose-capport-architecture X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 02:20:55 -0000 As one of the authors, I support adoption. David Dolson Sandvine Original Message From: Erik Kline Sent: Wednesday, August 30, 2017 7:04 AM To: captive-portals@ietf.org Cc: martin.thomson@gmail.com Subject: [Captive-portals] [adoption call] draft-larose-capport-architectur= e All, As indicated in the minutes from Prague [https://datatracker.ietf.org/doc/minutes-99-capport/], there was a general hum in favor of the architecture document: """ 1. for arch doc, do we want a milestone for architecture. Humming: in f= avor. 2. is the document a good basis for the milestone? Humming: in favor. """ This email is to initiate a two week adoption call for: https://datatracker.ietf.org/doc/draft-larose-capport-architecture/ Feedback requested, even if only to restate an opinion expressed in Prague. Thanks, -Erik From nobody Wed Aug 30 19:23:51 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CD71320BD for ; Wed, 30 Aug 2017 19:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_QUOTING=0.001] autolearn=ham autolearn_force=no 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 3CT3BqoBKlSS for ; Wed, 30 Aug 2017 19:23:48 -0700 (PDT) Received: from mail1.sandvine.com (mail1.sandvine.com [64.7.137.165]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6784C124207 for ; Wed, 30 Aug 2017 19:23:48 -0700 (PDT) Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by WTL-EXCHP-3.sandvine.com ([fe80::3c39:d305:d721:f00a%15]) with mapi id 14.03.0319.002; Wed, 30 Aug 2017 22:23:46 -0400 From: Dave Dolson To: Erik Kline , "captive-portals@ietf.org" CC: "martin.thomson@gmail.com" Thread-Topic: [Captive-portals] [adoption call] draft-donnelly-capport-detection Thread-Index: AQHTIX/D9R89IzwKE0+kUkvVPZ2QkKKdvVj1 Date: Thu, 31 Aug 2017 02:23:45 +0000 Message-ID: <20170831022344.5124178.78293.30454@sandvine.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Captive-portals] [adoption call] draft-donnelly-capport-detection X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 02:23:50 -0000 I support adopting the API document, expecting some changes to the details = of the API itself, which I believe the authors also said they expected. David Dolson Sandvine Original Message From: Erik Kline Sent: Wednesday, August 30, 2017 7:04 AM To: captive-portals@ietf.org Cc: martin.thomson@gmail.com Subject: [Captive-portals] [adoption call] draft-donnelly-capport-detection All, As indicated in the minutes from Prague [https://datatracker.ietf.org/doc/minutes-99-capport/], there was a general hum in favor of the API document: """ 4. API document: do we need a milestone? Humming: in favor. 5. Is this document a good basis. Humming in favor. """" This email is to initiate a two week call for adoption for: https://datatracker.ietf.org/doc/draft-donnelly-capport-detection/ Feedback requested, even if only to restate an opinion expressed in Prague. Thanks, -Erik From nobody Thu Aug 31 05:54:36 2017 Return-Path: X-Original-To: captive-portals@ietfa.amsl.com Delivered-To: captive-portals@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755F3132D68 for ; Thu, 31 Aug 2017 05:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 5QRcyYFQb0ro for ; Thu, 31 Aug 2017 05:54:31 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D261A132D90 for ; Thu, 31 Aug 2017 05:54:30 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id e2so2426304qta.0 for ; Thu, 31 Aug 2017 05:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7sz90detd5H7E5Nkw0b2yu9AeECq2XApsP3w6WtvbDE=; b=jLugv9aNKHPEPnQw5k5SIPHCe+dJJsK3zaW2gYPz1YMqRbuZHkD5ZKIt9uaYf76Ip0 zAA+HHxALaBUL7+SLiheLzf7qk9HxbENpCG5MhBiF6mydmSq48V98Pe2LqBQTCqa94tS vxzCUrZUto+OAapNZ74JdEtd1vIkECG1Q4NFZfOan6ZTeHuKfdkWW5D+TmhAUxaOhdjb m0VyQ3Rqf2xGLeErPn89GD4d3gye//wbX7Qj3Ncap0haxJa8wK1f2WUUErBJ0LrBNi1w U+PDtpw2mIv8fKOE1HLv0sbPKy9JZHkIpigS8F0tX6lsnXYt+xP6ke5ROFh2mu/B8rKy NCtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7sz90detd5H7E5Nkw0b2yu9AeECq2XApsP3w6WtvbDE=; b=HbPFhzuW5sMY1dsljGBypXKEEwmE+NoO9By6+FN8blYas8L/YYwzi4WI3xf7tG/lGA sQYr4y8VbjuNIrQVzqXgUPDBK2tNY2/KgKi2ceDIqnYFiphvc0qwC512GPOECFV9jdwd nPSYPgoINy5ckyrkzbyuQzV/g823/mbo7SiHAq89W7aYwi1C1lzAp+Tsbv1uLi1aXra9 uizOoBXCJpUvt4ncXO5NXctBS6qhOTYwe2vzcFGwD8zsdDwH/q5IsgQMK6qThp26bPYg Plk0jW91FUdE380k0O3i7F01qWk4HWdA1hmidhRx9qkwJd/ctXfpitFo4INU5QK7X1Tg kNsA== X-Gm-Message-State: AHYfb5g5SuTyF2RBB027uip2tYFBkPKJHZ5a/PCqQFlucD18+sWNXCEq bOrVfK/rSPMzHnC81/ZDYuqrhgcjhx2vArA= X-Google-Smtp-Source: ADKCNb52zDeSm1zId0FD42bZpDQK6Behg1Mr1djhVjpVgdUMHKocnw+r3wZbTzvpOJ+y5q7F0mvFZQDSejkrz4npouE= X-Received: by 10.237.63.246 with SMTP id w51mr7186952qth.62.1504184069200; Thu, 31 Aug 2017 05:54:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.132.102 with HTTP; Thu, 31 Aug 2017 05:54:27 -0700 (PDT) Received: by 10.12.132.102 with HTTP; Thu, 31 Aug 2017 05:54:27 -0700 (PDT) In-Reply-To: References: <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> From: David Bird Date: Thu, 31 Aug 2017 05:54:27 -0700 Message-ID: To: captive-portals@ietf.org Content-Type: multipart/alternative; boundary="001a11475d481fa00e05580c257a" Archived-At: Subject: [Captive-portals] Fwd: Re: Questions about PvD/API X-BeenThere: captive-portals@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of issues related to captive portals List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Aug 2017 12:54:34 -0000 --001a11475d481fa00e05580c257a Content-Type: text/plain; charset="UTF-8" Sending to list... ---------- Forwarded message ---------- From: "Martin Thomson" Date: Aug 30, 2017 3:52 PM Subject: Re: [Captive-portals] Questions about PvD/API To: "David Bird" Cc: sending that to the list would be helpful On 30 August 2017 at 23:11, David Bird wrote: > Part of the reason for confusion is that the "API" and "PvD" have a high > potential to overlap, and I generally feel that they will be merged somehow. > I got the impression from PvD authors in Prague that PvD could certainly > swallow the feature set of the API. So, without knowing exactly how the API > vs PvD will shake out, I generally lump them together. > > Re-looking at the drafts... > > PvD: > - The core material of interest to Capport is now largely in Appendix B. The > main part actually seems find... though, not very useful. If someone > *already* selected a WiFi network, do they really care about the name of the > network or the bandwidth? That data seems more important to know before > association (during network selection), not after. Anyways, > - Appendix B is where it gets more interesting -- and where I'm sure the > authors plan to baby-step in more features. This is where it starts > overstepping into 'enforcement' (and, frankly, should be triggering all the > same concern you have with ICMP; why doesn't it?): > > [ > { > "domains": ["example.com"] > }, > { > "prefixes4": ["78.40.123.182/32","78.40.123.183/32"] > }, > { > "beginDate": "2016-07-16T00:00:00Z", > "endDate": "2016-07-17T23:59:59Z", > }, > { > "beginDate": "2016-06-20T00:00:00Z", > "endDate": "2016-07-19T23:59:59Z", > "trafficRemaining": 12000000 > }, > { > "throughputMax": 100000 > } > ] > > If the host tries to download data from example.com, the conditions > of the first elementary billing are fulfilled, so the host takes this > elementary billing, finds no cost indication in it and so deduces > that it is totally free. If the host tries to exchange data with > foobar.com and the date is 2016-07-14T19:00:00Z, the conditions of > the first, second and third elementary billing are not fulfilled. > > API: > - Hm.. that doc seems stripped down a bit too. It has a network object which > has a 'state', 'conditions', etc, and a value for 'bytes_remaining' .. > (already overlaps?) > > > > On Sun, Aug 27, 2017 at 5:58 PM, Martin Thomson > wrote: >> >> Hi David, I'm just trying to work out if the concern is with PvD or >> the API to start with. Baby steps because I want to make sure there >> is no miscommunication. Can you address that question please? I >> can't tell from your response here. >> >> On 25 August 2017 at 23:11, David Bird wrote: >> > Sorry, NOC == Network Operations Center (Data Center). >> > >> > My concern isn't that an API *can* make claims about your captive state, >> > it >> > is more: >> > - The implementation of the API/PvD web services will be highly varied >> > -- in >> > compliance to the RFC, integration with the infrastructure (RADIUS, >> > portal, >> > etc), and easy to misconfigure. >> > - It separates enforcement for Capport devices from enforcement of >> > non-Capport devices, which has consequences... (*) >> > - It may very well make "Hotspots" more complicated, error prone, and >> > "broken" >> > >> > (*) This question isn't rhetorical :-) ... What will "First vendor with >> > PvD >> > client" do when a new phone, and only that new phone, has problems at >> > (just >> > for arguments sake) Chicago O'Hare? >> > >> > - Complain to venue? (even though their friend isn't having problems) >> > - Tell the user to turn off PvD? >> > - Tell the user to use their old phone? >> > - UE vendor will start contacting venues? >> > - Start doing legacy probes on top of PvD? >> > >> > My concern is that after all this work... UEs will still be doing legacy >> > probing... >> > >> > On Thu, Aug 24, 2017 at 7:09 PM, Martin Thomson >> > >> > wrote: >> >> >> >> Hmm, maybe we understand this very differently then. I see PvD as >> >> providing configuration in exactly the same way as 7710 does. >> >> >> >> That is, >> >> >> >> * 7710 says "here is the URL you go to for ???" where "???" is one or >> >> both of "web browsing" and "API" (see the API doc). It doesn't really >> >> say whether the endpoint is currently captive or not (and nor can it >> >> do so). >> >> >> >> * PvD, as I understand it, would say the same, though it might provide >> >> separate "web browsing" and "API" URLs, if we accept that an API is >> >> valuable (see below). It *could* also act in the "API" role, and I >> >> think that Tommy in particular finds that idea appealing, but my >> >> understanding was that we would consider that to be a logically >> >> distinct function. >> >> >> >> If, as we seem to have agreed in Prague, consider API to be basically >> >> reduced to "am I captive? y/n" and maybe "for how long?