Deploying FactoryTalk® Software with IPsec

(Internet Protocol Security)

This document p rovides a high-level overview of IPsec and an

example of how IPsec can be used with FactoryTalk® View SE,
FactoryTalk® ViewPoint, and FactoryTalk® AssetCentre in a
distributed network environment.
This document is available from the Rockwell Knowledgebase,
Document ID QA46277 (Legacy AID 1090456).

Copyright ©2019 Rockwell Automation, Inc.

Page | 2
Table of contents

Contents
What is IPsec?...................................................................................................................... 4
How IPsec works .................................................................................................................. 5
IPsec modes ......................................................................................................................... 7
IPsec vs. SSL/TLS (HTTPS) .................................................................................................... 8
IPsec and CIP........................................................................................................................ 9
IPsec configuration .............................................................................................................. 9
Test system architectures and IPsec configuration .......................................................... 11
7.1 FactoryTalk View SE ....................................................................................................... 11
7.1.1 Testing the configuration ............................................................................................... 19
7.2 FactoryTalk ViewPoint .................................................................................................... 21
7.2.1 Testing the configuration ........................................................................................... 30
7.3 FactoryTalk AssetCentre................................................................................................. 32
7.3.1 Testing the configuration ........................................................................................... 36
7.3.2 Optional configuration for large distributed FactoryTalk AssetCentre systems ........ 38
Results ............................................................................................................................... 39
8.1 FactoryTalk View SE results ............................................................................................ 39
8.2 FactoryTalk ViewPoint results ........................................................................................ 40
8.3 FactoryTalk AssetCentre results ..................................................................................... 40
Summary............................................................................................................................ 41

Page | 3
What is IPsec?
Internet Protocol Security (IPsec) is a collection of security protocols, built-in to Microsoft®
Windows™, designed to provide security services for IP network traffic. The main functions
of these services are Authentication, Data integrity, Data confidentiality and Anti-replay
protection.

Authentication involves an exchange of credentials between computers

participating in a secure connection to ensure that each of the computers receives
proof that a network packet is originating from an authentic source. Typically, the
authentication is done through Kerberos (using tokens that are verified against a
domain controller) or by using computer or user certificates that are verified against
a trusted root certificate.
Data integrity means an assurance that a packet sent is identical to the packet
received. This is achieved by using a cryptographic hash of the packet. The source
computer creates (calculates) and encrypts the hash and includes it in the packet.
The receiving computer creates its own hash and, through decryption method,
extracts the hash included in the packet. If the two hash value match, the packet
integrity is intact and can be accepted.
Data confidentiality means that the data included in a network packet is protected
and cannot be maliciously accessed by unauthorized computers or users. This is
achieved by encrypting the data using one of many different IPsec encryption
protocols.
Anti-replay protection ensures that a network packet cannot be intercepted and a
new and modified packet injected during transmission stream from source to
destination. This is achieved by a special packet sequence mechanism that compares
added packet sequence number at the source with the packet sequence number
maintained by a sequence counter at the destination. The arriving packets whose
sequence numbers do not meet sequence counter criteria at the destination are
considered either old or replayed and are being rejected.

Each of the protocols included in the IPsec is built around providing the above listed
functionalities. The most important IPsec protocols are:
• The Authentication Header (AH) - defines an optional packet header as a
protection against malicious modifications and replays of traffic by performing a
data origin authentication for IP packets.
• The Encapsulating Security Payload (ESP) header – defines an optional packet
header as a protection against malicious modifications by performing a data origin
authentication and a data confidentiality through encryption of the IP packets. It
can also provide protection against replays of traffic.

Page | 4
 • Internet Key Exchange (IKE) protocol – used while establishing a secure connection
