Today we’ll learn about two brothers: TCP and UDP.  Chances are, you have never heard of these guys.  Remember in a previous blog, we talked about how computers communicate with each other on a network: an IP Address (leaving off the other network protocols like Appletalk, IPX, and similar irrelevant inhabitants on the Isle of Misfit Protocols).  On your Windows computer, deep in the bowels of your network settings, it lists how your computer will talk to other computers.

To see this yourself, click Start, search for NCPA.CPL, then press enter on your keyboard.  This will send you to the Network Control Panel Applet where all your cool Network stuff is set up.  Right click one of your Network adapters, and select Properties.  Now you can see all the protocols and what not that you actually are using to communicate with other computers.  Pretty hefty stuff, right?  And there, in all its glory, is our golden Wonka ticket: Internet Protocol Version 4 (TCP/IPv4).  Select that bugger, and click Properties.

Pretty unimpressive, eh?  Chances are, it’s set to get everything from DHCP.  That meaning that your computer yells at the top of its lungs like a fussy toddler at naptime “I WANT TO LOOK AT LOLCATS!!!!1111” and some other device on your network (most likely your virtual Hagrid router) will give your computer an IP Address, Subnet Mask, Default Gateway, DNS servers, and other fun stuff we don’t really need to get into right now.  Your router is acting as a DHCP server – it hands out network information so computers can talk to each other.  It’s a rather kind thing to do.

So anyhow, we know all about IP Addresses, which use the IP protocol.  But what on earth is that other part?  TCP?  Eh?  What’s that?

Juggling for Fun and Profit

How many of you can juggle several things at once?  Do you trip while trying to walk and chew gum?  Can you multitask?  I sometimes can, but often I…. SQUIRREL!

So your computer can obviously multitask, doing several things at once.  One way your computer accomplishes this is by using ports.

Let’s go back in time to an earlier blog post analogy about your home network being a castle, and the Virtual Hagrid router being the big strong gateway to the outside world.  Now let’s take that analogy a tad deeper: that big strong gateway has 65,535 little keyholes on it, each numbered from 1 to 65,535.  And let’s say that only specific keys fit in each keyhole.  You want to surf the web?  That picture of LOLCATS can only come back inside your castle in keyhole number 80.  In fact, all web surfing can ever only come in that keyhole.  You want to do a DNS lookup to determine that google.com is actually 74.125.228.70?  That name query can only come back into your castle through keyhole number 53.  And so on, and so forth.

Now I’ll geek out on you.  Those keyholes in your castle door are called ports.  And specific kinds of traffic (called packets) come in on certain ports.  They always come in on those specific ports, it’s a universal standard.  There is a group of geeks who determined in RFC 6335 that port 80 would henceforth and forevermore be dedicated for HTTP Web traffic.  Oh you’re fancy shmancy and use your computer for encrypted web surfing when you go to your bank’s website?  Well encrypted web traffic (HTTPS) rides port 443.  DNS name lookups?  That is port 53.  And the list goes on and on and on.

Now here is where it gets a smidge complicated: for each keyhole port, there are two possible keys, belonging to two brothers.  We’ll start with the first brother.

The Respectable Responsible Brother

Our first brother is the Albus Dumbledore of the packet family.  We’ll call him TCP.  TCP seems to care an awful lot about his packets getting where they are supposed to go, in the correct order, and in a timely fashion.  If something doesn’t seem to be just right, TCP follows up to make sure it’s done.  His packets are delivered on the proper port number and he follows up to make sure they got there.  If they weren’t delivered on time, he sends them again and again until he receives word that they got there.  Sure the packets take a little longer as you have to reply to every single one that they were received, and have to wait for undelivered packets to be sent again.  But you are in good hands with the Albus Dumbledore of the packet world.

The Deadbeat Dunderheaded Brother

Our second brother is the Aberforth Dumbledore of the packet family.  We’ll call him UDP.  UDP doesn’t give a flying left handed goat poo about whether or not you got his packets; he just sends them off and goes about his business once they are gone.  If you don’t get them, oh well.  You probably didn’t need them anyway and if you did need them, well tough.  If you did get the blue key packets, they came in quickly.  You didn’t even have to respond that they were delivered.  They just show up, or if they don’t, oh well.  That makes for a faster delivery, though there is no guarantee you actually get them.

So now let’s bring it together – we have a bunch of ports on the castle door, and certain kinds of packets can only come into certain numbered ports.  TCP packets come into specific port numbers, and the sender follows up to make sure you got them before sending you more.  UDP packets come into specific port numbers, and they either show up or they don’t.

To use a big fancy twelve-dollar nerd word, TCP packets are considered connection-oriented, meaning there is a guaranteed receipt and the sender retransmits them if you don’t acknowledge their receipt.  Behind the scenes, there are funny words like “SYN” and “ACK” that instantly conjure up images of Bill the Cat.  It’s pretty comical until you realize you’re talking about packet data, then you come back to earth and feel sad inside that you are such a nerd.

The twelve-dollar nerd word for UDP packets is connection-less, meaning there is no verification of receipt.  They either show up or they don’t.  As such, they are faster packets without all the verifications.

Why On Earth Do We Even Care?

Let’s keep in mind that our ultimate goal is security and content filtering, so let’s boil this one down a bit.  It’s simplistic to say that to gain access to our castle, one must make it across the moat and through the front gate.  The reality is, that front gate has its own security, and only certain kinds of traffic can come in certain little holes in the gate.  If you come up the front door and say you are Web Traffic on TCP Port 80, you MUST come in that specific port.  This is to our advantage – we can then watch that port very closely, and monitor it more severely than we would other ports.  We could even just block up that port so nothing gets through.  And wait for it:

Key Concept

We can instruct our Virtual Hagrid Router to only allow certain traffic in on that port, while blocking other traffic that we don’t want.

I cannot understate the importance of this concept.  We’ll go much deeper into this soon, I promise.  But let’s get practical on this – we could only allow Web Traffic (TCP Port 80) from certain websites that we determine as “good”.  And we can then say that all other traffic gets tossed into the moat where nasty green crocodiles gnash their pointy teeth.

Or let’s use another fancy term we covered in a previous blog: we could only allow UDP port 23 DNS traffic back into our castle if it comes from a specific DNS server like OpenDNS, and all other DNS traffic winds up in the moat.

OK, Professor Plum, what is OpenDNS?

Ah glad you asked.  OpenDNS is a free service that allows the filtering of DNS traffic based on content.  You could use OpenDNS to only allow DNS lookups that are considered “safe” while dropping any traffic determined “adult” or “gambling” or “hacking” (though why would we want to!?).  OpenDNS is one of our main ninja weapons to keep our homes safe.  And on that cliffhanger of a concept, I’ll close.  Coming soon: more on OpenDNS, as well as how to play around in your Router without blowing crap up.