hledat:

Flow-Based Traffic Analysis System - User Interface

CESNET technical report number 9/2006
also available in PDF, PostScript, and XML formats.

Tom Kosnar
13.9. 2006

1   Abstract

Flow-Based Traffic Analysis System - FTAS is an experimental system designed for generic analysis of flow-based traffic data being developed at CESNET. This report tries to describe the two main parts of its user interface designed to provide queries from data collections prepared by FTAS main system and to visualise results of these queries.

2   FTAS User Interface Summary

The FTAS user interface architecture follows the conclusions given by [Kos14] - 1.4 Accessing traffic information. The whole user interface is a web delivered application called through CGI (Common Gateway Interface) at server side. It is written in perl. User interface package may be present at any collector-host (described in [Kos15]) of FTAS installation instance (typical), but also at any host outside.

We keep the idea of the two-phase work - one query & multiple visualisations. We also support optional aggregations while running queries. Optional aggregations at time of data visualisations are available too. With respect to this we designed and developed two basic experimental components of the FTAS user interface:

• The Query component provides data retrieval and results storage into separate data sets.
• The Viewer component provides visualisation of data prepared by the Query component.

3   The "Query" Component

The Query component is the default when user starts to work with FTAS user interface. It consists of a single section - Object Selection - in its initial state (Figure 1).

3.1   "Object Selection" Section

The Object Selection offers list of available data sources (Objects) and simple filtering mechanism (for cases with large numbers of available Objects). Currently available Object types are collections of data representing:

• flows received from primary flow sources (routers)
• results of flow filtering according to traffic filter configurations
• results of flow filtering according to configured accounting conditions
• results of accounting

Data source types availability depends on current configuration of the whole FTAS installation instance. In typical configuration the first two types are available. The last one is still very experimental.

User has to choose one of available data sources to be allowed to run any query. Requested data source must be selected from the list and explicitly chosen with the help of the Use button (selecting another source from the list without clicking the Use button does not have any effect). After that information associated with selected data source is retrieved from Master Configuration ([Kos15] - 1.6 Master Configuration). The Query component is then extended according to parameters tied with the selected Object (Figure 2).

The page itself is extended with two additional sections. The first one for setting conditions for data retrieval (Selected Object) and the second for setting parameters of query procedure itself (Query Parameters).

3.2   "Selected Object" Section

3.2.1   Object Description

First area in this section contains general information about selected Object - its type and description, additional configuration parameters (when "show selected object extended description..." in Object Selection section is in "ON" state) and information about basic storage parameters. Some Objects may be configured in such way, that both primary and post-processed data are stored and kept in the storage ([Kos14] - 1.9 Flow Post-processing and [Kos15] - 1.5.3 Post-processor). In these cases additional information is printed - Data Alternative column with button which enables to switch between POST-PROCESSED an PRIMARY data collections.

Here are some explanatory real Object Description examples corresponding with typical FTAS data collections.

3.2.2   Object Description - Example 1

Figure 3: Object description example 1. (large image)

Example 1 (Figure 3) shows description of an Object associated with primary flow source. The Configuration Parameters column contains information about configured sampling ([Kos15] - 1.5.1 Primary Flow-source Receiver) and flow export versions. The Data Storage Information informs how the data are stored and kept in storage - here the data are kept in the storage for 7 days without any aggregation and are stored into data sets (database tables) corresponding with two minutes time interval.

3.2.3   Object Description - Example 2

Figure 4: Object description example 2. (large image)

Example 2 (Figure 4) shows description of an Object representing PRIMARY data collection created according to traffic filter configuration. The Configuration Parameters column contains information about configured Filter Conditions which are applied on flows coming from Flow Sources.

3.2.4   Object Description - Example 3

Figure 5: Object description example 3. (large image)

