SANS Institute

Information Security Reading Room

Digging Deeper Into TCP/IP

______________________________
Leah Wilson

Copyright SANS Institute 2021. Author Retains Full Rights.

This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express
written permission.
 Digging Deeper Into TCP/IP
Leah Wilson
GSEC Practical Version 1.2f

Abstract

This paper takes a close look at TCP/IP as a reference for the security professional. Its goal is to
consolidate information from numerous sources into one place and to go deeper into the
client/server relationship. It explores basic TCP/IP concepts such as encapsulation, IP and TCP

ts
definitions, client/server connections, and discusses less well-known concepts such as state. It

igh
concludes with an illustration of an entire TCP session (Figure 10), including absolute sequence
and acknowledgement numbers, state identification, and client and server responses.

ll r
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
TCP/IP is an immense subject and this paper is by no means exhaustive, but references are

fu
supplied to help the reader further explore this topic.

ins
Encapsulation

eta
IP is the protocol that transports packets created by the TCP protocol. This TCP/IP combination
rr
allows users to do a variety of things with their computers, such as finger, telnet, FTP, and
HTTP. The TCP/IP combo allows two computers to connect to each other and exchange
ho

information in a reliable way.

ut
,A

TCP packets are encapsulated by IP as part of being sent across a network. David Hoelzer’s
“TCP/IP Primer” (p. 6-7) gives an extremely easy-to-understand explanation of encapsulation.
01

Delivering packets over a network is like delivering the mail. The media for delivering the mail
20

is a combination of letters, envelopes, mailboxes, mail bags, mail trucks, etc. The media for
delivering packets is TCP/IP. TCP packets contain data (letter) that is encapsulated by IP
te

(envelope), which is further encapsulated by the Link layer, e.g. in most cases Ethernet frame
tu

headers (mailbox). Data is put out on the wire (post offices, sorting centers) and forwarded via
routers (mail trucks, planes) to its final destination (receiver’s mailbox), where this process is
sti

reversed – the frame header is removed (the letter is removed from mailbox), the IP header is
In

stripped off (the envelope is opened), and the data is processed by the end application (the letter
is read).
NS
SA

IP

IP (Internet Protocol) was defined in RFC 791 (ISI-IP) as an Internet Layer protocol whose
©

purpose is to get data from a source to a destination. It does this by IP routing. A TCP packet is
crafted on a network and sent out on the wire. IP encapsulates it, and uses the subnet mask to
determine if the packet is destined for a host on the local network (Stevens, p. 44). If it is, IP
uses Address Resolution Protocol (ARP) to look up the Media Access Control (MAC) address of
the destination
Key fingerprint
host =then
AF19
sends
FA27
the2F94
packet
998D
directly
FDB5 to DE3D
that machine.
F8B5 06E4
If theA169
packet
4E46
is destined for a
host outside the local network, IP sends the packet to the next host. This host performs the same
function of checking if the packet belongs to its network and delivering it if it does or forwarding
it if it doesn’t. (Stevens, p. 54-56). Routing schemes such as split horizon and split horizon with

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 poison reverse are generally in place to ensure that the next hop is closer to the destination, not
further (Hedrick, section 2.2.1). Each time the IP packet passes through a hop, the Time-To-Live
(TTL) field in the header is decremented by one. If this field reaches 0 and the packet is still not
at its final destination, it is dropped and an Internet Control Message Protocol (ICMP) error
message is sent back to the sender.

As part of getting data from point A to point B across the Internet, IP has knowledge of how
much data the next hop can accept. IP looks at the Maximum Transmission Unit (MTU) of the
next hop and determines if the packet can be accepted. If the packet is too big for the next hop,

ts
IP will break it down, or fragment it, into several smaller pieces, each of which is encapsulated in

igh
its own IP header. These new, smaller packets are then routed separately. To keep track of this,
IP uses the 16-bit identification field, the 3-bit flags field, and the 13-bit fragment offset field in

ll r
the IP
Keyheader.
fingerprint
When= AF19
a packet
FA27
is fragmented,
2F94 998Dall
FDB5
the fragments
DE3D F8B5 are 06E4
given A169
the same
4E46
16-bit
identification field in their header. The last of the 3-bit flags field is used as the “more to come”

fu
bit – if it is set, there is another fragment to follow this one. The 13-bit fragment offset field

