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

Gunther Nitzsche <gnitzsche@netcologne.de> Tue, 06 June 2017 14:08 UTC

Return-Path: <gnitzsche@netcologne.de>
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 3E1D7128CFF for <captive-portals@ietfa.amsl.com>; Tue, 6 Jun 2017 07:08:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 0tHvVKqIUHG2 for <captive-portals@ietfa.amsl.com>; Tue, 6 Jun 2017 07:08:15 -0700 (PDT)
Received: from cc-smtpout1.netcologne.de (cc-smtpout1.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2464126C0F for <captive-portals@ietf.org>; Tue, 6 Jun 2017 07:08:13 -0700 (PDT)
Received: from cc-smtpin1.netcologne.de (cc-smtpin1.netcologne.de [89.1.8.201]) by cc-smtpout1.netcologne.de (Postfix) with ESMTP id AE75713486; Tue, 6 Jun 2017 16:08:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1496758091; bh=k9w1TcMc0E7SlrPV3EKe6ZhgbX8yvVHl7W66ztOJcpE=; h=Subject:To:References:Cc:From:Message-ID:Date:In-Reply-To:From; b=R0oUnWfoM/Lxp+ZLjauxqoE0g06E7x9idViU5PdnclVUjQSTyTi97Q5pv1I5yHe57 nJPbKDL0WT2qGFEsoKwwUjeDRoLBZq9JwCjYrMGQnKc6lXpfLXAHt1iqkA7V9eA1V/ q9DgrqNK24cAju/4/V7A7p5maE0c0nzrG/P8b0c8FuZG5qu6ZQ/DeSeij6M2AzJZhe YxCmCFhERcatYmKfa4nARy31qW7pjJ4OyvrS4A8Y4qij2HpYNUhI6WiSe8vXZrPKwU q23DtdNyCTg6Nt1xTXss6Lfg8toYMQHJZ3/GARVQfAQUnLRsOmhs2NH3nMuSEOMHRM x9d3tDggrc/Pg==
Received: from localhost (localhost [127.0.0.1]) by cc-smtpin1.netcologne.de (Postfix) with ESMTP id A030C11D75; Tue, 6 Jun 2017 16:08:11 +0200 (CEST)
Received: from [2001:4dd0:0:193:222::] (helo=cc-smtpin1.netcologne.de) by localhost with ESMTP (eXpurgate 4.1.9) (envelope-from <gnitzsche@netcologne.de>) id 5936b74b-021e-7f0000012729-7f0000018428-1 for <multiple-recipients>; Tue, 06 Jun 2017 16:08:11 +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-SHA (256/256 bits)) (No client certificate requested) by cc-smtpin1.netcologne.de (Postfix) with ESMTPSA; Tue, 6 Jun 2017 16:08:10 +0200 (CEST)
To: "Livingood, Jason" <Jason_Livingood@comcast.com>, Martin Thomson <martin.thomson@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>
Cc: Heiko Folkerts <heiko.folkerts@bsi.bund.de>, Warren Kumari <warren@kumari.net>, "captive-portals@ietf.org" <captive-portals@ietf.org>, "Herzig, Willi" <willi.herzig@bsi.bund.de>, Dave Dolson <ddolson@sandvine.com>
From: Gunther Nitzsche <gnitzsche@netcologne.de>
X-Enigmail-Draft-Status: N1110
Message-ID: <754719c5-c74c-fbdc-405e-b8c91478c0a5@netcologne.de>
Date: Tue, 06 Jun 2017 16:08:10 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <AD3F2B14-E9AD-4156-96A6-9B83F8545B54@cable.comcast.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/rgho7-CTNNakiGmcsiMXzZunX_0>
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: Tue, 06 Jun 2017 14:08:17 -0000

On 02.06.2017 14:47, Livingood, Jason wrote:
> [JL] But let me summarize the malware/hacked IoT device use case. A computing device is compromised and being used as part of a DDoS attack (a la the Dyn attack) or sending spam or doing keylogging or whatever. One alternative is to put them in a walled garden with CAPPORT whereby they have no access from any device in the home or, if the network architecture can do it, no access for only that specific device (other 

> The CAPPORT walled garden page would direct the device(s) or user(s) to a page explaining what the malware is and how to remediate, for example. 

..And how to get out of the walled garden.  (nobody wants to stay there )

> Another alternative is a method to direct a device to a page / deliver a message about this malware issue without otherwise affecting or constraining their Internet access. In this alternative method, the objective is to get a critical security message to the user (e.g. Device X has malware Y and needs to be fixed ASAP) while not affecting things like gaming, OTT voice, OTT video, etc.

This alternative is no option. The device in question seems to be a real
danger for
other internet users and also for the device owner himself (like data
loss..).
Letting traffic be unaffected by a walled garden means that a
participation in
e.g. a DDoS attack will go on.  A differentiation between "internet" and
"voice" should be made though.
(skype would be considered as internet use) A POP-UP window or
notification during gaming / trading /
whatsoever will just be ignored or delete-clicked or not even noticed
because of not having a browser like tool.

But that is a topic for a different mailinglist - "how to react to
internet abuse". MAAWG and others are
discussing this for many years now ..:)    We do stop internet access in
case of abuse immediately
and have therefor built our own form of walled garden; others may have a
more tolerant view or just
have bad contracts with their customers :/

So it seems we agree that there are valid reasons for walled gardens -
now we should concentrate
on *how* to implement this in the best way.

(the 511 error page does not seem to be the worst variant.. if the user
sees an error in the browser
then the next reload puts him to the correct walled garden page)


best greetings,
Gunther

NetCologne Systemadministration

-- 
NetCologne Gesellschaft für Telekommunikation mbH
Am Coloneum 9 ; 50829 Köln
Geschäftsführer:   
  Timo von Lepel,
  Mario Wilhelm  
Vorsitzender des Aufsichtsrates:
  Dr. Andreas Cerbe
  HRB 25580, AG Köln