Internet DRAFT - draft-hwang-ipsec-spiping
draft-hwang-ipsec-spiping
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 type is 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 it send SPI-PING request message to
doubtful IPSEC gateway 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 sends 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
perpormances of the other gateways.
If initiator doesnot receive SPI-PING reply message at interval, he
SHOULD log it and try again. Failure of receving SPI-PING repeats
a few times(MAY be 2 or 3 times), initiator concludes that there is a
problem and negotiates SAs again.
5-1. Responder
Any node which receives an SPI-PING request MAY log it. After receive
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 reqest and
reply message. So It is possible to control rate of incoming SPI-PING
packet.
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]
