| Home Prev |  cOS Core 14.00.15 Administration Guide
|
Next |
|---|
The IDP Traffic Shaping feature is traffic shaping that is performed based on information coming from the cOS Core Intrusion Detection and Prevention (IDP) subsystem (for more information on IDP see Section 7.8, Intrusion Detection and Prevention).
This feature is set up by selecting a value of Pipe for the Action property of an IDP Rule. Some extra properties become available when this action is selected and these are described later in this section.
Application Related Bandwidth Usage
A typical problem that can be solved with IDP Traffic Shaping is dealing with the traffic management issues caused by bandwidth hungry applications. A typical example of this is traffic related to peer-to-peer (P2P) data transfer applications which include such things as Bit Torrent and Direct Connect.The high traffic loads created by P2P transfers can often have a negative impact on the quality of service for other network users as bandwidth is quickly absorbed by such applications. An ISP or a corporate network administrator may therefore need to identify and control the bandwidth consumed by these applications and IDP Traffic Shaping can provide this ability.
Combining IDP and Traffic Shaping
One of the issues with controlling a traffic type such as P2P is to be able to distinguish it from other traffic. The signature database of cOS Core IDP already provides a highly effective means to perform this recognition and as an extension to this, cOS Core also provides the ability to apply throttling through the cOS Core traffic shaping subsystem when the targeted traffic is recognized.IDP Traffic Shaping is a combination of these two features, where traffic flows identified by the IDP subsystem automatically trigger the setting up of traffic shaping pipes to control those flows.
The steps for IDP Traffic Shaping setup are as follows:
Define an IDP rule that triggers on target traffic.
The IDP signature chosen determines which traffic is to be targeted and the signature usually has the word "POLICY" in its name which indicates it relates to specific applications types.
Select the rule's action to be the Pipe.
This specifies that IDP Traffic Shaping is to be performed on the connection that triggers the rule and on subsequent, related connections.
Select a Bandwidth value for the pipe.
This is the total bandwidth that will be allowed for the target traffic. The traffic measured is the combination of the flow over the triggering connection plus the flow from any associated connections, regardless of flow direction.
Connections opened before IDP triggered will not be subject to any restriction.
Optionally enter a Time Window in seconds.
This will be the period of time after rule triggering during which traffic shaping is applied to any associated connections that are opened.
Typically, a P2P transfer starts with an initial connection to allow transfer of control information followed by a number of data transfer connections to other hosts.
It is the initial connection that IDP detects and the Time Window specifies the expected period afterwards when other connections will be opened and subject to traffic shaping. Connections opened after the Time Window has expired will no longer be subject to traffic shaping.
A Time Window value of 0 means that only traffic flowing over the initial triggering connection will be subject to traffic shaping. Any associated connections that do not trigger an IDP rule will not be subject to traffic shaping.
Optionally specify a Network
If the Time Window value is greater than zero, a Network can be specified. This IP address range allows the administrator to further refine the subsequent connections associated with IDP rule triggering that will be subject to traffic shaping. At least one side of associated connection has to be in the IP range specified for it to be included in traffic shaping.
To better understand how IDP Traffic Shaping is applied, the following are the processing steps that occur:
A new connection is opened by one host to another through the Clavister firewall and traffic begins to flow. The source and destination IP address of the connection is noted by cOS Core.
The traffic flowing on the connection triggers an IDP rule. The IDP rule has Pipe as action so the traffic on the connection is now subject to the pipe traffic shaping bandwidth specified in the IDP rule.
A new connection is then established that does not trigger an IDP rule but has a source or destination IP that is the same as the connection that did trigger a rule. If the source or destination is also a member of the IP range specified as the Network, then the connection's traffic is included in the pipe performing traffic shaping for the original triggering connection.
If no Network is specified then this new connection is also included in the triggering connection's pipe traffic if source or destination match.
Either Side Can Trigger IDP
After reading through the processing flow description above, it can be better understood why specifying a Network is important. The IDP subsystem cannot know which side of a connection is causing a rule to trigger. Sometimes it is the initiating client side and sometimes the responding server. If traffic flow on both sides becomes restricted, this may have the unintended consequence of traffic shaping connections that should not be traffic shaped.Unintended Consequences
To explain this unintended traffic shaping, consider a client A that connects to host X with P2P traffic and triggers an IDP rule with the Pipe action so the connection becomes subject to traffic shaping. Now, if another client B also connects to host X but this time with web surfing traffic, an IDP rule is not triggered but the connection should not be traffic shaped along with client A's connection just because host X is involved.Excluding Hosts
To avoid these unintended consequences, we specify the IPv4 addresses of client A and client B in the Network range but not host X. This tells cOS Core that host X is not relevant in making a decision about including new non-IDP-triggering connections in traffic shaping.It may seem counter-intuitive that client B is also included in the Network range but this is done on the assumption that client B is a user whose traffic might also have to be traffic shaped if they become involved in a P2P transfer.
If Network is not specified then any connection involving either client A or host X will be subject to traffic shaping and this is probably not desirable.
The schematic below illustrates a typical scenario involving P2P data transfer. The sequence of events is:
The client with IP address 192.168.1.15 initiates a P2P file transfer through a connection (1) to the tracking server at 81.150.0.10.
This connection triggers an IDP rule in cOS Core which is set up with an IDP signature that targets the P2P application.
The Pipe action in the rule sets up a traffic shaping pipe with a specified capacity and the connection is added to it.
A subsequent connection (2) to the file host at 92.92.92.92 occurs within the IDP rule's Time Window and its traffic is therefore added to the pipe and is subject to shaping.
The client network to which 192.168.1.15 belongs, should ideally be included in the Network address range for the IDP rule.
Viewing Hosts
IDP traffic shaping has a special CLI command associated with it called idppipes and this can examine and manipulate the hosts which are currently subject to traffic shaping.To display all hosts being traffic shaped by IDP Traffic Shaping, the command would be:
Device:/> idppipes -show
Host kbps Tmout
----------- ---- ----
192.168.1.1 100 58A host, in this case with IP address 192.168.1.1, can be removed from traffic shaping using the command:
Device:/> idppipes -unpipe -host=192.168.1.1
A full description of the idppipes command can be found in the separate CLI Reference Guide.
Viewing Pipes
IDP Traffic Shaping makes use of normal cOS Core pipe objects which are created automatically. These pipes are always allocated the highest priority and use the Group feature to throttle traffic.The created pipes are, however, hidden from the administrator when examining the currently defined traffic shaping objects with either the Web Interface or InControl, but they can be examined and manipulated using the normal CLI pipes command. For example, to show all currently defined pipes, the CLI command is:
Device:/> pipes -showThe IDP Traffic Shaping pipes can be recognized by their distinctive naming convention which is explained next.
Pipe Naming
cOS Core names the pipes it automatically creates in IDP Traffic Shaping using the pattern IDPPipe_<bandwidth> for pipes with upstream (forward) flowing traffic and IDPPipe_<bandwidth>R for pipes with downstream (return) flowing traffic. A number suffix is appended if name duplication occurs.For example, the first pipes created with a limit of 1000 Kbps will be called IDPPipe_1000 for upstream traffic and IDPPipe_1000R for downstream traffic. Duplicates with the same limit would get the names IDPPipe_1000_(2) and IDPPipe_1000R_(2). If another set of duplicates occur, the suffix (3) is used.
Pipes are Shared
There is not a 1 to 1 relationship between a configured IDP action and the pipes created. Two pipes are created per configured bandwidth value, one for upstream (forward) traffic and one for downstream (return) traffic. Multiple hosts use the same pipe for each direction with traffic in the upstream pipe grouped using the "Per Source IP" feature and traffic in the downstream pipe grouped using the "Per Destination IP" feature.If desired, IDP Traffic Shaping can be used to do the opposite of limiting bandwidth for certain applications.
If the administrator wants to guarantee a bandwidth level, say 10 Megabits, for an application then an IDP rule can be set up to trigger for that application with the Pipe action specifying the bandwidth required. The traffic shaping pipes that are then automatically created get the highest priority by default and are therefore guaranteed that bandwidth.
IDP Traffic Shaping generates log messages on the following events:
When an IDP rule with the Pipe option has triggered and either host or client is present in the Network range.
When the subsystem adds a host that will have future connections blocked.
When a timer for piping news connections expires, a log message is generated indicating that new connections to or from the host are no longer piped.
There are also some other log messages which indicate less common conditions. All log messages are documented in the Log Reference Guide.
