Re: [IPsec] DPD in IKEv2

Toby Mao <yumao9@gmail.com> Sun, 11 July 2010 15:46 UTC

Return-Path: <yumao9@gmail.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FA603A69BB for <ipsec@core3.amsl.com>; Sun, 11 Jul 2010 08:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_83=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PknePvHs5Y-x for <ipsec@core3.amsl.com>; Sun, 11 Jul 2010 08:46:15 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 4971C3A69B9 for <ipsec@ietf.org>; Sun, 11 Jul 2010 08:46:15 -0700 (PDT)
Received: by qwe5 with SMTP id 5so1212891qwe.31 for <ipsec@ietf.org>; Sun, 11 Jul 2010 08:46:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Tk+pWWRp71GWgr3BsRpmfYljLNpX5ZFIH2igUdcRM0A=; b=XgxLOdR5joyVWRGLDzViv5A1yTpgwQ40aEDoX3Z+8/YVy+G7NbJLy2yq4o3XQZmDfg oPxYzgzSpyJ7n7V1D2f37MENWfJaDUJUB0WHMgHvI//PKQUvhS35bEmdU2nLeryPL0hc GINUzjN+pJzJ3v2TOZOWw8Y/9zdZxLWTNwzkU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Kqoqfe3+Ya9V5PQKmauD/h34OajUnoKmF2plPlywqRm8uZ84sBLq7VSM/041Sdr897 otmFArJ9p7yPV5WMK9O9Ya5VFno6GSUlE3cspfjA1EQnQVY+bEsfx8f9XeJndE65vpTI dGzPIC4nqm0UD0RROgopsuGQjq9oMwYO9a+5w=
MIME-Version: 1.0
Received: by 10.224.54.131 with SMTP id q3mr7130205qag.183.1278863178793; Sun, 11 Jul 2010 08:46:18 -0700 (PDT)
Received: by 10.229.78.98 with HTTP; Sun, 11 Jul 2010 08:46:18 -0700 (PDT)
In-Reply-To: <006FEB08D9C6444AB014105C9AEB133FFE28C51DE8@il-ex01.ad.checkpoint.com>
References: <AANLkTilbxF_NpZbXlZ8KmuwkKGQxz2g6VhYj-xxerCqe@mail.gmail.com> <006FEB08D9C6444AB014105C9AEB133FFE28C51DE8@il-ex01.ad.checkpoint.com>
Date: Sun, 11 Jul 2010 23:46:18 +0800
Message-ID: <AANLkTikPX5rm_0Ww0qV5UWoo8ZpUS4X2j1EPT8KsLVV1@mail.gmail.com>
From: Toby Mao <yumao9@gmail.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: multipart/alternative; boundary="0015175cf7b67d07a1048b1e8949"
Cc: IPsecme WG <ipsec@ietf.org>, "maoyu@h3c.com" <maoyu@h3c.com>
Subject: Re: [IPsec] DPD in IKEv2
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 11 Jul 2010 15:46:17 -0000

Hi Yoav:

      Thanks for your explanation.
      So, if we want to check liveliness,  an Informational request message
without payloads will be send and an Informational response message without
payloads can prove the peer's liveliness.

Best
  Toby


On Sun, Jul 11, 2010 at 6:27 PM, Yoav Nir <ynir@checkpoint.com> wrote:

>  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/>?
>
>
>