Well, I had to try that right away and sent some pings:
muenster:~# ping -s 1400 www.strato.de PING www.strato.de (192.67.198.33): 1400 data bytes 1408 bytes from 192.67.198.33: icmp_seq=0 ttl=245 time=159.6 ms 1408 bytes from 192.67.198.33: icmpseq=1 ttl=245 time=157.3 ms 1408 bytes from 192.67.198.33: icmpseq=2 ttl=245 time=327.5 ms 1408 bytes from 192.67.198.33: icmpseq=3 ttl=245 time=160.3 ms 1408 bytes from 192.67.198.33: icmpseq=4 ttl=245 time=159.0 ms --- www.strato.de ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 157.3/192.7/327.5 ms muenster:~# ping -s 1500 www.strato.de PING www.strato.de (192.67.198.33): 1500 data bytes --- www.strato.de ping statistics --- 8 packets transmitted, 0 packets received, 100% packet loss
What's happening here? I'm sending packets with 1400 byte and 1500 byte lengths. The 1500 byte ones are being nicely fragmented at our router - a Telekom router with a DSL fixed connection - and sent as fragments:
goggle# tcpdump -i ppp0 icmp tcpdump: listening on ppp0 09:29:01.223186 62.153.201.130 > 62.226.72.1: (frag 33019:28@1480) 09:29:01.316521 62.153.201.130 > 62.226.72.1: icmp: echo request (frag 33019:1472@0+) 09:29:01.316707 62.153.201.130 > 62.226.72.1: (frag 33019:8@1472+) 09:29:01.317017 62.226.72.1 > 62.153.201.130: (frag 14273:36@1472) 09:29:01.317148 62.226.72.1 > 62.153.201.130: icmp: echo reply (frag 14273:1472@0+)
For example, that's what it looks like when I ping my machine at home. What does that point to? I'd wager that Strato has a firewall strategy where transparent firewalls sit in front of the Strato servers. And fragments are apparently getting lost there. It's possible they do this because TCP/IP fragments are often used in attacks, because fragments with incorrect header data tend to crash TCP/IP stacks. Still, I'd say that's a clear configuration error on Strato's part. At least it smells strongly of that...