You can pay additional license payments to Oracle and have the Advanced Security Option take care of securing your Redo transport between your primary and your standby databases. However, alternatively, you could save yourself a good amount of license fees by using the open source OpenSSH to encrypt your redo traffic and use simple ssh port-forwarding.
Be aware that if you do not encrypt your redo transport then it is possible for your data to be read as it is sent over the wire. I looked at a tcpdump of the unencrypted traffic while I performed a simple update, and you can see both the original value and the updated value of the data. You really do not want to be sending this stuff if you have any sensitive data, but you can protect yourself easily.
First generate a public/private key pair for the oracle user:
oracle$ ssh-keygen -b 2048 -t dsa
Chose an empty passphrase when prompted.
Copy the public/private key to the standby server (you need a connection going in both directions, FAL is pull).
create your ssh tunnel:
oracle$ ssh -N -L 3333:remote-server:1521 oracle@standby-host
So port 3333 (you can choose your favourite number above 1024, that does not clash with some other service) is on the server that orginated the ssh tunnel, remote-server is the one you are connecting to (remember you want a tunnel going primary -> standby & standby -> primary) and 1521 is everyone’s favourite Oracle listener port. The -N flag means do not execute a remote command, while the -L specifies the localport:remotehost:remoteport that you want to use.
Now you create tns entries on primary and standby to use the port-forwarded connection:
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 3333))
(SERVICE_NAME = STANDBY)
You now use this tns entry in your LOG_ARCHIVE_DEST parameter to direct your redo to the standby. Once this is done, no one can read your redo transport stream.
This also saves you having to open a hole in any firewalls to allow traffic on port 1521, as the traffic goes over port 22. I have used this trick not only for securing dataguard communications, but also for securing remote database logons for applications. I have seen no performance impact to this and to me it seems a whole lot simpler than the Advanced Security Option.