From nobody Sat Jun 1 16:14:10 2019 Return-Path: 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 AEF7D120045 for ; Sat, 1 Jun 2019 16:14:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 lOcuxHlQvMq3 for ; Sat, 1 Jun 2019 16:14:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DB41200D6 for ; Sat, 1 Jun 2019 16:14:03 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x51NDxMo007340 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 2 Jun 2019 02:13:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x51NDuI6010295; Sun, 2 Jun 2019 02:13:56 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <23795.1716.390687.564153@fireball.acr.fi> Date: Sun, 2 Jun 2019 02:13:56 +0300 From: Tero Kivinen To: Paul Wouters Cc: Rafa Marin-Lopez , Fernando =?iso-8859-1?Q?Pere=F1=EDguez_Garc=EDa?= , "i2nsf\@ietf.org" , Gabriel Lopez , "ipsec\@ietf.org WG" , Linda Dunbar In-Reply-To: References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 20 min Archived-At: Subject: Re: [IPsec] [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2019 23:14:09 -0000 Paul Wouters writes: > > [Authors] We have observed some implementations (e.g. libreswan) > > has this variable initial-contact as well in the ipsec.conf. That i= s > > why we decide to=20 > > keep it. Is it not useful then=3F >=20 > We added it because sending or not sending it might change te behavio= ur > of the other endpoint. libreswan as implementation ignores the payloa= d > completely, because it has all the known information/state needed. > Although based on the above new finding of multiple IPsec SA's, this > might change. >=20 > I guess my point was more to the fact that instructing the NSF to sen= d > an INITIAL=5FCONTACT seems to mixup instructions from the SC. If the = SC > says "bring tunnel X to GW Y up", and then later says "bring tunnel Z= > up to GW Y and send INITIAL=5FCONTACT", it is implicitly sending a me= ssage > to the NSF to bring tunnel X to gateway Y down. Now the NSF and SC mi= ght > be out of sync if the SC wasn't expecting this result. The reason implementations need a flag for telling whether or not to send INITIAL=5FCONTACT notification is that there is no way for implementation to know whether it is replicated. I.e., if you have both your laptop and mobile phone making VPN connections to SGW, and both of them use same identity (for example kivinen@iki.fi), you want to disable sending INITIAL=5FCONTACT notifications as other wise when you have your laptop connection up and running and you start your phone, that will kill the IPsec SA for the laptop, as the phone would send INITIAL=5FCONTACT notification. When you disable it by the configuration then this will not happen. I.e., if you have separate connections that share same authenticated identity then you need to disable INITIAL=5FCONTACT notifications. Also= note that INITIAL=5FCONTACT is between identities, IP addresses, inner addresses etc does not matter, only the authenticated identities matter.=20 > > [Authors] This is an interesting question. We must state that, for = security reasons, any NSF should have a default DISCARD policy. A NSF r= estarting should > > not allow any traffic unless SC says so. In other words, Since the = NSF needs information coming from the SC, if that information is not in= place yet the > > safest option is DISCARD action. >=20 > Sure. I think adding some text that says a connection in the "configu= red > but not up" state is expceted to drop or hold onto the packets, that > would make it clear. Of course the device still needs to configure the IPsec policy so that device can connect to the security conntroller, and also perhaps add other holes to the policy that are needed to make that connection possible (arp, ND, perhaps ntp, etc).=20 > > Use "Configuration of IPsec Security Association (SA). Sectio= n 4.4.2.1 in RFC 4301" > > To ensure it is clear this is not about an IKE SA. Same on th= e next line for > > "for a particular SA" > > > > =A0=A0leaf seq-number-overflow-flag { type boolean; descripti= on "The flag indicating whether overflow of the sequence number counter= should > > prevent transmission of additional packets on the SA, or whet= her rollover is permitted."; } > > > > What is the source of this=3F I thought sequence numbers were= never allowed to overflow=3F > >=20 > >=20 > > [Authors] According to RFC 4301 - 4.4.2.1. =A0Data Items in the SAD= : > >=20 > > Sequence Counter Overflow: a flag indicating whether overflow of > > =A0 =A0 =A0 the sequence number counter should generate an auditabl= e event and > > =A0 =A0 =A0 prevent transmission of additional packets on the SA, o= r whether > > =A0 =A0 =A0 rollover is permitted. =A0The audit log entry for this = event SHOULD > > =A0 =A0 =A0 include the SPI value, current date/time, Local Address= , Remote > > =A0 =A0 =A0 Address, and the selectors from the relevant SAD entry.= >=20 >=20 > Hmm, I have never heard of this so I should look into it, but I guess= it > means you should have the option for it, but please default it to not= > allow rollover, and it would need to forbid rollover for AEAD's. >=20 > Tero, do you know anything more about this feature=3F I don't think w= e > could ever negotiate it via IKE anyway=3F Note, that AEAD counter is not in the sequence number field, it is in the IV field, and every AEAD cipher RFC has text which requires that IV field is generated in a way that ensures uniqueness. From RFC4309: The AES CCM IV field MUST be eight octets. The IV MUST be chosen by= the encryptor in a manner that ensures that the same IV value is use= d only once for a given key. The encryptor can generate the IV in any= manner that ensures uniqueness. Common approaches to IV generation include incrementing a counter for each packet and linear feedback shift registers (LFSRs). Anyways, as replay preventation is optional for the receiver, there is an option for ESP RFC4303 to disable it, and that case it does not matter whether the sequence number field overflows or not. Because of this the IPsec architecture document do allow option for wrapping sequence numbers. Of course if sequence number ever wraps, we do loose the anti-replay service, but there might be use cases where that does not matter. When using IKEv2, we do not negotiate anti-replay service, it is always assumed to be local matter on the receiver, thus there is no need for two peers to agreee on that. On the other hand if anybody would want to disable anti-replay, and use non-extended sequence numbers, and allow sequence numbers to wrap, then the IKEv2 does not offer that option, because it does not allow settign that flag in the SAD.=20 > > =A0=A0leaf anti-replay-window { type uint16 { range "0 | 32..= 1024"; } description "Anti replay window size"; } > > > > Why cap at 1024=3F That could be too low for 100gbps connecti= ons. > >=20 > >=20 > > [Authors] The truth is that RFC 4301 mentions: > >=20 > > Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) > > =A0 =A0 =A0 used to determine whether an inbound AH or ESP packet i= s a replay. > >=20 > > So we can replace this with uint64. On the other hand, we have obse= rved with uint16 should be enough in real cases. We can remove the rest= riction (1024) . > > what do you think=3F >=20 > Yes, I think the uint16 is more than enough, as long as you don't men= tion any cap like 1024. Actually the RFC4303 says in appendix A2: Also, the algorithm described below assumes that the window is no greater than 2^31 packets in width.) =20 so making it uint32, would work for any implementation using algorithm described in the RFC4303... --=20 kivinen@iki.fi From nobody Sun Jun 2 08:09:35 2019 Return-Path: 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 6C3551200F9; Sun, 2 Jun 2019 08:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 TABWrml9dhoz; Sun, 2 Jun 2019 08:09:30 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 233F81200B9; Sun, 2 Jun 2019 08:09:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45H1n36gmWz9Vy; Sun, 2 Jun 2019 17:09:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1559488167; bh=ao2IuD1BqMt5zQV6tUkcxaANIbZmLjTSCFHhZIWIWv0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=D0Wkl34jJ6sPkG37Z2RbY1h850evJmQDCUrQvPPOGRRj3cbGUW4jSEFL67Ckxn2GI QNPdnkF3/Ik71FFMKiLIXQzLiXdpc+BxIDox0jA1j8wuISBbOFUrWE25pVu7VW7c8p KWwAk+s0SQdj9YNZ496T8+tGhZycdDxRwJPIdDVI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 11BshvqV0S4n; Sun, 2 Jun 2019 17:09:26 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 2 Jun 2019 17:09:25 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C2D702C40F7; Sun, 2 Jun 2019 11:09:24 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C2D702C40F7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B6787410E45B; Sun, 2 Jun 2019 11:09:24 -0400 (EDT) Date: Sun, 2 Jun 2019 11:09:24 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: "ipsec@ietf.org WG" , "i2nsf@ietf.org" , Gabriel Lopez , Linda Dunbar , =?ISO-8859-15?Q?Fernando_Pere=F1=EDguez_Garc=EDa?= , Rafa Marin-Lopez In-Reply-To: <23795.1716.390687.564153@fireball.acr.fi> Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> <23795.1716.390687.564153@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 15:09:33 -0000 On Sun, 2 Jun 2019, Tero Kivinen wrote: > I.e., if you have separate connections that share same authenticated > identity then you need to disable INITIAL_CONTACT notifications. Also > note that INITIAL_CONTACT is between identities, IP addresses, inner > addresses etc does not matter, only the authenticated identities > matter. Sure, but "don't do that" :) > Note, that AEAD counter is not in the sequence number field, it is in > the IV field, and every AEAD cipher RFC has text which requires that > IV field is generated in a way that ensures uniqueness. From RFC4309: For now, but there are drafts going around that want to re-use the fields to save a few bytes :P > When using IKEv2, we do not negotiate anti-replay service, it is > always assumed to be local matter on the receiver, thus there is no > need for two peers to agreee on that. On the other hand if anybody > would want to disable anti-replay, and use non-extended sequence > numbers, and allow sequence numbers to wrap, then the IKEv2 does not > offer that option, because it does not allow settign that flag in the > SAD. Well, the IKEv2 endpoint that cares about this can just re-key or re-auth in time before reaching those counters. So yes, it does not need to be negotiated but it is the IKEv2 daemon handling this. So for the IKE-less case, I guess it should be there, although this is similar to the IKE-less case handling maxbytes, maxlife, maxidle counters. I think it is expected that the NSF sends the kernel message (pfkey, acquire) to the SC. So it could be avoided in the IKEless case than too. Paul From nobody Sun Jun 2 15:07:55 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C825120116; Sun, 2 Jun 2019 15:07:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <155951327415.21445.12260713059191420231@ietfa.amsl.com> Date: Sun, 02 Jun 2019 15:07:54 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2019 22:07:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Intermediate Exchange in the IKEv2 Protocol Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-intermediate-00.txt Pages : 10 Date : 2019-05-30 Abstract: This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jun 2 22:01:26 2019 Return-Path: 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 30ADB120116 for ; Sun, 2 Jun 2019 22:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, 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 kn_ckJiz8azr for ; Sun, 2 Jun 2019 22:01:22 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 4E47F120105 for ; Sun, 2 Jun 2019 22:01:22 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id y17so12483286lfe.0 for ; Sun, 02 Jun 2019 22:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:from:to:references:in-reply-to:subject:date:mime-version :content-transfer-encoding:importance; bh=d+GEnpzNI8Tg8ufK5CAFS82arpKjpIJ/EPT0AS+t6+0=; b=d06pkZrI+Z2gpYy/uzP+c3UD7I/PhP/UnzIlHr7CNK/7wVU0rKYts1hsjO9xKD2z6q BmXujo9rTmvaKM0u5lDG/d3wdqUflZWd9LYxSVCvRzEbq6qeQVuIq0imRPhK9w6CE77H HR8VjayXf0tw6HXCWFrc04TyV/87Q4vgiPo5L1juqHSbg9Wk7GDnBVZGYvSF30U0q1IE QqcLgYXyuDj18AALFfSNbMogCECadqLCN4T95lo+QYb78bmAS1M4Ripj+yRo21BtC2NC HNdyeJeHFOH8KYAYhgEa4QBua86V9oy/nASDSZmG3dajS1nwYSMkZ+mKhgSYYAR/U5w4 KCmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:from:to:references:in-reply-to :subject:date:mime-version:content-transfer-encoding:importance; bh=d+GEnpzNI8Tg8ufK5CAFS82arpKjpIJ/EPT0AS+t6+0=; b=JMnlb5g5zHzx0qVZlbCrC3zQXpLDkupiwnN6tZIpqCKFybx/Kd+vPJIwM+GvbfrdgR sqD5UHkTGsnnP+zzCMp7r5VSAtmdOCy3R/4dfOjcus+Bl3ZcSNWXvLsGRsyXf9KeFHPK QnRnVlIk07q/ks5YN5227vtyJ+d827BUKMRLARYEq2K0YhgLvAZCuEJ4dDxk6ijAoBg7 NHe6VfalrXFKoR4tVwpllC3rjH9HJTOVuyTJWfshnwMsjCCn8jGUkD5PRn6NoVOCtXSi ZcsrQRGbipae08kbEEgR89OK3/i6E4o41L9+byT7E7LiI1z6QB9lP269SyS4tDWtGR+b +Rsw== X-Gm-Message-State: APjAAAWA1m4MICDMSWxyVVvc73zPSyGA9t6SIOGs/Qq4vLnlg8Qt42Pe QqF2oG8N1DhdAcKNimXmrKUOTyDf X-Google-Smtp-Source: APXvYqzwHBCY+lZEtt0xty1EjemuG/GQ0MRBOHNT+vFe1LQ8eysJNLNajxXkoVH3ZbqF7k5KwHVxzQ== X-Received: by 2002:ac2:5938:: with SMTP id v24mr2401844lfi.161.1559538080194; Sun, 02 Jun 2019 22:01:20 -0700 (PDT) Received: from chichi (95-27-147-103.broadband.corbina.ru. [95.27.147.103]) by smtp.gmail.com with ESMTPSA id z17sm153905ljc.37.2019.06.02.22.01.18 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Jun 2019 22:01:19 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: References: <155951327415.21445.12260713059191420231@ietfa.amsl.com> In-Reply-To: <155951327415.21445.12260713059191420231@ietfa.amsl.com> Date: Mon, 3 Jun 2019 08:01:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 05:01:24 -0000 Hi, I've published a new version of ikev2-aux draft, which is now called ikev2-intermediate. There are few changes compared to previous version - the exchange is renamed (again) to IKE_INTERMEDIATE and the introduction text is changed to make more explicit that QSKE is not the only intended applycation for the exchange. There are also some clarifications and text improvements. Reviews and comments are appreciated, the document is stable for quite a long period of time. Regards, Valery. -----Original Message----- From: internet-drafts@ietf.org Date: 3 июня 2019 г. 1:07 To: i-d-announce@ietf.org Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Intermediate Exchange in the IKEv2 Protocol Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-intermediate-00.txt Pages : 10 Date : 2019-05-30 Abstract: This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-00 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Jun 3 03:33:07 2019 Return-Path: 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 2B5851201D9; Mon, 3 Jun 2019 03:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 o9M1RtUqNoHf; Mon, 3 Jun 2019 03:33:03 -0700 (PDT) Received: from xenon43.um.es (xenon43.um.es [155.54.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id CA4991201AE; Mon, 3 Jun 2019 03:33:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id 7766B20A60; Mon, 3 Jun 2019 12:33:01 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon43.um.es Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id AFSGUfh6KOU2; Mon, 3 Jun 2019 12:33:01 +0200 (CEST) Received: from quantum.inf.um.es (quantum.inf.um.es [155.54.204.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon43.um.es (Postfix) with ESMTPSA id 7F5BE20192; Mon, 3 Jun 2019 12:32:58 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <7C701C5B-4980-4CAD-B8D8-A4CADE3304FC@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_F57E2CE1-7C43-4B24-87F1-DD0104787A08" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 3 Jun 2019 12:32:57 +0200 In-Reply-To: Cc: Rafa Marin-Lopez , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , "i2nsf@ietf.org" , Gabriel Lopez , "ipsec@ietf.org WG" , Linda Dunbar To: Paul Wouters , Tero Kivinen References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> <718671CF-46BF-427A-A008-A9F8EB3631D0@um.es> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 10:33:06 -0000 --Apple-Mail=_F57E2CE1-7C43-4B24-87F1-DD0104787A08 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul, Tero >>=20 >> =E2=80=9CFor security reasons, a NSF MUST NOT allow any traffic = unless the Security Controller mandates so. In other words, since the = NSF needs IPsec information coming from the SC, if that information is = not in place yet the safest option is DISCARD (drop) packets." >=20 > I assume there are two types of deployment, "cleartext but encrypt = when > possible" and "encryption mandatory". So I feel the MUST NOT is a bit > too strong. Perhaps limit it to say "if encryption is mandatory for > all traffic of an NSF, its default policy MUST be to drop packets to > prevent cleartext packet leaks". >=20 > But then you also do not need per-tunnel "drop" policies, so the SC = does > not have to instruct the NSF for anything. [Authors] Indeed the NSF should have this policy without contacting with = the SC. The NSF should know beforehand (before SC can say anything to = the NSF) that the whole deployment policy will be "cleartext but encrypt = when possible=E2=80=9D or =E2=80=9Cencryption mandatory=E2=80=9D. We = should be able to use our interface to include a default policy = "cleartext but encrypt when possible=E2=80=9D or "=E2=80=9Cencryption = mandatory=E2=80=9D in the NSF=E2=80=99s startup config. In this case, = this startup config is not set by the Security Controller but by some = other entity during the NSF =E2=80=9Cbootstrapping" (before it is = deployed in the network). This initial startup config would include what = Tero mentioned about different policies that allow this NSF to contact = the SC once the NSF has been deployed.=20 Moreover, we should allow to change between "cleartext but encrypt when = possible=E2=80=9D and =E2=80=9Cencryption mandatory=E2=80=9D if the = administrator requires so. This change could be performed by the SC. = Perhaps we could add the following text: =E2=80=9CFor security reasons, if encryption is mandatory for all = traffic of a NSF, its default policy MUST be to drop (DISCARD) packets = to prevent cleartext packet leaks. This default policy MUST be in the = startup configuration datastore in the NSF before the NSF contacts with = the Security Controller. Moreover, the startup configuration datastore = MUST be pre-configured with the required ALLOW policies that allow to = communicate the NSF with the Security Controller once the NSF is = deployed. This pre-configuration step is not carried out by the Security = Controller but by some other entity before the NSF deployment. In this = manner, when the NSF reboots, it will always apply first the = configuration in the startup configuration before contacting the = Security Controller." >=20 >>>=20 >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_F57E2CE1-7C43-4B24-87F1-DD0104787A08 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Paul, Tero


