Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies
RFC 5393

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 08

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 .........................16