Overview: Terminologies and Conventions¶
Following are some important terms and concepts used in the BIG-IP Next SSL Orchestrator.
Inbound and Outbound¶
“Inbound” refers to traffic coming into the network from external sources, such as the Internet or a remote branch office. When SSL traffic is inbound, SSL Orchestrator acts as a gateway that intercepts and inspects the traffic before forwarding it to its intended destination. This allows SSL Orchestrator to apply security policies, such as decrypting and inspecting the traffic for malware or other threats, before it reaches its final destination.
“Outbound” refers to traffic leaving the network and heading towards external destinations, such as servers located on the Internet or other remote networks. When SSL traffic is outbound, SSL Orchestrator can apply security policies and perform advanced SSL processing functions such as encryption, decryption, certificate validation, and protocol enforcement. By doing so, SSL Orchestrator can ensure that outbound SSL traffic is secure, compliant, and optimized for performance.
Note: Currently, BIG-IP Next SSL Orchestrator does not support Outbound traffic.
Layers¶
“Layers” refer to a hierarchical set of protocols, standards, and functions that work together to enable communication between devices over a network. The layers provide a standardized approach to network architecture and help ensure that devices from different manufacturers can communicate with each other. The OSI (Open Systems Interconnection) model is the most commonly referenced network layer model.
Forward Proxy and Reverse Proxy¶
At its core, BIG-IP Next SSL Orchestrator uses a full proxy architecture that maintains separate connections for the client and server sides of a conversation. This distinction provides the flexibility to support the breadth of topology modes and security service types. A proxy is typically defined as either forward or reverse, and there are subtle yet important differences between these.
A reverse proxy is associated with inbound traffic; usually some infinite number of external clients (for example, clients on the Internet) attempting to access a finite set of internal resources. In SSL Orchestrator, the proxy type also defines who owns the encryption keys. In a reverse proxy, the BIG-IP Next owns the encryption keys and performs direct and explicit decryption with these keys.
A forward proxy is associated with outbound traffic; usually some finite set of internal users attempting to access infinite external resources (for example, using the Internet). In SSL Orchestrator, the proxy type also defines who owns the encryption keys. In a forward proxy, the remote resource owns the encryption keys, so SSL Orchestrator must re-issue (forge) a local copy of the remote server’s certificate to the internal client. The internal client must then trust the local certificate authority of those re-issued certificates. Forward proxies will be routed to (L3 topology mode) or addressed directly (explicit proxy topology mode).
Note: Currently, BIG-IP Next SSL Orchestrator does not support forward proxy.
Inline¶
Inline refers to a device with physically or logically separate inbound and outbound traffic paths. Traffic enters one interface and exits another. This term is used within BIG-IP Next SSL Orchestrator to define layer 2, layer 3, and HTTP security services to which SSL Orchestrator passes decrypted traffic. When BIG-IP Next SSL Orchestrator passes decrypted traffic to one interface of the device, that traffic flows through the device and exits another interface (again, physical or logical), returning to the SSL Orchestrator.
Service Chains¶
A service chain is a logical grouping of services in a defined order through which the SSL Orchestrator processes traffic. Security policies match traffic flow conditions, assigning flows to service chains. The service chain then orchestrates the traffic through the defined set of services in the specified order. An SSL Orchestrator service chain uniquely differs from the “daisy chain” approach of other SSL visibility products. Therefore, it may be useful to conceptualize a service chain as the opposite of a daisy chain.
Note: Currently, BIG-IP Next does not support dynamic service chaining. This release only supports static service chaining where traffic is orchestrated through services in no preferred order.
Daisy Chain
In a daisy chain, traffic flows through each device in the chain directly - out of the first device, into the second device, then to the third device, and so on before returning to the SSL visibility product. In such a daisy chain architecture, the devices are usually wired directly together such that all devices see all traffic.
The following are typical characteristics of a daisy chain:
If a device in the daisy chain is not designed to inspect some traffic, it still must at least pass that traffic through, which counts against its capacity.
If a specific throughput requirement is needed for the solution, then all devices in the daisy chain must support that throughput.
As these devices are usually wired together, it becomes challenging to scale (load balance), make changes or perform maintenance without requiring downtime.
Service Chain
In the SSL Orchestrator service chain model, all services are connected (physically or logically) to SSL Orchestrator. The service chain model improves over the daisy chain model in the following ways:
If some services are not designed to inspect some types of traffic, a traffic policy can send traffic to interested services, bypassing those that are not. For example, you can configure only to send outbound HTTP traffic to an HTTP proxy device.
If a specific throughput requirement is needed for the solution, but not all traffic needs to go to all services, then not all services have to scale simultaneously.
As these services are independently orchestrated, scaling and performing maintenance (such as adding/removing devices from individual service pools) becomes easy without downtime.
Static Service Chain¶
A static service chain is a predetermined sequence of security services and policies applied to SSL traffic as it flows through the SSL Orchestrator. The static service chain is configured ahead of time and not modified during runtime, which implies that SSL traffic is routed through the same set of security services and policies every time it passes through the SSL Orchestrator.
A static service chain in SSL Orchestrator can enforce a specific security policy, ensure compliance with regulatory requirements, or optimize network performance.
Dynamic Service Chain¶
A dynamic service is a combination of service chains and traffic policies. Traffic policies allow or block, intercept or bypass, and assign traffic to different service chains and different sets of security services dynamically based on parameters such as IP Protocol, IP Version, Client Port Match, Server Port Match, and so on.
Inspection zone¶
An inspection zone refers to the network region between decryption and re-encryption operations where cleartext data is available for inspection. BIG-IP Next SSL Orchestrator decrypts traffic once, dynamically orchestrates that traffic to the set of defined security services, and then re-encrypts.
Inbound Application Mode¶
Inbound Application Mode serves as a termination point. The client’s packet contains an IP address assigned to the topology listener as the destination address. In the Application mode setup, the corresponding LTM virtual server specifies the target destination IP address and port. Address and port translation are activated, a pool is designated, and NAT is applied to the load-balanced pool members.
Inbound Gateway Mode¶
Inbound Gateway Mode serves as a point of entry for SSL/TLS traffic into the network. It acts as a gateway where incoming SSL/TLS traffic is decrypted and inspected before being forwarded to its destination.