From nobody Thu Jun 1 16:17:43 2017 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 24BD5129449 for ; Thu, 1 Jun 2017 16:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 KxEV9pBFeb3A for ; Thu, 1 Jun 2017 16:17:41 -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 6BBE712420B for ; Thu, 1 Jun 2017 16:17:41 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wf3Ch4WTMz36S; Fri, 2 Jun 2017 01:17:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1496359056; bh=Vg+wZOSt1H1XOEgu4LOnVy+G6DDvJYF+kHumVR/XRdY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=huWKff8kRyMtCMiVI6pY7S0KZH4JjeFlD45ueWC/y+9oqmOhkoLR+zS6vs+NBb4A9 ThC2wSfbDoh2Hg3aExZB9usXxqy025SruDu3qX/hAyVQNGCG94IuiOJu8IH8zBI8E2 vsa1iKlbf3VSFwDzSdyN1/n+zjJ/IoiCQFYAbVL8= 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 NcuXjO6n1Sxw; Fri, 2 Jun 2017 01:17:33 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 2 Jun 2017 01:17:32 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 5CACF414CCC; Thu, 1 Jun 2017 19:17:31 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 5CACF414CCC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 403BC41799A5; Thu, 1 Jun 2017 19:17:31 -0400 (EDT) Date: Thu, 1 Jun 2017 19:17:31 -0400 (EDT) From: Paul Wouters To: Tommy Pauly cc: IPsecME WG In-Reply-To: <34C32236-D200-421F-AF6E-F953DA79A869@apple.com> Message-ID: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> <22793.40707.624092.66793@fireball.acr.fi> <34C32236-D200-421F-AF6E-F953DA79A869@apple.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: [IPsec] Should draft-ietf-ipsecme-tcp-encaps-10 update 7296 ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 23:17:43 -0000 On Wed, 31 May 2017, Tommy Pauly wrote: > I've posted a new version of the draft that incorporates the changes discussed in this thread. Please review! > > https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10 I just noticed this in RFC 7296: However, if a NAT is detected, both devices MUST use UDP encapsulation for ESP. I'm not sure if this one sentence really qualifies as this draft needing a formal "Updates 7296", but it currently does not seem to do that. Paul From nobody Thu Jun 1 16:35:05 2017 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 0A3DA126CD8 for ; Thu, 1 Jun 2017 16:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1hz91885qNM for ; Thu, 1 Jun 2017 16:35:02 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 106F612945B for ; Thu, 1 Jun 2017 16:35:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1496360100; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=jOVpN2JVJXePFnIAeTOImoer5/xxTG8gWN+4HDjRdDE=; b=jxnRySUx5uRKxLZMvYGGiVs4G6+QGt66bskBPSobjeK6YRYR7pDJXCZFMkouZaME kOR0KcY5CbhYfRxNVC1nxb82s5ME/j/Tkpjmpd9aAGLhcuLMH+sdmTGmp0mYPSRM WFx4Jl0yRwWuB1h6VsBQNvZHPqluNKsfKOSsehZv4VhsGF1iWaxWoR26Wg4cgd5V u7lM1hviDa+nChbgBbhVub+7H8e4OleQKaNDL4bzi9Y51XIY2Yn8k0kCwADduKtV zq5VF3mCmlikymAO2HiHFWMdxxEgnMdbLjLNocQ2HAm1vc5Z6AS9pRQsC8hwJepz ip8XPxaUMKXJahPpP0Y6EQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 24.93.07949.4A4A0395; Thu, 1 Jun 2017 16:35:00 -0700 (PDT) X-AuditID: 11973e16-0c7789a000001f0d-81-5930a4a4a057 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay3.apple.com (Apple SCV relay) with SMTP id D7.E8.15148.4A4A0395; Thu, 1 Jun 2017 16:35:00 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.75.119] (unknown [17.153.75.119]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OQW00EUQ6UBMO20@nwk-mmpp-sz12.apple.com>; Thu, 01 Jun 2017 16:35:00 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Thu, 01 Jun 2017 16:34:58 -0700 Cc: IPsecME WG Content-transfer-encoding: quoted-printable Message-id: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> <22792.20148.255067.132946@fireball.acr.fi> <82B5E72F-C518-420B-B941-E4CE4DD1BF87@kuehlewind.net> <22792.31378.769444.232365@fireball.acr.fi> <78A72CF3-E011-4E8D-9F66-63C7918A8236@kuehlewind.net> <22793.40707.624092.66793@fireball.acr.fi> <34C32236-D200-421F-AF6E-F953DA79A869@apple.com> To: Paul Wouters X-Mailer: Apple Mail (2.3430.2) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOLMWRmVeSWpSXmKPExsUi2FAYrLtkiUGkwbuTuhb7t7xgs3h/6xKT A5PHkiU/mTy+z2MKYIrisklJzcksSy3St0vgylhwbiJjwTL2iiUbFRsYn7F2MXJySAiYSFxq P8LSxcjFISSwmkli+tM3jDCJBbtvMUIkDjFKrLu2D6yDV0BQ4sfke0AdHBzMAuoSU6bkQtRM ZJKY+qoJLC4sICGxeU8iSLmwgJNEU88BFhCbTUBF4vi3DcwgNqeAq8St67PBylkEVCWaDvOA hJkF5CV6/29khLC1JZ68u8AKUsIrYCNx5XUhxKYf7BLrtveDjRQRUJSYdOYRC8TJ8hLbnl5n AymSEFjCJrFi/jfGCYzCs5BcPQvh6llIVixgZF7FKJSbmJmjm5lnrpdYUJCTqpecn7uJERTS 0+3EdjA+XGV1iFGAg1GJh9dCwSBSiDWxrLgy9xCjNAeLkjivUQJQSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA2PW9EqRg88Lizfwnoo9sWf9vcbYUpbfyxlXS67qSms7kXxVS/z9uZtX9f5M lOna2Piv9NHz1DuztqwL5Pgm81TG4LRkxAElxZh/Zx79Dz97634LO1/FvaVWs7cEMU35YMCV rPsh1CApK68x2Fws/nTe2dTcgLdLGjbxV0kHqn4LPTg/pCfG+4sSS3FGoqEWc1FxIgAYSY/i SgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42IRbCg+o7tkiUGkwYmVMhb7t7xgs3h/6xKT A5PHkiU/mTy+z2MKYIrisklJzcksSy3St0vgylhwbiJjwTL2iiUbFRsYn7F2MXJySAiYSCzY fYuxi5GLQ0jgEKPEumv7wBK8AoISPybfY+li5OBgFlCXmDIlF6JmIpPE1FdNYHFhAQmJzXsS QcqFBZwkmnoOsIDYbAIqEse/bWAGsTkFXCVuXZ8NVs4ioCrRdJgHJMwsIC/R+38jI4StLfHk 3QVWkBJeARuJK68LITb9YJdYt70fbKSIgKLEpDOPWCBOlpfY9vQ62wRGgVlIDp2FcOgsJFMX MDKvYhQoSs1JrDTWSywoyEnVS87P3cQIDsHC4B2Mf5ZZHWIU4GBU4uG1UDCIFGJNLCuuzAWG BAezkgjvuvlAId6UxMqq1KL8+KLSnNTiQ4xVQK9MZJYSTc4HxkdeSbyhiYmBibGxmbGxuYk5 VYSVxHkPeQFtFkhPLEnNTk0tSC2CWc7EwSnVwBjY8fLEBiYLb69vcl0mL+/0sUdHn3v7a0nR 89URc2Y9XiIq/Kjyc9H5plU5N5/uYikJCZhX0up35unpV/o9sof0o+pPhT6V0nw/Zbf+lSvn nW+2121uLnn44jHTjCPZjLZWG4UWeOzTN/F8l5x5ZtWMmJK0ikXTPmv/y5yW+olfvere5fyb 9uuUWIozEg21mIuKEwG1GfMQnAIAAA== Archived-At: Subject: Re: [IPsec] Should draft-ietf-ipsecme-tcp-encaps-10 update 7296 ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jun 2017 23:35:04 -0000 > On Jun 1, 2017, at 4:17 PM, Paul Wouters wrote: >=20 > On Wed, 31 May 2017, Tommy Pauly wrote: >=20 >> I've posted a new version of the draft that incorporates the changes = discussed in this thread. Please review! >> = https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-tcp-encaps-10 >=20 > I just noticed this in RFC 7296: >=20 > However, if a NAT is detected, both devices MUST use UDP = encapsulation for ESP. >=20 > I'm not sure if this one sentence really qualifies as this draft = needing > a formal "Updates 7296", but it currently does not seem to do that. Technically, one should only do TCP encapsulation if UDP couldn't go = through at all=E2=80=94so you couldn't even get the IKE_SA_INIT response = to do NAT detection. That means that we aren't in this case. However, = I'm happy to add a line to clarify this if we'd prefer that =3D) Thanks, Tommy >=20 > Paul From nobody Wed Jun 14 08:45:50 2017 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 1DD95129BA9; Wed, 14 Jun 2017 08:45:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.54.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149745514411.14108.4314599719251387753.idtracker@ietfa.amsl.com> Date: Wed, 14 Jun 2017 08:45:44 -0700 Archived-At: Subject: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-?= =?utf-8?q?ietf-ipsecme-tcp-encaps-10=3A_=28with_COMMENT=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Jun 2017 15:45:44 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss. I've only checked the diff but that seems fine now :-) Two more tiny things that I would recommend to change but can be done by the RFC editor: OLD "Implementations SHOULD favor using direct ESP or UDP encapsulation over TCP encapsulation whenever possible." NEW "Implementations SHOULD use direct ESP or UDP encapsulation over TCP encapsulation whenever possible." OLD "TCP Responders should be careful to ensure that the stream prefix "IKETCP" uniquely identifies incoming streams as ones that use the TCP encapsulation protocol, and they are not running any other protocols on the same listening port that could conflict with this." NEW "TCP Responders should be careful to ensure that the stream prefix "IKETCP" uniquely identifies incoming streams as ones that use the TCP encapsulation protocol, and MUST not run any other protocols on the same listening port that could conflict with this." From nobody Mon Jun 19 07:45:33 2017 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 D5E001270A7; Mon, 19 Jun 2017 07:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 X46XKZc6JSMt; Mon, 19 Jun 2017 07:45:12 -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 222D4131505; Mon, 19 Jun 2017 07:45:08 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wrv000pW8z1bS; Mon, 19 Jun 2017 16:45:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1497883504; bh=e8b5pflApT/2CkbbEJDgiwfMO0zkT/z2La+rUEmTeAs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=QaP3vxqe2eYPMpglI7gHQWHP0CC1vi5yxNMoDi2ENN0ox6h1pNkSXD6Ggn7LBuXlb wlrVRUHO0i8g7zPF/G4YGNs5XRuKV4qmTykyEmEwLI+HbZyQX+8bVYJfUo5iw7xiXH bGIKTv9MHoebCvfF2bJR5fw6GnDbqo3cV+c5vGHE= 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 zuWtq0mTmf-6; Mon, 19 Jun 2017 16:45:02 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 19 Jun 2017 16:45:01 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C674C353479; Mon, 19 Jun 2017 10:45:00 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C674C353479 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B07E8421253B; Mon, 19 Jun 2017 10:45:00 -0400 (EDT) Date: Mon, 19 Jun 2017 10:45:00 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: draft-ietf-ipsecme-rfc7321bis@ietf.org, Ben Campbell , ipsecme-chairs@ietf.org, ipsec@ietf.org, The IESG , david.waltermire@nist.gov In-Reply-To: <22739.38728.808538.27709@fireball.acr.fi> Message-ID: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <22739.38728.808538.27709@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 14:45:24 -0000 On Thu, 23 Mar 2017, Tero Kivinen wrote: > Paul Wouters writes: >>> -3: I wonder why "... is not to be used..." is not "... MUST NOT be >>> used...". But the section goes on to say if you do it anyway, you MUST >>> NOT use certain cryptosuites. So, does "... is not to be used..." mean >>> "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL" >>> sort of requirements? >> >> It is indeed. I think a SHOULD NOT would actually be appropriate ? > > We do not want to make the implementation of the manual keying MUST > NOT, as it is still useful in testing and similar situations, but we > do not want anybody using it in any real world use cases. As this > document is mostly about the implementation and tries to stay out from > the issues about what should be used (as explained in the 2nd > paragraph of the section 1.3). > > On the other hand section 1.3 is really about the use of the manual > keying, not about the implementation of manual keying, so that > confuses things (we do have some other cases were we say things DES > MUST NOT be used). > > I think the text needs to be clarified about this bit more, especially > we do not want to say that ENCR_AES_CBC MUST be used, as there are > other algorithms which can also be used (MUST be used would indicate > no other algorithm is possible). Here is a suggestion: OLD text: 3. Manual Keying Manual Keying is not to be used as it is inherently dangerous. Without any keying protocol, it does not offer Perfect Forward Secrecy ("PFS") protection. Deployments tend to never be reconfigured with fresh session keys. It also fails to scale and keeping SPI's unique amongst many servers is impractical. This document was written for deploying ESP/AH using IKE ([RFC7296]) and assumes that keying happens using IKEv2. If manual keying is used anyway, ENCR_AES_CBC MUST be used, and ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be used as these algorithms require IKE. NEW text: 3. Manual Keying Manual Keying SHOULD NOT be used as it is inherently dangerous. Without any keying protocol, it does not offer Perfect Forward Secrecy ("PFS") protection. Without IKE, another entity needs to ensure refreshing of session keys, tracking SPI uniqueness and ensuring nonces or IVs are not used more then once. This document was written for deploying ESP/AH using IKE ([RFC7296]) and assumes that keying happens using IKE version 2 or higher. If manual keying is used anyway, AEAD algorithms MUST NOT be used, as these algorithms require additional input provided by IKE and are compromised if a counter is accidentally re-used, such as when a counter overflows, or when a device reboots without remembering the previously used counters. As of publication of this document, ENCR_AES_CBC is the only non-AEAD Mandatory-To-Implement encryption algorithm suitable for Manual Keying. >>> - Table in section 6: >>> I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't see >>> anything in the text to explain the "MUST" part--did I miss something? >> >> >> First paragraph under the table: >> >> AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The >> only reason NULL is acceptable is when authenticated encryption >> algorithms are selected from Section 5. In all other cases, NULL >> MUST NOT be selected. > > It does not make it easier that there is typo in that paragraph, and > it talks about NULL, when it should be talking about AUTH_NONE... Queued up (NULL -> AUTH_NONE) Paul From nobody Mon Jun 19 08:00:58 2017 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 D5905131516; Mon, 19 Jun 2017 08:00:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , ekr@rtfm.com, ipsecme-chairs@ietf.org, kivinen@iki.fi, Tero Kivinen , ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149788444987.10738.3725836693927554368.idtracker@ietfa.amsl.com> Date: Mon, 19 Jun 2017 08:00:49 -0700 Archived-At: Subject: [IPsec] Protocol Action: 'TCP Encapsulation of IKE and IPsec Packets' to Proposed Standard (draft-ietf-ipsecme-tcp-encaps-10.txt) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 15:00:50 -0000 The IESG has approved the following document: - 'TCP Encapsulation of IKE and IPsec Packets' (draft-ietf-ipsecme-tcp-encaps-10.txt) as Proposed Standard This document is the product of the IP Security Maintenance and Extensions Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ Technical Summary This document describes a method to transport IKE and IPsec packets over a TCP connection for traversing network middleboxes that may block IKE negotiation over UDP. This method, referred to as TCP encapsulation, involves sending both IKE packets for Security Association establishment and ESP packets over a TCP connection. This method is intended to be used as a fallback option when IKE cannot be negotiated over UDP. Working Group Summary The draft came to the working group out of a need to standardize a push towards adding TCP support for IKE that was coming from several sources (VPN vendors and cellular carriers using IKE for telephony services). Some of the major changes that the WG made early on compared to existing proposals from external bodies was to remove the reliance on encapsulating IKE traffic within TLS. Much of the other WG discussion later on in review revolved around how to best manage the connection establishment and teardown transitions. Document Quality There are several early implementations of the protocol that were made to test interoperability (notably, Cisco and Apple). The draft also received input from vendors that have previously deployed proprietary versions of IPsec over TCP. Personnel The Document Shepherd is Tero Kivinen. The responsible ADs are Kathleen Moriarty (with Eric Rescorla taking custody for IESG revies). From nobody Mon Jun 19 08:17:37 2017 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 9A67913152E for ; Mon, 19 Jun 2017 08:17:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 muFMZHIInLEW for ; Mon, 19 Jun 2017 08:17:33 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 00575128BC8 for ; Mon, 19 Jun 2017 08:17:32 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l75so41724261ywc.3 for ; Mon, 19 Jun 2017 08:17:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qdULphOEt1tlB2T9fGQH3S1l90Q7LMra1lGUPrOwgA8=; b=TuraigA5eNl0IARAWSagd+rIrVJncjpgSZ71vQWqFrVDrFYGBHKKmtIVu3TaurGJ8U 87cdUNJ7M3vVoFWKxWPF0GF+qZm/hBW/8Sv6BEXLSjYOCbnP8M4SSJr8lyBM0oU5Fr18 UoL1Lyfo5YtIMjevyRkG9dyHX5SmtmgPsAK50+41e53c5d7Laz3RMINfZkXW/SCu03/e ZNvQD4b3apYaKv3ZyeuQd4HxCgrbKDg6C4i3L+0Eprme2c+iz9z94T7lXNLherHNVQ2f F9a18/KL5pbKYeYWrERxNDcMMBSN36eMk/QCiqC1+0WpRU13GQPnZCpd6C/kxIk/FSAs SC6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qdULphOEt1tlB2T9fGQH3S1l90Q7LMra1lGUPrOwgA8=; b=oMqnsmVl1n58CW2aInPoFvBNtAT3bY75l9vyED27NZBzDfCTrewhJZQKFN82Gk3wcT hx7+HwFRqW/jDMmxN8oChv8lMaAX+GQrB0ejaP7/zKraU72xwUdJHY4PmAJdiwbCkulc sWrR8ZeXDoi0cXM4CtHSORKGFFHW1/CTiPocCeg62Q32iRnGSBJN1BOqqsPiVkQhlrod BcSi3kFP1CPZbPeW/e1yttywSTCym/iVdbr76vWpoD3XyV7qlbFJfHpoQrfKsLDMOsMx ViGvNqnd+ww8+QFssrtW4SCwd0iOzZxSNxFJcIxKrIshCmCgCxTYJAC+GWDC3pMy/S39 mu0g== X-Gm-Message-State: AKS2vOy0e/QK3ufWBMb9Asswj+iJI3vg+8bZtqFsDU+j5XaSrtV+6VY3 98AAZf86+hg4+Xg9boa2S0VSAfdQbxQhf+c= X-Received: by 10.129.71.213 with SMTP id u204mr5168379ywa.270.1497885452202; Mon, 19 Jun 2017 08:17:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Mon, 19 Jun 2017 08:16:51 -0700 (PDT) In-Reply-To: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <22739.38728.808538.27709@fireball.acr.fi> From: Eric Rescorla Date: Mon, 19 Jun 2017 08:16:51 -0700 Message-ID: To: Paul Wouters Cc: Tero Kivinen , draft-ietf-ipsecme-rfc7321bis@ietf.org, Ben Campbell , ipsecme-chairs@ietf.org, IPsecME WG , The IESG , david.waltermire@nist.gov Content-Type: multipart/alternative; boundary="001a114c6ec04b62fb055251a287" Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 15:17:36 -0000 --001a114c6ec04b62fb055251a287 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 19, 2017 at 7:45 AM, Paul Wouters wrote: > On Thu, 23 Mar 2017, Tero Kivinen wrote: > > Paul Wouters writes: >> >>> -3: I wonder why "... is not to be used..." is not "... MUST NOT be >>>> used...". But the section goes on to say if you do it anyway, you MUST >>>> NOT use certain cryptosuites. So, does "... is not to be used..." mean >>>> "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL" >>>> sort of requirements? >>>> >>> >>> It is indeed. I think a SHOULD NOT would actually be appropriate ? >>> >> >> We do not want to make the implementation of the manual keying MUST >> NOT, as it is still useful in testing and similar situations, but we >> do not want anybody using it in any real world use cases. As this >> document is mostly about the implementation and tries to stay out from >> the issues about what should be used (as explained in the 2nd >> paragraph of the section 1.3). >> >> On the other hand section 1.3 is really about the use of the manual >> keying, not about the implementation of manual keying, so that >> confuses things (we do have some other cases were we say things DES >> MUST NOT be used). >> >> I think the text needs to be clarified about this bit more, especially >> we do not want to say that ENCR_AES_CBC MUST be used, as there are >> other algorithms which can also be used (MUST be used would indicate >> no other algorithm is possible). >> > > Here is a suggestion: > > OLD text: > > 3. Manual Keying > > Manual Keying is not to be used as it is inherently dangerous. > Without any keying protocol, it does not offer Perfect Forward > Secrecy ("PFS") protection. Deployments tend to never be > reconfigured with fresh session keys. It also fails to scale and > keeping SPI's unique amongst many servers is impractical. This > document was written for deploying ESP/AH using IKE ([RFC7296]) and > assumes that keying happens using IKEv2. > > If manual keying is used anyway, ENCR_AES_CBC MUST be used, and > ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be > used as these algorithms require IKE. > > NEW text: > > 3. Manual Keying > > Manual Keying SHOULD NOT be used as it is inherently dangerous. > Without any keying protocol, it does not offer Perfect Forward > Secrecy ("PFS") protection. Without IKE, another entity needs to > ensure refreshing of session keys, tracking SPI uniqueness and > ensuring nonces or IVs are not used more then once. This document > was written for deploying ESP/AH using IKE ([RFC7296]) and assumes > that keying happens using IKE version 2 or higher. > > If manual keying is used anyway, AEAD algorithms MUST NOT be used, > as these algorithms require additional input provided by IKE and > are compromised if a counter is accidentally re-used, such as when > a counter overflows, or when a device reboots without remembering > the previously used counters. As of publication of this document, > ENCR_AES_CBC is the only non-AEAD Mandatory-To-Implement encryption > algorithm suitable for Manual Keying. It's not AEAD that's the problem here. After all, it's perfectly possible to do AEAD with CBC-HMAC. Rather, it's CTR mode. -Ekr > > > - Table in section 6: >>>> I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't >>>> see >>>> anything in the text to explain the "MUST" part--did I miss something? >>>> >>> >>> >>> First paragraph under the table: >>> >>> AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT. The >>> only reason NULL is acceptable is when authenticated encryption >>> algorithms are selected from Section 5. In all other cases, NULL >>> MUST NOT be selected. >>> >> >> It does not make it easier that there is typo in that paragraph, and >> it talks about NULL, when it should be talking about AUTH_NONE... >> > > Queued up (NULL -> AUTH_NONE) > > Paul > > --001a114c6ec04b62fb055251a287 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 19, 2017 at 7:45 AM, Paul Wouters <paul@nohats.ca> wrote:
On Thu, 23 Ma= r 2017, Tero Kivinen wrote:

Paul Wouters writes:
-3: I wonder why "... is not to be used..." is not "... MUST= NOT be
used...". But the section goes on to say if you do it anyway, you MUST=
NOT use certain cryptosuites. So, does "... is not to be used..."= mean
"SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW = YOU WILL"
sort of requirements?

It is indeed. I think a SHOULD NOT would actually be appropriate ?

We do not want to make the implementation of the manual keying MUST
NOT, as it is still useful in testing and similar situations, but we
do not want anybody using it in any real world use cases. As this
document is mostly about the implementation and tries to stay out from
the issues about what should be used (as explained in the 2nd
paragraph of the section 1.3).

On the other hand section 1.3 is really about the use of the manual
keying, not about the implementation of manual keying, so that
confuses things (we do have some other cases were we say things DES
MUST NOT be used).

I think the text needs to be clarified about this bit more, especially
we do not want to say that ENCR_AES_CBC MUST be used, as there are
other algorithms which can also be used (MUST be used would indicate
no other algorithm is possible).

 Here is a suggestion:

OLD text:

3.=C2=A0 Manual Keying

=C2=A0 =C2=A0Manual Keying is not to be used as it is inherently dangerous.=
=C2=A0 =C2=A0Without any keying protocol, it does not offer Perfect Forward=
=C2=A0 =C2=A0Secrecy ("PFS") protection.=C2=A0 Deployments tend t= o never be
=C2=A0 =C2=A0reconfigured with fresh session keys.=C2=A0 It also fails to s= cale and
=C2=A0 =C2=A0keeping SPI's unique amongst many servers is impractical.= =C2=A0 This
=C2=A0 =C2=A0document was written for deploying ESP/AH using IKE ([RFC7296]= ) and
=C2=A0 =C2=A0assumes that keying happens using IKEv2.

