Versa Networks

Release 20.1.0
Feature Summary

Release Date September 27, 2018

 2

Table of Contents
Table of Contents ........................................................................................................................................... 2

DIA / DCA (SaaS) Traffic Optimizations ........................................................................................................... 3

DNS Proxy ....................................................................................................................................................... 5

Dynamic Path Bandwidth Measurement for SD-WAN Paths ......................................................................... 6

Pre-defined Application Groups and Application Filters ................................................................................ 7

LTE Focused Dynamic Probing Optimizations ................................................................................................ 8

Intel QAT Support ........................................................................................................................................... 9

Multicast ......................................................................................................................................................... 9

BGP Route Aggregation ................................................................................................................................ 12

RIPv2 ............................................................................................................................................................. 13

Device Finger-Printing and Logging .............................................................................................................. 14

File Filtering .................................................................................................................................................. 15

Lateral Movement Detection and Prevention .............................................................................................. 15

uCPE Cloudinit Support ................................................................................................................................ 16

Provisioning and ZTP Workflow Support for Routing and Security Use-Cases ............................................. 17

Hierarchy of templates (Ordered List Support) ............................................................................................ 17

Versa Analytics Fusion .................................................................................................................................. 18

Netflow-Based Flow Export .......................................................................................................................... 18

Copyright Versa Networks, Inc. All rights reserved

 3

DIA / DCA (SaaS) Traffic Optimizations

Versa provides a variety of traffic optimization features in book ended deployments. In
addition, our customers need traffic optimization solutions for single ended
deployments (when Versa FlexVNF is only on one end). Such scenarios involve SaaS
applications. As SaaS based applications are used more commonly by enterprises, this
unique capability becomes increasingly more important.
With this capability, Versa customers’ client devices can select best path(s) towards
Cloud SaaS providers based on application flow performance characteristics, measured
in single-ended FlexVNF deployments (without requiring another participating FlexVNF).
Such SaaS application performance measurements will allow Versa FlexVNF software to
assign Experience Score to these flows, allowing network administrator to manage
traffic based on performance policy and actual scores for each session. Such a capability
gives the best application experience on single ended DIA/DCA (SaaS) deployments.
In a deployment scenario with Direct Internet Access (DIA) connections, such as one
with a single or multiple broadband links connected directly to the branch site, the best
path to a SaaS application may be a direct connection from the branch. Alternatively,
the best connection to the cloud may be via a Versa FlexVNF instance deployed as a
cloud interconnection hub, while such hubs may be deployed in a variety of locations:
customer data center, an internet interconnection and/or hosting facility, such as
Equinix, or the SaaS provider’s data center.
In such scenarios, route resolution or basic methods like pings will not be sufficient to
predict the actual SaaS experience qualities that the user will experience. The need is to
determine the best path towards the Cloud SaaS provider, based on actual application
data.
In order to address this need, Versa software provides unmatched capabilities that are a
mix of route resolution, DNS resolution (to these well-known SaaS sites), detailed TCP
flow analysis and SD-WAN traffic steering capabilities, all working in harmony.
In its first release, Versa provides a true inline analysis based DIA/DCA SaaS traffic
optimization capabilities. Let us quickly talk about how this works.
As client initiates the connection to a well-known SaaS site, DNS proxy server resolves
the fully qualified domain name (FQDN) locally or forwards the inquiry to its broadband
or VPN links, to get it resolved to the IP address (via the use of DNS proxy or DNS server
entries populated by Versa Director). After the FQDN resolution happens, client
connects to SaaS provider’s web based services by using IP address provided by the DNS
proxy. While the resolution to that route may occur through multiple nexthop

Copyright Versa Networks, Inc. All rights reserved

 4

