This section describes the Secure Inner Channel (SIC) commands.

In RiOS v6.0 and later, encrypted peering extends beyond traditional SSL traffic encryption. In addition to SSL-based traffic like HTTPS that always needs a secure inner channel between the client-side and the server-side SteelHead, you can use the secure inner channel to encrypt and optimize other types of traffic as well:

Each SteelHead is manufactured with its own self-signed certificate and private key which uniquely identify that SteelHead. The secure inner channel setup process begins with the peer SteelHeads authenticating each other by exchanging certificates and negotiating a separate encryption key for each intercepted connection. Next, the SteelHeads create corresponding inner connections for all outer connections between the client and the client-side SteelHead and between the server and the server-side SteelHead.

Peers are detected the first time a client-side SteelHead attempts to connect to the server. The optimization service bypasses this initial connection and does not perform data reduction, but rather uses it to detect peers and populate the peer entry tables. On both SteelHeads, an entry appears in a peering list with the certificate of the other peer and identifying information such as IP address and hostname. You can then accept or decline the trust relationship with each SteelHead requesting a secure inner channel.

Once the appliances trust each other, they send encrypted data between themselves over secure inner connections matching the outer connections of the selected traffic types. The trust between the SteelHeads is bidirectional; the client-side SteelHead trusts the server-side SteelHead, and vice versa.

Riverbed recommends using the secure inner channel in place of IPSec encryption to secure traffic.

For detailed information, see the Management Console online help or the SteelHead Management Console User’s Guide.