INTERNET DRAFT Vlado D. Zafirov Category: Standards Track RADWare, Inc. Title: draft-vlado-ipsec-keep-alive-01.txt Date: June 2000 Internet Security Association and Key Management Protocol (ISAKMP) Keep-Alive Message exchange Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Copyright (C) The Internet Society 1999. All Rights Reserved. Zafirov, Vlado expires December 2000 [Page 1] INTERNET DRAFT June 2000 Abstract This memo describes a protocol utilizing ISAKMP protocol necessary for checking status of specific Ipsec tunnel. Table of Contents 1. Introduction 1.1. Why Keep-Alive message exchange is necessary 1.2. The Problem 1.3. The Solution 2. Implementing Keep-Alive message exchange 3. References 4. Authors' Addresses Zafirov, Vlado expires December 2000 [Page 2] INTERNET DRAFT June 2000 1. Introduction This memo describes a protocol utilizing ISAKMP protocol necessary for checking status of specific Ipsec tunnel. 1.1. Why Keep-Alive message exchange is necessary Keep-Alive message exchange is a necessary mechanism to detect if certain SA Tunnel is alive. This will allow load balancing and high-availability between Secure gateways without implementing key sharing between these implementations. This protocol MUST be used only with ESP and AH protocols working in tunnel mode. 1.2. The Problem (Active) +-------+ | SGW 1 | +-------+ +-------+------- Internet -------- | SGW 3 | +-------+-------/ +-------+ | SGW 2 | +-------+ (Backup) SGW = Secure Gateway Figure 1 Suppose SGW 3 already have SA with the SGW 1 which is the active at that moment. When SGW 1 goes down SGW 2 usually in load balanced/HA situation backup is taking over the IP of the active one. SGW 3 doesn't know that SGW 1 is dead so he continue to send ESP or AH packets to the other side. Backup SGW doesn't know how to decrypt these packets since he doesn't have the key and doesn't know that SPI #. SGW 3 could be client (end-point or mobile client) too. 1.3. Solution Implementing Keep-Alive exchanges between SGW will solve the problem. When Keep-Alive exchange fails SGW MUST destroy that SA and start new Phase 1 negotiation. 2. Implementing Keep-Alive message exchange An ISAKMP message has a fixed header format, shown in Figure 2, followed by a variable number of payloads. A fixed header simplifies parsing, providing the benefit of protocol parsing software that is less complex and easier to implement. The fixed header contains the information required by the protocol to maintain state, process payloads and possibly prevent denial of service or replay attacks. Zafirov, Vlado expires December 2000 [Page 3] INTERNET DRAFT June 2000 The ISAKMP Header fields are defined as follows: o Initiator Cookie (8 octets) - Cookie of entity that initiated SA establishment, SA notification, or SA deletion. o Responder Cookie (8 octets) - Cookie of entity that is responding to an SA establishment request, SA notification, or SA deletion. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Initiator ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Responder ! ! Cookie ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! MjVer ! MnVer ! Exchange Type ! Flags ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Message ID ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: ISAKMP Header Format o Next Payload (1 octet) - Indicates the type of the first payload in the message. The format for each payload is defined in sections 3.4 through 3.16. The processing for the payloads is defined in section 5. Next Payload Type Value NONE 0 Security Association (SA) 1 Proposal (P) 2 Transform (T) 3 Key Exchange (KE) 4 Identification (ID) 5 Certificate (CERT) 6 Certificate Request (CR) 7 Hash (HASH) 8 Signature (SIG) 9 Nonce (NONCE) 10 Notification (N) 11 Delete (D) 12 Vendor ID (VID) 13 RESERVED 14 - 127 Private USE 128 - 255 Zafirov, Vlado expires December 2000 [Page 4] INTERNET DRAFT June 2000 o Major Version (4 bits) - indicates the major version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Major Version to 1. Implementations based on previous versions of ISAKMP Internet- Drafts MUST set the Major Version to 0. Implementations SHOULD never accept packets with a major version number larger than its own. o Minor Version (4 bits) - indicates the minor version of the ISAKMP protocol in use. Implementations based on this version of the ISAKMP Internet-Draft MUST set the Minor Version to 0. Implementations based on previous versions of ISAKMP Internet- Drafts MUST set the Minor Version to 1. Implementations SHOULD never accept packets with a minor version number larger than its own, given the major version numbers are identical. o Exchange Type (1 octet) - indicates the type of exchange being used. This dictates the message and payload orderings in the ISAKMP exchanges. Exchange Type Value NONE 0 Base 1 Identity Protection 2 Authentication Only 3 Aggressive 4 Informational 5 ISAKMP Future Use 6 - 31 DOI Specific Use 32 - 239 Private Use 240 - 255 o Flags (1 octet) - indicates specific options that are set for the ISAKMP exchange. The flags listed below are specified in the Flags field beginning with the least significant bit, i.e the Encryption bit is bit 0 of the Flags field, the Commit bit is bit 1 of the Flags field, and the Authentication Only bit is bit 2 of the Flags field. The remaining bits of the Flags field MUST be set to 0 prior to transmission. -- E(ncryption Bit) (1 bit) - If set (1), all payloads following the header are encrypted using the encryption algorithm identified in the ISAKMP SA. The ISAKMP SA Identifier is the combination of the initiator and responder cookie. It is RECOMMENDED that encryption of communications be done as soon as possible between the peers. For all ISAKMP exchanges described in section 4.1, the encryption SHOULD begin after both parties have exchanged Key Exchange payloads. If the E(ncryption Bit) is not set (0), the payloads are not encrypted. Zafirov, Vlado expires December 2000 [Page 5] INTERNET DRAFT June 2000 -- C(ommit Bit) (1 bit) - This bit is used to signal key exchange synchronization. It is used to ensure that encrypted material is not received prior to completion of the SA establishment. The Commit Bit can be set (at anytime) by either party participating in the SA establishment, and can be used during both phases of an ISAKMP SA establishment. However, the value MUST be reset after the Phase 1 negotiation. If set(1), the entity which did not set the Commit Bit MUST wait for an Informational Exchange containing a Notify payload (with the CONNECTED Notify Message) from the entity which set the Commit Bit. In this instance, the Message ID field of the Informational Exchange MUST contain the Message ID of the original ISAKMP Phase 2 SA negotiation. This is done to ensure that the Informational Exchange with the CONNECTED Notify Message can be associated with the correct Phase 2 SA. The receipt and processing of the Informational Exchange indicates that the SA establishment was successful and either entity can now proceed with encrypted traffic communication. In addition to synchronizing key exchange, the Commit Bit can be used to protect against loss of transmissions over unreliable networks and guard against the need for multiple re-transmissions. NOTE: It is always possible that the final message of an exchange can be lost. In this case, the entity expecting to receive the final message of an exchange would receive the Phase 2 SA negotiation message following a Phase 1 exchange or encrypted traffic following a Phase 2 exchange. Handling of this situation is not standardized, but we propose the following possibilities. If the entity awaiting the Informational Exchange can verify the received message (i.e. Phase 2 SA negotiation message or encrypted traffic), then they MAY consider the SA was established and continue processing. The other option is to retransmit the last ISAKMP message to force the other entity to retransmit the final message. This suggests that implementations may consider retaining the last message (locally) until they are sure the SA is established. -- A(uthentication Only Bit) (1 bit) - This bit is intended for use with the Informational Exchange with a Notify payload and will allow the transmission of information with integrity checking, but no encryption (e.g. "emergency mode"). Section 4.8 states that a Phase 2 Informational Exchange MUST be sent under the protection of an ISAKMP SA. This is the only exception to that policy. If the Authentication Only bit is set (1), only authentication security services will be applied to the entire Notify payload of the Informational Exchange and the payload will not be encrypted. Zafirov, Vlado expires December 2000 [Page 6] INTERNET DRAFT June 2000 o Message ID (4 octets) - Unique Message Identifier used to identify protocol state during Phase 2 negotiations. This value is randomly generated by the initiator of the Phase 2 negotiation. In the event of simultaneous SA establishments (i.e. collisions), the value of this field will likely be different because they are independently generated and, thus, two security associations will progress toward establishment. However, it is unlikely there will be absolute simultaneous establishments. During Phase 1 negotiations, the value MUST be set to 0. o Length (4 octets) - Length of total message (header + payloads) in octets. Encryption can expand the size of an ISAKMP message. This exchange will use exchange ID of 250. It MUST take place only when ESP and AH are used in tunnel mode. It MUST be used only after successful Phase 2 exchange is finished. HDR is an ISAKMP header whose exchange type defines the payload orderings '*' signifies payload encryption after the ISAKMP header. This encryption MUST begin immediately after the ISAKMP header and all payloads following the ISAKMP header MUST be encrypted. => signifies "initiator to responder" communication <= signifies "responder to initiator" communication # Initiator Direction Responder NOTE (1) HDR* => Keep-Alive request (2) HDR* <= Keep-Alive reply All exchanges are similar in that with the beginning of any exchange, cryptographic synchronization MUST occur. The Keep-Alive Exchange is an exchange and not an ISAKMP message. Thus, the generation of an Message ID (MID) for an Informational Exchange SHOULD be independent of IVs of other on-going communication. This will ensure cryptographic synchronization is maintained for existing communications and the Informational Exchange will be processed correctly. The software implementation supporting keep-alive exchange MUST send keep-alive packet immediately. If other end responds with Informational message UNSUPPORTED-EXCHANGE-TYPE or INVALID-EXCHANGE-TYPE that means it doesn't support keep-alive. In that case no more keep-alive exchanges should occur. The software implementation SHOULD monitor incoming traffic and only when there is no traffic for the time set for keep-alive messages or user-defined time keep-alive exchange should occur thus reducing keep-alive messages to minimum. The software implementation MUST define API interface trough which frequensity and number of retries of this exchage is specified. Suggested default frequensity value is 10 seconds and number of retries is 5 times. This gives a 50 sec period trough which reply SHOULD be received. If reply is NOT received during that period of time implementation MUST delete that SA. When next packet arrives for this tunnel it should trigger new Phase 1 negotiation. Zafirov, Vlado expires December 2000 [Page 7] INTERNET DRAFT June 2000 3. References RFC2408 Internet Security Association and Key Management Protocol (ISAKMP) 4. Authors' Addresses Vlado Zafirov RADWare, Inc. 2012 Tunlaw Rd. NW Washington, DC 20007 Phone: (202) 625-1505 E-Mail: vladoz@radware.com