=E2=80=9CFor security reasons, a NSF MUST NOT allow any = traffic unless the Security Controller mandates so. In other words, = since the NSF needs IPsec information coming from the SC, if that = information is not in place yet the safest option is DISCARD (drop) = packets."

I assume there are = two types of deployment, "cleartext but encrypt when
possible" and "encryption mandatory". So I feel the MUST NOT = is a bit
too strong. Perhaps limit it to say "if = encryption is mandatory for
all traffic of an NSF, its = default policy MUST be to drop packets to
prevent = cleartext packet leaks".

But then you also = do not need per-tunnel "drop" policies, so the SC does
not = have to instruct the NSF for anything.

[Authors] Indeed the NSF should have this policy = without contacting with the SC. The NSF should know beforehand (before = SC can say anything to the NSF) that the whole deployment policy will be = "cleartext but encrypt when possible=E2=80=9D or =E2=80=9Cencryption = mandatory=E2=80=9D. We should be able to use our interface to include a = default policy "cleartext but encrypt when possible=E2=80=9D or = "=E2=80=9Cencryption mandatory=E2=80=9D in the NSF=E2=80=99s startup = config. In this case, this startup config is not set by the Security = Controller but by some other entity during the NSF =E2=80=9Cbootstrapping"= (before it is deployed in the network). This initial startup config = would include what Tero mentioned about different policies that allow = this NSF to contact the SC once the NSF has been = deployed. 

Moreover, we should = allow to change between "cleartext but encrypt when possible=E2=80=9D = and =E2=80=9Cencryption mandatory=E2=80=9D if the administrator requires = so. This change could be performed by the SC. Perhaps we could add the = following text:


=E2=80=9CFor security reasons, if encryption is = mandatory for all traffic of a NSF, its default policy MUST be to drop = (DISCARD) packets to prevent cleartext packet leaks. This default = policy MUST be in the startup configuration datastore in the NSF before = the NSF contacts with the Security Controller. Moreover, the startup = configuration datastore MUST be pre-configured with the required ALLOW = policies that allow to communicate the NSF with the Security Controller = once the NSF is deployed. This pre-configuration step is not carried out = by the Security Controller but by some other entity before the NSF = deployment. In this manner, when the NSF reboots, it will always apply = first the configuration in the startup configuration before contacting = the Security Controller."