Example 3 (Figure 5) shows the same Object as in previous case, but points to the POST-PROCESSED data collection. The Statistics Parameters and Statistics No-Grouping columns give information about the way of source data sets processing (database tables covering defined time interval in PRIMARY data collection). Each source data set is aggregated according to exclusive groups of values given by fields sub-set (fields listed in "Statistics No-Grouping" column) and then ordered (result of Bytes-measured field aggregation in descending order - Ordered by label). The time range of aggregation corresponds with configured "time size" of data sets, which is labelled as aggregation base in Data Storage Information column. Statistics No-Grouping column gives information how are the aggregated results processed (secondary aggregation) and which records are stored:

1. first 20 exclusive combinations (Bytes-measured order) of Dst-IP, Protocol, Src-Port, Dst-Port, Src-Group fields are stored for every hour (not first 20 from the aggregated result, but first 20 after processing all rows of that result)
2. then next 50 exclusive combinations of Dst-IP, Protocol, Src-Port, Src-Group fields
3. then next 50 exclusive combinations of Dst-IP, Src-Group fields
4. the "rest of data+Src-Group" means, that all rows, which didn't fall to any previous top-list (algorithm is duplicate free) are aggregated according to Src-Group field and stored

This is an example of mechanism described in [Kos14] - 1.10 Specific Aggregations

3.2.5   Object Description - Example 4

Figure 6: Object description example 4. (large image)

Example 4 (Figure 6) shows information about the same Object type as in example 3, but the POST-PROCESSED data collection creation mechanism differs in this case. There is an additional parameter in the Statistics Parameters column - the Group Definition Key. Data sets in the POST-PROCESSED data collection consist of aggregated records computed from the PRIMARY data collection in the following way:

1. first 10 exclusive combinations of Dst-IP, Protocol, Src-Port, Dst-Port fields - Statistics No-Grouping column (similar to previous example)
   
2. Statistics per Group column informs that next processing is performed for each exclusive Group Definition Key (exclusive combinations of Src-IP, Flow-Source fields found in the source data set) independently and results are stored according to the following scheme:
   1. first 10 exclusive combinations of Dst-IP, Protocol, Src-Port, Dst-Port fields
   2. then next 10 exclusive combinations of Dst-IP, Protocol, Src-Port fields
   3. then next 10 exclusive combinations of Dst-IP, Protocol fields
   4. the rest consists of aggregates given by exclusive Protocol field values

3.2.6   Fields selection

Second area in Selected Object section allows users to select data fields they are interested in. As was mentioned above this set of available fields is constructed according to information associated with current Object configuration parameters. Each Object may have its own field set configured. Only valid fields from this point of view are offered in this section. Some of the fields (default subset) are set to "ON" state when loading first data source or in case when all available fields are in "OFF" state. Choosing proper fields is very important when user wants to aggregate data during query (area in Query Parameters section). Every selected field becomes either a part of the grouping key or is subject of some computation in that case. All matching records from every source data set are aggregated according to fields participating in the grouping key ("GROUP BY" clause in SQL) which may rapidly reduce the number of records in result and speed up the visualisations (giving up exact time information of course).

Here is the list of fields which become a part of grouping key when selected:

Field	Description
Src-IP	Source IP address (v4, v6).
Dst-IP	Destination IP address (v4, v6).
Protocol	IP protocol byte.
Src-Port	Source service port number.
Dst-Port	Destination service port number.
Src/Prev-AS	Source or previous BGP autonomous system number (depends on flow source configuration).
Dst/Next-AS	Destination or next BGP autonomous system number (depends on flow source configuration).
Src-ifIndex	Input interface index (SNMP) at flow source.
Dst-ifIndex	Output interface index (SNMP) at flow source.
Src-Bitmask	Number of bits in mask - source address.
Dst-Bitmask	Number of bits in mask - destination address.
Nexthop	IP address of next-hop router (v4, v6).
TOS-flags	IP Type of Service byte.
TCP-flags	Cumulative of all the TCP flags for flow.
Flow-Source	Primary flow source identifier.
Src-Object	Low level accounting attribute of source - may be something like sub-organisation level.
Dst-Object	First level accounting attribute of destination - may be something like sub-organisation level.
Src-Organisation	Second level accounting attribute of source - may be associated with organisation.
Dst-Organisation	Second level accounting attribute of destination - may be associated with organisation.
Src-Group	Third level accounting attribute of source (highest) - may be associated with groups or types of organisations.
Dst-Group	Third level accounting attribute of destination (highest) - may be associated with groups or types of organisations.

