Security Features

Separation of Management and Network Traffic

The Oracle SD-WAN explicitly segregates all management and network traffic. This affords the appliance the ability to use known hardened applications to protect the appliance's management and configuration features without concern for collisions with Talari technologies.

This division also means that the Oracle SD-WAN data path cannot be compromised through management applications with known or unknown exploits or through standard probing techniques as the data path is not required to monitor, respond to, or forward management application traffic.

Security Zones

Oracle SD-WAN configuration allows for the explicit designation of network interfaces as Trusted or Untrusted.

A Trusted interface is a port that connects to a network where security is provided or is unnecessary. An example of this would be a link to an MPLS network or to a router that manages network-to-network security via a VPN infrastructure. Generally speaking, it is expected that a Trusted network segment is firewalled. Paths on a trusted interface can be configured as encrypted or non-encrypted.

An Untrusted interface is a port that connects to a network where no security/firewall is provided. An example of this would be a link to the public Internet, such as a DSL or Cable Internet connection. Paths on an untrusted interface can only be configured as encrypted. The Oracle SD-WAN does not allow non-encapsulated traffic to be forwarded from an Untrusted to a Trusted interface but does allow for PING and ARP requests.

Path Encryption

All Paths within a Conduit can be independently configured to encrypt or not encrypt their data between Sites. The method of encryption is configured globally for the entire Oracle SD-WAN. Path encryption is performed as follows:

• AES Encryption with 128bit or 256bit key (key length configured globally)
• Cipher Block Chaining (CBC) Mode
• Per-protocol sequence numbers included in every encrypted packet to help ensure message indistinguishability
• Per-session symmetric encryption keys negotiated using Elliptic Curve Diffie-Hellman exchange
• Optional: Periodic encryption key rotation using Elliptic Curve Diffie-Hellman exchange
• Optional: Use of an Initialization Vector, known as the Extended Packet Encryption Header
• Optional: Use of additional message authentication information, known as the Extended Packet Authentication Trailer

Per-Session Encryption Keys and Encryption Key Rotation

Per-session encryption keys are generated and automatically rotated (when Encryption Key Rotation is enabled) using an Elliptic Curve Diffie-Hellman algorithm. This provides the following benefits:

• Forward Secrecy
• Frequency Analysis from one session to another becomes a cryptographically hard problem since the session start and sequence number wrapping events are not immediately known
• A compromised encryption key does not automatically compromise the entire system and an Oracle SD-WAN reboot or encryption rekey re-secures the entire Oracle SD-WAN

Use of the Encryption Key Rotation feature is configured globally for the entire Oracle SD-WAN. It is enabled by default and Oracle strongly recommends that it remain enabled during normal operation. Disabling this feature may be relevant for certain troubleshooting scenarios. When enabled, Conduit encryption keys will be renegotiated on a random interval between 10 and 15 minutes.

Peer Message Authentication

The Oracle SD-WAN encrypts a checksum of the Talari Reliable Protocol (TRP) header as part of each outgoing message. After decryption is complete on the receiving end, the checksum is validated. Since the checksum was encrypted with the message, the Oracle SD-WAN assumes that a trusted party sent the message, provided that the encryption key is secure.

Users can also enable the Extended Packet Authentication Trailer, which greatly strengthens message authentication. This feature is described below.

Replay Attack Protection

In the Oracle SD-WAN, the NCN maintains a network time to which all Clients must sync. This gives the Oracle SD-WAN a uniquely accurate method to protect against replay attacks without the need for sequence number synchronization. The Oracle SD-WAN obfuscates a sent timestamp in the TRP trailer of each outgoing message. If the sent timestamp of an arriving packet isn't within a certain range of the current network time, the packet is unlikely to be needed by users in the network and is also unlikely to be valid for processing. The Oracle SD-WAN will discard the packet.