based on the defined security agreements, also called Security Associations (SA).
The protocol defines the cryptographic algorithms and a mechanism to share the
exchange keys that are needed by hosts to interpret and work with the algorithms.
o Part of the IKE protocol is Internet Security Association and Key
Management Protocol (ISAKMP). It manages the SAs and the connections
between two hosts that are using IPsec. SA describes a one-directional
connection between hosts which means that a pair of hosts would need
two SAs, one for each host. The SA include various information about
secure communication parameters, policies and mechanisms used to
establish an IPsec communication - cryptographic algorithm, encryption
key, IPsec connection mode, etc.
• Authenticated Internet Protocol (AuthIP) - one of the newer key exchange
protocols that leverages on IKE and expands and improves its capabilities. For the
purpose of this writing we will not cover it in details. It is mentioned here for
awareness only.

How IPsec works

Establishing an IPsec communication is a fairly complex process involving a number of
protocol negotiating and encryption methods. For easier understanding, it can be divided
into four steps:
1. The initial step in establishing IPsec communication is packet recognition. What
this means is that once an IP packet transmission is requested, a host needs to
determine whether the packet should be sent using IPsec. Typically, this is done
by checking the source and the destination IP addresses against the configured
IPsec policies. If the match is found, the security policy for the packet is initiated.
This in turn causes the sending party to encrypt or authenticate the packet (or
both, depending on the policy configuration). On the receiving side, the packet is
also recognized as a subject to IPsec-protected traffic and the verification of the
encryption/authentication is performed.
2. Next, using the Internet Key Exchange (IKE) protocol, a secure communication
between two hosts is established in two-phases:
I. In the first phase, an initial secure channel is being established. This
channel is used for policy negotiation, a process in which the hosts using
IPsec must agree upon a number of security parameters such as:
encryption and integrity algorithms, cryptographic keys and
authentication method. This phase is performed in one of two modes:

Page | 5
 ▪ Main mode – the initiating host starts the negotiation process by
sending offers for a potential security session. The offer proposes
all the required security parameters and can be sent repeatedly
until the receiving host agrees on the proposal. Note that the offer
cannot be modified by a responder – it can either accept it or send
back alternatives which are then negotiated further. As a result of
successful negotiation, an IKE Security Association (IKE SA) is
created and a secure channel is established for further negotiation
(described in phase 3 below).

The Main mode provides a great security because all the

negotiations occur over a secure channel created before
information exchange.
▪ Aggressive mode – the initiating host specifies IKE SA one-sidedly by
including almost all the security parameters in this single offer. The
responder completes the exchange by authenticating the session.
The Aggressive mode is quicker than the Main mode due to much
less exchanges being completed between the hosts. However, this
mode is also less secure because some of the key IPsec session
information is being exchanged before establishing a secure
channel.
II. In the second IKE phase, negotiation of the IPsec SAs takes place. The SA
parameters such as the type of cryptographic algorithms and the secret
keys to be used with these algorithms are being negotiated over the secure
channel protected by the IKE SA (created in phase I). This process occurred
in a so-called quick mode which is the mode enabled by successful
completion of phase I. In this mode, random numbers called nonces
(“number used once”) are also being exchanged to generate secret keys
used for authentication and anti-replay protection, as described earlier.
Upon completion of phase II, the SAs are established at each negotiating host.

Note: An IPsec SA is unidirectional meaning that each host has two SAs – one SA
to send and one SA to receive packets from a remote host. However, the IPsec
Monitor tool only displays a single SA for both hosts, as we will see in the
snapshots later in the document.
3. In this step the IPsec tunnel is established and the data is being exchanged.
Encryption and decryption of data packets occurs on both endpoints according to
the encryption negotiated and specified in the IPsec SAs (phase 2.II).

Page | 6
 4. In the final step, the Tunnel termination occurs, either through explicit deletion or
by timing out. Timeout can be time –based, i.e. an SA times out after a specified
time, or based on a volume of data (specified in bytes) that has been exchanged
through the tunnel. Upon terminating the tunnel, the SAs and all the associated
keying material associated with the session is discarded. Depending on the IKE
settings, the subsequent IPsec sessions can be created starting from either phase
I or phase II of the second step.