interfaces, FlexVNF would choose appropriate (one) nexthop interface to anchor that
flow and starts employing full (TCP) flow analysis. This flow analysis data establishes
very important data points for the performance of that flow, originated from that
branch, destined to that particular SaaS FQDN.
This process will repeat with more flows, eventually forming a large enough data pool
for that specific FQDN and by using that information, next set of flows will be forwarded
on best performing paths / nexthops destined for that FQDN.
Such real, TCP flow-based session analysis includes request, response, retransmission,
packet losses, and other critical flow details, thereby allowing Versa to establish reliable
data points for each SaaS FQDN from that site.
As part of that analysis, Versa assigns Application Experience score which is viewable
and will be used to manage traffic by using SD-WAN policies. As Versa FlexVNF
continuously analyzes these flows, it will be able to detect changing network conditions
and it will assign each new flow to the best path available for that FQDN.
Versa FlexVNF instances, irrespective of whether they are spokes or hubs, collect
various transport layer as well as application layer metrics for SaaS application sessions,
transiting the appliance in an inline fashion.
Furthermore, this information can be shared across the SD-WAN control plane of Versa,
giving the opportunity to distribute this information across the network, helping make
best decisions. Thus, spoke sites have information about whether direct internet access
or access through the hub would provide better performance.
Such information is collected locally across multiple links or paths and/or learned from
hub sites through SD-WAN Control Plane. Hence, FlexVNF can anchor flows to best
performing links or paths to those specific SaaS destinations and monitor the flows on
an ongoing basis so that if / when conditions change, it can implement appropriate
update and steering decisions and propagate that information to the rest of the
network.
The following are some examples of how SaaS connectivity may be realized.
● Direct access only
● Access through Internet hubs only
● Combination of direct and Internet hub access
In addition, the deployment modes may be categorized according to the various ways in
which passive metrics, active CFM metrics, and active application metrics are combined
to measure SaaS performance.

Copyright Versa Networks, Inc. All rights reserved

 5

One can think of this multi-dimensional feature as an intelligent ADC like function that is
applied over to a SD-WAN network while the assets are spread over Internet and
accessible through disparate ways.

DNS Proxy
A DNS proxy server takes DNS queries from a local network and forwards them to an
Internet or Intranet (authoritative) Domain Name Server. DNS proxy may also cache DNS
records. There are a few different modes of DNS proxy servers and both of these modes
are supported by Versa FlexVNF:
• Split Proxy: The DNS split proxy feature allows you to configure your DNS proxy
server to split the DNS query based on both the interface and the domain name.
You can configure a set of name servers and associate them with a given domain
name. When you query that domain name, the device sends the DNS queries to
only those name servers that are configured for that domain name to ensure
localization of DNS queries.
You can configure DNS split proxy based on the network transport domain. For
example, when the device has broadband connection(s) as well as MPLS-VPN or
IPSec VPN connection(s) to the corporate network through an IPsec VPN or any
other secure tunnel, you can configure DNS split proxy to use the secure VPN
tunnel to transport the domain name inquiries or traffic to such domains
belonging to the corporate network. In such a case, intranet DNS resolution
queries are not leaked to the ISP DNS server and are contained within the
corporate network.
If the client wants to reach to destinations on the Internet, DNS split proxy would
be able to guide to these client requests for anycast DNS servers, such as 8.8.8.8
that are located on Internet to resolve them in the best ways.
• Transparent Proxy: Transparent DNS proxy is a server that sits between your
computer and the Internet and redirects your requests and responses without
modifying them. A proxy server that does modify your requests and responses is
defined as a non-transparent proxy.
This mode allows client’s DNS queries to be forwarded to designated or well-
known DNS servers. DNS proxy is configured in the transparent mode when the
network for extranet queries and for the purpose of providing geo-location
optimized delivery.
Also, network operators can choose to use transparent DNS proxy to intercept all
DNS lookup requests (TCP/UDP port 53) to transparently proxy the results,
forcing clients to use their DNS service for all DNS lookups.

Copyright Versa Networks, Inc. All rights reserved

 6

Versa supports both modes of DNS proxy. Both TCP and UDP DNS protocols are
supported. Versa DNS proxy also supports DNS clients that use single UDP/TCP
connections and requests multiple transactions (DNS queries on different domains). In
such a scenario, FlexVNF does proxy based on each transaction.
You can also configure Versa DNS proxy with static entries, which will allow you to
configure static FQDN-to-IP address mappings, that is then provided in response to DNS
queries.
Today, you can use Versa’s DNS proxy to optimize name resolution requests on a per
region basis (geo location-based optimization). Versa DNS proxy can also be used to
manage the flow based on the first package. Firstly, packet-based lookup and traffic
direction (instead of scanning 4-5 packets as with the case with DPI) allows the flow to
be anchored on the interface based on domain name and route resolution, establishing
CGNAT and other records right from the first packet. Note that once CGNAT records are
established with the first packet, and once a session translation table is established on a
path, it cannot move to another interface as that will force a different address
translation, breaking the flow. For such reasons, DNS proxy is a key building block used
in Versa’s DIA/DCS (SaaS) traffic optimizations feature.
In subsequent releases, Versa DNS proxy implementation will expand to cover dynamic
DNS, DNS feeds, filtering functions. The latter will secure DNS inquires and provide
additional layer of security (roadmap).

