TCPopera

1
TCPopera

• Fiona Wong and S. Felix Wu
• Security Laboratory
• Computer Science Department
• University of California, Davis

2
Outline

• Introduction
• What is TCPreplay?
• What are TCPreplays limitations?
• TCPopera
• What is TCPopera?
• TCPopera Phase 1
• TCPopera design and implementation

3
Outline Continued

• TCPopera Phase 2
• Evaluation
• TCPopera evaluation
• Future Work
• Conclusion

4
Introduction - TCPreplay

• TCPreplay replays traffic saved in files created
  by TCPdump.
• Created in the hopes of improving NIDS (network
  intrusion detection systems) testing.

5
Introduction - TCPreplay

• How does TCPreplay help test NIDS systems?
• Performance degrades as network traffic
  increases.
• Attacks are hidden by heavily loaded traffic.

6
Introduction - TCPreplay

• TCPreplay advantages
• - Allows for exact replication of real traffic
  seen on real networks.
• TCPreplay disadvantages
• - Limitation on the type of network traffic that
  can be replayed

7
Introduction - TCPreplay

• TCPreplay is too static
• We can not replay the retransmission and
  congestion control.
• We can not replay in a different network or
  operational environment.

8
Introduction continued

• What we need is a tool that can extend
  TCPreplays abilities.

The solution is.
TCPopera!
9
TCPopera

• Given a TCPdump file
• We would like to produce different variations of
  the base dump file.

• TCPopera is a tool that extends TCPreplay by
  allowing users to define network conditions and
  play out traffic in a realistic environment where
  packets may be delayed or lost.

10
TCPopera

• How would TCPopera aid in IDS testing?
• Does the IDS track TCP connection state?
• How well does the IDS perform under different
  network conditions (false positives!)?
• How does the IDS handle retransmitted packets?
• TCPopera has the potential to provide IDS testing
  environments with traffic that exhibits TCP
  behavior quickly.

11
TCPopera

• TCPopera has the potential of being a very
  complex tool.
• Issues
• Considering time and labor constraints, how can
  we build a useful tool?
• Basic approach
• A simple working prototype

12
TCPopera High-Level Model
New TCPdump file
Original TCPdump file
TCPopera
13
TCPopera Phase 1 Requirements

• TCPopera Phase 1 Prototype requirements
• 1.  Support a stop and wait protocol.
• 2.    Retransmission mechanism defined by the
  following parameters
• Timeout mechanism
• Maximum allowable retransmissions
• Congestion control algorithm (AIMD, etc)
• 3.   Support a maximum of 25 connections.

14
TCPopera Phase 1 Requirements

• TCPopera Phase 1 Prototype requirements
• Given a TCPdump file as input TCPopera will
  generate a TCPdump file based on a given TCP
  behavioral portfolio, or, tcp_prof
• TCP_PROF defines a specific network entities TCP
  behavior.

15
TCPopera Phase 1 Requirements

• Percentage total packet loss.
• Percentage total packet delay
• Percentage data packet loss.
• Percentage ACK packet loss.
• Percentage data packet delay.
• Percentage ACK packet delay.
• Amount of delay
• Packet loss occurring on sending, receiving, or
  both sending and receiving sides.
• Packet delay occurring on sending, receiving, or
  both sending and receiving sides.

tcp_prof
198.206.5.211
16
TCPopera Phase 1 Design

• TCPopera can be approached in two ways.
• Using a simple heuristic to define data
  dependencies between messages in a TCPdump file.
• Peering into the data payload and determine the
  exact dependencies between messages in a TCPdump
  file.

17
TCPopera Phase 1 Design

• What do I mean by dependency?

18
TCPopera Phase 1 Design

• Another example

19
TCPopera Phase 1 Design

• For the stop-and-wait protocol we use the first
  approach.
• Dependency Heuristics
• Every packet is dependent on the most recent
  opposite-direction packet.
• If one packet is followed by two consecutive
  packets in the opposite direction, then the first
  packet of the two consecutive packets is a
  response to the first packet.

20
TCPopera Phase 1 Design

• Dependency Heuristics continued
• 3. The first packet in any scenario is a data
  packet.
• 4. If packet A is dependent on packet B, and
  packet A immediately proceeds B, then packet A is
  an ACK.

21
TCPopera Phase 1 Design

• TCPopera basic algorithm
• Given a tcpdump file and a configuration file,
  build tcp_port.
• For each TCP packet read, determine if a tcp_port
  exists for the SOURCE entity.
• If a tcp_port exists, based on the parameters
  (dropping rate, etc) for this entity, calculate a
  new timestamp.
• Calculate any retransmissions of packets that
  this current packet is dependent on.

22
TCPopera Phase 1 Design

• Example. Senders retransmission timeout is 1.5
  seconds

• Packet 2 is dropped

23
TCPopera Phase 1 Design

• The new scenario generated is as follows

• Packet 1 is retransmitted

24
TCPopera Phase 1 Design

• Other complicated scenarios
• Sender and receiver retransmission timeouts.

25
TCPopera Design
Packet Config Module
Packet Parse Module
Packet Connections Module
libpcap
TCPopera Module
Packet dependency Module
TCPopera Module
Packet Portfolio Module
Test Module
Packet Processing Module
Congestion control
Timestamp
Retransmit
26
TCPopera Implementation

• Programmed in C
• Libpcap
• Headers for pcap structures
• Portable, system-independent interface for
  user-level network packet capture
• Used by TCPdump and TCPreplay

27
TCPopera Phase 2

