TCP/IP
by Nathan Dorfman
Basically, How Does TCP/IP Work?
TCP/IP is most famous for its role in the global network known as the Internet. It also has useful applications in LANs. TCP/IP is able to run on many, often incompatible, network hardware types, which can be hooked together using this protocol suite.
Since you cannot hook an Ethernet card to a Token Ring interface with a single cable and expect things to work, how can TCP/IP achieve this inter-networking scheme? Well, consider the following example:
If A wanted to send a packet to C, it could not have had a direct link with C, because the two network cards would not know how to talk to one another. However, since it shares an Ethernet network with B, it can send it to B. B, in turn, has another interface - which is a Token Ring. Thus it can forward A's packet to C. B is a router, or gateway. A and C are hosts.
Much of the Internet is linked by high-speed telephone cables. However, people's networks aren't built out of phone cable. Consider an ISP:
In this example, we have the LAN of an Internet Service Provider.
Host A is able to accept a dial-up connection from a home user. Once that connection is established, it becomes a network link; indeed it is technically a network interface like any other. If the home user wants to send a packet to 204.141.125.38, which is part of the Internet, his TCP/IP software will first forward the packet to A over the PPP line.
A will forward it to C. C will then forward it over its T1 line, where it will be forwarded to another gateway, and so on until it reaches its destination.
To see this in action, use the traceroute command (UNIX) or tracert (Windows):
This is the output of a traceroute from a host on a PPP connection.
The first stop of a packet headed for inch.com will be pm1.qed.net, which is my ISP's dial-in computer. Since it's the only computer I'm connected to, any packet headed for anywhere will have to pass through this router first - woe to me if it ever goes down.
We can probably determine that Nyack-1.qed.net is my ISP's gateway to the world - rather, in this case, to new-york.net which is a larger network that connects various ISP's in the New York City area.
From there it heads onto UUNET (137.39.*.* is part of the UUNET/AlterNet network, which services parts of the Internet's backbone). From there, to inch.com.
Note though that the route back from inch.com to me can by all means take a different route:
(Note: You can't just request a traceroute from a remote host. Either you or someone else has to execute the traceroute command, or there has to be a daemon which accepts requests, and executes it. I doubt one exists.)
The packets first get routed to router1 (.inch.com) and from there, straight to the backbone. It is passed along until it reaches one of new-york.net routers, which forwards it to another, which forwards directly to pm1.qed.net, which is connected by PPP to me, so it can just send the packet over the phone line and it arrives safely at my house.
Routing tables at each router/host control where packets go. At a home computer connecting to a single PPP connection, routing tables are unimportant because there's only one place they can go (lie - it can go to loopback: 127.0.0.1) in order to get someplace.
However, at pm1.qed.net, it can go many ways since it is connected to many hosts. The routing table lists where to forward packets headed for each destination. If a packet is forwarded to the wrong gateway, such that the route from there would be either inefficient or impossible, the gateway sends an ICMP_REDIRECT, to tell the sender to modify its routing table. If, by error, a host gets a packet not destined for it, it doesn't send a redirect. It simply trashes the packet.
What Are the TCP/IP Protocols?
The TCP/IP suite has many protocols which are used for various aspects of its responsibility. This is summarized in the OSI 7-Layer Model, but better summarized in Craig Hunt's 4-Layer Model:
Application Layer: Programs and users using the network
Transport Layer: Host-to-host connectivity
Internet Layer: Low-level inter-network delivery
Physical Layer: Hardware deliveryThe Application Layer is programs using the network. This may be an FTP client or perhaps a web browser. The Transport Layer handles end-to-end connectivity, and includes the protocols TCP and UDP. TCP delivers a pseudo-connection-oriented link. The client requests a connection using a SYN packet, the server responds with a SYN+ACK (acknowledging the client's request, and requests a connection, forming a two-way/duplex connection).
Once the client responds with an ACK, data can be sent. A UDP connection, on the other hand, is unconnected. This is most useful for query-response type services. For example, the DAYTIME UDP service waits for any UDP packet, and sends the current time back in another UDP packet. The Internet Layer provides the router-to-router-to-router-to-endpoint path. It also provides the ICMP error messages. The Physical Layer involves sending the packets over an Ethernet connection, PPP link, Token Ring, etc.
When the application wants to send something across a TCP connection or through a UDP socket, it notifies the system of its intent to do so. The TCP or UDP then tacks on an appropriate header and passes it down to the Internet Layer. It tacks on an IP header and sends it to the Ethernet card or the PPP driver which tacks on an Ethernet or PPP header and sends it on its way. Note that, for example, to IP, the TCP header is just data.
What Are Some Vulnerabilities of TCP/IP?
Consider this setup:
In this setup, A is connected to the Internet through B, which is most likely his ISP's router. Note that he has a PPP connection, usually not more than 28.8 or 33.6 kbps (and sometimes 56.6 kbps).
C on the other hand, is connected to the Internet with an ISDN line. (The break in the connection between B and C means that the connection doesn't have to be direct. This can go from the other side of the Internet.)
Picture what happens if C starts sending large packets (let's say his ISDN line can handle 20 of them per second) to A. They will first have to arrive at B, and will be stored in its queue as it forwards them to A.
However, the PPP line will only be able to handle four of these packets per second. More and more packets arrive from C, but B can't send them to A that quickly.
Eventually, B's queue will begin to fill up, and it will send an ICMP_SOURCE_QUENCH to C.
However, UDP sockets cannot receive ICMP messages by default, unless they've been specifically bound to a remote host, for a special reason: if the socket isn't bound to any host, it may be sending different packets to different hosts.
On receipt of a SOURCE_QUENCH it will not know what to do. Thus, once B's queue is filled up, it won't be able to store messages for A, or from A, or to/from any other of its customers. This is often used in IRC wars because ircd will disconnect the person if they don't ping.
A similar affect can be achieved from PPP lines if many people do it at once.
SYN flooding is very simple - all it really is is sending repeated SYN packets with the source address spoofed. The victim will try to establish a connection with the fake address you put - and eventually crash.
Nuke is the lamest of all. It attempts to cut the connection between two hosts, such as an IRC client and server, or a lengthy FTP download, by sending an ICMP_HOST_UNREACH with the source spoofed to that of the server, to the client. The client software will theoretically believe that the server has crashed and end the connection. Most routers are smart enough now that this can be avoided. If yours isn't, upgrade your software.