Subject: [Captive-portals] FW: New Version Notification for draft-larose-capport-architecture-00.txt

From: Kyle Larose <[email-masked]>
Date: Thu, 9 Mar 2017 22:26:06 +0000

Hello,

Dave and I realized that the working group had discussed, at length, a possible solution to the captive portal problem.
Since we were planning on working on it during the hackathon, we figured it'd be a good idea to capture the working group's ideas in an architecture.

We've uploaded the below draft as a skeleton for the architecture in the interest of having something to work from for the hackathon,
and discuss at the meeting.

Let us know what you think. 

Thanks!

Kyle

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, March 09, 2017 5:22 PM
To: Dave Dolson; Kyle Larose
Subject: New Version Notification for draft-larose-capport-architecture-00.txt

A new version of I-D, draft-larose-capport-architecture-00.txt
has been successfully submitted by Kyle Larose and posted to the IETF repository.

Name:		draft-larose-capport-architecture
Revision:	00
Title:		CAPPORT Architecture
Document date:	2017-03-09
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-larose-capport-architecture-00.txt
Status:         https://datatracker.ietf.org/doc/draft-larose-capport-architecture/
Htmlized:       https://tools.ietf.org/html/draft-larose-capport-architecture-00

Abstract:
   This document aims to document concensus on the CAPPORT architecture.
   DHCP, ICMP, and an HTTP API are used to provide the solution.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Dave Dolson <[email-masked]>
Date: Fri, 10 Mar 2017 00:12:54 +0000

Martin,
We look forward to addressing all of these issues.

We have a story for (1), and we've waved our hands about (2) and (3).

‎I think a separate draft might be appropriate for the API.

To take an initial stab at it, we think a GET to the ‎URI provides a JSON document of information and menu choices, since we've heard of a lot of different ideas about how User Equipment might want to navigate the captive portal. Clearly this will need to be standardized.

Input and new wording is very welcome.

-Dave

  Original Message
From: Martin Thomson
Sent: Thursday, March 9, 2017 6:32 PM
To: Kyle Larose
Cc: [email-masked]; Dave Dolson
Subject: Re: [Captive-portals] FW: New Version Notification for draft-larose-capport-architecture-00.txt

Thanks for putting this together Kyle.

After a brief skim (I will read this more thoroughly in the next week
or so), I have some high level comments that I think you should spend
some time thinking about:

1. How to manage trust in the ICMP messages.  I like that you are just
using these to nudge a client into the flow, but how do you avoid
spoofing?  We've a little bit of experience with this in QUIC and
there is some advice on how a client might handle unauthenticated ICMP
there that might be reused (key observation: v6 >> v4 because you get
much better assurances about the message coming from a path element).

2. How do you authenticate the interactions with the portal? How do
you decide what to give it?

3. How to interact with the DHCP-provided URI.  The big failing of RFC
7710 (in my view) is that it doesn't really say what to do with this
URI that falls into your lap.  I think that you either shove it in a
browser or poke at it with some sort of other type of request (you
seem to assume the latter here), but that's astonishingly vague.  This
seems like a great opportunity to point at other work.  Work I'm
hoping will start at the hackathon.

On 10 March 2017 at 09:26, Kyle Larose <[email-masked]> wrote:
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Mar 2017 10:32:30 +1100

---

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Mar 2017 11:17:24 +1100

> ‎I think a separate draft might be appropriate for the API.

Yep.  I wouldn't expect this doc to get sidetracked too much.

> To take an initial stab at it, we think a GET to the ‎URI provides a JSON document of information and menu choices, since we've heard of a lot of different ideas about how User Equipment might want…

Agree.  Also, there seems to be some expectation that the URL gets fed
to a browser, so the portal would need to be able to distinguish that
from a JSON document approach.