Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)

Raj Singh <> Mon, 29 March 2010 13:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D41123A6A5C for <>; Mon, 29 Mar 2010 06:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.021
X-Spam-Status: No, score=0.021 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iuRr6+Ft+8Xz for <>; Mon, 29 Mar 2010 06:58:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 22E4A3A6A1A for <>; Mon, 29 Mar 2010 06:58:01 -0700 (PDT)
Received: by gxk9 with SMTP id 9so1590257gxk.8 for <>; Mon, 29 Mar 2010 06:58:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=e7PJgsblF9l4tsKX62/t4rL/KwFeYCsmuG65Nysu6gM=; b=uGgJVYCeHvQkTwYHHERHM9D/CdgmfyG3O2HC8XDzYRtatAyy0NCemtpv4LYJc4I+2X UID/zds5N+JTLU1CEDgRhIBG6q2KvhQuYJNZMPMfURzi5B1zZ6R0S+jTaUXkAgj/8Umb nJ8gyIcIjxNQJu+uDl1NHBUZfnzYsD2Ab9Tng=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sPbf2JjjJz8kU/pTS9etHixvn5ZPJTjv+M7DZkvCx3f5rc489PgqhdegJIDyPgdJcj /o8LapCDB+3W7hlONV7hOYC69py5WvMFyBbvz9gGRA/X8oYEPQjtVzd5pdDdsXEhelEx gYE6vAL7pKSUPdTnn0F/irt1VOJppnaMdGiVU=
MIME-Version: 1.0
Received: by with HTTP; Mon, 29 Mar 2010 06:58:24 -0700 (PDT)
In-Reply-To: <p06240806c7d51823a16f@>
References: <015701cacc74$9b0f3c20$d12db460$> <018001cacd04$d59efc50$80dcf4f0$> <> <001001cacdd7$557f0190$007d04b0$> <> <001801cace41$98e87e10$cab97a30$> <> <000301cace6f$24b23170$6e169450$> <> <p06240806c7d51823a16f@>
Date: Mon, 29 Mar 2010 19:28:24 +0530
Received: by with SMTP id 32mr1427202agd.25.1269871104662; Mon, 29 Mar 2010 06:58:24 -0700 (PDT)
Message-ID: <>
From: Raj Singh <>
To: Paul Hoffman <>
Content-Type: multipart/alternative; boundary=0016363105b71a9c6e0482f0e8e2
Cc: ipsec <>
Subject: Re: [IPsec] New PAKE Criteria draft posted (def. of gateway)
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Mar 2010 13:58:10 -0000

Hi Team,

The similar scenarios are beautifully handled by Redirect RFC-5685.
The Redirect RFC emphasize on client-gateway terminology, which is typical
use of Redirect mechanism in IKEv2 where Gateway redirects client to another
less loaded gateway but at the same time RFC is also applicable to
router-router scenario when one router decides to off-load all existing
IKEv2 sessions to another gateway when it goes down for maintenance etc.
I totally agree with Paul.

Best regards,

On Sun, Mar 28, 2010 at 8:09 PM, Paul Hoffman <> wrote:

> <wg-co-chair-hat on>
> The disagreement between Dan and Yaron is over wording in the not-at-all
> normative criteria draft. This draft is not intended to become an RFC, and
> is not binding on the WG. It currently is being edited by Yaron; soon it
> will be edited by both Yaron and Dan.
> From the active thread the past few days, it seems that Dan disagrees with
> Yaron's view that people thinking about the PAKE primarily as a
> gateway-to-gateway solution. That's fine: others in the WG might take one
> view or the other. I ask that Dan and Yaron produce an -03 with both views
> in it. I note that the current WG charter does not insist that the PAKE we
> choose be for gateway-to-gateway, but that it does list "authentication
> between two servers or routers" as a motivating scenario, and does not list
> remote access as a motivating scenario for the proposed new work.
> As WG members consider which criteria are important to them, they should
> also consider what scenarios we want to emphasize in the eventual document.
> I use the word "emphasize" here because we cannot prevent implementers and
> administrators from using the new authentication mechanism however they
> want; we have plenty of experience with IKE and IPsec documents saying "you
> should use this in that way" that are merrily ignored by large parts of the
> market.
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> IPsec mailing list