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

Re: [Captive-portals] API / ICMP for status and remaining time



If I understand correctly, the “Policy Class” can be considered as a “Reason”.

Then different users can be having different portal experiences from the same base URL.

Is that what you meant?

 

If so, I think this does address the issues of URL phishing by an off-net attacker.

 

Any thoughts on whether rate-limiting of messages should be specified?

 

 

 

 

 

From: David Bird [mailto:[email protected]]
Sent: Tuesday, September 06, 2016 4:03 PM
To: Michael Richardson
Cc: Dave Dolson; Alexander Roscoe; [email protected]
Subject: Re: [Captive-portals] API / ICMP for status and remaining time

 

Ideally, the "Policy Class" hint could be used instead of putting the URL in the ICMP packet (which was our original thought). I think it helps to require RFC 7710 to get the base CP URL so that Capport ICMP is meaningless in networks not configured with Capport DHCP. 

 

On Tue, Sep 6, 2016 at 12:46 PM, Michael Richardson <mcr+[email protected]> wrote:


Dave Dolson <[email protected]> wrote:
    > An ICMP extension could notify a sender that a 5-tuple connection is walled
    > off‎. It works for all IP protocols (TCP, UDP, GRE, even ICMP-echo).
    > ‎This will be more real-time than relying on the sender to periodically probe
    > well-known servers on port 80.

Agreed, it's good.  Like all ICMPs, we must assume that they could be forged.

    > Such a message should indicate a reason, which could be a URL to a JSON/REST
    > interface.
    > Or, it could simply be an event that means "go probe port 80 to get
    > redirected"

While I think it's slight less attackable to get redirected; I also favour
putting the URL in the packet, even if we ultimately can not trust it.

--
Michael Richardson <mcr+[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-