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

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



Agreed that TCP RST is a non-starter... While some NASs do it today, it is protocol specific and can't convey the presence of a captive portal, exactly; the client wouldn't know if the target server did the rst or the NAS. 

Also agreed, "ICMP seems to have an undeserved bad name"... We are looking for a network signal - I think we already found one.

On Thu, May 3, 2018 at 6:21 AM Michael Richardson <[email protected]> wrote:

Martin Thomson <[email protected]> wrote:
    > On Wed, May 2, 2018 at 10:06 PM Michael Richardson <[email protected]>
    > wrote:
    >> Have we considered TCP RST already? (I don't think it's better than ICMP,
    >> but
    >> I don't remember it being discussed yet)

    > We can now if you like.  But not all protocols use TCP.

Yes, that's true, but essentially all of the "am I behind a captive portal"
probes do, and in the most restrictive places, that's all that works anyway.
We don't need every protocol to detect the captive portal, so long as *some*
method does.

There are two possibilities that I see with a TCP RST.

1) SYN -> RST.
   I am anware of anything that has ever put a TCP option on a TCP RST
   packet.  A quick review of rfc793 does not seem to forbid it, but
   would likely require kernel and API work to get it to the application.
   A nice point is that TCP RST gets turned into a synchronous error code on
   connect(2), and the application already has to pay attention to that.

2) SYN, SYN/ACK+option, ACK, RST.
   The TCP option goes in a more expected place, and to endpoints that do not
   speak it, this looks like the socket being closed immediately.


Some advantages:
     1) uses TCP sequence numbers for "security".
     Of course, like all other methods, any observer that can see the
     outgoing packet can spoof the responses.  But, it requires
     a passive observer that can inject packets to do that.  (Such an
     attacker can also just TCP RST every TCP connection, of course)

     2) it uses existing signaling.  No firewall (host or network based)
     can filter the TCP RST itself, although it might be confused by options
     present!!!  If it happens to work today (we'd have to do a test), then
     it probably won't change in the future, while ICMP seems to have an
     undeserved bad name.

Some disadvantages:
     1) changes required to host TCP stack!
     2) not possible for a captive portal detector application to just open a
        raw socket and look for things like ICMPs of a particular type.
     3) can not be used to remind the host to check with the API for imminent
        renewal, etc.

I think that the disadvantages and unlikelyhood that it would really work in
practice makes this a non-starter to me.

    > David (Bird) listed some of the things that are in common usage: ICMP
    > DestUnreach (no specific code), TCP RST, and dropping packets.  Each have
    > different characteristics.  I think that one product of the discussion in
    > London was that we don't need to be restricted to choosing from that set if
    > we think that there is something better.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email protected]  http://www.sandelman.ca/        |   ruby on rails    [

_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals