[Captive-portals] Fwd: Re: Questions about PvD/API
David Bird <dbird@google.com> Thu, 31 August 2017 12:54 UTC
Return-Path: <dbird@google.com>
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 <captive-portals@ietfa.amsl.com>; 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 <captive-portals@ietfa.amsl.com>; 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 <captive-portals@ietf.org>; Thu, 31 Aug 2017 05:54:30 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id e2so2426304qta.0 for <captive-portals@ietf.org>; 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: <CABkgnnWWB6-VtteJZ6o7_FY6haC8r0JPkoY1wMfFtwJ8VKaweg@mail.gmail.com>
References: <CADo9JyU+XGYFWdNeXOBw1O43Pjyn0jZhGxDTb7VbLF+Jg4Xj4w@mail.gmail.com> <CAAedzxq4UhueFW=U-Tuc1gvG8Tapc7VE7BM2Akt9OXuzN3jLyQ@mail.gmail.com> <CADo9JyW0J7xzaosG5PJOFPHMy2g6vZ1cVpW6_YsuOdaKWqumkQ@mail.gmail.com> <A5B74413-32D8-4FE4-BDF7-DAA95266AAF4@apple.com> <CADo9JyUJTPRT9454VdZEM1nwFfxPSrMX3+Uk9i325uboQUya7g@mail.gmail.com> <7B520EA6-7B55-46B1-B084-F1CADF7DE28B@apple.com> <CADo9JyVSW5==nQOUMUUYWj743LmZCUjE9=W-YXnK-KMS-88AoQ@mail.gmail.com> <CABkgnnV1OT_29fdNbCDDJMgeRDNeOM8u2PYA94opo+ujj2=Avw@mail.gmail.com> <CADo9JyUdBZbBmwE0B21ryFuefQEaTiWLHD-w8AZSyWACH9u2dg@mail.gmail.com> <CABkgnnWbhHOmZRsvpEb0XusRtUJUPp7vpdM7V_4nLnC_B-mfKQ@mail.gmail.com> <CADo9JyUP_FWznzDWDO1s9-8B8-hMAUkFAMaa68uUZ1xR8CKHyw@mail.gmail.com> <CAKD1Yr0OrthUda3+ic3g83vWEpBATpcF4Z=4ENNg+ZuyySDMdg@mail.gmail.com> <CADo9JyW=wYh5y87KZrfs56fFze_VkdvUt-hF_SNeokPONxDuGA@mail.gmail.com> <CAKD1Yr2GpTX9NPTNJVbGjF+PxuNNyhgaRNjr0qMW90rVHeM_+g@mail.gmail.com> <98352984-4E92-42EC-97FE-B652C0FC41AF@apple.com> <CADo9JyVzW3TxFCHv=1N=Qsm2Th7gw7Yby8mdG2hOVWQQ_9YGpw@mail.gmail.com> <CAKD1Yr0_ksXDy6Ckc6RuFjYf+t4fiA4dJfAToZjfgrqed4h4QA@mail.gmail.com> <B05E727C-6F8B-438F-8DC9-1B1528CE73A5@apple.com> <D2A19ABBC0147C40BFBB83D1CF3E95F04010655B@wtl-exchp-2.sandvine.com> <CABkgnnXdMDd2BF0r0ekmwxFECSiLPxPruc46BpVTNDCFz8+Tvg@mail.gmail.com> <CADo9JyVUE89QZajqxQ+0ofXY3L5vDSj18cXvFpXG1ViXeCnqhQ@mail.gmail.com> <CABkgnnVX8s5+MPeY=XRnc3Vkmf9gg3GY2-MxhSrVq98B_odGcg@mail.gmail.com> <CADo9JyVetrad0b1WMXfCHhBHy2x2Ew7oM0Stpq4qVfBnWuEtNg@mail.gmail.com> <CABkgnnW4h6RQHtyKfLzOtA4HuuMxfEKYmCnB1HTo5hEMVKQRaw@mail.gmail.com> <CADo9JyW932m0C_OKEHwS_9_S0oH7m-Z9ocM3jTHkumzto6sncw@mail.gmail.com> <CABkgnnWWB6-VtteJZ6o7_FY6haC8r0JPkoY1wMfFtwJ8VKaweg@mail.gmail.com>
From: David Bird <dbird@google.com>
Date: Thu, 31 Aug 2017 05:54:27 -0700
Message-ID: <CADo9JyV9t6KCf59ykm=+gHrR+CpkwBuKJVfaKpg=wVpZmiermg@mail.gmail.com>
To: captive-portals@ietf.org
Content-Type: multipart/alternative; boundary="001a11475d481fa00e05580c257a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/t5151YowpMM5ZatWEW58PIRUII8>
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 <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 31 Aug 2017 12:54:34 -0000
Sending to list... ---------- Forwarded message ---------- From: "Martin Thomson" <martin.thomson@gmail.com> Date: Aug 30, 2017 3:52 PM Subject: Re: [Captive-portals] Questions about PvD/API To: "David Bird" <dbird@google.com> Cc: sending that to the list would be helpful On 30 August 2017 at 23:11, David Bird <dbird@google.com> 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 <martin.thomson@gmail.com> > 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 <dbird@google.com> 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 >> > <martin.thomson@gmail.com> >> > 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? <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. 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 == 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" 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 >> >> > <martin.thomson@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. 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 <VvanDam@sandvine.com> >> >> >> 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 <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 >> >> >> >>> >> >> >> >>> >> >> >> >> >> >> >> > >> >> >> > >> >> > >> >> > >> > >> > > >
- [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Erik Kline
- Re: [Captive-portals] Questions about PvD/API Lorenzo Colitti
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Tommy Pauly
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Tommy Pauly
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Martin Thomson
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Martin Thomson
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Lorenzo Colitti
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Lorenzo Colitti
- Re: [Captive-portals] Questions about PvD/API Tommy Pauly
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Lorenzo Colitti
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Tommy Pauly
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Vincent van Dam
- Re: [Captive-portals] Questions about PvD/API Martin Thomson
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Martin Thomson
- Re: [Captive-portals] Questions about PvD/API David Bird
- [Captive-portals] Fwd: Re: Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API David Bird
- Re: [Captive-portals] Questions about PvD/API Erik Kline
- Re: [Captive-portals] Questions about PvD/API Erik Kline
- Re: [Captive-portals] Questions about PvD/API Michael Richardson