Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 12 June 2017 18:33 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 D2FEE12EAF1 for <captive-portals@ietfa.amsl.com>; Mon, 12 Jun 2017 11:33:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 gJF60oRHooKs for <captive-portals@ietfa.amsl.com>; Mon, 12 Jun 2017 11:33:52 -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 4FA0B12960D for <captive-portals@ietf.org>; Mon, 12 Jun 2017 11:33:52 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2719CE235 for <captive-portals@ietf.org>; Mon, 12 Jun 2017 14:34:57 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 655E8636BB for <captive-portals@ietf.org>; Mon, 12 Jun 2017 14:33:51 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "captive-portals@ietf.org" <captive-portals@ietf.org>
In-Reply-To: <CAAedzxoZkuauME8n3B3aZqE1rra8p2hB9rGJLqoYyVi8usnx+g@mail.gmail.com>
References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <E8355113905631478EFF04F5AA706E98705C6C57@wtl-exchp-1.sandvine.com> <CAHw9_iJARf4MUA8nHqHA54jLvJNq-_Vek67A-rjHpSK6vC7r+Q@mail.gmail.com> <1BB90528-B35F-43F0-AF18-0215DC735FF0@cable.comcast.com> <CABkgnnWT6Xtqyx6pofpNOGa5E1FjJO1gPX1axmmiRaMnzxdoPg@mail.gmail.com> <AD3F2B14-E9AD-4156-96A6-9B83F8545B54@cable.comcast.com> <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de> <CAAedzxoZkuauME8n3B3aZqE1rra8p2hB9rGJLqoYyVi8usnx+g@mail.gmail.com>
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<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 12 Jun 2017 14:33:51 -0400
Message-ID: <9749.1497292431@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/knlcUqsqWGjSl86TfrFpya_Becg>
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
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: Mon, 12 Jun 2017 18:33:55 -0000

Erik Kline <ek@google.com> wrote:
    > Some observations, and questions for the working group.

    > I'm not sure we have enough input on whether 511 is useful or not.
    > There seemed to be some suggestion it would help, and some that it
    > wouldn't. Perhaps one question we could ask is whether it's harmful?
    > And if we agree it's not harmful, is it worth developing some
    > recommendations for its use?

I think you are asking the right question here.

    > As for the ICMP unreachable option, I certainly don't think it would
    > be harmful (with the extra URL bits removed for now). Is that
    > something we wish to progress?

I am keen to see it progress as you describe.

    > Given that we're probably looking at a portal detection method based
    > on entirely new work, it seems to me we're free to look at new things
    > like utilizing the PVD detection scheme (DNS queries for "provisioning
    > domain names", followed by other interaction still TBD). Have the
    > portal implementors reviewed this and given consideration as to
    > whether its useful? (I think of the discovery of the portal and
    > subsequent interaction with it as 2 separate processes conducted,
    > obviously, in serial.)

On this topic, I imagine you have all read about:
     https://www.malwaretech.com/2017/05/how-to-accidentally-stop-a-global-cyber-attacks.html

In which the investigator discovers that this malware looked for zones that
ought not to exist, and if they did, assumed it was in a quaranteen/lab..



--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-