Dynamic Path Bandwidth Measurement for SD-WAN Paths

Starting from our prior major release, 16.1R2, Versa provides available bandwidth
(bandwidth) measurement capability between any two Versa SD-WAN end points. Using
this capability, our customers started measuring available bandwidth to make informed
decisions about their policer configurations, QoS/App-QoS parameters, and network
traffic engineering policies.
This capability has been developed in an innovative way such that it is non-intrusive,
and it ensures that it does not disrupt customer’s ongoing traffic. Once the
measurement process is started, Versa sends appropriate traffic patterns at the
appropriate intervals to measure the real available bandwidth and at the end of the
measurement window, the data has been made available to the network operator.
In 16.1R2, this capability required manual trigger of the process by the network
operator. The operator could get the results exactly after 2 minutes and do the needful.
In 20.1.0, this capability has been enhanced further to be scheduled on a periodic basis
across the network. This enhancement allows our customers to measure their available

Copyright Versa Networks, Inc. All rights reserved

 7

bandwidth across the network at pre-determined times of the day (for example, at peak
times, at very low utilization times) and by days of the week so that they can collect this
information from their network on a systematic basis.
Such systematically collected data allows our customers to build large pool of measured
network available bandwidth across any or all points of the SD-WAN network. This data
will not only form a baseline but also help our customer see trend changes over time
and react to it or plan upgrades or changes proactively.
Once enabled, this data is collected and trended by Versa Analytics and it is ready to be
consumed by our customers by using effective windows and reporting capabilities of our
big data analysis tool.

Pre-defined Application Groups and Application Filters

Versa provided predefined Application Service Templates in 16.1R2 to classify and
manage similar types of applications easily and consistently for the desired outcome.
Versa identifies more than 3,000 applications and it can be challenging for the user to
define policies for each one of them.
Starting from 20.1.0, Application Service Templates can use pre-defined Application
Groups or Application Filters to achieve the desired outcome for well-known
applications that belong to the same class of apps, or risk profiles, or by similar
behaviors. Such groupings will simplify the definition of policies for groups of
applications rather than individual ones and manage these apps in a consistent way.
Pre-defined Application Groups are selections of App-IDs. App Groups are selections of
Apps that are grouped together by type, source (for example, vendor). While Versa
introduces pre-defined Application Groups in this release, Versa supported user-defined
/custom Application Groups for quite some time.
Let us look at an example of pre-defined App Group:
• Pre-defined Application Group: Office365 Apps
• Predefined App List for Office365 Application Group: OFFICE365, OUTLOOK,
ONEDRIVE, WORD_ONLINE, EXCEL_ONLINE, POWERPOINT_ONLINE,
SHAREPOINT, SHAREPOINT_ADMIN, SHAREPOINT_BLOG,
SHAREPOINT_CALENDAR, SHAREPOINT_DOCUMENT, SHAREPOINT_ONLINE,
SHAREPOINT, MS_ONENOTE, ONEDRIVE, MS_PLANNER, YAMMER
Pre-defined Application Filters are similar to groups but they are an alternative mapping
based on actual tags defined by Versa engineers. These tags characterize each of these
applications by type of traffic, risk profile, and general attributes of that application.

Copyright Versa Networks, Inc. All rights reserved

 8

These tags are assigned based on the research of Versa engineers and these tags have
attributes, such as risk profiles.
Such attributes like risk, productivity nature of the app, and other attribute values can
change over time and Versa engineers keep these attribute values updated. Versa
provides the updated tags with security updates, so that you can use these pre-defined
tags in up to date forms. Note that Versa does not allow defining custom Application
Filters.
Let us look at an example of pre-defined Application Filter:
• App-Filter: SaaS-Applications
• Example app that is part of this App Filter: OFFICE365
• QoS Mapping: Business Critical traffic class by default.
In the above examples, use of pre-defined Application Service Template with
Application Group of Office365 Apps or use of App Filter SaaS-Application makes it very
easy to apply appropriate policies (QoS profiles, path selection choices, decisions like
application of Advanced SD-WAN features like FEC, application of security profiles) to
manage each class of these applications.
With 20.1.0, Versa provides over 15 Application Filters and over 20 pre-defined
Application Groups. In addition to these, one can come up with user-defined/custom
App Groups.