=C2=A0 =C2=A0If manual keying is used anyway, ENCR_AES_CBC MUST be used, an= d
=C2=A0 =C2=A0ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT= be
=C2=A0 =C2=A0used as these algorithms require IKE.

NEW text:

3.=C2=A0 Manual Keying

Manual Keying SHOULD NOT be used as it is inherently dangerous.
Without any keying protocol, it does not offer Perfect Forward
Secrecy ("PFS") protection. Without IKE, another entity needs to<= br> ensure refreshing of session keys, tracking SPI uniqueness and
ensuring nonces or IVs are not used more then once. This document
was written for deploying ESP/AH using IKE ([RFC7296]) and assumes
that keying happens using IKE version 2 or higher.

If manual keying is used anyway, AEAD algorithms MUST NOT be used,
as these algorithms require additional input provided by IKE and
are compromised if a counter is accidentally re-used, such as when
a counter overflows, or when a device reboots without remembering
the previously used counters. As of publication of this document,
ENCR_AES_CBC is the only non-AEAD Mandatory-To-Implement encryption
algorithm suitable for Manual Keying.

It= 9;s not AEAD that's the problem here. After all, it's perfectly pos= sible to do AEAD
with CBC-HMAC. Rather, it's CTR mode.
<= div>
-Ekr
=C2=A0


- Table in section 6:
I'm boggled by the first entry being labeled "MUST/MUST NOT".= I don't see
anything in the text to explain the "MUST" part--did I miss somet= hing?


First paragraph under the table:

=C2=A0 =C2=A0 AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT= .=C2=A0 The
=C2=A0 =C2=A0 only reason NULL is acceptable is when authenticated encrypti= on
=C2=A0 =C2=A0 algorithms are selected from Section 5.=C2=A0 In all other ca= ses, NULL
=C2=A0 =C2=A0 MUST NOT be selected.

It does not make it easier that there is typo in that paragraph, and
it talks about NULL, when it should be talking about AUTH_NONE...

Queued up (NULL -> AUTH_NONE)

Paul


