[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

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