This chapter describes secure transport, which enables you to integrate and configure encryption services with path selection. Secure transport enables simple, secure, and manageable group encryption for inter-SteelHead communication for path selection deployments. It includes the following sections:

This chapter requires you be familiar with path selection, topology, sites, and networks. For more information, see Sites and Networks, Path Selection, and QoS, the SteelHead Deployment Guide, and the SteelCentral Controller for SteelHead User’s Guide.

Secure transport requires:

This section provides an overview of secure transport and includes the following topics:

A key feature for the hybrid enterprise is to leverage multiple paths between sites. This feature enables diversity across a variety of networks for resiliency. More importantly this feature enables you to more efficiently select the network delivery mechanism for an application.

However, not all network paths are equal in terms of exposure to security risks. A common technique to secure traffic is to encrypt traffic at the IP layer with IPSec, which prevents disclosure if traffic is intercepted in transit. This type of encryption also prevents replay attacks from an attacker in the middle of the chain.

Starting in RiOS 9.0 and SCC 9.0 Riverbed introduces the secure transport feature. Secure transport is integrated with path selection and provides a method to configure and enable encryption services for traffic over a path. Secure transport provides security services at the IP layer for path selection—you can add security for an application, application groups, or custom applications based on the path the traffic travels. By integrating encryption services into the SteelHead, the secure transport feature delivers a secure path between peers over a private WAN, public internet, or a hybrid network.

One key capability of secure transport with path selection managed by the SCC is that each peer automatically joins a security group with other SteelHeads whenever you mark a network as securable and assign the network to the site the peers belong to. This capability has benefits over other forms of encryption services that require configuration at both ends and policies to select the traffic that’s encrypted.

One benefit is that automatically joining a security group requires minimal configuration because it is easier to implement the network design changes when you want to include new sites or new networks that require encryption. Additionally, configuration is done centrally on the SCC, which minimizes the potential for configuration errors as opposed to configuring encryption separately on each device. Also, other virtual private network (VPN) technologies require traffic to match a policy, which then triggers negotiation between devices performing encryption before the encryption is actually performed. With secure transport, encryption is applied packet-by-packet using IPSec tunnel mode.

Secure transport uses a group model for encryption services. In a group model each appliance registers with a controller to learn network-reachability information, policies, and important material to use for encrypting traffic. Each appliance also performs reachability tests to ensure the path is available.

Secure transport uses standards-based IPSec using AES-256 and SHA-2 to secure traffic over a path. Secure transport uses IPSec tunnel mode of which the original IP addresses are part of the encrypted payload (Figure: Tunnel mode).

You manage the encryption services centrally through the SCC. Functionality of secure transport is separated into the:

Figure: Secure transport functionality shows how the functionality of secure transport performs at a high level. The SCC works with the management plane for configuration and reporting, a SteelHead in the group acting as the controller manages the control plane actions (such as distributing network-reachability information and encryption key information), and the SteelHeads in the group encrypt traffic for the data plane.

The management plane is configured on the SCC using SSL and SSH secured communications, in which you create and distribute the path selection policy. When a network is marked as securable, it indicates that the SteelHead will join a group of other SteelHeads that can encrypt traffic. The SCC pushes the path selection policy to all the SteelHeads.

The management plane also provides reports on the status and metrics associated with the secure transport feature.

The SCC is not intended to be an internet-facing device. We recommend that you connect over a network path, controlled by your organization: for example, a private WAN such as MPLS or a third-party VPN connection. After the SteelHead communicates with the SCC, it receives information on how to reach the controller, registers with the controller, and then can perform encryption services for path selection.

Currently, performing encryption services when a site doesn’t have a network path, controlled by your organization, is not a current use case. However, after the SteelHead has registered with the SCC and subsequently with the secure transport controller (controller), it can provide encryption services during periods of time in which connectivity with the SCC is not available through a network path controlled by your organization. This behavior occurs because the SteelHead can continue operating with the path selection policy received from its last contact with the SCC and the key information with the SteelHead acting as the controller.

The control plane is a secure communications channel between each SteelHead peer (group member) and a controller. The controller can run on a SteelHead that has been configured as a controller and activated using SCC. When a SteelHead receives a path selection configuration that has a securable path, the SteelHead completes a process of registering with the controller. The controller communicates with each SteelHead in the group and distributes network-reachability information and generates the encryption keys to use over the data plane.

For more information about encryption keys, see Encryption key operations.

Remember that the control plane is providing network reachability information related to the site, such as the public IP address for a secured path.

For more information about sites, see Configuring sites and networks.

For more information about the controller, see Controller sizing.

Each SteelHead in the group takes part in the data plane and secures traffic over any path marked as securable. The SteelHeads use the encryption keys received from the controller to perform encryption and use the path selection services policy received from the SCC to determine which traffic is encrypted.

Remember that the control plane is providing network reachability information related to the site such as the public IP address for a secured path.

For more information about sites, see Configuring sites and networks.

