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

Publisher

IETF / RFC Editor

URL

https://www.rfc-editor.org/rfc/rfc5393.html

Published

2008-12-01

Updated

unknown

Accessed

2026-09-25

HTTP status

200

License

IETF Trust; RFC text may be reproduced with attribution under BCP 78; short excerpts and locators only

Source notes citing this source

• Under RFC 5393, a proxy that forks a request to more than one destination must ensure the request is not looping through it; Via-based loop detection is recommended, but other mechanisms are allowed. in context
• RFC 5393 defines a Max-Breadth header field that limits concurrent forked branches for a request, with a recommended initial value of 60. in context
• RFC 5393 does not change RFC 3261's recommended initial Max-Forwards value of 70; it mitigates the amplification that this depth allows by adding loop-detection and Max-Breadth requirements. in context
• RFC 5393 (December 2008, Standards Track) normatively updates RFC 3261 to fix an amplification vulnerability in which forking proxies without loop detection turn a few requests into very large amounts of proxy-to-proxy traffic. in context

Cite this source record

APA

WarmTransfer. (2008, December 1). RFC 5393: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies. WarmTransfer. https://warmtransfer.net/knowledge/sources/ietf-rfc-5393-loop-amplification

BibTeX

@misc{warmtransfer-ietf-rfc-5393-loop-amplification,
  title  = {RFC 5393: Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies},
  author = {{WarmTransfer}},
  year   = {2008},
  url    = {https://warmtransfer.net/knowledge/sources/ietf-rfc-5393-loop-amplification},
  note   = {IETF / RFC Editor, accessed 2026-09-25}
}