Hi, Linda, and thanks for the review and follow-up. I don’t agree that much (or any) more needs to be said in this document: that’s what normative references are for. If the architecture document isn’t clear enough about what we’re doing and why, then I think that is the place to address it.
Barry
On Sun, May 10, 2020 at 7:18 PM Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> wrote:
Joe and Tommy,
Thank you very much for the explanation. They are very helpful. I don't recall those useful information when I glanced through the draft-ietf-capport-architecture. IMHO, those information would be useful to be added in the Introduction section.
Linda
-----Original Message-----
From: mjabaut@xxxxxxxxxxxxxxxx <mjabaut@xxxxxxxxxxxxxxxx> On Behalf Of Joe Abley
Sent: Saturday, May 9, 2020 5:42 PM
To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx>
Cc: ops-dir@xxxxxxxx; last-call@xxxxxxxxx; draft-ietf-capport-api.all@xxxxxxxx; captive-portals@xxxxxxxx
Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-capport-api-07
Hi Linda,
On 9 May 2020, at 18:06, Linda Dunbar via Datatracker <noreply@xxxxxxxx> wrote:
> Reviewer: Linda Dunbar
> What improvement does the proposed API have over today's existing
> communication between clients and Captive Server(s)? Captive servers
> have been deployed everywhere, like airport or restaurants trying to
> access free WIFI. What problems does the existing method have to justify this newly proposed APIs?
I have no involvement with this architecture apart from being an enthusiastic cheerleader on the sidelines, but it seems to me that none of the existing captive environments you mention have anything resembling a structured, machine-readable interface. So this is not a newly-proposed API so much as the first and only example of a standard API we have for this at all.
Existing mechanisms rely upon devices being configured in a particular way (e.g. DNSSEC validation disabled, DHCP-provided DNS server being used, DoH/DoT disabled), they rely upon users using particular applications to trigger an interaction to escape the captive environment (e.g. a browser), they provide no clear indication to client software that a captive portal exists, leaving the client to try to infer whether the network is simply broken or whether it is encumbered and it's rare that two such environments you encounter on any particular day act the same. They also often trigger certificate warnings in software like calendars and mail readers that I have seen users click OK on, imagining that they are gaining access to the network by doing so, whereas in fact they are just facilitating an on-path attack on TLS so that their credentials can be stolen.
While some widely-used devices have come to be accommodated more elegantly than others through simple market dynamics (e.g. giving iPhone users a smooth experience reduces support costs and increases revenue) the general experience is, putting it mildly, horrific, wildly inconsistent and hostile to users.
The companion architecture document draft-ietf-capport-architecture-07 contains a brief description of some common components of existing mechanisms in its appendix A, but I think the variety deployed in the world is wide enough that it's reasonable for that document not to try go into any more detail. In any case I don't think this document (draft-ietf-capport-api-07) needs any such narrative; I think the architecture document is a better place for it.
[Having been so rude about existing mechanisms, I will mention wistfully that I do very much look forward to the day when I can be horrified by wifi in airports and coffee shops again.]
Joe
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
