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

Dave Dolson <[email protected]> · 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 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:
> 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 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
>
>
> 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
>
> _______________________________________________
> Captive-portals mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/captive-portals