Hi Alexandr,
On Wed, Oct 30, 2019 at 10:14:09AM +0100, Alexandr Nedvedicky wrote:
| Hello Paul,
|
| interesting exercise it has never come to my mind to try something like that.
| I did poke to RFCs and found 1122 [1]. I'm not RFC guru so I hope this
| partcular one is not superseded or updated by more recent one.
Thanks, I tried looking for an applicable RFC but got lost in a twisty
maze of documents.
| If I understand quotation below right, then host TCP stack should just ignore
| ICMP port unreachable message sent on behalf rule:
| > block return-icmp proto tcp from any to any port 10002
Quoting a subsection of the bit you copied from the RFC:
| A transport protocol
| that has its own mechanism for notifying the sender that a
| port is unreachable (e.g., TCP, which sends RST segments)
| MUST nevertheless accept an ICMP Port Unreachable for the
| same purpose.
The "MUST [...] accept [...] for the same purpose" suggests to me that
a complying stack shouldn't ignore the ICMP error but should have the
same result ('same purpose').
At the very least, the OpenBSD behaviour of timing out (sending four
SYNs) but giving error message "Connection refused" seems to me as the
"half-way in between the two"-option.
| I think there is a very little IP/TCP implementations, which follow
| standard.
I've checked the behaviour of a couple of stacks:
FreeBSD: immediate connection refused (1 SYN)
Linux : immediate connection refused (1 SYN)
macOS : immediate connection refused (1 SYN)
Windows: almost immediate connection refused (3 SYNs) [*]
OpenBSD: connection refused after timeout (4 SYNs)
[*]: Note that on Windows I had to test using ssh -p 10001 to see its
behaviour, but it also sends 3 SYNs in the return-rst (with TCP RST)
case.
Those are the OSes I have easy access to for testing.
Cheers,
Paul
--
>++++++++[<++++++++++>-]<+++++++.>+++[<------>-]<.>+++[<+
+++++++++++>-]<.>++[<------------>-]<+.--------------.[-]
http://www.weirdnet.nl/