• Requirements
• TCP state (sliding window)
• Nagles algorithm
• - Support for bulk data transfer protocols (ftp)
• Will require peering into the pcap data (TCP/IP
  headers)
• Expanded functionality
• Support more congestion control mechanisms

28
Config file Example

• SETDROP ALL 192.186.0.2 25
• SETDROP DACK 192.186.0.3 25
• SETDROP DATA 192.186.0.3 50
• SETRETRANSMIT 192.186.0.2 3
• SETRETRANSMIT 192.186.0.3 2
• SETINITTIMEOUT 192.186.0.2 1.3

29
TCPopera Example

• DROPPED
• 100801.644364 nupte.cs.ucdavis.edu.32780 gt
  192.186.0.3.telnet P 56(1) ack 6 win 5840
  ltnop,nop,timestamp 69960 240133055gt (DF) tos
  0x10
• 100801.644474 192.186.0.3.telnet gt
  nupte.cs.ucdavis.edu.32780 P 67(1) ack 6 win
  5792 ltnop,nop,timestamp 240133066 69960gt (DF)
  tos 0x10
• TCPopera generates
• 1st transmission
• 100806.134362 nupte.cs.ucdavis.edu.32780 gt
  192.186.0.3.telnet P 56(1) ack 6 win 5840
  ltnop,nop,timestamp 69960 240133055gt (DF) tos
  0x10
• RETRANSMISSION
• 100807.824361 nupte.cs.ucdavis.edu.32780 gt
  192.186.0.3.telnet P 56(1) ack 6 win 5840
  ltnop,nop,timestamp 69960 240133055gt (DF) tos
  0x10
• 100807.824471 192.186.0.3.telnet gt
  nupte.cs.ucdavis.edu.32780 P 67(1) ack 6 win
  5792 ltnop,nop,timestamp 240133066 69960gt (DF)
  tos 0x10

30
TCPopera Evaluation

• Verification
• Manual comparison of TCPdump packets and
  TCPoperas labeling of packets to check for
  dependency correctness
• Validation
• Using divert sockets and iptables compare
  TCPopera output to actual network behavior.
• For more information go to http//www.tldp.org/HOW
  TO/mini/Divert-Sockets-mini-HOWTO.html

31
TCPopera Evaluation

• Divert Sockets
• filters out certain packets based on firewall
  specifications and brings them to user space.
• Choice of reinjection.
• Uses a special type of RAW socket called divert
  (IPPROTO_DIVERT)
• Anything that a firewall can filter out can be
  sent into a divert socket.
• Used in conjunction with iptables (firewall
  system)
• For more information go to http//www.netfilter.or
  g/

32
TCPopera Evaluation and Status

• Current Status
• Elementary stages of testing show
• Verification success
• Validation currently being performed.
• Evidence of results with interactive data
  (telnet)
• We assume a stop-and-wait protocol in this phase.

33
TCPopera Future

• Implement and test TCPopera Phase 2
• Incorporate TCP sliding window protocol
• Nagles algorithm
• Scalable
• TCP sliding window
• Testing
• Validated and verified in a larger test
  environment
• ftp, telnet, http, etc
• IDS testing using TCPopera dump files

34
TCPopera Conclusions

• TCPopera has the potential of becoming a useful
  tool for testing NIDS systems
• TCPopera may facilitate the process of profiling.

35
References

• http//www.netfilter.org/
• http//www.anr.mcnc.org/divert/index.shtml
• http//online.securityfocus.com/infocus/1623
• Intrusion Detection, Take Two, How We Tested
  Intrusion Detection, November, 1999, in Network
  Computing. URL http//www.networkcomputing.com/10
  23/1023f19.html?lsNCJS_1023bt
• http//www.nss.co.uk/ids/edition3/introduction.htm
  
• N. Puketza, K. Zhang, M. Chung, B. Mukherjee, R.
  Olsson. A Methodology for Testing Intrusion
  Detection Systems, in the 17th National Computer
  Security Conference in Valtime, MD, October,
  1994.
• C. Kruegel, F. Valeur, G. Vigna, R."Stateful
  Intrusion Detection for High-Speed Networks", in
  Proceedings of the IEEE Symposium on Research on
  Security and Privacy, Oakland, CA, May 2002.

36
References

• M. Ranum, Experiences Benchmarking Intrusion
  Detection Systems, in NFR Security Technical
  Publications, December, 2001. http//www.nfr.com
• R. Lippmann, D. Fried, I. Graf, J. Haines, K.
  Kendall, D. McClung, D. Weber, S. Webster, D.
  Wyschogrod, R. Cunningham, M. Zissman.
  Evaluating Intrusion Detection Systems The 1998
  DARPA Off-line Intrusion Detection Evaluation in
  Proceedings of the 2000 DARPA Information
  Survivability Conference and Exposition (DISCEX).
  2000.
• Y. Jou, F. Gong, C. Sargor, X. Wu, S.F. Wu, H.C.
  Chang, F. Wang, Design and Implementation of a
  Scalable Intrusion Detection System for the
  Protection of Network Infrastructure In DARPA
  Information Survivability Conference and
  Exposition, January 2000.
• V. Paxon, Bro A System for Detecting Network
  Intruders in Real-Time in the Proceedings of the
  7th USENIX Security Symposium San Antonio, Texas,
  January, 1998.

37
References

• N. Puketza, M. Chung, R. Olsson, B. Mukherjee, A
  Software Platform for Testing Intrusion Detection
  Systems, IEEE, 1997.
• A. Yasinsac. An Environment for Security
  Protocol Intrusion Detection in the Special
  edition of the Journal of Computer Security,
  2001.

38
Thank-you!