IPsec modes
IPsec-protected communication can be set up in two modes: Tunnel mode and Transport
mode.

Tunnel mode is typically used when two private networks (e.g. intranets) are
separated by a public network (Internet). To protect the public portion of the
network and treat the two intranets as one logical protected network, each intranet
has a gateway that utilizes IPsec and acts as an IPsec tunnel endpoint. This way the
traffic between computers on both sides of the public network will be relayed
through a secure tunnel.

Another example of the Tunnel mode is VPN (Virtual Private network) - a scenario
where a client computer, connected to a public network, is securely connected to a
remote trusted network. In a VPN environment, a trusted remote network gateway
creates an IPsec tunnel that is utilized by the client. Unlike in the previous example
where a gateway endpoint and a participating network computer endpoint are not
the same, in the VPN scenario the client’s IP address is both the client endpoint and
one of the tunnel’s endpoints.

Transport mode describes a one-to-one scenario where one host interacts directly
with another host. The traffic originating host initiates an IPsec communication
which is then negotiated between the hosts. Upon successful negotiation, a secure
end-to-end IPsec channel is established. The IPsec security policy in transport mode
requires only two IP addresses, one from each participating host.

The product testing scenarios, described later in this document, are using the Transport
mode.

Page | 7
IPsec vs. SSL/TLS (HTTPS)
In addition to IPsec, a network traffic generated by the FactoryTalk View products and their
components can be protected by SSL/TLS. For example, both FactoryTalk View SE and
FactoryTalk ViewPoint support communication over HTTPS, a protocol established by means
of certificates for use with SSL/TLS. So, the next logical question would be: if both IPsec and
SSL/TLS protocols are supported by FactoryTalk View, what is the difference between them
and which one should I use?
(Note that a deep-dive into technical details of each of these protocols is beyond the scope
of this document. We will just briefly identify the main technical differences between them.)

Both the IPsec and the SSL/TLS are cryptographic protocols. This means that they operate
on top of a concrete network protocol and provide the security-related services by use of
cryptographic methods such as data confidentiality, data integrity, authentication, data
encryption etc.

IPsec is implemented at the Network layer (layer 3 of the OSI model) and is an abstraction
of the IP protocol. It protects all traffic between the hosts but since it operates at the very
low OSI layer, it does not provide granularity that is often necessary to achieve specific user-
based and/or application-based security.

In contrast, HTTPS is implemented at the Application layer (layer 7 of the OSI model) and is
an abstraction of the HTTP protocol through use of SSL and /or TLS protocols (that belong to
Presentation layer, layer 6 of the OSI model). As such, HTTPS is designed towards securing
web-based traffic associated with a specific application and allows more flexibility when it
comes to meeting custom security requirements.

From the implementation point of view, depending on the network complexity, IPsec can be
much more challenging to configure than HTTPS. It requires careful planning and complex
policy configurations. Also, administration and maintenance requires skills and proficiency
which are not as demanding with HTTPS implementation.

With the above in mind, deciding which method to use may not be straightforward. The
unpopular but the true answer is: it depends. For example, if securing the FactoryTalk
ViewPoint traffic or the web-based project components of FactoryTalk View SE (graphic
displays, macros, parameter files, etc.), HTTPS could be an obvious choice. However, if the
objective is to secure the entire traffic of a FactoryTalk View distributed application,
especially in situations where the application’s servers and clients span across unprotected
segments of the network (and/or the flexibility for configuring security at the
application/user level is not of utmost importance), IPsec could be a method of choice.

Page | 8
IPsec and CIP
As mentioned in the previous section, IPsec is supported at the Network layer of the OSI
model (layer 3) or the top of the media layer of traffic meaning that securing the packets
prior to transport is the objective. Today, automation hardware that communicate via CIP
(Common Industrial Protocol) do not support IPsec in the media layers. The standard that
Rockwell Automation is implementing is ODVA CIP Security™
(https://www.odva.org/Technology-Standards/Common-Industrial-Protocol-CIP/CIP-
Security).

CIP Security specification is defined in Volume 8 of the Ethernet/IP ODVA specification

document. Rockwell Automation implementation of CIP Security is delivered with the
FactoryTalk Policy Manager tool. More information on both CIP Security and FactoryTalk
Policy Manager can be found in the following documents:
https://literature.rockwellautomation.com/idc/groups/literature/documents/at/secure-
at001_-en-p.pdf &
https://literature.rockwellautomation.com/idc/groups/literature/documents/rm/secure-
rm001_-en-p.pdf

IPsec configuration
There are number of ways and tools available for configuring IPsec communication. In this
document, we will not discuss all these different methods nor the details of the configuration
steps that need to be taken. For this and various other information, please refer to a rich
collection of technical documentation available on this subject on the web. Our objective is
to provide a general IPsec configuration guidance based on the method that we used in our
own tests.

The IPsec configuration procedure can be broken down into the following phases:

Page | 9
 1. Using Windows Group Policy Management Tools to configure one or more unique
Organizational Units (OU) (e.g. FactoryTalk View SE clients can represent one OU,
FactoryTalk Linx data servers can represent the other OU, etc.).
2. Using Active Directory Management Tools to add the participating computers to the
corresponding Organizational Units.
3. Using Group Policy Management Editor to configure the Group Policy for each OU:
a. Create IP Security Policy
b. Build IP Security Rules (for communicating with other computers):
i. For each Rule build an IP Filter List (the list represents collection of
filters that specify the source and the destination IP addresses and
define the communication protocol, ports, etc., between them).
ii. Configure the rest of the Rule properties such as: Authentication
Methods, Tunnel Settings, Connection Type
c. Configure Integrity and encryption Properties
These configuration phases will be much easier to understand and follow in the next section
that illustrates how each of these phases have been performed in our test systems.

Page | 10
Test system architectures and IPsec configuration
7.1 FactoryTalk View SE
Figure 1 below illustrates a simple redundant HMI server system architecture used for
IPsec testing.

Figure 1

The system clearly resembles an IPsec communication in Transport mode, as

described in section 3. This means that participating computers interact directly with
each other in one-to-one fashion, as indicated with the blue arrows.

As described in a previous section, the first step was to use Group Policy Management
Tools to configure Organizational Units. For this testing scenario we configured only
one OU called ServerClient (Fig. 2)

Page | 11
 Figure 2

The following computers have been added to the ServerClient OU:

Role IP address
FTD and SE Primary HMI Server 10.224.106.135
Secondary HMI Server 10.224.105.77
FactoryTalk Linx data server 10.224.105.85
SE Studio 10.224.105.43
SE Client 10.224.105.41
Table 1

Next, per the phase 3a from the previous section, we configured IP Security Policy for
the ServerClient OU:

Page | 12
 Figure 3

Per the phase 3b, we created two IP Security rules: FromOthersToMe and
FromMeToOthers.

Figure 4

Page | 13
The next step in the process (3b.i) was to create an IP Filter List for each of the IP
Security rules. The first rule we chose was FromOthersToMe:

Figure 5

Remember that IP Filter List must define the source and the destination IP addresses
as well as the communication protocol, the ports, etc. of all the computers to which
the IP Security rule will apply. The Figure 6 depicts the completed IP Filter List for the
FromOthersToMe rule.

Page | 14
 Figure 6

Similarly, per Figure 7 below, the next step was to select the FromMeToOthers rule
and create the IP Filter List for this rule too:

Figure 7

The rest of the Rule Properties were configured per Figures 8, 9 and 10 by accessing
their respective tabs:

Page | 15
 Figure 8

Note: There are numerous authentication methods supported by IPsec and Microsoft.
However, we recommend Kerberos as a preferred method of choice.

Figure 9

Page | 16
 Figure 10

Note how in Fig. 10 we selected “This rule does not specify an IPsec tunnel”. This
setting means that the IPsec communication will be performed in the Transport mode
and that the rule applies to all network traffic.
Tunnel strategies such as VPN are also supported but require different configuration
and additional consideration that are beyond the scope of this document (please refer
to the applicable Microsoft documentation).