Figure: Secure transport functionality shows another view of the functionality of the management, control, and data plane for secure transport. The SCC performing the management plane is the central point for configuration of the secure transport group. The SCC passes the group configuration information to the controller and group members. The controller generates encryption key information and network-reachability information, and it also performs registration and validation of group members in the control plane.

This section has information about sizing. It includes the following topics:

In RiOS 9.2 and later, the maximum number of supported secure transport sites is limited to 250. If you’re using secure transport in a RiOS version previous than 9.2, see that version of the SteelCentral Controller for SteelHead Deployment Guide.

Secure transport is a network service. For more information about the throughput and connections, see the SteelHead Product Family Specification Sheet.

Consider the concentration point in most VPN networks (typically the data center) has the most throughput, and as a result requires higher capacity devices. Likewise with WAN optimization, the SteelHeads in the central part of the network are larger model appliances with more CPU, RAM, and data store capacity. Furthermore, you can configure a dedicated SteelHead as a secure transport concentrator to perform only encryption services. For more detailed questions, contact your Riverbed account team.

For more information on a secure transport concentrator, see Secure transport concentrator.

Sizing of a controller follows similar logic as discussed in Group member sizing. We recommend that you consider the following factors when sizing and selecting the controller:

This section describes functional operations of the secure transport feature. It contains the following topics:

Secure transport requires communication on the management plane, control plane, and data plane. All communication is initiated by the SteelHead peer (group member), except for the management plane. Consider the following port usage:

The controller can communicate using any available SteelHead interface in which the controller is running on. By default, the SteelHead peer (group member) uses only the primary interface when communicating to the controller. This limited interface use presents a challenge if the primary interface can’t communicate over the data plane.

To communicate from a separate interface, the SteelHead must run RiOS 9.1 or later, and you must enter the stp-client controller in-path enable command.

After you use this command to enable another interface, the SteelHead attempts to communicate first from the in-path interfaces (starting with the lowest number, such as 0/0) and then moving onto the primary and auxiliary interface, until communication is established. Remember, because the request travels to both the private and then public address of the controller, it can take up to 40 seconds before the next interface is attempted.

Consider the choice of the controller IP address based on the reliability of the networks the in-path interfaces are connected to. For example, you can configure only a private IP address for the controller. This configuration allows all the SteelHeads participating in the secure transport group to contact the controller only to that single private IP address.

Because secure transport was built taking hybrid networking into account, you can configure a private and public IP address. The public IP address relies on reachability over a network marked Public. This configurations allows the controller to first be reached over the private network and then the public network. The private and public IP addresses do not need to come from the same in-path interface. With the stp-client controller in-path enable command, the data center SteelHead (DC-SH) uses the private and public IP addresses from the same in-path interface, while the branch office SteelHead (BR-SH) uses the private and public IP addresses from different in-path interfaces.

Whenever you use encryption services or any encapsulation technique, packet size and fragmentation become an issue. The SteelHead is aware of which paths are using an encapsulation technique, such as firewall traversal or secure transport, and lowers the TCP maximum segment size (MSS) as part of the initial setup of the connection. This behavior occurs for pass-through and optimized traffic and minimizes the possibility for fragmentation.

The secure transport feature uses more overhead than the 24 bytes for the generic routing encapsulation (GRE) header used in the firewall traversal feature but operates in the same manner. For information about maximum transmission unit (MTU) considerations for the firewall traversal feature, see the SteelHead Deployment Guide.

The encryption techniques used for secure transport are standard-based IPSec that includes encapsulating security payload (ESP). As part of the secure transport feature, the SteelHead can further encapsulate ESP packets in UDP. This encapsulation allows the SteelHead to leverage the private to public address translation, commonly referred to as NAT, which occurs at the boundary device between the private LAN and public WAN.

By default, RiOS uses UDP port 4500. On the SCC, NAT traversal is employed when you mark that a network is public and securable (Figure: Public and securable network).

For each SteelHead to use a public and securable path, the SteelHead must register its public IP address to the controller. On the SteelHead, you configure the public IP address and port number as part of the in-path interface configuration (Figure: Public IP address).

You must manually enter the public IP address because it is not automatically discovered. If the public IP address changes, you must change it on the SteelHead. We recommend that you use a static IP address from your service provider for a network configured as public.

If providing secure transport services over a public network in which NAT is used, the SteelHead acting as the controller must have its public IP address also assigned. This configuration is performed at the CLI for any SteelHead that’s an available controller.

Figure: Details of NAT traversal shows packet details from the Wireshark display for an encapsulated packet using NAT traversal.

In the world of data encryption, no key is considered secure for eternity. Given a period of time or given enough data, an attacker might be able to compromise the encrypted key. Secure transport supports the configuration of a rekey interval (time based) or rekey data size (volume based). By default the SCC has a rekey interval of 3600 seconds or 1 hour (Figure: Rekeying settings). However, for higher speed links a rekey can be triggered by the total amount of data transacted by the group, which is by default 4 TB. You can adjust these values by choosing Manage > Services: Secure Transport.

