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