Finally, for both FromOthersToMe and FromMeToOthers rules we configured the

Integrity and encryption Properties and the Security Method (Fig. 11 and 12).

Page | 17
 Figure 11

Figure 12

Note that the type of Security Method chosen in the above step may impact
performance of the applications being secured. For example, both integrity checks
and especially encryption, where traffic leveraging pre-defined cryptography must be
encrypted at the source and then decrypted at the destination, require time to
complete. However, it is difficult to predict how big the performance impact would

Page | 18
 be. It depends on the application, volume of the network traffic, network speed,
configuration and topology, etc.

7.1.1 Testing the configuration

To verify that the IPsec communication was properly established, we used network
analyzer tool. Fig. 14 illustrates an example of the network traffic between the
FactoryTalk Studio (IP 10.224.105.43) and the Primary HMI server / FactoryTalk
Directory (IP 10.224.105.135) computers.

Figure 13

As seen in the above figure, the communication protocol between the two hosts is
ESP (Encapsulating Security Payload). Per earlier discussion (Section 1) ESP is a part of
the IPsec protocol suite that provides confidentiality, data origin authentication,
connectionless integrity, and anti-replay service. These are the core services that
define IPsec.

One of the IPsec utilities that is available is IP Security Monitor. It is used to monitor
several IP security status information categories. One of them is the Security
Associations between the source computer (running the Monitor) and the computers
it communicates with over the IPsec. Below are the security association captured by
the tool on the FactoryTalk View Studio machine:

Page | 19
 Figure 14

From Fig. 14, we can see that the FactoryTalk View Studio computer established SAs
with both HMI servers and the FactoryTalk Linx data server machine, as expected from
the test system architecture (Fig. 1).

Page | 20
7.2 FactoryTalk ViewPoint
The test system architecture for FactoryTalk ViewPoint was composed of four
computers, as illustrated in Fig. 15.

Figure 15

Unlike in previous test, for this architecture we configured four Organizational Units,
one for each participating computer – DataServer, VPClient, VPHMI and VPServer.

Figure 16

Page | 21
Each computer was then added to their respective OU. Below is the IP table of the
computers involved:

Role IP address
SE HMI Server 10.224.106.94
FactoryTalk Linx data server 10.224.105.85
ViewPoint Client 10.224.105.195
VP Server 10.224.105.123
Table 2

Per the phase 3a (section 5) we configured the IP Security Policies for each configured
OU. The details of the rule configurations are very similar to those provided in
FactoryTalk View SE system test. The configuration for FactoryTalk ViewPoint system
test are therefore illustrated with self-explainable snapshots below.

ViewPoint client IPsec policy configuration:

Figure 17

Page | 22
Figure 18

Figure 19

Page | 23
 Figure 20

ViewPoint server IPsec policy configuration:

Figure 21

Page | 24
Figure 22

Figure 23

Page | 25
 Figure 24

View SE server IPsec policy configuration:

Figure 25

Page | 26
Figure 26

Figure 27

Page | 27
 Figure 28

FactoryTalk Linx data server IPsec policy configuration:

Figure 29

Page | 28
Figure 30

Figure 31

Page | 29
 Figure 32

For all four OUs, the other Rule properties (Authentication Mode, Connection Type
and Tunnel Settings) as well as Integrity and encryption Properties and Security
Method, were configured in the same way as for the ServerClient OU in the
FactoryTalk View SE system test (please refer to Figures 8, 9, 10, 11 and 12).

7.2.1 Testing the configuration

Same as in the previous test, to verify that the IPsec communication was properly
established, we used network analyzer tool. Fig. 33 illustrates an example of
communication between ViewPoint Server and ViewPoint Client and same as before
captures ESP (IPsec secure traffic):

Figure 33

Again, using the IP Security Monitor tool we can monitor Security Associations
between any computers in the test system. The picture below shows SAs between