The timestamp is sent with microsecond resolution and is 32 bits in length, which yields a ~4300 second (72 minute) range of protection. Encryption key rotation (which is configurable, but enabled by default) causes encryption keys to be renegotiated at intervals not to exceed 15 minutes, which means that there is never a long term window in which a replayed packet could be successful. Additionally, packet and flow sequence numbers ensure that short term replayed packets are treated as duplicates and dropped accordingly.

Secure Key Regeneration

In the same sense that it is not possible to eliminate the security ramifications of leaked VPN passwords, it is not possible to eliminate the ramifications of leaked Secure Keys. To that end, the Secure Key for a Site or for all Sites in the Oracle SD-WAN can be quickly regenerated via the Oracle SD-WAN web console. Regenerating Secure Keys is a non-resetting configuration change and will not affect Oracle SD-WAN operations.

Secure Key Protection

In both Oracle SD-WAN Software and Oracle SD-WAN Aware, Secure Keys are removed from all diagnostic information and no information is provided in diagnostic information that would allow Secure Keys to be reverse engineered.

Message Indistinguishability

• Sequence Number Size—The encryption key rotation window has been defined to guarantee that sequence numbers don’t wrap before the next key rotation. In order to balance the need for indistinguishability against the potential performance impact of key rotation, the rotation window and the size of various sequence numbers have been tuned against one another to extend the roll over time.
• Initial Sequence Number—All sequence numbers, except for the internal TRP Flow sequence number, are seeded with a cryptographically random initial value to reduce the risk of Frequency Analysis. This eliminates the predictable nature of first packets having identical content.

Extended Packet Encryption Header (Optional)

An Initialization Vector (IV) is often used to provide very high unpredictability of the first encrypted block in a cipher block chain. However, using Initialization Vectors has some drawbacks:

• A static IV is no more protective than a NULL IV.
• While an IV need not be secured in the encrypted message, it must be known to both sides of the encryption. Typically, this means the IV is sent along side the encrypted message.
• If an IV becomes predictable, much of the security it provides is compromised. There are known attacks to exploit this problem.

An alternative to rotating an IV in a cryptographically secure way is to seed the first cipher block of data with a large counter that is seeded with a cryptographically random initial value. After encryption, the counter is essentially a random block of data deterministic only with the encryption key. This method is proven to provide the same security as an IV, without incurring the process overhead of randomly generating an IV for each packet and guaranteeing that each IV is unique. See Appendix C of the NIST doc, which directly reference this methodology: http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf.

To provide users with the ability to have the highest level of packet uniqueness and protection against Frequency Analysis, an optional 16-byte counter can be prefixed inside the encrypted payload to act as a rotating, cryptographically random Initialization Vector.

This counter is known as the Extended Packet Encryption Header. Use of the Extended Packet Encryption Header is configured globally for the entire Oracle SD-WAN. It is disabled by default.

Extended Packet Authentication Trailer (Optional)

To provide users with the ability to have strong message authentication, an optional trailer inside the encrypted payload can be enabled. By default, this optional trailer is composed of a 4-byte checksum of the unencrypted packet data, which acts like a standard Hashed Message Authentication Code (HMAC). While a standard HMAC would impact performance significantly, this checksum trailer provides a similar benefit while minimizing processing overhead. Because the checksum is over unencrypted data and is itself encrypted, there is a very high statistical likelihood that any change made to the packet will lead to either an incomprehensible packet or a mismatching checksum.

If use of a standard HMAC is required, the optional trailer can be configured to use a 16-byte SHA-256 HMAC in place of the 4-byte packet checksum. (Note: When used as an authenticating HMAC, the result of the SHA-256 function is truncated to 16 bytes.) Use of a standard HMAC, though cryptographically more secure, significantly decreases forwarding performance.

This trailer is known as the Extended Packet Authentication Trailer. Use of the Extended Packet Authentication Trailer is configured globally for the entire Oracle SD-WAN. It is disabled by default.

Database Security

It is recommended, for security reasons, to limit access to the Aware database in order to protect the configuration and metric data. To accomplish list, remove external access to the database so that only the Aware application can access the database.