ins
contains the offset of this fragment from the original packet, and the total length field is adjusted
to be the size of the fragment. A good description of fragmentation can be found in Northcutt (p.

eta
36-41) and Stevens (p. 148-149). The point is that IP uses fields in the IP header to reassemble
the fragments at the final destination. rr
Note that the two other bits in the 3-bit flags field of the IP header do have meaning. The first bit
ho

is reserved and always set to 0. The middle bit is designated the “do not fragment” bit – if it is
ut

set, IP will not fragment the packet. If the packet’s size exceeds the MTU of the next hop and
,A

the “do not fragment” bit is set, the packet will be dropped and IP will generate an ICMP error
message (Stevens, p.149, and ISI-IP, p. 25).
01
20

There is no concept of an IP “connection”. IP will send packets from the same application over
any number of routes. It has no knowledge if these packets are related to each other in any way,
te

and it really doesn’t care if the packet gets to its final destination or not. If a packet gets to the
tu

point where it cannot be further delivered, say it cannot find the specified host on the local
network or the TTL in the IP header reaches 0, then IP magnanimously sends an ICMP message
sti

to the last host that sent the packet, but it does nothing further and it does not attempt to resend
In

the packet.
NS

So why is TCP/IP touted as reliable and connection-oriented if the IP part of it is unreliable and
SA

connectionless? That is because the state of the connection is managed by TCP. IP moves the
data from one computer to another, one hop at a time. It doesn’t care if the packet is TCP or
UDP, or if its part of a bitmap image or part of a text document. All IP knows is how to get the
©

packet to its destination. TCP’s job is to know what to do with the packets IP delivers – it knows
source and destination ports, it knows what order the data is supposed to be in, it knows when
data doesn’t arrive and it knows when to resend that data. TCP is the manager that understands
the bigger picture.
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
TCP

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 The Transmission Control Protocol “provides a connection-oriented, reliable, byte stream
service” (Stevens, p. 223). TCP was defined in RFC 793 (ISI-TCP), and is a Transport Layer
protocol that manages the end-to-end communications between hosts.

TCP treats data from an application as a contiguous stream of bytes and groups bytes of data
together into packets (Rodriguez, p. 207). It puts a TCP header on every packet, giving such
information as the source and destination ports and the 32-bit sequence and acknowledgement
numbers. These last two fields are the heart of the connection-oriented nature of TCP, and are
discussed further in the section below.

ts
igh
TCP features error recovery, which means if a packet does not reach its destination, TCP resends
it. Every time application data is put into TCP packets, a timer is set. If TCP does not receive an

ll r
acknowledgement
Key fingerprintfrom
= AF19
the other
FA27 side
2F94of998D
the connection
FDB5 DE3D thatF8B5
the packet
06E4 was
A169received
4E46 before the
timer expires, it resends the packet. Note that TCP resends the entire TCP packet. If IP

fu
fragments a large TCP packet and all but one arrive at the destination, TCP cannot and does not

ins
send only the fragment that didn’t arrive at the destination – it resends the entire TCP packet,
which may be fragmented differently on the retransmission during IP routing (Stevens, 149).

eta
Flow control through the windowing mechanism is another feature of TCP. Each side of the
rr
connection transmits to the other side how much data it is willing to accept at a time, so that one
side will not send more data than the other side can handle. Flow control is not further discussed
ho

in this paper, but good explanations of it can be found in Stevens (p. 280-282) and Rodriguez (p.
ut

208-212).
,A

Now that a general understanding of how packets are transported has been established, the focus
01

moves to looking more deeply into how a TCP connection is established.

20

How do they work together?

te
tu

The postal example of encapsulation applies more to the User Datagram Protocol (UDP) than
TCP. UDP packets are sent out but there is never any confirmation that they reach their final
sti

destination. The sender hopes that the packets arrive but is willing to tolerate some data loss if
In

they don’t. TCP is more reliable than UDP, in that it incorporates the idea of a connection to
ensure that packets arrive properly. A better analogy would be to compare TCP to a telephone
NS

call. The caller (sender) knows when call gets through (the connection is made) and redials
SA

(retransmits) if it does not go through.

Packets may arrive out of order and may travel various different routes over the Internet but
©

because of TCP sequence and acknowledgement numbers, the receiver of the packets knows how
to properly reassemble them when they do arrive.

