Yong.S. Hwang Internet Draft Jong.M. Lee Document: draft-hwang-ipsec-spiping-00.txt SIGn, Inc. Expires: September 14 2003 March 13. 2003 SPI-Based health checking mechanism for IPSEC. 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. Abstract This document describes a diagnostic protocol for unexpected failures between IPSEC gateways. The method covers two parts as IKE[1] consists of two phases. One is echo request/reply message between two IPSEC gateways to confirm health of IKE peer and the other is exchanging of IPSEC-SA SPI to assure exact state of IPSEC-SA. Two new Notification Payload message types are defined, SPI-PING-REQUEST and SPI-PING-REPLY. Yong.S. Hwang Expires September 13, 2003 [Page 1] Internet-Draft spiping March 2003 1. Introduction When two IPSEC gateways negotiate or use IKE[1] and IPSEC[2], unexpected problems may arise. For example, packets do not get through due to firewalls, network address translators, routing problems, etc. In such cases, there is no way for IKE and IPSEC to identify the loss of peer connectivity and all outgoing packets through such abnormal SAs cannot be delivered until the bad situtiation is recovered. Therefore it is very important to detect dead peers as soon as possible. In order to check peer IPSEC gateway's health, simple echo request/reply message through IKE-SA(SA established in PHASE 1) between gateways is not enough. It only checks health of IKE-SA and doesnot know about IPSEC-SA(SA established in PHASE 1). For example, subnet misconfiguration, one of the simple and often happening mistake, lead to success of IKE-SA negotiation and failure of IPSEC-SA negotiation. In this case, simple echo request/reply will succeed, but traffic through IPSEC-SA cannot be achieved. To validate IPSEC-SA, they SHOULD exchange SPI of IPSEC-SA. This scheme, called SPI-PING, relies on IKE Notify messages to query the liveliness of an IKE peer. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [3]. Yong.S. Hwang Expires September 13, 2003 [Page 2] Internet-Draft spiping March 2003 3. Message Exchanges The SPI-PING exchange is a bidirectional (REQUEST/REPLY) Notify message. The exchange is defined as: Sender Responder -------- ----------- HDR*, NOTIFY(SPI-PING -REQUEST),HASH ------> <------ HDR*, NOTIFY(SPI-PING -REPLY), HASH This document proposes a new ISAKMP Notify message types. These would be: Notify Message Value SPI-PING-REQUEST 36969 SPI-PING-REPLY 36970 An entity MUST reject unencrypted SPI-PING-REQUEST and SPI-PING-REPLY messages. 4. NOTIFY(SPI-PING-REQUEST/SPI-PING-REPLY) Message Format The SPI-PING exchange message MUST follow this form: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Domain of Interpretation (DOI) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol-ID ! SPI Size ! Notify Message Type ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Security Parameter Index (SPI) ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ Notification Data ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Next Payload (1 octet) - MUST be set to 0. - Domain of Interpretation (4 octets) - SHOULD be set to IPSEC-DOI. - Protocol ID (1 octet) - MUST be set to the protocol ID for ISAKMP. Yong.S. Hwang Expires September 13, 2003 [Page 3] Internet-Draft spiping March 2003 - SPI Size (1 octets) - SHOULD be set to sixteen (16), the length of two octet-sized ISAKMP cookies. - Notify Message Type (2 octets) - MUST be set to SPI-PING-REQUEST or SPI-PING-REPLY - Security Parameter Index (16 octets) - SHOULD be set to the cookies of the Initiator and Responder of the IPSEC-SA (in that order) - Notification Data (4 octets) - RESERVED 5. Implementation Suggestion There is an issue about a execution time of SPI-PING protocol. It MAY operate at regular intervals or only at suspicious status. but it is RECOMMENDED that an application, which is for interpreting the current packet flow, runs and sends SPI-PING request message to doubtful IPSEC gateways at need. An implementation of the failure-detecting application is beyond the scope of this document. 5-1. Initiator Any node which is to send SPI-PING request message MAY log it. After sending SPI-PING request message, the initiator MUST wait for arriving SPI-PING reply message until configured interval expires. The value of interval depends on the network environment and performances of the other gateways. If initiator does not receive SPI-PING reply message in interval, he SHOULD log it and try SPI-PING request again. After repeating failure of receiving SPI-PING reply a few times(MAY be 2 or 3 times), initiator concludes that there is a problem in the gateway. Then initiator deletes old SAs and negotiates SAs again. 5-1. Responder Any node which receives an SPI-PING request MAY log it. After receiving SPI-PING request message, the responder MUST send SPI-PING reply message immediately. Repeated requests at one interval from the same originator SHOULD be dropped to prevent unnessary processing. Yong.S. Hwang Expires September 13, 2003 [Page 4] Internet-Draft spiping March 2003 6. Security Considerations There is a concern that this protocol may be weak to distributed denial attacks. But SPI-PING protocol is based on pair of request and reply message. So It is possible to control rate of incoming SPI-PING packets. Yong.S. Hwang Expires September 13, 2003 [Page 5] Internet-Draft spiping March 2003 7. References [1] RFC 2409 Harkins, D. and Carrel, D., "The Internet Key Exchange (IKE)," November 1998. [2] RFC 2401 Kent, S. and Atkinson, R., "Security Architecture for the Internet Protocol," November 1998. [3] RFC 2119 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," BCP 14, RFC 2119, March 1997. 8. Author's Addresses Yong Soo. Hwang SIGn, Inc. 3/4F, Ildong Pharmaceutical Bldg., 60 Yangjae-Dong, Seocho-Gu Seoul-Korea, 137-733 Email: rono@sig-n.com Jong Moon. Lee SIGn, Inc. 3/4F, Ildong Pharmaceutical Bldg., 60 Yangjae-Dong, Seocho-Gu Seoul-Korea, 137-733 Email: moon7733@sig-n.com Yong.S. Hwang Expires September 13, 2003 [Page 6]