Internet DRAFT - draft-brugger-connection-metrics
draft-brugger-connection-metrics
Network Working Group S T. Brugger
INTERNET-DRAFT: draft-brugger-connection-metrics-01 UC Davis
16 August 2006
Definitions for TCP Connection Metrics
Intellectual Property Notice
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Status of this Memo
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Draft expires on 16 February 2007.
Comments are solicited and should be addressed to the author(s) at
<zow@acm.org>.
Abstract
Numerous metrics, or features, have been used to describe TCP
connections. These features are frequently of interest to the network
intrusion detection community, and occasionally the network
engineering community. While researchers may understand these terms
when used by others, there are no formal definitions of these terms
such that two researchers looking at the same connection will
necessarily calculate the same values for all the metrics. This paper
will propose a potential set of connection metrics with formal
definitions of each.
Brugger [Page 1]
Internet-Draft TCP Connection Metrics 16 August 2006
1. Introduction
Researchers frequently need to describe TCP connections, using
metrics from the widely accepted ``Duration'' to the less commonly
used, yet still understandable ``URG packet rate'', through more
obscure measures such as the ``Wrong packet resend rate''. The
advanced network intrusion detection community, which typically uses
machine learning to attempt to identify malicious or anomalous
connections, will use these metrics as the machine learning features
(or attributes) that their methods train and recall on [Axelsson00].
These metrics are also used by the network engineering community;
however, in this arena, researchers tend to focus on the effects of a
single metric (such as the ``Interpacket latency'') on a device or
network stack, at a time [Leland94, Paxson95, Racz03]. As such, the
use of metrics tends to be better defined.
It is important that researchers agree on the definitions of these
terms. This is somewhat easier in the network engineering community,
where an assumption is typically made that TCP connections will
behave to specification, and that misbehaviour is the result of
correctable deficiencies in network stack implementations, or
unforeseen interactions as networks scale in size. The lack of
definitions is more problematic in the intrusion detection community,
as attackers actively create connections that are outside protocol
specifications in an attempt to break stack implementations, such as
Christmas Tree Packets [Miller00]. Since this misbehaviour may occur
on such a small scale, relative to the total amount of traffic on the
network, a difference in definitions may cause one researcher to
measure a value of 0.01 for a metric, while another researcher
measures a value of 0.02 -- double the measurement of the first
researcher.
This paper will begin by providing a definition of a TCP connection
-- as that alone can account for differences in how metrics are
measured. We will then provide a list of first-order network metrics,
with definitions of each. While the intrusion detection community
frequently uses second-order (or calculated) metrics, such as ``The
number of new connections in the last n seconds'' [Lee98, Lee99a,
Lee99b, Lee00a, Lee00b], we will not delve into definitions for
those, as they should follow directly from the definitions we do
provide.
2. Definition of a TCP Connection
We will begin with a very basic definition: A TCP Connection is a set
of packets between a pair of sockets (Host IP and port pairs). Since
the same pair of sockets may be used for multiple connections, this
section will further refine this definition.
Brugger [Page 2]
Internet-Draft TCP Connection Metrics 16 August 2006
In a perfect world, the definition of a TCP connection is easy: It is
all the packets starting with the initial SYN packet, up to and
including the ACK of the second FIN [RFC793]. Of course, the RFC
acknowledges that we don't live in a perfect world, and it defines
how hosts should act in a variety of situations. It is easy to extend
the above definition to cover some of these, for example, we can say
up to and include in the ACK of the second FIN, or a connection RST
packet, but do we count a SYN packet in the middle of the current
sequence as part of the current connection, or as a separate
connection? Do we count a non-SYN packet that is not part of an
ESTABLISHED connection to be part of a connection at all?
We should begin by defining our viewpoint: we are assuming that we
are passively viewing the connections as a third party. We might be
observing the connections from a network edge-point, such as a
firewall or router, or we might be collecting network dumps on one of
the hosts via a user-level utility such as tcpdump [TCPDUMP] or Snort
[Caswell04]. In any case, we do not have access to the state
information of either of the hosts in the connection. Hence, we can
not know that the connection is in the ESTABLISHED state, instead we
must deduce it. Furthermore, we may only have a portion of the
connection: we may have begun observing the connection after it was
already established, or our observation may end before the connection
is complete.
To that end, we always require a SYN packet to begin a connection. If
we don't see a SYN, and we don't have a record of the connection
already, we must assume that the connection was already begun before
we started observation, hence we do not have a complete record of the
connection, and we will not attempt to record metrics on it. It is
true that an attacker may attempt to attack the network stack by
sending in a malicious packet (for instance a ``Christmas tree
packet'', which has all of the TCP flags set) without having already
established a connection, however this is not a connection, and any
desire to include it in overall network characterization should be
done separately from the connection metrics.
Once we see the initial SYN packet, we include all packets between
the source and destination sockets in the metrics for that
connection. This includes packets that are invalid for whatever
reason; for instance packets with incorrect checksums, or out of
sequence packets.
A connection ends when:
- Both sides have send a FIN, which has been acknowledged.
- One side sends a RST
Brugger [Page 3]
Internet-Draft TCP Connection Metrics 16 August 2006
- A packet goes unacknowledged for more than TIMEOUT seconds,
where we use the 300 second TIMEOUT suggested by RFC 793.
- There is no activity on the connection for more than TIMEOUT
seconds.
The first two are fairly straight forward. When we combine our
definition of when a connection begins with the third, it brings with
it an important implication: even if a connection never reaches the
ESTABLISHED state on the hosts, we include it as a connection in the
connection metrics. This means that if a firewall blocks the
connection, we will still record it as a connection consisting of one
packet. If the source tries to resend the SYN packet, lets say twice,
then we'll record it as a connection with two duplicate packets. The
fourth definition is really just a generalization of the third,
however we call it out separately as we expect it will generate some
discussion. The TCP specification indicates that once a connection is
established, it will stay established as long as both hosts keep it
established. It may be that during this idle time, one of the hosts
is removed from the network (shutdown, unplugged, etc), at which
point it will, in essence, terminate the connection, without being
able to let the other host know. This condition is known as a half-
open connection. Our problem is that, given our point of
observation, we can not ascertain when this has occurred. As such, we
must infer it through the lack of any activity over some time period.
If one accepts this, then the question becomes how long that timeout
should be. We propose using the same value as we use for closing the
connection when it is in the TIME-WAIT state.
3. Definitions of TCP Connection Metrics
Given the above definition of a connection, we will here define
various metrics that we might use in characterizing connections. We
follow the subsection for a Segment Arriving in the event processing
model in RFC 793 and note where we count various characteristics. Due
to our perspective, there is actually little overlap with the
endpoint-model that RFC 793 uses, so we duplicate some information as
necessary such that the reader does not require a copy of the RFC as
they read though. Some areas we differ from the RFC are: we ignore
the security and precedence checks, as those features of TCP/IP are
not used on contemporary networks; and we also assume a three-way
handshake to establish a connection, as it seems the four-way
handshake has never borne out.
3.1. Metrics to collect
An exhaustive list of the connection metrics that we collect as we
follow the event processing model is as follows:
Brugger [Page 4]
Internet-Draft TCP Connection Metrics 16 August 2006
- Number of packets
- Duration (time of last packet minus starting time), in seconds
- Number control packets
- Number data packets (Number of packets - Number control
packets)
- Bytes transfered
- Data bytes transfered
- Urgent
- Resend
- Wrong resend
- Duplicate ACK
- Wrong ACK
- Wrong data packet size
- Window exceeded
- Hole
- Connection errors
- Reset connection
- Other errors
- Disconnection errors
- Fragmented packets
- Bad fragment
- SYN-ONLY
- SYN-ACK
- Idle connection
- Half-open connection
Brugger [Page 5]
Internet-Draft TCP Connection Metrics 16 August 2006
All of these metrics -- except the last four -- should be stored in
the connection record, and can be reported when that record is
closed. The last four can be reported based on the state of the
record when it is closed.
All of these metrics should be reported as counts (as opposed to
rates), save for duration, which should be the number of seconds,
which may be a real number (clock resolution permitting).
3.2. Connection record
We use a modified form of the TCB presented in RFC 793 Section 3.2.
Since we're a third party observer to the connection, we attempt to
capture the state at both ends of the connection, rather than the
definitive information that either host uses.
Information on the source of the connection (the machine that sent
the initial SYN):
SRC.UNA - earliest sequence number the source has sent that has not
been acknowledged by the dest -- if all segments the source
has sent have been acknowledged, this will be equal to the
last ACK
SRC.NXT - the next sequence number the source is going to use
SRC.WND - the size of the window on the source machine
SRC.UP - pointer to the last urgent sequence that the source
machine should receive
SRC.UF - flag set to true when the urgent pointer should be examined
SRC.WL1 - sequence number used for last window update on source
machine
SRC.WL2 - sequence number of last source window update that the dest
acknowledged
SRC.FIN - sequence number of the source's FIN packet
Information on the destination of the connection:
DST.UNA - earliest sequence number the dest has sent that has not
been
acknowledged by the source -- if all segments the dest
has sent have been acknowledged, this will be equal to the
last ACK
Brugger [Page 6]
Internet-Draft TCP Connection Metrics 16 August 2006
DST.NXT - the next sequence number the dest is going to use
DST.WND - the size of the window on the dest machine
DST.UP - pointer to the last urgent sequence that the dest
machine should receive
DST.UF - flag set to true when the urgent pointer should be examined
DST.WL1 - sequence number used for last window update on dest machine
DST.WL2 - sequence number of last dest window update that the source
acknowledged
DST.FIN - sequence number of the dest's FIN packet
When looking at an individual packet, we may consider SND to be
whomever sent the packet: either SRC or DST, and RCV to be the other.
We use the same definition for SEG given in RFC 793, with the
clarification that SEG.LEN is the data length of the segment.
3.3. Segment Arriving
Since we're taking the viewpoint of a third-party observer to the
connection, the only event we're interested in is ``Segment
Arriving''. Of course, to us, the segment isn't really arriving, a
better term might be ``Segment Observed''.
A note on sequence comparisons: since sequence numbers run between
zero and 2**32 - 1, then repeat, RFC 793 notes that all sequence
comparisons should be done % 2**32, while this is not strictly
correct, it is easy enough for TCP implementations to check that
SND.UNA <= SEG.ACK <= SND.NXT, taking into account the special case
when SND.NXT < SND.UNA. This is not sufficient when collecting
metrics and we want to determine if ACKs are being duplicated, if a
segment is being ACKed before it arrives, or any other of a number of
scenarios. As such, whenever we note that a less than comparison
(including the < portion of <= ), such as A < B is being done, where
either A or B is SEG.SEQ or SEG.ACK, then if A is not less than B,
check if A is past halfway on the set of possible sequence numbers (>
2**31), B is below the halfway mark, and the difference between them
is at least 2**31. In formal notation:
A < B or (A > 2**31 and B < 2**31 and A-B > 2**31)
This may only be a heuristic, however it should be sufficient to
classify a packet as either a bad resend, or out-of-sequence.
Brugger [Page 7]
Internet-Draft TCP Connection Metrics 16 August 2006
3.3.1. Fragmented packets
For everything that follows, we assume that we're working with
complete segments, just as RFC 793 does. Hence, when a packet arrives
with the ``More Fragments'' (MF) flag set (that is part of a
connection that we either have a record for, or it has the SYN flag
set), it should be queued up in a fragmented packets queue. Any
packet without the MF flag set and with the fragment offset > 0 will
be assumed to be the last fragment. When it arrives, the
fragmentation pre-processor should:
- verify that all the fragments were received (there are no holes)
- verify that none of the fragments overlap
- verify that none of the fragments (including the last one) have
the ``Don't Fragment'' (DF) flag set.
If there are any holes, the packet is unusable, so the ``Fragmented
packets'' and ``Bad fragment'' counters should be incremented, and
processing on the packet should stop. If any of the conditionals do
not hold, then the ``Bad fragment'' counter should be incremented.
In either case, the ``Fragmented packets'' counter should be
incremented.
Since only the first fragment has the TCP portion of the header, we
must store the full header from the first fragment and use it for all
the segment information we require. We will need to substitute in
the full length of the packet as SEG.LEN. This measure will not
account for the extra transmission overhead of the extra headers on
all the fragment. This is fair because we are primarily interested
in the connection metrics at this point. General network metrics,
such as the total number of bytes sent or received on a given link,
can be collected independently of the connection. The same argument
holds for justification for dropping packets with missing fragments
before processing them as part of the connection.
Should the last fragment never arrive, then we may end up counting
the packet as a hole, below. If we don't count it as a hole, that
will mean that it was resent. Unfortunately, if it is not fragmented
when it is resent, we will not know to increase the ``Resent''
counter. If it is, however, fragmented, then the resend will show up
as a bad fragment due to overlap between the original and the resent
fragments. When a connection is closed, a count should be made of
any segments from that connection still on the fragmentation queue,
and that number added to the ``Bad fragments'' count.
The primary problem with this approach is that if the fragments
Brugger [Page 8]
Internet-Draft TCP Connection Metrics 16 August 2006
arrive out of order -- in particular if a fragment arrives after the
last fragment -- it will be recorded as a bad fragment. Considering
how infrequently fragmented packets are encountered in practice
anymore, we are not too concerned with this.
3.3.2. No Record
If we don't have a record of the connection, it could mean that the
connection was established before we started observing the traffic,
or that this packet is not part of an established connection. In the
later case, we don't know if the connection is in the CLOSED or
LISTEN state on the receiving host, so we continue to process this
packet.
If the packet is a RST, ignore it.
If the packet is an ACK, then it must be part of a connection that
was established before we began listening, so ignore it.
If the packet is a SYN, create a new connection record with
- the two sockets
- the starting time of the connection and time of last packet
- set SRC.UNA to SEG.SEQ
- set SRC.NXT to SEG.SEQ + 1
- set SRC.WND to SEG.WND
- set SRC.WL1 to SEG.SEQ
- set SRC.UP and SRC.WL2 to zero
- set SRC.UF to false
- set all the DST fields to zero
- set the state to SYN-RECEIVED
- set the ``Number of packets'' counter to one
- set the ``Bytes transfered'' to the total length of the
packet
- if the SEG.LEN is zero, set the ``Number controller
packets'' counter to one, otherwise increment the ``Data
bytes transfered'' by SEG.LEN and set the ``Wrong data packet
size'' counter to one
- set all other counters to zero
3.3.3. SYN-RECEIVED
When we're in the SYN-RECEIVED state, we expect to see a SYN-ACK.
For all packets:
- increment the ``Number of packets'' counter
- increment the ``Bytes transfered'' by the total length of the
packet
- if the SEG.LEN is zero, increment the ``Number controller
Brugger [Page 9]
Internet-Draft TCP Connection Metrics 16 August 2006
packets'' counter, otherwise increment ``Data bytes transfered''
by SEG.LEN and increment the ``Wrong data packet size'' counter
- set time of last packet
If the packet is not an ACK:
- increment the ``Connection errors'' counter
- stop processing this packet
Otherwise, the packet is an ACK, so check the acknowledgment number.
If SEG.ACK != SRC.NXT:
- increment the ``Connection errors'' counter
- stop processing this packet
If the ACK is fine, check if the RST flag is set. If so:
- increment the ``Connection errors'' counter
- increment the ``Reset connection'' counter
- close the record
If the SYN flag is set, then this is the SYN-ACK we expect:
- set DST.UNA to SEG.SEQ
- set DST.NXT to SEG.SEQ + 1
- set DST.WND to SEG.WND
- set DST.WL1 to SEG.SEQ
- set DST.UP and DST.WL2 to zero
- set DST.UF to false
- set SRC.UNA to SEG.ACK
- set SRC.NXT to SEG.ACK
- set the state to SYN-ACK
- stop processing this packet
If we made it this far, the packet is an ACK, but not a SYN-ACK, so:
- increment the ``Connection errors'' counter
- stop processing this packet
3.3.4. SYN-ACK and later
The SYN-ACK state is what we call when the source is in the
ESTABLISHED state and the destination is in the SYN-RECEIVED
state. For this state, and all the ones that follow, we follow some
common steps.
For all packets:
- increment the ``Number of packets'' counter
- increment the ``Bytes transfered'' by the total length of the
packet
- if the SEG.LEN is zero, increment the ``Number controller
packets'' counter, otherwise increment ``Data bytes transfered''
by SEG.LEN
Brugger [Page 10]
Internet-Draft TCP Connection Metrics 16 August 2006
- set time of last packet
First, check that the sequence number is acceptable.
If SEG.SEQ < SND.UNA, then the sender is resending a packet that
has already been acknowledged:
- increment the ``Wrong resend'' counter
- stop processing this packet
If SEG.SEQ+SEG.LEN-1 > SND.UNA+RCV.WND, then the sender is sending
a packet that will exceed the receiver's window:
- if the state is SYN-ACK, increment the ``Connection errors''
counter
- increment the ``Window exceeded'' counter
- while an end-host would stop processing the packet at this
point, we must consider that we failed to observe a packet
or that the end-host will be lenient in what it accepts
If SEG.SEQ < SND.NXT, then this is a resend:
- increment the ``Resend'' counter
- stop processing this packet
Now see if the packets are out of order:
If SND.NXT < SEG.SEQ, then this packet is either arriving after one
before it in the sequence, or there is a hole in the sequence:
- If the sequence of any packet in the other direction on the
out-of-sequence queue is < SEG.ACK, continue processing (we
will process the packets in the other direction below when we
examine the ACK field)
- Otherwise, push it on an ``out-of-sequence'' queue, which we
will process later
The remaining case is that SEG.SEQ = SND.NXT, which is what we want
and expect, so we continue to process it.
Second, if the RST flag is set:
- increment the ``Reset connection'' counter
- if the SEG.LEN > 0, increment the ``Wrong data packet size''
counter
- if the state is ``SYN-ACK'', increment the ``Connection errors''
counter
- close the record
Third, if the SYN flag is set:
- if the state is ``SYN-ACK'', increment the ``Connection errors''
counter, otherwise set the ``Other errors'' counter
- if the SEG.LEN > 0, increment the ``Wrong data packet size''
counter
- stop processing this packet
Brugger [Page 11]
Internet-Draft TCP Connection Metrics 16 August 2006
Fourth, check the ACK field:
If the ACK flag is not set:
- if the state is ``SYN-ACK'', increment the ``Connection
errors'' counter, otherwise set the ``Other errors'' counter
- stop processing this packet
SYN-ACK state:
If SEG.ACK != DST.UNA+1:
- increment the ``Connection errors'' counter
- stop processing this packet
Otherwise:
- change the state to ESTABLISHED
ESTABLISHED and FIN-WAIT-2 states:
If SEG.ACK < RCV.UNA:
- increment the ``Duplicate ACK'' counter
- stop processing this packet
If RCV.NXT < SEG.ACK:
- check the out-of-sequence queue - if there are any packets
from the receiver of this packet to the sender of this
packet, see if any of the sequences are < SEG.ACK; if so, for
each matching packet on the queue, in order, based on their
sequence numbers:
- recursively process that packet and remove it from the
queue; if while processing a packet, it finds a RCV.NXT <
SEG.ACK, then just increment the ``Hole'' counter, set
both RCV.NXT and RCV.UNA to SEG.ACK, and continue (in
other words, we will recurse from SND -> RCV to
RCV -> SND, from the perspective of the current segment,
but no further).
Once complete, continue to process this packet.
- If after processing any out-of-sequence packets, recheck
SEG.ACK < RCV.UNA; if true:
- increment the ``Wrong ACK'' counter
- stop processing this packet
- If after processing any out-of-sequence packets, recheck
RCV.NXT < SEG.ACK; if true:
- increment the ``Hole'' counter
- set RCV.NXT to SEG.ACK
- set RCV.UNA to SEG.ACK
- set RCV.UNA to SEG.ACK
- If SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and SND.WL2 <
SEG.ACK), then set SND.WND to SEG.WND, set SND.WL1 to
SEG.SEQ, and set SND.WL2 to SEG.ACK
FIN-WAIT-1 state:
- Follow the steps for the ESTABLISHED state
- If SEG.ACK = RCV.FIN + 1, then set the state to FIN-WAIT-2 and
set RCV.FIN to zero
Brugger [Page 12]
Internet-Draft TCP Connection Metrics 16 August 2006
CLOSING state:
- Follow the steps for the ESTABLISHED state
- If SEG.ACK = RCV.FIN + 1, then set RCV.FIN to zero (this, plus
the state, indicates that it has been ACKed) and set the state
to TIME-WAIT, otherwise increment the ``Disconnection errors''
counter
TIME-WAIT state:
- Follow the steps for the ESTABLISHED state
- If SEG.ACK = RCV.FIN + 1, then close the record
Note from this point forward that we don't need to handle the
SYN-ACK state as it will have either transitioned to the
ESTABLISHED state or have stopped processing with an error.
Fifth, check the URG flag:
ESTABLISHED, FIN-WAIT-1, and FIN-WAIT-2 states:
- If the URG flag is set, set RCV.UP to the max of RCV.UP and
SEG.UP and set RCV.UF to true
- If RCV.UF is true and SEG.SEQ <= RCV.UP, increment the
``Urgent'' counter, otherwise, set RCV.UF to false
CLOSING, and TIME-WAIT states:
- If the URG flag is set, increment the ``Disconnection errors''
counter
Sixth, update the source's sequence information:
ESTABLISHED, FIN-WAIT-1, and FIN-WAIT-2 states:
- If SEG.LEN > zero, set SND.NXT to SEG.SEQ + SEG.LEN
CLOSING, and TIME-WAIT states:
- If SEG.LEN > zero, increment the ``Wrong data packet size''
counter
Finally, check the FIN flag. Since we only process Segment Arrived
events, there are only two ways that a connection can be closed:
1. Host A sends a FIN to Host B, Host B ACKs this FIN. Eventually,
Host B sends its own FIN, which Host A will ACK, and the
connection is CLOSED.
2. Host A sends a FIN to Host B, Host B is thinking the same thing
and sends a FIN to Host A. One of the hosts (it does not matter
which) ACKs the other's FIN, then the other host ACKs the other
FIN, and the connection is CLOSED.
We tweak the event model in RFC 793 to fit these two choices: When
a FIN is received, we enter the FIN-WAIT-1 state. If that FIN is
ACKed, we enter the FIN-WAIT-2 state. If, instead, the other ACK is
received, we enter the CLOSING state. From the FIN-WAIT-2 state,
when we receive the other FIN, we enter the TIME-WAIT state. From
the CLOSING state, when one of the FINs is ACKed, we enter the
TIME-WAIT state. From the TIME-WAIT state, when the other FIN is
ACKed, we enter the CLOSED state.
Brugger [Page 13]
Internet-Draft TCP Connection Metrics 16 August 2006
This can be illustrated as follows:
+-------------+
| ESTABLISHED |
+-------------+
|
| FIN
V
+------------+
| FIN-WAIT-1 |------+
+------------+ |
| | FIN
| FIN-ACK |
V V
+------------+ +---------+
| FIN-WAIT-2 | | CLOSING |
+------------+ +---------+
| |
| FIN |
V | FIN-ACK
+-----------+ |
| TIME-WAIT |<------+
+-----------+
|
| FIN-ACK
V
+--------+
| CLOSED |
+--------+
So we perform the following steps, if the FIN bit is set:
ESTABLISHED state:
- set SND.FIN to SEG.SEQ
- set SND.NXT to SEG.SEQ + SEG.LEN + 1
- change the state to FIN-WAIT-1
FIN-WAIT-1 state:
- if SND.FIN is set (not zero), increment the ``Disconnection
errors'' counter and stop processing this packet
- set SND.FIN to SEG.SEQ
- set SND.NXT to SEG.SEQ + SEG.LEN + 1
- change the state to CLOSING
FIN-WAIT-2 state:
- if SND.FIN is set (not zero), increment the ``Disconnection
errors'' counter and stop processing this packet
- set SND.FIN to SEG.SEQ
- set SND.NXT to SEG.SEQ + SEG.LEN + 1
- change the state to TIME-WAIT
CLOSING and TIME-WAIT states:
Brugger [Page 14]
Internet-Draft TCP Connection Metrics 16 August 2006
- increment the ``Disconnection errors'' counter
- stop processing this packet
3.4. Cleaning up
When we are done observing the traffic over this connection, we will
still have a number of open connection records. We must decide if
these connections are still active, in which case we do not have all
the information on the connection to report its metrics, or if the
connection has timed out. If a connection has timed out, at least one
end of the connection has closed its TCB (or it never created one),
and any further attempts to use that connection will result in a RST
(or will just be ignored). As explained in section 2, if the last
packet was more than TIMEOUT seconds before we stopped observing
traffic on this link, then we will assume the connection is idle and
close it.
- If the state of the connection is SYN-RECEIVED, then report
the ``SYN-ONLY'' counter as one, otherwise report it as zero.
- If the state of the connection is SYN-ACK, then report the
``SYN-ACK'' counter as one, otherwise report it as zero.
- If the state of the connection is ESTABLISHED, then report the
``Idle connection'' counter as one, otherwise report it as
zero.
- If the state of the connection is FIN-WAIT-1, FIN-WAIT-2,
CLOSING, or TIME-WAIT, then report the ``Half-open
connection'' counter as one, otherwise report it as zero.
4. Security Considerations
There are no known security considerations to the creation and
processing of TCP connection metrics. The capture of network data as
a third party observer does, however, pose both security and privacy
issues, which must be addressed on a case-by-case basis for the
policies and environment of each network that data is collected from.
Such metrics are likely to be useful in network security
applications, such as network intrusion detectors. The potential for
such application is left to future research.
5. IANA Considerations
This document has no actions for IANA.
Brugger [Page 15]
Internet-Draft TCP Connection Metrics 16 August 2006
6. References
6.1. Normative References
[RFC793] Postal, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
6.2. Informative References
[Axelsson00] Axelsson, S., "Intrusion detection systems: A survey and
taxonomy", Chalmers Univ. of Technology, Technical
Report 99-15, March 2000.
[Caswell04] Caswell, B. and M. Roesch, "Snort: The open source
network intrusion detection system",
"http://www.snort.org/".
[Lee98] Lee, W. and S. J. Stolfo, "Data mining approaches for
intrusion detection", Proc. of the 7th USENIX Security Symp.,
1998.
[Lee99a] Lee, W., "A Data Mining Framework for Constructing Features
and Models for Intrusion Detection Systems", Columbia Univ.,
Ph. D. thesis, 1999.
[Lee99b] Lee, W., S. J. Stolfo, and K. W. Mok, "Mining in a data-flow
environment: Experience in network intrusion detection",
Proc. of the Fifth International Conference on Knowledge
Discovery and Data Mining (KDD-99), S. Chaudhuri and
D. Madigan (Eds.), pp. 114-124, 15-18 August 1999.
[Lee00a] Lee, W. and S. J. Stolfo, "A framework for constructing
features and models for intrusion detection systems",
Information and System Security 3 (4), pp. 227-261, 2000.
[Lee00b] Lee, W., S. J. Stolfo, and K. W. Mok, "Adaptive intrusion
detection: A data mining approach", Artificial Intelligence
Review 14 (6), pp. 533-567, 2000.
[Leland94] Leland, W. E., M. S. Taqqu, W. Willinger, and D. V.
Wilson, "On the self-similar nature of ethernet traffic
(extended version)", IEEE/ACM Trans. Networking 2, pp.
1-15, February 1994.
[Miller00] Miller, T., "Intrusion detection level analysis of Nmap
and Queso", SecurityFocus, Technical Report 1225, 30
August 2000.
Brugger [Page 16]
Internet-Draft TCP Connection Metrics 16 August 2006
[Paxson95] Paxson, V. and S. Floyd, "Wide area traffic: the failure
of Poisson modeling", IEEE/ACM Trans. Networking 3 (3),
pp. 226-244, June 1995.
[Racz03] Racz, P. I., T. Matsuda, and M. Yamamoto, "Contribution of
the application, transport and network layers to the
self-similarity of Internet traffic", Proc. of 2003 IEEE
Pacific Rim Conf. on Communications, Computers and Signal
Processing, Volume 2, pp. 760-763, 28-30 August 2003.
[TCPDUMP] TCPDUMP public repository, "http://www.tcpdump.org/".
Author's Address
S Terry Brugger
Department of Computer Science
University of California, Davis
One Shields Ave
Davis, CA
Phone: 925.424.4992
EMail: zow@acm.org
IPR Notice
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
Brugger [Page 17]
Internet-Draft TCP Connection Metrics 16 August 2006
Copyright Notice
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expiration Notice
Draft expires on 16 February 2007.
Brugger [Page 18]