The rekey operation is performed without incurring a period of packet loss. Each SteelHead in the group is given a new encryption key by the controller. As each appliance in the group has the new encryption key, it uses the new key to perform path monitoring. After each group member on a path is using the new key for path monitoring, the SteelHeads switch to the new key.

The SteelHeads in the group contact the controller every 15 seconds as a means to verify if the controller is reachable. When a SteelHead in the group is unable to reach the controller after three attempts, that SteelHead enters into disconnected mode. Disconnected mode lasts for 300 seconds by default, after which time the SteelHead ceases performing encryption services. You can adjust the disconnected mode timeout to allow for more or less time. You can add more time to account for the manual process of selecting a new controller in the SCC. Less time can potentially run the risk of causing encryption services to stop during a momentary outage.

You can decide that a SteelHead can stop all traffic if encryption services for a path can’t be performed and no alternative secure paths are available. This operation can be done in the path selection rules and applied to individual applications, application groups, custom applications, or for all traffic. However, this setting doesn’t take effect if the SteelHead fails and goes into the default fail-to-wire mode. In fail-to-wire mode, all traffic is relayed through the SteelHead without encryption. As a result, configure both the in-path interface for fail-to-block and the path selection rules to drop traffic if the desired secure path is not available.

You can dedicate a SteelHead for secure transport functionality by configuring the SteelHead in the SCC as a secure transport concentrator. When configured as a secure transport concentrator, the SteelHead only performs encryption services. This configuration can be an ideal option for:

Figure: Topology for secure transport concentrator shows a typical topology that’s applicable to the secure transport concentrator capability.

Use the SCC in order to configure a SteelHead as a secure transport concentrator on the sites page by adding the SteelHead and one or more secure uplinks.

For more details about the secure transport concentrator, see the SteelCentral Controller for SteelHead User’s Guide.

This basic secure transport workflow provides encryption services over a private WAN.

Figure: Basic deployment example shows a single SteelHead located at the data center and the branch office. Each SteelHead has a single in-path interface. Each site has a separate Layer-3 device providing routing services for a private WAN (such as MPLS) and a public WAN (such as the internet). A general purpose VPN is not incorporated at the branch office for internet traffic encryption. Instead internet access is meant to offload corporate traffic from the private WAN onto the public WAN. This deployment is a hybrid network backhaul use case for the secure transport feature.

The example also includes encryption services for an application over the MPLS that demonstrates another use case.

Figure: Basic deployment example has a path selection policy that can leverage this internet offload path and provides encryption services for traffic selected on that path. Because that path is on the public internet, other traffic doesn’t use the internet path because this path is not available unless the secure transport path is operational.

Each site is configured in the SCC.

To complete the path selection policy, you must create path selection rules on the SCC. In the example, traffic using TCP source port 5001 or TCP destination port 5001 is configured to use the MPLS-secure path and be dropped if that path is not available. Traffic using TCP source port 5002 or TCP destination port 5002 is configured to use the internet path and be dropped if that path is not available. All other traffic is relayed. Figure: Path selection rules shows an example of specifying a custom application to take a securable path and drop if that path is not available. However, you can use different path selection rules to meet the business requirements.

Figure: Split tunnel example shows a single SteelHead located at the data center and a single SteelHead at the branch office. Each SteelHead has two in-path interfaces in which each in-path interface sits between a LAN router and a WAN edge router.

Each site has a separate Layer-3 device providing routing services for a private WAN (such as MPLS) and a public WAN (such as the internet). A general purpose VPN is not incorporated for encryption over the internet. Instead, internet access is serving the following purposes in this example:

This example also shows direct internet access, also known as a split tunnel, in which traffic that’s configured as a secured path to the internet and traffic going to internet destinations, egresses through the same interface. For more information about internet traffic, see Step 3 in To manually configure the SCC to manage a single site.

 

After the policy is pushed, the SteelHeads can use the secured paths. Figure: Secure transport encryption shows a connection that was optimized and path selected over the internet-secure path. The connection was encrypted using secure transport.

Figure: MPLS-secure path shows another connection that was optimized and path selected over the MPLS-secure path. This connection was also encrypted using secure transport but was not UDP encapsulated.

Internet connections at the branch were identified and relayed as the site has Direct-to-Internet configured. Figure: Failed terminated shows a connection that appears as Failed Terminated because the SteelHead attempted autodiscovery and there was no SteelHead on the path to the server. Figure: Traffic passing through) shows how changing the in-path rules causes the connection to appear as intentional pass-through traffic and the same path selection action, relay, is performed.

 

Figure: Current connections report shows details in the SteelHead current connection report that indicate whether an individual connection is using secure transport and on which uplink traffic was sent.

Figure: Traffic information shows aggregate traffic information that’s available in the SCC on the Secure Transport page.