Table 1: List of fields which become a part of grouping key when selected

Here is list of fields which are subjects of computation when aggregation is requested:

Field	Description	Aggregation Result
Flow-Start	Time at which the first packet associated with the flow was switched.	MINIMUM
Flow-End	Time at which the last packet associated with the flow was switched.	MAXIMUM
Pkts-measured	Number of packets associated with the flow.	SUM
Pkts-estimated	Number of packets estimated (equals to Pkts-measured when no sampling applied).	SUM
Bytes-measured	Number of bytes associated with the flow.	SUM
Bytes-estimated	Number of bytes estimated (equals to Bytes-measured when no sampling applied).	SUM

Table 2: List of fields which may be subjects of computation.

Typical field set examples are shown in Figure 7 and Figure 8).

3.2.7   Simple Query Condition Form

Third area in Selected Object section enables users to set up query conditions. Users can set up conditions for any field which exists in selected data collection including fields that were not selected to be retrieved. The first way how to set up query conditions - Simple Form - is based on ad-hoc prepared form containing inputs for any existing field in the selected data collection (Figure 9).

Logical bindings of conditions for source and destination field pairs can be explicitly set up (ignored when condition is set up for one "side" only). Conditions or pairs of conditions are then joined with logical AND when the resulting query condition is constructed.

Some field conditions may be set up as selections from lists of authorities. All lists allow multiple selections. Conditions for the rest of fields are set up as plain text. Each field condition may consist of several partial conditions. Partial conditions are comma-delimited. Parts are joined with logical OR. The syntax and examples of appropriate field conditions follows:

IP address
Associated Fields	Src-IP, Dst-IP
Condition Syntax	Hostname, IPAddress, FromIPAddress-ToIPAddress, IPAddress/Mask, IPAddress/MaskBits
Notice	Host names are always resolved at the time of query construction. IPv6 conditions must be currently set up in full format - for example: ff02:0000:0000:0000:0000:0000:0000:0005
Condition Example	www.cesnet.cz, www.liberouter.org, 10.0.0.1-10.0.0.23, 224.0.0.0/255.255.255.0, 127.0.0.0/8, 0123:0000:0000:0000:4567:0000:0000:8900
Service Port
Associated Fields	Src-Port, Dst-Port
Condition Syntax	ServiceNumber,FromServiceNumber-ToServiceNumber
Notice	Currently only numbers are allowed (no translation from/to names is implemented).
Condition Example	80,3306,4001-4015
AS Number (origin/neighbour)
Associated Fields	Src/Prev-AS, Dst/Next-AS
Condition Syntax	ASnumber, FromASnumber-ToASnumber
Notice	Numbers only - without any prefixes like 'AS'.
Condition Example	2855, 65000-65534
Interface SNMP Index
Associated Fields	Src-ifIndex, Dst-ifIndex
Condition Syntax	SNMPIndex, FromSNMPIndex-ToSNMPIndex
Notice	Currently only numbers are allowed (no translation from/to names is implemented).
Condition Example	2, 11-35, 42, 75-76

Table 3: The syntax and examples of plain text field conditions in simple condition form.

3.2.8   Advanced Query Condition Form

Second way how to set up query condition is the Advanced Form (Figure 10). Users can switch between simple and advanced forms with the help of the button in upper-right corner of the area. Advanced query condition form is based on entering the whole condition for all fields including grouping and logical operators. The basic principles of syntax are:

