Re: [IPsec] DPD in IKEv2

Yoav Nir <ynir@checkpoint.com> Sun, 11 July 2010 10:26 UTC

From: Yoav Nir <ynir@checkpoint.com>
To: 'Toby Mao' <yumao9@gmail.com>, IPsecme WG <ipsec@ietf.org>
Date: Sun, 11 Jul 2010 13:27:08 +0300
Thread-Topic: [IPsec] DPD in IKEv2
Thread-Index: Acsg4NvCOFHCFE6xRWa/jbrpsXXkKQAAaRsw
Message-ID: <006FEB08D9C6444AB014105C9AEB133FFE28C51DE8@il-ex01.ad.checkpoint.com>
References: <AANLkTilbxF_NpZbXlZ8KmuwkKGQxz2g6VhYj-xxerCqe@mail.gmail.com>
In-Reply-To: <AANLkTilbxF_NpZbXlZ8KmuwkKGQxz2g6VhYj-xxerCqe@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_006FEB08D9C6444AB014105C9AEB133FFE28C51DE8ilex01adcheck_"
MIME-Version: 1.0
Cc: "maoyu@h3c.com" <maoyu@h3c.com>
Subject: Re: [IPsec] DPD in IKEv2
Precedence: list

Hi.

Liveness check in IKEv2 is very much like any other INFORMATIONAL exchange. Here's what the introduction says about this.

              An INFORMATIONAL request with no payloads (other than the
   empty Encrypted payload required by the syntax) is commonly used as a
   check for liveness.

So you don't need any payloads, and no counters other than the message counter in the IKE header. Also, you are correct that the counter gets synchronized to cluster members, just like following any other IKE message.

Hope this helps

Yoav

________________________________
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Toby Mao
Sent: Sunday, July 11, 2010 1:07 PM
To: IPsecme WG
Cc: maoyu@h3c.com
Subject: [IPsec] DPD in IKEv2

Hi all:
         DPD(RFC 3706) provide a mechanism to detect dead IKEv1 peer.  In  draft-ietf-ipsecme-roadmap-07, 4.2.3.1, it tell us <http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-roadmap/> "This RFC defines an optional extension to IKEv1; dead peer detection (DPD) is an integral part of IKEv2, which refers to this feature as a "liveness check" or "liveness test"."  So we can learn DPD can be used in IKEv2. However,  some issues need to discuss when used in IKEv2.

         #1:  Sequence Number in DPD Message
        In rfc3706, sequence number in DPD message can prove liveliness and guard against message replay attack, it is presented in the notification data field in the Notify Payload format. However, Message ID in the IKEv2 can provide the same function(see WG draft draft-ietf-ipsecme-ikev2bis<http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ikev2bis/> 2.2). If DPD is used in IKEv2, DPD notify message can use Message ID in the IKEv2 message header other than define the other redundancy sequence number in the notification data field. Furthermore,  another WG draft  draft-ietf-ipsecme-ipsec-ha<http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ipsec-ha/>  define SADB information to be synchronized in the clusters. If DPD use its unique sequence number , the number should also be synched as IKE SA counters.

         #2:   Message Type
      RFC3706 define DPD  Message  as below:

     Notify                          Message Value

      R-U-THERE                   36136

      R-U-THERE-ACK           36137








      But I do not see these definition in draft-ietf-ipsecme-ikev2bis<http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ikev2bis/> or http://www.iana.org/assignments/ikev2-parameters.








   So,  should we udpate RFC 3706 or make a detailed description in draft-ietf-ipsecme-ikev2bis<http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ikev2bis/>?