--001a114c6ec04b62fb055251a287-- From nobody Mon Jun 19 08:26:46 2017 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 439F0131526; Mon, 19 Jun 2017 08:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 e9HAio1eCZO6; Mon, 19 Jun 2017 08:26: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 882F4128C83; Mon, 19 Jun 2017 08:26:43 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wrvw15kxqz6G; Mon, 19 Jun 2017 17:26:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1497886001; bh=SNzc8TQkA8/cJpFa3K1pFaZ5Or4kFd0l3oVNHHjNaMc=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TKCZnTVXh9Z6Firr0GJKD5Burv6hScF4vGh2mlPRJk0Ks7OUiN4dtWP5DT74A5M4h SIv/80xpP196r6Q5fGmNlKOLr6dQjCA3nmJ2gjCg3Io4ZFaXnJq0z2ZsJJ/p9CQhRk vHUysn52gaLTCMzxeZAljQaXwAb0rnxNjqRvhPEI= 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 vdqcefXmaOnb; Mon, 19 Jun 2017 17:26:41 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 19 Jun 2017 17:26:40 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 21BE5353479; Mon, 19 Jun 2017 11:26:40 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 21BE5353479 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 1944B421253E; Mon, 19 Jun 2017 11:26:40 -0400 (EDT) Date: Mon, 19 Jun 2017 11:26:39 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: Tero Kivinen , draft-ietf-ipsecme-rfc7321bis@ietf.org, Ben Campbell , ipsecme-chairs@ietf.org, IPsecME WG , The IESG , david.waltermire@nist.gov In-Reply-To: Message-ID: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <22739.38728.808538.27709@fireball.acr.fi> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 15:26:45 -0000 On Mon, 19 Jun 2017, Eric Rescorla wrote: > If manual keying is used anyway, AEAD algorithms MUST NOT be used, > as these algorithms require additional input provided by IKE and > are compromised if a counter is accidentally re-used, such as when > a counter overflows, or when a device reboots without remembering > the previously used counters. As of publication of this document, > ENCR_AES_CBC is the only non-AEAD Mandatory-To-Implement encryption > algorithm suitable for Manual Keying. > > > It's not AEAD that's the problem here. After all, it's perfectly possible to do AEAD > with CBC-HMAC. Rather, it's CTR mode. Hmm, of course we only have CTR based AEAD's :P Ok, NEW NEW last paragraph: If manual keying is used regardless, Counter Mode AEAD algorithms MUST NOT be used, as these algorithms require additional input provided by IKE and are compromised if a counter is accidentally re-used, such as when a counter overflows, or when a device reboots without remembering the previously used counters. As of publication of this document, ENCR_AES_CBC is the only Mandatory-To-Implement encryption algorithm suitable for Manual Keying. Paul From nobody Mon Jun 19 08:41:40 2017 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 B93691293E1; Mon, 19 Jun 2017 08:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=dell.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 bXHxIbYgTroi; Mon, 19 Jun 2017 08:41:36 -0700 (PDT) Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (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 6990D12F258; Mon, 19 Jun 2017 08:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1497886678; x=1529422678; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=b2UywURb8pjAcCP2e8ZaGpMfUDOhcglWdvWx/MeJzJM=; b=QNxB6hiTwwqWbK+4YuV2xNkFQnscIcyGcZXkTyY6fb+Ue/x5bkChknk8 VPsLKvgdPiNFV89PqnPy6FFeSXqtdmr3QsOHTWiZJPABHTZeQ4cWXSwIJ q+634HcShOWolWIbUBUSmBjCTjDTViyCThp3MQ71vbOjqid/J+q/I4wJz c=; Received: from esa2.dell-outbound2.iphmx.com ([68.232.153.202]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2017 10:37:55 -0500 From: Received: from ausc60pc101.us.dell.com ([143.166.85.206]) by esa2.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jun 2017 21:30:43 +0600 X-LoopCount0: from 10.0.2.213 X-IronPort-AV: E=Sophos;i="5.39,361,1493701200"; d="scan'208";a="1122191819" To: CC: , , , , , , , Thread-Topic: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) Thread-Index: AQHS6Qq8cXwAfROIYUmdpSJAsUwYJKIsn+OAgAAGpwA= Date: Mon, 19 Jun 2017 15:40:40 +0000 Message-ID: References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <22739.38728.808538.27709@fireball.acr.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.177.49.166] Content-Type: text/plain; charset="us-ascii" Content-ID: <0BDBF1AE62D91A45B01308E0838412D2@dell.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 15:41:39 -0000 > On Jun 19, 2017, at 11:16 AM, Eric Rescorla wrote: >=20 >=20 >=20 > On Mon, Jun 19, 2017 at 7:45 AM, Paul Wouters wrote: >=20 > Paul Wouters writes: > -3: I wonder why "... is not to be used..." is not "... MUST NOT be > used...". But the section goes on to say if you do it anyway, you MUST > NOT use certain cryptosuites. So, does "... is not to be used..." mean > "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL" > sort of requirements? >=20 > It is indeed. I think a SHOULD NOT would actually be appropriate ? >=20 > We do not want to make the implementation of the manual keying MUST > NOT, as it is still useful in testing and similar situations, but we > do not want anybody using it in any real world use cases. As this > document is mostly about the implementation and tries to stay out from > the issues about what should be used (as explained in the 2nd > paragraph of the section 1.3). I still prefer MUST NOT. =20 If we're goint to use SHOULD NOT, it needs to be accompanied by very explic= it wording that directs test labs and authors of certification requirements= documents that they are forbidden from having manual keying in their certi= fication requirements. We currently have the issue that some uninformed ce= rtification requirements documents do exactly this: force implementers to i= mplement something we KNOW is wrong. We end up writing stuff in the user m= anual along the lines of "NEVER use this option -- it exists only because o= f a certification requirement". This is absurd, and it has to stop. > ... > NEW text: >=20 > 3. Manual Keying >=20 > Manual Keying SHOULD NOT be used as it is inherently dangerous. > Without any keying protocol, it does not offer Perfect Forward > Secrecy ("PFS") protection. Without IKE, another entity needs to > ensure refreshing of session keys, tracking SPI uniqueness and > ensuring nonces or IVs are not used more then once. This document > was written for deploying ESP/AH using IKE ([RFC7296]) and assumes > that keying happens using IKE version 2 or higher. That's ok so far as it goes, but I don't believe it is sufficient to correc= the previous agency errors. paul From nobody Mon Jun 19 08:42:42 2017 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 8E21C1201FA for ; Mon, 19 Jun 2017 08:42:40 -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, 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 TES75do0An-f for ; Mon, 19 Jun 2017 08:42:38 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B47C71293FF for ; Mon, 19 Jun 2017 08:42:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0997330056B for ; Mon, 19 Jun 2017 11:35:16 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PaQWL-rKJIoA for ; Mon, 19 Jun 2017 11:35:14 -0400 (EDT) Received: from a860b60074bd.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id E97E33004D0; Mon, 19 Jun 2017 11:35:13 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Russ Housley In-Reply-To: Date: Mon, 19 Jun 2017 11:35:13 -0400 Cc: Eric Rescorla , draft-ietf-ipsecme-rfc7321bis@ietf.org, Ben Campbell , ipsecme-chairs@ietf.org, Tero Kivinen , IETF IPsec , IESG , david.waltermire@nist.gov Content-Transfer-Encoding: quoted-printable Message-Id: <1A070DF5-2B35-410C-97E6-429A1977EF1F@vigilsec.com> References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <22739.38728.808538.27709@fireball.acr.fi> To: Paul Wouters X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 15:42:40 -0000 > On Jun 19, 2017, at 11:26 AM, Paul Wouters wrote: >=20 > On Mon, 19 Jun 2017, Eric Rescorla wrote: >=20 >> If manual keying is used anyway, AEAD algorithms MUST NOT be = used, >> as these algorithms require additional input provided by IKE and >> are compromised if a counter is accidentally re-used, such as = when >> a counter overflows, or when a device reboots without = remembering >> the previously used counters. As of publication of this = document, >> ENCR_AES_CBC is the only non-AEAD Mandatory-To-Implement = encryption >> algorithm suitable for Manual Keying. >> It's not AEAD that's the problem here. After all, it's perfectly = possible to do AEAD >> with CBC-HMAC. Rather, it's CTR mode. >=20 >=20 > Hmm, of course we only have CTR based AEAD's :P >=20 > Ok, NEW NEW last paragraph: >=20 > If manual keying is used regardless, Counter Mode AEAD = algorithms > MUST NOT be used, as these algorithms require additional input > provided by IKE and are compromised if a counter is accidentally > re-used, such as when a counter overflows, or when a device = reboots > without remembering the previously used counters. As of = publication > of this document, ENCR_AES_CBC is the only = Mandatory-To-Implement > encryption algorithm suitable for Manual Keying. The Security Considerations in RFC 3686 point out the problems with = using AES-CTR with static keys, which is what I think you mean by manual = in this paragraph. I think you need to delete =E2=80=9CAEAD=E2=80=9D = from the first sentence or explain that CCM and GCM encompass counter = mode. Russ From nobody Mon Jun 19 09:50:19 2017 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 20D5613162F for ; Mon, 19 Jun 2017 09:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 38-XdnhpD_ZX for ; Mon, 19 Jun 2017 09:50:11 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 7FC641316D1 for ; Mon, 19 Jun 2017 09:46:07 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id e142so42750489ywa.1 for ; Mon, 19 Jun 2017 09:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hPmCS2l6WRgacp3uKdJxW/ilM64D/v1+pXDiTJTBsjI=; b=tk8JsWnyGTAGrOJ36nf5TsV7rIPZilGJmlBskn58VidQTYeybeTIDtaaMNzE3o1GmC Z0DUZPgaGzugzbTGPOW+q3M6IDoWtrTVIBN/JTb9/RzlwcwprbUUKEi54CTGVzqaMhrY fRZRGXOLUVozFiKJ53NbAFtK6zYNvGVfpqTS3wtt07isFHwZKMzhzRFbRbftzUDurBLR xGWTkY7ngzpzFFFP8LQDW1jM8GbCBkeqxAqU4sUyMD4dQv4RrqwiE/h32whU823hoPjQ p+GuP1j/+hbK6Ry1ZNCmjbdPZ88XwcpsPu2qQBbCavSHVLSk0sfCKsBvBwMvc8wcguHm ewWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hPmCS2l6WRgacp3uKdJxW/ilM64D/v1+pXDiTJTBsjI=; b=gOKZLz8khP95CdeGX7zRcG2bfHWJzgqDVY/hJwxmRF0vJIPNQ5CwnK5OlBwTa6Ukj2 6vcBqdrwrVdE27wXJ9C7ToBtwSNgM6M+fsszbRbyyLk5EGjH/UgXgZBbx7BV9Z/gic5F LkRprZIzuHGf4keOGVMkEyeQfZd/9sGwup+czru6cciCkirTpD21M04bRNCWmda3mUq0 5g97cTliGc+sx4O98b50wsX7PEnCuEjBQLNvVsAPXIghz068fibit49ylcU/W6PhLqUc hFP+SuyXJDp2dx7OWrLf5QA7DZ0hpkhOomFKqp/D80wzKly75UNfAw7hrxvE9lZDjJaU LCHQ== X-Gm-Message-State: AKS2vOyEDsThnDMIM/UM5wLPnT6rmgckyED5YFuRVPrNfn/QWmc+7oQI BqJXrunqlkPIpmkBORre8yZdmDoYT05V X-Received: by 10.129.68.10 with SMTP id r10mr18717748ywa.85.1497890766598; Mon, 19 Jun 2017 09:46:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Mon, 19 Jun 2017 09:45:25 -0700 (PDT) In-Reply-To: <1A070DF5-2B35-410C-97E6-429A1977EF1F@vigilsec.com> References: <148962889979.14189.965850110922865986.idtracker@ietfa.amsl.com> <22739.38728.808538.27709@fireball.acr.fi> <1A070DF5-2B35-410C-97E6-429A1977EF1F@vigilsec.com> From: Eric Rescorla Date: Mon, 19 Jun 2017 09:45:25 -0700 Message-ID: To: Russ Housley Cc: Paul Wouters , draft-ietf-ipsecme-rfc7321bis@ietf.org, Ben Campbell , ipsecme-chairs@ietf.org, Tero Kivinen , IETF IPsec , IESG , david.waltermire@nist.gov Content-Type: multipart/alternative; boundary="f403045eb7680ec22c055252df12" Archived-At: Subject: Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 16:50:13 -0000 --f403045eb7680ec22c055252df12 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Russ. On Mon, Jun 19, 2017 at 8:35 AM, Russ Housley wrote: > > > On Jun 19, 2017, at 11:26 AM, Paul Wouters wrote: > > > > On Mon, 19 Jun 2017, Eric Rescorla wrote: > > > >> If manual keying is used anyway, AEAD algorithms MUST NOT be used= , > >> as these algorithms require additional input provided by IKE and > >> are compromised if a counter is accidentally re-used, such as whe= n > >> a counter overflows, or when a device reboots without remembering > >> the previously used counters. As of publication of this document, > >> ENCR_AES_CBC is the only non-AEAD Mandatory-To-Implement encrypti= on > >> algorithm suitable for Manual Keying. > >> It's not AEAD that's the problem here. After all, it's perfectly > possible to do AEAD > >> with CBC-HMAC. Rather, it's CTR mode. > > > > > > Hmm, of course we only have CTR based AEAD's :P > > > > Ok, NEW NEW last paragraph: > > > > If manual keying is used regardless, Counter Mode AEAD algorithms > > MUST NOT be used, as these algorithms require additional input > > provided by IKE and are compromised if a counter is accidentally > > re-used, such as when a counter overflows, or when a device reboo= ts > > without remembering the previously used counters. As of publicati= on > > of this document, ENCR_AES_CBC is the only Mandatory-To-Implement > > encryption algorithm suitable for Manual Keying. > > The Security Considerations in RFC 3686 point out the problems with using > AES-CTR with static keys, which is what I think you mean by manual in thi= s > paragraph. I think you need to delete =E2=80=9CAEAD=E2=80=9D from the fi= rst sentence or > explain that CCM and GCM encompass counter mode. > > Russ > > --f403045eb7680ec22c055252df12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Russ.

