IPSec Plugin Users Manual Reference Manual Downloads Purchase |  | Notice:
Portions of this material were reproduced by permission from IBM Corporation and adapted from "A Guide to Virtual Private Networks" copyright International Business Machines Corporation 1998.

Contents |
Motivation for IPSec Introduction to IPSec IPSec Outline IPSec Security Introduction to VPN's Principal IPSec Protocols 6.1 IP Authentication Header (AH) 6.2 IP Encapsulating Security Payload (ESP) 6.3 Combining the protocols 6.4 Internet Security Association and Key Management Protocol (ISAKMP) IPSec Security Associations 7.1 Security Parameter Index 7.2 IP Destination Address 7.3 Security Protocol Tunnel vs. Transport Mode IPSec Scenarios 9.1 Case-1: End-to-End Security Between 2 Hosts 9.2 Case-2: Simple Virtual Private Network 9.3 Case-3: Case 1 and 2 Combined 9.4 Case-4: Mobile User Accessing Secure Host Behind Firewall IPSec Plugin Interoperability Plugin Protocol Support Summary More About IPSec IPSec RFC's
1. Motivation for IPSec |
Internet has shown its strength during the nineties. Most major corporations are now connected, and a large fraction of homes will be networked in the next few years. Though superior in its flexibility, the Internet has shown a major weakness; The lack of security. Without encryption, anyone can read and tamper with the data sent over the network. Secrets can be stolen and mission critical data can be modified to cause irrepairable harm. Without proper authentication, anyone can easily lie about identity and it may be impossible to know who you are doing business with or keep track if a crime has been committed. Internet devices without protection are susceptible to external attacks. An attacker can get into internal data repositories, destroy information, install viruses, or just simply turn off or prohibit the services. The obvious demand for a comprehensive security standard has finally been answered with the network vendor adoption of the IPSec standard.
2. Introduction to IPSec |
The purpose of the IPSec (Internet Protocol Security) protocol suite is to provide a standard way for protecting all traffic on the Internet transparently, irrespective of the application. The IPSec protocol is a set of security extensions providing privacy and authentication services by using modern cryptographic methods. It can protect all traffic against unauthorized modification and eavesdropping and securely authenticate the parties that are communicating with each other. It renders the commonly used security attack methods completely ineffective. IPSec makes it possible to securely connect company offices, individual host, and services to the network. It makes the network safe for transmitting confidential information. For the first time, security is transparent, requiring absolutely no actions on the part of end users. From a customer's perspective IPSec brings two main benefits: strong standardized network security inherent with IPSec compliant products, and interoperability with other IPSec compliant vendors. IPSec customers have the comfort of knowing that IP based communications passing over the network are using the most secure and comprehensive standard available today where encryption, authentication and data integrity are wrapped together. An exciting part of IPSec compliance is that it provides the first open roadmap for customers to integrate their own unique x.509 digital certificates into vendors IPSec compliant products for strong and transparent user authentication.
3. IPSec Outline |
1. IPSec Goals Data Origin Authentication Data Integrity Data Confidentiality Replay Protection Automated Key Management 2. IPSec consists of three components AH - Authentication Header (double hash w/ key) ESP - IP Encapsulating Security Payload ISAKMP - Internet Security Association & Key Management Protocol 3. Two Possible Modes Transport - Host to Host Tunnel - Host to Firewall, Firewall to Host, Firewall to Firewall
4. IPSec Security |
Within the layered communications protocol stack, the network layer (IP in case of TCP/IP) is the lowest layer that can provide end-to-end security. Network-layer security protocols provide blanket protection for all upper-layer application data carried in the payload of an IP datagram, without requiring a user to modify the applications. IPSec is based on the IP Security Architecture open framework, defined by the IPSec Working Group of the IETF. IPSec is called a framework because it provides a stable, future-ready base for providing network layer security. It can accommodate today's cryptographic algorithms, and can also accommodate newer, more powerful algorithms as they become available. IPv6 implementations are required to support IPSec, and IPv4 implementations are strongly recommended to do so. In addition to providing the base security functions for the Internet, IPSec furnishes flexible building blocks from which robust, secure virtual private networks can be constructed. The IPSec Working Group has concentrated on defining protocols to address several major areas: Data Origin Authentication. Verifies that each datagram was originated by the claimed sender. Data Integrity. Verifies that the contents of the datagram were not changed in transit, either deliberately or due to random errors. Data Confidentiality. Conceals the cleartext of a message, typically by using encryption. Replay Protection Assures that an attacker can not intercept a datagram and play it back at some later time without being detected. Automated Management of Cryptographic Keys and Security Associations. Assures that a company's VPN policy can be conveniently and accurately implemented throughout the extended network with little or no manual configuration. These functions make it possible for a VPN's size to be scaled to whatever size a business requires. IPSec applies to both UDP and TCP traffic, but also ICMP traffic as long as it is not ICMP error messages. For example ICMP Echo/Reply (ping) blocks are treated like other traffic and protected on an end-to-end basis, using SAs in the usual fashion. An ICMP error message protected by AH or ESP which is generated by a router is processed and forwarded in a tunnel mode. Note, if the router at the originating end of the tunnel is forwarding an ICMP error message from another router, the source address check would fail.
5. Introduction to VPN's |
Virtual Private Networks (VPNs) exploit the worldwide reach of the public Internet to provide secure, cost-effective intra-company and inter-company communications. The breadth of the Internet and its growth in popularity have positioned it as the external network of choice for connecting intranets securely, both within and between companies. VPNs securely convey information across the Internet connecting remote users, branch offices, and business partners into an extended corporate network, as shown below: Traditional corporate networks were typically operated by the corporation; they used private facilities (e.g., leased lines or frame relay circuits); they carried only internal traffic; and they were generally inaccessible by outside users. In this closed environment, the traditional corporate network was usually considered to be secure. Today, the corporate networks are evolving toward a collection of physically separated intranets interconnected over the public Internet, and inter-company communication is now a business necessity. This new business model presents security exposures that were not present in the traditional corporate networks. Operators of VPN's must understand these exposures and protect against them. Internet Service Providers (ISPs) offer cost-effective access to the Internet (via direct lines or local telephone numbers), enabling companies to eliminate their current, expensive leased lines, long-distance calls, and toll-free telephone numbers.
6. Principal IPSec Protocols |
The principal IPSec protocols are: IP Authentication Header (AH) provides data origin authentication, data integrity, and replay protection. IP Encapsulating Security Payload (ESP) provides data confidentiality, data origin authentication, data integrity, and replay protection. Internet Security Association and Key Management Protocol (ISAKMP) provides a method for automatically setting up security associations and managing their cryptographic keys. Authentication Header (AH) The IP Authentication Header provides connectionless (that is, per-packet) integrity and data origin authentication for IP datagrams, and also offers protection against replay. Data integrity is assured by the checksum generated by a message authentication code (for example, MD5); data origin authentication is assured by including a secret shared key in the data to be authenticated; and replay protection is provided by use of a sequence number field within the AH header. In the IPSec vocabulary, these three distinct functions are lumped together and simply referred to by the name authentication. AH authenticates as much of the IP datagram as possible. Some fields in the IP header change and their value cannot be predicted by the receiver. These fields are called mutable and are not protected by AH. The mutable IPv4 fields are: Type of Service (TOS) Flags Fragment Offset Time to Live (TTL) Header Checksum When protection of these fields is required, tunneling should be used. The payload of the IP packet is considered immutable and is always protected by AH. AH processing is applied only to non-fragmented IP packets. However an IP packet with AH applied can be fragmented by intermediate routers. In this case the destination first reassembles the packet and then applies AH processing to it. Packets that failed authentication are discarded and never delivered to upper layers. This mode of operation greatly reduces the chances of successful denial of service attacks, which aim to block the communication of a host or gateway by flooding it with bogus packets. AH can be used in two ways: transport mode and tunnel mode. Original Datagram: Original Datagram Protected by AH in Transport Mode: Original Datagram Protected by AH in Tunnel Mode: Encapsulating Security Payload (ESP) The IP Encapsulating Security Payload provides data confidentiality (encryption), connectionless (that is per-packet) integrity, data origin authentication, and protection against replay. ESP always provides data confidentiality, and can also optionally provide data origin authentication, data integrity checking, and replay protection. Comparing ESP to AH, one sees that only ESP provides encryption, while either can provide authentication, integrity checking, and replay protection. When ESP is used to provide authentication functions, it uses the same algorithms used by the AH protocol. However, the coverage is different. Encryption is selectable independent of the other services. It is highly recommended that if encryption is enabled, then integrity check and authentication be turned on. If only encryption is used, intruders could forge packets in order to mount cryptanalytic attacks. This is infeasible when integrity check and authentication are in place. Although both authentication (with integrity check) and encryption are optional, at least one of them is always selected. Otherwise it really does not make sense to use ESP at all. The format of the ESP packet is more complicated than that of the AH packet. Actually there is not only an ESP header, but also an ESP trailer and ESP authentication data. The payload is located (encapsulated) between the header and the trailer, hence the name of the the protocol. Like AH, ESP can be used in two ways: transport mode and tunnel mode. Original Datagram: Original Datagram Protected by ESP in Transport Mode: Original Datagram Protected by ESP in Tunnel Mode: ESP in transport mode provides neither authentication nor encryption for the IP header. This is a disadvantage, since false packets might be delivered for ESP processing. The advantage of transport mode is the lower processing overhead. As in the case of AH, ESP in transport mode is used by hosts, not gateways. ESP in tunnel mode, the original datagram becomes the payload data for the new ESP packet, its protection is total if both encryption and authentication are selected. Combining the Protocols Either ESP or AH may be applied alone, in combination with the other, or even nested within another instance of itself. With these combinations, authentication and/or encryption can be provided between a pair of communicating hosts, between a pair of communicating firewalls, or between a host and a firewall. Internet Security Association and Key Management Protocol (ISAKMP/Oakley) A security association (SA) contains all the relevant information that communicating systems need in order to execute the IPSec protocols, such as AH or ESP. For example, a security association will identify the cryptographic algorithm to be used, the keying information, the identities of the participating parties, etc. ISAKMP defines a standardized framework to support negotiation of security associations (SA), initial generation of all cryptographic keys, and subsequent refresh of these keys. Oakley is the mandatory key management protocol that is required to be used within the ISAKMP framework. ISAKMP supports automated negotiation of security associations, and automated generation and refresh of cryptographic keys. The ability to perform these functions with little or no manual configuration of machines will be a critical element as a VPN grows in size. Secure exchange of keys is the most critical factor in establishing a secure communications environment no matter how strong your authentication and encryption are, they are worthless if your key is compromised. Since the ISAKMP procedures deal with initializing the keys, they must be capable of running over links where no security can be assumed to exist. That is, they are used to bootstrap the IPSec protocols. Hence, the ISAKMP protocols use the most complex and processor-intensive operations in the IPSec protocol suite. ISAKMP requires that all information exchanges must be both encrypted and authenticated. No one can eavesdrop on the keying material, and the keying material will be exchanged only among authenticated parties. In addition, the ISAKMP methods have been designed with the explicit goals of providing protection against several well-known exposures: Denial-of-Service: The messages are constructed with unique cookies that can be used to quickly identify and reject invalid messages without the need to execute processor-intensive cryptographic operations. Man-in-the-Middle: Protection is provided against the common attacks such as deletion of messages, modification of messages, reflecting messages back to the sender, replaying of old messages, and redirection of messages to unintended recipients. Perfect Forward Secrecy (PFS): Compromise of past keys provides no useful clues for breaking any other key, whether it occurred before or after the compromised key. That is, each refreshed key will be derived without any dependence on predecessor keys. The robustness of any cryptography-based solution depends much more strongly on keeping the keys secret than it does on the actual details of the chosen cryptographic algorithms. Hence, the IETF IPSec Working Group has prescribed a set of extremely robust ISAKMP/Oakley exchange protocols. It uses a 2-phase approach: Phase 1: This set of negotiations establishes a master secret from which all cryptographic keys will subsequently be derived for protecting the users' data traffic. In the most general case, public key cryptography is used to establish an ISAKMP security association between systems, and to establish the keys that will be used to protect the ISAKMP messages that will flow in the subsequent Phase 2 negotiations. Phase 1 is concerned only with establishing the protection suite for the ISAKMP messages themselves, but it does not establish any security associations or keys for protecting user data. In Phase 1, the cryptographic operations are the most processor-intensive but need only be done infrequently, and a single Phase 1 exchange can be used to support multiple subsequent Phase 2 exchanges. As a rule of thumb, Phase 1 negotiations are executed once a day or maybe once a week, while Phase 2 negotiations are executed once every few minutes. Phase 2: Phase 2 exchanges are less complex, since they are used only after the security protection suite negotiated in Phase 1 has been activated. A set of communicating systems negotiate the security associations and keys that will protect user data exchanges. Phase 2 ISAKMP messages are protected by the ISAKMP security association generated in Phase 1. Phase 2 negotiations generally occur more frequently than Phase 1. For example, a typical application of a Phase 2 negotiation is to refresh the cryptographic keys once every two to three minutes. But the ISAKMP protocol offers a solution even when the remote host's IP address is not known in advance. ISAKMP allows a remote host to identify itself by a permanent identifier, such as a name or an e-mail address. The ISAKMP Phase 1 exchanges will then authenticate the remote host'ss permanent identity using public key cryptography: Certificates create a binding between the permanent identifier and a public key. Therefore, ISAKMP's certificate-based Phase 1 message exchanges can authenticate the remote host's permanent identify. Since the ISAKMP messages themselves are carried within IP datagrams, the ISAKMP partner (for example, a firewall or destination host) can associate the remote host's dynamic IP address with its authenticated permanent identity.
7. IPSec Security Associations |
The concept of a Security Association (SA) is fundamental to IPSec. An SA is a one direction logical connection between two IPSec systems, uniquely identified by the following triple: [ Security Parameter Index, IP Destination Address, Security Protocol ] The definition of the members is as follows: Security Parameter Index (SPI) This is a 32-bit value used to identify different SAs with the same destination address and security protocol. The SPI is carried in the header of the security protocol (AH or ESP). The SPI has only local significance, as defined by the creator of the SA. The SPI values in the range 1 to 255 are reserved by the Internet Assigned Numbers Authority (IANA). The SPI value of 0 must be used for local implementation-specific purposes only. Generally the SPI is selected by the destination system during the SA establishment. IP Destination Address This address may be a unicast, broadcast or multicast address. However, currently SA management mechanisms are defined only for unicast addresses. Security Protocol This can be either AH or ESP. Because SAs are in one direction, bidirectional communication between two IPSec systems require two SAs defined, one in each direction. An SA gives security services to the traffic carried by it either by using AH or ESP, but not both. In other words, for a connection that should be protected by both AH and ESP, two SAs must be defined for each direction. In this case, the set of SAs that define the connection is referred to as an SA bundle. The SAs in the bundle do not have to terminate at the same endpoint. For example, a mobile host could use an AH SA between itself and a firewall and a nested ESP SA that extends to a host behind the firewall. An IPSec implementation maintains two databases related to SAs: Security Policy Database (SPD) The Security Policy Database specifies what security services are to be offered to the IP traffic, depending on factors such as source, destination, whether it is inbound, outbound, etc. It contains an ordered list of policy entries, separate for inbound and or outbound traffic. These entries might specify that some traffic must not go through IPSec processing, some must be discarded and the rest must be processed by the IPSec module. Entries in this database are similar to the firewall rules or packet filters. Security Association Database (SAD) The Security Association Database contains parameter information about each SA, such as AH or ESP algorithms and keys, sequence numbers, protocol mode and SA lifetime. For outbound processing, an SPD entry points to an entry in the SAD. That is, the SPD determines which SA is to be used for a given packet. For inbound processing, the SAD is consulted to determine how the packet must be processed. The user interface of an IPSec implementation usually hides or presents in a more friendly way these databases and makes the life of the administrator easier.
8. Tunnel vs. Transport Mode |
As shown above, AH and ESP can be used in both transport mode or tunnel mode, depending on the mode of the protocol in the SA. IPSec's tunnel mode is an encapsulation technique modeled after "IP Encapsulation within IP" (RFC 2003). The key points to keep in mind are: Transport mode is normally used between the end points of a connection. For example, if secure communication is desired along all elements of a path from a client to a server, the client and server would use IPSec's transport mode. Tunnel mode is normally used between two machines when at least one of the machines is not an end point of the connection. For example, if secure communication is desired between two firewalls that are located between a client and a server, the firewalls would use IPSec's tunnel mode between themselves. Or if a remote host dialed in to its home network, it may want a secure path between itself and an entry gateway at its home network. Again, the remote host and the entry gateway would use IPSec's tunnel mode in this situation. Tunneling or encapsulation is a common technique in packet-switched networks. It consists of wrapping a packet in a new one. That is, a new header is attached to the original packet. The entire original packet becomes the payload of the new one. In general tunneling is used to carry traffic of one protocol over a network that does not support that protocol directly. For example, NetBIOS or IPX can be encapsulated in IP to carry it over a TCP/IP WAN link. In the case of IPSec, IP is tunneled through IP for a slightly different purpose: to provide total protection, including the header of the encapsulated packet. If the encapsulated packet is encrypted, an intruder cannot figure out for example the destination address of that packet. The internal structure of a private network can be concealed in this way. Tunneling requires intermediate processing of the original packet on its route. The destination specified in the outer header, usually an IPSec firewall or router, retrieves the original packet and sends it to the ultimate destination. The processing overhead is compensated by the extra security. A notable advantage of IP tunneling is the possibility to exchange packets with private IP addresses between two intranets over the public Internet, which requires globally unique addresses. Since the encapsulated header is not processed by the Internet routers, only the endpoints of the tunnel (the gateways) have to have globally assigned addresses; the hosts in the intranets behind them can be assigned private addresses, for example 10.x.x.x. As globally unique IP addresses are becoming a scarce resource, this interconnection method gains importance. The tunneling was originally designed for Mobile IP, an architecture that allows a mobile host to keep its home IP address even if attached to remote or foreign subnets. The transport mode is used by hosts, not by gateways. Gateways are not even required to support transport mode. The advantage of the transport mode is less processing overhead. The disadvantage is that the mutable fields are not authenticated. The tunnel mode is used whenever either end of a security association is a gateway. Thus, between two firewalls the tunnel mode is always used. Although gateways are supposed to support tunnel mode only, often they can also work in transport mode. This mode is allowed when the gateway acts as a host, that is in cases when traffic is destined to itself. Examples are SNMP commands or ICMP echo requests. In tunnel mode the outer headers' IP addresses does not need to be the same as the inner headers' addresses. For example two security gateways may operate an ESP tunnel which is used to secure all traffic between the networks they connect together. Hosts are not required to support tunnel mode, but often they do. The advantages of the tunnel mode are total protection of the encapsulated IP datagram and the possibility of using private addresses. However, there is an extra processing overhead associated with this mode.
9. IPSec Scenarios |
This section describes four typical IPSec examples (scenarios). The diagrams and text below describe the basic cases. Black circle on diagram means IPSec support. NOTE: The security associations below can be either AH or ESP. The mode (tunnel vs transport) is determined by the nature of the endpoints. For host-to-host SAs, the mode can be either transport or tunnel. Case 1: End-to-End Security Between 2 Hosts. This is the case of providing end-to-end security between 2 hosts across the Internet (or an Intranet). Note that either transport or tunnel mode can be selected by the hosts. Note that there is no requirement to support general nesting, but in transport mode, both AH and ESP can be applied to the packet. In this event, the SA establishment procedure MUST ensure that first ESP, then AH are applied to the packet. Case 2: Simple Virtual Private Network. This case illustrates simple virtual private networks support. Only tunnel mode is required here. Case 3: Case 1 and 2 Combined. This case combines cases 1 and 2, adding end-to-end security between the sending and receiving hosts. It imposes no new requirements on the hosts or security gateways, other than a requirement for a security gateway to be configurable to pass IPsec traffic (including ISAKMP traffic) for hosts behind it. Case 4. Mobile User Accesing Secure Host Behind Firewall. This covers the situation where a remote host (Host 1) uses the Internet to reach an organization's firewall (Gateway 2) and to then gain access to some server or other machine (Host 2). The remote host could be a mobile host (Host 1) dialing up to a local PPP/ARA server on the Internet and then crossing the Internet to the home organization's firewall (Gateway 2), etc. Only tunnel mode is required between Host 1 and Gateway 2. So the choices for the SA between Host 1 and Gateway 2 would be one of the ones in case 2. The choices for the SA between Host 1 and Host 2 would be one of the ones in case 1.
10. IPSec Plugin Interoperability |
InJoy IPSec Plugin supports the following specifications and protocols: SA Types: tunnel and transport mode IPSec protocols: AH (RFC 2402) and ESP (RFC 2406) Policies: authentication, encryption, encryption/authentication AH transforms: HMAC MD5 (RFC 2403) and HMAC SHA (RFC 2404) ESP transforms: DES CBC (RFC 2405) 3DES CBC (RFC 1851) ESP NULL (RFC 2410)(*) Key Exchange: ISAKMP/Oakley (RFC 2412) (*) The InJoy IPSec implementation is not tested for particular use of the ESP NULL encryption, as it is functionally equivalent to using AH and turning off ESP (no encryption, only authentication) which is working well. Our IPSec implementation has been tested with: SSH Communications Security ISAKMP test engine National Institute of Standarts and Technology test engine - IP Security Web Based Interoperability Tester (IPsec-WIT) But based on the protocol specifications, our implementation should also be compatible with these IPSec solutions: F-Secure VPN for Windows (F/X approved) PGP 6.5 Mac and Windows IPSEC Client (F/X approved) IRE Safenet/SoftPK WinNT Client (F/X approved) Nortel Contivity Extranet Switch Notice Nortel uses a propriatary protocol, but according to Nortel, new releases with support of the standard IPSec protocols are pending. Please e-mail support@fx.dk for the latest developments in this area. Cisco Routers Raptor Firewall 5 for Windows NT Xedia Access Point/QVPN Borderware 6.0 and Freegate 1.3 beta TimeStep Permit/Gate (2520) OpenBSD IPSEC FreeBSD IPSEC Linux IPSec implementations (FreeSWAN etc) Not all the above vendors have been tested by F/X Communications, but these vendors are known to offer configurations that are compatibility with Pluto. Please report if you have additional information about compatibility with other vendors. Known limitations and things that have not been implemented yet: The only method for session keys creation is automatic IKE based on preshared secrets There is no ability to change IPSec configuration on-the-fly IPsec handling for ICMP Path MTU Discovery messages is not implemented New features of version 1.30 (requires Pluto 1.1-130 or higher) 1-DES support is added Added aggressive Mode support for IKE negotiations Added support for subnets behind Road Warriors Now possible to choose authentication transform, MD5 or SHA1 Now possible to choose encryption transform, DES and 3DES
11. Plugin Protocol Support Summary |
This section provides a summary of the protocols and the features that the IPSec Plugin provides. SA Types: tunnel mode transport mode ISAKMP SA negotiation methods main mode aggressive mode IPSec protocols: AH (RFC 2402) ESP (RFC 2406) Policies: authentication encryption encryption/authentication authentication/encryption AH transforms: HMAC MD5 (RFC 2403) HMAC SHA (RFC 2404) ESP transforms: 1-DES CBC (RFC 2405) 3-DES CBC NULL-ESP Key Exchange: ISAKMP/Oakley (RFC 2412) Other VPN-related features: firewall compatibility Road Warrior support (dynamic IP addresses) Road Warrior subnet support (network behind RW's) logging alert support
12. More About IPSec |
IP Security Protocol Charter Official status of IPSec project. Drafts, RFCs and other related documents. Virtual Private Networks: An Overview Overview of VPNs by IBM. Using IPSec to construct secure Virtual Private Networks Detailed description of IPSec protocols and IPSec operation.
13. IPSec RFC's |
Legend: S for Standard (fully adopted) D for Draft (initial testing) P for Proposed (entry level) H for Historic General IPsec
RFC 2401 | P | Security Architecture for the Internet Protocol
RFC 2411 |  | IP Security Document Roadmap
RFC 2521 | E | ICMP Security Failures Messages
ESP and AH Headers
RFC 2406 | P | Encapsulating Security Payload (ESP)
RFC 2402 | P | IP Authentication Header
Key Exchange
RFC 2407 | P | Internet IP Security Domain of Interpretation for ISAKMP
RFC 2408 | P | Internet Security Association and Key Management Protocol (ISAKMP)
RFC 2409 | P | Internet Key Exchange (IKE)
RFC 2412 |  | OAKLEY Key Determination Protocol
RFC 2367 |  | PF_KEY Key Management API, Version 2
RFC 2522 | E | Photuris: Session-Key Management Protocol
RFC 2523 | E | Photuris: Extended Schemes and Attributes
Cryptographic Algorithms
RFC 2405 | P | ESP DES-CBC Cipher Algorithm With Explicit IV
RFC 2451 | P | ESP CBC-Mode Cipher Algorithms
RFC 2104 |  | HMAC: Keyed-Hashing for Message Authentication
RFC 2202 |  | Test Cases for HMAC-MD5 and HMAC-SHA-1
RFC 2403 | P | Use of HMAC-MD5-96 within ESP and AH
RFC 2404 | P | Use of HMAC-SHA-1-96 within ESP and AH
RFC 2410 | P | NULL Encryption Algorithm and Its Use With IPsec
RFC 1828 | P | IP Authentication using Keyed MD5 (may be moved to Historic)
RFC 1829 | P | ESP DES-CBC Transform (may be moved to Historic)
RFC 2085 | P | HMAC-MD5 IP Authentication with Replay Prevention
RFC 2393 | P | IP Payload Compression Protocol (IPComp)
RFC 2394 |  | IP Payload Compression Using DEFLATE
RFC 2395 |  | IP Payload Compression Using LZS
Copyright © 1999, 2000, F/X Communications. All rights reserved. InJoy IPSec Plugin is published by F/X Communications webmaster@fx.dk