[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] FW: New Version Notification for draft-larose-capport-architecture-00.txt
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.
From: Martin Thomson
Sent: Thursday, March 9, 2017 6:32 PM
To: Kyle Larose
Cc: [email protected]; 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 protected]> wrote:
> 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.
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> 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
> 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
> Captive-portals mailing list
> [email protected]