On Tue, 29 Jun 2004, Peter Corlett wrote:
Tony Hain <alh-ietf@tndh.net> wrote:
While it is often great sport to poke at MS, did you consider that this might have nothing to do with classfullness or CIDR? I believe you will find that 0 & -1 are invalid for whatever netmask the windows stack is given.
I think you may be confused about the problem. Let's not mask the IP addresses that I spotted this problem, but get them out into the open. (BTW, don't bother probing these addresses to retrace my steps, some hosts are now down, firewalled, or roaming the aisles of Gotts Road in ghostly torment.)
Step back.. The windows box does not have the problem IP directly connected nor does it have it specifically in its routing table, it is also not in the same classful network as the problem IP. Therefore netmasks are not involved, therefore it should not do anything other than forward it to the default. Afaik this is true of both classful and classless networking. Steve
On the one end of the connection, we have a Windows 2000 box with the IP address 217.169.21.28 and a Linux box with the adjacent IP address 217.169.21.29. These are on a LAN with a 255.255.255.240 netmask. In classful parlance, it is a Class C that has been subnetted. I also have a packet sniffer on the network.
On the other end of the connection, we have a Linux box with the IP address 195.92.249.0. I forget the exact netmask, but it was around the /19 or /20 mark. In classful parlance, it is a Class C that has been supernetted.
From the Windows box, I can ping 195.92.249.0 fine. I can't seem to ssh to that IP though. Break out the packet sniffer.
I ping, and the packet sniffer shows packets leaving, and coming back ~25ms later. Good. I fire up telnet and point it at port 22. "Connection refused". Packet sniffer shows no traffic. Double-checking from the Linux box, I can ping and telnet to port 22, and I get packets flowing just fine.
By the way, the Windows 2000 box is stock install, with no service packs, "personal firewall" software, antivirus stuff, etc, etc. In other words a sitting duck :) but it does mean that the problems aren't caused by third-party software.
You will note that 195.92.249.0 is not all-bits-zero or all-bits-set ("0 & -1") on 217.169.21.16/28. Therefore it is a perfectly valid IP address. Windows has *no* business interpreting IP addresses outside its limited view of the world.
You might also find that some 'features' are mitigation for exploits that existed at one time
Exactly what exploits are mitigated by blocking TCP connections, but letting ICMP through just fine? It's not as if worms can't create raw sockets and create packets (with or without the evil bit) as appropriate.
(possibly long before some of the thread participants were in high school).
I'm older than TCP/IP and the Internet. I'd left school well before Windows had heard of the Internet. Haven't got the Unix hacker beard yet though :)