
Falsehoods programmers believe about networks - kiyanwang
http://blog.erratasec.com/2012/06/falsehoods-programmers-believe-about.html#.WA2xdpMrJ-V
======
rvense
It'd be great if someone wrote three lines explaining why one would believe
each of those, why it's wrong, and why that's important.

~~~
Vendan
I tried to write up a little about the ones that I know something about, here
it is:

    
    
      Data on the network cannot be altered.
    

False, if something goes through another device, it can be altered. Important
because, well, man in the middle.

    
    
      Encrypted data on the network cannot be altered.
    

Same as the above. Harder, but still doable

    
    
      Data cannot be accidentally corrupted, because TCP has checksums and Ethernet has CRCs
    

This is about like saying "only 1 bit can be flipped at once, so parity
checking will always catch it"

    
    
      If it's inside my perimeter firewall, that means I have total control over it (@armorguy)
    

Similar to the top ones, still harder, but it's a weak point if someone gets
into your perimeter at all.

    
    
      Packets arrive in the order in which they were sent.
    

Completely false, though TCP will reorder them back to the original order for
you.

    
    
      If you can't ping the target, then it doesn't exist. (@jjarmoc)
      

Trivial to make a host not respond to pings

    
    
      If you can ping the target, then it does exist.
      

Again, trivial to make a router or any device respond to pings for a lot of
IPs

    
    
      TCP RSTs come from end-nodes.
    

Devices in the middle sending RSTs is really common, google "comcast rst
packets"

    
    
      Bytes must be "swapped" from the network byte-order to the host CPU byte-order.
    

IP/TCP and such protocol bytes must be swapped. The only thing that cares at
the application layer is the application code, it can just say "everything is
little endian" and be done with it.

    
    
      It's an internal web app -- outsiders won't be able to discover where it is (@biosshadow)
      

if this is about a "exposed under an obscure name", the tools like fierce can
probe for it. If it's exposed to the internet at all, consider it under attack
at all times.

    
    
      The DHCP address will be the same after a reboot (@shewfig)
    

Not necessarily true, depends on the DHCP server and such.

    
    
      The DHCP address will remain the same until the next reboot.
    

You get a lease time, OBSERVE IT. Don't just keep using it cause you say "this
is mine still!"

    
    
      Well, it'll last a long time between changes
    

One culprit is coffeeshops, there have been reports of coffeeshops with 30
minute lease times. I've seen cable modems hand out 30 second leases, but that
was when it was still trying to connect to the cable side, so it wanted the
computer to keep checking back

    
    
      The DHCP server and local router are the same (@schrotthaufen)
      

Not at all a requirement, and would cause your packets to go off into nowhere
if you tried to rely on it.

~~~
dllthomas
> The only thing that cares at the application layer is the application code,

True, but...

> it can just say "everything is little endian" and be done with it.

... doesn't quite follow. If you're blitting integers directly, your code will
break on either a big- or little-endian boxes. Better to pick a standard
encoding and always serialize/deserialize properly whatever that means. That
standard encoding may be little-endian (maybe better than big-endian - such
systems are overwhelmingly more common on the desktop/server) or may be some
packed representation. But ideally you could change the representation without
changing application code other than the serialization/deserialization itself
(which may well live in a library).

~~~
saurik
I had taken that to read that there are programs in the wild that assume hosts
are little endian and always "swap" bytes as opposed to converting between the
two orders (which might be a no-op on a big endian system).

~~~
dllthomas
Yeah, that's probably the case, and quite possibly what was intended. I think
my elaboration deals fine with that case too, though.

------
angry_octet
Also:

\- MAC addresses are unique.

\- LANs won't be bridged.

\- Spanning tree will converge quickly.

\- Quickly enough that it will beat BIOS getting to DHCP for netbooting.

\- There will only be one circuit in the network so you can disable spanning
tree.

\- The path MTU will be at least 1500 (or 9000, or x).

\- Path MTU discovery will work.

\- Packets with DF bit set won't be fragmented.

