IETF Logo Mail Archive

Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00

Dave Dolson <ddolson@sandvine.com> Mon, 07 March 2016 15:08 UTC

Return-Path: <ddolson@sandvine.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E98F1B427C for <captive-portals@ietfa.amsl.com>; Mon, 7 Mar 2016 07:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham
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 GJg5h6l5Yfd6 for <captive-portals@ietfa.amsl.com>; Mon, 7 Mar 2016 07:08:29 -0800 (PST)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) by ietfa.amsl.com (Postfix) with ESMTP id 391CA1B4272 for <captive-portals@ietf.org>; Mon, 7 Mar 2016 07:08:29 -0800 (PST)
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.195.1; Mon, 7 Mar 2016 10:08:28 -0500
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by blr-exchp-2.sandvine.com ([fe80::6c6d:7108:c63c:9055%14]) with mapi id 14.03.0181.006; Mon, 7 Mar 2016 10:08:19 -0500
From: Dave Dolson <ddolson@sandvine.com>
To: Martin Thomson <martin.thomson@gmail.com>, "Livingood, Jason" <Jason_Livingood@comcast.com>
Thread-Topic: [Captive-portals] Comments on draft-nottingham-capport-problem-00
Thread-Index: AQHRdOMXZOFwZ0XXhk2b4ei54nIPUJ9OFNFg
Date: Mon, 07 Mar 2016 15:08:27 +0000
Message-ID: <E8355113905631478EFF04F5AA706E9830EBCAE6@wtl-exchp-2.sandvine.com>
References: <D2FCEB47.12A6DC%jason_livingood@cable.comcast.com> <CABkgnnV-Nbbt3Mkh-ZOzWig7rJX32SFugkWLnx-t94bA-B__Lw@mail.gmail.com>
In-Reply-To: <CABkgnnV-Nbbt3Mkh-ZOzWig7rJX32SFugkWLnx-t94bA-B__Lw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.200.63]
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: <http://mailarchive.ietf.org/arch/msg/captive-portals/BfiJbCjgib_SqftsFBp5drTXrXw>
Cc: Mark Nottingham <mnot@mnot.net>, "captive-portals@ietf.org" <captive-portals@ietf.org>
Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.15
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, 07 Mar 2016 15:08:35 -0000

Regarding non-browser clients, even non-HTTP clients, and considering
this is the IETF, it seems reasonable to find an IP-layer solution vs. 
an HTTP-layer solution.

E.g., a new ICMP/ICMP6 error code to indicate the host is walled, with a pointer
to the method to authenticate in the payload.
This could be an extension to "Network Unreachable", or a new code.

ICMP messages are handled by the O/S, and could trigger an authentication work-flow
appropriate to the device, whether it be a human-interface device like a tablet
or a head-less IOT device.

E.g., suppose the a VoIP phone becomes walled during a call. Outgoing packets
are answered with an ICMP message; the O/S immediately performs the authentication
using previously-provided credentials, and the call continues shortly thereafter.
If the credentials fail, the user can be presented with a  window or browser.


The ICMP payload would be a standard format, and could have security features
to avoid spoofing.


I guess I'm jumping ahead of the problem statement, but I think the
"Non-Browser Clients" issue could be changed to "Non-HTTP Clients",
providing a huge win.



-Dave




-----Original Message-----
From: Captive-portals [mailto:captive-portals-bounces@ietf.org] On Behalf Of Martin Thomson
Sent: Wednesday, March 02, 2016 7:25 PM
To: Livingood, Jason
Cc: Mark Nottingham; captive-portals@ietf.org
Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00

On 3 March 2016 at 11:16, Livingood, Jason <Jason_Livingood@comcast.com> wrote:
> 3.0, Feel free to take a look at the text in Section 12 of RFC 6108 and
> use some of that text. You got the gist of it in the Non-Browser Clients
> sub-section though (https://tools.ietf.org/html/rfc6108#section-12)


This raises an interesting point about internet dot org by facebook.
I wonder if there are any lessons to be learned from that as well.

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

v2.23.0 | Report a Bug | By Email