1. Detecting Anomaly Traffic using Flow Data in the Real VoIP Network
Hyeongu Son, Youngseok Lee
{hgson,
Chungnam National University
Korea
(Mon.)
Thank you for chairman
My name is Hyeongu Son.
Recently, many VoIP applications are deployed and VoIP users are increasing because of free or cheap call charge.
Since the VoIP services are popular, a lot of VoIP anomaly traffic have been deployed
Today, my talk is Detecting Anomaly Traffic using Flow Data in the real VoIP network.

2. Introduction Current trend Most of all VoIP applications
Over 5 millions (about 20% of all phone users) in Korea
In 2009, over 27 millions in the U.S.A.
Most of all VoIP applications
SIP : for call connection
RTP : In order to transmit voice traffic
Various anomaly traffic in the Internet
Worm, DoS, DDoS etc.
Degrade bit/packet rate, increase packet transmit delay, etc.
VoIP anomaly traffic
Terminate / cancel calls between VoIP users
Degrade voice quality
Last year, members of VoIP applications are over 5 millions in Korea. Also, it was expected that users of VoIP applications in the U.S.A are over 27 millions.
Most of all VoIP applications in Korea provided from those service providers use SIP for call connection and RTP to transmit voice traffic.
Nowadays, various anomaly traffic such as Worm, DDos is exposed in the Internet. The anomaly traffic can be caused degradation of packet transmission rate and growth of packet transmission delay.
In addition, anomaly traffic for interfering VoIP services directly, have been deployed. This anomaly traffic can be occurred the mentioned problem as well as degradation of voice quality and termination and cancellation calls between users.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

3. Motivation Current SIP/RTP-based VoIP services
Provide minimal security function related with authentication
The packet is not encrypted
Possible to be sniffed and forged by an attacker
Proposed security protocol
SRTP, TLS, IPSec, etc.
Current SIP/RTP-based VoIP services in Korea provide minimal security function related with authentication.
However, because the VoIP packet is not encrypted, it is possible to be sniffed and forged the packet by an attacker.
For preventing these problems by the attacker, the security protocols such as SRTP, TLS and IPSec have been proposed, but these protocols have not been fully implemented in most of all commercial VoIP applications.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

4. Contribution Propose three VoIP anomaly traffic detection methods
For monitoring VoIP traffic : employ IPFIX
Define new IPFIX templates for monitoring SIP and RTP traffic
To monitor wireless LAN traffic at wireless access router
Add MAC header information
Propose VoIP-related anomaly traffic detection methods
CANCEL DoS anomaly traffic detection
BYE DoS anomaly traffic detection
RTP flooding traffic detection
In this paper, we proposed these anomaly traffic detecting method using flow-data.
In order to use flow-level traffic measurement, we use IPFIX which is proposed by IETF IPFIX working group.
Based on this measurement, we propose 2 new IPFIX templates for monitoring SIP and RTP traffic. In addition, we add on some IPFIX fields for observing wireless LAN traffic.
Based on this monitored results, we proposed three VoIP anomaly traffic detection methods.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

5. IPFIX IPFIX IP Flow Information eXport Based on Cisco NetFlow v9
Flexible and easily extensible template architecture
Support IPv4 traffic as well as IPv6, VoIP and MPLS
Reliable transport protocols
Default IPFIX flow transport protocol
UDP
For reliability
Support SCTP and TCP
In this paper, we use IPFIX based on cisco netflow v9 for standard flow-level traffic measurement. This method provides flexible and extensible template architecture so it can be easy to support various kinds of protocols such as IPv6, MPLS and VoIP. In addition, this method supports reliable transport protocols such as SCTP and TCP when IPFIX message is transmitted to a collector.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

6. (2 options Data Records)
Example of IPFIX flow
IPFIX Header
Template
FlowSet
(1 Template)
Data
FlowSet
(3 Flow Data Reords)
Options
Template FlowSet
(1 Template)
Option Data
FlowSet
(2 options Data Records)
Ver = 10
Message
Length
SRC IPv4 Addr
DST IPv4 Addr
Src port
Pkt #
Bytes # 80 22
5009
748
388934
Export Timestamp
Sequence Number
FlowSet ID = 256
Length = 92
Source ID
FlowSet ID = 1
Length = 24
Template ID 257
Opt Scope Length = 4
Option Length = 8
Source ID=TBD
FlowSet ID = 0
Length = 28 bytes 80
Scope 1
Field Length = 4
TOTAL_EXP_PKTS
_SENT=41
Template ID 256
Field Count = 5
IPV4_SRC_ADDR = 27
Field Length = 4
5009
Field Length = 2
TOTAL_FLOWS_EXP=42
IPV4_DST_ADDR = 28
Field Length = 4
Field Length = 2
Padding
L4_SRC_PORT= 7
Field Length = 4
IPFIX flow consists of 5 section such as IPFIX header, template set, data set, option template set and option data template set
Each flow entry includes data records according to the define flow template which while will be sent to the flow collector before the flow data is exported.
In this figure, we can see that source IP address, destination IP address, port numbers, packet count and byte count.
IN_PKTS = 2
Field Length = 4
Line Card ID
IPFIX msg
Export Flow
IN_BYTES = 1
Field Length = 4 22
Line Card 1
Line Card 2
345
690
10201
20402
748
388934
FlowSet ID = 257
Length = 20 1
345
10201 2
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010) 6
690
20402

7. Related Work Related Work Features Drawback
Using Hellinger Distance[8]
VoIP anomaly traffic detection using Hellinger Distance
Detection of anomaly traffic in this method is used packet count, so it is difficult to detect anomaly traffic having 1 or 2 packet(s)
State machine[11]
VoIP anomaly detection method using Extended Finite State Machine
It needs to maintain status information of VoIP packets
SIPFIX[10]
SIP traffic monitoring method involved application-layer inspection and information in SDP
This method is presented only the possibility of applying it to detect DoS anomaly traffic
SIP Anomalies Detection Simulation[14]
Simulation of SIP anomaly traffic detection
The results were presented at non-real VoIP network
For detecting VoIP anomaly traffic, various detection methods have been proposed. We will introduce some detection methods and explain their weaknesses briefly.
First one is flooding anomaly traffic detection method using Hellinger distance. This method used packet count to calculate Hellinger distance. However, it is difficult to anomaly traffic having 1 or 2 packet(s).
Second one is VoIP anomaly traffic detection using extended finite state machine. This method needs to maintain status information of VoIP packets, so it is possible to increase overhead of detection system overhead such as memory consumption.
For monitoring SIP traffic, it is proposed to involve application-layer inspection and information of SDP. This method is called SIPFIX. However, this method is presented only the possibility of applying it to detect VoIP DoS anomaly traffic.
In this paper, we propose VoIP anomaly traffic detection method in commercial VoIP network.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

8. VoIP Anomaly Traffic in Real VoIP Network
VoIP traffic in real VoIP network
Security : only provide authentication
CANCEL DoS anomaly traffic
Do not need authentication key provided from proxy server
BYE DoS anomaly traffic
Need authentication key which is the same as the key in INVITE
Possible to get the key from unencrypted INVITE message by sniffing
RTP flooding
Do not need authentication key in a RTP packet
INVITE / Registeration etc.
Need authentication key
Difficult to obtain authentication key in real VoIP network
Before sending anomaly traffic, attacker have to get authentication key
Most of all VoIP applications in Korea only provide an authentication security function, but packet encryption is not supported.
So, an attacker easily obtain header information of VoIP packet through sniffing it.
In this paper, we generate three anomaly traffic – CANCEL/BYE DoS and RTP flooding anomaly traffic.
CANCEL traffic do not need authentication key in SIP header. So attacker can generate CANCEL anomaly traffic using sniffed information from unencrypted SIP message.
In the contrast, BYE message have to need authentication key for call termination. Because the authentication key in BYE message is the same as the key in INVITE message, the attacker easily generate BYE DoS anomaly traffic through obtaining user information and the authentication key from unencrypted INVITE and OK message,
RTP flooding traffic generation is easy because RTP packet is also not encrypted, so the attacker can send RTP flooding traffic which is similar with normal RTP traffic.
However, it is difficult to generate INVITE and Registeration anomaly traffic because the attacker can not know the authentication key before generating these anomaly traffic.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

9. CANCEL DoS Anomaly Traffic
attacker
CANCEL Traffic does not use authentication field
CANCEL
Wireless access router
Internet
INVITE
CNU Network
INVITE
Request Terminated
VoIP Node 1
Proxy server
Router
We generate CANCEL DoS anomaly traffic through sniffing VoIP traffic in wireless network. (click)From INVITE message, we generate fake CANCEL message, then send to proxy server. Proxy server regard as normal cancel state because fields of this CANCEL traffic are the same as normal CANCEL traffic. After that, proxy server send request terminated to VoIP node 1 for informing normal termination of the calls.
The call of VoIP node 1
is canceled by the attack
VoIP Node 2
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

10. BYE DoS Anomaly Traffic
BYE Traffic uses authentication field
attacker
BYE
Wireless access router
Internet
INVITE OK
CNU Network
INVITE
VoIP Node 1
Proxy server
Router
(Click)For generating BYE DoS anomaly traffic, it is similar with generating CANCEL DoS anomaly traffic. Fake BYE message is made from sniffing INVITE and OK messages. We copy some fields using in BYE message from INVITE and OK message. (click)We send it to proxy server, then the server send to VoIP node 2. After that, call of VoIP node 2 is terminated, and VoIP node 1 does not know that call is terminated. At that time, RTP traffic is only transmitted from VoIP node 1 to proxy server. OK
The call of VoIP node 2
is only terminated by the attack
VoIP Node 2
: RTP Traffic
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

11. RTP Flooding Anomaly Traffic
: RTP Traffic
: RTP Flooding Traffic
attacker
Wireless access router
Internet
CNU Network
INVITE
VoIP Node 1
Proxy server
Router
(click)RTP flooding traffic is generated through sniffing RTP packet in wireless network. The attacker generates over 1000 packets in short time and send to proxy server. After that, voice communication is caused disconnecting or degrading voice quality.
Degradation of voice quality due to the attack
between node 1 and node 2 OK
VoIP Node 2
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

12. Detection Architecture
Capture packets
Analyze packets
Flow management
Create IPFIX flow
Send IPFIX flow
Receive IPFIX flow
Analyze IPFIX flow DB
(Save traffic information)
Packets
IPFIX flow generation
(Router or Switch)
IPFIX flow collector
IPFIX Flow
(TCP/UDP/SCTP)
Detect anomaly VoIP traffic using this information
Visualization
Visualization of detection results
This is our VoIP-related anomaly traffic detection architecture. This architecture is consisted of IPFIX flow generator, IPFIX flow collector and visualizer. In the generator, packet is captured and analyzed. The generator create IPFIX flow, then send it to IPFIX flow collector.
The collector receives the IPFIX flows from the generator, then analyzes and save traffic measurement results to database.
Visualizer represents anomaly traffic detection results.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

13. RTP first sequence num. = 618
IPFIX Template
RTP-related template
Monitor RTP header fields
Can detect RTP-related anomaly traffic
RTP flooding
Malformed RTP traffic
Default template
Monitor default flow information
bit and packet rate
Classification by port number
Difficult to monitor VoIP traffic using this template
SIP-related template
Monitor SIP header fields
Call-ID, SIP message type
Voice codec, IP address / port number for transmitting RTP traffic
Can detect SIP-related anomaly traffic from this template
IPFIX Header
Set ID
Length
Template ID = 262
Field count = 19
Default template
RTP first SSRC = 600
Field Length = 4
RTP Jitter = 604
RTP packet loss rate = 606
RTP payload type = 608
Field Length = 2
RTP ave. oneway delay = 616
RTP first sequence num. = 618
RTP last sequence num. = 619
SSRC changed count = 620
RTP Max. sequence num. = 621
RTP Min. sequence num. = 622
Version = 10
Total length
Export time
Sequence number
Source ID
Set ID
Length
Template ID = 260
Field count = 9
Src IPv4 Addr = 8
Field Length = 4
Dst IPv4 Addr = 12
Src port = 7
Field Length = 2
Dst port = 11
Protocol = 4
Field Length = 1
First timestamp = 22
Last timestamp = 21
OctetDeltaCount = 1
PacketDeltaCount = 2
IPFIX Header
Set ID
Length
Template ID = 261
Field count = 14
Default template
SIP call-ID = 400
Field Length = 50
SIP MSG type = 412
Field Length = 4
SIP RTP codecs = 403
Field Length = 1
SIP RTP port = 409
Field Length = 2
SIP RTP IPv4 addr = 410
This IPFIX template provides default information of traffic – byte/packet count, IP address, port number and timestamp. Using this template, we can not monitor SIP and RTP traffic because this template does not provide their header information.
So we define 2 IPFIX template for monitoring SIP and RTP traffic.
(Click)This template SIP-related IPFIX template. This template add on some fields of SIP and SDP over default template. From SIP header, we monitor Call-ID and SIP message type, From SDP, we observe information of voice communication session – IP address, port number and voice codec.
(Click)This IPFIX template is for monitoring RTP traffic. This template include RTP header information such as SSRC and sequence number and QoS metrics such as packet loss rate and one-way delay, voice codec
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

14. IPFIX Fields – 802.11 MAC Header Information
MAC First Sequence number = 500
Field Length = 2
MAC Last Sequence number = 501
Source MAC = 56
Fiend Length = 6
Destination MAC = 80
MAC header analysis
Sequence number in MAC header
Source MAC/ Destination MAC address
Not independent template
When traffic measurement is performed at wireless access router, add on these fields in each template
This IPFIX fields are analyzed MAC header. We observe source and destination MAC address, sequence number in MAC header. When traffic measurement is performed at wireless access router, add on these fields in each template. When traffic measurement is performed at wireless access router, we can add on these fields in each template for monitoring MAC header.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

15. CANCEL DoS Anomaly Traffic Detection
Source MAC address
If SRC. MAC address is different with INVITE SIP messages  attack
The possibility of source MAC address spoofing
Need sequence number inspection
Sequence number
Sequence number gap
CANCEL traffic (A)
Last IP packet having the same 4-tuple before CANCEL traffic(B)
Gap = B - A
Sequence number gap >= “N”  attack
In our CANCEL DoS anomaly traffic detection, we use source MAC address and sequence number in MAC header.
First, we match source MAC address between searched CANCEL message and INVITE message which has the same Call-ID and 4-tuple information.
However, an attacker can transmit anomaly traffic spoofed source MAC address. So after source MAC address step, we calculate sequence number gap between CANCEL traffic and last IP packet of the same flow before the CANCEL traffic.
If the gap is over N or the same as N, the searched CANCEL traffic is anomaly.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

16. BYE DoS Anomaly Traffic Detection
In SDP
Include IP address and port number for transmitting RTP traffic
In order to obtain this information
INVITE : source IP address and port number
OK : destination IP address and port number
Timestamp of RTP traffic
In normal state
The RTP traffic is not observed after BYE traffic
In abnormal state
The one-way RTP traffic is observed over constant time after BYE traffic
In SDP, there is session information of transmitting RTP traffic. So we extract this information from INVITE and OK message. From INVITE, source IP address and port number are obtained and destination IP address and port number are obtained from OK message.
From obtained the information, we search timestamp of RTP traffic. The reason of using the timestamp is that RTP traffic is not existed after BYE traffic in normal state.
However, if an attacker generates BYE DoS anomaly traffic, the RTP traffic is observed after BYE traffic.
Call of VoIP user received BYE DoS anomaly traffic is terminated. Since another VoIP user does not know the call termination, the one-way RTP traffic is observed in the VoIP network.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

17. RTP Flooding Detection
SSRC in RTP header
SSRC field in RTP header
Do not change the value in the same call connection
Check ‘SSRC changed count’
If the value of this field > “1”
RTP anomaly traffic
Sequence number in RTP header
Possible to be spoofed SSRC field from normal RTP traffic
Compare Max./Min. and the first / last sequence number
(Min. Seq. < first Seq.) || (Max. Seq. > last Seq.)
No sequence number is wrapped in a RTP flow
(Max. Seq. < first Seq.) || (Min. Seq. > last Seq.)
Sequence number is wrapped in a RTP flow
For detecting RTP flooding traffic, we use SSRC and sequence number of RTP header.
First, we check ‘SSRC changed count’ IPFIX field. Because SSRC value is not changed in the same call connection, if the value of this field is over 1, the RTP anomaly traffic is occurred.
It is possible to be spoofed SSRC field from normal RTP traffic, so we compare sequence number in a RTP flow for detecting RTP anomaly traffic.
For comparing sequence number, we use minimum, maximum, last and first sequence number.
Because range of the sequence number in RTP header is 0 ~ 65535, we propose 2 kinds of sequence number comparison whether the sequence number is wrapped or not.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

18. Experiment Environment
attacker
Wireless access router
VoIP Node 1
Phone number
CNU Network
IPFIX
router
router
HUB
Internet
WLAN Traffic monitor
VoIP anomaly traffic
Korea 070 VoIP Service Provider
VoIP Node 2
Phone Number:
IPFIX flow generator
Modified nProbe[28]
IPFIX flow collector
Modified libipfix[29]
Save traffic monitoring results
Mysql[30]
For experiment in real VoIP network, we used two commercial VoIP phones which number is started 070.
We established wireless access router included two wireless LAN cards. One wireless LAN card is used for access point. Another one is used for monitoring traffic.
In wireless access router, we installed modified nProbe for monitoring VoIP traffic and generating IPFIX flows.
The attacker having two wireless LAN cards established between VoIP Node 1 and wireless access router. One LAN card is used for sniffing VoIP traffic. Another one is used for sending VoIP anomaly traffic to the proxy server in a service provider.
Generated IPFIX flows are transmitted to IPFIX collector. For collecting and decoding IPFIX flows, we use modified libipfix. In addition, the IPFIX collector is installed mysql to save monitoring results.
In addition, our anomaly traffic detection program is installed at the collector. DB
IPFIX
Proxy Server
IPFIX Collector and VoIP anomaly traffic detector
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

19. Evaluation Results CANCEL DoS Detection BYE DoS RTP Flooding
Attack types
Total flows
Anomaly flows
Precision
(%)
Recall
F-Score
CANCEL DoS
381 89
100.00
95.50
97.69
BYE DoS
755
118
97.39
94.92
96.13
RTP Flooding
810
103
96.26
98.09
Total
1,946
310
97.72
96.77
97.24
CANCEL DoS Detection
Sequence number gap : 5 in this experiment
Few CANCEL DoS anomalies are generated over configured sequence number gap
BYE DoS
Constant time : 1 min. in this paper
Sometimes, after normal BYE traffic, few RTP traffic is observed over configured time.
RTP Flooding
Few normal RTP traffic
Be mistaken for anomaly traffic because of wrapping of the sequence number in a RTP flow
Overall detection accuracy of proposed our three VoIP anomaly traffic detection is 97.24%.
In CANCEL DoS anomaly traffic detection, we set sequence number gap as “5”. So few CANCEL DoS anomalies are not detected because the anomaly traffic is generated over our configured sequence number gap.
We configured constant time as 1 minute for detecting BYE DoS anomaly traffic. Sometimes, after normal BYE traffic, few RTP traffic is observed over configured time. Moreover, after BYE DoS anomaly traffic, some RTP traffic is observed in our configured time.
In RTP flooding detection, the accuracy is about 98%. The reason of precision is that few normal RTP traffic was mistaken for anomaly traffic because of wrapping of the sequence number in a RTP flow.
This table represents evaluation results of our detection method.
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

20. Conclusion & Future Work
In this paper, we proposed VoIP anomaly traffic detection method using IPFIX in real VoIP network
Define new IPFIX templates and add IPFIX fields for monitoring traffic
CANCEL DoS detection method
Source MAC address and sequence number in
BYE DoS detection method
SIP header information and timestamp of RTP traffic
RTP flooding method
SSRC and sequence number in RTP header
Future work
Plan to extend our approach to detect other possible VoIP attacks
Devise a protection method against comprehensive IP telephony anomalies
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

21. Reference
[1] VoIP member count in Korea, [2] VoIP member expectation in U.S.A., librarynews 1.php?news id= [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler, SIP: Session Initiation Protocol, IETF RFC3261, June [4] H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, RTP: A Transport Protocol for Real-time Applications, IETF RFC3550, July [5] D. Geneiatakis, T. Dagiuklas, G. Kambourakis, C. Lambrinoudakis, S.Gritzalis, K. S. Ehlert, and D. Sisalem, Survey of security vulnerabilities in session initiation protocol, Communications Surveys & Tutorials, IEEE Volume 8, Issue 3, 3rd. Qtr Page(s): [6] T. Dierks, E. Rescorla, The Transport Layer Security (TLS) Protocol, IETF RFC 5246, Aug [7] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, The Secure Real-time Transport Protocol (SRTP), IETF RFC 3711, Mar [8] H. Sengar, H. Wang, D. Wijesekera, S. Jajodia, Detecting VoIP Floods Using the Hellinger Distance IEEE Transactions on Parallel and Distributed systems, Vol. 19, No. 6, pp , June [9] J. Quittek, T. Zseby, B. Claise and S. Zander, Requreiements for IP Flow Information Export(IPFIX), IETF RFC3917, October [10] S. Anderson, S. Niccolini, and D. Hogrefe, SIPFIX: A Scheme for Distributed SIP Monitoring, IEEE IM2009, [11] H. Sengar, D. Wijesekera, H. Wang, S. Jajodia, VoIP Intrusion Detection Through Interacting Protocol State Machines, IEEE DSN, pp , June [12] F. Guo and T. Chiueh, Sequence Number-Based MAC Address Spoof Detection, in Proceedings of 8th International Symposium on Recent Advances in Intrusion Detection (RAID 2005), September [13] C. Lee, H. Kim, K. Ko, J. Kim, and H. Jeong, A VoiP Traffic Monitoring System based on NetFlow v9, International Journal of Advanced Technology, vol. 4, March [14] Y. Ding and G. Su, Intrusion detection system for signal based SIP attacks through timed HCPN, Second International Conference on Availability, Reliability and Security (ARES), [15] H. Son and Y. Lee, An Anomaly Traffic Detection Method for VoIP Applications using Flow Data, PAM2009 Student Workshop, [16] L. Deri, nProbe: an Open Source NetFlow Probe for Gigabit Networks, TERENA Networking Conference, May [17] libipfix Internet Measurement Project: [18] MySQL,
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)

22. Thank you Q&A
Detecting Anomaly Traffic using Flow Data in the real VoIP network(NETSAP 2010)