On Mon, Jun 19, 2017 at 8:35 AM, Russ Housley <= housley@vigilsec.com> wrote:

> On Jun 19, 2017, at 11:26 AM, Paul Wouters <paul@nohats.ca> wrote:
>
> On Mon, 19 Jun 2017, Eric Rescorla wrote:
>
>>=C2=A0 =C2=A0 =C2=A0 If manual keying is used anyway, AEAD algorith= ms MUST NOT be used,
>>=C2=A0 =C2=A0 =C2=A0 as these algorithms require additional input p= rovided by IKE and
>>=C2=A0 =C2=A0 =C2=A0 are compromised if a counter is accidentally r= e-used, such as when
>>=C2=A0 =C2=A0 =C2=A0 a counter overflows, or when a device reboots = without remembering
>>=C2=A0 =C2=A0 =C2=A0 the previously used counters. As of publicatio= n of this document,
>>=C2=A0 =C2=A0 =C2=A0 ENCR_AES_CBC is the only non-AEAD Mandatory-To= -Implement encryption
>>=C2=A0 =C2=A0 =C2=A0 algorithm suitable for Manual Keying.
>> It's not AEAD that's the problem here. After all, it's= perfectly possible to do AEAD
>> with CBC-HMAC. Rather, it's CTR mode.
>
>
> Hmm, of course we only have CTR based AEAD's :P
>
> Ok, NEW NEW last paragraph:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0If manual keying is used regardless, Counter= Mode AEAD algorithms
>=C2=A0 =C2=A0 =C2=A0 =C2=A0MUST NOT be used, as these algorithms requir= e additional input
>=C2=A0 =C2=A0 =C2=A0 =C2=A0provided by IKE and are compromised if a cou= nter is accidentally
>=C2=A0 =C2=A0 =C2=A0 =C2=A0re-used, such as when a counter overflows, o= r when a device reboots
>=C2=A0 =C2=A0 =C2=A0 =C2=A0without remembering the previously used coun= ters. As of publication
>=C2=A0 =C2=A0 =C2=A0 =C2=A0of this document, ENCR_AES_CBC is the only M= andatory-To-Implement
>=C2=A0 =C2=A0 =C2=A0 =C2=A0encryption algorithm suitable for Manual Key= ing.

The Security Considerations in RFC 3686 point out the problems with = using AES-CTR with static keys, which is what I think you mean by manual in= this paragraph.=C2=A0 I think you need to delete =E2=80=9CAEAD=E2=80=9D fr= om the first sentence or explain that CCM and GCM encompass counter mode.
Russ


