[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.


  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