LTE Focused Dynamic Probing Optimizations

One of the key functionalities of SD-WAN is the ability to provide SLA-bound application
experience. In order to achieve the SLA defined for the applications, dynamic probes are
used over all the available paths to estimate the performance for each application. This
is inefficient for the relatively expensive access technology likeLTE which has limited
volume of data.
Starting for 20.1.0 release, the dynamic probing over LTE access are optimized. When
LTE is defined as a stand-by, the access is enabled only when the primary links are
detected to be in-operable.

Copyright Versa Networks, Inc. All rights reserved

 9

Intel QAT Support

Versa FlexVNF software runs in Baremetal on Intel x86 architecture. Intel provides
QuickAssist Technology (Intel® QAT) to offload encryption and decryption, as well as
compression and decompression tasks onto specialized hardware blocks within select
CPUs or onto dedicated chips (ColetoCreek chips). Such hardware offload capabilities
accelerate these tasks and free up valuable CPU resources for other tasks that cannot be
offloaded to hardware.
You can find more information on Intel’s Quick Assist Technology here:
https://www.intel.com/content/www/us/en/architecture-and-technology/intel-quick-
assist-technology-overview.html
Starting from 20.1.0 release, Versa FlexVNF supports QAT on the following platforms:
• Rangeley (as used within V1xx platforms), Denverton (as used within V2xx
platforms), and Skylake-D (as used within V9xx platforms) based platforms via
built-in QAT block within the CPU. These platforms do not need an external
chipset to support QAT.
• Xeon and select Xeon-D based platforms via optional ColetoCreek cards (an
option for V8xx and V1xxx platforms).
As you upgrade to 20.1.0, you will not have to do any changes in your configuration and
software is built with intelligence to recognize these specific hardware parts and use
appropriate hardware offload capabilities in a seamless fashion.
As a result, you will see performance increase on these platforms that support QAT. For
details on QAT performance numbers, please refer to QAT performance testing results.

Multicast
Prior to 20.1.0, these features were available on a special multicast branch and got
deployed by select production networks. Starting from 20.1.0, Versa provides a rich set
of multicast routing protocols in generally available deployable form to our overall
customer base.
Multicast is typically used by online streaming video and gaming, financial, or
broadcasting applications that distribute information from one-to-many or from many-
to-many. Different multicast networking protocols were developed over timeto allow
more efficient use of network resources when supporting these types of applications.
Versa supports these multicast protocols in 20.1.0 release:
• IGMP v2/v3

Copyright Versa Networks, Inc. All rights reserved

 10

• PIM SM w/neighbor on LAN & WAN interfaces, Rendezvous-Point, Bootstrap RP

• PIM SSM
Internet Group Management Protocol (IGMP) is used by hosts and adjacent routers on
IPv4 networks to establish multicast group memberships. IGMP operates between a
host and a local multicast router. A host requests membership to a group through its
local router while a router listens for these requests and periodically sends out
subscription queries. A single router per subnet is elected to perform this querying
function.
IGMPv2 is used very commonly in IPv4 network today, while IGMPv3 enhances this
protocol further by providing source specific multicast support, as well as IPv6 support
by defining the protocol MLD. Source specific multicast allows a transmission from a
particular sender to a particular group and there are some applications that require this.
Versa IGMP implementation is fully compliant with IGMPv2 (as defined by RFC2236) and
with IGMP v3 (as defined with RFC4604). For details on these, please refer to:
https://tools.ietf.org/html/rfc2236
https://tools.ietf.org/html/rfc4604
Protocol-Independent Multicast (PIM) is a family of multicast routing protocols for IP
networks that provide one-to-many and many-to-many distribution of data over LAN,
WAN or (in the case of Versa) SD-WAN overlay networks. It is termed protocol-
independent because PIM does not include its’ own topology discovery mechanism, but
instead uses routing information supplied by other routing protocols. PIM is not
dependent on a specific unicast routing protocolIt can make use of any unicast routing
protocol in use on the network. PIM does not build its own routing tables. PIM uses the
unicast routing table for reverse path forwarding.
In a multicast networks while IGMP is used between the host and the routers located on
a LAN, Protocol Independent Multicast (PIM) is used between the local and remote
multicast routers, to direct multicast traffic from hosts sending multicasts to hosts that
have registered through IGMP to receive them.
PIM provides several different modes and among those, Versa supports PIM SM and
PIM SSM in 20.1.0.
PIM Sparse Mode (PIM-SM) explicitly builds unidirectional shared trees rooted at a
rendezvous point (RP) per group, and optionally creates shortest-path trees per source.
PIM-SM generally scales fairly well for wide-area usage. PIM SM is suitable for groups
where a very low percentage of the nodes (and their routers) will subscribe to the

