Re: [Captive-portals] time-based walled gardens

On Mon, Apr 10, 2017 at 8:57 AM, Mikael Abrahamsson <[email protected]> wrote:

On Mon, 10 Apr 2017, David Bird wrote:

As far as being use-case specific, you mean the captive portal use-case? (I like to think that within captive portal use-cases, the ICMP concept is actually very use-case agnostic). If so, I see you point... but, this is the Capport WG. Perhaps we are now talking more generally about any 'network prompted portal interaction' ?

I'm talking about "general network information". For me CAPPORT use-case is one use-case for this kind of information. There are others.

CAPPORT doesn't have to just solve its own problems, perhaps it'd be good to try to come up with a slightly more generic solution and send it for review in INT-AREA for instance? I keep mentioning ALTO because I see their use-case as similar as well, but they invented their own discovery mechanism.

I took a quick look at ALTO. I'd have some concerns about the complexity and the high incentive for "attacker" or hostile behavior. The 5 Security subsections all seemed a bit scary, with the protection strategy for a server wanting to provide misleading information:

   To protect applications from undesirable ALTO information resources,
   it is important to note that there is no protocol mechanism to
   require conforming behaviors on how applications use ALTO information
   resources.  An application using ALTO may consider including a
   mechanism to detect misleading or undesirable results from using ALTO
   information resources.  For example, if throughput measurements do
   not show "better-than-random" results when using an ALTO cost map to
   select resource providers, the application may want to disable ALTO
   usage or switch to an external ALTO server provided by an
   "independent organization" (see AR-20 and AR-21 in [RFC6708]).

In public access networks, I think it is more appropriate to take the information you get and: trust, but verify. DHCP/RA gives you the portal URL, it might as well since it is also giving you your default route and IP. The network is providing notification, because it might as well, it is doing that anyway and the in-line components enforcing any limitation (NAS, rate-limiting, etc) have the information they need.

Also, the ICMP error we're talking about, is that feature parity with RFC7710? Because I would like to see DHCP options, RA options and ICMP messages all being able to do the same thing. I could even imagine the ICMP unreach message (perhaps very similar in content) be sent to a multicast group on the LAN, completely replacing the RA/DHCP option? Or we could do it using mDNS instead of in RA? Is there even work on feature parity using mDNS instead?

No, the Capport ICMP protocol doesn't provide parity with rfc7710, rather works in combination. My first draft allowed for the portal URL in the ICMP message, but even with other precautions, the group quickly determined that was too risky for threat of an ICMP message sending you to an arbitrary site. It seems reasonable to separate 'notification' from 'configuration' in this way...

--
Mikael Abrahamsson email: [email protected]