• Conditions associated with fields may be either field_identifier=field_condition to perform positive match or field_identifier<>field_condition to perform negative match; field_condition may be single condition or comma-delimited list of conditions.
• The 'and', 'or' operators bind conditions or groups of conditions together and perform logical AND, OR operations.
• Brackets () provide grouping of conditions or groups of conditions.

Here is basic field condition syntax description for advanced condition form:

Field	Field condition syntax
Src-IP	src_ip=Hostname, IPAddress, FromIPAddress-ToIPAddress, IPAddress/Mask, IPAddress/MaskBits
Dst-IP	dst_ip=Hostname, IPAddress, FromIPAddress-ToIPAddress, IPAddress/Mask, IPAddress/MaskBits
Protocol	proto=ProtoNumber, FromProtoNumber-ToProtoNumber
Src-Port	src_port=ServiceNumber, FromServiceNumber-ToServiceNumber
Dst-Port	dst_port=ServiceNumber, FromServiceNumber-ToServiceNumber
Src/Prev-AS	src_as=ASnumber, FromASnumber-ToASnumber
Dst/Next-AS	dst_as=ASnumber, FromASnumber-ToASnumber
Src-ifIndex	src_if=SNMPIndex, FromSNMPIndex-ToSNMPIndex
Dst-ifIndex	dst_if=SNMPIndex, FromSNMPIndex-ToSNMPIndex
Nexthop	nexthop=Hostname, IPAddress, FromIPAddress-ToIPAddress, IPAddress/Mask, IPAddress/MaskBits
TOS-flags	tos=TOSNumValue, TOSNumValue
TCP-flags	tcp_flags=FlagNumValue,FlagNumValue
Notice: Conditions for fields listed below must be currently set as numbers (IDs from configuration database) which values are available through interface component for administration only. There is currently none helping list of name-ID pairs available.
Field	Field condition syntax
Flow-Source	flow_source= FlowSourceID, FromFlowSourceID-ToFlowSourceID
Src-Object	src_acc_obj=AccObjID, FromAccObjID-ToAccObjID
Dst-Object	dst_acc_obj=AccObjID, FromAccObjID-ToAccObjID
Src-Organization	src_acc_obj=AccOrgID, FromAccOrgID-ToAccOrgID
Dst-Organization	dst_acc_obj=AccOrgID, FromAccOrgID-ToAccOrgID
Src-Group	src_acc_obj=AccGrpID, FromAccGrpID-ToAccGrpID
Dst-Group	dst_acc_obj=AccGrpID, FromAccGrpID-ToAccGrpID

Table 4: Field identifiers and associated field condition syntax in advanced condition form.

3.2.9   Advanced Query Condition Form Examples

Here are some examples for better demonstration how to set up real conditions.

Example 1 - traffic from tcp/80 at www.cesnet.cz or traffic to tcp/80 at www.cesnet.cz:

proto=6 and
( 
 (src_ip=www.cesnet.cz and src_port=80)
  or 
 (dst_ip=www.cesnet.cz and dst_port=80)
)

Example 2 - the same effect as in previous example, but the port numbers (80) are set up with the help of negative match:

proto=6 and 
( 
 (src_ip=www.cesnet.cz and src_port<>0-79,81-65535)
  or 
 (dst_ip=www.cesnet.cz and dst_port<>0-79,81-65535)
)

Example 3 - TCP traffic where cumulative TCP flags contain ack(16) and either tcp/25,80 at www.cesnet.cz or tcp/179 anywhere:

tcp_flags=16 and proto=6 and 
(
  (
    ( 
      (src_ip=www.cesnet.cz and src_port=80,25)
      or 
      (dst_ip=www.cesnet.cz and dst_port=80,25)
    )
  )
  or 
  ( src_port=179 or dst_port=179 )
)

Example 4 - TCP traffic, where cumulative TCP flags contain syn(2) only:

proto=6 and tcp_flags=2 and tcp_flags<>1,4,8,16

Example 5 - any traffic with IPv6 source addresses:

src_ip=0000:0000:0000:0000:0000:0000:0000:0000-
ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff

3.2.10   Setting time parameters for queries

Last area in Selected Object section allows users to set up investigated time range (Figure 11). Two input fields have the start time - end time meaning. Values may be set either as absolute in format YYYY/MM/DD hh:mm:ss or as relative to current time. Relative values have the current-Xy syntax where X is a count of y time intervals (m implies minutes, h hours and d days). The current value implies the time when query starts (when user clicks on the Run New Query button in Query Parameters section). For example current-12h means twelve hours before the query starts. Empty values are substituted with current value.

There is a special, very experimental parameter at the bottom line of this area - optional time step. Here has to be mentioned that the time granularity of any query is computed at the time when query starts. It is the basic time interval which gives the time spacing of values or time size of partial value sums in the Viewer component. The default value auto lets the system to compute the value. Users can set up demanding time step as the number of seconds, but system will correct that value in case it should cause some problems. Total number of time steps computed is checked against hard-coded limits - currently no more than 60 steps/range and no less than 1 step/range are accepted. For example user should set this value to 3600 and start of the investigated time range to hour boundary when he wants to see hour summaries.

3.3   "Query Parameters" Section

This section enables users to start the real query and set up how it will be run. Users can choose (with the help of Query Limits area) whether the real query will be run in interactive mode or will be run on background. Interactive queries (Figure 12) are performed in one or more query steps - each is limited by time (Max. query time parameter) and number of records stored in current query step (Max. record count parameter). Beside this, there is a limit for total number of saved records hard-coded inside.

First two parameters are ignored when running background queries. Users have to check run in background to run background queries (Figure 13). They can also fill the after finishing notify to input field with an email address where the notification should be sent after the query finishes. Notification contains some query statistics and also direct link to query results (Figure 15, Figure 16).

The last parameter here is request for optional aggregation in the Aggregate Query area (mentioned above). Data are aggregated on the source data set (database table) basis (Figure 14). Time step of aggregation corresponds with the data sets "time size" (Object Description section, Data Storage Information column). New query is started after clicking on the Run New Query button.

Interactive queries results are displayed in the Query Results section. In case of background queries which results are notified (users type valid email addresses) notifications may look like in the following examples.

3.4   "Query Results" Section

This section allows users to control queries which have been started in interactive mode. When query stops without being completely finished (Figure 17), users can run on its execution with the help of Continue button. This action is sensible to any parameter changes in the Query Limits area (Query Parameters section). It means that users can change the number of record limit or time limit and continue query in interactive mode - there is some statistical information displayed after each query step (Query Statistics column) to help users to control next query steps. Beside that users can check run in background (and optionally set email address for notification) and move the rest of the query process to background. Users can also analyse partial results (buttons in Viewer Window Options column where this window means current window, separate window means stand-alone browser window dedicated to current query results and standard viewer window means stand-alone browser window shared by all FTAS sessions). Example of finished interactive query is shown in Figure 18.

4   The "Viewer" Component

Main task of the Viewer component is to visualise data sets created by the Query component. Viewer can be accessed from the top line of any component of the FTAS user interface (Viewer button). Then it looks and behaves similar to Query component in its initial state and contains Results Selection section only (Figure 19).

The other way how to enter the Viewer component is accessing it directly from the Query Results section in the Query component (any button in Viewer Window Options column) - query results are selected by user interface automatically in that case.

4.1   "Results Selection" Section

The Results Selection section offers list of available data sets (Results) created by the Query component. User has to choose one of available Results to be allowed to visualise it. Users must click on the Use button for that (selecting other Result from the list without clicking the Use button does not have any effect).

There are two types of Results - temporary query results and permanent query results. Temporary is the default attribute for any data set created by any query. These Results are automatically deleted by the system after some time. Current expiration time for temporary query results is set to 24 hours (since time they were created). Users can make any selected Results permanent with the help of the button on right side of the bottom line (save these results permanently as) and save them under name given by the value of the corresponding input field.