Copyright Versa Networks, Inc. All rights reserved

 11

multicast session, based on explicit interest (this is the opposite of PIM Dense Mode
assumptions).
PIM-SM explicitly constructs a tree from each sender to the receivers in the multicast
group. PIM SM allows multiple multicast sources (any source multicast) which allows
multiple sources to originate traffic for a multicast group such that a source can be a
listener as well. The latter scenario will require PIM SM to create associate
unidirectional trees accordingly as well. High scale of PIM SM deployments with many
groups, sources, and listeners can get complex over time.
PIM SM uses Rendezvous Point (RP) to simplify this any to any data forwarding problem.
Multicast distribution trees are rooted at the selected node called the Rendezvous Point
(RP) and used by all sources sending to the multicast group. To send to the RP, sources
must encapsulate data in PIM control messages and send it by unicast to the RP. This is
done by the source's Designated Router (DR), which is a router on the source's local
network. Discovering the address of RP for a given multicast group is critical for PIM SM.
PIM SM uses several techniques for this and among those, Bootstrap RP is supported by
Versa FlexVNF in 20.1.0.
For more information on PIM SM, please see RFC4601 here:
https://tools.ietf.org/html/rfc4601
As noted above, Versa’s PIM SM implementation covers RP (Rendezvous Point) and
Bootstrap RP functions in 20.1.0.
PIM Source-Specific Multicast (PIM-SSM) builds trees that are rooted in just one source,
offering a more secure and scalable model for a limited number of applications (mostly
broadcasting of content). In SSM, an IP datagram is transmitted by a source (S) to an
SSM destination address (G), and receivers can receive this datagram by subscribing to
channel (S,G). For more information, please see RFC3569, here:
https://tools.ietf.org/html/rfc3569
PIM SSM is perceived simpler compared to PIM SM. There is no need for shared trees or
RP mapping (no RP is required), or for RP-to-RP source discovery through MSDP. By
ignoring the many-to-many model and focusing attention on the one-to-many source-
specific multicast (SSM) model, highly scalable multicast deployments can be achieved
for applications that have one source and many listeners. An example of such an
application is television channel distribution or stock market information distribution
over the Internet or over SD-WAN network. In such examples, by using PIM-SSM, one
can broadcast information to listeners much more quickly and efficiently by selecting
which sources to listen to and by only managing the data traffic in one way.

Copyright Versa Networks, Inc. All rights reserved

 12

PIM SSM is also used by initial incarnation of VXLAN overlay tunnels within the
virtualized DC environments.
As it can be seen through the protocol overview and implementation scope overview
shared above, Versa provides a very rich set of multicast capabilities to our customer
base on local LAN and WAN interfaces as well as over SD-WAN overlay networks.
In Versa SD-WAN deployments with multicast, it is recommended to choose PIM-SSM if
application allows. In the case of PIM SM, it is recommended to choose Rendezvous
Point deployments either at the Hub-FlexVNF or some other PIM router behind a hub.
While Versa FlexVNF can generate quite a large volume of multicast packets in the RP
role, if large volumes of traffic replication are required, Versa recommends leveraging
an ASIC based router or Ethernet switch to act as the RP. Alternatively, a hierarchy of
hubs can be used to reduce the packet replication load on a single RP.
Versa’s multicast support has additional means to control the traffic. Versa provides
policy based traffic control for multicast traffic and allows customers to choose
transport networks according to their policies. Multicast WAN topology can be spread
over Broadband, MPLS-VPN links, and/or SD-WAN overlay paths based on given
destination(s), which administrator can fully control.

