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]