Each result description in the list consists of its name (defaults to the name of the source data collection) and creation time. Queries in INCOMPLETE state are identified with additional asterisk character '*' at the end.

Additional sections appear in the Viewer component window after clicking on the Use button (or entering the Viewer component directly from Viewer Window Options in Query component). These sections are: Selected Results and View Parameters (Figure 20).

4.2   "Selected Results" Section

This section consists of two parts. The first one - Results Description - is optional and depends on show selected results extended description... state (in Results Selection section). The second part contains switches to select fields.

4.2.1   Results Description

Extended description contains information about data collection the query was run on and information about query itself - its name, final state, time parameters, number of records stored and query conditions applied. This information may be useful especially when the source data collection is post-processed (as shown in Figure 21) - it may draw users attention to the fact that some of the records may have some fields empty.

4.2.2   Fields selection

Corresponding area contains all fields available for visualisation. This set of fields is given by conjunction of fields presented in data collection and fields selected in Query component. So called Value Fields (packet, byte and time based fields) are exception from that and are available by default. Optimal set of selected fields (same importance here as in Query component) is one of the keys how to achieve desired results fast and without wasting resources. When query has been well configured then combination of selected fields and values set up in View Parameters section (below) ensures the quality of final report.

4.3   "View Parameters" and "Results" Sections

Parameters in the View Parameters section (Figure 22) determine how will the final result look out. There are currently two types of output reports available  - textual and graphical. There are specific parameters associated with each type, some other parameters are common.

After choosing the desired output type, users have to set up ordering parameters (field and direction) in both cases. There is no relation between field selected as the base for ordering and fields selected in Fields selection area - users can use any available field regardless of it was selected to be displayed in output report or not.

Output report is generated after clicking on the Display button and is displayed in separate Results section. There are some differences between textual and graphical report generation mechanisms as well as between parameters associated with each report type and also browsing options slightly differ. Therefore each report type is described separately.

4.3.1   Textual Reports - Aggregation

In case of textual reports, users may set whether the data should be aggregated or not - this is another key parameter (together with selected fields). We demonstrate its importance in the following example which also shows typical textual reports.

Let's imagine that user wants to generate the top list of data sources from data collection described in Figure 23.

We can see, that query was run on post-processed data collection representing results of flow filtering. Data aggregation was not set up for query, but data in collection are already aggregated - it is the result of post-processing mechanism. Time base for aggregation is one hour in this case (see Data Storage Information column).

Results description in Selected results section implies (see Statistic No-Grouping column) that there may be some records with empty Src-IP field (bottom line: rest of data+Dst-Group) in the resulting data set. Src-IP field is the only one key field selected for visualisation, but user forgot to set up aggregation (it is set to off). So we see first 20 (recs/page parameter) of 3075 records created by query ordered by Bytes-estimated field in descending order (Figure 24). Each record fits into one hour (original aggregation time base) - and we see first 10 records with empty Src-IP fields (given by configuration of post-processing) - this is probably not what user expects to see. Now we set up aggregation to on state (Figure 25).

It is the expected top-list. Each Src-IP field value (including the empty one) appears only once in the output report and time range of appearance is given by the first and last time of appearance during the whole requested time interval.

4.3.2   Textual Reports - Results Browsing

The recs/page parameter limits number of records displayed at once. Except the Display button, users can browse through the output report with the help of the following buttons which are located in upper-left and bottom-left corners of the output report table:

Button	Action
Display	Generates report page according to actual parameters starting with first record in actual order. It means that any View Parameters values changes as well as selected field set modifications are accepted. Unlike other buttons this one also adopts recs/page parameter value changes.
o	Generates report page according to actual parameters starting with the record number currently displayed on top of the page. Accepts any relevant parameter changes except recs/page value.
>	Generates report page according to actual parameters starting with record number increased by original recs/page value. Accepts any relevant parameter changes except recs/page value.
<	Generates report page according to actual parameters starting with record number decreased by original recs/page value. Accepts any relevant parameter changes except recs/page value.

