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

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 21 March 2019 11:37 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 9E8B0128661 for <ipsec@ietfa.amsl.com>; Thu, 21 Mar 2019 04:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.499
X-Spam-Level:
X-Spam-Status: No, score=-0.499 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, URIBL_BLOCKED=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 It2qQBSQHKVA for <ipsec@ietfa.amsl.com>; Thu, 21 Mar 2019 04:37:08 -0700 (PDT)
Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 ADD81127964 for <ipsec@ietf.org>; Thu, 21 Mar 2019 04:37:07 -0700 (PDT)
Received: by mail-wm1-x335.google.com with SMTP id z11so2383157wmi.0 for <ipsec@ietf.org>; Thu, 21 Mar 2019 04:37:07 -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=8o1+G0L9a5Kv+urnwU1u1ZNalqEsav9SPT6EA32TNLA=; b=t3T2aKaAFa3nnAj9izAJNFzqn4lL2aDRmz1WkrRQOP1uStHMMBXbiKRK4HSfVtEOLE ijjsNIOQ1iCzFOEv5fNXQxVtcdbj+saBXJjpHV7185ZrJCeB6xUbpQVl2ucgBnvmFfPH KMm0oXWcjBGGBkPXsmZF5D5w1uOkJcfJO8wKJgGi7MfsoczsPJVOJpsob1TGDmLywHrv fa5b6AKzjJtmWIBwzOw+l//qCGVJ38pr+BO0duT8wUve9UQuZIsNqH7wR8do920KgOYI miMooTyeBqitQf/qHUTLh3SDotOa3vU7FEyMm0QuznPi4snbIv1Yp0WRH4d015qm4PVT Lryg==
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=8o1+G0L9a5Kv+urnwU1u1ZNalqEsav9SPT6EA32TNLA=; b=cLZFZWBf5ZjtRZs8WyAkBtJ2fW8fUBDgoxQvoDcBY4T6JVloR1OKMitV+R6sQC7lUk lC0hPK8zLGqxVxhw6Hy/VpuMQnsf5Etb8urUecycpfglAlZUOZv2FgETzzTWTcAFqPts PZWMGARabJ5vbvNinE5yhcBk+RwONNJXGyqJUeaovIu13byGwdF78whw0x7t664Sb3wW DHSTWYBgwU44IaDNvA92F3mjTgqOInOv23WIMgM09pcYi61DHVRPLyAvKTMgKiGuxU1Q rUqb7ZCngcv7PrjijrBCWJBrOsgsnNdecs5wFoKrhqxpb8ntzI0UuEIONC9gFePhbN82 ev5A==
X-Gm-Message-State: APjAAAXfoVKp0k9c40gRFlk35i2nC8fkoyoBKO0E5JW93g/r0EvvIDqB /dfxRUjHpU3OaUHzyhsz+oNnYSMe
X-Google-Smtp-Source: APXvYqxM51wvVqf2VgTA58rkBS+vqF52y0yPOTqI3NHVdBrWOZwJk9owQlT6LKG7S80+BwDeqFcF8w==
X-Received: by 2002:a1c:7918:: with SMTP id l24mr1988121wme.29.1553168225764; Thu, 21 Mar 2019 04:37:05 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q19sm5957251wmq.23.2019.03.21.04.37.03 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Mar 2019 04:37:04 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Paul Wouters' <paul@nohats.ca>, 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> <077301d4dfbc$60031f10$20095d30$@gmail.com> <alpine.LRH.2.21.1903210506180.7783@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.21.1903210506180.7783@bofh.nohats.ca>
Date: Thu, 21 Mar 2019 14:37:01 +0300
Message-ID: <079d01d4dfda$67159800$3540c800$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQICh2VSFjkuY0eSQrYh6iGxPAV2+AHuWDWOAmpINo8CGcLbUAMGThUEAw641ZkCdcCrbQH6yHdxAYDYIUoBRdt7SqUcrbfw
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/HDWdb8GC8wTo-Mz9z7ui4uzOyzo>
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 11:37:10 -0000

Hi Paul,

> > 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.
> 
> I would think it quite differently. Each protocol extension just puts
> payloads in the IKE_SA_INIT and once that one becomes too big, the
> IKE daemon starts to split it up in an IKE_SA_INIT and IKE_INTERMEDIATE.
> This document defines what goes into IKE_SA_INIT, so the rest (eg new
> stuff) ca ngo into IKE_INTERMEDIATE.

>From implementer's point of view it's better if the possible content
of each message be clearly defined. It simplifies parsing message and 
state machine...

> > I think that corresponding application document must define this.
> 
> I don't see why they would need to do that? For example, imagine I
> add a large notify payload that would cause IKE_SA_INIT fragmentation,
> the IKE daemon looks what payloads to put in IKE_SA_INIT and the
> non-listed Notify payload would be put into one or more
> IKE_INTERMEDIATE exchanges.

I don't see any problem here. You can write an application document
saying that once INTERMEDIATE is negotiated (and some other 
thing happened, indicating mutual support for the following),
the peers may offload there whatever they want (and makes sense) 
from IKE_SA_INIT. I just don't want such things take place sporadically,
by sole fact that INTERMEDIATE is supported. Otherwise Tobias G.'s
concerns are applied.

Regards,
Valery.

> Paul
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec