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

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

On Tue, Sep 6, 2016 at 1:56 PM, Dave Dolson <[email protected]> wrote:

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?


That would depend on the portal -- it can decide to redirect to a different portal, display different text, or do nothing -- so, potentially.


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


It would be easy to prevent ICMP of this nature entering a network from the Internet (the NAS decide is in a good position to do this in many cases). We could make it clear that routers should drop capport ICMP unless specifically configured not to. 

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


I think there needs to be a section on it. In the validity description I mention a NAS may start silently dropping packets, that could be stronger. Any suggestions from past experiences?





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 <[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 <[email protected]>, Sandelman Software Works
 -= IPv6 IoT consulting =-