From nobody Thu May 2 11:25: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 527D1120075 for ; Thu, 2 May 2019 11:25:18 -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, URIBL_BLOCKED=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 qE2m9zmf9hLr for ; Thu, 2 May 2019 11:25:16 -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 E5960120099 for ; Thu, 2 May 2019 11:25:15 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44w3bF3dXNzKyp; Thu, 2 May 2019 20:25:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1556821513; bh=tK6vYgxJwSjJ+zRwoPzuXhB5B+5uBuVcGuUwJz0v2AI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gRAs/E8QvdjXO0d2OmXlzoot1t/rzhjSttl/JxKS2OpkWPqsD3eoaTWpb1VPTDPem KnsyIYbfDBr+TfsWjgbr3cCvIb9UaAdi+HOv/U2QzuYhO3wo7zFB06pWltDiUrCuiF J7QAkQX6aP7PxW2yx5cEYf5Y+DkVb8m7f4IgP9tM= 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 Z4nOmkFUfuG4; Thu, 2 May 2019 20:25:11 +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; Thu, 2 May 2019 20:25:11 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 855C23A797B; Thu, 2 May 2019 14:25:10 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 855C23A797B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7880E4027A8E; Thu, 2 May 2019 14:25:10 -0400 (EDT) Date: Thu, 2 May 2019 14:25:10 -0400 (EDT) From: Paul Wouters To: mohamed.boucadair@orange.com cc: "ipsec@ietf.org" In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA67EB7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Message-ID: References: <23734.7331.402882.289451@fireball.acr.fi> <01b201d4f4f1$e617eb90$b247c2b0$@gmail.com> <636D1D4B-3E3F-47F1-B64C-A266BF871010@nohats.ca> <787AE7BB302AE849A7480A190F8B93302EA67B69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA67EB7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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] Draft-ietf-ipsecme-ipv6-ipv4-codes 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, 02 May 2019 18:25:19 -0000 On Tue, 30 Apr 2019, mohamed.boucadair@orange.com wrote: >> Why would the initiator that is allowed by policy to do both v4 and v6 >> not ask for both at once? > > [Med] I do fully agree that requesting both when supported would be straightforward, but I'm afraid that some implementations may not follow that behavior. Do we currently have a large scale implementation issue, or are you predicting that this may happen in the future. While I am okay with doing it if it fixes a large deployment issue, I'm not okay with it to pre-emptively support expected implementation issues. > Such implementations may do that: > * for arbitrary reasons given that existing specs do not forbid such separate requests. So what is the problem with bad implementations doing bad things? Why would this notify tell them to do things differently next time? > * or, in some contexts such cellular devices, mimic a similar behavior for requesting separate PDP contexts instead of a dual-stack one. Is this actually happening at scale, or is this just a feared bad way things will get implemented? >> I don't see the "use of separate requests" as a real use case. Can you >> explain how this would actually happen in a real world? > > [Med] See the cases above. There is also the case of a responder that wants (for policy reasons) requests to be made as separate IKE SAs. For this case, requests will need to be done separately. If the "policy reason" is there, why would a notify change their behaviour? If they are already sending a v4 and a separate v6 request, what value does the notify add? Paul From nobody Thu May 2 11:28:33 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 9D78D120125 for ; Thu, 2 May 2019 11:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 6lzJUrT_GMvL for ; Thu, 2 May 2019 11:28:30 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 2F348120099 for ; Thu, 2 May 2019 11:28:30 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44w3g02Lnqz72r; Thu, 2 May 2019 20:28:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1556821708; bh=2PxJesZUe+3pcnjSuv2lZRf84qN42AOs/wIAuyPxbwk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Qe0Gyen5ZtfrbTJNlZCjJSEsDjt/yZ5zJqPp//A0euDEYuGgv5KA6oSF263gtQl0L L+/I7eixdkWz+LMcSbMjDizCtyBEjZp7YuRMQVqVnsUvY1O5tsHB3Rb/8b5hkJQ8DQ HtvuY3a0PUAp3lmM6LDtcL8LH+AonSBw8xykO7b8= 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 YfaZALFtAPZ5; Thu, 2 May 2019 20:28: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; Thu, 2 May 2019 20:28:25 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9BEC73A797B; Thu, 2 May 2019 14:28:24 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9BEC73A797B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 92DBA4027A8E; Thu, 2 May 2019 14:28:24 -0400 (EDT) Date: Thu, 2 May 2019 14:28:24 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: ipsec@ietf.org, 'Tero Kivinen' In-Reply-To: <00c001d4ff1b$62c87050$285950f0$@gmail.com> Message-ID: References: <23734.7331.402882.289451@fireball.acr.fi> <01b201d4f4f1$e617eb90$b247c2b0$@gmail.com> <636D1D4B-3E3F-47F1-B64C-A266BF871010@nohats.ca> <00c001d4ff1b$62c87050$285950f0$@gmail.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes 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, 02 May 2019 18:28:32 -0000 On Tue, 30 Apr 2019, Valery Smyslov wrote: >> I would prefer no notify if the request was fulfilled and to only send a notify if a request could not be fulfilled. >> Since clients can ask for both that should cover things. If a client isn’t asking for ipvX, I see no need to answer >> that ipvX is supported too. > > That would make sending these notifies dependent on the content of request. > So, the tradeoff is whether saving eight bytes justifies complication of state machine. I wouldn't call that complicated the state machine. You are not adding new states or transitions, and you already keep a list of received payloads for this state/exchange I hope :P Paul From nobody Thu May 2 23:58:00 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 B828B120044 for ; Thu, 2 May 2019 23:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 uabCptRHw49a for ; Thu, 2 May 2019 23:57:55 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D19F12006B for ; Thu, 2 May 2019 23:57:55 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 44wNHj3tQCz5wlt; Fri, 3 May 2019 08:57:53 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 44wNHj2z6zz2xCJ; Fri, 3 May 2019 08:57:53 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Fri, 3 May 2019 08:57:53 +0200 From: To: Paul Wouters CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes Thread-Index: AQHU/qYb3HfUY8UNAEyhkEccw2niI6ZUOIFAgABdCwCAACGpIIADUrcAgADu0QA= Date: Fri, 3 May 2019 06:57:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA6A854@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <23734.7331.402882.289451@fireball.acr.fi> <01b201d4f4f1$e617eb90$b247c2b0$@gmail.com> <636D1D4B-3E3F-47F1-B64C-A266BF871010@nohats.ca> <787AE7BB302AE849A7480A190F8B93302EA67B69@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <787AE7BB302AE849A7480A190F8B93302EA67EB7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes 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, 03 May 2019 06:57:58 -0000 Hi Paul,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Paul Wouters [mailto:paul@nohats.ca] > Envoy=E9=A0: jeudi 2 mai 2019 20:25 > =C0=A0: BOUCADAIR Mohamed TGI/OLN > Cc=A0: ipsec@ietf.org > Objet=A0: Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes >=20 > On Tue, 30 Apr 2019, mohamed.boucadair@orange.com wrote: >=20 > >> Why would the initiator that is allowed by policy to do both v4 and v6 > >> not ask for both at once? > > > > [Med] I do fully agree that requesting both when supported would be > straightforward, but I'm afraid that some implementations may not follow = that > behavior. >=20 > Do we currently have a large scale implementation issue, or are you > predicting that this may happen in the future. While I am okay with > doing it if it fixes a large deployment issue, I'm not okay with it > to pre-emptively support expected implementation issues. >=20 > > Such implementations may do that: > > * for arbitrary reasons given that existing specs do not forbid such > separate requests. >=20 > So what is the problem with bad implementations doing bad things? [Med] This may double the load on the responder. Sending systematically a s= econd request while a responder will discard it because it does support onl= y one AF is suboptimal (think about IPv6-only voice over WLAN for example). Why > would this notify tell them to do things differently next time? [Med] The notification message will provide an information to the initiator= whether it is useful or not to send a request for the other AF. >=20 > > * or, in some contexts such cellular devices, mimic a similar behavior = for > requesting separate PDP contexts instead of a dual-stack one. >=20 > Is this actually happening at scale, or is this just a feared bad way > things will get implemented? >=20 > >> I don't see the "use of separate requests" as a real use case. Can you > >> explain how this would actually happen in a real world? > > > > [Med] See the cases above. There is also the case of a responder that w= ants > (for policy reasons) requests to be made as separate IKE SAs. For this ca= se, > requests will need to be done separately. >=20 > If the "policy reason" is there, why would a notify change their > behaviour? If they are already sending a v4 and a separate v6 > request, what value does the notify add? [Med] I'm not sure to understand your comment. The policy is at the respond= er side. The responder will honor one AF per request. Returning the support= ed AFs to the initiator will trigger a separate request from the initiator = to get the other AF (if needed).=20 >=20 > Paul From nobody Sun May 5 23:02: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 4B04412009E for ; Sun, 5 May 2019 23:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLdnFC8QPpz9 for ; Sun, 5 May 2019 23:02:09 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 CAE07120096 for ; Sun, 5 May 2019 23:02:08 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id z124so2083433lfd.6 for ; Sun, 05 May 2019 23:02:08 -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=Fzx2h2dINoIne6XQ0fxHMONWTIstMJd+RnWtA/nmSQE=; b=k2hNWmpn9CdNLexTliQ9MKP0HZK1/BQPVjf23JvHF7OxIKaOQH3Zmx2fRGRCcUsD1m JCihdjCGhcMDdIoZGJ+yFUMk+mxKOrhHUTZ0c/pi5ZBJ5s0vZs8jyhLSzltUI0kMl3LR iDdiYnLh2XdjLL20R1bVufwVgDxhhCvM/Fhlg/n1ZNTVB/VVt3jtseA2dfH7N3qVLMrt dq2dbFdx5D/t19+XKQfNxLykvdTk3Ti/nFfboJvYT9XpaF47Kb7NGpO0oSBE4ScRyl/o ZZqGYRk0qcZHmCVOkItIfaz98BK+QSt6I7ABLpbk/mmm7l3+MeuiXE2V6EQ6grPr7nzR OiWw== 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=Fzx2h2dINoIne6XQ0fxHMONWTIstMJd+RnWtA/nmSQE=; b=TdR62xBroJBR3dJPQ9hddYCGPmKVM01pLGbw8zq9jTWO4wrD2OR6bAr7hgkeqph57X xTbWvJMcbgNBuQ5qC5u8bFYmzt5F8pcfOwvsAgHReTqUQkKc4NboIUek0wp6zODZS9Oq /i40Tz9EwxuVaTwVwuk8YFh6bFcs2Cl0+AjsbmSPBhRBXnXC1fvBU7GB+uD/roOuhwKc tY0NPcGHarv+czCbQcfCczWxHJIeGcDjv1hOY+/z1l0JlxGac3ZLh8qdQirJeOqcEWLq FGjzu1wRGrL8SyGbF+8BJVtlwMYZw/DSajX7Om7CCck/o42YRnfmC2PPpMdJlSn7i1bQ zYXA== X-Gm-Message-State: APjAAAVqt7hD5r4+5rLW67hxJGiVeGJMSTXzGp1RgbYR9Ki8npVgINGC ARKOFuIjIPBvf+xXSwZgZDAj3GIP X-Google-Smtp-Source: APXvYqy/KIFeEyu68WNTPl3YixXzcncjhILTiIjTgwdYyX422kACM7yCql0MXnmaLeTQqF6F/x9U8w== X-Received: by 2002:a19:4f54:: with SMTP id a20mr11647357lfk.136.1557122526708; Sun, 05 May 2019 23:02:06 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id y10sm588863lji.12.2019.05.05.23.02.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 05 May 2019 23:02:05 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: , "'Tero Kivinen'" References: <23734.7331.402882.289451@fireball.acr.fi> <01b201d4f4f1$e617eb90$b247c2b0$@gmail.com> <636D1D4B-3E3F-47F1-B64C-A266BF871010@nohats.ca> <00c001d4ff1b$62c87050$285950f0$@gmail.com> In-Reply-To: Date: Mon, 6 May 2019 09:02:05 +0300 Message-ID: <02cf01d503d1$3bc9d970$b35d8c50$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGx2DB/WIutEoo9ZJxUMu3Z3MbCGgJMohb3Ab24xX8DHlx+XQCoBll6pmVrQZA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Draft-ietf-ipsecme-ipv6-ipv4-codes 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, 06 May 2019 06:02:10 -0000 > >> I would prefer no notify if the request was fulfilled and to only = send a notify if a request could not be > fulfilled. > >> Since clients can ask for both that should cover things. If a = client isn=E2=80=99t asking for ipvX, I see no need to > answer > >> that ipvX is supported too. > > > > That would make sending these notifies dependent on the content of = request. > > So, the tradeoff is whether saving eight bytes justifies = complication of state machine. >=20 > I wouldn't call that complicated the state machine. You are not adding > new states or transitions, and you already keep a list of received > payloads for this state/exchange I hope :P True, I wasn't precise enough. The complication is that in the current = approach the responder sends these notifications blindly, sending them doesn't = depend on the content of CP request. Regards, Valery. > Paul From nobody Mon May 6 07:42:44 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 A6029120052 for ; Mon, 6 May 2019 07:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] 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 QTteHXr_AtSy for ; Mon, 6 May 2019 07:42:39 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 A2DCF120191 for ; Mon, 6 May 2019 07:42:39 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 44yQSY2rX3zHXX; Mon, 6 May 2019 16:42:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1557153757; bh=GWKNFskzY6x6vl9zTfLzHixLHVG9WAQU7xzisA0Ugew=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jW8BDRm58UwzLRapVhAp3fiBquhGHeXDs9O095/QNQxrdpa221gmBZXucnSXJNboB 0a7+5DprGUyPk7+cWgV47W1emuiP4qsLg0UPYh0kpbDmdmLB/j4jyDw24Te7FfSlK6 BA+B/J4n1znzmmiuLYJCGmnNFYWPLC6tE01P0uW8= 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 rPaFmvWZRxWb; Mon, 6 May 2019 16:42:36 +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, 6 May 2019 16:42:35 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 70E209E3; Mon, 6 May 2019 10:42:34 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 70E209E3 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 636A541092A2; Mon, 6 May 2019 10:42:34 -0400 (EDT) Date: Mon, 6 May 2019 10:42:34 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: ipsec@ietf.org, 'Tero Kivinen' In-Reply-To: <02cf01d503d1$3bc9d970$b35d8c50$@gmail.com> Message-ID: References: <23734.7331.402882.289451@fireball.acr.fi> <01b201d4f4f1$e617eb90$b247c2b0$@gmail.com> <636D1D4B-3E3F-47F1-B64C-A266BF871010@nohats.ca> <00c001d4ff1b$62c87050$285950f0$@gmail.com> <02cf01d503d1$3bc9d970$b35d8c50$@gmail.com> 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] Draft-ietf-ipsecme-ipv6-ipv4-codes 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, 06 May 2019 14:42:43 -0000 On Mon, 6 May 2019, Valery Smyslov wrote: >>> That would make sending these notifies dependent on the content of request. >>> So, the tradeoff is whether saving eight bytes justifies complication of state machine. >> >> I wouldn't call that complicated the state machine. You are not adding >> new states or transitions, and you already keep a list of received >> payloads for this state/exchange I hope :P > > True, I wasn't precise enough. The complication is that in the current approach > the responder sends these notifications blindly, sending them doesn't depend > on the content of CP request. RFC 7296 found that argument weak :) Note that no recommendations are made in this document as to how an implementation actually figures out what information to send in a response. That is, we do not recommend any specific method of an IRAS determining which DNS server should be returned to a requesting IRAC. For example, you can always reply with INTERNAL_IP4_DNS and INTERNAL_IP4_NBNS if the client is requesting only an INTERNAL_IP6_ADDRESS and either these first two CFG payloads or not. But I hope you added "complicated code" to not send those :) sub-optimal clients get sub-optimal answers. Paul From nobody Wed May 22 00:37: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 76CA01200BA for ; Wed, 22 May 2019 00:37:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 aG0Ah9wSX3v8 for ; Wed, 22 May 2019 00:37:33 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 5C83812004B for ; Wed, 22 May 2019 00:37:33 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 7851798A53CB3769D938; Wed, 22 May 2019 08:37:31 +0100 (IST) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 22 May 2019 08:37:30 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.182]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0415.000; Wed, 22 May 2019 15:37:18 +0800 From: "Panwei (William)" To: Paul Wouters , Y Sowji , "ipsec@ietf.org" CC: Sandeep Kampati , "Meduri S S Bharath (A)" Thread-Topic: New Version Notification for draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-01.txt Thread-Index: AdUQa5zbFJc1ZkuRRnS9150Td0+2+A== Date: Wed, 22 May 2019 07:37:17 +0000 Message-ID: <30E95A901DB42F44BA42D69DB20DFA6A69F68ABE@nkgeml513-mbx.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.37.117] Content-Type: multipart/alternative; boundary="_000_30E95A901DB42F44BA42D69DB20DFA6A69F68ABEnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-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, 22 May 2019 07:37:36 -0000 --_000_30E95A901DB42F44BA42D69DB20DFA6A69F68ABEnkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGF1bCwgU293amFueWEgYW5kIGZvbGtzLA0KDQoNCg0KVGhhbmtzIGEgbG90IGZvciBQYXVs IGFuZCBTb3dqYW55YeKAmXMgcmV2aWV3cywgd2UgaGF2ZSBtb2RpZmllZCBvdXIgZHJhZnQgYmFz ZWQgb24geW91ciBjb21tZW50cy4NCg0KDQoNClRoZSBuZXcgdmVyc2lvbiBkcmFmdCBpbmNsdWRl cyB0aGUgZm9sbG93aW5nIG1haW4gY2hhbmdlczoNCg0KMS4gUmVkZXNpZ24gdGhlIHNlY3Rpb25z IHRvIG1ha2UgdGhlIHN0cnVjdHVyZSBtb3JlIHJlYXNvbmFibGUgYW5kIHRoZSBkcmFmdCBtb3Jl IHJlYWRhYmxlLg0KDQoyLiBDaGFuZ2UgdGhlIG5lZ290aWF0aW9uIG9mIHN1cHBvcnQgdG8gdGhl IElLRV9BVVRIIHBoYXNlLCBhbmQgY2hhbmdlIHRoZSBzdXBwb3J0IG5vdGlmaWNhdGlvbuKAmXMg bmFtZS4NCg0KMy4gRGV0YWlsIHRoZSBvcHRpbWl6YXRpb24gZm9yIHJla2V5aW5nIElLRSBTQXMs IGFuZCB1c2UgU0FfVU5DSEFOR0VEIG5vdGlmaWNhdGlvbiBwYXlsb2FkIHRvIHJlcGxhY2UgU0Eg cGF5bG9hZHMuDQoNCjQuIERldGFpbCB0aGUgb3B0aW1pemF0aW9uIGZvciByZWtleWluZyBDaGls ZCBTQXMsIGFuZCB1c2UgU0FfVFNfVU5DSEFOR0VEIG5vdGlmaWNhdGlvbiBwYXlsb2FkIHRvIHJl cGxhY2UgU0EgYW5kIFRTIHBheWxvYWQuDQoNCjUuIEZvciByZWtleWluZyBDaGlsZCBTQXMsIHdl IGN1cnJlbnRseSByZW1vdmUgdGhlIGNvbnNpZGVyYXRpb24gdGhhdCBvbmx5IG9taXR0aW5nIFRT IHBheWxvYWRzLCBiZWNhdXNlIHdlIHRoaW5rIHRoaXMga2luZCBvbWl0dGluZyB3aWxsIGludHJv ZHVjZSBtb3JlIGNvbXBsZXhpdGllcy4gSW5pdGlhdG9yIFNBIHBheWxvYWQsIEluaXRpYXRvciBU UyBwYXlsb2FkLCBSZXNwb25kZXIgU0EgcGF5bG9hZCBhbmQgUmVzcG9uZGVyIFRTIHBheWxvYWQs IGlmIGVpdGhlciBvZiB0aGVzZSBmb3VyIHBheWxvYWRzIGNhbiBiZSBvbWl0dGVkLCB0aGVyZSB3 aWxsIGJlIHVwIHRvIDE2IGNpcmN1bXN0YW5jZXMsIHRoYXQgd2lsbCBiZSB0b28gY29tcGxleC4N Cg0KDQoNCkNvbW1lbnRzIGFuZCByZXZpZXdzIGZvciB0aGUgbmV3IHZlcnNpb24gZHJhZnQgYXJl IHZlcnkgd2VsY29tZS4NCg0KDQoNCkJlc3QgUmVnYXJkcw0KDQpXZWkgUGFuDQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFtt YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMjIs IDIwMTkgMjoxNyBQTQ0KVG86IE1lZHVyaSBTIFMgQmhhcmF0aCAoQSkgPE1lZHVyaVMuQmhhcmF0 aEBodWF3ZWkuY29tPjsgTWVkdXJpIFMgUyBCaGFyYXRoIChBKSA8TWVkdXJpUy5CaGFyYXRoQGh1 YXdlaS5jb20+OyBQYW53ZWkgKFdpbGxpYW0pIDx3aWxsaWFtLnBhbndlaUBodWF3ZWkuY29tPjsg U2FuZGVlcCBLYW1wYXRpIDxzYW5kZWVwa2FtcGF0aUBodWF3ZWkuY29tPg0KU3ViamVjdDogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjItc2Et dHMtcGF5bG9hZHMtb3B0LTAxLnR4dA0KDQoNCg0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBk cmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0LTAxLnR4dA0KDQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFdlaSBQYW4gYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAgICAgICAgICAgZHJhZnQta2FtcGF0 aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9wdA0KDQpSZXZpc2lvbjogICAgICAgICAw MQ0KDQpUaXRsZTogICAgICAgICAgICAgICAgSUtFdjIgT3B0aW9uYWwgU0EmVFMgUGF5bG9hZHMg aW4gQ2hpbGQgRXhjaGFuZ2UNCg0KRG9jdW1lbnQgZGF0ZTogICAgICAgICAyMDE5LTA1LTIxDQoN Ckdyb3VwOiAgICAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCg0KUGFnZXM6ICAgICAg ICAgICAgICAxMQ0KDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQt MDEudHh0DQoNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0Lw0KDQpIdG1s aXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthbXBhdGktaXBz ZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDENCg0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQta2FtcGF0aS1pcHNlY21lLWlr ZXYyLXNhLXRzLXBheWxvYWRzLW9wdA0KDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXls b2Fkcy1vcHQtMDENCg0KDQoNCkFic3RyYWN0Og0KDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJl cyBhIG1ldGhvZCBmb3IgcmVkdWNpbmcgdGhlIHNpemUgb2YgdGhlDQoNCiAgIEludGVybmV0IEtl eSBFeGNoYW5nZSB2ZXJzaW9uIDIgKElLRXYyKSBleGNoYW5nZXMgYXQgdGltZSBvZiByZWtleWlu Zw0KDQogICBJS0UgU0FzIGFuZCBDaGlsZCBTQXMgYnkgcmVtb3Zpbmcgb3IgbWFraW5nIG9wdGlv bmFsIG9mIFNBICYgVFMNCg0KICAgcGF5bG9hZHMuICBSZWR1Y2luZyBzaXplIG9mIElLRXYyIGV4 Y2hhbmdlcyBpcyBkZXNpcmFibGUgZm9yIGxvdw0KDQogICBwb3dlciBjb25zdW1wdGlvbiBiYXR0 ZXJ5IHBvd2VyZWQgZGV2aWNlcy4gIEl0IGFsc28gaGVscHMgdG8gYXZvaWQgSVANCg0KICAgZnJh Z21lbnRhdGlvbiBvZiBJS0V2MiBtZXNzYWdlcy4NCg0KDQoNCg0KDQoNCg0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg0K --_000_30E95A901DB42F44BA42D69DB20DFA6A69F68ABEnkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEg NiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6R2FkdWdpOw0KCXBh bm9zZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbi10b3A6MS41 cHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjEuNXB0Ow0KCW1hcmdpbi1s ZWZ0OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tdG9wOi4zZ2Q7DQoJbXNvLXBhcmEtbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90dG9tOi4zZ2Q7DQoJbXNvLXBhcmEtbWFyZ2lu LWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv UGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/mlofmnKwgQ2hhciI7DQoJbWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhcmEtbWFyZ2luLXRvcDouM2dk Ow0KCW1zby1wYXJhLW1hcmdpbi1yaWdodDowY207DQoJbXNvLXBhcmEtbWFyZ2luLWJvdHRvbTow Y207DQoJbXNvLXBhcmEtbWFyZ2luLWxlZnQ6MGNtOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJHYWR1Z2kiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/mlofmnKwgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6r+aWh+acrDsNCglmb250 LWZhbWlseToiR2FkdWdpIixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5O30NCi5Nc29QYXBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1hcmdpbi10b3A6MS41cHQ7DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJn aW4tYm90dG9tOjEuNXB0Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tdG9w Oi4zZ2Q7DQoJbXNvLXBhcmEtbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tcGFyYS1tYXJnaW4tYm90 dG9tOi4zZ2Q7DQoJbXNvLXBhcmEtbWFyZ2luLWxlZnQ6MGNtO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLXRvcDozLjZwdCI+SGkgUGF1bCwgU293amFueWEgYW5kIGZvbGtzLDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi10b3A6My42cHQiPlRoYW5rcyBhIGxvdCBmb3IgUGF1bCBhbmQgU293amFueWHigJlzIHJl dmlld3MsIHdlIGhhdmUgbW9kaWZpZWQgb3VyIGRyYWZ0IGJhc2VkIG9uIHlvdXIgY29tbWVudHMu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRv cDozLjZwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLXRvcDozLjZwdCI+VGhlIG5ldyB2ZXJzaW9uIGRyYWZ0IGluY2x1ZGVzIHRo ZSBmb2xsb3dpbmcgbWFpbiBjaGFuZ2VzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPjEuIFJlZGVzaWduIHRoZSBzZWN0aW9u cyB0byBtYWtlIHRoZSBzdHJ1Y3R1cmUgbW9yZSByZWFzb25hYmxlIGFuZCB0aGUgZHJhZnQgbW9y ZSByZWFkYWJsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tdG9wOjMuNnB0Ij4yLiBDaGFuZ2UgdGhlIG5lZ290aWF0aW9uIG9mIHN1cHBvcnQg dG8gdGhlIElLRV9BVVRIIHBoYXNlLCBhbmQgY2hhbmdlIHRoZSBzdXBwb3J0IG5vdGlmaWNhdGlv buKAmXMgbmFtZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tdG9wOjMuNnB0Ij4zLiBEZXRhaWwgdGhlIG9wdGltaXphdGlvbiBmb3IgcmVrZXlp bmcgSUtFIFNBcywgYW5kIHVzZSBTQV9VTkNIQU5HRUQgbm90aWZpY2F0aW9uIHBheWxvYWQgdG8g cmVwbGFjZSBTQSBwYXlsb2Fkcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij40LiBEZXRhaWwgdGhlIG9wdGltaXphdGlvbiBm b3IgcmVrZXlpbmcgQ2hpbGQgU0FzLCBhbmQgdXNlIFNBX1RTX1VOQ0hBTkdFRCBub3RpZmljYXRp b24gcGF5bG9hZCB0byByZXBsYWNlIFNBIGFuZCBUUyBwYXlsb2FkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPjUuIEZvciBy ZWtleWluZyBDaGlsZCBTQXMsIHdlIGN1cnJlbnRseSByZW1vdmUgdGhlIGNvbnNpZGVyYXRpb24g dGhhdCBvbmx5IG9taXR0aW5nIFRTIHBheWxvYWRzLCBiZWNhdXNlIHdlIHRoaW5rIHRoaXMga2lu ZCBvbWl0dGluZyB3aWxsIGludHJvZHVjZSBtb3JlIGNvbXBsZXhpdGllcy4gSW5pdGlhdG9yIFNB IHBheWxvYWQsIEluaXRpYXRvciBUUyBwYXlsb2FkLA0KIFJlc3BvbmRlciBTQSBwYXlsb2FkIGFu ZCBSZXNwb25kZXIgVFMgcGF5bG9hZCwgaWYgZWl0aGVyIG9mIHRoZXNlIGZvdXIgcGF5bG9hZHMg Y2FuIGJlIG9taXR0ZWQsIHRoZXJlIHdpbGwgYmUgdXAgdG8gMTYgY2lyY3Vtc3RhbmNlcywgdGhh dCB3aWxsIGJlIHRvbyBjb21wbGV4LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPkNvbW1lbnRzIGFu ZCByZXZpZXdzIGZvciB0aGUgbmV3IHZlcnNpb24gZHJhZnQgYXJlIHZlcnkgd2VsY29tZS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMu NnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tdG9wOjMuNnB0Ij5CZXN0IFJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij5XZWkgUGFuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDozLjZwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLXRvcDozLjZwdCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIDxi cj4NClNlbnQ6IFdlZG5lc2RheSwgTWF5IDIyLCAyMDE5IDI6MTcgUE08YnI+DQpUbzogTWVkdXJp IFMgUyBCaGFyYXRoIChBKSAmbHQ7TWVkdXJpUy5CaGFyYXRoQGh1YXdlaS5jb20mZ3Q7OyBNZWR1 cmkgUyBTIEJoYXJhdGggKEEpICZsdDtNZWR1cmlTLkJoYXJhdGhAaHVhd2VpLmNvbSZndDs7IFBh bndlaSAoV2lsbGlhbSkgJmx0O3dpbGxpYW0ucGFud2VpQGh1YXdlaS5jb20mZ3Q7OyBTYW5kZWVw IEthbXBhdGkgJmx0O3NhbmRlZXBrYW1wYXRpQGh1YXdlaS5jb20mZ3Q7PGJyPg0KU3ViamVjdDog TmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjIt c2EtdHMtcGF5bG9hZHMtb3B0LTAxLnR4dDwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij5BIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxv YWRzLW9wdC0wMS50eHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IFdlaSBQYW4gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10 b3A6My42cHQiPk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2 Mi1zYS10cy1wYXlsb2Fkcy1vcHQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij5SZXZpc2lvbjombmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMDE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij5UaXRsZTombmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSUtFdjIgT3B0aW9uYWwgU0EmYW1wO1RTIFBheWxvYWRz IGluIENoaWxkIEV4Y2hhbmdlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLXRvcDozLjZwdCI+RG9jdW1lbnQgZGF0ZTombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMjAxOS0wNS0yMTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPkdyb3Vw OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij5QYWdlczombmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgMTE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij5VUkw6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtl djItc2EtdHMtcGF5bG9hZHMtb3B0LTAxLnR4dCI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9w dC0wMS50eHQ8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLXRvcDozLjZwdCI+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0LyI+DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtl djItc2EtdHMtcGF5bG9hZHMtb3B0LzwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij5IdG1saXplZDombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDEiPg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWthbXBhdGktaXBzZWNtZS1pa2V2Mi1z YS10cy1wYXlsb2Fkcy1vcHQtMDE8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDozLjZwdCI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQta2FtcGF0aS1pcHNlY21lLWlrZXYyLXNhLXRzLXBheWxvYWRzLW9w dCI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWthbXBhdGkt aXBzZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQ8L2E+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDozLjZwdCI+RGlmZjombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWthbXBhdGktaXBz ZWNtZS1pa2V2Mi1zYS10cy1wYXlsb2Fkcy1vcHQtMDEiPmh0dHBzOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1rYW1wYXRpLWlwc2VjbWUtaWtldjItc2EtdHMtcGF5bG9hZHMtb3B0 LTAxPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1h cmdpbi10b3A6My42cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPiZuYnNwOyZu YnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIG1ldGhvZCBmb3IgcmVkdWNpbmcgdGhlIHNp emUgb2YgdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLXRvcDozLjZwdCI+Jm5ic3A7Jm5ic3A7IEludGVybmV0IEtleSBFeGNoYW5nZSB2ZXJz aW9uIDIgKElLRXYyKSBleGNoYW5nZXMgYXQgdGltZSBvZiByZWtleWluZzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPiZuYnNw OyZuYnNwOyBJS0UgU0FzIGFuZCBDaGlsZCBTQXMgYnkgcmVtb3Zpbmcgb3IgbWFraW5nIG9wdGlv bmFsIG9mIFNBICZhbXA7IFRTPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLXRvcDozLjZwdCI+Jm5ic3A7Jm5ic3A7IHBheWxvYWRzLiZuYnNwOyBS ZWR1Y2luZyBzaXplIG9mIElLRXYyIGV4Y2hhbmdlcyBpcyBkZXNpcmFibGUgZm9yIGxvdzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42 cHQiPiZuYnNwOyZuYnNwOyBwb3dlciBjb25zdW1wdGlvbiBiYXR0ZXJ5IHBvd2VyZWQgZGV2aWNl cy4mbmJzcDsgSXQgYWxzbyBoZWxwcyB0byBhdm9pZCBJUDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPiZuYnNwOyZuYnNwOyBm cmFnbWVudGF0aW9uIG9mIElLRXYyIG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6My42cHQiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t dG9wOjMuNnB0Ij5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9u IGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDozLjZwdCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRv cDozLjZwdCI+VGhlIElFVEYgU2VjcmV0YXJpYXQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjMuNnB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_30E95A901DB42F44BA42D69DB20DFA6A69F68ABEnkgeml513mbxchi_-- From nobody Fri May 24 04:50:14 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 2FAA01202DB; Fri, 24 May 2019 04:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 jXM0iqe7TJ98; Fri, 24 May 2019 04:50:07 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [IPv6:2001:720:1710:601::42]) by ietfa.amsl.com (Postfix) with ESMTP id 65804120045; Fri, 24 May 2019 04:50:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 1F7CE20985; Fri, 24 May 2019 13:50: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 pEe4JuTOWsqN; Fri, 24 May 2019 13:50:02 +0200 (CEST) Received: from [192.168.1.36] (251.red-88-17-15.dynamicip.rima-tde.net [88.17.15.251]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon42.um.es (Postfix) with ESMTPSA id 24C26204EA; Fri, 24 May 2019 13:49:58 +0200 (CEST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F8B20024-0B42-4C71-B7C1-78425663B620" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin-Lopez In-Reply-To: Date: Fri, 24 May 2019 13:49:57 +0200 Cc: Rafa Marin-Lopez , Linda Dunbar , "i2nsf@ietf.org" , "ipsec@ietf.org WG" , Gabriel Lopez , =?utf-8?Q?Fernando_Pere=C3=B1=C3=ADguez_Garc=C3=ADa?= Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> To: Paul Wouters X-Mailer: Apple Mail (2.3124) 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, 24 May 2019 11:50:12 -0000 --Apple-Mail=_F8B20024-0B42-4C71-B7C1-78425663B620 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Paul: Sorry for the delayed answer. Our answer took us more time than expected = preparing. Thank you very much again. Please see our comments inline: > El 22 abr 2019, a las 18:19, Paul Wouters escribi=C3=B3= : >=20 > Linda Dunbar wrote: >=20 >> This email starts a four weeks Working Group Last Call >> on draft-ietf-i2nsf-sdn-ipsec-flow-protection-04.=20 >> This poll runs until May 15, 2019.=20 >=20 >> If you are listed as an Author or a Contributor of this Document = please respond to this email and >> indicate whether or not you are aware of any relevant undisclosed = IPR. The Document won't progress >> without answers from all the Authors and Contributors. >=20 > I'm not sure if I should consider mylsef a Contributors, but = regardless > I have no IPR on any of this. >=20 >=20 >=20 > The Security Controller is in charge of managing and > applying SPD and PAD entries (deriving and delivering IKE = Credentials > such as a pre-shared key, certificates, etc.), and applying other = IKE > configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF > for the IKE negotiation. >=20 > This text is a little confusing as IKE manages and applies the SPD/PAD > entries, but the SC is not the one running IKE. Proposed new text: >=20 > The Security Controller is in charge of managing and > applying IPsec connection information (determing which nodes need to > start an IKE/IPsec session, deriving and delivering IKE Credentials > such as a pre-shared key, certificates, etc.), and applying other = IKE > configuration parameters (e.g. IKE_SA_INIT algorithms) to the NSF > for the IKE negotiation. [Authors] Changed.=20 >=20 >=20 > IKE case MAY be easier to deploy than IKE-less case because current > gateways typically have an IKEv2/IPsec implementation. >=20 > Why is that MAY in capitals? Also, based on the paragraph it seems you > really are saying the IKE case is easier to deploy, unless your nodes > lack the resources to run IKEv2. [Authors] We have rephrased as: =E2=80=9CIn principle, IKE case is easier to deploy than IKE-less case because current gateways typically have an IKEv2/IPsec=20 implementation. Moreover hosts can install easily an IKE = implementation." >=20 > The main > reason is that the Security Controller is not able to observe any > session keys generated for the IPsec SAs because IKEv2 is in charge > of negotiating the IPsec SAs. >=20 > I think you mean "because the nodes, not the Security Controller, is > generating the session keys". I would not use the word IKEv2, because > it is unclear if that IKEv2 would be running on the SG or the node. [Authors] That=E2=80=99s right. Let=E2=80=99s only write this sentence: "The main reason is that the NSFs are generating the session keys and = not the Security Controller=E2=80=9D. >=20 >=20 > For IKE case, the rekeying process is carried out by IKEv2, = following > the information defined in the SPD and SAD. >=20 > That is not the whole story though? Isn't is the Security Controller > that decides when to terminate a connection? I guess it is implied = here > that we are talking about connections that are instructed by the SG to > stay up long enough to need rekeying? [Authors] The Security Controller may decide to terminate a connection = but, in principle, if nothing unexpected happens after applying IKE = configuration will allow IKE to operate as configured. So, yes, it is = expected that connections will live unless something different is = required by the administrator or the SC detects something wrong.=20 >=20 >=20 > Section 5.3.1 talks about a bundle of two inbound SA's. That is a = little > confusing as traditionally we talk about the bundle being an inbound = and > outbound SA from the perspective of one of the endpoints. I understand > you are doing this so you can talk about installing inbound on both = ends > first. Perhaps talk initially about the inbound and outbound bundle, > then state you are handing out what is the inbound sa from the point = of > view of each endpoint first ? [Authors] We can add the following paragraph. How about this one?: "Traditionally, during a rekey process of the IPSec SA using IKE, a = bundle of inbound and outbound SAs, from the perspective of one of the = NSFs, is taken into account. For example, if the inbound SA expires both = the inbound and outbound SA are rekeyed at the same time in that NSF. = However, when IKE is not used, we have followed a different approach to = avoid any packet loss during rekey: the Security Controller installs = first the new inbound SAs in both NSFs and then, the outbound SAs." >=20 > It is worth noting that if the IPsec implementation > can itself detect traffic on the new IPsec SA, and it can delete > the old IPsec SA itself without instruction from the Security > Controller, then this step 3 is not required. >=20 > Technically, they can never know this because IKEv2 allows installing > multiple IPsec SA's with the exact same policies. [Authors] We are talking here about IKE-less case so there is no IKEv2. = This paragraph was added after , as far as I remember, your comment = about this possibility. I think if the IPsec SAs have different SPIs the = SDN controller can distinguish among them > We are for example > doing this for performance increases by creating multiple IPsec SA's, > (identical policies, different keys) > to get one IPsec SA bound per CPU > on the endpoint. I would recommend to leave this up only to the = Security > Controller, eg: >=20 > The IPsec implementation cannot detect whether a new identical > IPsec SA is an additional (identical) IPsec SA or a replacement > IPsec SA. It should only delete the (seemingly) old IPsec SA > when the Security Controller instructs the node to do so. [Authors] Then the step 3 still applies. Most probably removing the = paragraph should be enough, right? >=20 >=20 >=20 > It can also instruct the affected NSF to send IKEv2 = INITIAL_CONTACT. >=20 > I think this is something the IKEv2 implementation would determine on = its own. > I would remove the sentence or change it to say the node can determine = it > needs to send INITIAL_CONTACT. Also, this removes the need for the SC = to > have to relay this option to the IKEv2 NSF. [Authors] We have observed some implementations (e.g. libreswan) has = this variable initial-contact as well in the ipsec.conf. That is why we = decide to keep it. Is it not useful then? >=20 > In IKE-less case, if the Security Controller detects that a NSF has > lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec = SAs > of the non-failed nodes established with the failed node (step 1). > This prevents the non-failed nodes from leaking plaintext. >=20 > Wouldn't doing that before installing a new IPsec SA not actually = _cause_ > leaking plaintext? Unless the non-failed nodes, upon receiving the = delete > would put in an SPD policy that would catch packets and trigger an = acquire. [Authors] This is an interesting question. We must state that, for = security reasons, any NSF should have a default DISCARD policy. A NSF = restarting 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 > I see the use of ah-algorithms. I thought we were going to remove all = mention > of AH and perhaps tell people to use ESP NULL encryption? [Authors] Yes, we have removed AH. That is what we are doing for version = -05. >=20 > +--rw security-protocol? ic:ipsec-protocol >=20 > What does this stand for? There is no "IPsec protocol" in the sense = that we do not have > an IANA protocol entry for "IPsec" (only for ESP) [Authors] I understand. The intention was to say ipsec related protocol. = Should we use something like ic:ipsec-related-protocol? or = ic:sec-protocol? =20 >=20 > SHOULD NEVER -> MUST NOT [Authors] Fixed >=20 >=20 > If PSK authentication is used in IKEv2, the Security > Controller SHOULD remove the PSK immediately after generating and > distributing it >=20 > Why is that SHOULD not a MUST? Can you give an example of an = exception? [Authors] Right. MUST is the right option. >=20 > If raw public keys are used, > the Security Controller SHOULD remove the associated private key > immediately after generating and distributing them to the NSFs. >=20 > Again, why is this SHOULD not a MUST? What is the exception? [Authors] Right too. We have fixed this. >=20 > In the IKE-less case, the controller sends the IPsec SA information > to the SAD that includes the keys for integrity and encryption (when > ESP is used). That key material are symmetric keys to protect data > traffic. >=20 > Change to: >=20 > In the IKE-less case, the controller sends the IPsec SA information > to the SAD that includes the private session keys required for = integrity > and encryption. [Authors] Done. >=20 >=20 > The general recommendation is that the Security Controller > SHOULD NEVER stores the keys >=20 > Again, use RFC 2119 terms, so change SHOULD NEVER to MUST NOT. (or = SHOULD > NOT, but then you again need to say what the exception would be) [Authors] MUST NOT better. >=20 > Moreover, the > NSFs MUST NOT allow the reading of these values once they have been > applied by the Security Controller (i.e. write only operations). >=20 > These are not really "applied by the Security Controller". Perhaps you > meant "obtained" instead of =E2=80=9Capplied" > ? [Authors] Since we were referring to IKE-less case the Security = Controlles sends these keys to the NSF. In that case, the Security = Controller applies the keys but it MUST NOT BE obtained (read) by anyone = (including the SC). >=20 >=20 > In other words, it may have access to the > key material used in the distributed IPsec SAs and observe the > traffic between peers. >=20 > change to: >=20 > In other words, the attack might be able to observe the IPsec = traffic and decrypt, or even modify > and re-encrypt the traffic between peers. [Authors] Done. >=20 >=20 > In any case, some escenarios with special > secure environments (e.g. physically isolated data centers) make = this > type of attack difficult. >=20 > I would not make this claim and just delete this setence (and the = "Morever," part > of the next sentence. [Authors] Done >=20 > enum ah { description "AH Protocol"; } >=20 > another occurance of AH ? [Authors] We are writing version -05 of these changes will be applied. >=20 > typedef ipsec-upper-layer-proto { > type enumeration { > enum TCP { description "TCP traffic"; } > enum UDP { description "UDP traffic"; } > enum SCTP { description "SCTP = traffic";} > enum DCCP { description "DCCP = traffic";} > enum ICMP { description "ICMP = traffic";} > enum IPv6-ICMP { description "IPv6-ICMP = traffic";} > enum GRE {description "GRE traffic";} > } > description "Next layer proto on top of IP"; > } >=20 > I don't understand ipsec-upper-layer-proto? If this is encapsulation = protocol, then > there is only TCP and UDP. If this is the protocol of the encrypted = data, then there > are a lot more protocols. The document also nowhere explains the term = "upper layer protocol" > I think you mean what I would call the "inner protocol" so that it is = every number from the > IANA protocol registry. [Authors] Basically RFC 4301 mentions next layer protocols and we had = that in previous versions but it was suggested that was not a good name. = So we used this one. We can use inner protocol. Thus it is not = encapsulation but the protocols in the next header after IP header. "Next Layer Protocol: Obtained from the IPv4 "Protocol" or the IPv6 "Next Header" fields.=E2=80=9D So it seems that every number from the IANA protocol registry should be = there. So here we have again the same problem as crypto algorithms. = However, we can do as RFC 8519 :=20 leaf protocol { type uint8; description "Internet Protocol number. Refers to the protocol of the payload. In IPv6, this field is known as 'next-header', and if extension headers are present, the protocol is present in the 'upper-layer' header."; reference " RFC 791 : Internet Protocol =20 RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification."; } >=20 >=20 > typedef pfs-group { > type enumeration { > enum NONE {description "NONE";} > enum 768-bit-MODP {description "768-bit = MODP Group";} > enum 1024-bit-MODP {description = "1024-bit MODP Group";} > enum 1536-bit-MODP {description = "1536-bit MODP Group";} > enum 2048-bit-MODP {description = "2048-bit MODP Group";} > enum 3072-bit-MODP {description = "3072-bit MODP Group";} > enum 4096-bit-MODP {description = "4096-bit MODP Group";} > enum 6144-bit-MODP {description = "6144-bit MODP Group";} > enum 8192-bit-MODP {description = "8192-bit MODP Group";} > } > description "PFS group for IPsec rekey"; > } >=20 > This is the only entry still enumerating (partially!) an IANA = registry. [Authors] Right. But I am not sure if there is a final conclusion about = this dilemma. Personally, I still prefer to have a uint32 and refer = Group Description (Value 4) in=20 https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml >=20 > leaf-list ike-sa-authalg { type ic:integrity-algorithm-t; = description "Auth algorigthm for IKE SA=E2=80=9D;} [Authors] Done. >=20 > Typo in algorigthm >=20 > leaf-list ike-sa-encalg { type ic:encryption-algorithm-t; = description "Auth algorigthm for IKE SAs";} >=20 > Same typo, but it should also not be "Auth" but "Encryption or AEAD = algorithm=E2=80=9D. [Authors] Done. >=20 >=20 > description "Configure the IKEv2 software"; >=20 > Maybe call it "Configuration of the IKEv2 implementation" ? > (more of these "Configure" vs "Configuration" terms follow) [Authors] Ok. >=20 > leaf pad-entry-id { type uint64; description "SAD index. ";} >=20 > did you mean "PAD index=E2=80=9D ? [Authors] Yes, it is a typo. >=20 > Whether to use IKEv2 fragmentation as >=20 > Whether or not to enable IKEv2 fragmentation >=20 > (enable because the other end can not have support, it is just a = suggestion, not a demand) [Authors] True. >=20 > container ike-sa-state { > container uptime { > description "IKE service uptime"; >=20 > Did you mean "IKE connection uptime=E2=80=9D ? [Authors] Yes, that is correct. > To me ike-sa-state means an IKE state, not IKE service state? [Authors] Agree >=20 > leaf nat-any {type boolean; description "YES, if both local and = remote endpoints are behind a NAT=E2=80=9D;} >=20 > I could call this nat-both instead of nat-any, nat-any suggests it = could be "0 or more=E2=80=9D [Authors] Done >=20 > Seconds before IKE SA gets rekeyed -> Seconds before IKE SA must be = rekeyed > (same for next auth item) [Authors] Done. >=20 > description "Configure Security Association (SA). Section 4.4.2.1 in = RFC 4301"; >=20 > Use "Configuration of IPsec Security Association (SA). Section 4.4.2.1 = in RFC 4301" > To ensure it is clear this is not about an IKE SA. Same on the next = line for > "for a particular SA" >=20 > leaf seq-number-overflow-flag { type boolean; description "The flag = indicating whether overflow of the sequence number counter should = prevent transmission of additional packets on the SA, or whether = rollover is permitted."; } >=20 > What is the source of this? I thought sequence numbers were never = allowed to overflow? [Authors] According to RFC 4301 - 4.4.2.1. Data Items in the SAD: Sequence Counter Overflow: a flag indicating whether overflow of the sequence number counter should generate an auditable event and prevent transmission of additional packets on the SA, or whether rollover is permitted. The audit log entry for this event SHOULD include the SPI value, current date/time, Local Address, Remote Address, and the selectors from the relevant SAD entry. >=20 > leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } = description "Anti replay window size"; } >=20 > Why cap at 1024? That could be too low for 100gbps connections. [Authors] The truth is that RFC 4301 mentions: Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) used to determine whether an inbound AH or ESP packet is a replay. So we can replace this with uint64. On the other hand, we have observed = with uint16 should be enough in real cases. We can remove the = restriction (1024) . what do you think? >=20 > leaf spd-entry-id {type uint64; description "This value links the SA = with the SPD entry";} >=20 > Again, use "IPsec SA=E2=80=9D [Authors] Ok.=20 >=20 > leaf security-protocol { type ic:ipsec-protocol; description = "Security protocol of IPsec SA: Either AH or ESP."; } >=20 > If we killed AH, remove from here. [Authors] Yes, this has already been removed. >=20 > leaf mode { type ic:ipsec-mode; description "SA Mode"; } >=20 > "IPsec SA". Should it say "tunnel/transport=E2=80=9D ? [Authors] Right. >=20 > leaf replay {type uint32; default 0; description "packets detected = out of the replay window and dropped because they are replay packets";} >=20 > That should be: "inside the replay window=E2=80=9D [Authors] Good catch. Changed. >=20 > typedef sadb-msg-satype { > type enumeration { > enum sadb_satype_unspec { description = "SADB_SATYPE_UNSPEC"; } > enum sadb_satype_ah { description = "SADB_SATYPE_AH"; } > enum sadb_satype_esp { description = "SADB_SATYPE_ESP"; } > enum sadb_satype_rsvp { description = "SADB_SATYPE_RSVP"; } > enum sadb_satype_ospfv2 { description = "SADB_SATYPE_OSPFv2"; } > enum sadb_satype_ripv2 { description = "SADB_SATYPE_RIPv2"; } > enum sadb_satype_mip { description = "SADB_SATYPE_MIP"; } > enum sadb_satype_max { description = "SADB_SATYPE_MAX"; } > } > description "PF_KEY Security Association = types"; > } >=20 > Is this enumerating an IANA registry? I think it might be from xfrm.h = but I don't know any of those > except the first three. [Authors] Yes, you=E2=80=99r right they belong to xfrm.h (pf_keyv2) . = And yes, we have left UNSPEC and ESP >=20 > description "Configure integrity for IPSec Authentication Header = (AH)"; >=20 > "Configuration of integrity algorithm for IPSec Authentication Header = (AH) [Authors] This has been deleted. >=20 > description "Configure encryption for IPSec Encapsulation Secutiry = Payload (ESP)"; >=20 > "Configuration of encryption or AEAD algorithm for IPSec = Authentication Header (ESP)" >=20 > description "Configure authentication for IPSec Encapsulation = Secutiry Payload (ESP)"; >=20 > See above, but also I would not use "authentication" here, but = "integrity", as it is really > the same thing as the AH value except for ESP. So either call both = authentication or call both > integrity - i strongly prefer integrity to avoid confusing with IKE = authentication. [Authors] Done. >=20 > /* With AEAD algorithms, the integrity node is not used */ >=20 > So it can either be fully ommited, or it can contain the integrity = value for None. Perhaps > relfect that in the comment? There are some implementations that do = not handle both, so there > might be a need to configure "None" as the integrity algorithm for an = AEAD. [Authors] If integrity node does not appear in the configuration sent by = the controller, the integrity interpretation is none. We can comment = this.=20 Our comment is if the encryption container is sent to the NSF with an = AEAD algorithm the container integrity is not sent , not required since = AEAD algorithm provides integrity (and encryption) >=20 > I now spotted the entry for AEAD, so now I am a little confused. If = the above encryption is not > used for that, and we have a special entry for aead, than the above = comment is wrong, because > then with AEAD algorithms, encryption and integrity is not used but = combined-enc-intr. [Authors] combined-enc-intr has been removed. We have only encryption and integrity container now. But an AEAD = algorithm will be included in the encryption leaf and there won=E2=80=99t = be integrity leaf. >=20 > I would be more inclined to keep this more in line with IKEv2, where = AEAD's are just encryption > algorithms. So remove the combined-enc-intr leaf. >=20 > notification sadb_expire { > description "A IPsec SA expiration (soft or = hard)"; >=20 > uses base-grouping; > leaf spi { type ic:ipsec-spi; description = "Security Parameter Index";} > leaf anti-replay-window { type uint16 { range = "0 | 32..1024"; } description "Anti replay window"; } >=20 > leaf encryption-algorithm { type = ic:encryption-algorithm-t; description "encryption algorithm of the = expired SA"; } > leaf authentication-algorithm { type = ic:integrity-algorithm-t; description "authentication algorithm of the = expired SA"; } >=20 > So if you keep AEAD as a seperate entry, you also need a leaf here for = it. [Authors] If the encryption-algorithm is AEAD the = authentication(integrity)-algorithm will not contain any algorithm, = right?. >=20 >=20 >=20 >=20 > I see IPcomp is not used anywhere. I agree with that but I'm not sure = if there is WG conensus for that. [Authors] We did not include IPcomp from the beginning and until now, = there has not been any comment in this regard. > Some IoT people think compression is super important. [Authors] I am aware they are working in some compression techniques for = very constrained links. >=20 > nits: >=20 > These appear a few times: >=20 > "in IKE case" -> in the IKE case" > "in IKE-less case" -> in the IKE-less case" >=20 > making IKEv2 configuration -> making the IKEv2 configuration >=20 >=20 > Note that the usage of TRANSPORT mode when NAT is > required is forbidden in this specification. >=20 > We normally don't use words like "forbidden". We usually write that = like: >=20 > Transport mode MUST NOT be used when a NAT is present between > two NSF's. >=20 > and not the IKE-less. -> and not the IKE-less case. >=20 > In order to support IKE case and IKE-less case -> In order to support = the IKE and IKE-less cases >=20 > I see the use of "IKE case" and the use of "IKE-case". Pick one and = stick to that? >=20 > minimu -> minimum >=20 > it may access to these values. -> it might have access to the key = material" >=20 > It is acting as initiator in this connection -> It is acting as = initiator for this connection >=20 > IKEless -> IKE-less >=20 > "A SPD entry has expired" -> "An SPD entry has expired" >=20 > "A IPsec SA is required " -> "An IPsec SA is required" >=20 > "A IPsec SA expiration (soft or hard)" -> "An IPsec SA expiration = (soft or hard)" >=20 > "Security Parameter Index" -> "Security Parameter Index (SPI)=E2=80=9D [Authors] All these nits have been solved. Thank you very much again for this review and your time. >=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=_F8B20024-0B42-4C71-B7C1-78425663B620 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi = Paul:

Sorry for the = delayed answer. Our answer took us more time than expected preparing. = Thank you very much again. Please see our comments inline:

El 22 abr 2019, a las 18:19, Paul Wouters <paul@nohats.ca> = escribi=C3=B3:

Linda Dunbar <linda.dunbar@huawei.com> wrote:

This email starts a four = weeks Working Group Last Call
on draft-ietf-i2nsf-sdn-ipsec-flow-protection-04. This poll runs until May 15, 2019. 

If you are listed as an Author or a Contributor of this = Document please respond to this email and
indicate whether = or not you are aware of any relevant undisclosed IPR. The Document won't = progress
without answers from all the Authors and = Contributors.

I'm not sure if = I should consider mylsef a Contributors, but regardless
I = have no IPR on any of this.



  The Security Controller is in = charge of managing and
  applying SPD and PAD = entries (deriving and delivering IKE Credentials
=   such as a pre-shared key, certificates, etc.), and applying = other IKE
  configuration parameters (e.g. =  IKE_SA_INIT algorithms) to the NSF
  for = the IKE negotiation.

This text is a little = confusing as IKE manages and applies the SPD/PAD
entries, = but the SC is not the one running IKE. Proposed new text:

  The Security Controller is in = charge of managing and
  applying IPsec = connection information (determing which nodes need to
=   start an IKE/IPsec session, deriving and delivering IKE = Credentials
  such as a pre-shared key, = certificates, etc.), and applying other IKE
=   configuration parameters (e.g.  IKE_SA_INIT algorithms) = to the NSF
  for the IKE negotiation.

[Authors] = Changed. 


=   IKE case MAY be easier to deploy than IKE-less case because = current
  gateways typically have an = IKEv2/IPsec implementation.

Why is that MAY = in capitals? Also, based on the paragraph it seems you
really are saying the IKE case is easier to deploy, unless = your nodes
lack the resources to run IKEv2.

[Authors] We have rephrased as:

=E2=80=9CIn principle, IKE case is easier to = deploy than IKE-less
case because current gateways typically = have an IKEv2/IPsec 
implementation. Moreover hosts can = install easily an IKE implementation."


=   The main
  reason is that the = Security Controller is not able to observe any
=   session keys generated for the IPsec SAs because IKEv2 is in = charge
  of negotiating the IPsec SAs.

I think you mean "because the nodes, not the = Security Controller, is
generating the session keys". I = would not use the word IKEv2, because
it is unclear if = that IKEv2 would be running on the SG or the node.

[Authors] That=E2=80=99s right. Let=E2=80=99s only = write this sentence:

"The main = reason is that the NSFs are generating the session keys and not the = Security Controller=E2=80=9D.



  For IKE case, the rekeying = process is carried out by IKEv2, following
=   the information defined in the SPD and SAD.

That is not the whole story though? Isn't is the Security = Controller
that decides when to terminate a connection? I = guess it is implied here
that we are talking about = connections that are instructed by the SG to
stay up long = enough to need rekeying?

[Authors] The Security Controller may decide to = terminate a connection but, in principle, if nothing unexpected happens = after applying IKE configuration will allow IKE to operate as = configured. So, yes, it is expected that connections will live unless = something different is required by the administrator or the SC detects = something wrong. 


Section 5.3.1 talks about a bundle of two inbound SA's. That = is a little
confusing as traditionally we talk about the = bundle being an inbound and
outbound SA from the = perspective of one of the endpoints. I understand
you are = doing this so you can talk about installing inbound on both ends
first. Perhaps talk initially about the inbound and outbound = bundle,
then state you are handing out what is the inbound = sa from the point of
view of each endpoint first ?

[Authors] We can add the following paragraph. How = about this one?:

"Traditionally, = during a rekey process of the IPSec SA using IKE, a bundle of inbound = and outbound SAs, from the perspective of one of the NSFs, is taken into = account. For example, if the inbound SA expires both the inbound and = outbound SA are rekeyed at the same time in that NSF. However, when IKE = is not used, we have followed a different approach to avoid any packet = loss during rekey: the Security Controller installs first the new = inbound SAs in both NSFs and then, the outbound SAs."



  It is worth = noting that if the IPsec implementation
  can = itself detect traffic on the new IPsec SA, and it can delete
  the old IPsec SA itself without instruction from = the Security
  Controller, then this step 3 is = not required.

Technically, they can never = know this because IKEv2 allows installing
multiple IPsec = SA's with the exact same policies.

[Authors] We are talking here about IKE-less case = so there is no IKEv2. This paragraph was added after , as far as I = remember, your comment about this possibility. I think if the IPsec SAs = have different SPIs the SDN controller can distinguish among = them

We are for example
doing this = for performance increases by creating multiple IPsec SA's,
(identical policies, different = keys)

to get one IPsec SA bound = per CPU
on the endpoint. I would recommend to leave this = up only to the Security
Controller, = eg:

The IPsec implementation cannot = detect whether a new identical
IPsec SA = is an additional (identical) IPsec SA or a replacement
IPsec SA. = It should only delete the (seemingly) old IPsec SA
when the = Security Controller instructs the node to do so.

[Authors] Then the step 3 still applies. Most = probably removing the paragraph should be enough, right?




It can = also instruct the affected NSF to send IKEv2 INITIAL_CONTACT.

I think this is something the IKEv2 = implementation would determine on its own.
I would remove = the sentence or change it to say the node can determine it
needs to send INITIAL_CONTACT. Also, this removes the need = for the SC to
have to relay this option to the IKEv2 = NSF.

[Authors] We have observed some implementations = (e.g. libreswan) has this variable initial-contact as well in the = ipsec.conf. That is why we decide to keep it. Is it not useful = then?




  In IKE-less case, if the Security = Controller detects that a NSF has
  lost the = IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs
  of the non-failed nodes established with the = failed node (step 1).
  This prevents the = non-failed nodes from leaking plaintext.

Wouldn't doing that before installing a new IPsec SA not = actually _cause_
leaking plaintext? Unless the non-failed = nodes, upon receiving the delete
would put in an SPD = policy that would catch packets and trigger an acquire.

[Authors] This is an interesting question. We must = state that, for security reasons, any NSF should have a default DISCARD = policy. A NSF restarting 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.


I see the use of = ah-algorithms. I thought we were going to remove all mention
of AH and perhaps tell people to use ESP NULL encryption?

[Authors] Yes, we have removed AH. That is what we = are doing for version -05.


+--rw = security-protocol? =          ic:ipsec-protocol
What does this stand for? There is no "IPsec = protocol" in the sense that we do not have
an IANA = protocol entry for "IPsec" (only for ESP)

[Authors] I understand. The intention was to say = ipsec related protocol. Should we use something like = ic:ipsec-related-protocol? or  ic:sec-protocol?

 

SHOULD NEVER = -> MUST NOT

[Authors] Fixed


=   If PSK authentication is used in IKEv2, the Security
  Controller SHOULD remove the PSK immediately = after generating and
  distributing it

Why is that SHOULD not a MUST? Can you give an = example of an exception?

[Authors] Right. MUST is the right option.

  If raw public keys are used,
  the Security Controller SHOULD remove the = associated private key
  immediately after = generating and distributing them to the NSFs.

Again, why is this SHOULD not a MUST? What is the = exception?

[Authors] Right too. We have fixed this.

  In the IKE-less case, the = controller sends the IPsec SA information
  to = the SAD that includes the keys for integrity and encryption (when
  ESP is used).  That key material are = symmetric keys to protect data
  traffic.

Change to:

=   In the IKE-less case, the controller sends the IPsec SA = information
  to the SAD that includes the = private session keys required for integrity
=   and encryption.

[Authors] = Done.



=   The general recommendation is that the Security = Controller
  SHOULD NEVER stores the keys

Again, use RFC 2119 terms, so change SHOULD = NEVER to MUST NOT. (or SHOULD
NOT, but then you again need = to say what the exception would be)

[Authors] = MUST NOT better.

  Moreover, the
  NSFs MUST NOT allow the reading of these values = once they have been
  applied by the Security = Controller (i.e. write only operations).

These are not really "applied by the Security Controller". = Perhaps you
meant "obtained" instead of = =E2=80=9Capplied"
?

[Authors] Since we were referring to IKE-less case = the Security Controlles sends these keys to the NSF. In that case, the = Security Controller applies the keys but it MUST NOT BE obtained (read) = by anyone (including the SC).




  In other words, it = may have access to the
  key material used in = the distributed IPsec SAs and observe the
=   traffic between peers.

change = to:

  In other words, the attack = might be able to observe the IPsec traffic and decrypt, or even = modify
  and re-encrypt the traffic between = peers.

[Authors] Done.


=   In any case, some escenarios with special
=   secure environments (e.g. physically isolated data centers) = make this
  type of attack difficult.

I would not make this claim and just delete = this setence (and the "Morever," part
of the next = sentence.

[Authors] Done

=    enum ah { description "AH Protocol"; }
another occurance of AH ?

[Authors] = We are writing version -05 of these changes will be applied.

   typedef = ipsec-upper-layer-proto {
=             &n= bsp;          type = enumeration {
=             &n= bsp;           &nbs= p;      enum TCP { description "TCP = traffic"; }
=             &n= bsp;           &nbs= p;      enum UDP { description "UDP = traffic"; }
=             &n= bsp;           &nbs= p;      enum SCTP { description "SCTP = traffic";}
=             &n= bsp;           &nbs= p;      enum DCCP { description "DCCP = traffic";}
=             &n= bsp;           &nbs= p;      enum ICMP { description "ICMP = traffic";}
=             &n= bsp;           &nbs= p;      enum IPv6-ICMP { description = "IPv6-ICMP traffic";}
=             &n= bsp;           &nbs= p;      enum GRE {description "GRE = traffic";}
=             &n= bsp;          }
=             &n= bsp;          descriptio= n "Next layer proto on top of IP";
=             &n= bsp;  }

I don't understand = ipsec-upper-layer-proto? If this is encapsulation protocol, then
there is only TCP and UDP. If this is the protocol of the = encrypted data, then there
are a lot more protocols. The = document also nowhere explains the term "upper layer protocol"
I think you mean what I would call the "inner protocol" so = that it is every number from the
IANA protocol = registry.

[Authors] Basically RFC 4301 mentions next layer = protocols and we had that in previous versions but it was suggested that = was not a good name. So we used this one. We can use inner protocol. = Thus it is not encapsulation but the protocols in the next header after = IP header.

"Next Layer Protocol: = Obtained from the IPv4 "Protocol" or the
  =       IPv6 "Next Header" fields.=E2=80=9D

So it seems  that = every number from the IANA protocol registry should be there. So here we = have again the same problem as crypto algorithms. However, we can do as = RFC 8519 : 

leaf protocol {
  =     type uint8;
      = description
        "Internet = Protocol number.  Refers to the protocol of the
         payload.  In IPv6, = this field is known as 'next-header',
    =      and if extension headers are present, the protocol = is
         present in the = 'upper-layer' header.";
      = reference
        "
RFC = 791
: Internet Protocol
  =        
RFC 8200
: Internet = Protocol, Version 6 (IPv6) Specification.";
  =   }



=             &n= bsp;  typedef pfs-group {
=             &n= bsp;          type = enumeration {
=             &n= bsp;           &nbs= p;      enum NONE {description "NONE";}
=             &n= bsp;           &nbs= p;      enum 768-bit-MODP {description = "768-bit MODP Group";}
=             &n= bsp;           &nbs= p;      enum 1024-bit-MODP {description = "1024-bit MODP Group";}
=             &n= bsp;           &nbs= p;      enum 1536-bit-MODP {description = "1536-bit MODP Group";}
=             &n= bsp;           &nbs= p;      enum 2048-bit-MODP {description = "2048-bit MODP Group";}
=             &n= bsp;           &nbs= p;      enum 3072-bit-MODP {description = "3072-bit MODP Group";}
=             &n= bsp;           &nbs= p;      enum 4096-bit-MODP {description = "4096-bit MODP Group";}
=             &n= bsp;           &nbs= p;      enum 6144-bit-MODP {description = "6144-bit MODP Group";}
=             &n= bsp;           &nbs= p;      enum 8192-bit-MODP {description = "8192-bit MODP Group";}
=             &n= bsp;          }
=             &n= bsp;          descriptio= n "PFS group for IPsec rekey";
=             &n= bsp;  }

This is the only entry = still enumerating (partially!) an IANA registry.

[Authors] Right. But I am not sure if there is a = final conclusion about this dilemma. Personally, I still prefer to have = a uint32 and refer Group Description (Value 4) = in 





    leaf-list = ike-sa-authalg { type ic:integrity-algorithm-t; description "Auth = algorigthm for IKE SA=E2=80=9D;}

[Authors] = Done.

Typo in algorigthm

    leaf-list = ike-sa-encalg { type ic:encryption-algorithm-t; description "Auth = algorigthm for IKE SAs";}

Same typo, but it = should also not be "Auth" but "Encryption or AEAD algorithm=E2=80=9D.

[Authors] = Done.


=   description "Configure the IKEv2 software";

Maybe call it "Configuration of the IKEv2 implementation" = ?
(more of these "Configure" vs "Configuration" terms = follow)

[Authors] Ok.


=  leaf pad-entry-id { type uint64; description "SAD index. ";}

did you mean "PAD index=E2=80=9D ?

[Authors] = Yes, it is a typo.

  Whether to use = IKEv2 fragmentation as

Whether or not to = enable IKEv2 fragmentation

(enable because = the other end can not have support, it is just a suggestion, not a = demand)

[Authors] True.


=    container ike-sa-state {
=           container = uptime {
=             &n= bsp; description "IKE service uptime";

Did you mean "IKE connection uptime=E2=80=9D ? =

[Authors] Yes, that = is correct.

To me ike-sa-state means an = IKE state, not IKE service state?

[Authors] = Agree


=    leaf nat-any {type boolean; description "YES, if both = local and remote endpoints are behind a NAT=E2=80=9D;}


I = could call this nat-both instead of nat-any, nat-any suggests it could = be "0 or more=E2=80=9D

[Authors] Done

Seconds before = IKE SA gets rekeyed -> Seconds before IKE SA must be rekeyed
(same for next auth item)

[Authors] = Done.

  description = "Configure Security Association (SA). Section 4.4.2.1 in RFC 4301";

Use "Configuration of IPsec Security = Association (SA). Section 4.4.2.1 in RFC 4301"
To ensure = it is clear this is not about an IKE SA. Same on the next line for
"for a particular SA"

=   leaf seq-number-overflow-flag { type boolean; description = "The flag indicating whether overflow of the sequence number counter = should prevent transmission of additional packets on the SA, or whether = rollover is permitted."; }

What is the = source of this? I thought sequence numbers were never allowed to = overflow?

[Authors] According to RFC 4301 - 4.4.2.1.  Data = Items in the SAD:

Sequence Counter Overflow: a flag indicating whether overflow = of
      the sequence number counter = should generate an auditable event and
  =     prevent transmission of additional packets on the SA, or = whether
      rollover is permitted. =  The audit log entry for this event SHOULD
      include the SPI value, current = date/time, Local Address, Remote
    =   Address, and the selectors from the relevant SAD = entry.




  leaf anti-replay-window { type = uint16 { range "0 | 32..1024"; } description "Anti replay window size"; = }

Why cap at 1024? That could be too low = for 100gbps connections.

[Authors] The truth is that RFC 4301 = mentions:

Anti-Replay = Window: a 64-bit counter and a bit-map (or equivalent)
      used to determine whether an inbound AH = or ESP packet is a replay.

So we can replace this with uint64. On the other hand, we = have observed with uint16 should be enough in real cases. We can remove = the restriction (1024) . what do you think?



  leaf spd-entry-id = {type uint64; description "This value links the SA with the SPD = entry";}

Again, use "IPsec = SA=E2=80=9D

[Authors] = Ok. 

 leaf security-protocol = { type ic:ipsec-protocol; description "Security protocol of IPsec SA: = Either AH or ESP."; }

If we killed AH, = remove from here.

[Authors] Yes, this has already been = removed.

  leaf mode { type = ic:ipsec-mode; description "SA Mode"; }

"IPsec SA". Should it say "tunnel/transport=E2=80=9D ?

[Authors] = Right.

  leaf replay {type = uint32; default 0; description "packets detected out of the replay = window and dropped because they are replay packets";}

That should be: "inside the replay = window=E2=80=9D

[Authors] Good catch. Changed.

=             &n= bsp;typedef sadb-msg-satype {
=             &n= bsp;           type= enumeration {
=             &n= bsp;           &nbs= p;      enum sadb_satype_unspec { = description "SADB_SATYPE_UNSPEC"; }
=             &n= bsp;           &nbs= p;      enum sadb_satype_ah { description = "SADB_SATYPE_AH"; }
=             &n= bsp;           &nbs= p;      enum sadb_satype_esp { description = "SADB_SATYPE_ESP"; }
=             &n= bsp;           &nbs= p;      enum sadb_satype_rsvp { = description "SADB_SATYPE_RSVP"; }
=             &n= bsp;           &nbs= p;      enum sadb_satype_ospfv2 { = description "SADB_SATYPE_OSPFv2"; }
=             &n= bsp;           &nbs= p;      enum sadb_satype_ripv2 { = description "SADB_SATYPE_RIPv2"; }
=             &n= bsp;           &nbs= p;      enum sadb_satype_mip { description = "SADB_SATYPE_MIP"; }
=             &n= bsp;           &nbs= p;      enum sadb_satype_max { description = "SADB_SATYPE_MAX"; }
=             &n= bsp;          }
=             &n= bsp;          descriptio= n "PF_KEY Security Association types";
=             &n= bsp;  }

Is this enumerating an = IANA registry? I think it might be from xfrm.h but I don't know any of = those
except the first three.

[Authors] = Yes, you=E2=80=99r right they belong to xfrm.h (pf_keyv2) . And yes, we = have left UNSPEC and ESP

=   description "Configure integrity for IPSec Authentication = Header (AH)";

"Configuration of integrity = algorithm for IPSec Authentication Header (AH)

[Authors] This has been deleted.


  description "Configure encryption = for IPSec Encapsulation Secutiry Payload (ESP)";

"Configuration of encryption or AEAD algorithm for IPSec = Authentication Header (ESP)"

=   description "Configure authentication for IPSec = Encapsulation Secutiry Payload (ESP)";

See = above, but also I would not use "authentication" here, but "integrity", = as it is really
the same thing as the AH value except for = ESP. So either call both authentication or call both
integrity - i strongly prefer integrity to avoid confusing = with IKE authentication.

[Authors] Done.

=   /* With AEAD algorithms, the integrity node is not used = */

So it can either be fully ommited, or it = can contain the integrity value for None. Perhaps
relfect = that in the comment? There are some implementations that do not handle = both, so there
might be a need to configure "None" as the = integrity algorithm for an AEAD.

[Authors] = If integrity node does not appear in the configuration sent by the = controller, the integrity interpretation is none. We can comment = this. 

Our comment is if the = encryption container is sent to the NSF with an AEAD algorithm the = container integrity is not sent , not required since AEAD algorithm = provides integrity (and encryption)

I = now spotted the entry for AEAD, so now I am a little confused. If the = above encryption is not
used for that, and we have a = special entry for aead, than the above comment is wrong, because
then with AEAD algorithms, encryption and integrity is not = used but combined-enc-intr.

[Authors] = combined-enc-intr has been removed.

We= have only encryption and integrity container now. But an AEAD algorithm = will be included in the encryption leaf and there won=E2=80=99t be = integrity leaf.


I = would be more inclined to keep this more in line with IKEv2, where = AEAD's are just encryption
algorithms. So remove the = combined-enc-intr leaf.

 notification = sadb_expire {
=             &n= bsp;          descriptio= n "A IPsec SA expiration (soft or hard)";

=             &n= bsp;          uses = base-grouping;
=             &n= bsp;          leaf spi = { type ic:ipsec-spi;  description "Security Parameter Index";}
=             &n= bsp;          leaf = anti-replay-window { type uint16 { range "0 | 32..1024"; } description = "Anti replay window"; }

=             &n= bsp;          leaf = encryption-algorithm { type ic:encryption-algorithm-t; description = "encryption algorithm of the expired SA"; }
=             &n= bsp;          leaf = authentication-algorithm { type ic:integrity-algorithm-t; description = "authentication algorithm of the expired SA"; }

So if you keep AEAD as a seperate entry, you also need a leaf = here for it.

[Authors] If the encryption-algorithm is AEAD the = authentication(integrity)-algorithm will not contain any algorithm, = right?.




I see IPcomp is not used anywhere. I agree = with that but I'm not sure if there is WG conensus for that.

[Authors] We did not include IPcomp from the = beginning and until now, there has not been any comment in this = regard.

Some IoT people think compression is super = important.

[Authors] I am aware they are working in some = compression techniques for very constrained links.

nits:

These = appear a few times:

"in IKE case" -> in = the IKE case"
"in IKE-less case" -> in the IKE-less = case"

making IKEv2 configuration -> = making the IKEv2 configuration


  Note that the usage of TRANSPORT mode when NAT = is
  required is forbidden in this = specification.

We normally don't use words = like "forbidden". We usually write that like:

  Transport mode MUST NOT be used when a NAT is = present between
  two NSF's.

and not the IKE-less. -> and not the IKE-less case.

In order to support IKE case and IKE-less case = -> In order to support the IKE and IKE-less cases

I see the use of "IKE case" and the use of "IKE-case". Pick = one and stick to that?


minimu -> minimum

it may access to these values. -> it might have access to = the key material"

It is acting as initiator = in this connection -> It is acting as initiator for this = connection

IKEless -> IKE-less

"A SPD entry has expired" -> "An SPD entry = has expired"

"A IPsec SA is required " = -> "An IPsec SA is required"

"A IPsec SA = expiration (soft or hard)" -> "An IPsec SA expiration (soft or = hard)"

"Security Parameter Index" -> = "Security Parameter Index (SPI)=E2=80=9D

[Authors] All these nits have been = solved.


Thank you very much again for this review and your = time.


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=_F8B20024-0B42-4C71-B7C1-78425663B620-- From nobody Fri May 24 11:38:19 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 E8BAA1202EA; Fri, 24 May 2019 11:38:09 -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, URIBL_BLOCKED=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 tuaVPXoiAB8K; Fri, 24 May 2019 11:38:07 -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 72EE312004B; Fri, 24 May 2019 11:38:07 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 459Zqx0kYJzBT; Fri, 24 May 2019 20:38:05 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1558723085; bh=Ft6LYGlUf8kgkzVjK+apMrkZOQq/U6gdhk/oNwfc9PY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=N1lXuNdfFFiFq3mhwLJh8uK2v2ULlbVYvadEqhn7ylgYJZT+LUfPycIftuihj6x3B 0IKxVjshU32a487ZPpM2TOVIcLtVvCYzxGcFXiHA5L1x7eXDf9Cohhng/RY3YaRfKv ryKNBbSoFMJL7ywV9G1jEexhUkIntwXBPXiZWkg8= 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 JX88BdpYJ1Hg; Fri, 24 May 2019 20:38:01 +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; Fri, 24 May 2019 20:38:00 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0053A898; Fri, 24 May 2019 14:37:57 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0053A898 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DC212401B15B; Fri, 24 May 2019 14:37:57 -0400 (EDT) Date: Fri, 24 May 2019 14:37:57 -0400 (EDT) From: Paul Wouters To: Rafa Marin-Lopez cc: =?ISO-8859-15?Q?Fernando_Pere=F1=EDguez_Garc=EDa?= , "i2nsf@ietf.org" , Gabriel Lopez , Linda Dunbar , "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT 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, 24 May 2019 18:38:10 -0000 On Fri, 24 May 2019, Rafa Marin-Lopez wrote: > Sorry for the delayed answer. Our answer took us more time than expected preparing. Thank you very much again. Please see our comments inline: No problem, thanks for addressing the issues! > [Authors] We have rephrased as: > > “In principle, IKE case is easier to deploy than IKE-less > case because current gateways typically have an IKEv2/IPsec  > implementation. Moreover hosts can install easily an IKE implementation." Looks good. >   The main >   reason is that the Security Controller is not able to observe any >   session keys generated for the IPsec SAs because IKEv2 is in charge >   of negotiating the IPsec SAs. > > I think you mean "because the nodes, not the Security Controller, is > generating the session keys". I would not use the word IKEv2, because > it is unclear if that IKEv2 would be running on the SG or the node. > > > [Authors] That’s right. Let’s only write this sentence: > > "The main reason is that the NSFs are generating the session keys and not the Security Controller”. Looks good. >   For IKE case, the rekeying process is carried out by IKEv2, following >   the information defined in the SPD and SAD. > > That is not the whole story though? Isn't is the Security Controller > that decides when to terminate a connection? I guess it is implied here > that we are talking about connections that are instructed by the SG to > stay up long enough to need rekeying? > > > [Authors] The Security Controller may decide to terminate a connection but, in principle, if nothing unexpected happens after applying IKE configuration > will allow IKE to operate as configured. So, yes, it is expected that connections will live unless something different is required by the administrator or > the SC detects something wrong.  Agreed. no modifications needed. > Section 5.3.1 talks about a bundle of two inbound SA's. That is a little > confusing as traditionally we talk about the bundle being an inbound and > outbound SA from the perspective of one of the endpoints. I understand > you are doing this so you can talk about installing inbound on both ends > first. Perhaps talk initially about the inbound and outbound bundle, > then state you are handing out what is the inbound sa from the point of > view of each endpoint first ? > > > [Authors] We can add the following paragraph. How about this one?: > > "Traditionally, during a rekey process of the IPSec SA using IKE, a bundle of inbound and outbound SAs, from the perspective of one of the NSFs, is taken > into account. For example, if the inbound SA expires both the inbound and outbound SA are rekeyed at the same time in that NSF. However, when IKE is not > used, we have followed a different approach to avoid any packet loss during rekey: the Security Controller installs first the new inbound SAs in both NSFs > and then, the outbound SAs." Looks good. >   It is worth noting that if the IPsec implementation >   can itself detect traffic on the new IPsec SA, and it can delete >   the old IPsec SA itself without instruction from the Security >   Controller, then this step 3 is not required. > > Technically, they can never know this because IKEv2 allows installing > multiple IPsec SA's with the exact same policies. > > > [Authors] We are talking here about IKE-less case so there is no IKEv2. This paragraph was added after , as far as I remember, your comment about this > possibility. I think if the IPsec SAs have different SPIs the SDN controller can distinguish among them Yes, but that was after I was pointed to this text in RFC 7296: Note that IKEv2 deliberately allows parallel SAs with the same Traffic Selectors between common endpoints. One of the purposes of this is to support traffic quality of service (QoS) differences among the SAs (see [DIFFSERVFIELD], [DIFFSERVARCH], and Section 4.1 of [DIFFTUNNEL]). Hence unlike IKEv1, the combination of the endpoints and the Traffic Selectors may not uniquely identify an SA between those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate Traffic Selectors SHOULD NOT be used. So two IPsec SA's might be the same _and_ one of these might not see much if any traffic. Still it should not get deleted. So I would now say my original suggestion is wrong, and we should remove the paragraph that starts with "It is worth noting that if the IPsec implementation" > [Authors] Then the step 3 still applies. Most probably removing the paragraph should be enough, right? Yes just remove it > It can also instruct the affected NSF to send IKEv2 INITIAL_CONTACT. > > I think this is something the IKEv2 implementation would determine on its own. > I would remove the sentence or change it to say the node can determine it > needs to send INITIAL_CONTACT. Also, this removes the need for the SC to > have to relay this option to the IKEv2 NSF. > > [Authors] We have observed some implementations (e.g. libreswan) has this variable initial-contact as well in the ipsec.conf. That is why we decide to > keep it. Is it not useful then? We added it because sending or not sending it might change te behaviour of the other endpoint. libreswan as implementation ignores the payload 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. I guess my point was more to the fact that instructing the NSF to send an INITIAL_CONTACT 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_CONTACT", it is implicitly sending a message to the NSF to bring tunnel X to gateway Y down. Now the NSF and SC might be out of sync if the SC wasn't expecting this result. >   In IKE-less case, if the Security Controller detects that a NSF has >   lost the IPsec SAs (e.g. it reboots) it will delete the old IPsec SAs >   of the non-failed nodes established with the failed node (step 1). >   This prevents the non-failed nodes from leaking plaintext. > > Wouldn't doing that before installing a new IPsec SA not actually _cause_ > leaking plaintext? Unless the non-failed nodes, upon receiving the delete > would put in an SPD policy that would catch packets and trigger an acquire. > > > [Authors] This is an interesting question. We must state that, for security reasons, any NSF should have a default DISCARD policy. A NSF restarting 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. Sure. I think adding some text that says a connection in the "configured but not up" state is expceted to drop or hold onto the packets, that would make it clear. > +--rw security-protocol?          ic:ipsec-protocol > > What does this stand for? There is no "IPsec protocol" in the sense that we do not have > an IANA protocol entry for "IPsec" (only for ESP) > > > [Authors] I understand. The intention was to say ipsec related protocol. Should we use something like ic:ipsec-related-protocol? or  ic:sec-protocol? or maybe ipsec-protocol-parameters ? >   NSFs MUST NOT allow the reading of these values once they have been >   applied by the Security Controller (i.e. write only operations). > > These are not really "applied by the Security Controller". Perhaps you > meant "obtained" instead of “applied" > > [Authors] Since we were referring to IKE-less case the Security Controlles sends these keys to the NSF. In that case, the Security Controller applies the > keys but it MUST NOT BE obtained (read) by anyone (including the SC). Perhaps use: NSF's receiving private key material from the SC, MUST NOT allow the reading ..... > [Authors] We are writing version -05 of these changes will be applied. > >    typedef ipsec-upper-layer-proto { >                        type enumeration { >                                enum TCP { description "TCP traffic"; } >                                enum UDP { description "UDP traffic"; } >                                enum SCTP { description "SCTP traffic";} >                                enum DCCP { description "DCCP traffic";} >                                enum ICMP { description "ICMP traffic";} >                                enum IPv6-ICMP { description "IPv6-ICMP traffic";} >                                enum GRE {description "GRE traffic";} >                        } >                        description "Next layer proto on top of IP"; >                } > > I don't understand ipsec-upper-layer-proto? If this is encapsulation protocol, then > there is only TCP and UDP. If this is the protocol of the encrypted data, then there > are a lot more protocols. The document also nowhere explains the term "upper layer protocol" > I think you mean what I would call the "inner protocol" so that it is every number from the > IANA protocol registry. > > > [Authors] Basically RFC 4301 mentions next layer protocols and we had that in previous versions but it was suggested that was not a good name. So we used > this one. We can use inner protocol. Thus it is not encapsulation but the protocols in the next header after IP header. Ok, so then I think inner protocol would be more clear. > "Next Layer Protocol: Obtained from the IPv4 "Protocol" or the >         IPv6 "Next Header" fields.” > > So it seems  that every number from the IANA protocol registry should be there. So here we have again the same problem as crypto algorithms. However, we > can do as RFC 8519 :  This one did not get answered. Do you plan to link to the protocol registry at IANA ? >                typedef pfs-group { >                        type enumeration { >                                enum NONE {description "NONE";} >                                enum 768-bit-MODP {description "768-bit MODP Group";} >                                enum 1024-bit-MODP {description "1024-bit MODP Group";} >                                enum 1536-bit-MODP {description "1536-bit MODP Group";} >                                enum 2048-bit-MODP {description "2048-bit MODP Group";} >                                enum 3072-bit-MODP {description "3072-bit MODP Group";} >                                enum 4096-bit-MODP {description "4096-bit MODP Group";} >                                enum 6144-bit-MODP {description "6144-bit MODP Group";} >                                enum 8192-bit-MODP {description "8192-bit MODP Group";} >                        } >                        description "PFS group for IPsec rekey"; >                } > > This is the only entry still enumerating (partially!) an IANA registry. > > > [Authors] Right. But I am not sure if there is a final conclusion about this dilemma. Personally, I still prefer to have a uint32 and refer Group > Description (Value 4) in  > > https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml That's an old IKEv1 registry, you would want to link it to: https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-8 And it would be a uint16, not a uint32. > Use "Configuration of IPsec Security Association (SA). Section 4.4.2.1 in RFC 4301" > To ensure it is clear this is not about an IKE SA. Same on the next line for > "for a particular SA" > >   leaf seq-number-overflow-flag { type boolean; description "The flag indicating whether overflow of the sequence number counter should > prevent transmission of additional packets on the SA, or whether rollover is permitted."; } > > What is the source of this? I thought sequence numbers were never allowed to overflow? > > > [Authors] According to RFC 4301 - 4.4.2.1.  Data Items in the SAD: > > Sequence Counter Overflow: a flag indicating whether overflow of >       the sequence number counter should generate an auditable event and >       prevent transmission of additional packets on the SA, or whether >       rollover is permitted.  The audit log entry for this event SHOULD >       include the SPI value, current date/time, Local Address, Remote >       Address, and the selectors from the relevant SAD entry. 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. Tero, do you know anything more about this feature? I don't think we could ever negotiate it via IKE anyway? >   leaf anti-replay-window { type uint16 { range "0 | 32..1024"; } description "Anti replay window size"; } > > Why cap at 1024? That could be too low for 100gbps connections. > > > [Authors] The truth is that RFC 4301 mentions: > > Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) >       used to determine whether an inbound AH or ESP packet is a replay. > > So we can replace this with uint64. On the other hand, we have observed with uint16 should be enough in real cases. We can remove the restriction (1024) . > what do you think? Yes, I think the uint16 is more than enough, as long as you don't mention any cap like 1024. > [Authors] Right. > >   leaf replay {type uint32; default 0; description "packets detected out of the replay window and dropped because they are replay packets";} > > That should be: "inside the replay window” > [Authors] Good catch. Changed. Actually, now I am not sure anymore :) Outside the replay window, if the number is too low, it should be dropped. If it is too high, I think once decrypted successfully, the window is updated. If the packet is within the window, we keep a list of received / not-received sequence numbers, and drop duplicates ? So I think I misled you and you were correct with the original text. > [Authors] If integrity node does not appear in the configuration sent by the controller, the integrity interpretation is none. We can comment this.  > Our comment is if the encryption container is sent to the NSF with an AEAD algorithm the container integrity is not sent , not required since AEAD > algorithm provides integrity (and encryption) Just to clarify, some (bad) implementations handle "no integrity transforms" differently from "the integrity transform NONE" (value 0) I know older libreswan versions did it wrong. However, I am not sure if this needs to be exposed here. I think it is fine to that the model states to not send any integrity transform, and that the implementation properly handles it when it receives an ENCR transforms AES_GCM with an INTEG transform NONE. > [Authors] combined-enc-intr has been removed. Great! > I see IPcomp is not used anywhere. I agree with that but I'm not sure if there is WG conensus for that. > > [Authors] We did not include IPcomp from the beginning and until now, there has not been any comment in this regard. Okay. I guess the model can always be extended in the future if needed. Thanks! Paul From nobody Tue May 28 16:14:58 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 975801200A4; Tue, 28 May 2019 16:14:50 -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_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 tKWF1dwyxM9B; Tue, 28 May 2019 16:14:48 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0B34120090; Tue, 28 May 2019 16:14:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 387A3B80E5B; Tue, 28 May 2019 16:14:46 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, ipsec@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190528231446.387A3B80E5B@rfc-editor.org> Date: Tue, 28 May 2019 16:14:46 -0700 (PDT) Archived-At: Subject: [IPsec] =?utf-8?q?RFC_8598_on_Split_DNS_Configuration_for_the_In?= =?utf-8?q?ternet_Key_Exchange_Protocol_Version_2_=28IKEv2=29?= 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, 28 May 2019 23:14:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8598 Title: Split DNS Configuration for the Internet Key Exchange Protocol Version 2 (IKEv2) Author: T. Pauly, P. Wouters Status: Standards Track Stream: IETF Date: May 2019 Mailbox: tpauly@apple.com, pwouters@redhat.com Pages: 16 Characters: 36887 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsecme-split-dns-17.txt URL: https://www.rfc-editor.org/info/rfc8598 DOI: 10.17487/RFC8598 This document defines two Configuration Payload Attribute Types (INTERNAL_DNS_DOMAIN and INTERNAL_DNSSEC_TA) for the Internet Key Exchange Protocol version 2 (IKEv2). These payloads add support for private (internal-only) DNS domains. These domains are intended to be resolved using non-public DNS servers that are only reachable through the IPsec connection. DNS resolution for other domains remains unchanged. These Configuration Payloads only apply to split- tunnel configurations. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 29 03:55:21 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 5B1531200B1; Wed, 29 May 2019 03:55:13 -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 j9_txpcBnglO; Wed, 29 May 2019 03:55:09 -0700 (PDT) Received: from xenon44.um.es (xenon44.um.es [155.54.212.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8B9120092; Wed, 29 May 2019 03:55:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon44.um.es (Postfix) with ESMTP id DC5B320354; Wed, 29 May 2019 12:55:06 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon44.um.es Received: from xenon44.um.es ([127.0.0.1]) by localhost (xenon44.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MxJ72Fx42mi2; Wed, 29 May 2019 12:55:06 +0200 (CEST) Received: from [155.54.14.162] (unknown [155.54.14.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon44.um.es (Postfix) with ESMTPSA id 9C268202E0; Wed, 29 May 2019 12:55:03 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Rafa Marin Lopez In-Reply-To: Date: Wed, 29 May 2019 12:55:02 +0200 Cc: Rafa Marin Lopez , =?utf-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , "i2nsf@ietf.org" , Gabriel Lopez , "ipsec@ietf.org WG" , Linda Dunbar Content-Transfer-Encoding: quoted-printable Message-Id: <718671CF-46BF-427A-A008-A9F8EB3631D0@um.es> References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> To: Paul Wouters X-Mailer: Apple Mail (2.3445.104.8) 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: Wed, 29 May 2019 10:55:14 -0000 Hi Paul: Please see some additional comments inline: snip >=20 >> It can also instruct the affected NSF to send IKEv2 = INITIAL_CONTACT. >>=20 >> I think this is something the IKEv2 implementation would = determine on its own. >> I would remove the sentence or change it to say the node can = determine it >> needs to send INITIAL_CONTACT. Also, this removes the need for = the SC to >> have to relay this option to the IKEv2 NSF. >> [Authors] We have observed some implementations (e.g. libreswan) has = this variable initial-contact as well in the ipsec.conf. That is why we = decide to >> keep it. Is it not useful then? >=20 > We added it because sending or not sending it might change te = behaviour > of the other endpoint. libreswan as implementation ignores the payload > 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 send > an INITIAL_CONTACT 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_CONTACT", it is implicitly sending a = message > to the NSF to bring tunnel X to gateway Y down. Now the NSF and SC = might > be out of sync if the SC wasn't expecting this result. [Authors] Then it is safer to remove this possibility. Done. >=20 >> In IKE-less case, if the Security Controller detects that a = NSF has >> lost the IPsec SAs (e.g. it reboots) it will delete the old = IPsec SAs >> of the non-failed nodes established with the failed node (step = 1). >> This prevents the non-failed nodes from leaking plaintext. >>=20 >> Wouldn't doing that before installing a new IPsec SA not = actually _cause_ >> leaking plaintext? Unless the non-failed nodes, upon receiving = the delete >> would put in an SPD policy that would catch packets and trigger = an acquire. >> [Authors] This is an interesting question. We must state that, for = security reasons, any NSF should have a default DISCARD policy. A NSF = restarting 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 = "configured > but not up" state is expceted to drop or hold onto the packets, that > would make it clear. [Authors] We understand. In the IKE-less case we do not have this kind = of "configured but not up=E2=80=9D state. We assume that once the SC = configures the NSF with the IPsec SA, the NSF will apply the = configuration right way without waiting anything else. In IKE case it is possible to define this with the type-autostartup = (on-demand) by adding your text to the description. However, I was = thinking that, actually, this is a general security policy that should = be applied in both iKE-case and IKE-less and, even, when the NSF starts = in the network and there is no contact with the NSF. Perhaps the best place to mention this is in the Security Considerations = section. Then, we can add in the model the text you mention. We could = include this paragraph in Security Considerations (the general part not = specific to any case): =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 >> +--rw security-protocol? ic:ipsec-protocol >>=20 >> What does this stand for? There is no "IPsec protocol" in the = sense that we do not have >> an IANA protocol entry for "IPsec" (only for ESP) >> [Authors] I understand. The intention was to say ipsec related = protocol. Should we use something like ic:ipsec-related-protocol? or = ic:sec-protocol? >=20 > or maybe ipse-protocol-parameters ? [Authors] Ok. >=20 >> NSFs MUST NOT allow the reading of these values once they have = been >> applied by the Security Controller (i.e. write only = operations). >>=20 >> These are not really "applied by the Security Controller". = Perhaps you >> meant "obtained" instead of =E2=80=9Capplied" >> [Authors] Since we were referring to IKE-less case the Security = Controlles sends these keys to the NSF. In that case, the Security = Controller applies the >> keys but it MUST NOT BE obtained (read) by anyone (including the SC). >=20 > Perhaps use: >=20 > NSF's receiving private key material from the SC, MUST NOT allow = the reading =E2=80=A6.. [Authors] Ok >=20 >> [Authors] We are writing version -05 of these changes will be = applied. >>=20 >> typedef ipsec-upper-layer-proto { >> type enumeration { >> enum TCP { description "TCP = traffic"; } >> enum UDP { description "UDP = traffic"; } >> enum SCTP { description "SCTP = traffic";} >> enum DCCP { description "DCCP = traffic";} >> enum ICMP { description "ICMP = traffic";} >> enum IPv6-ICMP { description = "IPv6-ICMP traffic";} >> enum GRE {description "GRE = traffic";} >> } >> description "Next layer proto on top of = IP"; >> } >>=20 >> I don't understand ipsec-upper-layer-proto? If this is = encapsulation protocol, then >> there is only TCP and UDP. If this is the protocol of the = encrypted data, then there >> are a lot more protocols. The document also nowhere explains the = term "upper layer protocol" >> I think you mean what I would call the "inner protocol" so that = it is every number from the >> IANA protocol registry. >> [Authors] Basically RFC 4301 mentions next layer protocols and we had = that in previous versions but it was suggested that was not a good name. = So we used >> this one. We can use inner protocol. Thus it is not encapsulation but = the protocols in the next header after IP header. >=20 > Ok, so then I think inner protocol would be more clear. [Authors] Ok. >=20 >> "Next Layer Protocol: Obtained from the IPv4 "Protocol" or the >> IPv6 "Next Header" fields.=E2=80=9D >> So it seems that every number from the IANA protocol registry should = be there. So here we have again the same problem as crypto algorithms. = However, we >> can do as RFC 8519 :=20 >=20 > This one did not get answered. Do you plan to link to the protocol > registry at IANA ? [Authors] Our approach so far will be similar to the one we found in RFC = 8519. There they use a type uint8 and give a description and preference. = More specifically: leaf protocol { type uint8; description "Internet Protocol number. Refers to the protocol of the payload. In IPv6, this field is known as 'next-header', and if extension headers are present, the protocol is present in the 'upper-layer' header."; reference " RFC 791 : Internet Protocol =20 RFC 8200 : Internet Protocol, Version 6 (IPv6) Specification."; } Therefore, we would like to add something a uint8 and referring to IANA = registry. Is this approach acceptable for you? We will take also the same approach for crypto-algs so far in order to = see if this is valid for yang-doctors' review >=20 >> typedef pfs-group { >> type enumeration { >> enum NONE {description "NONE";} >> enum 768-bit-MODP {description = "768-bit MODP Group";} >> enum 1024-bit-MODP {description = "1024-bit MODP Group";} >> enum 1536-bit-MODP {description = "1536-bit MODP Group";} >> enum 2048-bit-MODP {description = "2048-bit MODP Group";} >> enum 3072-bit-MODP {description = "3072-bit MODP Group";} >> enum 4096-bit-MODP {description = "4096-bit MODP Group";} >> enum 6144-bit-MODP {description = "6144-bit MODP Group";} >> enum 8192-bit-MODP {description = "8192-bit MODP Group";} >> } >> description "PFS group for IPsec rekey"; >> } >>=20 >> This is the only entry still enumerating (partially!) an IANA = registry. >> [Authors] Right. But I am not sure if there is a final conclusion = about this dilemma. Personally, I still prefer to have a uint32 and = refer Group >> Description (Value 4) in=20 >> https://www.iana.org/assignments/ipsec-registry/ipsec-registry.xhtml >=20 > That's an old IKEv1 registry, you would want to link it to: >=20 > = https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#i= kev2-parameters-8 >=20 > And it would be a uint16, not a uint32. [Authors] Great. Here again, it is worth noting that we will specify the = uint16 and link it to the information you provide to that IANA registry. >=20 >> Use "Configuration of IPsec Security Association (SA). Section = 4.4.2.1 in RFC 4301" >> To ensure it is clear this is not about an IKE SA. Same on the = next line for >> "for a particular SA" >>=20 >> leaf seq-number-overflow-flag { type boolean; description "The = flag indicating whether overflow of the sequence number counter should >> prevent transmission of additional packets on the SA, or whether = rollover is permitted."; } >>=20 >> What is the source of this? I thought sequence numbers were = never allowed to overflow? >> [Authors] According to RFC 4301 - 4.4.2.1. Data Items in the SAD: >> Sequence Counter Overflow: a flag indicating whether overflow of >> the sequence number counter should generate an auditable event = and >> prevent transmission of additional packets on the SA, or = whether >> rollover is permitted. The audit log entry for this event = SHOULD >> include the SPI value, current date/time, Local Address, Remote >> 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=E2=80=99s.= [Authors] We have included this in the description: "The flag indicating whether overflow of the sequence number counter = should prevent transmission of additional packets on the IPsec SA (FALSE), or whether = rollover is permitted (TRUE). If Authenticated Encryption with = Associated Data (AEAD) is used this flag MUST BE false.=E2=80=9D; >=20 > Tero, do you know anything more about this feature? I don't think we > could ever negotiate it via IKE anyway? >=20 >> leaf anti-replay-window { type uint16 { range "0 | 32..1024"; = } description "Anti replay window size"; } >>=20 >> Why cap at 1024? That could be too low for 100gbps connections. >> [Authors] The truth is that RFC 4301 mentions: >> Anti-Replay Window: a 64-bit counter and a bit-map (or equivalent) >> used to determine whether an inbound AH or ESP packet is a = replay. >> So we can replace this with uint64. On the other hand, we have = observed with uint16 should be enough in real cases. We can remove the = restriction (1024) . >> what do you think? >=20 > Yes, I think the uint16 is more than enough, as long as you don't = mention any cap like 1024. [Authors] OK >=20 >> [Authors] Right. >>=20 >> leaf replay {type uint32; default 0; description "packets = detected out of the replay window and dropped because they are replay = packets";} >>=20 >> That should be: "inside the replay window=E2=80=9D >=20 >> [Authors] Good catch. Changed. >=20 > Actually, now I am not sure anymore :) >=20 > Outside the replay window, if the number is too low, it should be > dropped. If it is too high, I think once decrypted successfully, the > window is updated. If the packet is within the window, we keep a list > of received / not-received sequence numbers, and drop duplicates ? >=20 > So I think I misled you and you were correct with the original text. [Authors] No problem. We can leave it. >=20 >> [Authors] If integrity node does not appear in the configuration sent = by the controller, the integrity interpretation is none. We can comment = this.=20 >=20 >> Our comment is if the encryption container is sent to the NSF with an = AEAD algorithm the container integrity is not sent , not required since = AEAD >> algorithm provides integrity (and encryption) >=20 > Just to clarify, some (bad) implementations handle "no integrity > transforms" differently from "the integrity transform NONE" (value 0) >=20 > I know older libreswan versions did it wrong. However, I am not sure = if > this needs to be exposed here. I think it is fine to that the model > states to not send any integrity transform, and that the = implementation > properly handles it when it receives an ENCR transforms AES_GCM with > an INTEG transform NONE. [Authors] Correct. We think this can be handled by the implementation as = well. >=20 >> [Authors] combined-enc-intr has been removed. >=20 > Great! >=20 >> I see IPcomp is not used anywhere. I agree with that but I'm not = sure if there is WG conensus for that. >> [Authors] We did not include IPcomp from the beginning and until now, = there has not been any comment in this regard. >=20 > Okay. I guess the model can always be extended in the future if = needed. Indeed. Thank you very much again!. >=20 > Thanks! >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed May 29 07:44:30 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 111C0120122; Wed, 29 May 2019 07:44:21 -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 pmSKbRc8-e6g; Wed, 29 May 2019 07:44:19 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 DCC7412010C; Wed, 29 May 2019 07:44:18 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45DYPs040gzFQV; Wed, 29 May 2019 16:44:17 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1559141057; bh=rOQ/3E0TD2Df6s1x0ivdkoeT8jzJbKBRMJGcXADu8Ps=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LySkQHvSllmbUjvFYaMxuT1eqayLpDx4PGO8ccKQFCJio9ejzZT/TQVeFdPQZeo0u F5a5LRKAV6UUGZAzI4Vt2xcjYElqR4ZcHNn+mQSRc3X6T3s483Yq5AeZG/7VymCFMJ Il0qU8B4G5PKCopKW6oLO86Qhzj2woYbO0W2fTCg= 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 CDiAFj6B2AQq; Wed, 29 May 2019 16:44:15 +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; Wed, 29 May 2019 16:44:14 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AC5833159D9; Wed, 29 May 2019 10:44:13 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca AC5833159D9 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A4B0940BE921; Wed, 29 May 2019 10:44:13 -0400 (EDT) Date: Wed, 29 May 2019 10:44:13 -0400 (EDT) From: Paul Wouters To: Rafa Marin Lopez cc: =?ISO-8859-15?Q?Fernando_Pere=F1=EDguez_Garc=EDa?= , "i2nsf@ietf.org" , Gabriel Lopez , "ipsec@ietf.org WG" , Linda Dunbar In-Reply-To: <718671CF-46BF-427A-A008-A9F8EB3631D0@um.es> Message-ID: References: <4A95BA014132FF49AE685FAB4B9F17F66B3869DE@sjceml521-mbs.china.huawei.com> <718671CF-46BF-427A-A008-A9F8EB3631D0@um.es> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT 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: Wed, 29 May 2019 14:44:21 -0000 On Wed, 29 May 2019, Rafa Marin Lopez wrote: > Please see some additional comments inline: > [Authors] We understand. In the IKE-less case we do not have this kind of "configured but not up” state. We assume that once the SC configures the NSF with the IPsec SA, the NSF will apply the configuration right way without waiting anything else. > > In IKE case it is possible to define this with the type-autostartup (on-demand) by adding your text to the description. However, I was thinking that, actually, this is a general security policy that should be applied in both iKE-case and IKE-less and, even, when the NSF starts in the network and there is no contact with the NSF. > > Perhaps the best place to mention this is in the Security Considerations section. Then, we can add in the model the text you mention. We could include this paragraph in Security Considerations (the general part not specific to any case): > > “For 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. >> This one did not get answered. Do you plan to link to the protocol >> registry at IANA ? > > [Authors] Our approach so far will be similar to the one we found in RFC 8519. There they use a type uint8 and give a description and preference. More specifically: > > leaf protocol { > type uint8; > description > "Internet Protocol number. Refers to the protocol of the > payload. In IPv6, this field is known as 'next-header', > and if extension headers are present, the protocol is > present in the 'upper-layer' header."; > reference > " > RFC 791 > : Internet Protocol > > RFC 8200 > : Internet Protocol, Version 6 (IPv6) Specification."; > } > > Therefore, we would like to add something a uint8 and referring to IANA registry. Is this approach acceptable for you? Sounds good. > We will take also the same approach for crypto-algs so far in order to see if this is valid for yang-doctors' review Okay. >>> [Authors] According to RFC 4301 - 4.4.2.1. Data Items in the SAD: >>> Sequence Counter Overflow: a flag indicating whether overflow of >>> the sequence number counter should generate an auditable event and >>> prevent transmission of additional packets on the SA, or whether >>> rollover is permitted. The audit log entry for this event SHOULD >>> include the SPI value, current date/time, Local Address, Remote >>> Address, and the selectors from the relevant SAD entry. >> >> >> 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. > > [Authors] We have included this in the description: > > "The flag indicating whether overflow of the sequence number counter should prevent > transmission of additional packets on the IPsec SA (FALSE), or whether rollover is permitted (TRUE). If Authenticated Encryption with Associated Data (AEAD) is used this flag MUST BE false.”; Okay, good. With these, I think you resolved all my outstanding issues I had. Thanks! Paul