Internet Draft Sachin Shenoy HCL Technologies draft-shenoy-sip-via-validation-00.txt Dec 18, 2002 Expires: June 2003 Session Initiation Protocol Extension for Response Integrity Check using Validation Cookie STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract This document defines an extension to the Session Initiation Protocol (SIP). This extension allows detection of stale responses and responses whose Via header (SIP [1]) have been modified. This memo suggests new processing rules at the proxy servers while forwarding requests and responses. The extension works by defining a new parameter which would be used to run an integrity check on received responses. Sachin Shenoy [Page 1] Internet Draft SIP Validation Cookie Dec 18, 2002 1 Introduction The Session Initiation Protocol (SIP) [1], does not mandate proxy servers to perform any validation check on response while forwarding it. According to SIP [1], a proxy receiving a response, would check the topmost Via entry to ensure that it is its own. If this check is passed the proxy would forward the response to the next entry in the Via header. This feature can be easily exploited to carryout Distributed Denial of Service (DDoS) attacks. This memo proposes the use of a new parameter in Via header to detect tampered responses. A mechanism to detect stale responses is also given. 2 Terminology In this document, the key words "MUST", "MUSTNOT", "REQUIRED", "SHALL", "SHALLNOT", "SHOULD", "SHOULDNOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant SIP implementations. Additionally, we define and use the following terms: Validation cookie: This is a hash created using a one way hash function on the request. This value MUST be atleast 128 bits long. This value is used for detecting fake or tampered responses. This has nothing to do with the magic-cookie defined in SIP [1]. Cookie creation time: This is the time, at which validation cookie was created. It is used for the detection of stale cookies in responses. Cookie creation time should have resolution in seconds. Cookie expiration interval: The maximum time after which a cookie would be considered as expired. This SHOULD be atleast 5 minutes. Private data: Private data is a secret value that only the proxy knows. It SHOULD have atleast 128 bits of randomness. Use of cryptographically random identifiers (RFC 1750 [2]) in the generation of private data is RECOMMENDED. Sachin Shenoy [Page 2] Internet Draft SIP Validation Cookie Dec 18, 2002 3 Problem description According to SIP [1], a proxy receiving a response, would check the sent-by value in the topmost Via entry to ensure that it is its own address. If this check is passed, the proxy would forward the response to the next entry in the Via header. In the absence of transport level security, like TLS [4], this behaviour can be exploited to carryout DDoS attack. The way to achieve DDoS with this, is by sending fake responses to proxy. These responses should have the first Via entry as the proxy's entry and the second Via entry as the server that is under attack. Since a proxy would remove topmost Via and forward the response to the next entry, the server under attack would receive the response. Now if multiple proxies are used in this fashion, to target a single server, the server under attack would receive response from all the proxies. This would soon cause congestion on the attacked server. Here the different proxies, even though unwillingly, would be playing a part in carrying out the attack. Also response can be setup to get loopback gain by having the Via entries to have loops within them. Since the proxy servers do not do any check on this, the response would just loop on until the Via entries run out. As an example, consider a scenario where 2 proxies are present, proxy A and proxy B. Suppose proxy A and proxy B would accept response with proxy-a-via and proxy-b-via in their topmost via entry respectively. A response with these two via-entries back-to-back repeatedly would create a loop between the two proxies. Via: proxy-a-via, proxy-b-via, proxy-a-via, proxy-b-via, ... proxy-a-via, proxy-b-via Also an attacker may choose to place an non existant fully qualified domain name (FQDN) in the via entry. This may force the proxy to queue up the response while performing DNS (Domain Name Service) lookup. This queuing can causing resource crunch at proxy. These kind of attacks are quite difficult to ward off because, attackers usually remain hidden. The originator of the attack cannot be known by looking at the responses. For the server under attack, it would look as if the proxies which are sending the responses as attackers. Here proxies are only innocent accomplice in carrying out the attack. Sachin Shenoy [Page 3] Internet Draft SIP Validation Cookie Dec 18, 2002 4 Solution 4.1 Mechanism The solution is to have an integrity check being performed on the response before forwarding it. This integrity check should minimally be able to detect fake responses or tampered responses. Additionally detection of stale responses is also required to avoid replay attacks using an old responses. 4.2 Overview of operation This section provides a brief overview of operation of the extension. It is tutorial in nature and should not be considered as normative. Response integrity check is performed by adding a new parameter in the via header. While forwarding a request, the proxy would add a cookie parameter in its via entry along with the branch parameter. This cookie parameter would allow proxies to peform an integrity check on the response. The cookie parameter value would be calculated using a one way hash function on the request. Whenever a response comes in, proxy would perform this integrity check. If the check fails proxy would drop the response silently. If the check passes, the proxy would process the response using the rules given in SIP [1]. This integrity check would allow proxies to detect o Fake responses or responses with tampered via headers. o Stale responses (responses to requests that were forwarded atleast Cookie expiration interval before the current time). Detection of stale responses is to prevent replay attacks using an old response. 4.3 Processing while forwarding Requests While forwarding request, proxy server should add a cookie parameter in its via entry. This parameter value should be separable into 2 parts by implementation. The first part, should be the hash calculated using the mechanism given in Section 4.5. The first part would be used to perform the integrity check. The second part, should be the cookie creation time. The second part is used to detect stale cookies. The format of encoding of the cookie creation time is left to implementation. But the encoded time should have resolution in seconds. Note that cookie creation time can be encoded in clear text format. Apart from this all other processing are as given in SIP [1]. Sachin Shenoy [Page 4] Internet Draft SIP Validation Cookie Dec 18, 2002 4.4 Processing while forwarding Responses When a proxy receives a response, it would check the sent-by value in the first (topmost) via header. If it does not match the proxy, the response would be silently dropped (as given in SIP [1]). If it matches, the proxy MUST go ahead and perform the check given below. The proxy retrieves the cookie creation time from the cookie parameter of the topmost via entry. This cookie creation time is then compared with the current time. If the time difference is more than cookie expiration interval, the cookie is considered as stale and the response SHOULD be dropped. If the time difference is less than cookie expiration time or if the proxy decides not to drop the response, as suggested in the previous step, it MUST perform the integrity check given below. Proxy calculates the cookie using the method given in Section 4.5. This calculated cookie is compared with one present in the topmost via entry. If it matches, the response is considered to be valid and MUST be further processed as given in SIP [1]. If it does not match, the response MUST be dropped. 4.5 Calculation of the Cookie Parameter Cookie parameter has 2 parts. The first part is the hash calculated as given below. The second part is cookie creation time. The hash should be calculated by using a one way hash function on the following data. (MD5 is the RECOMMENDED hash function). o Call-ID The Call-ID header in the message. o CSeq The CSeq header in the message. o Previous hops Via entry. This should include the Via field and parameters also (including any parameters added by this element). o Number of via header fields present (via count) Number of via header fields present before the current element's via field (i.e. count of all the via fields till the previous hop including the previous hop). o Cookie creation time This is the time at which the validation cookie was created. This should have resolution in seconds. The purpose of this is to detect stale cookies in responses. o Private Data Private data SHOULD have atleast 128 bits of randomness. Sachin Shenoy [Page 5] Internet Draft SIP Validation Cookie Dec 18, 2002 validation cookie = MD5( call-id, cseq, previous via entry, via count, cookie creation time, private data ); cookie creation time = Time at which the cookie was created (resolvable to seconds). e.g. Via: SIP/2.0/UDP proxy.test.com:5060; branch=z9hG4bKd13e5c725cede1645508afaeed9a65bd; cookie=aa663004def625ffc29e78491e02ca2-2002:Jan:20:11:30:26 Note in the above example, the cookie parameter's validation cookie part is "aa663004def625ffc29e78491e02ca2" and cookie creation time part is "2002:Nov:25:11:30:26". It can be noted that cookie creation time itself is not encrypted in anyway. Also note that this is only an example and an implementation may choose to encrypt the cookie creation time in its own way. 4.6 Cookie Parameter Definition The ABNF [5] syntax of the cookie parameter is given below. via-cookie = "cookie" EQUAL token This grammar conforms with the extension-token grammar defined in SIP [1]. This would allow proxies and servers not recognizing this parameter to process the message. 5 Security Considerations TBD 6 References [1] 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. [2] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Sachin Shenoy [Page 6] Internet Draft SIP Validation Cookie Dec 18, 2002 Expires: June 2003 [4] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [5] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. 7 Authors' Addresses Sachin Shenoy e-mail sachins@npd.hcltech.com Sachin Shenoy [Page 7]