BGP Route Aggregation

Route aggregation is a method that helps minimize the number of routing tables in an IP
network by consolidating selected routes into a single route advertisement. The
aggregation methodology does not help reduce the size of the routing-table on the
router that does the aggregation. When you configure an export policy that only
advertises the aggregate but not the contributing routes anymore, you have the
aggregation effect on the routers that receive updates. Advertiser of the aggregate
route will not use this aggregated route.
In order for an aggregate route to be advertised, at least one contributing route (more
specific route) must be active. If that route becomes unavailable, the aggregate route
advertisement is withdrawn. This inherent feature of route aggregation also helps
stabilize route churns in a network by containing all of the route changes to the
aggregating router.
BGP has implemented a rich set of route aggregation techniques and Versa’s BGP route
aggregation implementation is at par with established route aggregation
implementations in the market.

Copyright Versa Networks, Inc. All rights reserved

 13

An aggregate BGP route can carry an AS Path attribute that lists the set of autonomous
systems (AS) that this route was originated and advertised from. In the case of BGP
route aggregation, as the actual sequence of these AS instance is no longer relevant, AS-
Sequence cannot be used and only AS-Path attribute gets used.
AS-Path attribute populated as AS-Set type and it consists of union of all of the AS-Path
values participating routes that have been learned from. It is a common practice to
overwrite those AS-Path values by using a route policy to set it as the local AS.
In addition, aggregating router also provider aggregator attribute to provider the router
id of the device that does route aggregation.
Versa also supports Atomic Aggregate Attribute such that if one still needs to advertise
more specific route(s) in addition to the aggregate route, it can be done.
While this feature may be used for a variety of routing use-cases, this feature may be
commonly used by our customers to summarize SD-WAN network and branch networks
behind SD-WAN network, over to legacy network or to core network devices for the
purpose of providing a single route to these devices. Such a choice can help operators of
these brownfield networks to talk to branches by using appropriate SD-WAN Gateway
nodes.

RIPv2
Versa FlexVNF provides Routing Information Protocol Version 2 to increase its’ interop
options with legacy network equipment.
Versa’s RIPv2 implementation complies with RFC2543.
In a nutshell, RIPv2 distributes routing prefix information through participating routers
to provide reachability to those network prefixes or subnets. RIPv2 (as well as RIPv1), is
a distance vector based routing protocols that uses router hop counts as its’ distance
calculation metrics. RIPv2 supports a maximum hop count value of 15. Any router
farther than 15 hops away is considered to be unreachable.
RIPv2 supports subnets and CIDR (Classless Interdomain Routing), which were some of
the main shortcomings of RIPv1.
You can find more information on RIPv2, here:
https://tools.ietf.org/html/rfc2453

Copyright Versa Networks, Inc. All rights reserved

 14

Device Finger-Printing and Logging

Device identification and fingerprinting have become a critical piece of monitoring
networks, analysis, and mitigation of imminent security threats associated with specific
devices.
Device identification and fingerprinting brings more visibility to the network and
security operations. Device identification itself is not a single mechanism or protocol but
comprises of a few well known mechanisms or techniques used by many vendors. Some
of the mechanisms include leveraging the functionality of OS finger printing, OUI
database, parsing HTTP User Agent headers, and more.
Versa supports the following methods to fingerprint a device and to logs its’ associated
activities:
• HTTP User Agent Header: HTTP User Agent header is typically generated by all
kinds of browsers and useful information can be derived from this header. The
header includes Browser (Safari, Chrome, Firefox, etc.), Browser version (53.0,
11.0, 64.1, etc.), OS (MAC OS, Android, Windows, etc.), OS version (10.12, 7.1,
11.2.5 etc.), platform (Desktop, Tablet, Phone, etc.), vendor (Apple, Google,
Motorola, etc.) information among other things.
• MAC address based analysis: First three bytes of the MAC address is assigned for
Organizationally Unique ID by IEEE. An OUI is a 24-bit number that uniquely
identifies a vendor, manufacturer, or other organization. In addition to the
vendor type, Versa software also captures the MAC address of the device. Note
that MAC based logging and identification works if the device is in the same L2
domain as the Versa FlexVNF.
• OS Finger Printing: A set of techniques that involve deep analysis of protocol
stacks that device uses to communicate with the outside world, This particular
method will be supported after the initial release of 20.1.10.
Fingerprinted device and its’ associated information can be logged to Versa Analytics.
Such device logs’ include device’s MAC address, IP Address, device type, browser
information, and information obtained from other network headers. This information
can then be stored and analyzed at a base level by Versa Analytics. If desired, this
information can be forwarded to third party systems for deeper analysis.
Subsequent to 20.1.0, Versa will provide ability to categorize and control the access
through the application of security policies to enforce security measures. The
categorization and policy application enables the operator to isolate certain types of
vulnerable devices from becoming the means for security threats.