Connection-Oriented
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
What exactly does “connection-oriented” mean? It means two computers must establish a
connection to each other before they can exchange data (Stevens, p. 229). Who is establishing
this connection? How is it maintained? How is it ended?

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 It may help the reader to refer to Figure 10 while reading the following sections. This figure is
based on an actual TCP connection to a Simple Mail Transfer Protocol (SMTP) server. The
sequence and acknowledgement numbers in the figure were derived from hex output generated
by snort. Snort is a powerful and free intrusion detection system and sniffer. More information
about snort can be found at http://www.snort.org.

A connection is generally described in terms of a client-server relationship. A server computer

has information that it is willing to “serve” to other computers. It contains some software

ts
application that implements TCP/IP, so connections and data requests from other computers,

igh
called clients, can be handled. In order for the client to ask the server for information, it needs to
establish a connection. So the client crafts a TCP packet with the SYN flag set and sends it to the

ll r
server.
KeyThefingerprint
server replies
= AF19byFA27
sending
2F94back
998D
a packet
FDB5withDE3DtheF8B5
SYN 06E4
and ACK
A169flags
4E46
set,
acknowledging that it received the client’s SYN and initiating its own connection to the client

fu
via use of its own SYN. The client then responds with another ACK to acknowledge receipt of

ins
the server’s SYN/ACK, and the famous three-way handshake is complete – a connection is
established. The connection is called “full-duplex”, meaning data is flowing from both the client

eta
side and the server side – it can travel in both directions (Stevens, p. 233).
rr
Sequence and Acknowledgement Numbers
ho

To keep track of the connection, sequence (SEQ) and acknowledgement (ack) numbers stored in
ut

the TCP header are used. When a connection is started, the client sends a packet with an initial
32-bit SEQ number that ranges from 0 to 4,294,967,295 (this is 232 – 1). According to RFC 793
,A

this is supposed to be a random number with a seed based on a 32-bit clock with a low order bit
01

incremented every 4 microseconds. Note that some implementations, such as some Berkeley-
20

derived TCP implementations, violate the RFC and base this number on a low order bit
incremented every 8 microseconds (Stevens, p. 232-233). Generating an appropriate initial
te

sequence number is a difficult task, as acknowledged by Cisco in February 2001 when they
tu

released a software patch to fix a bug in their router’s operating system that allowed the initial
sequence number to be predicted. Improper implementations can allow hackers to predict
sti

sequence numbers and launch session hijacking attacks or close existing sessions. For more
In

information on the dangers of improperly generated initial sequence numbers, refer to Noel’s
Davis’ article “Predictable Initial Sequence Numbers”.
NS
SA

Acknowledgement (ack) numbers give the next expected sequence number. This will be
discussed more in later sections. The important point is that SEQ and ack numbers are the glue
that holds the TCP connection together, and they also allow TCP to properly reassemble packets
©

when they arrive at their destination.

Three-Way Handshake

In the
Key three-way
fingerprint
handshake,
= AF19 FA27
the client
2F94sends
998Da FDB5
SYN packet
DE3Dwith
F8B5an06E4
initialA169
32-bit4E46
sequence
number and with an acknowledgement number (ack) of 0. As an example, taken from Figure 10,
this is represented by:

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 Figure 1

Step 1:
Client SYN (SEQ: 1023645922) a:0 Server

“Absolute” numbers are used for all examples in this paper. These are the actual numbers
(converted to decimal) that were found in the hex output from snort (which uses tcpdump) from
the TCP header’s SEQ and ack fields. The tcpdump program defaults to using “relative”
sequence numbers that are normalized, and this convention is followed in many textbooks.

ts
These smaller numbers are easier to read, but absolute sequence numbers are used in this paper

igh
to prevent confusion converting back and forth from relative/normalized to absolute. The “-r”
option in tcpdump can be used to force a display of absolute numbers. For more information on

ll r
tcpdump,
Key fingerprint
see http://www.tcpdump.org.
= AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

fu
If the server is listening, it responds back to the client with a packet having the SYN and ACK

ins
flags set, and containing its own initial SEQ and an ack equal to the server’s SEQ plus one. (If
the server is NOT listening, the client will get back a message that the connection failed.)

eta
Essentially the server is saying “I ACKnowledge the SEQ you sent me and here’s a SYN of my
own to open my side of the connection”. This looks like:
rr
Figure 2
ho
ut

Step 2:
,A

