IETF Logo Mail Archive

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

"Valery Smyslov" <smyslov.ietf@gmail.com> Thu, 21 March 2019 11:47 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 91852127964 for <ipsec@ietfa.amsl.com>; Thu, 21 Mar 2019 04:47:11 -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 roK4r30T5hFu for <ipsec@ietfa.amsl.com>; Thu, 21 Mar 2019 04:47:10 -0700 (PDT)
Received: from mail-wr1-x432.google.com (mail-wr1-x432.google.com [IPv6:2a00:1450:4864:20::432]) (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 D4F1C12795E for <ipsec@ietf.org>; Thu, 21 Mar 2019 04:47:09 -0700 (PDT)
Received: by mail-wr1-x432.google.com with SMTP id j9so6214868wrn.6 for <ipsec@ietf.org>; Thu, 21 Mar 2019 04:47:09 -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=st/hQhXxdil/1sCFWX6eHUexcJv5QpfTjn6Dw3F30uA=; b=HXJ9Vv6yW9silGmwJwh+0l3XFmZlYnQ3WXaq+dwCOdhcn42nsWjWPNtzxEKmeqj97E qzKZkGVDdUUKhXn5fWktLbO9Cov4vSEY9V2xvZA5KR3AJnKeOob3RFDj0DV4Xpv4V/JE XqDyMBzy4F/FVF1VJbo2deWQQR2ZDn8o35HTMY9HlhArA8fJNLX3MCaWJ60qjcLZjYck rsnjn3b+ro7N3biW8kz5ToTYUCuFhBG9KXSU8DaOU54FA6nrJ1/ley53gECfaKDBAyEZ nl6uYjeRbDYMimE8IHmPvVNye1br0zq5KiZwQV+hk+a/5SBLgmC2o5YARMXthPZIe5qT Hdbg==
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=st/hQhXxdil/1sCFWX6eHUexcJv5QpfTjn6Dw3F30uA=; b=VHjV1O+fcs/RAvnw6flNgQV4D9zW8XTx/falB6PRWPA6+UmvrcvAS02ATSg1r6agj4 6RX2LVY4gUsrul4B1HjwI9PAkhv8M9HroXfnV21pudtWXhcBg0DNXcQmpQX+KDxG1PHV jGeVKG4vAlVt+8vCWm9SZmyCsw82OW8ZeRpBOiFpvYBsLMLo16jCeQzlf5COjLcYfivK 9fmRrSglg/6oKD3kwkM0aBR2U/KtjnQtb0K+mOa4f/VV3xdfVfrz1fr1nMgJfXWfQ80F D9Uuxn/ME1/puPBdSUL7AYOCBt53LMv55si5pR/K9w+O7H6AxJ46cuerApH5JRJU6kV+ 1dlQ==
X-Gm-Message-State: APjAAAW+sZx54bzwAZloNJ03xyeJZsal0r1IJ7S2JQUlh+90IWasFIbK rwDmp88E12gGkOkUKHzTQ2w=
X-Google-Smtp-Source: APXvYqyzW6bhkehlpU72fPidZlx/hYWbCnKNhRSv2nsLFpCjBFF29+JZrrsV8zSzvkwhFb2a22jy0g==
X-Received: by 2002:a5d:5111:: with SMTP id s17mr2172111wrt.159.1553168828425; Thu, 21 Mar 2019 04:47:08 -0700 (PDT)
Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id a20sm8014661wmb.17.2019.03.21.04.47.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 21 Mar 2019 04:47:06 -0700 (PDT)
From: Valery Smyslov <smyslov.ietf@gmail.com>
To: 'Tobias Heider' <heidert@nm.ifi.lmu.de>, '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> <aa4d9b8c-3442-3507-0c99-cd9533fc2135@nm.ifi.lmu.de>
In-Reply-To: <aa4d9b8c-3442-3507-0c99-cd9533fc2135@nm.ifi.lmu.de>
Date: Thu, 21 Mar 2019 14:47:04 +0300
Message-ID: <07a601d4dfdb$ce2c5230$6a84f690$@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+AHuWDWOAmpINo8CGcLbUAMGThUEAw641ZkCdcCrbQH6yHdxAYDYIUoBRdt7SgIfEFY1pQu6epA=
Content-Language: ru
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/rDARqSfB2ousGSqviiBn95CawTg>
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:47:12 -0000

> > 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.
> >
> I like that idea actually. It would be nice though to have some fixed
> order for
> additional payloads, as we always had a fixed order for expected payloads.

IKEv2 has no restrictions on payloads order.

> >> 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.
> Indeed.
> I think the main advantage of IKE_INTERMEDIATE could be that specific
> "users" would not have to take care of this in their documents because it is
> solved once in a generic way.

True. Besides specification, there is an advantage that a single piece of code will 
take care of some INTERMEDIATE core functions (like its authentication etc.)

Regards,
Valery.

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

v2.23.0 | Report a Bug | By Email