One document matched: draft-shenoy-sip-via-validation-00.txt

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]