Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
Gunther Nitzsche <gnitzsche@netcologne.de> Thu, 18 May 2017 12:19 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 6E4911294E8 for <captive-portals@ietfa.amsl.com>; Thu, 18 May 2017 05:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 P9OJOh9l2QgQ for <captive-portals@ietfa.amsl.com>; Thu, 18 May 2017 05:19:09 -0700 (PDT)
Received: from cc-smtpout2.netcologne.de (cc-smtpout2.netcologne.de [IPv6:2001:4dd0:100:1062:25:2:0:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C66128799 for <captive-portals@ietf.org>; Thu, 18 May 2017 05:14:12 -0700 (PDT)
Received: from cc-smtpin1.netcologne.de (cc-smtpin1.netcologne.de [89.1.8.201]) by cc-smtpout2.netcologne.de (Postfix) with ESMTP id 8E723124B3; Thu, 18 May 2017 14:14:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de; s=nc1116a; t=1495109650; bh=T7mKIV5cY02rusEgHwVJFC4lDN8eTEwJ6Ec81HeLta0=; h=Subject:To:References:Cc:From:Message-ID:Date:In-Reply-To:From; b=iQlQWPQdaVbwYXd7lsj688LDEuJr17ea2zKHa6nRJsHk0VJ3J0L8kXelWpiezPlZl 02zPCOTS679fFPJFbaoBvqF0xg8u+HDmtchEg791sgLQLVf2Skp0Nsg6hZh2JdE+wX Yd4VmUUnAxCKqcktdAkpfNo16NCyuShVv3iyCoXSTC+/5nK9CYrwSttD4UBRalp3q2 X/VuizJq9pkq2WyHz/eOOi6sGQqHBJ4KVf/lJp49x/Lnhi+Z1ko294eUjaSh8wXDyI UO7etlq6Xkmpm9llzZqlVyrySHlTEQucJfYlQfv+zRLQHvKPl1Nb19QHoDLsNBIKia TG0O53mG9O/cg==
Received: from localhost (localhost [127.0.0.1]) by cc-smtpin1.netcologne.de (Postfix) with ESMTP id 8320F11DFD; Thu, 18 May 2017 14:14:10 +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 591d9012-021e-7f0000012729-7f000001c48f-1 for <multiple-recipients>; Thu, 18 May 2017 14:14:10 +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; Thu, 18 May 2017 14:14:10 +0200 (CEST)
To: David Bird <dbird@google.com>
References: <201705031442.50683.heiko.folkerts@bsi.bund.de> <8951dd0a-044b-b3ed-4454-e24fac407c4e@netcologne.de> <CADo9JyVdkzrtWE6RMt3CVYCkHrdB=+LKA9eDazN8Xf+R=Vza_Q@mail.gmail.com>
Cc: Heiko Folkerts <heiko.folkerts@bsi.bund.de>, "Herzig, Willi" <willi.herzig@bsi.bund.de>, captive-portals@ietf.org
From: Gunther Nitzsche <gnitzsche@netcologne.de>
X-Enigmail-Draft-Status: N0110
Message-ID: <7e4e6be2-3f2e-897e-4c7b-0374f0b7b0b5@netcologne.de>
Date: Thu, 18 May 2017 14:14: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: <CADo9JyVdkzrtWE6RMt3CVYCkHrdB=+LKA9eDazN8Xf+R=Vza_Q@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/_xanTMAnmaOHZpTQnqD3jd9GlIc>
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: Thu, 18 May 2017 12:19:12 -0000
Hello, thanks for your reply. Let me argue against ..:) On 17.05.2017 17:11, David Bird wrote: > > > We need to stop the 443 redirecting! > > Thus far, I don't see any reason why ICMP wouldn't work. In fact, if > *no* ICMP worked, some basic networking stops working (general dest > unreach, MTU discovery, etc). > In a theoretical point of view I absolutely second your opinion. In real world scenarios I don't see how this could work out. >That is by design, in some respects. The "capport compliant" device will not ignore these messages (by definition). "Legacy" devices would ignore them, and they will still depend on the >HTTP redirect. I guess that is the crux. There are no "capport compliant devices" outside wifi and there won't be any for long long time.(as I said: outside the mobile world)) (I may be wrong here?) I do not see how to tell Microsoft, Apple, sun/oracle or the linux community to insert a capport detection inside their OS. And even if a Windows 11 and a linux kernel 5 would support that, there will be a wide majority of devices which would not be updated and will not meet the criteria and still has to be handled in a different way. When the major browsers would support that (like the Chromium Project for ChromeBooks in https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection#TOC-Interpretation-of-Portal-State ) we might get a step further. But I doubt that the majority of users will accept permanent "test-traffic" in normal circumstances. > The separation of "configuration" and "notification" is by design. > That might be a design error. Notification is done by the provider, but configuration (how to react on e.g. icmp unreachable) is up to the enduser. The provider cannot (and will not) configure any customer's client device. Maybe the CPE can be (pre-)configured (cable-modem/dsl-router) but not the home-PC. How do I tell the home-PC to open up a specific URL when capport detection gets activated (if it would exist)? > > => If the customers wants to communicate via a browser, then we should > answer via the browser. All other separate communication forms may > work but are > unreliable and are dependent on the customer setup. > > > > Increasingly, it is the operating system's captive portal detection > that is detecting the need for portal interaction. I agree that it is > convenient to have an in-line HTTP response with the redirect or 511 > status code, but plain old HTTP is becoming obsolete. Hijacking HTTPS > to return a 511 response is a bad idea. The ICMP approach gives > 'notification' without requiring (in-line protocol dependent) > man-in-the-middle responses and is protocol agnostic. > Now let's see how that would look like. If an ICMP unreachable is sent out to the customer, he will see an error in the browser. A different one like the ssl-breaking/stopping error, but still an error. But what comes next? Now we have lost the only channel to the customer - the http(s) session has ended. And we have lost the opportunity to tell the customer's browser what to show instead. If we sent out a status code instead we have at least the chance to show >something< in the browser which might help the customer to get on the right way. Maybe the return code just triggers a warning of the kind "the webserver is unreachable due to providers action and asks you to go to <URL> instead" and does not do a redirection by itself. Everything is better (for the customers experience, not for the pure theoretical doctrine) than just showing a site unreachable. > > > It isn't clear to me how subscriber UEs get assigned their IP > addresses in your network; they don't use DHCP? Some do, some don't. cable users do DHCP, DSL customers do radius (via ppp). Pretty standard stuff. Actually that doesn't matter a lot, since the connection termination is done by the CPE, not by the customer's client device (PC). Even if the cable-modem realizes that something strange is going on, the home-PC will not be affected by that. > > The UE browser will be 'informed' of the captive portal URL by the > captive portal detection mechanism (OS/vendor dependent like today). That might be true in the mobile world; For home-pc, small networks. and so on there is no cpdm which I know of. (That is why I am here :-) > There is a bit of a race condition between the captive portal > detection mechanism and the human interacting with the browser in > real-time. However, it is possible for browsers (or any Apps) to > integrate with the platform captive portal detection service to get > additional information like the portal URL. Could you name an example for this? Valid for a standard home-PC ? And..without having the user to install a cpd - service on his device? (remember: not mobile) ("If you want to be our customer you have to install <this> software here on all your devices; for Ubuntu please use <this> and for windows XP click <here>.." -> .. will not work) As I see it there is no detection mechanism in standard OS (outside wifi) today. And I cannot blame the customer to not have such service installed if it would exist. It is up to the provider to use the existing sources and work with the (unknown) equipment of different customers. So I fear we are stuck to work with the return codes.. > Agreed that UE (and browser) behaviors need to be better defined, but > that gets tricky to mandate in RFC, imho. What we can do is define > networking 'building blocks' and recommendations on how vendors build > user experiences with them. > (What is UE ?) tl;dr : while I support the opinion to stop breaking/redirecting https and do proper signaling with icmp instead, I do not see working setups in real world scenarios without sending a http-status code leading to specific browser's behaviour (outside of the mobile world). Otherwise the customer is left alone with a browser showing an error page. (If there would be a possibility to trigger a webpage with a capportdetection - icmp unreachable message, that would be great.. any hints welcome. Very well possible that I just overlooked something..) Thanks for listening and sorry for the again (too) long text... 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
- [Captive-portals] Use Case: "Carrier Grade Captiv… Heiko Folkerts
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… David Bird
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Dave Dolson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Warren Kumari
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Erik Kline
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Mark Nottingham
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Michael Richardson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Gunther Nitzsche
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… David Bird
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Gunther Nitzsche
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… David Bird
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Dave Dolson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Vincent van Dam
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Erik Kline
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Livingood, Jason
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Martin Thomson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Livingood, Jason
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Martin Thomson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Gunther Nitzsche
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Erik Kline
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Michael Richardson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… David Bird
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Vincent van Dam
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Dave Dolson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Eric Vyncke (evyncke)
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Erik Kline
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Dave Dolson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Tommy Pauly
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… David Bird
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Dave Dolson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Dave Dolson
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Tommy Pauly
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… Tommy Pauly
- Re: [Captive-portals] Use Case: "Carrier Grade Ca… David Bird