Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
RFC 5393
Document | Type |
RFC - Proposed Standard
(December 2008; No errata)
Updates RFC 3261
|
|
---|---|---|---|
Authors | Robert Sparks , Byron Campen , Scott Lawrence , Alan Hawrylyshen | ||
Last updated | 2018-12-20 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5393 (Proposed Standard) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Cullen Jennings | ||
Send notices to | (None) |
Network Working Group R. Sparks, Ed. Request for Comments: 5393 Tekelec Updates: 3261 S. Lawrence Category: Standards Track Nortel Networks, Inc. A. Hawrylyshen Ditech Networks Inc. B. Campen Tekelec December 2008 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address a security vulnerability identified in SIP proxy behavior. This vulnerability enables an attack against SIP networks where a small number of legitimate, even authorized, SIP requests can stimulate massive amounts of proxy-to-proxy traffic. This document strengthens loop-detection requirements on SIP proxies when they fork requests (that is, forward a request to more than one destination). It also corrects and clarifies the description of the loop-detection algorithm such proxies are required to implement. Additionally, this document defines a Max-Breadth mechanism for limiting the number of concurrent branches pursued for any given request. Sparks, et al. Standards Track [Page 1] RFC 5393 Amplification Vulnerability in SIP December 2008 Table of Contents 1. Introduction ....................................................3 2. Conventions and Definitions .....................................3 3. Vulnerability: Leveraging Forking to Flood a Network ............3 4. Updates to RFC 3261 .............................................7 4.1. Strengthening the Requirement to Perform Loop Detection ....7 4.2. Correcting and Clarifying the RFC 3261 Loop-Detection Algorithm ...................................7 4.2.1. Update to Section 16.6 ..............................7 4.2.2. Update to Section 16.3 ..............................8 4.2.3. Impact of Loop Detection on Overall Network Performance .........................................9 4.2.4. Note to Implementers ................................9 5. Max-Breadth ....................................................10 5.1. Overview ..................................................10 5.2. Examples ..................................................11 5.3. Formal Mechanism ..........................................12 5.3.1. Max-Breadth Header Field ...........................12 5.3.2. Terminology ........................................13 5.3.3. Proxy Behavior .....................................13 5.3.3.1. Reusing Max-Breadth .......................14 5.3.4. UAC Behavior .......................................14 5.3.5. UAS Behavior .......................................14 5.4. Implementer Notes .........................................14 5.4.1. Treatment of CANCEL ................................14 5.4.2. Reclamation of Max-Breadth on 2xx Responses ........14 5.4.3. Max-Breadth and Automaton UAs ......................14 5.5. Parallel and Sequential Forking ...........................15 5.6. Max-Breadth Split Weight Selection ........................15 5.7. Max-Breadth's Effect on Forking-Based Amplification Attacks .....................................15 5.8. Max-Breadth Header Field ABNF Definition ..................16 6. IANA Considerations ............................................16 6.1. Max-Breadth Header Field ..................................16 6.2. 440 Max-Breadth Exceeded Response .........................16Show full document text