--f403045eb7680ec22c055252df12-- From nobody Mon Jun 19 19:03:34 2017 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 CFDD31318D1; Mon, 19 Jun 2017 19:03:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149792421279.23662.8593265933742061820@ietfa.amsl.com> Date: Mon, 19 Jun 2017 19:03:32 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc7321bis-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 02:03:33 -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 of the IETF. Title : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Authors : Paul Wouters Daniel Migault John Mattsson Yoav Nir Tero Kivinen Filename : draft-ietf-ipsecme-rfc7321bis-06.txt Pages : 14 Date : 2017-06-19 Abstract: This document updates the Cryptographic Algorithm Implementation Requirements for ESP and AH. The goal of these document is to enable ESP and AH to benefit from cryptography that is up to date while making IPsec interoperable. This document obsoletes RFC 7321. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc7321bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc7321bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-rfc7321bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc7321bis-06 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 Tue Jun 20 10:33:37 2017 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 471E91315C3 for ; Tue, 20 Jun 2017 10:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-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 f_paDzicX5ZL for ; Tue, 20 Jun 2017 10:33: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 7CE951315A2 for ; Tue, 20 Jun 2017 10:33:29 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wsZgq0nWXz1Kv; Tue, 20 Jun 2017 19:33:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1497980007; bh=j0NLpahI07pAYVACxeR8+XyX1ONbWidZKBCVgcDEVMY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=H0dJ/ke2PuGH/jzDbQ1js8uIbXkwoN93EcFtNYHNdxPufu3HgJE+NUpKyN4lZyMA3 BcYHc1eaQpDxA6TKE9DIiMMH9rensx4DwNoMNRz3DSn2nie/qRlMKsM5iyEDAV/EYq Ye6Ayt6uC8UbI/YkFmfsu0dg0yNvbEe9uQHQPFbY= 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 pnN0Pat2yq6C; Tue, 20 Jun 2017 19:33:25 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 20 Jun 2017 19:33:25 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6200D1255FC; Tue, 20 Jun 2017 13:33:24 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6200D1255FC Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 58CD740D3592; Tue, 20 Jun 2017 13:33:24 -0400 (EDT) Date: Tue, 20 Jun 2017 13:33:24 -0400 (EDT) From: Paul Wouters To: Valery Smyslov , Sahana Prasad cc: IPsecME WG In-Reply-To: <2FBB5ECC7B8043F2B4E1A6141B3D4FE1@buildpc> Message-ID: References: <876523B00C3F9D47BFD2B654D63DBF92BEAA73FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FBB5ECC7B8043F2B4E1A6141B3D4FE1@buildpc> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] vendor support of RFC7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 17:33:36 -0000 On Mon, 10 Oct 2016, Valery Smyslov wrote: Valery, I forgot if we reached any consensus or ideas on the 7427 issue you brought up in Seoul. Sahana has started work on implementing 7427 for libreswan and during this process we came up with a few questions. Has there been any discussion about using a hash algorithm that is different from the one used to sign the CERT (if certificates are used) ? It seems to not make much sense and lead to false sense of security if the signature uses SHA2 but the CERT is trusted based on a SHA1 signature. So, in a way sending more then one hash algorithm seems to only make sense for raw public keys, not with certificates? Is it implied that when using SHA2, one twiches the RSA algorithm variant? If so, how does one know that the old variant is supported? (I guess that's the issue you brought up in the link below) Another issue we have in our implementation, is that we don't know which hash algorithms we allow when needing to send an IKE_INIT response. In theory, our server could have two connections loaded, one using RSA-SHA1 and one using ECDSA-SHA2. These connections can only be selected when we receive the IKE_AUTH packet. So our implementation picks one (sort of randomly) and when processing IKE_AUTH it can "switch" to the other connection. But we already have to commit to a hash algorithm in the IKE_INIT reply. And if we are sending ALL the hash algorithms that we support/implement, then we run the risk of the peer expecting to be able to use some hash algorithm, but we don't allow it per configuration for that specific connection (eg the SHA2 one on the RSA-SHA1 connection) and there is no way to signal that other then AUTHENTICATION_FAILED. Paul > Subject: Re: [IPsec] vendor support of RFC7427 > Hi, >   > we (ELVIS-PLUS) support RFC7427 for over a year and we are interoperable with Strongswan. >   > However, see my message about some interoperability problems: > https://www.ietf.org/mail-archive/web/ipsec/current/msg10840.html >   > This issue is scheduled for discussion on ipsecme meeting in Seoul. >   > Regards, > Valery Smyslov. From nobody Wed Jun 21 00:01:30 2017 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 DDD17126DFB for ; Wed, 21 Jun 2017 00:01:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.199 X-Spam-Level: X-Spam-Status: No, score=-1.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j_ykUBWlv2M7 for ; Wed, 21 Jun 2017 00:01:26 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 A4CFC126C3D for ; Wed, 21 Jun 2017 00:01:25 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id h22so7932523lfk.3 for ; Wed, 21 Jun 2017 00:01:25 -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=/c3TEVCQfZ3d2U3tH6LsfXG2IVo+MJLaQ6h+Gas3r5I=; b=n+Qp8k44TCvp8oIlggIc1GpmlJ7KpKFQwxO+c+wKy5wAQT7RVwLKucxO3u0AsQgNEa t0Q+xs/zGvbxrsaLm/FHzq44EjkI6mHNSuTv1S/ZpcgSaEqe7bjwo2B3LCg+0j5xdhOn r/KFvQBlBQMWbu3XSpiYx1trY330f5JIejIfjs+lCmpE2Wv65Pe6hfXf02WjS8xSuq+b FTbOYtqppVZ3U7Y9c6XVT4zR2e0jFYzC3acM6YF+1OxtcAUmbM7XiFwOBEVucCBcztqD xU/e9RBNn4EfxLq9jIFSfEel+GBYRxCYq8k9Ps/W2mBt2lRlWb+b+IgOz04f5x3ERpi4 q5sw== 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=/c3TEVCQfZ3d2U3tH6LsfXG2IVo+MJLaQ6h+Gas3r5I=; b=DJ/9+WU2vfxv271j8eWqPjoS+H2Djh/Mo6FEuJDvtRg3+Fx8apoXS1/jfLdj+BTAQf k6wXz3UB/kjqnJ6vrniiUfPyiDkDwP779hzj0xcirJqMxjj+94GaOnDN4LkiIFOafQ30 sHww4MQBF+vkxazwGoqXnHNdELJrp6kwNyjmvNXMje8KX7ayvUYmNlAlacPzIPxblooo 513dF7Eb94mB+oPN+Jq6ke+04Xhzps0LBR1FOw+kza5c2XBKlon62o5VUGAF7k/8PtDW IQFrDg4RKbZIrGBt0BKft2q6PcPWioLRGE5TNGTpio8TyXAWKqlnqeo/YrLhXFR18Q/v ykHg== X-Gm-Message-State: AKS2vOx8+ey9lXRdn4lPw9lP4swY0NiFgTbiaeKpfOXo/NHuu0zDhI4O wcqCPX7OF2eJqERi X-Received: by 10.46.88.86 with SMTP id x22mr9503316ljd.106.1498028483528; Wed, 21 Jun 2017 00:01:23 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id g88sm4558328lfh.17.2017.06.21.00.01.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 Jun 2017 00:01:22 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Sahana Prasad'" Cc: "'IPsecME WG'" References: <876523B00C3F9D47BFD2B654D63DBF92BEAA73FA@US70UWXCHMBA05.zam.alcatel-lucent.com> <2FBB5ECC7B8043F2B4E1A6141B3D4FE1@buildpc> In-Reply-To: Date: Wed, 21 Jun 2017 10:01:23 +0300 Message-ID: <01df01d2ea5c$3205afd0$96110f70$@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: AQJTe0RxQFhX5rnP0h9T8vu9aUAHgwHfQdM2AaM8+LGhEZdR4A== Content-Language: ru Archived-At: Subject: Re: [IPsec] vendor support of RFC7427 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 07:01:28 -0000 Hi Paul, > Valery, > > I forgot if we reached any consensus or ideas on the 7427 issue you > brought up in Seoul. Sahana has started work on implementing 7427 > for libreswan and during this process we came up with a few questions. My impression was that most of participants considered the problem insignificant. But I wouldn't call this a consensus. > Has there been any discussion about using a hash algorithm that > is different from the one used to sign the CERT (if certificates are > used) ? It seems to not make much sense and lead to false sense of > security if the signature uses SHA2 but the CERT is trusted based on > a SHA1 signature. So, in a way sending more then one hash algorithm > seems to only make sense for raw public keys, not with certificates? I don't think so. The responder usually doesn't know which certificate the initiator will use in IKE_AUTH, so it has to announce support for all supported hashes. > Is it implied that when using SHA2, one twiches the RSA algorithm > variant? If so, how does one know that the old variant is supported? > (I guess that's the issue you brought up in the link below) Yes. The IKE peer can announce which hash algorithms it supports, but it cannot announce which signature formats it supports. For example, with RSA we have at least two widely used - RSA-PKCS1 and RSA-PSS. We did meet a situation when one product supported RSA-PSS in certificates, but didn't support it in IKE AUTH, so that we received AUTHENTICATION_FAILED if we used RSA-PSS. As initiator we can retry with RSA-PKCS1 (however it is ugly), but as responder we cannot, so the connection just failed. If there were means to announce support for particular signature formats, then we would have used this format (RSA-PKCS1 in the example above) and the connection would succeed. I guess similar problem can arise in the future with other signatures - we now see some new signature schemes emerging (EdDSA, XMSS etc.). > Another issue we have in our implementation, is that we don't know which > hash algorithms we allow when needing to send an IKE_INIT response. In > theory, our server could have two connections loaded, one using RSA-SHA1 > and one using ECDSA-SHA2. These connections can only be selected > when we receive the IKE_AUTH packet. So our implementation picks one > (sort of randomly) and when processing IKE_AUTH it can "switch" to the > other connection. But we already have to commit to a hash algorithm > in the IKE_INIT reply. And if we are sending ALL the hash algorithms that > we support/implement, then we run the risk of the peer expecting to be > able to use some hash algorithm, but we don't allow it per configuration > for that specific connection (eg the SHA2 one on the RSA-SHA1 connection) > and there is no way to signal that other then AUTHENTICATION_FAILED. This is even a more fundamental problem with IKEv2 - the responder cannot have per-peer policy (e.g. if server's policy states, that IKE SA with client alice@example.com must be secured with AES and IKE SA with client carol@example.com must be secured with Chacha20, and both clients send both algorithms in IKE_SA_INIT, then the server in general cannot enforce this policy, because it must select a single algorithm before it figures out who the client is). It seems that the only solution is to have a global policy for IKE. So, in your particular example the server should announce both hashes (assuming both are strong enough). Regards, Valery. > Paul > > > Subject: Re: [IPsec] vendor support of RFC7427 > > > Hi, > > > > we (ELVIS-PLUS) support RFC7427 for over a year and we are interoperable with Strongswan. > > > > However, see my message about some interoperability problems: > > https://www.ietf.org/mail-archive/web/ipsec/current/msg10840.html > > > > This issue is scheduled for discussion on ipsecme meeting in Seoul. > > > > Regards, > > Valery Smyslov. From nobody Wed Jun 21 07:36:39 2017 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 2423A129B69; Wed, 21 Jun 2017 07:36:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149805579002.15916.15299944146252256927@ietfa.amsl.com> Date: Wed, 21 Jun 2017 07:36:30 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-mglt-ipsecme-implicit-iv-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:36:30 -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 of the IETF. Title : Implicit IV for Counter-based Ciphers in IPsec Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-mglt-ipsecme-implicit-iv-03.txt Pages : 7 Date : 2017-06-21 Abstract: IPsec ESP sends an initialization vector (IV) or nonce in each packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce, saving 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-03 https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-implicit-iv-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-implicit-iv-03 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 Wed Jun 21 07:49:55 2017 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 87D55129C3E for ; Wed, 21 Jun 2017 07:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yO-e87vK5f3 for ; Wed, 21 Jun 2017 07:49:52 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 5DA0D129C64 for ; Wed, 21 Jun 2017 07:48:58 -0700 (PDT) X-AuditID: c6180641-361ff700000037f2-e5-594a40f74179 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id B4.85.14322.7F04A495; Wed, 21 Jun 2017 11:48:42 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0339.000; Wed, 21 Jun 2017 10:48:54 -0400 From: Daniel Migault To: IPsecME WG Thread-Topic: New Version Notification for draft-mglt-ipsecme-implicit-iv-03.txt Thread-Index: AQHS6pvI8nBGwdX3r0m3JcUidbQ5dKIvZSqA Date: Wed, 21 Jun 2017 14:48:53 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C118C84109@eusaamb107.ericsson.se> References: <149805579025.15916.372451184882879606.idtracker@ietfa.amsl.com> In-Reply-To: <149805579025.15916.372451184882879606.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUyuXRPoO4vB69Ig9b3nBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqVXk1kK1olVvF/Wy9zA+ES0i5GTQ0LAROLTi0eMILaQwFFG iR+TDboYuYDs5YwSvxbMYwdJsAkYSbQd6geyOThEBOQlZt7IBAkLCwRKPHg7kwXEFhEIkthx 5QiUbSRxeOIPZhCbRUBVYtuki0wgNq+Ar8T8izdZIHb5SPy+8o8ZZCQnULxpgxNImFFATOL7 qTVg5cwC4hK3nsxngjhTQGLJnvPMELaoxMvH/1ghbCWJOa+vgY1hFtCUWL9LH6JVUWJK90N2 iK2CEidnPmGZwCgyC8nUWQgds5B0zELSsYCRZRUjR2lxQU5uupHhJkZgYB+TYHPcwbi31/MQ owAHoxIP7xYDr0gh1sSy4srcQ4wSHMxKIrxfmoBCvCmJlVWpRfnxRaU5qcWHGKU5WJTEed+V X4gQEkhPLEnNTk0tSC2CyTJxcEo1MG7eWnmXZbvYr3mPj3gr/VptN6n7cEZ8p2uS9v+cQC6W Kzwpj6QuPSh59me1Tc8K1rn5Bw7ZHNtXJhWWMv/DbR3Pi1b9NREts9a87o/u3tE6+f+PE1zr BQOtkqbtq+/a9K75o17Mzpg9C5rX9HTLrXwSP/PWmnK9yZ+XifyaI7y2k3eN4nfu5buUWIoz Eg21mIuKEwHKHn5VaAIAAA== Archived-At: Subject: [IPsec] FW: New Version Notification for draft-mglt-ipsecme-implicit-iv-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 14:49:54 -0000 SGksIA0KDQpQbGVhc2UgZmluZCBhbiB1cGRhdGUgb2Ygb3VyIGRyYWZ0LiBXZSBoYXZlIGFkZHJl c3NlZCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgb24gbXVsdGljYXN0IGFuZCBtZW50aW9uZWQgdGhl IEJFQVNUIGF0dGFjayBhcyB3ZWxsLiBJIGJlbGlldmUgYWxsIGNvbW1lbnRzIHByb3ZpZGVkIGhh dmUgYmVlbiBhZGRyZXNzZWQsIHRoYXQgc2FpZCwgYXMgSSBoYWQgdG8gbWVyZ2UgdHdvIGRpZmZl cmVudCB2ZXJzaW9ucywgSSBtaWdodCBoYXZlIG1pc3NlZCBzb21ldGhpbmcsIHNvIGZlZWwgZnJl ZSB0byBjaGVjay4gDQoNCllvdXJzLCANCkRhbmllbA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnXSANClNlbnQ6IFdlZG5lc2RheSwgSnVuZSAyMSwgMjAxNyAxMDozNyBBTQ0K VG86IFRvYmlhcyBHdWdnZW1vcyA8Z3VnZ2Vtb3NAbW5tLXRlYW0ub3JnPjsgRGFuaWVsIE1pZ2F1 bHQgPGRhbmllbC5taWdhdWx0QGVyaWNzc29uLmNvbT47IFlvYXYgTmlyIDx5bmlyLmlldGZAZ21h aWwuY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1tZ2x0 LWlwc2VjbWUtaW1wbGljaXQtaXYtMDMudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LW1nbHQtaXBzZWNtZS1pbXBsaWNpdC1pdi0wMy50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxs eSBzdWJtaXR0ZWQgYnkgRGFuaWVsIE1pZ2F1bHQgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBv c2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtbWdsdC1pcHNlY21lLWltcGxpY2l0LWl2DQpSZXZpc2lv bjoJMDMNClRpdGxlOgkJSW1wbGljaXQgSVYgZm9yIENvdW50ZXItYmFzZWQgQ2lwaGVycyBpbiBJ UHNlYw0KRG9jdW1lbnQgZGF0ZToJMjAxNy0wNi0yMA0KR3JvdXA6CQlpcHNlY21lDQpQYWdlczoJ CTcNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtbWdsdC1pcHNlY21lLWltcGxpY2l0LWl2LTAzLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LW1nbHQtaXBzZWNtZS1pbXBsaWNp dC1pdi8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bWdsdC1pcHNlY21lLWltcGxpY2l0LWl2LTAzDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1tZ2x0LWlwc2VjbWUtaW1wbGljaXQtaXYt MDMNCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtbWdsdC1pcHNlY21lLWltcGxpY2l0LWl2LTAzDQoNCkFic3RyYWN0Og0KICAgSVBzZWMgRVNQ IHNlbmRzIGFuIGluaXRpYWxpemF0aW9uIHZlY3RvciAoSVYpIG9yIG5vbmNlIGluIGVhY2gNCiAg IHBhY2tldCwgYWRkaW5nIDggb3IgMTYgb2N0ZXRzLiAgU29tZSBhbGdvcml0aG1zIHN1Y2ggYXMg QUVTLUdDTSwgQUVTLQ0KICAgQ0NNLCBBRVMtQ1RSIGFuZCBDaGFDaGEyMC1Qb2x5MTMwNSByZXF1 aXJlIGEgdW5pcXVlIG5vbmNlIGJ1dCBkbyBub3QNCiAgIHJlcXVpcmUgYW4gdW5wcmVkaWN0YWJs ZSBub25jZS4gIFdoZW4gdXNpbmcgc3VjaCBhbGdvcml0aG1zIHRoZQ0KICAgcGFja2V0IGNvdW50 ZXIgdmFsdWUgY2FuIGJlIHVzZWQgdG8gZ2VuZXJhdGUgYSBub25jZSwgc2F2aW5nIDggb2N0ZXRz DQogICBwZXIgcGFja2V0LiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgaG93IHRvIGRvIHRoaXMu DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Jun 21 09:12:29 2017 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 3AE0712EB0B; Wed, 21 Jun 2017 09:12: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: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149806154722.15567.13719134858702936743@ietfa.amsl.com> Date: Wed, 21 Jun 2017 09:12:27 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-mglt-ipsecme-implicit-iv-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 16:12: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 of the IETF. Title : Implicit IV for Counter-based Ciphers in IPsec Authors : Daniel Migault Tobias Guggemos Yoav Nir Filename : draft-mglt-ipsecme-implicit-iv-04.txt Pages : 7 Date : 2017-06-21 Abstract: IPsec ESP sends an initialization vector (IV) or nonce in each packet, adding 8 or 16 octets. Some algorithms such as AES-GCM, AES- CCM, AES-CTR and ChaCha20-Poly1305 require a unique nonce but do not require an unpredictable nonce. When using such algorithms the packet counter value can be used to generate a nonce, saving 8 octets per packet. This document describes how to do this. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-mglt-ipsecme-implicit-iv-04 https://datatracker.ietf.org/doc/html/draft-mglt-ipsecme-implicit-iv-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mglt-ipsecme-implicit-iv-04 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 Fri Jun 23 17:11:33 2017 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 AE7C812EAF7; Fri, 23 Jun 2017 17:07:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ipsec@ietf.org, ekr@rtfm.com X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282670.7840.8140564589390684615.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:06 -0700 Archived-At: Subject: [IPsec] ipsecme - Requested session has been scheduled for IETF 99 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:07 -0000 Dear Tero Kivinen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. ipsecme Session 1 (1:30:00) Friday, Afternoon Session II 1150-1320 Room Name: Karlin I/II size: 150 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: sacm mile tcpinc curdle tls saag cfrg i2nsf Second Priority: 6tisch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Eric Rescorla Tero Kivinen David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Thu Jun 29 09:18:05 2017 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 D41E6129B36 for ; Thu, 29 Jun 2017 09:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 YLsEeykxejnn for ; Thu, 29 Jun 2017 09:17:52 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B5D12F092 for ; Thu, 29 Jun 2017 09:17:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A411BB8168A; Thu, 29 Jun 2017 09:17:18 -0700 (PDT) To: charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, kivinen@iki.fi, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, david.waltermire@nist.gov, kivinen@iki.fi X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: mtaylor@unicoi.com, ipsec@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170629161718.A411BB8168A@rfc-editor.org> Date: Thu, 29 Jun 2017 09:17:18 -0700 (PDT) Archived-At: Subject: [IPsec] [Technical Errata Reported] RFC7296 (5056) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jun 2017 16:18:04 -0000 The following errata report has been submitted for RFC7296, "Internet Key Exchange Protocol Version 2 (IKEv2)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5056 -------------------------------------- Type: Technical Reported by: Michael Taylor Section: 1.7 Original Text ------------- This document removes discussion of the INTERNAL_ADDRESS_EXPIRY configuration attribute because its implementation was very problematic. Implementations that conform to this document MUST ignore proposals that have configuration attribute type 5, the old value for INTERNAL_ADDRESS_EXPIRY Corrected Text -------------- Unclear what it should be Notes ----- Configuration attribute 5, INTERNAL_ADDRESS_EXPIRY, is a type of attribute in a configuration payload. It is not an attribute in a proposal. As documented in Section 2.7 proposals are part of an SA payload. An SA payload consists of one or more proposals. Each proposal includes one protocol. Each protocol contains one or more transforms -- each specifying a cryptographic algorithm. Each transform contains zero or more attributes (attributes are needed only if the Transform ID does not completely specify the cryptographic algorithm). So the correct behavior when one receives a *configuration* payload with INTERNAL_ADDRESS_EXPIRY cannot be to ignore a proposal. Was the intent to say that the configuration payload should be ignored? Was the intent to say that the configuration payload should be processed but the INTERNAL_ADDRESS_EXPIRY attribute ignored? Clearly these choices would result in radically different outcomes for the negotiation. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC7296 (draft-kivinen-ipsecme-ikev2-rfc5996bis-04) -------------------------------------- Title : Internet Key Exchange Protocol Version 2 (IKEv2) Publication Date : October 2014 Author(s) : C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, T. Kivinen Category : INTERNET STANDARD Source : IP Security Maintenance and Extensions Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Jun 30 00:50:25 2017 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 B9F74126E3A for ; Fri, 30 Jun 2017 00:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 n-HTBHc6Fyx5 for ; Fri, 30 Jun 2017 00:50:20 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 98EC1126C22 for ; Fri, 30 Jun 2017 00:50:20 -0700 (PDT) X-AuditID: c1b4fb2d-bcf0a9c000005faa-88-595602bad0e7 Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F3.AC.24490.AB206595; Fri, 30 Jun 2017 09:50:18 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.78) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 30 Jun 2017 09:50:15 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XIEz6OwCT/sKLCvQsvYA3IjGAM/tRyU3pP5R9WZLO1Y=; b=kMAP9+n7fuTTE7AwE2L0sk0ddrx+Znw3Ia0emsi1siUHNIhhkBTBvkX8c7paQaSKg9PTP+/y3/tXSxQx/8Egx+dy/ifpU6jMpxg2oEJfyO+EaBalehJPvnsGHaQSSVbNOt4IKqRvrKASMFm7r5HXriFlHMRwp3yh7uoFhOwvZBk= Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com (10.169.153.136) by AM5PR0701MB2803.eurprd07.prod.outlook.com (10.168.155.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1240.6; Fri, 30 Jun 2017 07:50:14 +0000 Received: from AM5PR0701MB2468.eurprd07.prod.outlook.com ([fe80::c079:8902:1edb:99da]) by AM5PR0701MB2468.eurprd07.prod.outlook.com ([fe80::c079:8902:1edb:99da%17]) with mapi id 15.01.1240.006; Fri, 30 Jun 2017 07:50:14 +0000 From: Ivo Sedlacek To: "ipsec@ietf.org" Thread-Topic: [IPsec] Query regarding Qos with IKE Thread-Index: AdLxbdUgY7lOj73ESvayTXtPBOJN3A== Date: Fri, 30 Jun 2017 07:50:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [193.179.210.162] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2803; 7:UM3f6owrCY/ozFr9XTmhlq2/2xbXVB+TUG66ktUX+yHnNVH0f6pGKab2nQsn23Pwh2VzKb+rqTrVwVd3pkz5Oc/WdB8RMHX40ZiU13rBM5YKM2Z67czz2GXmF+8zEWborJCS3Qv8TXq9L/aysSdwPWk87looVbSiBd7jYwMNc4tqFQoKAV39zDHu7kpauPxmiAHqTFdUgzujkqkP0aUmz9Uf3O62LoYhEjW59qEHD8yz+3R6MxA78iVX0gC8K00WHf3aVkd1gg8Ef2kmb7dwCrt7hEU0q1Ddi548K/ynNQE0e0KOzPXyC3VBTczPmk5nNDX6Tn3YGznIKC/l9TMOeUadwM8Dkc0HRd4kHgUQGRf/8rBZVe1MYD4wp/nOvHce083Ek/rsf3fDhK5x031b57Dkc/67KvcVkehWrVzIV5WdlnTLaropTVHI5ECTRRLNrt8pOElevgFan85Ng1PNGPxE/Akq98CAKcNjMLvDIgVEn3k5SMYMKphaFA6i5H00y7cvr2gCkZGWAtWLFcp4aiMPqVZhJLyBnIfFRFUk+ZSbggPSIdSYOsbGcvWlzW8nb1hSBN9CSd+Jdpb4OSFbNL7Dd9ayONawurYEUbFRf3icsrIdfAPh5T566nhtMLC95QkDTH3TkUvqJ2GfD8k8h7mO+iR6KKfyrWl5gOOeMuHR5fbgSomFhvIjmnyyiLrWoeaOMGq2K83KtyQpRqA2BQtPBNuwB2s7m27tz/vpAlVsxz7ivO0DxZW91/ZqXeshGjFN2JXv5loWeh1ZC/m3cazRAmfLSYNaJBRHk93EEDw= x-ms-office365-filtering-correlation-id: 182ae08d-2b15-476b-1946-08d4bf8ca4cf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:AM5PR0701MB2803; x-ms-traffictypediagnostic: AM5PR0701MB2803: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(151999592597050)(26388249023172)(236129657087228)(148574349560750)(21748063052155)(209349559609743); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0701MB2803; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0701MB2803; x-forefront-prvs: 0354B4BED2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39850400002)(39840400002)(39400400002)(39410400002)(39450400003)(2501003)(3846002)(33656002)(5630700001)(6436002)(790700001)(6116002)(5660300001)(561944003)(7736002)(2351001)(14454004)(102836003)(966005)(478600001)(110136004)(189998001)(50986999)(7696004)(99286003)(54896002)(9686003)(236005)(38730400002)(54356999)(55016002)(6306002)(53936002)(3660700001)(86362001)(1730700003)(8676002)(5640700003)(25786009)(74316002)(3280700002)(81166006)(2900100001)(6506006)(8936002)(66066001)(5250100002)(2906002)(606006)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2803; H:AM5PR0701MB2468.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2468F50310EC376791430684E5D30AM5PR0701MB2468_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jun 2017 07:50:14.5333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2803 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SW0hTcRzH+5/LNpeD03L6w8uDC2mkTvNGd9SHsgelHhLNB115UmlusqOS gqQQYg4t95A5L9McZuWTLcxLptNEh2nmksgsSilrxqSkNZ3Vzs4E3z6/7wX+vx9/AS7uJAMF BapiWqNSKKU8IdGU0ZcWOYClZ0aPOI4eeW5a5SWiFKPRiZ1DF4UncmllQSmtiTqVI8zf7Gvh F82EXtMtzxCVyBVSi3wEQMVBf4MBZ1lMjSMY7AyvRUI3TyL4pL/PYweCqsPB/GaMxznNGCzq er3DVwRbhnmC7fMoOTSYxkmW/agwsHQ1eng/FQkTkz8ITo+BD+0Wb0YOvW/7MJYJd/5X2wCf ZRGVA1s1Vo+OKH9wWHo8jFMB8G7FgHHvpsA4NItzLIFvy39J9kGI0iJYb1vwhg6ASWf3hkLg tUGL2BBQn3lgvOUkOSMV1qzcbkDNY3CnfojgjAhY0jYijtXw+2Wrt12P4MGg09uYIOG7vtvb CIaJykWSMxZIcNS2IO4CgbBkvenlYFh9/4zkNlJDy5SLfxsd1O9aUL/L0nsOsg+mmlYITo+A 9sGfPI7DoavDhu/w9MgytltvR/yHSMLQDFOYFxMrpzUFlxlGrZKr6OJe5P46o6atyKfokS3J jCgBkvqKqtYuZIpJRSlTVmhGIMClfqJYp1sS5SrKymmNOltToqQZMwoSENIAUeLwqwwxlaco pq/SdBGt2XExgU9gJWroqJYlzNnO6c4j2YZdPfvlZNiN7Tqq/kpIcraDt54uO1ahv1Rjr7qX Zco/s2axpcVZmwJSczaThxa10y5JlnBjz2mXf5j8iV39x7i35KxvYXyWRCaaC6pO+ji8lJsS rYxPsE11Px69HtVzvIgu77/7opke+BfuHEtrrYgL3ZYSTL7i8CFcwyj+AzId0SU2AwAA Archived-At: Subject: [IPsec] Query regarding Qos with IKE X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 07:50:23 -0000 --_000_AM5PR0701MB2468F50310EC376791430684E5D30AM5PR0701MB2468_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, a few years ago, there was a discussion on control of DSCP field in outer I= P header of IPSec ESP packets in https://www.ietf.org/mail-archive/web/ipse= c/current/msg08740.html the discussion seemed to end with proposal to write a new I-D specifying a = new notify type in https://www.ietf.org/mail-archive/web/ipsec/current/msg0= 8787.html Can anyone please point me to this I-D? Thank you. Kind regards Ivo Sedlacek --_000_AM5PR0701MB2468F50310EC376791430684E5D30AM5PR0701MB2468_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

