idnits 2.17.1 draft-niccolini-speermint-voipthreats-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 841. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 848. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 854. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 374: '...outing Functions MUST support mutual a...' RFC 2119 keyword, line 377: '...outing Functions MUST provide support ...' RFC 2119 keyword, line 380: '...ls used to enable session peering MUST...' RFC 2119 keyword, line 382: '...s that are not understood by SBEs MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2008) is 5656 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3263' is defined on line 688, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-speermint-terminology' is defined on line 711, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: A later version (-17) exists of draft-ietf-speermint-terminology-16 == Outdated reference: A later version (-11) exists of draft-ietf-speermint-requirements-07 -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPEERMINT Working Group S. Niccolini 3 Internet-Draft NEC 4 Intended status: Informational E. Chen 5 Expires: May 4, 2009 NTT 6 J. Seedorf 7 NEC 8 H. Scholz 9 freenet 10 October 31, 2008 12 SPEERMINT Security Threats and Suggested Countermeasures 13 draft-niccolini-speermint-voipthreats-05 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 4, 2009. 40 Abstract 42 This memo presents the different security threats related to 43 SPEERMINT classifying them into threats to the Location Function, to 44 the Signaling Function and to the Media Function. The different 45 instances of the threats are briefly introduced inside the 46 classification. Finally the existing security solutions in SIP and 47 RTP/RTCP are presented to describe the countermeasures currently 48 available for such threats. The objective of this document is to 49 identify and enumerate the SPEERMINT-specific threat vectors in order 50 to specify security-related requirements. Once the requirements are 51 identified, methods and solutions how to achieve such requirements 52 can be selected. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Security Threats relevant to SPEERMINT . . . . . . . . . . . . 5 58 2.1. Threats Relevant to the Look-Up Function (LUF) . . . . . . 5 59 2.1.1. Threats to LUF Confidentiality . . . . . . . . . . . . 5 60 2.1.2. Threats to LUF Integrity . . . . . . . . . . . . . . . 5 61 2.1.3. Threats to LUF Availability . . . . . . . . . . . . . 6 62 2.2. Threats Relevant to the Location Routing Function (LRF) . 6 63 2.2.1. Threats to LRF Confidentiality . . . . . . . . . . . . 6 64 2.2.2. Threats to LRF Integrity . . . . . . . . . . . . . . . 6 65 2.2.3. Threats to LRF Availability . . . . . . . . . . . . . 6 66 2.3. Threats to the Signaling Function (SF) . . . . . . . . . . 7 67 2.3.1. Threats to SF Confidentiality . . . . . . . . . . . . 7 68 2.3.2. Threats to SF Integrity . . . . . . . . . . . . . . . 7 69 2.3.3. Threats to SF Availability . . . . . . . . . . . . . . 8 70 2.4. Threats to the Media Function (MF) . . . . . . . . . . . . 9 71 2.4.1. Threats to MF Confidentiality . . . . . . . . . . . . 9 72 2.4.2. Threats to MF Integrity . . . . . . . . . . . . . . . 9 73 2.4.3. Threats to MF Availability . . . . . . . . . . . . . . 10 74 3. Security Requirements . . . . . . . . . . . . . . . . . . . . 11 75 4. Suggested Countermeasures . . . . . . . . . . . . . . . . . . 12 76 4.1. Database Security . . . . . . . . . . . . . . . . . . . . 13 77 4.2. DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 14 78 4.3. DNS Replication . . . . . . . . . . . . . . . . . . . . . 14 79 4.4. Cross-Domain Privacy Protection . . . . . . . . . . . . . 14 80 4.5. Digest Authentication on all requests in peering 81 agreements . . . . . . . . . . . . . . . . . . . . . . . . 14 82 4.6. Use TCP instead of UDP to deliver SIP messages . . . . . . 14 83 4.7. Ingress Filtering / Reverse-Path Filtering . . . . . . . . 15 84 4.8. Strong Identity Assertion . . . . . . . . . . . . . . . . 15 85 4.9. Reliable Border Element Pooling . . . . . . . . . . . . . 16 86 4.10. Rate limit . . . . . . . . . . . . . . . . . . . . . . . . 16 87 4.11. Border Element Hardening . . . . . . . . . . . . . . . . . 16 88 4.12. SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 4.13. SRTCP . . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 5. Current Deployment of Countermeasures . . . . . . . . . . . . 18 91 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 19 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 93 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 94 9. Informative References . . . . . . . . . . . . . . . . . . . . 22 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 96 Intellectual Property and Copyright Statements . . . . . . . . . . 26 98 1. Introduction 100 With VoIP, the need for security is compounded because there is the 101 need to protect both the control plane and the data plane. In a 102 legacy telephone system, security is a more valid assumption. 103 Intercepting conversations requires either physical access to 104 telephone lines or to compromise the Public Switched Telephone 105 Network (PSTN) nodes or the office Private Branch eXchanges (PBXs). 106 Only particularly security-sensitive organizations bother to encrypt 107 voice traffic over traditional telephone lines. In contrast, the 108 risk of sending unencrypted data across the Internet is more 109 significant (e.g. DTMF tones corresponding to the credit card 110 number). An additional security threat to Internet Telephony comes 111 from the fact that the signaling devices may be addressed directly by 112 attackers as they use the same underlying networking technology as 113 the multimedia data; traditional telephone systems have the signaling 114 network separated from the data network. This is an increased 115 security threat since a hacker could attack the signaling network and 116 its servers with increased damage potential (call hijacking, call 117 drop, DoS attacks, etc.). Therefore there is the need of 118 investigating the different security threats, to extract security- 119 related requirements and to highlight the solutions how to protect 120 from such threats. 122 2. Security Threats relevant to SPEERMINT 124 This section enumerates potential security threats relevant to 125 SPEERMINT. A taxonomy of VoIP security threats is defined in 126 [refs.voipsataxonomy]. Such a taxonomy is really comprehensive and 127 takes into account also non-VoIP-specific threats (e.g. loss of 128 power, etc.). Threats relevant to the boundaries of layer-5 SIP 129 networks are extracted from such a taxonomy and mapped to the 130 classification relevant for the SPEERMINT architecture as defined in 131 [refs.speermintarch], moreover additional threats for the SPEERMINT 132 architecture are listed and detailed under the same classification 133 and according the CIA (Confidentiality, Integrity and Availability) 134 triad: 136 o Look-Up Function (LUF); 138 o Location Routing Function (LRF); 140 o Signaling Function (SF); 142 o Media Function (MF). 144 2.1. Threats Relevant to the Look-Up Function (LUF) 146 If the LUF is hosted locally it is vulnerable to the same threats 147 that affect database systems in general. If the SSP relies on a 148 remote 3rd party to provide the LUF functionality both integrity and 149 authenticity of the responses are at risk. 151 2.1.1. Threats to LUF Confidentiality 153 o SIP URIs and peering domains harvesting - an attacker can exploit 154 this weakness if the underlying database has a weak authentication 155 system, and then use the gained knowledge to launch other kind of 156 attacks. 158 o 3rd party information - a LUF providing information to multiple 159 companies / third parties can attacked to obtain information about 160 third party peering configurations and possible contracts. 162 2.1.2. Threats to LUF Integrity 164 The underlying database could be vulnerable to: 166 o Injection attack - an attacker could manipulate statements 167 performed on the database by the end user. 169 2.1.3. Threats to LUF Availability 171 The underlying database could be vulnerable to: 173 o Denial of Service attacks - e.g. an attacker makes incomplete 174 requests causing the server to create an idle state for each of 175 them causing memory to be exhausted. 177 2.2. Threats Relevant to the Location Routing Function (LRF) 179 2.2.1. Threats to LRF Confidentiality 181 o URI harvesting - the attacker harvests URIs and IP addresses of 182 the existing User Endpoints (UEs) by issuing a multitude of 183 location requests. Direct intrusion against vulnerable UEs or 184 telemarketing are possible attack scenarios that would use the 185 gained knowledge. 187 o SIP device enumeration - the attacker discovers the IP address of 188 each intermediate signaling device by looking at the Via and 189 Record-Route headers of a SIP message. Targeting the discovered 190 devices with subsequent attacks is a possible attack scenario. 192 2.2.2. Threats to LRF Integrity 194 An attacker may feed bogus information to the LRF if the routing data 195 is not correctly validated. Dynamic call routing discovery and 196 establishment, as in the scope of SPEERMINT, introduce opportunities 197 for attacks such as the following. 199 o Man-in-the-Middle attack - the attacker has already or inserts an 200 unauthorized node in the signaling path modifying the SED. The 201 results is that the attacker is then able to read, insert and 202 modify the multimedia communications. 204 o Incorrect destinations - the attacker redirect the calls to a 205 incorrect destination with the purpose of establishing fraud 206 communications like voice phishing or DoS attacks. 208 2.2.3. Threats to LRF Availability 210 The LRF can be object of DoS attacks. DoS attacks to the LRF can be 211 carried out by sending a large number of queries to the LS or Session 212 Manager, SM, with the result of preventing an originating SSP from 213 looking up call routing data of any URI outside its administrative 214 domain. As an alternative the attacker could target the DNS to 215 disable resolution of SIP addresses. 217 2.3. Threats to the Signaling Function (SF) 219 Signaling function involves a great number of sensitive information. 220 Through signaling function, user agents (UA) assert identities and 221 VSP operators authorize billable resources. Correct and trusted 222 operations of signaling function is essential for service providers. 223 This section discusses potential security threats to the signaling 224 function to detail the possible attack vectors. 226 2.3.1. Threats to SF Confidentiality 228 SF traffic is vulnerable to eavesdropping, in particular when the 229 data is moved across multiple SSPs having different levels of 230 security policies. Threats for the SF confidentiality are listed 231 here: 233 o call pattern analysis - the attacker tracks the call patterns of 234 the users violating his/her privacy (e.g. revealing the social 235 network of various users, the daily phone usage, etc.), also rival 236 SSPs may infer information about the customer base of other SSPs 237 in this way; 239 o Password cracking - challenge-response authentication mechanism of 240 SIP is not secure if the attacker is able to eavesdrop a 241 sufficient number of SIP authentication messages exchanged between 242 a SIP server and a SIP client. 244 2.3.2. Threats to SF Integrity 246 The integrity of the SF can be violated using SIP request spoofing, 247 SIP reply spoofing and SIP message tampering. 249 2.3.2.1. SIP Request Spoofing 251 Most SIP request spoofing require first a SIP message eavesdropping 252 but some of the them could be also performed by guessing or 253 exploiting broken implementations. Threats in this category are: 255 session teardown - the attacker uses CANCEL/BYE messages in order 256 to tear down an existing call at SIP layer, it is needed that the 257 attacker replicates the proper SIP header for the hijacking to be 258 successful (To, From, Call-ID, CSeq); 260 REGISTER spoofing - the attacker forges a REGISTER request and 261 register a bogus contact information with the objective of 262 hijacking incoming calls. 264 Billing fraud - the same attack as in the case of the REGISTER 265 spoofing may lead an attacker to be able to direct billing for 266 calls to the victim UE and avoid paying for the phone calls; 268 user ID spoofing - SSPs are responsible for asserting the 269 legitimacy of user ID; if an SSP fails to achieve the level of 270 identity assertion that the federation it belongs expects, it may 271 create an entry point for attackers to conduct user ID spoofing 272 attacks. 274 2.3.2.2. SIP Reply Spoofing 276 Threats in this category are: 278 Forged 200 Response - the attacker sends a forged CANCEL request 279 to terminate a call in progress tricking the terminating UE to 280 believe that the originating UE actually sent it, and successfully 281 hijacks a call sending a forged 200 OK message to the originating 282 UE communicating the address of the rogue UE under the attacker's 283 control; 285 Forged 302 Response - the attacker sends a forged "302 Moved 286 Temporarily" reply instead of a 200 OK, this enables the attack to 287 hijack the call and to redirect it to any destination UE of his 288 choosing; 290 Forged 404 Response - the attacker sends a forged "404 Not Found" 291 reply instead of a 200 OK, this enables the attack to disrupt the 292 call establishment; 294 2.3.2.3. SIP Message Tampering 296 This threat involves the alternation of important field values in a 297 SIP message or in the SDP body. Examples of this threat could be the 298 dropping or modification of handshake packets in order to avoid the 299 establishment of a secure RTP session (SRTP). The same approach 300 could be used to degrade the quality of media session by letting UE 301 negotiate a poor quality codec. 303 2.3.3. Threats to SF Availability 305 o Flooding attack - a SBE is susceptible to message flooding attack 306 that may come from interconnected SSPs; 308 o Session Black Holing - the attacker (assumed to be able to make 309 Man-in-the-Middle attacks) intentionally drops essential packets, 310 e.g. INVITEs, to prevent certain calls from being established; 312 o SIP Fuzzing attack - fuzzing tests and software can be used by 313 attackers to discover and exploit vulnerabilities of a SIP entity, 314 this attack may result in crashing SIP entity. 316 2.4. Threats to the Media Function (MF) 318 The Media function (MF) is responsible for the actual delivery of 319 multimedia communication between the users and carries sensitive 320 information. Through media function, UE can establish secure 321 communications and monitor quality of conversations. Correct and 322 trusted operations of MF is essential for privacy and service 323 assurance issues. This section discusses potential security threats 324 to the MF to detail the possible attack vectors. 326 2.4.1. Threats to MF Confidentiality 328 The MF is vulnerable to eavesdropping in which the attacker may 329 reconstruct the voice conversation or sensitive information (e.g. 330 PIN numbers from DTMF tones). SRTP and ZRTP are vulnerable to bid- 331 down attacks, i.e. by selectively dropping key exchange protocol 332 packets may result in the establishment of a non-secure 333 communications. 335 2.4.2. Threats to MF Integrity 337 Both RTP and RTCP are vulnerable to integrity violation in many ways: 339 o Media Hijack - if an attacker can somehow detect an ongoing media 340 session and eavesdrop a few RTP packets, he can start sending 341 bogus RTP packets to one of the UEs involved using the same codec. 342 As illustrated in Fig. 8, if the bogus RTP packets have 343 consistently greater timestamps and sequence numbers (but within 344 the acceptable range) than the legitimate RTP packets, the 345 recipient UE may accept the bogus RTP packets and discard the 346 legitimate ones. 348 o Media Session Teardown - the attacker sends bogus RTCP BYE 349 messages to a target UE signaling to tear down the media 350 communication, please note that RTCP messages are normally not 351 authenticated. 353 o QoS degradation - the attacker sends wrong RTCP reports 354 advertising more packet loss or more jitter than actually 355 experimented resulting in the usage of a poor quality codec 356 degrading the overall quality of the call experience. 358 2.4.3. Threats to MF Availability 360 o Malformed messages - the attacker tries to cause a crash or a 361 reboot of the DBE/UE by sending RTP/RTCP malformed messages; 363 o Messages flooding - the attacker tries to exhaust the resources of 364 the DBE/UE by sending many RTP/RTCP messages. 366 3. Security Requirements 368 The security requirements for SPEERMINT have been moved from an 369 earlier version of this draft to the SPEERMINT requirements draft 370 [I-D.ietf-speermint-requirements]. These security requirements are 371 the following [I-D.ietf-speermint-requirements]: 373 o Requirement #15: The protocols used to query the Lookup and 374 Location Routing Functions MUST support mutual authentication. 376 o Requirement #16: The protocols used to query the Lookup and 377 Location Routing Functions MUST provide support for data 378 confidentiality and integrity 380 o Requirement #17: The protocols used to enable session peering MUST 381 NOT interfere with the exchanges of media security attributes in 382 SDP. Media attribute lines that are not understood by SBEs MUST 383 be ignored and passed along the signaling path untouched. 385 The security requirements are currently being finalized and this 386 creates a dependency for this draft. As soon as they will be mature 387 and stable enough this section will provide a mapping of concrete 388 solutions and protocols to meet them. 390 4. Suggested Countermeasures 392 This section describes implementer-specific countermeasures against 393 the threats described in the previous section to supplement the 394 security requirements described in [I-D.ietf-speermint-requirements]. 396 The following table provides a map of the relationships between 397 threats and countermeasures. The suggested countermeasures are 398 discussed in detail in the subsequent subsections. 400 +-------+---------------+-------------------------------------------+ 401 | Group | Threat | Suggested Countermeasure | 402 +-------+---------------+-------------------------------------------+ 403 | LUF | Unauthorized | database BCPs | 404 | | access | | 405 | | | | 406 | | SQL injection | database BCPs | 407 | | | | 408 | | DoS to LUF | database BCPs | 409 | | | | 410 | | | | 411 | LRF | URI | DNSSEC (Section 4.2) | 412 | | harvesting | | 413 | | | | 414 | | SIP equipment | DNSSEC, privacy protection (Section 4.4) | 415 | | enumeration | | 416 | | | | 417 | | MitM attack | DNSSEC | 418 | | | | 419 | | Incorrect | DNSSEC | 420 | | destinations | | 421 | | | | 422 | | DoS to LRF | DNS replication (Section 4.3) | 423 | | | | 424 | | | | 425 | SF | Call pattern | TLS | 426 | | analysis | | 427 | | | | 428 | | Password | TLS | 429 | | cracking | | 430 | | | | 431 | | Session | TLS, TCP (Section 4.6), digest | 432 | | teardown | authentication (Section 4.5), ingress | 433 | | | filtering (Section 4.7) | 434 | | | | 435 | | REGISTER | digest authentication | 436 | | spoofing | | 437 | | | | 438 | | Billing fraud | digest authentication | 439 | | | | 440 | | User ID | strong identity assertioan (Section 4.8) | 441 | | spoofing | | 442 | | | | 443 | | Forged 200 | TLS, TCP, ingress filtering | 444 | | Response | | 445 | | | | 446 | | Forged 302 | TLS, TCP, ingress filtering | 447 | | Response | | 448 | | | | 449 | | Forged 404 | TLS, TCP, ingress filtering | 450 | | Response | | 451 | | | | 452 | | Flooding | reliable border element pooling | 453 | | attack | (Section 4.9), rate limit (Section 4.10) | 454 | | | | 455 | | Session black | DNSSEC | 456 | | holing | | 457 | | | | 458 | | SIP fuzzing | border element hardening (Section 4.11) | 459 | | attack | | 460 | | | | 461 | | | | 462 | MF | Eavesdropping | SRTP (Section 4.12) | 463 | | | | 464 | | Media hijack | SRTP | 465 | | | | 466 | | Media session | SRTCP (Section 4.13) | 467 | | teardown | | 468 | | | | 469 | | QoS | SRTCP | 470 | | degradation | | 471 | | | | 472 | | Malformed | border element hardening | 473 | | messages | | 474 | | | | 475 | | Message | rate limit | 476 | | flooding | | 477 +-------+---------------+-------------------------------------------+ 479 4.1. Database Security 481 Adequate security measures must be applied to the LUF to prevent it 482 from being a target of attacks often seen on common database systems. 483 Common security Best Current Practices (BCPs) for database systems 484 include the use of strong passwords to prevent unauthorized access, 485 parameterized statements to prevent SQL injections and server 486 replication to prevent any database from being a single point of 487 failure. [refs.dbsec] is one of many existing literatures that 488 describe BCPs in this area. 490 4.2. DNSSEC 492 If DNS is used by the LRF, it is recommended to deploy the recent 493 version of Domain Name System Security Extensions (informally called 494 "DNSSEC-bis") defined by [RFC4033][RFC4034][RFC4035] to enhance the 495 security of DNS data using strong cryptography. DNSSEC provides 496 authentication to defend against URI harvesting, SIP equipment 497 enumeration, as well as integrity checking to defend against MitM 498 attacks, session blackholing and other attacks that lead traffic to 499 incorrect destinations. 501 4.3. DNS Replication 503 DNS replication is a very important countermeasure to mitigate DoS 504 attacks on LRF. Simultaneously bringing down multiple DNS servers 505 that support LRF is much more challenging than attacking a sole DNS 506 server (single point of failure). 508 4.4. Cross-Domain Privacy Protection 510 Stripping Via and Record-Route headers, replacing the Contact header, 511 and even changing Call-IDs are the mechanisms described in [RFC3323] 512 to protect SIP privacy. This practice allows an SSP to hide its SIP 513 network topology, prevents intermediate signaling equipment from 514 becoming the target of DoS attacks, as well as protects the privacy 515 of UEs according to their preferences. This practice is effective in 516 preventing SIP equipment enumeration that exploits LRF. 518 4.5. Digest Authentication on all requests in peering agreements 520 Digest authentication [RFC2617] is commonly used to challenge 521 REGISTER and INVITE requests in order to prevent REGISTER spoofing 522 and billing fraud. However, it is recommended to apply digest 523 authentication to all SIP requests in peering agreements, especially 524 BYE and CANCEL requests, to prevent session teardown as well. 526 4.6. Use TCP instead of UDP to deliver SIP messages 528 SIP clients need to stay connected with the server on a persistent 529 basis (differently from HTTP clients). Scalability requirements are 530 therefore much more stringent for a SIP server than for a web server. 531 This leads to the choice of UDP as protocol used between SSPs to 532 carry SIP messages (especially for providers with a large user 533 community). New improvements in the Linux kernel 535 [refs.tcp-scalability] show a big increase of the scalability of TCP 536 in handling large number of persistent (but idle) connections. 537 Therefore SSP operators still using UDP for their SIP network should 538 consider switching to TCP. This would significantly increase the 539 difficulty of performing session teardown and forging responses (200, 540 302, 404 etc). Since look-up and SED data should be exchanged 541 securely (see security requirements), it is further recommended to 542 not only use TCP but TLS for messages exchanged between SSPs. 544 4.7. Ingress Filtering / Reverse-Path Filtering 546 Ingress filtering, i.e., blocking all traffic coming from a host that 547 has a source address different than the addresses that have been 548 assigned to that host (see [RFC2827]) can effectively prevent UEs 549 from sending packets with a spoofed source IP address. This can be 550 achieved by reverse-path filtering, i.e., only accepting ingress 551 traffic if responses would take the same path. This practice is 552 effective in preventing session teardown and forged SIP replies (200, 553 302, 404 etc), if the recipient correctly verifies the source IP 554 address for the authenticity of each incoming SIP message. 556 4.8. Strong Identity Assertion 558 "Caller ID spoofing" can be achieved thanks to the weak identity 559 assertion on the From URI of an INVITE request. In a single SSP 560 domain, strong identity assertion can be easily achieved by 561 authenticating each INVITE request. However, in the context of 562 SPEERMINT, only the originating SSP is able to verify the identity 563 directly. In order to overcome this problem there are currently only 564 two major approaches: transitive trust and cryptographic signature. 565 The transitive trust approach builds a chain of trust among different 566 SSP domains. One example of this approach is a combined mechanism 567 specified in [RFC3324] and [RFC3325]. Using this approach in a 568 transit peering network scenario, the terminating SSP must establish 569 a trust relationship with all SSP domains on the path, which can be 570 seen as an underlying weakness. The use of cryptographic signatures 571 is an alternative approach. "SIP Authenticated Identity Body (AIB)" 572 is specified in [RFC3893]. [RFC4474] introduces two new header 573 fields IDENTITY and IDENTITY-INFO that allow a SIP server in the 574 originating SSP to digitally sign an INVITE request after 575 authenticating the sending UE. The terminating SSP can verify if the 576 INVITE request is signed by a trusted SSP domain. Although this 577 approach does not require the terminating SSP to establish a trust 578 relationship with all transit SSPs on the path, a PKI infrastructure 579 is assumed to be in place. 581 4.9. Reliable Border Element Pooling 583 It is advisable to implement reliable pooling on border elements. An 584 architecture and protocols for the management of server pools 585 supporting mission-critical applications are addressed in the 586 RSERPOOL WG. Using this mechanism (see [RFC3237] for requirements), 587 a UE can effectively increase its capacity in handling flooding 588 attacks. 590 4.10. Rate limit 592 Flooding attacks on SF and MF can also be mitigated by limiting the 593 rate of incoming traffic through policing or queuing. In this way 594 legitimate clients can be denied of the service since their traffic 595 may be discarded. Rate limiting can also be applied on a 596 per-source-IP basis under the assumption that the source IP of each 597 attack packet is not spoofed dynamically and will all the limitations 598 related to NAT and mobility issues. It may be preferable to limit 599 the number of concurrent 'sessions', i.e., ongoing calls instead of 600 the messaging associated with it (since session use more resources on 601 backend-systems). When calculating rate limits all entities along 602 the session path should be taken into account. SIP entities on the 603 receiving end of a call may be the limiting factor (e.g., the number 604 of ISDN channels on PSTN gateways) rather than the ingress limiting 605 device. 607 4.11. Border Element Hardening 609 To prevent fuzzing attacks on SPEERMINT border elements these 610 implementations should be security hardened. For instance, fuzz 611 testing is a common black box testing technique used in software 612 engineering. Also, security vulnerability tests can be carried out 613 preventively to assure a UE/SBE/DBE can handle unexpected data 614 correctly without crashing. [RFC4475] and [refs.protos] are examples 615 of torture test cases specific for SIP devices and freely available 616 security testing tools, respectively. These type of tests needs to 617 be carried out before product release and in addition throughout the 618 product life cycle. 620 4.12. SRTP 622 Secure Real-time Transport Protocol (SRTP) adds security features to 623 plain RTP by mainly providing encryption using AES to prevent 624 eavesdropping. It also uses HMAC-SHA1 and index keeping to enable 625 message authentication/integrity and replay protection required to 626 prevent media hijack attacks. 628 4.13. SRTCP 630 Secure RTCP (SRTCP) provides the same security-related features to 631 RTCP as SRTP does for RTP. SRTCP is described in [RFC3711] as 632 optional. In order to prevent media session teardown, it is 633 recommended to turn this feature on. 635 5. Current Deployment of Countermeasures 637 At the time of writing this document not all suggested 638 countermeasures are widely deployed. In particular, the following 639 measures to prevent attacks suggested in section Section 4 have not 640 seen wide deployment: 642 o DNSSEC 644 o Digest authentication on all requests in peering agreements 646 Nevertheless, these protocols and solutions can provide effective 647 means for preventing some of the attacks with respect to the 648 SPEERMINT architecture described in this document. It is envisioned 649 that these countermeasures will be more widely deployed in the 650 future. Therefore, these mechanisms are listed in this document even 651 though they are not widely deployed today. 653 6. Conclusions 655 This memo presented the different SPEERMINT security threats 656 classified in groups related to the LUF, LRF, SF and MF respectively. 657 The multiple instances of the threats are presented with a brief 658 explanation. Afterwards the suggested countermeasures for SPEERMINT 659 were outlined together with possible mitigation of the existing 660 threats by means of them. 662 7. Security Considerations 664 This memo is entirely focused on the security threats for SPEERMINT. 666 8. Acknowledgements 668 This memo takes inspiration from VOIPSA VoIP Security and Privacy 669 Threat Taxonomy. The authors would like to thank VOIPSA for having 670 produced such a comprehensive taxonomy which is the starting point of 671 this draft. The authors would also like to thank Cullen Jennings for 672 the useful slides presented at the VoIP Management and Security 673 workshop in Vancouver. Further, the authors thank Hendrik Scholz for 674 providing extensive and very helpful comments to this draft. 676 9. Informative References 678 [refs.voipsataxonomy] 679 Zar, J. and et al, "VOIPSA VoIP Security and Privacy 680 Threat Taxonomy", October 2005. 682 [refs.speermintarch] 683 Penno, R., Malas, D., Khan, S., and A. Uzelac, "SPEERMINT 684 Peering Architecture", 685 draft-ietf-speermint-architecture-04.txt (work in 686 progress), August 2007. 688 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 689 Protocol (SIP): Locating SIP Servers", RFC 3263, 690 June 2002. 692 [refs.zrtp] 693 Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: 694 Extensions to RTP for Diffie-Hellman Key Agreement for 695 SRTP", draft-zimmermann-avt-zrtp-04.txt (work in 696 progress), July 2007. 698 [refs.tlsbis] 699 Dierks, T. and E. Rescorla, "The TLS Protocol Version 700 1.2", draft-ietf-tls-rfc4346-bis-09.txt (work in 701 progress), February 2008. 703 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 704 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 705 RFC 3711, March 2004. 707 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 708 Authenticated Identity Management in the Session 709 Initiation Protocol (SIP)", RFC 4474, August 2006. 711 [I-D.ietf-speermint-terminology] 712 Malas, D. and D. Meyer, "SPEERMINT Terminology", 713 draft-ietf-speermint-terminology-16 (work in progress), 714 February 2008. 716 [I-D.ietf-speermint-requirements] 717 Mule, J., "SPEERMINT Requirements for SIP-based Session 718 Peering", draft-ietf-speermint-requirements-07 (work in 719 progress), October 2008. 721 [refs.dbsec] 722 Gertz, M. and S. Jajodia, "Handbook of Database Security". 724 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 725 Rose, "DNS Security Introduction and Requirements", 726 RFC 4033, March 2005. 728 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 729 Rose, "Resource Records for the DNS Security Extensions", 730 RFC 4034, March 2005. 732 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 733 Rose, "Protocol Modifications for the DNS Security 734 Extensions", RFC 4035, March 2005. 736 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 737 Initiation Protocol (SIP)", RFC 3323, November 2002. 739 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 740 Leach, P., Luotonen, A., and L. Stewart, "HTTP 741 Authentication: Basic and Digest Access Authentication", 742 RFC 2617, June 1999. 744 [refs.tcp-scalability] 745 Shemyak, K., "Scalability of TCP Servers, Handling 746 Persistent Connections". 748 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 749 Defeating Denial of Service Attacks which employ IP Source 750 Address Spoofing", BCP 38, RFC 2827, May 2000. 752 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 753 Identity", RFC 3324, November 2002. 755 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 756 Extensions to the Session Initiation Protocol (SIP) for 757 Asserted Identity within Trusted Networks", RFC 3325, 758 November 2002. 760 [RFC3893] Peterson, J., "Session Initiation Protocol (SIP) 761 Authenticated Identity Body (AIB) Format", RFC 3893, 762 September 2004. 764 [RFC3237] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., 765 Loughney, J., and M. Stillman, "Requirements for Reliable 766 Server Pooling", RFC 3237, January 2002. 768 [refs.protos] 769 Wieser, C., "SIP Robustness Testing for Large-Scale Use". 771 [RFC4475] Sparks, R., Hawrylyshen, A., Johnston, A., Rosenberg, J., 772 and H. Schulzrinne, "Session Initiation Protocol (SIP) 773 Torture Test Messages", RFC 4475, May 2006. 775 Authors' Addresses 777 Saverio Niccolini 778 NEC Laboratories Europe, NEC Europe Ltd. 779 Kurfuersten-Anlage 36 780 Heidelberg 69115 781 Germany 783 Phone: +49 (0) 6221 4342 118 784 Email: niccolini@nw.neclab.eu 785 URI: http://www.nw.neclab.eu 787 Eric Chen 788 Information Sharing Platform Laboratories, NTT 789 3-9-11 Midori-cho 790 Musashino, Tokyo 180-8585 791 Japan 793 Email: eric.chen@lab.ntt.co.jp 794 URI: http://www.ntt.co.jp/index_e.html 796 Jan Seedorf 797 NEC Laboratories Europe, NEC Europe Ltd. 798 Kurfuersten-Anlage 36 799 Heidelberg 69115 800 Germany 802 Phone: +49 (0) 6221 4342 221 803 Email: seedorf@nw.neclab.eu 804 URI: http://www.nw.neclab.eu 806 Hendrik Scholz 807 freenet Cityline GmbH 808 Am Germaniahafen 1-7 809 Kiel 24143 810 Germany 812 Phone: +49 (0) 431 9020 552 813 Email: hendrik.scholz@freenet.ag 814 URI: http://freenet.ag 816 Full Copyright Statement 818 Copyright (C) The IETF Trust (2008). 820 This document is subject to the rights, licenses and restrictions 821 contained in BCP 78, and except as set forth therein, the authors 822 retain all their rights. 824 This document and the information contained herein are provided on an 825 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 826 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 827 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 828 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 829 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 830 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 832 Intellectual Property 834 The IETF takes no position regarding the validity or scope of any 835 Intellectual Property Rights or other rights that might be claimed to 836 pertain to the implementation or use of the technology described in 837 this document or the extent to which any license under such rights 838 might or might not be available; nor does it represent that it has 839 made any independent effort to identify any such rights. Information 840 on the procedures with respect to rights in RFC documents can be 841 found in BCP 78 and BCP 79. 843 Copies of IPR disclosures made to the IETF Secretariat and any 844 assurances of licenses to be made available, or the result of an 845 attempt made to obtain a general license or permission for the use of 846 such proprietary rights by implementers or users of this 847 specification can be obtained from the IETF on-line IPR repository at 848 http://www.ietf.org/ipr. 850 The IETF invites any interested party to bring to its attention any 851 copyrights, patents or patent applications, or other proprietary 852 rights that may cover technology that may be required to implement 853 this standard. Please address the information to the IETF at 854 ietf-ipr@ietf.org.