[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] Signals from the network and ICMP



On Thu, 17 May 2018 at 16:21, Vincent van Dam <[email protected]>
wrote:


> > On 16 May 2018, at 15:49, Erik Kline <[email protected]> wrote:
> >
> > In the latter case especially, what becomes clear is that the UE needs
> > to be able to receive an unsolicited packet.  ICMP is a canonical
> > example of receiving and processing an unsolicited packet.  But it
> > could also be something like a UDP socket listening on a well known
> > port that receives a 1-byte datagram, which causes the UE to enqueue
> > (for rate-limiting purposes) a captive API query.

> I think UDP on a well-known port could be a viable alternative to ICMP.
The interface should have deliver at least the same level of trust as the
ICMP unreachable can provide. In the unreachable ICMP it is possible to
relate the packet to the packet that caused the notification. I am not
claiming the UDP interface (or other interface) should use this exact same
approach for reliability, but if we use it as just a single byte message,
we would actually make it easier for malicious users to trigger calls to
the capport-api (even though it’s rate limited). Maybe some token as
payload, or a better idea that has lesser dependencies on moving parts in
the capport deployment.

Well, if we're doing application protocol stuff (like UDP), then perhaps we
could revisit the API key used for signing messages (which I think was
removed from the API doc :).

One problem with UDP is that if the enforcement point is well upstream of
several firewalls, it likely won't get through.

Consider the case of a DSLAM doing some captive portal enforcement on a
per-line-ID basis.  Originating a packet from the DSLAM back to the sender
can reasonably be expected to get to the home CPE (DSL modem), but if the
user has installed firewall devices downstream of this then ICMP stands a
better chance of getting through than UDP, I feel.

Thinking about this case in particular suggests to me that /new/ ICMP types
for "captive portal in force" may not work well either, as I strongly
suspect that firewall devices/software inspects ICMP messages.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature