Re: [Captive-portals] CAPPORT ICMP

[David Bird <[e-mail]>]

+captive-portals

On Sat, Apr 1, 2017 at 1:22 PM, Martin Thomson <[e-mail]>
wrote:

> (Adding ek; though I'm thinking that we should just take this discussion
> to the list.)
>
> Those places that use a public address space for their closed network (or
> the part that houses the enforcement device) would suffer in that case.
>
>
That wouldn't matter much -- unless there is some sort of source routing in
play...


> Maybe we should step back and examine the security goal.  We want to
> reduce the chance that a spurious signal is accepted by a client.  In this
> case, a signal is spurious if it comes from off path, if it is sent from a
> network that is too remote (a definition that probably needs some
> refinement), or if data flows despite the signal.
>
>
I'd argue that are goals are not particularly 'security' focused.. Though,
agreed it is a concern. We certainly shouldn't *worsen* the security.



> I'm starting to think that an explicit probe is what we want here, just as
> David (Bird) said.  That is, a message that is guaranteed* to elicit a
> response from a portal.  Let's say that an endpoint receives an ICMP
> unreachable with the captive portal decoration.  At that point, it kicks
> the detection engine. That generates a series of ICMP messages** with low
> TTLs and high entropy payloads (this could be a traceroute in effect) and
> the same capport extension.  If the captive portal is valid, it will return
> the packet and include the capport extension.
>
>
Agreed, good point.


> It shouldn't take very long to detect a legitimate block this way.  So
> during the check, the endpoint does not disable the affected interface.  If
> it continues to receive data on the flow that triggered this, it should
> consider the original ICMP unreachable as spurious and cancel the probe.
> Ideally this is all in the kernel, but an application could implement this
> logic itself.
>
> (BTW, I think that the entire payload in draft-kumari is unwise.  It would
> be better if we rely on something like draft-donnelly and ask for
> expiration times.  I'll follow up on the list.)
>
>
My concern (fundamentally) about asking the API anything is that it could
be wrong (and, I'd argue, it WILL be wrong so often that UEs will just
start ignoring it). I think the API should only, more or less, confirm
information and provide a means for "auto-login" (pinning saved credentials
in the WiFi profile to an API URI and server x509 certificate).

The NAS, imho, MUST be the source of truth. Yes, the API *can* be in the
NAS, but if you secure it with https (and want a real cert) that is
expensive. Moreover, many operator would want that API more centralized. As
they do that, things will start falling apart...

Some examples:

- What if a network (configured by mistake, configured poorly, or
otherwise) configures RFC 7710 in their DHCP server and creates the CAPPORT
API, and that is it!  Now, imagine the *customer complaints* about the
CAPPORT detection features in handsets when they figure out only THEY get
the portal when legacy devices do NOT.

- It is not unusual for a Hotspot to have MULTIPLE authentication sources:
MAC Authentication, different RADIUS servers used by realm, etc. Having an
API that is the source of truth would require networks redesign -- broken
networks galore.

- It is also not unusual for captive portals to be outsources to companies
that DO NOT own, operator, install, or otherwise administer the Wi-Fi
infrastructure. Sure, they need to coordinate configurations, to some
degree, for things like Walled garden to work, but once that is done once,
the configuration is fragile (unless the operator does out-of-band
synchronization of configurations to APs). -- again, broken networks galore.

- You are pretty much guaranteed (minus the risk for forgery) that the one
sending the ICMP is the NAS!



> * by our specification at least, we have to allow for packet loss, of
> course.
> ** straw man example only
>
>
> On 1 April 2017 at 12:59, David Bird <[e-mail]> wrote:
>
>> We could restrict the sending address space to something in rfc1918...
>>
>> On Sat, Apr 1, 2017 at 10:38 AM, Dave Dolson <[e-mail]>
>> wrote:
>>
>>> I don't think we should assume the enforcement point is always on the
>>> local link.
>>>
>>> David Dolson
>>> Sandvine
>>> *From: *David Bird
>>> *Sent: *Saturday, April 1, 2017 12:14 PM
>>> *To: *Dave Dolson
>>> *Cc: *Martin Thomson; Kyle Larose
>>> *Subject: *Re: CAPPORT ICMP
>>>
>>> Also, as suggested by Erik Kline, we can make further limitations on who
>>> can send these messages - link local / unroutable addresses, etc.
>>>
>>> On Apr 1, 2017 8:46 AM, "David Bird" <[e-mail]> wrote:
>>>
>>> In https://github.com/wlanmac/draft-wkumari-capport-icmp-unreach I was
>>> thinking that a Session ID could be used to group ICMP messages into, more
>>> or less, a single event. Only when the Session ID changes (and also based
>>> on input from the Validity and Delay times) would the UE revisit the API.
>>> And, a UE would not expect the Session ID to constantly be changing (I
>>> think then it can assume it is under attack from a malicious user or just a
>>> really unfriendly network provider).
>>>
>>>
>>>
>>> On Fri, Mar 31, 2017 at 7:02 AM, Dave Dolson <[e-mail]>
>>> wrote:
>>>
>>>> I think we can mitigate concerns about the ICMP by rate-limiting visits
>>>> to the capport API, which is not something that can be done with current
>>>> redirect approaches.
>>>>
>>>>
>>>>
>>>> *From: *David Bird
>>>> *Sent: *Friday, March 31, 2017 8:09 AM
>>>> *To: *Martin Thomson
>>>> *Cc: *Dave Dolson; Kyle Larose
>>>> *Subject: *Re: CAPPORT ICMP
>>>>
>>>>
>>>>> With RFC 4884, which we could require, the UE still has to remember
>>>>> every packet it sends.  I think that is the larger burden.  One
>>>>> potential way to fix that would be to treat an ICMP unreachable as
>>>>> provisional and then run an explicit test.
>>>>>
>>>>
>>>> It wasn't the intention that UEs would have to remember what it sends.
>>>> Should the ICMP be supported in the kernel, the capport "enriched" Dest
>>>> Unreach bubbles up to the application. Without kernel support, something
>>>> similar can be done where the application can ask another service "was my
>>>> Dest Unreach with this tuple blocked by capport?" In that scenario, the
>>>> "another service" just needs to intercept ICMP and hold the tuple for a
>>>> little while in case an application queries about it.
>>>>
>>>> And, yes, the capport detection engine in the OS should be kicked
>>>> whenever a capport ICMP is received. It is also not the intention that a UE
>>>> will do something for EVERY ICMP, rather taken as input/signal to the
>>>> capport detection.
>>>>
>>>
>>>
>>>
>>
>