Page | 30
ViewPoint server and the rest of the computers in the system:

Figure 34

Page | 31
7.3 FactoryTalk AssetCentre
The test system architecture for FactoryTalk AssetCentre was composed of five
computers, as illustrated in Fig. 35.

Figure 35

For this architecture we configured one Organizational Unit called FTACSystem.

Page | 32
 Figure 36

Each computer was then added to the FTACSystem OU. Below is the IP table of the
computers involved:

Role IP address
FactoryTalk Directory Server 10.224.108.234
FactoryTalk AssetCentre Server 10.224.108.180
FactoryTalk AssetCentre Client 10.224.108.94
FactoryTalk AssetCentre Agent 10.224.108.35
SQL Database Server 10.224.108.55
Table 3

Per the phase 3a (section 5) we configured the IP Security Policies for the OU. The
details of the rule configurations are very similar to those provided in FactoryTalk
View SE and FactoryTalk ViewPoint system tests. The configuration for FactoryTalk
AssetCentre system test is therefore illustrated with self-explainable snapshots
below. In addition, the configuration for each computer in the architecture is
essentially the same and can be repeated as in the snapshots below.

AssetCentre IP security policy configuration:

Page | 33
Figure 37

Figure 38

Page | 34
Figure 39

Figure 40

Page | 35
 Figure 41

For the FTACSystem OU, the other Rule properties (Authentication Mode, Connection
Type and Tunnel Settings) as well as Integrity and encryption Properties and Security
Method, were configured in the same way as for the ServerClient OU in the
FactoryTalk View SE system test (please refer to Figures 8, 9, 10, 11 and 12).

7.3.1 Testing the configuration

In the same way as the previous test, to verify that the IPsec communication was
properly established, we used a network analyzer tool. Fig. 42 illustrates an example
of communication between the FactoryTalk AssetCentre Server and Agent. Fig. 43
shows an example of communication between the FactoryTalk AssetCentre Server
and Client. Same as before, we can see the protocol is ESP (IPsec secure traffic):

Page | 36
 Figure 42

Figure 43

Again, using the IP Security Monitor tool we can monitor Security Associations
between any computers in the test system. The picture below shows SAs between the
FactoryTalk AssetCentre Server, SQL Database server, AssetCentre Agent, and Client:

Page | 37
 Figure 44

7.3.2 Optional configuration for large distributed FactoryTalk AssetCentre systems

FactoryTalk AssetCentre offers the ability to have a large number of Agent and Client
computers distributed throughout the local facility, all connected to a single
FactoryTalk Directory. It may be desirable to secure all of these PCs with a single rule,
instead of defining each communication path. In this case we can create a single IP
Security rule called LargeACSystem with IP Filters set to Any IP Address to Any IP
Address as in Figure 45.

Figure 45

Page | 38
Results
8.1 FactoryTalk View SE results
The testing was completed with FactoryTalk View SE v11 using the application and the
procedures that are commonly used when testing any upcoming product version. The
scope of testing was comprehensive and performed in several iterations with and
without IPsec protected communication. It included all core product functionalities as
listed in the following table:

Functional Area / Action Result

Tag Read & Write Pass
Trend \ TrendPro read tag values Pass
Datalogging Pass
Recipe \ RecipePro+ Pass
Local message Pass
Event Pass
Parameter list and file Pass
Macro Pass
Animation Pass
Legacy HMI alarm (v10 & Earlier) Pass
Alarms & Events (Server & Device-based) Pass
Runtime language switch Pass
Global object resolution Pass
Web browser Display Object Pass
VBA Runtime Execution Pass
Runtime Security Pass
Runtime Secured command Pass
Onscreen keyboard (string input) Pass
SE Client view only Pass
SE Client auto logout Pass
SE Client code debugging (only VBA IDE) Pass
Redundancy Pass
Save studio changes in redundancy Pass
Table 4