Copyright Versa Networks, Inc. All rights reserved

 15

File Filtering
File Filtering is an important tool for data loss prevention as well as protection from a
wide variety of Malwares in the network. Versa SD-Security file filtering feature helps
reduce the risk of attacks from unwanted and malicious file types. It provides file
protection against virus and vulnerabilities that are associated with various file types
and blocks potentially risky file transfers, applications (file types), file with specific size,
files with specific protocols, and traffic direction. This decreases an attacker’s ability to
conduct an attack on your organization.
The file filtering functionality detects the file type from scanning the first few packets of
the file (and not only based on the extension type). Versa supports these protocols to
extract the file in transfer: HTTP, SMTP, FTP, IMAP, MAPI, etc.
Once the file type is understood and the signature of the file is extracted, the filter
filtering functionality looks for a match of the file against a blacklist database, whitelist
database, and reputation database in order to identify malicious files. Through the file
reputation feeds, Versa can carry signatures of very large number of files, known to
distribute malicious content. Additional criterion, such as file size, file type, etc are used
to make policy decisions.
The file filtering functionality works in conjunction with the Anti-Virus feature to ensure
that the files are not infected. If it is used in combination with AV, it reduces the work
on AV by providing a pre-scanned file to the AV engine. The AV engine will only scan for
files that are not in whitelist or blacklists.
Also note that soon after the 20.1.0 release, Versa will provide support for
decompression functionality, allowing FlexVNF to decompress and analyze files that are
compressed by well-known algorithms.

Lateral Movement Detection and Prevention

When a Malware’s is targeting a particular organization or enterprise, the attacker is
after a prize which is not accessible from the outside the network. ‘Lateral Movement’ is
an attack mechanism which is used to use a low value host as the base by the attacker
to widen the attack to ultimately reach the prized host. The methods employed by the
attacker to identify resources on the internal network, gather information or credentials
from an infiltrated host, and use the gathered information to gain control of other
resource on the internal network, are called “Lateral Movement Techniques”.

Copyright Versa Networks, Inc. All rights reserved

 16

As Windows is the most widely used OS in any enterprise network, the mechanisms
used for lateral movement are usually based on Windows networking protocols.
However, similar techniques are applicable for any operating system.
A malware which uses lateral movement techniques typically follows these steps to gain
access to the network:
1. Infiltrate: The attacker gains access to one of the low value targets in the
organization by using Spear Phishing, Drive by Download, etc.
2. Reconnaissance: The Malware snoops the network to identify the topology,
hosts, etc.
3. Credential Harvesting: The infected machine snoops on the cached credentials.
4. Code Execution: Using the information gained from Reconnaissance state and
Credential Harvesting state, the attacker now obtains further authorization by
using Kerberos or other protocols.
Versa’s SD-Security solution is enhanced to identify the exploit and alert the
administrators. Versa’s IPS and AV signatures are enhanced against such threats. The AV
engine detects the binaries used in such exploits. The IPS tool inspects the network
traffic to identify the activities typical to ransomware and malware as well as activities
seen by commonly mis-used tools, such as Responder. Starting 20.1 release, Versa
FlexVNF has support to detect advanced lateral movement techniques in a Windows
environment irrespective of the Malware sample or threat actor. The security engine
will be able to detect network activity that’s indicative of psexec, pass-the-hash,
credential harvesting attacks, attacks on active directory and more.

uCPE Cloudinit Support