_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_F57E2CE1-7C43-4B24-87F1-DD0104787A08-- From nobody Mon Jun 3 05:15:20 2019 Return-Path: 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 C793512020A; Mon, 3 Jun 2019 05:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 hm_MicxbzNtB; Mon, 3 Jun 2019 05:15:16 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [IPv6:2001:720:1710:601::42]) by ietfa.amsl.com (Postfix) with ESMTP id F2D831200EA; Mon, 3 Jun 2019 05:15:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 8C3191FF64; Mon, 3 Jun 2019 14:15:14 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon42.um.es Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RqeKU2D-7M02; Mon, 3 Jun 2019 14:15:14 +0200 (CEST) Received: from quantum.inf.um.es (quantum.inf.um.es [155.54.204.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon42.um.es (Postfix) with ESMTPSA id C22B82099B; Mon, 3 Jun 2019 14:15:11 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <997AE9FE-F0EB-4148-96B7-16A138E92205@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_A9739FEF-C2C6-4E4B-9876-03FB9C0FFD41" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 3 Jun 2019 14:15:11 +0200 In-Reply-To: Cc: Rafa Marin-Lopez , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , "i2nsf@ietf.org" , Gabriel Lopez , Linda Dunbar , "ipsec@ietf.org WG" To: Paul Wouters , Tero Kivinen References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> <23795.1716.390687.564153@fireball.acr.fi> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 12:15:19 -0000 --Apple-Mail=_A9739FEF-C2C6-4E4B-9876-03FB9C0FFD41 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tero, Paul: > El 2 jun 2019, a las 17:09, Paul Wouters escribi=C3=B3:= >=20 > On Sun, 2 Jun 2019, Tero Kivinen wrote: >=20 >> I.e., if you have separate connections that share same authenticated >> identity then you need to disable INITIAL_CONTACT notifications. Also >> note that INITIAL_CONTACT is between identities, IP addresses, inner >> addresses etc does not matter, only the authenticated identities >> matter. >=20 > Sure, but "don't do that" :) [Authors] Taking into account that road-warrior case is not considered = in the I-D (only host-to-host and gw-to-gw) and Paul=E2=80=99s comment I = think we can safely remove the leaf initial-contact, correct?. Moreover the Security Controller is the one providing this identity to = the NSFs so I think this case would not be possible, would it?. >=20 >> Note, that AEAD counter is not in the sequence number field, it is in >> the IV field, and every AEAD cipher RFC has text which requires that >> IV field is generated in a way that ensures uniqueness. =46rom = RFC4309: >=20 > For now, but there are drafts going around that want to re-use the > fields to save a few bytes :P [Authors] Our model allows the Security Controller to set the IV in the = SAD in the IKE-less case. leaf iv { nacm:default-deny-all; type yang:hex-string;=20 description=20 "ESP encryption IV value";=20 } >=20 >> When using IKEv2, we do not negotiate anti-replay service, it is >> always assumed to be local matter on the receiver, thus there is no >> need for two peers to agreee on that. On the other hand if anybody >> would want to disable anti-replay, and use non-extended sequence >> numbers, and allow sequence numbers to wrap, then the IKEv2 does not >> offer that option, because it does not allow settign that flag in the >> SAD. >=20 > Well, the IKEv2 endpoint that cares about this can just re-key or > re-auth in time before reaching those counters. So yes, it does not > need to be negotiated but it is the IKEv2 daemon handling this. So for > the IKE-less case, I guess it should be there, although this is = similar > to the IKE-less case handling maxbytes, maxlife, maxidle counters. I > think it is expected that the NSF sends the kernel message (pfkey, > acquire) to the SC. So it could be avoided in the IKEless case than = too. [Authors] We have a doubt here: if the IKEv2 endpoint that cares about = this performs the re-key or re-auth, it needs to know when this event = happens. I guess IKEv2 implementation would be expecting a notification = from the kernel like xfrm_replay_notify(struct xfrm_state *x, int event) = when a xfrm_replay_overflow happens (see for example : = ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/kernel-3.10.14= /net/xfrm/xfrm_replay.c) is this correct? We have also observed several types of overflow: = xfrm_replay_overflow_bmp (not sure about the purpose of this, any = clarification?), xfrm_replay_overflow_esn, xfrm_replay_overflow if that is the case, we should include that notification in the model = for IKE-less case so that the Security Controller is aware of this = situation. However, wouldn't it be enough to use the number of packets = lifetime instead of having this new threshold (in xfrm we have seen = replay_maxdiff and replay_maxage as such as threshold). Best Regards. >=20 > Paul >=20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_A9739FEF-C2C6-4E4B-9876-03FB9C0FFD41 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tero, Paul:

El 2 jun 2019, a las 17:09, Paul Wouters = <paul@nohats.ca> = escribi=C3=B3:

On Sun, 2 Jun 2019, Tero Kivinen wrote:

I.e., if = you have separate connections that share same authenticated
identity then you need to disable INITIAL_CONTACT = notifications. Also
note that INITIAL_CONTACT is between = identities, IP addresses, inner
addresses etc does not = matter, only the authenticated identities
matter.

Sure, but "don't do that" :)

[Authors] Taking into account that = road-warrior case is not considered in the I-D (only host-to-host and = gw-to-gw) and Paul=E2=80=99s comment I think we can safely remove the = leaf initial-contact, correct?.

Moreover the Security Controller is the one = providing this identity to the NSFs so I think this case would not be = possible, would it?.



Note, = that AEAD counter is not in the sequence number field, it is in
the IV field, and every AEAD cipher RFC has text which = requires that
IV field is generated in a way that ensures = uniqueness. =46rom RFC4309:

For = now, but there are drafts going around that want to re-use the
fields to save a few bytes :P


[Authors] Our model allows the Security Controller to = set the IV in the SAD in the IKE-less case.

leaf iv {
= nacm:default-deny-all;
        = type yang:hex-string; 
        = description 
"ESP encryption IV = value"; 
}


When using IKEv2, we do = not negotiate anti-replay service, it is
always assumed to = be local matter on the receiver, thus there is no
need for = two peers to agreee on that. On the other hand if anybody
would want to disable anti-replay, and use non-extended = sequence
numbers, and allow sequence numbers to wrap, then = the IKEv2 does not
offer that option, because it does not = allow settign that flag in the
SAD.

Well, the IKEv2 endpoint that = cares about this can just re-key or
re-auth in time before = reaching those counters. So yes, it does not
need to be = negotiated but it is the IKEv2 daemon handling this. So for
the IKE-less case, I guess it should be there, although this = is similar
to the IKE-less case handling maxbytes, = maxlife, maxidle counters. I
think it is expected that the = NSF sends the kernel message (pfkey,
acquire) to the SC. = So it could be avoided in the IKEless case than too.

[Authors] We have a doubt here: if the IKEv2 = endpoint that cares about this performs the re-key or re-auth, it needs = to know when this event happens. I guess IKEv2 implementation would be = expecting a notification from the kernel like xfrm_replay_notify(struct xfrm_state *x, int = event) when a xfrm_replay_overflow happens (see for example : ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/ker= nel-3.10.14/net/xfrm/xfrm_replay.c)

is this = correct?

We have also = observed several types of overflow: xfrm_replay_overflow_bmp (not sure about the purpose of this, = any clarification?), xfrm_replay_overflow_esn, xfrm_replay_overflow

if that is the case, we should include = that notification in the model for IKE-less case so that the Security = Controller is aware of this situation. However, wouldn't it be enough to = use the number of packets lifetime instead of having this new threshold = (in xfrm we have seen replay_maxdiff and replay_maxage as such as = threshold).

Best= Regards.


Paul

_______________________________________________
I2nsf mailing list
I2nsf@ietf.org
https://www.ietf.org/mailman/listinfo/i2nsf

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_A9739FEF-C2C6-4E4B-9876-03FB9C0FFD41-- From nobody Mon Jun 3 07:38:37 2019 Return-Path: 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 61DAE1202BE for ; Mon, 3 Jun 2019 07:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Wcef61V-VvsB for ; Mon, 3 Jun 2019 07:38:33 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FF61202BB for ; Mon, 3 Jun 2019 07:38:32 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 67B7A3808A; Mon, 3 Jun 2019 10:37:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5C6AD107E; Mon, 3 Jun 2019 10:38:30 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5AECA7E4; Mon, 3 Jun 2019 10:38:30 -0400 (EDT) From: Michael Richardson To: "Valery Smyslov" cc: ipsec@ietf.org In-Reply-To: References: <155951327415.21445.12260713059191420231@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 14:38:35 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > I've published a new version of ikev2-aux draft, which is now called ikev2-intermediate. > There are few changes compared to previous version - the exchange is renamed (again) > to IKE_INTERMEDIATE and the introduction text is changed to make more > explicit I'm not super enthusiastic about IKE_INTERMEDIATE, but I sure prefer it to aux! Thank you for the change. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlz1MOYACgkQgItw+93Q 3WXmGwgAuAm/v2uclcqf0QbA7u/28o7nyu4kuk6IxUQw4bPAWW0+riJH3dYL8cjk Ri4pDnDPxoQoANrNWYV2me6quOkLFN/gJu//eP6uB7DcZ1kkpy/bH03FS+Zsl3T3 KyYYVsuqWSSx361lrDSssQj5bi7hZNBjjZpf1x6CglJZF7fnij8Nkvs6Vnnj2a7k Xy+nuiWR2/9hdZ5+lpR/EmFE0tTYmvgYp0WKuscY4UmzmTgBTuOKnTHGLUYzcXo2 zLB3NRHLAG3tNQ024aqxGIwedmAJYbesGbQyW56Ce/kDoMBEqCURgQqWf2Q8MOY4 u2XjLNzhAL43Ld5BenYXK+dNz4rqfA== =CCNh -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jun 3 12:02:09 2019 Return-Path: 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 D9D81120384 for ; Mon, 3 Jun 2019 12:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 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_HELO_NONE=0.001, 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 1LS09wlQx59Q for ; Mon, 3 Jun 2019 12:02:06 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 5E371120143 for ; Mon, 3 Jun 2019 12:02:06 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id y17so14456727lfe.0 for ; Mon, 03 Jun 2019 12:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=vs/dv3hUQxOy+DcGhR7hoPdZ9yi9mzbRhXER0xEfwNg=; b=ARFVLuW3wAbxFuVZ4VWOBKzUyfpZyuN7ahCfO5DkqIQKKpF+yMqztQxwDYLU1ab3Kq qMm8wecKCzfFlYAfh8QK9jbAhMc+lArAl5bJ6FTMpWZmkGzFsMliyzwqjvrhE/MT3jvy YMMW1SVxu2V52NFXbqAOgrnYHDK+Fybd401V4laay6FCsnj4BGpn0yZPkxUaMUxq4Bf+ QAt+WjAgCdHQA4ZHUHD/yVvgxWfNUosBqvuyc1WrRNbw1Y7UyRcpXHlk2f+gLcRvQvEg zG2FNeyxsDAUzHbNp44/NXz4jRdtLrHgm+w9M3UuC0lTYyIasH4BKzJMTGa8Cn6398Pu awmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=vs/dv3hUQxOy+DcGhR7hoPdZ9yi9mzbRhXER0xEfwNg=; b=SgLOt3ia6I4IJMUntYz5b+dLKkMjRfaVfA8qC3qLcwT911fYxldvmzaQl9Jyf/YTqH nYMW6Z9gNLuqFPAFz5wY+fLHOliK7JGFAG3GMm9NkdfAeM8G25/gcUx+vPDSDSSHpFon 73OY4vRqfUi/5UgfThRmgWJXKhspL1wnXW1nf5o6QgEBWCeUGnsLAojFLQYSPpwd3WIW fW7FCqhIG3C3CfVqxjDPwSrbA6D8KXk+vNdf5gwE87/v1fnZ1qMXmey+i3HYIPv8zxDf AVSOgJtMAGUdkceeL14J6JWLO/43izXmwo1SVvdY0aWjtN75z+14z8YplV3YeEuVfVsR R+0g== X-Gm-Message-State: APjAAAXqaZ2UxvSqfQ5fiWbEHjd11d/HU8OMN1njaRasmFZ+3YlT8xPC FRuEbolAUmeRnh48E7fIHvDaUIbX X-Google-Smtp-Source: APXvYqxDCCromThp1bwkBeEaTkeg3YsncqoxmUu3GuAUfvBUrBQ+nIGw8N/fbXsRmyUCYospyYaITw== X-Received: by 2002:a19:7716:: with SMTP id s22mr14419735lfc.64.1559588524298; Mon, 03 Jun 2019 12:02:04 -0700 (PDT) Received: from svannotebook (o63-hfw-1-nat-0-1-22.extel-gsm.com. [85.115.224.150]) by smtp.gmail.com with ESMTPSA id j11sm3317656lfm.29.2019.06.03.12.02.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Jun 2019 12:02:03 -0700 (PDT) From: "Valery Smyslov" To: "'Michael Richardson'" Cc: References: <155951327415.21445.12260713059191420231@ietfa.amsl.com> <16311.1559572710@localhost> In-Reply-To: <16311.1559572710@localhost> Date: Mon, 3 Jun 2019 22:02:00 +0300 Message-ID: <009c01d51a3e$d40fd6c0$7c2f8440$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKDLFCx6bNfpWqtAgPgMyTEf1JR0wDgXQ1gATxgoHGlHT4rcA== Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 19:02:08 -0000 Hi Michael, this name was suggested by Paul Wouters at the last IETF. If you have better name in mind, please come out with it :-) Regards, Valery. > Valery Smyslov wrote: > > I've published a new version of ikev2-aux draft, which is now called ikev2- > intermediate. > > There are few changes compared to previous version - the exchange is > renamed (again) > > to IKE_INTERMEDIATE and the introduction text is changed to make more > > explicit > > I'm not super enthusiastic about IKE_INTERMEDIATE, but I sure prefer it to > aux! Thank you for the change. > > -- > Michael Richardson , Sandelman Software Works - > = IPv6 IoT consulting =- > > From nobody Tue Jun 4 02:40:53 2019 Return-Path: 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 ECA871200CE for ; Tue, 4 Jun 2019 02:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no 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 EChKJ68SHH1H for ; Tue, 4 Jun 2019 02:40:49 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193AD120046 for ; Tue, 4 Jun 2019 02:40:47 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x549ehdR006058 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Jun 2019 12:40:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x549ef9L022752; Tue, 4 Jun 2019 12:40:41 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <23798.15513.517314.618936@fireball.acr.fi> Date: Tue, 4 Jun 2019 12:40:41 +0300 From: Tero Kivinen To: Rafa Marin-Lopez Cc: Paul Wouters , Fernando =?utf-8?Q?Pere=C3=B1=C3=ADguez_Garc=C3=ADa?= , "i2nsf\@ietf.org" , Gabriel Lopez , Linda Dunbar , "ipsec\@ietf.org WG" In-Reply-To: <997AE9FE-F0EB-4148-96B7-16A138E92205@um.es> References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> <23795.1716.390687.564153@fireball.acr.fi> <997AE9FE-F0EB-4148-96B7-16A138E92205@um.es> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Archived-At: Subject: Re: [IPsec] [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 09:40:52 -0000 Rafa Marin-Lopez writes: > Hi Tero, Paul: >=20 > El 2 jun 2019, a las 17:09, Paul Wouters escribi= =C3=B3: > =20 > On Sun, 2 Jun 2019, Tero Kivinen wrote: >=20 > I.e., if you have separate connections that share same authen= ticated > identity then you need to disable INITIAL=5FCONTACT notificat= ions. Also > note that INITIAL=5FCONTACT is between identities, IP address= es, inner > addresses etc does not matter, only the authenticated identit= ies > matter. >=20 > Sure, but "don't do that" :) >=20 > [Authors] Taking into account that road-warrior case is not considere= d in the > I-D (only host-to-host and gw-to-gw) and Paul=E2=80=99s comment I thi= nk we can safely > remove the leaf initial-contact, correct=3F. The same setting is also used in case there is replicated setups, i.e., every case where you might have two nodes sharing identity and authentication information. Load balancing, hotswap setups, replicated servers etc quite often also want to make sure they set this setting on. Those cases might be in scope for i2nsf too. > Moreover the Security Controller is the one providing this identity t= o the > NSFs so I think this case would not be possible, would it=3F. It depends. Security controller might provide same identity to both load balancing nodes, or both to the in sgw in use and the hot swap replicated version.=20 > Note, that AEAD counter is not in the sequence number field, = it is in > the IV field, and every AEAD cipher RFC has text which requir= es that > IV field is generated in a way that ensures uniqueness. From = RFC4309: >=20 > For now, but there are drafts going around that want to re-use th= e > fields to save a few bytes :P >=20 > [Authors] Our model allows the Security Controller to set the IV in > the SAD in the IKE-less case. IV is per packet information, SC cannot really provide it. It can provide initial value for it, but the updating of it must be done in node. > Well, the IKEv2 endpoint that cares about this can just re-key or= > re-auth in time before reaching those counters. So yes, it does n= ot > need to be negotiated but it is the IKEv2 daemon handling this. S= o for > the IKE-less case, I guess it should be there, although this is s= imilar > to the IKE-less case handling maxbytes, maxlife, maxidle counters= . I > think it is expected that the NSF sends the kernel message (pfkey= , > acquire) to the SC. So it could be avoided in the IKEless case th= an too. >=20 > [Authors] We have a doubt here: if the IKEv2 endpoint that cares abou= t this > performs the re-key or re-auth, it needs to know when this event happ= ens. I > guess IKEv2 implementation would be expecting a notification from the= kernel > like xfrm=5Freplay=5Fnotify(struct xfrm=5Fstate *x, int event) when a= =20 > xfrm=5Freplay=5Foverflow happens (see for example :=20 > ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/kernel-3.= 10.14/net/xfrm/xfrm=5Freplay.c > ) >=20 > is this correct=3F IKEv2 will register suitable triggers to kernel, and kernel will then use suitable method to notify IKEv2 when those timers, counters etc are expiring. Not sure what those xfrm things do, as those are not part of standard, but are internal implementation details for one specific implementation. Usually IKEv2 will set packet counter triggers that will expire way before the actual overflow happens, so it has time to rekey before the hard expiration happens.=20 --=20 kivinen@iki.fi From nobody Wed Jun 5 00:16:01 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A02221200FB; Wed, 5 Jun 2019 00:15:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, kaduk@mit.edu, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155971895965.18861.14026366882358841281.idtracker@ietfa.amsl.com> Date: Wed, 05 Jun 2019 00:15:59 -0700 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 105 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 07:16:00 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: sacm mile tcpinc curdle tls saag cfrg i2nsf Second Priority: 6tisch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Tero Kivinen David Waltermire Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Wed Jun 5 00:37:53 2019 Return-Path: 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 3C1D21200F1 for ; Wed, 5 Jun 2019 00:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 bBxna6EMAkQD for ; Wed, 5 Jun 2019 00:37:49 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 49687120224 for ; Wed, 5 Jun 2019 00:37:47 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 9768B60260; Wed, 5 Jun 2019 03:37:46 -0400 (EDT) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_349AF57B-4CCF-48AF-81D8-9D0A8B77F5E5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 5 Jun 2019 03:37:45 -0400 References: <155971876029.18772.2783863612606872760@ietfa.amsl.com> Cc: Christian Hopps To: "ipsec@ietf.org WG" Message-Id: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [IPsec] Update to IP-TFS [Fwd: I-D Action: draft-hopps-ipsecme-iptfs-01.txt] X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 07:37:51 -0000 --Apple-Mail=_349AF57B-4CCF-48AF-81D8-9D0A8B77F5E5 Content-Type: multipart/alternative; boundary="Apple-Mail=_6363E56F-3C10-412A-873B-70CAC14EB260" --Apple-Mail=_6363E56F-3C10-412A-873B-70CAC14EB260 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii FYI, A new version of the IP-TFS draft has been posted. This version = incorporates changes requested by the WG (and from TSV folks) on the = mailing list and at IETF 104. In particular: - IKEv2 TFS Type transform type introduced. - Notification Status Message for indicating dont-fragment. - Congestion Control information is now sent in-band, instead of using = IKE. - Congestion Control information and text changed to align with = published TCP friendly congestion control algorithms. - Appendix illustrating how to implement TCP friendly CC algorithm. Thanks, Chris. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-hopps-ipsecme-iptfs-01.txt > Date: June 5, 2019 at 3:12:40 AM EDT > To: > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : IP Traffic Flow Security > Author : Christian Hopps > Filename : draft-hopps-ipsecme-iptfs-01.txt > Pages : 25 > Date : 2019-06-05 >=20 > Abstract: > This document describes a mechanism to enhance IPsec traffic flow > security by adding traffic flow confidentiality to encrypted IP > encapsulated traffic. Traffic flow confidentiality is provided by > obscuring the size and frequency of IP traffic using a fixed-sized, > constant-send-rate IPsec tunnel. The solution allows for congestion > control as well. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-01 > https://datatracker.ietf.org/doc/html/draft-hopps-ipsecme-iptfs-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-hopps-ipsecme-iptfs-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 --Apple-Mail=_6363E56F-3C10-412A-873B-70CAC14EB260 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii FYI,

A = new version of the IP-TFS draft has been posted. This version = incorporates changes requested by the WG (and from TSV folks) on the = mailing list and at IETF 104. In particular:

- IKEv2 TFS Type transform type = introduced.
- Notification Status Message for = indicating dont-fragment.
- Congestion Control = information is now sent in-band, instead of using IKE.
- Congestion Control information and text changed to align = with published TCP friendly congestion control algorithms.
- Appendix illustrating how to implement TCP friendly CC = algorithm.

Thanks,
Chris.

Begin= forwarded message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-hopps-ipsecme-iptfs-01.txt
Date: = June 5, 2019 at 3:12:40 AM = EDT
To: = <i-d-announce@ietf.org>
Reply-To: = internet-drafts@ietf.org


A New = Internet-Draft is available from the on-line Internet-Drafts = directories.


=        Title =           : IP Traffic = Flow Security
=        Author =          : Christian = Hopps
Filename =        : = draft-hopps-ipsecme-iptfs-01.txt
Pages =           : 25
= Date =            : = 2019-06-05

Abstract:
=   This document describes a mechanism to enhance IPsec traffic = flow
  security by adding traffic flow = confidentiality to encrypted IP
  encapsulated = traffic.  Traffic flow confidentiality is provided by
=   obscuring the size and frequency of IP traffic using a = fixed-sized,
  constant-send-rate IPsec tunnel. =  The solution allows for congestion
=   control as well.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hopps-ipsecme-iptfs/=

There are also htmlized versions available = at:
https://tools.ietf.org/html/draft-hopps-ipsecme-iptfs-01
https://datatracker.ietf.org/doc/html/draft-hopps-ipsecme-iptfs= -01

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-hopps-ipsecme-iptfs-0= 1


Please note that it may = take a couple of minutes from the time of submission
until = the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by = anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: = http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt


= --Apple-Mail=_6363E56F-3C10-412A-873B-70CAC14EB260-- --Apple-Mail=_349AF57B-4CCF-48AF-81D8-9D0A8B77F5E5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlz3cUkACgkQLh2DDte4 MCXCmw/9FGsQ4Td2pQB15A0FQijBJPckmCZzSBifA/8XQA4nDFYED205IMllO6Y3 RBppRhp+k9IyFBy0kvtuqbEubs1tvPeW4tDR0EcTBJHlPghZyNH17blR4w/Ownsb H4O2ghATL6Xa9Ds+rD7xa2wWq9LXwSevsyJ7ebsRlpsq+ICoBmmibIR2kFKsMyem Lta8I0ngH9kHF7hR5AFq8hg1s0qZWtBs3DC8lMeB7FEAz7BFeoVfOB+cAGX6ssq7 HdFiNfrB09DSAvz64N9RoMBloIEgL25KwEQBP85HaRFLltFNrWJA8SzXyNMO11cG LrIYRaaC2GWJ07E1Tg9yueRZH3Bg7pWM0/COlS7caHEM482mcHRXoGxpWENWQdFS iqFNzUi1IAWTfiAiCcew7CZQsZFRz+PKC4NOy+YeTZbmHXLPwPcBa266p1bEBkDC LMjjxtmsKh/wzSphQsIEs6doBAYUKVHmF5JPDDr6Oy63ruwUDPX6pjfGiLoixfDa mgp7ZfDOVlFTOwwxehE/DPgvsk3+LWS+QH54wICWOcfGBdgtMVt4bcUNEAeqpQM0 wu+duMaEuX+6J/3kb6/FrtmPjkS3EZNIgaBvcjuNGAGxLW+gLXWhsygKUN6yMy3P 5uBg2P9NxDu6cWOxKXarMrp7kPXM9T4d8nxo36jGn6jRs2bCEsA= =Cquk -----END PGP SIGNATURE----- --Apple-Mail=_349AF57B-4CCF-48AF-81D8-9D0A8B77F5E5-- From nobody Fri Jun 7 01:53:12 2019 Return-Path: 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 52C8F120100; Fri, 7 Jun 2019 01:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 QMtjGvFTIiH2; Fri, 7 Jun 2019 01:53:05 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [IPv6:2001:720:1710:601::42]) by ietfa.amsl.com (Postfix) with ESMTP id 3E0C8120266; Fri, 7 Jun 2019 01:53:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 6FF8220657; Fri, 7 Jun 2019 10:53:03 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon42.um.es Received: from xenon42.um.es ([127.0.0.1]) by localhost (xenon42.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 31eYWy-74hw3; Fri, 7 Jun 2019 10:53:03 +0200 (CEST) Received: from quantum.inf.um.es (quantum.inf.um.es [155.54.204.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon42.um.es (Postfix) with ESMTPSA id 70866206C7; Fri, 7 Jun 2019 10:52:59 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <88BE764B-BC37-45F2-ABA0-AA8367D02A08@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_FD56DD2B-757A-4255-9BD3-EB27EC0ADAA1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 7 Jun 2019 10:52:56 +0200 In-Reply-To: <23798.15513.517314.618936@fireball.acr.fi> Cc: Rafa Marin-Lopez , Paul Wouters , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , "i2nsf@ietf.org" , Gabriel Lopez , Linda Dunbar , "ipsec@ietf.org WG" To: Tero Kivinen References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> <23795.1716.390687.564153@fireball.acr.fi> <997AE9FE-F0EB-4148-96B7-16A138E92205@um.es> <23798.15513.517314.618936@fireball.acr.fi> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] [I2nsf] WGLC and IPR poll for draft-ietf-i2nsf-sdn-ipsec-flow-protection-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 08:53:09 -0000 --Apple-Mail=_FD56DD2B-757A-4255-9BD3-EB27EC0ADAA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tero: > El 4 jun 2019, a las 11:40, Tero Kivinen escribi=C3=B3:= >=20 > Rafa Marin-Lopez writes: >> Hi Tero, Paul: >>=20 >> El 2 jun 2019, a las 17:09, Paul Wouters = escribi=C3=B3: >>=20 >> On Sun, 2 Jun 2019, Tero Kivinen wrote: >>=20 >> I.e., if you have separate connections that share same = authenticated >> identity then you need to disable INITIAL_CONTACT = notifications. Also >> note that INITIAL_CONTACT is between identities, IP addresses, = inner >> addresses etc does not matter, only the authenticated = identities >> matter. >>=20 >> Sure, but "don't do that" :) >>=20 >> [Authors] Taking into account that road-warrior case is not = considered in the >> I-D (only host-to-host and gw-to-gw) and Paul=E2=80=99s comment I = think we can safely >> remove the leaf initial-contact, correct?. >=20 > The same setting is also used in case there is replicated setups, > i.e., every case where you might have two nodes sharing identity and > authentication information. Load balancing, hotswap setups, replicated > servers etc quite often also want to make sure they set this setting > on. >=20 > Those cases might be in scope for i2nsf too. [Authors] Then you propose to keep initial-contact, don=E2=80=99t you? >=20 >> Moreover the Security Controller is the one providing this identity = to the >> NSFs so I think this case would not be possible, would it?. >=20 > It depends. Security controller might provide same identity to both > load balancing nodes, or both to the in sgw in use and the hot swap > replicated version.=20 [Authors] So let=E2=80=99s keep the initial-contact node? >=20 >> Note, that AEAD counter is not in the sequence number field, = it is in >> the IV field, and every AEAD cipher RFC has text which = requires that >> IV field is generated in a way that ensures uniqueness. =46rom = RFC4309: >>=20 >> For now, but there are drafts going around that want to re-use the >> fields to save a few bytes :P >>=20 >> [Authors] Our model allows the Security Controller to set the IV in >> the SAD in the IKE-less case. >=20 > IV is per packet information, SC cannot really provide it. It can > provide initial value for it, but the updating of it must be done in > node. >=20 >> Well, the IKEv2 endpoint that cares about this can just re-key or >> re-auth in time before reaching those counters. So yes, it does = not >> need to be negotiated but it is the IKEv2 daemon handling this. So = for >> the IKE-less case, I guess it should be there, although this is = similar >> to the IKE-less case handling maxbytes, maxlife, maxidle counters. = I >> think it is expected that the NSF sends the kernel message (pfkey, >> acquire) to the SC. So it could be avoided in the IKEless case = than too. >>=20 >> [Authors] We have a doubt here: if the IKEv2 endpoint that cares = about this >> performs the re-key or re-auth, it needs to know when this event = happens. I >> guess IKEv2 implementation would be expecting a notification from the = kernel >> like xfrm_replay_notify(struct xfrm_state *x, int event) when a=20 >> xfrm_replay_overflow happens (see for example :=20 >> = ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/kernel-3.10.14= /net/xfrm/xfrm_replay.c = >> ) >>=20 >> is this correct? >=20 > IKEv2 will register suitable triggers to kernel, and kernel will then > use suitable method to notify IKEv2 when those timers, counters etc > are expiring. Not sure what those xfrm things do, as those are not > part of standard, but are internal implementation details for one > specific implementation. [Agree] Agree. =46rom your answer we understand that we should have a = notification for that anyway. We think that =E2=80=9Cexpire" = notification should be enough. Best Regards and thank you for your answers. >=20 > Usually IKEv2 will set packet counter triggers that will expire way > before the actual overflow happens, so it has time to rekey before the > hard expiration happens.=20 > --=20 > kivinen@iki.fi ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_FD56DD2B-757A-4255-9BD3-EB27EC0ADAA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tero:

El 4 jun 2019, a las 11:40, Tero Kivinen = <kivinen@iki.fi> = escribi=C3=B3:

Rafa = Marin-Lopez writes:
Hi Tero, Paul:

   El 2 jun 2019, a las 17:09, Paul Wouters = <paul@nohats.ca> = escribi=C3=B3:

   On Sun, 2 = Jun 2019, Tero Kivinen wrote:

       I.e., if you have = separate connections that share same authenticated
       identity then you = need to disable INITIAL_CONTACT notifications. Also
       note that = INITIAL_CONTACT is between identities, IP addresses, inner
       addresses etc does = not matter, only the authenticated identities
       matter.

   Sure, but "don't do that" = :)

