ENT-04 Condition Catalogs

Module 4: Condition Catalogs
Provisioning Methodology
Analyze business Classify
objectives
Monitor
Monitor
Enforce
Create required
catalog entries
Condition Action
Catalogs catalogs
Alert
Define policies Report

1
As we have seen, catalog entries are the building blocks that we use to make the
rules that comprise our traffic policy. Catalog entries may be conditions or actions. In
this module, we will learn about the catalogs you can use to define the conditions
which classify traffic in your policy.
ACTE (Enterprise Track) 1

• Why Do We Need To Classify?

• Condition Catalogs
• Host
• Service
• Time
• ToS
• Encapsulation
• Interface
• Allot Protocol Updates (APU)
We will begin by asking why is it important to classify at all?

Why Do We Need To Classify?
• To gain network visibility

• Through a clearer view of object distribution
• To enforce traffic policies
• By applying rules to a group of objects
Why do we need to classify network traffic? The answer is twofold.

Firstly, classifying gives us a better understanding of the traffic. For example, to see
which user is consuming the most bandwidth, we must first classify the network
traffic by user (the user can be identified by the host that initiates the traffic). Once
we have a clear view of the network traffic, we can analyze it over time and spot
trends and new behavior patterns.
Secondly, classifying allows us to apply different QoS to different types of traffic. If
traffic was not classified into identifiable groups, it would be impossible to apply
quality of service for every different traffic instance.

Example – Classifying Road Traffic
?
Manufacturer ?
Color ?
Type of Vehicle
?
Destination ?
Max Speed ?
Size
Classification method
Themust serve business objectives
Conclusion
The need for classifying traffic may be clear, but what methods should we use? To
take the example of street traffic, we can see that there are many different categories
by which we can classify cars. The car manufacturer, its color and its maximum speed
are just a few possibilities. Which one is the best?
How we classify depends on what we want to achieve. Classifying by car color for
example may be suitable if you manufacture paint for cars, but this type of
classification is of little use if your aim is to manage the road system.

How To Use
Define Your Business Objectives:
• What do you want to achieve?

• How should you classify the
traffic in your network to
enable this?
The first step of implementation will therefore be to define your business objectives.
Ask yourself what it is you want to achieve with the Allot solution. How would you
classify your network traffic to meet the desired outcome? For example, if a different
quality of service is to be implemented for different users, we need to classify our
users into categories. If you want to define different service parameters for different
applications, then classification needs to be per application type.
We will now review the different classification condition catalogs available.


• Host
• Service
• Time
• ToS
• Encapsulation
• Interface
Traffic classification is performed by defining condition catalogs in the NetXplorer.

With an understanding of your business aims, you can choose the appropriate type of
condition catalog to define.
We will now examine each of the different types of conditions in turn, beginning with
the Host Catalogs.

Internal / External Hosts
Hosts are defined as internal or external on the basis of which

interface they are connected to on the bypass
External Bypass Unit Internal

hosts hosts
Hosts may be internal or external. Whether a host will be recognized by the SSG as
internal or external depends on the interface of the bypass unit to which that host is
connected.

Internal / External Hosts
Host catalog entries are defined in the NetXplorer interface, irrespective of whether
they are to be used as internal or external host conditions. The decision to define a
host catalog as an internal host condition or an external one, is made at a later stage,
when you build your policy in the NetXplorer policy editor (see Module 8: Building
The Enforcement Policy)

Host Hierarchy
Host List One or more hosts defined by:
Host Group
 IPv4 subnet
 IPv4 address
 IPv4 range
 IPv6 prefix
 IPv6 prefix range
There are several types of Host catalog entries, and it is important to understand the
hierarchical relationship between them – in particular between a host list and a host
group.
A Host List is a list of hosts defined by IPv4 Address, IPv4 Subnet, IPv4 Range, IPv6
Prefix or IPv6 Prefix Range, or any combination of these attributes. (Note: NetXplorer
GUI has two more options: Host Name or MAC Address. These option are available
only in the legacy product, AC-400, which is no longer sold). A Host List can represent
an individual subscriber, a corporate branch or a network subnet. How you use a Host
List depends on the policies you define to implement the relevant network business
objective.
Once you have defined Host Lists, you can group several of them into a Host Group.
Here is an example of using hosts to represent different locations. One Host Group
will represent North America. Inside this Host Group we can have multiple Host Lists,
each one representing a major city.
The city Host List represents the actual IP addresses, subnets and ranges used in the
specific city. Chicago is a Host List consisting of a simple IP subnet. New York is a Host
List made up of an IP range and an additional IP address outside of that range.

Creating Host Lists and Groups

1. Create Host Lists 2. Create Host Group
• Define new Host Lists • Define Host
using different types: Group and assign
• Host Name
Host Lists to it
• IPv4 Address • In the example
• IPv4 Range 3 Host Lists are
• IPv4 Subnet created:
• MAC Address • London
• IPv6 Prefix • Paris
• IPv6 Prefix Range • Madrid
• They are assigned
to the Host Group
named “Europe”
10
First, you should define a Host List:

1. In the Navigation pane, right-click Hosts and select New Host List from the
shortcut menu.
2. Enter a name and description in the Host List Entry Properties dialog box.
3. To add items to the host list, click Add. From the Host Item Type drop-down list,
select the type of item to be included in the host list (IPv4 Address, IPv4 Subnet,
IPv4 Range, IPv6 Prefix or IPv6 Prefix Range).
4. Define the additional parameters if you like to do so.
5. Click Apply. The item is added to the host list.
Repeat steps 3-5 to add more hosts to the list. Create more Host Lists if needed.
To join existing host lists into a single host group:
1. In the Navigation pane, right-click Hosts and select New Host Group from the
shortcut menu.
2. Enter the name of the host group, together with a description if required.
3. To add host lists to the host group, click Add. From “Add Group Items” dialog box
choose available Host lists that can be added to the host group.
The “Scope” of a Host List, as well as Host Group, can be either Global or specific to a
particular Service Gateway. We will discuss it in the next slide.

