Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP)
obsoleted by
- rfc-5245 — Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols
Extracted elements (12)
Placing sdp-anat in the Require header field (rather than just Supported) ensures that ANAT offers are rejected with a clear 420 Bad Extension response by entities lacking ANAT support, rather than being mishandled silently.
The sdp-anat option-tag was introduced because ANAT-unaware answerers exhibit unpredictable behavior (establishing too many streams, rejecting with non-informative errors) when receiving ANAT-grouped SDP offers, necessitating an explicit capability signal in SIP.
An ANAT-unaware answerer that does not support all network types offered may either establish only understood streams or reject the offer entirely, with error responses unlikely to be explicit enough for the offerer to understand the failure.
An ANAT-unaware answerer that supports all network types offered may accept the offer and establish all media streams, resulting in more streams than the offerer expects and potentially high bandwidth usage.
Many SIP servers do not include an SDP description in responses to OPTIONS requests, making it impossible to discover ANAT support via RFC 3388 grouping attributes alone; the sdp-anat option-tag in a Supported header field solves this discovery problem.
SIP entities generating an offer that uses the ANAT semantics SHOULD place the sdp-anat option-tag in a Require header field.
SIP entities that support the ANAT semantics MUST understand the sdp-anat option-tag.
To avoid DoS and media-stream manipulation attacks, integrity protection of the Require header field is RECOMMENDED. The natural choice is S/MIME.
The sdp-anat option-tag is defined for use in the Require and Supported SIP header fields. SIP user agents that place this option-tag in a Supported header field understand the ANAT semantics as defined in RFC 4091.
This document registers the SIP option-tag 'sdp-anat' in the IANA SIP parameter registry.
An attacker may add the sdp-anat option-tag to the Require header field to perform a DoS attack, causing a UAS without ANAT support to return an error response instead of processing the message.
An attacker may remove the sdp-anat option-tag from the Require header field, potentially resulting in the establishment of too many media streams and high bandwidth usage.