[Authors] Taking into account that = road-warrior case is not considered in the
I-D (only = host-to-host and gw-to-gw) and Paul=E2=80=99s comment I think we can = safely
remove the leaf initial-contact, correct?.

The same setting is also used in case there is replicated = setups,
i.e., every = case where you might have two nodes sharing identity and
authentication information. Load = balancing, hotswap setups, replicated
servers etc quite often also want to make sure they set this = setting
on.

Those cases might be in scope = for i2nsf too.

[Authors] Then you propose to keep = initial-contact, don=E2=80=99t you?


Moreover the Security Controller is = the one providing this identity to the
NSFs so I think = this case would not be possible, would it?.
It depends. Security controller = might provide same identity to both
load balancing nodes, or both to the in sgw in use and the = hot swap
replicated = version. 

[Authors] So = let=E2=80=99s keep the initial-contact node?

       Note, that AEAD = counter is not in the sequence number field, it is in
       the IV field, and = every AEAD cipher RFC has text which requires that
       IV field is = generated in a way that ensures uniqueness. =46rom RFC4309:

   For now, but there are = drafts going around that want to re-use the
   fields to save a few bytes :P

[Authors] Our model allows the Security = Controller to set the IV in
the SAD in the IKE-less = case.

IV is per packet information, SC cannot really provide it. It = can
provide = initial value for it, but the updating of it must be done in
node.

   Well, the IKEv2 endpoint that cares about = this can just re-key or
   re-auth in time = before reaching those counters. So yes, it does not
   need to be negotiated but it is the IKEv2 = daemon handling this. So for
   the = IKE-less case, I guess it should be there, although this is similar
   to the IKE-less case handling maxbytes, = maxlife, maxidle counters. I
   think it is = expected that the NSF sends the kernel message (pfkey,
   acquire) to the SC. So it could be avoided = in the IKEless case than too.

