Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction
updates
- rfc-3261 — SIP: Session Initiation Protocol
Extracted elements (16)
A 408 response to a non-INVITE will always arrive too late to be useful: the client already has full knowledge of the timeout and cannot act on the information, so 408 responses only waste network resources and contribute to an O(N^2) response storm through N proxies.
Late non-INVITE responses by definition arrive after the client transaction's Timer F has fired and the transaction has entered the Terminated state, making them indistinguishable from strays; prohibiting proxies from forwarding such responses eliminates the late-response storm.
Non-100 provisional responses to non-INVITE requests are disallowed because non-INVITE transactions must complete rapidly; any information beyond 'I'm here' can be just as usefully delayed to the final response, and sending non-100 provisionals wastes bandwidth.
Sending a 100 Trying after Timer E reaches T2 (but not before) prevents blacklisting of a late-responding element without damaging recovery from unreliable transport failure; over reliable transports, sending it well in advance of timeout is sufficient.
Sending any provisional response inside a non-INVITE transaction (NIT) before Timer E reaches T2 damages recovery from failure of an unreliable transport, which is why the 100 Trying is withheld until Timer E reaches T2 for UDP hops.
Standardizing mechanisms to remember non-responsive destinations between non-INVITE transactions (to avoid them with future requests) is left to future work, as it requires more aggressive protocol changes beyond the scope of this document.
A non-INVITE transaction must complete immediately or risk losing a race condition; losing the race causes the requester to temporarily blacklist the responder and stop sending traffic to it, making rapid completion a critical interoperability constraint.
Provisional responses (other than a correctly-timed 100 Trying) on non-INVITE transactions can delay recovery from lost final responses, creating a problematic interaction between provisional response handling and the NIT state machine defined in RFC 3261.
A transaction-stateful SIP element MUST NOT send a response with Status-Code of 408 to a non-INVITE request; as a consequence, an element that cannot respond before the transaction expires will send no final response at all.
A transaction-stateful SIP proxy MUST NOT send any response to a non-INVITE request unless it has a matching server transaction that is not in the Terminated state, thereby preventing forwarding of late non-INVITE responses.
An SIP element MAY respond to a non-INVITE request with a Status-Code of 100 over a reliable transport at any time.
An SIP element MUST NOT respond to a non-INVITE request with a Status-Code of 100 over any unreliable transport (such as UDP) before the amount of time it takes a client transaction's Timer E to be reset to T2.
An SIP element MUST NOT send any provisional response with a Status-Code other than 100 to a non-INVITE request.
Without regard to transport, an SIP element MUST respond to a non-INVITE request with a Status-Code of 100 if it has not otherwise responded after the amount of time it takes a client transaction's Timer E to be reset to T2.
Without the prohibition on 408 responses to non-INVITE transactions, an attacker could entice user agents to send non-INVITE requests to a black hole (via social engineering or DNS poisoning) or selectively drop responses, exploiting the automatic 408 storm to flood the network.
Without the prohibition on forwarding late non-INVITE responses at proxies, an attacker could easily forge messages that appear to be late responses; RFC 3261-compliant proxies are required to forward these, wasting bandwidth and CPU and potentially overwhelming user agents on low-speed connections.