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

[David Bird <[e-mail]>]

On Mon, Apr 10, 2017 at 8:57 AM, Mikael Abrahamsson <[e-mail]>
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
<https://tools.ietf.org/html/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: [e-mail]
>