Table 5: Buttons for browsing through the textual output report.

4.3.3   Textual Reports - Additional Buttons

There are some specific fields containing IP addresses or autonomous system numbers. Values of these fields are highlighted by default and have a form of button which generates stand-alone browser window offering some additional information about appropriate object - like in the following examples (Figure 26, Figure 27).

4.3.4   Graphical Reports

Graphical reports aggregate the source data automatically. The default report gives information about sums of values within the requested time interval and their time behaviour during that interval (rates) - both are shown in Figure 28.

Both pie graphs above show the portion of the total amount of value (bytes in this case) displayed in the main graphs on the left side. The red-green rate graph in the rates part shows the same but distributed in time. These additional graphs help users to judge the significance of the main graphs.

An alternative to the rates part of the graphical output are summaries per time steps. Let's assume, that we configure 3600 second time step for the same query (Figure 29).

Then we check show summaries/time-step rather than rates in the View Parameters section (Figure 30).

In this case the rates part of the output report is substituted with graph showing summaries per time steps - one hour sums in this example (Figure 31).

4.3.5   Graphical Reports - Results Browsing

Browsing the graphical results is similar to the textual ones. Main difference is that number of records displayed in each part of graphical output report is hard-coded and cannot be changed through the user interface. Basic navigation buttons have the analogous meaning and functionality behind. But there are additional buttons available. The following table gives list of all available buttons for graphical report browsing:

Button	Action
Display	Generates report page according to actual parameters starting with first record in actual order. It means that any View Parameters values changes as well as selected field set modifications are accepted.
o	Generates report page according to actual parameters starting with record number currently displayed on top of the page.
<	Generates report page according to actual parameters starting with first record number decreased by 8 (number of records in rates or summaries per time steps parts).
>	Associated with the "o" button generates report page according to actual parameters starting with first record number increased by 8 (number of records in rates or summaries per time steps parts).
>	Associated with data record generates report page according to actual parameters starting with record number of the associated record.
N.	Where N. is the record number. Generates report page according to actual parameters containing record with associated record number only.

Table 6: Buttons for browsing through the graphical output report.

4.3.6   Graphical Reports - Additional Buttons

Functionality of additional buttons (highlighted values) is identical in both textual and graphical reports.

4.3.7   Additional parameters

There is a set of common parameters at the bottom line of View Parameters section. They have the same meaning for both types or output reports:

resolve host names

This check-box turns host name resolution on. Resolution is provided in real time - every time the output report page is generated. It means that it may rapidly slow down response especially when number of values is high (recs/page parameter in textual reports).

hide viewer form

This check-box turns all Viewer Component sections except Results off.

hide links in results

This check-box turns all active objects (buttons, links) in Results section off.

send (*.tar) with directory name

Checking associated check-box causes sending output report to browser in the form of tar archive. Name of the archive corresponds with the value of associated input field (default value is FTAS). Report consists of a directory (name corresponds with the value of associated input field) which contains index.html file and optional image files in png format. After extracting files from archive and loading index.html to browser at client side, the browser window contains Results section only without any active elements. Output looks like the interactive one with hidden viewer form and hidden links in results.

5   Conclusion

This is a short overview of the FTAS user interface and functionality in its state in autumn 2006. It may help current users to use it more effectively or inspire others who are building similar systems. The whole FTAS system itself is still a functional prototype under continuous development. Although we see some open areas for its further development (automated security related behaviour, more output information or single purpose wrappers for example), we would like to keep its generic character and use it as an open platform for flow based traffic analysis which helps us to observe the network traffic from different points of view and find what is significant in various contexts.

References

[Kos14]	Kosnar T. Notes to Flow-Based Traffic Analysis System Design CESNET Technical Report 14/2004 (available online)
[Kos15]	Kosnar T. Flow-Based Traffic Analysis System - Architecture Overview CESNET Technical Report 15/2004 (available online)