\- ICMP won't be dropped.

\- Network circuits will be the same path in both directions.

\- There will be one NIC / a default route.

\- The domain name 'localhost' will always resolve to localhost, or 127.0.0.1.

\- A DNS responder exists on the network.

\- It is a good idea to try to resolve IP addresses as names.

\- A device will use IPv4 by default (some systems opportunistically look for
A and AAAA addresses and try both).

\- All networks have a path to the internet.

\- There will be no proxy required, or

\- The proxy won't require a login, or

\- The proxy credentials won't have a backslash.

I'm diverging higher up the stack at this point so I'll stop.

~~~
nieve
> MAC addresses are unique

Or at least they're unique on a single machine... except for the various OSes
and hardware platforms that have deliberately made all MAC addresses the same
for a given machine.

~~~
tonyarkles
Way back in the land before time, I acquired a number of old 486s and ISA
NICs. Being a good Slashdot nerd, I of course thought "lets make a Beowulf
cluster of these!"

So I've got the cluster set up, and it's mostly working. There's two nodes
though that behave funny. Imagine my surprise when I try pinging one of them
and get two responses per ping! Sure enough, two ISA NICs pulled randomly out
of a box of garbage indeed had identical MACs. I learned a lot about IP and
the MAC layer from that project!

------
asmithmd1
One that has bitten me:

"ACKs come from an end node"

Cellular carriers will ACK a packet destined for a device on their network
before they have actually delivered it if they have the device registered and
are confident they can deliver the packet "soon." I have seen packets happily
being ACKed that are destined for a device that I just powered down. About a
minute later the carrier starts telling the truth, but now you have no idea
what actually got through to your device.

------
chris_wot
The IP address returned from each hop on a traceroute is from the actual
device that the ICMP packet was originally sent to.

~~~
gruturo
> The IP address returned from each hop on a traceroute is from the actual
> device that the ICMP packet was originally sent to.

Actually - the return packets are ICMP (TTL expired in transit), but the
packets you send, _by default_, are UDP.

Traceroute can indeed be instructed to use ICMP though, but it's not the
default on an any OS I know.

~~~
chris_wot
I knew someone would say this.

Windows not uses ICMP by default, but there is no switch to use UDP packets
instead of ICMP packets.[1]

Yes, I'm well aware that UDP is the default on most Unix-based systems.

1\. [https://technet.microsoft.com/en-
us/library/cc940128.aspx](https://technet.microsoft.com/en-
us/library/cc940128.aspx)

------
flukus
I would add "local networks are fast":

[https://people.eecs.berkeley.edu/~rcs/research/interactive_l...](https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html)

------
bogomipz
Why is this listed under falsehood?

"Bytes must be "swapped" from the network byte-order to the host CPU byte-
order."

Don't PowerPC and Sparc hardware require byte swapping(depending on what
endian mode they are in)? Or am I misreading this?

~~~
angry_octet
Well, NBO is big endian and PPC/Sparc/MIPS were usually BE in servers, now in
routers and TVs, and LE in printers... Though POWER8 switched to LE.

So you can (and I have) write programs for these BE systems that completely
neglect to use swizzling. You will also see code that doesn't use the
swizzling macros (htons, ntohs, etc) because they 'know' the packets need to
be swizzled and they do it always, when they shouldn't on some architectures.

------
jjp
Seems to have missed the falsehood that everything on the network will respond
really quickly and so it's fine to have loads of blocking calls on starting an
application

------
richm44
A few more:

\- Localhost is 127.0.0.1

\- A TCP SYN will also always result in a SYN-ACK

\- Ok, a SYN-ACK or a RST

\- Ok, ok, an out-going TCP packet will always result in a TCP response

~~~
chris_wot
"Nobody will ever be stupid enough to stick debug data in TCP RST payloads on
a production system"

[https://support.f5.com/kb/en-
us/solutions/public/13000/200/s...](https://support.f5.com/kb/en-
us/solutions/public/13000/200/sol13223.html)

