The issue of security can be broken down in to two major components:
Authentication : Only people who are *allowed* to access the network can actually do so.
Privacy : The data transferred by authenticated parties is encrypted so that it cannot be read by anyone who intercepts it as the data traverses the network.
Traditional network authentication has been via the familiar "username and password" method. ePipe supports this, as well as several schemes which encrypt authentcation transactions in order to guard against passwords being revealed to any eavesdroppers.
Dial-out PPP connections may be authenticated by a username and plain text password in the "chat script", or by the PPP Password Authentication Protocol (PAP). Authentication using encrypted passwords is achieved via the Challenge Handshake Authentication Protocol (CHAP or a Microsoft variant called MS-CHAP).
Dial-in connections may be authenticated via a username and plain text password prompt, or via PAP, CHAP or MS-CHAP (as per outgoing connections).
The ePipe can store a list of valid users and their passwords in its internal database, or it can use the Remote Access Dial-In User Security protocol (RADIUS) to ask another server computer on the LAN to verify the incoming connection. RADIUS allows an authentication database to be managed centrally, and no user configuration need be stored at the ePipe. This is desirable when multiple ePipes are deployed. ePipe will interact with RADIUS servers from all major vendors, and open-source RADIUS servers. RADIUS security server software is available for Unix and Windows server environments.
ePipe provides the standard Internet Protocol Security suite (IPSec). Every network packet sent via IPSec contains a "cryptographic checksum". The checksum is used to prove that the packet originated from a trusted peer, and was not altered in any way during transmission.
IPSec authentication protects against imposters gaining access to your network, and also ensures that malicious parties are unable to modify any data as it traverses the Internet, or other insecure network.
ePipe allows you to encrypt traffic which crosses the Internet to another ePipe, to a PPTP client, or to another IPSec gateway. Encryption ensures that your private data cannot be read by anyone else, even if it is sent on a public network.
Encryption prevents any non-authorized party from reading or changing data. The level of protection provided by encryption is determined by an encryption algorithm. In a brute-force attack, the strength is measured by the number of possible keys and the key size. For example, a Triple-Data Encryption Standard system (3 DES) uses 112-bit or 168-bit keys and, based on currently available processing power, is virtually immune to brute-force attacks. With 112-bit key and the ability to try 245 billion keys per second, it would take an average of 336 trillion years to discover the key. Other popular shared key encryption ciphers are MPPE and Blowfish. Shared key or symmetric ciphers are typically used to encrypt the information payload.
ePipe supports DES, 3DES and Blowfish in the SSV feature set and MPPE in the SRA feature set.
Business to Business VPNs (Extranets) share sensitive data with multiple organizations, so demand the highest level of security and scalability. This requires public key encryption and secure key exchange, both of which are designed to eliminate the risk of the key becoming known to an unauthorized party. One party possesses a private unlocking key and makes a public locking key.
This technique can also be used to create a digital signature, which is a one way transformation of a clear message encrypted using a key and appended to the plain message. This transformation makes it possible to authenticate the sender of the message and verify that the message has not been altered since being sent by the author. Public key encryption is very CPU-intensive. It is used for small amounts of data, typically the athentication phase and not the bulk information transfer phase, where strong security is required.
The forthcoming BBV feature set will use Public Key Encryption through a Public Key Infrastructure supporting Digital Certificates.
Network Address Translation (NAT) allows computers on a private network to access the Internet without requiring their own global (public) Internet address.
NAT modifies outgoing network packets so that the return address is a valid Internet host (usually the address of the ePipe itself). Return (incoming) packets have their destination address changed back, and are relayed to the client host, thereby protecting the private addresses from public view.
There are two reasons to use NAT:
ISPs are reluctant to give out large numbers of addresses. If you have
more computers than you can get addresses, NAT allows those computers
to access the internet (outgoing traffic is re-written to use one of the
globally valid addresses allocated for your use).
You do not want your internal network addresses shown on the Internet. With NAT, all traffic will be shown as coming from the ePipe, yet clients will still be able to access the Internet as normal.
With ePipe and NAT, you can give your client computers addresses from the IP ranges reserved for private use (no need to buy extra network addresses from an ISP), and your ePipe will allow those client computers to access the Internet. Other Internet users will not be permitted to access your client computers (so they are secure), yet those same client computers can still access the Internet as if they were directly connected.
If you need to allow outside traffic (from the Internet) to enter your network, ePipe puts you back in control. You can restrict which hosts are allowed to enter, to which computers they may connect, and to what services. For example, you can allow connections only to the WWW server, or permit another organization access to a particular shared area of a fileserver.
You can also restrict the kinds and destinations of outgoing traffic that are permitted. Certain local clients may be permitted to access the Internet, while others may be denied.
Copyright © 2002 ePipe Pty. Ltd. All rights reserved.