Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: next
    • Labels:
      None

      Description

      Introduction

      This is a proposal to add overload policies and a filter mechanism for JSR 359.

      • An overload policy based on resources managed by the SIP container such as number of active sip sessions, general memory usage etc
      • A low-level hook (filters) that provides a way to programmatically affect the decision making whether a SIP message should be further processed by the stack or not
        .

      The purpose of introducing these mechanisms is to protect SIP Servlet applications from e.g. denial of service attacks and other spikes that typically can either bring down or seriously affect the performance of a SIP Servlet application.

      Overload Policy

      This feature is more for the system administrator than the application developer. Through performance testing and knowing the typical user scenario for a particular deployment, the sys admin can e.g. set the maximum number of sessions allowed before traffic is actively rejected. The overload policy could be configurable both per SIP Servlet container instance and for each individual application.

      Support for Filters

      The low-level hook (filters) would allow an organization to implement their own custom rules for how and when traffic is dropped at a more granular level. E.g., during a DDOS attack it may be hard to just block traffic based on IP (which may be more appropriate to do elsewhere anyway) but there may be traffic pattern that you can trigger on and block traffic based on that. In addition, filters must be chainable to allow for multiple policies to be in effect at the same time. These filters should be configurable per SIP Servlet container instance.

      The idea of having chains of filters for requests is quite popular in many web stacks. E.g., the Python WSGI interface specification (http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface) allows for middleware commonly used to implement "filters" such as CSRF, cookie management etc. Similarly, Ruby has the rack specification (http://rack.github.com/), which provides hooks for implementing filters as middleware. Both of these technologies allows you to decide whether to forward the request up the stack, terminate it or simply log and silently drop it. Looking to the Java world, Tomcat has a concept of filters (http://tomcat.apache.org/tomcat-7.0-doc/config/filter.html) and all their examples are about preventing various types of attacks. Most of their filters are direct ports for the Apache HTTP Server, which is another great example where filters are used to allow or block traffic based on some particular criteria.

      Overall, filters are a well-known concept within the web world and it seems like it would be a good fit for a SIP Servlet Container as well.

      Btw, the JAIN SIP reference implementation has a basic concept of this (essentially a single filter). See http://hudson.jboss.org/hudson/job/jain-sip/lastSuccessfulBuild/artifact/javadoc/gov/nist/javax/sip/SipStackImpl.html and the property gov.nist.javax.sip.SIP_MESSAGE_VALVE. The interface for the message valve is here: http://hudson.jboss.org/hudson/job/jain-sip/lastSuccessfulBuild/artifact/javadoc/gov/nist/javax/sip/stack/SIPMessageValve.html

        Activity

        Hide
        binod added a comment -
        Show
        binod added a comment - Comment from Face2Face (Please see the overload section): http://java.net/projects/sipservlet-spec/downloads/download/f2fjan13/JSR359F2FSanFranciscoNotes.pdf
        Hide
        jonbo372 added a comment -

        I believe the overall conclusion is that no overload policy per say will be introduced but rather a mechanism for implementing one according to the needs of a particular deployment could be useful. Today, there is no way to intercept a message before it hits the transaction layer. As pointed out in the description, the jain sip reference implementation has a mechanism allowing to intercept a message before any transaction/dialog mapping occurs, making it a more efficient way to process the message without consuming too many resources. This would allow an application developer to build their own overload policy, which simply could drop the request or whatever it wants to do.

        Show
        jonbo372 added a comment - I believe the overall conclusion is that no overload policy per say will be introduced but rather a mechanism for implementing one according to the needs of a particular deployment could be useful. Today, there is no way to intercept a message before it hits the transaction layer. As pointed out in the description, the jain sip reference implementation has a mechanism allowing to intercept a message before any transaction/dialog mapping occurs, making it a more efficient way to process the message without consuming too many resources. This would allow an application developer to build their own overload policy, which simply could drop the request or whatever it wants to do.
        Hide
        binod added a comment -

        As per the EG meeting, EG opinion was divided on whether it is possible to implement a portable Filter/Interceptor that work for all containers. We decided to postpone this to a future release taking into consideration the relative priorities of the tasks.

        Show
        binod added a comment - As per the EG meeting, EG opinion was divided on whether it is possible to implement a portable Filter/Interceptor that work for all containers. We decided to postpone this to a future release taking into consideration the relative priorities of the tasks.

          People

          • Assignee:
            jonbo372
            Reporter:
            jonbo372
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated: