From nobody Tue Sep 1 07:33:37 2020 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 739F63A091A for ; Tue, 1 Sep 2020 07:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 7iLUsuMYH3vW for ; Tue, 1 Sep 2020 07:33:33 -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 867B13A0915 for ; Tue, 1 Sep 2020 07:33:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BgqLf11ZjzGCy; Tue, 1 Sep 2020 16:33:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1598970810; bh=UaeDLJUjZC+ISliKXoEA80E1KnFde7c39ZHWCy4yRwk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=KrP+BWg1B9EAj37TzCWteR/uUiSQzV7iUa2mqSwLiNYxrucW2PoDrfU2YbahLIDhP nYR7CbCcGZbz3umSu2ntYCLQ/Bh3+voqKRlRJQ9QMUH/VnkwPp33RXSy+hKrioKGtw ET7UpzJHjPceAv3N+TaxvkNY9Onf/s5onAtVUJkc= 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 8yIuBMjfF6bT; Tue, 1 Sep 2020 16:33:29 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 1 Sep 2020 16:33:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A7B256029B99; Tue, 1 Sep 2020 10:33:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 9D8BB669F1; Tue, 1 Sep 2020 10:33:27 -0400 (EDT) Date: Tue, 1 Sep 2020 10:33:27 -0400 (EDT) From: Paul Wouters To: Michael Richardson cc: "ipsec@ietf.org WG" In-Reply-To: <20447.1598895285@localhost> Message-ID: References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23589.701449.658566@fireball.acr.fi> <20447.1598895285@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 01 Sep 2020 14:33:35 -0000 On Mon, 31 Aug 2020, Michael Richardson wrote: > Tero Kivinen wrote: > > Normally the ticket is encrypted with key that is changed every time > > the server configuration changes, which means changing the server > > configuration will invalidate all tickets. > > This is probably a rather bad thing. > In many cases there is a single configuration "template" which applies to all > users who authenticate with a certificate from a certain CA, or with a login > matching some pattern. > > In order to store the configuration serial number, on a per-user basis, then > some state is created a per-user basis. This does not sound like a horrible > thing to me, but it is probably something new. What we did for libreswan was to add a connection serial number and place this in the encrypted ticket. So if the ticket is presented, the connection serial is looked up. If it does not exist, the ticket is invalid. Whenever the connection template is reloaded, meaning the connection configuration could have changed, the serial number is changed. This ensures that a reloaded connection on server invalidates all issued tickets. We are planning to use an encryption key that is generated every once in while (prob 24h) and we will keep the last replaced key around for a little while as well. We are still looking at the best working lifetimes and how we will interact these with ike lifetime, ipsec lifetime and re-authentication lifetime. > If one keeps the parent SA around, then one has some state in which to store > per-user data. If you keep that around on the server in a dormant state, you will quickly connect too many of these when you have thousands of clients continuously reconnecting. And a lot of lookups to delete these old IKE SA's when the client has started a new one without resumption. I don't see a use case for this, provided an errata clarifies the liveness triggered server deletes and the client suppresses deletes when it has a ticket to resume and its state says it should remain up. Paul From nobody Tue Sep 1 08:22:21 2020 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 BD8DD3A0B50 for ; Tue, 1 Sep 2020 08:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 0cLplVnnC1mw for ; Tue, 1 Sep 2020 08:22:17 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 58A863A0B4E for ; Tue, 1 Sep 2020 08:22:16 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id CF8571B00189; Tue, 1 Sep 2020 18:22:11 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598973731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oFUqWHIUAR7RSobLMZLsfseLEZx6dCWEUjLxFoj12uY=; b=G+B0tZ8eFrjiF8xiPdIZBYKw33y1GaC+InEX/lnlV8TkC+tztHYPz+E1LNzjUy+tYzx2z5 6/e/7LAb9a9wqlQZTct2BFeMXjzFG6pOCsoXRrVLn/BdtW/6qIMJm6R0FenXVUPOj2FioY G+RxF9vihZU53hnSX27IlqI5N6ayHWxHCetFHqcphKVAoctTTmAXVI/9ztpKDrBxiLy3gV /AlXKoXQI8IQoaZLMHgDfJFNPULafx+z71ZXuljWLurcYLKgDY/Da5HN6U6wX+pbJu5TXg KPArOgo/UuUzT6HyYIGhR09UCylVl0bOaxW31lcH2RmrEtMiSHQe4B1/s5CNDw== Received: by fireball.acr.fi (Postfix, from userid 15204) id AE8CF25C1252; Tue, 1 Sep 2020 18:22:07 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24398.26399.665122.367573@fireball.acr.fi> Date: Tue, 1 Sep 2020 18:22:07 +0300 From: Tero Kivinen To: Paul Wouters Cc: nupur202000@gmail.com, "ipsec\@ietf.org WG" In-Reply-To: References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23952.909994.886850@fireball.acr.fi> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 17 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598973731; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oFUqWHIUAR7RSobLMZLsfseLEZx6dCWEUjLxFoj12uY=; b=ZAkuhgcWBxswhMWNJfJuIdQl1u98xbrcYxT/H36saTfCO6vR7gbPGzWAJDUi4tlgInTyON hFB74c/LQnLzh8AkE9oULdihY6WYU0Pg7ZTi4LES+/Dm0EHYh/4/ZXIblT39QDxQiVHaSI i7hQKx+8t89dsOFO/0SWxAAgLpqO9YuQhrduqP9OUII5Uar3MBYwX19ZrSQUrzy+0kDx/1 XJWl00uuS8KyOobs3mOWJzRCCGWwlG198VvHGcsgGkIrlJAnw0ohieG4o5m3/y34bZlCOu 9ygFOhMheOx/eEBDYXi0CItQfJw98LfWds9N+SYMHtyPwSyUpkfqniKvCMkFsQ== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1598973731; a=rsa-sha256; cv=none; b=pJq7hxdTPqdrRq+FvXgJ4GheSSFrQ1jKVLqi0v9oFgx08Z/jeXq7OaeISdXO5atnTlltss aSCUh8mEFH2y2IbxQgJECx48rsNp1rJkIbl7AFsSFjnudaofHNsJvJYtGf+uEvkHFFwI4j bJSH8SsmhaiWhIyPvfFODoumvojVBS8w/ClT8c3T8qRhcsmHzyZ/MtqhDQuuofaECSBF9P 2g1BP6lAKgex0+mDZO/Wo50OwqEMrKex0t09oz6kICMooYv1DAHYekbmr/vG3QWbY4uioG OLEMgKRg6B1hTNSMcC9QtNr8DiVSXec5HiDlNlMRV0vNrTQMKCTVxkVaMLBYQg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 01 Sep 2020 15:22:20 -0000 Paul Wouters writes: > On Mon, 31 Aug 2020, Tero Kivinen wrote: > > > That should not matter, the server should not invalidate tickets even > > if there is liveness failures, as if it does that every time there is > > transient network failure the resumption is useless. > > I agree, but that is not what the RFC says. Perhaps this would qualify > for an Errata ? Note, that when liveness check fails there is NO delete to be sent over the IKE SA, thus IKE SA is not deleted, it was just deemed to have failed. If any implementation sends Delete notification when liveness check fails that is a bug... RFC7296 says: ---------------------------------------------------------------------- 2.1. Use of Retransmission Timers ... IKE is a reliable protocol: the initiator MUST retransmit a request until it either receives a corresponding response or deems the IKE SA to have failed. In the latter case, the initiator discards all state associated with the IKE SA and any Child SAs that were negotiated using that IKE SA. ---------------------------------------------------------------------- I.e., there is no delete notification sent, and IKE sa is not deleted, initiator just discards all state associated with IKE SA (and this would be the SGW side doing and failing the liveness checks). If the stateless resumption is used, then there is no state in SGW side anyway to be stored, so when client comes back with resumption request then server recreates the state. RFC5723 explitly says that "In particular, when an IKE SA is deleted by the client or the gateway, the client MUST delete its stored ticket.", which would mean active delete operation, not just destroying of state because of liveness failures. Also 3 is quite clear that losing network connection and ike sa timing out because of liveness tests does NOT invalidate ticket, as this is expected case where ticket is used to reconnect. Same with suspending laptop. > > At one point I did propose an option for MOBIKE to send address update > > without any addresses, i.e., saying that I will go to sleep so I will > > not have any addresses you can use to connect to me, do not call me, I > > will call you when I am back... > > > > If I remember right people considered it too complex, and this was not > > accepted > > But it is possible, sort of. The client just sleeps and upon wake up > sends the UPDATE without any addresses specified and the responder > will update to the address and port of the IKE header (after packet > was authenticated). But you are right in that with MOBIKE, we have no > way of saying "please suspend any liveness tests - I will be out of > the office". > > I do think overall it would have been better to have 1 solution instead > of 2. But I think with supporting both, things can work the way we want. > > For unexpected network outages we can switch interface using MOBIKE. > Like phone losing wifi briefly in the elevator. For expected downtime, > eg "phone is going to sleep mode" we can use RESUME to reconnect. You use mobike if your IP-addresses changes, but IKE SA is still active. You use resume if you were away so long that IKE SA state was cleared out on the SGW. > Resume does take two roundtrips over mobike taking one. So perhaps it > would still be nice to have the "out of office notify" to instruct > the server to disable liveness so MOBIKE can be used instead of RESUME. > However, that does take more resources on the server. But looking at > realy busy servers now - it is a stream of (re)connecting clients, > so I'll take any solution even if it needs state as it is less work > than all these new DH exchanges. Modifying MOBIKE so that there is one new NO_ADDRESSES notification which says there will not be any addresses for the client, not even the one over which this message came in, and then server should simply blackhole all communications for this client until it comes back and gives some addresses (and of course disable liveness checks). If IKE SA or Child SA expires or needs to be rekeyed then as packets are blackholed, the SGW acts just like the operation timedout, i.e. descards IKE SA state). In that case when client comes back and tries to do mobike, it will fail with INVALID_IKE_SPI as the SGW has descarded state for that IKE SA, so client can do resumption to get IKE SA back. -- kivinen@iki.fi From nobody Tue Sep 1 08:34:35 2020 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 965F03A0B92 for ; Tue, 1 Sep 2020 08:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 uTRXhAeR554Z for ; Tue, 1 Sep 2020 08:34:29 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (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 7278D3A0B8D for ; Tue, 1 Sep 2020 08:34:29 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 7CD9F1B00189; Tue, 1 Sep 2020 18:34:27 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598974467; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ih60cKy25lwd4eR5GXbm8GVwzDAgUd3TqID6FFjbmHY=; b=HGykyaDiK1g/Iwze5xJob9SWfY3C2+AOxVCW8QjUf+twaqHF2ZGXpYKAGJzB02+PbjislQ 8BAJS2WatoqzeEF1AzGqA6Wuu4tBkbXV11Q1MrdLMY2ocegJZwTbORp0JybpcVQeW4kEDm KZFmO9WfooltkKADC+JhPh8PY0juSHNsi1eYEISo50qFIFuiTsYiqv/ymgBeGJfhDoUOn1 4H5EY/JjJpuNhC0yiC32IvZUyhEkINfT8E6kCkFNJXG6TiG/OFC73kvL/BY1P7laNYRJoe 0tv+NAGe6PbhrYMxa4PeDey0WMNCxNBG0JiAl7IJD/uItQgN6qzGjFdyXVjb+w== Received: by fireball.acr.fi (Postfix, from userid 15204) id 3BBEC25C1256; Tue, 1 Sep 2020 18:34:27 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24398.27138.979226.920386@fireball.acr.fi> Date: Tue, 1 Sep 2020 18:34:26 +0300 From: Tero Kivinen To: Michael Richardson Cc: "ipsec\@ietf.org WG" In-Reply-To: <20447.1598895285@localhost> References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23589.701449.658566@fireball.acr.fi> <20447.1598895285@localhost> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 11 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1598974467; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Ih60cKy25lwd4eR5GXbm8GVwzDAgUd3TqID6FFjbmHY=; b=kIR6VygzWZb1+IhYT6Jmi0tiecrNw/fumPG6V219lwafN6QOTLIYHCLGkIDg/jnXVUF6jQ tTQiepYQHCBXOVA/fUwG4EATXPJ7UJpYvUldM9S0FKdJkqB6Z3ojfPErPyjlQuZhA6MGYp KrWz5UuyQUc5KmJy9dtawoEz224I2Wgz+CMh35bobiloS8s0yROS3Pu7sMK9+TuRywb9Xd FWjUqhl7esqiQ4k7JJjXAW13OOnJcomF1WzjB1yh8w76v85Ar4yc5+aK9uZEYDeM74D1Kx qHBu62f67LtBFFg9ko1fh0gGj0qnMibnVs8btA3va6J9f7RE12ihhNWxzwkUog== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1598974467; a=rsa-sha256; cv=none; b=HRPigoewod0weW/ME5Gux7mFlO7TdOy8P4q+XTKlvb8gRcievMmBy5w0G1JUyY7y78uvb9 B+wK3bLEC6MUTfQLrDX3kQ6XFgrhUo12/pEwCmPgFS3FJIpGmIurke+pdE/TVkqaSXhepv 7HiOO6G9cNpCHwJvhqtZDbr8bSX2TdJz2goQ9S243xWlYC5M6BBnBp8vSF1em5ES8Ihavw 00XpsxX3HQdwZazixdtaccK+VEeagajsodzjJtKlf9IXvgM6Tcj9lrTjqzXu+D0lITqMJK curJqgzbfmUOm0/FPKbGVpW85tw+rPtA2hhFFH+3z9sYUeiXr9ktSkjEaifxgg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 01 Sep 2020 15:34:32 -0000 Michael Richardson writes: > > Tero Kivinen wrote: > > Normally the ticket is encrypted with key that is changed every time > > the server configuration changes, which means changing the server > > configuration will invalidate all tickets. > > This is probably a rather bad thing. If server configuration is changed to require AES-GCM instead of 3DES then I think all active tickets needs to be invalidated to make sure they do not work. Easiest way is to change the ticket encrypting key. Or if configuration is changed so that tunnels to 10.0.0.0/8 is no longer allowed... Global configuration changes are quite rare, and most implementations I know do not bother checking whether existing IKE SAs match the new policy or not, but simply delete all IKE SAs and recreates them. Of course things that do not affect existing IKE SAs like adding new users, or new networks etc are not really such global changes, and do not require IKE SAs to be recreated. Again if you want you can make your implementation so it matches the policy and all existing IKE or Child SAs, and deletes only those IKE or Child SAs which are against new policy, but that is quite complicated thing to do, especially as you might not have stored all information needed to match the policy (i.e., you might not have the original certificate used to authenticate the specific IKE SA, so you might not be able to match whether that has something that is no required by new policy). > > If this is not wanted for > > change which only affects certain user, then ticket should contain > > user identification number or similar, and the configuration serial > > number for that user, and every time something changes in the user > > configuration which requires revoking outstanding tickets, the > > configuration serial number for that user is incremented. If client > > tries to use ticket which has wrong configuration serial number for > > user, then server will simply reject that ticket. > > In many cases there is a single configuration "template" which applies to all > users who authenticate with a certificate from a certain CA, or with a login > matching some pattern. > > In order to store the configuration serial number, on a per-user basis, then > some state is created a per-user basis. This does not sound like a horrible > thing to me, but it is probably something new. Almost always there is some per user data anyways, most commonly the password etc, and/or all kind policy information coming from the AAA server... I do not think people will configure remote users in such way, that anybody with EE cert signed with that CA can log in... Almost always they use EAP or similar and those have per user data. -- kivinen@iki.fi From nobody Wed Sep 2 06:28:48 2020 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 6B7F83A0D46 for ; Wed, 2 Sep 2020 06:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Rj-4nEJd0Fjg for ; Wed, 2 Sep 2020 06:28:46 -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 EA1403A0BF4 for ; Wed, 2 Sep 2020 06:28:45 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BhPsQ1LBkzG30; Wed, 2 Sep 2020 15:28:42 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1599053322; bh=fP+ptz8+P/XanhK+isoWdU6uGfkLSM8bcVjRN7/RGCs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=dve49GT6KNB74pEGth/4wLAcARuA4wy9NJEYLBUDt0N4rpcAp+Hu5W39hHsANkzVP CR9Qmw7VpeQoeP0s1Hcush5S1SGyxXJGlDR9GrJZ9oDzgpzfL9r5+slrRxOxeVs3UI MtsFDS4Mmptc/j64ge6gHIM/tj0wCzX6T3vG+4Ps= 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 ImdIbPO9DJey; Wed, 2 Sep 2020 15:28:41 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 2 Sep 2020 15:28:40 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id AD8D16029BA2; Wed, 2 Sep 2020 09:28:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AC33866A7B; Wed, 2 Sep 2020 09:28:39 -0400 (EDT) Date: Wed, 2 Sep 2020 09:28:39 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: Michael Richardson , "ipsec@ietf.org WG" In-Reply-To: <24398.27138.979226.920386@fireball.acr.fi> Message-ID: References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23589.701449.658566@fireball.acr.fi> <20447.1598895285@localhost> <24398.27138.979226.920386@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 02 Sep 2020 13:28:47 -0000 On Tue, 1 Sep 2020, Tero Kivinen wrote: > If server configuration is changed to require AES-GCM instead of 3DES > then I think all active tickets needs to be invalidated to make sure > they do not work. Easiest way is to change the ticket encrypting key. Yes, this is why we (libreswan) add the conection serial created at (re)load into the ticket. Even reloading the connection without a change will invalidate all the issued tickets. > Global configuration changes are quite rare, and most implementations > I know do not bother checking whether existing IKE SAs match the new > policy or not, but simply delete all IKE SAs and recreates them. for our implementation, global changes only take effect when reloading the connection, so we are covered for this part. >> In order to store the configuration serial number, on a per-user basis, then >> some state is created a per-user basis. This does not sound like a horrible >> thing to me, but it is probably something new. > > Almost always there is some per user data anyways, most commonly the > password etc, and/or all kind policy information coming from the AAA > server... I don't understand why user authentication needs to be "stored". If a user changes a password, their current IKE SA is not invalidated. If a user certificate revoked, the current IKE SA is not invalidated. Those checks are only repeated at re-authentication time, and session ticket lifetime's should only be allowed to upto the re-authentication time before requirting a re-auth. > I do not think people will configure remote users in such way, that > anybody with EE cert signed with that CA can log in... Almost always > they use EAP or similar and those have per user data. I don't think this is relevant, provided session ticket lifetime's have a max of issue time + re-auth time. You might even want to refuse the ticket if it is within 1 rekey time of this maximum to prevent needing a rekey before the normal rekey time. Paul From nobody Wed Sep 2 09:47:37 2020 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 E2B5C3A12C6 for ; Wed, 2 Sep 2020 09:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 l-VIAyFmWO_6 for ; Wed, 2 Sep 2020 09:47:34 -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 D576F3A0E07 for ; Wed, 2 Sep 2020 09:47:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BhVGp5TWxzG3b; Wed, 2 Sep 2020 18:47:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1599065250; bh=1SHOeCh8+qgC9f/+DJ4NelbBEdWp8cL/yqh+mdq84qE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=b+6Qnpl+k58R2/6uBjV9aRyWsafB+jg6N2z0p0YwdgguYhjJbQueuEIyDjM/gY0uh jMDl7dcsE+W2rNfILTS7OD4idDQaTfgfWC2/C3BmAhFw9U2/ZVghmJGMF34zW/rcFj /iB2ikQJPOd8drV9G8lxfIl5ECFvns9ZlfUevCes= 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 5b7cZlNHIncs; Wed, 2 Sep 2020 18:47:29 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 2 Sep 2020 18:47:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 230796020EC4; Wed, 2 Sep 2020 12:47:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1AB5F66A7B; Wed, 2 Sep 2020 12:47:27 -0400 (EDT) Date: Wed, 2 Sep 2020 12:47:27 -0400 (EDT) From: Paul Wouters To: Benjamin Kaduk cc: Tero Kivinen , nupur202000@gmail.com, "ipsec@ietf.org WG" In-Reply-To: <20200831222331.GO16914@kduck.mit.edu> Message-ID: References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23952.909994.886850@fireball.acr.fi> <20200831222331.GO16914@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 02 Sep 2020 16:47:36 -0000 On Mon, 31 Aug 2020, Benjamin Kaduk wrote: >> On Mon, 31 Aug 2020, Tero Kivinen wrote: >> >>> That should not matter, the server should not invalidate tickets even >>> if there is liveness failures, as if it does that every time there is >>> transient network failure the resumption is useless. >> >> I agree, but that is not what the RFC says. Perhaps this would qualify >> for an Errata ? > > I think an Errata Report would be appropriate for this topic. Given that > we are still discussing the details, I suggest to iterate on the OLD/NEW > text on the list before actually submitting the report, though. So here is my first pass: Abstract: Current: A client can reconnect to a gateway from which it was disconnected. New: A client can reconnect to a gateway from which it was disconnected, due to a network issue between the client and server. Section 6.2: Current: Each ticket is associated with a single IKE SA. In particular, when an IKE SA is deleted by the client or the gateway, the client MUST delete its stored ticket. Similarly, when credentials associated with the IKE SA are invalidated (e.g., when a user logs out), the ticket MUST be deleted. New: Each ticket is associated with a single IKE SA. In particular, when an IKE SA is deleted by administrative actions initiated by the client or due to the client receiving a Delete Notification from the gateway, the client MUST delete its stored ticket. Similarly, when credentials associated with the IKE SA are invalidated (e.g., when a user logs out), the ticket MUST be deleted. When the client deletes the IKE SA due to a failed liveness probe, the client MUST NOT send Delete Notifications and SHOULD keep the ticket to allow it to attempt a Session Resumption Exchange when the network outage has cleared. Section 9.8: Current: A misbehaving client could present a ticket in its possession to the gateway resulting in session resumption, even though the IKE SA associated with this ticket had previously been deleted. This is disallowed by Section 6.2. New: A misbehaving client could present a ticket in its possession to the gateway resulting in session resumption, even though the IKE SA associated with this ticket had been terminated by the client or server during regular operations that included processing Delete Notifications. This is disallowed by Section 6.2. Note that during an outage, deletion of the IKE SA that is the result of failed liveness probes MUST NOT invalidate the ticket for resumption, as this behaviour is expected to occur during a network outage. Invalidating the ticket due to a liveness failure would make session resumption impossible. I am confused a bit about 4.3.1: Current: a client MUST NOT reuse a ticket. A reused ticket SHOULD be rejected by a gateway. Why is there a SHOULD and not a MUST NOT ? With the SHOULD I guess I can now ignore it (as we do in our implementation currently). We could clarify here that the timing interactions of ike lifetime, re-auth lifetime and ticket lifetime should prevent it from being used after the user credentials have expired, but I don't think it is really needed in the errata? This one is also a little tricky: Note 3: If the certificate has an iPAddress SubjectAltName, and the implementation requires it to match the peer's source IP address, the same check needs to be performed on session resumption and the required information saved locally or in the ticket. We need to update our implementation to add this ip restriction into the session ticket so we can compare it on resume without having the CERT. Paul From nobody Thu Sep 3 00:49:35 2020 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 DC5B43A0B92 for ; Thu, 3 Sep 2020 00:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vdh1yeLSAXVp for ; Thu, 3 Sep 2020 00:49:32 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 DA7D33A0B8D for ; Thu, 3 Sep 2020 00:49:31 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id w3so2452344ljo.5 for ; Thu, 03 Sep 2020 00:49:31 -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=aDvquwxJbf2ejShYAaHaZNJTPKfJuMbQ0ahYsHmHQgE=; b=Oxao/U7e5uS0kc6m4FzjZcddMBToRxP9KVYQDWSvmfoWRA4ZcIuDdp/jGYLHhMJhP7 tnqSgAfGtc1mJttG1cM6gGN24h/ltTl2LQIBd6o0XPuD4jEGB5pD9053MDmLKpZGgNAu fgsER4jNYGCA344W/V1J5eNthinYtrvfdS8t3fbt4awp05pJ50EMkWitBlqNy5a2oPkd o4BsUeIM7ct4AqTC8QUVA+mrN5svajU6hHEaITXVKlJlY1VdRfBXHRJ6iEzDuI2usvGl g8cr5riPZ6TKWwzx2i7XmVQJKE8FHkkOR0DnhtupdG5Vo9TUjUOkNGBVZwcJpVvvBPIS BAcA== 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=aDvquwxJbf2ejShYAaHaZNJTPKfJuMbQ0ahYsHmHQgE=; b=sXsWdXh32N8pb1TXUKIfrmkhqPAu+qpP3As1VHNdqI/4uc2lQWWfe0OQQs2xlgw+IS VeX3234HNY313CC1yRPCVHcFhJ4TWtvclno3qoM3C9iNLJl+xK1ehSQNhBpknbjl6dqH GTiIWNGHr6jfTDMTuxk9XqzpznwnalyovjUlc84nrK4+TgMTrOEv3ow0a1bx2FBIZ01U EODc0ROgHP3exRkwzyHBCeD6Igmd33Fw6zDN+HqKRiv3dQMEZkp+21YeVeSgehVnjE54 0gDEBEBDBveVuC874JqSRgF1IXOfjwulgEFehfst+hSwTesH9kKzjcPOk0YJuyO7oXmk LE2A== X-Gm-Message-State: AOAM5321rVD41k4ub22APhjOCXiFKEMJkCDINyJ9u1t3dPOaj1lFH4PK WeOt3ybtfPdvzaeGyEHgdeSPm59ZbIk= X-Google-Smtp-Source: ABdhPJxZFCBJMk2mhd9OnsGv9X1jzHydVPTGbdUJaY4A03wiWBJJ64PHMllytgRswEUKfXCGXUqnKA== X-Received: by 2002:a2e:9a01:: with SMTP id o1mr648753lji.32.1599119369584; Thu, 03 Sep 2020 00:49:29 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id z18sm427721lji.107.2020.09.03.00.49.28 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Sep 2020 00:49:28 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Benjamin Kaduk'" Cc: , , "'Tero Kivinen'" References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23952.909994.886850@fireball.acr.fi> <20200831222331.GO16914@kduck.mit.edu> In-Reply-To: Date: Thu, 3 Sep 2020 10:49:31 +0300 Message-ID: <053901d681c6$c29fab40$47df01c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLu9y+F8Hx7VjEs5Up2N5/HjUuRUQIY8v4QAaOOJ2gBL/fVcgHByqFWAnrCpYwBXVCZGAJDyyPeAivsmeoA8GRVmAIlZHTHppU4l6A= Content-Language: ru Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 03 Sep 2020 07:49:34 -0000 Hi Paul, > So here is my first pass: > > Abstract: > > Current: > > A client can reconnect to a gateway from which it was disconnected. > > New: > > A client can reconnect to a gateway from which it was disconnected, > due to a network issue between the client and server. I don't like this change - it's too narrow and only talks about network issue. The disconnection can also be a result switching off power on a CPE, or rebooting the device. > Section 6.2: > > Current: > > Each ticket is associated with a single IKE SA. In particular, when > an IKE SA is deleted by the client or the gateway, the client MUST > delete its stored ticket. Similarly, when credentials associated > with the IKE SA are invalidated (e.g., when a user logs out), the > ticket MUST be deleted. > > New: > > Each ticket is associated with a single IKE SA. In particular, > when an IKE SA is deleted by administrative actions initiated by > the client or due to the client receiving a Delete Notification from > the gateway, the client MUST delete its stored ticket. Similarly, > when credentials associated with the IKE SA are invalidated (e.g., > when a user logs out), the ticket MUST be deleted. > When the client deletes the IKE SA due to a failed liveness probe, the client The following text: > MUST NOT send Delete Notifications and is unnecessary and technically incorrect, because if there is no connectivity (as turned out after liveness probe failed), the client _cannot_ send any message to the server. Please, remove it. > SHOULD keep the ticket to allow > it to attempt a Session Resumption Exchange when the network outage > has cleared. > > Section 9.8: > > Current: > > A misbehaving client could present a ticket in its possession to the > gateway resulting in session resumption, even though the IKE SA > associated with this ticket had previously been deleted. This is > disallowed by Section 6.2. > > New: > > A misbehaving client could present a ticket in its possession to > the gateway resulting in session resumption, even though the IKE > SA associated with this ticket had been terminated by the client > or server during regular operations that included processing Delete > Notifications. This is disallowed by Section 6.2. Note that during an > outage, deletion of the IKE SA that is the result of failed liveness > probes MUST NOT invalidate the ticket for resumption, as this behaviour > is expected to occur during a network outage. Again, the network outage is not the only reason for deleting SAs - switching off power or rebooting the device can also occur. > Invalidating the ticket > due to a liveness failure would make session resumption impossible. I think this clarification is not necessary. > I am confused a bit about 4.3.1: > > Current: > > a client MUST NOT reuse a ticket. A reused ticket SHOULD be rejected by a gateway. > > Why is there a SHOULD and not a MUST NOT ? With the SHOULD I guess I can > now ignore it (as we do in our implementation currently). We could > clarify here that the timing interactions of ike lifetime, re-auth > lifetime and ticket lifetime should prevent it from being used after > the user credentials have expired, but I don't think it is really needed > in the errata? I guess that it's SHOULD, because if it were MUST, a stateless server implementation would not be possible, even with ticket by value. Regards, Valery. > This one is also a little tricky: > > Note 3: If the certificate has an iPAddress SubjectAltName, and the > implementation requires it to match the peer's source IP > address, the same check needs to be performed on session > resumption and the required information saved locally or in > the ticket. > > We need to update our implementation to add this ip restriction into the > session ticket so we can compare it on resume without having the CERT. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Sep 3 07:15:50 2020 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 7933C3A0CD1 for ; Thu, 3 Sep 2020 07:15:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 Yv9O8sS1A-bk for ; Thu, 3 Sep 2020 07:15:47 -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 500163A0CD5 for ; Thu, 3 Sep 2020 07:15:32 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Bj2ry6NKmzG5Y; Thu, 3 Sep 2020 16:15:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1599142530; bh=Shi0V7gAsfTGKyytAzqBRjuCaYB9BKDQXnbgcgbBZDI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=GhkZo1mCNEt0owKuoZtYQPfIIiturwkYNJDZkn/2o6y47A+1c7O6fjwTg3QKp4psP eprexTWTmlvDxxHZgMvEQ5QtlXSc/vbUiAmORflCn+HiV8IXfvS6gQ5Myno0EnVC+m viWBMYwrxfqWxT6UfAJxOT4d0f3n4DluSbspKuOE= 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 0yUDek3dxpD4; Thu, 3 Sep 2020 16:15:29 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 3 Sep 2020 16:15:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 16C046020EC4; Thu, 3 Sep 2020 10:15:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 156FA66A7B; Thu, 3 Sep 2020 10:15:28 -0400 (EDT) Date: Thu, 3 Sep 2020 10:15:28 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: 'Benjamin Kaduk' , ipsec@ietf.org, 'Tero Kivinen' , nupur202000@gmail.com In-Reply-To: <053901d681c6$c29fab40$47df01c0$@gmail.com> Message-ID: References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23952.909994.886850@fireball.acr.fi> <20200831222331.GO16914@kduck.mit.edu> <053901d681c6$c29fab40$47df01c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 03 Sep 2020 14:15:50 -0000 On Thu, 3 Sep 2020, Valery Smyslov wrote: >> Current: >> >> A client can reconnect to a gateway from which it was disconnected. >> >> New: >> >> A client can reconnect to a gateway from which it was disconnected, >> due to a network issue between the client and server. > > I don't like this change - it's too narrow and only talks about network issue. > The disconnection can also be a result switching off power on a CPE, > or rebooting the device. You are right. >> Section 6.2: >> >> Current: >> >> Each ticket is associated with a single IKE SA. In particular, when >> an IKE SA is deleted by the client or the gateway, the client MUST >> delete its stored ticket. Similarly, when credentials associated >> with the IKE SA are invalidated (e.g., when a user logs out), the >> ticket MUST be deleted. >> >> New: >> >> Each ticket is associated with a single IKE SA. In particular, >> when an IKE SA is deleted by administrative actions initiated by >> the client or due to the client receiving a Delete Notification from >> the gateway, the client MUST delete its stored ticket. Similarly, >> when credentials associated with the IKE SA are invalidated (e.g., >> when a user logs out), the ticket MUST be deleted. >> When the client deletes the IKE SA due to a failed liveness probe, the client > > The following text: > >> MUST NOT send Delete Notifications and > > is unnecessary and technically incorrect, because if there is no connectivity > (as turned out after liveness probe failed), the client _cannot_ send any message to the server. > Please, remove it. There are cases where the client thinks it can send them, but it should not. Eg if it connected to a wifi AP that has no more uplink. If it sends the delete, and the connection would briefly allow packet flow, then the server would delete the state and invalidate any tickets. So I think it is important to clarify. And "cannot" is just a subset of "MUST NOT". >> SHOULD keep the ticket to allow >> it to attempt a Session Resumption Exchange when the network outage >> has cleared. >> >> Section 9.8: >> >> Current: >> >> A misbehaving client could present a ticket in its possession to the >> gateway resulting in session resumption, even though the IKE SA >> associated with this ticket had previously been deleted. This is >> disallowed by Section 6.2. >> >> New: >> >> A misbehaving client could present a ticket in its possession to >> the gateway resulting in session resumption, even though the IKE >> SA associated with this ticket had been terminated by the client >> or server during regular operations that included processing Delete >> Notifications. This is disallowed by Section 6.2. Note that during an >> outage, deletion of the IKE SA that is the result of failed liveness >> probes MUST NOT invalidate the ticket for resumption, as this behaviour >> is expected to occur during a network outage. > > Again, the network outage is not the only reason for deleting SAs - > switching off power or rebooting the device can also occur. How about: s/outage/interruption of service/ or: (planned or unplanned) interruption of service s/during a network outage/in some situations, such as a network outage/ >> Invalidating the ticket >> due to a liveness failure would make session resumption impossible. > > I think this clarification is not necessary. I think this discussion on the list shows that it is neccessary? >> I am confused a bit about 4.3.1: >> >> Current: >> >> a client MUST NOT reuse a ticket. A reused ticket SHOULD be rejected by a gateway. >> >> Why is there a SHOULD and not a MUST NOT ? With the SHOULD I guess I can >> now ignore it (as we do in our implementation currently). We could >> clarify here that the timing interactions of ike lifetime, re-auth >> lifetime and ticket lifetime should prevent it from being used after >> the user credentials have expired, but I don't think it is really needed >> in the errata? > > I guess that it's SHOULD, because if it were MUST, a stateless server implementation > would not be possible, even with ticket by value. But that is a cop out. It should have explained in which cases it should not be rejected. If this section had clarified the liveness probe failure case, we would not be having any of this discussion and everyone would have implemented it properly :) Paul From nobody Thu Sep 3 13:22:45 2020 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 0DE0E3A0F28 for ; Thu, 3 Sep 2020 13:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1KaMoTwN6lA for ; Thu, 3 Sep 2020 13:22:42 -0700 (PDT) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 657763A0E59 for ; Thu, 3 Sep 2020 13:22:42 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id a17so4548094wrn.6 for ; Thu, 03 Sep 2020 13:22:42 -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:content-language :thread-index; bh=sccsWFW0SzRWInMH2Yrk9LI4Dr0c5linclMCL7GaOXs=; b=ht6kIn5lj/eNxEQvwMe2RiJsu0J6j8s9NJQXYVATg6+FZHhoslmN580kslHYkrkWFv xQPkSHfnAq2zk6ayKA/qwNOHVsd/WVkK7Wnb6SJ/zOLUCdLcibtGivBIafBqdfgBmglY z3OBl+tbfimyqGnE4ovuJs63bpEN/tG/NQFvOnOIgx3o4gFaZfwusB9kXrr2ms69tk3W fg3iPa7Wb3sDKXpjlRqRGgv2pErGR667MY+QLnEQ3dBWkHtZqLYUfeqYniCP20lgXwwk ECtI0Cc5vHMnzPIBHwMBwTOXaiH+Viuhx7nYAd+MFfM3cqcwAppssgvtgtyCLRPvKcDp RLFw== 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:content-language :thread-index; bh=sccsWFW0SzRWInMH2Yrk9LI4Dr0c5linclMCL7GaOXs=; b=oVsNZIQTfu+K7gyEI2EIPxBVeNtgyqKhmneLkMW5XpZnaXp+B9e5uBqrFTVlBFVqkj AyhDdrzLsRnBQ3v9JB3yEsTbbBLASPv3BLeqn0CJCbvOSr9sDtwq5LLRaFrkXBw9kpp8 e+qJmJfeAxInzgaI6YfpjVlTr7+emvtTtO6xMbVVgb6+dEhA0+DgRmwEpNPfekT4S999 JYKm1vkR3HXreMSfnzsaNj64uBBxAeZS7Q5Ib7lM+vdkuxcdFGrDaEtRztW8zqP8PLsr TbPGmg04cZZG4IbATf6HoRVyZvDV6XYydXoK4KxIcdm12OU0JqXG6Iy2NmeYx3gxeG4y zLkg== X-Gm-Message-State: AOAM533O+Tbz1eg2XvCTZDfN+k35DriEcvvLdM3SNOWt7iEegMT4UPG8 XyWZ4AAAPeyi79aVh0F73zNrZmjlD6I= X-Google-Smtp-Source: ABdhPJx6zxMUbmUboCnqiTc9SS+uyJ2jBGMpko8A0ENgP0A32SEFWetbAayeaEKdimuRlwa5asfKwA== X-Received: by 2002:a5d:6291:: with SMTP id k17mr4170566wru.130.1599164560456; Thu, 03 Sep 2020 13:22:40 -0700 (PDT) Received: from chichi (37-144-56-120.broadband.corbina.ru. [37.144.56.120]) by smtp.gmail.com with ESMTPSA id d6sm6237407wrq.67.2020.09.03.13.22.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Sep 2020 13:22:39 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'Benjamin Kaduk'" , , "'Tero Kivinen'" , References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23952.909994.886850@fireball.acr.fi> <20200831222331.GO16914@kduck.mit.edu> <053901d681c6$c29fab40$47df01c0$@gmail.com> In-Reply-To: Date: Thu, 3 Sep 2020 23:22:35 +0300 Message-ID: <019501d6822f$f66c8830$e3459890$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: ru Thread-Index: AQLu9y+F8Hx7VjEs5Up2N5/HjUuRUQIY8v4QAaOOJ2gBL/fVcgHByqFWAnrCpYwBXVCZGAJDyyPeAivsmeoA8GRVmAIlZHTHApqsu4IBhr/+qaZ0/21Q Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 03 Sep 2020 20:22:44 -0000 Hi Paul, > >> Section 6.2: > >> > >> Current: > >> > >> Each ticket is associated with a single IKE SA. In particular, when > >> an IKE SA is deleted by the client or the gateway, the client MUST > >> delete its stored ticket. Similarly, when credentials associated > >> with the IKE SA are invalidated (e.g., when a user logs out), the > >> ticket MUST be deleted. > >> > >> New: > >> > >> Each ticket is associated with a single IKE SA. In particular, > >> when an IKE SA is deleted by administrative actions initiated by > >> the client or due to the client receiving a Delete Notification from > >> the gateway, the client MUST delete its stored ticket. Similarly, > >> when credentials associated with the IKE SA are invalidated (e.g., > >> when a user logs out), the ticket MUST be deleted. > >> When the client deletes the IKE SA due to a failed liveness probe, the > client > > > > The following text: > > > >> MUST NOT send Delete Notifications and > > > > is unnecessary and technically incorrect, because if there is no > connectivity > > (as turned out after liveness probe failed), the client _cannot_ send any > message to the server. > > Please, remove it. > > There are cases where the client thinks it can send them, but it should > not. Eg if it connected to a wifi AP that has no more uplink. If it > sends the delete, and the connection would briefly allow packet flow, > then the server would delete the state and invalidate any tickets. So > I think it is important to clarify. And "cannot" is just a subset of > "MUST NOT". I fail to understand this. RFC7296 is very clear, that if exchange is timed out, IKE SA is silently deleted (Section 2.1): IKE is a reliable protocol: the initiator MUST retransmit a request until it either receives a corresponding response or deems the IKE SA to have failed. In the latter case, the initiator discards all state associated with the IKE SA and any Child SAs that were negotiated using that IKE SA. Note, that RFC7296 doesn't say that you may/should/must send a Delete payload in this case, it says that IKE SA state is discarded. You cannot send DELETE notification over discarded SA. And I disagree that "cannot" is just a subset of "MUST NOT". "MUST NOT" means that you are able to do this, but it is forbidden. You don't say: "you MUST NOT use TCP/UDP port number greater than 65535" or "you MUST NOT exceed speed of light". > >> SHOULD keep the ticket to allow > >> it to attempt a Session Resumption Exchange when the network > outage > >> has cleared. > >> > >> Section 9.8: > >> > >> Current: > >> > >> A misbehaving client could present a ticket in its possession to the > >> gateway resulting in session resumption, even though the IKE SA > >> associated with this ticket had previously been deleted. This is > >> disallowed by Section 6.2. > >> > >> New: > >> > >> A misbehaving client could present a ticket in its possession to > >> the gateway resulting in session resumption, even though the IKE > >> SA associated with this ticket had been terminated by the client > >> or server during regular operations that included processing Delete > >> Notifications. This is disallowed by Section 6.2. Note that during an > >> outage, deletion of the IKE SA that is the result of failed liveness > >> probes MUST NOT invalidate the ticket for resumption, as this > behaviour > >> is expected to occur during a network outage. > > > > Again, the network outage is not the only reason for deleting SAs - > > switching off power or rebooting the device can also occur. > > How about: > > s/outage/interruption of service/ or: (planned or unplanned) > interruption of service > s/during a network outage/in some situations, such as a network outage/ Works for me. > >> Invalidating the ticket > >> due to a liveness failure would make session resumption impossible. > > > > I think this clarification is not necessary. > > I think this discussion on the list shows that it is neccessary? No, it is not necessary. You put all the requirements not to invalidate ticket in this case in the preceding text. This sentence adds no additional requirements, it just explains why these requirements are imposed. You may leave it, but I don't think it's necessary... Regards, Valery. > >> I am confused a bit about 4.3.1: > >> > >> Current: > >> > >> a client MUST NOT reuse a ticket. A reused ticket SHOULD be rejected > by a gateway. > >> > >> Why is there a SHOULD and not a MUST NOT ? With the SHOULD I guess I > can > >> now ignore it (as we do in our implementation currently). We could > >> clarify here that the timing interactions of ike lifetime, re-auth > >> lifetime and ticket lifetime should prevent it from being used after > >> the user credentials have expired, but I don't think it is really needed > >> in the errata? > > > > I guess that it's SHOULD, because if it were MUST, a stateless server > implementation > > would not be possible, even with ticket by value. > > But that is a cop out. It should have explained in which cases it should > not be rejected. If this section had clarified the liveness probe > failure case, we would not be having any of this discussion and everyone > would have implemented it properly :) > > Paul From nobody Thu Sep 3 17:03:11 2020 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 5BEF63A13D8 for ; Thu, 3 Sep 2020 17:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.948, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 OXr1hmxd39AZ for ; Thu, 3 Sep 2020 17:03:08 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 4ABEE3A13D6 for ; Thu, 3 Sep 2020 17:03:07 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id B15C41B00045; Fri, 4 Sep 2020 03:03:04 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1599177784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4qgkHL5pXrv7jL0ZmVwx/eI1pSf5bXHfOZ23+SnWr7E=; b=dI3QIW95b1XGALZVk8dP4Fhdh0W2rW1VSPMwISOhK4x3B5AKur3zyzswS7QE4HOB4ntAwd 0m0RD/Xthvt5wVj5Py4c4qaeaMKM3A2FNKDKdaAQAw6ERHYnaw+zorqmom5s4B8PhrBYop AomaDbC1mlBN9z8XZx/S3vMORVMNpARZpGSbRhbeVK+3HTtoiSTfakKiHcep+f4O2flwWE bUsQYdkmA3b/IDTVRqVkZ9pfxHGsw1OB7oHU1yFqwLVKJrGBPa0yA0V0mNLYbKFqXaDLTf QuAB0bZ/O3PRMZCxZMS7rTzbidYDqIJqSQ35cvOP/BLeQYKH1WL1lZygUOjNCA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 5444125C0F86; Fri, 4 Sep 2020 03:03:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24401.33848.293979.377520@fireball.acr.fi> Date: Fri, 4 Sep 2020 03:03:04 +0300 From: Tero Kivinen To: Paul Wouters Cc: Valery Smyslov , ipsec@ietf.org, nupur202000@gmail.com, 'Benjamin Kaduk' In-Reply-To: References: <9856.1598554487@localhost> <29645.1598647338@localhost> <24396.23952.909994.886850@fireball.acr.fi> <20200831222331.GO16914@kduck.mit.edu> <053901d681c6$c29fab40$47df01c0$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1599177784; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4qgkHL5pXrv7jL0ZmVwx/eI1pSf5bXHfOZ23+SnWr7E=; b=nsrajyfB6JEZw9Bu2Gvu477uRK6qOXkifgSBxl27uXEAVhlS5xZaaM2t4gBAI4kD7ElwXO E509NbXUcRKHXeChooQJnp6U4yM0AEiciBwwVG+0XTk1haBEYGH2q0F62pCXPqoTQdYTPs dy/KDorARh8cYCHO+qIjlxYdwUc83m7uXIalF8dUO6Y+S8gz4mDom9iG67SAekvt5jURG1 j0CtCuHWwIA6k+1t4v7o+P2U3A8wi+BKtpNSbQYWzp+owAF5PGb4lcrJ98bvWHEO92gfe2 chHdYATkWlnn4C3kvqt0eFqgS/QPcoVai27erc43EtyiTZ5l85jgFEs0IWr/fA== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1599177784; a=rsa-sha256; cv=none; b=Wk9Z8Tioz7s4lF7DoflcicqU2bAb8H/9Y92lKEz800h7OkXQQICjFaQul/aQjPQEw2EUgE 26XJWxv9gCxRWWOKt2yo4RdVn1mYJ8WMrcT190inPbSEYOI16DOEdf/goIFylp/5ONGIf5 OADp33KtqeX94yjikgBRlyPd7So4HjxOMRoYFIUZRhIe89Si9mZDdshfWOfss36zpVVWbO fBYF+ipCzJaj0bdg1pfrMpjW0iKdxBVBliBfj6aDIfSlW4nhJvDpUKmiQYxYVLSdSlCh7Q tN4UmfGu4MQXaeZezKmuNUB3mGUQMHeRvkKGw1imf0nqisARauH+nmdMt9cPEw== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Question on RFC 5723 Session Resumption 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, 04 Sep 2020 00:03:10 -0000 By first look the changes seemed way too big for errata, but it seems they are getting narrowed down to something that could be actually done by errata. If we want to do something bigger we can of course do 5723bis and do other things at the same time if needed. Paul Wouters writes: > > The following text: > > > >> MUST NOT send Delete Notifications and > > > > is unnecessary and technically incorrect, because if there is no connectivity > > (as turned out after liveness probe failed), the client _cannot_ > > send any message to the server. > > Please, remove it. > > There are cases where the client thinks it can send them, but it should > not. Eg if it connected to a wifi AP that has no more uplink. If it > sends the delete, and the connection would briefly allow packet flow, > then the server would delete the state and invalidate any tickets. So > I think it is important to clarify. And "cannot" is just a subset of > "MUST NOT". This of course would require you to implement and use the window size larger than one. If you use the default size of one, your one slot is already in use by the liveness check, and you can't send the next message until that is finished, and it will not be finished as network is broken... If your implementation actually uses window size larger than one, then it could waste its resources and send the delete using next message id, but I do not see any point in that. Why would any implementation do that? If they are tearing down the connection because other end is dead, why do the want to send message telling the other end the connection is now dead, if it does not reach it. Yes, you could have one way connection, where the other end can actually receive messages but you do not receive replies, but I do not think there is point of implementing feature for just such networks. -- kivinen@iki.fi From nobody Thu Sep 10 00:32:31 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4703A0F9E; Thu, 10 Sep 2020 00:32:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.16.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <159972314733.21449.12883222792400646372@ietfa.amsl.com> Date: Thu, 10 Sep 2020 00:32:27 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 07:32:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : Intermediate Exchange in the IKEv2 Protocol Author : Valery Smyslov Filename : draft-ietf-ipsecme-ikev2-intermediate-05.txt Pages : 11 Date : 2020-09-10 Abstract: This documents defines a new exchange, called Intermediate Exchange, for the Internet Key Exchange protocol Version 2 (IKEv2). This exchange can be used for transferring large amount of data in the process of IKEv2 Security Association (SA) establishment. Introducing Intermediate Exchange allows re-using existing IKE fragmentation mechanism, that helps to avoid IP fragmentation of large IKE messages, but cannot be used in the initial IKEv2 exchange. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-05 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 10 00:33:41 2020 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 A39863A1202; Thu, 10 Sep 2020 00:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 a1tDPYcy3v17; Thu, 10 Sep 2020 00:33:32 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7DB3A11E7; Thu, 10 Sep 2020 00:33:25 -0700 (PDT) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 4Bn9bm4WQlz30lZ; Thu, 10 Sep 2020 09:33:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1599723204; bh=yKyQr7rW3c/ej0/XxWSGB3joYijiDFGd+OqUf33imbM=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=kjgKw2XUjLJfm3wur4XYvqS+9bJqeBxKiLbjsPQns1OiayuZzOK9vgzuRbFypt9Is 7ArjVSvdYuAQrp2fnMVwxEhjGCdDEQYNNjRwjx0JWp5dDZxrwbW53KOemDBw3rCK2s I0HrxT1R0hY8DFKqrba0yEdSgrxDiV4bv0N8sCB8njJdFR55kd/dCS2ZnwQDsF7BSA hpzwb7DPoFqm3y0CtX8NHCIhSb23md3iMGBfdyk+RzWjEJwbjDpuvEDReZCIweLyi7 4yVMj8OTMBLUui87Lpg8Gtn/L59FbWyoaElQMd1DwTCdP6lb/mByIE9suQAIpJ6Vim FMXYBNqqmkoWw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.73]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4Bn9bm3ZL0z5vPn; Thu, 10 Sep 2020 09:33:24 +0200 (CEST) From: To: "ipsec@ietf.org" CC: "draft-btw-add-ipsecme-ike@ietf.org" Thread-Topic: New Version Notification for draft-btw-add-ipsecme-ike-01.txt Thread-Index: AQHWhqEic1WOV2DGt0Gr5Z8wSgvWfKlhdVZw Date: Thu, 10 Sep 2020 07:33:23 +0000 Message-ID: <24155_1599723204_5F59D6C4_24155_339_53_787AE7BB302AE849A7480A190F8B93303153E1B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159965296544.28196.15433560776696094354@ietfa.amsl.com> In-Reply-To: <159965296544.28196.15433560776696094354@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 07:33:40 -0000 SGkgYWxsLA0KDQpXZSB1cGRhdGVkIHRoZSBkcmFmdCB0byB0YWtlIGludG8gYWNjb3VudCB0aGUg Y29tbWVudHMgcmFpc2VkIGR1cmluZyB0aGUgbGFzdCBJRVRGIG1lZXRpbmcuIEluc3RlYWQgb2Yg bXVsdGlwbGV4aW5nIHRoZSBhdHRyaWJ1dGVzLCB3ZSBzaW1wbGlmaWVkIHRoZSBkZXNpZ24gc28g dGhhdCB0eXBlcyBhcmUgYXNzaWduZWQgdG8gZWFjaCBlbmNyeXB0ZWQgRE5TIHR5cGUgKERvVCwg RG9ILCBEb1EpLg0KDQpQbGVhc2UgcmV2aWV3IGFuZCBzaGFyZSB5b3VyIGNvbW1lbnRzLiANCg0K VGhhbmsgeW91LiANCg0KQ2hlZXJzLA0KTWVkDQoNCi0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KRGXCoDogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnXSANCkVudm95w6nCoDogbWVyY3JlZGkgOSBzZXB0ZW1icmUgMjAyMCAxNDowMw0K w4DCoDogRGFuIFdpbmcgPGR3aW5nLWlldGZAZnVnZ2xlcy5jb20+OyBWYWxlcnkgU215c2xvdiA8 c3ZhbkBlbHZpcy5ydT47IEJPVUNBREFJUiBNb2hhbWVkIFRHSS9PTE4gPG1vaGFtZWQuYm91Y2Fk YWlyQG9yYW5nZS5jb20+OyBUaXJ1bWFsZXN3YXIgUmVkZHkuSyA8dGlydW1hbGVzd2FycmVkZHlf a29uZGFAbWNhZmVlLmNvbT47IFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlf S29uZGFATWNBZmVlLmNvbT4NCk9iamV0wqA6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3Ig ZHJhZnQtYnR3LWFkZC1pcHNlY21lLWlrZS0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtYnR3LWFkZC1pcHNlY21lLWlrZS0wMS50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5 IHN1Ym1pdHRlZCBieSBNb2hhbWVkIEJvdWNhZGFpciBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJl cG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1idHctYWRkLWlwc2VjbWUtaWtlDQpSZXZpc2lvbjoJ MDENClRpdGxlOgkJSW50ZXJuZXQgS2V5IEV4Y2hhbmdlIFByb3RvY29sIFZlcnNpb24gMiAoSUtF djIpIENvbmZpZ3VyYXRpb24gZm9yIEVuY3J5cHRlZCBETlMNCkRvY3VtZW50IGRhdGU6CTIwMjAt MDktMDkNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTExDQpVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYnR3LWFkZC1pcHNlY21lLWlr ZS0wMS50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1idHctYWRkLWlwc2VjbWUtaWtlLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYnR3LWFkZC1pcHNlY21lLWlrZQ0KSHRt bGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1idHctYWRkLWlw c2VjbWUtaWtlLTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlm Zj91cmwyPWRyYWZ0LWJ0dy1hZGQtaXBzZWNtZS1pa2UtMDENCg0KQWJzdHJhY3Q6DQogICBUaGlz IGRvY3VtZW50IHNwZWNpZmllcyBhIG5ldyBJbnRlcm5ldCBLZXkgRXhjaGFuZ2UgUHJvdG9jb2wg VmVyc2lvbg0KICAgMiAoSUtFdjIpIENvbmZpZ3VyYXRpb24gUGF5bG9hZCBBdHRyaWJ1dGUgVHlw ZXMgZm9yIGVuY3J5cHRlZCBETlMNCiAgIHdpdGggYSBmb2N1cyBvbiBETlMtb3Zlci1IVFRQUyAo RG9IKSwgRE5TLW92ZXItVExTIChEb1QpLCBhbmQgRE5TLQ0KICAgb3Zlci1RVUlDIChEb1EpLg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMg Y29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIK YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBh IGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4K Cg== From nobody Thu Sep 10 00:40:22 2020 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 A04463A0FE8 for ; Thu, 10 Sep 2020 00:40:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuoHBG-3XoIC for ; Thu, 10 Sep 2020 00:40:20 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 073333A0FE4 for ; Thu, 10 Sep 2020 00:40:20 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id u21so6888616ljl.6 for ; Thu, 10 Sep 2020 00:40:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=4nCTHRxQlp53idKAXSBlVyeXCuFkePANrmyJqsc5Cxk=; b=gTsNS8T40Z5vR1z4vebi4CUf5eb50b7CoucUHqwnDNw7NFqVZpE+CY969d5NYPg41u 63BWO1Lp8HFLp1ItsgCbvRJA9cP73914JfTD/C4CfB4VTWJ3TdXbcLQG7dZ2ojf5MHae U/EoHTFMRE7/Pm6OEFsW0LVbb4K500XahU0iFfgG59TRQlPmz/ya4NTR9HY6LIp3C5s7 +lC77n4e8zD10H5XKEjViePtFsYjvGl1hKA1ewiCGwFB5U7nM3OF9wehawDgQm9YbDiG S4lqCcXQdVF/mXnCTc6cuJ2DC0VG+uMrfMN3DdBhaYZ5v5kkN4QGDcrYEkONVoA3jMPs C03Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=4nCTHRxQlp53idKAXSBlVyeXCuFkePANrmyJqsc5Cxk=; b=F5zU9h/u4ajxAj/DOz0xj8YeV7/VCbBbRvv0iLJRooJhWuaOpx6y+RNv5VG4U/lYvE mgvE/Cu+IchKbVN9x3vIUgxrLA++eLI5ESoWa5bwY0jj3Yso3KrUCDOcvnd5JtAMeSF/ MXiyHDAKyzZ232JXIn1wwumz60VsnJrvj+xT5xBZaKLx/QqR3cF+6CXT2HZSmiaVBImw IJuu0a4yNZXOUIA4q5z8sZ6a6nRw28la67rzHPq6jnL6OjwPbcIIltjD5vtlaa9f+f8Y P8bXO2tDJlbtjGdw/Rq8hjVwgr+BOFkyKZgspVLhcWiy2QKSmHcdq9CCToEKZflDnf6B btrQ== X-Gm-Message-State: AOAM532NPNYNcqNePM1YGWm7v8p0fySzoJGclB7pRpypUhKIX1rosqKv ol11KXuC+BEqqg8v9gFd6QIpJbe7+y0= X-Google-Smtp-Source: ABdhPJwpvd5YMQlhLyt8r1u7fl+MqWXjDylo8CMsSKIgkaJBti+Fn3upwaOHAxzCxU09RJpWRYAD/w== X-Received: by 2002:a2e:1311:: with SMTP id 17mr3825819ljt.397.1599723617927; Thu, 10 Sep 2020 00:40:17 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id u17sm1148922lfi.2.2020.09.10.00.40.17 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Sep 2020 00:40:17 -0700 (PDT) From: "Valery Smyslov" To: References: <159972314733.21449.12883222792400646372@ietfa.amsl.com> In-Reply-To: <159972314733.21449.12883222792400646372@ietfa.amsl.com> Date: Thu, 10 Sep 2020 10:40:12 +0300 Message-ID: <016901d68745$9e00bcf0$da0236d0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQISqrk+K5eQskfJtegFWagxvoeC/6jpNArg Content-Language: ru Archived-At: Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-ikev2-intermediate-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 07:40:22 -0000 Hi, I've posted a new version of draft-ietf-ipsecme-ikev2-intermediate. It includes text improvements, partially resulted from off-list discussion with Paul Wouters. In addition, a short Implementation Status section is added. The draft is stable for over a year and there are at least three independent interoperable implementations of it. I think the draft is ready for Last Call. Regards, Valery. > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. > > Title : Intermediate Exchange in the IKEv2 Protocol > Author : Valery Smyslov > Filename : draft-ietf-ipsecme-ikev2-intermediate-05.txt > Pages : 11 > Date : 2020-09-10 > > Abstract: > This documents defines a new exchange, called Intermediate Exchange, > for the Internet Key Exchange protocol Version 2 (IKEv2). This > exchange can be used for transferring large amount of data in the > process of IKEv2 Security Association (SA) establishment. > Introducing Intermediate Exchange allows re-using existing IKE > fragmentation mechanism, that helps to avoid IP fragmentation of > large IKE messages, but cannot be used in the initial IKEv2 exchange. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-intermediate/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-intermediate-05 > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-intermediate-05 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ikev2-intermediate-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Sep 10 07:36:46 2020 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 AA03B3A0B91; Thu, 10 Sep 2020 07:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 qcgHs-XOv4AP; Thu, 10 Sep 2020 07:36:42 -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 6D2E43A0B90; Thu, 10 Sep 2020 07:36:42 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BnM085kMrzF1G; Thu, 10 Sep 2020 16:36:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1599748600; bh=0KeTUfUQSFcQG5Ns4OdK05Pt5LROs62ixoSUbd9Vf5Y=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=P7hye8pwg6aSUxrKh+CHjx4DPimn9S44/RxlbD/ORKcXOIwmijTlqKiozeyqIJpyd 7PGN6AJE9zatJqRiTzC30lKLn+rYn0YxXV8joCPhh5hmehSQjDSHCTwM5l//2gODW4 eooP70tI39hdXlpeE1crhpvl9q+985dSjORVzWvg= 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 hb-1EkXIJB10; Thu, 10 Sep 2020 16:36:38 +0200 (CEST) Received: from bofh.nohats.ca (unknown [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 10 Sep 2020 16:36:38 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 343216020F63; Thu, 10 Sep 2020 10:36:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 32E22669F1; Thu, 10 Sep 2020 10:36:36 -0400 (EDT) Date: Thu, 10 Sep 2020 10:36:36 -0400 (EDT) From: Paul Wouters To: mohamed.boucadair@orange.com cc: "ipsec@ietf.org" , "draft-btw-add-ipsecme-ike@ietf.org" In-Reply-To: <24155_1599723204_5F59D6C4_24155_339_53_787AE7BB302AE849A7480A190F8B93303153E1B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Message-ID: References: <159965296544.28196.15433560776696094354@ietfa.amsl.com> <24155_1599723204_5F59D6C4_24155_339_53_787AE7BB302AE849A7480A190F8B93303153E1B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2020 14:36:45 -0000 On Thu, 10 Sep 2020, mohamed.boucadair@orange.com wrote: > We updated the draft to take into account the comments raised during the last IETF meeting. Instead of multiplexing the attributes, we simplified the design so that types are assigned to each encrypted DNS type (DoT, DoH, DoQ). Why is this using a seperate CP payload type per encrypted DNS type? This means that for a DNS server supporting DoT, DoH and DoQ, it needs to send 3 separate payloads. Why not send 1 CP payload that contains a bitmask specifying which services it supports? The only reason I can think of for this choice is because these might be running on non-standard ports, but I think that reason is rather weak. DoT and DoQ will run on standard defines ports and DoH's protocol aims at blending in as web traffic so it really is only getting deployed on port 443. So if I build a single server that can do unencrypted and all encrypted flavours, I'd prefer to send and receive just 1 CP payload covering everything. We _could_ leave the port there for non-standard ports, but then we should add a specific port attribute for each bitmask entry. But honestly, the whole non-default port part seems like overengineering. For those who care a lot about minimizing bytes exchanged over IKE, my above proposal would save a lot of bytes. I would also like to see more clarification about split-DNS and how a list of domains is conveyed via IKE as the only domains to be resolved via the given encrypted DNS servers. I would like to see something in the Security Considerations about handing out well known non-VPN reachable encrypted DNS servers. Eg I'd like to avoid that this document can instruct VPN users to use DoT at 8.8.8.8 if it is not going to offer a VPN that covers 8.8.8.8. If we don't do this, then VPN profiles might end up abusing/redirecting users without offering any actual VPN service - like overriding the system or application specific configuration without offering actual VPN servers to the user. I'm also considered about possive abuse by the specification of the authentication domain name. Eg a VPN provider setting up a tunnel covering 1.1.1.1 (dns.cloudflare.com) with an authentication name of "dns.google.com" and basically redirecting all 1.1.1.1 traffic over the VPN to 8.8.8.8. Paul > Please review and share your comments. > > Thank you. > > Cheers, > Med > > -----Message d'origine----- > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Envoyé : mercredi 9 septembre 2020 14:03 > À : Dan Wing ; Valery Smyslov ; BOUCADAIR Mohamed TGI/OLN ; Tirumaleswar Reddy.K ; Tirumaleswar Reddy > Objet : New Version Notification for draft-btw-add-ipsecme-ike-01.txt > > > A new version of I-D, draft-btw-add-ipsecme-ike-01.txt has been successfully submitted by Mohamed Boucadair and posted to the IETF repository. > > Name: draft-btw-add-ipsecme-ike > Revision: 01 > Title: Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS > Document date: 2020-09-09 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/id/draft-btw-add-ipsecme-ike-01.txt > Status: https://datatracker.ietf.org/doc/draft-btw-add-ipsecme-ike/ > Htmlized: https://datatracker.ietf.org/doc/html/draft-btw-add-ipsecme-ike > Htmlized: https://tools.ietf.org/html/draft-btw-add-ipsecme-ike-01 > Diff: https://www.ietf.org/rfcdiff?url2=draft-btw-add-ipsecme-ike-01 > > Abstract: > This document specifies a new Internet Key Exchange Protocol Version > 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS > with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- > over-QUIC (DoQ). > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Sep 11 00:14:13 2020 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 4B3B43A092E; Fri, 11 Sep 2020 00:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 8U6r7tEwpNnR; Fri, 11 Sep 2020 00:14:09 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B29A3A090D; Fri, 11 Sep 2020 00:14:09 -0700 (PDT) Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4Bnn735hsmz8tc9; Fri, 11 Sep 2020 09:14:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1599808447; bh=YSWgWwUzDTlx0TyPPZNs56jbx+HCT6P7oF8yt+y40ew=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=t6lzJSDOPTelG8POlti3snt/e0rV/E7W3weC7LiOcSnr8wkAfsu6u4dOSgqvcW/OL YGDQbE9Cjf/O92+OtUXGEJ7UAkrti/dsQIoixadxKjUFaZm02/h8i4MPCVj2Alhok/ zssKz3y6w7cgcHfoxnT6oBgpDmkPOGMNV0oYwLg65v4Mm3RIceZRHeoKNYxBMMupR8 6OYopkf6IeD/NlQhJPwaJJX+6PJCR6LO4QeTxFh2jsN9d7xARqzDX7yoUk6Mg/3XT/ ltxDNo5qesW+VBwBoET9FZosiQYI3N9yLSUshMH2xDpifEa/eWAZ7c78ZGq25gB8ge jLe9Y/t+qbqeg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 4Bnn734jQJz2xCK; Fri, 11 Sep 2020 09:14:07 +0200 (CEST) From: To: Paul Wouters CC: "ipsec@ietf.org" , "draft-btw-add-ipsecme-ike@ietf.org" Thread-Topic: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-01.txt Thread-Index: AQHWhqEic1WOV2DGt0Gr5Z8wSgvWfKlh8lh6gAD3cfA= Date: Fri, 11 Sep 2020 07:14:07 +0000 Message-ID: <24324_1599808447_5F5B23BF_24324_2_1_787AE7BB302AE849A7480A190F8B93303153EE6B@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <159965296544.28196.15433560776696094354@ietfa.amsl.com> <24155_1599723204_5F59D6C4_24155_339_53_787AE7BB302AE849A7480A190F8B93303153E1B7@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.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-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: Fri, 11 Sep 2020 07:14:11 -0000 SGkgUGF1bCwNCg0KVGhhbmsgeW91IGZvciB0aGUgY29tbWVudHMuIA0KDQpQbGVhc2Ugc2VlIGlu bGluZS4gDQoNCkNoZWVycywNCk1lZA0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0K PiBEZcKgOiBQYXVsIFdvdXRlcnMgW21haWx0bzpwYXVsQG5vaGF0cy5jYV0NCj4gRW52b3nDqcKg OiBqZXVkaSAxMCBzZXB0ZW1icmUgMjAyMCAxNjozNw0KPiDDgMKgOiBCT1VDQURBSVIgTW9oYW1l ZCBUR0kvT0xOIDxtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPg0KPiBDY8KgOiBpcHNlY0Bp ZXRmLm9yZzsgZHJhZnQtYnR3LWFkZC1pcHNlY21lLWlrZUBpZXRmLm9yZw0KPiBPYmpldMKgOiBS ZTogW0lQc2VjXSBUUjogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1idHctYWRk LQ0KPiBpcHNlY21lLWlrZS0wMS50eHQNCj4gDQo+IE9uIFRodSwgMTAgU2VwIDIwMjAsIG1vaGFt ZWQuYm91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+IA0KPiA+IFdlIHVwZGF0ZWQgdGhlIGRy YWZ0IHRvIHRha2UgaW50byBhY2NvdW50IHRoZSBjb21tZW50cyByYWlzZWQNCj4gZHVyaW5nIHRo ZSBsYXN0IElFVEYgbWVldGluZy4gSW5zdGVhZCBvZiBtdWx0aXBsZXhpbmcgdGhlDQo+IGF0dHJp YnV0ZXMsIHdlIHNpbXBsaWZpZWQgdGhlIGRlc2lnbiBzbyB0aGF0IHR5cGVzIGFyZSBhc3NpZ25l ZCB0bw0KPiBlYWNoIGVuY3J5cHRlZCBETlMgdHlwZSAoRG9ULCBEb0gsIERvUSkuDQo+IA0KPiBX aHkgaXMgdGhpcyB1c2luZyBhIHNlcGVyYXRlIENQIHBheWxvYWQgdHlwZSBwZXIgZW5jcnlwdGVk IEROUyB0eXBlPw0KPiBUaGlzIG1lYW5zIHRoYXQgZm9yIGEgRE5TIHNlcnZlciBzdXBwb3J0aW5n IERvVCwgRG9IIGFuZCBEb1EsIGl0DQo+IG5lZWRzIHRvIHNlbmQgMyBzZXBhcmF0ZSBwYXlsb2Fk cy4gV2h5IG5vdCBzZW5kIDEgQ1AgcGF5bG9hZCB0aGF0DQo+IGNvbnRhaW5zIGEgYml0bWFzayBz cGVjaWZ5aW5nIHdoaWNoIHNlcnZpY2VzIGl0IHN1cHBvcnRzPw0KDQpbTWVkXSBXZSB1c2VkIHRv IGhhdmUgb25lIHNpbmdsZSBhdHRyaWJ1dGUgdGhhdCBpcyB1c2VkIGZvciBhbGwgdHlwZXMgKHdp dGggYSBiaXRtYXNrKS4gV2UgY2hhbmdlZCB0aGUgZGVzaWduIGFzIHdlIHRob3VnaHQgdGhpcyB3 aWxsIHNpbXBsaWZ5IHRoZSBwcm9jZXNzaW5nIG9mIHRoZSBhdHRyaWJ1dGVzIGFuZCBhbGxvdyBm b3IgbW9yZSBmbGV4aWJpbGl0eS4gDQoNClRoaXMgaXMgYWxzbyB0byBlY2hvIHRoaXMgY29tbWVu dCBmcm9tIFRlcm8gKGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzEwOC9taW51dGVz L21pbnV0ZXMtMTA4LWlwc2VjbWUtMDEucGRmKToNCg0KIlRlcm86IEFkZCBjb25maWd1cmF0aW9u IGF0dHJpYnV0ZXMsIGxlc3MgaW50ZXJuYWwgc3RydWN1dHJlLCBtb3JlIGhpZ2hlciBsZXZlbCBz dHJ1Y3R1cmUiDQoNCj4gDQo+IFRoZSBvbmx5IHJlYXNvbiBJIGNhbiB0aGluayBvZiBmb3IgdGhp cyBjaG9pY2UgaXMgYmVjYXVzZSB0aGVzZQ0KPiBtaWdodCBiZSBydW5uaW5nIG9uIG5vbi1zdGFu ZGFyZCBwb3J0cywNCg0KW01lZF0gQ3VzdG9taXplZCBwb3J0IG51bWJlcnMgY2FuIGJlIGFjY29t bW9kYXRlZCB3aXRoIHRoZSBzaW5nbGUgYXR0cmlidXRlICh3aXRoIGJpdG1hc2spIGJ5IHJldHVu aW5nIG11bHRpcGxlIGluc3RhbmNlcyBvZiB0aGUgYXR0cmlidXRlIHdpdGggZGlzdGluY3QgRE5T IHR5cGVzLiAgIA0KDQpUaGUgc2FtZSByZWFzb25pbmcgYXBwbGllcyBpZiBvbmUgd2FudCB0byB0 ZXJtaW5hdGUgRG9UL0RvSC9Eb1Egb24gZGlzdGluY3QgSVAgYWRkcmVzKGVzKSBvciBvbmUgd2Fu dCB0byB1c2UgZGlzdGluY3QgYXV0aGVudGljYXRpb24gbmFtZSBmb3IgZWFjaCBlbmNyeXB0ZWQg RE5TLiANCg0KSW4gdGhhdCBhcHByb2FjaCwgYW4gaW1wbGVtZW50YXRpb24gaGFzIHRvIHByb2Nl c3MgYm90aCB0aGUgYXR0cmlidXRlIHR5cGUgYW5kIHN1Yi10eXBlIHRvIGRlY2lkZSB3aGF0IHRv IGRvLiAgDQoNCldpdGggdGhlIHN1Yi10eXBlIHJlbW92ZWQsIHRoZSBwcm9jZXNzaW5nIGlzIGEg bGl0dGxlIGJpdCBzaW1wbGlmaWVkLiANCg0KIGJ1dCBJIHRoaW5rIHRoYXQgcmVhc29uIGlzDQo+ IHJhdGhlciB3ZWFrLiBEb1QgYW5kIERvUSB3aWxsIHJ1biBvbiBzdGFuZGFyZCBkZWZpbmVzIHBv cnRzIGFuZA0KDQpbTWVkXSBJIHRlbmQgdG8gYWdyZWUgd2l0aCB5b3UgZm9yIERvVC4gDQoNCkZv ciBEb1EsIHRoZSBzaXR1YXRpb24gaXMgYSBsaXR0bGUgYml0IGRpZmZlcmVudDoNCiogVGhlcmUg aXMgbm8gZGVmYXVsdCBwb3J0ICh5ZXQpLg0KKiBXZSBhZGRlZCB0aGUgcG9ydCB0byB0aGUgc3Bl YyB0byBhZGRyZXNzIGEgY29tbWVudCB3ZSByZWNlaXZlZCBmcm9tIHRoZSBhdXRob3JzIG9mIERv USBzcGVjaWZpY2F0aW9uOiBDaHJpc3RpYW4gSHVpdGVtYSBzdWdnZXN0ZWQgdG8gaGF2ZSB0aGUg cG9ydCBjb25maWd1cmFibGUuIA0KDQo+IERvSCdzIHByb3RvY29sIGFpbXMgYXQgYmxlbmRpbmcg aW4gYXMgd2ViIHRyYWZmaWMgc28gaXQgcmVhbGx5IGlzDQo+IG9ubHkgZ2V0dGluZyBkZXBsb3ll ZCBvbiBwb3J0IDQ0My4NCg0KW01lZF0gRnVsbHkgYWdyZWUuIA0KDQo+IA0KPiBTbyBpZiBJIGJ1 aWxkIGEgc2luZ2xlIHNlcnZlciB0aGF0IGNhbiBkbyB1bmVuY3J5cHRlZCBhbmQgYWxsDQo+IGVu Y3J5cHRlZCBmbGF2b3VycywgSSdkIHByZWZlciB0byBzZW5kIGFuZCByZWNlaXZlIGp1c3QgMSBD UCBwYXlsb2FkDQo+IGNvdmVyaW5nIGV2ZXJ5dGhpbmcuDQoNCltNZWRdIFRoYXQgd2FzIHRoZSBy ZWFzb25pbmcgd2UgaGFkIGluIC0wMCBhbmQgbXkgZmF2b3JpdGUgQlRXIGJ1dCBhcyBhbiBlZGl0 b3Igb2YgdGhlIGRvY3VtZW50IEknbSBhbHNvIGhlYXJpbmcgY29tbWVudHMgYXNraW5nIGZvciBt b3JlIGZsZXhpYmlsaXR5IGFuZCBzaW1wbGljaXR5Og0KKiB3aGF0IGlmIHRoZSBzZXJ2ZXJzIHRl cm1pbmF0ZXMgb24gZGlzdGluY3QgYWRkcmVzc2VzPw0KKiB3aGF0IGlmIGRpc3RpbmN0IGF1dGhl bnRpY2F0aW9uIG5hbWVzIGFyZSB1c2VkPw0KKiB3aGF0IGlmIGEgbm9uLWRlZmF1bHQgcG9ydCBp cyB1c2VkPw0KDQpJJ20gbm90IHN1cmUgd2UgY2FuIHJlY29uY2lsZSB0aGUgZGVzaXJlIHRvIHJl dHVybiBvbmUgQ1AgcGF5bG9hZCB2cy4gYXR0cmlidXRlIHNpbXBsaWNpdHkgZm9yIGNhc2VzIHdp dGggY3VzdG9taXplZCBjb25maWcuIA0KDQo+IA0KPiBXZSBfY291bGRfIGxlYXZlIHRoZSBwb3J0 IHRoZXJlIGZvciBub24tc3RhbmRhcmQgcG9ydHMsIGJ1dCB0aGVuIHdlDQo+IHNob3VsZCBhZGQg YSBzcGVjaWZpYyBwb3J0IGF0dHJpYnV0ZSBmb3IgZWFjaCBiaXRtYXNrIGVudHJ5LiBCdXQNCj4g aG9uZXN0bHksIHRoZSB3aG9sZSBub24tZGVmYXVsdCBwb3J0IHBhcnQgc2VlbXMgbGlrZQ0KPiBv dmVyZW5naW5lZXJpbmcuDQo+IA0KPiBGb3IgdGhvc2Ugd2hvIGNhcmUgYSBsb3QgYWJvdXQgbWlu aW1pemluZyBieXRlcyBleGNoYW5nZWQgb3ZlciBJS0UsDQo+IG15IGFib3ZlIHByb3Bvc2FsIHdv dWxkIHNhdmUgYSBsb3Qgb2YgYnl0ZXMuDQo+IA0KDQpbTWVkXSBBZ3JlZSB0aGF0IGl0IHNhdmVz IGJ5dGVzIGZvciB0aGUgc2luZ2xlIHNlcnZlciBjYXNlIHN1cHBvcnRpbmcgYWxsIEROUyB0eXBl cywgYnV0IG5vdCBpZiBjdXN0b21pemVkIEAvQU5EL3BvcnQgYXJlIHVzZWQuICAgDQoNCj4gDQo+ IEkgd291bGQgYWxzbyBsaWtlIHRvIHNlZSBtb3JlIGNsYXJpZmljYXRpb24gYWJvdXQgc3BsaXQt RE5TIGFuZCBob3cNCj4gYSBsaXN0IG9mIGRvbWFpbnMgaXMgY29udmV5ZWQgdmlhIElLRSBhcyB0 aGUgb25seSBkb21haW5zIHRvIGJlDQo+IHJlc29sdmVkIHZpYSB0aGUgZ2l2ZW4gZW5jcnlwdGVk IEROUyBzZXJ2ZXJzLg0KDQpbTWVkXSBXZSBhcmUgcmVseWluZyB1cG9uIFJGQzg1OTggYXMgZGVz Y3JpYmVkIGluIHRoZSBkcmFmdDogIA0KDQogICBJZiB0aGUgSVBzZWMgY29ubmVjdGlvbiBpcyBh IHNwbGl0LXR1bm5lbCBjb25maWd1cmF0aW9uIGFuZCB0aGUNCiAgIGluaXRpYXRvciBuZWdvdGlh dGVkIElOVEVSTkFMX0ROU19ET01BSU4gYXMgcGVyIFtSRkM4NTk4XSwgdGhlIEROUw0KICAgY2xp ZW50IE1VU1QgcmVzb2x2ZSB0aGUgaW50ZXJuYWwgbmFtZXMgdXNpbmcgRU5DRE5TX0lQKl8qIERO Uw0KICAgc2VydmVycy4NCg0KICAgICAgTm90ZTogW1JGQzg1OThdIHJlcXVpcmVzIElOVEVSTkFM X0lQNl9ETlMgKG9yIElOVEVSTkFMX0lQNF9ETlMpDQogICAgICBhdHRyaWJ1dGUgdG8gYmUgbWFu ZGF0b3J5IHByZXNlbnQgd2hlbiBJTlRFUk5BTF9ETlNfRE9NQUlOIGlzDQogICAgICBpbmNsdWRl ZC4gIFRoaXMgc3BlY2lmaWNhdGlvbiByZWxheGVzIHRoYXQgY29uc3RyYWludCBpbiB0aGUNCiAg ICAgIHByZXNlbmNlIG9mIEVOQ0ROU19JUCpfKiBhdHRyaWJ1dGVzLg0KDQpEbyB5b3UgaGF2ZSBp biBtaW5kIGFueSBzcGVjaWZpYyBwb2ludCBub3QgY292ZXJlZCBpbiBSRkM4NTk4IHRoYXQgd2Ug bmVlZCB0byBjb25zaWRlcj8gDQoNCj4gDQo+IEkgd291bGQgbGlrZSB0byBzZWUgc29tZXRoaW5n IGluIHRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBhYm91dA0KPiBoYW5kaW5nIG91dCB3ZWxs IGtub3duIG5vbi1WUE4gcmVhY2hhYmxlIGVuY3J5cHRlZCBETlMgc2VydmVycy4gIEVnDQo+IEkn ZCBsaWtlIHRvIGF2b2lkIHRoYXQgdGhpcyBkb2N1bWVudCBjYW4gaW5zdHJ1Y3QgVlBOIHVzZXJz IHRvIHVzZQ0KPiBEb1QgYXQgOC44LjguOCBpZiBpdCBpcyBub3QgZ29pbmcgdG8gb2ZmZXIgYSBW UE4gdGhhdCBjb3ZlcnMNCj4gOC44LjguOC4gSWYgd2UgZG9uJ3QgZG8gdGhpcywgdGhlbiBWUE4g cHJvZmlsZXMgbWlnaHQgZW5kIHVwDQo+IGFidXNpbmcvcmVkaXJlY3RpbmcgdXNlcnMgd2l0aG91 dCBvZmZlcmluZyBhbnkgYWN0dWFsIFZQTiBzZXJ2aWNlIC0NCj4gbGlrZSBvdmVycmlkaW5nIHRo ZSBzeXN0ZW0gb3IgYXBwbGljYXRpb24gc3BlY2lmaWMgY29uZmlndXJhdGlvbg0KPiB3aXRob3V0 IG9mZmVyaW5nIGFjdHVhbCBWUE4gc2VydmVycyB0byB0aGUgdXNlci4NCj4gDQoNCltNZWRdIFRo aXMgd291bGQgYXBwbHkgZm9yIElOVEVSTkFMX0lQKl9ETlMgYXR0cmlidXRlcyBhcyB3ZWxsLiBX ZSBjYW4gYWRkIGEgZ2VuZXJpYyBub3RlLiANCg0KPiBJJ20gYWxzbyBjb25zaWRlcmVkIGFib3V0 IHBvc3NpdmUgYWJ1c2UgYnkgdGhlIHNwZWNpZmljYXRpb24gb2YgdGhlDQo+IGF1dGhlbnRpY2F0 aW9uIGRvbWFpbiBuYW1lLiBFZyBhIFZQTiBwcm92aWRlciBzZXR0aW5nIHVwIGEgdHVubmVsDQo+ IGNvdmVyaW5nIDEuMS4xLjEgKGRucy5jbG91ZGZsYXJlLmNvbSkgd2l0aCBhbiBhdXRoZW50aWNh dGlvbiBuYW1lIG9mDQo+ICJkbnMuZ29vZ2xlLmNvbSIgYW5kIGJhc2ljYWxseSByZWRpcmVjdGlu ZyBhbGwgMS4xLjEuMSB0cmFmZmljIG92ZXINCj4gdGhlIFZQTiB0byA4LjguOC44Lg0KPiANCg0K W01lZF0gTm90IHN1cmUgdG8gZ2V0IHRoaXMgb25lLg0KCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBk aWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBh dmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwn ZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBM ZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9u LApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRl IGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZv cm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUg ZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Mon Sep 14 11:06:58 2020 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 378EF3A0DEF for ; Mon, 14 Sep 2020 11:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnexW9O7I3fa for ; Mon, 14 Sep 2020 11:06:55 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 700F83A0DD6 for ; Mon, 14 Sep 2020 11:06:02 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id E6ED0601E3; Mon, 14 Sep 2020 18:06:01 +0000 (UTC) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_E7379B18-57C7-49A3-8CCC-7A24F417A9DD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Message-Id: Date: Mon, 14 Sep 2020 14:06:00 -0400 Cc: Christian Hopps To: ipsec@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: [IPsec] Next IPTFS doc update question 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, 14 Sep 2020 18:06:56 -0000 --Apple-Mail=_E7379B18-57C7-49A3-8CCC-7A24F417A9DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Folks, I'll be posting a new version of = https://www.ietf.org/archive/id/draft-ietf-ipsecme-iptfs-01.txt in the = next couple days, and have one edit to ask about. Early in the document development process there was a request by Valery = (perhaps supported by Paul W?) to remove the late-enabling of IP-TFS on = an SA. The expressed feeling was this was too much complexity to add for = not enough value. 2.4. Initiating IP-TFS Operation On The SA. While a user will normally configure their IPsec tunnel (SA) to operate using IP-TFS to start, we also allow IP-TFS operation to be enabled post-SA creation and use. This late-enabling may be useful for debugging or other purposes. To support this late-enabled operation the receiver switches to IP-TFS operation on receipt of the first ESP payload with the IPTFS_PROTOCOL indicated as the payload type which also contains a data block (i.e., a non-empty IP-TFS payload). The the receipt of an empty IPTFS_PROTOCOL payload (i.e., one without any data blocks) is used to communicate congestion control information from the receiver back to the sender on a non-IP- TFS enabled SA, and MUST NOT cause IP-TFS to be enabled on that SA. I'm wondering if anyone else has any comments (for or against) on = keeping this functionality? Thanks, Chris. --Apple-Mail=_E7379B18-57C7-49A3-8CCC-7A24F417A9DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl9fsQgACgkQLh2DDte4 MCWOHBAAg5gk9uyVmPI+57q4RPEH161x1qA5J7hn5GmBfweONfN1+0ER3IAHGtaD k6uYuaW+c/LKVbAOrvZQydBMXhoe1uMIYosLfeETiQzrnEN/AqJ1EEhzcb1azjJ2 IeNraux6+2UCKajULkW3S8KaqCigx8C+dzASOultaAHSJlv0/DeFX45bYwXs+vMo 9UAFCKFWRs4RnaYxDRX0Up1mtCk1bORluLWM5hmjDvTJvYqZSmkbvl/ZFNSEhHUT i6UsCl/cl2wmuP89FV8sf5vRQ8eVPXxZpfaCUTL5x/DSbawpNvOoDUEHnRFXKMYL YJuU8NtYP7Oy5L5nk6DijMaU52lwehgEcW7KCHm13/dCDcCmkHcWF2Noyz59vr5A ZSgWD5iqP5NiujM3LZXvwxc50/MmvZHtVK6IA/9UrfRgALzV/jmQNXBqdRLT2wbz 9V7REyZAwHHTnn8TYSuxAUUiwY732pol1+EjQ1MUWMNJjqRn57uUxKk3ltGVRRE0 oxoOZRV+olvNu0Sy94u+dPnBmvhcUK7kZleErbzCr3OGEqJrOao8I+w5b8ulqFxO aHlf0bv/pasZyIAo453TDz7LNAz9cfIbEbK18HmcFfF3s8HKtNumMv7/vfBuZetX SOMR4dIlCstt9Cab0XDu0K0RWuvmQx2kLOZrz0YIAwuy1Xvh+zg= =OfYf -----END PGP SIGNATURE----- --Apple-Mail=_E7379B18-57C7-49A3-8CCC-7A24F417A9DD-- From nobody Wed Sep 16 15:02:14 2020 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 255C03A0DD2 for ; Wed, 16 Sep 2020 15:02:13 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrUVbAajSR4v for ; Wed, 16 Sep 2020 15:02:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D463A0D91 for ; Wed, 16 Sep 2020 15:02:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C5D2E389B0; Wed, 16 Sep 2020 17:40:52 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2FKPhStvvxZi; Wed, 16 Sep 2020 17:40:47 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id B7441389A9; Wed, 16 Sep 2020 17:40:47 -0400 (EDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BC6534F5; Wed, 16 Sep 2020 18:02:04 -0400 (EDT) To: ipsec@ietf.org, Michael.rossbert@tu-ilmenau.de References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> From: Michael Richardson Message-ID: <47eb9242-4211-04ec-8bdf-96be54f2864d@sandelman.ca> Date: Wed, 16 Sep 2020 18:02:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [IPsec] Data Center changes to ESP, Re: leading versus trailing ICV 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, 16 Sep 2020 22:02:13 -0000 Hi, I finally got to watching your presentation on the IETF youtube channel. the illustration at https://youtu.be/IrNsFAPhx-Q?t=3410, which I guess is also at: https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-proposed-improvements-to-esp-01 slide 3. It is unfortunate that the youtube video does not capture the jabber discussion at all, and I have to go find that log. As Bill Simpson pointed out, you don't need a new ESP protocol number because the layout of the ESP packet is already essentially driven by the SPI#. The business of using this window,sender and sequence number as the IV might be AES-AEAD specific. I'm sure that it can apply to a number of other ciphers, but perhaps not to classic 3DES+MD5^WAES-128+SHA256. I think that a way to negotiate this is as if it was unique cipher. i.e: https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-5 which is Expert Review. I agree with Tero that this is outside of the charter. I suggest that you ask for an allocation, write some code, document it an individual ID and report on the WG on how well this works for you, and on whether the hardware people are happy with the results. From nobody Wed Sep 16 23:57:30 2020 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 48B173A0EF2 for ; Wed, 16 Sep 2020 23:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 sJ3JqEDyw7fP for ; Wed, 16 Sep 2020 23:57:20 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2BBC3A0F7D for ; Wed, 16 Sep 2020 23:57:10 -0700 (PDT) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 85855548019; Thu, 17 Sep 2020 08:57:05 +0200 (CEST) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7CF93440059; Thu, 17 Sep 2020 08:57:05 +0200 (CEST) Date: Thu, 17 Sep 2020 08:57:05 +0200 From: Toerless Eckert To: Tero Kivinen Cc: William Allen Simpson , Steffen Klassert , ipsec@ietf.org Message-ID: <20200917065705.GF50637@faui48f.informatik.uni-erlangen.de> References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> <20200731083259.GG20687@gauss3.secunet.de> <97778198-87b3-e27e-6da9-b3ea83f62b29@gmail.com> <24364.15444.621102.781854@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24364.15444.621102.781854@fireball.acr.fi> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [IPsec] leading versus trailing ICV 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, 17 Sep 2020 06:57:29 -0000 On Thu, Aug 06, 2020 at 08:22:28PM +0300, Tero Kivinen wrote: > William Allen Simpson writes: > > > So it might make sense to have the ICV at the end because it is > > > likely cache hot when needed. > > > > But after removing padding for these stream algorithms, then the ICV is > > very likely not aligned. For zero-copy RDMA, it is rather inconvenient. > > And the IP header cache lines are likely still hot. > > > > Anyway, that's why I'd like to consider at least a negotiated option -- > > as long as it's possible to implement efficiently in Linux and others. > > We need to hear from more implementers. > > I think it would be a bad idea to have such option. Yes, it might > offer small gains on environments where the option is picked exactly > when both ends like it, but when one ends pick it in a way which other > end does not like, we usually end up big performance penalties. If IKEv2/IPsec will not allow to negotiate the mutually best option, then IMHO IKEv2/IPsec option negotiation needs to be improved. But for a new option, i can not see short-term issues: Nodes for whom the new option will not provide performance enhancements will simply not implement them. Of course, when the mayority of implementations get a benefit of a new option and the next profile for IPsec makes it mandatory, then those other implementation will start having a challenge without better negotiations. > And also it again multiples the testing effort as now you need to add > to your test suites this combined with all posible ciphers etc. > > This is was one of the main problems with IKEv1, there were so many > different combinations of different options that to be able to test > all of them required thousands or tens of thousands of test cases. Automated regression testing. There is certainly the need to distinguish profiling of options between more agile managed implementations and those who are not. > Example of similar optimzation causing problems was found during > interop events when some version (I think it was Linux) was sending > fragmented packets in reverse order, so the first network packet > sent/received was the last fragment. The idea was that when receiver > saw that last fragment it can immediately know how big the final > packet will be and it can allocate big enough buffer for the packet. > > Then when you combined that with IPsec with per flow policy, meaning > each TCP/UDP flow might be using different SA, that meant that SGW > required to store all fragments in memory until it got the last packet > from the network, which was the first fragment, and only after that it > could check whether this packet is allowed to pass, and which SA it > needs to use. > > Then it sent the fragments out, but there was lots of added latency > because of this. Actually I think there were also implementations > which did not even store the later fragments, they simply checked the > later fragments, and found out that they have not seen the first > fragment that would allow them to be passed, so they dropped them. > > The SGW of course then sent the frames out in order, so that the > receiving SGW can efficently do exit tunnel checks (i.e., check from > the first fragment that this packet should be allowed, and match later > fragments with same fragment id to that, and allow them to passed), > and it then did not need to do same buffering. Of course the final > destination host now did not benefit at all from this optimization as > it was negatied by the SGWs in the middle. If insights like there would be documented more prominentaly, like in a living IETF document, then they would fsater trickle through implementers. > So immediately when the options to use start to depend on the > platform, implementation etc it gets harder and harder to find out > which will be the optimal combination between two devices, and they > might end up using suboptimal feature set. And all of those add more > complexity and combinations that needs to be tested. Before the next profile changes as to what options SOULD/MUST be supported, there could be a collection round of evidence: If a new protocol option has documented performance results in comparison to prior MUST options that show e.g.: double performance, you will have a hard time to reject it. If it doesn't have such data, you will have an easy way to reject it. > Of course if this option is added, it should be something like IPCOMP > or transport mode, meaning it is off by default, and everybody MUST > implement case where it is not enabled, then you would only implement > (and propose) it on cases where it actually benefits you, and > everybody else would never ever implement it. I think thats what i also said above. Cheers Toerless > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- --- tte@cs.fau.de From nobody Thu Sep 17 03:59:39 2020 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 1F5BC3A0990 for ; Thu, 17 Sep 2020 03:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 AMHaiFFjyLak for ; Thu, 17 Sep 2020 03:59:36 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 C75723A098A for ; Thu, 17 Sep 2020 03:59:34 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 5D04F20337; Thu, 17 Sep 2020 13:59:31 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1600340371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s9ok+Bhi2WqW8+0tDtb058qpXvXplTCTQg0Q826lxJE=; b=n/v1DRxgYO8HAHFavhJIAvyVNlo3CrqRYy7xyTAxbku5zefMSBc9joSGpgTkEVryY9l5qG R5CXlswaBdF1oJcFCbZlWGWl0tEXCSd4jGFSt9KdHjfG/yDC/7mw4TXbeZ7BPLg78j6g3T apkMEbk9f6Rewlv4oZfJbj2ZAbhLPFw= Received: by fireball.acr.fi (Postfix, from userid 15204) id D67B625C11A2; Thu, 17 Sep 2020 13:59:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24419.16786.828280.632306@fireball.acr.fi> Date: Thu, 17 Sep 2020 13:59:30 +0300 From: Tero Kivinen To: Toerless Eckert Cc: William Allen Simpson , Steffen Klassert , ipsec@ietf.org In-Reply-To: <20200917065705.GF50637@faui48f.informatik.uni-erlangen.de> References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> <20200731083259.GG20687@gauss3.secunet.de> <97778198-87b3-e27e-6da9-b3ea83f62b29@gmail.com> <24364.15444.621102.781854@fireball.acr.fi> <20200917065705.GF50637@faui48f.informatik.uni-erlangen.de> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 15 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1600340371; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=s9ok+Bhi2WqW8+0tDtb058qpXvXplTCTQg0Q826lxJE=; b=KEiCldW35F6tOmE5aNA5dUr1PyDcOK1LOoyw80B+4iGg61ddh8HI4AGeTHrZ/7+jowPCdM 5782Iinoyd9GY0fRLEmRTzS8nbziLa7zjhBnZMJCv95XFAtlIM7lvX/CZ9iK259QRpe+z3 4khCqFuE/kZToNYYhQY+u3JoqAMfBlY= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1600340371; a=rsa-sha256; cv=none; b=TtdoxDUcPH6uIW+EMc3GxpcGTo3f52FVkbjXAO/RWs/SauWacVA4fSLLQ5AAsJ3lAXssN3 Oho9+JuUNcaVpPfqC0uuBk2gGMBblckzjeut/0Ngq64ESz7FFbByph17A+q3XdyI68a0rd ErSZYjp2whvy8JniGdrio6/Duk9dHV4= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] leading versus trailing ICV 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, 17 Sep 2020 10:59:38 -0000 Toerless Eckert writes: > If insights like there would be documented more prominentaly, like > in a living IETF document, then they would fsater trickle through > implementers. That kind of things were usually found in the interop events where there were few dozen vendors testing againt each other. We did document some of those issues in documents like RFC4718 IKEv2 Clarifications and Implementation Guidelines. Most vendors are not very keen on telling how they actually manage to get the performance gains they do, because that is one of their benefits, if they are 3% faster than competitor because they actually modify operating system so that it always makes sure there is space at the end of packet for ICV. It is much easier to get vendors to disclose, issues that affect interoperability than issues that affect performance. And even those cases they do no want company names to be mentioned. They might tell their secret performance enhancing tricks during friendly talk with other implementor, but might not want this to be written down (as then they would need permission from the management, which would most likely say no way). > > So immediately when the options to use start to depend on the > > platform, implementation etc it gets harder and harder to find out > > which will be the optimal combination between two devices, and they > > might end up using suboptimal feature set. And all of those add more > > complexity and combinations that needs to be tested. > > Before the next profile changes as to what options SOULD/MUST be supported, > there could be a collection round of evidence: If a new protocol option > has documented performance results in comparison to prior MUST options > that show e.g.: double performance, you will have a hard time to reject > it. If it doesn't have such data, you will have an easy way to reject it. If there would be someone who finds a way to double the performance then yes, that would be huge difference, but when we are talking implementations which should be able to use 95% of the capacity of the network link anyways, the performance gains are usually much smaller. For large packets the speed is usually restricted either by the network speed, or the raw crypto speed. For small packets the issues are quite often in general operating system overhead (i.e., even without crypto things tend to be slow). -- kivinen@iki.fi From nobody Fri Sep 18 05:51:17 2020 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 C9C6C3A08AF; Fri, 18 Sep 2020 05:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAK83lbFQZRh; Fri, 18 Sep 2020 05:51:13 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 86C7C3A08B2; Fri, 18 Sep 2020 05:51:13 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id n25so5007276ljj.4; Fri, 18 Sep 2020 05:51:13 -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=JFFa45A3vQdoWB9KyCV35NZLqfVpjtOM7Eo5BgCuhr8=; b=K+iHtB2l0hhvCu6TK93+LFFofIWzJSg7bcsQ6qej8eidebM+IfBao/Y86wnpEnQ4Tr 3fL97HXG3W5Fc9A0tB56Z2b3dmIYN0xV2bMmN14WmGM06yWmjSN6rDEmWsHz9paQD/4H IzdimLa0oWILipf0xBK33261euq11EuiiyXNogu6U4O/U3y2c7e2tAGScyTyfTO1I8hy Ra4/1bqaMAAwHRYWyvINTlJtu3LO453iCykjh6tSZgLmhjYvfCzW/10109TnhY9fyg7u lb1rhAEi6/vlEtfoUvg8B54Wv8QYmsEtzyT3Vg3vRuN8hGW4hPk1ssvd/KaBMselRiY9 mm5g== 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=JFFa45A3vQdoWB9KyCV35NZLqfVpjtOM7Eo5BgCuhr8=; b=fP5qIf5Lk11Lzz/j6DMvmweg2YimEFf6xJdoPHdu3un8h4ulZXwCVjJoWP9VQS7uYU 9mE1FuqU97NMgqYm3kW2AOo8zruf+yTIbsXXvTzU4bsjI1daoSuD4zg0yI9QKTHXI0bl lhsI1mOOM3uKrE5w8AWxkV3QyuUkaWvqprRM5r/ahHVTpa+Z9kQ7/JSeLEBJROJUZVI1 BaWJngw7s1RIBDEqtxa3wzdMl5+liX+a6YbtAMDSCb3RqwogTlowd6flJpqQIiCSiL6F U0KdcLk+SGRwRAyKiGm00bokPFR7bUCokzm4A4RTOvqbuhj2uUEZJYhAN/VNQIwSJpPI b0tw== X-Gm-Message-State: AOAM531JqCSw96n3USVmKM0G/RS9tMm5GtHWfUztVUCMaMyS8AJgQPZx Q55RBIZJmGIxeQXVFFAtUU00TYT39wk= X-Google-Smtp-Source: ABdhPJy0G0L+ty/7DUiMcRHTGqyrQEPecEqzQf9oiG1+b/xbCvwwBWG+QpKtFoyDht0r/hVNtMMIyQ== X-Received: by 2002:a2e:b4ca:: with SMTP id r10mr11973337ljm.452.1600433471035; Fri, 18 Sep 2020 05:51:11 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id l188sm568885lfd.127.2020.09.18.05.51.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Sep 2020 05:51:10 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , Cc: , References: <159965296544.28196.15433560776696094354@ietfa.amsl.com> <24155_1599723204_5F59D6C4_24155_339_53_787AE7BB302AE849A7480A190F8B93303153E1B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Fri, 18 Sep 2020 15:51:11 +0300 Message-ID: <087501d68dba$63522690$29f673b0$@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: AQMPpE7MyCZTOOcf6YMBeeCfdJsZvgIZFiwOAj9vIcSm2V4DMA== Content-Language: ru Archived-At: Subject: Re: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-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: Fri, 18 Sep 2020 12:51:16 -0000 Hi Paul, > Why is this using a seperate CP payload type per encrypted DNS type? > This means that for a DNS server supporting DoT, DoH and DoQ, it needs > to send 3 separate payloads. Why not send 1 CP payload that contains a > bitmask specifying which services it supports? Well, from my understanding of ADD (I'm not an expert), there must not be substantial difference between different types of encrypted DNS servers in terms of provided service (ADD folks use term "equivalent" reolvers, emphasizing=20 that no matter which resolver the client reaches the=20 response will be the same).=20 If my understanding is correct, then I see little sense in=20 configuring all types of encrypted DNS servers. So, DoT, DoH, DoQ is more a capability negotiation: the client asks for those types of encrypted DNS it supports and the server returns server(s) of one type, based on its configuration. In this case there is no difference in message size if we use=20 separate attributes or a single attribute with bitmask. And several simple attributes are a bit easier to process... > The only reason I can think of for this choice is because these might > be running on non-standard ports, but I think that reason is rather > weak. DoT and DoQ will run on standard defines ports and DoH's = protocol > aims at blending in as web traffic so it really is only getting = deployed > on port 443. >=20 > So if I build a single server that can do unencrypted and all = encrypted > flavours, I'd prefer to send and receive just 1 CP payload covering > everything. Please, see above. > We _could_ leave the port there for non-standard ports, but then we > should add a specific port attribute for each bitmask entry. But = honestly, > the whole non-default port part seems like overengineering. >=20 > For those who care a lot about minimizing bytes exchanged over IKE, > my above proposal would save a lot of bytes. Again, see above. > I would also like to see more clarification about split-DNS and how a > list of domains is conveyed via IKE as the only domains to be resolved > via the given encrypted DNS servers. What problems are with the current text? I believe almost all from = RFC8598 remains valid, we only replace Do53 servers IP addresses with Encrypted=20 DNS ones. > I would like to see something in the Security Considerations about = handing > out well known non-VPN reachable encrypted DNS servers. Eg I'd like = to > avoid that this document can instruct VPN users to use DoT at 8.8.8.8 = if > it is not going to offer a VPN that covers 8.8.8.8. If we don't do = this, > then VPN profiles might end up abusing/redirecting users without = offering > any actual VPN service - like overriding the system or application > specific configuration without offering actual VPN servers to the = user. What is your proposal? Restrict DNS servers IP addresses=20 to always be within Tri/TSr ranges? > I'm also considered about possive abuse by the specification of the > authentication domain name. Eg a VPN provider setting up a tunnel > covering 1.1.1.1 (dns.cloudflare.com) with an authentication name of > "dns.google.com" and basically redirecting all 1.1.1.1 traffic over = the > VPN to 8.8.8.8. How can you prevent it? Regards, Valery. > Paul >=20 >=20 >=20 >=20 > > Please review and share your comments. > > > > Thank you. > > > > Cheers, > > Med > > > > -----Message d'origine----- > > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Envoy=C3=A9 : mercredi 9 septembre 2020 14:03 > > =C3=80 : Dan Wing ; Valery Smyslov = ; BOUCADAIR Mohamed TGI/OLN > ; Tirumaleswar Reddy.K = ; > Tirumaleswar Reddy > > Objet : New Version Notification for = draft-btw-add-ipsecme-ike-01.txt > > > > > > A new version of I-D, draft-btw-add-ipsecme-ike-01.txt has been = successfully submitted by Mohamed > Boucadair and posted to the IETF repository. > > > > Name: draft-btw-add-ipsecme-ike > > Revision: 01 > > Title: Internet Key Exchange Protocol Version 2 (IKEv2) = Configuration for Encrypted DNS > > Document date: 2020-09-09 > > Group: Individual Submission > > Pages: 11 > > URL: = https://www.ietf.org/id/draft-btw-add-ipsecme-ike-01.txt > > Status: = https://datatracker.ietf.org/doc/draft-btw-add-ipsecme-ike/ > > Htmlized: = https://datatracker.ietf.org/doc/html/draft-btw-add-ipsecme-ike > > Htmlized: = https://tools.ietf.org/html/draft-btw-add-ipsecme-ike-01 > > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-btw-add-ipsecme-ike-01 > > > > Abstract: > > This document specifies a new Internet Key Exchange Protocol = Version > > 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS > > with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- > > over-QUIC (DoQ). > > > > > > > > > > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and > diff are available at tools.ietf.org. > > > > The IETF Secretariat > > > > > > > > > = _________________________________________________________________________= ___________________ > _____________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne > doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le > signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles > d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or = privileged information that may be protected > by law; > > they should not be distributed, used or copied without = authorisation. > > If you have received this email in error, please notify the sender = and delete this message and its > attachments. > > As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Sep 18 15:21:36 2020 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 37CBE3A0982 for ; Fri, 18 Sep 2020 15:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtT--aF4whwX for ; Fri, 18 Sep 2020 15:21:32 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED123A005C for ; Fri, 18 Sep 2020 15:21:31 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id A90C31F4A9 for ; Fri, 18 Sep 2020 22:21:30 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 78D2C1A022D; Fri, 18 Sep 2020 18:21:29 -0400 (EDT) From: Michael Richardson to: ipsec@ietf.org In-reply-to: <47eb9242-4211-04ec-8bdf-96be54f2864d@sandelman.ca> References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> <47eb9242-4211-04ec-8bdf-96be54f2864d@sandelman.ca> Comments: In-reply-to Michael Richardson message dated "Wed, 16 Sep 2020 18:02:04 -0400." X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Fri, 18 Sep 2020 18:21:29 -0400 Message-ID: <108017.1600467689@dooku> Archived-At: Subject: Re: [IPsec] Data Center changes to ESP, Re: leading versus trailing ICV 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, 18 Sep 2020 22:21:35 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Michael Richardson wrote: > Hi, I finally got to watching your presentation on the IETF youtube c= hannel. > the illustration at https://youtu.be/IrNsFAPhx-Q?t=3D3410, which I gu= ess is > also at: > https://www.ietf.org/proceedings/108/slides/slides-108-ipsecme-propos= ed-improvements-to-esp-01 > slide 3. My attempt to CC Michael Rossbert failed. I was reading off the slides from= a youtube paused. I hope he is on the ML. > I think that a way to negotiate this is as if it was unique cipher. BTW: I recognize that this might require a new value for each cipher. As such, it's not a great long term solution, but I would claim that it probably applies to a few ciphers very specifically at first.=20=20 Once the new layout is so popular, then we could persue some other way to do this. Probably that means the same Notify() mechanism we use for TRANSPORT= _MODE/etc. I'm not especially fond of this architecturally, but it certainly works. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl9lMukACgkQlUzhVv38 QpA14wf/erwx2pP8lrX03kIqTHAXbh4nUG60M/1NhxfQFyGIsZ8FtSCJR1PMn7bt 0QAttzGpjFJdX4G6dN+2z3Jr7JJSSC7IaM6XRkS3TP5OrfQWMUAKLDSQ7w0WKAqH DM88cu/pCbFURCa7JnbNbT3T5Xyx3uQbHDLbB2EkiRbyz/e77ESirXPjZ0aBJ+mX MLXlpgm1MqAFY4UEuHHr7aRKByR7vE1H8fl6Lo+OLQ/bRsSmzOj5MvzPMGJpZq6J 8N3Lu1YbUt4MRyMURtvIWdubB79GMVwC+ZqMn2DfvSdgGn0X57Hf6otrcfIon/mH QIrtlXCz6iDXLe5Uyubgt1vIrkg9EA== =O57h -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 18 22:09:46 2020 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 A90AB3A0B60; Fri, 18 Sep 2020 22:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCOVvLCSHe4s; Fri, 18 Sep 2020 22:09:41 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 465B13A09C3; Fri, 18 Sep 2020 22:09:41 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08J59YLo002724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 19 Sep 2020 01:09:36 -0400 Date: Fri, 18 Sep 2020 22:09:34 -0700 From: Benjamin Kaduk To: Valery Smyslov Cc: "'Paul Wouters'" , mohamed.boucadair@orange.com, ipsec@ietf.org, draft-btw-add-ipsecme-ike@ietf.org Message-ID: <20200919050934.GN89563@kduck.mit.edu> References: <159965296544.28196.15433560776696094354@ietfa.amsl.com> <24155_1599723204_5F59D6C4_24155_339_53_787AE7BB302AE849A7480A190F8B93303153E1B7@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <087501d68dba$63522690$29f673b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <087501d68dba$63522690$29f673b0$@gmail.com> User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-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: Sat, 19 Sep 2020 05:09:44 -0000 On Fri, Sep 18, 2020 at 03:51:11PM +0300, Valery Smyslov wrote: > Hi Paul, > > > Why is this using a seperate CP payload type per encrypted DNS type? > > This means that for a DNS server supporting DoT, DoH and DoQ, it needs > > to send 3 separate payloads. Why not send 1 CP payload that contains a > > bitmask specifying which services it supports? > > Well, from my understanding of ADD (I'm not an expert), > there must not be substantial difference between different > types of encrypted DNS servers in terms of provided service > (ADD folks use term "equivalent" reolvers, emphasizing > that no matter which resolver the client reaches the > response will be the same). > > If my understanding is correct, then I see little sense in > configuring all types of encrypted DNS servers. > So, DoT, DoH, DoQ is more a capability negotiation: > the client asks for those types of encrypted DNS > it supports and the server returns server(s) of one type, > based on its configuration. I would expect there to be some people pushing to have this be a capability negotiation that honors the client's preference, not the server's; the scenario you describe is one where the server's preference is used. (To be fair, I'm not following ADD much at all, though, so I could be wrong.) -Ben > In this case there is no difference in message size if we use > separate attributes or a single attribute with bitmask. > And several simple attributes are a bit easier to process... > > > The only reason I can think of for this choice is because these might > > be running on non-standard ports, but I think that reason is rather > > weak. DoT and DoQ will run on standard defines ports and DoH's protocol > > aims at blending in as web traffic so it really is only getting deployed > > on port 443. > > > > So if I build a single server that can do unencrypted and all encrypted > > flavours, I'd prefer to send and receive just 1 CP payload covering > > everything. > > Please, see above. > > > We _could_ leave the port there for non-standard ports, but then we > > should add a specific port attribute for each bitmask entry. But honestly, > > the whole non-default port part seems like overengineering. > > > > For those who care a lot about minimizing bytes exchanged over IKE, > > my above proposal would save a lot of bytes. > > Again, see above. > > > I would also like to see more clarification about split-DNS and how a > > list of domains is conveyed via IKE as the only domains to be resolved > > via the given encrypted DNS servers. > > What problems are with the current text? I believe almost all from RFC8598 > remains valid, we only replace Do53 servers IP addresses with Encrypted > DNS ones. > > > I would like to see something in the Security Considerations about handing > > out well known non-VPN reachable encrypted DNS servers. Eg I'd like to > > avoid that this document can instruct VPN users to use DoT at 8.8.8.8 if > > it is not going to offer a VPN that covers 8.8.8.8. If we don't do this, > > then VPN profiles might end up abusing/redirecting users without offering > > any actual VPN service - like overriding the system or application > > specific configuration without offering actual VPN servers to the user. > > What is your proposal? Restrict DNS servers IP addresses > to always be within Tri/TSr ranges? > > > I'm also considered about possive abuse by the specification of the > > authentication domain name. Eg a VPN provider setting up a tunnel > > covering 1.1.1.1 (dns.cloudflare.com) with an authentication name of > > "dns.google.com" and basically redirecting all 1.1.1.1 traffic over the > > VPN to 8.8.8.8. > > How can you prevent it? > > Regards, > Valery. > > > Paul > > > > > > > > > > > Please review and share your comments. > > > > > > Thank you. > > > > > > Cheers, > > > Med > > > > > > -----Message d'origine----- > > > De : internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Envoy : mercredi 9 septembre 2020 14:03 > > > : Dan Wing ; Valery Smyslov ; BOUCADAIR Mohamed TGI/OLN > > ; Tirumaleswar Reddy.K ; > > Tirumaleswar Reddy > > > Objet : New Version Notification for draft-btw-add-ipsecme-ike-01.txt > > > > > > > > > A new version of I-D, draft-btw-add-ipsecme-ike-01.txt has been successfully submitted by Mohamed > > Boucadair and posted to the IETF repository. > > > > > > Name: draft-btw-add-ipsecme-ike > > > Revision: 01 > > > Title: Internet Key Exchange Protocol Version 2 (IKEv2) Configuration for Encrypted DNS > > > Document date: 2020-09-09 > > > Group: Individual Submission > > > Pages: 11 > > > URL: https://www.ietf.org/id/draft-btw-add-ipsecme-ike-01.txt > > > Status: https://datatracker.ietf.org/doc/draft-btw-add-ipsecme-ike/ > > > Htmlized: https://datatracker.ietf.org/doc/html/draft-btw-add-ipsecme-ike > > > Htmlized: https://tools.ietf.org/html/draft-btw-add-ipsecme-ike-01 > > > Diff: https://www.ietf.org/rfcdiff?url2=draft-btw-add-ipsecme-ike-01 > > > > > > Abstract: > > > This document specifies a new Internet Key Exchange Protocol Version > > > 2 (IKEv2) Configuration Payload Attribute Types for encrypted DNS > > > with a focus on DNS-over-HTTPS (DoH), DNS-over-TLS (DoT), and DNS- > > > over-QUIC (DoQ). > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of submission until the htmlized version and > > diff are available at tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > > > > > > > > > ____________________________________________________________________________________________ > > _____________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne > > doivent donc > > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le > > signaler > > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles > > d'alteration, > > > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or privileged information that may be protected > > by law; > > > they should not be distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the sender and delete this message and its > > attachments. > > > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > > > Thank you. > > > > > > _______________________________________________ > > > IPsec mailing list > > > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Sat Sep 19 16:02:08 2020 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 B3F0A3A0869; Sat, 19 Sep 2020 16:02:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 x5AlRCae3poI; Sat, 19 Sep 2020 16:02:05 -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 DD61A3A0855; Sat, 19 Sep 2020 16:02:04 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4Bv5n60n4hz55b; Sun, 20 Sep 2020 01:02:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1600556522; bh=+nuMOKvGCGiNCDNVJiEbpOerhT6AXC4+V5DQ35zGxr8=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=S3zQbstuo6qf/1NOHGGGZ8LHTTIHpU9hW0RnJAkecSb8ASI+06ZvaKMhRvdNS1eUS XTuFg3CJ6Cd9LFtrx6kYgJd3GvJn41PQRY+HgpmA2a0+VTBer8Cxgh/ePV83LVqGkM mN/3ljpBVnpgW1C9Jz5v8sVePyd1Bun0PiLmFOP8= 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 x0-IYQOhW-DW; Sun, 20 Sep 2020 01:02:00 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 20 Sep 2020 01:02:00 +0200 (CEST) Received: from [193.110.157.210] (unknown [193.110.157.210]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 78A3E6029BA2; Sat, 19 Sep 2020 19:01:59 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Paul Wouters Mime-Version: 1.0 (1.0) Date: Sat, 19 Sep 2020 19:01:54 -0400 Message-Id: <36CA437C-7F66-4603-9A36-0C5BB3A2FE05@nohats.ca> References: <20200919050934.GN89563@kduck.mit.edu> Cc: Valery Smyslov , mohamed.boucadair@orange.com, ipsec@ietf.org, draft-btw-add-ipsecme-ike@ietf.org In-Reply-To: <20200919050934.GN89563@kduck.mit.edu> To: Benjamin Kaduk X-Mailer: iPhone Mail (17H35) Archived-At: Subject: Re: [IPsec] TR: New Version Notification for draft-btw-add-ipsecme-ike-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: Sat, 19 Sep 2020 23:02:07 -0000 On Sep 19, 2020, at 01:09, Benjamin Kaduk wrote: >=20 > =EF=BB=BF > I would expect there to be some people pushing to have this be a capabilit= y > negotiation that honors the client's preference, not the server's; the > scenario you describe is one where the server's preference is used. > (To be fair, I'm not following ADD much at all, though, so I could be > wrong.) That is not how the CP payloads work. The initiator sends a set it is okay w= ith and the responder picks what it prefers from that set. Or an error if it= deems all of it bad. I would still prefer a single request for encrypted DNS and a reply with ser= vers with capabilities. Asking for all these different types will be more co= mplicated. Paul From nobody Mon Sep 21 01:38:57 2020 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 9A7823A0A94 for ; Mon, 21 Sep 2020 01:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=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 sEqZAqWNnQz9 for ; Mon, 21 Sep 2020 01:38:53 -0700 (PDT) Received: from smail.rz.tu-ilmenau.de (smail.rz.tu-ilmenau.de [141.24.186.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71AF13A0A83 for ; Mon, 21 Sep 2020 01:38:52 -0700 (PDT) Received: from olous.prakinf.tu-ilmenau.de (olous.prakinf.tu-ilmenau.de [141.24.212.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smail.rz.tu-ilmenau.de (Postfix) with ESMTPSA id 97E01580090; Mon, 21 Sep 2020 10:38:50 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_C9F983F8-DCBF-4621-8026-BD1D5F880095"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) From: Michael Rossberg In-Reply-To: <108017.1600467689@dooku> Date: Mon, 21 Sep 2020 10:38:49 +0200 Cc: ipsec@ietf.org Message-Id: References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> <47eb9242-4211-04ec-8bdf-96be54f2864d@sandelman.ca> <108017.1600467689@dooku> To: Michael Richardson X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [IPsec] Data Center changes to ESP, Re: leading versus trailing ICV 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, 21 Sep 2020 08:38:56 -0000 --Apple-Mail=_C9F983F8-DCBF-4621-8026-BD1D5F880095 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, >=20 >> I think that a way to negotiate this is as if it was unique cipher. >=20 > BTW: I recognize that this might require a new value for each cipher. >=20 > As such, it's not a great long term solution, but I would claim that = it > probably applies to a few ciphers very specifically at first. >=20 > Once the new layout is so popular, then we could persue some other way = to do > this. Probably that means the same Notify() mechanism we use for = TRANSPORT_MODE/etc. > I'm not especially fond of this architecturally, but it certainly = works. I guess this would be an option for our particular problem. = Nevertheless, I agree the inflationary use of IDs is a problem. Also, I see the possibility of confusion of the = readers, ie. having three AES-GCM modes. This would also reduce the number of interop tests, as we would have one = cipher that works a little different. In contrast of having an option for full 64-bit sequence = numbers, multiple replay windows, etc. and a combination of each. Hence, in a data center environment one = could simply use two code paths depending on the IKE negotiation. --Apple-Mail=_C9F983F8-DCBF-4621-8026-BD1D5F880095 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEE/ZtCXI3ladZ37VLCzADDFAM3dskFAl9oZpkACgkQzADDFAM3 dsli8BAAix01iKR4Ck2oEohGJXtbPEBomJV92/kJDWenNS1CHQ1T7mu3DWBUUiN5 1CRUoSNNeSBn0DMvulvRDXZUxyhRrsSHqoKoN99rq7JLwBfonXuyN8clOurp8CZj 1t8HCiGpyT5ho5PmQnR2Bk7Qg67+T2JvzzMytuVNhMYvO+xQVDLPVg2ULSXOSPPC i3QHw9deG9etuTXhAxVy76z/gUGX0C882j3N3J/4Vdfgh98OUyuXKr1u+15/NtFU YcdCM+SLQ9MUPc6c0c+kHGpvFVuLQsZqkfw4kysydT/s0X+XazesxlhxMCw4NWGJ x2qLWCRif0fmO/XYGbB8oQCnmCgszs4tb2iYjvyyYj10OpDorb24jbp9ZQww7wEz PvRnbq8iZvVxfSp+8oOl59WBCaU+758GTbdxDpXNAL/LvLCGcy9gIuoRHiG+4WCB +E7q+9nKw2pJ41MklxtnxNwz/UspW2dvQbn1G0B6cja0TFjsjEZlLOnh8PidPx6D ZjgWcHRMLQlfD4mzSfn/g7KRQCJYoVch5WwX1nYoRQq9RVJjkGsIYIeHrsveVz0T UMP5WgRhR2gdUsZ2R0lpTAm48wNSjgd5zAqJbAK/4I68uC9VACsiZ7ob/dbLGIvG 7ASPWS9OM+NEro+h/asrtIV+qxxLLTAWvQGNT3xN969XRIMMoec= =wQhC -----END PGP SIGNATURE----- --Apple-Mail=_C9F983F8-DCBF-4621-8026-BD1D5F880095-- From nobody Mon Sep 21 08:04:27 2020 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 4C7F13A0407 for ; Mon, 21 Sep 2020 08:04:25 -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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBl2xVzUtk7w for ; Mon, 21 Sep 2020 08:04:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4EC33A040F for ; Mon, 21 Sep 2020 08:04:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 54421389BA; Mon, 21 Sep 2020 10:42:31 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4bO6xHiEV9Tj; Mon, 21 Sep 2020 10:42:27 -0400 (EDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:103c:9eff:fecb:2eac]) by tuna.sandelman.ca (Postfix) with ESMTP id C4DFE389B7; Mon, 21 Sep 2020 10:42:26 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E5D6A721; Mon, 21 Sep 2020 11:03:47 -0400 (EDT) From: Michael Richardson To: Michael Rossberg cc: ipsec@ietf.org In-Reply-To: References: <5484040d-3b40-d94a-634e-c182c9165634@gmail.com> <47eb9242-4211-04ec-8bdf-96be54f2864d@sandelman.ca> <108017.1600467689@dooku> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Data Center changes to ESP, Re: leading versus trailing ICV 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, 21 Sep 2020 15:04:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Rossberg wrote: >>> I think that a way to negotiate this is as if it was unique cipher. >> >> BTW: I recognize that this might require a new value for each cipher. >> >> As such, it's not a great long term solution, but I would claim that= it >> probably applies to a few ciphers very specifically at first. >> >> Once the new layout is so popular, then we could persue some other w= ay to do >> this. Probably that means the same Notify() mechanism we use for TR= ANSPORT_MODE/etc. >> I'm not especially fond of this architecturally, but it certainly wo= rks. > I guess this would be an option for our particular > problem. Nevertheless, I agree the inflationary use of IDs is a > problem. Also, I see the possibility of confusion of the readers, > ie. having three AES-GCM modes. I don't think that the reader will be confused. > This would also reduce the number of interop tests, as we would have > one cipher that works a little different. Yes, and likely implemented in a non-modular streamlined (or data pipelined) way in hardware. Hardware is not going to have more than two ciphers. If as many as two. Again, I suggest you write an Informational document, as for a code point, and submit through ISE. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9owNMACgkQgItw+93Q 3WXTAwgAq2v6KhvSsnkjHhvxrtE64R6Ipa0iQPSMq/FIxpIldDQnlVwoHdelDfi8 fYWpQ2oPXk4MnO1VzareB4HqxuyyYbFdZRDdVsigczqEwvDARWhZU0a4roK6oTCN ODlMbag0TvseV1L2HQiPMcjUikIRbz+TgOG9esUt0cbEAEOOeyiJlyXl3/emPb2t FVAShsCP0edMbcEjhmAVP8jqdK+9YSf5scUNnZ/Ku8qtT+VntSjKu6GVBdxQA7oM wjIiiM6/50bbpcZTx6drd0mpY4zsWrNO1pPxsA+7TmDc12zZ+0ZD42y7gJKkI9Hx 56ibg7ryz3Q+pYy/r7PqeDB6KXeoNQ== =aZEj -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 21 22:19:01 2020 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 5E2543A1400; Mon, 21 Sep 2020 22:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=upct.onmicrosoft.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 e4YMZ6ybHBYY; Mon, 21 Sep 2020 22:18:47 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20059.outbound.protection.outlook.com [40.107.2.59]) (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 A42683A139A; Mon, 21 Sep 2020 22:18:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I9BKuUQf3In5TL1DTyhU0FFSQimZQZ0i2os6EBfmDRqB6iAYMA7/8Z4Di78HM23cK5py5z0+130nuDceLy6hti9kfrMpear6bbTlfD0JJ2K4GRDTV8nfyEh3lG9wB8S3+7mJDzBRSyoCmS6LBmso5/II/CHPlm2np1W9nLNKXxOiN3mNTt4gyg4cK87HMNCRqqzC0jQ8sKVb1GqS4yHgCyiufp4INn9dzGtkEtfv9EATbeXIeQPwbmqWm0YKoJpkarWX8rBVU1xEPGDZdx3NFhzFGDie6O9JcVOlxlkLrzqlD6urer+XRz+ZwR5Si8PUrppTr6xVBtSVbczMly9C5w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=073fq2fukmQxseTNiAYtnxsd6ejQf0XOo42KLYvEBbU=; b=P+8FPa55Gn8dJXhw+vhvEARJNfQao4fVUof4MTV5JEmkz6/OhIcQV5TsGgGyglhZubQptFtzTeVYHIAyAxCFKeEsGFdRY7EiZR4QJ/Y1Q//Uca0xn8Sfcac3q2jc7WCm+wvYgCmHU6gk/5k3BZCQW5RBhwbjfS2EYrY9aoZ4PZkhsl+EleN2Js46tZJt5u54KoA1o3gNT+efp2I8UsmRiNRnx3R1+ZF+FVK05hwIXOOdGuYzMtVK+xMOQ570tLl8vl4wDzltLSdNz9pu8WFiG50ixMpJZKj7Gx5YqjtatK/1SHXDpKy72qLmaGowi8SdkOOn4MAh8cckKMOjMmjBXA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cud.upct.es; dmarc=pass action=none header.from=cud.upct.es; dkim=pass header.d=cud.upct.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UPCT.onmicrosoft.com; s=selector2-UPCT-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=073fq2fukmQxseTNiAYtnxsd6ejQf0XOo42KLYvEBbU=; b=PLsHx4XpgYqsyqwTHRRRv1d9L5eNJqkwZEE8SQEq6qljxjf+V6u1C0xQRRP28kBNe9Hgz+PJ/kxW2+wve1Jzdgdtp6Zh5SX/XvOTWnteTB12Yyubc3v54FrJGvSt6+0Kgif/O14mt80aj8rqkheahlvHNL58h9DveIfzbP1hA6I= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cud.upct.es; Received: from AM6PR08MB4936.eurprd08.prod.outlook.com (2603:10a6:20b:eb::14) by AM7PR08MB5319.eurprd08.prod.outlook.com (2603:10a6:20b:dc::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.15; Tue, 22 Sep 2020 05:18:39 +0000 Received: from AM6PR08MB4936.eurprd08.prod.outlook.com ([fe80::ed14:ea08:3412:88eb]) by AM6PR08MB4936.eurprd08.prod.outlook.com ([fe80::ed14:ea08:3412:88eb%6]) with mapi id 15.20.3391.024; Tue, 22 Sep 2020 05:18:38 +0000 X-Gm-Message-State: AOAM533l2BQzIZAeM5EMpyN/ESL2741jverzGIQvpn28UnGiqFuSCXVL UiJij/UocsWvptjHVytPLNDeKa9LhK1tpUMd2/s= X-Google-Smtp-Source: ABdhPJzGfgWxs4N1UcionYJ1qPg7ndtyesSI5EhM4WOSUF6SmPo8YYayiFzv2Ic1VsL/xgHm5KIRDVsNH1NXvfFY/uY= X-Received: by 2002:a05:6402:17b1:: with SMTP id j17mr1791713edy.253.1600751915509; Mon, 21 Sep 2020 22:18:35 -0700 (PDT) References: <5F44E66D.6080408@btconnect.com> In-Reply-To: <5F44E66D.6080408@btconnect.com> From: =?UTF-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= Date: Tue, 22 Sep 2020 07:17:00 +0200 X-Gmail-Original-Message-ID: Message-ID: To: tom petch Cc: LAST-CALL@ietf.org, i2nsf@ietf.org, Roman Danyliw , draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org, i2nsf-chairs@ietf.org, "ipsec@ietf.org WG" Content-Type: multipart/alternative; boundary="0000000000004c302605afe01947" X-ClientProxiedBy: AM0P190CA0030.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::40) To AM6PR08MB4936.eurprd08.prod.outlook.com (2603:10a6:20b:eb::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mail-ed1-f47.google.com (209.85.208.47) by AM0P190CA0030.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:190::40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14 via Frontend Transport; Tue, 22 Sep 2020 05:18:38 +0000 Received: by mail-ed1-f47.google.com with SMTP id n13so14901524edo.10; Mon, 21 Sep 2020 22:18:38 -0700 (PDT) X-Gm-Message-State: AOAM533l2BQzIZAeM5EMpyN/ESL2741jverzGIQvpn28UnGiqFuSCXVL UiJij/UocsWvptjHVytPLNDeKa9LhK1tpUMd2/s= X-Google-Smtp-Source: ABdhPJzGfgWxs4N1UcionYJ1qPg7ndtyesSI5EhM4WOSUF6SmPo8YYayiFzv2Ic1VsL/xgHm5KIRDVsNH1NXvfFY/uY= X-Received: by 2002:a05:6402:17b1:: with SMTP id j17mr1791713edy.253.1600751915509; Mon, 21 Sep 2020 22:18:35 -0700 (PDT) X-Gmail-Original-Message-ID: X-Originating-IP: [209.85.208.47] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9f8bbb57-6149-4466-2fb9-08d85eb6f635 X-MS-TrafficTypeDiagnostic: AM7PR08MB5319: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:989; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EfZ/OymFUF2/zbvuuj2X/4EFOscTXv8YkSTQOAgjyVVVqrtdLgguHB9je8SppiKCoooOATHcoDWlX/NfT62PtUmpjQm2F3+hmCHvXMBL2ETk95AjkdkTHVrreNP3Q/MxtEASg05NALWYBddHdrfe9tdDsJ1eZqXNolJ2x4OjpeoyRYNaWe//+rRL4xNh0dwoPkU2/jqjXpmf/Up/4VV2O/LXzWGtYFl/J1e83b6VQTLBXK9qLPfWD3upaASFw9f7Qxs7kdLf91X6U1K1DzVFlF8MzlVb0ZLoOGmf388KSjy4DIHaG9upe4wMZJFu4r0vqzJaSdvVmdrAyyYHdRg2DQmGg6/bVqB0AzjfBHiPchalR9XGT1CahT06BfoXkrNpjLn90+Xvh4etMZ9AbrOUHA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4936.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(39840400004)(366004)(376002)(346002)(396003)(136003)(85182001)(66946007)(6862004)(55446002)(8676002)(86362001)(33964004)(26005)(66556008)(186003)(6666004)(52116002)(5660300002)(450100002)(83380400001)(54906003)(9686003)(316002)(66574015)(66476007)(2906002)(42186006)(8936002)(478600001)(85202003)(966005)(166002)(4326008)(786003)(30864003); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: XqN5T3M4SOa7v6+uZginCJKNYW1ljXF4kxUZ139L8mjMzkD3ZO7heAogYvnlvlo3cI6nUhciGxj2K+g1RHMHF1fQ2K4o0Js7r1UpIOLc4S1w4DRmJMDyzuJ2tCPwofZ5glL4v2u552C/026uHJDPSyIQs/7oNglp++J5odkMiwDzTy6djaApkM3QMjVyvapkUy1IhDvBnnTPa/prxLEnXtY/bhISGGjgQJzmQht9I/SCltNPNMKbbmP6xX1w4hXWJ/1w0nG5psvPmv3wN4Z/T/YPwGuG+Avenu17dOtJQHhNiZdwT05e4JrGdYc0/fa42PnIwHjoz7rmfsiT2ADI3OKbfiGmX+CY7NZhP0L/7aPpLW1E66emJW4esXA6TKmobotvUM/3PbA7Nr1VWmxQqxNvW6wBPMqhVMH3OQt8dZd/p0uqxHELLUwwu9ESKEVymKzkt1goqAd7WSMuiJrcmy9Qmap3gTl3NBkaEqNsvj9q7P/+w7OE4F3s+Mul0cHsFptejk1D/TlnxQVcZdKSKGE11l8dQr45WHxKUSD5aTEQq9sBh048r5mgPwhj51dyYDQ/p9fNU/nL9M5KVkomomUQZmuHlD4VZu5RC6AB5He5/2aXnEst7oWTruUEZMQ3xKjjPGwUfhQ0aqdHMOmuig== X-OriginatorOrg: cud.upct.es X-MS-Exchange-CrossTenant-Network-Message-Id: 9f8bbb57-6149-4466-2fb9-08d85eb6f635 X-MS-Exchange-CrossTenant-AuthSource: AM6PR08MB4936.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2020 05:18:38.7430 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 967e1b81-5cf6-4b03-bb60-d71bf48069f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: pm27Sxq6zZAgYhemUByrhGKhNNp5ym+8YP5xL8sglUkF+XE6/XdYokl+KgiP+q1fnAE7p2yaVc+trSgQYzG+DG9maUxmYQFb7WuF2yc0a4c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5319 Archived-At: Subject: Re: [IPsec] Last Call: (Software-Defined Networking (SDN)-based IPsec Flow Protection) to Proposed Standard 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, 22 Sep 2020 05:18:59 -0000 --0000000000004c302605afe01947 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for your feedback and help. We are working to address your comments in the next version of the draft (v09). Please, see our answers below, identified with the tag "[Authors]". El mar., 25 ago. 2020 a las 12:23, tom petch () escribi=C3=B3: > Looking at the YANG module from a different perspective from that of a > YANG Doctor or a IPsec WG Chair, there is quite a lot of editing needed. > > '2019' appears 10 times and I suspect most should be 2020; one is an > import by revision which is uncommon because of potential, future, > compatibility problems. > > *[Authors]* Fixed. The import by revision has been removed. > Conventionally, Appendices are Informative and YANG modules are > Normative so if you want the modules to be Normative,I suggest adding to > Appendices A, B, C > 'This Appendix is Normative.' > > *[Authors]* Added this text to clarify the normative nature of Appendices. > YANG is version 1.1 so RFC7950 is required. I suggest adding [RFC7950] > to YANG in the Introduction. *[Authors]* Added RFC7950 and a brief text clarifying we are using YANG 1.1= . > For IANA considerations, RFC6020 is the > better reference. > *[Authors] *We do not understand this comment. The IANA considerations section has been written following the guidelines provided in RFC 8407 (section 3.8). Consequently, the current text references RFC 6020 when registering the YANG modules names. The current IANA review state is "IANA OK - Actions Needed", meaning that the IANA Considerations section indicates the details of the actions correctly. > > NMDA[RFC8342] conformance should be stated as appropriate > > *[Authors]* Clarification added in the introduction. > YANG'import' need a reference; I see five without > *[Authors]* Fixed. > > Tree Diagrams need explaining - RFC8340 does that > *[Authors]* We will include new text at the end of sections 6.1 and 6.2, explaining the type of information and how it is structured for each module. > > 'revision' should be 'Initial version' at this stage with a reference to > this I-D's title > *[Authors] *Fixed. > > Lots of references - good - but they need to appear in the I-D > References, mostly, probably, Normative. I see no I-D Reference for > 822 - ood 2821? > 2247 - > 3280 - ood 5280? > 3947 - > 4303 - > 5280 - > 5915 - > 7383 - > 7427 - > 7619 - > 8017 - > 8174 - > 8221 - > > X.690 > > I-D Common YANG Data Types for Cryptography > > IANA Registry Internet Key Exchange Version 2 Parameters > IANA Registry- Transform Type 1 > IANA Registry- Transform Type 3 > IANA Registry Protocol Numbers > > *[Authors] *Thanks for pointing out this. We have thoroughly revised all yang data models to identify missing references. > and they will each need a reference from the body of the I-D such as > 'The YANG modules make reference to [RFC2247], .... > > *[Authors]* At the beginning of Appendix A, B and C, we have included a citation to the normative and informative references. > I note that RFC822 and RFC3280 are Obsoleted which makes their use > problematic. > > *[Authors]* Following your recommendation, we have replaced RFC 3280 with RFC 5280. Regarding RFC 822, we reference it because the IKEv2 protocol specification (RFC 7296) explicitly defines RFC 822 emails address (see page 90) as a valid identification type. If we replace RFC 822 with RFC 2821, we don't know its impact on IKEv2. > s.8.3 > /The YANG module/The YANG modules/ > > *[Authors]* Fixed. > IANA Considerations > The Registrant contact is usually the IESG > *[Authors] *Ok, updated. > > The prefix registered for ipsec-common is not the same as appears in > Appendix A > *[Authors]* Fixed. Now the prefix registered in the declaration of module ietf-ipsec-common is "ic". > > For the Web address, it is unusual to have '/about' > > *[Authors]* Fixed. > grouping port-range > with a range, it is usual to specify how a single address is specified, > e.g. the absence of 'end' or 'start'=3D'end' and for a YANG must to > require end>start or end>=3Dstart as appropriate. The use of key 'start > end' implies that 'start' and 'end' must both be present. > > *[Authors]* Thanks for your comment. We have updated the description associated to "leaf end" with the following text: *End port number. The assigned value must be equal or greater than the start port number. To express a single port, set the same value as start and end.* > > Tom Petch > Best regards, Fernando. > > The IESG has received a request from the Interface to Network Security > Functions WG (i2nsf) to consider the following document: - > 'Software-Defined > Networking (SDN)-based IPsec Flow Protection' > as Proposed Standa= rd > > The IESG plans to make a decision in the next few weeks, and solicits fin= al > comments on this action. Please send substantive comments to the > last-call@ietf.org mailing lists by 2020-09-04. Exceptionally, comments > may > be sent to iesg@ietf.org instead. In either case, please retain the > beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document describes how to provide IPsec-based flow protection > (integrity and confidentiality) by means of an I2NSF Controller. It > considers two main well-known scenarios in IPsec: (i) gateway-to- > gateway and (ii) host-to-host. The service described in this > document allows the configuration and monitoring of IPsec information > from a I2NSF Controller to one or several flow-based Network Security > Function (NSF) that implement IPsec to protect data traffic. > > The document focuses on the I2NSF NSF-Facing Interface by providing > YANG data models for configuration and state data required to allow > the I2NSF Controller to configure the IPsec databases (SPD, SAD, PAD) > and IKEv2 to establish IPsec Security Associations with a reduced > intervention of the network administrator. > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protecti= on/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce > --=20 ---------------------------------------------------------------------------= ------------------------- Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa, PhD Department of Sciences and Informatics University Defense Center, (CUD), Spanish Air Force Academy, MDE-UPCT C/ Coronel Lopez Pe=C3=B1a, s/n, 30720, San Javier, Murcia - SPAIN Tel: +34 968 189 946 Fax: +34 968 189 970 ---------------------------------------------------------------------------= --------------------------- --0000000000004c302605afe01947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

Thanks for your feedba= ck and help. We are working to address your comments in the next version of= the draft (v09).
Please, see our answers below, identified w= ith the tag  "[Authors]".

El mar., 25 ago. 2020 a las 12:= 23, tom petch (<daedulus@btconnect.com>) escribi=C3=B3:
Looking at the YANG module from a differ= ent perspective from that of a
YANG Doctor or a IPsec WG Chair, there is quite a lot of editing needed.
'2019' appears 10 times and I suspect most should be 2020; one is an
import by revision which is uncommon because of potential, future,
compatibility problems.

 
[Authors] Fixed. The import b= y revision has been removed. 
 
Conventionally, Appendices are Informative and YANG modules are
Normative so if you want the modules to be Normative,I suggest adding to Appendices A, B, C
'This Appendix is Normative.'


[Authors] Added this text to cl= arify the normative nature of Appendices.
 
YANG is version 1.1 so RFC7950 is required.  I suggest adding [RFC7950= ]
to YANG in the Introduction. 

[Auth= ors] Added RFC7950 and a brief text clarifying we are using YANG 1.1.
 
= For IANA considerations, RFC6020 is the
better reference.

[Authors] We d= o not understand this comment. The IANA considerations section has been wri= tten following the guidelines provided in RFC 8407 (section 3.8). Consequen= tly, the current text references RFC 6020 when registering the YANG modules= names. The current IANA review state is "IANA OK - Actions Neede= d", meaning that the IANA Considerations section indicates the de= tails of the actions correctly.
 

NMDA[RFC8342] conformance should be stated as appropriate


[Authors] Clarification added i= n the introduction.
 
YANG'import' need a reference; I see five without

=
[Authors] Fixed.
 

Tree Diagrams need explaining - RFC8340 does that

=
[Authors] We will include new text at the end of sections= 6.1 and 6.2, explaining the type of information and how it is structured f= or each module. 
 

'revision' should be 'Initial version' at this stage with a reference to this I-D's title

[Authors] Fixed= .
 

Lots of references - good - but they need to appear in the I-D
References, mostly, probably, Normative.  I see no I-D Reference for 822 - ood 2821?
2247 -
3280 - ood 5280?
3947 -
4303 -
5280 -
5915 -
7383 -
7427 -
7619 -
8017 -
8174 -
8221 -

X.690

I-D Common YANG Data Types for Cryptography

IANA Registry Internet Key Exchange Version 2 Parameters
IANA Registry- Transform Type 1
IANA Registry- Transform Type 3
IANA Registry Protocol Numbers


[Authors] Thanks for pointing o= ut this. We have thoroughly revised all yang data models to identify missin= g references.
 
and they will each need a reference from the body of the I-D such as
'The YANG modules make reference to [RFC2247], ....


[Authors] At the beginning= of Appendix A, B and C, we have included a citation to the normative and i= nformative references.
 
I note that RFC822 and RFC3280 are Obsoleted which makes their use
problematic.


[Authors]  Following your = recommendation, we have replaced RFC 3280 with RFC 5280. Regarding RFC 822,= we reference it because the IKEv2 protocol specification (RFC 7296) explic= itly defines RFC 822 emails address (see page 90) as a valid identification= type. If we replace RFC 822 with RFC 2821, we don't know its impact on IKE= v2. 
 
s.8.3
/The YANG module/The YANG modules/

 
[Authors] Fixed.
 
IANA Considerations
The Registrant contact is usually the IESG

<= div>[Authors] Ok, updated.
 

The prefix registered for ipsec-common is not the same as appears in
Appendix A

[Authors] Fixed.= Now the prefix registered in the declaration of module ietf-ipsec-common i= s "ic".
 

For the Web address, it is unusual to have '/about'


[Authors] Fixed. 
 
grouping port-range
with a range, it is usual to specify how a single address is specified, e.g. the absence of 'end' or 'start'=3D'end' and for a YANG must to
require end>start or end>=3Dstart as appropriate.  The use of ke= y 'start
end' implies that 'start' and 'end' must both be present.


[Authors] Thanks for your comme= nt. We have updated the description associated to "leaf end"= with the following text:             &n= bsp;        

    &nb= sp;                End port numb= er. The assigned value must be
           = ;          equal or greater than the start port nu= mber.
                  &n= bsp;  To express a single port, set the same value
    &n= bsp;                as start and en= d.
 

Tom Petch

Best regards,
Ferna= ndo.
 
last-call@ietf.org<= /a> mailing lists by 2020-09-04. Exceptionally, comments may
be sent to iesg@ietf.org= instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.

Abstract


    This document describes how to provide IPsec-based flow prote= ction
    (integrity and confidentiality) by means of an I2NSF Controll= er.  It
    considers two main well-known scenarios in IPsec: (i) gateway= -to-
    gateway and (ii) host-to-host.  The service described in= this
    document allows the configuration and monitoring of IPsec inf= ormation
    from a I2NSF Controller to one or several flow-based Network = Security
    Function (NSF) that implement IPsec to protect data traffic.<= br>
    The document focuses on the I2NSF NSF-Facing Interface by pro= viding
    YANG data models for configuration and state data required to= allow
    the I2NSF Controller to configure the IPsec databases (SPD, S= AD, PAD)
    and IKEv2 to establish IPsec Security Associations with a red= uced
    intervention of the network administrator.




The file can be obtained via
https://datatracker.ietf= .org/doc/draft-ietf-i2nsf-sdn-ipsec-flow-protection/



No IPR declarations have been submitted directly on this I-D.





_______________________________________________
IETF-Announce mailing list
IETF-Announce@i= etf.org
https://www.ietf.org/mailman/listinfo/ietf-announ= ce


--
= ----= ---------------------------------------------------------------------------= ---------------------
Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa, PhD
Departm= ent of Sciences and Informatics
University Defense Center, (CUD), Spanis= h Air Force Academy, MDE-UPCT
C/ Coronel Lopez Pe=C3=B1a, s/n, 30720, Sa= n Javier, Murcia - SPAIN
Tel: +34 968 189 946 Fax: +34 968 189 970
--= ---------------------------------------------------------------------------= -------------------------
<= /div>
--0000000000004c302605afe01947-- From nobody Tue Sep 22 04:56:40 2020 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 D981F3A1654; Tue, 22 Sep 2020 04:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TYkOQ8u2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RV7i9K7z 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 VhfOuQ5zfKSp; Tue, 22 Sep 2020 04:56:36 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C09663A1653; Tue, 22 Sep 2020 04:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5724; q=dns/txt; s=iport; t=1600775795; x=1601985395; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LC3Iqwt02axlnvoeNescTpwMZ3/WOlea9tZ6zAuqzL8=; b=TYkOQ8u2iaG6BWBh/HR3gEDMIQKLIS1kVdhHthWZOjQ7Fymv8CqufRPQ EqsjRRiSXn8pJfTZwOCpmGy8LScR5KgD2kimJ2DsjmA1asiR1iETeiX9i DwyKiDYJPj5jUJac7uew7qiGR78N609wuG8BJdhm7Lzrxxpa8AyGtGpcF w=; IronPort-PHdr: =?us-ascii?q?9a23=3Am7JO2hKpz5sUu+/sm9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvKs/h1/ORZ3ArfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBteGMHmf0aUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvCAAv5Wlf/4ENJK1fHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFPgVJRB3BZLywKhDCDRgONeph1glMDVQsBAQENAQEYCwoCBAEBhEs?= =?us-ascii?q?CF4IOAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDAQEQEREMAQEsCwE?= =?us-ascii?q?LBAIBCA4DBAEBAQICFQEBDwICAiULFQgIAgQBDQUIEweDBYJLAy4BAwuqCgK?= =?us-ascii?q?BOYhhdoEygwEBAQWFLhiCEAMGgQ4qgnGDaYJBhBEbgUE/gRFDgU9+PoJcAQG?= =?us-ascii?q?BYQUzIQSCODOCCyKTNaQACoJnlUqFJoMMiXmTfpJ+n3wCBAIEBQIOAQEFgWs?= =?us-ascii?q?jgVdwFTuCaVAXAg2OHwwXFIM6hRSFQnQ3AgYBCQEBAwl8jFIBgRABAQ?= X-IronPort-AV: E=Sophos;i="5.77,290,1596499200"; d="scan'208";a="830316616" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Sep 2020 11:56:34 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 08MBuYak010523 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Sep 2020 11:56:34 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Sep 2020 06:56:34 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Sep 2020 06:56:33 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 22 Sep 2020 06:56:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZbwOmkMHCchmqJWE1PbBf8B2hrZvjA3za6kYvBMKZksPaS6ccpZFHa5ikcZw9QLU5+Wg5HQrglm16oGDET/d7YFUb7TbqAuhX3vjes/zDuc1oo2w+lim28Y0DXGCiAE8rdec0jpPJ0dMki3bksQt/1LwCsLfKZhlTvweMzhjt/aMKiakHP+be8j9vFxeyarxSIgEtjVjzeiEUTZNqQJCf4sxophChlYTze+pcRjcaWq5/iq9fn8TGJwyvfDwcMGM3Z0LCWS5pOPu9CAQCYFDv/3M6352ibmZv16LPVNQXeqxytKSJWA9cpqbkBAAVKfxEyAuKt7OSMab0ITUDo26Lg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LC3Iqwt02axlnvoeNescTpwMZ3/WOlea9tZ6zAuqzL8=; b=nBw4ZkG1Stbz7ulNJFtWyVITs4cWaRCJRSP4KCJEzIZGwLn5o44e3fYn5Fk+ODyhXSIBb4PPz+WlFj+dt2IVbUTcdL08MFaMmR/WjuJHN545ZuwTedty1yW0E+oFfJAWmxuZN7ReUd8NcG41+xgBCOrGFwBG+VaP3qmkiTqkU+xBq1lnJlLyrySM3wwL0P5oZ3sqE2czyPSfvTl8qQ1cDUs1yLHHYspRjMGPKHhK8bN5B7JcIz7mRBQZMqLaQDmaoIiKsRU4Ttal29MBtnSWIR8i2pYAFt18Uc4uwF8rmM8dvprv7uySGkkcOtH03lVHYlMX8AzxlGhLkqpJHqeq6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LC3Iqwt02axlnvoeNescTpwMZ3/WOlea9tZ6zAuqzL8=; b=RV7i9K7zDQe9CLBXtNhP10Sa+fb0QgMFgv51Ph9KzMjFa7CTeGtgFjwWcuUeR8O8Wgcp+aDUvRajEaD1MP4GmpbKdRVp4W7geZStovQEHBPQDlBSHSJwtJZBEESeLFu+HjRbpP9LRwUEFk4lhr1Ei8dqd2bIKtI6EVlFKyG1Ky4= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4221.namprd11.prod.outlook.com (2603:10b6:208:18d::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Tue, 22 Sep 2020 11:56:32 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3391.026; Tue, 22 Sep 2020 11:56:32 +0000 From: "Rob Wilton (rwilton)" To: Christian Hopps , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" CC: "i2nsf@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , "yang-doctors@ietf.org" , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= Thread-Topic: [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 Thread-Index: AQHWeiQ1OzamIxEUgUCW76UP8U3vNKlHffqAgC01gyA= Date: Tue, 22 Sep 2020 11:56:32 +0000 Message-ID: References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chopps.org; dkim=none (message not signed) header.d=none;chopps.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e57dc6cc-58fc-413f-5727-08d85eee8c7e x-ms-traffictypediagnostic: MN2PR11MB4221: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Gl5hjkGdkmLz6hywrNrBd44uVcP/c96x0GtEB8tF2HAtUisYHhCB59qkQJ4KgEmJNsS1UnMcKFF50NTnAbtUyAqQWbl521w6bsuIF+rd2mXE7K78Smq+focxuhuR/fQVtcxFXBLwdmlQsCxMZd0bZS0l0bK83Yst4ztjdHSVuZwicIQIVG+OU4tL4OWdfxJYfj0S0x0evwulmnswyTLtgI6vbIH9lg7Fu0AF1nvcl0HuejFWhGZEOQXB1QF5vCoTFoPWExRZ8wsEOet/bD4Ta8Iw0igAUYLzcIFdcYMq3It/ni3guwlf0+j4oldgQJYiyHuuEpzvAu5T3Kq5ikz68dJLCa6tymV9maWuHJb/Y5jLs8172z1chYgMpsFq00VDfOEXie6TEstpYDAISf+7pA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(39860400002)(396003)(376002)(346002)(86362001)(7696005)(53546011)(8936002)(76116006)(6506007)(33656002)(66574015)(5660300002)(478600001)(2906002)(83380400001)(110136005)(54906003)(26005)(8676002)(4326008)(66446008)(9686003)(52536014)(316002)(186003)(966005)(71200400001)(66946007)(66476007)(55016002)(64756008)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: j5XD2EqYV+nMzgN7E20LrXu/1Tban0sZf+M1X8h/9WRsC3EpGpqwik4WJynbpdR9YThjmRu4yuQJn1e9JFAdDWJebKh3E6o/nmk0F1kYRKnfwU0NNQxjPrGA8i+9ya3qaUjUd8IFdOp9hrcjvaoBHbmJhuiPVv0zo+70RnKorDJU0GaQvu+VIzaZJxYqblOKeJgfN5mo3cUToMC9qoYD4vGAytAO45AlPWhi0SkzeZX4Loz1hsOdsHsjhQvVC5oWe41Tmm4zbK7OkEZw1Aq0PqZH4wbxb367VRl28zPhCNrWDZsfbGYFSnaUD73HmQJ2JQ46i8uUCnB4qyM9bGN9LfEdJ640rbdUkuNHJ9mSg0DTmWEpipO2zKXsZv8a6kOBZsMrGzp3MxjkJtpcln0Lpcd6AeYTLak0yv50d/iFuvMta7lzcZKWmr9/QsZ4Lu9KVEI58JhKYFZbE6YmGCzHjsQZ4a5kMaZBpcOWkwIj9nCh9OZhFhtdah3h6EnGbWeI+oCY0tjmwwkyv3U+YChmU4MSreBMploP7SEhtkjCgaD8pBDiPtVEtgVyzXx7NIsWaXZ2Sqt0bJw1tnbgjfCE3xzz9lHEsJPuXR3s70hp5XcXoPVOOaB7vqb5vdJnaUiWwPKozPGT8auZnNLeeAhhiA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e57dc6cc-58fc-413f-5727-08d85eee8c7e X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2020 11:56:32.2274 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jsaz9IxpvPAtQusd0hU9AB9scCFQwhsRw9OWF19SxI5e30Ync6vAmqGaiBq585CAWcUwYxr3H/1eDi05QsJlMA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4221 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [IPsec] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 22 Sep 2020 11:56:38 -0000 SGkgZHJhZnQgYXV0aG9ycywgQ2hyaXMsDQoNCkNhbiB3ZSBhbHNvIHBsZWFzZSB0cnkgYW5kIGNs b3NlIG9uIHRoaXMgaXNzdWUgcmFpc2VkIGJ5IENocmlzLg0KDQpDaHJpcywgSSBkb27igJl0IHRo aW5rIHRoYXQgdGhlcmUgaXMgYW55IGdyZWF0IHdheSB0byBzb2x2ZSB0aGlzIGlzc3VlIHVzaW5n IFlBTkcgZmVhdHVyZXMsIGJ1dCBwcmVzdW1hYmx5IHRoZSBjb25zdHJhaW50IGNvdWxkIGJlIGVu Zm9yY2VkIHdpdGggYSBtdXN0IHN0YXRlbWVudCwgb3IgZ3JvdXBpbmdzIGNvdWxkIGJlIHVzZWQg dG8gY29weSBwYXJ0cyBvZiB0aGUgaXBzZWMgc3RydWN0dXJlIGludG8gYW4gc2RuIHNwZWNpZmlj IGlwc2VjIHRyZWUgc3RydWN0dXJlLg0KDQpJIHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBpc24ndCBh bnkgZ3JlYXQgZGVzaXJlIHRvIGRlbGF5IHRoZXNlIGRyYWZ0cyBieSB0cnlpbmcgdG8gZ2VuZXJh bGl6ZSB0aGUgaXBzZWMgWUFORyBtb2RlbCBjb250YWluZWQgd2l0aGluIGl0LiAgSG93ZXZlciwg SSB0aGluayB0aGF0IG1lYW5zIHRoYXQgdGhlIG1vZHVsZXMgc2hvdWxkIGhhdmUgIi1zZG4tIiBp biB0aGVpciBuYW1lcyB0byBpbmRpY2F0ZSB0aGF0IHRoZXkgYXJlIGludGVuZGVkIHNwZWNpZmlj YWxseSBmb3IgdGhlIFNETiB1c2UgY2FzZSwgYW5kIHNob3VsZCBub3QgYmUgY29uZnVzZWQgd2l0 aCB0aGUgbW9yZSBnZW5lcmljIGlwc2VjIFlBTkcgbW9kdWxlcyB0aGF0IGhhdmUgYmVlbiBwcm9w b3NlZC4NCg0KUmVnYXJkcywNClJvYg0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogeWFuZy1kb2N0b3JzIDx5YW5nLWRvY3RvcnMtYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIENocmlzdGlhbg0KPiBIb3Bwcw0KPiBTZW50OiAyNCBBdWd1c3QgMjAyMCAxODow OA0KPiBUbzogTWFydGluIEJqw7Zya2x1bmQgPG1iaitpZXRmQDQ2Njguc2U+DQo+IENjOiBpMm5z ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy0NCj4gcHJvdGVjdGlv bi5hbGxAaWV0Zi5vcmc7IGlwc2VjQGlldGYub3JnOyBsYXN0LWNhbGxAaWV0Zi5vcmc7IHlhbmct DQo+IGRvY3RvcnNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt5YW5nLWRvY3RvcnNdIFlhbmdk b2N0b3JzIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi0NCj4gaTJuc2Ytc2RuLWlwc2Vj LWZsb3ctcHJvdGVjdGlvbi0wOA0KPiANCj4gW2FkZGluZyBpbiBpcHNlY0BdDQo+IA0KPiBIaSwN Cj4gDQo+IFRoaXMgZHJhZnQgd2FzIGRpc2N1c3NlZCBpbiBpcHNlY21lIGF0IHRoZSBsYXN0IElF VEYsIGFuZCB0aGVyZSB3YXMgYQ0KPiBkZXNpcmUgdG8gbG9vayBjbG9zZXIgYXQgYSBjb3VwbGUg Y2hhbmdlcyB0aGF0IHdvdWxkIG1ha2UgdGhlc2UgbW9kZWxzDQo+IHVzYWJsZSBieSBpcHNlYyBn ZW5lcmFsbHkgcmF0aGVyIHRoYW4gb25seSBmb3IgU0ROcy4gT3RoZXJ3aXNlIHdlIHdpbGwgZW5k DQo+IHVwIHdpdGggMiBtb2RlbHMgdGhhdCBsb29rIHZlcnkgc2ltaWxhciBhbmQgZHVwbGljYXRl IGFsbW9zdCBhbGwgdGhlDQo+IGZ1bmN0aW9uYWxpdHkuIFRoaXMgd2FzIGdvaW5nIHRvIGJlIGRv bmUgZHVyaW5nIHRoZSBuZXh0IHlhbmcgZG9jdG9yDQo+IHJldmlldywgYnV0IGl0IGxvb2tzIGxp a2UgdGhhdCBoYXBwZW5lZCBpbiB0aGUgbWVhbnRpbWUgKHNoaXBzIGluIHRoZQ0KPiBuaWdodCku DQo+IA0KPiBBdCBtaW5pbXVtIHRoZSBtb2R1bGUgbmFtZXMgc2hvdWxkIGluY2x1ZGUgIi1zZG4t IiBpZiBubyBvdGhlciBjaGFuZ2VzIGFyZQ0KPiBtYWRlIHRvIGluZGljYXRlIHRoYXQgdGhleSBh cmUgb25seSBmb3Igc2RuIHVzZTsgaG93ZXZlciwgdGhpcyBpcyBub3QgdGhlDQo+IG9wdGltYWwg c29sdXRpb24uDQo+IA0KPiBBIGJldHRlciBzb2x1dGlvbiB3b3VsZCBiZSB0byBtb3ZlIHRoZSBj b250YWluZXJzIGN1cnJlbnRseSB1bmRlciBpa2VsZXNzDQo+IChmb3IgU0EgYW5kIFBvbGljeSBk YXRhYmFzZXMpIHVuZGVyIGlwc2VjLWNvbW1vbi4NCj4gDQo+IFRoZSBmZWVkYmFjayBJIHJlY2Vp dmVkIGZyb20gdGhlIGF1dGhvcnMgd2FzIHRoYXQgdGhlIFNETiBjb250cm9sbGVycw0KPiBkaWRu J3QgY2FyZSBhYm91dCB0aGUgYWN0dWFsIFNBcyBhbmQgcG9saWNpZXMgd2hlbiB1c2luZyBJS0Ug c28gdGhleQ0KPiBkaWRuJ3Qgd2FudCB0byByZXF1aXJlIHNvbWVvbmUgaW1wbGVtZW50aW5nIGlr ZStjb21tb24gbW9kdWxlcyB0byBoYXZlIHRvDQo+IHN1cHBvcnQgdGhlbS4NCj4gDQo+IFRoZSBZ QU5HIHF1ZXN0aW9uIEkgc3VwcG9zZSBpcywgaXMgdGhlcmUgYW4gZWFzeSB3YXkgdG8gbW92ZSB0 aGVzZQ0KPiBjb250YWluZXJzIGZyb20gaXBzZWMtaWtlbGVzcyB0byBpcHNlYy1jb21tb24sIGJ1 dCBzdGlsbCBhbGxvdyBmb3IgdGhlbSB0bw0KPiBiZSBlbXB0eSBhbmQvb3IgdW5pbXBsZW1lbnRl ZCBmb3IgdGhlIFNETiBJS0UgdXNlIGNhc2U/IElmIHRoZXkgd2VyZSBtYWRlDQo+IGZlYXR1cmVz LCBpcyB0aGVyZSBhIHByb3BlciBZQU5HIHdheSB0byBpbmRpY2F0ZSB0aGF0IGlmIHRoZSBpa2Vs ZXNzDQo+IG1vZHVsZSBpcyBwcmVzZW50IHRoZW4gdGhvc2UgZmVhdHVyZXMgbXVzdCBhbHNvIGJl IHN1cHBvcnRlZCB0aHVzIG1hdGNoaW5nDQo+IHRoZSBmdW5jdGlvbmFsaXR5IGFzIGRlZmluZWQg YnkgdGhlIGN1cnJlbnQgZHJhZnQ/DQo+IA0KPiBUaGFua3MsDQo+IENocmlzLg0KPiANCj4gDQo+ IA0KPiA+IE9uIEF1ZyAyNCwgMjAyMCwgYXQgMTA6MzcgQU0sIE1hcnRpbiBCasO2cmtsdW5kIHZp YSBEYXRhdHJhY2tlcg0KPiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQo+ID4NCj4gPiBSZXZp ZXdlcjogTWFydGluIEJqw7Zya2x1bmQNCj4gPiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5p dHMNCj4gPg0KPiA+IEkgZGlkIGFuIGVhcmx5IFlBTkcgRG9jdG9yJ3MgcmV2aWV3IG9mIHRoaXMg ZHJhZnQuICBNb3N0IG9mIG15DQo+ID4gY29tbWVudHMgdGhlbiBoYXZlIGJlZW4gYWRkcmVzc2Vk IGluIHRoaXMgdmVyc2lvbi4NCj4gPg0KPiA+IENvbW1lbnRzOg0KPiA+DQo+ID4gbyAgQXMgSSB3 cm90ZSBpbiBteSBlYXJseSByZXZpZXcsIHRoZSBSRkMgZWRpdG9yIGVuZm9yY2VzIGEgY29tbW9u DQo+ID4gICBmb3JtYXQgb2YgWUFORyBtb2R1bGVzLCBzbyBpdCBpcyBiZXR0ZXIgdG8gYWRoZXJl IHRvIHRoaXMgZm9ybWF0DQo+ID4gICBiZWZvcmUgc2VuZGluZyB0aGUgZHJhZnQgdG8gdGhlIFJG QyBlZGl0b3IuICBVc2UNCj4gPg0KPiA+ICAgICBweWFuZyAtZiB5YW5nIC0teWFuZy1saW5lLWxl bmd0aCA2OSA8RklMRT4NCj4gPg0KPiA+ICAgdG8gZ2V0IGEgY29uc2lzdGVudCBsb29rLWFuZC1m ZWVsIGZvciB5b3VyIG1vZHVsZS4NCj4gPg0KPiA+ICAgKFlvdSB3aWxsIGhhdmUgdG8gbWFudWFs bHkgcmUtZmxvdyBkZXNjcmlwdGlvbiBzdGF0ZW1lbnRzIGFmdGVyDQo+ID4gICB0aGlzLikNCj4g Pg0KPiA+DQo+ID4gbyAgVGhlcmUgYXJlIHNvbWUgbGVhZnMgdGhhdCBhcmUgb3B0aW9uYWwgaW4g dGhlIG1vZGVsLCBidXQgdy9vIGENCj4gPiAgIGRlZmF1bHQgdmFsdWUgYW5kIHcvbyBhbiBleHBs YW5hdGlvbiBvZiB3aGF0IGhhcHBlbnMgaWYgdGhhdCBsZWFmDQo+ID4gICBpcyBub3Qgc2V0LiAg WW91IHNob3VsZCBmaW5kIHRob3NlIGFuZCBlaXRoZXIgbWFrZSB0aGVtIG1hbmRhdG9yeSwNCj4g PiAgIGFkZCBhIGRlZmF1bHQgdmFsdWUsIG9yIGV4cGxhaW4gd2hhdCBpdCBtZWFucyB3aGVuIGl0 IGlzbid0IHNldC4NCj4gPiAgIEFzIGFuIGV4YW1wbGUsDQo+ID4gICAvaXBzZWMtaWtlL3BhZC9w YWQtZW50cnlwZWVyLWF1dGhlbnRpY2F0aW4vcHJlLXNoYXJlZC9zZWNyZXQNCj4gPiAgIGlzIG9w dGlvbmFsLiAgSSBzdXNwZWN0IHRoYXQgdGhpcyBsZWFmIG5lZWRzIHRvIGJlIG1hbmRhdG9yeS4N Cj4gPiAgIEFub3RoZXIgZXhhbXBsZSBpcyB0aGUgbGVhZiBlc3BlbmNhcC4NCj4gPg0KPiA+DQo+ ID4gL21hcnRpbg0KPiA+DQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IHlhbmctZG9jdG9ycyBtYWlsaW5nIGxpc3QNCj4gPiB5YW5n LWRvY3RvcnNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3lhbmctZG9jdG9ycw0KDQo= From nobody Tue Sep 22 05:34:09 2020 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 2B82C3A0D6D; Tue, 22 Sep 2020 05:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6rBc4Uma-Nf; Tue, 22 Sep 2020 05:34:06 -0700 (PDT) Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 B28033A010A; Tue, 22 Sep 2020 05:34:06 -0700 (PDT) Received: by mail-wr1-x42d.google.com with SMTP id e16so16900480wrm.2; Tue, 22 Sep 2020 05:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=S+r2ZNhlGD6jERNT+H/lcDTFTq32/+6ph7GgNpTlLVE=; b=LQcGU72crsmRVoa1bWP3W1r9TppScm/axyhBgmlDRznzkJzz2Qb6j2BMXnySX849El BQKJemPMXzrOTZb4ENrs7WcDVs+u8BSGwNONctGR88wSCdeIq0nze9/RpTegFj5E6G86 h2oRGhOyg6wL5XPXq/fBpdggIXBcLvu0/k88wbSaKG6st4EYvpbzRFz3O1LSt1b24YdN q22y49uO3+9/dvpEbDoH0U3mM3Z/hxkMpheZAoGNLAyF8/im2xT9DqBLTdG2hdsWJ4wm GN345ifmqBwvq+m9Ba0B3uygZjGkCq8uyMYuI1UL2LuHifz9eySlCXzO78O66kAoxXVp ZVlg== 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=S+r2ZNhlGD6jERNT+H/lcDTFTq32/+6ph7GgNpTlLVE=; b=rbH1aWpeOHZWwepkdRzh1cIxNAZZcuQbT/EUsB3CZVRrkKi6dcLKtSFgFp5a82Emsg RgrdoACTXx7JZOURD/4wcjp8oXopQZr6mjBJnz78cid2ApmI/Hi7dYr9xNO3uxN3eeiX G9pDO9WqwM5CG3dC138NlkUQUzqr4AWRdXJOA9msL74dZ5jquZF8xmy0b96DSHBfqPV/ g4NXpVkN6jEcxo+IZHnAXqhJiRcd7pWRxMjMoG8qPGRPZaPFq8KT2jlAjafi0TJ4ideV Z7F+Lcjwitntm4283NBwc9wEhY6SQU9GSsdVehleCeAnG20BzxjSI800PJNmnv+aOFCm 1QNQ== X-Gm-Message-State: AOAM533WVzLZ/RZYtyEGhA2XT9eH+RhSLcvsQSmywXVkpitzcKcImKH9 EIm4oE9lQDOinI138vWDArW+i9GvQPg= X-Google-Smtp-Source: ABdhPJw95fkJ+WJDrrO/rFnhGA7mdOmr/oJUQeV9VFCIt+Czn4Kr99ohVBYBmi6PBROOjyL0UMgKAg== X-Received: by 2002:a5d:50c3:: with SMTP id f3mr4961895wrt.125.1600778044674; Tue, 22 Sep 2020 05:34:04 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id l19sm4289602wmi.8.2020.09.22.05.34.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2020 05:34:04 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Benjamin Kaduk'" Cc: "'Valery Smyslov'" , , , References: <20200919050934.GN89563@kduck.mit.edu> <36CA437C-7F66-4603-9A36-0C5BB3A2FE05@nohats.ca> In-Reply-To: <36CA437C-7F66-4603-9A36-0C5BB3A2FE05@nohats.ca> Date: Tue, 22 Sep 2020 15:34:04 +0300 Message-ID: <0b7f01d690dc$a942cae0$fbc860a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJfpgm03buNdMTxDmgdDhCiMqlx0QJPtq2zqE/rzjA= Content-Language: ru Archived-At: Subject: Re: [IPsec] [***SPAM***] Re: TR: New Version Notification for draft-btw-add-ipsecme-ike-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: Tue, 22 Sep 2020 12:34:08 -0000 Hi Paul, > > I would expect there to be some people pushing to have this be a capability > > negotiation that honors the client's preference, not the server's; the > > scenario you describe is one where the server's preference is used. > > (To be fair, I'm not following ADD much at all, though, so I could be > > wrong.) > > That is not how the CP payloads work. The initiator sends a set it is okay with and the responder picks what it > prefers from that set. Or an error if it deems all of it bad. Exactly. However, with different attribute types the client can indicate its capabilities too and can prioritize them (by adding attributes to the request in the order of client's preference). > I would still prefer a single request for encrypted DNS and a reply with servers with capabilities. Asking for all > these different types will be more complicated. I don't think it's really more complicated. I agree, that current solution is more bulky in case you want to convey all possible types of encrypted DNS, all sharing the same IP-addresses and authentication domain and not counting non-standard ports. In other use cases it's roughly the same in size. Regards, Valery. > Paul From nobody Tue Sep 22 06:05:42 2020 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 40B173A0D7C; Tue, 22 Sep 2020 06:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 xu7-PQ9H65KI; Tue, 22 Sep 2020 06:05:35 -0700 (PDT) Received: from mx01.puc.rediris.es (outbound4mad.lav.puc.rediris.es [130.206.19.145]) (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 CBDDD3A0D7B; Tue, 22 Sep 2020 06:05:34 -0700 (PDT) Received: from xenon43.um.es (xenon43.um.es [155.54.212.170]) by mx01.puc.rediris.es with ESMTP id 08MD5NOX021011-08MD5NOY021011; Tue, 22 Sep 2020 15:05:23 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id 0BDD4218A3; Tue, 22 Sep 2020 15:05:23 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon43.um.es Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id n5is1bVaCk7k; Tue, 22 Sep 2020 15:05:22 +0200 (CEST) Received: from [192.168.1.36] (198.red-2-138-84.dynamicip.rima-tde.net [2.138.84.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon43.um.es (Postfix) with ESMTPSA id E9FBB2102E; Tue, 22 Sep 2020 15:05:16 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_B2A7A8BA-328F-4742-9A5A-56DD587147A9" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Tue, 22 Sep 2020 15:05:16 +0200 In-Reply-To: Cc: Rafa Marin-Lopez , Christian Hopps , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "i2nsf@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , "yang-doctors@ietf.org" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= To: "Rob Wilton (rwilton)" References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.170, helo=xenon43.um.es, mailFrom=rafa@um.es Authentication-Results: mx01.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.170 as permitted sender) smtp.mailfrom=rafa@um.es DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=DIFlZ5nqnXOdMGFtzaLEziUWDbhibgsJ1NTkKeIJZOc=; b=2LejQjJ4k9V59P1XV3XPTghaoUNfLxkVVvYH2m/VKyCYrFKrVi2q5k1xqmSFJfckLYyilZ6Et996 FnihOum9Ec5GA3PByDXVrGzrdndDkFVEiYi8aO07Sl0Pb69iy3DYnueyJwy29PkVTUnOZ7MeI+en K3AlJ3lr2QDWxDRWxEVj67dkXmqs7qgc4i4xlqHhdpV78rxSoDJ5uS+MgiSPTrXn12EUQy1wAPqd 41I0476ti9VQfr8dlvv5rGORmnj0/kLyxEh4obzTbWs4NAzHBr7LHMrLlURXaFExO+7vvibFvzMn 1zq6oXCap/gl5hoUs3J6szCLD8X27dFaFuNlwQ== Archived-At: Subject: Re: [IPsec] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 22 Sep 2020 13:05:37 -0000 --Apple-Mail=_B2A7A8BA-328F-4742-9A5A-56DD587147A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Rob: Apologies for our delayed answer. We are now working in the revision to = submit v09 by compiling all the comments. As you mentioned, we want to avoid any further delay. As we mentioned to = Chris in the past (i2nsf mailing list), we do not have any problem to = include some additional text (e.g. =E2=80=9C-sdn-" in the module names). = Therefore, Rob, we agree with your point of view about this. In summary, we are working in the next revision v09, and our idea to = address Chris=E2=80=99 comments was to include -sdn- to the module = names. We hope this is fine. Best regards. > El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) = escribi=C3=B3: >=20 > Hi draft authors, Chris, >=20 > Can we also please try and close on this issue raised by Chris. >=20 > Chris, I don=E2=80=99t think that there is any great way to solve this = issue using YANG features, but presumably the constraint could be = enforced with a must statement, or groupings could be used to copy parts = of the ipsec structure into an sdn specific ipsec tree structure. >=20 > I understand that there isn't any great desire to delay these drafts = by trying to generalize the ipsec YANG model contained within it. = However, I think that means that the modules should have "-sdn-" in = their names to indicate that they are intended specifically for the SDN = use case, and should not be confused with the more generic ipsec YANG = modules that have been proposed. >=20 > Regards, > Rob >=20 >=20 >> -----Original Message----- >> From: yang-doctors On Behalf Of = Christian >> Hopps >> Sent: 24 August 2020 18:08 >> To: Martin Bj=C3=B6rklund >> Cc: i2nsf@ietf.org; draft-ietf-i2nsf-sdn-ipsec-flow- >> protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang- >> doctors@ietf.org >> Subject: Re: [yang-doctors] Yangdoctors last call review of = draft-ietf- >> i2nsf-sdn-ipsec-flow-protection-08 >>=20 >> [adding in ipsec@] >>=20 >> Hi, >>=20 >> This draft was discussed in ipsecme at the last IETF, and there was a >> desire to look closer at a couple changes that would make these = models >> usable by ipsec generally rather than only for SDNs. Otherwise we = will end >> up with 2 models that look very similar and duplicate almost all the >> functionality. This was going to be done during the next yang doctor >> review, but it looks like that happened in the meantime (ships in the >> night). >>=20 >> At minimum the module names should include "-sdn-" if no other = changes are >> made to indicate that they are only for sdn use; however, this is not = the >> optimal solution. >>=20 >> A better solution would be to move the containers currently under = ikeless >> (for SA and Policy databases) under ipsec-common. >>=20 >> The feedback I received from the authors was that the SDN controllers >> didn't care about the actual SAs and policies when using IKE so they >> didn't want to require someone implementing ike+common modules to = have to >> support them. >>=20 >> The YANG question I suppose is, is there an easy way to move these >> containers from ipsec-ikeless to ipsec-common, but still allow for = them to >> be empty and/or unimplemented for the SDN IKE use case? If they were = made >> features, is there a proper YANG way to indicate that if the ikeless >> module is present then those features must also be supported thus = matching >> the functionality as defined by the current draft? >>=20 >> Thanks, >> Chris. >>=20 >>=20 >>=20 >>> On Aug 24, 2020, at 10:37 AM, Martin Bj=C3=B6rklund via Datatracker >> wrote: >>>=20 >>> Reviewer: Martin Bj=C3=B6rklund >>> Review result: Ready with Nits >>>=20 >>> I did an early YANG Doctor's review of this draft. Most of my >>> comments then have been addressed in this version. >>>=20 >>> Comments: >>>=20 >>> o As I wrote in my early review, the RFC editor enforces a common >>> format of YANG modules, so it is better to adhere to this format >>> before sending the draft to the RFC editor. Use >>>=20 >>> pyang -f yang --yang-line-length 69 >>>=20 >>> to get a consistent look-and-feel for your module. >>>=20 >>> (You will have to manually re-flow description statements after >>> this.) >>>=20 >>>=20 >>> o There are some leafs that are optional in the model, but w/o a >>> default value and w/o an explanation of what happens if that leaf >>> is not set. You should find those and either make them mandatory, >>> add a default value, or explain what it means when it isn't set. >>> As an example, >>> /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret >>> is optional. I suspect that this leaf needs to be mandatory. >>> Another example is the leaf espencap. >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>> _______________________________________________ >>> yang-doctors mailing list >>> yang-doctors@ietf.org >>> https://www.ietf.org/mailman/listinfo/yang-doctors >=20 ------------------------------------------------------- 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=_B2A7A8BA-328F-4742-9A5A-56DD587147A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = Rob:

Apologies for = our delayed answer. We are now working in the revision to submit v09 by = compiling all the comments.

As you mentioned, we want to avoid any further delay. As we = mentioned to Chris in the past (i2nsf mailing list), we do not have any = problem to include some additional text (e.g. =E2=80=9C-sdn-" in the = module names). Therefore, Rob, we agree with your point of view about = this.

In = summary, we are working in the next revision v09, and our idea to = address Chris=E2=80=99 comments was to include -sdn- to the module = names.

We hope = this is fine.

Best regards.

El 22 sept 2020, a las 13:56, = Rob Wilton (rwilton) <rwilton@cisco.com> escribi=C3=B3:

Hi = draft authors, Chris,

Can we also please = try and close on this issue raised by Chris.

Chris, I don=E2=80=99t think that there is any great way to = solve this issue using YANG features, but presumably the constraint = could be enforced with a must statement, or groupings could be used to = copy parts of the ipsec structure into an sdn specific ipsec tree = structure.

I understand that there isn't = any great desire to delay these drafts by trying to generalize the ipsec = YANG model contained within it.  However, I think that means that = the modules should have "-sdn-" in their names to indicate that they are = intended specifically for the SDN use case, and should not be confused = with the more generic ipsec YANG modules that have been proposed.

Regards,
Rob


-----Original Message-----
From: yang-doctors = <yang-doctors-bounces@ietf.org> On Behalf Of = Christian
Hopps
Sent: 24 August 2020 = 18:08
To: Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Cc: i2nsf@ietf.org; draft-ietf-i2nsf-sdn-ipsec-flow-
protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang-
doctors@ietf.org
Subject: Re: [yang-doctors] Yangdoctors last call review of = draft-ietf-
i2nsf-sdn-ipsec-flow-protection-08

[adding in ipsec@]

Hi,

This draft was discussed in = ipsecme at the last IETF, and there was a
desire to look = closer at a couple changes that would make these models
usable by ipsec generally rather than only for SDNs. = Otherwise we will end
up with 2 models that look very = similar and duplicate almost all the
functionality. This = was going to be done during the next yang doctor
review, = but it looks like that happened in the meantime (ships in the
night).

At minimum the module = names should include "-sdn-" if no other changes are
made = to indicate that they are only for sdn use; however, this is not the
optimal solution.

A better = solution would be to move the containers currently under ikeless
(for SA and Policy databases) under ipsec-common.

The feedback I received from the authors was = that the SDN controllers
didn't care about the actual SAs = and policies when using IKE so they
didn't want to require = someone implementing ike+common modules to have to
support = them.

The YANG question I suppose is, is = there an easy way to move these
containers from = ipsec-ikeless to ipsec-common, but still allow for them to
be empty and/or unimplemented for the SDN IKE use case? If = they were made
features, is there a proper YANG way to = indicate that if the ikeless
module is present then those = features must also be supported thus matching
the = functionality as defined by the current draft?

Thanks,
Chris.



On Aug = 24, 2020, at 10:37 AM, Martin Bj=C3=B6rklund via Datatracker
<noreply@ietf.org> wrote:

Reviewer: = Martin Bj=C3=B6rklund
Review result: Ready with Nits

I did an early YANG Doctor's review of this = draft.  Most of my
comments then have been addressed = in this version.

Comments:

o  As I wrote in my early review, the RFC editor = enforces a common
 format of YANG modules, so it is = better to adhere to this format
 before sending the = draft to the RFC editor.  Use

=    pyang -f yang --yang-line-length 69 <FILE>

 to get a consistent look-and-feel for = your module.

 (You will have to = manually re-flow description statements after
=  this.)


o  There = are some leafs that are optional in the model, but w/o a
=  default value and w/o an explanation of what happens if that = leaf
 is not set.  You should find those and = either make them mandatory,
 add a default value, or = explain what it means when it isn't set.
 As an = example,
=  /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret
 is optional.  I suspect that this leaf needs to = be mandatory.
 Another example is the leaf = espencap.


/martin


_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors


-------------------------------------------------------
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=_B2A7A8BA-328F-4742-9A5A-56DD587147A9-- From nobody Tue Sep 22 06:27:30 2020 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 A6A503A0DCA; Tue, 22 Sep 2020 06:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXqSfO7xQiYh; Tue, 22 Sep 2020 06:27:18 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 138933A074B; Tue, 22 Sep 2020 06:27:18 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 22D4A6020E; Tue, 22 Sep 2020 13:27:17 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_47034DC4-BD7D-4C84-95C1-B45CA7B6B2E5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Tue, 22 Sep 2020 09:27:15 -0400 In-Reply-To: <20200922.141953.1142814413326145014.id@4668.se> Cc: Christian Hopps , "Rob Wilton (rwilton)" , gabilm@um.es, draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org, i2nsf@ietf.org, ipsec@ietf.org, last-call@ietf.org, yang-doctors@ietf.org To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <20200922.141953.1142814413326145014.id@4668.se> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [IPsec] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 22 Sep 2020 13:27:21 -0000 --Apple-Mail=_47034DC4-BD7D-4C84-95C1-B45CA7B6B2E5 Content-Type: multipart/alternative; boundary="Apple-Mail=_3D50758C-FD74-4484-9657-EF4F9762F25B" --Apple-Mail=_3D50758C-FD74-4484-9657-EF4F9762F25B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 22, 2020, at 8:19 AM, Martin Bj=C3=B6rklund = wrote: >=20 > Hi, >=20 > Sorry I missed this question. >=20 > I think it probably can be solved; but see below. >=20 >=20 > "Rob Wilton (rwilton)" > = wrote: >> Hi draft authors, Chris, >>=20 >> Can we also please try and close on this issue raised by Chris. >>=20 >> Chris, I don=E2=80=99t think that there is any great way to solve = this issue >> using YANG features, but presumably the constraint could be enforced >> with a must statement, or groupings could be used to copy parts of = the >> ipsec structure into an sdn specific ipsec tree structure. >>=20 >> I understand that there isn't any great desire to delay these drafts >> by trying to generalize the ipsec YANG model contained within it. >> However, I think that means that the modules should have "-sdn-" in >> their names to indicate that they are intended specifically for the >> SDN use case, and should not be confused with the more generic ipsec >> YANG modules that have been proposed. >>=20 >> Regards, >> Rob >>=20 >>=20 >>> -----Original Message----- >>> From: yang-doctors On Behalf Of >>> Christian >>> Hopps >>> Sent: 24 August 2020 18:08 >>> To: Martin Bj=C3=B6rklund >>> Cc: i2nsf@ietf.org; draft-ietf-i2nsf-sdn-ipsec-flow- >>> protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang- >>> doctors@ietf.org >>> Subject: Re: [yang-doctors] Yangdoctors last call review of >>> draft-ietf- >>> i2nsf-sdn-ipsec-flow-protection-08 >>>=20 >>> [adding in ipsec@] >>>=20 >>> Hi, >>>=20 >>> This draft was discussed in ipsecme at the last IETF, and there was = a >>> desire to look closer at a couple changes that would make these = models >>> usable by ipsec generally rather than only for SDNs. Otherwise we = will >>> end >>> up with 2 models that look very similar and duplicate almost all the >>> functionality. This was going to be done during the next yang doctor >>> review, but it looks like that happened in the meantime (ships in = the >>> night). >>>=20 >>> At minimum the module names should include "-sdn-" if no other = changes >>> are >>> made to indicate that they are only for sdn use; however, this is = not >>> the >>> optimal solution. >>>=20 >>> A better solution would be to move the containers currently under >>> ikeless >>> (for SA and Policy databases) under ipsec-common. >=20 > Are we talking about /ipsec-ikeless/spd and /ipsec-ikeless/sad? If > these are moved to another module, ipsec-ikeless becomes empty (if > also the related notifs are moved). It will still contain the notification, which is used for managing = ikeless ipsec in the SDN controller case. >=20 > Why do you want to move them? It is b/c they are under > "ipsec-ikeless"? If so, perhaps a simpler solution is to use another > (more generic) name for the module and top-level container. Yes, b/c IPsec always has an SA database (both ike or ikeless). The = reason, according to the authors, it was not put in common and was only = included in ikeless was b/c the authors felt that for SDNs the SDN = controller didn't care about the SA database since IKE was managing it. = That doesn't mean it doesn't exist, just that their use case didn't = care, and didn't want to force people to implement the YANG for it if = they only supported the IKE module for SDN use. I don't see why the want to not implement the SA database YANG for = SDN+IKE couldn't be handled with a feature (or some other YANG = mechanism) instead and then have a more correct model organization The problem is that this common ipsec module (and the ikeless and ike = even) are easily augmented and usable by IPsec in general if the SA and = policy database were moved to common and out of ikeless. The only other = way to re-use it would be to augment a duplicate SA database under the = IKE module, but there is only a single SA database on a server, so now = we have 2 SA databases in YANG (under ikeless and ike namespaces) to = represent the same SA database. It seems wrong to go this route since = the change I was suggesting seems pretty trivial. In my case we have an ipsec extension in development along with a YANG = module (https://tools.ietf.org/html/draft-fedyk-ipsecme-yang-iptfs-00) = that want's to augment the SA database (for operational state like = packet counters among other things), but of course we want this to be = for IKE and IKE-less -- in particular IKE is the vastly common use case = for IPsec. Thanks, Chris. >=20 > If they are moved to ietf-ipsec-common, an implementation that > implements ietf-ipsec-ike can still import ietf-ipsec-common, but > choose to not implement it (it will show up as an 'import-only-module' > in yang library). >=20 >=20 > /martin >=20 >=20 >>> The feedback I received from the authors was that the SDN = controllers >>> didn't care about the actual SAs and policies when using IKE so they >>> didn't want to require someone implementing ike+common modules to = have >>> to >>> support them. >>>=20 >>> The YANG question I suppose is, is there an easy way to move these >>> containers from ipsec-ikeless to ipsec-common, but still allow for >>> them to >>> be empty and/or unimplemented for the SDN IKE use case? If they were >>> made >>> features, is there a proper YANG way to indicate that if the ikeless >>> module is present then those features must also be supported thus >>> matching >>> the functionality as defined by the current draft? >>>=20 >>> Thanks, >>> Chris. >>>=20 >>>=20 >>>=20 >>>> On Aug 24, 2020, at 10:37 AM, Martin Bj=C3=B6rklund via Datatracker >>> wrote: >>>>=20 >>>> Reviewer: Martin Bj=C3=B6rklund >>>> Review result: Ready with Nits >>>>=20 >>>> I did an early YANG Doctor's review of this draft. Most of my >>>> comments then have been addressed in this version. >>>>=20 >>>> Comments: >>>>=20 >>>> o As I wrote in my early review, the RFC editor enforces a common >>>> format of YANG modules, so it is better to adhere to this format >>>> before sending the draft to the RFC editor. Use >>>>=20 >>>> pyang -f yang --yang-line-length 69 >>>>=20 >>>> to get a consistent look-and-feel for your module. >>>>=20 >>>> (You will have to manually re-flow description statements after >>>> this.) >>>>=20 >>>>=20 >>>> o There are some leafs that are optional in the model, but w/o a >>>> default value and w/o an explanation of what happens if that leaf >>>> is not set. You should find those and either make them mandatory, >>>> add a default value, or explain what it means when it isn't set. >>>> As an example, >>>> /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret >>>> is optional. I suspect that this leaf needs to be mandatory. >>>> Another example is the leaf espencap. >>>>=20 >>>>=20 >>>> /martin >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> yang-doctors mailing list >>>> yang-doctors@ietf.org >>>> https://www.ietf.org/mailman/listinfo/yang-doctors --Apple-Mail=_3D50758C-FD74-4484-9657-EF4F9762F25B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 22, 2020, at 8:19 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> = wrote:

Hi,

Sorry I = missed this question.

I think it probably can be solved; but see below.


"Rob Wilton = (rwilton)" <rwilton@cisco.com> wrote:
Hi draft authors, Chris,

Can we also please try and close on this issue = raised by Chris.

Chris, I don=E2=80=99t = think that there is any great way to solve this issue
using = YANG features, but presumably the constraint could be enforced
with a must statement, or groupings could be used to copy = parts of the
ipsec structure into an sdn specific ipsec = tree structure.

I understand that there = isn't any great desire to delay these drafts
by trying to = generalize the ipsec YANG model contained within it.
However, I think that means that the modules should have = "-sdn-" in
their names to indicate that they are intended = specifically for the
SDN use case, and should not be = confused with the more generic ipsec
YANG modules that = have been proposed.

Regards,
Rob


-----Original Message-----
From: = yang-doctors <yang-doctors-bounces@ietf.org> On Behalf Of
Christian
Hopps
Sent: 24 August = 2020 18:08
To: Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Cc: i2nsf@ietf.org; draft-ietf-i2nsf-sdn-ipsec-flow-
protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang-
doctors@ietf.org
Subject: Re: [yang-doctors] Yangdoctors last call review = of
draft-ietf-
i2nsf-sdn-ipsec-flow-protection-08

[adding in ipsec@]

Hi,

This draft was discussed in ipsecme at the = last IETF, and there was a
desire to look closer at a = couple changes that would make these models
usable by = ipsec generally rather than only for SDNs. Otherwise we will
end
up with 2 models that look very similar and = duplicate almost all the
functionality. This was going to = be done during the next yang doctor
review, but it looks = like that happened in the meantime (ships in the
night).

At minimum the module names should include = "-sdn-" if no other changes
are
made to = indicate that they are only for sdn use; however, this is not
the
optimal solution.

A better solution would be to move the containers currently = under
ikeless
(for SA and Policy databases) = under ipsec-common.

Are we = talking about /ipsec-ikeless/spd and /ipsec-ikeless/sad? =  If
these are = moved to another module, ipsec-ikeless becomes empty (if
also the = related notifs are moved).

It will still contain the notification, which is used = for managing ikeless ipsec in the SDN controller case.


Why do you = want to move them?  It is b/c they are under
"ipsec-ikeless"?  If so, perhaps a simpler solution is = to use another
(more generic) name for the module and top-level = container.

Yes, = b/c IPsec always has an SA database (both ike or ikeless). The = reason, according to the authors, it was not put in = common and was only included in ikeless was b/c the authors felt = that for SDNs the SDN controller didn't care about the SA database since = IKE was managing it. That doesn't mean it doesn't exist, just that their = use case didn't care, and didn't want to force people to implement the = YANG for it if they only supported the IKE module for SDN = use.

I don't see why the want to not = implement the SA database YANG for SDN+IKE couldn't be handled with a = feature (or some other YANG mechanism) instead and then have a more = correct model organization

The = problem is that this common ipsec module (and the ikeless and ike even) = are easily augmented and usable by IPsec in general if the SA and policy = database were moved to common and out of ikeless. The only other way to = re-use it would be to augment a duplicate SA database under the IKE = module, but there is only a single SA database on a server, so now we = have 2 SA databases in YANG (under ikeless and ike namespaces) to = represent the same SA database. It seems wrong to go this route since = the change I was suggesting seems pretty trivial.




If they are = moved to ietf-ipsec-common, an implementation that
implements = ietf-ipsec-ike can still import ietf-ipsec-common, but
choose to not = implement it (it will show up as an 'import-only-module'
in yang = library).


/martin


The feedback I received from the authors was that the SDN = controllers
didn't care about the actual SAs and policies = when using IKE so they
didn't want to require someone = implementing ike+common modules to have
to
support them.

The YANG question = I suppose is, is there an easy way to move these
containers = from ipsec-ikeless to ipsec-common, but still allow for
them= to
be empty and/or unimplemented for the SDN IKE use = case? If they were
made
features, is there a = proper YANG way to indicate that if the ikeless
module is = present then those features must also be supported thus
matching
the functionality as defined by the = current draft?

Thanks,
Chris.



On Aug 24, 2020, at = 10:37 AM, Martin Bj=C3=B6rklund via Datatracker
<noreply@ietf.org> wrote:

Reviewer: Martin Bj=C3=B6rklundReview result: Ready with Nits

I = did an early YANG Doctor's review of this draft.  Most of my
comments then have been addressed in this version.

Comments:

o =  As I wrote in my early review, the RFC editor enforces a common
 format of YANG modules, so it is better to adhere to = this format
 before sending the draft to the RFC = editor.  Use

   pyang = -f yang --yang-line-length 69 <FILE>

 to get a consistent look-and-feel for your module.

 (You will have to manually re-flow = description statements after
 this.)


o  There are some leafs that are optional = in the model, but w/o a
 default value and w/o an = explanation of what happens if that leaf
 is not set. =  You should find those and either make them mandatory,
 add a default value, or explain what it means when it = isn't set.
 As an example,
 /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/sec= ret
 is optional.  I suspect that this leaf = needs to be mandatory.
 Another example is the leaf = espencap.


/martin


_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors
=

= --Apple-Mail=_3D50758C-FD74-4484-9657-EF4F9762F25B-- --Apple-Mail=_47034DC4-BD7D-4C84-95C1-B45CA7B6B2E5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl9p+7MACgkQLh2DDte4 MCWPpxAAkZg+3BSs5wiOS3GF/bGJ39lFiVs445myCSJTue1TRop2jYWvLoyF/p6n jQpX+6XaRo4KzS2y9y2fOucmjp7X4VIZ0Ym+FqkKRmEJwUjEL5CahuPn/j8MY7E9 cDK8D8CHu17re1HJvCD9JFYkaaHtQPHs3qBa6R0k74eM3OIX2g7TUVt72ZdUQWwi 019mysbmUHZKXwNqaBDNVHPpdrqt7xSE7v0yG3IiD+toSbuxGhZBPvAfewlfEZDg CuVB+yDGbx+JOw6kecKK4vzhJQU04fm9m3QHbUXemlhHOjCi1zrnMNoyTQUgq7oq EzV31BfTnFsfbgYxjsEoeaFGgmojaKJWSYCAEeQ86enYrmJKGOC9FxMP7+y9e0cj YmV1EqFHHhN7vF9lMYWo26eACB+j6nCJuBDZSDrWyohUv2q0Z0f/+aBOAAd6Y1Qk TG9xLWr4v1Wgf64logBOWi36tHL6BMpmi+cr39EzsChsI5TNLhgD57kBt9PM95zj 7/ZoSOiUWjGAk63mRrhvl7//FrzplrrmtuXvcbTjxTFDcZedLAXUHqUQh/+miaCI GqoH7tiu7JErgQrOxFEWe61gMNjsIgoF1zfIVQuox4GiAdXJDBEMGL2OVgIDsxvt vYee1nGlYqgwo+VEzQixIFiOd1qrO4yvF1mJumUjQKnumPeFIwo= =xJ78 -----END PGP SIGNATURE----- --Apple-Mail=_47034DC4-BD7D-4C84-95C1-B45CA7B6B2E5-- From nobody Tue Sep 22 07:46:34 2020 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 748663A0F2F for ; Tue, 22 Sep 2020 07:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzenEAOfWU1Y for ; Tue, 22 Sep 2020 07:46:32 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 1C9E13A0F7A for ; Tue, 22 Sep 2020 07:46:31 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id g4so16493656edk.0 for ; Tue, 22 Sep 2020 07:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=dF8DqNCdmo5Pac+pOu19a326uGE6xIM+5NbNTG4iA2k=; b=O4Dsl9/9njRopXOh9GwZHgw5jZOjMLmG2/5Yg4VBn/FWAuUlWo66zJloKU84Lanx88 N8yoh9Oyj06ry7fVfr1MbqhPCFSN4mEqTtuj1h+6F7dq9LU+wkl9+/AwTIbPoLll4wln Iu3SOqZ73fTvyS+EqghcZE68/mtdkk3HZaYqvQQM/R+p/cV34gicZEB4ZWrazhYXWMHN vRS9ae8hvMRwk81umRlg2NgxE3VsJ//albbT6LbQC9FxnbqFkHQG8Se2UXcMGzfoP8xo 23jklh61hfozZ2NhzK2Aa8jHd6SGj8jC2R6UVEAfB9iHNbBrdBWXSdZqdpPwiH3JhETL HIVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=dF8DqNCdmo5Pac+pOu19a326uGE6xIM+5NbNTG4iA2k=; b=okZMkY1IPfpNo6GBXBEuMZWHYOL5DjvvDIYJJAJSgCGkNojChrfWUTsouVH8nX1MR0 EkE/4Hm6shc63oGOqxNOXPPsy49REkXAvUopp39IkEVINZ7lO9DkHeQ80OoQRN0UAIzK ArMXG0boNjwK+LuNyCakAYqZkM8T/kMHwTqqZkOXUGemoCjdaz25HBRbZYS9VT/ujvgG WeENcHndL+21XjsCDpInRKPttz2E0MrKGEP/0L4ExEoiM3cFxL1nrh0CmCmOJGsHioAB OhbgtwKwaVCrqLtyp7Rdah/0TDuHVHLL0HWLPmxLMKqNXBRtEf70luO8TsvXscQkZQaa MjxA== X-Gm-Message-State: AOAM531Tz4YF+jLakJMrNGEaetb/CBkdp9qyWVuUUwtTp0y2CFd8e3H4 8CriabfklkRehisTKNScbja1HQdvDsg= X-Google-Smtp-Source: ABdhPJw3M0htZBVG6e31rqtSEfJJFH2y7VHTgigl+jGTOqQLw7gdn90GyhzB4ZE0fkxtthdybwF4ng== X-Received: by 2002:a50:9b5e:: with SMTP id a30mr4204202edj.49.1600785990030; Tue, 22 Sep 2020 07:46:30 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id s14sm10663988eju.84.2020.09.22.07.46.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2020 07:46:29 -0700 (PDT) From: "Valery Smyslov" To: "IPsecME WG" Date: Tue, 22 Sep 2020 17:46:30 +0300 Message-ID: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdaQ3Of9sw8SpNWjSvGCvcC+lRolpg== Content-Language: ru Archived-At: Subject: [IPsec] Cookie logic results in failed authentication 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, 22 Sep 2020 14:46:33 -0000 Hi, while performing stress tests, we ran into the problem, that is concerned with the way cookies are handled in RFC7296. The problem is that if network conditions are bad (high probability for packets to be delayed, reordered or lost), then some SAs are not established with AUTHENTICATION_FAILED error. Consider the following scenario: Initiator Responder 1. HDR, SAi, KEi, Ni --> 2. --> HDR, SAi, KEi, Ni (server has a large number of half-open SAs, so it responds with cookie, that is generated using cookie secret K1) 2. (message is delayed in the network) ... <-- HDR, N(COOKIE1) 3. (client retransmits its original message) HDR, SAi, KEi, Ni --> 4. --> HDR, SAi, KEi, Ni (server has a large number half-open SAs, so it responds with cookie, but the cookie generation secret has been already changed, and becomes K2, that results in generating a new cookie for the same request, COOKIE2) 5. <-- HDR, N(COOKIE2) 6. HDR, N(COOKIE2) <-- 7. (client receives message and retransmits its request with COOKIE2) HDR, N(COOKIE2), SAi, KEi, Ni --> 8. --> HDR, N(COOKIE2), SAi, KEi, Ni (server verifies COOKIE2, it's OK, since K2 is still the current secret) 9. (message is delayed in the network) ... <-- HDR, SAr, KEr, Nr 10. HDR, N(COOKIE1) <-- 11. (eventually the delayed first message from the server with COOKIE1 reaches the client. Since the client doesn't know that COOKIE1 is stall, it decides that it's fresher than COOKIE2, because it receives this message later, so the client replaces cookie and resends its initial request with COOKIE1) HDR, N(COOKIE1), SAi, KEi, Ni --> (this message get lost) 12. HDR, SAr, KEr, Nr <-- (eventually delayed server's response reaches the client. At this point the client thinks that IKE_SA_INIT is completed and starts IKE_AUTH) What is interesting in the above diagram: both the client and the server have eventually completed IKE_SA_INIT, but they have different opinions on what IKE_SA_INIT message from initiator to responder contains. The client thinks that the server has responded to its most recently sent message HDR, N(COOKIE1), SAi, KEi, Ni, while the server has never received it and in fact has responded to HDR, N(COOKIE2), SAi, KEi, Ni. As a result - while calculating AUTH payload they will have different inputs to it and authentication will fail. Despite this diagram looking artificial, we did observe a noticeable number of these errors during real stress tests (up to 5% of SAs failed with this error in bad network conditions). What's particularly unfortunate with this: 1. The bad network conditions may happen as a result of DDoS attack, which also may cause cookie logic to be triggered on the server. So, the two pre-conditions - bad network and server under attack are coupled. 2. The most disappointing thing for me is that despite bad network conditions, peers did manage to complete initial IKE exchanges, only to get "authentication failed" result. 3. For customers this looks surprising - they have valid credentials, but from time to time they receive "authentication failed" diagnostics without any clue why this happens. The root of the problem is that IKE_SA_INIT request may be retransmitted with different content (different cookies) and the peers have no means to be sure that they have send/receive identical messages. And later these possibly different messages are used in AUTH payload calculation. I believe that the proper solution would be to exclude cookie from the AUTH payload calculation. It is verified by the responder using cookie generation secret and it is not concerned with a client (the client did not generate it, just echoes it back). However, this solution is obviously incompatible with RFC7296, so this is not an option. Any opinions? Should this problem be addressed by the WG or ignored? Regards, Valery. From nobody Tue Sep 22 08:24:41 2020 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 158B33A1023 for ; Tue, 22 Sep 2020 08:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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 JGh0OT2l8aad for ; Tue, 22 Sep 2020 08:24:37 -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 D1D253A0FDF for ; Tue, 22 Sep 2020 08:24:36 -0700 (PDT) Received: from lhreml738-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C961E3D393687189E4E4; Tue, 22 Sep 2020 16:24:34 +0100 (IST) Received: from nkgeml706-chm.china.huawei.com (10.98.57.153) by lhreml738-chm.china.huawei.com (10.201.108.188) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 22 Sep 2020 16:24:34 +0100 Received: from nkgeml705-chm.china.huawei.com (10.98.57.154) by nkgeml706-chm.china.huawei.com (10.98.57.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Tue, 22 Sep 2020 23:24:31 +0800 Received: from nkgeml705-chm.china.huawei.com ([10.98.57.154]) by nkgeml705-chm.china.huawei.com ([10.98.57.154]) with mapi id 15.01.1913.007; Tue, 22 Sep 2020 23:24:31 +0800 From: "Panwei (William)" To: Valery Smyslov , IPsecME WG Thread-Topic: [IPsec] Cookie logic results in failed authentication Thread-Index: AdaQ3Of9sw8SpNWjSvGCvcC+lRolpgAFt4jA Date: Tue, 22 Sep 2020 15:24:31 +0000 Message-ID: References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> In-Reply-To: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.201.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 22 Sep 2020 15:24:40 -0000 Hi Valery, It seems like a rare scene but I think it needs to be considered. Compared with ignoring cookie payload, how about adding N(COOKIE2) in the 9= th message? Then when Initiator received the 12th message, it'll know which= cookie this message matches with. Regards & Thanks! Wei Pan > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov > Sent: Tuesday, September 22, 2020 10:47 PM > To: IPsecME WG > Subject: [IPsec] Cookie logic results in failed authentication >=20 > Hi, >=20 > while performing stress tests, we ran into the problem, that is concerned > with the way cookies are handled in RFC7296. > The problem is that if network conditions are bad (high probability for > packets to be delayed, reordered or lost), then some SAs are not establis= hed > with AUTHENTICATION_FAILED error. Consider the following scenario: >=20 > Initiator Responder > 1. HDR, SAi, KEi, Ni --> > 2. --> HDR, SAi, KEi, Ni > (server has a large number of > half-open SAs, so it responds with cookie, > that is generated using cookie > secret K1) > 2. (message is delayed in the network) ... <-- HDR, N(COOKIE1) > 3. (client retransmits its original message) > HDR, SAi, KEi, Ni --> > 4. --> HDR, SAi, KEi, Ni > (server has a large number > half-open SAs, so it responds with cookie, > but the cookie generation secret > has been already changed, and becomes K2, > that results in generating a new > cookie for the same request, COOKIE2) > 5. <-- HDR, N(COOKIE2) > 6. HDR, N(COOKIE2) <-- > 7. (client receives message and retransmits its request with COOKIE2) > HDR, N(COOKIE2), SAi, KEi, Ni --> > 8. --> HDR, N(COOKIE2), SAi, KEi, Ni > (server verifies COOKIE2, it's OK, > since K2 is still the current secret) > 9. (message is delayed in the network) ... <-- HDR, SAr, KEr, Nr > 10. HDR, N(COOKIE1) <-- > 11. (eventually the delayed first message from the server with COOKIE1 > reaches the client. Since the client doesn't know that COOKIE1 is stall, = it > decides that it's fresher than COOKIE2, because it receives this message = later, > so the client replaces cookie and resends its initial request with COOKIE= 1) > HDR, N(COOKIE1), SAi, KEi, Ni --> (this message get lost) > 12. HDR, SAr, KEr, Nr <-- > (eventually delayed server's response reaches the client. At this point t= he > client thinks that IKE_SA_INIT is completed and starts > IKE_AUTH) >=20 > What is interesting in the above diagram: both the client and the server = have > eventually completed IKE_SA_INIT, but they have different opinions on wha= t > IKE_SA_INIT message from initiator to responder contains. > The client thinks that the server has responded to its most recently sent > message HDR, N(COOKIE1), SAi, KEi, Ni, while the server has never receive= d > it and in fact has responded to HDR, N(COOKIE2), SAi, KEi, Ni. > As a result - while calculating AUTH payload they will have different inp= uts to > it and authentication will fail. >=20 > Despite this diagram looking artificial, we did observe a noticeable numb= er > of these errors during real stress tests (up to 5% of SAs failed with thi= s error > in bad network conditions). >=20 > What's particularly unfortunate with this: > 1. The bad network conditions may happen as a result of DDoS attack, whic= h > also may cause cookie logic to be triggered on the server. > So, the two pre-conditions - bad network and server under attack are > coupled. > 2. The most disappointing thing for me is that despite bad network > conditions, peers did manage to complete initial IKE exchanges, > only to get "authentication failed" result. > 3. For customers this looks surprising - they have valid credentials, but= from > time to time they receive "authentication failed" > diagnostics without any clue why this happens. >=20 > The root of the problem is that IKE_SA_INIT request may be retransmitted > with different content (different cookies) and the peers have no means to= be > sure that they have send/receive identical messages. And later these poss= ibly > different messages are used in AUTH payload calculation. >=20 > I believe that the proper solution would be to exclude cookie from the AU= TH > payload calculation. > It is verified by the responder using cookie generation secret and it is = not > concerned with a client (the client did not generate it, just echoes it b= ack). > However, this solution is obviously incompatible with RFC7296, so this is= not > an option. >=20 > Any opinions? Should this problem be addressed by the WG or ignored? >=20 > Regards, > Valery. >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Sep 22 08:38:58 2020 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 D6E903A1004; Tue, 22 Sep 2020 08:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=O3+LbHNh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cnGZt5i8 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 noQZwbH2YY-s; Tue, 22 Sep 2020 08:38:53 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4783A0FDF; Tue, 22 Sep 2020 08:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25216; q=dns/txt; s=iport; t=1600789133; x=1601998733; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=MPkQ7mzH/b7EmZhXZU2tngwUb0yulgAX2Ezso38EFTw=; b=O3+LbHNhzWUJ0+JP741m7k1i0gQwAIWGYwvCDP7+0bgQmEZ73cnR85Rx 0am7tOG4N7tdP2drK63ac0Xe0GM5NXFh1nEm0gT7M4BNJR0gMcMEd3276 dSIDuumHi3CB0zSkrrnppFeeuT1PgDvoWG/LgSh+RdropUcJ4ivDmRaRD k=; IronPort-PHdr: =?us-ascii?q?9a23=3A4stfQRyUIBIC4rzXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRSBt+hoylLSDs3X6PNB3uzRta2oGWkN+o2Iv31KdptQHw?= =?us-ascii?q?QEhsMbk01FYoaFBET3IeSsY3k8G8JPB0JguXygYgBZHc/kbAjUpXu/pTcZBh?= =?us-ascii?q?T4M19zIeL4Uo7fhsi6zaa84ZrWNg5JnzG6J7h1KUa7?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfCABKGWpf/4MNJK1fHQEBAQEJARI?= =?us-ascii?q?BBQUBgg+BIy8jLgdwWS8sCoQwg0YDjXmUB4RugUKBEQNVCwEBAQ0BARgBCgo?= =?us-ascii?q?CBAEBhEsCF4IOAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDAQEQEQo?= =?us-ascii?q?TAQEsCwELBAIBCBEEAQEoAwICAiULFAkIAgQOBQgTB4MFgX5NAy4BAwuqLwK?= =?us-ascii?q?BOYhhdoEygwEBAQWFLxiCEAMGgTiCcYNphlIbgUE/gRFDgU9+PoJcAQGBJTw?= =?us-ascii?q?FBwkWCQKCXzOCCyKPbySCZjyGfSaLUpELCoJnlUqFJoMMiXmTfrJ6AgQCBAU?= =?us-ascii?q?CDgEBBYFrIyqBLXAVO4JpUBcCDY4fCgIXFIM6hRSFQnQ3AgYBCQEBAwl8jFI?= =?us-ascii?q?BgRABAQ?= X-IronPort-AV: E=Sophos;i="5.77,291,1596499200"; d="scan'208,217";a="818738634" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Sep 2020 15:38:51 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 08MFcpof006671 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 22 Sep 2020 15:38:51 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Sep 2020 10:38:50 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 22 Sep 2020 10:38:50 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 22 Sep 2020 10:38:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=czReKwOvakkiiGmeQDZAspwDhD3lk20g7GmF/qywwIpeDx4K9RuurQf+Pd2ENDarpyLp0kVhPsyi538x5bkQ3eIVTAx5cUuKsCAJJagGst/mgN9znxwgxLBWh6FHJrKSgL7zbUojSKTaJasPnFy2kXUTDGUQ1PN+TNsztwm/KVipcxWzhGYy6aM0tBCLth9rctXjf95McaNjrA89xSYE5V4olx9dhyoYzvqqRnQJ+4T/UFQT72ZRHsad+NiSHp/hIktDmltkl8+K4eroRI1vlMzKsxCaGTAcBiQM17AThZBEF4yEQRUvKBUktsG/SvyyMtXEH3T0hMMNWccwSb2F8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MPkQ7mzH/b7EmZhXZU2tngwUb0yulgAX2Ezso38EFTw=; b=STOaS52Ajt88vApaUcvClNt+qpIn04u1K3fAmEuWIhVZO2igiKZaNI9mzvBNPR4QYuhxkJUO6HQJdLQng6/2BTqfXyBl5FzFDfieqQHsQ5cD7CXUMaDc6dFBEgO00WHeQlhlKXZdGTarp2Mmoc6fbve0IbpiTvSXH/cF5F3oQGYvQWNVejyMr8xx4BCSLA2kB17NeUPu+pUAbxP2T49EfJNFj4NuebwMR1Y3Cm6h/0IDtlXUP3t2bv5QIZuBupJjE/GGSx62BK00f1lio43qhirb+aFIx+XPAqo1PNiwCgv8CJSLyRQKheYQgYCzDZJarlVCD2xBsbPkDX3HBKpDhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MPkQ7mzH/b7EmZhXZU2tngwUb0yulgAX2Ezso38EFTw=; b=cnGZt5i8iap7W0TQXtds+tSNEaKh1Uwl0OiM90/0UDZQD7IQHWqLdmY5ICTesHcIOWMqKxO0ZwJBZ5vZsAjPOlIgnIma82z7cd92DcfGln/A6OnNdyRI+QbWS4h3rW7CYCvYtNM05TmatGxoBz9UHpS6lGb2zEBjRcBmF6//GjI= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3265.namprd11.prod.outlook.com (2603:10b6:208:6a::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Tue, 22 Sep 2020 15:38:46 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3391.026; Tue, 22 Sep 2020 15:38:45 +0000 From: "Rob Wilton (rwilton)" To: Rafa Marin-Lopez CC: Christian Hopps , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "i2nsf@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , "yang-doctors@ietf.org" , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= Thread-Topic: [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 Thread-Index: AQHWeiQ1OzamIxEUgUCW76UP8U3vNKlHffqAgC01gyCAABpCAIAAJ6MA Date: Tue, 22 Sep 2020 15:38:45 +0000 Message-ID: References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> In-Reply-To: <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: um.es; dkim=none (message not signed) header.d=none;um.es; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d53cb30b-15a3-4ab3-651c-08d85f0d97d1 x-ms-traffictypediagnostic: BL0PR11MB3265: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: miKYgZQmRzTqxVFMskUSOhteMb3y8U9uG7WoX3DZNAHnD3m1B24f0pvJquyYL62K9MGe1NVibVZKlaGM1KXJxtm3j0kzf0WL2g/gWgJo/KyFyVyAm6KJ9lfo4i7q5h/XRb3kqsymMoXqtxSmR9ZDWDrzQTnn2QJ+l6v4LVy+TQxbGJw8cR3Kjpw9aYJSn8lw4ADpItKSogUJKBKS2BqOP89ZQQ3nrfv1CsGOzlt2CJIgMhZ1q9c4CLxWjjqSh52GKuFeNHxYLnESTRDMXl8h813T4A/Sm9C2ra3c8rLiDuxwK/Au6TrF3yrmuXroMBxlsnCreyJp0g/eCHXhWC4LZFDUvq4S/bQijAjhyEYHWcq09t5A2B/DK5lfmKJCYd45+mVLUq5M1fQTpcLwHvpwQA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(376002)(346002)(366004)(39860400002)(2906002)(966005)(71200400001)(4326008)(5660300002)(166002)(186003)(66574015)(83380400001)(55016002)(8936002)(26005)(33656002)(7696005)(86362001)(9686003)(66556008)(64756008)(66446008)(76116006)(54906003)(52536014)(316002)(9326002)(66946007)(6916009)(66476007)(478600001)(6506007)(53546011)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: u14Zn6bDBuRJVrDi95/aFyJm97R13v7R/Xu4WXm8RZILUF2eqFoj8ww8UjYJgGqlYWVO9TI2sJRoxEAqkapJnaJY/6SLg0jbULUFQXfZiKG3bPquBD37+vnYSBZuuWHT/cMo9tdYVURymTsTHMuJ4Na/6IeH3UIPabSICUCkaJj96L+A8v5nsYHnMRTc3JmYFT6tkYKhSaSKLTWyLqsKRCRu12D4a0YCxx3HxIku0WCdKNEnvv4ghPRgCadiQvesEgaR79QS5DOHkYQklGvv8/XIc+DprMH/QQ22vymmtgDN+u2b+CF0MdpZb3sRZLgk79uNTn9cIKPwS2A2wCnLFncQRUZGIXW3irYpMORfNuoSw9UcEhcimCZWXjfl+yUbPpCTgOmcRIqLjgKLpsNU5/egTJdpkaREPCcR0YtaQAv2rGWxOL0iDZASEUu01SHOtKBHkUSeGfweTJFYpRuHpPhzMO4eGlidr3BFV31tKRlh6P1wI7JE6wWJrc0rXt3FjAisnIZ1SjKO868a39D7G3amT/KPA7ifpLflif8h+NyAXlwrr9HCvL0bTlQSZ72RR2dWwImJeVRdaBOfFsiCtm6eZqzi5HzLAwHjuyH7s8/TsKbsGVNgDpd2tckiL7b5BRXThOqcsB5VyZq8WJ6Meg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366E30B3C372D13B391AE07B53B0MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d53cb30b-15a3-4ab3-651c-08d85f0d97d1 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2020 15:38:45.7852 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kg+nKLV6QV1y4JiyKOXObDGzmScKMnlhDAIGWAtxWLdlsWBRBWBDldiHfwpP/Q3m/FALGZkc7pn9ApMvgXzCpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3265 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [IPsec] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 22 Sep 2020 15:38:56 -0000 --_000_MN2PR11MB4366E30B3C372D13B391AE07B53B0MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFmYSwNCg0KVGhhbmtzIGZvciBnZXR0aW5nIGJhY2sgdG8gbWUuDQoNClllcywgY2hhbmdp bmcgdGhlIG5hbWUgb2YgdGhlIG1vZHVsZSBpcyBhbiBva2F5LCBpZiBub3QgaWRlYWwsIHJlc29s dXRpb24uICBCdXQgSSBhcHByZWNpYXRlIHRoYXQgeW91IGFsc28gd2FudCB0byBiZSBkb25lIHdp dGggdGhpcyB3b3JrLg0KDQpCdXQgSSB3b3VsZCBsaWtlIHRvIGNoZWNrOiAgTXkgdW5kZXJzdGFu ZGluZyBpcyB0aGF0IHRoZSBjaGFuZ2VzIHRoYXQgQ2hyaXMgaXMgcHJvcG9zaW5nIGFyZSBwcmV0 dHkgc21hbGwuICBJLmUuIG1vdmUgdGhlIFNBIHN0cnVjdHVyZSB1bmRlciBpcHNlYy1jb21tb24s IGFuZCBwdXQgaXQgdW5kZXIgYSBZQU5HIGZlYXR1cmUuICBBcmUgeW91IHN1cmUgdGhhdCBpdCBp cyBpbXByYWN0aWNhbCB0byBhY2NvbW1vZGF0ZSB0aGlzIGNoYW5nZSB3aGljaCB3b3VsZCBhbGxv dyBhIHNpbmdsZSBpcHNlYyBtb2R1bGUgdG8gYmUgc2hhcmVkIGFuZCBleHRlbmRlZCB2aWEgWUFO RyBhdWdtZW50YXRpb25zPw0KDQpUaGFua3MsDQpSb2INCg0KDQpGcm9tOiBSYWZhIE1hcmluLUxv cGV6IDxyYWZhQHVtLmVzPg0KU2VudDogMjIgU2VwdGVtYmVyIDIwMjAgMTQ6MDUNClRvOiBSb2Ig V2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+DQpDYzogUmFmYSBNYXJpbi1Mb3Bl eiA8cmFmYUB1bS5lcz47IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBHYWJy aWVsIExvcGV6IDxnYWJpbG1AdW0uZXM+OyBkcmFmdC1pZXRmLWkybnNmLXNkbi1pcHNlYy1mbG93 LXByb3RlY3Rpb24uYWxsQGlldGYub3JnOyBpMm5zZkBpZXRmLm9yZzsgaXBzZWNAaWV0Zi5vcmc7 IGxhc3QtY2FsbEBpZXRmLm9yZzsgeWFuZy1kb2N0b3JzQGlldGYub3JnOyBNYXJ0aW4gQmrDtnJr bHVuZCA8bWJqK2lldGZANDY2OC5zZT4NClN1YmplY3Q6IFJlOiBbeWFuZy1kb2N0b3JzXSBZYW5n ZG9jdG9ycyBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaTJuc2Ytc2RuLWlwc2VjLWZs b3ctcHJvdGVjdGlvbi0wOA0KDQpEZWFyIFJvYjoNCg0KQXBvbG9naWVzIGZvciBvdXIgZGVsYXll ZCBhbnN3ZXIuIFdlIGFyZSBub3cgd29ya2luZyBpbiB0aGUgcmV2aXNpb24gdG8gc3VibWl0IHYw OSBieSBjb21waWxpbmcgYWxsIHRoZSBjb21tZW50cy4NCg0KQXMgeW91IG1lbnRpb25lZCwgd2Ug d2FudCB0byBhdm9pZCBhbnkgZnVydGhlciBkZWxheS4gQXMgd2UgbWVudGlvbmVkIHRvIENocmlz IGluIHRoZSBwYXN0IChpMm5zZiBtYWlsaW5nIGxpc3QpLCB3ZSBkbyBub3QgaGF2ZSBhbnkgcHJv YmxlbSB0byBpbmNsdWRlIHNvbWUgYWRkaXRpb25hbCB0ZXh0IChlLmcuIOKAnC1zZG4tIiBpbiB0 aGUgbW9kdWxlIG5hbWVzKS4gVGhlcmVmb3JlLCBSb2IsIHdlIGFncmVlIHdpdGggeW91ciBwb2lu dCBvZiB2aWV3IGFib3V0IHRoaXMuDQoNCkluIHN1bW1hcnksIHdlIGFyZSB3b3JraW5nIGluIHRo ZSBuZXh0IHJldmlzaW9uIHYwOSwgYW5kIG91ciBpZGVhIHRvIGFkZHJlc3MgQ2hyaXPigJkgY29t bWVudHMgd2FzIHRvIGluY2x1ZGUgLXNkbi0gdG8gdGhlIG1vZHVsZSBuYW1lcy4NCg0KV2UgaG9w ZSB0aGlzIGlzIGZpbmUuDQoNCkJlc3QgcmVnYXJkcy4NCg0KDQpFbCAyMiBzZXB0IDIwMjAsIGEg bGFzIDEzOjU2LCBSb2IgV2lsdG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb208bWFpbHRv OnJ3aWx0b25AY2lzY28uY29tPj4gZXNjcmliacOzOg0KDQpIaSBkcmFmdCBhdXRob3JzLCBDaHJp cywNCg0KQ2FuIHdlIGFsc28gcGxlYXNlIHRyeSBhbmQgY2xvc2Ugb24gdGhpcyBpc3N1ZSByYWlz ZWQgYnkgQ2hyaXMuDQoNCkNocmlzLCBJIGRvbuKAmXQgdGhpbmsgdGhhdCB0aGVyZSBpcyBhbnkg Z3JlYXQgd2F5IHRvIHNvbHZlIHRoaXMgaXNzdWUgdXNpbmcgWUFORyBmZWF0dXJlcywgYnV0IHBy ZXN1bWFibHkgdGhlIGNvbnN0cmFpbnQgY291bGQgYmUgZW5mb3JjZWQgd2l0aCBhIG11c3Qgc3Rh dGVtZW50LCBvciBncm91cGluZ3MgY291bGQgYmUgdXNlZCB0byBjb3B5IHBhcnRzIG9mIHRoZSBp cHNlYyBzdHJ1Y3R1cmUgaW50byBhbiBzZG4gc3BlY2lmaWMgaXBzZWMgdHJlZSBzdHJ1Y3R1cmUu DQoNCkkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlzbid0IGFueSBncmVhdCBkZXNpcmUgdG8gZGVs YXkgdGhlc2UgZHJhZnRzIGJ5IHRyeWluZyB0byBnZW5lcmFsaXplIHRoZSBpcHNlYyBZQU5HIG1v ZGVsIGNvbnRhaW5lZCB3aXRoaW4gaXQuICBIb3dldmVyLCBJIHRoaW5rIHRoYXQgbWVhbnMgdGhh dCB0aGUgbW9kdWxlcyBzaG91bGQgaGF2ZSAiLXNkbi0iIGluIHRoZWlyIG5hbWVzIHRvIGluZGlj YXRlIHRoYXQgdGhleSBhcmUgaW50ZW5kZWQgc3BlY2lmaWNhbGx5IGZvciB0aGUgU0ROIHVzZSBj YXNlLCBhbmQgc2hvdWxkIG5vdCBiZSBjb25mdXNlZCB3aXRoIHRoZSBtb3JlIGdlbmVyaWMgaXBz ZWMgWUFORyBtb2R1bGVzIHRoYXQgaGF2ZSBiZWVuIHByb3Bvc2VkLg0KDQpSZWdhcmRzLA0KUm9i DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogeWFuZy1kb2N0b3JzIDx5 YW5nLWRvY3RvcnMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86eWFuZy1kb2N0b3JzLWJvdW5jZXNA aWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuDQpIb3Bwcw0KU2VudDogMjQgQXVndXN0 IDIwMjAgMTg6MDgNClRvOiBNYXJ0aW4gQmrDtnJrbHVuZCA8bWJqK2lldGZANDY2OC5zZTxtYWls dG86bWJqK2lldGZANDY2OC5zZT4+DQpDYzogaTJuc2ZAaWV0Zi5vcmc8bWFpbHRvOmkybnNmQGll dGYub3JnPjsgZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy0NCnByb3RlY3Rpb24uYWxs QGlldGYub3JnPG1haWx0bzpwcm90ZWN0aW9uLmFsbEBpZXRmLm9yZz47IGlwc2VjQGlldGYub3Jn PG1haWx0bzppcHNlY0BpZXRmLm9yZz47IGxhc3QtY2FsbEBpZXRmLm9yZzxtYWlsdG86bGFzdC1j YWxsQGlldGYub3JnPjsgeWFuZy0NCmRvY3RvcnNAaWV0Zi5vcmc8bWFpbHRvOmRvY3RvcnNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3lhbmctZG9jdG9yc10gWWFuZ2RvY3RvcnMgbGFzdCBjYWxs IHJldmlldyBvZiBkcmFmdC1pZXRmLQ0KaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJvdGVjdGlvbi0w OA0KDQpbYWRkaW5nIGluIGlwc2VjQF0NCg0KSGksDQoNClRoaXMgZHJhZnQgd2FzIGRpc2N1c3Nl ZCBpbiBpcHNlY21lIGF0IHRoZSBsYXN0IElFVEYsIGFuZCB0aGVyZSB3YXMgYQ0KZGVzaXJlIHRv IGxvb2sgY2xvc2VyIGF0IGEgY291cGxlIGNoYW5nZXMgdGhhdCB3b3VsZCBtYWtlIHRoZXNlIG1v ZGVscw0KdXNhYmxlIGJ5IGlwc2VjIGdlbmVyYWxseSByYXRoZXIgdGhhbiBvbmx5IGZvciBTRE5z LiBPdGhlcndpc2Ugd2Ugd2lsbCBlbmQNCnVwIHdpdGggMiBtb2RlbHMgdGhhdCBsb29rIHZlcnkg c2ltaWxhciBhbmQgZHVwbGljYXRlIGFsbW9zdCBhbGwgdGhlDQpmdW5jdGlvbmFsaXR5LiBUaGlz IHdhcyBnb2luZyB0byBiZSBkb25lIGR1cmluZyB0aGUgbmV4dCB5YW5nIGRvY3Rvcg0KcmV2aWV3 LCBidXQgaXQgbG9va3MgbGlrZSB0aGF0IGhhcHBlbmVkIGluIHRoZSBtZWFudGltZSAoc2hpcHMg aW4gdGhlDQpuaWdodCkuDQoNCkF0IG1pbmltdW0gdGhlIG1vZHVsZSBuYW1lcyBzaG91bGQgaW5j bHVkZSAiLXNkbi0iIGlmIG5vIG90aGVyIGNoYW5nZXMgYXJlDQptYWRlIHRvIGluZGljYXRlIHRo YXQgdGhleSBhcmUgb25seSBmb3Igc2RuIHVzZTsgaG93ZXZlciwgdGhpcyBpcyBub3QgdGhlDQpv cHRpbWFsIHNvbHV0aW9uLg0KDQpBIGJldHRlciBzb2x1dGlvbiB3b3VsZCBiZSB0byBtb3ZlIHRo ZSBjb250YWluZXJzIGN1cnJlbnRseSB1bmRlciBpa2VsZXNzDQooZm9yIFNBIGFuZCBQb2xpY3kg ZGF0YWJhc2VzKSB1bmRlciBpcHNlYy1jb21tb24uDQoNClRoZSBmZWVkYmFjayBJIHJlY2VpdmVk IGZyb20gdGhlIGF1dGhvcnMgd2FzIHRoYXQgdGhlIFNETiBjb250cm9sbGVycw0KZGlkbid0IGNh cmUgYWJvdXQgdGhlIGFjdHVhbCBTQXMgYW5kIHBvbGljaWVzIHdoZW4gdXNpbmcgSUtFIHNvIHRo ZXkNCmRpZG4ndCB3YW50IHRvIHJlcXVpcmUgc29tZW9uZSBpbXBsZW1lbnRpbmcgaWtlK2NvbW1v biBtb2R1bGVzIHRvIGhhdmUgdG8NCnN1cHBvcnQgdGhlbS4NCg0KVGhlIFlBTkcgcXVlc3Rpb24g SSBzdXBwb3NlIGlzLCBpcyB0aGVyZSBhbiBlYXN5IHdheSB0byBtb3ZlIHRoZXNlDQpjb250YWlu ZXJzIGZyb20gaXBzZWMtaWtlbGVzcyB0byBpcHNlYy1jb21tb24sIGJ1dCBzdGlsbCBhbGxvdyBm b3IgdGhlbSB0bw0KYmUgZW1wdHkgYW5kL29yIHVuaW1wbGVtZW50ZWQgZm9yIHRoZSBTRE4gSUtF IHVzZSBjYXNlPyBJZiB0aGV5IHdlcmUgbWFkZQ0KZmVhdHVyZXMsIGlzIHRoZXJlIGEgcHJvcGVy IFlBTkcgd2F5IHRvIGluZGljYXRlIHRoYXQgaWYgdGhlIGlrZWxlc3MNCm1vZHVsZSBpcyBwcmVz ZW50IHRoZW4gdGhvc2UgZmVhdHVyZXMgbXVzdCBhbHNvIGJlIHN1cHBvcnRlZCB0aHVzIG1hdGNo aW5nDQp0aGUgZnVuY3Rpb25hbGl0eSBhcyBkZWZpbmVkIGJ5IHRoZSBjdXJyZW50IGRyYWZ0Pw0K DQpUaGFua3MsDQpDaHJpcy4NCg0KDQoNCg0KT24gQXVnIDI0LCAyMDIwLCBhdCAxMDozNyBBTSwg TWFydGluIEJqw7Zya2x1bmQgdmlhIERhdGF0cmFja2VyDQo8bm9yZXBseUBpZXRmLm9yZzxtYWls dG86bm9yZXBseUBpZXRmLm9yZz4+IHdyb3RlOg0KDQoNClJldmlld2VyOiBNYXJ0aW4gQmrDtnJr bHVuZA0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQoNCkkgZGlkIGFuIGVhcmx5IFlB TkcgRG9jdG9yJ3MgcmV2aWV3IG9mIHRoaXMgZHJhZnQuICBNb3N0IG9mIG15DQpjb21tZW50cyB0 aGVuIGhhdmUgYmVlbiBhZGRyZXNzZWQgaW4gdGhpcyB2ZXJzaW9uLg0KDQpDb21tZW50czoNCg0K byAgQXMgSSB3cm90ZSBpbiBteSBlYXJseSByZXZpZXcsIHRoZSBSRkMgZWRpdG9yIGVuZm9yY2Vz IGEgY29tbW9uDQogZm9ybWF0IG9mIFlBTkcgbW9kdWxlcywgc28gaXQgaXMgYmV0dGVyIHRvIGFk aGVyZSB0byB0aGlzIGZvcm1hdA0KIGJlZm9yZSBzZW5kaW5nIHRoZSBkcmFmdCB0byB0aGUgUkZD IGVkaXRvci4gIFVzZQ0KDQogICBweWFuZyAtZiB5YW5nIC0teWFuZy1saW5lLWxlbmd0aCA2OSA8 RklMRT4NCg0KIHRvIGdldCBhIGNvbnNpc3RlbnQgbG9vay1hbmQtZmVlbCBmb3IgeW91ciBtb2R1 bGUuDQoNCiAoWW91IHdpbGwgaGF2ZSB0byBtYW51YWxseSByZS1mbG93IGRlc2NyaXB0aW9uIHN0 YXRlbWVudHMgYWZ0ZXINCiB0aGlzLikNCg0KDQpvICBUaGVyZSBhcmUgc29tZSBsZWFmcyB0aGF0 IGFyZSBvcHRpb25hbCBpbiB0aGUgbW9kZWwsIGJ1dCB3L28gYQ0KIGRlZmF1bHQgdmFsdWUgYW5k IHcvbyBhbiBleHBsYW5hdGlvbiBvZiB3aGF0IGhhcHBlbnMgaWYgdGhhdCBsZWFmDQogaXMgbm90 IHNldC4gIFlvdSBzaG91bGQgZmluZCB0aG9zZSBhbmQgZWl0aGVyIG1ha2UgdGhlbSBtYW5kYXRv cnksDQogYWRkIGEgZGVmYXVsdCB2YWx1ZSwgb3IgZXhwbGFpbiB3aGF0IGl0IG1lYW5zIHdoZW4g aXQgaXNuJ3Qgc2V0Lg0KIEFzIGFuIGV4YW1wbGUsDQogL2lwc2VjLWlrZS9wYWQvcGFkLWVudHJ5 cGVlci1hdXRoZW50aWNhdGluL3ByZS1zaGFyZWQvc2VjcmV0DQogaXMgb3B0aW9uYWwuICBJIHN1 c3BlY3QgdGhhdCB0aGlzIGxlYWYgbmVlZHMgdG8gYmUgbWFuZGF0b3J5Lg0KIEFub3RoZXIgZXhh bXBsZSBpcyB0aGUgbGVhZiBlc3BlbmNhcC4NCg0KDQovbWFydGluDQoNCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnlhbmctZG9jdG9ycyBtYWlsaW5n IGxpc3QNCnlhbmctZG9jdG9yc0BpZXRmLm9yZzxtYWlsdG86eWFuZy1kb2N0b3JzQGlldGYub3Jn Pg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby95YW5nLWRvY3RvcnMNCg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpSYWZhIE1hcmluLUxvcGV6LCBQaEQNCkRlcHQuIEluZm9ybWF0aW9uIGFuZCBDb21tdW5pY2F0 aW9ucyBFbmdpbmVlcmluZyAoRElJQykNCkZhY3VsdHkgb2YgQ29tcHV0ZXIgU2NpZW5jZS1Vbml2 ZXJzaXR5IG9mIE11cmNpYQ0KMzAxMDAgTXVyY2lhIC0gU3BhaW4NClRlbGY6ICszNDg2ODg4ODUw MSBGYXg6ICszNDg2ODg4NDE1MSBlLW1haWw6IHJhZmFAdW0uZXM8bWFpbHRvOnJhZmFAdW0uZXM+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQoNCg0KDQoNCg== --_000_MN2PR11MB4366E30B3C372D13B391AE07B53B0MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgUmFmYSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+VGhhbmtzIGZvciBnZXR0aW5nIGJhY2sgdG8gbWUuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlllcywgY2hhbmdpbmcg dGhlIG5hbWUgb2YgdGhlIG1vZHVsZSBpcyBhbiBva2F5LCBpZiBub3QgaWRlYWwsIHJlc29sdXRp b24uJm5ic3A7IEJ1dCBJIGFwcHJlY2lhdGUgdGhhdCB5b3UgYWxzbyB3YW50IHRvIGJlIGRvbmUg d2l0aCB0aGlzIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJ1dCBJIHdvdWxkIGxpa2UgdG8gY2hlY2s6Jm5ic3A7IE15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgY2hhbmdlcyB0aGF0IENocmlzIGlzIHByb3Bvc2lu ZyBhcmUgcHJldHR5IHNtYWxsLiZuYnNwOyBJLmUuIG1vdmUgdGhlIFNBIHN0cnVjdHVyZSB1bmRl ciBpcHNlYy1jb21tb24sIGFuZCBwdXQgaXQgdW5kZXIgYSBZQU5HIGZlYXR1cmUuJm5ic3A7IEFy ZSB5b3UNCiBzdXJlIHRoYXQgaXQgaXMgaW1wcmFjdGljYWwgdG8gYWNjb21tb2RhdGUgdGhpcyBj aGFuZ2Ugd2hpY2ggd291bGQgYWxsb3cgYSBzaW5nbGUgaXBzZWMgbW9kdWxlIHRvIGJlIHNoYXJl ZCBhbmQgZXh0ZW5kZWQgdmlhIFlBTkcgYXVnbWVudGF0aW9ucz88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmtzLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Um9iPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJhZmEgTWFyaW4tTG9wZXogJmx0O3JhZmFA dW0uZXMmZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gMjIgU2VwdGVtYmVyIDIwMjAgMTQ6MDU8YnI+ DQo8Yj5Ubzo8L2I+IFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDtyd2lsdG9uQGNpc2NvLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IFJhZmEgTWFyaW4tTG9wZXogJmx0O3JhZmFAdW0uZXMmZ3Q7OyBD aHJpc3RpYW4gSG9wcHMgJmx0O2Nob3Bwc0BjaG9wcHMub3JnJmd0OzsgR2FicmllbCBMb3BleiAm bHQ7Z2FiaWxtQHVtLmVzJmd0OzsgZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90 ZWN0aW9uLmFsbEBpZXRmLm9yZzsgaTJuc2ZAaWV0Zi5vcmc7IGlwc2VjQGlldGYub3JnOyBsYXN0 LWNhbGxAaWV0Zi5vcmc7IHlhbmctZG9jdG9yc0BpZXRmLm9yZzsgTWFydGluIEJqw7Zya2x1bmQN CiAmbHQ7bWJqK2lldGZANDY2OC5zZSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFt5YW5n LWRvY3RvcnNdIFlhbmdkb2N0b3JzIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pMm5z Zi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLTA4PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBSb2I6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcG9sb2dpZXMgZm9yIG91ciBkZWxheWVkIGFuc3dlci4gV2Ug YXJlIG5vdyB3b3JraW5nIGluIHRoZSByZXZpc2lvbiB0byBzdWJtaXQgdjA5IGJ5IGNvbXBpbGlu ZyBhbGwgdGhlIGNvbW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BcyB5b3UgbWVudGlvbmVkLCB3ZSB3YW50IHRvIGF2b2lkIGFueSBm dXJ0aGVyIGRlbGF5LiBBcyB3ZSBtZW50aW9uZWQgdG8gQ2hyaXMgaW4gdGhlIHBhc3QgKGkybnNm IG1haWxpbmcgbGlzdCksIHdlIGRvIG5vdCBoYXZlIGFueSBwcm9ibGVtIHRvIGluY2x1ZGUgc29t ZSBhZGRpdGlvbmFsIHRleHQgKGUuZy4g4oCcLXNkbi0mcXVvdDsgaW4gdGhlIG1vZHVsZSBuYW1l cykuIFRoZXJlZm9yZSwgUm9iLCB3ZSBhZ3JlZSB3aXRoDQogeW91ciBwb2ludCBvZiB2aWV3IGFi b3V0IHRoaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkluIHN1bW1hcnksIHdlIGFyZSB3b3JraW5nIGluIHRoZSBuZXh0IHJldmlzaW9uIHYw OSwgYW5kIG91ciBpZGVhIHRvIGFkZHJlc3MgQ2hyaXPigJkgY29tbWVudHMgd2FzIHRvIGluY2x1 ZGUgLXNkbi0gdG8gdGhlIG1vZHVsZSBuYW1lcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaG9wZSB0aGlzIGlzIGZpbmUuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJk cy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVsIDIyIHNl cHQgMjAyMCwgYSBsYXMgMTM6NTYsIFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDs8YSBocmVmPSJt YWlsdG86cndpbHRvbkBjaXNjby5jb20iPnJ3aWx0b25AY2lzY28uY29tPC9hPiZndDsgZXNjcmli acOzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgZHJh ZnQgYXV0aG9ycywgQ2hyaXMsPGJyPg0KPGJyPg0KQ2FuIHdlIGFsc28gcGxlYXNlIHRyeSBhbmQg Y2xvc2Ugb24gdGhpcyBpc3N1ZSByYWlzZWQgYnkgQ2hyaXMuPGJyPg0KPGJyPg0KQ2hyaXMsIEkg ZG9u4oCZdCB0aGluayB0aGF0IHRoZXJlIGlzIGFueSBncmVhdCB3YXkgdG8gc29sdmUgdGhpcyBp c3N1ZSB1c2luZyBZQU5HIGZlYXR1cmVzLCBidXQgcHJlc3VtYWJseSB0aGUgY29uc3RyYWludCBj b3VsZCBiZSBlbmZvcmNlZCB3aXRoIGEgbXVzdCBzdGF0ZW1lbnQsIG9yIGdyb3VwaW5ncyBjb3Vs ZCBiZSB1c2VkIHRvIGNvcHkgcGFydHMgb2YgdGhlIGlwc2VjIHN0cnVjdHVyZSBpbnRvIGFuIHNk biBzcGVjaWZpYyBpcHNlYyB0cmVlDQogc3RydWN0dXJlLjxicj4NCjxicj4NCkkgdW5kZXJzdGFu ZCB0aGF0IHRoZXJlIGlzbid0IGFueSBncmVhdCBkZXNpcmUgdG8gZGVsYXkgdGhlc2UgZHJhZnRz IGJ5IHRyeWluZyB0byBnZW5lcmFsaXplIHRoZSBpcHNlYyBZQU5HIG1vZGVsIGNvbnRhaW5lZCB3 aXRoaW4gaXQuICZuYnNwO0hvd2V2ZXIsIEkgdGhpbmsgdGhhdCBtZWFucyB0aGF0IHRoZSBtb2R1 bGVzIHNob3VsZCBoYXZlICZxdW90Oy1zZG4tJnF1b3Q7IGluIHRoZWlyIG5hbWVzIHRvIGluZGlj YXRlIHRoYXQgdGhleSBhcmUgaW50ZW5kZWQgc3BlY2lmaWNhbGx5DQogZm9yIHRoZSBTRE4gdXNl IGNhc2UsIGFuZCBzaG91bGQgbm90IGJlIGNvbmZ1c2VkIHdpdGggdGhlIG1vcmUgZ2VuZXJpYyBp cHNlYyBZQU5HIG1vZHVsZXMgdGhhdCBoYXZlIGJlZW4gcHJvcG9zZWQuPGJyPg0KPGJyPg0KUmVn YXJkcyw8YnI+DQpSb2I8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9t OiB5YW5nLWRvY3RvcnMgJmx0OzxhIGhyZWY9Im1haWx0bzp5YW5nLWRvY3RvcnMtYm91bmNlc0Bp ZXRmLm9yZyI+eWFuZy1kb2N0b3JzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBPbiBCZWhhbGYg T2YgQ2hyaXN0aWFuPGJyPg0KSG9wcHM8YnI+DQpTZW50OiAyNCBBdWd1c3QgMjAyMCAxODowODxi cj4NClRvOiBNYXJ0aW4gQmrDtnJrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaitpZXRmQDQ2 Njguc2UiPm1iaitpZXRmQDQ2Njguc2U8L2E+Jmd0Ozxicj4NCkNjOiA8YSBocmVmPSJtYWlsdG86 aTJuc2ZAaWV0Zi5vcmciPmkybnNmQGlldGYub3JnPC9hPjsgZHJhZnQtaWV0Zi1pMm5zZi1zZG4t aXBzZWMtZmxvdy08YnI+DQo8YSBocmVmPSJtYWlsdG86cHJvdGVjdGlvbi5hbGxAaWV0Zi5vcmci PnByb3RlY3Rpb24uYWxsQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlwc2VjQGlldGYu b3JnIj4NCmlwc2VjQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmxhc3QtY2FsbEBpZXRm Lm9yZyI+bGFzdC1jYWxsQGlldGYub3JnPC9hPjsgeWFuZy08YnI+DQo8YSBocmVmPSJtYWlsdG86 ZG9jdG9yc0BpZXRmLm9yZyI+ZG9jdG9yc0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBSZTog W3lhbmctZG9jdG9yc10gWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRm LTxicj4NCmkybnNmLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24tMDg8YnI+DQo8YnI+DQpbYWRk aW5nIGluIGlwc2VjQF08YnI+DQo8YnI+DQpIaSw8YnI+DQo8YnI+DQpUaGlzIGRyYWZ0IHdhcyBk aXNjdXNzZWQgaW4gaXBzZWNtZSBhdCB0aGUgbGFzdCBJRVRGLCBhbmQgdGhlcmUgd2FzIGE8YnI+ DQpkZXNpcmUgdG8gbG9vayBjbG9zZXIgYXQgYSBjb3VwbGUgY2hhbmdlcyB0aGF0IHdvdWxkIG1h a2UgdGhlc2UgbW9kZWxzPGJyPg0KdXNhYmxlIGJ5IGlwc2VjIGdlbmVyYWxseSByYXRoZXIgdGhh biBvbmx5IGZvciBTRE5zLiBPdGhlcndpc2Ugd2Ugd2lsbCBlbmQ8YnI+DQp1cCB3aXRoIDIgbW9k ZWxzIHRoYXQgbG9vayB2ZXJ5IHNpbWlsYXIgYW5kIGR1cGxpY2F0ZSBhbG1vc3QgYWxsIHRoZTxi cj4NCmZ1bmN0aW9uYWxpdHkuIFRoaXMgd2FzIGdvaW5nIHRvIGJlIGRvbmUgZHVyaW5nIHRoZSBu ZXh0IHlhbmcgZG9jdG9yPGJyPg0KcmV2aWV3LCBidXQgaXQgbG9va3MgbGlrZSB0aGF0IGhhcHBl bmVkIGluIHRoZSBtZWFudGltZSAoc2hpcHMgaW4gdGhlPGJyPg0KbmlnaHQpLjxicj4NCjxicj4N CkF0IG1pbmltdW0gdGhlIG1vZHVsZSBuYW1lcyBzaG91bGQgaW5jbHVkZSAmcXVvdDstc2RuLSZx dW90OyBpZiBubyBvdGhlciBjaGFuZ2VzIGFyZTxicj4NCm1hZGUgdG8gaW5kaWNhdGUgdGhhdCB0 aGV5IGFyZSBvbmx5IGZvciBzZG4gdXNlOyBob3dldmVyLCB0aGlzIGlzIG5vdCB0aGU8YnI+DQpv cHRpbWFsIHNvbHV0aW9uLjxicj4NCjxicj4NCkEgYmV0dGVyIHNvbHV0aW9uIHdvdWxkIGJlIHRv IG1vdmUgdGhlIGNvbnRhaW5lcnMgY3VycmVudGx5IHVuZGVyIGlrZWxlc3M8YnI+DQooZm9yIFNB IGFuZCBQb2xpY3kgZGF0YWJhc2VzKSB1bmRlciBpcHNlYy1jb21tb24uPGJyPg0KPGJyPg0KVGhl IGZlZWRiYWNrIEkgcmVjZWl2ZWQgZnJvbSB0aGUgYXV0aG9ycyB3YXMgdGhhdCB0aGUgU0ROIGNv bnRyb2xsZXJzPGJyPg0KZGlkbid0IGNhcmUgYWJvdXQgdGhlIGFjdHVhbCBTQXMgYW5kIHBvbGlj aWVzIHdoZW4gdXNpbmcgSUtFIHNvIHRoZXk8YnI+DQpkaWRuJ3Qgd2FudCB0byByZXF1aXJlIHNv bWVvbmUgaW1wbGVtZW50aW5nIGlrZStjb21tb24gbW9kdWxlcyB0byBoYXZlIHRvPGJyPg0Kc3Vw cG9ydCB0aGVtLjxicj4NCjxicj4NClRoZSBZQU5HIHF1ZXN0aW9uIEkgc3VwcG9zZSBpcywgaXMg dGhlcmUgYW4gZWFzeSB3YXkgdG8gbW92ZSB0aGVzZTxicj4NCmNvbnRhaW5lcnMgZnJvbSBpcHNl Yy1pa2VsZXNzIHRvIGlwc2VjLWNvbW1vbiwgYnV0IHN0aWxsIGFsbG93IGZvciB0aGVtIHRvPGJy Pg0KYmUgZW1wdHkgYW5kL29yIHVuaW1wbGVtZW50ZWQgZm9yIHRoZSBTRE4gSUtFIHVzZSBjYXNl PyBJZiB0aGV5IHdlcmUgbWFkZTxicj4NCmZlYXR1cmVzLCBpcyB0aGVyZSBhIHByb3BlciBZQU5H IHdheSB0byBpbmRpY2F0ZSB0aGF0IGlmIHRoZSBpa2VsZXNzPGJyPg0KbW9kdWxlIGlzIHByZXNl bnQgdGhlbiB0aG9zZSBmZWF0dXJlcyBtdXN0IGFsc28gYmUgc3VwcG9ydGVkIHRodXMgbWF0Y2hp bmc8YnI+DQp0aGUgZnVuY3Rpb25hbGl0eSBhcyBkZWZpbmVkIGJ5IHRoZSBjdXJyZW50IGRyYWZ0 Pzxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpDaHJpcy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDI0LCAy MDIwLCBhdCAxMDozNyBBTSwgTWFydGluIEJqw7Zya2x1bmQgdmlhIERhdGF0cmFja2VyPG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7PGEgaHJl Zj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmciPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90 ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KUmV2aWV3ZXI6IE1hcnRpbiBCasO2cmtsdW5kPGJyPg0KUmV2aWV3IHJlc3VsdDogUmVhZHkg d2l0aCBOaXRzPGJyPg0KPGJyPg0KSSBkaWQgYW4gZWFybHkgWUFORyBEb2N0b3IncyByZXZpZXcg b2YgdGhpcyBkcmFmdC4gJm5ic3A7TW9zdCBvZiBteTxicj4NCmNvbW1lbnRzIHRoZW4gaGF2ZSBi ZWVuIGFkZHJlc3NlZCBpbiB0aGlzIHZlcnNpb24uPGJyPg0KPGJyPg0KQ29tbWVudHM6PGJyPg0K PGJyPg0KbyAmbmJzcDtBcyBJIHdyb3RlIGluIG15IGVhcmx5IHJldmlldywgdGhlIFJGQyBlZGl0 b3IgZW5mb3JjZXMgYSBjb21tb248YnI+DQombmJzcDtmb3JtYXQgb2YgWUFORyBtb2R1bGVzLCBz byBpdCBpcyBiZXR0ZXIgdG8gYWRoZXJlIHRvIHRoaXMgZm9ybWF0PGJyPg0KJm5ic3A7YmVmb3Jl IHNlbmRpbmcgdGhlIGRyYWZ0IHRvIHRoZSBSRkMgZWRpdG9yLiAmbmJzcDtVc2U8YnI+DQo8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDtweWFuZyAtZiB5YW5nIC0teWFuZy1saW5lLWxlbmd0aCA2OSAm bHQ7RklMRSZndDs8YnI+DQo8YnI+DQombmJzcDt0byBnZXQgYSBjb25zaXN0ZW50IGxvb2stYW5k LWZlZWwgZm9yIHlvdXIgbW9kdWxlLjxicj4NCjxicj4NCiZuYnNwOyhZb3Ugd2lsbCBoYXZlIHRv IG1hbnVhbGx5IHJlLWZsb3cgZGVzY3JpcHRpb24gc3RhdGVtZW50cyBhZnRlcjxicj4NCiZuYnNw O3RoaXMuKTxicj4NCjxicj4NCjxicj4NCm8gJm5ic3A7VGhlcmUgYXJlIHNvbWUgbGVhZnMgdGhh dCBhcmUgb3B0aW9uYWwgaW4gdGhlIG1vZGVsLCBidXQgdy9vIGE8YnI+DQombmJzcDtkZWZhdWx0 IHZhbHVlIGFuZCB3L28gYW4gZXhwbGFuYXRpb24gb2Ygd2hhdCBoYXBwZW5zIGlmIHRoYXQgbGVh Zjxicj4NCiZuYnNwO2lzIG5vdCBzZXQuICZuYnNwO1lvdSBzaG91bGQgZmluZCB0aG9zZSBhbmQg ZWl0aGVyIG1ha2UgdGhlbSBtYW5kYXRvcnksPGJyPg0KJm5ic3A7YWRkIGEgZGVmYXVsdCB2YWx1 ZSwgb3IgZXhwbGFpbiB3aGF0IGl0IG1lYW5zIHdoZW4gaXQgaXNuJ3Qgc2V0Ljxicj4NCiZuYnNw O0FzIGFuIGV4YW1wbGUsPGJyPg0KJm5ic3A7L2lwc2VjLWlrZS9wYWQvcGFkLWVudHJ5cGVlci1h dXRoZW50aWNhdGluL3ByZS1zaGFyZWQvc2VjcmV0PGJyPg0KJm5ic3A7aXMgb3B0aW9uYWwuICZu YnNwO0kgc3VzcGVjdCB0aGF0IHRoaXMgbGVhZiBuZWVkcyB0byBiZSBtYW5kYXRvcnkuPGJyPg0K Jm5ic3A7QW5vdGhlciBleGFtcGxlIGlzIHRoZSBsZWFmIGVzcGVuY2FwLjxicj4NCjxicj4NCjxi cj4NCi9tYXJ0aW48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCnlhbmctZG9jdG9ycyBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86eWFuZy1kb2N0b3JzQGlldGYub3JnIj55YW5nLWRvY3RvcnNAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by95YW5nLWRvY3RvcnMiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8veWFu Zy1kb2N0b3JzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6 YmxhY2siPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08YnI+DQpSYWZhIE1hcmluLUxvcGV6LCBQaEQ8YnI+DQpEZXB0LiBJbmZvcm1hdGlvbiBh bmQmbmJzcDtDb21tdW5pY2F0aW9ucyZuYnNwO0VuZ2luZWVyaW5nIChESUlDKTxicj4NCkZhY3Vs dHkgb2YgQ29tcHV0ZXImbmJzcDtTY2llbmNlLVVuaXZlcnNpdHkgb2YmbmJzcDtNdXJjaWE8YnI+ DQozMDEwMCBNdXJjaWEgLSBTcGFpbjxicj4NClRlbGY6ICszNDg2ODg4ODUwMSBGYXg6Jm5ic3A7 KzM0ODY4ODg0MTUxIDxhIGhyZWY9Im1haWx0bzpyYWZhQHVtLmVzIj5lLW1haWw6Jm5ic3A7cmFm YUB1bS5lczwvYT48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6Q291cmllcjtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MN2PR11MB4366E30B3C372D13B391AE07B53B0MN2PR11MB4366namp_-- From nobody Tue Sep 22 09:22:34 2020 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 D70483A0816; Tue, 22 Sep 2020 09:22:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=btconnect.onmicrosoft.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 Hkk2aoGUrkh0; Tue, 22 Sep 2020 09:22:25 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40090.outbound.protection.outlook.com [40.107.4.90]) (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 0F9523A052C; Tue, 22 Sep 2020 09:22:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m+Nqds+h/MJ6kc4ocvBesFbRXRddcOsWfsW+x8j/P+tSVCMmh+rTi+gBpSLqT6g30rmogI0Co01HuFW5cUP3Sh2MIX/rLvBKp3RAFAZUrpSIff1NdjbmoIVYKnYhaqnHkNsXV7CPlZIwyl8MTpir2TQGU5FypCNombQQxefp+P9dLvbbIb7/Jsfu4V2w2XlgNAFGUulYCdosEvYh4HXrwYhK+w/H4ZJGZoU+HKLwJys7mirGQxyUL2tfmWgoPVnnHPtcAtMirFd2HjP8uyOCE1/S5QTmLIAHW0hK5j3bVWSylAL+weBcvjxcSXNjkxor9zexcIvxwyNihytk3qTw4w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iMMXvmSqFwh8FZBuaoYRDZDSRoO14tg1dX5KX4ZQzBs=; b=moDRMeRT7iWcjrnPdsYFV9hZOF8v77qsbO8ZA8Gcp1MSld04DANNpFkD0nvLmGqfBSdxDnZXYANnWwaK6ZhrKMIk7yqJlFe0der3lzNUTCIlIbTKCuCh62cAmhfT4H+kzP1GHKLiUQoX81IwvrCSZJ/wX0ZkjwOIMyyvZRimlDrJk3xiyaV7wGYTL9Q1uXJbqbhcZC5jY3BS0MO1ylQnm2swrv9hp+rhvwIGfuRaTdh583aFPL9IwV/+OLmNtpWJ4sPo85gzgrZYhLsBeInaUWYuWe+dFdA5E1FKn0xxCBuEj9nw7vTl6qiRDG5Bq+YjpBfbHl0UX1oQ3xPq2WmPHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iMMXvmSqFwh8FZBuaoYRDZDSRoO14tg1dX5KX4ZQzBs=; b=YBkf2rJXm4ORPODrBzjkJWZ6m4XdnbJ/CwrICXCzMqYAQDIPQH/DccCQa9qqmBWh0Ph8pBIhpc4L+T1WSCcd/97ve30T865ks4SBlesOA46QytMM/HXl25t3xxzHDKG0LYwwAcZetwVldNcyMB921PvB2fO+BKLRSS0OfXvrS24= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB5502.eurprd07.prod.outlook.com (2603:10a6:803:b7::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.4; Tue, 22 Sep 2020 16:22:21 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db%5]) with mapi id 15.20.3412.020; Tue, 22 Sep 2020 16:22:21 +0000 To: "Rob Wilton (rwilton)" , Rafa Marin-Lopez References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> Cc: "i2nsf@ietf.org" , Gabriel Lopez , Christian Hopps , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , "yang-doctors@ietf.org" From: tom petch Message-ID: <5F6A24BA.7040802@btconnect.com> Date: Tue, 22 Sep 2020 17:22:18 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0122.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::14) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.153.136.175) by LO2P265CA0122.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3412.20 via Frontend Transport; Tue, 22 Sep 2020 16:22:20 +0000 X-Originating-IP: [86.153.136.175] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fd1ac7f5-8887-4f33-85fd-08d85f13aeb5 X-MS-TrafficTypeDiagnostic: VI1PR07MB5502: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: H48V7r7JbpSExxuPAX+tJQp9PjwBF0Uug7m+E44vCnKzbUhwvso/S8pAWNSXD2fb0KQHepS67mh108gGwVGrXXzbbkyuct7XMG/pQD/oUk94OJOgaoLh9ooUUUka3uvJ8nLApvmoOAxxGYgik6QOevkYbAf0QvLkHqSe+Wm0tGr3Rfj1VzBS/UUUHf6jHFfQFWhkzeFX4atD9qL1iKWwAXGhkg+HgF9OScdUULXYyovAut5ATD7cXfT70b9FdUHUCJS+9dIBH1SLkupSX4QtpSXGQWyMMfp9PXc2MneC38i7XbMPFztewRJUyCX/FBn7Nxf1uYJM3bI4GmtJOyFdMguIbxAqLkVCaYtEoysOjwfxoQdE+GzQB4GmBnhqS9NJajkI19CUQHXn43dFYwex526ZncY+EEj24nOIb2mmD2FQ6naF6JU5cFqMU5D8URItHRYlaSbJwwYp2bHYoAV0kA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(39860400002)(346002)(376002)(396003)(54906003)(956004)(2616005)(36756003)(53546011)(316002)(16576012)(86362001)(8676002)(66556008)(6486002)(7416002)(966005)(26005)(66946007)(33656002)(110136005)(16526019)(186003)(4326008)(83380400001)(5660300002)(87266011)(478600001)(52116002)(66476007)(8936002)(66574015)(2906002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: u/xPP+TvyBOmUotdhXfmx6IGbrVv9inzil1ynkHQuMTtL223+sAHyQr34iafQPDoiob8kxRRc6JQfY3IyI3F2YcnuVsEnyB+Ro5axMu0X94LsNuY2Noe1tPlFdOB8gWsCgO/wt7s1aBRCkoQwf26fVOPrjrDQxPKp/82SvojgLprCTNn0Xrm+GrnNVGj5mO4KveKfpKQhNS7cMSf+0W5RHC04E26nG6szo21Ye4kO+dE9pcEK2I5v5xt7jZxXJ7QK9V7hhL50WrMOZPrlC1jfPMGS1giB/10osYsXujk2SPk8MuXt6rqLOr2meTCdvKQRqj04jNvO/EtBcah1VWH1t0alTUyHME3n8AGsz/qtlWlptJBmT73c/ymWFZyzcZKepqiD6r3HdlDvnvG6V6TR6ZIxIO66v1edN3kbpE1LG2TiaCzQ1gg01BX7WZ3dWI8gWBOsl581VOI2VwZfkICwbiYa05mYhYg8ZXvU2QX6JYL7hvVO+PgmnqxlFAqdL/PjbbwUPvZKOP8DXsStkuKEj9f7E25GY4pzcLa2GgBA8jq7aNmv9+hRt7JN8Xirdjl/a83xGKDqRkAS/8c+usnL0MDHrGk7eZvmS6EGz+yq89CLLgE1W73f7MmbPjFvqJtUOpg2w8/PAuAP/Rqcf8x9Q== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: fd1ac7f5-8887-4f33-85fd-08d85f13aeb5 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Sep 2020 16:22:21.5125 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 16kbi/sxABFd6I+8WD63s3zD4XsC//7WJvEiGUmlUAuzwiHYCBjTufiRu6OY9lBY7UH1bhKus0dckATZvn0gvQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB5502 Archived-At: Subject: Re: [IPsec] [Last-Call] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 22 Sep 2020 16:22:28 -0000 On 22/09/2020 16:38, Rob Wilton (rwilton) wrote: > Hi Rafa, > > Thanks for getting back to me. > > Yes, changing the name of the module is an okay, if not ideal, > resolution. But I appreciate that you also want to be done with this > work. > > But I would like to check: My understanding is that the changes that > Chris is proposing are pretty small. I.e. move the SA structure > under ipsec-common, and put it under a YANG feature. Are you sure > that it is impractical to accommodate this change which would allow a > single ipsec module to be shared and extended via YANG > augmentations? Rob As you say, the changes look feasible and IMHO will pay for themselves long term. But another point to consider is the prefix or prefixes. Note that the current I-D has ike and ikeless which could cause much confusion depending on what this I-D ends up containing. There are a number of related i2nsf modules and a number of different unrelated prefix. I have encouraged authors to use nsf... for prefix and would encourage that even more strongly if the only change here is to the module name. As you know, imports of an IETF module by an IETF module have to use the prefix defined in the module. Tom Petch > Thanks, Rob > > > From: Rafa Marin-Lopez Sent: 22 September 2020 14:05 To: > Rob Wilton (rwilton) Cc: Rafa Marin-Lopez > ; Christian Hopps ; Gabriel Lopez > ; > draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; > i2nsf@ietf.org; ipsec@ietf.org; last-call@ietf.org; > yang-doctors@ietf.org; Martin Bjrklund Subject: > Re: [yang-doctors] Yangdoctors last call review of > draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 > > Dear Rob: > > Apologies for our delayed answer. We are now working in the revision > to submit v09 by compiling all the comments. > > As you mentioned, we want to avoid any further delay. As we mentioned > to Chris in the past (i2nsf mailing list), we do not have any problem > to include some additional text (e.g. -sdn-" in the module names). > Therefore, Rob, we agree with your point of view about this. > > In summary, we are working in the next revision v09, and our idea to > address Chris comments was to include -sdn- to the module names. > > We hope this is fine. > > Best regards. > > > El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) > > escribi: > > Hi draft authors, Chris, > > Can we also please try and close on this issue raised by Chris. > > Chris, I dont think that there is any great way to solve this issue > using YANG features, but presumably the constraint could be enforced > with a must statement, or groupings could be used to copy parts of > the ipsec structure into an sdn specific ipsec tree structure. > > I understand that there isn't any great desire to delay these drafts > by trying to generalize the ipsec YANG model contained within it. > However, I think that means that the modules should have "-sdn-" in > their names to indicate that they are intended specifically for the > SDN use case, and should not be confused with the more generic ipsec > YANG modules that have been proposed. > > Regards, Rob > > > > -----Original Message----- From: yang-doctors > > > On Behalf Of Christian Hopps Sent: 24 August 2020 18:08 To: Martin > Bjrklund > Cc: > i2nsf@ietf.org; > draft-ietf-i2nsf-sdn-ipsec-flow- > protection.all@ietf.org; > ipsec@ietf.org; > last-call@ietf.org; yang- > doctors@ietf.org Subject: Re: [yang-doctors] > Yangdoctors last call review of draft-ietf- > i2nsf-sdn-ipsec-flow-protection-08 > > [adding in ipsec@] > > Hi, > > This draft was discussed in ipsecme at the last IETF, and there was > a desire to look closer at a couple changes that would make these > models usable by ipsec generally rather than only for SDNs. Otherwise > we will end up with 2 models that look very similar and duplicate > almost all the functionality. This was going to be done during the > next yang doctor review, but it looks like that happened in the > meantime (ships in the night). > > At minimum the module names should include "-sdn-" if no other > changes are made to indicate that they are only for sdn use; however, > this is not the optimal solution. > > A better solution would be to move the containers currently under > ikeless (for SA and Policy databases) under ipsec-common. > > The feedback I received from the authors was that the SDN > controllers didn't care about the actual SAs and policies when using > IKE so they didn't want to require someone implementing ike+common > modules to have to support them. > > The YANG question I suppose is, is there an easy way to move these > containers from ipsec-ikeless to ipsec-common, but still allow for > them to be empty and/or unimplemented for the SDN IKE use case? If > they were made features, is there a proper YANG way to indicate that > if the ikeless module is present then those features must also be > supported thus matching the functionality as defined by the current > draft? > > Thanks, Chris. > > > > > On Aug 24, 2020, at 10:37 AM, Martin Bjrklund via Datatracker > > wrote: > > > Reviewer: Martin Bjrklund Review result: Ready with Nits > > I did an early YANG Doctor's review of this draft. Most of my > comments then have been addressed in this version. > > Comments: > > o As I wrote in my early review, the RFC editor enforces a common > format of YANG modules, so it is better to adhere to this format > before sending the draft to the RFC editor. Use > > pyang -f yang --yang-line-length 69 > > to get a consistent look-and-feel for your module. > > (You will have to manually re-flow description statements after > this.) > > > o There are some leafs that are optional in the model, but w/o a > default value and w/o an explanation of what happens if that leaf is > not set. You should find those and either make them mandatory, add a > default value, or explain what it means when it isn't set. As an > example, > /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret is > optional. I suspect that this leaf needs to be mandatory. Another > example is the leaf espencap. > > > /martin > > > _______________________________________________ yang-doctors mailing > list yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > > ------------------------------------------------------- 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 > ------------------------------------------------------- > > > > > > ob As you From nobody Tue Sep 22 09:47:01 2020 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 959993A1818; Tue, 22 Sep 2020 09:46:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 85e-3swCdJ40; Tue, 22 Sep 2020 09:46:57 -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 C225E3A1758; Tue, 22 Sep 2020 09:46:56 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BwnJs5cxkzCQ5; Tue, 22 Sep 2020 18:46:53 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1600793213; bh=JM3kA4jdGIhiwpfr6T2iec3Nvb6IEzAEXOhGaqKFc1w=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RlN0kAz7i5ZhspJjvt2A+ryIQ18r2UMq8gd6GouykRTjVJx0W9rAZ4puHCdKi0pLM hcn9MfYNL637NT4/kpeaVvtUHgYZZakaSl6r5xyVi4lCPP6EWR6I4f422h3iiUCYm8 UKj/32U4X6lw9lju4+TZVkaX76jvlfquTvt0b09o= 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 maTEgYYELt1a; Tue, 22 Sep 2020 18:46:52 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 22 Sep 2020 18:46:52 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 93FE16029A7D; Tue, 22 Sep 2020 12:46:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8BC4666AF7; Tue, 22 Sep 2020 12:46:51 -0400 (EDT) Date: Tue, 22 Sep 2020 12:46:51 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: 'Benjamin Kaduk' , ipsec@ietf.org, mohamed.boucadair@orange.com, draft-btw-add-ipsecme-ike@ietf.org In-Reply-To: <0b7f01d690dc$a942cae0$fbc860a0$@gmail.com> Message-ID: References: <20200919050934.GN89563@kduck.mit.edu> <36CA437C-7F66-4603-9A36-0C5BB3A2FE05@nohats.ca> <0b7f01d690dc$a942cae0$fbc860a0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] [***SPAM***] Re: TR: New Version Notification for draft-btw-add-ipsecme-ike-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: Tue, 22 Sep 2020 16:46:59 -0000 On Tue, 22 Sep 2020, Valery Smyslov wrote: >> That is not how the CP payloads work. The initiator sends a set it is okay with and the responder picks what it >> prefers from that set. Or an error if it deems all of it bad. > > Exactly. However, with different attribute types the client can indicate its capabilities too > and can prioritize them (by adding attributes to the request in the order of client's preference). I don't think the Configuration Payload order significies a preference for anything? Does RFC 7296 really say that? >> I would still prefer a single request for encrypted DNS and a reply with servers with capabilities. Asking for all >> these different types will be more complicated. > > I don't think it's really more complicated. I agree, that current solution is more bulky in case you want to > convey all possible types of encrypted DNS, all sharing the same IP-addresses and authentication domain and > not counting non-standard ports. In other use cases it's roughly the same in size. The common case will be DNS servers that support the kitchen sink. Let's make that use case the easiest. Paul From nobody Tue Sep 22 10:50:33 2020 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 188023A0783; Tue, 22 Sep 2020 10:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 LrtTdWgfBguV; Tue, 22 Sep 2020 10:50:22 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 495963A05AC; Tue, 22 Sep 2020 10:50:20 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 2C9D41B00348; Tue, 22 Sep 2020 20:50:16 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1600797016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/lAnYT6jBUJLMq1yx0jmS5/3riCBWVKrXy+7v+qFKXY=; b=XnhjsIbzAGUAGepEj7e9LAjFHDiiDVxKW9RDzd21Nxp3Ks7o2P8jS/GdXb6mQj4xY6tCqn BTiw9a7FVv2+oso0a1zQOF350rri9iV8BVNhH3eik+DkfjKPhyRpKmhnuu2A5NHYnVXWSV k0pg77mz8EX9jWksZOAoFxFTWTGVHhOjGs+LELoEjI3awxN8SLe/Bx6j8iWDmimxFGTGvg hdaY2LndXybamWwNA8ZtC/0rU8x+G1MbuXLYIcodk3O0SaY57OO9vXNCNFIMop79TxsFqI 3x7mWYe4bNAXh57P2TjHuZQlKscDgzoH7EAS0lXqUFOl3MwpQPig8zwKC6mBfg== Received: by fireball.acr.fi (Postfix, from userid 15204) id D85C025C104B; Tue, 22 Sep 2020 20:50:15 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <24426.14679.827153.422523@fireball.acr.fi> Date: Tue, 22 Sep 2020 20:50:15 +0300 From: Tero Kivinen To: Fernando =?iso-8859-1?Q?Pere=F1=EDguez_Garc=EDa?= Cc: tom petch , Roman Danyliw , i2nsf@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org, "ipsec\@ietf.org WG" , LAST-CALL@ietf.org, i2nsf-chairs@ietf.org In-Reply-To: References: <5F44E66D.6080408@btconnect.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 9 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1600797016; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/lAnYT6jBUJLMq1yx0jmS5/3riCBWVKrXy+7v+qFKXY=; b=peucKlm7OFamchVURmruOInJ7Sdw6Xa1pqLMVcy48RTdF2V5qWxwdaSh4R6+JD9j594x2a N+q3SkSLqa39caqJkl1I7+/OgXTXFt5f7qfa41o5nTkyl2TCpH6e4zMAH3HWfg3LgmDWV4 tCUv4EKgKfWbK2cM+VkQmFtJwLz6EvtB78YvHe54G0VbtXweTjE5AC9czHB1XhNPphM1oA 3ZKspN5l4av7mVF0TRxnZDElM9XvHko1t3AZ6EHvARuQ5YOjOBpiWV7LJSunrbPcIc7X9W WuMUX6jtz7jyTFRJCPJpkG7TaE3KEhwmzTML9i5tp38005Ls/ZOWX2R4DcJrxg== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1600797016; a=rsa-sha256; cv=none; b=m3FxuznHSZfTYJb3HinkME2VMKx/52D3bQj1M0fhGtodGqI+PXZcNiQcBc58lCos/S1y2N yj+yhbeWYt40xxD3EgdlVUooNcFwugvAVwvybvSDYa5rBrNtjUOhQWxRXHIraRRXD9Qq/e qYpDS9sFRK0bQ3IvF9kcYzKSfxyA40CUvaFfCrWBk8XtRafo7sOCk/cCGTIXnTtLLq6DYa WYNg2LHPycxVRsRn3VW0jX2G3HP7efzVh0MHUAk3yA2xiD9Tp3dI/gfR7iordwyQX7ONHd rar0NNNhm4Mi3hWXWpc3e2aiEbTEGn9n+WKVcU/MIeI9vFt4Qq+IAwKoM7oECw== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Last Call: (Software-Defined Networking (SDN)-based IPsec Flow Protection) to Proposed Standard 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, 22 Sep 2020 17:50:24 -0000 Fernando Pere=F1=EDguez Garc=EDa writes: > I note that RFC822 and RFC3280 are Obsoleted which makes their us= e > problematic. >=20 > [Authors] Following your recommendation, we have replaced RFC 3280 w= ith RFC > 5280. Regarding RFC 822, we reference it because the IKEv2 protocol > specification (RFC 7296) explicitly defines RFC 822 emails address (s= ee page > 90) as a valid identification type. If we replace RFC 822 with RFC 28= 21, we > don't know its impact on IKEv2.=20 IKEv2 talks about RFC 822 email addresses, the reference points Internationalized Email Headers RFC 6532, with comment of: Because of [EAI], implementations would be wise to treat this field as UTF-8 encoded text, not as pure ASCII. So it uses RFC822 as name not as reference. There should not be any problems to replace that with newer versions. Most of the implementations simply consider that as a string and some cases they actually do not even follow the string email address format, as they add some routing information for AAAA in the end or something. --=20 kivinen@iki.fi From nobody Tue Sep 22 11:11:43 2020 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 AFDF33A1918 for ; Tue, 22 Sep 2020 11:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 qgJfTBtOdawC for ; Tue, 22 Sep 2020 11:11:39 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 B681C3A18CC for ; Tue, 22 Sep 2020 11:11:38 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 71FCB1B00431; Tue, 22 Sep 2020 21:11:36 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1600798296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WqGx8bhxG4f8fsHJKdJJKWaOSC8/c5s9HdKJaIaOi9k=; b=DxtgjpNhgjiQVmziazw5cQhxRInpGKDm1+74hhaMfQ6QoYISEAm7A66wXduob43+utTxTZ 4iYAG555BP4Y0g1kDqQtI5k1FQuGoXl029gNUVvSqC5AfImm+UPa2MqxOTvTpL1OoFazdK hviQXACL2YZFxOQ2bDzSiaiTMbSls6Ely8rgplTxMBSA4mQLIitNQhUqiVWQ0GnS46qqv8 46wjOIRWCsZLT9JXb8wMhPZx+n6mzTQ9cB5XP/7oMvTBqlixT7zT+HBxYeNx/Eo9dYHB6V XPFaUwnptfN1sWMnAaiLRfoC5e5UYzMLO5bLDkOF2yFeAu+gWrcd/OnfiXnkbQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 1DA4925C104F; Tue, 22 Sep 2020 21:11:35 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24426.15958.874046.766670@fireball.acr.fi> Date: Tue, 22 Sep 2020 21:11:34 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: "IPsecME WG" In-Reply-To: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1600798296; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=WqGx8bhxG4f8fsHJKdJJKWaOSC8/c5s9HdKJaIaOi9k=; b=HtdUwcsqF9bBYPzDZ53c6LqSO82DKgA0jxtovG/C5k63MCpE8lmR22M1cH0Eyt0D5qBZdl 5xXaJ7CRqQ12LageGptE8rvDphbBA/fEEK4snPOaV5QmvImRLhSvNLqc5LUheq/fZmDLao ASDMRiDjsHsyEXxJHfmUCG3U1U3eFjb4nbmhkWVbiAEYjwcttd/G1fUxVJMtg1B5RwFhO3 uvNgFeu5NZPBOu1XmH/QIHRYycYgQRMetfif0WfmbVETkbDJ7Idrxdq7YJqsxX9RZ8gpdP xPy5gfpaVLRr5acAReFzDXxy6NsL8KVMi3hK6B5a8clBmNi/LZu/G7nuUBOgJg== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1600798296; a=rsa-sha256; cv=none; b=VZ0QBTB7YGjnknGalkUzqODrmyk183Jq0lqN2esX/zJ65xZBgbS4uNFECGe6MmyF/2nvQD nCHltsStkdmeUHN8Rmp3oB7WxEs11RdZA6cteaQOo5YdKMYrUZVkcxe+oqFmP1PulINMpR bifEBW4MFpamIQUpFuJXPEhO/79ICNBd4jD8qa7sYZ4lYlxwVjgYg5/zd0fcYaTijqJlIh cFPa7CWgG0d/2foya6NAVi7gwgIX7S6F1CVLUqG2G3THFauM+iyRHRUIuYA1fpXUEsKq0y nfxxNk36rWZPlk1JzB+Q8h2YPpPeUZtg9QAWFwAiqdN12SuBkiI/J/I3uCM2hA== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: [IPsec] Cookie logic results in failed authentication 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, 22 Sep 2020 18:11:42 -0000 Valery Smyslov writes: > I believe that the proper solution would be to exclude cookie from > the AUTH payload calculation. It is verified by the responder using > cookie generation secret and it is not concerned with a client (the > client did not generate it, just echoes it back). However, this > solution is obviously incompatible with RFC7296, so this is not an > option. Simple solution. Do not change cookie generation secret too often if you are under attack with really crappy network... I mean if the attackers are sending blind connection attemps where cookies help, changing the cookie does not make any difference. If the attackers are using real DDoS where each attack packet is actually a host which will reply to your cookie request then again changing cookie secret does not help. Only case where changing cookie secret helps is that attacker cannot collect thousands of valid cookie responsenses and then suddenly send them all out. Or you could try to make sure that the cookie secret selection is stabile for the same peer always for longer time, i.e. remember some state that you used cookie secret x for following sessions before changing to new one. After the cookie secret is changed and enough time has gone by, you can forget that list and old secret, and you only need to start collecting that list at the point when you are planning to change cookie generation secret again soon. If you have 10000 incoming connections per second and you consider 300 seconds for suitable timeout for sessions to finish, and you only store source ipv4-address for each time you used cookies, you need 11 MB of memory for that state (and that assumes none of the incoming sessions are actually coming from same ip-address). > Any opinions? Should this problem be addressed by the WG or ignored? I think the long term solution is to do puzzles, as I do not think you need to change puzzles secrets that often compared to the cookie secrets. -- kivinen@iki.fi From nobody Tue Sep 22 11:32:09 2020 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 682BE3A0A66 for ; Tue, 22 Sep 2020 11:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 FmFhxwhbmTL0 for ; Tue, 22 Sep 2020 11:32:05 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [195.140.195.201]) (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 9AFDC3A0A21 for ; Tue, 22 Sep 2020 11:32:05 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id AFDD720592; Tue, 22 Sep 2020 21:32:02 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1600799522; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oYGVFO5nKj8dn/FAzuacNumfwipiPLI+n3lWYW6Xfow=; b=GyJ3Xhw227WENWpvRmCItJP8sR5ciDbs5ff0E8m1vM8vBqo+wiAzpcFrBcEk6qqW+4xnSH zYizP5FCciul521nUe8Q0x8LG8s7fTtLZwlkP/QdsSaG3A1cUa1aV8SthDW0pTL7ee/M/O VmgFxfRQ4Wj4gsELzL4Tv1PrzsZ8pCM= Received: by fireball.acr.fi (Postfix, from userid 15204) id 4CC4C25C0B93; Tue, 22 Sep 2020 21:32:02 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24426.17186.275023.44982@fireball.acr.fi> Date: Tue, 22 Sep 2020 21:32:02 +0300 From: Tero Kivinen To: "Panwei \(William\)" Cc: Valery Smyslov , IPsecME WG In-Reply-To: References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 19 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1600799522; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=oYGVFO5nKj8dn/FAzuacNumfwipiPLI+n3lWYW6Xfow=; b=WAkmEINBS5lUM0w+XgLcCey13F2kynA9uIoQIuQZ4IcyNqVAo2c0vHmqCGgA5z0djzxpIG aCqXXgIT5Rxgyu+HRK2LT1PDlILtSd4vnbVLJYq8pSqcxhmMJYn10sb3BbvbmIUNm0yR7z teMZXBFfGvh9urGbizyBd9gEf9A4W24= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1600799522; a=rsa-sha256; cv=none; b=ppQPj5L54E4EGeE04hpAzfXssZ48b45jJUS/vNDYm0U/rEy6VbWaLi2DPqmpm0dSRHQudK Pllv166tWMZXhg5W/M5Ady3iHAcrVIae6HMrYC1875OIVx5Zl6R4LBn8vqsWkyqVouTsRy lruDxgp1fDqdBiACzjKTTOiTdPDHVIE= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 22 Sep 2020 18:32:07 -0000 Panwei (William) writes: > It seems like a rare scene but I think it needs to be considered. > Compared with ignoring cookie payload, how about adding N(COOKIE2) > in the 9th message? Then when Initiator received the 12th message, > it'll know which cookie this message matches with. Actually I think the best option is to include the N(COOKIE) in the Initiators IKE_AUTH too. I.e.: Initiator Responder ------------------------------------------------------------------- 1. HDR(A,0), SAi1, KEi, Ni --> 2. delayed<-- HDR(A,0), N(COOKIE1) 3. HDR(A,0), SAi1, KEi, Ni --> 4. <-- HDR(A,0), N(COOKIE2) 5. HDR(A,0), N(COOKIE2), SAi1, KEi, Ni --> 6. delayed received here 7. HDR(A,0), N(COOKIE1), SAi1, KEi, Ni --> lost 8. <-- HDR(A,B), SAr1, KEr, Nr, [CERTREQ] 9. HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr, N(COOKIE1)} --> ^^^^^^^^^^ Added here. 10. <-- HDR(A,B), SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Now when Responder receives IKE_AUTH at step 9, it will decrypt that and it can see that Initiator thinks the cookie is COOKIE1, and it can then reconstruct the packets initiator is using for his calculations. Of course it needs to assume that initiator did not change order of payloads or anything else when it swiched from COOKIE2 to COOKIE1, i.e., that only difference in step 5 and step 7 packets is the cookie payload contents. This kind of change would most likely be backward compatible, i.e., old responders would simply ignore the extra notify payload in IKE_AUTH and old initiators would not simply even send it. -- kivinen@iki.fi From nobody Tue Sep 22 11:38:40 2020 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 5688F3A0B1A; Tue, 22 Sep 2020 11:38:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 CYZj7mFrj-M3; Tue, 22 Sep 2020 11:38:36 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 B985D3A0AB1; Tue, 22 Sep 2020 11:38:36 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 802E5202E7; Tue, 22 Sep 2020 21:38:33 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1600799913; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=W5a9EulwtSxcRq2NrJbnF+DwrIbmuwLXiKTzIP6L1m8=; b=iaBDxtuNS4pgEdn184fsIsxF7v9UGpolPMiNu8dJ2b7C3zAhxTGGqycW3smJ5s8osKMraK s+vLz6i4o4FUTataB29x32qVILJcCMrBbkavO4KNsEP/hETJVmukV9/v9pw45T5m3vFaIv BXYk2W78Hw6Rx44+fDPso1jKP9zGr9c= Received: by fireball.acr.fi (Postfix, from userid 15204) id 2953325C0B93; Tue, 22 Sep 2020 21:38:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24426.17577.122661.798588@fireball.acr.fi> Date: Tue, 22 Sep 2020 21:38:33 +0300 From: Tero Kivinen To: Paul Wouters Cc: Valery Smyslov , ipsec@ietf.org, draft-btw-add-ipsecme-ike@ietf.org, mohamed.boucadair@orange.com, 'Benjamin Kaduk' In-Reply-To: References: <20200919050934.GN89563@kduck.mit.edu> <36CA437C-7F66-4603-9A36-0C5BB3A2FE05@nohats.ca> <0b7f01d690dc$a942cae0$fbc860a0$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 5 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1600799913; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=W5a9EulwtSxcRq2NrJbnF+DwrIbmuwLXiKTzIP6L1m8=; b=DbifCV1mbRx0m5eQJKk9QelhPK8DMZhyhLa6LohwEQasyFuMhuzpr9apZz6d+bEUFuFBc2 TI9yYcIK0J2eaZZ92wJ+P6Pu2lmtPqq+OsSMrSg8DRVT+FEBFsFYFK1Q7CFgTMl81HP0Au eVEpkbPTvoFjrVWR0EuX4POf0pw7QMs= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1600799913; a=rsa-sha256; cv=none; b=LdxQP2DeMDgvZx/Cxn1jES+k4x8bmEWVPG0u91D0O4FumXAmeIeLREE9U3/OQTzIoL8Q+2 rxwZ67+aHWevjfP05XCHEYFy2+OpBCQ6i160Lp2Kl5nwWOxZTR3FZR4DDGLigpAIa3pq5W txYZ1s6iHnu3jUtytG4xEtZANAfa9f4= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] [***SPAM***] Re: TR: New Version Notification for draft-btw-add-ipsecme-ike-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: Tue, 22 Sep 2020 18:38:38 -0000 Paul Wouters writes: > On Tue, 22 Sep 2020, Valery Smyslov wrote: > > >> That is not how the CP payloads work. The initiator sends a set > >> it is okay with and the responder picks what it prefers from that > >> set. Or an error if it deems all of it bad. > > > > Exactly. However, with different attribute types the client can > > indicate its capabilities too and can prioritize them (by adding > > attributes to the request in the order of client's preference). > > I don't think the Configuration Payload order significies a > preference for anything? Does RFC 7296 really say that? Not exactly. It does say that for Security Association Payloads, and I think mostly people have been assuming that same applies for other things too (like CERTREQs, or Hash algorithm negotiation of RFC 7427). It would be logical to assume same applies to the Configuration Payloads, for example the first DNS server address is the preferred, or the first INTERNAL_IP_ADDRESS returned is preferred one and others are aliases... -- kivinen@iki.fi From nobody Tue Sep 22 23:15:29 2020 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 6A67C3A09C5; Tue, 22 Sep 2020 23:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=upct.onmicrosoft.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 EoWzim3QhGYE; Tue, 22 Sep 2020 23:15:22 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80057.outbound.protection.outlook.com [40.107.8.57]) (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 C18C03A09C1; Tue, 22 Sep 2020 23:15:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ods8gQb5xuunxWAE1XLTx3GpNynzAooYkPhvdEmNtlZ+og96LPiQZjilvID/8gsvKe4PgKuJoDmW/ncRvAyQuQJMOHCKH6tHKtBPoxLjKWiLvzAPchh9AxLGQUyBn2p6cgsWEHIjLwMVg3P9sPwKVS8L5M8fZ4P6jvqaTpvJ8Il6i2hr+3/rCzamsAA4hBXpaYFLur+WLO/TcSYOP1i2CGiR4/9pspsufsQ8ZimPMG4b7xTgfAMl2RE9Ly5Le2ZwsF5W0F8HZi7kQFYIdN8rPJcPKRXRy+h6l75GlbML+UTGfYa4nGjuFL8sVzagdju/uTS71F0tSFKE1Am/6nCLjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r824CV6PuBURY8Qli2trjlZ6CYlmi8Wx+9uvPNNcIdI=; b=c8F6csVLonyA0RFmqbcDMYSPeriBLmVOP7r0UFbX5eMHHxanwco4bZYNy/3MnMakUP1ZdqNeq3WzZ84maZ7Gq0AUZuFwCQRvDzXt6SZQSK66macyliEJPsyA1NwetbQfk54d7oZr5qxkfQN2qjpBm6Qx9u8XIDWwElxItNcNoPgjDWvNk/E6LpoUKPgZh8mZ8OaYp64wVHUl/5h5Ak+WajY+Dcxkhqz6qf5if24QPNHqYQPJ4wtPEnLe+b3o4EwlKzkOVWVYmyApZwnWIdjeFLA0UgVEKp+T9ue3eCVvMpxJACfws9ZoSOgkAFQyJoQJNOn4iqSfvlA2rmO6l+mcYA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cud.upct.es; dmarc=pass action=none header.from=cud.upct.es; dkim=pass header.d=cud.upct.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UPCT.onmicrosoft.com; s=selector2-UPCT-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=r824CV6PuBURY8Qli2trjlZ6CYlmi8Wx+9uvPNNcIdI=; b=MBvVBTJ0oRf6Rh7ZDVpYn57ND/MNwgMamFP26gxQPkQZOjG2Uvjfwkv8aQ/8F8wJK3ghi2MuL2Cp2xOkAcJG/G9Sy2tEAxRyh927lMVMqkjZ1w3Jsk1zkaaTW0jrax5etQk+ISV5b2gO7gUZmjk4hmJOOPDrxkk/s0xdhzIeC1I= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cud.upct.es; Received: from AM6PR08MB4936.eurprd08.prod.outlook.com (2603:10a6:20b:eb::14) by AM6PR08MB3685.eurprd08.prod.outlook.com (2603:10a6:20b:6f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20; Wed, 23 Sep 2020 06:15:19 +0000 Received: from AM6PR08MB4936.eurprd08.prod.outlook.com ([fe80::ed14:ea08:3412:88eb]) by AM6PR08MB4936.eurprd08.prod.outlook.com ([fe80::ed14:ea08:3412:88eb%6]) with mapi id 15.20.3391.024; Wed, 23 Sep 2020 06:15:19 +0000 X-Gm-Message-State: AOAM532C5V3lmFC7nrKbVNlJGM6ixJM/0kLjaJXc8X9viaia1zsX+Xhi gPOGay1/yPH87Bdx+9iy2nTTe6tRO1ds5YA5eb4= X-Google-Smtp-Source: ABdhPJylprhzElFffz0+e8OcGG4uQIQ12EMS4mXufNsA/0BvagJXepytVC54Rgd6jFLMYO2iSD0uFPZp9MuvkTDjhEk= X-Received: by 2002:a17:906:c191:: with SMTP id g17mr9025387ejz.117.1600841715300; Tue, 22 Sep 2020 23:15:15 -0700 (PDT) References: <5F44E66D.6080408@btconnect.com> <24426.14679.827153.422523@fireball.acr.fi> In-Reply-To: <24426.14679.827153.422523@fireball.acr.fi> From: =?UTF-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= Date: Wed, 23 Sep 2020 08:16:14 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Tero Kivinen Cc: tom petch , Roman Danyliw , i2nsf@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org, "ipsec@ietf.org WG" , LAST-CALL@ietf.org, i2nsf-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000c83cbc05aff50189" X-ClientProxiedBy: AM0PR02CA0033.eurprd02.prod.outlook.com (2603:10a6:208:3e::46) To AM6PR08MB4936.eurprd08.prod.outlook.com (2603:10a6:20b:eb::14) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mail-ej1-f47.google.com (209.85.218.47) by AM0PR02CA0033.eurprd02.prod.outlook.com (2603:10a6:208:3e::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.21 via Frontend Transport; Wed, 23 Sep 2020 06:15:17 +0000 Received: by mail-ej1-f47.google.com with SMTP id j11so26185628ejk.0; Tue, 22 Sep 2020 23:15:17 -0700 (PDT) X-Gm-Message-State: AOAM532C5V3lmFC7nrKbVNlJGM6ixJM/0kLjaJXc8X9viaia1zsX+Xhi gPOGay1/yPH87Bdx+9iy2nTTe6tRO1ds5YA5eb4= X-Google-Smtp-Source: ABdhPJylprhzElFffz0+e8OcGG4uQIQ12EMS4mXufNsA/0BvagJXepytVC54Rgd6jFLMYO2iSD0uFPZp9MuvkTDjhEk= X-Received: by 2002:a17:906:c191:: with SMTP id g17mr9025387ejz.117.1600841715300; Tue, 22 Sep 2020 23:15:15 -0700 (PDT) X-Gmail-Original-Message-ID: X-Originating-IP: [209.85.218.47] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 965db98a-8f05-4095-f553-08d85f880b12 X-MS-TrafficTypeDiagnostic: AM6PR08MB3685: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IO/Y5kftCzhAZ/JHf3z9wl6gRs99wZkj37WGk6EQCzQJnuf50G32Tci0B5JiWh2NRRvDhHHJmCwZVixsihLliGpeY/zesSa3C3a0gTlHmxD3TIw8c/jF84Lba9+iUMWdq++VPDrePuw98AuTjyhAH+2BU12+juLoiZFP1tZ7a+ewB3jM9UNUxKZnJ16LLJ5D0J3EjtY2H9oNXE/7156jia2QoqkbKSt0knyiaorW6jVcm8X1Ta+iDfypZ3MfVf/RDprj2JAVKGuR6UdcNSveoWrmEqB1Sg1wZx3KhmqAlczgShEdMRGvhkZREixRjA9ipgK1AMUFMUxjTp34zrf0lU1OTywMPVY3qHtJoYSNMM7oL4vLnku6WAIwyfqnggqy X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4936.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(376002)(366004)(39850400004)(396003)(186003)(26005)(52116002)(66946007)(6666004)(2906002)(5660300002)(66476007)(8936002)(66574015)(8676002)(66556008)(55446002)(54906003)(83380400001)(786003)(478600001)(316002)(42186006)(33964004)(85202003)(9686003)(85182001)(86362001)(6862004)(4326008)(450100002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: 9jBjrsTZDZCGxOI9m8lEcRjjlY9V+IWM8F5g9yvEC9CYjiRxmUDXjnw6NJ2dUNQWyMdXpSLLrhznJEYFyUSdPIokYQbpaiYD4SUhUXsHc7EHmxmpCxzdKbI1zxiM5ZHpkuOTr2+yFBQcw1FmdkQo5TsmxXOaOethkKWXmcbw9DmZnOwgAJh/u/XowOD3fR6cg4hAfOuU6/i4JO1IvM0XVTQU5EDiqzbCxrjQeZ+M51TSa3zrECPTXORvjYJbQzDde0dKG3EYfgjMHl9Y5vjsLodBaY6eRwAa66eAvuXq4EBIRUWp2cv4nX1EFFE0tYZ6AA4MgVKJSOZiot4tZAsyqSIvsM/ldQri9Az3Pieo7jM5pCCqjzlHFoWiCNHpiDZQO9yGeas/1+1zV/hEo1K6vIvApxe4NX3KvJOdPjAsaNgNJnsZR2ILys0M3zIS98XAXynBrBgTz9j0W/jdj9kaBdCZzrHvhC4CSoujGPtj0aJc1UTm29ObN/Ue3p2IUv+wVI2rgA0AMCvGWuiERpy/ek5/qKl6VvCJC/LzkJRPeKnSUewqpq6V8XbtDQgsfVIEZunddFfejScYVJXsj5M52nSJEg1+dwQJX3wCuUhaY9MXhOFTiwPkB6qTXDhXkJALZfAllwLl5+QDSoJiCnMuIg== X-OriginatorOrg: cud.upct.es X-MS-Exchange-CrossTenant-Network-Message-Id: 965db98a-8f05-4095-f553-08d85f880b12 X-MS-Exchange-CrossTenant-AuthSource: AM6PR08MB4936.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2020 06:15:18.6993 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 967e1b81-5cf6-4b03-bb60-d71bf48069f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 7yx6qxSI+H7pAY8s4jauo7o105M+rxGMXU7B8shpQxJPI9fetEXhCughg7QQf9zMLlSaBwbH7zoa4Fx6aVqE5D0txFM5pqGZgOsst1YqoVE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB3685 Archived-At: Subject: Re: [IPsec] Last Call: (Software-Defined Networking (SDN)-based IPsec Flow Protection) to Proposed Standard 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, 23 Sep 2020 06:15:24 -0000 --000000000000c83cbc05aff50189 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tero, Thank you very much for your clarification. We will update reference RFC 822 accordingly in our draft. Tom, you proposed us to replace RFC 822 with 2822, but it is also obsoleted by 5322. So, if you agree, we will reference RFC 5322 instead. Best regards, Fernando. El mar., 22 sept. 2020 a las 19:50, Tero Kivinen () escribi=C3=B3: > Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa writes: > > I note that RFC822 and RFC3280 are Obsoleted which makes their use > > problematic. > > > > [Authors] Following your recommendation, we have replaced RFC 3280 wit= h > RFC > > 5280. Regarding RFC 822, we reference it because the IKEv2 protocol > > specification (RFC 7296) explicitly defines RFC 822 emails address (see > page > > 90) as a valid identification type. If we replace RFC 822 with RFC 2821= , > we > > don't know its impact on IKEv2. > > IKEv2 talks about RFC 822 email addresses, the reference points > Internationalized Email Headers RFC 6532, with comment of: > > Because of [EAI], implementations would be wise to treat this > field as UTF-8 encoded text, not as pure ASCII. > > So it uses RFC822 as name not as reference. There should not be any > problems to replace that with newer versions. Most of the > implementations simply consider that as a string and some cases they > actually do not even follow the string email address format, as they > add some routing information for AAAA in the end or something. > -- > kivinen@iki.fi > --=20 ---------------------------------------------------------------------------= ------------------------- Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa, PhD Department of Sciences and Informatics University Defense Center, (CUD), Spanish Air Force Academy, MDE-UPCT C/ Coronel Lopez Pe=C3=B1a, s/n, 30720, San Javier, Murcia - SPAIN Tel: +34 968 189 946 Fax: +34 968 189 970 ---------------------------------------------------------------------------= --------------------------- --000000000000c83cbc05aff50189 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tero,

Thank you very much for your cla= rification. We will update reference RFC 822 accordingly in our draft. = ;

Tom, you proposed us to replace RFC 822 with 282= 2, but it is also obsoleted by 5322. So, if you agree, we will reference RF= C 5322 instead.


Best regards,
=
Fernando.

El mar., 22 sept. 2020 a las 19:50, Tero Kivinen (<<= a href=3D"mailto:kivinen@iki.fi" target=3D"_blank">kivinen@iki.fi>) = escribi=C3=B3:
F= ernando Pere=C3=B1=C3=ADguez Garc=C3=ADa writes:
>     I note that RFC822 and RFC3280 are Obsoleted which = makes their use
>     problematic.
>
> [Authors]  Following your recommendation, we have replaced RFC 32= 80 with RFC
> 5280. Regarding RFC 822, we reference it because the IKEv2 protocol > specification (RFC 7296) explicitly defines RFC 822 emails address (se= e page
> 90) as a valid identification type. If we replace RFC 822 with RFC 282= 1, we
> don't know its impact on IKEv2.

IKEv2 talks about RFC 822 email addresses, the reference points
Internationalized Email Headers RFC 6532, with comment of:

      Because of [EAI], implementations would be wise to tre= at this
      field as UTF-8 encoded text, not as pure ASCII.

So it uses RFC822 as name not as reference. There should not be any
problems to replace that with newer versions. Most of the
implementations simply consider that as a string and some cases they
actually do not even follow the string email address format, as they
add some routing information for AAAA in the end or something.
--
kivinen@iki.fi


--
= ----= ---------------------------------------------------------------------------= ---------------------
Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa, PhD
Departm= ent of Sciences and Informatics
University Defense Center, (CUD), Spanis= h Air Force Academy, MDE-UPCT
C/ Coronel Lopez Pe=C3=B1a, s/n, 30720, Sa= n Javier, Murcia - SPAIN
Tel: +34 968 189 946 Fax: +34 968 189 970
--= ---------------------------------------------------------------------------= -------------------------
<= /div>
--000000000000c83cbc05aff50189-- From nobody Wed Sep 23 02:29:33 2020 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 8AEDF3A0B98; Wed, 23 Sep 2020 02:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 fWMsTOFcaip2; Wed, 23 Sep 2020 02:29:29 -0700 (PDT) Received: from mx02.puc.rediris.es (outbound4sev.lav.puc.rediris.es [130.206.19.178]) (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 05DA13A0ED5; Wed, 23 Sep 2020 02:29:27 -0700 (PDT) Received: from xenon43.um.es (xenon43.um.es [155.54.212.170]) by mx02.puc.rediris.es with ESMTP id 08N9THWV010942-08N9THWW010942; Wed, 23 Sep 2020 11:29:17 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon43.um.es (Postfix) with ESMTP id 3802D243CA; Wed, 23 Sep 2020 11:29:17 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon43.um.es Received: from xenon43.um.es ([127.0.0.1]) by localhost (xenon43.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9TNN55LsDQL9; Wed, 23 Sep 2020 11:29:17 +0200 (CEST) Received: from [192.168.1.36] (198.red-2-138-84.dynamicip.rima-tde.net [2.138.84.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon43.um.es (Postfix) with ESMTPSA id 617BD243CD; Wed, 23 Sep 2020 11:29:07 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_B17EE439-6F9C-449D-A99C-54A86EAB9814" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Wed, 23 Sep 2020 11:29:06 +0200 In-Reply-To: Cc: Rafa Marin-Lopez , "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "yang-doctors@ietf.org" To: "Rob Wilton (rwilton)" , Christian Hopps References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.170, helo=xenon43.um.es, mailFrom=rafa@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.170 as permitted sender) smtp.mailfrom=rafa@um.es DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=Qa5N6b8rYgR8BBf/H0dN7Ka0NKl/vf9d9qqW6pXjm30=; b=EZLDL+rQSHa6O1+zmdkZA6hPe2dMV/J4cB2d0AhPcbYXO2emzUT+MZ8Qzi5u3GqUA46PRx7np7t2 tCYERf8YxKbEcpJtV0ZWUix/VYZAHC4qe1eW00eDdVBI3fXZ7DpveKD48lJhrNE6lZAXifCa8LoI 2gTu1GPvagUrwQ9pcP1Cs2JlPsubkBBaRoZeYuH8npXwC4EGynWxXVvOqa+wBRouFXPLg1Xl/t8e bGus/E6desyQnykAwR7BX9quB6eEvfJtCa7DmEOwFQFHNVAuzA5GMHVyf9ansWnIx2e0Uu62ebT1 +VIqfKmYqS66vti2P9lsNVy6Bqzt6oBmsEiOHA== Archived-At: Subject: Re: [IPsec] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 23 Sep 2020 09:29:32 -0000 --Apple-Mail=_B17EE439-6F9C-449D-A99C-54A86EAB9814 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, (Chris): Thank you very much for your answers. Please see our comments inline.=20 > El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) = escribi=C3=B3: >=20 > Hi Rafa, > =20 > Thanks for getting back to me. > =20 > Yes, changing the name of the module is an okay, if not ideal, = resolution. But I appreciate that you also want to be done with this = work. Correct, especially at this point of time. We have been discussing this = I-D for a long time. There was a consensus in the WG. I2NSF WG chairs = can comment about this. In our opinion, the changes that need to be = applied are major changes from what it was approved in the WG. However, = this is coming in the =E2=80=9Clast minute=E2=80=9D and we feel this is = not merely moving a few lines from here to there. We need to understand = the impact of this. Therefore, it is not so trivial as it may seem. See = below.=20 > =20 > But I would like to check: My understanding is that the changes that = Chris is proposing are pretty small. I.e. move the SA structure under = ipsec-common, and put it under a YANG feature. Are you sure that it is = impractical to accommodate this change which would allow a single ipsec = module to be shared and extended via YANG augmentations? In the context of our I-D, if we move SAD structure to ipsec-common, = what we are meaning is that IPsec SA configuration data (setting values = to the SAD structure) are common to the IKE case and the IKE-less cases, = which are not. It is confusing. Moreover, the usage of feature means = that, after all, this =E2=80=9Ccommon=E2=80=9D is not =E2=80=9Ccommon=E2=80= =9D to both cases IKE case and IKE-less. Again, it seems confusing. In = the IKE case, the SDN/I2NSF controller does not configure the SAD at all = but the IKE implementation in the NSF. In our opinion, in order to = properly add this IPsec SA operational state to the IKE case we should = include operational data about the IPsec SAs (config false) to the = ietf-ipsec-ike. Alternatively, we have certain operational data (ro) in = the SAD structure in the IKE-less case. If only those are moved to the = common part should be ok but we think it does not solve the problem.=20 Therefore it is not only an implementation aspect. As you may observe, our discussion is taking into account there is an = I2NSF Controller and we have two cases IKE case and IKE-less case, that = have been discussed in the WG. The YANG model in the I-D has tried to = reflect this discussion. It was never the intention to provide a general = YANG model for IPsec.=20 Best Regards. > Thanks, > Rob > =20 > =20 > From: Rafa Marin-Lopez =20 > Sent: 22 September 2020 14:05 > To: Rob Wilton (rwilton) > Cc: Rafa Marin-Lopez ; Christian Hopps = ; Gabriel Lopez ; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; i2nsf@ietf.org; = ipsec@ietf.org; last-call@ietf.org; yang-doctors@ietf.org; Martin = Bj=C3=B6rklund > Subject: Re: [yang-doctors] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 > =20 > Dear Rob: > =20 > Apologies for our delayed answer. We are now working in the revision = to submit v09 by compiling all the comments. > =20 > As you mentioned, we want to avoid any further delay. As we mentioned = to Chris in the past (i2nsf mailing list), we do not have any problem to = include some additional text (e.g. =E2=80=9C-sdn-" in the module names). = Therefore, Rob, we agree with your point of view about this. > =20 > In summary, we are working in the next revision v09, and our idea to = address Chris=E2=80=99 comments was to include -sdn- to the module = names. > =20 > We hope this is fine. > =20 > Best regards. >=20 >=20 > El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) > escribi=C3=B3: > =20 > Hi draft authors, Chris, >=20 > Can we also please try and close on this issue raised by Chris. >=20 > Chris, I don=E2=80=99t think that there is any great way to solve this = issue using YANG features, but presumably the constraint could be = enforced with a must statement, or groupings could be used to copy parts = of the ipsec structure into an sdn specific ipsec tree structure. >=20 > I understand that there isn't any great desire to delay these drafts = by trying to generalize the ipsec YANG model contained within it. = However, I think that means that the modules should have "-sdn-" in = their names to indicate that they are intended specifically for the SDN = use case, and should not be confused with the more generic ipsec YANG = modules that have been proposed. >=20 > Regards, > Rob >=20 >=20 >=20 > -----Original Message----- > From: yang-doctors > On Behalf Of Christian > Hopps > Sent: 24 August 2020 18:08 > To: Martin Bj=C3=B6rklund > > Cc: i2nsf@ietf.org ; = draft-ietf-i2nsf-sdn-ipsec-flow- > protection.all@ietf.org ; = ipsec@ietf.org ; last-call@ietf.org = ; yang- > doctors@ietf.org > Subject: Re: [yang-doctors] Yangdoctors last call review of = draft-ietf- > i2nsf-sdn-ipsec-flow-protection-08 >=20 > [adding in ipsec@] >=20 > Hi, >=20 > This draft was discussed in ipsecme at the last IETF, and there was a > desire to look closer at a couple changes that would make these models > usable by ipsec generally rather than only for SDNs. Otherwise we will = end > up with 2 models that look very similar and duplicate almost all the > functionality. This was going to be done during the next yang doctor > review, but it looks like that happened in the meantime (ships in the > night). >=20 > At minimum the module names should include "-sdn-" if no other changes = are > made to indicate that they are only for sdn use; however, this is not = the > optimal solution. >=20 > A better solution would be to move the containers currently under = ikeless > (for SA and Policy databases) under ipsec-common. >=20 > The feedback I received from the authors was that the SDN controllers > didn't care about the actual SAs and policies when using IKE so they > didn't want to require someone implementing ike+common modules to have = to > support them. >=20 > The YANG question I suppose is, is there an easy way to move these > containers from ipsec-ikeless to ipsec-common, but still allow for = them to > be empty and/or unimplemented for the SDN IKE use case? If they were = made > features, is there a proper YANG way to indicate that if the ikeless > module is present then those features must also be supported thus = matching > the functionality as defined by the current draft? >=20 > Thanks, > Chris. >=20 >=20 >=20 >=20 > On Aug 24, 2020, at 10:37 AM, Martin Bj=C3=B6rklund via Datatracker > > wrote: >=20 >=20 > Reviewer: Martin Bj=C3=B6rklund > Review result: Ready with Nits >=20 > I did an early YANG Doctor's review of this draft. Most of my > comments then have been addressed in this version. >=20 > Comments: >=20 > o As I wrote in my early review, the RFC editor enforces a common > format of YANG modules, so it is better to adhere to this format > before sending the draft to the RFC editor. Use >=20 > pyang -f yang --yang-line-length 69 >=20 > to get a consistent look-and-feel for your module. >=20 > (You will have to manually re-flow description statements after > this.) >=20 >=20 > o There are some leafs that are optional in the model, but w/o a > default value and w/o an explanation of what happens if that leaf > is not set. You should find those and either make them mandatory, > add a default value, or explain what it means when it isn't set. > As an example, > /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret > is optional. I suspect that this leaf needs to be mandatory. > Another example is the leaf espencap. >=20 >=20 > /martin >=20 >=20 > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors = > =20 > =20 > ------------------------------------------------------- > 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:=C2=A0rafa@um.es = > ------------------------------------------------------- > =20 > =20 > =20 > =20 > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf = ------------------------------------------------------- Rafa Marin-Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_B17EE439-6F9C-449D-A99C-54A86EAB9814 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Rob, (Chris):

Thank = you very much for your answers. Please see our comments inline. 

El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org> = escribi=C3=B3:

Hi Rafa,
 
Thanks for getting back to me.
 
Yes, changing the name of the module is an = okay, if not ideal, resolution.  But I appreciate that you also = want to be done with this = work.

Correct, especially at this point of time. We have = been discussing this I-D for a long time. There was a consensus in the = WG. I2NSF WG chairs can comment about this. In our opinion, the changes = that need to be applied are major changes from what it was approved in = the WG. However, this is coming in the =E2=80=9Clast minute=E2=80=9D and = we feel this is not merely moving a few lines from here to there. We = need to understand the impact of this. Therefore, it is not so trivial = as it may seem. See below. 

 
But I would like to check:  My = understanding is that the changes that Chris is proposing are pretty = small.  I.e. move the SA structure under ipsec-common, and put it = under a YANG feature.  Are you sure that it is impractical to = accommodate this change which would allow a single ipsec module to be = shared and extended via YANG = augmentations?


In the context of our I-D, if = we move SAD structure to ipsec-common, what we are meaning is that IPsec = SA configuration data (setting values to the SAD structure) are common = to the IKE case and the IKE-less cases, which are not. It is confusing. = Moreover, the usage of feature means that, after all, this =E2=80=9Ccommon= =E2=80=9D is not =E2=80=9Ccommon=E2=80=9D to both cases IKE case and = IKE-less. Again, it seems confusing. In the IKE case, the SDN/I2NSF = controller does not configure the SAD at all but the IKE implementation = in the NSF. In our opinion, in order to properly add this IPsec SA = operational state to the IKE case we should include operational data = about the IPsec SAs (config false) to the ietf-ipsec-ike. Alternatively, = we have certain operational data (ro) in the SAD structure in the = IKE-less case. If only those are moved to the common part should be ok = but we think it does not solve the problem. 

Therefore it is not only an implementation = aspect.

As you may observe, our = discussion is taking into account there is an I2NSF Controller and we = have two cases IKE case and IKE-less case, that have been discussed in = the WG. The YANG model in the I-D has tried to reflect this discussion. = It was never the intention to provide a general YANG model for = IPsec. 

Best = Regards.


Thanks,
Rob
 
 
From: Rafa = Marin-Lopez <rafa@um.es> 
Sent: 22 = September 2020 14:05
To: Rob Wilton (rwilton) <rwilton@cisco.com>
Cc: Rafa Marin-Lopez <rafa@um.es>; Christian = Hopps <chopps@chopps.org>; Gabriel Lopez <gabilm@um.es>; draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; = i2nsf@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang-doctors@ietf.org; Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Subject: Re: [yang-doctors] = Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
 
Dear Rob:
 
Apologies for our delayed answer. We are now working in the = revision to submit v09 by compiling all the comments.
 
As you mentioned, we want to avoid any = further delay. As we mentioned to Chris in the past (i2nsf mailing = list), we do not have any problem to include some additional text (e.g. = =E2=80=9C-sdn-" in the module names). Therefore, Rob, we agree with your = point of view about this.
 
In summary, we are working in the next revision v09, and our = idea to address Chris=E2=80=99 comments was to include -sdn- to the = module names.
 
We hope this is fine.
 
Best regards.


El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) <rwilton@cisco.com> escribi=C3=B3:
 
Hi draft authors, Chris,

Can we also please try and close on this issue = raised by Chris.

Chris, I don=E2=80=99t = think that there is any great way to solve this issue using YANG = features, but presumably the constraint could be enforced with a must = statement, or groupings could be used to copy parts of the ipsec = structure into an sdn specific ipsec tree structure.

I understand that there isn't any great desire to delay these = drafts by trying to generalize the ipsec YANG model contained within it. =  However, I think that means that the modules should have "-sdn-" = in their names to indicate that they are intended specifically for the = SDN use case, and should not be confused with the more generic ipsec = YANG modules that have been proposed.

Regards,
Rob



-----Original Message-----
From: yang-doctors <yang-doctors-bounces@ietf.org> On Behalf Of = Christian
Hopps
Sent: 24 August 2020 = 18:08
To: Martin Bj=C3=B6rklund <mbj+ietf@4668.se>
Cc: i2nsf@ietf.org; = draft-ietf-i2nsf-sdn-ipsec-flow-
protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang-
doctors@ietf.org
Subject: Re: [yang-doctors] Yangdoctors last call review of = draft-ietf-
i2nsf-sdn-ipsec-flow-protection-08

[adding in ipsec@]

Hi,

This draft was discussed in = ipsecme at the last IETF, and there was a
desire to look = closer at a couple changes that would make these models
usable by ipsec generally rather than only for SDNs. = Otherwise we will end
up with 2 models that look very = similar and duplicate almost all the
functionality. This = was going to be done during the next yang doctor
review, = but it looks like that happened in the meantime (ships in the
night).

At minimum the module = names should include "-sdn-" if no other changes are
made = to indicate that they are only for sdn use; however, this is not the
optimal solution.

A better = solution would be to move the containers currently under ikeless
(for SA and Policy databases) under ipsec-common.

The feedback I received from the authors was = that the SDN controllers
didn't care about the actual SAs = and policies when using IKE so they
didn't want to require = someone implementing ike+common modules to have to
support = them.

The YANG question I suppose is, is = there an easy way to move these
containers from = ipsec-ikeless to ipsec-common, but still allow for them to
be empty and/or unimplemented for the SDN IKE use case? If = they were made
features, is there a proper YANG way to = indicate that if the ikeless
module is present then those = features must also be supported thus matching
the = functionality as defined by the current draft?

Thanks,
Chris.




On Aug = 24, 2020, at 10:37 AM, Martin Bj=C3=B6rklund via Datatracker
<noreply@ietf.org> = wrote:


Reviewer: Martin Bj=C3=B6rklund
Review result: = Ready with Nits

I did an early YANG = Doctor's review of this draft.  Most of my
comments = then have been addressed in this version.

Comments:

o  As I wrote in = my early review, the RFC editor enforces a common
 format of YANG modules, so it is better to adhere to = this format
 before sending the draft to the RFC = editor.  Use

   pyang = -f yang --yang-line-length 69 <FILE>

 to get a consistent look-and-feel for your module.

 (You will have to manually re-flow = description statements after
 this.)


o  There are some leafs that are optional = in the model, but w/o a
 default value and w/o an = explanation of what happens if that leaf
 is not set. =  You should find those and either make them mandatory,
 add a default value, or explain what it means when it = isn't set.
 As an example,
 /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/sec= ret
 is optional.  I suspect that this leaf = needs to be mandatory.
 Another example is the leaf = espencap.


/martin


_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org
https://www.ietf.org/mailman/listinfo/yang-doctors
 
 
-------------------------------------------------------
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
-------------------------------------------------------
 
 
 
 
_______________________________________________
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=_B17EE439-6F9C-449D-A99C-54A86EAB9814-- From nobody Wed Sep 23 03:24:35 2020 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 BE36D3A0A8E; Wed, 23 Sep 2020 03:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.618 X-Spam-Level: X-Spam-Status: No, score=-9.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UweO70uT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Odgt4Jmo 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 obp9rjejZ9a7; Wed, 23 Sep 2020 03:24:26 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31E0B3A0F31; Wed, 23 Sep 2020 03:24:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40570; q=dns/txt; s=iport; t=1600856666; x=1602066266; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tOa6n0pEGLO+c/THj7y34Py+g0U/toF6NbDxXhBZfdI=; b=UweO70uTi9H1+uhIdMVd+VwED4dmsr5StCekiGtwUcFwO53QGCgKaYuy 21IQCYdjN5uRhwK0GgJQZXTYzmRsp9msdENoN2bxJxdyBlsNjYLimuqjt u6FW5ra6mZ0TyXqFdt3oH6WQ3pj+gWi0KLCQMP4yQl8oNJxSPAPgbdmvR Y=; IronPort-PHdr: =?us-ascii?q?9a23=3A1JCtmhHmJruEEPLYwgXOTJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401AGbQICd5ukXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoLE0TFd2tL1HXq2e5uDgVHB?= =?us-ascii?q?i3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjBQC3IWtf/4ENJK1gHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCD4EjLyMuB3BZLywKhDCDRgONeph2gUKBEQNVCwEBAQ0BARg?= =?us-ascii?q?BCgoCBAEBhEsCF4ITAiQ4EwIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDAQE?= =?us-ascii?q?QEQoTAQEsCwELBAIBCBEEAQEWCwMEAwICAiULFAkIAgQBDQUIEweDBYF+TQM?= =?us-ascii?q?uAQMLqxACgTmIYXaBMoMBAQEFgTMBg3kYghADBoE4gnGDaYJBhBEbgUE/gRF?= =?us-ascii?q?DgU9QLj6CXAEBAoEWDTwFBwkWCQIHglgzggsij3AkgmY8hn4mi1KRCwqCZ49?= =?us-ascii?q?MhgGFJoMMiXqOOIVKkn+ffgIEAgQFAg4BAQWBayMqgS1wFTuCaVAXAg2OHwo?= =?us-ascii?q?CFxSDOoUUhUJ0AjUCBgEJAQEDCXyMUgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.77,293,1596499200"; d="scan'208,217";a="805932283" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Sep 2020 10:24:21 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 08NAOLCI013070 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 23 Sep 2020 10:24:21 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 23 Sep 2020 05:24:20 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 23 Sep 2020 06:24:19 -0400 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 23 Sep 2020 06:24:19 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=leBgvmVfXHDCY7PMndNz6tJkevK5r2m5xnE/HrIXfkoG57DuFgmpBCMoKNLvbdpDm4Gt35Ew5j/DpzIPJOnbmuniLH+fh2AlMV1qDDAIGvZxSir+3CfabKxsLyHmAKVDyu8XuflHSRL+yfKrbroxo+BEp0W+z8UhSfuY84rtw08n0RjrQzMicTFVnUMSgxLdHM6DUiE3E5Kh8jWQNmAmv7uqi53zCcOB/PXwQKC86JWQ5Zp0tVGqwiMbF2yj5Bcxwe3ct4i5a25koz1Aw3hTulf1eLdt1/to8Al8RbMpk9gShD8XiRtf9lCuh5pf9Ihea10pwrfQE1T26RsJlPB/zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tOa6n0pEGLO+c/THj7y34Py+g0U/toF6NbDxXhBZfdI=; b=LPEbUqVKPVhCMC8qHsASL2A1aIIvd+7/e5i5YBZRvNWyn4gfnRd5d6Gb6rzmRUSk/pxiVvfUQTiW7Sv1mG7r5lbYb2NoycCo1OOfWYv0gCn81HuTIVmzHhXd4pNUWXVhCUtntXYHoba1ZTgcFtiM3Bw9vcI8hINBd/0e/ZL24DkxVp7auDWWe3+eaKbFrCUMHb2NnQLFkrzBX2p61AcEh/iyyc1DrDjio9lnlWpY1HSLrs/cUg7Gy7NjszQpNq3zsdgpdB34C8jlsFKJ7PELkcCTt4Jw2XPENBLHVFzLd+RqA0pUyBsZjFUoMwYVsJiy6sjI1BbP5WpQ+Yhrx1wdtA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tOa6n0pEGLO+c/THj7y34Py+g0U/toF6NbDxXhBZfdI=; b=Odgt4JmoN/cc2qVKNew6gTcDfQuJktoENgLz9PZtVUBwihJfdP1ZuW8C6mjs7rzA2bQwz0gluIZBFBazUDikpl0PxEXxhg3fDlwSOnPSADUmDYJQwxbtg1gMzpF1MN6zHtXiDnjtt4hbU8kKWuvy7p+iSKIAKUqfRylE2g9kJas= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by MN2PR11MB4568.namprd11.prod.outlook.com (2603:10b6:208:266::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.22; Wed, 23 Sep 2020 10:24:18 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3391.026; Wed, 23 Sep 2020 10:24:18 +0000 From: "Rob Wilton (rwilton)" To: Rafa Marin-Lopez , Christian Hopps CC: "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , =?utf-8?B?TWFydGluIEJqw7Zya2x1bmQ=?= , "yang-doctors@ietf.org" Thread-Topic: [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 Thread-Index: AQHWeiQ1OzamIxEUgUCW76UP8U3vNKlHffqAgC01gyCAABpCAIAAJ6MAgAEuTACAAA3zcA== Date: Wed, 23 Sep 2020 10:24:18 +0000 Message-ID: References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> In-Reply-To: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: um.es; dkim=none (message not signed) header.d=none;um.es; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 47f8a6c5-bb59-4f7f-e67f-08d85faad48b x-ms-traffictypediagnostic: MN2PR11MB4568: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9G5YnRMD4RnD+z/pgNvKfl1j4R2OxjHdfwbGJqloyxLPGoaIJTUOHNLrWUVvjEBQtvZe1R2emw6wW1XXsah0EpkXayV9FKJEFY5XID+Dieot9dwg9amHj/2JZ69I879eivMzuO3V3WZTc+HDoimTn7KwiLj5LW5OvuQYnJS+FPxaJAdXRJ8vMqNGT9oADkHEfxGv2R7aLrMQqjB/pcBdA4sH18FW0aD5hU0+dfFKcIPYwBNx2d3euWLBP+7NJiXktAfo+MI5O6v9ACZOxr2qyfPUx7vqmlrEfJ+82apLMUl/0DpIU2TC5wgYm50ZeEpOpMaxlTCJp/3/Da6Ue3RRrWDU3egrVVqmNLSZgPdYTszrYQVrHEMQz5IbJAz10RRgbMJqiutvKJNLnxZZeeglBR/humhq8Dh9IW5hlT4bu4ya5bZ9akvgh/jckxWLDjBKb/yg2VKG8B9CqtidPK3qSw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(346002)(136003)(39860400002)(396003)(478600001)(966005)(66574015)(4326008)(316002)(166002)(33656002)(86362001)(53546011)(110136005)(26005)(52536014)(8676002)(6506007)(5660300002)(186003)(64756008)(66446008)(71200400001)(55016002)(9686003)(54906003)(83380400001)(66556008)(66476007)(2906002)(8936002)(9326002)(66946007)(76116006)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: dzxhQLDAiHpgApPKPDHaTY0X/obNRL1slH6eHN0mbBgbpL9ti/WTacptnopUQcqAcIWjdhBo+HlNXcIDupRQ1D3c9vLAAtu/x0GJ4CJnSpT5Z4jcL2gkKdHMT51QqXF3ey6Km11fy0NDbg+QtS+gYjEyNPXi8sUc7HilbluQe8Nkj7ItVfsegYi31MXpM2anJU+f23MK1JVWaMlwrTvQgWn40YHE08t3dmQfrjHeoE6QCtxy3NE2TjlfjkHoZ6doUGuDJcy+IUNebjDjExJSxQsNCt5008VbIzsl/GngIDW+ryZkoMfMJmEXmUEWlMP7rBb4cZbGss40UEx62+eSjVzT1dvU+ES3Z37z1Un+t3XTCJTYM49HfcXR/iiHHIMss5/j55YHr3rNI8INczjzqYsH1IMve1OueFEDzoVCFTdsbWhBfhUhRG2fU7dwusmquwAqo5iHuNdTbe6LvYvIy6kSTtRMsQ/TGdDmWUwXmO5xkAKmDMy5uDyj5ghPSA+lN0ijoolo5ny+nwpwivoC0jLfnSv0CnX9D1PdkSBFISLgf2ivct75UBH0EyuEF4+bVl1GCvKlrAfK5Gu1QL3YIp4Ng0Ua4xbsasEuopdPFGhaIvPfMMO0KwrXPdBCqb7Hu+dDE8UgXlkifLD6NNM9qQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB4366119EA0904BF1076AD896B5380MN2PR11MB4366namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47f8a6c5-bb59-4f7f-e67f-08d85faad48b X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Sep 2020 10:24:18.6873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: tPIsukg/EcHHOy7a1qAHk2Ks7V2Nx/BLJc9egmiyzMQTZspd6OoKRaaCOIGXLRLKaRhBGxrg6uG8MeJmtnDqdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4568 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [IPsec] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 23 Sep 2020 10:24:30 -0000 --_000_MN2PR11MB4366119EA0904BF1076AD896B5380MN2PR11MB4366namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmFmYSwNCg0KVGhhbmtzIGZvciByZXBseWluZyB3aXRoIHRoZSBleHRyYSBiYWNrZ3JvdW5k IGluZm9ybWF0aW9uLg0KDQpJdCBzZWVtcyBsaWtlIHJlbmFtaW5nIHRoZSBtb2R1bGVzLCBhcyB5 b3UgcHJvcG9zZSBmb3IgdGhlIC0wOSB2ZXJzaW9uLCBpcyB0aGUgcHJhZ21hdGljIHBhdGggZm9y d2FyZCBoZXJlLg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0KRnJvbTogUmFmYSBNYXJpbi1Mb3BleiA8 cmFmYUB1bS5lcz4NClNlbnQ6IDIzIFNlcHRlbWJlciAyMDIwIDEwOjI5DQpUbzogUm9iIFdpbHRv biAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPjsgQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNA Y2hvcHBzLm9yZz4NCkNjOiBSYWZhIE1hcmluLUxvcGV6IDxyYWZhQHVtLmVzPjsgaTJuc2ZAaWV0 Zi5vcmc7IEdhYnJpZWwgTG9wZXogPGdhYmlsbUB1bS5lcz47IGRyYWZ0LWlldGYtaTJuc2Ytc2Ru LWlwc2VjLWZsb3ctcHJvdGVjdGlvbi5hbGxAaWV0Zi5vcmc7IGlwc2VjQGlldGYub3JnOyBsYXN0 LWNhbGxAaWV0Zi5vcmc7IE1hcnRpbiBCasO2cmtsdW5kIDxtYmoraWV0ZkA0NjY4LnNlPjsgeWFu Zy1kb2N0b3JzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW0kybnNmXSBbeWFuZy1kb2N0b3JzXSBZ YW5nZG9jdG9ycyBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaTJuc2Ytc2RuLWlwc2Vj LWZsb3ctcHJvdGVjdGlvbi0wOA0KDQpIaSBSb2IsIChDaHJpcyk6DQoNClRoYW5rIHlvdSB2ZXJ5 IG11Y2ggZm9yIHlvdXIgYW5zd2Vycy4gUGxlYXNlIHNlZSBvdXIgY29tbWVudHMgaW5saW5lLg0K DQoNCkVsIDIyIHNlcHQgMjAyMCwgYSBsYXMgMTc6MzgsIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxy d2lsdG9uPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzpyd2lsdG9uPTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnPj4gZXNjcmliacOzOg0KDQpIaSBSYWZhLA0KDQpUaGFua3MgZm9y IGdldHRpbmcgYmFjayB0byBtZS4NCg0KWWVzLCBjaGFuZ2luZyB0aGUgbmFtZSBvZiB0aGUgbW9k dWxlIGlzIGFuIG9rYXksIGlmIG5vdCBpZGVhbCwgcmVzb2x1dGlvbi4gIEJ1dCBJIGFwcHJlY2lh dGUgdGhhdCB5b3UgYWxzbyB3YW50IHRvIGJlIGRvbmUgd2l0aCB0aGlzIHdvcmsuDQoNCkNvcnJl Y3QsIGVzcGVjaWFsbHkgYXQgdGhpcyBwb2ludCBvZiB0aW1lLiBXZSBoYXZlIGJlZW4gZGlzY3Vz c2luZyB0aGlzIEktRCBmb3IgYSBsb25nIHRpbWUuIFRoZXJlIHdhcyBhIGNvbnNlbnN1cyBpbiB0 aGUgV0cuIEkyTlNGIFdHIGNoYWlycyBjYW4gY29tbWVudCBhYm91dCB0aGlzLiBJbiBvdXIgb3Bp bmlvbiwgdGhlIGNoYW5nZXMgdGhhdCBuZWVkIHRvIGJlIGFwcGxpZWQgYXJlIG1ham9yIGNoYW5n ZXMgZnJvbSB3aGF0IGl0IHdhcyBhcHByb3ZlZCBpbiB0aGUgV0cuIEhvd2V2ZXIsIHRoaXMgaXMg Y29taW5nIGluIHRoZSDigJxsYXN0IG1pbnV0ZeKAnSBhbmQgd2UgZmVlbCB0aGlzIGlzIG5vdCBt ZXJlbHkgbW92aW5nIGEgZmV3IGxpbmVzIGZyb20gaGVyZSB0byB0aGVyZS4gV2UgbmVlZCB0byB1 bmRlcnN0YW5kIHRoZSBpbXBhY3Qgb2YgdGhpcy4gVGhlcmVmb3JlLCBpdCBpcyBub3Qgc28gdHJp dmlhbCBhcyBpdCBtYXkgc2VlbS4gU2VlIGJlbG93Lg0KDQoNCg0KQnV0IEkgd291bGQgbGlrZSB0 byBjaGVjazogIE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCB0aGUgY2hhbmdlcyB0aGF0IENocmlz IGlzIHByb3Bvc2luZyBhcmUgcHJldHR5IHNtYWxsLiAgSS5lLiBtb3ZlIHRoZSBTQSBzdHJ1Y3R1 cmUgdW5kZXIgaXBzZWMtY29tbW9uLCBhbmQgcHV0IGl0IHVuZGVyIGEgWUFORyBmZWF0dXJlLiAg QXJlIHlvdSBzdXJlIHRoYXQgaXQgaXMgaW1wcmFjdGljYWwgdG8gYWNjb21tb2RhdGUgdGhpcyBj aGFuZ2Ugd2hpY2ggd291bGQgYWxsb3cgYSBzaW5nbGUgaXBzZWMgbW9kdWxlIHRvIGJlIHNoYXJl ZCBhbmQgZXh0ZW5kZWQgdmlhIFlBTkcgYXVnbWVudGF0aW9ucz8NCg0KDQpJbiB0aGUgY29udGV4 dCBvZiBvdXIgSS1ELCBpZiB3ZSBtb3ZlIFNBRCBzdHJ1Y3R1cmUgdG8gaXBzZWMtY29tbW9uLCB3 aGF0IHdlIGFyZSBtZWFuaW5nIGlzIHRoYXQgSVBzZWMgU0EgY29uZmlndXJhdGlvbiBkYXRhIChz ZXR0aW5nIHZhbHVlcyB0byB0aGUgU0FEIHN0cnVjdHVyZSkgYXJlIGNvbW1vbiB0byB0aGUgSUtF IGNhc2UgYW5kIHRoZSBJS0UtbGVzcyBjYXNlcywgd2hpY2ggYXJlIG5vdC4gSXQgaXMgY29uZnVz aW5nLiBNb3Jlb3ZlciwgdGhlIHVzYWdlIG9mIGZlYXR1cmUgbWVhbnMgdGhhdCwgYWZ0ZXIgYWxs LCB0aGlzIOKAnGNvbW1vbuKAnSBpcyBub3Qg4oCcY29tbW9u4oCdIHRvIGJvdGggY2FzZXMgSUtF IGNhc2UgYW5kIElLRS1sZXNzLiBBZ2FpbiwgaXQgc2VlbXMgY29uZnVzaW5nLiBJbiB0aGUgSUtF IGNhc2UsIHRoZSBTRE4vSTJOU0YgY29udHJvbGxlciBkb2VzIG5vdCBjb25maWd1cmUgdGhlIFNB RCBhdCBhbGwgYnV0IHRoZSBJS0UgaW1wbGVtZW50YXRpb24gaW4gdGhlIE5TRi4gSW4gb3VyIG9w aW5pb24sIGluIG9yZGVyIHRvIHByb3Blcmx5IGFkZCB0aGlzIElQc2VjIFNBIG9wZXJhdGlvbmFs IHN0YXRlIHRvIHRoZSBJS0UgY2FzZSB3ZSBzaG91bGQgaW5jbHVkZSBvcGVyYXRpb25hbCBkYXRh IGFib3V0IHRoZSBJUHNlYyBTQXMgKGNvbmZpZyBmYWxzZSkgdG8gdGhlIGlldGYtaXBzZWMtaWtl LiBBbHRlcm5hdGl2ZWx5LCB3ZSBoYXZlIGNlcnRhaW4gb3BlcmF0aW9uYWwgZGF0YSAocm8pIGlu IHRoZSBTQUQgc3RydWN0dXJlIGluIHRoZSBJS0UtbGVzcyBjYXNlLiBJZiBvbmx5IHRob3NlIGFy ZSBtb3ZlZCB0byB0aGUgY29tbW9uIHBhcnQgc2hvdWxkIGJlIG9rIGJ1dCB3ZSB0aGluayBpdCBk b2VzIG5vdCBzb2x2ZSB0aGUgcHJvYmxlbS4NCg0KVGhlcmVmb3JlIGl0IGlzIG5vdCBvbmx5IGFu IGltcGxlbWVudGF0aW9uIGFzcGVjdC4NCg0KQXMgeW91IG1heSBvYnNlcnZlLCBvdXIgZGlzY3Vz c2lvbiBpcyB0YWtpbmcgaW50byBhY2NvdW50IHRoZXJlIGlzIGFuIEkyTlNGIENvbnRyb2xsZXIg YW5kIHdlIGhhdmUgdHdvIGNhc2VzIElLRSBjYXNlIGFuZCBJS0UtbGVzcyBjYXNlLCB0aGF0IGhh dmUgYmVlbiBkaXNjdXNzZWQgaW4gdGhlIFdHLiBUaGUgWUFORyBtb2RlbCBpbiB0aGUgSS1EIGhh cyB0cmllZCB0byByZWZsZWN0IHRoaXMgZGlzY3Vzc2lvbi4gSXQgd2FzIG5ldmVyIHRoZSBpbnRl bnRpb24gdG8gcHJvdmlkZSBhIGdlbmVyYWwgWUFORyBtb2RlbCBmb3IgSVBzZWMuDQoNCkJlc3Qg UmVnYXJkcy4NCg0KDQpUaGFua3MsDQpSb2INCg0KDQpGcm9tOiBSYWZhIE1hcmluLUxvcGV6IDxy YWZhQHVtLmVzPG1haWx0bzpyYWZhQHVtLmVzPj4NClNlbnQ6IDIyIFNlcHRlbWJlciAyMDIwIDE0 OjA1DQpUbzogUm9iIFdpbHRvbiAocndpbHRvbikgPHJ3aWx0b25AY2lzY28uY29tPG1haWx0bzpy d2lsdG9uQGNpc2NvLmNvbT4+DQpDYzogUmFmYSBNYXJpbi1Mb3BleiA8cmFmYUB1bS5lczxtYWls dG86cmFmYUB1bS5lcz4+OyBDaHJpc3RpYW4gSG9wcHMgPGNob3Bwc0BjaG9wcHMub3JnPG1haWx0 bzpjaG9wcHNAY2hvcHBzLm9yZz4+OyBHYWJyaWVsIExvcGV6IDxnYWJpbG1AdW0uZXM8bWFpbHRv OmdhYmlsbUB1bS5lcz4+OyBkcmFmdC1pZXRmLWkybnNmLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rp b24uYWxsQGlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWkybnNmLXNkbi1pcHNlYy1mbG93LXBy b3RlY3Rpb24uYWxsQGlldGYub3JnPjsgaTJuc2ZAaWV0Zi5vcmc8bWFpbHRvOmkybnNmQGlldGYu b3JnPjsgaXBzZWNAaWV0Zi5vcmc8bWFpbHRvOmlwc2VjQGlldGYub3JnPjsgbGFzdC1jYWxsQGll dGYub3JnPG1haWx0bzpsYXN0LWNhbGxAaWV0Zi5vcmc+OyB5YW5nLWRvY3RvcnNAaWV0Zi5vcmc8 bWFpbHRvOnlhbmctZG9jdG9yc0BpZXRmLm9yZz47IE1hcnRpbiBCasO2cmtsdW5kIDxtYmoraWV0 ZkA0NjY4LnNlPG1haWx0bzptYmoraWV0ZkA0NjY4LnNlPj4NClN1YmplY3Q6IFJlOiBbeWFuZy1k b2N0b3JzXSBZYW5nZG9jdG9ycyBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaTJuc2Yt c2RuLWlwc2VjLWZsb3ctcHJvdGVjdGlvbi0wOA0KDQpEZWFyIFJvYjoNCg0KQXBvbG9naWVzIGZv ciBvdXIgZGVsYXllZCBhbnN3ZXIuIFdlIGFyZSBub3cgd29ya2luZyBpbiB0aGUgcmV2aXNpb24g dG8gc3VibWl0IHYwOSBieSBjb21waWxpbmcgYWxsIHRoZSBjb21tZW50cy4NCg0KQXMgeW91IG1l bnRpb25lZCwgd2Ugd2FudCB0byBhdm9pZCBhbnkgZnVydGhlciBkZWxheS4gQXMgd2UgbWVudGlv bmVkIHRvIENocmlzIGluIHRoZSBwYXN0IChpMm5zZiBtYWlsaW5nIGxpc3QpLCB3ZSBkbyBub3Qg aGF2ZSBhbnkgcHJvYmxlbSB0byBpbmNsdWRlIHNvbWUgYWRkaXRpb25hbCB0ZXh0IChlLmcuIOKA nC1zZG4tIiBpbiB0aGUgbW9kdWxlIG5hbWVzKS4gVGhlcmVmb3JlLCBSb2IsIHdlIGFncmVlIHdp dGggeW91ciBwb2ludCBvZiB2aWV3IGFib3V0IHRoaXMuDQoNCkluIHN1bW1hcnksIHdlIGFyZSB3 b3JraW5nIGluIHRoZSBuZXh0IHJldmlzaW9uIHYwOSwgYW5kIG91ciBpZGVhIHRvIGFkZHJlc3Mg Q2hyaXPigJkgY29tbWVudHMgd2FzIHRvIGluY2x1ZGUgLXNkbi0gdG8gdGhlIG1vZHVsZSBuYW1l cy4NCg0KV2UgaG9wZSB0aGlzIGlzIGZpbmUuDQoNCkJlc3QgcmVnYXJkcy4NCg0KDQoNCkVsIDIy IHNlcHQgMjAyMCwgYSBsYXMgMTM6NTYsIFJvYiBXaWx0b24gKHJ3aWx0b24pIDxyd2lsdG9uQGNp c2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+PiBlc2NyaWJpw7M6DQoNCkhpIGRyYWZ0 IGF1dGhvcnMsIENocmlzLA0KDQpDYW4gd2UgYWxzbyBwbGVhc2UgdHJ5IGFuZCBjbG9zZSBvbiB0 aGlzIGlzc3VlIHJhaXNlZCBieSBDaHJpcy4NCg0KQ2hyaXMsIEkgZG9u4oCZdCB0aGluayB0aGF0 IHRoZXJlIGlzIGFueSBncmVhdCB3YXkgdG8gc29sdmUgdGhpcyBpc3N1ZSB1c2luZyBZQU5HIGZl YXR1cmVzLCBidXQgcHJlc3VtYWJseSB0aGUgY29uc3RyYWludCBjb3VsZCBiZSBlbmZvcmNlZCB3 aXRoIGEgbXVzdCBzdGF0ZW1lbnQsIG9yIGdyb3VwaW5ncyBjb3VsZCBiZSB1c2VkIHRvIGNvcHkg cGFydHMgb2YgdGhlIGlwc2VjIHN0cnVjdHVyZSBpbnRvIGFuIHNkbiBzcGVjaWZpYyBpcHNlYyB0 cmVlIHN0cnVjdHVyZS4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgaXNuJ3QgYW55IGdyZWF0 IGRlc2lyZSB0byBkZWxheSB0aGVzZSBkcmFmdHMgYnkgdHJ5aW5nIHRvIGdlbmVyYWxpemUgdGhl IGlwc2VjIFlBTkcgbW9kZWwgY29udGFpbmVkIHdpdGhpbiBpdC4gIEhvd2V2ZXIsIEkgdGhpbmsg dGhhdCBtZWFucyB0aGF0IHRoZSBtb2R1bGVzIHNob3VsZCBoYXZlICItc2RuLSIgaW4gdGhlaXIg bmFtZXMgdG8gaW5kaWNhdGUgdGhhdCB0aGV5IGFyZSBpbnRlbmRlZCBzcGVjaWZpY2FsbHkgZm9y IHRoZSBTRE4gdXNlIGNhc2UsIGFuZCBzaG91bGQgbm90IGJlIGNvbmZ1c2VkIHdpdGggdGhlIG1v cmUgZ2VuZXJpYyBpcHNlYyBZQU5HIG1vZHVsZXMgdGhhdCBoYXZlIGJlZW4gcHJvcG9zZWQuDQoN ClJlZ2FyZHMsDQpSb2INCg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IHlhbmctZG9jdG9ycyA8eWFuZy1kb2N0b3JzLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnlhbmct ZG9jdG9ycy1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIENocmlzdGlhbg0KSG9wcHMN ClNlbnQ6IDI0IEF1Z3VzdCAyMDIwIDE4OjA4DQpUbzogTWFydGluIEJqw7Zya2x1bmQgPG1iaitp ZXRmQDQ2Njguc2U8bWFpbHRvOm1iaitpZXRmQDQ2Njguc2U+Pg0KQ2M6IGkybnNmQGlldGYub3Jn PG1haWx0bzppMm5zZkBpZXRmLm9yZz47IGRyYWZ0LWlldGYtaTJuc2Ytc2RuLWlwc2VjLWZsb3ct DQpwcm90ZWN0aW9uLmFsbEBpZXRmLm9yZzxtYWlsdG86cHJvdGVjdGlvbi5hbGxAaWV0Zi5vcmc+ OyBpcHNlY0BpZXRmLm9yZzxtYWlsdG86aXBzZWNAaWV0Zi5vcmc+OyBsYXN0LWNhbGxAaWV0Zi5v cmc8bWFpbHRvOmxhc3QtY2FsbEBpZXRmLm9yZz47IHlhbmctDQpkb2N0b3JzQGlldGYub3JnPG1h aWx0bzpkb2N0b3JzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFt5YW5nLWRvY3RvcnNdIFlhbmdk b2N0b3JzIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi0NCmkybnNmLXNkbi1pcHNlYy1m bG93LXByb3RlY3Rpb24tMDgNCg0KW2FkZGluZyBpbiBpcHNlY0BdDQoNCkhpLA0KDQpUaGlzIGRy YWZ0IHdhcyBkaXNjdXNzZWQgaW4gaXBzZWNtZSBhdCB0aGUgbGFzdCBJRVRGLCBhbmQgdGhlcmUg d2FzIGENCmRlc2lyZSB0byBsb29rIGNsb3NlciBhdCBhIGNvdXBsZSBjaGFuZ2VzIHRoYXQgd291 bGQgbWFrZSB0aGVzZSBtb2RlbHMNCnVzYWJsZSBieSBpcHNlYyBnZW5lcmFsbHkgcmF0aGVyIHRo YW4gb25seSBmb3IgU0ROcy4gT3RoZXJ3aXNlIHdlIHdpbGwgZW5kDQp1cCB3aXRoIDIgbW9kZWxz IHRoYXQgbG9vayB2ZXJ5IHNpbWlsYXIgYW5kIGR1cGxpY2F0ZSBhbG1vc3QgYWxsIHRoZQ0KZnVu Y3Rpb25hbGl0eS4gVGhpcyB3YXMgZ29pbmcgdG8gYmUgZG9uZSBkdXJpbmcgdGhlIG5leHQgeWFu ZyBkb2N0b3INCnJldmlldywgYnV0IGl0IGxvb2tzIGxpa2UgdGhhdCBoYXBwZW5lZCBpbiB0aGUg bWVhbnRpbWUgKHNoaXBzIGluIHRoZQ0KbmlnaHQpLg0KDQpBdCBtaW5pbXVtIHRoZSBtb2R1bGUg bmFtZXMgc2hvdWxkIGluY2x1ZGUgIi1zZG4tIiBpZiBubyBvdGhlciBjaGFuZ2VzIGFyZQ0KbWFk ZSB0byBpbmRpY2F0ZSB0aGF0IHRoZXkgYXJlIG9ubHkgZm9yIHNkbiB1c2U7IGhvd2V2ZXIsIHRo aXMgaXMgbm90IHRoZQ0Kb3B0aW1hbCBzb2x1dGlvbi4NCg0KQSBiZXR0ZXIgc29sdXRpb24gd291 bGQgYmUgdG8gbW92ZSB0aGUgY29udGFpbmVycyBjdXJyZW50bHkgdW5kZXIgaWtlbGVzcw0KKGZv ciBTQSBhbmQgUG9saWN5IGRhdGFiYXNlcykgdW5kZXIgaXBzZWMtY29tbW9uLg0KDQpUaGUgZmVl ZGJhY2sgSSByZWNlaXZlZCBmcm9tIHRoZSBhdXRob3JzIHdhcyB0aGF0IHRoZSBTRE4gY29udHJv bGxlcnMNCmRpZG4ndCBjYXJlIGFib3V0IHRoZSBhY3R1YWwgU0FzIGFuZCBwb2xpY2llcyB3aGVu IHVzaW5nIElLRSBzbyB0aGV5DQpkaWRuJ3Qgd2FudCB0byByZXF1aXJlIHNvbWVvbmUgaW1wbGVt ZW50aW5nIGlrZStjb21tb24gbW9kdWxlcyB0byBoYXZlIHRvDQpzdXBwb3J0IHRoZW0uDQoNClRo ZSBZQU5HIHF1ZXN0aW9uIEkgc3VwcG9zZSBpcywgaXMgdGhlcmUgYW4gZWFzeSB3YXkgdG8gbW92 ZSB0aGVzZQ0KY29udGFpbmVycyBmcm9tIGlwc2VjLWlrZWxlc3MgdG8gaXBzZWMtY29tbW9uLCBi dXQgc3RpbGwgYWxsb3cgZm9yIHRoZW0gdG8NCmJlIGVtcHR5IGFuZC9vciB1bmltcGxlbWVudGVk IGZvciB0aGUgU0ROIElLRSB1c2UgY2FzZT8gSWYgdGhleSB3ZXJlIG1hZGUNCmZlYXR1cmVzLCBp cyB0aGVyZSBhIHByb3BlciBZQU5HIHdheSB0byBpbmRpY2F0ZSB0aGF0IGlmIHRoZSBpa2VsZXNz DQptb2R1bGUgaXMgcHJlc2VudCB0aGVuIHRob3NlIGZlYXR1cmVzIG11c3QgYWxzbyBiZSBzdXBw b3J0ZWQgdGh1cyBtYXRjaGluZw0KdGhlIGZ1bmN0aW9uYWxpdHkgYXMgZGVmaW5lZCBieSB0aGUg Y3VycmVudCBkcmFmdD8NCg0KVGhhbmtzLA0KQ2hyaXMuDQoNCg0KDQoNCg0KT24gQXVnIDI0LCAy MDIwLCBhdCAxMDozNyBBTSwgTWFydGluIEJqw7Zya2x1bmQgdmlhIERhdGF0cmFja2VyDQo8bm9y ZXBseUBpZXRmLm9yZzxtYWlsdG86bm9yZXBseUBpZXRmLm9yZz4+IHdyb3RlOg0KDQoNCg0KUmV2 aWV3ZXI6IE1hcnRpbiBCasO2cmtsdW5kDQpSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5pdHMN Cg0KSSBkaWQgYW4gZWFybHkgWUFORyBEb2N0b3IncyByZXZpZXcgb2YgdGhpcyBkcmFmdC4gIE1v c3Qgb2YgbXkNCmNvbW1lbnRzIHRoZW4gaGF2ZSBiZWVuIGFkZHJlc3NlZCBpbiB0aGlzIHZlcnNp b24uDQoNCkNvbW1lbnRzOg0KDQpvICBBcyBJIHdyb3RlIGluIG15IGVhcmx5IHJldmlldywgdGhl IFJGQyBlZGl0b3IgZW5mb3JjZXMgYSBjb21tb24NCiBmb3JtYXQgb2YgWUFORyBtb2R1bGVzLCBz byBpdCBpcyBiZXR0ZXIgdG8gYWRoZXJlIHRvIHRoaXMgZm9ybWF0DQogYmVmb3JlIHNlbmRpbmcg dGhlIGRyYWZ0IHRvIHRoZSBSRkMgZWRpdG9yLiAgVXNlDQoNCiAgIHB5YW5nIC1mIHlhbmcgLS15 YW5nLWxpbmUtbGVuZ3RoIDY5IDxGSUxFPg0KDQogdG8gZ2V0IGEgY29uc2lzdGVudCBsb29rLWFu ZC1mZWVsIGZvciB5b3VyIG1vZHVsZS4NCg0KIChZb3Ugd2lsbCBoYXZlIHRvIG1hbnVhbGx5IHJl LWZsb3cgZGVzY3JpcHRpb24gc3RhdGVtZW50cyBhZnRlcg0KIHRoaXMuKQ0KDQoNCm8gIFRoZXJl IGFyZSBzb21lIGxlYWZzIHRoYXQgYXJlIG9wdGlvbmFsIGluIHRoZSBtb2RlbCwgYnV0IHcvbyBh DQogZGVmYXVsdCB2YWx1ZSBhbmQgdy9vIGFuIGV4cGxhbmF0aW9uIG9mIHdoYXQgaGFwcGVucyBp ZiB0aGF0IGxlYWYNCiBpcyBub3Qgc2V0LiAgWW91IHNob3VsZCBmaW5kIHRob3NlIGFuZCBlaXRo ZXIgbWFrZSB0aGVtIG1hbmRhdG9yeSwNCiBhZGQgYSBkZWZhdWx0IHZhbHVlLCBvciBleHBsYWlu IHdoYXQgaXQgbWVhbnMgd2hlbiBpdCBpc24ndCBzZXQuDQogQXMgYW4gZXhhbXBsZSwNCiAvaXBz ZWMtaWtlL3BhZC9wYWQtZW50cnlwZWVyLWF1dGhlbnRpY2F0aW4vcHJlLXNoYXJlZC9zZWNyZXQN CiBpcyBvcHRpb25hbC4gIEkgc3VzcGVjdCB0aGF0IHRoaXMgbGVhZiBuZWVkcyB0byBiZSBtYW5k YXRvcnkuDQogQW5vdGhlciBleGFtcGxlIGlzIHRoZSBsZWFmIGVzcGVuY2FwLg0KDQoNCi9tYXJ0 aW4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K eWFuZy1kb2N0b3JzIG1haWxpbmcgbGlzdA0KeWFuZy1kb2N0b3JzQGlldGYub3JnPG1haWx0bzp5 YW5nLWRvY3RvcnNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3lhbmctZG9jdG9ycw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClJhZmEgTWFyaW4tTG9wZXosIFBoRA0KRGVwdC4gSW5mb3Jt YXRpb24gYW5kIENvbW11bmljYXRpb25zIEVuZ2luZWVyaW5nIChESUlDKQ0KRmFjdWx0eSBvZiBD b21wdXRlciBTY2llbmNlLVVuaXZlcnNpdHkgb2YgTXVyY2lhDQozMDEwMCBNdXJjaWEgLSBTcGFp bg0KVGVsZjogKzM0ODY4ODg4NTAxIEZheDogKzM0ODY4ODg0MTUxIGUtbWFpbDogcmFmYUB1bS5l czxtYWlsdG86cmFmYUB1bS5lcz4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkkybnNmIG1haWxpbmcgbGlzdA0KSTJuc2ZAaWV0Zi5vcmc8 bWFpbHRvOkkybnNmQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pMm5zZg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpSYWZhIE1hcmluLUxvcGV6LCBQaEQNCkRlcHQuIEluZm9ybWF0aW9uIGFu ZCBDb21tdW5pY2F0aW9ucyBFbmdpbmVlcmluZyAoRElJQykNCkZhY3VsdHkgb2YgQ29tcHV0ZXIg U2NpZW5jZS1Vbml2ZXJzaXR5IG9mIE11cmNpYQ0KMzAxMDAgTXVyY2lhIC0gU3BhaW4NClRlbGY6 ICszNDg2ODg4ODUwMSBGYXg6ICszNDg2ODg4NDE1MSBlLW1haWw6IHJhZmFAdW0uZXM8bWFpbHRv OnJhZmFAdW0uZXM+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCg0KDQoNCg== --_000_MN2PR11MB4366119EA0904BF1076AD896B5380MN2PR11MB4366namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q291cmllcjsNCglwYW5vc2UtMToyIDcgNCA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5h cHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNw YWNlO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkhpIFJhZmEsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3IgcmVwbHlpbmcgd2l0aCB0aGUgZXh0cmEgYmFj a2dyb3VuZCBpbmZvcm1hdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SXQgc2VlbXMgbGlrZSByZW5hbWluZyB0aGUgbW9k dWxlcywgYXMgeW91IHByb3Bvc2UgZm9yIHRoZSAtMDkgdmVyc2lvbiwgaXMgdGhlIHByYWdtYXRp YyBwYXRoIGZvcndhcmQgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8YnI+DQpSb2I8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBs YW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUmFmYSBNYXJp bi1Mb3BleiAmbHQ7cmFmYUB1bS5lcyZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAyMyBTZXB0ZW1i ZXIgMjAyMCAxMDoyOTxicj4NCjxiPlRvOjwvYj4gUm9iIFdpbHRvbiAocndpbHRvbikgJmx0O3J3 aWx0b25AY2lzY28uY29tJmd0OzsgQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9y ZyZndDs8YnI+DQo8Yj5DYzo8L2I+IFJhZmEgTWFyaW4tTG9wZXogJmx0O3JhZmFAdW0uZXMmZ3Q7 OyBpMm5zZkBpZXRmLm9yZzsgR2FicmllbCBMb3BleiAmbHQ7Z2FiaWxtQHVtLmVzJmd0OzsgZHJh ZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLmFsbEBpZXRmLm9yZzsgaXBz ZWNAaWV0Zi5vcmc7IGxhc3QtY2FsbEBpZXRmLm9yZzsgTWFydGluIEJqw7Zya2x1bmQgJmx0O21i aitpZXRmQDQ2Njguc2UmZ3Q7OyB5YW5nLWRvY3RvcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFtJMm5zZl0gW3lhbmctZG9jdG9yc10gWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJl dmlldyBvZiBkcmFmdC1pZXRmLWkybnNmLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24tMDg8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBSb2IsIChDaHJp cyk6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5 b3UgdmVyeSBtdWNoIGZvciB5b3VyIGFuc3dlcnMuIFBsZWFzZSBzZWUgb3VyIGNvbW1lbnRzIGlu bGluZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkVsIDIyIHNlcHQgMjAyMCwgYSBsYXMgMTc6MzgsIFJvYiBXaWx0b24gKHJ3aWx0b24pICZsdDs8 YSBocmVmPSJtYWlsdG86cndpbHRvbj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyI+cndpbHRv bj00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IGVzY3JpYmnDszo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJhZmEsPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgZ2V0 dGluZyBiYWNrIHRvIG1lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5ZZXMsIGNoYW5naW5nIHRoZSBuYW1lIG9mIHRoZSBtb2R1bGUgaXMgYW4g b2theSwgaWYgbm90IGlkZWFsLCByZXNvbHV0aW9uLiZuYnNwOyBCdXQgSSBhcHByZWNpYXRlIHRo YXQgeW91IGFsc28gd2FudCB0byBiZSBkb25lIHdpdGggdGhpcyB3b3JrLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkNvcnJlY3QsIGVzcGVjaWFsbHkgYXQgdGhpcyBwb2ludCBvZiB0aW1lLiBXZSBoYXZl IGJlZW4gZGlzY3Vzc2luZyB0aGlzIEktRCBmb3IgYSBsb25nIHRpbWUuIFRoZXJlIHdhcyBhIGNv bnNlbnN1cyBpbiB0aGUgV0cuIEkyTlNGIFdHIGNoYWlycyBjYW4gY29tbWVudCBhYm91dCB0aGlz LiBJbiBvdXIgb3BpbmlvbiwgdGhlIGNoYW5nZXMgdGhhdCBuZWVkIHRvIGJlIGFwcGxpZWQgYXJl IG1ham9yIGNoYW5nZXMNCiBmcm9tIHdoYXQgaXQgd2FzIGFwcHJvdmVkIGluIHRoZSBXRy4gSG93 ZXZlciwgdGhpcyBpcyBjb21pbmcgaW4gdGhlIOKAnGxhc3QgbWludXRl4oCdIGFuZCB3ZSBmZWVs IHRoaXMgaXMgbm90IG1lcmVseSBtb3ZpbmcgYSBmZXcgbGluZXMgZnJvbSBoZXJlIHRvIHRoZXJl LiBXZSBuZWVkIHRvIHVuZGVyc3RhbmQgdGhlIGltcGFjdCBvZiB0aGlzLiBUaGVyZWZvcmUsIGl0 IGlzIG5vdCBzbyB0cml2aWFsIGFzIGl0IG1heSBzZWVtLiBTZWUgYmVsb3cuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IEkg d291bGQgbGlrZSB0byBjaGVjazombmJzcDsgTXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IHRoZSBj aGFuZ2VzIHRoYXQgQ2hyaXMgaXMgcHJvcG9zaW5nIGFyZSBwcmV0dHkgc21hbGwuJm5ic3A7IEku ZS4gbW92ZSB0aGUgU0Egc3RydWN0dXJlIHVuZGVyIGlwc2VjLWNvbW1vbiwgYW5kIHB1dCBpdCB1 bmRlciBhIFlBTkcgZmVhdHVyZS4mbmJzcDsgQXJlIHlvdSBzdXJlIHRoYXQgaXQgaXMgaW1wcmFj dGljYWwgdG8gYWNjb21tb2RhdGUNCiB0aGlzIGNoYW5nZSB3aGljaCB3b3VsZCBhbGxvdyBhIHNp bmdsZSBpcHNlYyBtb2R1bGUgdG8gYmUgc2hhcmVkIGFuZCBleHRlbmRlZCB2aWEgWUFORyBhdWdt ZW50YXRpb25zPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgY29udGV4dCBvZiBvdXIgSS1ELCBpZiB3 ZSBtb3ZlIFNBRCBzdHJ1Y3R1cmUgdG8gaXBzZWMtY29tbW9uLCB3aGF0IHdlIGFyZSBtZWFuaW5n IGlzIHRoYXQgSVBzZWMgU0EgY29uZmlndXJhdGlvbiBkYXRhIChzZXR0aW5nIHZhbHVlcyB0byB0 aGUgU0FEIHN0cnVjdHVyZSkgYXJlIGNvbW1vbiB0byB0aGUgSUtFIGNhc2UgYW5kIHRoZSBJS0Ut bGVzcyBjYXNlcywgd2hpY2ggYXJlIG5vdC4gSXQgaXMgY29uZnVzaW5nLg0KIE1vcmVvdmVyLCB0 aGUgdXNhZ2Ugb2YgZmVhdHVyZSBtZWFucyB0aGF0LCBhZnRlciBhbGwsIHRoaXMg4oCcY29tbW9u 4oCdIGlzIG5vdCDigJxjb21tb27igJ0gdG8gYm90aCBjYXNlcyBJS0UgY2FzZSBhbmQgSUtFLWxl c3MuIEFnYWluLCBpdCBzZWVtcyBjb25mdXNpbmcuIEluIHRoZSBJS0UgY2FzZSwgdGhlIFNETi9J Mk5TRiBjb250cm9sbGVyIGRvZXMgbm90IGNvbmZpZ3VyZSB0aGUgU0FEIGF0IGFsbCBidXQgdGhl IElLRSBpbXBsZW1lbnRhdGlvbiBpbiB0aGUNCiBOU0YuIEluIG91ciBvcGluaW9uLCBpbiBvcmRl ciB0byBwcm9wZXJseSBhZGQgdGhpcyBJUHNlYyBTQSBvcGVyYXRpb25hbCBzdGF0ZSB0byB0aGUg SUtFIGNhc2Ugd2Ugc2hvdWxkIGluY2x1ZGUgb3BlcmF0aW9uYWwgZGF0YSBhYm91dCB0aGUgSVBz ZWMgU0FzIChjb25maWcgZmFsc2UpIHRvIHRoZSBpZXRmLWlwc2VjLWlrZS4gQWx0ZXJuYXRpdmVs eSwgd2UgaGF2ZSBjZXJ0YWluIG9wZXJhdGlvbmFsIGRhdGEgKHJvKSBpbiB0aGUgU0FEIHN0cnVj dHVyZQ0KIGluIHRoZSBJS0UtbGVzcyBjYXNlLiBJZiBvbmx5IHRob3NlIGFyZSBtb3ZlZCB0byB0 aGUgY29tbW9uIHBhcnQgc2hvdWxkIGJlIG9rIGJ1dCB3ZSB0aGluayBpdCBkb2VzIG5vdCBzb2x2 ZSB0aGUgcHJvYmxlbS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhlcmVmb3JlIGl0IGlzIG5vdCBvbmx5IGFuIGltcGxlbWVudGF0 aW9uIGFzcGVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QXMgeW91IG1heSBvYnNlcnZlLCBvdXIgZGlzY3Vzc2lvbiBpcyB0YWtpbmcgaW50 byBhY2NvdW50IHRoZXJlIGlzIGFuIEkyTlNGIENvbnRyb2xsZXIgYW5kIHdlIGhhdmUgdHdvIGNh c2VzIElLRSBjYXNlIGFuZCBJS0UtbGVzcyBjYXNlLCB0aGF0IGhhdmUgYmVlbiBkaXNjdXNzZWQg aW4gdGhlIFdHLiBUaGUgWUFORyBtb2RlbCBpbiB0aGUgSS1EIGhhcyB0cmllZCB0byByZWZsZWN0 IHRoaXMgZGlzY3Vzc2lvbi4NCiBJdCB3YXMgbmV2ZXIgdGhlIGludGVudGlvbiB0byBwcm92aWRl IGEgZ2VuZXJhbCBZQU5HIG1vZGVsIGZvciBJUHNlYy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCBSZWdhcmRzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Sb2I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPlJhZmEgTWFyaW4tTG9wZXogJmx0Ozxh IGhyZWY9Im1haWx0bzpyYWZhQHVtLmVzIj5yYWZhQHVtLmVzPC9hPiZndDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPGI+U2VudDo8L2I+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjIyIFNlcHRlbWJl ciAyMDIwIDE0OjA1PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5Sb2IgV2lsdG9uIChyd2lsdG9uKSAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5S YWZhIE1hcmluLUxvcGV6ICZsdDs8YSBocmVmPSJtYWlsdG86cmFmYUB1bS5lcyI+cmFmYUB1bS5l czwvYT4mZ3Q7OyBDaHJpc3RpYW4gSG9wcHMgJmx0OzxhIGhyZWY9Im1haWx0bzpjaG9wcHNAY2hv cHBzLm9yZyI+Y2hvcHBzQGNob3Bwcy5vcmc8L2E+Jmd0OzsgR2FicmllbCBMb3BleiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmdhYmlsbUB1bS5lcyI+Z2FiaWxtQHVtLmVzPC9hPiZndDs7DQo8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLmFsbEBp ZXRmLm9yZyI+ZHJhZnQtaWV0Zi1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLmFsbEBp ZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86aTJuc2ZAaWV0Zi5vcmciPmkybnNmQGlldGYu b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlwc2VjQGlldGYub3JnIj4NCmlwc2VjQGlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmxhc3QtY2FsbEBpZXRmLm9yZyI+bGFzdC1jYWxsQGlldGYu b3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnlhbmctZG9jdG9yc0BpZXRmLm9yZyI+DQp5YW5nLWRv Y3RvcnNAaWV0Zi5vcmc8L2E+OyBNYXJ0aW4gQmrDtnJrbHVuZCAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1iaitpZXRmQDQ2Njguc2UiPm1iaitpZXRmQDQ2Njguc2U8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5S ZTogW3lhbmctZG9jdG9yc10gWWFuZ2RvY3RvcnMgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1p ZXRmLWkybnNmLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24tMDg8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EZWFyIFJvYjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFwb2xvZ2llcyBmb3Igb3VyIGRlbGF5ZWQg YW5zd2VyLiBXZSBhcmUgbm93IHdvcmtpbmcgaW4gdGhlIHJldmlzaW9uIHRvIHN1Ym1pdCB2MDkg YnkgY29tcGlsaW5nIGFsbCB0aGUgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFzIHlvdSBtZW50aW9uZWQsIHdlIHdhbnQgdG8gYXZvaWQgYW55IGZ1cnRoZXIgZGVsYXkuIEFz IHdlIG1lbnRpb25lZCB0byBDaHJpcyBpbiB0aGUgcGFzdCAoaTJuc2YgbWFpbGluZyBsaXN0KSwg d2UgZG8gbm90IGhhdmUgYW55IHByb2JsZW0gdG8gaW5jbHVkZSBzb21lIGFkZGl0aW9uYWwgdGV4 dCAoZS5nLiDigJwtc2RuLSZxdW90OyBpbiB0aGUgbW9kdWxlIG5hbWVzKS4gVGhlcmVmb3JlLCBS b2IsIHdlIGFncmVlIHdpdGgNCiB5b3VyIHBvaW50IG9mIHZpZXcgYWJvdXQgdGhpcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gc3VtbWFyeSwgd2UgYXJlIHdvcmtpbmcgaW4gdGhlIG5l eHQgcmV2aXNpb24gdjA5LCBhbmQgb3VyIGlkZWEgdG8gYWRkcmVzcyBDaHJpc+KAmSBjb21tZW50 cyB3YXMgdG8gaW5jbHVkZSAtc2RuLSB0byB0aGUgbW9kdWxlIG5hbWVzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XZSBob3BlIHRoaXMgaXMgZmluZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmVzdCByZWdhcmRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWwgMjIgc2VwdCAy MDIwLCBhIGxhcyAxMzo1NiwgUm9iIFdpbHRvbiAocndpbHRvbikgJmx0OzxhIGhyZWY9Im1haWx0 bzpyd2lsdG9uQGNpc2NvLmNvbSI+cndpbHRvbkBjaXNjby5jb208L2E+Jmd0OyBlc2NyaWJpw7M6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBkcmFmdCBhdXRob3JzLCBDaHJpcyw8YnI+DQo8YnI+DQpD YW4gd2UgYWxzbyBwbGVhc2UgdHJ5IGFuZCBjbG9zZSBvbiB0aGlzIGlzc3VlIHJhaXNlZCBieSBD aHJpcy48YnI+DQo8YnI+DQpDaHJpcywgSSBkb27igJl0IHRoaW5rIHRoYXQgdGhlcmUgaXMgYW55 IGdyZWF0IHdheSB0byBzb2x2ZSB0aGlzIGlzc3VlIHVzaW5nIFlBTkcgZmVhdHVyZXMsIGJ1dCBw cmVzdW1hYmx5IHRoZSBjb25zdHJhaW50IGNvdWxkIGJlIGVuZm9yY2VkIHdpdGggYSBtdXN0IHN0 YXRlbWVudCwgb3IgZ3JvdXBpbmdzIGNvdWxkIGJlIHVzZWQgdG8gY29weSBwYXJ0cyBvZiB0aGUg aXBzZWMgc3RydWN0dXJlIGludG8gYW4gc2RuIHNwZWNpZmljIGlwc2VjIHRyZWUNCiBzdHJ1Y3R1 cmUuPGJyPg0KPGJyPg0KSSB1bmRlcnN0YW5kIHRoYXQgdGhlcmUgaXNuJ3QgYW55IGdyZWF0IGRl c2lyZSB0byBkZWxheSB0aGVzZSBkcmFmdHMgYnkgdHJ5aW5nIHRvIGdlbmVyYWxpemUgdGhlIGlw c2VjIFlBTkcgbW9kZWwgY29udGFpbmVkIHdpdGhpbiBpdC4gJm5ic3A7SG93ZXZlciwgSSB0aGlu ayB0aGF0IG1lYW5zIHRoYXQgdGhlIG1vZHVsZXMgc2hvdWxkIGhhdmUgJnF1b3Q7LXNkbi0mcXVv dDsgaW4gdGhlaXIgbmFtZXMgdG8gaW5kaWNhdGUgdGhhdCB0aGV5IGFyZSBpbnRlbmRlZCBzcGVj aWZpY2FsbHkNCiBmb3IgdGhlIFNETiB1c2UgY2FzZSwgYW5kIHNob3VsZCBub3QgYmUgY29uZnVz ZWQgd2l0aCB0aGUgbW9yZSBnZW5lcmljIGlwc2VjIFlBTkcgbW9kdWxlcyB0aGF0IGhhdmUgYmVl biBwcm9wb3NlZC48YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NClJvYjxicj4NCjxicj4NCjxicj4N Cjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IHlhbmctZG9j dG9ycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnlhbmctZG9jdG9ycy1ib3VuY2VzQGlldGYub3JnIj55 YW5nLWRvY3RvcnMtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBDaHJpc3Rp YW48YnI+DQpIb3Bwczxicj4NClNlbnQ6IDI0IEF1Z3VzdCAyMDIwIDE4OjA4PGJyPg0KVG86IE1h cnRpbiBCasO2cmtsdW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWJqK2lldGZANDY2OC5zZSI+bWJq K2lldGZANDY2OC5zZTwvYT4mZ3Q7PGJyPg0KQ2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzppMm5zZkBpZXRmLm9yZyI+aTJu c2ZAaWV0Zi5vcmc8L2E+OyBkcmFmdC1pZXRmLWkybnNmLXNkbi1pcHNlYy1mbG93LTxicj4NCjxh IGhyZWY9Im1haWx0bzpwcm90ZWN0aW9uLmFsbEBpZXRmLm9yZyI+cHJvdGVjdGlvbi5hbGxAaWV0 Zi5vcmc8L2E+OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YSBocmVmPSJtYWlsdG86aXBzZWNAaWV0Zi5vcmciPmlwc2VjQGlldGYub3JnPC9hPjs8c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmxhc3QtY2FsbEBpZXRmLm9yZyI+bGFzdC1jYWxsQGlldGYub3JnPC9hPjsNCiB5YW5nLTxi cj4NCjxhIGhyZWY9Im1haWx0bzpkb2N0b3JzQGlldGYub3JnIj5kb2N0b3JzQGlldGYub3JnPC9h Pjxicj4NClN1YmplY3Q6IFJlOiBbeWFuZy1kb2N0b3JzXSBZYW5nZG9jdG9ycyBsYXN0IGNhbGwg cmV2aWV3IG9mIGRyYWZ0LWlldGYtPGJyPg0KaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJvdGVjdGlv bi0wODxicj4NCjxicj4NClthZGRpbmcgaW4gaXBzZWNAXTxicj4NCjxicj4NCkhpLDxicj4NCjxi cj4NClRoaXMgZHJhZnQgd2FzIGRpc2N1c3NlZCBpbiBpcHNlY21lIGF0IHRoZSBsYXN0IElFVEYs IGFuZCB0aGVyZSB3YXMgYTxicj4NCmRlc2lyZSB0byBsb29rIGNsb3NlciBhdCBhIGNvdXBsZSBj aGFuZ2VzIHRoYXQgd291bGQgbWFrZSB0aGVzZSBtb2RlbHM8YnI+DQp1c2FibGUgYnkgaXBzZWMg Z2VuZXJhbGx5IHJhdGhlciB0aGFuIG9ubHkgZm9yIFNETnMuIE90aGVyd2lzZSB3ZSB3aWxsIGVu ZDxicj4NCnVwIHdpdGggMiBtb2RlbHMgdGhhdCBsb29rIHZlcnkgc2ltaWxhciBhbmQgZHVwbGlj YXRlIGFsbW9zdCBhbGwgdGhlPGJyPg0KZnVuY3Rpb25hbGl0eS4gVGhpcyB3YXMgZ29pbmcgdG8g YmUgZG9uZSBkdXJpbmcgdGhlIG5leHQgeWFuZyBkb2N0b3I8YnI+DQpyZXZpZXcsIGJ1dCBpdCBs b29rcyBsaWtlIHRoYXQgaGFwcGVuZWQgaW4gdGhlIG1lYW50aW1lIChzaGlwcyBpbiB0aGU8YnI+ DQpuaWdodCkuPGJyPg0KPGJyPg0KQXQgbWluaW11bSB0aGUgbW9kdWxlIG5hbWVzIHNob3VsZCBp bmNsdWRlICZxdW90Oy1zZG4tJnF1b3Q7IGlmIG5vIG90aGVyIGNoYW5nZXMgYXJlPGJyPg0KbWFk ZSB0byBpbmRpY2F0ZSB0aGF0IHRoZXkgYXJlIG9ubHkgZm9yIHNkbiB1c2U7IGhvd2V2ZXIsIHRo aXMgaXMgbm90IHRoZTxicj4NCm9wdGltYWwgc29sdXRpb24uPGJyPg0KPGJyPg0KQSBiZXR0ZXIg c29sdXRpb24gd291bGQgYmUgdG8gbW92ZSB0aGUgY29udGFpbmVycyBjdXJyZW50bHkgdW5kZXIg aWtlbGVzczxicj4NCihmb3IgU0EgYW5kIFBvbGljeSBkYXRhYmFzZXMpIHVuZGVyIGlwc2VjLWNv bW1vbi48YnI+DQo8YnI+DQpUaGUgZmVlZGJhY2sgSSByZWNlaXZlZCBmcm9tIHRoZSBhdXRob3Jz IHdhcyB0aGF0IHRoZSBTRE4gY29udHJvbGxlcnM8YnI+DQpkaWRuJ3QgY2FyZSBhYm91dCB0aGUg YWN0dWFsIFNBcyBhbmQgcG9saWNpZXMgd2hlbiB1c2luZyBJS0Ugc28gdGhleTxicj4NCmRpZG4n dCB3YW50IHRvIHJlcXVpcmUgc29tZW9uZSBpbXBsZW1lbnRpbmcgaWtlK2NvbW1vbiBtb2R1bGVz IHRvIGhhdmUgdG88YnI+DQpzdXBwb3J0IHRoZW0uPGJyPg0KPGJyPg0KVGhlIFlBTkcgcXVlc3Rp b24gSSBzdXBwb3NlIGlzLCBpcyB0aGVyZSBhbiBlYXN5IHdheSB0byBtb3ZlIHRoZXNlPGJyPg0K Y29udGFpbmVycyBmcm9tIGlwc2VjLWlrZWxlc3MgdG8gaXBzZWMtY29tbW9uLCBidXQgc3RpbGwg YWxsb3cgZm9yIHRoZW0gdG88YnI+DQpiZSBlbXB0eSBhbmQvb3IgdW5pbXBsZW1lbnRlZCBmb3Ig dGhlIFNETiBJS0UgdXNlIGNhc2U/IElmIHRoZXkgd2VyZSBtYWRlPGJyPg0KZmVhdHVyZXMsIGlz IHRoZXJlIGEgcHJvcGVyIFlBTkcgd2F5IHRvIGluZGljYXRlIHRoYXQgaWYgdGhlIGlrZWxlc3M8 YnI+DQptb2R1bGUgaXMgcHJlc2VudCB0aGVuIHRob3NlIGZlYXR1cmVzIG11c3QgYWxzbyBiZSBz dXBwb3J0ZWQgdGh1cyBtYXRjaGluZzxicj4NCnRoZSBmdW5jdGlvbmFsaXR5IGFzIGRlZmluZWQg YnkgdGhlIGN1cnJlbnQgZHJhZnQ/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCkNocmlzLjxicj4N Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgMjQsIDIwMjAsIGF0IDEwOjM3IEFN LCBNYXJ0aW4gQmrDtnJrbHVuZCB2aWEgRGF0YXRyYWNrZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDs8YSBocmVm PSJtYWlsdG86bm9yZXBseUBpZXRmLm9yZyI+bm9yZXBseUBpZXRmLm9yZzwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQpSZXZpZXdlcjogTWFydGluIEJqw7Zya2x1bmQ8YnI+DQpS ZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIE5pdHM8YnI+DQo8YnI+DQpJIGRpZCBhbiBlYXJseSBZ QU5HIERvY3RvcidzIHJldmlldyBvZiB0aGlzIGRyYWZ0LiAmbmJzcDtNb3N0IG9mIG15PGJyPg0K Y29tbWVudHMgdGhlbiBoYXZlIGJlZW4gYWRkcmVzc2VkIGluIHRoaXMgdmVyc2lvbi48YnI+DQo8 YnI+DQpDb21tZW50czo8YnI+DQo8YnI+DQpvICZuYnNwO0FzIEkgd3JvdGUgaW4gbXkgZWFybHkg cmV2aWV3LCB0aGUgUkZDIGVkaXRvciBlbmZvcmNlcyBhIGNvbW1vbjxicj4NCiZuYnNwO2Zvcm1h dCBvZiBZQU5HIG1vZHVsZXMsIHNvIGl0IGlzIGJldHRlciB0byBhZGhlcmUgdG8gdGhpcyBmb3Jt YXQ8YnI+DQombmJzcDtiZWZvcmUgc2VuZGluZyB0aGUgZHJhZnQgdG8gdGhlIFJGQyBlZGl0b3Iu ICZuYnNwO1VzZTxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO3B5YW5nIC1mIHlhbmcgLS15 YW5nLWxpbmUtbGVuZ3RoIDY5ICZsdDtGSUxFJmd0Ozxicj4NCjxicj4NCiZuYnNwO3RvIGdldCBh IGNvbnNpc3RlbnQgbG9vay1hbmQtZmVlbCBmb3IgeW91ciBtb2R1bGUuPGJyPg0KPGJyPg0KJm5i c3A7KFlvdSB3aWxsIGhhdmUgdG8gbWFudWFsbHkgcmUtZmxvdyBkZXNjcmlwdGlvbiBzdGF0ZW1l bnRzIGFmdGVyPGJyPg0KJm5ic3A7dGhpcy4pPGJyPg0KPGJyPg0KPGJyPg0KbyAmbmJzcDtUaGVy ZSBhcmUgc29tZSBsZWFmcyB0aGF0IGFyZSBvcHRpb25hbCBpbiB0aGUgbW9kZWwsIGJ1dCB3L28g YTxicj4NCiZuYnNwO2RlZmF1bHQgdmFsdWUgYW5kIHcvbyBhbiBleHBsYW5hdGlvbiBvZiB3aGF0 IGhhcHBlbnMgaWYgdGhhdCBsZWFmPGJyPg0KJm5ic3A7aXMgbm90IHNldC4gJm5ic3A7WW91IHNo b3VsZCBmaW5kIHRob3NlIGFuZCBlaXRoZXIgbWFrZSB0aGVtIG1hbmRhdG9yeSw8YnI+DQombmJz cDthZGQgYSBkZWZhdWx0IHZhbHVlLCBvciBleHBsYWluIHdoYXQgaXQgbWVhbnMgd2hlbiBpdCBp c24ndCBzZXQuPGJyPg0KJm5ic3A7QXMgYW4gZXhhbXBsZSw8YnI+DQombmJzcDsvaXBzZWMtaWtl L3BhZC9wYWQtZW50cnlwZWVyLWF1dGhlbnRpY2F0aW4vcHJlLXNoYXJlZC9zZWNyZXQ8YnI+DQom bmJzcDtpcyBvcHRpb25hbC4gJm5ic3A7SSBzdXNwZWN0IHRoYXQgdGhpcyBsZWFmIG5lZWRzIHRv IGJlIG1hbmRhdG9yeS48YnI+DQombmJzcDtBbm90aGVyIGV4YW1wbGUgaXMgdGhlIGxlYWYgZXNw ZW5jYXAuPGJyPg0KPGJyPg0KPGJyPg0KL21hcnRpbjxicj4NCjxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KeWFuZy1kb2N0b3Jz IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzp5YW5nLWRvY3RvcnNAaWV0Zi5vcmci PnlhbmctZG9jdG9yc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3lhbmctZG9jdG9ycyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby95YW5nLWRvY3RvcnM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6Q291cmll ciI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTxicj4NClJhZmEgTWFyaW4tTG9wZXosIFBoRDxicj4NCkRlcHQuIEluZm9ybWF0aW9uIGFuZCZu YnNwO0NvbW11bmljYXRpb25zJm5ic3A7RW5naW5lZXJpbmcgKERJSUMpPGJyPg0KRmFjdWx0eSBv ZiBDb21wdXRlciZuYnNwO1NjaWVuY2UtVW5pdmVyc2l0eSBvZiZuYnNwO011cmNpYTxicj4NCjMw MTAwIE11cmNpYSAtIFNwYWluPGJyPg0KVGVsZjogKzM0ODY4ODg4NTAxIEZheDombmJzcDsrMzQ4 Njg4ODQxNTE8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGEgaHJlZj0ibWFpbHRvOnJhZmFAdW0uZXMiPmUtbWFpbDombmJzcDtyYWZhQHVtLmVzPC9hPjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTpDb3VyaWVyIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTpDb3VyaWVyIj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkkybnNm IG1haWxpbmcgbGlzdDxicj4NCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86STJuc2ZAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXIiPkkybnNm QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTpDb3VyaWVyIj48YnI+DQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pMm5zZiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6Q291cmllciI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p Mm5zZjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTpDb3VyaWVyO2NvbG9yOmJsYWNrIj4tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KUmFmYSBNYXJpbi1M b3BleiwgUGhEPGJyPg0KRGVwdC4gSW5mb3JtYXRpb24gYW5kJm5ic3A7Q29tbXVuaWNhdGlvbnMm bmJzcDtFbmdpbmVlcmluZyAoRElJQyk8YnI+DQpGYWN1bHR5IG9mIENvbXB1dGVyJm5ic3A7U2Np ZW5jZS1Vbml2ZXJzaXR5IG9mJm5ic3A7TXVyY2lhPGJyPg0KMzAxMDAgTXVyY2lhIC0gU3BhaW48 YnI+DQpUZWxmOiArMzQ4Njg4ODg1MDEgRmF4OiZuYnNwOyszNDg2ODg4NDE1MSA8YSBocmVmPSJt YWlsdG86cmFmYUB1bS5lcyI+ZS1tYWlsOiZuYnNwO3JhZmFAdW0uZXM8L2E+PGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OkNvdXJpZXI7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_MN2PR11MB4366119EA0904BF1076AD896B5380MN2PR11MB4366namp_-- From nobody Wed Sep 23 03:39:42 2020 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 32B3E3A0E49; Wed, 23 Sep 2020 03:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 iPV-bK1qMcfQ; Wed, 23 Sep 2020 03:39:35 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70102.outbound.protection.outlook.com [40.107.7.102]) (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 CC44E3A0BC0; Wed, 23 Sep 2020 03:39:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bVBOxlcEetOKX8aQXRRxK3NeObyYsX1JvIeH2o2BzK2md414/d4/VRhkQ4fOV9Pnn5qDXb7/lqv+ThpThRPbm3kuiVV1W48yzWAhMKbYE/RwF/25QbkgxavWnQnK7YWbIu9u3Akk9uTHnnZQwDbwz62oa8OdH8EIYKsMAbCaOmKJffmOUnZWInSZ/3joYRma4P8/BLs5WQoS4Z4zVnQB6kgRQDKONWAtzvLlchVMgwD6xtdtS5F/+YPVqPKhrHGnT5IjakAFBkTqIG95W/aZJXmv/5sVQKf/aUO+OTVMqI5IhQQnAZYVOASO5RZULJOxVMxC80YoS14Tf64iRdQs7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s0OvRmLgLymSIa+6/WqIX3WjgyRMeL2kRJA9L1GzsEA=; b=dMXuRjPsyencAH/qortQD5qHFQmvKA+8x0JOJ60SbQE3WhWvObESnENRw/bDzxgX6DK/n6Sah5TvJMSl2ocZT5fZ2jvXOxMoKkk/DQxAF0eosdmtDGd/F3n9n72mh2y6xrDfP/QaxFGzA0gzwpMlkwLcuLXdndmBS9TVM69SD2H8TOouf5LsMZPTjGN+f3xgDWp2hHIyjsppoCpFlEoE3Xwxbe2iSqOSU1Ii3O7t46cBXBSF7ojkgcKX8EGBv2CySzFekxfZMVAM5hhZLuSSq4k/76F2ajnnlP9Ue17w0LLPCCTqoFhA9jKfMUFwxFZpJhG6BJKemsaJ/IfS/yRecw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s0OvRmLgLymSIa+6/WqIX3WjgyRMeL2kRJA9L1GzsEA=; b=aV1BtUuVsbFpNM2vUc971qSQUG044cylWK/W5kl/+KmWCklAyY+N+NAsIwjeWGePIQjL0IvmpHrBT+ZLVxAkuUH5SB5c7TJcF63XLRgTp6wBoe87eiqsYQu5fZAFG1X1sI9HuG1zy16rbVV3A/kJGLXE0bNx2iXxKaQQhgnN4Es= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR0701MB2543.eurprd07.prod.outlook.com (2603:10a6:800:6f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.15; Wed, 23 Sep 2020 10:39:30 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db%5]) with mapi id 15.20.3412.020; Wed, 23 Sep 2020 10:39:30 +0000 To: =?UTF-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= , Tero Kivinen References: <5F44E66D.6080408@btconnect.com> <24426.14679.827153.422523@fireball.acr.fi> Cc: Roman Danyliw , i2nsf@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org, "ipsec@ietf.org WG" , LAST-CALL@ietf.org, i2nsf-chairs@ietf.org From: tom petch Message-ID: <5F6B25DF.8010508@btconnect.com> Date: Wed, 23 Sep 2020 11:39:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0205.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::25) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.153.136.175) by LO2P265CA0205.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3412.20 via Frontend Transport; Wed, 23 Sep 2020 10:39:29 +0000 X-Originating-IP: [86.153.136.175] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 00d39633-184f-4fb0-8dce-08d85facf3c7 X-MS-TrafficTypeDiagnostic: VI1PR0701MB2543: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5cIwYDLvQ0Y1YsmFHx1WAuR3QGiEe7J9KMV6/8Hxeq7PUZCG7It3+ePt/lKJL++D/izhO3ORa0xk97hme38V8/JMv/TVif8lGK6zulT9suPdi3FcOmy0+F6ZJNBH6pcpZMOlp/KvSyvxOYGpDhVDLrmd4gIMRvKScmgqo9lFNadz9OsDowS0lgmvVqpMdLIyp5kMG1u+4Q94/hpGo2MQmeIb2lFI/9mLLl1bLv/sZct6ivdESv4IUZBvQ0a6LSBYdf5n69P+QJMv+AhK8OtlPQV6xoyhcHa6hkHFG4SZlYLDUpnwa/1Sgk30h1HYuc1hkkPi1YMi/jUyKiW52cHIwQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(366004)(39860400002)(376002)(346002)(8676002)(478600001)(4326008)(8936002)(66574015)(110136005)(316002)(16576012)(5660300002)(2616005)(16526019)(53546011)(33656002)(66946007)(52116002)(66476007)(26005)(6486002)(87266011)(86362001)(83380400001)(2906002)(54906003)(956004)(36756003)(186003)(66556008); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: uOEwTgJyUv6BuFGczl/bUCGyWcgucfg0RD98oAPYnv2kk0fsh4CoAs/Bym476HhzSi2EiY5si1Fs3nJP/askOLnFNg9Blzt4prvx7414zAwbu1lXihRdwR7PJA2QkiXZU2B0XB38+zBFkxpPYFuGOFiIwxIAz29olhrq4nUqHl2QQOwSrrWGcATX9TWimCElRakRydInkV1ZtdtwMhhJtTPt+9sQCJ1rEqErb/fBb7q/+MqY38L0Vn7CZ8vMQFhb6C9L8AXV0Xt9kr+GW7OhiN/hay03fySkIMZ/wX/eZtvPYDGOK4vk8CkqGttGkcSBpi9TvP15KzZSUeGhEX3pzmVLH518LOdme9YPiNSEIGary7cOd2gBNiBca75LU24HQAqf5oCgbjPD+Hoyn5RpYkblpflSE0DMD+isHAGqwg/x7mJQ2kmOVzTg0NHpjU4hRXsydddYlcYiXFXeSI36xWOqxAACwVdU1ZP3VkZ1gvRmecX1+rtDDNPfh/Ugb0RZtBxBIMR0QzSKQHXwjtr5cvse1q2cPQhDrh+PIVm7LmBCI1wMj7/vr6OyQmANOvxtj8v9kqgezwqu+vadUCVoLcxGXGSy4uXU+0FtKp76X3zsqdExEBgk5JwgyxoC1DHdb+GY83GzDJ9OMGfW2I7sJA== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 00d39633-184f-4fb0-8dce-08d85facf3c7 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2020 10:39:30.3981 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 2dqQY9gX8TI4u4raM6ixiX+K9+R4pjvL+RcrXgkmCYL5FtVi7onOVHcBHXt9qIBvibF46Cr3L4v+V+EC6E4eNw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2543 Archived-At: Subject: Re: [IPsec] Last Call: (Software-Defined Networking (SDN)-based IPsec Flow Protection) to Proposed Standard 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, 23 Sep 2020 10:39:37 -0000 On 23/09/2020 07:16, Fernando Pereñíguez García wrote: > Hi Tero, > > Thank you very much for your clarification. We will update reference RFC > 822 accordingly in our draft. > > Tom, you proposed us to replace RFC 822 with 2822, but it is also obsoleted > by 5322. So, if you agree, we will reference RFC 5322 instead. That is fine by me; my comment was that RFC822 is obsoleted by RCC2822 so you should consider a more up-to-date version not that RFC2822 was the correct update! You said previously that you did not understand my comment on RFC6020 in IANA Considerations. It is fine. What I was trying to say is that in most places, RFC7950 is the better reference so RFC6020 should not be used but for IANA Considerations, RFC6020 is the better reference so when updating elsewhere in the I-D, leave IANA Considerations alone. Tom Petch > Best regards, > Fernando. > > El mar., 22 sept. 2020 a las 19:50, Tero Kivinen () > escribió: > >> Fernando Pereñíguez García writes: >>> I note that RFC822 and RFC3280 are Obsoleted which makes their use >>> problematic. >>> >>> [Authors] Following your recommendation, we have replaced RFC 3280 with >> RFC >>> 5280. Regarding RFC 822, we reference it because the IKEv2 protocol >>> specification (RFC 7296) explicitly defines RFC 822 emails address (see >> page >>> 90) as a valid identification type. If we replace RFC 822 with RFC 2821, >> we >>> don't know its impact on IKEv2. >> >> IKEv2 talks about RFC 822 email addresses, the reference points >> Internationalized Email Headers RFC 6532, with comment of: >> >> Because of [EAI], implementations would be wise to treat this >> field as UTF-8 encoded text, not as pure ASCII. >> >> So it uses RFC822 as name not as reference. There should not be any >> problems to replace that with newer versions. Most of the >> implementations simply consider that as a string and some cases they >> actually do not even follow the string email address format, as they >> add some routing information for AAAA in the end or something. >> -- >> kivinen@iki.fi >> > > From nobody Wed Sep 23 03:46:01 2020 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 B94D63A0F62; Wed, 23 Sep 2020 03:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=btconnect.onmicrosoft.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 y8g-yPaKicnx; Wed, 23 Sep 2020 03:45:50 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2132.outbound.protection.outlook.com [40.107.21.132]) (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 D8A2E3A0F63; Wed, 23 Sep 2020 03:45:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Wom5knw6Kruy6W/rHT4E3WTzCh8fxY+bRrihzQ+ceEGFwFKLA0jfFLdxU1c+0Rh8TyNAzuPVZukVMqOK/ShJYR85waIft/RvA+jx9aXFQfG0knHWGx/G4iVlottWlBemwieg6Vk0nPv03rP3YNpcmSx7Sf2SE5mavqw1QzL+Ci1DSbyuw1VaTLTvog1JkAsQPIL1jeRm9yM0pHhNNMI1WCRJB6Y7NYgRRlQbC0glsUThdM8jQsfGXVfueXOXMmi7x7beMaYSsQhaSPOf1Dls9XnyiFnrjSp9OOFPdAZMYZs5LbN53bRZSp9v1dUf3ocQYD9WVUdXLHT/eO/ULQyZYQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=efOeRHEJ6wGqDTY8GdMOGVD6OUaiM2Se+4N281BbXLI=; b=mmOwMwxITxAZBO+ePUUKaDVFkqshcv4k+d2X6e1eekoqa6TTQwmr7wGWxgwoz0CGfeAY7qJrtni5WYLoUw4Rb1kLR99DzHsGQ19AvHWfibSHB/9/62JGIsH50+9gEx9He587oXqHUTD1zP2p9gTbHSz/J4ig72U4k4h8k2yFhPxZSLvs18ghdyf8xkrWtszqbPO3qnxaqbSA97ItSCX5+EETrAYEqUqzYnp6dJtwT1r0kKe1se+Cw439paZisW2Zp52zF4IPCw0VNrOw5N1iODCDYGWK4S9ILWTIjGlFpLuS88Feq/p22HwgK09dAFtoBE9Q08b6bozozvwjSDW6ew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=efOeRHEJ6wGqDTY8GdMOGVD6OUaiM2Se+4N281BbXLI=; b=UPFMhFXkCb7s3nJkomDk//s+J4xYgaIZItJaVq6zYJrAz0dMGSgIKKmW3kUNviId+f1I7PUSrxkaAUWxP2z7iLW/KayhyBmvIwUnBEG0jIY14EB1VeNsGld5c3IFdUZbyDnO8T3mLxkTD/Piys4K2LP8yVm8gdUXXskAappV7PI= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR0701MB2543.eurprd07.prod.outlook.com (2603:10a6:800:6f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.15; Wed, 23 Sep 2020 10:45:46 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db%5]) with mapi id 15.20.3412.020; Wed, 23 Sep 2020 10:45:46 +0000 To: "Rob Wilton (rwilton)" , Rafa Marin-Lopez , Christian Hopps References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> Cc: "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , "yang-doctors@ietf.org" From: tom petch Message-ID: <5F6B2757.9010804@btconnect.com> Date: Wed, 23 Sep 2020 11:45:43 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P265CA0153.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::21) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.153.136.175) by LO2P265CA0153.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3412.20 via Frontend Transport; Wed, 23 Sep 2020 10:45:45 +0000 X-Originating-IP: [86.153.136.175] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 40d44741-f43b-43d0-b80d-08d85fadd3d3 X-MS-TrafficTypeDiagnostic: VI1PR0701MB2543: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6430; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Q/NI3CbzQB9ah1/kNF0HtGRieuxf9JLeIRkaXJID9+MwJayo1PznAGuxiWrTIbvSdrFN7GZ9jXxpzuODUqTwcvTxbMV74qmpvToYPZzn0vEC6sZT4H4tsVqn3kaH0EuZyyZlWO3/TeTRvi20ls1B99/O2JctX3FXGzFR6K2JDjmAkJ3s5VT1ir/KwjOdeWUbJ9i7tr8nU8V8iUd2eTQjDtfzkyx64aHdWPeMZSvxsNX4Y7P0Z1nFPQ9RQGo40IBU3ljJWdWEDIWqe8hpSXjuLr6ta4VmVgzUqEBmCZzNLbgVaHslZ6KphvoxLzYL1CUpzzriP5Ra7TvWe2eeHkmYYJ7sgJeQXO3pwwTVIiwmABXBSgcRhKeQshnZu7xe3g95MRFwc1tyCEg/VQeef+nbMQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(39860400002)(376002)(396003)(136003)(5660300002)(16526019)(2616005)(30864003)(54906003)(956004)(2906002)(83380400001)(186003)(66556008)(36756003)(66946007)(52116002)(66476007)(53546011)(33656002)(87266011)(86362001)(6486002)(26005)(8936002)(8676002)(7416002)(4326008)(478600001)(316002)(966005)(16576012)(110136005)(66574015); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: Dg1zL31aZ33GL3gEs7WRctr31cKgVtpj3B/dyGUhpeKq+0PHxSQVZ2d5+kryJ7CrX5+U/e8X3oKw6kKeh1QCj6o+80HeOU7gPqzm4YA4pw1QbS5fYYsmzAJfQgeXHNQfB9rTM7uPctiKIr39ul1m7cY51s/KJMS8dCVhnNTJiTI8ngNimPomWZt0CLwS/yOi4DDJB9Io+0F3tVMhRaUnENQE0BFhL9zUIfnpojCq+KTbMI2FHqXA/dS4A/qzP7Yxc1OchZt0shgwBZDP/ZzPyGpBtok+kLbliLwboMTk/RNv2u8ZwZ0Pu85jTpbdcGfEjkEBPqD94Uk2JpodVvTpTaPPdo7eOmpvNB8llUevMSsfKWQBymMxMaxZM1ypu8lKwjMt4v3qfkmMRIn477+P7ZIKpGanO4EM7ApJKHioqtliRtNWEylMD4idR3NeBRoIMGrhwkNnGYZFVHOAg53GjPCIRQmCTdsq1eqUQ2YDojaa1q1nHYKekTzHVvUNM+ueelNA8aljH8V73MbjsMyzkcBQWSjX4y5/lmPjmTQ4+xVIVB6HExrjh3kAWN4lpl9S8sckTejZAfIwtRjdo8ABkHXR2qtOv7W91NXOF8m0bHJlzLIY8N/yfhbfMYLaBc0Uqb4vc7ECPjcF5q6P+aEsQg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 40d44741-f43b-43d0-b80d-08d85fadd3d3 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2020 10:45:46.4308 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: oUGHb9w6gLPPFPWLD5uN7QxLtCrkuaFdm/3luQ/N369KdNxo6cd/xXnaFafv7R1dIqwYcfNvk0J9C62IrAQLeA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2543 Archived-At: Subject: Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 23 Sep 2020 10:45:53 -0000 On 23/09/2020 11:24, Rob Wilton (rwilton) wrote: > Hi Rafa, > > Thanks for replying with the extra background information. > > It seems like renaming the modules, as you propose for the -09 version, is the pragmatic path forward here. And the namespace and the YANG prefix IMHO. Having ike as a prrefix for a module which is not the 'ike' module I see as a source of confusion. If this is nsf specific, then I would suggest nsfike although nsfikeless then seems a bit long. Tom Petch > Regards, > Rob > > > From: Rafa Marin-Lopez > Sent: 23 September 2020 10:29 > To: Rob Wilton (rwilton) ; Christian Hopps > Cc: Rafa Marin-Lopez ; i2nsf@ietf.org; Gabriel Lopez ; draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; Martin Bjrklund ; yang-doctors@ietf.org > Subject: Re: [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 > > Hi Rob, (Chris): > > Thank you very much for your answers. Please see our comments inline. > > > El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) > escribi: > > Hi Rafa, > > Thanks for getting back to me. > > Yes, changing the name of the module is an okay, if not ideal, resolution. But I appreciate that you also want to be done with this work. > > Correct, especially at this point of time. We have been discussing this I-D for a long time. There was a consensus in the WG. I2NSF WG chairs can comment about this. In our opinion, the changes that need to be applied are major changes from what it was approved in the WG. However, this is coming in the last minute and we feel this is not merely moving a few lines from here to there. We need to understand the impact of this. Therefore, it is not so trivial as it may seem. See below. > > > > But I would like to check: My understanding is that the changes that Chris is proposing are pretty small. I.e. move the SA structure under ipsec-common, and put it under a YANG feature. Are you sure that it is impractical to accommodate this change which would allow a single ipsec module to be shared and extended via YANG augmentations? > > > In the context of our I-D, if we move SAD structure to ipsec-common, what we are meaning is that IPsec SA configuration data (setting values to the SAD structure) are common to the IKE case and the IKE-less cases, which are not. It is confusing. Moreover, the usage of feature means that, after all, this common is not common to both cases IKE case and IKE-less. Again, it seems confusing. In the IKE case, the SDN/I2NSF controller does not configure the SAD at all but the IKE implementation in the NSF. In our opinion, in order to properly add this IPsec SA operational state to the IKE case we should include operational data about the IPsec SAs (config false) to the ietf-ipsec-ike. Alternatively, we have certain operational data (ro) in the SAD structure in the IKE-less case. If only those are moved to the common part should be ok but we think it does not solve the problem. > > Therefore it is not only an implementation aspect. > > As you may observe, our discussion is taking into account there is an I2NSF Controller and we have two cases IKE case and IKE-less case, that have been discussed in the WG. The YANG model in the I-D has tried to reflect this discussion. It was never the intention to provide a general YANG model for IPsec. > > Best Regards. > > > Thanks, > Rob > > > From: Rafa Marin-Lopez > > Sent: 22 September 2020 14:05 > To: Rob Wilton (rwilton) > > Cc: Rafa Marin-Lopez >; Christian Hopps >; Gabriel Lopez >; draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; i2nsf@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang-doctors@ietf.org; Martin Bjrklund > > Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 > > Dear Rob: > > Apologies for our delayed answer. We are now working in the revision to submit v09 by compiling all the comments. > > As you mentioned, we want to avoid any further delay. As we mentioned to Chris in the past (i2nsf mailing list), we do not have any problem to include some additional text (e.g. -sdn-" in the module names). Therefore, Rob, we agree with your point of view about this. > > In summary, we are working in the next revision v09, and our idea to address Chris comments was to include -sdn- to the module names. > > We hope this is fine. > > Best regards. > > > > El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) > escribi: > > Hi draft authors, Chris, > > Can we also please try and close on this issue raised by Chris. > > Chris, I dont think that there is any great way to solve this issue using YANG features, but presumably the constraint could be enforced with a must statement, or groupings could be used to copy parts of the ipsec structure into an sdn specific ipsec tree structure. > > I understand that there isn't any great desire to delay these drafts by trying to generalize the ipsec YANG model contained within it. However, I think that means that the modules should have "-sdn-" in their names to indicate that they are intended specifically for the SDN use case, and should not be confused with the more generic ipsec YANG modules that have been proposed. > > Regards, > Rob > > > > > -----Original Message----- > From: yang-doctors > On Behalf Of Christian > Hopps > Sent: 24 August 2020 18:08 > To: Martin Bjrklund > > Cc: i2nsf@ietf.org; draft-ietf-i2nsf-sdn-ipsec-flow- > protection.all@ietf.org; ipsec@ietf.org; last-call@ietf.org; yang- > doctors@ietf.org > Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf- > i2nsf-sdn-ipsec-flow-protection-08 > > [adding in ipsec@] > > Hi, > > This draft was discussed in ipsecme at the last IETF, and there was a > desire to look closer at a couple changes that would make these models > usable by ipsec generally rather than only for SDNs. Otherwise we will end > up with 2 models that look very similar and duplicate almost all the > functionality. This was going to be done during the next yang doctor > review, but it looks like that happened in the meantime (ships in the > night). > > At minimum the module names should include "-sdn-" if no other changes are > made to indicate that they are only for sdn use; however, this is not the > optimal solution. > > A better solution would be to move the containers currently under ikeless > (for SA and Policy databases) under ipsec-common. > > The feedback I received from the authors was that the SDN controllers > didn't care about the actual SAs and policies when using IKE so they > didn't want to require someone implementing ike+common modules to have to > support them. > > The YANG question I suppose is, is there an easy way to move these > containers from ipsec-ikeless to ipsec-common, but still allow for them to > be empty and/or unimplemented for the SDN IKE use case? If they were made > features, is there a proper YANG way to indicate that if the ikeless > module is present then those features must also be supported thus matching > the functionality as defined by the current draft? > > Thanks, > Chris. > > > > > > On Aug 24, 2020, at 10:37 AM, Martin Bjrklund via Datatracker > > wrote: > > > > Reviewer: Martin Bjrklund > Review result: Ready with Nits > > I did an early YANG Doctor's review of this draft. Most of my > comments then have been addressed in this version. > > Comments: > > o As I wrote in my early review, the RFC editor enforces a common > format of YANG modules, so it is better to adhere to this format > before sending the draft to the RFC editor. Use > > pyang -f yang --yang-line-length 69 > > to get a consistent look-and-feel for your module. > > (You will have to manually re-flow description statements after > this.) > > > o There are some leafs that are optional in the model, but w/o a > default value and w/o an explanation of what happens if that leaf > is not set. You should find those and either make them mandatory, > add a default value, or explain what it means when it isn't set. > As an example, > /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret > is optional. I suspect that this leaf needs to be mandatory. > Another example is the leaf espencap. > > > /martin > > > _______________________________________________ > yang-doctors mailing list > yang-doctors@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > > ------------------------------------------------------- > 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 > ------------------------------------------------------- > > > > > _______________________________________________ > 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 > ------------------------------------------------------- > > > > > > From nobody Wed Sep 23 03:56:19 2020 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 552733A0F6C; Wed, 23 Sep 2020 03:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6ev7xRgjI4j1; Wed, 23 Sep 2020 03:56:12 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BF8383A0F6B; Wed, 23 Sep 2020 03:56:11 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id B9E57601E3; Wed, 23 Sep 2020 10:56:10 +0000 (UTC) From: Christian Hopps Message-Id: <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> Content-Type: multipart/signed; boundary="Apple-Mail=_BEC43563-6603-4BA4-99F2-9690E000EFE1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 23 Sep 2020 06:56:09 -0400 In-Reply-To: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> Cc: Christian Hopps , Robert Wilton , "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "yang-doctors@ietf.org" To: Rafa Marin-Lopez References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [IPsec] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 23 Sep 2020 10:56:14 -0000 --Apple-Mail=_BEC43563-6603-4BA4-99F2-9690E000EFE1 Content-Type: multipart/alternative; boundary="Apple-Mail=_AE12EB89-14E3-4A7E-BB13-72BF587EE110" --Apple-Mail=_AE12EB89-14E3-4A7E-BB13-72BF587EE110 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez wrote: >=20 >>=20 >>=20 >> But I would like to check: My understanding is that the changes that = Chris is proposing are pretty small. I.e. move the SA structure under = ipsec-common, and put it under a YANG feature. Are you sure that it is = impractical to accommodate this change which would allow a single ipsec = module to be shared and extended via YANG augmentations? >=20 >=20 > In the context of our I-D, if we move SAD structure to ipsec-common, = what we are meaning is that IPsec SA configuration data (setting values = to the SAD structure) are common to the IKE case and the IKE-less cases, = which are not. It is confusing. Something defined in a common module but marked as a feature does not = imply that that feature has to be implemented by an importing module. = This is not confusing to YANG implementers or users I think. If we are = just talking about document flow here, then a sentence saying "the SAD = feature is not required to implement IKE functionality" is quite enough = to clear that up I think. Thanks, Chris. > Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is not =E2=80=9Ccommon=E2=80=9D to both cases = IKE case and IKE-less. Again, it seems confusing. In the IKE case, the = SDN/I2NSF controller does not configure the SAD at all but the IKE = implementation in the NSF. In our opinion, in order to properly add this = IPsec SA operational state to the IKE case we should include operational = data about the IPsec SAs (config false) to the ietf-ipsec-ike. = Alternatively, we have certain operational data (ro) in the SAD = structure in the IKE-less case. If only those are moved to the common = part should be ok but we think it does not solve the problem. >=20 --Apple-Mail=_AE12EB89-14E3-4A7E-BB13-72BF587EE110 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@um.es> wrote:


 
But I would like to = check:  My understanding is that the changes that Chris is = proposing are pretty small.  I.e. move the SA structure under = ipsec-common, and put it under a YANG feature.  Are you sure that = it is impractical to accommodate this change which would allow a single = ipsec module to be shared and extended via YANG = augmentations?


In the context of = our I-D, if we move SAD structure to ipsec-common, what we are meaning = is that IPsec SA configuration data (setting values to the SAD = structure) are common to the IKE case and the IKE-less cases, which are = not. It is confusing.

Something defined in a common module but marked as = a feature does not imply that that feature has to be implemented by an = importing module. This is not confusing to YANG implementers or users I = think. If we are just talking about document flow here, then a sentence = saying "the SAD feature is not required to implement IKE functionality" = is quite enough to clear that up I think.

Thanks,
Chris.

Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is not =E2=80=9Ccommon=E2=80=9D to both cases = IKE case and IKE-less. Again, it seems confusing. In the IKE case, the = SDN/I2NSF controller does not configure the SAD at all but the IKE = implementation in the NSF. In our opinion, in order to properly add this = IPsec SA operational state to the IKE case we should include operational = data about the IPsec SAs (config false) to the ietf-ipsec-ike. = Alternatively, we have certain operational data (ro) in the SAD = structure in the IKE-less case. If only those are moved to the common = part should be ok but we think it does not solve the = problem. 


= --Apple-Mail=_AE12EB89-14E3-4A7E-BB13-72BF587EE110-- --Apple-Mail=_BEC43563-6603-4BA4-99F2-9690E000EFE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl9rKckACgkQLh2DDte4 MCXW5Q/+JWE17jhfffJONrCp5AjTKk4UwKiqIKjj0kDIQymOlF4D4HpUd9P5v4E4 jSrlP89qlX9QSnCRGNtYiCbQyddCh1+1a5QRkSnSR6Qnfo2Q+IFb78pb8PDYPIH7 qF6f1beb3nYJdwj1VoV9oX/gP+uU3g4w5xk8BonMBQMbvLzEj2tu88ThKTBw7pVZ xo67+IWaRwr7kkHX+Jyx5gdgP1QlKoFicSKTYGjOSNldbG9CyctGwt7y+p0pbDDd rNLp+Z2sDmcb7acFV3j+HcYEHGIe4cWy9GgJI3sntib06Bd73oQJFo83zQkp4lyQ 2ytakGPDyPvSdZqCaEd8ARoZ9GPDMfn7bkdh7Utp54QkcYHA1cKJq7BM/TTt91z6 x3fzEWQHClf9t6NU9QI090bXdQu/rYAjUVR5MOprZpDcKH/rrZLqjBvFwhy8P528 C9ZrHbqh7sNiB4meUm5FUuk6CAY9IxOcN/0jo3LAuqShBg2qx6ZTk5meXZ+88epZ H539cJiBPGWQP/ZZrAmwKn+jchjq64TI6DA/6xWSVKlqV2BHef3/QwLtQEIA4L4p eH3IchQm+f4I2TaHy5D7XBS3r+8TNx7lXBZoLgyjCjpz+DLwwMaarJwhokqfXgA0 gnkt6QjKvDGTe/srKPdjvj5A4UGC2exHr+rJstqYOug9V9wUi80= =pSBk -----END PGP SIGNATURE----- --Apple-Mail=_BEC43563-6603-4BA4-99F2-9690E000EFE1-- From nobody Wed Sep 23 04:19:00 2020 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 365EA3A0F94; Wed, 23 Sep 2020 04:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=upct.onmicrosoft.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 3dlwEylo_Exh; Wed, 23 Sep 2020 04:18:57 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60067.outbound.protection.outlook.com [40.107.6.67]) (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 E56C53A0F98; Wed, 23 Sep 2020 04:18:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bnMrsuRH4gNOHBJNjuGN0pHoQJqP78SB756l4/sVgeMnmGTbPPJ6YUIupCq7Ffydka542JvxAlxTrsVVIC2Umj6CQFGvqPaEEYo9WjUqOyRklCX4FbMTjEzyLNpXR3Ksfno+VsHNBcgdbmI2PlhvGoj1iH6UNTj4wCDGSlvjvKThPhfx90awWUMHsrEDgTSj/Cquker14fZoaIJuDDbd4CBITNKC7fSX/hC6xtB1dlFlFV6gAutPQc/N8fFxlpnyj9rDeisNf6puHPbvSaR6yNTgy2UooHGM7TIfwcM8cfDdCVtICKyd7WO2z10+3ZDv0Ph0su/wo/TM5byRBdyNSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KqK4qkK/6IB4v3xGhBN69fOzqmGrZLC3YVuGSJiw4GI=; b=XvB/HMKli3BI6uZVEy8EEca5Vnqxjt9oXrVHtpiJvyGNv/Ktl4PxLKd0R09vNKNjmidmMsG4Y1eXiAPfOxIbnAyJrb5WmZaPh6z1tkXZg+el//wWFnWzXGJz9u7TsXwMadUVCPxsqufHrSiQs03UEnxCD17zYdLuIL3CLSFxMKMBBVVYNLVoL3ug23NS0sJzoQfQTNVHHClj4MNcBYvQjSKjgfsgMtFjt3GmaRse8jo4sy7XeFtQb6HwAn//+fVBCWPdNNiyKEHyUAGCYUHufR3luk/eDwZkKHYtc1VE9AOPgpPC5qhbRldd2AB4gyQuX25T1h35XAIlHwSV9pkIow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cud.upct.es; dmarc=pass action=none header.from=cud.upct.es; dkim=pass header.d=cud.upct.es; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=UPCT.onmicrosoft.com; s=selector2-UPCT-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KqK4qkK/6IB4v3xGhBN69fOzqmGrZLC3YVuGSJiw4GI=; b=GOE2eh2fV17tH6zmR5KvCCcM4v6kjLwRH5EmhyA+rVxsGC/AAkwqNnDwZN/AYQLzshowMwbZ69baqWnpjJHoYhxUlesfqjLPtKhXiMYO/zRqm+uE/7pSqV1a4I+ZJGCF6YdL5Jx+yshwWHKXeHF8qXSdp/ygPZqAizaxa2z+GZU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cud.upct.es; Received: from DB8PR08MB4938.eurprd08.prod.outlook.com (2603:10a6:10:e0::24) by DB7PR08MB3899.eurprd08.prod.outlook.com (2603:10a6:10:7f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3391.14; Wed, 23 Sep 2020 11:18:52 +0000 Received: from DB8PR08MB4938.eurprd08.prod.outlook.com ([fe80::1cc7:8d25:af31:810d]) by DB8PR08MB4938.eurprd08.prod.outlook.com ([fe80::1cc7:8d25:af31:810d%7]) with mapi id 15.20.3391.027; Wed, 23 Sep 2020 11:18:52 +0000 X-Gm-Message-State: AOAM533UT7191hNLI8WuUZpXzYrhMVEobnwsC77j+vvcO0zBZhMctN/6 SJpzwh8XIwtwGYAljeWb1/otAUH7bxCd4c4UMOo= X-Google-Smtp-Source: ABdhPJz7rNtpHxkQvJ6izZ7S2XOU+HHAezFqd5c+OE8+lQS/lYqtwMJRny4qMHFL934vL/yPtfVKsKi3ThnxQlilXnc= X-Received: by 2002:a17:906:f0cb:: with SMTP id dk11mr10069371ejb.457.1600859927581; Wed, 23 Sep 2020 04:18:47 -0700 (PDT) References: <5F44E66D.6080408@btconnect.com> <24426.14679.827153.422523@fireball.acr.fi> <5F6B25DF.8010508@btconnect.com> In-Reply-To: <5F6B25DF.8010508@btconnect.com> From: =?UTF-8?B?RmVybmFuZG8gUGVyZcOxw61ndWV6IEdhcmPDrWE=?= Date: Wed, 23 Sep 2020 13:19:46 +0200 X-Gmail-Original-Message-ID: Message-ID: To: tom petch Cc: Tero Kivinen , Roman Danyliw , i2nsf@ietf.org, draft-ietf-i2nsf-sdn-ipsec-flow-protection@ietf.org, "ipsec@ietf.org WG" , LAST-CALL@ietf.org, i2nsf-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000519fe605aff93fc8" X-ClientProxiedBy: AM0PR04CA0011.eurprd04.prod.outlook.com (2603:10a6:208:122::24) To DB8PR08MB4938.eurprd08.prod.outlook.com (2603:10a6:10:e0::24) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from mail-ej1-f43.google.com (209.85.218.43) by AM0PR04CA0011.eurprd04.prod.outlook.com (2603:10a6:208:122::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3412.20 via Frontend Transport; Wed, 23 Sep 2020 11:18:51 +0000 Received: by mail-ej1-f43.google.com with SMTP id i26so27157747ejb.12; Wed, 23 Sep 2020 04:18:51 -0700 (PDT) X-Gm-Message-State: AOAM533UT7191hNLI8WuUZpXzYrhMVEobnwsC77j+vvcO0zBZhMctN/6 SJpzwh8XIwtwGYAljeWb1/otAUH7bxCd4c4UMOo= X-Google-Smtp-Source: ABdhPJz7rNtpHxkQvJ6izZ7S2XOU+HHAezFqd5c+OE8+lQS/lYqtwMJRny4qMHFL934vL/yPtfVKsKi3ThnxQlilXnc= X-Received: by 2002:a17:906:f0cb:: with SMTP id dk11mr10069371ejb.457.1600859927581; Wed, 23 Sep 2020 04:18:47 -0700 (PDT) X-Gmail-Original-Message-ID: X-Originating-IP: [209.85.218.43] X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 99142aea-a3fa-4080-08ec-08d85fb27359 X-MS-TrafficTypeDiagnostic: DB7PR08MB3899: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MC1jL24mrI0gTbaLCIJcTH/9U8Kq2uIU5K3WU83JFftKRHd6F66UhBIiyh87VjMg/sBBZoU5McrPVx6pViuyMRQvIACSHI6TpuQ52zKLU6LA6RGeLDguuJKyhy3RriTwtbGaYnDEvPTNBPdxyp/2PQliQaQ9NnodU/xzMAGmhjne0SuL6BvYJnslM2fpEYC+F1o6+W/+e53pJ1It8fjlethhAAJaWpsbEvGw6XJg8H5/jcaG6QkQz8e7BIDZLNyzBfyozFYSy+AtZVDTtQpLnOerYoZMwLXktimL6VPBNanuQ6K0WkD4QD6S25QW0QMU6olpwLoZtP0C2w6E/SxBag== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8PR08MB4938.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(366004)(39850400004)(136003)(396003)(85182001)(450100002)(33964004)(42186006)(786003)(316002)(53546011)(52116002)(83380400001)(85202003)(54906003)(478600001)(55446002)(8936002)(66476007)(86362001)(9686003)(8676002)(2906002)(6666004)(66946007)(5660300002)(26005)(186003)(6862004)(4326008)(66556008)(66574015); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData: nwZ/0ra/zbwKx7zTrBuZG6Ld1q18qrCadjCTADnSdxuGvvFV16eI+e6yqJqvLwn+gUteTXSJX8Z2c4EdTs1jpSnnnbSMa/vInVJKXiap6tq2b+CwjHPF6lS0Qk9LqKYnwlTZYPDwtlJ0hAalQeNpkOyZfZxXxvoa0WRryr+bZ06kT9I+6oZHuHJbDjKchcyB2y2z02aAh6OU3ixSObCqX5r7r81xKUDZc87agWSpa9ewwZEbNOHMIwGddKY4P/+uRNTfA/B/yxryr7edfkC3nHBYPK0uXw30TZd6/oOuuzPCDuCThM2P6kB0KG5b37Fa2ij3vqP7slYUzHuTDTkPAOcbtYMwoqKgAdKuPiBFtfZVADvZSEbHVtlsj47h54pQS0q7pRn4+n45+ekXqoP6Cjkh3oE25UaaVmkipZM1zB2LBc3I5S3ZHoWjqxx7s18idcHuzshA28pIMMe7bGXLpYQy99eRvQVQ2ouvdfREk90VWVpPqJrZ4yAtVOxjabUSzWN9RW2LXpn0KJdGavhW4LRnsc+kA8dLnW5WmaD58E//IT6zg8/Wh+XL6Y7BvzfFc/rj8TbvgbU66aQBthyjZFxLSylLzE6PblU51eL3RHNrohbt4ZINXs9ZvQoVjTRS6JboMwoXakxTEYw8lGLnfw== X-OriginatorOrg: cud.upct.es X-MS-Exchange-CrossTenant-Network-Message-Id: 99142aea-a3fa-4080-08ec-08d85fb27359 X-MS-Exchange-CrossTenant-AuthSource: DB8PR08MB4938.eurprd08.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Sep 2020 11:18:52.2004 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 967e1b81-5cf6-4b03-bb60-d71bf48069f9 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: G24NgJxqDmlvP/QfLw5QDKQTTiWCYtd5VqdsIBsdCJlSGcmaqBX4Exp5Io2pjUFnVOasRUAkP6/yY5Zuphlv3Y1WijKa0o+HFHLY1d4KDe4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3899 Archived-At: Subject: Re: [IPsec] Last Call: (Software-Defined Networking (SDN)-based IPsec Flow Protection) to Proposed Standard 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, 23 Sep 2020 11:18:59 -0000 --000000000000519fe605aff93fc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tom, Thanks for clarifying this, now we completely understand these two comments. We will update the next version of the draft accordingly. Regards, Fernando. El mi=C3=A9., 23 sept. 2020 a las 12:39, tom petch () escribi=C3=B3: > On 23/09/2020 07:16, Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa wrote: > > Hi Tero, > > > > Thank you very much for your clarification. We will update reference RF= C > > 822 accordingly in our draft. > > > > Tom, you proposed us to replace RFC 822 with 2822, but it is also > obsoleted > > by 5322. So, if you agree, we will reference RFC 5322 instead. > > That is fine by me; my comment was that RFC822 is obsoleted by RCC2822 > so you should consider a more up-to-date version not that RFC2822 was > the correct update! > > You said previously that you did not understand my comment on RFC6020 in > IANA Considerations. It is fine. What I was trying to say is that in > most places, RFC7950 is the better reference so RFC6020 should not be > used but for IANA Considerations, RFC6020 is the better reference so > when updating elsewhere in the I-D, leave IANA Considerations alone. > > Tom Petch > > > --=20 ---------------------------------------------------------------------------= ------------------------- Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa, PhD Department of Sciences and Informatics University Defense Center, (CUD), Spanish Air Force Academy, MDE-UPCT C/ Coronel Lopez Pe=C3=B1a, s/n, 30720, San Javier, Murcia - SPAIN Tel: +34 968 189 946 Fax: +34 968 189 970 ---------------------------------------------------------------------------= --------------------------- --000000000000519fe605aff93fc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

Thanks for clarifying = this, now we completely understand these two comments. We will update = the next version of the draft accordingly.

Regards= ,
Fernando.

El mi=C3=A9., 23 sept. 2020 a las 12:39, tom petch (&l= t;daedulus@btconnect.com>)= escribi=C3=B3:
= On 23/09/2020 07:16, Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa wrote:
> Hi Tero,
>
> Thank you very much for your clarification. We will update reference R= FC
> 822 accordingly in our draft.
>
> Tom, you proposed us to replace RFC 822 with 2822, but it is also obso= leted
> by 5322. So, if you agree, we will reference RFC 5322 instead.

That is fine by me; my comment was that RFC822 is obsoleted by RCC2822
so you should consider a more up-to-date version not that RFC2822 was
the correct update!

You said previously that you did not understand my comment on RFC6020 in IANA Considerations.  It is fine.  What I was trying to say is th= at in
most places, RFC7950 is the better reference so RFC6020 should not be
used but for IANA Considerations, RFC6020 is the better reference so
when updating elsewhere in the I-D, leave IANA Considerations alone.

Tom Petch



--
<= div dir=3D"ltr">---------------------------------------------------------------= -------------------------------------
Fernando Pere=C3=B1=C3=ADguez Garc=C3=ADa= , PhD
Department of Sciences and Informatics
University Defense Cente= r, (CUD), Spanish Air Force Academy, MDE-UPCT
C/ Coronel Lopez Pe=C3=B1a= , s/n, 30720, San Javier, Murcia - SPAIN
Tel: +34 968 189 946 Fax: +34 9= 68 189 970
-------------------------------------------------------------= -----------------------------------------
--000000000000519fe605aff93fc8-- From nobody Wed Sep 23 04:20:52 2020 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 EEA163A0F9F; Wed, 23 Sep 2020 04:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 KOR8a3d4cAgs; Wed, 23 Sep 2020 04:20:44 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 266F03A0F9A; Wed, 23 Sep 2020 04:20:29 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2BBED6020E; Wed, 23 Sep 2020 11:20:28 +0000 (UTC) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1FFA713F-07B4-47F8-9661-83118FBAA775"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Date: Wed, 23 Sep 2020 07:20:26 -0400 In-Reply-To: <20200923.125826.1562347052257995146.id@4668.se> Cc: Christian Hopps , Robert Wilton , i2nsf@ietf.org, Gabriel Lopez , draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org, ipsec@ietf.org, last-call@ietf.org, Rafa Marin-Lopez , yang-doctors@ietf.org To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= References: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: Subject: Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 23 Sep 2020 11:20:46 -0000 --Apple-Mail=_1FFA713F-07B4-47F8-9661-83118FBAA775 Content-Type: multipart/alternative; boundary="Apple-Mail=_63BAE7D7-EDE0-4EEE-99BF-6A711AADB3F5" --Apple-Mail=_63BAE7D7-EDE0-4EEE-99BF-6A711AADB3F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 23, 2020, at 6:58 AM, Martin Bj=C3=B6rklund = wrote: >=20 > Hi, >=20 > Christian Hopps > wrote: >>=20 >>=20 >>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez wrote: >>>=20 >>>>=20 >>>>=20 >>>> But I would like to check: My understanding is that the changes = that >>>> Chris is proposing are pretty small. I.e. move the SA structure = under >>>> ipsec-common, and put it under a YANG feature. Are you sure that = it >>>> is impractical to accommodate this change which would allow a = single >>>> ipsec module to be shared and extended via YANG augmentations? >>>=20 >>>=20 >>> In the context of our I-D, if we move SAD structure to ipsec-common, >>> what we are meaning is that IPsec SA configuration data (setting >>> values to the SAD structure) are common to the IKE case and the >>> IKE-less cases, which are not. It is confusing. >>=20 >> Something defined in a common module but marked as a feature does not >> imply that that feature has to be implemented by an importing >> module. This is not confusing to YANG implementers or users I >> think. If we are just talking about document flow here, then a >> sentence saying "the SAD feature is not required to implement IKE >> functionality" is quite enough to clear that up I think. >=20 > Another alternative could be to move these containers to another > (new) module. It may also be enough to mark the notifications in the ikeless module as = a feature I suppose. That is the actual thing I think non-SDN = implementations would want to omit. The module name "ikeless" is not = great in this case, but perhaps workable. This is a sub-optimal compromise b/c all IPsec have SA databases even = ones running IKE -- i.e., SA databases are common whether exposed in = YANG or not -- but if it can move it forward perhaps good enough. I'm definitely concerned about IETF process and real world usability = here. These modules are basically workable for ipsec I think, they could = be used by operators today. If we restart the entire process to redo = this work for the more generic IPsec case it will probably be years = before they are finished and in the field. This new work can be started, = but why not have something usable in the meantime? Thanks, Chris. >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >> Thanks, >> Chris. >>=20 >>> Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is >>> not =E2=80=9Ccommon=E2=80=9D to both cases IKE case and IKE-less. = Again, it seems >>> confusing. In the IKE case, the SDN/I2NSF controller does not >>> configure the SAD at all but the IKE implementation in the NSF. In = our >>> opinion, in order to properly add this IPsec SA operational state to >>> the IKE case we should include operational data about the IPsec SAs >>> (config false) to the ietf-ipsec-ike. Alternatively, we have certain >>> operational data (ro) in the SAD structure in the IKE-less case. If >>> only those are moved to the common part should be ok but we think it >>> does not solve the problem. >>>=20 >>=20 > -- > last-call mailing list > last-call@ietf.org > https://www.ietf.org/mailman/listinfo/last-call = --Apple-Mail=_63BAE7D7-EDE0-4EEE-99BF-6A711AADB3F5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Sep 23, 2020, at 6:58 AM, Martin Bj=C3=B6rklund <mbj+ietf@4668.se> = wrote:

Hi,

Christian = Hopps <chopps@chopps.org> wrote:


On Sep 23, 2020, at 5:29 = AM, Rafa Marin-Lopez <rafa@um.es> wrote:



But I would like to check: My understanding is that the = changes that
Chris is proposing are pretty small. =  I.e. move the SA structure under
ipsec-common, and = put it under a YANG feature.  Are you sure that it
is = impractical to accommodate this change which would allow a single
ipsec module to be shared and extended via YANG = augmentations?


In= the context of our I-D, if we move SAD structure to ipsec-common,
what we are meaning is that IPsec SA configuration data = (setting
values to the SAD structure) are common to the = IKE case and the
IKE-less cases, which are not. It is = confusing.

Something defined = in a common module but marked as a feature does not
imply = that that feature has to be implemented by an importing
module. This is not confusing to YANG implementers or users = I
think. If we are just talking about document flow here, = then a
sentence saying "the SAD feature is not required to = implement IKE
functionality" is quite enough to clear that = up I think.

Another alternative could be to move these containers to = another
(new) = module.

It = may also be enough to mark the notifications in the ikeless module as a = feature I suppose. That is the actual thing I think non-SDN = implementations would want to omit. The module name "ikeless" is not = great in this case, but perhaps workable.

This is a sub-optimal compromise b/c = all IPsec have SA databases even ones running IKE -- i.e., SA databases = are common whether exposed in YANG or not -- but if it can move it = forward perhaps good enough.

I'm definitely concerned = about IETF process and real world usability here. These modules are = basically workable for ipsec I think, they could be used by operators = today. If we restart the entire process to redo this work for the more = generic IPsec case it will probably be years before they are finished = and in the field. This new work can be started, but why not have = something usable in the meantime?

Thanks,
Chris.



/martin




Thanks,
Chris.

Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is
not =E2=80=9Ccommon=E2=80=9D = to both cases IKE case and IKE-less. Again, it seems
confusing. In the IKE case, the SDN/I2NSF controller does = not
configure the SAD at all but the IKE implementation in = the NSF. In our
opinion, in order to properly add this = IPsec SA operational state to
the IKE case we should = include operational data about the IPsec SAs
(config = false) to the ietf-ipsec-ike. Alternatively, we have certain
operational data (ro) in the SAD structure in the IKE-less = case. If
only those are moved to the common part should be = ok but we think it
does not solve the problem.


-- 
last-call = mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call

= --Apple-Mail=_63BAE7D7-EDE0-4EEE-99BF-6A711AADB3F5-- --Apple-Mail=_1FFA713F-07B4-47F8-9661-83118FBAA775 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAl9rL3oACgkQLh2DDte4 MCXEQw/9FIH/rWjXOE3LyJ03XnYFMm/oTHfxrXtYE7EQzYIyT05/ZzFD/4OiiD4i HluIw3LRYo+9fRf0M/ymQc142+6oZNnkkSpcpU4PJgGgojgutNXRfdN9iX1CdVla moNKXtbgI3ArkuMDSFHQZZtxF4/ekCv+LUs6Wdimq79AG/cx+zhbgmR8QmWg0ssV wijZKK9Mcf0IkIp/8zVijb/FopR0KTh4RmR4Gi+Ns9SdhkkjyET5LsVPz8wGRA58 UccbBnraFhiOMaP7hpA+BQUio5bjllzeKlMwn5KciqBkNGYptITLZDhph5Jy8E5V 9nrv5AEvzWolG1to0J9eycKFCtsTTcjOUso88Zmv8X6IUyCOxgL70k4+5q6x9v1R 4Hfkm26Lj/QRhxlODPhS0Sk1ImUrpsT5rxykQbbC9GchxOnGpHMz1ODtBq191n0P kM1AeAjazDxpqaf3LzzlP/ZQgzyuxE0Rphoe6tw7jGzAh2ymMiXLnuWxgUIHMGDL UVzUUf8UuWfpCy4vdfoIC2HRfwG/8RRv00+8SqRKbysXimPycNT59MUAZvSLzPC5 M3OSKu9dt9gXhprRjGHKUTiGu/O/vLbYWsQhgwug6fVrbHKe+d+LKCRyIWTcrchn StkS4KqZxIwJtd4Bj8ldqyCIyDiNgjeqsdh1++GJ0WRQYqZ9RC8= =3FPo -----END PGP SIGNATURE----- --Apple-Mail=_1FFA713F-07B4-47F8-9661-83118FBAA775-- From nobody Wed Sep 23 07:01:37 2020 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 937713A0F87 for ; Wed, 23 Sep 2020 07:01:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tIr2raKv41L3 for ; Wed, 23 Sep 2020 07:01:29 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 D030A3A0A9E for ; Wed, 23 Sep 2020 07:01:28 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id a15so17352472ljk.2 for ; Wed, 23 Sep 2020 07:01:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=mbhCN7WJz8N+efGnws/h4wFD8lCQTU+8hlxJqOXCPdY=; b=TMCFSb272HEM/S/Bx4mbIYfmkUHbIE2QMjPZgujcjUoaczI2dDlOMDDSJmZFGjcr8Z ln5iNaLyJEuBy90MDILm9tuPthMd+9VjXkOXWy+bhbAIiyw7dQ/Qi1xghpMQmyTQ6qxG JCP6Xabw/ROjYI493n0JdEYzSpuqYFKgL6dRpb6RBro4ro0596iFdp2/+IKLkNiwWYqK 28aMFQ/HLiLAjlprO0kT4LRWMA+bOcLf9oxMDqi0ibeFCsSZNqGri1Iz9hDEtrCQnWTf EDIT9HRhBHrDuRYIO01ovHlufvUw1AGmEKqtEc1e1oZczT2QR3enqgQGSIyJf1HLfkRV R4Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=mbhCN7WJz8N+efGnws/h4wFD8lCQTU+8hlxJqOXCPdY=; b=AnFi6lUzv5F2F7DjxoZDxGgdCbhtDM5Gnzs5JW1ETjQIcm/0mS+zTZ71jTNI0ccX2l auU95kAFQoVqTBmBzlBTBAGVZWoCgJojBpOK+4i2zTTfJb1ImYIU81CyMueuveycAMgj DJHkrh82DCxNNzRwzlb2v6bXaknypv4+IetFDZDK9IR4rA3hCAmQss56lUkaxgz5U0vo q+kQiFKbaWiz0VYqTyOymkyDjdz/habp+XLc42aO3gWEXjd7E5GLLyPFZcOUbS/2k/og fTriyIrHsfT63mIcwZPtl/FFn4KGWNbqVxpgI9NbZaohTEadymhfb1BTnOnE1Mwqg8Q/ +MwQ== X-Gm-Message-State: AOAM531lE0GFuXmT8uXEvWc3W9MDA8H2JtSD2UP747SlWFRcUkJXkwoN q6l4FNd8WoRqJNulVmVKc8hmGjigK2Q= X-Google-Smtp-Source: ABdhPJwAy6Z8skIyxDx7WAJujtPEzhZ6JElXa7xKGFTAK8cUtBtfnsIO8c1XWZjANvdLjkpcZfD4Fg== X-Received: by 2002:a05:651c:124b:: with SMTP id h11mr23042ljh.172.1600869686566; Wed, 23 Sep 2020 07:01:26 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id y10sm5555lfj.271.2020.09.23.07.01.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Sep 2020 07:01:25 -0700 (PDT) From: "Valery Smyslov" To: "'Panwei \(William\)'" , "'IPsecME WG'" References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> In-Reply-To: Date: Wed, 23 Sep 2020 17:01:28 +0300 Message-ID: <0d3801d691b2$08899990$199cccb0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDerNHJ6yQWbz9owZeTkO8kxeEfAE/6KzdqRD9NeA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 23 Sep 2020 14:01:34 -0000 Hi William, > Hi Valery, > > It seems like a rare scene but I think it needs to be considered. > Compared with ignoring cookie payload, how about adding N(COOKIE2) in the 9th message? Then when > Initiator received the 12th message, it'll know which cookie this message matches with. The problem with this approach is that the responder doesn't know whether initiator is a legacy implementation or an updated one. The legacy implementation may treat any IKE_SA_INIT response containing COOKIE as a request to re-send a request with this COOKIE, even it contains other payloads. So, if the responder includes N(COOKIE) in every IKE_SA_INIT response it will cause infinite loop of resending request if initiator is legacy implementation. Regards, Valery. > Regards & Thanks! > Wei Pan > > > -----Original Message----- > > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Valery Smyslov > > Sent: Tuesday, September 22, 2020 10:47 PM > > To: IPsecME WG > > Subject: [IPsec] Cookie logic results in failed authentication > > > > Hi, > > > > while performing stress tests, we ran into the problem, that is concerned > > with the way cookies are handled in RFC7296. > > The problem is that if network conditions are bad (high probability for > > packets to be delayed, reordered or lost), then some SAs are not established > > with AUTHENTICATION_FAILED error. Consider the following scenario: > > > > Initiator Responder > > 1. HDR, SAi, KEi, Ni --> > > 2. --> HDR, SAi, KEi, Ni > > (server has a large number of > > half-open SAs, so it responds with cookie, > > that is generated using cookie > > secret K1) > > 2. (message is delayed in the network) ... <-- HDR, N(COOKIE1) > > 3. (client retransmits its original message) > > HDR, SAi, KEi, Ni --> > > 4. --> HDR, SAi, KEi, Ni > > (server has a large number > > half-open SAs, so it responds with cookie, > > but the cookie generation secret > > has been already changed, and becomes K2, > > that results in generating a new > > cookie for the same request, COOKIE2) > > 5. <-- HDR, N(COOKIE2) > > 6. HDR, N(COOKIE2) <-- > > 7. (client receives message and retransmits its request with COOKIE2) > > HDR, N(COOKIE2), SAi, KEi, Ni --> > > 8. --> HDR, N(COOKIE2), SAi, KEi, Ni > > (server verifies COOKIE2, it's OK, > > since K2 is still the current secret) > > 9. (message is delayed in the network) ... <-- HDR, SAr, KEr, Nr > > 10. HDR, N(COOKIE1) <-- > > 11. (eventually the delayed first message from the server with COOKIE1 > > reaches the client. Since the client doesn't know that COOKIE1 is stall, it > > decides that it's fresher than COOKIE2, because it receives this message later, > > so the client replaces cookie and resends its initial request with COOKIE1) > > HDR, N(COOKIE1), SAi, KEi, Ni --> (this message get lost) > > 12. HDR, SAr, KEr, Nr <-- > > (eventually delayed server's response reaches the client. At this point the > > client thinks that IKE_SA_INIT is completed and starts > > IKE_AUTH) > > > > What is interesting in the above diagram: both the client and the server have > > eventually completed IKE_SA_INIT, but they have different opinions on what > > IKE_SA_INIT message from initiator to responder contains. > > The client thinks that the server has responded to its most recently sent > > message HDR, N(COOKIE1), SAi, KEi, Ni, while the server has never received > > it and in fact has responded to HDR, N(COOKIE2), SAi, KEi, Ni. > > As a result - while calculating AUTH payload they will have different inputs to > > it and authentication will fail. > > > > Despite this diagram looking artificial, we did observe a noticeable number > > of these errors during real stress tests (up to 5% of SAs failed with this error > > in bad network conditions). > > > > What's particularly unfortunate with this: > > 1. The bad network conditions may happen as a result of DDoS attack, which > > also may cause cookie logic to be triggered on the server. > > So, the two pre-conditions - bad network and server under attack are > > coupled. > > 2. The most disappointing thing for me is that despite bad network > > conditions, peers did manage to complete initial IKE exchanges, > > only to get "authentication failed" result. > > 3. For customers this looks surprising - they have valid credentials, but from > > time to time they receive "authentication failed" > > diagnostics without any clue why this happens. > > > > The root of the problem is that IKE_SA_INIT request may be retransmitted > > with different content (different cookies) and the peers have no means to be > > sure that they have send/receive identical messages. And later these possibly > > different messages are used in AUTH payload calculation. > > > > I believe that the proper solution would be to exclude cookie from the AUTH > > payload calculation. > > It is verified by the responder using cookie generation secret and it is not > > concerned with a client (the client did not generate it, just echoes it back). > > However, this solution is obviously incompatible with RFC7296, so this is not > > an option. > > > > Any opinions? Should this problem be addressed by the WG or ignored? > > > > Regards, > > Valery. > > > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Sep 23 07:13:45 2020 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 881593A0FC2 for ; Wed, 23 Sep 2020 07:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84mTYiF-1CUI for ; Wed, 23 Sep 2020 07:13:42 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 C57393A0995 for ; Wed, 23 Sep 2020 07:13:41 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id a12so19943437eds.13 for ; Wed, 23 Sep 2020 07:13:41 -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=Bg7yjtSjRm6Igd1lOrgw8b5lBEu+1tS3SwSp99UDmYM=; b=Ug4ueQV4cWRynDis9K4cYXjci/4jxWlvcDncjM2VDBG5ltlS/Fdt89KdyNfny2TVXb vbhzz5/T8+6vBWEkL2h0L8JCgHLyWYNWq5cVAG7mvR8QhqqoQwsBgDevK2OvZTWnDrcr ZOdyjWHNiwdfep4+CvVMAPoacL4w1jv+6E7RXa0GgV5tjTsziAf1m4je6QVlhLiPDw+i NJyuSVuw16i4brsQUY6yH+oQB2m6QlWvBJ/H2DDRlxVGzXQvD+/gvsRrXe7tMAvS95+L JER+EYKg/5g01nsjlSFKdQsJ8VXeLmjE7tyNPIeOncB1ueiK7uSQaTTT7/OZ6TLAvE8X qBwQ== 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=Bg7yjtSjRm6Igd1lOrgw8b5lBEu+1tS3SwSp99UDmYM=; b=VIN4dZTFdbbA1zzDQcq71Cs4d6Fqum85fBCH+sjqfdCH4cgSvndZ+zir5SXfpJoqoa qiUMhkK9CeS7CxQvNqI/sYhRed4i3dtmn0J0KsOh/u/HSyZCI3nGGvSyovA7ftnRRZHi Hta07iZtYSNdWBHE61A5yQOCaGrlqdTErsAB3+JnRi2M2HDpmpck1DwjUsqHGCDwgDjK zwJIjp9UepjXmcelxEB+SQtE/SPuIiCAd32Q6i66LkGozB0EotFxjahoZx9BqXfRZE1P aEFKS1G2NzzY3hfZ+iDhJRXdgCFgLGvm6i8kjKXhNRdaAyu1Lt5r5XDczsEZNEsIZ817 o/DQ== X-Gm-Message-State: AOAM533q79Q9UdKCy6m8EJXLd9NlBQ1ZxAFo25TXXQ3KhTiPlZd4JraF QIy9M6CSaXhEJgzUKi44iXnuUua+wNY= X-Google-Smtp-Source: ABdhPJxmnCRo+l0LXRLstWN7WFA9jKYV6FtXMhkluLiJ838UoS1HfSJ9cbw/axCI3G+yn1HZJOL80Q== X-Received: by 2002:a05:6402:1451:: with SMTP id d17mr9744394edx.48.1600870416762; Wed, 23 Sep 2020 07:13:36 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id r16sm67379ejb.110.2020.09.23.07.13.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Sep 2020 07:13:35 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Panwei \(William\)'" Cc: "'IPsecME WG'" References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> <24426.17186.275023.44982@fireball.acr.fi> In-Reply-To: <24426.17186.275023.44982@fireball.acr.fi> Date: Wed, 23 Sep 2020 17:13:38 +0300 Message-ID: <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDerNHJ6yQWbz9owZeTkO8kxeEfAE/6KzdAuLoloqo+0PJAA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 23 Sep 2020 14:13:44 -0000 Hi Tero, > Simple solution. Do not change cookie generation secret too often if > you are under attack with really crappy network... Unfortunately, RFC7296 advises just the opposite: The responder should change the value of frequently, especially if under attack. > I mean if the > attackers are sending blind connection attemps where cookies help, > changing the cookie does not make any difference. If the attackers are > using real DDoS where each attack packet is actually a host which will > reply to your cookie request then again changing cookie secret does > not help. Only case where changing cookie secret helps is that > attacker cannot collect thousands of valid cookie responsenses and > then suddenly send them all out. > > Or you could try to make sure that the cookie secret selection is > stabile for the same peer always for longer time, i.e. remember some > state that you used cookie secret x for following sessions before > changing to new one. After the cookie secret is changed and enough > time has gone by, you can forget that list and old secret, and you > only need to start collecting that list at the point when you are > planning to change cookie generation secret again soon. > > If you have 10000 incoming connections per second and you consider 300 > seconds for suitable timeout for sessions to finish, and you only > store source ipv4-address for each time you used cookies, you need 11 > MB of memory for that state (and that assumes none of the incoming > sessions are actually coming from same ip-address). I don't like stepping back from stateless to stateful solution (although with a limited state)... And it doesn't solve the problem completely, it will only occur less frequently. > > Any opinions? Should this problem be addressed by the WG or ignored? > > I think the long term solution is to do puzzles, as I do not think you > need to change puzzles secrets that often compared to the cookie > secrets. Puzzle are not solution for this problem. RFC 8019 suggests that is included in the cookie that allows the responder to determine the requested puzzle difficulties and the like. Even if cookie secret is not changed, this information may change quite frequently and we will run into the same problem. > > It seems like a rare scene but I think it needs to be considered. > > Compared with ignoring cookie payload, how about adding N(COOKIE2) > > in the 9th message? Then when Initiator received the 12th message, > > it'll know which cookie this message matches with. > > Actually I think the best option is to include the N(COOKIE) in the > Initiators IKE_AUTH too. I.e.: ... > Now when Responder receives IKE_AUTH at step 9, it will decrypt that > and it can see that Initiator thinks the cookie is COOKIE1, and it can > then reconstruct the packets initiator is using for his calculations. > Of course it needs to assume that initiator did not change order of > payloads or anything else when it swiched from COOKIE2 to COOKIE1, > i.e., that only difference in step 5 and step 7 packets is the cookie > payload contents. > > This kind of change would most likely be backward compatible, i.e., > old responders would simply ignore the extra notify payload in > IKE_AUTH and old initiators would not simply even send it. This change will require both client and server to be updated to take an effect. IMHO in this case a better option would be as follows: negotiate an extension that will change AUTH payload input by zeroing out content of cookie. Initiator Responder HDR, SAi, KEi, Ni --> <-- HDR, N(COOKIE), N(COOKIE_NA) HDR, N(COOKIE_NA), SAi, KEi, Ni --> <-- HDR, SAr, KEr, Nr We define a new status notify COOKIE_NA (No Auth). The responder includes both COOKIE and COOKIE_NA in its response, COOKIE is formed as usual, COOKIE_NA is empty. If the initiator supports this extension, it includes COOKIE_NA (instead of COOKIE) in the retried IKE_SA_INIT request, copying a content of COOKIE there. If the responder receives retried request with COOKIE_NA and successfully verifies it, later when initiator's AUTH is being verified it just zeroes out the content of COOKIE_NA notification in the initiator's message passed to prf. The same does the initiator when calculating AUTH payload. Comparing with your proposal: - it consumes less bits on the wire - it consumes less resources on the responder (no need to verify cookie received in IKE_AUTH) - it eliminates cases when the responder cannot verify cookie sent in IKE_AUTH (unclear what to do in this case) The sad thing is that both initiator and responder need to be modified... Regards, Valery. > kivinen@iki.fi From nobody Wed Sep 23 14:57:47 2020 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 A02423A1527 for ; Wed, 23 Sep 2020 14:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 5JKZ9B7ck7ZC for ; Wed, 23 Sep 2020 14:57:43 -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 AC1573A1525 for ; Wed, 23 Sep 2020 14:57:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BxX905gk1zCQ6; Wed, 23 Sep 2020 23:57:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1600898260; bh=Bsa6UhbZJQvIL40BB3xBQ3Bh0lr96XTaJweWX0rdQRw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tpFQsjdaLQBeD3Pi0u0TMgYwrRtREZVfo9BcIgH58IBG4b+pQpXIuBgQx2oBrLopr UCxbVSqi0Bj9rMWuFxSohmJPYCimkAEbsng2Hw6HKrDus9Q585lNfn3+DJbKW3gMOH vOxIc8JUci1lO7ogtRjCP/1XZc1vFYurwhrcbKd8= 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 2NLhn2jsoSAs; Wed, 23 Sep 2020 23:57:39 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 23 Sep 2020 23:57:39 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 556EF6029BA2; Wed, 23 Sep 2020 17:57:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4CFCE66AF7; Wed, 23 Sep 2020 17:57:38 -0400 (EDT) Date: Wed, 23 Sep 2020 17:57:38 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: 'Tero Kivinen' , "'Panwei (William)'" , 'IPsecME WG' In-Reply-To: <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> Message-ID: References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> <24426.17186.275023.44982@fireball.acr.fi> <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 23 Sep 2020 21:57:46 -0000 On Wed, 23 Sep 2020, Valery Smyslov wrote: > This change will require both client and server to be updated to take an effect. > IMHO in this case a better option would be as follows: negotiate an extension > that will change AUTH payload input by zeroing out content of cookie. What would this actually achieve? We have a server that is under a serious DDoS attack. It is sending back COOKIES and soon might have too many half open SA's to even accept any new connections with COOKIES. Those problems are much more severe than the legitimate client needing to once retry the overloaded server because the server changed a cookie secret that should be a rare event to begin with - in our implementation 1 hour. So the client, which can do 1 exchange attempt per 10 seconds? Would have a 0.277 % change of hitting that slot and having another 10s delay for the next keying attempt to succeed. Is the chance of the DDoS attack plus the chance of the secret reloading worth a new IKE extension at all? Paul From nobody Wed Sep 23 17:16:51 2020 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 EB3883A0141 for ; Wed, 23 Sep 2020 17:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 L7BgRIzs8xcC for ; Wed, 23 Sep 2020 17:16:47 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 F3BA53A00E5 for ; Wed, 23 Sep 2020 17:16:46 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 0A2901B00333; Thu, 24 Sep 2020 03:16:43 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1600906603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KEcgzYZu4RnELRORCP8bWxq927QhVlyQ4dfKsH75Ntg=; b=Zfqend6zENsgIaD9F3gqsCG3fViugsPG1E+kilm0QkGyQBgRKFGsGZ+WK58BA28AsrPYUW KB0/lE/j59X9QxjUTlASMG2nmrYSfKBAGcoPq4t025ryJi1gYlS1CM/9cN05VSxSlh05Kb o0JAAE8Jk/8sHcCk7+KSUGS8cnU7X8tESo2B2cy4O85Hm8DrDuU+Ot2o7fsYGp2CDn0CUD MXGuSqcYGrpRUz1mgsAzwNGP3Lr2CvzwJvj7zjlhF+5g63e74W64Hz7KWqCYLtmc9ZAwn+ ouGE1SvAZ/WMQsLveTunodLaNY4gXd1LTvyLG0/y7p7XVBySyLh1wU9edoNGoQ== Received: by fireball.acr.fi (Postfix, from userid 15204) id 946DE25C0FE1; Thu, 24 Sep 2020 03:16:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24427.58722.139650.897613@fireball.acr.fi> Date: Thu, 24 Sep 2020 03:16:34 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Panwei \(William\)'" , "'IPsecME WG'" In-Reply-To: <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> <24426.17186.275023.44982@fireball.acr.fi> <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 17 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1600906603; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KEcgzYZu4RnELRORCP8bWxq927QhVlyQ4dfKsH75Ntg=; b=ifi/ua/sjdjRg+WE6RN6+c9EOuNZ3H1irjYHVGMDllvmNsWXWHIbaYUYE/+vgt4SbTR6LD bfJYk/m4D3yTIkRReUboyghsPsNhwv+YM73JIyfttMVlZdcpIw12omEF+u2++AOC5JmP8a nvY0rGX2LibymC5EUfcEbtub2OBzYtFLPGPO7Z0Tq43M2fFkvoHy6Y3Ravsvn3BfJhQc6g bbrEgu6XcVq2pA1uLgGfkudzAjq+I1ebjkr8fcwYzENRCeM2m1JxD+lBJ7XPWAvh2hsy21 FrXyjyVQCREAD6mXi/pVwtExsabDgJEMDykfj6DwOXEuKJzBZcILtoRE13BiDQ== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1600906603; a=rsa-sha256; cv=none; b=Tp2DBna4BmIRPMjJNCWY4YeQDPlXgOo3e1BDJoAKeto7o2Z3tY/5DgQS0QoV98HcwnxROf SyUAGDjBIJEIlK9j81GFVD+GnCm3GqQTJrZp2T7F4KXPrCrqErYyY5PtCzGdSRHws/dajK n4ryEgnfo0ttGyPzgGMgt1cdtKU9/I1ialh1lg610zPZOvaQ8mu/ARx+2lOXPI8ZPpcWrb 8EiPKSTgqUbanolM3P7y5G6Lq8OA6rv49QIkYdoNm8MjthNJNyKNfB7msxyU2QUQO3w3Yq fk92QNtgvGuXODKfoxNXGv3mBjZ7uWbqejlG+eeNxCvkz59a5K42guvXRev8yQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 24 Sep 2020 00:16:50 -0000 Valery Smyslov writes: > Hi Tero, > > > Simple solution. Do not change cookie generation secret too often if > > you are under attack with really crappy network... > > Unfortunately, RFC7296 advises just the opposite: > > The responder should change the value of frequently, especially > if under attack. Frequently, as in every hour or so. Not as every few minutes. There is nothing gained changing the cookie secret too often, as changing it only protectes against attackers who can do return routability checks. It only protectes against attackers who are using single or very few devices to do the attack, and want to collect lots of valid cookies, and then mount an attack. > > I think the long term solution is to do puzzles, as I do not think you > > need to change puzzles secrets that often compared to the cookie > > secrets. > > Puzzle are not solution for this problem. RFC 8019 suggests that > is included in the cookie that allows the responder > to determine the requested puzzle difficulties and the like. > Even if cookie secret is not changed, this information may change > quite frequently and we will run into the same problem. If I remember right puzzles requires the attacker to solve the puzzles before it can do the attack, thus making changing the cookie or puzzle secrets something that can be done much more infrequently. I mean if it takes a second for the attacker to solve the puzzle, that means that you can easly slow the done the attack rate from single source so much that you do not need to change cookie secret too often. And if attacker has so much cpu power and with properly connected routable addresses, that you can't cope even with puzzles on, then you are out of action anyways, regardless whether you change cookie secret or not. > > > > It seems like a rare scene but I think it needs to be considered. > > > Compared with ignoring cookie payload, how about adding N(COOKIE2) > > > in the 9th message? Then when Initiator received the 12th message, > > > it'll know which cookie this message matches with. > > > > Actually I think the best option is to include the N(COOKIE) in the > > Initiators IKE_AUTH too. I.e.: > ... > > Now when Responder receives IKE_AUTH at step 9, it will decrypt that > > and it can see that Initiator thinks the cookie is COOKIE1, and it can > > then reconstruct the packets initiator is using for his calculations. > > Of course it needs to assume that initiator did not change order of > > payloads or anything else when it swiched from COOKIE2 to COOKIE1, > > i.e., that only difference in step 5 and step 7 packets is the cookie > > payload contents. > > > > This kind of change would most likely be backward compatible, i.e., > > old responders would simply ignore the extra notify payload in > > IKE_AUTH and old initiators would not simply even send it. > > This change will require both client and server to be updated to > take an effect. But it is backward compatible with both old and new client and server. Meaning you can easily just turn it on in your initiator (where this will be trivial change). Then when responder is supporting this you will get protection. I agree that implementing this on responder do require more work. > IMHO in this case a better option would be as follows: negotiate an > extension that will change AUTH payload input by zeroing out content > of cookie. Implementing that do require about same amount of work than my proposal on the responder, but now you again have one more option that you need to include in IKE_SA_INIT making it even bigger. > > Initiator Responder > HDR, SAi, KEi, Ni --> > <-- HDR, N(COOKIE), N(COOKIE_NA) > HDR, N(COOKIE_NA), SAi, KEi, Ni --> > <-- HDR, SAr, KEr, Nr > > We define a new status notify COOKIE_NA (No Auth). The responder > includes both COOKIE and COOKIE_NA in its response, COOKIE is formed > as usual, COOKIE_NA is empty. If the initiator supports this > extension, it includes COOKIE_NA (instead of COOKIE) in the retried > IKE_SA_INIT request, copying a content of COOKIE there. If the > responder receives retried request with COOKIE_NA and successfully > verifies it, later when initiator's AUTH is being verified it just > zeroes out the content of COOKIE_NA notification in the initiator's > message passed to prf. The same does the initiator when calculating > AUTH payload. I think that would work too. I wonder if there is any new attacks which can be done, because now the cookie is no longer authenticated at all? I have to think about whether there is something that can be done when initiator and responder do no longer include cookie in their auth calculations. In my proposal both would still include the cookie in calculations so security properties is not changed, responder just gets informed which cookie was used by initiator. > Comparing with your proposal: > - it consumes less bits on the wire It uses more bits on the wire in the IKE_SA_INIT where it counts. My proposal does not use any extra bytes there. On the other hand your proposal uses them in responders cookie reply, where it most likely do not matter. > - it consumes less resources on the responder (no need to verify > cookie received in IKE_AUTH) Stateless cookie verifications are supposed to be very fast, so I do not think that is big issue. > - it eliminates cases when the responder cannot verify cookie sent > in IKE_AUTH (unclear what to do in this case) If responder cannot verify the cookie, it will drop the conenction with error, because this cookie was so old that it is no longer valid... > The sad thing is that both initiator and responder need to be > modified... I think that is unavoidable unless you want to do heristics like I described in other email and keep some state. Anyways both of these would work, the question is, whether this problem is big enough that we want to modify the IKEv2 protocol to fix this. Or whether if we just change cookie secret not to change too often that will make problem so rare that we do not care. -- kivinen@iki.fi From nobody Thu Sep 24 06:14:46 2020 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 C86293A0A4F for ; Thu, 24 Sep 2020 06:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJ3vidB4vEh6 for ; Thu, 24 Sep 2020 06:14:43 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E57703A0A3C for ; Thu, 24 Sep 2020 06:14:42 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id m5so3857489lfp.7 for ; Thu, 24 Sep 2020 06:14:42 -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=OcbrSD0D3OLD6x/jHAaOcMV7xRTWZBlJ4mL/VVMq7VM=; b=uPr45ir/oqGd6TXsL57BhI5toMdy9dFKId2EvK5IVs6Aht8N4104tiRejDezUJxISR mwRLjrQMoPjGQE0Naw4MK+TpRBtAmfvCqsxulDqEGYjWoksD/6h3+usmJSohuZJ9+HQO gHhXNvLvc/7K13vuXys7FzoI+VBOdD8G/RFoySyECA3khW0n1J5fsDVhKf99JyL9HsKF 6waO++DgIMN72ezIPMb6AtwegocOGP0FJ+g6jKj2gJHWCvnxd+IS5iXXGGpgoGlNbaNp jD41tnFIxG0iD/MYZYrRL0O4sXjdpHJOnS+UP3ePV/71QPipoYAzJ4E8g2TORO00GsWl YQ/w== 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=OcbrSD0D3OLD6x/jHAaOcMV7xRTWZBlJ4mL/VVMq7VM=; b=KivQXXysxBbSNFJL/vogGD/KDagQ9oj9lWMCti3DKhOhh+o9Bm4nkaidJ1dR56zx+n HLfU5F9GRn3Zo0wUgxDeeo/22urb9OcKCmnd43gI1DzHb4QN9ORA4d+SYCIqt+WhV/zY Ds6o4XQkFMHSMK5CGhOoB3J1tu3hPcySEKJmBDpzI0Pc0xa8s2Nl2nIFM+PwUfDduz59 xsORoGopMsaJzC1NOPyf+0wRw9RUzTxnH/ep4MaLlNa7zC5CGCV3YxgbQNjOgcAfd8+y Km3n+0iNceDSAbXmT6Fo2RYhaBcIl8CIJc4k2tiiY4juulgJikt9DYnm5ZB7XlSIyWbf aDSg== X-Gm-Message-State: AOAM531Uqy3gtSy/wkdL8bo5IkscTUvy61ajEU4rLaJalyuciC0D9ONp cM5AxJ+cO2u9t7kmJT2AyTU0YA38/dA= X-Google-Smtp-Source: ABdhPJzxmE3l4rtyS5hew5C3qqI1mIcdeyePZHYFKXgc54N4oXhvz2RG418vFVOUXZvjSOGK9l2Y7w== X-Received: by 2002:a19:404e:: with SMTP id n75mr284507lfa.172.1600953280711; Thu, 24 Sep 2020 06:14:40 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id o15sm2047348lfg.226.2020.09.24.06.14.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2020 06:14:39 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" Cc: "'Tero Kivinen'" , "'Panwei \(William\)'" , "'IPsecME WG'" References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> <24426.17186.275023.44982@fireball.acr.fi> <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> In-Reply-To: Date: Thu, 24 Sep 2020 16:14:43 +0300 Message-ID: <0e2901d69274$ab071cc0$01155640$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDerNHJ6yQWbz9owZeTkO8kxeEfAE/6KzdAuLolooBtd1BXALhJxMwqNgizjA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 24 Sep 2020 13:14:45 -0000 Hi Paul, > > This change will require both client and server to be updated to take an effect. > > IMHO in this case a better option would be as follows: negotiate an extension > > that will change AUTH payload input by zeroing out content of cookie. > > What would this actually achieve? > > We have a server that is under a serious DDoS attack. It is sending back > COOKIES and soon might have too many half open SA's to even accept any > new connections with COOKIES. I fail to understand why server might have too many half open SA's with the proposed extension. Note, that it remains stateless until the client returns COOKIE, exactly as it happens now. > Those problems are much more severe than > the legitimate client needing to once retry the overloaded server > because the server changed a cookie secret that should be a rare event > to begin with - in our implementation 1 hour. So the client, which can > do 1 exchange attempt per 10 seconds? Would have a 0.277 % change of > hitting that slot and having another 10s delay for the next keying > attempt to succeed. Is the chance of the DDoS attack plus the chance > of the secret reloading worth a new IKE extension at all? The problem is not the delay. The problem is that sometime it caused failed authentication, that definitely must not happen as a result of bad network. If client receives fails due to exchange timeout, it's clear for him/her that this is transient error and an attempt should be retried. If it receives response AUTHENTICATION_FAILED it might suspect that something is wrong with his/her credentials and probably won't retry until figuring this out. Even if this happens rarely, it means that the protocol is flawed. Regards, Valery. > Paul From nobody Thu Sep 24 06:44:32 2020 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 B2EEF3A0CAB for ; Thu, 24 Sep 2020 06:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TZDrAdsoyQOo for ; Thu, 24 Sep 2020 06:44:29 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (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 A41A03A0CA6 for ; Thu, 24 Sep 2020 06:44:28 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id a15so2818076ljk.2 for ; Thu, 24 Sep 2020 06:44:28 -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=R16h/0KTIsiCqsJnFovguzujck1BJjriDlGc7dmrQwc=; b=YKOqcnniqlUjCHbA2SEc3HzGCDBiXY0rkjCkxcAkSAo9ddEnyOefKWpMd6RhIGlTIP RyxgKZoZoFCqLHPtpP/fnkGeFF2FEKiJtyAl7quaVWT2cwrnozN+NKNt40DxOthcSZ4W 9GXWb2Gq39SLJjAyB82ieSfYhs7WtR5o/ZyquOMuXDod9GeltgjP4cqwH7kUssXSrb/2 Bv5jlz8irxol8MHCN2v9Qz9PqWzcVl0dYCOM1njL4yNhsp2FdcBmbkaQgStZ8vohA7lH laLzELr26LHTtPMjnzxS1fezXEnXtRR4FPe+D8lQlxZrHOtwvyXNsY8NumMxlCSSLSq3 LU8Q== 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=R16h/0KTIsiCqsJnFovguzujck1BJjriDlGc7dmrQwc=; b=rRDakSA1Qtp8guc1BxfI91mzt/WkRTIKEILX4aoj88EZKJ8/2rLUMvq780Dd8SdIgQ KhkO1cDdSnlo3MHM6haAQPBfpXDaYflshdOCp6xDlgzQ2/yrLcnU6qD0sJonpP4MJ+Dt 0BAOrRj9tpOpyv1t8NVUljg4dewjgUWm0/TP2/mKYdyyNqlkV0mF4/C7/C+pgJ4yWCqj mwdvhwsST/oa+Mc6k7oD7mVqxeOLQA0LyNXa5FGqJMTtfrIbi87puCSjuAXahEiceMm3 02RztzWhFKYqbTV2qizTixTjBpcGnm2yW+D3839xOXKTdvCFlihGLUczT/PDYFkIp87t YfSg== X-Gm-Message-State: AOAM530LC0ZU4bHAKqruGx4CpRKDLedAr+hKIIKXJB2zCH9m0G/XwG7p lDbZEZtEsyp6Zc9gdCUFmRcpj7tVLw8= X-Google-Smtp-Source: ABdhPJwh6dAqybTQg+CB7lc7vyQcZOfE+c0sqOpd409DNU+n40nfjex/13DNOS3uUcv8RMTd2UdkZA== X-Received: by 2002:a2e:9bc2:: with SMTP id w2mr338911ljj.236.1600955066187; Thu, 24 Sep 2020 06:44:26 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id z7sm2096693lfc.59.2020.09.24.06.44.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Sep 2020 06:44:25 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'Panwei \(William\)'" , "'IPsecME WG'" References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> <24426.17186.275023.44982@fireball.acr.fi> <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> <24427.58722.139650.897613@fireball.acr.fi> In-Reply-To: <24427.58722.139650.897613@fireball.acr.fi> Date: Thu, 24 Sep 2020 16:44:28 +0300 Message-ID: <0e2a01d69278$d33f7350$79be59f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDerNHJ6yQWbz9owZeTkO8kxeEfAE/6KzdAuLolooBtd1BXAH19/peqN9+yHA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 24 Sep 2020 13:44:31 -0000 Hi Tero, > > > I think the long term solution is to do puzzles, as I do not think you > > > need to change puzzles secrets that often compared to the cookie > > > secrets. > > > > Puzzle are not solution for this problem. RFC 8019 suggests that > > is included in the cookie that allows the responder > > to determine the requested puzzle difficulties and the like. > > Even if cookie secret is not changed, this information may change > > quite frequently and we will run into the same problem. > > If I remember right puzzles requires the attacker to solve the puzzles > before it can do the attack, thus making changing the cookie or puzzle > secrets something that can be done much more infrequently. I mean if > it takes a second for the attacker to solve the puzzle, that means > that you can easly slow the done the attack rate from single source so > much that you do not need to change cookie secret too often. If the same cookie is returned every time to a given initiator, then this initiator can solve puzzle once (since cookie is an input data for a puzzle) and then present the solution many times (selecting the same SPIi and Ni), thus bypassing DDoS protection. For this reason RFC8019 advises to make every cookie different or at least to change the secret frequently. > And if attacker has so much cpu power and with properly connected > routable addresses, that you can't cope even with puzzles on, then you > are out of action anyways, regardless whether you change cookie secret > or not. Not exactly. If you return different cookies to the same initiator each time it starts creating IKE SA, then this initiator will have to solve new puzzle every time. Otherwise it can do it once and then present the solution many times. > > > This kind of change would most likely be backward compatible, i.e., > > > old responders would simply ignore the extra notify payload in > > > IKE_AUTH and old initiators would not simply even send it. > > > > This change will require both client and server to be updated to > > take an effect. > > But it is backward compatible with both old and new client and server. > Meaning you can easily just turn it on in your initiator (where this > will be trivial change). Then when responder is supporting this you > will get protection. I agree that implementing this on responder do > require more work. I didn't say it is not backward compatible :-) > > IMHO in this case a better option would be as follows: negotiate an > > extension that will change AUTH payload input by zeroing out content > > of cookie. > > Implementing that do require about same amount of work than my > proposal on the responder, but now you again have one more option that > you need to include in IKE_SA_INIT making it even bigger. The responder only includes an empty Notify in a COOKIE request message, which usually contains only N(COOKIE), so it's less than 100 bytes in length. With my proposal it'll 8 bytes longer. Not a big loss. > > Initiator Responder > > HDR, SAi, KEi, Ni --> > > <-- HDR, N(COOKIE), N(COOKIE_NA) > > HDR, N(COOKIE_NA), SAi, KEi, Ni --> > > <-- HDR, SAr, KEr, Nr > > > > We define a new status notify COOKIE_NA (No Auth). The responder > > includes both COOKIE and COOKIE_NA in its response, COOKIE is formed > > as usual, COOKIE_NA is empty. If the initiator supports this > > extension, it includes COOKIE_NA (instead of COOKIE) in the retried > > IKE_SA_INIT request, copying a content of COOKIE there. If the > > responder receives retried request with COOKIE_NA and successfully > > verifies it, later when initiator's AUTH is being verified it just > > zeroes out the content of COOKIE_NA notification in the initiator's > > message passed to prf. The same does the initiator when calculating > > AUTH payload. I must correct myself. Zeroing out cookie is not enough - it must be completely removed from the initiator's message while performing AUTH computation, as if no cookie was exchanged (and correct Next Payload and Length in IKE Header). The reason is that another sequence possible when the server first feels it's under attack and returns cookie, but then when the client retransmits the server can no more feel it is being attacked and returns IKE_SA_INIT as usual. In this case if packets are reordered and delayed we may run into the situation when the client will think cookie was requested, but the server will think that it requested no cookie. > I think that would work too. I wonder if there is any new attacks > which can be done, because now the cookie is no longer authenticated > at all? I have to think about whether there is something that can be > done when initiator and responder do no longer include cookie in their > auth calculations. In my proposal both would still include the cookie > in calculations so security properties is not changed, responder just > gets informed which cookie was used by initiator. I hope it leads to no new attacks. Cookie is verified by other means and if we just have an input to the AUTH as if no cookie was exchanged (that is a legitimate case). > > Comparing with your proposal: > > - it consumes less bits on the wire > > It uses more bits on the wire in the IKE_SA_INIT where it counts. My 8 bytes on the very short message requesting cookie. > proposal does not use any extra bytes there. On the other hand your > proposal uses them in responders cookie reply, where it most likely do > not matter. Usually the size of cookie is about 32-64 bytes, so it'll add 40-72 bytes to repeat cookie. However, I agree that it's IKE_AUTH when this is not a big issue. > > - it consumes less resources on the responder (no need to verify > > cookie received in IKE_AUTH) > > Stateless cookie verifications are supposed to be very fast, so I do > not think that is big issue. I agree, but you still have to do some work. Comparing to zero work. > > - it eliminates cases when the responder cannot verify cookie sent > > in IKE_AUTH (unclear what to do in this case) > > If responder cannot verify the cookie, it will drop the conenction > with error, because this cookie was so old that it is no longer > valid... Why? Note, that the purpose of cookie is to verify that the client is a live host. If the client managed to get to IKE_AUTH, then it's definitely live. On the other hand, I agree that it's strange to receive unverifiable cookie. That's why I said that it's unclear what to do in this case and I'd rather to eliminate such situations from the protocol. > > The sad thing is that both initiator and responder need to be > > modified... > > I think that is unavoidable unless you want to do heristics like I > described in other email and keep some state. > > Anyways both of these would work, the question is, whether this > problem is big enough that we want to modify the IKEv2 protocol to fix > this. Or whether if we just change cookie secret not to change too > often that will make problem so rare that we do not care. This is the question. However, giving the advice from RFC8019 (see above), it seems that the problem is worth to solve. Regards, Valery. > -- > kivinen@iki.fi From nobody Thu Sep 24 08:37:30 2020 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 3A6033A0EFB for ; Thu, 24 Sep 2020 08:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 pf-2aC8flYH9 for ; Thu, 24 Sep 2020 08:37:27 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72F463A0EEF for ; Thu, 24 Sep 2020 08:37:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4BxzgX6qRYz37K; Thu, 24 Sep 2020 17:37:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1600961832; bh=2xVjNO4KlHF7fgpmuAN9FHpWFGgRrwkvnOdRUr1HpYs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=EykAf2KhR7HFJdO10OhpvUcl/JBcocIbx67ZpqLxln8vZqrXFpa3pmUWXD1vUoBLY OA0gVoKYoO9kDQF/Ea7DWXM5gfYDI03X4xELGQPBA8kFNIFrA2zNAxUQ0r6SOhm+Ha f3cKxrapEw6FUg4DPg4mTs8lVeMOcgHnkj+xWX/I= 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 IQ7jHj55VPg2; Thu, 24 Sep 2020 17:37:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 24 Sep 2020 17:37:11 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0F5926029A48; Thu, 24 Sep 2020 11:37:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0700D66AF7; Thu, 24 Sep 2020 11:37:10 -0400 (EDT) Date: Thu, 24 Sep 2020 11:37:09 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: 'IPsecME WG' , "'Panwei (William)'" , 'Tero Kivinen' In-Reply-To: <0e2901d69274$ab071cc0$01155640$@gmail.com> Message-ID: References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> <24426.17186.275023.44982@fireball.acr.fi> <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> <0e2901d69274$ab071cc0$01155640$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 24 Sep 2020 15:37:29 -0000 On Thu, 24 Sep 2020, Valery Smyslov wrote: >> We have a server that is under a serious DDoS attack. It is sending back >> COOKIES and soon might have too many half open SA's to even accept any >> new connections with COOKIES. > > I fail to understand why server might have too many half open SA's > with the proposed extension. Note, that it remains stateless until > the client returns COOKIE, exactly as it happens now. That's true. I was assuming a bunch of these would be advanced enough to receive packets back too, but then fail authentication. So they would linger as half-open for a while. If it was just an attack of spoofed packets, then you would be correct. > The problem is not the delay. The problem is that sometime > it caused failed authentication, that definitely must not > happen as a result of bad network. If client receives > fails due to exchange timeout, it's clear for him/her that > this is transient error and an attempt should be retried. > If it receives response AUTHENTICATION_FAILED > it might suspect that something is wrong with his/her credentials > and probably won't retry until figuring this out. > Even if this happens rarely, it means that the protocol is flawed. That is a fair point. Paul From nobody Thu Sep 24 14:50:15 2020 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 C851A3A0F66 for ; Thu, 24 Sep 2020 14:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iki.fi 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 1Wg9PL33Iv3f for ; Thu, 24 Sep 2020 14:50:11 -0700 (PDT) Received: from meesny.iki.fi (meesny.iki.fi [IPv6:2001:67c:2b0:1c1::201]) (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 B734E3A0A00 for ; Thu, 24 Sep 2020 14:50:10 -0700 (PDT) Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by meesny.iki.fi (Postfix) with ESMTPSA id 29D4220553; Fri, 25 Sep 2020 00:50:07 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1600984207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BVUiQuifpR0vucPQP7mj3NZYsV2ex540tfKQcxVARL8=; b=NB2PwCHrE65yqX12BS0+AbNhPi0M+CYVUrcnMoPHLU+Fhh1mFXNgb7Gv4mNEM6n+sZ83+v 6aqqqtaqH7ZziP2fRHWiZP2c8UdAFSUVkWUPWZSgwt0fW8S0TlUdUbiX/VYS8evJbHneeI 5HwuSJ+7hK1+VvX+K3e3lQeOshcnmy4= Received: by fireball.acr.fi (Postfix, from userid 15204) id D923A25C0BAD; Fri, 25 Sep 2020 00:50:06 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24429.5262.851837.148188@fireball.acr.fi> Date: Fri, 25 Sep 2020 00:50:06 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Panwei \(William\)'" , "'IPsecME WG'" In-Reply-To: <0e2a01d69278$d33f7350$79be59f0$@gmail.com> References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> <24426.17186.275023.44982@fireball.acr.fi> <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> <24427.58722.139650.897613@fireball.acr.fi> <0e2a01d69278$d33f7350$79be59f0$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 16 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=meesny; t=1600984207; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=BVUiQuifpR0vucPQP7mj3NZYsV2ex540tfKQcxVARL8=; b=Ij4bdy8RVuJ38Af0K6SYi6t1UvKgrtVkltENtJJQwg2742Ph9A57QCqoSNjegNYICy4ARV F3qx/s6m6h275LUyAQL4rw5N6lFU+hTBPnLN4eAEDA3JODEIg0/tI1rt7MyoftNDTiRcb6 p7DrSSXIFhyoYGYw/5yIRT5rktvu0tU= ARC-Seal: i=1; s=meesny; d=iki.fi; t=1600984207; a=rsa-sha256; cv=none; b=vSgyH7wDy2heyZw/0RzToSrZmspXotVqbOd7VC6OTBIcrQMHnjT1YfdB3s3JrzunH8MBQM 6OsZwfV0woD8DvWLspN9H0O71Ehq8nlabyEagLwnH5ui4ZrtH+tD7Y5sok2YSr2FK26Tgk Ti/HUQtl5KV5Ivv8WXftRfm361ksZIY= ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 24 Sep 2020 21:50:14 -0000 Valery Smyslov writes: > Hi Tero, > > > > > I think the long term solution is to do puzzles, as I do not think you > > > > need to change puzzles secrets that often compared to the cookie > > > > secrets. > > > > > > Puzzle are not solution for this problem. RFC 8019 suggests that > > > is included in the cookie that allows the responder > > > to determine the requested puzzle difficulties and the like. > > > Even if cookie secret is not changed, this information may change > > > quite frequently and we will run into the same problem. > > > > If I remember right puzzles requires the attacker to solve the puzzles > > before it can do the attack, thus making changing the cookie or puzzle > > secrets something that can be done much more infrequently. I mean if > > it takes a second for the attacker to solve the puzzle, that means > > that you can easly slow the done the attack rate from single source so > > much that you do not need to change cookie secret too often. > > If the same cookie is returned every time to a given initiator, > then this initiator can solve puzzle once (since cookie is an input data > for a puzzle) and then present the solution many times (selecting the same > SPIi and Ni), thus bypassing DDoS protection. But in that case the connection is same, and as puzzle is already solved, you have created state, and if the IKE_SA_INIT is repeated with solved puzzle and cookie, you simply retransmit the response. Or do you mean that after the few minutes when the actual IKE_AUTH failes the attacker can then reuse the old cookie and puzzle and try again, as responder has already forgetten everything about the previous attempt? I think adding timestamp to the cookie would allow you to detect when someone uses old cookie even if you have not changed the cookie secret, i.e. put unix timestamp inside the AdditionalInfo of the cookie, and then when you receive cookie with puzzle, you can verify that it is not too old. > For this reason RFC8019 advises to make every cookie different > or at least to change the secret frequently. I think adding timestamp is better solution. > > And if attacker has so much cpu power and with properly connected > > routable addresses, that you can't cope even with puzzles on, then you > > are out of action anyways, regardless whether you change cookie secret > > or not. > > Not exactly. If you return different cookies to the same initiator each > time it starts creating IKE SA, then this initiator will have to solve > new puzzle every time. Otherwise it can do it once and then > present the solution many times. If you have timestamps there it can only present it as long as you allow time for it to solve the puzzle. Also as the time cookies and puzzles are accepted is limited, you can also keep state of already used puzzles, as for anything to be added to that state do require attacker to solve the puzzle first, and you will anyways at least once move to the IKE_AUTH doing diffie-hellman so you can keep that state bit longer (for example if you only allow cookies that are sent in last 5 minutes to be used, that should allow plenty of time for initiators to solve the puzzle but still allows responder of limited amount of state it needs to keep (i.e., few bytes for every puzzle attacker can solve during that time period). > > > - it eliminates cases when the responder cannot verify cookie sent > > > in IKE_AUTH (unclear what to do in this case) > > > > If responder cannot verify the cookie, it will drop the conenction > > with error, because this cookie was so old that it is no longer > > valid... > > Why? Note, that the purpose of cookie is to verify that the client > is a live host. If the client managed to get to IKE_AUTH, then it's > definitely live. On the other hand, I agree that it's strange to > receive unverifiable cookie. That's why I said that it's unclear > what to do in this case and I'd rather to eliminate such situations > from the protocol. Because of the cookie is not anything responder ever used, the authentication will anyways fail, as responder will not be using same cookie when calculating auth payload than initiator. This is just to make sure we do not fail with AUTHENTICATION_FAILED but with some other error message the indicates more clearly that something wierd happened, and you should try again. -- kivinen@iki.fi From nobody Fri Sep 25 00:16:22 2020 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 4C4343A1219 for ; Fri, 25 Sep 2020 00:16:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJMtNtkQbYrY for ; Fri, 25 Sep 2020 00:16:20 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 9BDA23A1218 for ; Fri, 25 Sep 2020 00:16:19 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id k25so1570769ljg.9 for ; Fri, 25 Sep 2020 00:16:19 -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=iF+dw940I2XA5Ax/riS3pClLMPiTe4jTvzz2WlRCOEw=; b=CuWsDvQmzF27p1cJ8xNkSCMXTn8jN65MRRCDdWrywZINuonzxBcSK+jwvrJIb51yfk MNYEHKjABkEcsI0WLXQAv5AuDJ/UeVgAEXLwOD+ZMVmZnxM8ofYAJvZIipizD1OfOreE mwqXcZ7gGIbzYHvwn7hx+0zrC81afUgz9PYK8d3vY1hhBIuXfTCwFVUC6efHX7SFRD2H 7FsB6zHQNlErNoI+ZyYJ/n0LoxNRWQF1Xq6VjYKwusmnhlnfJEyXbfNWYiob7hZSAx/N rlQh0wBWREjpPgORIiFHMJZ3DYzUhZNJL5JhFHViuZFDlLzWs9mRek91InN6ARdybQh6 hFWA== 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=iF+dw940I2XA5Ax/riS3pClLMPiTe4jTvzz2WlRCOEw=; b=GPxqScdhZWcuR74oy7wDK7NB+eYnHSagkEM5KQNvc3uIKlJt+ep0/A3+s0++1Bmazq 483rbxNY3886jAGPqkLrjb6sp5oa77AA0f28OPPHnKbtmFqhLKcdb2epGT9uAkda68Qk 4AFzqE+utSrtO9JKD1075UG+KXfxzBEYXxMqpvfhPY4XHWLssyrSeOYkXHWi3LmgyQYe WkD8mq+rZQfFEBkm2rDSxMtjjDg5grYraB9ZpN0dJPnK/qiH9dipWJDMYx8s3DhnDJKc 3c1CAaxsYnrmG/j1RvS8H42YM9dzVajxnl9GUiQM2XYcawLv1EvM+jMbe3OXGFOr+hk/ y/BA== X-Gm-Message-State: AOAM532Be5PAWznzc6b9pYvSjaHXgLyejeWYZ0jYJvNwS+rUzM2iGWj3 60S3eciug96A3WYaABJd/pXWJXz/Wes= X-Google-Smtp-Source: ABdhPJxWOgXc3bkrqiccgqNks49YgCbAEZZJH3kb0fBES4WGjQ6oG5cpd97YaymdMX9QNCxVO2P4zA== X-Received: by 2002:a2e:2241:: with SMTP id i62mr988042lji.265.1601018177552; Fri, 25 Sep 2020 00:16:17 -0700 (PDT) Received: from buildpc ([82.138.51.3]) by smtp.gmail.com with ESMTPSA id p27sm1560343lfo.272.2020.09.25.00.16.16 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Sep 2020 00:16:16 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'Panwei \(William\)'" , "'IPsecME WG'" References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> <24426.17186.275023.44982@fireball.acr.fi> <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> <24427.58722.139650.897613@fireball.acr.fi> <0e2a01d69278$d33f7350$79be59f0$@gmail.com> <24429.5262.851837.148188@fireball.acr.fi> In-Reply-To: <24429.5262.851837.148188@fireball.acr.fi> Date: Fri, 25 Sep 2020 10:16:20 +0300 Message-ID: <0e9d01d6930b$c5076d90$4f1648b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIDerNHJ6yQWbz9owZeTkO8kxeEfAE/6KzdAuLolooBtd1BXAH19/peAh1mm6EB1e4qMqjBD+GA Content-Language: ru Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication 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, 25 Sep 2020 07:16:21 -0000 Hi Tero, > > If the same cookie is returned every time to a given initiator, > > then this initiator can solve puzzle once (since cookie is an input data > > for a puzzle) and then present the solution many times (selecting the same > > SPIi and Ni), thus bypassing DDoS protection. > > But in that case the connection is same, and as puzzle is already > solved, you have created state, and if the IKE_SA_INIT is repeated > with solved puzzle and cookie, you simply retransmit the response. > > Or do you mean that after the few minutes when the actual IKE_AUTH > failes the attacker can then reuse the old cookie and puzzle and try > again, as responder has already forgetten everything about the > previous attempt? Yes, that's what I meant. > I think adding timestamp to the cookie would allow you to detect when > someone uses old cookie even if you have not changed the cookie > secret, i.e. put unix timestamp inside the AdditionalInfo of the > cookie, and then when you receive cookie with puzzle, you can verify > that it is not too old. > > > For this reason RFC8019 advises to make every cookie different > > or at least to change the secret frequently. > > I think adding timestamp is better solution. Yes, that's what RFC8019 advises. However, this would make the problem with false failed authentication worse, since even without changing secret cookies will change frequently for the same peer and the chances for this situation to happen will increase. > > > And if attacker has so much cpu power and with properly connected > > > routable addresses, that you can't cope even with puzzles on, then you > > > are out of action anyways, regardless whether you change cookie secret > > > or not. > > > > Not exactly. If you return different cookies to the same initiator each > > time it starts creating IKE SA, then this initiator will have to solve > > new puzzle every time. Otherwise it can do it once and then > > present the solution many times. > > If you have timestamps there it can only present it as long as you > allow time for it to solve the puzzle. Also as the time cookies and > puzzles are accepted is limited, you can also keep state of already > used puzzles, as for anything to be added to that state do require > attacker to solve the puzzle first, and you will anyways at least once > move to the IKE_AUTH doing diffie-hellman so you can keep that state > bit longer (for example if you only allow cookies that are sent in > last 5 minutes to be used, that should allow plenty of time for > initiators to solve the puzzle but still allows responder of limited > amount of state it needs to keep (i.e., few bytes for every puzzle > attacker can solve during that time period). I'd rather to avoid additional and prolonged states on responder... > > > If responder cannot verify the cookie, it will drop the conenction > > > with error, because this cookie was so old that it is no longer > > > valid... > > > > Why? Note, that the purpose of cookie is to verify that the client > > is a live host. If the client managed to get to IKE_AUTH, then it's > > definitely live. On the other hand, I agree that it's strange to > > receive unverifiable cookie. That's why I said that it's unclear > > what to do in this case and I'd rather to eliminate such situations > > from the protocol. > > Because of the cookie is not anything responder ever used, the > authentication will anyways fail, as responder will not be using same > cookie when calculating auth payload than initiator. This is just to > make sure we do not fail with AUTHENTICATION_FAILED but with some > other error message the indicates more clearly that something wierd > happened, and you should try again. OK, and that's the problem:. you drop the connection that otherwise would succeed just because cookie is stall. Sure, the initiator will retry, but overall it looks like a non-optimal protocol design. Regards, Valery. > kivinen@iki.fi From nobody Sat Sep 26 07:53:00 2020 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 16D8A3A010A for ; Sat, 26 Sep 2020 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi 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 oaO9RKZDoA-M for ; Sat, 26 Sep 2020 07:52:57 -0700 (PDT) Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [IPv6:2a0b:5c81:1c1::37]) (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 4076C3A00E0 for ; Sat, 26 Sep 2020 07:52:55 -0700 (PDT) Received: from fireball.acr.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id D5E791B00118; Sat, 26 Sep 2020 17:52:50 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1601131970; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KPqRGYDUNSLn19wrXpBnn17yUB5+TD9r075k8a5XVC0=; b=A4JdeLMmVneEdVXATw58i7Zbah6yAkzGW53pq6pRbqhYfxXqTtHJkPg+qSfq5Ufmjskw9n kvN2mxfg5s5M0LkU7EVsG34GWo/MAYfFLek0yVSNgI13TNptgucwdtqtnK0pfIW5Hth3Vw epMyLQA4p0/0J/TunT8I3N76LpS3JVsmkxHj+t+K3jSt9RCySrwXpNykrh4OeFLagXV7tA mWr0xZCoYF7nK4X+ZlJWknFOi/CB6vm9F5rCeUYA1JHt9z7RsCVnc1Wqn1nPKvUu3473rE 7til/MIHWE2LBYDb9rDYDDOmTFeliqv51EcBYiPvW1kCubdaStsmzG/oyZuiaA== Received: by fireball.acr.fi (Postfix, from userid 15204) id 1106625C0E35; Sat, 26 Sep 2020 17:52:48 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24431.21952.3719.839515@fireball.acr.fi> Date: Sat, 26 Sep 2020 17:52:48 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Panwei \(William\)'" , "'IPsecME WG'" In-Reply-To: <0e9d01d6930b$c5076d90$4f1648b0$@gmail.com> References: <0bc801d690ef$29136a10$7b3a3e30$@gmail.com> <24426.17186.275023.44982@fireball.acr.fi> <0d3f01d691b3$bbc40e90$334c2bb0$@gmail.com> <24427.58722.139650.897613@fireball.acr.fi> <0e2a01d69278$d33f7350$79be59f0$@gmail.com> <24429.5262.851837.148188@fireball.acr.fi> <0e9d01d6930b$c5076d90$4f1648b0$@gmail.com> X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1601131970; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KPqRGYDUNSLn19wrXpBnn17yUB5+TD9r075k8a5XVC0=; b=REQAw646Y+ywcWBwMKgxwAqSGimTyGymcdfG0pTx/sLJgVfBDfpaJ9fG90b2cPW/tL95vV kzkWsBVoKeumX0jlr+bWwKmtlPc/iouDruRiuVfaYUknIHErU/nt5jN1c5svHv/NEgWVvP 3QldSL5ZSiXaAunZ8OwqPhRxSxxo98mo9y90ovV7Q/DwX6HhBn2S9KpPQtqvZeO3WL1vS+ +kCN3tosbuk3Iz1bd8U3zhFBYWO9e+jMSnNkkYVl4qMZIcNzUPPKMJorYdAqjitNzAdqAu hg3arS+31MnnPWOWGWowNdIp1T2giHslRX6+geYgtsX4vswmRzyuCw5tZ8oZ6w== ARC-Seal: i=1; s=lahtoruutu; d=iki.fi; t=1601131970; a=rsa-sha256; cv=none; b=UNZeEeSpOxnmk365ygFPu7HO8io62s97wUeC9rKjNEwObhtFFJOYwBhq4QiPzQpGEz/BZZ 6THMYy+SZwpE4uku0R2MZkHYuspVC+JyLZFyqD5e2b4IyXz1PuPLFh8EcY4xqFa/cr4JLT X0HHVFnAYOl44rkjVB4B5jyuHt68qSxSvxg+/vKaEfc8tGT2uTVMXS7l3DQk2aqNE7+loV 3GWqUDfyiH+LAAbiRyZOoAngx0uDwdkBJRBS6xNQOAX4HRZ1FLfmasfssMasAWVYLp+z6v sNc3mQwjoTIVcNBXhxuMIeG7B3r9vxXOxCpeDO+uWxef0NYMb2jae7MUklmuAg== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen smtp.mailfrom=kivinen@iki.fi Archived-At: Subject: Re: [IPsec] Cookie logic results in failed authentication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Sep 2020 14:52:59 -0000 Valery Smyslov writes: > > > For this reason RFC8019 advises to make every cookie different > > > or at least to change the secret frequently. > > > > I think adding timestamp is better solution. > > Yes, that's what RFC8019 advises. However, this would make > the problem with false failed authentication worse, since > even without changing secret cookies will change frequently > for the same peer and the chances for this situation to happen will increase. Combined with initiator sending the cookie it used in the IKE_SA_INIT in IKE_AUTH solves that problem, and puzzles solve part of the problem and the timestamp in cookies solves the saved cookies/puzzles problem. > > Because of the cookie is not anything responder ever used, the > > authentication will anyways fail, as responder will not be using same > > cookie when calculating auth payload than initiator. This is just to > > make sure we do not fail with AUTHENTICATION_FAILED but with some > > other error message the indicates more clearly that something wierd > > happened, and you should try again. > > OK, and that's the problem:. you drop the connection that otherwise > would succeed just because cookie is stall. Sure, the initiator will retry, > but overall it looks like a non-optimal protocol design. If initiator sent cookie we do not recognize, that means it is an attacker, or broken implementation so most likely the authentication would not work anyways, so no we are not throwing out connection that would work. Cookie time will tell whether the cookie is new enough that we should recognize and if cookie time is so old that our policy does not allow us to accept it, then accepting that cookie is forbidden by policy. -- kivinen@iki.fi From nobody Sun Sep 27 07:26:28 2020 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 173503A0F8C for ; Sun, 27 Sep 2020 07:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 M8LTUGeM9e01 for ; Sun, 27 Sep 2020 07:26:19 -0700 (PDT) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 299843A0F88 for ; Sun, 27 Sep 2020 07:26:19 -0700 (PDT) Received: from CMGW (unknown [10.9.0.13]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id E69DD40121 for ; Sun, 27 Sep 2020 08:26:15 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id MXd1kLFGXUY3DMXd1kpm61; Sun, 27 Sep 2020 08:26:15 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.2 cv=e/12ceh/ c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10 a=reM5J-MqmosA:10 a=Vy_oeq2dmq0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=ek1ZzK3JAAAA:8 a=48vgC7mUAAAA:8 a=lXQ4aAXma2xo5KIvwZ8A:9 a=QEXdDO2ut3YA:10 a=NIOFosGgFE1dvRPHt9AA:9 a=jBo3mMT2HaanXQ07:21 a=_W_S_7VecoQA:10 a=xQ-UgBqouqXb-DtQvhst:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=eAzXvR7otJiiVf8W6HSrlbn2g1VlFxJdUuYwfUiKNHY=; b=eZf3+QHZP7bZnjad6cCqG84rmq izOHnO754Z1CZOdqnlugVuWI6G3TV0e3k4AHzH5qVgrC3hBwFXtJP7USmbnJyio0FsoeoDhWjdVES et5ZcJLd47SASQAVdHYqeA7WT; Received: from [127.0.0.1] (port=47407 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1kMXd1-002UUH-CP; Sun, 27 Sep 2020 08:26:15 -0600 To: Christian Hopps , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= Cc: Robert Wilton , i2nsf@ietf.org, Gabriel Lopez , draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org, ipsec@ietf.org, last-call@ietf.org, Rafa Marin-Lopez , yang-doctors@ietf.org References: <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <70A0A406-0742-4F28-A5A4-8D539B160E24@chopps.org> <20200923.125826.1562347052257995146.id@4668.se> From: Lou Berger Message-ID: <023fc27b-f86e-ed71-0c8f-d270c338f08c@labn.net> Date: Sun, 27 Sep 2020 10:26:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0E4061741A87736C9144E351" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1kMXd1-002UUH-CP X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:47407 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2020 14:26:22 -0000 This is a multi-part message in MIME format. --------------0E4061741A87736C9144E351 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > This is a sub-optimal compromise b/c all IPsec have SA databases even > ones running IKE -- i.e., SA databases are common whether exposed in > YANG or not -- but if it can move it forward perhaps good enough. > Speaking as an interested party, I hope that some compromise / good enough solution is followed in the -09 version of  this draft. Lou On 9/23/2020 7:20 AM, Christian Hopps wrote: > > >> On Sep 23, 2020, at 6:58 AM, Martin Björklund > > wrote: >> >> Hi, >> >> Christian Hopps > wrote: >>> >>> >>>> On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez >>> > wrote: >>>> >>>>> >>>>> >>>>> But I would like to check: My understanding is that the changes that >>>>> Chris is proposing are pretty small.  I.e. move the SA structure under >>>>> ipsec-common, and put it under a YANG feature.  Are you sure that it >>>>> is impractical to accommodate this change which would allow a single >>>>> ipsec module to be shared and extended via YANG augmentations? >>>> >>>> >>>> In the context of our I-D, if we move SAD structure to ipsec-common, >>>> what we are meaning is that IPsec SA configuration data (setting >>>> values to the SAD structure) are common to the IKE case and the >>>> IKE-less cases, which are not. It is confusing. >>> >>> Something defined in a common module but marked as a feature does not >>> imply that that feature has to be implemented by an importing >>> module. This is not confusing to YANG implementers or users I >>> think. If we are just talking about document flow here, then a >>> sentence saying "the SAD feature is not required to implement IKE >>> functionality" is quite enough to clear that up I think. >> >> Another alternative could be to move these containers to another >> (new) module. > > It may also be enough to mark the notifications in the ikeless module > as a feature I suppose. That is the actual thing I think non-SDN > implementations would want to omit. The module name "ikeless" is not > great in this case, but perhaps workable. > > This is a sub-optimal compromise b/c all IPsec have SA databases even > ones running IKE -- i.e., SA databases are common whether exposed in > YANG or not -- but if it can move it forward perhaps good enough. > > I'm definitely concerned about IETF process and real world usability > here. These modules are basically workable for ipsec I think, they > could be used by operators today. If we restart the entire process to > redo this work for the more generic IPsec case it will probably be > years before they are finished and in the field. This new work can be > started, but why not have something usable in the meantime? > > Thanks, > Chris. > >> >> >> /martin >> >> >> >>> >>> Thanks, >>> Chris. >>> >>>> Moreover, the usage of feature means that, after all, this “common” is >>>> not “common” to both cases IKE case and IKE-less. Again, it seems >>>> confusing. In the IKE case, the SDN/I2NSF controller does not >>>> configure the SAD at all but the IKE implementation in the NSF. In our >>>> opinion, in order to properly add this IPsec SA operational state to >>>> the IKE case we should include operational data about the IPsec SAs >>>> (config false) to the ietf-ipsec-ike. Alternatively, we have certain >>>> operational data (ro) in the SAD structure in the IKE-less case. If >>>> only those are moved to the common part should be ok but we think it >>>> does not solve the problem. >>>> >>> >> -- >> last-call mailing list >> last-call@ietf.org >> https://www.ietf.org/mailman/listinfo/last-call > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --------------0E4061741A87736C9144E351 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

This is a sub-optimal compromise b/c all IPsec have SA databases even ones running IKE -- i.e., SA databases are common whether exposed in YANG or not -- but if it can move it forward perhaps good enough.

Speaking as an interested party, I hope that some compromise / good enough solution is followed in the -09 version of  this draft.

Lou

On 9/23/2020 7:20 AM, Christian Hopps wrote:


On Sep 23, 2020, at 6:58 AM, Martin Björklund <mbj+ietf@4668.se> wrote:

Hi,

Christian Hopps <chopps@chopps.org> wrote:


On Sep 23, 2020, at 5:29 AM, Rafa Marin-Lopez <rafa@um.es> wrote:



But I would like to check: My understanding is that the changes that
Chris is proposing are pretty small.  I.e. move the SA structure under
ipsec-common, and put it under a YANG feature.  Are you sure that it
is impractical to accommodate this change which would allow a single
ipsec module to be shared and extended via YANG augmentations?


In the context of our I-D, if we move SAD structure to ipsec-common,
what we are meaning is that IPsec SA configuration data (setting
values to the SAD structure) are common to the IKE case and the
IKE-less cases, which are not. It is confusing.

Something defined in a common module but marked as a feature does not
imply that that feature has to be implemented by an importing
module. This is not confusing to YANG implementers or users I
think. If we are just talking about document flow here, then a
sentence saying "the SAD feature is not required to implement IKE
functionality" is quite enough to clear that up I think.

Another alternative could be to move these containers to another
(new) module.

It may also be enough to mark the notifications in the ikeless module as a feature I suppose. That is the actual thing I think non-SDN implementations would want to omit. The module name "ikeless" is not great in this case, but perhaps workable.

This is a sub-optimal compromise b/c all IPsec have SA databases even ones running IKE -- i.e., SA databases are common whether exposed in YANG or not -- but if it can move it forward perhaps good enough.

I'm definitely concerned about IETF process and real world usability here. These modules are basically workable for ipsec I think, they could be used by operators today. If we restart the entire process to redo this work for the more generic IPsec case it will probably be years before they are finished and in the field. This new work can be started, but why not have something usable in the meantime?

Thanks,
Chris.



/martin




Thanks,
Chris.

Moreover, the usage of feature means that, after all, this “common” is
not “common” to both cases IKE case and IKE-less. Again, it seems
confusing. In the IKE case, the SDN/I2NSF controller does not
configure the SAD at all but the IKE implementation in the NSF. In our
opinion, in order to properly add this IPsec SA operational state to
the IKE case we should include operational data about the IPsec SAs
(config false) to the ietf-ipsec-ike. Alternatively, we have certain
operational data (ro) in the SAD structure in the IKE-less case. If
only those are moved to the common part should be ok but we think it
does not solve the problem.


-- 
last-call mailing list
last-call@ietf.org
https://www.ietf.org/mailman/listinfo/last-call


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--------------0E4061741A87736C9144E351-- From nobody Mon Sep 28 02:01:52 2020 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 B92443A0F3A; Mon, 28 Sep 2020 02:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 yEt0IJ2v5-Aj; Mon, 28 Sep 2020 02:01:48 -0700 (PDT) Received: from mx02.puc.rediris.es (outbound4sev.lav.puc.rediris.es [130.206.19.177]) (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 0D2413A0F3F; Mon, 28 Sep 2020 02:01:47 -0700 (PDT) Received: from xenon41.um.es (xenon41.um.es [155.54.212.167]) by mx02.puc.rediris.es with ESMTP id 08S91ZFt013876-08S91ZFu013876; Mon, 28 Sep 2020 11:01:35 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon41.um.es (Postfix) with ESMTP id 5FEC8209A9; Mon, 28 Sep 2020 11:01:35 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon41.um.es Received: from xenon41.um.es ([127.0.0.1]) by localhost (xenon41.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XsyNDacb1m11; Mon, 28 Sep 2020 11:01:35 +0200 (CEST) Received: from [192.168.1.33] (198.red-2-138-84.dynamicip.rima-tde.net [2.138.84.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon41.um.es (Postfix) with ESMTPSA id 54B0920956; Mon, 28 Sep 2020 11:01:27 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <4DDFB9F6-DA2D-4E77-8987-010FDBFAD018@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_C65B2203-3321-4984-9A9D-A6AD7EF10CD7" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Mon, 28 Sep 2020 11:01:28 +0200 In-Reply-To: <5F6B2757.9010804@btconnect.com> Cc: Rafa Marin-Lopez , Christian Hopps , "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "yang-doctors@ietf.org" To: tom petch , "Rob Wilton (rwilton)" References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <5F6B2757.9010804@btconnect.com> X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.167, helo=xenon41.um.es, mailFrom=rafa@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.167 as permitted sender) smtp.mailfrom=rafa@um.es DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=0IyKX35UyfpxHea7Cup/QqtuNHO0ceY7HbdQF7Gv0U0=; b=iSGA6Ph4KOzZuRFT/wGtg2z48wcECu9l5KZE3+3T9ObANruXfIw+bjAl88hNRvvWcJXg2zsCffii o4rvwCAVeM+eSRXECAfsdxBNxQHPJDW9JtyeWz+eQSLqGTSiPKAogwrA+tkEwAVsBfTidkfzEtJm XE3/sNKBIfXK3P+Si0uezsU6Bjh+7gGnHb1Eek94+6uE/+fzxDxHg1k2RGHCqAJ8XFuDYojb24Oz fnaNE5dvOD6KQ1nwtjnvQOoFtY0kTl+QgC3DZPlbXXtmLjPoYciFIac0izZSc2jaWXLVa44Yehft velhiQUmXvQEfs+r8ALQzcAlaOK5O9OHoUm6Xg== Archived-At: Subject: Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 28 Sep 2020 09:01:51 -0000 --Apple-Mail=_C65B2203-3321-4984-9A9D-A6AD7EF10CD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Rob, Tom: Renaming the modules sounds reasonable. With regard to have a different = prefix, it is also ok. Perhaps the easiest way is to solve this is the = following: instead of using -sdn- we could include -i2nsf- so we would = have: ietf-i2nsf-common, ietf-i2nsf-ike, and ietf-i2nsf-ikeless. This = would mean that this is in the context of i2nsf wg. What do you think? > El 23 sept 2020, a las 12:45, tom petch > escribi=C3=B3: >=20 > On 23/09/2020 11:24, Rob Wilton (rwilton) wrote: >> Hi Rafa, >>=20 >> Thanks for replying with the extra background information. >>=20 >> It seems like renaming the modules, as you propose for the -09 = version, is the pragmatic path forward here. >=20 > And the namespace and the YANG prefix IMHO. Having ike as a prrefix = for a module which is not the 'ike' module I see as a source of = confusion. If this is nsf specific, then I would suggest nsfike although = nsfikeless then seems a bit long. >=20 > Tom Petch >=20 >> Regards, >> Rob >>=20 >>=20 >> From: Rafa Marin-Lopez > >> Sent: 23 September 2020 10:29 >> To: Rob Wilton (rwilton) >; Christian Hopps > >> Cc: Rafa Marin-Lopez >; i2nsf@ietf.org = ; Gabriel Lopez >; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org = ; = ipsec@ietf.org ; last-call@ietf.org = ; Martin Bj=C3=B6rklund >; yang-doctors@ietf.org = >> Subject: Re: [I2nsf] [yang-doctors] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>=20 >> Hi Rob, (Chris): >>=20 >> Thank you very much for your answers. Please see our comments inline. >>=20 >>=20 >> El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) = >> = escribi=C3=B3: >>=20 >> Hi Rafa, >>=20 >> Thanks for getting back to me. >>=20 >> Yes, changing the name of the module is an okay, if not ideal, = resolution. But I appreciate that you also want to be done with this = work. >>=20 >> Correct, especially at this point of time. We have been discussing = this I-D for a long time. There was a consensus in the WG. I2NSF WG = chairs can comment about this. In our opinion, the changes that need to = be applied are major changes from what it was approved in the WG. = However, this is coming in the =E2=80=9Clast minute=E2=80=9D and we feel = this is not merely moving a few lines from here to there. We need to = understand the impact of this. Therefore, it is not so trivial as it may = seem. See below. >>=20 >>=20 >>=20 >> But I would like to check: My understanding is that the changes that = Chris is proposing are pretty small. I.e. move the SA structure under = ipsec-common, and put it under a YANG feature. Are you sure that it is = impractical to accommodate this change which would allow a single ipsec = module to be shared and extended via YANG augmentations? >>=20 >>=20 >> In the context of our I-D, if we move SAD structure to ipsec-common, = what we are meaning is that IPsec SA configuration data (setting values = to the SAD structure) are common to the IKE case and the IKE-less cases, = which are not. It is confusing. Moreover, the usage of feature means = that, after all, this =E2=80=9Ccommon=E2=80=9D is not =E2=80=9Ccommon=E2=80= =9D to both cases IKE case and IKE-less. Again, it seems confusing. In = the IKE case, the SDN/I2NSF controller does not configure the SAD at all = but the IKE implementation in the NSF. In our opinion, in order to = properly add this IPsec SA operational state to the IKE case we should = include operational data about the IPsec SAs (config false) to the = ietf-ipsec-ike. Alternatively, we have certain operational data (ro) in = the SAD structure in the IKE-less case. If only those are moved to the = common part should be ok but we think it does not solve the problem. >>=20 >> Therefore it is not only an implementation aspect. >>=20 >> As you may observe, our discussion is taking into account there is an = I2NSF Controller and we have two cases IKE case and IKE-less case, that = have been discussed in the WG. The YANG model in the I-D has tried to = reflect this discussion. It was never the intention to provide a general = YANG model for IPsec. >>=20 >> Best Regards. >>=20 >>=20 >> Thanks, >> Rob >>=20 >>=20 >> From: Rafa Marin-Lopez >> >> Sent: 22 September 2020 14:05 >> To: Rob Wilton (rwilton) >> >> Cc: Rafa Marin-Lopez >>; Christian = Hopps >>; Gabriel Lopez >>; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org = >; = i2nsf@ietf.org >; ipsec@ietf.org = >; = last-call@ietf.org >; yang-doctors@ietf.org = >; Martin Bj=C3=B6rklund >> >> Subject: Re: [yang-doctors] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>=20 >> Dear Rob: >>=20 >> Apologies for our delayed answer. We are now working in the revision = to submit v09 by compiling all the comments. >>=20 >> As you mentioned, we want to avoid any further delay. As we mentioned = to Chris in the past (i2nsf mailing list), we do not have any problem to = include some additional text (e.g. =E2=80=9C-sdn-" in the module names). = Therefore, Rob, we agree with your point of view about this. >>=20 >> In summary, we are working in the next revision v09, and our idea to = address Chris=E2=80=99 comments was to include -sdn- to the module = names. >>=20 >> We hope this is fine. >>=20 >> Best regards. >>=20 >>=20 >>=20 >> El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) >> escribi=C3=B3: >>=20 >> Hi draft authors, Chris, >>=20 >> Can we also please try and close on this issue raised by Chris. >>=20 >> Chris, I don=E2=80=99t think that there is any great way to solve = this issue using YANG features, but presumably the constraint could be = enforced with a must statement, or groupings could be used to copy parts = of the ipsec structure into an sdn specific ipsec tree structure. >>=20 >> I understand that there isn't any great desire to delay these drafts = by trying to generalize the ipsec YANG model contained within it. = However, I think that means that the modules should have "-sdn-" in = their names to indicate that they are intended specifically for the SDN = use case, and should not be confused with the more generic ipsec YANG = modules that have been proposed. >>=20 >> Regards, >> Rob >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: yang-doctors >> On Behalf Of Christian >> Hopps >> Sent: 24 August 2020 18:08 >> To: Martin Bj=C3=B6rklund >> >> Cc: i2nsf@ietf.org >; draft-ietf-i2nsf-sdn-ipsec-flow- >> protection.all@ietf.org = >; ipsec@ietf.org = >; = last-call@ietf.org >; yang- >> doctors@ietf.org > >> Subject: Re: [yang-doctors] Yangdoctors last call review of = draft-ietf- >> i2nsf-sdn-ipsec-flow-protection-08 >>=20 >> [adding in ipsec@] >>=20 >> Hi, >>=20 >> This draft was discussed in ipsecme at the last IETF, and there was a >> desire to look closer at a couple changes that would make these = models >> usable by ipsec generally rather than only for SDNs. Otherwise we = will end >> up with 2 models that look very similar and duplicate almost all the >> functionality. This was going to be done during the next yang doctor >> review, but it looks like that happened in the meantime (ships in the >> night). >>=20 >> At minimum the module names should include "-sdn-" if no other = changes are >> made to indicate that they are only for sdn use; however, this is not = the >> optimal solution. >>=20 >> A better solution would be to move the containers currently under = ikeless >> (for SA and Policy databases) under ipsec-common. >>=20 >> The feedback I received from the authors was that the SDN controllers >> didn't care about the actual SAs and policies when using IKE so they >> didn't want to require someone implementing ike+common modules to = have to >> support them. >>=20 >> The YANG question I suppose is, is there an easy way to move these >> containers from ipsec-ikeless to ipsec-common, but still allow for = them to >> be empty and/or unimplemented for the SDN IKE use case? If they were = made >> features, is there a proper YANG way to indicate that if the ikeless >> module is present then those features must also be supported thus = matching >> the functionality as defined by the current draft? >>=20 >> Thanks, >> Chris. >>=20 >>=20 >>=20 >>=20 >>=20 >> On Aug 24, 2020, at 10:37 AM, Martin Bj=C3=B6rklund via Datatracker >> >> wrote: >>=20 >>=20 >>=20 >> Reviewer: Martin Bj=C3=B6rklund >> Review result: Ready with Nits >>=20 >> I did an early YANG Doctor's review of this draft. Most of my >> comments then have been addressed in this version. >>=20 >> Comments: >>=20 >> o As I wrote in my early review, the RFC editor enforces a common >> format of YANG modules, so it is better to adhere to this format >> before sending the draft to the RFC editor. Use >>=20 >> pyang -f yang --yang-line-length 69 >>=20 >> to get a consistent look-and-feel for your module. >>=20 >> (You will have to manually re-flow description statements after >> this.) >>=20 >>=20 >> o There are some leafs that are optional in the model, but w/o a >> default value and w/o an explanation of what happens if that leaf >> is not set. You should find those and either make them mandatory, >> add a default value, or explain what it means when it isn't set. >> As an example, >> /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret >> is optional. I suspect that this leaf needs to be mandatory. >> Another example is the leaf espencap. >>=20 >>=20 >> /martin >>=20 >>=20 >> _______________________________________________ >> yang-doctors mailing list >> yang-doctors@ietf.org = > >> https://www.ietf.org/mailman/listinfo/yang-doctors = >>=20 >>=20 >> ------------------------------------------------------- >> 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 >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> I2nsf mailing list >> I2nsf@ietf.org >> https://www.ietf.org/mailman/listinfo/i2nsf >>=20 >> ------------------------------------------------------- >> 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 >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 ------------------------------------------------------- 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:=C2=A0rafa@um.es = ------------------------------------------------------- --Apple-Mail=_C65B2203-3321-4984-9A9D-A6AD7EF10CD7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Rob, Tom:

Renaming the modules = sounds reasonable. With regard to have a different prefix, it is also = ok. Perhaps the easiest way is to solve this is the following: instead = of using -sdn- we could include -i2nsf- so we would have: = ietf-i2nsf-common, ietf-i2nsf-ike, and ietf-i2nsf-ikeless. This would = mean that this is in the context of i2nsf wg.

What do you think?

El 23 sept 2020, a las 12:45, tom petch <daedulus@btconnect.com> escribi=C3=B3:

On = 23/09/2020 11:24, Rob Wilton (rwilton) wrote:
Hi Rafa,

Thanks = for replying with the extra background information.

It seems like renaming the modules, as you propose for the = -09 version, is the pragmatic path forward here.

And the namespace and the YANG = prefix IMHO.  Having ike as a prrefix for a module which is not the = 'ike' module I see as a source of confusion. If this is nsf specific, = then I would suggest nsfike although nsfikeless then seems a bit = long.

Tom Petch

Regards,
Rob


From: Rafa = Marin-Lopez <rafa@um.es>
Sent: 23 September 2020 = 10:29
To: Rob Wilton (rwilton) <rwilton@cisco.com>; = Christian Hopps <chopps@chopps.org>
Cc: Rafa Marin-Lopez = <rafa@um.es>; i2nsf@ietf.org; Gabriel = Lopez <gabilm@um.es>;= draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org; = ipsec@ietf.org; last-call@ietf.org; = Martin Bj=C3=B6rklund <mbj+ietf@4668.se>; yang-doctors@ietf.org
Subject: Re: [I2nsf] = [yang-doctors] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

Hi Rob, (Chris):

Thank you very = much for your answers. Please see our comments inline.


El 22 sept 2020, a las 17:38, Rob Wilton = (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org<mailto:rwilton=3D40cisco.com@dmarc.ietf.org>> = escribi=C3=B3:

Hi Rafa,

Thanks for getting back to me.

Yes, changing the name of the module is an okay, if not = ideal, resolution.  But I appreciate that you also want to be done = with this work.

Correct, especially at this = point of time. We have been discussing this I-D for a long time. There = was a consensus in the WG. I2NSF WG chairs can comment about this. In = our opinion, the changes that need to be applied are major changes from = what it was approved in the WG. However, this is coming in the =E2=80=9Cla= st minute=E2=80=9D and we feel this is not merely moving a few lines = from here to there. We need to understand the impact of this. Therefore, = it is not so trivial as it may seem. See below.



But I would like to check: =  My understanding is that the changes that Chris is proposing are = pretty small.  I.e. move the SA structure under ipsec-common, and = put it under a YANG feature.  Are you sure that it is impractical = to accommodate this change which would allow a single ipsec module to be = shared and extended via YANG augmentations?


In the context of our I-D, if we move SAD = structure to ipsec-common, what we are meaning is that IPsec SA = configuration data (setting values to the SAD structure) are common to = the IKE case and the IKE-less cases, which are not. It is confusing. = Moreover, the usage of feature means that, after all, this =E2=80=9Ccommon= =E2=80=9D is not =E2=80=9Ccommon=E2=80=9D to both cases IKE case and = IKE-less. Again, it seems confusing. In the IKE case, the SDN/I2NSF = controller does not configure the SAD at all but the IKE implementation = in the NSF. In our opinion, in order to properly add this IPsec SA = operational state to the IKE case we should include operational data = about the IPsec SAs (config false) to the ietf-ipsec-ike. Alternatively, = we have certain operational data (ro) in the SAD structure in the = IKE-less case. If only those are moved to the common part should be ok = but we think it does not solve the problem.

Therefore it is not only an implementation aspect.

As you may observe, our discussion is taking = into account there is an I2NSF Controller and we have two cases IKE case = and IKE-less case, that have been discussed in the WG. The YANG model in = the I-D has tried to reflect this discussion. It was never the intention = to provide a general YANG model for IPsec.

Best Regards.


Thanks,
Rob


From: Rafa Marin-Lopez <rafa@um.es<mailto:rafa@um.es>>
Sent: 22 = September 2020 14:05
To: Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>>
Cc: Rafa = Marin-Lopez <rafa@um.es<mailto:rafa@um.es>>; Christian Hopps <chopps@chopps.org<mailto:chopps@chopps.org>>; Gabriel Lopez <gabilm@um.es<mailto:gabilm@um.es>>; = draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org<= mailto:draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org<= /a>>; i2nsf@ietf.org<mailto:i2nsf@ietf.org>; ipsec@ietf.org<mailto:ipsec@ietf.org>; = last-call@ietf.org<mailto:last-call@ietf.org>; yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>; Martin Bj=C3=B6rklund = <mbj+ietf@4668.se<mailto:mbj+ietf@4668.se>>
Subject: = Re: [yang-doctors] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

Dear Rob:

Apologies for our = delayed answer. We are now working in the revision to submit v09 by = compiling all the comments.

As you = mentioned, we want to avoid any further delay. As we mentioned to Chris = in the past (i2nsf mailing list), we do not have any problem to include = some additional text (e.g. =E2=80=9C-sdn-" in the module names). = Therefore, Rob, we agree with your point of view about this.

In summary, we are working in the next = revision v09, and our idea to address Chris=E2=80=99 comments was to = include -sdn- to the module names.

We hope = this is fine.

Best regards.


El 22 sept 2020, a las 13:56, = Rob Wilton (rwilton) <rwilton@cisco.com<mailto:rwilton@cisco.com>> escribi=C3=B3:

Hi draft authors, Chris,

Can we also please try and close on this issue raised by = Chris.

Chris, I don=E2=80=99t think that = there is any great way to solve this issue using YANG features, but = presumably the constraint could be enforced with a must statement, or = groupings could be used to copy parts of the ipsec structure into an sdn = specific ipsec tree structure.

I understand = that there isn't any great desire to delay these drafts by trying to = generalize the ipsec YANG model contained within it.  However, I = think that means that the modules should have "-sdn-" in their names to = indicate that they are intended specifically for the SDN use case, and = should not be confused with the more generic ipsec YANG modules that = have been proposed.

Regards,
Rob




-----Original Message-----
From: = yang-doctors <yang-doctors-bounces@ietf.org<mailto:yang-doctors-bounces@ietf.org>> On Behalf Of = Christian
Hopps
Sent: 24 August 2020 = 18:08
To: Martin Bj=C3=B6rklund <mbj+ietf@4668.se<mailto:mbj+ietf@4668.se>>
Cc: i2nsf@ietf.org<mailto:i2nsf@ietf.org>; = draft-ietf-i2nsf-sdn-ipsec-flow-
protection.all@ietf.org<mailto:protection.all@ietf.org>; ipsec@ietf.org<mailto:ipsec@ietf.org>; = last-call@ietf.org<mailto:last-call@ietf.org>; yang-
doctors@ietf.org<mailto:doctors@ietf.org>
Subject: Re: = [yang-doctors] Yangdoctors last call review of draft-ietf-
i2nsf-sdn-ipsec-flow-protection-08

[adding in ipsec@]

Hi,

This draft was discussed in ipsecme at the = last IETF, and there was a
desire to look closer at a = couple changes that would make these models
usable by = ipsec generally rather than only for SDNs. Otherwise we will end
up with 2 models that look very similar and duplicate almost = all the
functionality. This was going to be done during = the next yang doctor
review, but it looks like that = happened in the meantime (ships in the
night).

At minimum the module names should include = "-sdn-" if no other changes are
made to indicate that they = are only for sdn use; however, this is not the
optimal = solution.

A better solution would be to = move the containers currently under ikeless
(for SA and = Policy databases) under ipsec-common.

The = feedback I received from the authors was that the SDN controllers
didn't care about the actual SAs and policies when using IKE = so they
didn't want to require someone implementing = ike+common modules to have to
support them.

The YANG question I suppose is, is there an = easy way to move these
containers from ipsec-ikeless to = ipsec-common, but still allow for them to
be empty and/or = unimplemented for the SDN IKE use case? If they were made
features, is there a proper YANG way to indicate that if the = ikeless
module is present then those features must also be = supported thus matching
the functionality as defined by = the current draft?

Thanks,
Chris.





On Aug 24, 2020, at 10:37 AM, = Martin Bj=C3=B6rklund via Datatracker
<noreply@ietf.org<mailto:noreply@ietf.org>> wrote:



Reviewer: Martin Bj=C3=B6rklundReview result: Ready with Nits

I= did an early YANG Doctor's review of this draft.  Most of my
comments then have been addressed in this version.

Comments:

o =  As I wrote in my early review, the RFC editor enforces a common
 format of YANG modules, so it is better to adhere to = this format
 before sending the draft to the RFC = editor.  Use

   pyang = -f yang --yang-line-length 69 <FILE>

=  to get a consistent look-and-feel for your module.
 (You will have to manually re-flow description = statements after
 this.)


o  There are some leafs that are optional = in the model, but w/o a
 default value and w/o an = explanation of what happens if that leaf
 is not = set.  You should find those and either make them mandatory,
 add a default value, or explain what it means when it = isn't set.
 As an example,
=  /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret
 is optional.  I suspect that this leaf needs to = be mandatory.
 Another example is the leaf = espencap.


/martin


_______________________________________________
yang-doctors mailing list
yang-doctors@ietf.org<mailto:yang-doctors@ietf.org>
https://www.ietf.org/mailman/listinfo/yang-doctors


-------------------------------------------------------
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<mailto:rafa@um.es>
-------------------------------------------------------




_______________________________________________
I2nsf mailing list
I2nsf@ietf.org<mailto: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<mailto:rafa@um.es>
-------------------------------------------------------





-------------------------------------------------------
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=_C65B2203-3321-4984-9A9D-A6AD7EF10CD7-- From nobody Mon Sep 28 02:33:59 2020 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 3DBC73A0F59; Mon, 28 Sep 2020 02:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.113 X-Spam-Level: X-Spam-Status: No, score=-2.113 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 TcJ8zlMAmYRW; Mon, 28 Sep 2020 02:33:52 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2091.outbound.protection.outlook.com [40.107.20.91]) (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 840783A0F52; Mon, 28 Sep 2020 02:33:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nnBa3aCBdHesGPZUlcW6KxRAAdMwTFFiCRlE56QNHBAhu1Urm4sZ1pUcJJGitpoEqXfrykiOFOLQJjNNinNNAoy2at6t6LAbaBO3S2i6tlNpVk0bDTRk6844feuqukhhX/ihVEIViHMA2FaOMjYoN5YzDS5MGc5TY4lUOhiLdCMTtkVmn+vOfx5xgFJzbPAjf5U8NO0wC+tD7DTJmiGpfOao4rU+Kp8IdanmaljeNesVl++XiHyRlEDl7GWLithJ+36Ak7h4QsZ058CJsvzrOAuIzLsFwQ8sLF56uukAjbyaSlKZpaPMFesmbtoSMFcE96L0gGVTv9SGfSBhkEO5dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8t/FgCRt8C344SOV6ylq0b/KzDnNojYAFARE8/FDSeA=; b=K+YQ0prPrgV9+AIGKC38cGVcLI5NUT1pVrr1zhUGH7HsxJstyPM8ST4qbGHRmkFGBh1v8A23suoyTYrfiGClEYhffv6dV4dOf5Cv1v8+AMmyhd0jsf9x594bMMBhv+1NzZP0A39HxLKbYQqMzLimQKFRkLMWvtFLcP2qmOiegYo/eE/2O1xaTBKqOv+HLc6lbgqBdumqpkVj6XR0gxi9C0gJXTZ5F4w5RhglWxjNmpOEyRmHBS2RGRCVgWsUNhyYXz5oNHLYWp8YljoAHRejZUOmEbOzGPK01HQ5dtw6XD997B/TnnjThiToFp4x2K1zoGAJJnky4XF+mSDC8RrSbw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8t/FgCRt8C344SOV6ylq0b/KzDnNojYAFARE8/FDSeA=; b=q30yCXApQ4CxPD+L+/NpiOebRlsnz7UxQv0RKNFPBGa3ZzgcPEwSFfqc8oldGCYtl+cG5ZKRpFZ2mR7+U1DqvznSTP1qjlO1SbEVmxBDvKWSnn2CJzEmYxdqwsjFCbhbDTbX77H2HcKUSP74SMmKzruB4JjqOuJI0NotfvBTuPU= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB6558.eurprd07.prod.outlook.com (2603:10a6:800:18e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.18; Mon, 28 Sep 2020 09:33:49 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6165:9c1c:e5b1:15db%4]) with mapi id 15.20.3433.030; Mon, 28 Sep 2020 09:33:49 +0000 To: Rafa Marin-Lopez , "Rob Wilton (rwilton)" References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <5F6B2757.9010804@btconnect.com> <4DDFB9F6-DA2D-4E77-8987-010FDBFAD018@um.es> Cc: Christian Hopps , "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= , "yang-doctors@ietf.org" From: tom petch Message-ID: <5F71ADF6.8020900@btconnect.com> Date: Mon, 28 Sep 2020 10:33:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <4DDFB9F6-DA2D-4E77-8987-010FDBFAD018@um.es> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LO2P265CA0185.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::29) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LO2P265CA0185.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3412.22 via Frontend Transport; Mon, 28 Sep 2020 09:33:48 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: a4437717-4700-4e7a-ebd4-08d863919a9b X-MS-TrafficTypeDiagnostic: VI1PR07MB6558: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6430; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EP4rZwwlZ8PBzv4SiqP0Pfz96oc6789beISEjdHhfcvyetSKLl7qW2o1i9J+MU3I3f5FLAAKu8cspRb/SxfWYPzWejmrcSYIXX/0gXrswHPaeCxTwY5Q3ic7Hiu3yQQSMOquh4IaSWU6peZ/yXO7Yx3xmRI82H3VLamvtF0PPAksbWleUdzvdf7+83+W4MMWm9cSLEzPc6vVvCpvP0dRX9dt1okjSyi+Eq4r2nJpUBMbMsJp2L1957gwbeJlWxZ4312W5i1zzoI7fBbhKpDI10snF8HdcISzaFh4Pau9fFltBlEQ/a28dJDgNMR1RXoQ6lydd9YCjUg9gHtC0v0W2A== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(376002)(39860400002)(366004)(136003)(6666004)(16576012)(53546011)(87266011)(66946007)(66556008)(66476007)(26005)(316002)(4326008)(6486002)(5660300002)(2906002)(36756003)(86362001)(66574015)(52116002)(33656002)(110136005)(54906003)(2616005)(956004)(83380400001)(16526019)(8676002)(186003)(8936002)(7416002)(478600001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: q2Hpkglbeh8e8QUH7DGrHhCAMg5MetLwqcT4tgKDzN05Yvn4XfjOcQgLVfesjJ9QENY1vLiQ3MoR3GYZz7n0X9yAFJxUL93gaAUVsf3Ak9tYDED4QsoYhHOV7lWfU+6iCFEh3nBNgvXhfzS7UNrcYCC6xBmmk1v5p9CnFtBcpfHksXhYZ91w5rVHqfd/6Q3fSBwatHr0smJIYbfqZYEUYL74c/+iu8W+2fy3rEB+/PUQI/nA5gxe8nlaLwSQq2aULtiD2sNLkfYYj006++o8KHvV+zR7oJQqdmm1eGIWBWmI0tiKuzY1TmM+u5q2wBD8j3FpU4t3Low7HdSbZCmFSlszJc+gKK7hpSTNldpgLc/62P41GmePS4Y3VzsGb96AJ+/Yryo/siJwW798kRxPS0PqqDTgBF4IEOcoQ79q2u0/IiGANyif9OcutSJQ2oBVP8DUhDk8dWwQStMH+CRChZ7hXe0Y1roEm/+UO7Cn4T9wje004ojKx8ua4oOJM6utSJD3z6Xi4Ry1bDPanxQGKgIXFq47AOwGQj/XWyFR2clP74Czp20PF1u7x5mMsQPEdR/uhKL1/PmHa81QyoOd4XTryeAKQXJpe6MA/czSjcgK56wkkzkSbSbXHV2PtRBzPstbNh+cBvxDA/CWahJZvg== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4437717-4700-4e7a-ebd4-08d863919a9b X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2020 09:33:49.1025 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: uCundz+JRwlQJd85hFSItoWlJ8Tu9AXSx6TAcCWihjszfwQHreV0qGjatku6XlHbiDjgpJvygyI9N/9TOTSmVw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB6558 Archived-At: Subject: Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 28 Sep 2020 09:33:54 -0000 On 28/09/2020 10:01, Rafa Marin-Lopez wrote: > Hi Rob, Tom: > > Renaming the modules sounds reasonable. With regard to have a different prefix, it is also ok. Perhaps the easiest way is to solve this is the following: instead of using -sdn- we could include -i2nsf- so we would have: ietf-i2nsf-common, ietf-i2nsf-ike, and ietf-i2nsf-ikeless. This would mean that this is in the context of i2nsf wg. > > What do you think? Ok with -ike and -ikeless but I would not use ietf-i2nsf-common the reason being that there is an awful lot in common across the different i2nsf I-D that with hindsight would have made an excellent common i2nsf module and may be will in future if these modules get revised. Other WG have created 'common' or 'types' modules, with more of the latter and then abbreviated that to 't' or 'c' so perhaps ietf-i2nsf-iket, or -ikec. Prefix ahould be short so something like nsfike, nsfikeless (longer than I would like - nsfiken?) and nsfiket, or nsfikec. Tom Petch >> El 23 sept 2020, a las 12:45, tom petch > escribió: >> >> On 23/09/2020 11:24, Rob Wilton (rwilton) wrote: >>> Hi Rafa, >>> >>> Thanks for replying with the extra background information. >>> >>> It seems like renaming the modules, as you propose for the -09 version, is the pragmatic path forward here. >> >> And the namespace and the YANG prefix IMHO. Having ike as a prrefix for a module which is not the 'ike' module I see as a source of confusion. If this is nsf specific, then I would suggest nsfike although nsfikeless then seems a bit long. >> >> Tom Petch >> >>> Regards, >>> Rob >>> >>> >>> From: Rafa Marin-Lopez > >>> Sent: 23 September 2020 10:29 >>> >>> Hi Rob, (Chris): >>> >>> Thank you very much for your answers. Please see our comments inline. >>> >>> >>> El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) >> escribió: >>> >>> Hi Rafa, >>> >>> Thanks for getting back to me. >>> >>> Yes, changing the name of the module is an okay, if not ideal, resolution. But I appreciate that you also want to be done with this work. >>> >>> Correct, especially at this point of time. We have been discussing this I-D for a long time. There was a consensus in the WG. I2NSF WG chairs can comment about this. In our opinion, the changes that need to be applied are major changes from what it was approved in the WG. However, this is coming in the “last minute” and we feel this is not merely moving a few lines from here to there. We need to understand the impact of this. Therefore, it is not so trivial as it may seem. See below. >>> >>> But I would like to check: My understanding is that the changes that Chris is proposing are pretty small. I.e. move the SA structure under ipsec-common, and put it under a YANG feature. Are you sure that it is impractical to accommodate this change which would allow a single ipsec module to be shared and extended via YANG augmentations? >>> >>> In the context of our I-D, if we move SAD structure to ipsec-common, what we are meaning is that IPsec SA configuration data (setting values to the SAD structure) are common to the IKE case and the IKE-less cases, which are not. It is confusing. Moreover, the usage of feature means that, after all, this “common” is not “common” to both cases IKE case and IKE-less. Again, it seems confusing. In the IKE case, the SDN/I2NSF controller does not configure the SAD at all but the IKE implementation in the NSF. In our opinion, in order to properly add this IPsec SA operational state to the IKE case we should include operational data about the IPsec SAs (config false) to the ietf-ipsec-ike. Alternatively, we have certain operational data (ro) in the SAD structure in the IKE-less case. If only those are moved to the common part should be ok but we think it does not solve the problem. >>> >>> Therefore it is not only an implementation aspect. >>> >>> As you may observe, our discussion is taking into account there is an I2NSF Controller and we have two cases IKE case and IKE-less case, that have been discussed in the WG. The YANG model in the I-D has tried to reflect this discussion. It was never the intention to provide a general YANG model for IPsec. >>> >>> Best Regards. >>> >>> Thanks, >>> Rob >>> >>> From: Rafa Marin-Lopez >> >>> Sent: 22 September 2020 14:05 >>> Subject: Re: [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>> >>> Dear Rob: >>> >>> Apologies for our delayed answer. We are now working in the revision to submit v09 by compiling all the comments. >>> >>> As you mentioned, we want to avoid any further delay. As we mentioned to Chris in the past (i2nsf mailing list), we do not have any problem to include some additional text (e.g. “-sdn-" in the module names). Therefore, Rob, we agree with your point of view about this. >>> >>> In summary, we are working in the next revision v09, and our idea to address Chris’ comments was to include -sdn- to the module names. >>> >>> We hope this is fine. >>> >>> Best regards. >>> >>> >>> >>> El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) >> escribió: >>> >>> Hi draft authors, Chris, >>> >>> Can we also please try and close on this issue raised by Chris. >>> >>> Chris, I don’t think that there is any great way to solve this issue using YANG features, but presumably the constraint could be enforced with a must statement, or groupings could be used to copy parts of the ipsec structure into an sdn specific ipsec tree structure. >>> >>> I understand that there isn't any great desire to delay these drafts by trying to generalize the ipsec YANG model contained within it. However, I think that means that the modules should have "-sdn-" in their names to indicate that they are intended specifically for the SDN use case, and should not be confused with the more generic ipsec YANG modules that have been proposed. >>> >>> Regards, >>> Rob >>> >>> -----Original Message----- >>> From: yang-doctors >> On Behalf Of Christian >>> Hopps >>> Sent: 24 August 2020 18:08 >>> >>> [adding in ipsec@] >>> >>> Hi, >>> >>> This draft was discussed in ipsecme at the last IETF, and there was a >>> desire to look closer at a couple changes that would make these models >>> usable by ipsec generally rather than only for SDNs. Otherwise we will end >>> up with 2 models that look very similar and duplicate almost all the >>> functionality. This was going to be done during the next yang doctor >>> review, but it looks like that happened in the meantime (ships in the >>> night). >>> >>> At minimum the module names should include "-sdn-" if no other changes are >>> made to indicate that they are only for sdn use; however, this is not the >>> optimal solution. >>> >>> A better solution would be to move the containers currently under ikeless >>> (for SA and Policy databases) under ipsec-common. >>> >>> The feedback I received from the authors was that the SDN controllers >>> didn't care about the actual SAs and policies when using IKE so they >>> didn't want to require someone implementing ike+common modules to have to >>> support them. >>> >>> The YANG question I suppose is, is there an easy way to move these >>> containers from ipsec-ikeless to ipsec-common, but still allow for them to >>> be empty and/or unimplemented for the SDN IKE use case? If they were made >>> features, is there a proper YANG way to indicate that if the ikeless >>> module is present then those features must also be supported thus matching >>> the functionality as defined by the current draft? >>> >>> Thanks, >>> Chris. >>> >>> On Aug 24, 2020, at 10:37 AM, Martin Björklund via Datatracker >>> >> wrote: >>> >>> Reviewer: Martin Björklund >>> Review result: Ready with Nits >>> >>> I did an early YANG Doctor's review of this draft. Most of my >>> comments then have been addressed in this version. >>> >>> Comments: >>> >>> o As I wrote in my early review, the RFC editor enforces a common >>> format of YANG modules, so it is better to adhere to this format >>> before sending the draft to the RFC editor. Use >>> >>> pyang -f yang --yang-line-length 69 >>> >>> to get a consistent look-and-feel for your module. >>> >>> (You will have to manually re-flow description statements after >>> this.) >>> >>> >>> o There are some leafs that are optional in the model, but w/o a >>> default value and w/o an explanation of what happens if that leaf >>> is not set. You should find those and either make them mandatory, >>> add a default value, or explain what it means when it isn't set. >>> As an example, >>> /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret >>> is optional. I suspect that this leaf needs to be mandatory. >>> Another example is the leaf espencap. >>> >>> >>> /martin >>> From nobody Mon Sep 28 11:49:12 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB593A135D; Mon, 28 Sep 2020 11:49:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kivinen@iki.fi, kaduk@mit.edu, ipsec@ietf.org, ipsecme-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160131894893.17820.13845074328992637927@ietfa.amsl.com> Date: Mon, 28 Sep 2020 11:49:09 -0700 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 109 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2020 18:49:10 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 30 Conflicts to Avoid: Chair Conflict: tls acme Technology Overlap: cfrg People who must be present: Yoav Nir Tero Kivinen Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Sep 29 09:15:04 2020 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 146503A0EEE; Tue, 29 Sep 2020 09:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=um.es 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 tL5EgXHRXqbp; Tue, 29 Sep 2020 09:14:56 -0700 (PDT) Received: from mx02.puc.rediris.es (outbound4sev.lav.puc.rediris.es [130.206.19.178]) (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 8E51A3A0EEF; Tue, 29 Sep 2020 09:14:55 -0700 (PDT) Received: from xenon42.um.es (xenon42.um.es [155.54.212.169]) by mx02.puc.rediris.es with ESMTP id 08TGEfGs015885-08TGEfGt015885; Tue, 29 Sep 2020 18:14:41 +0200 Received: from localhost (localhost [127.0.0.1]) by xenon42.um.es (Postfix) with ESMTP id 0774E2048E; Tue, 29 Sep 2020 18:14:41 +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 y6DxEEmmeIrV; Tue, 29 Sep 2020 18:14:40 +0200 (CEST) Received: from [192.168.1.33] (198.red-2-138-84.dynamicip.rima-tde.net [2.138.84.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa@um.es) by xenon42.um.es (Postfix) with ESMTPSA id 6510D20357; Tue, 29 Sep 2020 18:14:36 +0200 (CEST) From: Rafa Marin-Lopez Message-Id: <8AA79D47-C067-4249-B665-37644301657C@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_E0528C43-7F93-4AFB-97BB-14715EB47D2D" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Tue, 29 Sep 2020 18:14:41 +0200 In-Reply-To: <5F71ADF6.8020900@btconnect.com> Cc: Rafa Marin-Lopez , "Rob Wilton (rwilton)" , Christian Hopps , "i2nsf@ietf.org" , Gabriel Lopez , "draft-ietf-i2nsf-sdn-ipsec-flow-protection.all@ietf.org" , "ipsec@ietf.org" , "last-call@ietf.org" , =?utf-8?Q?Martin_Bj=C3=B6rklund?= , "yang-doctors@ietf.org" To: tom petch References: <159827985531.30993.17722282912726281276@ietfa.amsl.com> <27C522C8-53E3-40EF-ADD7-5B2F84FFCF83@um.es> <2B88888E-A264-4D81-A8DA-9C6225E83E0E@um.es> <5F6B2757.9010804@btconnect.com> <4DDFB9F6-DA2D-4E77-8987-010FDBFAD018@um.es> <5F71ADF6.8020900@btconnect.com> X-Mailer: Apple Mail (2.3445.104.14) X-FEAS-SPF: spf-result=pass, ip=155.54.212.169, helo=xenon42.um.es, mailFrom=rafa@um.es Authentication-Results: mx02.puc.rediris.es; spf=pass (rediris.es: domain of rafa@um.es designates 155.54.212.169 as permitted sender) smtp.mailfrom=rafa@um.es X-FE-Policy-ID: 2:15:0:SYSTEM DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=um.es; s=DKIM; c=relaxed/relaxed; h=from:message-id:content-type:mime-version:subject:date:cc:to:references; bh=lWvod5OFHHxb0XCLWqpXDN3ec+SnKCjLEOIx4HXJD/A=; b=aqJwHYCavFPA1DW3EHpCzlrc/HTaknOxlepikB0QqIkOuwgUhoS1J+3POiH6iAWLZ2liTBDZuIGM KSTExel8Q4idwFB6y3+Y1v4xBBrAk0lkqkhuC2MvRZW+bToldeUX5KdxlKgmHQnVVW7QeWR4yLBE Fox95v85aDVrTeOuidAXIq2Abp9sWRv9k0H7Smcn/eckYMCQEQTnxDZ+Gw8KKPhjB4i1n9zdYQb1 qdvolQxHg4V+nDXgCzAhzp9wumGVYWr5R3ibIRIcqlUZye9eHuMBB1e41kjnggcv5sVQoqd57g6W dxcvqXA8cpZlhOQtsFdcmmV3mStt2cKYYKkFaA== Archived-At: Subject: Re: [IPsec] [Last-Call] [I2nsf] [yang-doctors] Yangdoctors last call review of draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 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, 29 Sep 2020 16:14:58 -0000 --Apple-Mail=_E0528C43-7F93-4AFB-97BB-14715EB47D2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tom: Please see our comments inline: > El 28 sept 2020, a las 11:33, tom petch = escribi=C3=B3: >=20 > On 28/09/2020 10:01, Rafa Marin-Lopez wrote: >> Hi Rob, Tom: >>=20 >> Renaming the modules sounds reasonable. With regard to have a = different prefix, it is also ok. Perhaps the easiest way is to solve = this is the following: instead of using -sdn- we could include -i2nsf- = so we would have: ietf-i2nsf-common, ietf-i2nsf-ike, and = ietf-i2nsf-ikeless. This would mean that this is in the context of i2nsf = wg. >>=20 >> What do you think? >=20 > Ok with -ike and -ikeless Great. > but I would not use ietf-i2nsf-common the reason being that there is = an awful lot in common across the different i2nsf I-D that with = hindsight would have made an excellent common i2nsf module and may be = will in future if these modules get revised. We agree. > Other WG have created 'common' or 'types' modules, with more of the = latter and then abbreviated that to 't' or 'c' so perhaps = ietf-i2nsf-iket, or -ikec. Ok about ietf-i2nsf-ikec. > Prefix ahould be short so something like nsfike, nsfikeless (longer = than I would like - nsfiken?) and nsfiket, or nsfikec. For the prefix to the common module=20 prefix "nsfikec"; For the prefix to the ietf-i2nsf-ike, nsfike seems to refer to IKE case = , which is good. prefix "nsfike=E2=80=9D;=20 For the prefix to the ietf-i2nsf-ikeless, nsfikeless (a shorter one = could be nsfikels but we do not know if that is acceptable) has a clear = meaning and it is coherent with the rest of the names. I think we can = live with a few letters more. =20 Is this acceptable? Best Regards. >=20 > Tom Petch >=20 >>> El 23 sept 2020, a las 12:45, tom petch > escribi=C3=B3: >>>=20 >>> On 23/09/2020 11:24, Rob Wilton (rwilton) wrote: >>>> Hi Rafa, >>>>=20 >>>> Thanks for replying with the extra background information. >>>>=20 >>>> It seems like renaming the modules, as you propose for the -09 = version, is the pragmatic path forward here. >>>=20 >>> And the namespace and the YANG prefix IMHO. Having ike as a prrefix = for a module which is not the 'ike' module I see as a source of = confusion. If this is nsf specific, then I would suggest nsfike although = nsfikeless then seems a bit long. >>>=20 >>> Tom Petch >>>=20 >>>> Regards, >>>> Rob >>>>=20 >>>>=20 >>>> From: Rafa Marin-Lopez > >>>> Sent: 23 September 2020 10:29 >>>>=20 >>>> Hi Rob, (Chris): >>>>=20 >>>> Thank you very much for your answers. Please see our comments = inline. >>>>=20 >>>>=20 >>>> El 22 sept 2020, a las 17:38, Rob Wilton (rwilton) = >> = escribi=C3=B3: >>>>=20 >>>> Hi Rafa, >>>>=20 >>>> Thanks for getting back to me. >>>>=20 >>>> Yes, changing the name of the module is an okay, if not ideal, = resolution. But I appreciate that you also want to be done with this = work. >>>>=20 >>>> Correct, especially at this point of time. We have been discussing = this I-D for a long time. There was a consensus in the WG. I2NSF WG = chairs can comment about this. In our opinion, the changes that need to = be applied are major changes from what it was approved in the WG. = However, this is coming in the =E2=80=9Clast minute=E2=80=9D and we feel = this is not merely moving a few lines from here to there. We need to = understand the impact of this. Therefore, it is not so trivial as it may = seem. See below. >>>>=20 >>>> But I would like to check: My understanding is that the changes = that Chris is proposing are pretty small. I.e. move the SA structure = under ipsec-common, and put it under a YANG feature. Are you sure that = it is impractical to accommodate this change which would allow a single = ipsec module to be shared and extended via YANG augmentations? >>>>=20 >>>> In the context of our I-D, if we move SAD structure to = ipsec-common, what we are meaning is that IPsec SA configuration data = (setting values to the SAD structure) are common to the IKE case and the = IKE-less cases, which are not. It is confusing. Moreover, the usage of = feature means that, after all, this =E2=80=9Ccommon=E2=80=9D is not = =E2=80=9Ccommon=E2=80=9D to both cases IKE case and IKE-less. Again, it = seems confusing. In the IKE case, the SDN/I2NSF controller does not = configure the SAD at all but the IKE implementation in the NSF. In our = opinion, in order to properly add this IPsec SA operational state to the = IKE case we should include operational data about the IPsec SAs (config = false) to the ietf-ipsec-ike. Alternatively, we have certain operational = data (ro) in the SAD structure in the IKE-less case. If only those are = moved to the common part should be ok but we think it does not solve the = problem. >>>>=20 >>>> Therefore it is not only an implementation aspect. >>>>=20 >>>> As you may observe, our discussion is taking into account there is = an I2NSF Controller and we have two cases IKE case and IKE-less case, = that have been discussed in the WG. The YANG model in the I-D has tried = to reflect this discussion. It was never the intention to provide a = general YANG model for IPsec. >>>>=20 >>>> Best Regards. >>>>=20 >>>> Thanks, >>>> Rob >>>>=20 >>>> From: Rafa Marin-Lopez >> >>>> Sent: 22 September 2020 14:05 >>>> Subject: Re: [yang-doctors] Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08 >>>>=20 >>>> Dear Rob: >>>>=20 >>>> Apologies for our delayed answer. We are now working in the = revision to submit v09 by compiling all the comments. >>>>=20 >>>> As you mentioned, we want to avoid any further delay. As we = mentioned to Chris in the past (i2nsf mailing list), we do not have any = problem to include some additional text (e.g. =E2=80=9C-sdn-" in the = module names). Therefore, Rob, we agree with your point of view about = this. >>>>=20 >>>> In summary, we are working in the next revision v09, and our idea = to address Chris=E2=80=99 comments was to include -sdn- to the module = names. >>>>=20 >>>> We hope this is fine. >>>>=20 >>>> Best regards. >>>>=20 >>>>=20 >>>>=20 >>>> El 22 sept 2020, a las 13:56, Rob Wilton (rwilton) = >> escribi=C3=B3: >>>>=20 >>>> Hi draft authors, Chris, >>>>=20 >>>> Can we also please try and close on this issue raised by Chris. >>>>=20 >>>> Chris, I don=E2=80=99t think that there is any great way to solve = this issue using YANG features, but presumably the constraint could be = enforced with a must statement, or groupings could be used to copy parts = of the ipsec structure into an sdn specific ipsec tree structure. >>>>=20 >>>> I understand that there isn't any great desire to delay these = drafts by trying to generalize the ipsec YANG model contained within it. = However, I think that means that the modules should have "-sdn-" in = their names to indicate that they are intended specifically for the SDN = use case, and should not be confused with the more generic ipsec YANG = modules that have been proposed. >>>>=20 >>>> Regards, >>>> Rob >>>>=20 >>>> -----Original Message----- >>>> From: yang-doctors >> On Behalf Of Christian >>>> Hopps >>>> Sent: 24 August 2020 18:08 >>>>=20 >>>> [adding in ipsec@] >>>>=20 >>>> Hi, >>>>=20 >>>> This draft was discussed in ipsecme at the last IETF, and there was = a >>>> desire to look closer at a couple changes that would make these = models >>>> usable by ipsec generally rather than only for SDNs. Otherwise we = will end >>>> up with 2 models that look very similar and duplicate almost all = the >>>> functionality. This was going to be done during the next yang = doctor >>>> review, but it looks like that happened in the meantime (ships in = the >>>> night). >>>>=20 >>>> At minimum the module names should include "-sdn-" if no other = changes are >>>> made to indicate that they are only for sdn use; however, this is = not the >>>> optimal solution. >>>>=20 >>>> A better solution would be to move the containers currently under = ikeless >>>> (for SA and Policy databases) under ipsec-common. >>>>=20 >>>> The feedback I received from the authors was that the SDN = controllers >>>> didn't care about the actual SAs and policies when using IKE so = they >>>> didn't want to require someone implementing ike+common modules to = have to >>>> support them. >>>>=20 >>>> The YANG question I suppose is, is there an easy way to move these >>>> containers from ipsec-ikeless to ipsec-common, but still allow for = them to >>>> be empty and/or unimplemented for the SDN IKE use case? If they = were made >>>> features, is there a proper YANG way to indicate that if the = ikeless >>>> module is present then those features must also be supported thus = matching >>>> the functionality as defined by the current draft? >>>>=20 >>>> Thanks, >>>> Chris. >>>>=20 >>>> On Aug 24, 2020, at 10:37 AM, Martin Bj=C3=B6rklund via Datatracker >>>> >> wrote: >>>>=20 >>>> Reviewer: Martin Bj=C3=B6rklund >>>> Review result: Ready with Nits >>>>=20 >>>> I did an early YANG Doctor's review of this draft. Most of my >>>> comments then have been addressed in this version. >>>>=20 >>>> Comments: >>>>=20 >>>> o As I wrote in my early review, the RFC editor enforces a common >>>> format of YANG modules, so it is better to adhere to this format >>>> before sending the draft to the RFC editor. Use >>>>=20 >>>> pyang -f yang --yang-line-length 69 >>>>=20 >>>> to get a consistent look-and-feel for your module. >>>>=20 >>>> (You will have to manually re-flow description statements after >>>> this.) >>>>=20 >>>>=20 >>>> o There are some leafs that are optional in the model, but w/o a >>>> default value and w/o an explanation of what happens if that leaf >>>> is not set. You should find those and either make them mandatory, >>>> add a default value, or explain what it means when it isn't set. >>>> As an example, >>>> /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret >>>> is optional. I suspect that this leaf needs to be mandatory. >>>> Another example is the leaf espencap. >>>>=20 >>>>=20 >>>> /martin >>>>=20 ------------------------------------------------------- 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=_E0528C43-7F93-4AFB-97BB-14715EB47D2D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Tom:

Please see our = comments inline:

El 28 sept 2020, a las 11:33, = tom petch <daedulus@btconnect.com> escribi=C3=B3:

On = 28/09/2020 10:01, Rafa Marin-Lopez wrote:
Hi Rob, Tom:

Renaming the modules sounds reasonable. With regard to have a = different prefix, it is also ok. Perhaps the easiest way is to solve = this is the following: instead of using -sdn- we could include -i2nsf- = so we would have: ietf-i2nsf-common, ietf-i2nsf-ike, and = ietf-i2nsf-ikeless. This would mean that this is in the context of i2nsf = wg.

What do you think?

Ok with -ike and = -ikeless

Great.

but I would not use = ietf-i2nsf-common the reason being that there is an awful lot in common = across the different i2nsf I-D that with hindsight would have made an = excellent common i2nsf module and may be will in future if these modules = get revised.

We agree.
Other WG have created = 'common' or 'types' modules, with more of the latter and then = abbreviated that to 't' or 'c' so perhaps ietf-i2nsf-iket, or -ikec.

Ok = about ietf-i2nsf-ikec.


Prefix ahould be short so something like nsfike, nsfikeless = (longer than I would like - nsfiken?) and nsfiket, or nsfikec.

For = the prefix to the common module 

prefix "nsfikec";


For the prefix to the = ietf-i2nsf-ike, nsfike seems to refer to IKE case , which is = good.

prefix = "nsfike=E2=80=9D; 

For the = prefix to the ietf-i2nsf-ikeless, nsfikeless (a shorter one could be = nsfikels but we do not know if that is acceptable) has a clear meaning = and it is coherent with the rest of the names. I think we can live with = a few letters more.  

Is this = acceptable?

Best Regards.


Tom Petch

El 23 sept 2020, a las 12:45, tom petch <daedulus@btconnect.com <mailto:daedulus@btconnect.com>> escribi=C3=B3:

On 23/09/2020 11:24, Rob Wilton (rwilton) = wrote:
Hi Rafa,

Thanks for replying with the extra background = information.

It seems like renaming the = modules, as you propose for the -09 version, is the pragmatic path = forward here.

And the = namespace and the YANG prefix IMHO.  Having ike as a prrefix for a = module which is not the 'ike' module I see as a source of confusion. If = this is nsf specific, then I would suggest nsfike although nsfikeless = then seems a bit long.

Tom Petch

Regards,Rob


From: Rafa = Marin-Lopez <rafa@um.es = <mailto:rafa@um.es>>
Sent: 23 = September 2020 10:29

Hi Rob, (Chris):

Thank you very much for your answers. Please = see our comments inline.


El = 22 sept 2020, a las 17:38, Rob Wilton (rwilton) <rwilton=3D40cisco.com@dmarc.ietf.org <mailto:rwilton=3D40cisco.com@dmarc.ietf.org><mailto:rwilton=3D40cisco.com@dmarc.ietf.org <mailto:rwilton=3D40cisco.com@dmarc.ietf.org>>> = escribi=C3=B3:

Hi Rafa,

Thanks for getting back to me.

Yes, changing the name of the module is an okay, if not = ideal, resolution.  But I appreciate that you also want to be done = with this work.

Correct, especially at this = point of time. We have been discussing this I-D for a long time. There = was a consensus in the WG. I2NSF WG chairs can comment about this. In = our opinion, the changes that need to be applied are major changes from = what it was approved in the WG. However, this is coming in the =E2=80=9Cla= st minute=E2=80=9D and we feel this is not merely moving a few lines = from here to there. We need to understand the impact of this. Therefore, = it is not so trivial as it may seem. See below.

But I would like to check:  My understanding is that the = changes that Chris is proposing are pretty small.  I.e. move the SA = structure under ipsec-common, and put it under a YANG feature.  Are = you sure that it is impractical to accommodate this change which would = allow a single ipsec module to be shared and extended via YANG = augmentations?

In the context of our I-D, = if we move SAD structure to ipsec-common, what we are meaning is that = IPsec SA configuration data (setting values to the SAD structure) are = common to the IKE case and the IKE-less cases, which are not. It is = confusing. Moreover, the usage of feature means that, after all, this = =E2=80=9Ccommon=E2=80=9D is not =E2=80=9Ccommon=E2=80=9D to both cases = IKE case and IKE-less. Again, it seems confusing. In the IKE case, the = SDN/I2NSF controller does not configure the SAD at all but the IKE = implementation in the NSF. In our opinion, in order to properly add this = IPsec SA operational state to the IKE case we should include operational = data about the IPsec SAs (config false) to the ietf-ipsec-ike. = Alternatively, we have certain operational data (ro) in the SAD = structure in the IKE-less case. If only those are moved to the common = part should be ok but we think it does not solve the problem.

Therefore it is not only an implementation = aspect.

As you may observe, our discussion = is taking into account there is an I2NSF Controller and we have two = cases IKE case and IKE-less case, that have been discussed in the WG. = The YANG model in the I-D has tried to reflect this discussion. It was = never the intention to provide a general YANG model for IPsec.

Best Regards.

Thanks,
Rob

From: = Rafa Marin-Lopez <rafa@um.es <mailto:rafa@um.es><mailto:rafa@um.es <mailto:rafa@um.es>>>
Sent: 22 = September 2020 14:05
Subject: Re: [yang-doctors] = Yangdoctors last call review of = draft-ietf-i2nsf-sdn-ipsec-flow-protection-08

Dear Rob:

Apologies for our = delayed answer. We are now working in the revision to submit v09 by = compiling all the comments.

As you = mentioned, we want to avoid any further delay. As we mentioned to Chris = in the past (i2nsf mailing list), we do not have any problem to include = some additional text (e.g. =E2=80=9C-sdn-" in the module names). = Therefore, Rob, we agree with your point of view about this.

In summary, we are working in the next = revision v09, and our idea to address Chris=E2=80=99 comments was to = include -sdn- to the module names.

We hope = this is fine.

Best regards.


El 22 sept 2020, a las 13:56, = Rob Wilton (rwilton) <rwilton@cisco.com <mailto:rwilton@cisco.com><mailto:rwilton@cisco.com = <mailto:rwilton@cisco.com>>> escribi=C3=B3:

Hi draft authors, Chris,

Can we also please try and close on this issue raised by = Chris.

Chris, I don=E2=80=99t think that = there is any great way to solve this issue using YANG features, but = presumably the constraint could be enforced with a must statement, or = groupings could be used to copy parts of the ipsec structure into an sdn = specific ipsec tree structure.

I understand = that there isn't any great desire to delay these drafts by trying to = generalize the ipsec YANG model contained within it.  However, I = think that means that the modules should have "-sdn-" in their names to = indicate that they are intended specifically for the SDN use case, and = should not be confused with the more generic ipsec YANG modules that = have been proposed.

Regards,
Rob

-----Original = Message-----
From: yang-doctors <yang-doctors-bounces@ietf.org <mailto:yang-doctors-bounces@ietf.org><mailto:yang-doctors-bounces@ietf.org <mailto:yang-doctors-bounces@ietf.org>>> On = Behalf Of Christian
Hopps
Sent: 24 August = 2020 18:08

[adding in ipsec@]

Hi,

This draft = was discussed in ipsecme at the last IETF, and there was a
desire to look closer at a couple changes that would make = these models
usable by ipsec generally rather than only = for SDNs. Otherwise we will end
up with 2 models that look = very similar and duplicate almost all the
functionality. = This was going to be done during the next yang doctor
review, but it looks like that happened in the meantime = (ships in the
night).

At = minimum the module names should include "-sdn-" if no other changes = are
made to indicate that they are only for sdn use; = however, this is not the
optimal solution.
A better solution would be to move the containers currently = under ikeless
(for SA and Policy databases) under = ipsec-common.

The feedback I received from = the authors was that the SDN controllers
didn't care about = the actual SAs and policies when using IKE so they
didn't = want to require someone implementing ike+common modules to have to
support them.

The YANG question = I suppose is, is there an easy way to move these
containers = from ipsec-ikeless to ipsec-common, but still allow for them to
be empty and/or unimplemented for the SDN IKE use case? If = they were made
features, is there a proper YANG way to = indicate that if the ikeless
module is present then those = features must also be supported thus matching
the = functionality as defined by the current draft?

Thanks,
Chris.

On = Aug 24, 2020, at 10:37 AM, Martin Bj=C3=B6rklund via Datatracker
<noreply@ietf.org <mailto:noreply@ietf.org><mailto:noreply@ietf.org = <mailto:noreply@ietf.org>>> wrote:

Reviewer: Martin Bj=C3=B6rklund
Review result: Ready with Nits

I = did an early YANG Doctor's review of this draft.  Most of my
comments then have been addressed in this version.

Comments:

o =  As I wrote in my early review, the RFC editor enforces a common
 format of YANG modules, so it is better to adhere to = this format
 before sending the draft to the RFC = editor.  Use

   pyang = -f yang --yang-line-length 69 <FILE>

=  to get a consistent look-and-feel for your module.
 (You will have to manually re-flow description = statements after
 this.)


o  There are some leafs that are optional = in the model, but w/o a
 default value and w/o an = explanation of what happens if that leaf
 is not = set.  You should find those and either make them mandatory,
 add a default value, or explain what it means when it = isn't set.
 As an example,
=  /ipsec-ike/pad/pad-entrypeer-authenticatin/pre-shared/secret
 is optional.  I suspect that this leaf needs to = be mandatory.
 Another example is the leaf = espencap.


/martin


-------------------------------------------------------
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=_E0528C43-7F93-4AFB-97BB-14715EB47D2D-- From nobody Wed Sep 30 09:25:57 2020 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B12B23A0B20; Wed, 30 Sep 2020 09:25:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.17.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ipsec@ietf.org Message-ID: <160148315262.3746.2680691950315422865@ietfa.amsl.com> Date: Wed, 30 Sep 2020 09:25:52 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-iptfs-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Sep 2020 16:25:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions WG of the IETF. Title : IP Traffic Flow Security Author : Christian Hopps Filename : draft-ietf-ipsecme-iptfs-02.txt Pages : 26 Date : 2020-09-30 Abstract: This document describes a mechanism to enhance IPsec traffic flow security by adding traffic flow confidentiality to encrypted IP encapsulated traffic. Traffic flow confidentiality is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-iptfs/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-iptfs-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-iptfs-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/