Versa’s Universal CPE functionality is used by the customers to host third party Virtual
Network Functions hosted over the virtual infrastructure provided by Versa FlexVNF.
Third party VNFs provide network services in conjunction with FlexVNF services. Service
chaining allows the IP flows to be processed by FlexVNF services as well as third party
VNFs.
Versa’s Universal CPE allows simplified branch network by hosting services provided by
multiple vendors over a single hardware. Additionally, the Versa Director provides a
single pane of glass management by providing VM lifecyle management for the third
party VNFs.
In the virtual deployment, Cloudinit capability of Versa uCPE solution provides the VM
Lifecycle Manager with an automated mechanism to insert parameters to the VM while

Copyright Versa Networks, Inc. All rights reserved

 17

booting. Cloudinit is typically used to configure the IP address and other service
parameters for efficient automation of the VM instantiation.
From 20.1.0 onwards, the Cloudinit parameters can be uploaded as a file to the service
chain configuration. The Cloud Init parameters can also be parameterized. When the
Cloud Init data is parameterized, the VM specific information can be uploaded during
the VM configuration.

Provisioning and ZTP Workflow Support for Routing and Security

Use-Cases
In SD-WAN topology, the controller is introduced in the architecture to provide 3
specific functionalities:
- Enable authentication of the branch devices irrespective of whether the branch
has static IP address, dynamic IP address, or private IP address.
- Enable secure channel for control plane signaling, including Netconf and IPFix
communication.
- Enable MP-BGP route reflector functionality to exchange the LAN reachability
information.
The controller functionality enables Zero Touch Provisioning for the devices irrespective
of the access link.
Zero Touch Provisioning for device onboarding and branch deployment reduces the lead
time of branch deployment and reduces the operational expense incurred. Thus, ZTP is a
valuable feature for a customer irrespective of SD-WAN or non-SD-WAN deployment
model.
From 20.1.0 onwards, customers can make use of the controller when deploying CPEs in
non-SDWAN use cases. For example, a router or SD-Security (acting as a FW or a UTM
device) device deployment can benefit from ZTP by using the controller in the
architecture. The controller allows the branch to authenticate with the network,
perform Zero Touch Provisioning by downloading the configuration automatically, and
provide secure connectivity to branch from Versa Director/Analytics.

Hierarchy of templates (Ordered List Support)

Versa Director provides an innovative single pane of glass management portal with
templates and workflows, allowing automation of device provisioning, deployment, and
management. Based on the feedback and usage patterns, release 16.1R2 had
introduced service templates. While service templates were defined independently, the

Copyright Versa Networks, Inc. All rights reserved

 18

templates could be created and yet reused for service configuration (for branches with
different connectivity options but similar service configuration).
From 20.1.0 onwards, the service templates can now be associated with Device Groups.
Device Groups is a concept which groups the devices which use similar templates (which
means belong to the same tenant organization. When Service Templates were
associated with General Templates, there could have been only 1:1:1 relationship
between the service configuration, templates and device groups.
With Service templates now associated with Device Groups, the SP can create 1:1:Many
relationship. Using the General Templates, Device Groups and Service Templates, the
customers can incorporate various ‘modules’ as and when required.

Versa Analytics Fusion

Versa introduces the next generation of Versa Analytics product that is based on open
source database and with higher performance, scalability, and capabilities.
Versa Analytics Fusion matches the Versa Analytics in features today and it provides the
following advantages, additionally:
- Fast database backup and restore capabilities. Great for data replication between data
centers.
- Topology view of search clusters.
- Better scalability of the database.
Versa expects the average performance to increase by around 40% compared to
previous versions, while the same hardware and network scale is used.
In its initial release, Versa Analytics Fusion will be supported only on new deployments.
Over time, Versa will develop data migration tools to move the data from existing Versa
Analytics over to the new Versa Analytics Fusion flavor.

Netflow-Based Flow Export

Netflow is a popular log collector protocol, deployed in many networks. There are
number of third party analytics applications available that consume the logs in the
Netflow format. However, traditionally, Versa has preferred IPFix format with vendor
specific extension to provide rich and SD-WAN specific logs, including tenant
information, application detection information, etc.
From 20.1.0 onwards, third party Netflow collectors can be integrated with Versa
FlexVNF to consume the Netflow logs directly. The FlexVNF implementation is enhanced

Copyright Versa Networks, Inc. All rights reserved

 19

with option to configure traffic monitoring rules and send Netflow-based IETF defined
fields.

Copyright Versa Networks, Inc. All rights reserved