Sending to mailing list. From: Dave Dolson Sent: Tuesday, September 06, 2016 5:29 PM To: 'David Bird' Subject: RE: [Captive-portals] API / ICMP for status and remaining time
Inline [DD] From: David Bird [mailto:db...@google.com] Sent: Tuesday, September 06, 2016 5:23 PM To: Dave Dolson Subject: Re: [Captive-portals] API / ICMP for status and remaining time On Tue, Sep 6, 2016 at 1:56 PM, Dave Dolson <ddol...@sandvine.com<mailto:ddol...@sandvine.com>> 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. [DD] I’m not a fan of recommending ICMP be dropped. My point was that there is little damage that an off-network attacker can do, except make you go to your own portal. But perhaps often; hence the receiver should rate-limit visits to the portal. 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? [DD] How about saying the receiver of the ICMP messages should rate-limit visits to the portal. From: David Bird [mailto:db...@google.com<mailto:db...@google.com>] Sent: Tuesday, September 06, 2016 4:03 PM To: Michael Richardson Cc: Dave Dolson; Alexander Roscoe; captive-portals@ietf.org<mailto:captive-portals@ietf.org> 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+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>> wrote: Dave Dolson <ddol...@sandvine.com<mailto:ddol...@sandvine.com>> 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+i...@sandelman.ca<mailto:mcr%2bi...@sandelman.ca>>, Sandelman Software Works -= IPv6 IoT consulting =-
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