The special consideration has been given to potential performance issues and delays
that could be exhibited when opening a new client session, when navigating displays,
while processing commands, etc. For instance, we repeatedly measured the time it
took to not only open a display but also the time it took to populate data items, process
animations and expression as well as global objects on that display. Furthermore, we
tested VBA and the time it took to read tag values.

The performance results are, of course, very specific to the test system architecture as

Page | 39
 well as the application and the procedures that we used. However, they can be used
as a general indicator about an impact that IPsec communication may have on certain
product functional areas.

According to our tests, here are the functional areas that were mostly affected by the
IPsec communication (the performance impact is presented as an average time ratio
(in %) between the times taken to complete the same actions when using IPsec and
when using TCP/IP communication).

Action Slower with IPsec Integrity & Encryption [%]

Initial opening of a client session 36
First opening of a graphic display 19
Recipe download 25
Expression evaluation 25
Animation resolution 35
Stopping data log model 35
Table 5

Other functional areas tested with IPsec yielded the same or very similar results as
when tested with TCP/IP, meaning without indicating any significant delay or a
performance impact.

8.2 FactoryTalk ViewPoint results

The testing was completed with FactoryTalk ViewPoint v11 using the same application
as in FactoryTalk View SE testing. In addition to core functionality tests (the tests listed
in Table 3 but only for functional areas applicable to ViewPoint), a special consideration
had been given to mobile functionalities such as Recipe and Alarming. Same as for
FactoryTalk View SE, all of the tests were completed with the status – PASS.

As for the performance impact, the most notable delays when using IPsec with
FactoryTalk ViewPoint were experienced while loading specific graphic displays. In
average, a display loading time was around 30% slower when compared to loading
the same display on a non-protected network (using TCP/IP).

Other functional areas such as recipe and trending were not affected by IPsec and
yielded the same performance as when operating the product on a TCP/IP-based
network.

8.3 FactoryTalk AssetCentre results

Page | 40
 The testing was completed with FactoryTalk AssetCentre v9 using a similar architecture
to the FactoryTalk View SE testing. Testing was conducted on core functionality and
the results are shown below in Table 6.

Functional Area / Action Result

AoS Tree Pass
Archive Pass
Schedules plug-in Pass
Agent Groups plug-in Pass
Logs Plug-in Pass
Searches Plug-in Pass
Table 6
Please note that depending on any number of factors such as system topology,
application specifics, hardware used, network speed and many others, you may
experience different results. Advanced managed network devices, such as Stratix™
managed switches, provide greater performance for IPsec network traffic transport
and may help reduce the latency introduced with these security protocols.

Our results were presented merely as a reference and also as a reminder that when
using IPsec it is advisable to set your expectations properly and be prepared for some
performance sacrifices when running FactoryTalk products in a network environment
protected by IPsec.

Summary
FactoryTalk View SE, FactoryTalk ViewPoint, and FactoryTalk AssetCentre operate normally
when running in a distributed network environment protected by using IPsec. None of the
functional areas of these products are affected by the secure nature of the network.

As discussed in the previous section, performance impact/slowness has been observed in

certain aspects of the product’s operations. This is an expected result when keeping in mind
the internal mechanisms and the protocols the IPsec is based upon. By its secure nature,
IPsec introduces the bandwidth/IP packet overheads that affect efficiency of the network.
Security parameter negotiation process when initializing and establishing an IPsec
communication also adds to the overall data transfer delays. In addition, defined Security
Associations are resource consumers, both memory-wise and CPU-wise and can have an
impact on their host (which is also hosting a FactoryTalk View or its component).

The key point to keep in mind is that the origins of the potential communication slowness
and/or performance impact in an industrial control system protected by IPsec are beyond
control of the FactoryTalk products. Our products rely on the network layer that IPsec is
implemented at. Whatever bandwidth and a speed that layer can provide is the bandwidth
and the speed our products can utilize. Proper network infrastructure that delivers the

Page | 41
maximum bandwidth and security protection are essential investments when building a
high-performance, robust, and secure control system.

Page | 42