Host List – Scope
11
By default, host lists which you define are global. This means that they are sent to
each Service Gateway in the network and can be used by them. If you are working
with large numbers of long and detailed host lists though, this might unnecessarily
compromise the performance of your Service Gateway. If you know therefore that
the catalogs you have defined are only relevant to a specific Service Gateway on the
network, it may be worth while limiting the scope of the catalog to the relevant
Service Gateway.
To set the scope of the entry to a specific platform:
1. Click the Scope browse button. The Entry Scope Properties dialog box is displayed.
2. To make the entry available to a selected platform only, select Specific Device and
then select the platform from the drop-down list.
3. Click OK. The Host List Entry Properties dialog box is displayed.
4. Click Save.

Importing Hosts from External Text File
• Large groups or lists of hosts can be

exported from external text files
• User updates text file
• NX checks for changes every 10 minutes
3 different methods
12
It is also possible to import large groups of hosts from an external text file. The user
updates this text file and the NetXplorer checks for changes every 10 minutes. As
long as the text file is not updated, no NX resources are used. Note – the default
value of 10 minutes can be changed. Contact customer support to enable this change
if required.
Make sure you have the file on the NX at all times (if you delete it, the host entry
based on this file will have no data in it).
There are 3 different methods for importing external text files. The user can create:
- A new external text file host list
- A new external text file host group
- A new dynamic external text file host group

Which Method to Choose?

Type Of External Text File List or Number of Supported Types of
Group Entries Entries Hosts
External Text File Host GROUP Group Several thousand • Address • Internal
only • Subnet • External
External Text File Host LIST List • Range
(IPv4 & IPv6)
DYNAMIC External Text File Host Group SSG400 360,000 Address • Internal
GROUP
SSG600 60,000
Up to 10,000 per file, up to 1000
files supported per NetXplorer SSG800 180,000
(10,000,000 in total).
13
What is the difference between the regular External Text File Host Group (or List) and
the DYNAMIC External Text File Host Group?
The dynamic external text file host group functionality was developed to help
customers who wish regularly to use particularly large text files containing tens of
thousands of entries.
With the regular external text file host group we can only support a few thousand
hosts, but the Dynamic version enables us to support many more – 360,000 for the
SSG400, 60,000 for an SSG600 and 180,000 for an SSG800.
There are however, several limitations when using the dynamic mechanism:
1) It can only be used to support internal hosts.
2) It only supports individual IPs (ranges and subnets will be ignored)
3) Each SSG can support up to 750 dynamic host files.
4) IPv6 is not supported
Note that another side effect of the dynamic system is that the IPs updated with the
Dynamic text file are deleted when the SG reboots. The NetXplorer server will update
the IPs again after approximately 10 minutes, but until then there will be no rule
matching to the pipes and VCs in the policy that use those text files in their
conditions.

External Text File Format

Type Format Example
IPv4 address Name;IP IP1;1.1.1.1 Dynamic External Text File Host Group Supports Only This Entry
IPv4 subnet Name;IP/Mask IP1;1.1.1.0/255.255.255.0
IPv4 range Name;IP-IP IP2;5.5.5.5-6.6.6.6
IPv6 address prefix Name;IP\<prefix_length> Prefix_name;2001:1234::/32

Identical IPv6 addresses
IPv6 address range Name;IP-IP\<prefix_length> Range_name;2001:1234::-2001:1234::/32 defined in two different ways
Note: Each entry must be on a

separate line
14
Using this feature, you can import long lists of hosts from an external text file into a
Host Group or Host List Catalog on the NetXplorer.
There are five types of hosts that can be imported: IP address, IP range, IP subnet,
IPv6 address and IPv6 range. When using the dynamic method, IP address is the only
type of field that can be imported.
Create a text file according to the guidelines defined below, making sure that you
enter each host entry on a separate line. The text file format for each type of hosts is
as follows:
IPv4 address: Name;IP
IPv4 subnet: Name;IP/Mask
IPv4 range: Name;IP-IP
IPv6 address prefix: Name;IP\prefix length
IPv6 address range: Name;IP-IP\prefix length
NOTE: This method creates individual hosts with corresponding names but they are
all added to a single group. They cannot be separated.
NOTE: There should be no space between the name and the IP itself. The semi colon
sign is the separator.

Example:
Creating External Text File Host List
File Location On the

Server
15
For example, lets see how to create a new external text file host list. From the Hosts
item in the catalogs pane, choose “New External Text File Host List”. The External
Text File Host Entry Properties dialog is opened and the path of the text file is
entered. In this case the text file has been placed directly onto the server’s C drive.
However the file can be located on any machine that the NetXplorer Server can
access.

Host Group vs Host List Entries

How Does System Handle the Text File?
Host List:
All Ips from both Hosts are
presented in the same list.
Used with Host List No Host related
Host: “IP1” Host Text File
2 Groups are
created – 1 per
each host
Host: “IP2”
Used with Host Group
16
Here we see how the system would handle the same text file, when the administrator
creates an external text file host list and an external text file host group.
A text file is created which includes two host names: IP1 and IP2. IP1 contains two IP
addresses and one IP subnet, and IP2 contains one IP and one IP range.
Here we see an imported host list, which simply extract all instances of the file to be
host items in this host list.
Below we see an imported host group, consisting of 2 host entries. Clicking each host
entry will show us what it contains.
This difference has important implications later when we come to work with
templates (in Module 6).

Host Search
In which Host LIST is a host

defined?
17
When you are working with long lists of hosts, you might lose track of individual host
entries. The host search is used to find a host definition from within a host list.
1. Select Catalogs and right-click Hosts in the Navigation pane and select Host Search
from the popup menu.
OR
In the Application Details pane, right-click an entry in the Host Catalog and select
Host Search from the popup menu.
The Host Search Properties dialog is displayed.
2. A Host Entry can be searched for by Host Name, IP or MAC address. Enter the
details of the host which you are looking for.
3. Click Search. Results are shown in the Search Results list.
4. Click Close to close the dialog.
Note that the search does not search within host groups.
Please keep in mind that Host Name (here it is called “Host”) and MAC Address
options are available only in the legacy product, AC-400, which is no longer sold.

How To Use – Host catalog
Group Users Identify Specific Objects
• Per Location • Mission Critical Server

