D-Link NetDefendOS, User Manual

Page: 800 / 912

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 NetDefendOS 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.
10.2.5. A P2P Scenario
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 NetDefendOS 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.
Chapter 10: Traffic Management
800