a few years ago, there was a di= scussion on control of DSCP field in outer IP header of IPSec ESP packets i= n https://www.ietf.org/mail-archive/web/ipsec/= current/msg08740.html

 

the discussion seemed to end wi= th proposal to write a new I-D specifying a new notify type in https://www.ietf.org/mail-archive/web/ipsec/current/msg08787.html

 

Can anyone please point me to t= his I-D? Thank you.

 

Kind regards<= /p>

 

Ivo Sedlacek<= /p>

 

--_000_AM5PR0701MB2468F50310EC376791430684E5D30AM5PR0701MB2468_-- From nobody Fri Jun 30 07:11:17 2017 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 69125129AAD for ; Fri, 30 Jun 2017 07:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 1T8yCMINddWa for ; Fri, 30 Jun 2017 07:11:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEFF3129789 for ; Fri, 30 Jun 2017 07:11:12 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v5UEB2bZ009569 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 30 Jun 2017 17:11:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v5UEAxGo011123; Fri, 30 Jun 2017 17:10:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22870.23539.671389.864676@fireball.acr.fi> Date: Fri, 30 Jun 2017 17:10:59 +0300 From: Tero Kivinen To: RFC Errata System Cc: charliekaufman@outlook.com, paul.hoffman@vpnc.org, nir.ietf@gmail.com, pe@iki.fi, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, david.waltermire@nist.gov, mtaylor@unicoi.com, ipsec@ietf.org In-Reply-To: <20170629161718.A411BB8168A@rfc-editor.org> References: <20170629161718.A411BB8168A@rfc-editor.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 21 min Archived-At: Subject: [IPsec] [Technical Errata Reported] RFC7296 (5056) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jun 2017 14:11:15 -0000 RFC Errata System writes: > The following errata report has been submitted for RFC7296, > "Internet Key Exchange Protocol Version 2 (IKEv2)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5056 > > -------------------------------------- > Type: Technical > Reported by: Michael Taylor > > Section: 1.7 > > Original Text > ------------- > This document removes discussion of the INTERNAL_ADDRESS_EXPIRY > configuration attribute because its implementation was very > problematic. Implementations that conform to this document MUST > ignore proposals that have configuration attribute type 5, the old > value for INTERNAL_ADDRESS_EXPIRY > > > Corrected Text > -------------- > Unclear what it should be > > Notes > ----- > Configuration attribute 5, INTERNAL_ADDRESS_EXPIRY, is a type of > attribute in a configuration payload. It is not an attribute in a > proposal. As documented in Section 2.7 proposals are part of an SA > payload. "proposal" in this context has normal meaning. The SA payload contains Proposals (note capital P), i.e., the payload and substructures in payloads are identified by the capital initial letter. Configuration payloads of type CFG_REQUEST can be seen as being proposal (normal English meaning). We do similar thing with Traffic Selectors (see section 2.9, which do talk about propsals, but does not talk about Proposals). Also this text is from the RFC 5996, and it is from the section where RFC 5996 talks about changes between RFC 4306 and RFC 5996. I do not think there is any way to misunderstand that text, and we are talking about the feature which was removed from the specification 7 years ago... Check the RFC4718 Section 6.7 about the discussion about the INTERNAL_ADDRESS_EXPIRY and why it was removed. > An SA payload consists of one or more proposals. Each proposal > includes one protocol. Each protocol contains one or more transforms > -- each specifying a cryptographic algorithm. Each transform > contains zero or more attributes (attributes are needed only if the > Transform ID does not completely specify the cryptographic > algorithm). This is true, but this is not the only place where we can have proposal. It is the only place where we have Proposal substructures... > So the correct behavior when one receives a *configuration* payload > with INTERNAL_ADDRESS_EXPIRY cannot be to ignore a proposal. Was the > intent to say that the configuration payload should be ignored? Was > the intent to say that the configuration payload should be processed > but the INTERNAL_ADDRESS_EXPIRY attribute ignored? Clearly these > choices would result in radically different outcomes for the > negotiation. The correct behavior is to ignore the INTERNAL_ADDRESS_EXPIRY Configuration Attribute, and act as if it does not exists, just like it should ignore all configuration payload types it does not know: >From 3.15.1: Unrecognized or unsupported attributes MUST be ignored in both requests and responses. I.e., as there is no Configuration type number 5 anymore, complient implementations should simply skip over that attribute. The text was there in RFC5996 for those old implementation which might still implement INTERNAL_ADDRESS_EXPIRY, and it mandates them to remove the code handling INTERNAL_ADDRESS_EXPIRY, as there is no longer such configuration attribute type. -- kivinen@iki.fi