//Cyber Battlefield/Networking – Ports

This lesson looks at the nature of network connections. We'll introduce the concept of ports, which help connect network packets to particular software and services. Then we'll discuss two protocols, TCP and UDP, that define how network packets move from one host to another.

Ports

It's worth noting that you can specify what port you want your browser to use to contact a web server by putting a : then the number after the domain name (or IP Address). For example
http://www.usna.edu:80
tells the browser to use port 80 (which it would've done anyway), while
http://www.usna.edu:53
tells the browser to use port 53. This request will fail, of course, because USNA's web server isn't listening on port 53, it's listening on 80. DNS name servers listen on port 53.
There is nothing preventing a server from listening on a non-standard port and providing the service from a non-standard port. Listening on non-standard ports just makes it harder for hosts on the network, or public Internet, to find and use your services.

Listing Ports In Use

Shell commands resource. netstat requires an Administrator shell.

Transport Layer: TCP and UDP

    We will discuss all the "layers" of the Internet and how they interact later. The top layer in our model, the Application Layer, is the one we interact with as users; it's where programs like web browsers operate. For the rest of this discussion, we'll visit the "Transport Layer", which resides one level below the Application Layer, and helps hosts communicate with other hosts.
  • There are two basic Transport Layer protocols: TCP (Transmission Control Protocol) and UDP (User Datagram Protocol).
  • TCP is like communicating via the phone: you establish a connection, which requires knowing the phone number (IP Address), but after the connection is made, you communicate through the connection and, as long as you don't hang up, you don't have to redial the number. Each word you utter (packet you send) makes it to the listener on the other end in the same order you said it.
  • UDP is more like communicating via the mail: there is no connection, so every time you send a letter you have to provide the address (IP Address). Letters get lost from time to time, and a letter you sent Tuesday may arrive before a letter you sent Monday.
  • Where these analogies break down, however, is that UDP (unlike the mail compared to the phone) is fast, much faster than TCP.
  • TCP - The Transmission Control Protocol is a connection oriented service that works in tandem with IP to provide services such as reliable transmission, error detection, flow control, and congestion control. To begin communication, a "handshake" takes place (a few packets are exchanged) to establish certain parameters. Every packet gets a sequence number, which helps allow for out-of-order arrival of packets. Think of TCP when you need perfect communication or data transfer.
  • UDP - The User Datagram Protocol is a connectionless protocol, so there is no "handshake" between hosts. UDP is not a smart protocol, so it provides far fewer features. However, this protocol is much more lightweight than TCP because it has to check far fewer details with each packet. Think of this protocol for applications that are temporal in nature, like Voice Over IP (VOIP). Would you notice if a few packets were dropped in the middle of a UDP phone conversation? What would happen to the conversation if it was implemented using TCP and you had to wait for packets to arrive out of order?

A Tool for Transport-Layer Communication: netkitten (nk)

netkitten (shell command is nk) is a very flexible and powerful tool. It can be used in mode similar to a "client" or a "server".
  • In the "client" mode of netkitten, you give it an IP Address (or symbolic name that it will resolve for you via DNS) and a port number, and whatever you type into after pressing enter gets sent to the given address and port using TCP over IPv4.
  • In the "server" mode of netkitten. you give the -l option (listen) and nk then acts like a server, "listening" for a connection request, accepting the first one it receives, then echoing whatever gets sent to it to the screen, and taking whatever gets typed on the screen and sending it to the client whose connection request it accepted.
  • The diagram below illustrates what commands users at two hosts would have to give to make a TCP connection with netkitten.
     
    Host 10.53.88.12
    (server: listens (-l) for connections on port 42123)
    > nk -l 42123
    Host 10.53.12.94
    (client: connects to 10.53.88.12 on port 42123)
    > nk 10.53.88.12 42123
     
  • UNIX also has a netkitten "like" program called netcat, which uses the nc command instead of the nk command. Actually, netcat was the original program written for UNIX and was then ported to Windows. For this class we use a slightly different version named netkitten. The UNIX netcat (nc) and the Windows netkitten (nk) are for the most part identical.
    For more information on netcat (nc), see the manual page. To do this, open up a rona shell and type:
    $ man nc
    Note: the "server" command on Host 10.53.88.12 must be given first! Otherwise, when the client calls there's nobody home!
  • netkitten with the -u option (UDP) uses UDP instead of TCP. Since this is connectionless, the server version accepts datagrams from any and all who send them, rather than making a connection with one client. As another consequence, the UDP server doesn't exit just because one of the clients exits.
With netkitten, we as users can act like Application Layer programs. Like most Application Layer programs, we require that the Transport Layer provide us with services, which means at a bare minimum that we decide whether we want UDP or TCP. There are lots of interesting demos and activities we can do that demonstrate how TCP and UDP work and how they differ from one another; especially if we are using protocols that are text oriented, easy for humans to create and read, like HTTP.