• Per Importance • VIP User
• Per Department
• Per Branch
What other uses can you think of?
18
Knowing your business objectives, you can use the host catalog to group different
users groups. For example: per geographical location, per importance to the
organization, per department, per country, etc.
On the other hand you can use host catalog to identify crucial network elements.
Later, you can build your policy to ensure that enough bandwidth is allocated to each
of these network elements.
Can you think of other uses for host catalogs? Share your thoughts with your trainer
and the training class.


• Host
• Service
• Time
• ToS
• Encapsulation
• Interface
19
Service catalog entries are used to classify traffic by application or protocol.

Applications may be anything from an instant messaging application to a business
ERP application. Protocol entries include network protocols, transport protocols and
application protocols.

How are Services Identified?
• Layer 4 classification: By source & destination IP & port

• Layer 7 classification: By application signature
− Which strings appear in the contents of the payload?
− Do the packets have particular numerical properties? At the heart of Allot’s
− Does the protocol behave and operate in a particular solutions is a DART engine
manner? which feeds off a
comprehensive library of
• Additional Challenges: signatures and behavior
− Protocol Encryption and Concealment
− Protocol Tagging and Encapsulation
20
The standard packet inspection process (shallow packet inspection) extracts basic
protocol information such as IP addresses (source, destination) and other low-level
connection states. This information typically resides in the packet header itself and
reveals the principal communication intent. The inspection level in the shallow
inspection process is insufficient to reach any application-related conclusions. For
example, if a packet is the result of an application trying to set up additional
connections for its core operation, an examination of the source or destination
addresses as they appear within the packet header itself will not reveal any useful
information regarding the connections to be used in the future, as requested by the
application. Furthermore, it is very common that the necessary information is spread
over several packet transactions; and once again, examination of the header
information alone overlooks the complete transaction perspective.
DART, on the other hand, provides application awareness. This is achieved by
analyzing the content in both the packet header and the payload over a series of
packet transactions. At the heart of Allot’s solutions is a DPI engine which feeds off a
comprehensive library of signatures and behavior.

Service Objects and Hierarchy

3 level service object hierarchy
Object Example Note
Service Group Monitored Service Web Services Can contain any
Group number of
services and
UDS items
Used in Used in
enforcement policy monitoring graphs
HTTP
Services
www.yahoo.com HTTP based
UDS
21
There are several different types of service objects - Service Groups and Monitored
Service Groups, Services and HTTP User Defines Signatures (UDS). The different types
are organized hierarchically.
Service groups enable you to efficiently assign multiple services to policies, instead of
defining separate policies on a service-by-service basis.
Monitored Service Group enables you to efficiently monitor multiple services,
irrespectively to their policy assignment.
Services are the protocol or application-based criteria for traffic classification.
Services can exist in only one location in the hierarchy at any given time.
HTTP UDS objects give huge flexibility to define signatures using any of the HTTP
header fields.

Service Objects and Hierarchy

NetXplorer comes with pre-defined services
organized into several generic service groups
and monitored service groups
Default traffic policy is based on the pre-defined

service groups
Services can be updated with the latest

applications and protocols, using the APU feature
All services outside default groups will join the

monitored service group called “Unclassified”
22
NetXplorer comes with pre-defined services to incorporate the growing number of

protocols representing the same or similar applications. These services are organized
into several generic service groups and monitored service groups such as Games,
Instant Messaging, Mail, Network Operation etc.
Note that these services can be updated, either manually or automatically, using the
Allot Protocol Update (APU) feature. The procedure for doing this is described fully at
the end of this module.
The default traffic policy classifies traffic into different VCs according to the generic
service groups, and this helps you to get an initial picture of the type of traffic running
through your network when you perform out of the box monitoring.
Note: All services not mapped to one of the default groups will join an extra
monitored service group called “Unclassified”. This will allow monitoring of all the
traffic flowing via the in-line platforms using one of the monitored service groups.

Example: Web Applications Service Group

Application Signature
Service Group
Ports
Services
Service
HTTPS
23
To better understand services and service groups, let’s look at the Web Applications
Service group.
This group includes several services: HTTP, HTTP Proxy, HTTPS and more. Each service
is defined by its application signature and by its port numbers.
HTTP is based on the HTTP application signature, and it includes both a signature and
a port number (80).
HTTPS is based on the Other TCP application and it includes a port only (443).
We will now review the steps to create a new service, and explain all the different
options available.

Creating a New Service
Two methods:
1. Based on an Application type
recognized by Allot DPI
2. Based on a port assignment
recognized by IANA
Will Be Marked With A

Question Mark Icon 24
While NetXplorer comes with an extensive set of common services, you may want to
define additional services. There are two methods for defining additional services:
1. Creating a new service based on an existing application type recognized by
Allot’s DPI engine.
2. Selecting a known service from the protocol library containing over 1000
protocols recognized by IANA (Internet Assigned Names Authority)
assigned ports.
The new service created by the user will be marked with a small blue question mark,
to indicate that this is a user created service, and not part of the Allot Protocol Pack.

Creating a New Service #1:

Based on an Existing Application
Traffic is identified by signature. If the
signature is not recognized, then the
traffic is identified according to the port
used, regardless of the application
Traffic is identified according to signature,

regardless of the destination port
specified
Traffic is identified according to the

destination port or server specified,
regardless of the signature
Specify the port or server
25
Lets first see how to create a new service based on an existing application. From the Service
Catalog, we select new service, and choose our application type. Assign additional properties
to it, such as port number. Now define the entry identification method. We can also take a
recognized application, and re-define the way in which it is recognized. From the Application
Type drop-down list, select the basic application type, and choose ADD. You can now
manually configure the identification method to either default, signature or port based.
Default: The DPI engine identifies the traffic by signature. If the signature is not recognized,
then the traffic is identified according to the port used, regardless of the application.
Signature: The DPI engine identifies the traffic according to the signature of origin, regardless
of the port. You can choose to check for this signature on particular ports or on all ports. By
using this method, you can distinguish between applications which use the same signature on
different ports.
Port/Server based: If you choose this method (also known as “parse by port”) , traffic on this
destination port or server will be identified as the service you have defined. The application
signature on this port will not be checked. Consequently, the traffic is identified as soon as
the first packet enters the classification engine. This makes it very useful for syn attacks and
other malicious traffic. In the Server field, select a pre-defined destination server from the
Host List catalog (Any is selected by default).

