[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00
Regarding non-browser clients, even non-HTTP clients, and considering
this is the IETF, it seems reasonable to find an IP-layer solution vs.
an HTTP-layer solution.
E.g., a new ICMP/ICMP6 error code to indicate the host is walled, with a pointer
to the method to authenticate in the payload.
This could be an extension to "Network Unreachable", or a new code.
ICMP messages are handled by the O/S, and could trigger an authentication work-flow
appropriate to the device, whether it be a human-interface device like a tablet
or a head-less IOT device.
E.g., suppose the a VoIP phone becomes walled during a call. Outgoing packets
are answered with an ICMP message; the O/S immediately performs the authentication
using previously-provided credentials, and the call continues shortly thereafter.
If the credentials fail, the user can be presented with a window or browser.
The ICMP payload would be a standard format, and could have security features
to avoid spoofing.
I guess I'm jumping ahead of the problem statement, but I think the
"Non-Browser Clients" issue could be changed to "Non-HTTP Clients",
providing a huge win.
From: Captive-portals [mailto:[email protected]] On Behalf Of Martin Thomson
Sent: Wednesday, March 02, 2016 7:25 PM
To: Livingood, Jason
Cc: Mark Nottingham; [email protected]
Subject: Re: [Captive-portals] Comments on draft-nottingham-capport-problem-00
On 3 March 2016 at 11:16, Livingood, Jason <[email protected]> wrote:
> 3.0, Feel free to take a look at the text in Section 12 of RFC 6108 and
> use some of that text. You got the gist of it in the Non-Browser Clients
> sub-section though (https://tools.ietf.org/html/rfc6108#section-12)
This raises an interesting point about internet dot org by facebook.
I wonder if there are any lessons to be learned from that as well.
Captive-portals mailing list