As some of you may know, I occasionally teach networking to college
students and I frequently encounter misconceptions about some aspect
of networking that can take a fair amount of effort to correct.
For instance, a topic that has come up on this list before is how the
inappropriate use of classful terminology is rampant among students,
books and often other teachers. Furthermore, the terminology isn't even
always used correctly in the original context of classful addressing.
I have a handful of common misconceptions that I'd put on a top 10 list,
but I'd like to solicit from this community what it considers to be the
most annoying and common operational misconceptions future operators
often come at you with.
I'd prefer replies off-list and can summarize back to the list if
there is interest.
I don't know how many times I have "Network Administrators" ask questions
like this...
Speaking in the context of configuring an ipsec tunnel..
"I have my side built. Can you lock your side down to a specific
protocol? Our sets his device to TCP 104. Makes it nice for me when I set
my ACLs."
I am pretty sure that he meant protocol TCP and Port 104, but I do grind my
teeth when I have to go show them that a specific protocol number means
something completely different than what they were asking.
I almost always see someone fill in the 'default gateway' field when
they're configuring a temporary address on their computer to communicate
with a device on the local network.
On the topic of VLANs, it's common to think of 'trunking' and something
that happens between switches. It's hard to get someone to ponder the
fact that trunking isn't an all or nothing concept, and that a server can
be configured to speak vlan.
Confusing ftp, sftp, ftps. Or telnet, telnets, ssh.
Packet loss at hop X in traceroute/mtr does not necessarily point to a
problem at hop X.
BGP does not magically load balance your ingress and egress traffic.
Just because it's down for you, doesn't mean it's down for everyone.
MD5 makes BGP peering sessions more secure. There was a nice recent
NANOG rant on that one.
One of my favorites from corporate america; if you run one application
on a server you can put in that apps port in the firewall and block
everything else and the server will be happy. Evidently folks don't
know servers need to do things like make DNS queries, have remote access
to them, contact domain controllers or software update servers. *sigh*
"Packet loss at hop X in traceroute/mtr does not necessarily point to a
problem at hop X."
Good one.
Also, security as a whole seems to be confusing for folks. They've seen "Firewall" with Harrison Ford and therefore the FW is some secret master voodoo widget that only people from Area 51 can operate. They don't understand "header manipulation" vs "payload".
Switches provide security (by traffic isolation)
DHCP provides security (by only letting in hosts we know)
MAC address filtering provides security (fill in the blanks…)
NAC provides security
NATs provide security
Firewalls provide security
Buying Vendor-_ provides security
ICMP is evil.
Firewalls can be configured default-permit.
Firewalls can be configured unidirectionally.
Firewalls will solve our security issues.
Antivirus will solve our security issues.
IDS/IPS will solve our security issues.
Audits and checklists will solve our security issues.
Our network will never emit abuse or attacks.
Our users can be trained.
We must do something; this is something; let's do this.
We can add security later.
We're not a target.
We don't need to read our logs.
What logs?
(with apologies to Marcus Ranum, from whom I've shamelessly
cribbed several of these)
Use other VLANs other than vlan1. Disable vlan1. Disable ports (physical
and logical) that aren't in use. Encrypt your passwords in your config, etc
etc etc...
This thread is about misconceptions. What I said was a common
misconception that "all ICMP should be blocked for security reasons".
In reality, some kinds of ICMP are REQUIRED for proper functioning of
an internetwork for things like Path MTU Discovery (ICMP Fragmentation
Needed/Packet Too Big). Other kinds of ICMP are good to allow for
being nice to the users and applications by informing them of an error
immediately rather than forcing them to wait for a timeout (ICMP
Destination Unreachable).
(1) Block all ICMP (obviously some are required for normal operations,
unreachables, pMTU too large/DF set, etc).
(2) Block certain ports (blindly, w/o at least "established") taking out
legitimate ephemeral port usage.
(3) Local uRPF is unnecesary (or source spoofing mitigation in general)
(4) Automagical things are necessary (Microsoft proprietary, UPnP, Apple
Bonjour, mDNS, etc)
(5) WAN routing to multiple providers will automagically load-balance
automagically. or for that matter...
(6) IGP routing across multiple paths will automagically load-balance
automagically. Or for that matter...
(7) Port-channel (link aggregation) will load-balance automagically.
(8) Connectivity/throughput issues are always local or first-hop. (We
have a gig connection, why am I not getting a gig throughput)
I'm sure there are more, but those were at the top of my head
By your classful addressing example, it sounds like these students are
what most nanog posters would consider to be entry-level.
RFC1918 is misused a lot by entry-level folks, most seem not to know
about 172.16.0.0/12
I think students should be able to learn how "traceroute" actually
works, which I have found, is a lot easier to teach as a conceptual
lesson than by just telling them "maybe the problem is in the return
path" without giving them any understanding of how or why.
MTU, Path MTU Detection, and MSS
NxGE isn't a serial 4Gbps link, and why this is so important
On the other hand, more than half of the CCIEs I have worked with are
clueless about all of the above. :-/
