Network Working Group T. Zourzouvillys Internet-Draft VoIP.co.uk Intended status: Informational March 2, 2009 Expires: September 3, 2009 Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Servers draft-zourzouvillys-sip-via-cookie-02 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 3, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document addresses a vulnerability in publicly accessible SIP servers (servers includes both UASes and proxies) that enables them Zourzouvillys Expires September 3, 2009 [Page 1] Internet-Draft SIP Via Cookie March 2009 to be used as an amplifier in an untracable reflected denial of service attack. The amplification ratio is between 1:10 to over 1:350 in both packets and bytes. As a proposed solution, a mechanism for stateless cookie exchange between a SIP server and client to ensure that a public SIP server that wishes to accept SIP requests from hosts over datagram can not be used as an amplifier for a denial of service attack. This brings SIP over datagram transports (such as UDP) in line with TCP in terms of routability to the source IP address. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Vulnerability: Using SIP servers to reflect and amplify a UDP packet . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Proposed Solution: Cookie value in Via header . . . . . . . . 9 4.1. Overview of Operation . . . . . . . . . . . . . . . . . . 10 4.2. Client Behaviour . . . . . . . . . . . . . . . . . . . . . 11 4.3. Server Behaviour . . . . . . . . . . . . . . . . . . . . . 11 4.4. Stateless Cookie Generation . . . . . . . . . . . . . . . 12 4.4.1. Cookie Lifetime . . . . . . . . . . . . . . . . . . . 13 4.4.2. Key Generation . . . . . . . . . . . . . . . . . . . . 13 4.5. Parameter Definition . . . . . . . . . . . . . . . . . . . 14 4.6. Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Additional Behaviour . . . . . . . . . . . . . . . . . . . . . 14 5.1. General Server Behaviour . . . . . . . . . . . . . . . . . 14 5.2. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . 15 5.3. UAS Behaviour . . . . . . . . . . . . . . . . . . . . . . 15 6. Other Solutions . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Deprecate UDP transports . . . . . . . . . . . . . . . . . 15 6.2. Use Digest Authentication . . . . . . . . . . . . . . . . 15 6.3. Use a new authentication scheme . . . . . . . . . . . . . 16 6.4. Re-engineer the internet . . . . . . . . . . . . . . . . . 16 6.5. Rate Limit . . . . . . . . . . . . . . . . . . . . . . . . 16 6.6. Use Identity . . . . . . . . . . . . . . . . . . . . . . . 16 6.7. Listen for hints something is wrong . . . . . . . . . . . 17 6.8. Have a UAC CANCEL any unsolicited responses . . . . . . . 17 6.9. Only apply cookie to INVITE . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8.1. cookie parameter . . . . . . . . . . . . . . . . . . . . . 18 8.2. 4XX Via Cookie Required . . . . . . . . . . . . . . . . . 19 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 10. Normative References . . . . . . . . . . . . . . . . . . . . . 19 Zourzouvillys Expires September 3, 2009 [Page 2] Internet-Draft SIP Via Cookie March 2009 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Zourzouvillys Expires September 3, 2009 [Page 3] Internet-Draft SIP Via Cookie March 2009 1. Introduction Because SIP can be used over a datagram transport (such as UDP), any SIP server that processes requests (servers includes UASes and proxies) received from sources that can not be verified (such as the general internet) can be used in an amplification attack where an attacker can send a SIP request with the source address spoofed to be that of a victim. The SIP server then sends a far larger number of responses to the victim than the attacker sent to the server due to server transaction mechanisms used in SIP requests received over unreliable transports. Note that the victim does not need to be a SIP element. As responses are sent using UDP, they can be directed at any target with IP connectivity. Indeed, a victim does not even need to have any ports open to be attacked. Firewalls or NAT gateways will not protect a victim against this attack: the sheer number of packets an attacker can generate with ease will commonly result in connectivity to the victim being saturated. To aid in mitigating this amplification attack, a new SIP Via parameter, "cookie" is defined which allows a stateless cookie exchange to occur and a client demonstrate to a server it is capable of receiving responses on the apparent source address/port and can process those responses. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The terms "server" and "client" in this document are used to refer to logical components comprising of {address, port, transport} triples within a SIP element rather than a transaction or UA server or client. These logical components are located within any SIP element, be it a proxy (stateless or stateful), UA, redirect server, or B2BUA. 3. Vulnerability: Using SIP servers to reflect and amplify a UDP packet This section describes setting up an attack on a victim over the public internet using a publicly accessible stateful SIP server (e.g, a proxy or User Agent) that has been configured to process requests without authentication - for example a proxy responsible for a URI listed in a public ENUM record. Zourzouvillys Expires September 3, 2009 [Page 4] Internet-Draft SIP Via Cookie March 2009 Consider a SIP proxy (P1) that is authoritative for example.com. It is configured to process SIP requests received from the public internet over UDP and TCP, and forward those requests statefully to the users it serves. An attacker can craft an INVITE request (F1) and sent it to P1, with the source IP address of a victim. P1 will receive the request, and then send a 100 Processing response (F2) to the apparent source of the address, the victim. Assuming that the R-URI is the INVITE is valid, the call may progress, resulting in zero or more provisional responses before a 2xx class response when the call is answered. At this point, Alice's UA will start transmitting RTP to the victim, and continue to retransmit the SIP responses (F4). Undoubtedly after a few seconds of Alice not getting a response after she answered the call, she will hang up. This will cause the RTP to stop being transmitted, but will generate a BYE request (F5) from P1 to the Victim. F5 will be transmitted to Victim a total of 12 times using the default timers specified in RFC 3261. Adding all of these requests together, we come to a minimum of 22 messages (1 for the 100, 1 or more for a 180, and 10 for the 200 OK, and 10 BYE requests), all sent to the Victim from a single spoofed UDP request sent by the Attacker. Additionally, an attacker could use a UAS that implements 1xx-rel as the R-URI in the request, resuling in a flurry of 1xx retransmits. This adds another 10 messages on to the amplification, resuling in 32 messages from a single spoofed UDP request. In addition to signalling messages, a large number of RTP packets may be sent once the call is answered on the UAS side, until T1 * 64 expires and the call disconnected. This would be a paticularly effective attack if the attacker could direct the spoofed requests at a service that auto answers calls (e.g, voicemail). F1 INVITE Attacker -> P1 INVITE sip:alice@atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport Call-ID: abcdef From: ;tag=x To: sip:z@f.com CSeq: 1 INVITE Zourzouvillys Expires September 3, 2009 [Page 5] Internet-Draft SIP Via Cookie March 2009 Content-Type: application/sdp Contact: v=0 o=- 1 1 IN IP4 192.0.2.1 s=- c=IN IP4 192.0.2.1 t=0 0 m=audio 1234 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 100 Trying P1 -> Victim SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport=5060 Call-ID: abcdef From: ;tag=1 To: ;tag=abcdefg CSeq: 1 INVITE F3 180 Ringing P1 -> Victim SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport=5060 Call-ID: abcdef From: ;tag=1 To: ;tag=abcdefg CSeq: 1 INVITE F4 200 OK P1 -> Victim SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport=5060 Call-ID: abcdef From: ;tag=1 To: ;tag=abcdefg CSeq: 1 INVITE Contact: Content-Type: application/sdp v=0 o=- 1 1 IN IP4 192.0.2.1 s=- Zourzouvillys Expires September 3, 2009 [Page 6] Internet-Draft SIP Via Cookie March 2009 c=IN IP4 192.0.2.1 t=0 0 m=audio 1234 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F5 BYE P1 -> Victim BYE sip:192.0.2.1:5060 SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK74bf9;rport=5060 Call-ID: abcdef From: ;tag=1 To: ;tag=abcdefg Additionally, if F1 contained a 100rel extension and the target supported it, a flurry of re-transmits of the reliable 1xx response would also be transmitted to the victim in addition to the 2xx responses and BYE retransmits. The scenario layed out above assumes that an attacker knows a valid R-URI that can be used as the reflector. These URIs could be collected by harvesting addresses found on the World Wide Web in the same way as spammers do for email addresses, or perhaps more simply by walking the global e164.arpa tree or private ones. An attacker could also perform a dictionary attack to try and solicit some valid addresses. However, even in the case of a failure response in the dictionary example presented above, a single request will still generate 11 responses if any part of the processing of the request results in the request needing to be handled statelessly (for example, a proxy forwarding the response to a next-hop address establishes by performing an SRV lookup that resulted in multiple potential targets) due to timer G. This problem is not unique to INVITE requests. There are a number of attack vectors in processing non-INVITE requests too. The most notable being a SUBSCRIBE generating a response along with a NOTIFY and it's associated retransmits. An spoofed OPTIONS request without an SDP offer will also potentially result in a larger response being sent back, allowing a reflected amplification attack. Zourzouvillys Expires September 3, 2009 [Page 7] Internet-Draft SIP Via Cookie March 2009 3.1. Analysis In the "best" case scenario, an attacker would need to send 1/10th the number of packets to a vulnerable SIP server than he wants the victim to receive. Commonly, an attacker would only need to send 1/33rd of the number of packets than he wants to victim to receive. The pathological case is in excees of 1/330th. Note that the above is only the number of packets, not the number of bytes. For the "best" case scenario, an attacker will get an average of 1:12 amplification. commonly around 1:50 if a target URI is known and can be made to ring (for example, a voicemail or auto-attendant server), and the pathological case in excess of 1:350 (meaning for every 1MB of data the attacker transmited, the victim would receive 350MB) due to RTP sent from the callee to the victim. The above figures were calculated in the "best" case scenario using a very small (but valid) SIP request: INVITE sip:x.x.x.x SIP/2.0 v:SIP/2.0/UDP xxx.com;branch=z9hG4bK1;rport f:sip:x@x.ie;tag=x t:sip:t@d.xx i:x m: sip:192.0.2.1 CSeq:1 INVITE A selection of commonly used SIP servers (gateways, PBXes, and phone) tested returned responses in the range of 241 bytes through 434 bytes, with the average being 337. However, a 481 response solicited a slightly higher response size on average, because of the reason phrase being longer. Other "tricks" may be used to force larger responses: sending an invalid Accept or Require header resulted in a number of stacks sending back larger responses, as may sending invalid media line in SDP, which results in a 606 or 488 with an entire SDP response, with one device sending back 988 bytes in response to a 207 byte request: an amplification of almost 5x, and combined with IST retries, resulted in a 1:50 amplification. Note that it would be in favour of the attacker to try and make the failure responses as large as possible: this can easily be achived by padding headers copied frmo the request into the response with junk - for example, using a long Call-ID, Via branch, From and To display- name, URI etc. Zourzouvillys Expires September 3, 2009 [Page 8] Internet-Draft SIP Via Cookie March 2009 In the pathological case, a SIP URI found in ENUM was called. An auto-attendant answered, and transmitted RTP for 32 seconds, before transmitting (and re-transmitting) a BYE. Note here that an attacker could manipulate media to request higher rate codecs, video, or even multiple media lines, should the UAS support it. Carefuly crafted requests could allow an attacker to make an amplifier launch an attack on itself, by spoofing the source of the request to be that of another UDP service which returns data to a UDP packet, for example DNS. While the DNS response may be small, a 1:11 amplification in terms of packets count could be used to take out a SIP server by an attacker. 4. Proposed Solution: Cookie value in Via header SIP devices will only forward requests which arrive containing a valid cookie. Initial requests without such a cookie will be rejected (4xx) message and the original request is then re-sent with a valid cookie. Thus the sender's IP address is verified. The exchange of the cookie between a server and a client is on a hop- by-hop basis in a via header field parameter. A server may use cryptographic hashes to generate stateless cookies than can be verified without storing any state between requests. Zourzouvillys Expires September 3, 2009 [Page 9] Internet-Draft SIP Via Cookie March 2009 Client Server | | |(1) INVITE | | Via: ... ;cookie | |------------------------------------------------>| | | |(2) 4XX Cookie Required | | Via: ... ;cookie=yyy | |<------------------------------------------------| | | |(3) ACK | |------------------------------------------------>| | | |(4) INVITE cookie=xxx | | Via: ... ;cookie=yyy | |------------------------------------------------>| | | |(5) 100 | |<------------------------------------------------| | | |(6) 200 | |<------------------------------------------------| | | |(7) ACK | |------------------------------------------------>| | | The solution provides a mechanism for clients to indicate support for this extension, does not require any extra state to be stored on servers, and traverses proxies that do not implement this specification. It also provides a mechanism to allow cookies to be re-used by clients to limit the round-tripping of requests for validation. 4.1. Overview of Operation A SIP element that receives a request over UDP can verify that the client sending the request is both able and willing to receive responses for a SIP request before it is processed. To do so, the SIP server rejects a SIP request received over UDP with a 'cookie'. The cookie is then sent back to the client, which re- transmits the request with the cookie the server provided. As a result of this round-trip, a server can be sure that a request received over UDP was not spoofed, and that the apparent sender really is the sender of the request. Zourzouvillys Expires September 3, 2009 [Page 10] Internet-Draft SIP Via Cookie March 2009 4.2. Client Behaviour The client behaviour specified here affects the transport processing defined in Section 18.1 of SIP [RFC3261]. A client, compliant to this specification (clients include UACs and proxies), MUST include a "cookie" parameter in the top Via header field value of any requests (both INVITE and non-INVITE) it generates that are to be sent out over a datagram transport that is not secured by DTLS (e.g, UDP). This parameter will have no value for the first request to a given remote address/port/transport tuple, and indicates that the client supports this specification. If the client has previously received a cookie from the remote target, that value SHOULD be included as the value of the "cookie" parameter. If the client receives a response to a request sent with a cookie parameter with a status code of 4XX, the request SHOULD be retransmitted. The retransmitted request will contain a new branch value (As it is a new request), and the cookie parameter from the 4XX response from the first request MUST be copied in to the top Via of the new request. The new request must then be transmitted to the same target ip address and port as the original request was. The re-sent request is sent within a new branch, and is treated as a further fork of the original request, rather than a resending operation performed by a transaction user. This means that the entire re-sent request is identical in every way except the top via header field, which will contain a new branch value parameter and the cookie parameter copied from the original request. In paticular, the CSeq value is not incremented. Note that a 4XX response to an INVITE MUST trigger an ACK to be sent as per normal SIP processing rules. The generated ACK MUST contain the cookie parameter copied from the 4XX response. If the response for the second request solicits a 4XX response a second time, the transaction MUST be aborted and processing continue by trying another server as defined in [RFC3263] or return the final response to the TU. 4.3. Server Behaviour The server behaviour specified here affects the transport processing defined in Section 18.2 of SIP [RFC3261]. When a server compliant to this specification (which can be a proxy or UAS) receives a SIP request (both INVITE and non-INVITE), it examines the topmost Via header field value. If this Via header Zourzouvillys Expires September 3, 2009 [Page 11] Internet-Draft SIP Via Cookie March 2009 field value contains a "cookie" parameter, and the value of the parameter is is equal to a cookie generated for the client previously, the cookie parameter MUST be removed and the request continues being processed as normal. The cookie is removed to ensure that it is not leaked to a upstream server, which could then maliciously use the value for attacking the client. If a request is received from an IP address that could be spoofable (i.e, any request received from the general internet), and continuing processing that request may result in a server transaction being created for it, and the top Via field contains a cookie parameter, then the server SHOULD instead generate a new cookie for this source and generate a 4XX response, and place the cookie value into the cookie parameter of the top via field before sending the response statelessly as defined in section 8.2.7 of [RFC3261]. If a request is received to a public server over a datagram transport, and the server is unable to authenticate the client, and the top Via header field does not contain a "cookie" parameter, then the server SHOULD reject the request with a 4XX Stateless Cookie Required response. Note that a server that is providing services to clients that authenticate (for example, an outbound proxy) SHOULD always send the 401/407 statelessly to avoid being used as a reflecting amplifier in a denial of service attack. Sending responses statelessly is documented in 8.2.7 of [RFC3261]. 4.4. Stateless Cookie Generation A RECOMMENDED way to create a stateless cookie for a client is to generate a hashed MAC [RFC2104], H1 over the concatenation of a timestamp and the normalized values of the source IP address and port of the request: H1 = HMAC(ts || ":" || src_ip || ":" || src_port, key) The resuling cookie could then the concatenation of timestamp used for generating the hash, a "-", and H1: cookie = ( ts || "-" || H1 ) To verify a cookie, extract the timestamp and ensure it is within an acceptable period of time, and then generate the hash again using the timestamp extracted from the cookie. If the two values match, then the cookie is valid. Note that stateless deployments that run multiple stack instances on Zourzouvillys Expires September 3, 2009 [Page 12] Internet-Draft SIP Via Cookie March 2009 the same IP address, port, and transport (e.g, using anycast) need to share the same key. A server deployed on the public internet MUST NOT use a mechanism for generating cookies that is known to be cryptographically insecure. 4.4.1. Cookie Lifetime Using the above method, a cookies lifetime is configurable. A good value for the lifetime of a cookie is a balance between causing a round-trip when it expires and for how long a leaked cookie could cause damage. At one extreme, parameters within the request such as the R-URI, CSeq, Call-ID etc could be used for generating the cookie (as a client implementing this specification will always re-transmit the same request with only a new branch and the cookie value after receiving a 4XX response), meaning that each and every request would need to be round tripped to get a cookie. A leaked cookie can only be used to attack the UA the cookie was generated for, and any proxy generating one will remove it before forwarding the request on, so risk of leakage except through MITM attacks is low. As such, it is RECOMMENDED a cookie remain valid for all requests from a single IP address and port combination for a period of at least X minutes. 4.4.2. Key Generation A short key may potentially be subject to a dictionary attack. It is RECOMMENDED that implementations use a cryptographically random [RFC1750] identifier for the generation of keys, and SHOULD at the very least be XXX bytes in length. Implementations SHOULD provide a configuration option for generating a key randomly on startup, and the key length should be configurable. Note that the key does not need to remain the same between restarts of the server. If a key changes, a round-trip verification of a cookie will occur next time any client tries to send a request. Implementations SHOULD roll keys on a regular basis. Note that if a set of servers are serving the same IP address, port, and transport, then the keys will need to be rotated at the same time. It is RECOMMENDED that implementations in such a configuration accept cookies created using both keys for 64 * T1 after the key is changed. Zourzouvillys Expires September 3, 2009 [Page 13] Internet-Draft SIP Via Cookie March 2009 4.5. Parameter Definition cookie-param = "cookie" [ = 1*paramchar ] 4.6. Example All non essential details have been excluded for brevity. Lines have been wrapped to confirm to document rules F1 INVITE bob -> P1 INVITE sip:alice@atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK-AAAA;cookie F2 4xx P1 -> bob SIP/2.0 4xx Via Cookie Required Via: SIP/2.0/UDP 192.0.2.1:5060\ ;branch=z9hG4bK-AAAA;cookie=1234567890-Axda6utydMc F3 INVITE bob -> P1 INVITE sip:alice@atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.1:5060\ ;branch=z9hG4bK-BBBB;cookie=1234567890-Axda6utydMc 5. Additional Behaviour 5.1. General Server Behaviour This attack only exists when an INVITE server transaction (IST) is created. As such, the best remedy is to never allow an untrusted source create an IST unless absolutly necessary. Many commonly deployed SIP elements create an IST for every single INVITE received, even those that are generating 401/407 responses, and in some cases even for malformed requests. Behaviour such as this can be exploited by an attacker. Zourzouvillys Expires September 3, 2009 [Page 14] Internet-Draft SIP Via Cookie March 2009 5.2. Proxy Behaviour A proxy SHOULD remain stateless unless processing requires it to be stateful, for example due to forwarding a request to a next-hop that is resolved using SRV mechanisms. When a proxy supports being stateful and is compliant to this specification, it MUST support perform the operations described in "Client Behaviour" section. Failure to do so leaves the proxy open to being used as an amplifying attack reflector. A Proxy MUST never create an INVITE server transaction for a 4xx Cookie Required response. 5.3. UAS Behaviour A UAS SHOULD never create a server transaction for an INVITE request received over UDP unless it is absolutly vital. By creating a transaction, the UAS is opening itself to being a reflector as described in the vulnerability section. 6. Other Solutions A number of other solutions were considered. Here is a list of some of them and why they were rejected. 6.1. Deprecate UDP transports A way of mitigating this attack would be for publicly accessible SIP servers to not enable UDP support on public interfaces. Removing such a commonly deployed compontent from systems at this time seems too extreme a solution. Additionally, UDP is a useful protocol for publicly accessible servers due to its scalability features. Anycast can be used with stateless proxies to scale horizontally, something that cannot be achieved with connection oriented transports like TCP or ones that require state like DTLS when a large number of deployed SIP UAs do not yet support RFC 3263. 6.2. Use Digest Authentication A public server could require standard digest authentication (and nonces) to be used instead. There are 2 issues with this potential solution: A SIP UAC would not know if it should query the user for credentials or just send straight away with an "anonymous" username as suggested Zourzouvillys Expires September 3, 2009 [Page 15] Internet-Draft SIP Via Cookie March 2009 in 22.1 of [RFC3261]. Secondly, this solution does not perform well over multi-hop UDP requests, as each hop would need to send a 401/407 response all the way back to the UAC to re-issue the request again. 6.3. Use a new authentication scheme A new authentication scheme could be defined that indicates the UAC does not wish to provide any authentication, thus getting over the problem of a UAC not knowing if it should ask the user for authentication or not. The scheme could provide a nonce in the 401/ 407 response, which then would need to be copied into the new request. While this authentication may be useful for other functionality in SIP, it does not solve the multi-hop UDP problem mentioned in the previous section. 6.4. Re-engineer the internet Another solution could be to simply blame service providers that allow spoofing of source addresses rather than solve the problem in SIP itself. This solution was rejected as potentially being to extreme a solution. 6.5. Rate Limit Limit number of active server transactions to any given source IP address/port. This is always a good idea in almost any implementation, but does not solve the problem as an attacker could use a small number of transactions on a large number of public SIP servers to attack the victim successfully. 6.6. Use Identity While Identity initially seems like a good candidate, it would stop anonymous users being able to send requests. Additionally, without extra constraints placed on sending responses of identity header check failures to ensure they are sent statelessly, it would not actually stop the vulnerability described in this document as a valid request sent to a different server could be replayed by spoofing the request to P1 with a source of the Zourzouvillys Expires September 3, 2009 [Page 16] Internet-Draft SIP Via Cookie March 2009 victim, resulting in the identity within the Identity header of the original (legitimate) request being essentially joe jobbed. Of course, there is also nothing to stop a malicious user creating their own identity and using it in the spoofed requests. These would pass identity checks for public services (as they're valid), but without a reputation system for Identity, requests will still be processed and victims attacked. 6.7. Listen for hints something is wrong Listen for ICMP type 3 requests. Not so useful if the victim is a SIP server itself, nor if the victim is so bogged down it can't send them. Additionally, most operating systems rate limit the ICMP messages number sent per second. Even if the victim was not an SIP server, a known open UDP port could be used - for example by crafting the request to come from port 53 of the victim, when the victim is a DNS server. 6.8. Have a UAC CANCEL any unsolicited responses Firstly, this does not work if the victim is not a SIP stack. Even if it were a SIP stack and it knew it was being spoofed (for example, due to the received parameter in the only via of a response matching its public IP address), this does not solve non-INVITE transaction problems. Also, the UAC may be so overloaded already it is not able to send the CANCEL out. Additionally, draft-sparks-sip-invfix-02 modifes ICT handling to drop responses that do not match an existing client transaction. 6.9. Only apply cookie to INVITE At first it would appear that only INVITE is vulnerable to this attack due to Timer G being the timer that causes the attack. However, non-INVITE requests can also be used to generate state in a server, and the result of that state being created can cause requests, for example a SUBSCRIBE being created may result in a NOTIFY being sent to the target of the dialog in the request. While this mechanism does not stop an attack from a legitimate host, it does stop the untracable attack that is currently possible where a client performs a "fire and forget" attack. As such, this mechanism should be applied to all requests received over UDP, both INVITE and non-INVITE. Zourzouvillys Expires September 3, 2009 [Page 17] Internet-Draft SIP Via Cookie March 2009 7. Security Considerations This document is specifically designed to address a security issue in SIP when accepting requests over a datagram transport. The proposed solution provides a mechanism to mitigate a SIP server being used as an amplifier. A response sent by a proxy that requires via cookie support for clients trying to send a request to it will generally generate smaller responses than the original request due to not including SDP in the response. Even in the case of no SDP offer in the original request, the response will only be marginally larger than the request. This document does not try to restruct attacks that can be performed by creating an INVITE session with a server and setting the remote destination address for the RTP to a victim, which could be the subject of further study. Likewise, ensuring a contact is valid in a dialog-creatign request is also out of the scope of this document. A cookie value could be leaked to a 3rd party if multiple instances of a SIP stack are running on the same IP address/port (i.e, using anycast), but only one of them implements this specification. In such a case, the first request may cause a cookie to be generated and a 4XX response sent to the client, and the second request including the cookie go to the instance that does not support this specification, so the request is forwarded without removing the cookie value, and thus leaked to any party the request was forwarded to. While the potential for attack is very limited (especially if cookie lifetime is kept very short), deployments must ensure that if multiple servers are running on the same address, they either always implement this specification or do not. 8. IANA Considerations 8.1. cookie parameter The IANA is requested to register the 'cookie' Via header field parameter, which is defined in Section X, under the Header Field Parameters and Parameter Values subregistry within the SIP Parameters registry: Predefined Header Field Parameter Name Values Reference ---------------------------- --------------- --------- --------- Zourzouvillys Expires September 3, 2009 [Page 18] Internet-Draft SIP Via Cookie March 2009 Via cookie No [RFCxxxx] 8.2. 4XX Via Cookie Required The IANA is requested to register a new SIP response code which is described in section X. It is sent when a server receives a SIP request over a datagram transport that lacks a cookie field parameter value. Response Code Number: 4XX Default Reason Phrase: Via Cookie Required 9. Acknowledgements Thanks to Michael Procter, Jon Ribbens, Nils Ohlmerier, Dale Worley, Tim Bray, and Adam Roach for thorough feedback on early versions of this document. 10. Normative References [RFC1750] Eastlake, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Zourzouvillys Expires September 3, 2009 [Page 19] Internet-Draft SIP Via Cookie March 2009 Author's Address Theo Zourzouvillys VoIP.co.uk Commerce House Telford Road Bicester, Oxfordshire OX26 4LD UK Phone: +44 1908 764 181 Email: theo@voip.co.uk Zourzouvillys Expires September 3, 2009 [Page 20]