Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 21 March 2019 08:02 UTC

Return-Path: <smyslov.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2675913103B for <ipsec@ietfa.amsl.com>; Thu, 21 Mar 2019 01:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-ezXpOaWUxI for <ipsec@ietfa.amsl.com>; Thu, 21 Mar 2019 01:02:10 -0700 (PDT)
Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F951130F82 for <ipsec@ietf.org>; Thu, 21 Mar 2019 01:02:10 -0700 (PDT)
Received: by mail-wr1-x42b.google.com with SMTP id p10so5518027wrq.1 for <ipsec@ietf.org>; Thu, 21 Mar 2019 01:02:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=uU4HOfCxEkyAQ4rOcxZ9E9v3ATvhHFyiiB2CsEnKvwE=; b=RFRV5W62WyQo3aSI6yu1KH63JXQCLNNiSqLhGDdrUGMC6ii4r9iwncJDbxV2gK4xyO Pt4Mw1jrVtnyC6gsxT6DUY9/7DmDVOq/LCAsckz2iZ/KnEq1y6dX7o3pBWM+lZBNnTkK W+c07eQdf2r0PajYFX+lKVQinPH7T/VXA86KpnaECPiyfdf+TkVdZb1sCnPQ30qmpMyH gCJx2eYMmTdIMbSGfLnuyfs52P/enZmgRbn3Sl0aPtVh0nFPq91rlMaVoHOGXvYHHdwc Nd0u/t8mo+gcZtXbq7/OIpqG6yn+yI4hHNJm7kSq6HbC42ZIS2GFwc+LFknOcu6KxKAa NZBg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=uU4HOfCxEkyAQ4rOcxZ9E9v3ATvhHFyiiB2CsEnKvwE=; b=HJHuTkeqDXpb7cROyoqHq1svFz1eiWXJhzzAoQUj0XlR+8c57He5mChj0NcMMCgZGt watHhVfcZKiI+r3zOMmqwYUpMvLRr1IpGVomZC2UxsQzLCwilx7k1huiidikdIxjGrjJ 7ZKcWYruMINcMOXtFtnVnBlqLrvQ8re8Q5fDZivIMTel6oPOo+WoFVLT+Wx/u+pF09yQ T+mDGN2S48yS2morVni2b/fe7P/IAOGS05kBR1GMqf4823Uae9RKBwUg94q1KYp+j1EK ZHguh6isKcfs1nErXSG6ENDAT1mGqJQz7aKFMxiozVlDcgSYgAMSJEwY9vQheWDjTjLD Q+Hg==
X-Gm-Message-State: APjAAAW+MU4GcnXq0C+lbBGM3bl7QpNZOBFRJ0RSKCuvxHZAJEQB+CLk x1QSZnO6id2SIqqPSwo1wcE=
X-Google-Smtp-Source: APXvYqySMGWjtwMjVsRmdDR7URJTx+hkgROxm7trGsvIuHmYtMC43VTdTnlmhDxICGz/JPjFWw492g==
X-Received: by 2002:adf:dd4a:: with SMTP id u10mr1625857wrm.322.1553155328627; Thu, 21 Mar 2019 01:02:08 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g10sm3204973wrq.61.2019.03.21.01.02.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Mar 2019 01:02:07 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tobias Heider' <heidert@cip.ifi.lmu.de>, 'Tobias Guggemos' <guggemos@nm.ifi.lmu.de>, 'Tero Kivinen' <kivinen@iki.fi>, ipsec@ietf.org
References: <23688.31062.426962.985107@fireball.acr.fi> <01c701d4da41$3c61f890$b525e9b0$@gmail.com> <6454f07af680410e918431971f3489f2@XCH-ALN-010.cisco.com> <001e01d4ddac$5502d770$ff088650$@nm.ifi.lmu.de> <059301d4de2d$faa5a000$eff0e000$@gmail.com> <000a01d4de79$31d3cc00$957b6400$@nm.ifi.lmu.de> <06b701d4deed$706f1310$514d3930$@gmail.com> <a1bc12d7-7c8c-cd12-f0fa-cb6bd9bb7265@cip.ifi.lmu.de>
In-Reply-To: <a1bc12d7-7c8c-cd12-f0fa-cb6bd9bb7265@cip.ifi.lmu.de>
Date: Thu, 21 Mar 2019 11:02:04 +0300
Message-ID: <077301d4dfbc$60031f10$20095d30$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUAMGThUEAw641ZkCdcCrbQH6yHdxpTKaF/A=
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/hCM9JsVaNbdIje9FIo9wHqeqtfc>
Subject: Re: [IPsec] WG adoptation call for draft-smyslov-ipsecme-ikev2-aux-02
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Thu, 21 Mar 2019 08:02:17 -0000

Hi Tobias,

> Hi Valery,
> 
> >> If there is a chance that this is a potential thread (and I fear it'll be impossible to proof the opposite), my
> >> feeling is that the document should say that IKE_INTERMEDIATE MUST NOT be supported without the
> >> support of at least one document defining the payload.
> > That is implied. I can make this more explicit, by adding something like that:
> >
> > Successful exchange of INTERMEDIATE_EXCHANGE_SUPPORTED
> > notification only confirms that both parties support INTERMEDIATE
> > exchange. It is not enough condition to start doing INTERMEDIATE exchange.
> > A separate documents that utilize this exchange MUST define
> > the conditions in which peers would do INTERMEDIATE exchanges,
> > the conditions for ending the sequence of these exchanges and start IKE_AUTH,
> > and the payloads these exchanges should carry.
> >
> > Is it OK for you?
> I was wondering about what happens when multiple documents utilize the
> IKE_INTERMEDIATE exchange
> at the same time.
> Can two different documents utilize a single exchange of
> IKE_INTERMEDIATE messages,
> or must every document add an additional exchange of IKE_INTERMEDIATE
> messages?

It's a good question. My idea is that each application document
must define this, as well as the order of INTERMEDIATE exchanges,
if it matters. So, I assume that by default each application
will utilize its own INTERMEDIATE , but some applications could
benefit from piggybacking. But this must be clearly described
in corresponding document.

> Currently the only "user" is the Hybrid PQKE draft which adds up to
> seven INTERMEDIATE exchanges before the IKE_AUTH,
> could i just define a draft that includes an additional payload in the
> first INTERMEDIATE exchange (not knowing whether Hybrid KE is used or not)
> or would i have to add an eighth INTERMEDIATE exchange?

I think that corresponding application document must define this.
QSKE exchanges would most probably take place before any other 
INTERMEDIATE exchange, since they update the keys and increase
IKE SA protection, but again, it must be defined in the application
documents.

> I couldn't find any info on this in the current draft and i feel like
> this is quite relevant for future users of the exchange.

I don't think it must be defined in this draft. Instead, it must be
defined in the documents utilizing this exchange. Note, that 
these documents will appear one by one, so every next published 
document must have a section describing how this application
of INTERMEDIATE should deal with the already defined
applications (whether it is OK to combine payloads or not,
what is the relative order etc.)

Regards,
Valery.

> Regards,
> (another) Tobias