Case 8. Managing Priority for AS (Autonomous Systems)

DPI supports traffic classification by direction through the specification of external autonomous systems (ASN). Labeling by direction takes precedence over labeling by protocol. It is recommended to perform labeling by autonomous system number only for external ASNs (for example, Facebook or Google); this labeling rule will work immediately for all channels and subscribers without the possibility of exceptions.

Policing subscriber ASNs is also possible, but it may disrupt the policing rules set through channel and subscriber settings. It is not recommended to use subscriber ASN policing in conjunction with other types of policing!

For settings, specify:

1. AS number
2. Rule name
3. Public description
4. Priority (select from the list)
5. Tags (select from the list)

Tags values:

• drop — packets should not be forwarded (they should be dropped).
• pass — traffic from this AS is forwarded through DPI transit without analysis and processing.
• local — traffic from this AS is considered local traffic for the operator.
• peer — the operator is peering with this AS; used only for the Caching option.
• term — termination is allowed for this AS.
• mark1 — for AS with this label, SNI will take priority if protocols are specified for both SNI and IP. mark1 for ASN
• mark2 — QUIC traffic without SNI from this AS will be marked as QUIC_UNKNOWN_MARKED. mark2 for ASN
• mark3 — reserved.

Within the traffic classifier, the following default priorities are defined (the lower the number, the higher the priority):

1. Custom protocol identified by IP + port number.
2. Custom protocol identified by IP.
3. Custom protocol identified by SNI or CN.
4. Cloud protocol identified by IP + port number.
5. Cloud protocol identified by IP.
6. Cloud protocol identified by SNI or CN.
7. Embedded protocol.

Embedded signatures can be composite and supplemented with cloud-based records for IP, IP+port, SNI, and CN as needed. Embedded signatures refer to traffic analysis mechanisms built into the DPI engine and applied within the classification tree during session state processing.

When mark1 is set for a specific autonomous system, the detector’s priority for traffic towards this autonomous system is modified as follows:

1. Custom protocol identified by SNI or CN.
2. Custom protocol identified by IP + port number.
3. Custom protocol identified by IP.
4. Cloud protocol identified by SNI or CN.
5. Cloud protocol identified by IP + port number.
6. Cloud protocol identified by IP.
7. Embedded protocol.

Thus, the end user can override any cloud-based or embedded protocol with their own set of IP+port, IP, SNI, or CN.

To check whether an IP address or SNI record belongs to a particular protocol, execute the following console command on the DPI node:

checkproto [ip[:port] | sni | cn]

Note that if an SNI record contains a wildcard (*), the more specific entry takes priority. For example:

1. xyz.abc.com → protocol_1
2. *.abc.com → protocol_2

mark2 enables the reclassification of QUIC traffic where the SNI cannot be extracted into a distinct protocol. When this flag is set for an autonomous system, all traffic classified as QUIC_UNKNOWN will be reassigned to QUIC_UNKNOWN_MARKED. This allows the enforcement of specific blocking policies for unidentified traffic targeting the designated autonomous system.

Currently, blocking QUIC_UNKNOWN_MARKED sessions leads to the re-establishment of a new session with a properly filled Client Hello message. This improves traffic identification accuracy and reduces the proportion of unrecognized sessions.