Creating a New Service #2:

Based on the IANA Port Assignment
Select required protocol and commit
it to the Service Catalog
Layer 4 Identification
26
The second way to create a new service is by using the port-based protocol library.
The protocol library is based on the IANA list. You can import entries from the library
to the main service list.
The service protocol library can be sorted by protocol name, ID or port number to
search for a particular protocol. It can also be filtered to display only particular
protocols.
To add a new service using the protocol library:
1. In the Navigation pane, right-click Services and select New. The Service Entry
Properties dialog box is displayed.
2. To select a publicly recognized port assignment for the application, click Library
in the Service Entry Properties dialog box. The Service Protocols Library dialog
box is displayed.
3. Select one or more entries in the library and click Commit. The selected entries
are added to the port list in the Service Entry Properties dialog box.
4. In the Service Entry Properties dialog box, click Save.
These library-based services use layer 4 identification, based on standard port usage
for specific applications.

Service Group / Monitored Service Group

• User-defined
• Several services can
be combined into one
group
• Similar services can
be grouped together
and assigned with the Select service to
same QoS as in be added to a
example: “Business Service Group
Applications”
Services are
added to a new
Service Group
27
You can define your own service groups by combining several services into a single
group. Similar services can be grouped if you want to apply the same QoS policy to
them. An example of this is seen on the screen, where a service group called:
“Business Applications” is created, consisting of Oracle, SAP and Vonage, with a view
to giving this group a guaranteed quality of service.
While Service Groups are defined to classify traffic and then perform different actions
on that traffic as part of the enforcement policy, you can also group services together
into Monitored Service Groups for the purpose of monitoring only.
These two mechanisms work independently of one another, meaning that a
particular service may be included in a particular service group for the purpose of
enforcement, while in a separate monitored service group for the purpose of
monitoring.
Groups combine port recognition and Layer 7 analysis. Within a group, the
identification of one service might be based on Layer 7 analysis, while another might
be identified by port number alone.

Moving an Existing Service to a Group
1. Select service to move

2. Right-click and select Move
3. Select parent group
28
Moving a service to an existing service group is also a simple process. For example,
here we see how to move H.323 to the Business Applications Group that we defined
earlier.
To move a service into an existing Service Group:
1. In the Service Catalog, right-click the service that you want to move, and select
Move from the shortcut menu. The Move Service Select target dialog is displayed.
2. Select the location to which you want to move the selected Service.
3. Click Save.
Note that you cannot move a group into another group. If you wish to classify traffic
from different service groups into a single Pipe or VC, this can be done using the “add
rule” function when building the traffic policy. This procedure is explained in Module
6: Building the Enforcement Policy.

User Defined Signatures (UDS)

Introduction: HTTP Common Usage
HTTP
• Traditional browsing =
• File downloads – file sharing sites +

(Mega, Mediafire, etc.)
• Streaming video (YouTube, Zulu, etc.) +
• Movie players, IM, VoIP, Gaming, P2P +

(BitTorrent trackers, etc.)
• Transport layer for many applications +
More
Granular HTTP Classification is Required
29
These days HTTP is used for a lot more than traditional browsing. HTTP is commonly
used for file sharing applications such as Mega, Mediafile and more. It is used to view
streaming videos via dedicated web sites such as YouTube and Zulu. It is used for
instant messaging applications, voice over IP, on line gaming, P2P and a lot more. In
order to be able to identify what traffic is flowing over a specific HTTP session, a
more granular classification is required.

User Defined Signatures (UDS)

How Is HTTP Traffic Classified By Default?
Matched to a specific When there is no When there is no

application matched application: matched
Matched to an HTTP application/
category based on behavior:
• YouTube behavior (Other) HTTP
• Rapidshare
• Facebook
• Google Maps
• Gmail • HTTP File Transfer
• Twitter • HTTP Streaming
• HTTP
• Google Earth • HTTP Browsing
• Etc. • Etc.
UDS matches (based on HTTP header fields)

overrule all the above
30
Let’s see how Allot’s Service Gatewayclassifies HTTP traffic. When there is a matching
application, traffic will be classified as the specific application. For example: YouTube,
Rapidshare, etc.
When there is no matched application, traffic will be classified by behavior to one of
the HTTP categories, such as “HTTP File Transfer”.
When there is no matched application or behavior, traffic will be classified as generic
“HTTP”.
In case you want to use a more granular HTTP classification, define a User Defined
Signature, based on HTTP header fields. A UDS match is stronger than all signatures
and HTTP categories.
Let’s see now what HTTP Header fields can you use to define an HTTP User Defined
Signature.

Creating a New HTTP UDS
(1) Activate HTTP UDS
(2) Create New UDS (3) Add HTTP Header Fields to the
UDS (max 16)
31
HTTP User Defined Signatures (hereinafter UDS), can be used on all AOS driven
products.
HTTP UDS must first of all be activated from the Networking tab which is accessed by
choosing “configuration” from the Service Gateway. After activating the UDS, create a
new HTTP UDS from the Host Catalog category. You can now add HTTP header fields
(up to a maximum of 16) and define the parameters required for each one. The
relationship between each header is “AND”, so a match will be made with this UDS if
the flow matches all of the header filters created.
Note: when you create a new UDS, you are actually adding a new service to the
service catalog. Therefore any connection with a matching service to this new UDS
will not match any other service even when there is no rule for this UDS in the policy.
This means that if a UDS is defined but not added to the policy matching traffic might
be classified to the Fallback VC.
UDS cannot be used in an “asymmetric” environment.

UDS Content Key Options:

HTTP Request Headers
Request
Request Description Examples Value Type