[Authors] We = have a doubt here: if the IKEv2 endpoint that cares about this
performs the re-key or re-auth, it needs to know when this = event happens. I
guess IKEv2 implementation would be = expecting a notification from the kernel
like = xfrm_replay_notify(struct xfrm_state *x, int event) when a 
xfrm_replay_overflow happens (see for example : 
ftp://grids.be/mirror/ftp.ingenic.cn/DevSupport/Linux/Bison/ker= nel-3.10.14/net/xfrm/xfrm_replay.c
)

is this correct?

IKEv2 will register suitable = triggers to kernel, and kernel will then
use suitable method to notify IKEv2 when those timers, = counters etc
are expiring. = Not sure what those xfrm things do, as those are not
part of standard, but are = internal implementation details for one
specific implementation.

[Agree] Agree. =46rom your answer we understand that we = should have a notification for that anyway. We think that =E2=80=9Cexpire"= notification should be enough.

Best = Regards and thank you for your answers.

Usually IKEv2 will set packet counter triggers that will = expire way
before the = actual overflow happens, so it has time to rekey before the
hard expiration happens. 
-- 
kivinen@iki.fi

-------------------------------------------------------
Rafa Marin-Lopez, PhD
Dept. Information = and Communications Engineering (DIIC)
Faculty of = Computer Science-University of Murcia
30100 = Murcia - Spain
Telf: +34868888501 Fax: +34868884151 = e-mail: rafa@um.es
-------------------------------------------------------




= --Apple-Mail=_FD56DD2B-757A-4255-9BD3-EB27EC0ADAA1-- From nobody Thu Jun 20 06:52:16 2019 Return-Path: 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 CC66E120045 for ; Thu, 20 Jun 2019 06:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Ydgus_R_CQ_G for ; Thu, 20 Jun 2019 06:52:11 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89871120020 for ; Thu, 20 Jun 2019 06:52:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45V3CZ0StLzD0d for ; Thu, 20 Jun 2019 15:52:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1561038730; bh=8muboYTVfkYSOjD0dfqV8UWfeAOaaeKDPOAZcGm5kUc=; h=Date:From:To:Subject; b=cqyKdoXBEPSVrKClZAzRV6Yle2gPeEGihsfaZm3Y7r7qquW1VospU6J/ojdvgM1Xy fWuElD/58zirHGjDOcblH8tuCIqcvnqvBCB7yvSHtlYE8Sm9vD3rbP9ml//NkQCiez U//gTxg7+btBGjrj36zadeHzlGM0zyaAha2RDtTo= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id WgPPgj5bjFJ2 for ; Thu, 20 Jun 2019 15:52:08 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 20 Jun 2019 15:52:07 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B06904A46EF; Thu, 20 Jun 2019 09:52:06 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B06904A46EF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A88B9417255E for ; Thu, 20 Jun 2019 09:52:06 -0400 (EDT) Date: Thu, 20 Jun 2019 09:52:06 -0400 (EDT) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 13:52:14 -0000 Hi, We are having a discussion about which notify to return in certain cases. The issue comes down to the names of the notifies and their actual dictated use in the RFC that does not always intuitively maps to the name. NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec proposal list matches due to all proposals having at least one mismatching transform" versus "no matching ike connection for your IKE proposal" where proposal refers to the entire IKE proposal, not the proposals list with transforms. INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC text uses this as the "if all other errors dont match, use this one" so you can end up returning this even if there is no invalid syntax at all. So if your IPsec gateway only has static IP based VPNs and an unknown IP connects, some feel NO_PROPOSAL_CHOSEN conveys that, while technically, even though there is no invalid syntax in that proposal, the RFC states we should return INVALID_SYNTAX. Similarly, if during IKE_AUTH you are finding out there is no IPsec configuration that matches the incoming client, there is no "proposal list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural match, should we really return INVALID_SYNTAX despite there being no syntax problem? That is what the RFC says. I guess in the end, we are really missing a "CONNECTION_REJECTED" notify that would cover all the things not covered in the more specific notifies. What do other implementations do? Should we clarify this anywhere? libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now slated to be more strict to the RFC and use INVALID_SYNTAX. (and clearly, I'm not happy about it but it seems the RFC dictates this) Paul From nobody Thu Jun 20 07:40:07 2019 Return-Path: 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 0E08A12014B for ; Thu, 20 Jun 2019 07:39:58 -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_HELO_NONE=0.001, 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 zmgTKM1ZslQY for ; Thu, 20 Jun 2019 07:39:55 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 44E1D12013C for ; Thu, 20 Jun 2019 07:39:55 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id k18so2916587ljc.11 for ; Thu, 20 Jun 2019 07:39:55 -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=ex7Tji0YQBtDtChnQYFpJ674SMDy1ELwjbbzdNMzA3o=; b=Zg6OxxjTAx6TyyYsK04v+Cmym1mu45GhjurpoGaAbnb6nnYDi8xNnYZFTl1WFeigpQ D9kXXGgV/+hgpKBpgg7jxtIA7U2Kg4y5S+5Ca9/8r3XiM/NONoNiftjYzT1XooKKzLQc NQxBe+lvJBbO5ZYqY7Nbi7+wvW37ECLwJIKNKFQ0Sa4NYFtr6DaK+KW/p4GMIMmmIY/F pn0DlwhRJG431Ywoybo6Om56duGy74XWBQLIvUhUcQx1fGu1eNdjSmSEE8wS5CIqepWG lEMdFVqeIpmGZShewJsRT+X8WHhEsBfL7Em5BmEXcL4rhGvgEOOjOCVrAcpjWWc1+GPr RBtg== 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=ex7Tji0YQBtDtChnQYFpJ674SMDy1ELwjbbzdNMzA3o=; b=VhNfvoaOebUco1na9hHFZ20sEiewFEHTePf3wK3311nIhKLm8DTHHorfOCHtv69URZ +6C/d9lvXOdcqcZOxMShREFSYJztHV3RBc7DTUZiiJvg6zd347P8RHgBWmBWevMlqA/l GG6pkUXFmPJu6+txcjwt8204tueXdKTEvtWDzjYzpOtA3Mfw7Re18Zcugkz9au87M5dX +BCHnUAxtwcqtquhDs7XJyrXRJ7x+xQfCnOqUz8fhqMXYlF/k7omMbMityQfdaUhfz7d 9jssyvpHuP2XD4PGN0DgroY2SGXYYNgDRpt4WDQr2tRy9hrU5JV4bmDPkqEatXYhh0jz WkuQ== X-Gm-Message-State: APjAAAWBWbaVV2VKSpWDYzeZ7JroK5tjX/Vpd1v2+azUZVmMD2aJK4s/ MRJbF+9oXyL3ATUhLnAbgmwsbO0f X-Google-Smtp-Source: APXvYqw2HIvC0ft6ilhOwbXDo4oaOpN0xgIgqJPF3VRIZd5O3yykzRBqY+AgVPAKYmnmrbMzBTLjRQ== X-Received: by 2002:a2e:9158:: with SMTP id q24mr44765364ljg.119.1561041592543; Thu, 20 Jun 2019 07:39:52 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h10sm3172083lfj.10.2019.06.20.07.39.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 20 Jun 2019 07:39:51 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , References: In-Reply-To: Date: Thu, 20 Jun 2019 17:39:30 +0300 Message-ID: <028201d52775$f89a8230$e9cf8690$@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: AQMOVHCg7qEpa2o+m56j10GVVAXT7qQyP5gA Content-Language: ru Archived-At: Subject: Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 14:40:06 -0000 Hi Paul, generally the INVALID_SYNTAX must be returned when something fatal happened, that cannot be fixed by adjusting configuration etc., only re-installing app after bug-fixing would help. In contrast, NO_PROPOSAL_CHOSEN means that after some actions from operator the connection would succeed. > Hi, > > We are having a discussion about which notify to return in certain > cases. The issue comes down to the names of the notifies and their > actual dictated use in the RFC that does not always intuitively > maps to the name. > > NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec > proposal list matches due to all proposals having at least one mismatching > transform" versus "no matching ike connection for your IKE proposal" > where proposal refers to the entire IKE proposal, not the proposals > list with transforms. > > INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC text > uses this as the "if all other errors dont match, use this one" so you > can end up returning this even if there is no invalid syntax at all. > > So if your IPsec gateway only has static IP based VPNs and an unknown IP > connects, some feel NO_PROPOSAL_CHOSEN conveys that, while technically, > even though there is no invalid syntax in that proposal, the RFC states > we should return INVALID_SYNTAX. I'd rather not return anything in this case. > Similarly, if during IKE_AUTH you are finding out there is no IPsec > configuration that matches the incoming client, there is no "proposal > list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural > match, should we really return INVALID_SYNTAX despite there being no > syntax problem? That is what the RFC says. I'd return NO_PROPOSAL_CHOSEN. Regards, Valery. > I guess in the end, we are really missing a "CONNECTION_REJECTED" > notify that would cover all the things not covered in the more specific > notifies. > > What do other implementations do? Should we clarify this anywhere? > > libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now > slated to be more strict to the RFC and use INVALID_SYNTAX. (and > clearly, I'm not happy about it but it seems the RFC dictates this) > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Jun 20 08:52:25 2019 Return-Path: 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 0BE6F12011E for ; Thu, 20 Jun 2019 08:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 235xIyY1wqCL for ; Thu, 20 Jun 2019 08:52:21 -0700 (PDT) Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4C512010F for ; Thu, 20 Jun 2019 08:52:21 -0700 (PDT) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x5KFq3Le065113; Thu, 20 Jun 2019 08:52:19 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=DDmiGLnXUzIlT6CMd21HpHCug40PsNVvNvmdQQvAGg0=; b=kCDKoUiPqId3obwV9ZYHzXAXKSF53etthSMvQPygAiL1alr/h9zrwW9mgThoUUouSTJt M6RVEAKFSrFVXfHX+wOn47y8filpw9gZBJp941y6Wu95RRBFrmhTyC3XR+CKtstPIdAd UaO8oeex9jG08JTT1lqQuVdqfEHDl2P69bfzLRZndPQgC24oSCoRGP3/d53JD4Bejd0s TYk2jVBgTtuwnsrnVxmrXO9mKrCx+omnubDJ/Ngo5+9UHmsfZm8gce4XBjo3Jga/0k4E mzMwqdRM7Gk1KNviqboHv7RORvBBUbmYJ1ENNVXqjF+pLO9k42jcW0Gb6CwMzy1h2A4+ Qg== Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2t820utvyh-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 20 Jun 2019 08:52:19 -0700 MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dg5yK3BhD6x8JOGy9LRgxg)" Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PTE00HGTMR2ZA80@mr2-mtap-s03.rno.apple.com>; Thu, 20 Jun 2019 08:52:15 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PTE00000MFHV100@nwk-mmpp-sz13.apple.com>; Thu, 20 Jun 2019 08:52:14 -0700 (PDT) X-Va-A: X-Va-T-CD: 6fac4ea4ce1268ab8f029544b781c2d5 X-Va-E-CD: 1f559111330cf8762e01d43a53052495 X-Va-R-CD: 061c326c74df9fe43e37225ff7ccc6c7 X-Va-CD: 0 X-Va-ID: 9b55545f-675f-4327-899c-21ad1ecbfb1f X-V-A: X-V-T-CD: 6fac4ea4ce1268ab8f029544b781c2d5 X-V-E-CD: 1f559111330cf8762e01d43a53052495 X-V-R-CD: 061c326c74df9fe43e37225ff7ccc6c7 X-V-CD: 0 X-V-ID: 623f3e01-f375-41b7-bff1-f749a2f7bb52 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-06-20_11:,, signatures=0 Received: from [17.230.151.181] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PTE00JOWMQKI120@nwk-mmpp-sz13.apple.com>; Thu, 20 Jun 2019 08:51:57 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Thu, 20 Jun 2019 08:51:45 -0700 In-reply-to: <028201d52775$f89a8230$e9cf8690$@gmail.com> Cc: "ipsec@ietf.org WG" To: Valery Smyslov , Paul Wouters References: <028201d52775$f89a8230$e9cf8690$@gmail.com> X-Mailer: Apple Mail (2.3445.104.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-20_11:, , signatures=0 Archived-At: Subject: Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 15:52:24 -0000 --Boundary_(ID_dg5yK3BhD6x8JOGy9LRgxg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT It does seem to a question open to interpretation by the implementation. I think you can make a good argument for NO_PROPOSAL_CHOSEN in both cases. If your implementation interprets things as always getting a list of valid proposal values based on the remote address or ID, then any unknown client would match the empty list of proposals. Thanks, Tommy > On Jun 20, 2019, at 7:39 AM, Valery Smyslov wrote: > > Hi Paul, > > generally the INVALID_SYNTAX must be returned when something > fatal happened, that cannot be fixed by adjusting configuration etc., > only re-installing app after bug-fixing would help. > In contrast, NO_PROPOSAL_CHOSEN means that after some actions from > operator the connection would succeed. > >> Hi, >> >> We are having a discussion about which notify to return in certain >> cases. The issue comes down to the names of the notifies and their >> actual dictated use in the RFC that does not always intuitively >> maps to the name. >> >> NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec >> proposal list matches due to all proposals having at least one mismatching >> transform" versus "no matching ike connection for your IKE proposal" >> where proposal refers to the entire IKE proposal, not the proposals >> list with transforms. >> >> INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC text >> uses this as the "if all other errors dont match, use this one" so you >> can end up returning this even if there is no invalid syntax at all. >> >> So if your IPsec gateway only has static IP based VPNs and an unknown IP >> connects, some feel NO_PROPOSAL_CHOSEN conveys that, while technically, >> even though there is no invalid syntax in that proposal, the RFC states >> we should return INVALID_SYNTAX. > > I'd rather not return anything in this case. > >> Similarly, if during IKE_AUTH you are finding out there is no IPsec >> configuration that matches the incoming client, there is no "proposal >> list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural >> match, should we really return INVALID_SYNTAX despite there being no >> syntax problem? That is what the RFC says. > > I'd return NO_PROPOSAL_CHOSEN. > > Regards, > Valery. > >> I guess in the end, we are really missing a "CONNECTION_REJECTED" >> notify that would cover all the things not covered in the more specific >> notifies. >> >> What do other implementations do? Should we clarify this anywhere? >> >> libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now >> slated to be more strict to the RFC and use INVALID_SYNTAX. (and >> clearly, I'm not happy about it but it seems the RFC dictates this) >> >> Paul >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_dg5yK3BhD6x8JOGy9LRgxg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable It = does seem to a question open to interpretation by the = implementation.

I = think you can make a good argument for NO_PROPOSAL_CHOSEN in both = cases. If your implementation interprets things as always getting a list = of valid proposal values based on the remote address or ID, then any = unknown client would match the empty list of proposals.
Thanks,
Tommy

On Jun 20, 2019, at 7:39 AM, Valery Smyslov <smyslov.ietf@gmail.com> wrote:

Hi Paul,

generally the INVALID_SYNTAX = must be returned when something
fatal happened, that cannot be fixed by adjusting = configuration etc.,
only re-installing app after bug-fixing would help.
In contrast, NO_PROPOSAL_CHOSEN = means that after some actions from 
operator the connection would = succeed.

Hi,

We are having a discussion about which notify = to return in certain
cases. The issue comes down to the = names of the notifies and their
actual dictated use in the = RFC that does not always intuitively
maps to the name.

NO_PROPOSAL_CHOSEN can be interpreted as "no = proposal from the IKE/IPsec
proposal list matches due to = all proposals having at least one mismatching
transform" = versus "no matching ike connection for your IKE proposal"
where proposal refers to the entire IKE proposal, not the = proposals
list with transforms.

INVALID_SYNTAX can be interpreted as "malformed packet" but = the RFC text
uses this as the "if all other errors dont = match, use this one" so you
can end up returning this even = if there is no invalid syntax at all.

So if = your IPsec gateway only has static IP based VPNs and an unknown IP
connects, some feel NO_PROPOSAL_CHOSEN conveys that, while = technically,
even though there is no invalid syntax in = that proposal, the RFC states
we should return = INVALID_SYNTAX.

I'd rather not return anything in this case.

Similarly, if during IKE_AUTH you are finding out there is no = IPsec
configuration that matches the incoming client, = there is no "proposal
list" to compare, so while = NO_PROPOSAL_CHOSEN feels a more natural
match, should we = really return INVALID_SYNTAX despite there being no
syntax = problem? That is what the RFC says.

I'd return = NO_PROPOSAL_CHOSEN.

Regards,
Valery.

I guess in the end, we are really = missing a "CONNECTION_REJECTED"
notify that would cover = all the things not covered in the more specific
notifies.
What do other implementations do? Should we = clarify this anywhere?