Client SYN/ACK (SEQ: 2234678799) a:1023645923 Server

Here’s my I see your SEQ
01

initial SEQ! and raise you one!

20
te

This is telling the server that the next packet it sends had better have a SEQ = 1023645923. And
tu

indeed it does, so the client sends back a packet with just the ACK flag set, and with updated
SEQ and ack numbers.
sti
In

Figure 3
NS

Step 3:
SA

Client ACK (SEQ: 1023645923) a:2234678800 Server

Here’s I see your SEQ
©

my SEQ! and raise you one!

The three-way handshake is how a typical TCP connection is started. Notice the relationship of
SEQ and ack numbers:
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 Figure 4
Step SEQ # ack # SYN ACK
1 X 0 1 0
2 Y X+nBytes 1 1
3 X+nBytes Y+nBytes 0 1

“nBytes” refers to the number of bytes sent in the packet’s payload.

ts
The ack number is the next expected sequence number that one side of a connection expects.

igh
Stevens defines it as “the sequence number plus 1 of the last successfully received byte of data”
(pg. 226). During the three-way handshake, since there is no connection yet, no data is yet being

ll r
sentKey
(ackfingerprint
= 0), so nBytes
= AF19= ack
FA27+ 12F94
= 0 +998D
1 = 1.
FDB5
A packet
DE3DwillF8B5
have
06E4
an ack
A169
number
4E46only if the
ACK flag is set.

fu
ins
Data Exchange

eta
Once the connection has been established, the client and server can exchange data. For a telnet
session, this data might be commands issued to a remote computer, say a user logging onto his
rr
work mainframe from home. For HTTP, this could be a GIAC student connecting to a web site
then using FTP (another TCP connection!) to download a primer that explains the basics of
ho

TCP/IP. For SMTP, this could be a user sending email (the application translates the user’s
ut

actions and data into SMTP commands that it sends to the server) or a hacker telnet-ing to port
,A

25 and trying to verify user IDs.

01

When data is sent over a connection, the PSH flag in the TCP header gets involved. In most
20

Berkeley-derived implementations, the PSH flag is set by TCP to signal there is no more data to
follow, i.e. the packet with the PSH empties the buffer of what is being sent (Stevens, p.284).
te

This differs slightly from the original RFC 793 (IIS-TCP, section 3.8).
tu

Payload
sti
In

SEQ and ack numbers are affected by the payload packet size. In Step 5 of Figure 10, notice the
client is sending a “help” command to the SMTP server. It has the ACK and PSH flags set as in
NS

Figure 5:
SA

Figure 5
©

Step 5:
Client ACK/PSH (SEQ: 1023645923) a:2234678893 Server

“help”

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

The server’s response is to send help information to the user (for SMTP, this is a list of valid
SMTP commands). It sends this data in a packet (Step 7), also with an ACK/PSH:

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 Figure 6

Step 7:
Client ACK/PSH (SEQ: 223478893) a:1023645928 Server

A list of SMTP
commands

ts
Notice the numbers in bold. Step 7’s ack is not one more than the last SEQ it received, it is five

igh
more than Step 5’s SEQ. That is because the packet in Step 5 sent the four characters “h”, “e”,
“l”, “p”. The server is acknowledging to the client that it received the four bytes of data by

ll r
setting
Keyitsfingerprint
ack to the=last
AF19successfully
FA27 2F94 received
998D FDB5
byte (1023645923
DE3D F8B5+06E4
4) = A169
1023645927,
4E46 plus one to
equal 1023645928. This jump in ack numbers happens every time a packet contains payload.

fu
ins
The analyst will rarely have to go into this much nitty-gritty detail about payload size. It is much
easier and faster to use tcpdump with relative numbers, which also provides a start and end byte

eta
range of the data and a byte count.

Notice Step 6:
rr
ho

Figure 7
ut
,A

Step 6:
Client ACK (SEQ: 1023645923) a:2234678893 Server
01
20

This has the exact same SEQ and ack as Step 5, but only the ACK flag is set and there is no
payload. In fact, the whole connection has extra ACKs sprinkled liberally throughout. These
te

extra ACKs are the application’s way of continually verifying that the connection is still up and
tu

running, and their use varies from implementation to implementation.

sti

Shutdown
In

There are two ways to shutdown a connection. The brute force method is for one side to abort
NS

the session by setting the RST flag in the TCP header. The connection is terminated
SA

immediately.

The more elegant method takes four steps (Stevens, p.233). In its simplest form, one side (say
©

the server) sends a FIN to indicate it wants to close (Step 35). The client replies with an ACK to
that FIN (Step 36) and sends its own FIN to indicate it wants to close its side of the connection
too (Step 38). The server then responds with a final ACK. In Figure 10, the classic steps in a
shutdown are not followed exactly, with the ACKs of FIN replaced by RST – a hybrid of brute
force
Key
andfingerprint
elegance. =The
AF19
termination
FA27 2F94 method
998DcanFDB5
varyDE3D
by application
F8B5 06E4andA169
TCP implementation.
4E46

The three connection stages – handshake, data transfer, and shut down – are broad concepts
security professionals learn early in their career. But TCP has another higher concept that is not

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 as widely discussed, that of “state”. What is the connection doing? Is it in the three-way
handshake? Is it established, so data can be sent? It is closed or being closed? Depending on
how the client and server applications work, a variety of different situations can occur while a
connection is being established or ended, and the TCP protocol handles these conditions by
keeping track of the state of both connections.

State

Figure 8 – TCP State Transition Diagram

ts
igh
ll r
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

fu
ins
eta
rr
ho
ut
,A
01
20
te
tu
sti
In
NS
SA
©

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46
RFC 793 defines eleven possible states a TCP connection can be in at any given point in the
session (ISI-TCP, p. 20). The client and server each have their own state, and when both are
“ESTABLISHED”, data can be exchanged.

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 Figure 8 illustrates the eleven TCP states, and is based on Figure 18.12 in Stevens (p. 241). It
further highlights the fact that TCP connections are full duplex – the client has a connection
state (black), the server has it’s own connection state (red).

The details of how the connection states change, and what is required for each state change, are
described very well in both RFC 793 (sections 3.2, 3.4, 3.5) and in Stevens, chapter 18.6. They
are presented here as a head’s up to security professionals and/or developers who may one day
have to implement TCP/IP in an application.

ts
igh
To see some of these states “in the wild” the netstat command can be used to monitor
connections on an SMTP server is running. Figure 9 shows such an example. WITH

ll r
PERMISSION,
Key fingerprint
open= AF19
two terminal
FA27 2F94
windows
998DinFDB5
Unix or
DE3D
Linux.
F8B5
In one
06E4window,
A169 4E46
log on to the
same machine as the SMTP server and type “netstat –a -c” to see a list of open ports and their

fu
state. The “-c” option runs netstat continuously. On the other terminal, telnet to the SMTP

ins
server (“telnet your_SMTP_Server 25”). If the server accepted the connection, netstat will show
a state of ESTABLISHED associated with the SMTP server. On another terminal, log onto the

eta
SMTP server machine and do a “kill –9” on the process ID of the connection. (Author’s note: a
“quit” was tried, but then the closing states couldn’t be seen – the connection just disappeared
rr
from netstat’s display.) If the timing is right, netstat may show the connection in FIN_WAIT_1
or FIN_WAIT_2, but most likely it will appear in TIME_WAIT for several iterations before the
ho

connection closes. Figure 9 shows an abbreviated example of this exercise. Unfortunately,

ut

netstat is not fast enough to catch the three-way handshake.

,A

Figure 9
01

> netstat -ac | grep smtp

20

tcp 0 0 localhost.localdom:smtp *:* LISTEN

te

tcp 0 0 devbox-mypc-vm1:32779 devbox-wsrv.devbx:smtp ESTABLISHED

tcp 0 0 localhost.localdom:smtp *:* LISTEN
tu

.
.
sti

.
tcp 0 0 devbox-mypc-vm1:32779 devbox-wsrv.devbx:smtp ESTABLISHED
In

tcp 0 0 localhost.localdom:smtp *:* LISTEN

.
.
NS

.
(killed the telnet process using kill -9 on the PID)
SA

tcp 0 0 devbox-mypc-vm1:32779 devbox-wsrv.devbx:smtp TIME_WAIT

tcp 0 0 localhost.localdom:smtp *:* LISTEN
tcp 0 0 devbox-mypc-vm1:32779 devbox-wsrv.devbx:smtp TIME_WAIT
tcp 0 0 localhost.localdom:smtp *:* LISTEN
©

tcp 0 0 devbox-mypc-vm1:32779 devbox-wsrv.devbx:smtp TIME_WAIT

