Type: New Feature
Affects Version/s: None
Fix Version/s: next
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.
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.
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