Headers
Host The domain name of the server requested www.cnn.com Free Text
Method The desired action to be performed on the GET, CONNECT, POST Predefined
resource identified by the Request URI values
Referrer The address of the previous web page http://www.google.com/search Free Text
from which a link to the currently
requested page was followed
URL Relative path (to the host domain name) When opening Allot Mobile Free Text
(URI) representing the page to load. The 1st field Trends Report from
in the header after the HTTP Command http://www.allot.com then the
(Method ) “URI” is: /allot-mobile-trends
User- Contains information about the web- PC Browser e.g: Mozilla/5.0 Free Text
Agent browser used by the computer or mobile Mobile Browser e.g:
handset originating the request “Nokia5300..”
32
Here we see the 5 different request headers that can be defined in the HTTP UDS
with examples for each one.
Host is used for the domain name of the server requested. For example you
can use it to identify all traffic going to www.cnn.com, or all traffic going to your
own home web site. This is a free text field.
Method is used for the desired action to be performed on the resource
identified by the requester. This is a multiple choice field where you can
choose: GET, CONNECT or POST.
Referer is used for the address of the previous web page from which a link to
the currently requested page was followed. For example, when opening
cnn.com from a google search the “Referer” will show:
http://www.google.com/search?hl=en&q=cnn.com&rlz=1I7RNTN_en <CR>
<LF>. This is a free text field.
URL (URI) is string of characters which identify and locate resources on the
Internet. For example, for Tolly Report from http://www.allot.com the “URI” is:
/Tolly_Report.html. This is a free text field.
User-Agent is used to obtain information about the web-browser or the type of
mobile handset originating the request. For example: Browser e.g: Mozilla/5.0,
Mobile handset e.g: “Nokia…”. This is a free text field.

UDS Content Key Options:

HTTP Response Headers
Response
Request Description Examples Value Type

Headers
Content- The type of encoding used on gzip Free text
Encoding the data
Content-Length The length of the response body 254 “greater than” or “lower
in octets (8-bit bytes) than” Integer
Content-Type The MIME type of this content text/html Predefined values to
(Multipurpose Internet Mail image/jpeg select
Extensions)
Location An alternate location for the http://edition.cnn.com Free text
returned data http://www.bbc.co.uk/
33
Here we see the 4 different response headers that can be defined in the HTTP UDS
with examples for each one.
Content-Encoding is used for the type of encoding used on the data. For
example: gzip. This is a free text field.
Content-Length is used for the length of the response body in octets (8-bit
bytes). This field can be set to “greater than” or “lower than”.
Content-Type is used for the MIME type of this content (Multipurpose Internet
Mail Extensions). For example: text/html, image/gif, image/jpeg. This field has
predefined values to select.
Location is used for an alternate location for the returned data. For example:
http://edition.cnn.com, http://www.bbc.co.uk/. This is a free text field.
User Defined Signatures must conform to the following specifications:
• Each field in a UDS may contain a maximum of 512 characters.
• Up to 40,000 characters total may be configured for all UDS signatures.
• A maximum of 16 different content keys may be defined per UDS
• The maximum of different services which can be defined is set per in-line platform.
This number includes those services included with the Allot Protocol Pack. See
release notes for updated figures.

User Defined Signature (UDS)

Example
IF URL = \sport AND
Host = Host = Host =

bbc.com
OR cnn.com
OR foxnews.com
THEN Classify as “Sports”
UDS is stronger than any other service
34
Here we see a defined UDS to identify all traffic going towards bbc.com or
foxnews.com or cnn.com and the request is for a ‘sport ‘ page.
NOTE: UDS is stronger than any other service in your service catalog. When a session
matches both a UDS and an additional service, such as HTTP Browsing, the session
will be identified as the matching UDS.

Additional Granularity (Content):

HTTPS Server Name Identification
Select Service=HTTPS
Select “Add”to add

ContentType=server_name
35
When using HTTPS, the HTTP data is encrypted within TLS/SSL (Transport Layer
Security/ Secure Sockets Layer). Although most information is encrypted, the
“server_name“ in the “Client Hello” request packet is sent un-encrypted. The
“server_name“ is the equivalent of the HTTP-Get “Host” key, which is used in regular
HTTP UDS.
In order to identify HTTPS by server name, create a new content. This is done by right
clicking “service” in the catalog tree, and choosing “New Content”.
Select HTTPS as the service, and add the server name by clicking “Add”.

Additional Granularity (Content):

VOIP Codec Identification
• Identify VOIP Codecs

• Supported Services:
• H323-RTP
• RTP
• SIP-RTP
• Add a Codec to Content Entry
36
It is possible to identify VOIP traffic based on different codecs. This is done using New
Content in the service catalog.
The available services are:
• H323-RTP
• RTP
• SIP-RTP
Supported codecs are G723, G729, GSM and G711A/U. You can add one or more
codecs to each content entry.
This capability allows for accurate QoS control for VoIP traffic based on the specific
codec used.
NOTE: other content services are available only with AC-400, which is not based on
AOS.

How To Use – Service Catalog
Identify: In Order To:

•Critical business apps •Ensure high QoE
•Your web site traffic •Ensure high priority
•High BW consuming apps
•Keep within capacity
limits
37
Knowing your business objectives, you can use service catalogs to identify services
and applications and control them. For example:
• Identify your critical business applications to ensure high quality of experience for
them at all times.
• Identify your own home web site traffic to ensure high priority so you will always
be available.
• Identify high bandwidth consuming applications, such as P2P and limit the
available bandwidth for them during peak hours.
We will learn more about how to configure such policies in modules 5 & 6 of this
training course.
Can you think of other uses for service catalogs? Share your thoughts with your
trainer and the training class.


• Host
• Service
• Time
• ToS
• Encapsulation
• Interface
38
In this section we will examine the time catalog.

Time
• Defines period of time during which a rule is active

• Example:
Limit P2P during work hours
• When time expires:
Traffic is reclassified
39
The Time Catalog contains entries that are used to define the period of time during
which a particular rule is active.
Time Catalog entries are useful when you want to apply conditions to traffic only on
specific days or at specific times. For example, you might differentiate between work
and non-work hours, or give priority to maintenance jobs run at scheduled times.
NOTE: You can use time catalogs to divide time up as you wish, for example by
defining as many time cycles as you want within a 24 hour period.
If a time catalog has been assigned to a Line, Pipe or Virtual Channel, what happens
when the expiration time is reached?
Both new and existing connections will be reclassified into other Lines, Pipes or
Virtual Channels.

Defining Time Entry
40
To define a time period:

1. In the Navigation pane, right-click Time and select New Time from the shortcut
menu. The Time Entry Properties dialog box is displayed.
2. In the Name field, edit the name of the entry and add a description as required.
3. Click Add. The Add Time Item dialog box is displayed.
4. In the “Frequency” area, select the frequency of the time period. The parameters
available in the “When” area vary according to the frequency selected. Select the
required time period in the When and the Recurrence areas.
5. Click OK and then Save.
Note: time rules must be overlapping in order to allow re-classification of traffic.
Otherwise, traffic will be re-classified to a fallback rule.

Time-Based Policy
• Time-based classification
• Reclassification on time expiration
41
Here is an example of using Time Catalog entries to define a time-based policy. In this
example, Peer to Peer traffic is limited to 256kbps during work hours and has a much
more liberal limit outside work hours.

How To Use – Time catalog
Define: In Order To:

•Peak hours •Avoid congestion
•Working hours •Ensure high QOE
42
Knowing your business objectives, you can use time catalogs to define different time
slots and control them. For example:
• Define peak hours in your network to avoid congestion and allow fair usage to all
subscribers all day long.
• Create unique Happy Hour offerings for your subscribers allowing them to enjoy
special bandwidth rates at specific hours of the day.
• Define your organization working hours to ensure high quality of experience for
your business applications.
We will see more about how to configure such policies in modules 5 & 6 of this
training course.
Can you think of other uses for time catalogs? Share your thoughts with your trainer
and the training class.


• Host
• Service
• Time
• ToS
• Encapsulation
• Interface
43
In this section, we examine the ToS catalog. ToS can serve as a condition or as an
action in your policy table.
Lets begin with a few words of explanation about the Type of Service Byte in the IP
header, and how it can be used.

TOS – Type Of Service
• IPv4 Packet Tagging

• Historically Used To Set
• Packet Classification
• Buffering Level
0 1 2 3 4 5 6 7
44
The Type of Service, or TOS field, is one of the fields of the IPv4 header. It can be used
to differentiate traffic flows one from another. It was originally designed to support
classification of different services by the designers of the IP protocol. It is an 8 bit
field. We will see now common usages of the TOS field.

TOS RFC Overview

RFC Description Bits Used # Options Notes
1349 ToS Standard 8 Original TOS
3 precedence bits RFC, not
4 ToS Bits, rarely used common today
Final bit must be zero
2474, DiffServ 64
2475 codepoints 6 DSCP Bits
Standard
(DSCP)
2597 Assured 12 Predefined in
Forwarding 3 Bits to set 4 different class levels NX GUI
3 bits to set 3 drop precedence levels
Layer 4 Classification
45
The ToS Standard, defined by RFC 1349, is divided into 3 fields – precedence, ToS and
MBZ. Precedence is defined by bits 0-2. There are 8 possible precedence values: from
000 (decimal 0) through 111 (decimal 7). Generally decimal 0 is treated as the lowest
priority traffic, and decimal 7 is treated as the highest priority traffic. The four bits in
the ToS field are very rarely used. MBZ, the “must be zero” field, was never used.
DiffServ standard defined by RFC 2474 & 2475 is 6 bits long and can range from
000000 to 111111 – giving a total of 64 possible values.
Assured Forwarding, defined by RFC 2597, was designed to provide different levels of
forwarding assurances for customer traffic. There are 4 classes defined – from 1 to 4.
Within each class, packets are marked with 3 levels of drop precedence – low,
medium and high. The higher the level of drop precedence the more likely the packet
is to get dropped. These 4 class level and 3 drop precedence levels offer 12 possible
values for assured forwarding (AF). Layer 4 network elements can allocate different
resources to each level.
The NetXplorer ToS catalog comes with these 12 values pre-defined. Note that the
decimal values shown in the NetXplorer ToS catalog for each AF service type, are
calculated from all 8 bits.
In addition, you can use the NetXplorer to define any value you wish, based on any
combination of the 8 bits including the last two.

Defining TOS
46
In the TOS Catalog, you can view the properties of predefined entries and can create
entries that classify the TOS byte using any or all of the 8 bits.
To define a TOS using free format:
1. In the Navigation pane, right-click ToS and select New ToS from the shortcut menu.
The ToS Entry Properties dialog box is displayed.
2. In the Name field, edit the name of the entry and add a description if required.
3. Define the TOS value by inserting bit values in one of the following ways:
• Click the bit value field boxes (grey indicates 0, black indicates 1). The decimal
equivalent is displayed in the Selected TOS Byte Bit Settings area.
• Enter the decimal or hexadecimal representation of the bit in the Decimal or
Hex fields, respectively.
4. Click Save. The new entry is saved in the TOS Catalog.


• Host
• Service
• Time
• ToS
• Encapsulation
• Interface
47
The next condition catalog which we will examine is the encapsulation catalog.

Encapsulation
GRE Tunnel
VoIP IP VPN
• Default:
• SSG ignores encapsulation
• Classification is based on the data itself
• Encapsulation Catalog:
• Allows you to classify per encapsulation protocol (in addition to the data itself)
• Also possible to classify per encapsulation only as service
48
By default, the SSG recognizes different types of encapsulation protocols, and knows
how to identify the data inside. For example, when a user is browsing the web via a
GRE Tunnel, the connection will be identified as HTTP Browsing.
Allot’s DART engine knows how to unwrap many different encapsulation methods,
including VLAN, MPLS, L2TP v2, PPPoE, GTP, GRE and more.
The encapsulation catalog for VLAN or GRE covers a different use case. Using this
catalog you can actually classify traffic based on the encapsulation tunnel used – e.g:
to assign a specific QoS for all GRE tunnel traffic. Connections inside the tunnel will
be identified based on the actual data packet, yet all GRE tunnel traffic will be
classified according to the pre-defined rule.
We will see in the next slide how to configure VLAN and GRE catalogs.
Note: it is also possible to change the classification method so that traffic is identified
as the encapsulation tunnel, irrespective of the actual traffic type within.

Classification by Encapsulation Type:

VLAN -IEEE 802.1ad (QinQ)
• Specific VLAN or VLAN Range

• Classification by:
• VLAN ID (12 bits)
• User Priority (3 bits)
• VLAN Type (C-VLAN or S-VLAN)
49
The VLAN Catalog contains Virtual LAN entities defined according to the IEEE 802.1ad
(QinQ) standard. QinQ allows double VLAN tagging. The first/inner tag is called C-
VLAN, and the second/outer tag is called S-VLAN.
In order to define a new VLAN catalog, go to the navigation pane, right-click
Encapsulation and select New VLAN from the shortcut menu. On the VLAN Entry
Properties dialog box, supply Name and Description (optional). You can then choose
whether you want to define a specific VLAN or VLAN Range. Click on the plus button
to open the VLAN Definition window to see the binary equivalent displayed in bit
value fields. VLAN ID is computed from the values chosen for Bits 1-12. Bit 13 is the
reserved bit. The User Priority value is computed from the values chosen in Bits 14-
16 and can be used to specify user priority (7 is the highest priority).
You can also choose to classify by Any VLAN ID or Any User Priority. This is useful if a
user wants to edit the VLAN catalog from the Enforcement Policy Editor to work
with/without VLAN.
Last, you can choose the VLAN Type: the default or C-VLAN or S-VLAN.
The Service Gateway is transparent to Cisco ISL tagging (Cisco uses his own
proprietary VLAN IDs). In other words, the Service Gateway detects that there is an
ISL tag and while it cannot classify traffic based on that tag ID, it can go deeper into
the frame to check regular criteria such as hosts and applications.

Classification by Encapsulation Type:

GRE
10.10.10.12 > 10.10.10.13
GRE Tunnel
router router
Include GRE tunnels originating from

all internal IPs
Include GRE tunnels originating from

specific internal IP
50
GRE (Generic Routing Encapsulation) is a tunneling protocol designed to encapsulate

different network layer protocols inside virtual point to point links over the internet.
In order to define a new GRE catalog, go to the navigation pane, right-click
Encapsulation and select New GRE from the shortcut menu. The GRE Entry Properties
dialog box is displayed.
Complete the Name and Description fields, if required.
Define an Internal (source) IP for the GRE by selecting the relevant radio button. You
may select Any IP (which will include GRE tunnels originating from all internal IPs) or
enter a specific IP. Follow the same step for External IP. Click Save. The new entry is
saved in the Encapsulation Catalog.
A GRE catalog can be used in the policy to assign each GRE tunnel its own priority and
QoS definition according to the policies you define.

Encapsulation Groups
Group several VLANs or GRE tunnels together:
51
After defining the different encapsulation catalogs you can define a new
encapsulation group with one or more VLAN or GRE catalogs.
To create an Encapsulation Group Catalog entry:
1. Select and right-click Encapsulation in the Navigation pane and select New
Encapsulation Group from the popup menu. Define if you wish to create a New VLAN
Group or a New GRE Group.
2. Complete the Name and Description fields, if required.
3. Select GREs or VLANS in the Available list and use the arrow keys to move them
into the Selected list.
4. Click Save. The new Group entry is saved in the Encapsulation Catalog.


• Host
• Service
• Time
• ToS
• Encapsulation
• Interface
52
Now we will examine the “interface” catalog

Defining Interface Catalog

Classification per Interface / Interface Group
53
The Interface Catalog enables you to define individual physical ports or groups of
ports (called Interface Groups) on your Service Gateway for use in policies.
To define a physical port:
1. Select and right-click Interface in the Navigation pane and select New Physical Port
from the popup menu.
2. Select the Service Gateway you wish to define a port on in the Device drop-down
menu.
3. Select the individual port on the selected Service Gateway in the Port drop-down
menu.
4. Click Save. The new entry is saved in the Interface Catalog.
To define an interface group:
(used for classifying traffic from several ports. These ports may be spread over
different blades)
1. Select and right-click Interface in the Navigation pane and select New Interface
Group from the popup menu.
2. Select previously defined physical interfaces in the Available list and use the arrow
keys to move them into the Selected list.
3. Click Save. The new entry is saved in the Interface Catalog.


• Host
• Service
• Time
• ToS
• Encapsulation
• Interface
54
Finally, let’s examine Allot’s Protocol Update capability

What Does it Do?

Update service catalog
55
The NetXplorer operates in a constantly evolving Network environment. New

protocols constantly appear, and existing applications evolve.
The Allot Protocol Updates (APU) are designed to update the service catalog, so that
additional protocols can be identified. APU does not upgrade the software, and no re-
boot is required.
Each Protocol Pack is identified by a Protocol Pack number and build number. For
example, PP3.35.27. The Protocol Pack here is 3.35 and the build number is 27.
Note: After a Protocol Pack Update, Service Assignments to service groups will not
return to default, unless the “Revert service-group assignment to default” is selected

What Do You Need?

Valid Support
Contract Required!
NX Key
SSG Key
SG Key
56
In order to access Web updates you need a valid support contract as well as an
appropriate key for both the NetXplorer server and all the in-line platforms which it
manages. You obtain these keys by renewing your support contract.
To check that APU is included in your NetXplorer key (and to enter a new one if it is
not), from the “Tools” menu select “NetXplorer Application server registration”
To perform the same check for the SSG, from the Network tree select the SSG and
choose “Configuration”. Go to the “Identification & Key” tab. Here you can see if APU
is enabled and you can identify the currently installed protocol pack.

Update Stages
1. Download protocol pack to

NX server
Manual or automatic
NetXplorer
2. Update NetXplorer server
Server
3. Update SSGs Manual only
Secure Service Gateways

57
57
The upgrade process consists of the following 3 steps:

1) Downloading the protocol pack to the NetXplorer server
2) Updating the NetXplorer server
3) Updating the Service Gateways
Note: it is possible to update the NetXplorer or the SG in isolation. If however, a
policy is created based on a service that is only updated in the server, the SG will
ignore it and the user will see mis-classified traffic.
Updating the protocol pack does not require any reboot to the NetXplorer or in-line
platform.

Protocol Pack Update Wizard

Step1: Update from Web Step2: Install Updates on NX Step3: Install Updates on SG
• Protocol updates wizard
• Leads you through each of 3 steps
Signatures added
in this PP Summary
Signatures
updated in this PP
58
Step1: If your NetXplorer server can access the Allot Website on the internet, the simplest
way to perform manual updates is by using the protocol updates wizard. The wizard is
accessed from the protocol updates item on the Tools menu. Choose “From Allot Web Site”.
Step2: Firstly, the wizard will check for updates. A list of changes to be made to the service
catalog and the protocol pack number will displayed. The pending changes are divided into
applications, services and service groups. Each one is split up into “Create” for new
applications/services and groups and “Update” for updating existing ones. Click on “update
now” to download the protocol pack to the NetXplorer and make changes to all of the listed
changes to the service catalogs of the NetXplorer. When the service catalog has been
successfully updated, the list of changes will be displayed. In addition, the successful
installation will be recorded in the alarms log.
NOTE: Services that have been manually moved, added or deleted from a service group by
the user will not change their location due to a Protocol Pack upgrade or rollback, unless the
service has been deleted from the new Protocol Pack, in which case it will also be deleted
from the service catalog and any groups it is part of.
Step3: The 3rd and final stage of the process is to update the Service Gateways. Select the
Service Gateways that you wish to update. In the example above there is only one SG
available. For each SG you can see the services to be changed by clicking the “Advanced”
button. You can also choose the specific PP version you wish to install from this window.
Clicking Next one more time brings you to the end of the process.

APU Configuration and Alerts

Network->configuration->
1
2
3 Note: SSGs must be

updated manually
59
Stages 1 and 2 of the process can be configured to run automatically.

In the Network tree, right-click “Network” and select “Configuration” from the menu.
In the network configuration dialog, select the “Protocol Updates” tab. Note: the
build number is not displayed in this window, only the Protocol Pack version.
Here you can configure the NetXplorer to check for updates periodically (stage 1). If
there is an update, the protocol pack will be downloaded to the NetXplorer server,
and an alarm will be displayed in the alarm log.
You can also choose to automatically install the new update on the NetXplorer server
(stage 2).
Note that in any event, the update of the service catalogs on the SSGs (stage 3) must
be done manually.
Once a Protocol Pack is updated, an alert will show up in the alarm log indicating a
successful update.

Alternative Methods
Where NX Cannot Access Allot Website
1. Download protocol pack to NX server

• From Allot Website (Manually or Automatically)
• From a Server Where NX is not directly
• From a CD connected to Internet
2. Update NX server
NetXplorer Full Procedure in
Protocol Pack
Server Release Notes
3. Update SSGs
Secure Service Gateways

60
We have seen how the upgrade package is downloaded using the wizard and how this
process can be configured to run automatically.
There are additional ways to download the update package to the NetXplorer server
which can be particularly useful when the NetXplorer has no direct access to the
internet.
In this case, the package can be downloaded from Allot Support Area and copied to
another server or a CD.
After you have it, go to the Tools menu in the NetXplorer GUI, and choose Protocol
Updates > From Local Package to update the NetXplorer. Choose Install to Device to
update the in-line platforms.
It is also possible to rollback the NetXplorer and/or the in-line platforms to a previous
version.
Follow the full procedure in the Protocol Pack Release Notes.

Review Question
What condition catalogs do you need to
define for the rule below?
Limit Mpeg download for operations

department users during working hours
Service Group X
UDS Content Mpeg
Time Peak Surfing Hours
Host List Bronze Subscribers
61
What condition catalogs do you need to define in order to create a rule which limits
Mpeg download traffic from operations department users during working hours?

Review Question
Look at the entry identification definitions for the service
below. How will the SSG identify this service?
Any traffic for whom no

application signature can
?
be matched, but which is
running on port number
5634 will be classified as
this particular service
62
Look at the entry identification definitions for the service displayed here. How will the
SSG identify this service?

Exercise
Condition Catalogs
4.1 Host Based Classification
4.2 Classifying by Service
4.3 Classifying by Time
63

ENT-04 Condition Catalogs

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ENT-04 Condition Catalogs

Uploaded by

Copyright:

Available Formats

Module 4: Condition Catalogs

Define policies Report

ACTE (Enterprise Track) 1

• Why Do We Need To Classify?

We will begin by asking why is it important to classify at all?

ACTE (Enterprise Track) 2

Why Do We Need To Classify?

• To gain network visibility

Why do we need to classify network traffic? The answer is twofold.

ACTE (Enterprise Track) 3

Example – Classifying Road Traffic

ACTE (Enterprise Track) 4

Define Your Business Objectives:

• What do you want to achieve?

ACTE (Enterprise Track) 5

• Why Do We Need To Classify?

Traffic classification is performed by defining condition catalogs in the NetXplorer.

ACTE (Enterprise Track) 6

Internal / External Hosts

Hosts are defined as internal or external on the basis of which

External Bypass Unit Internal

ACTE (Enterprise Track) 7

Internal / External Hosts

ACTE (Enterprise Track) 8

ACTE (Enterprise Track) 9

Creating Host Lists and Groups

First, you should define a Host List:

ACTE (Enterprise Track) 10

Host List – Scope

ACTE (Enterprise Track) 11

Importing Hosts from External Text File

• Large groups or lists of hosts can be

ACTE (Enterprise Track) 12

Which Method to Choose?

ACTE (Enterprise Track) 13

External Text File Format

IPv4 range Name;IP-IP IP2;5.5.5.5-6.6.6.6

IPv6 address prefix Name;IP\<prefix_length> Prefix_name;2001:1234::/32

Note: Each entry must be on a

ACTE (Enterprise Track) 14

File Location On the

ACTE (Enterprise Track) 15

Host Group vs Host List Entries

Host: “IP1” Host Text File

ACTE (Enterprise Track) 16

In which Host LIST is a host

ACTE (Enterprise Track) 17

How To Use – Host catalog

Group Users Identify Specific Objects

• Per Location • Mission Critical Server

What other uses can you think of?

ACTE (Enterprise Track) 18

• Why Do We Need To Classify?

Service catalog entries are used to classify traffic by application or protocol.

ACTE (Enterprise Track) 19

How are Services Identified?

• Layer 4 classification: By source & destination IP & port

ACTE (Enterprise Track) 20

Service Objects and Hierarchy

ACTE (Enterprise Track) 21

Service Objects and Hierarchy

Default traffic policy is based on the pre-defined

Services can be updated with the latest