tcp 0 0 localhost.localdom:smtp *:* LISTEN
.
.
.

tcp 0 0 devbox-mypc-vm1:32779 devbox-wsrv.devbx:smtp TIME_WAIT

tcp Key fingerprint
0 0= AF19 FA27 2F94 998D*:*FDB5 DE3D F8B5 06E4
localhost.localdom:smtp A169 4E46
LISTEN
tcp 0 0 localhost.localdom:smtp *:* LISTEN
tcp 0 0 localhost.localdom:smtp *:* LISTEN

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 Conclusion

This paper has shown how TCP packets are sent by IP over a network to another computer.
Details of how a TCP connection is established, maintained, and terminated have been presented,
along with a brief discussion of TCP state. An attempt has been made to delve into areas of TCP
connections that are not normally presented in an introductory forum.

To conclude this section, Figure 10 is presented to show an entire TCP session between a client
(on port 1042) and an SMTP server, listening on port 25. This session simulates a hacker trying

ts
to identify valid users. As denoted by the key at the bottom of the figure, the bit flags of each

igh
packet that passes between the client and server are shown (e.g. SYN, ACK, PSH, FIN, RST).
The number in parenthesis immediately following the bit flag(s) is the absolute sequence

ll r
number,
Key fingerprint
and the number
= AF19
following
FA27 2F94
the “a:”
998Dis the
FDB5
acknowledgement
DE3D F8B5 06E4
number.
A169Absolute
4E46 sequence
numbers were used for clarity - although the numbers are large, it more simply demonstrates a

fu
connection than relative numbers since the reader does not have to convert back and forth

ins
between absolute and relative. Figure 10 is also included here as a resource for security
professionals, since a more than two-hour search of the internet trying to find an entire TCP

eta
session with absolute sequence numbers came up empty. The commands entered by the
client/user are quoted in light blue, and a summary of the server responses are also in light blue
rr
and in parentheses.
ho
ut
,A
01
20
te
tu
sti
In
NS
SA
©

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 ts
igh
ll r
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

fu
ins
eta
rr
ho
ut
,A
01
20
te
tu
sti
In
NS
SA
©

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.
 References

Cisco Systems Inc. “Cisco Security Advisory: Cisco IOS Software TCP Initial Sequence
Number Randomization Improvements Revision 1.2: Interim”. 7 March 2001.

ts
http://www.cisco.com/warp/public/707/ios-tcp-isn-random-pub.shtml (20 November 2001).

igh
Davis, Noel. “Predictable Initial Sequence Numbers”. 8 May 2001.

ll r
http://linux.oreillynet.com/pub/a/linux/2001/05/08/insecurities.html
Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 (20 November
A169 4E462001).

fu
Hedrick, C. “RFC 1058 – Routing Information Protocol”. June 1988.

ins
http://www.ietf.org/rfc/rfc1058.txt?number=1058 (28 November 2001).

eta
Hoelzer, David. “TCP/IP Primer”. 2001. http://www.sans.org/NO2001/Hoelzer.pdf (28
November 2001). rr
(ISI-IP) Information Sciences Institute, University of Southern California. “RFC 791 – Internet
ho

Protocol – DARPA Internet Program Protocol Specification”. September 1981.

ut

http://www.ietf.org/rfc/rfc0791.txt?number=791 (26 November 2001).

,A

(ISI-TCP) Information Sciences Institute, University of Southern California. “RFC 793 –

01

Transmission Control Protocol – DARPA Internet Program Protocol Specification”. September

20

1981. http://www.ietf.org/rfc/rfc0793.txt?number=793 (26 November 2001).

te

Northcutt, Stephen, Judy Novak and Donald McLachlan. Network Intrusion Detection, An
tu

Analyst’s Handbook, Second Edition. Indianapolis: New Riders Publishing, 2001.

sti

Rodriguez, Adolpho, John Gatrell, John Karas, and Roland Peschke. “IBM Redbooks – TCP/IP
In

Tutorial and Technical Overview”. August 2001. Downloaded PDF file from
http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/gg243376.html?Open (20
NS

November, 2001).
SA

Stevens, W. Richard. TCP/IP Illustrated, Volume 1. Reading: Addison Wesley Longman, Inc.,
1994.
©

Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46

© SANS Institute 2001, As part of the Information Security Reading Room. Author retains full rights.