libreswan was using = NO_PROPOSAL_CHOSEN for most of these, but is now
slated to = be more strict to the RFC and use INVALID_SYNTAX. (and
clearly, I'm not happy about it but it seems the RFC dictates = this)

Paul

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

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

= --Boundary_(ID_dg5yK3BhD6x8JOGy9LRgxg)-- From nobody Thu Jun 20 12:01:09 2019 Return-Path: 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 03D311201E0 for ; Thu, 20 Jun 2019 12:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 pwRZYYfItAtj for ; Thu, 20 Jun 2019 12:00:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E6912017E for ; Thu, 20 Jun 2019 12:00:54 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 4239E38185 for ; Thu, 20 Jun 2019 14:59:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 6A5AF12EB; Thu, 20 Jun 2019 15:00:52 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 67B5B560 for ; Thu, 20 Jun 2019 15:00:52 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <028201d52775$f89a8230$e9cf8690$@gmail.com> References: <028201d52775$f89a8230$e9cf8690$@gmail.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 19:01:08 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > generally the INVALID_SYNTAX must be returned when something fatal > happened, that cannot be fixed by adjusting configuration etc., only > re-installing app after bug-fixing would help. In contrast, > NO_PROPOSAL_CHOSEN means that after some actions from operator the > connection would succeed. I agree that INVALID_SYNTAX should be about things you can't fix by configuration. I also agree with Paul: paul> I guess in the end, we are really missing a "CONNECTION_REJECTED" paul> notify that would cover all the things not covered in the more paul> specific notifies. I would like some more fine-grained replies as well. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0L1+MACgkQgItw+93Q 3WUnqgf+IssgPk8y9ZP+Hh27bWrNSo3OGkXb65K6olxUdFRvh6wpWL6/LuhUP6Fd L/GfjGjRlP8zKwi6/ffuj5YXgThrhqd/4FVH3YcB6AqonNRbcSAYGTNpSFbnaZmA 8FgMsnQiMYP/hXHaeBbwuh7yHxVLG7Cikagpt5gNajy7rmrXiB3ickrqUJnRJfci bTWReglKA2j6JufsE9G3TMpF0WNB1kvqBpmxpP5tm7gTjksFQxTD0BTsot2k5kf5 1ypxbxtkFLlQ9p3j40ejYxxPwsafrwnZQvFOSgQbaQchdzjBY/16/8VrK5GRq3sZ ESEr2OnIBzdSpxNWEKxY52Ja6ICkpA== =NfBZ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 20 13:51:57 2019 Return-Path: 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 3A2861201EE for ; Thu, 20 Jun 2019 13:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 1hSHv6jPIwaB for ; Thu, 20 Jun 2019 13:51:53 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 038661201E4 for ; Thu, 20 Jun 2019 13:51:53 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id c2so4378501wrm.8 for ; Thu, 20 Jun 2019 13:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+kGycsozSQ9OvbyO+oDeNCeUyqi57hXU4IAvGk6eoYI=; b=Iu9uK3fztgT+Owa3/1d+BtPYD4Y33Q6ESlPlOVCd8NqGawpecFQLQmlFMmtPWATjGd A4KO4G4K/wDNmBGAHiEclGuIKApXELei8eN435g3ZNqF3zfrZUDWYHEvqPfCIBuul3KF cznvcrr90wTxgYcm6c6zOekfijH6oV06GqKUc8Dg5FXNuIXHARXzKNaqUY4uw+mXiTKZ VFqh5RiwC2yaPNQ33tKagRrwR3vZJG+AjjVFtI2Y/xq6qIL7Ic6gQjpxz2CzLkged67w dkNww0uHurFA+v4RpB+D+3iaSm65ovvD4N99dR/V7OK1ZiNdtOStmLTZA/jqcROU6amq +p0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+kGycsozSQ9OvbyO+oDeNCeUyqi57hXU4IAvGk6eoYI=; b=l8OcEmBACB2FrPAgd6Gr+c718ylA+nr1ZYKyXPF7I6BhGLoXCSM6if3u73FyzMQ1ax v42SaNQbfxyx7D0cNiiQHy9FANDzkNoQUXzN0MstGaXDD55gYVfhvkAAPjwwrVVW6YxL sZy2mzPi3eDcuf8yARx1YGk6AbYpSfPS38ipb+HuSKQQfCdllZiHLixuHp1oQB8zspDf 8/1ZNNQRG3sdZBOstPu4dgQfxOSovRJRhS0BdeRNMc4mtGhjEU0QDLtt12HA5XIDk2yd aClOjcX0kCggOPtiJIQSD5mrzIX2NBVvWi5NHfFShKdn5YASFaakWMQ+m7igclw5VWl3 sasg== X-Gm-Message-State: APjAAAW4RhIUD7/TXa/5hV21Xy8dSwG1qpLjAnt2FcK9xZtfBqUf/i3B 55ilawneSjYeu5kePRHsyJo= X-Google-Smtp-Source: APXvYqzJSB1jc1F2g0nl1Y1z3RI5q1jGElGAF6/CYZn64twk4VRjzLWuer06kZDC8m47FQK/xxKJRg== X-Received: by 2002:adf:f909:: with SMTP id b9mr61687594wrr.119.1561063911499; Thu, 20 Jun 2019 13:51:51 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id d18sm1380095wrb.90.2019.06.20.13.51.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jun 2019 13:51:50 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Yoav Nir In-Reply-To: Date: Thu, 20 Jun 2019 23:51:48 +0300 Cc: "ipsec@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <54816C88-2B2D-4AAD-A906-DF628D4BA946@gmail.com> References: To: Paul Wouters X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 20:51:55 -0000 In the days when I had an IKEv2 implementation, NO_PROPOSAL_CHOSEN was = the go-to error code for everything the Responder didn=E2=80=99t like; = wrong algorithms, wrong transforms (like transport instead of tunnel), = unknown peer,=20 INVALID_SYNTAX meant something like malformed packet. > On 20 Jun 2019, at 16:52, Paul Wouters wrote: >=20 >=20 > Hi, >=20 > We are having a discussion about which notify to return in certain > cases. The issue comes down to the names of the notifies and their > actual dictated use in the RFC that does not always intuitively > maps to the name. >=20 > NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the = IKE/IPsec > proposal list matches due to all proposals having at least one = mismatching > transform" versus "no matching ike connection for your IKE proposal" > where proposal refers to the entire IKE proposal, not the proposals > list with transforms. >=20 > INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC = text > uses this as the "if all other errors dont match, use this one" so you > can end up returning this even if there is no invalid syntax at all. >=20 > So if your IPsec gateway only has static IP based VPNs and an unknown = IP > connects, some feel NO_PROPOSAL_CHOSEN conveys that, while = technically, > even though there is no invalid syntax in that proposal, the RFC = states > we should return INVALID_SYNTAX. >=20 > Similarly, if during IKE_AUTH you are finding out there is no IPsec > configuration that matches the incoming client, there is no "proposal > list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural > match, should we really return INVALID_SYNTAX despite there being no > syntax problem? That is what the RFC says. >=20 > I guess in the end, we are really missing a "CONNECTION_REJECTED" > notify that would cover all the things not covered in the more = specific > notifies. >=20 > What do other implementations do? Should we clarify this anywhere? >=20 > libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now > slated to be more strict to the RFC and use INVALID_SYNTAX. (and > clearly, I'm not happy about it but it seems the RFC dictates this) >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Jun 22 03:03:53 2019 Return-Path: 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 46FE7120048 for ; Sat, 22 Jun 2019 03:03:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no 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 PSB5e2Cr6_OG for ; Sat, 22 Jun 2019 03:03:49 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D2012006F for ; Sat, 22 Jun 2019 03:03:48 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x5MA3kYA010233 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 22 Jun 2019 13:03:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x5MA3k5f020157; Sat, 22 Jun 2019 13:03:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23821.64770.290809.680244@fireball.acr.fi> Date: Sat, 22 Jun 2019 13:03:46 +0300 From: Tero Kivinen To: Paul Wouters Cc: "ipsec\@ietf.org WG" In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Archived-At: Subject: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 10:03:51 -0000 Paul Wouters writes: > NO_PROPOSAL_CHOSEN can be interpreted as "no proposal from the IKE/IPsec > proposal list matches due to all proposals having at least one mismatching > transform" versus "no matching ike connection for your IKE proposal" > where proposal refers to the entire IKE proposal, not the proposals > list with transforms. Note, that this includes cases where the list of acceptable proposals is EMPTY because you do not allow any connections from that host. > INVALID_SYNTAX can be interpreted as "malformed packet" but the RFC text > uses this as the "if all other errors dont match, use this one" so you > can end up returning this even if there is no invalid syntax at all. If both implementations work correctly you should NEVER send INVALID_SYNTAX error. That always means there is programming error in one of the implementations. > So if your IPsec gateway only has static IP based VPNs and an unknown IP > connects, some feel NO_PROPOSAL_CHOSEN conveys that, while technically, > even though there is no invalid syntax in that proposal, the RFC states > we should return INVALID_SYNTAX. Correct error code is NO_PROPOSAL_CHOSEN as you use unknown IP to do policy lookup, find empty list of acceptable proposals to match against what other end sent, and of course empty list does not match, so you do not have any proposal that matches, meaning you return NO_PROPOSAL_CHOSEN. > Similarly, if during IKE_AUTH you are finding out there is no IPsec > configuration that matches the incoming client, there is no "proposal > list" to compare, so while NO_PROPOSAL_CHOSEN feels a more natural > match, should we really return INVALID_SYNTAX despite there being no > syntax problem? That is what the RFC says. In that case you do have proposal list, but that list is empty. And empty list does not match and you return NO_PROPOSAL_CHOSEN. > I guess in the end, we are really missing a "CONNECTION_REJECTED" > notify that would cover all the things not covered in the more specific > notifies. We discussed this, but decided that we want to keep error codes limited, not to leak out information what is wrong in the configuration. So you get same NO_PROPOSAL_CHOSEN error notification regardless whether your algorithm list does not match, or whether the ip is unknown, or whether the identity of the other end is unknown. > What do other implementations do? Should we clarify this anywhere? Use NO_PROPOSAL_CHOSEN every time if there is something that could be fixed by changing configuration in implementations. Use INVALID_SYNTAX if error is something that is against RFC, and even if configuration is changed you can never accept such message ever. For example if whole SA payload is missing you send INVALID_SYNTAX, if some mandatory transform types are missing that is NO_PROPOSAL_CHOSEN. > libreswan was using NO_PROPOSAL_CHOSEN for most of these, but is now > slated to be more strict to the RFC and use INVALID_SYNTAX. (and > clearly, I'm not happy about it but it seems the RFC dictates this) No, the RFC does not dictate that. -- kivinen@iki.fi From nobody Sun Jun 23 16:27:31 2019 Return-Path: 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 72655120253 for ; Sun, 23 Jun 2019 16:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 AJMMrTUikdsG for ; Sun, 23 Jun 2019 16:27:27 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AF8E1200F1 for ; Sun, 23 Jun 2019 16:27:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45X7qw3ppbzDmq; Mon, 24 Jun 2019 01:27:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1561332444; bh=RQlEis/KkF8tcHlAg8hKHoWRVV4HyZ8iL02gVc6sPsc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=WktaThp2psC6Zl80oHqPfz+9TKu6m/g4i7QfLyWuiGFrf6j7lDsl09LNPWlXvmuW7 1BNwPcNocyGqPrtJKSNldfumYUgLc20AuzlmYO3OHK22MZ2HwU3hyUrOvs4llztoSg JUUtaC5l80Am+dKPOZnFFDW6A/29+tqjAfHlozfU= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id HIgIpjFj2JCy; Mon, 24 Jun 2019 01:27:23 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 24 Jun 2019 01:27:22 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8A2BF4A46EA; Sun, 23 Jun 2019 19:27:21 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8A2BF4A46EA Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 77C6540D35BF; Sun, 23 Jun 2019 19:27:21 -0400 (EDT) Date: Sun, 23 Jun 2019 19:27:21 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: "ipsec@ietf.org WG" In-Reply-To: <23821.64770.290809.680244@fireball.acr.fi> Message-ID: References: <23821.64770.290809.680244@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] NO_PROPOSAL_CHOSEN vs INVALID_SYNTAX X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2019 23:27:29 -0000 On Sat, 22 Jun 2019, Tero Kivinen wrote: > If both implementations work correctly you should NEVER send > INVALID_SYNTAX error. That always means there is programming error in > one of the implementations. > Correct error code is NO_PROPOSAL_CHOSEN as you use unknown IP to do > policy lookup, find empty list of acceptable proposals to match > against what other end sent, and of course empty list does not match, > so you do not have any proposal that matches, meaning you return > NO_PROPOSAL_CHOSEN. Thanks to the group for the various explanations. I've changed our return code back to NO_PROPOSAL_CHOSEN. Paul From nobody Thu Jun 27 01:31:44 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F46120110; Thu, 27 Jun 2019 01:31:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <156162430314.21616.575950570339313589@ietfa.amsl.com> Date: Thu, 27 Jun 2019 01:31:43 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 08:31:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Intermediate Exchange in the IKEv2 Protocol Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-intermediate-01.txt Pages : 10 Date : 2019-06-27 Abstract: This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE Fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-01 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jun 27 01:34:53 2019 Return-Path: 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 68C56120140 for ; Thu, 27 Jun 2019 01:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.498 X-Spam-Level: X-Spam-Status: No, score=-0.498 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_HELO_NONE=0.001, 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 vfOLs0CI4pqi for ; Thu, 27 Jun 2019 01:34:49 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 7A2FD120110 for ; Thu, 27 Jun 2019 01:34:49 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id x144so963956lfa.9 for ; Thu, 27 Jun 2019 01:34:49 -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=ZoOY63XYPiok8MWC+wHe/+lrKCOGzRcFLHKErZjMEAs=; b=ghwRmsJyIrHxnLbfynggHjCgQuR6x1FV9YvabgdIX6cFn6nvF+zcJ2r9m+Mr666aij i1T4/gF7KPyamXPJ5SPKkNpGRDweu5koGcLRcAaEeIj8bzOp7M2tA8pi0ci5/XEN1818 DnTIu9ausZkklivpf2c50ua8sz6AjTTQHb0RWaOcnaDN/TBDQ4Lvy+PsybqG0mTMJNZT c4A5CzB4NR2U5qGPF9AW7RIcE4P7MNmX393Mh++LXb7FJJzhNpAR60jHF1U50zMNxvAq nvae5fwWJB8DLf/QSJpjwDZTMvXvjSNvprtUlRgwFZiPA3hImx2F1+4WAos0C4DMJhXg nATw== 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=ZoOY63XYPiok8MWC+wHe/+lrKCOGzRcFLHKErZjMEAs=; b=ImB7+F6DXL2q0OgmERDjEgpq0jNtMyy25WvN92lG/SHQ21DcD5GEP8+wkQwQPf2uMb 3wp62/903/tY4dGrFJcMedhSUK1Fp45703Beh8/cZQnK1sB7iZ7vPylvOgZ++SZmxRzt 9WXT/U1kjSwI97Yknc4oPmM+VAKEDOUF3FgfNcE/b0qqQ6rHsTXWx2vykxKCEYdCTNxd 93DDtVKY9uYAeiMuuPgHBkxLkUfVGML8mo0HEG1Fnedea9+Owqvd2MZXlqYcssA3JulG oiMtr38mAgMHnuKwRCclejIt9lOeMi9ByY621AEZF7tpRvR4cyJt6cl+yY8msLvzI8M+ 9UeQ== X-Gm-Message-State: APjAAAUmmUdLscnKyNW8Q70aEWE8VZsvYoRFEWllo/ICmw5VxZOZDUgu 2PSY6MH+/PUBn9CHxZLPJ+NTfWwB X-Google-Smtp-Source: APXvYqwpjFoE80fspknCrGsEz/FUNS0ckmyVzoOBBeqDebsZjIxEzB+ROhsULVuyLq6p6WbUtfc8MA== X-Received: by 2002:a19:5007:: with SMTP id e7mr1487607lfb.76.1561624487458; Thu, 27 Jun 2019 01:34:47 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id o74sm230998lff.46.2019.06.27.01.34.46 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 27 Jun 2019 01:34:46 -0700 (PDT) From: "Valery Smyslov" To: References: <156162430314.21616.575950570339313589@ietfa.amsl.com> In-Reply-To: <156162430314.21616.575950570339313589@ietfa.amsl.com> Date: Thu, 27 Jun 2019 11:34:02 +0300 Message-ID: <012b01d52cc3$1373d1e0$3a5b75a0$@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: AQM9SRwx7yqfhgf90zk3p0fld82dlaPe8z8w Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 08:34:51 -0000 Hi, a new (-01) version of IKE_INTERMEDIATE draft is published. It only clarifies that in case of IKE SA resumption a support for IKE_INTERMEDIATE should be renegotiated (i.e. it is not stored in the resumption ticket). Regards, Valery. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : Intermediate Exchange in the IKEv2 Protocol > Author : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-intermediate-01.txt > Pages : 10 > Date : 2019-06-27 > > Abstract: > This documents defines a new exchange, called Intermediate Exchange, > for the Internet Key Exchange protocol Version 2 (IKEv2). This > exchange can be used for transferring large amount of data in the > process of IKEv2 Security Association (SA) establishment. > Introducing Intermediate Exchange allows re-using existing IKE > Fragmentation mechanism, that helps to avoid IP fragmentation of > large IKE messages, but cannot be used in the initial IKEv2 exchange. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-01 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Jun 28 16:02:44 2019 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5012912099C; Fri, 28 Jun 2019 15:58:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ipsec@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176268132.11015.9045367728071473653.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:58:01 -0700 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 105 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 22:58:15 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:30 requested) Tuesday, 23 July 2019, Afternoon Session II 1520-1650 Room Name: Sainte-Catherine size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/ipsecme.ics Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: sacm mile tcpinc curdle tls saag cfrg i2nsf Second Priority: 6tisch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Tero Kivinen David Waltermire Benjamin Kaduk Resources Requested: Special Requests: ---------------------------------------------------------