From nobody Tue Sep 1 19:27:30 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785ED1B38CF for ; Tue, 1 Sep 2015 19:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.053 X-Spam-Level: X-Spam-Status: No, score=0.053 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_MISMATCH_COM=0.553] autolearn=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 TTD1_8_id_hg for ; Tue, 1 Sep 2015 19:27:28 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BECB1B3C7C for ; Tue, 1 Sep 2015 19:27:21 -0700 (PDT) Received: from [10.32.60.217] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t822RJmJ073576 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Sep 2015 19:27:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.32.60.217] From: "Paul Hoffman" To: "IPsecME WG" Date: Tue, 01 Sep 2015 19:27:19 -0700 Message-ID: <429E7D65-0BB0-48DC-9FA3-302B41273576@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2015 02:27:29 -0000 There is general agreement that this document is a good starting point for a WG item. Yoav and Simon: please prepare this as a -00 draft, incorporating any of the relevant suggestions you got during the past few weeks. --Paul Hoffman From nobody Sun Sep 6 15:13:57 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87301B2C89 for ; Sun, 6 Sep 2015 15:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.424 X-Spam-Level: * X-Spam-Status: No, score=1.424 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, SPF_PASS=-0.001] autolearn=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 GgQ7t7BbSfAr for ; Sun, 6 Sep 2015 15:13:56 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c: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 C735F1B2AAB for ; Sun, 6 Sep 2015 15:13:55 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so70377978wic.0 for ; Sun, 06 Sep 2015 15:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-type:content-transfer-encoding; bh=X+y5f8GQlh0c9d1/9DhxYGVArLBNq2DMc49diaqwz6A=; b=BRqZbt5H194aXRrbSGx/dSU4BOZJjARx2sBUjgVPLXMmtbtezZOKCe2yLg/3LZjeNG XLoKIHCA42Ep2qORvvBSbt/Z/VoWiLezuKGvFTsqKvQbJGLp36YFOqHH8GyXbXv3Pype +HedIuB/MTyiSOS8AbXElpqUyQMx7sKuqJ05q2YLPqI8vPlC6oPlhYRb42qogAlPcYaE I4OCwRzlprmQ2SF27GdEtB3ZZcBv92QfgL/sBx0ba0qpdD1vI80PPGByJNV27D9MGEWB 28dciTb1vvk6LnBHEJlZvXVjdKu1KRXnSGnm12kXjAEH8iWSjrDkmQxgrrMYBGX69fjv XwDg== X-Received: by 10.180.106.66 with SMTP id gs2mr28907502wib.14.1441577634316; Sun, 06 Sep 2015 15:13:54 -0700 (PDT) Received: from [10.0.0.8] (bzq-79-177-155-119.red.bezeqint.net. [79.177.155.119]) by smtp.googlemail.com with ESMTPSA id eu2sm16914824wic.8.2015.09.06.15.13.52 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 06 Sep 2015 15:13:53 -0700 (PDT) To: IPsecME WG From: Yaron Sheffer Message-ID: <55ECBA9F.5090401@gmail.com> Date: Mon, 7 Sep 2015 01:13:51 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [IPsec] Leadership change X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2015 22:13:57 -0000 
Dear members of the IPsecME working group,

After co-chairing the IPsecME working group for 7 years ever since its inception, I have decided that both I and the working group could benefit from a change. I have asked the security ADs to relieve me of this position, and I am glad they came up with a worthy co-chair to continue leading the group, alongside Paul.

David Waltermire is with the National Institute of Standards and Technology where he works on standardizing approaches to automate security processes. He has been active at the IETF as a contributor in a number of working groups including SACM and MILE, and as Security Directorate member and reviewer. He has a background in systems, network, and software engineering. David is looking forward to working with the IPsecME working group in this new role. 

I am proud of what we have achieved in the working group and grateful to the small core of old timers and some not-so-old timers who have worked and are still working to maintain IPsec as a secure and relevant part of the Internet's infrastructure. I wish best of luck to Paul, Dave and the rest of the team.

I intend to continue being active within the Security Directorate, so I'll be seeing you, guys and gals.

Thanks,
	Yaron
From nobody Sun Sep 6 18:08:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A0F1A9172 for ; Sun, 6 Sep 2015 18:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.353 X-Spam-Level: * X-Spam-Status: No, score=1.353 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553] autolearn=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 FKLmpIMRxHPD for ; Sun, 6 Sep 2015 18:08:42 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 938311A01F9 for ; Sun, 6 Sep 2015 18:08:42 -0700 (PDT) Received: from [10.20.30.121] (142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8718csU087806 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 6 Sep 2015 18:08:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-100.dsl.dynamic.fusionbroadband.com [142.254.17.100] claimed to be [10.20.30.121] From: "Paul Hoffman" To: "IPsecME WG" Date: Sun, 06 Sep 2015 18:08:38 -0700 Message-ID: <2834AA4D-4F97-4699-B7A8-AF540B555374@vpnc.org> In-Reply-To: <55ECBA9F.5090401@gmail.com> References: <55ECBA9F.5090401@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [IPsec] Leadership change X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 01:08:43 -0000 On 6 Sep 2015, at 15:13, Yaron Sheffer wrote: > Dear members of the IPsecME working group, > > After co-chairing the IPsecME working group for 7 years ever since > its inception, I have decided that both I and the working group could > benefit from a change. I have asked the security ADs to relieve me of > this position, and I am glad they came up with a worthy co-chair to > continue leading the group, alongside Paul. > > David Waltermire is with the National Institute of Standards and > Technology where he works on standardizing approaches to automate > security processes. He has been active at the IETF as a contributor in > a number of working groups including SACM and MILE, and as Security > Directorate member and reviewer. He has a background in systems, > network, and software engineering. David is looking forward to working > with the IPsecME working group in this new role. > > I am proud of what we have achieved in the working group and grateful > to the small core of old timers and some not-so-old timers who have > worked and are still working to maintain IPsec as a secure and > relevant part of the Internet's infrastructure. I wish best of luck to > Paul, Dave and the rest of the team. > > I intend to continue being active within the Security Directorate, so > I'll be seeing you, guys and gals. Thank you Yaron, and thank you David. The change in half the "leadership" of the WG should not affect our work too much, particularly at our lower level of work these days. --Paul Hoffman From nobody Sun Sep 6 19:12:12 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500341A8843 for ; Sun, 6 Sep 2015 19:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-egJ3195313 for ; Sun, 6 Sep 2015 19:12:10 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649CA1A871A for ; Sun, 6 Sep 2015 19:12:10 -0700 (PDT) Received: by qgx61 with SMTP id 61so54130186qgx.3 for ; Sun, 06 Sep 2015 19:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tE0sNarqU7gFgm2ZC78WAOZj8BQ3Dt4KMgoxaf2RGAY=; b=IQjooTnBJ92vyy82mUM8wvDPPnY6oJYc5EKNiD9ZBhgDy48Clkk1tnvlvE/tcfM36s 0DUsyU0gkHwigCa1gNey5RFad4WHD1v9v3avYFhdfUj1UT5lC4GNIXBU9XSgMVGx+x9f PrIOmqYpTqvaiTkRTjEtimthUDFRuwrV3LAYjtSPu+u0qmyIt/5adzpwj6N399qGWyDe RxkWpRA7zlOSoM9K6NF4gHJ6nS4K3jkcg+dUEQh6LRzr694lCxmv31PovTH0eZpoKvPw /JQ/+dE8RY0OLio30Z/0WDJKTJX2cFKSx4309xZ/W6ovOb+C8dn4IXe/aTJ6736J1Iyw DeRw== X-Received: by 10.140.201.79 with SMTP id w76mr25045014qha.82.1441591929610; Sun, 06 Sep 2015 19:12:09 -0700 (PDT) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by smtp.gmail.com with ESMTPSA id 139sm5966484qhh.32.2015.09.06.19.12.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 06 Sep 2015 19:12:08 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (12H143) In-Reply-To: <2834AA4D-4F97-4699-B7A8-AF540B555374@vpnc.org> Date: Sun, 6 Sep 2015 22:12:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <55ECBA9F.5090401@gmail.com> <2834AA4D-4F97-4699-B7A8-AF540B555374@vpnc.org> To: Paul Hoffman Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Leadership change X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Sep 2015 02:12:12 -0000 Thank you, Yaron! 7 years as a chair is impressive and very much appreciate= d! Thank you, Dave for helping out with IPsecME!=20 Best regards, Kathleen=20 Sent from my iPhone > On Sep 6, 2015, at 9:08 PM, Paul Hoffman wrote: >=20 >> On 6 Sep 2015, at 15:13, Yaron Sheffer wrote: >>=20 >> Dear members of the IPsecME working group, >>=20 >> After co-chairing the IPsecME working group for 7 years ever since its in= ception, I have decided that both I and the working group could benefit from= a change. I have asked the security ADs to relieve me of this position, and= I am glad they came up with a worthy co-chair to continue leading the group= , alongside Paul. >>=20 >> David Waltermire is with the National Institute of Standards and Technolo= gy where he works on standardizing approaches to automate security processes= . He has been active at the IETF as a contributor in a number of working gro= ups including SACM and MILE, and as Security Directorate member and reviewer= . He has a background in systems, network, and software engineering. David i= s looking forward to working with the IPsecME working group in this new role= . >>=20 >> I am proud of what we have achieved in the working group and grateful to t= he small core of old timers and some not-so-old timers who have worked and a= re still working to maintain IPsec as a secure and relevant part of the Inte= rnet's infrastructure. I wish best of luck to Paul, Dave and the rest of the= team. >>=20 >> I intend to continue being active within the Security Directorate, so I'l= l be seeing you, guys and gals. >=20 > Thank you Yaron, and thank you David. The change in half the "leadership" o= f the WG should not affect our work too much, particularly at our lower leve= l of work these days. >=20 > --Paul Hoffman >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Sep 7 22:26:45 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC16A1A1F04 for ; Mon, 7 Sep 2015 22:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=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 wH00xi0hFZhp for ; Mon, 7 Sep 2015 22:26:43 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (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 106311A886D for ; Mon, 7 Sep 2015 22:26:41 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t885QVcs030375 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 8 Sep 2015 07:26:32 +0200 Resent-To: ipsec@ietf.org Resent-From: Simon Josefsson Resent-Date: Tue, 08 Sep 2015 07:26:31 +0200 Resent-Message-ID: <87zj0x1ny0.fsf@latte.josefsson.org> From: Simon Josefsson To: "Paul Hoffman" References: <429E7D65-0BB0-48DC-9FA3-302B41273576@vpnc.org> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150908:ipsec@ietf.org::VbV7naRL1OoF9Wz1:9F65 X-Hashcash: 1:22:150908:paul.hoffman@vpnc.org::xjreDQwhzvEu6EIT:iGje Date: Tue, 08 Sep 2015 07:22:28 +0200 In-Reply-To: <429E7D65-0BB0-48DC-9FA3-302B41273576@vpnc.org> (Paul Hoffman's message of "Tue, 01 Sep 2015 19:27:19 -0700") Message-ID: <8737yp32p7.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Call for adoption: draft-nir-ipsecme-curve25519 as a WG work item X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 05:26:43 -0000 --=-=-= Content-Type: text/plain "Paul Hoffman" writes: > There is general agreement that this document is a good starting point > for a WG item. Yoav and Simon: please prepare this as a -00 draft, > incorporating any of the relevant suggestions you got during the past > few weeks. I have uploaded a WG -00 based on feedback. The document is now shorter than Yoav's version. I believe that this document should closely match the CFRG document, and that contains relevant discussions, algorithm descriptions and test vectors already. If there is any area where this WG want to deviate from the CFRG document (text that I now may have removed), I believe we need to articulate that and consider whether that is something to bring back to the CFRG for more general considerations. I am hoping that there will be no such area (since that may slow down the CFRG progress), and I expect and appreciate everyone's review to get consensus around that. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJV7nCcAAoJEIYLf7sy+BGdDm0H/2DKLpMo0Y1oe0wgR3wxxITf T2Tl+AgHz3HD6gkrgBs4CrYfpf80eRgYSK1/b/JrJNko1MRmw+2MlmtzegQRnuVK BoXeM6JbrujpeA9xaKeKCGSSF/dMksdAq8ZhHKWLcTMIeB53BVxOSBkFaE0QjTEC rUmqOWJxO3Moxn2bl+W7bkYTa1zgC74t7w1ecBaxodz1y2q4zHBrB94mE/7X/ndK aGiPACUvsoG2vT3w/tK1wcOA/qiHvaS+2gwnbqQmt4CS2Xin2ljGMVf8+xBH4wAW 3A/ZjfunB2vDSJYh5HB0GX+SdgK1r10bVoBt27seGZ+DWqZBAuv69NcvkA+xpdo= =Yipp -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Sep 8 07:09:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18411B4A7A; Tue, 8 Sep 2015 07:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 7g-Iu-v68Kzd; Tue, 8 Sep 2015 07:09:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7541B4A66; Tue, 8 Sep 2015 07:09:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150908140946.22348.61148.idtracker@ietfa.amsl.com> Date: Tue, 08 Sep 2015 07:09:46 -0700 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Sep 2015 14:09:52 -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 Working Group of the IETF. Title : Curve25519 and Curve448 for IKEv2 Key Agreement Authors : Yoav Nir Simon Josefsson Filename : draft-ietf-ipsecme-safecurves-00.txt Pages : 6 Date : 2015-09-07 Abstract: This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 10 10:43:50 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCD41B2A9A for ; Thu, 10 Sep 2015 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 cNQtdLAmAIGP for ; Thu, 10 Sep 2015 10:43:46 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 806EF1ACDDE for ; Thu, 10 Sep 2015 10:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1441907025; x=2305820625; 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=ObYbbhJTjUoMCJc3zrYdHji/H7WpXfbzVZ8RyMcMmnw=; b=4OM1lYpUByn5XVUiDmBKlCSPij/os25ipBZyzi3w7z2Tan5lT1Noloj6PtbO1IAq LFJvQTcFoRaKRzCbyiDoixU51elJ5y5ViVUoa01pvMDGTGidThvt6ndPMjtW/bud EOqZrGy3TH3juF7CqYC45FgQMWttDIHJIFA1lUKf4kkBxYdskbOGpmGsry5AOiEJ nLQvSIheiJv6a4NE2wy/p4vIkjJ2jzJVKqHpQEdldcIlQnDzgulkSgoMIIhGG2of a+yQnXWUuGWu/dw3zfZPpoDmpkRuRaFFK4WRAy5hapBApRAghv1AWF5FGiiVDqlD moqzZUaXKbe4yznel2FQeQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 3C.85.03127.051C1F55; Thu, 10 Sep 2015 10:43:45 -0700 (PDT) X-AuditID: 11973e11-f79d76d000000c37-18-55f1c150e83d Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id EA.67.22881.F41C1F55; Thu, 10 Sep 2015 10:43:43 -0700 (PDT) Received: from [17.153.17.2] (unknown [17.153.17.2]) by orrisroot.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUH009N82KVWX10@orrisroot.apple.com> for ipsec@ietf.org; Thu, 10 Sep 2015 10:43:43 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_5A2E582B-5EC0-4BFE-B6B2-C4864AA4B06B" Date: Thu, 10 Sep 2015 10:44:17 -0700 References: <20150910173027.20500.21521.idtracker@ietfa.amsl.com> To: IPsecME WG Message-id: MIME-version: 1.0 (Mac OS X Mail 9.0 \(3074\)) X-Mailer: Apple Mail (2.3074) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUi2FAYpRt48GOowcGpnBb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt3TzewFD+wqvuyfxdbAuM+8i5GTQ0LAROJL61tmCFtM4sK9 9WxdjFwcQgJ7GSUu/Whkgil69awRKjGFSaL77V0oZxKTxIU/XUBVHBzCAhISm/ckgjSwCahI HP+2AWwqs0CSxJ9nh1hBbGGBAIkNnc+ZQcpZBFQl/v1PBQkLCThKXDu9nRUkLCIgLzHzRiZI mFfARmL1jMdsELaeRPO/vVB3ykr8PH6UHeQCCYE5bBLnm9+zT2AUnIVk2ywkPRBxbYllC19D 2ZoS+7uXs2CKa0h0fpvIuoCRbRWjUG5iZo5uZp6RXmJBQU6qXnJ+7iZGUHBPtxPcwXh8ldUh RgEORiUe3oSLH0KFWBPLiitzDzFKc7AoifMqVwCFBNITS1KzU1MLUovii0pzUosPMTJxcEo1 MLYH1Pbduyv66vIHWwMB8Unev3d7ck+49/1wX8L2YkML/TfHQ+ReLXOdrv/eXM15ddzXN0/F 8yf6/jq+MlmcneeyXGiuRt4VS4Yc/oUXpdZL3FltOEtzxlbpP7zvjf5GJNbp9rddfjRp8eWV D36kbPxjuaDwjNmmjce8Dz+X+J2bGrprbv32zutKLMUZiYZazEXFiQA6fp/HTwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUi2FCcpet/8GOowewGK4v9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+7pZvaCB3YVX/bPYmtg3GfexcjJISFgIvHqWSMbhC0mceHe eiCbi0NIYAqTRPfbu1DOJCaJC3+6mLoYOTiEBSQkNu9JBGlgE1CROP5tAzOIzSyQJPHn2SFW EFtYIEBiQ+dzZpByFgFViX//U0HCQgKOEtdOb2cFCYsIyEvMvJEJEuYVsJFYPeMxG4StJ9H8 by8zxDmyEj+PH2WfwMg3C8mCWUjKIOLaEssWvoayNSX2dy9nwRTXkOj8NpF1ASPbKkaBotSc xEozvcSCgpxUveT83E2M4GAsjNrB2LDc6hCjAAejEg9vwsUPoUKsiWXFlbmHGCU4mJVEeM37 PoYK8aYkVlalFuXHF5XmpBYfYpzICPTjRGYp0eR8YKzklcQbmpgYmBgbmxkbm5uY01JYSZy3 QeRVqJBAemJJanZqakFqEcxRTBycUg2MuTX/pmrvq/r/ed298szZrScDV9fLT30Z90KJ/0bk Ld72YnapnKYn/j4nuI8wVs7SlQtv4Dq2yd1a8E4ke4TJ03ehhyWPWXvvLxarm1Ty90fF5q2V HUrBXAlasttvM8Zv7QuI4c7r6lvYG/Fzo5vpDjnBALFHDuv0jT6W2QuKOiy0ir29fIUSS3FG oqEWc1FxIgDUzMnNuQIAAA== Archived-At: Subject: [IPsec] Fwd: New Version Notification for draft-pauly-ipsecme-tcp-encaps-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 17:43:48 -0000 --Apple-Mail=_5A2E582B-5EC0-4BFE-B6B2-C4864AA4B06B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I=E2=80=99ve just posted a new draft to specify how to transport IKEv2 = and IPSec packets over a TCP connection in networks that block UDP.=20 All comments and feedback are welcome! Best, Tommy Pauly > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Date: September 10, 2015 at 10:30:27 AM PDT > To: Samy Touati , Tommy Pauly = , Tommy Pauly , Samy Touati = > Subject: New Version Notification for = draft-pauly-ipsecme-tcp-encaps-00.txt >=20 >=20 > A new version of I-D, draft-pauly-ipsecme-tcp-encaps-00.txt > has been successfully submitted by Tommy Pauly and posted to the > IETF repository. >=20 > Name: draft-pauly-ipsecme-tcp-encaps > Revision: 00 > Title: TCP Encapsulation of IKEv2 and IPSec Packets > Document date: 2015-09-10 > Group: Individual Submission > Pages: 10 > URL: = http://www.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-00.txt > Status: = https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps/ > Htmlized: = https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-00 >=20 >=20 > Abstract: > This document describes a method to transport IKEv2 and IPSec = packets > over a TCP connection for traversing network middleboxes that may > block IKEv2 negotiation over UDP. This method, referred to as TCP > encapsulation, involves sending all packets for tunnel establishment > as well as tunneled packets over a TCP connection. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_5A2E582B-5EC0-4BFE-B6B2-C4864AA4B06B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I=E2=80=99ve just posted a new draft to specify how to = transport IKEv2 and IPSec packets over a TCP connection in networks that = block UDP. 

All comments and feedback are welcome!
Best,
Tommy = Pauly

Begin forwarded message:

From: = internet-drafts@ietf.org
Date: = September 10, 2015 at 10:30:27 = AM PDT
To: = Samy Touati <samy.touati@ericsson.com>, Tommy Pauly <tpauly@apple.com>, = Tommy Pauly <tpauly@apple.com>, Samy Touati <samy.touati@ericsson.com>
Subject: = New Version = Notification for draft-pauly-ipsecme-tcp-encaps-00.txt

A new version of I-D, = draft-pauly-ipsecme-tcp-encaps-00.txt
has been = successfully submitted by Tommy Pauly and posted to the
IETF= repository.

Name: = draft-pauly-ipsecme-tcp-encaps
Revision: 00
Title:= = TCP Encapsulation of IKEv2 and IPSec Packets
Document= date: = 2015-09-10
Group: Individual Submission
Pages:= = 10
URL: =           http://www.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-pauly-ipsecme-tcp-encaps= /
Htmlized:       https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-00


Abstract:
=   This document describes a method to transport IKEv2 and = IPSec packets
  over a TCP connection for = traversing network middleboxes that may
  block = IKEv2 negotiation over UDP.  This method, referred to as TCP
  encapsulation, involves sending all packets for = tunnel establishment
  as well as tunneled = packets over a TCP connection.




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

The IETF Secretariat


= --Apple-Mail=_5A2E582B-5EC0-4BFE-B6B2-C4864AA4B06B-- From nobody Thu Sep 10 11:50:41 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41011B5FA9 for ; Thu, 10 Sep 2015 11:50:39 -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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 M1_RSbX92mrT for ; Thu, 10 Sep 2015 11:50:33 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (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 E999F1B2D54 for ; Thu, 10 Sep 2015 11:50:32 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so33679657wic.1 for ; Thu, 10 Sep 2015 11:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w/2GLoUEGweBJC3C8lscxx4708jBfTbfpZMw+Mk8o2k=; b=K3WiRHfCoopXUv9w74JT77BgdFpAMRGOzV6onOmy4YHMnAvH67QHBN3sCJXGZ1xvTb x+Q/kTMJu7ClrTInSUeO8Fx7V6yVHouMdy8O36coc9ZoEwfncsa9IYtSRuccnd/YsAsM B7FAkcU+cQW4CEtjwyvZJh3dKgqoauTZJ6Kj0XxvPcVbiE3HACRaTB//57pm0nrlkFp2 K7zHU16/GUufScP2oUbFAqJe3KKdhMM2IbzMdJMQy3sWm0HHHiAGcW7CwgHgwU2ndSnB X+6h/lt42r8FV6FWZ6fAVdSZfXKnEZk3VKhszH3yi3LyNwgIiFY0mwoIQA4Kpb736iza XLzw== X-Received: by 10.194.250.40 with SMTP id yz8mr78760642wjc.37.1441911031438; Thu, 10 Sep 2015 11:50:31 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id bh5sm17008155wjb.42.2015.09.10.11.50.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 10 Sep 2015 11:50:30 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: text/plain; charset=us-ascii From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Thu, 10 Sep 2015 19:38:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <2104052F-4EF1-476D-B10B-4DDC4F2A53F1@gmail.com> References: <55CDD568.4020003@gmail.com> <79614077359A4222A46B773C450158F4@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPsecME WG , Kathleen Moriarty , Paul Wouters Subject: Re: [IPsec] DDoS draft next steps - CAPTCHA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 18:50:40 -0000 > On Aug 14, 2015, at 7:08 PM, Valery Smyslov wrote: >=20 >>>> With no hat on, I hate captchas. I sometimes don't see it well = enough >>>> depending on the images selected and have not used applications as = a >>>> result. It is a clever way to tackle the problem, so it would be = up >>>> to the deployer to make sure their captcha images didn't prevent >>>> expected and authorized users from connecting. >>>=20 >>> To be frank I hate them also as a user in real life. >>> But any kind of puzzle solution (be it captca or >>> cryptographic puzzle) would annoy users (additional delays, battery = power consumption etc.). >> captcha's also assume there is a user to talk to, which might not = always >> (or even mostly) be the case. >=20 > Yes, I wrote in my original e-mail that this is not appropriate > for "unattended" devices. For those cryptographic puzzles are left. > This is appropriate mostly for smartphones. [with vendor hat on] Some of the IPsec gateways are not big devices with powerful CPUs. There = are VPN gateways that double as home routers and Firewalls/VPN gateways = specifically made for branch offices (think of the sales office from = Glengarry Glen Ross with 3 employees, some of whom are always out). = These gateways are made with general-purpose CPUs too weak to put in = anything but the lowest of low-end phones, plus they come with a single = core. Their ability to solve cryptographic puzzles is even lower than = that of phones. [hat off] So if a flood of IKE requests can make the center gateway effectively = lock out all the branch offices, then we are only helping to make this = DDoS attack successful. If we recognize the need to support weak unattended devices as a = requirement, then we need an answer for this class of devices. A = one-time reauthentication token is one possibility, but making sure it = is not replayed requires storage on the Responder. We could come up with = a scheme such as this: - Cryptographic puzzle - for powerful (enough) initiators. - Captcha (optional) - for weak initiators with a UI - Reauthentication token - for weak, unattended devices that have = previously connected. Yoav From nobody Fri Sep 11 04:35:02 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 311A31A0389 for ; Fri, 11 Sep 2015 04:35:01 -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 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 RwBranzn38qr for ; Fri, 11 Sep 2015 04:34:59 -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 E277E1A0032 for ; Fri, 11 Sep 2015 04:34:58 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8BBYrqF015392 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 11 Sep 2015 14:34:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8BBYrWx016709; Fri, 11 Sep 2015 14:34:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22002.48221.707622.426756@fireball.acr.fi> Date: Fri, 11 Sep 2015 14:34:53 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <2104052F-4EF1-476D-B10B-4DDC4F2A53F1@gmail.com> References: <55CDD568.4020003@gmail.com> <79614077359A4222A46B773C450158F4@buildpc> <2104052F-4EF1-476D-B10B-4DDC4F2A53F1@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Cc: IPsecME WG , Valery Smyslov , Paul Wouters , Kathleen Moriarty Subject: Re: [IPsec] DDoS draft next steps - CAPTCHA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2015 11:35:01 -0000 Yoav Nir writes: > [with vendor hat on] > > Some of the IPsec gateways are not big devices with powerful CPUs. > There are VPN gateways that double as home routers and Firewalls/VPN > gateways specifically made for branch offices (think of the sales > office from Glengarry Glen Ross with 3 employees, some of whom are > always out). These gateways are made with general-purpose CPUs too > weak to put in anything but the lowest of low-end phones, plus they > come with a single core. Their ability to solve cryptographic > puzzles is even lower than that of phones. > > [hat off] > > So if a flood of IKE requests can make the center gateway > effectively lock out all the branch offices, then we are only > helping to make this DDoS attack successful. Those offices should use bit of money and get static IP-address, so they can be configured to the VPN gateway so that for those IP-addresses we just do cookie exchange while under attack, but do not require puzzles... -- kivinen@iki.fi From nobody Tue Sep 15 15:11:58 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1DE1B2BE0 for ; Tue, 15 Sep 2015 15:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.552 X-Spam-Level: X-Spam-Status: No, score=0.552 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_COM=0.553] autolearn=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 bN3cyWtIlZZZ for ; Tue, 15 Sep 2015 15:11:54 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47DCA1B2BD4 for ; Tue, 15 Sep 2015 15:11:54 -0700 (PDT) Received: from [10.32.60.83] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8FMBrxo070239 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Sep 2015 15:11:53 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.83] From: "Paul Hoffman" To: "IPsecME WG" Date: Tue, 15 Sep 2015 15:11:53 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [IPsec] Not meeting at IETF 94 in Yokohama, but continuing work here on the list X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 22:11:55 -0000 Greetings again. Dave (our new co-chair) and I talked, and we don't see any need to meet at the upcoming meeting in Yokohama. Instead, we would love to see more discussion here about the DDoS document and discussion of possible new items. --Paul Hoffman From nobody Tue Sep 15 16:29:47 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925A21B2E3F for ; Tue, 15 Sep 2015 16:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.921 X-Spam-Level: X-Spam-Status: No, score=-0.921 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fgR0oBSaqtCm for ; Tue, 15 Sep 2015 16:29:45 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415751B2E3B for ; Tue, 15 Sep 2015 16:29:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1442359784; x=2306273384; 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=lpqCyZ3LVQVTW8uaNJaCK+gijADoSldDHS/9Nk9Rkqc=; b=zojTYKCV7bBHVBQ0kvPLGIigvdkdIqNEW8RKS+Wmh6FULhUKKnFu1YExOEhF3KNt HnOY+4pKXpbYRi/vuPJ/EHLXY9UbDW7yqOSd355KNkiUqoIROkWAk2MOu30/HExI F5dSLyiyvkqRpJt2fSpTloSUeEgP2j2S+2I+9KaQvXn+EgVFpiQlvCi85hBeEVNH 3LV7DylgBhvL4GaS/Vgty+heTdAdSnXRka4m6ckKVCA51mTrtMFmgN9t6CgBXXGL BiIEjj5GtYjJ5A8de7m+ExH/0ApZCOjKjnhOmPxlFKikYBnG7+WgZwvuhJozeqrM ZG77mdpQXzLI80aay9470w==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id DD.54.24122.8E9A8F55; Tue, 15 Sep 2015 16:29:44 -0700 (PDT) X-AuditID: 11973e16-f79826d000005e3a-ef-55f8a9e80c4d Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id B7.36.32123.8E9A8F55; Tue, 15 Sep 2015 16:29:44 -0700 (PDT) Received: from [17.153.81.3] (unknown [17.153.81.3]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUQ002PARXK1V90@cilantro.apple.com> for ipsec@ietf.org; Tue, 15 Sep 2015 16:29:44 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_EE55A461-5BEF-4B4D-978E-3F7C3A123178" Message-id: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> Date: Tue, 15 Sep 2015 16:30:09 -0700 To: IPsecME WG MIME-version: 1.0 (Mac OS X Mail 9.0 \(3074\)) X-Mailer: Apple Mail (2.3074) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUi2FAYrPti5Y9Qg41LjCz2b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujC/T7jMV3JOp2Pp5ElMD4yrJLkZODgkBE4m9q++wQdhiEhfu rQeyuTiEBPYySlyYupUVpmjB3/0sILaQwEQmieWXbSGK+pgkZt/pAurg4BAWkJDYvCcRpIZN QEXi+LcNzCA2s0CSxLfZF8B6hQU0JdqOTGMEsXkFbCQOf1sNVsMioCoxq/8UM8gYEQF5iZk3 MiFK9CSa/+1lhjhBVuLn8aPsIGslBCawSZx8d5F9AqPALCQrZiHpgYhrSyxb+BrK1pTY372c BVNcQ6Lz20TWBYxsqxiFchMzc3Qz88z1EgsKclL1kvNzNzGCgni6ndgOxoerrA4xCnAwKvHw RrR/DxViTSwrrsw9xCjNwaIkzpvU/iNUSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PgHp/G Vax98580Bzkb+y3YrFAVHHI9KXVDparMwq9BVtna5bMncm+r3v6XpzT5Z8NBznSHTwuK1oUz /jzr2rJ9WqdBXOT759q9d1JqGAsT4u9dDPga0L8n0yph9ab+5++/Pu1c2Hf44Ffb0Nm/sguP GbFV7f4kGSrJc7KtOGmycmNaQHTvRiWW4oxEQy3mouJEAGVP/6hDAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUi2FAspPti5Y9Qg59n9C32b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujC/T7jMV3JOp2Pp5ElMD4yrJLkZODgkBE4kFf/ezQNhiEhfu rWcDsYUEJjJJLL9s28XIBWT3MUnMvtMFlODgEBaQkNi8JxGkhk1AReL4tw3MIDazQJLEt9kX wOYIC2hKtB2Zxghi8wrYSBz+thqshkVAVWJW/ylmkDEiAvISM29kQpToSTT/28sMcYKsxM/j R9knMPLOQjJ1FpIyiLi2xLKFr6FsTYn93ctZMMU1JDq/TWRdwMi2ilGgKDUnsdJYL7GgICdV Lzk/dxMjOOgKg3cw/llmdYhRgINRiYc3ov17qBBrYllxZe4hRgkOZiUR3o01P0KFeFMSK6tS i/Lji0pzUosPMU5kBHpmIrOUaHI+MCbySuINTUwMTIyNzYyNzU3MaSmsJM6b0Ap0kUB6Yklq dmpqQWoRzFFMHJxSDYz8f81Smr/OEzDd9n9r1Zn+n0/ORjhdvGKReuHvYaHs3lfGr1nmbOmR uf/tk2xLVvHX+MesxwPidva1Kh3Z/Otwj1Dc62KONRua716++qpTTf7Ukvb0nU9/9f6KepKg fV05YGmksf6/kz/nOqiVmwjc2Dp3wtK+u31S2ctvbzm0fMVxzjd3otWWKrEUZyQaajEXFScC ALE78NetAgAA Archived-At: Subject: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Sep 2015 23:29:46 -0000 --Apple-Mail=_EE55A461-5BEF-4B4D-978E-3F7C3A123178 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I wanted to get a sense of WG interest in working on a standard for = running IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse = networks that currently block UDP traffic. Here=E2=80=99s the link to the draft: https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-00 = Abstract: This document describes a method to transport IKEv2 and IPSec packets over a TCP connection for traversing network middleboxes that may block IKEv2 negotiation over UDP. This method, referred to as TCP encapsulation, involves sending all packets for tunnel establishment as well as tunneled packets over a TCP connection. For clients that rely heavily on IKEv2, such as phones that use IKEv2 to = to route VoIP calls over Wi-Fi back to carrier networks, working in such = networks in critical. Please respond with your comments! Thanks, Tommy Pauly Apple= --Apple-Mail=_EE55A461-5BEF-4B4D-978E-3F7C3A123178 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

I = wanted to get a sense of WG interest in working on a standard for = running IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse = networks that currently block UDP traffic.

Here=E2=80=99s the link to the = draft:
https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-00

Abstract:
This document describes a = method to transport IKEv2 and IPSec packets
  =  over a TCP connection for traversing network middleboxes that = may
   block IKEv2 negotiation over UDP. =  This method, referred to as TCP
  =  encapsulation, involves sending all packets for tunnel = establishment
   as well as tunneled = packets over a TCP connection.

For clients that rely heavily on IKEv2, = such as phones that use IKEv2 to to route VoIP calls over Wi-Fi = back to carrier networks, working in such networks in = critical.

Please= respond with your comments!

Thanks,
Tommy = Pauly
Apple
= --Apple-Mail=_EE55A461-5BEF-4B4D-978E-3F7C3A123178-- From nobody Tue Sep 15 18:30:04 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7171ACDCB for ; Tue, 15 Sep 2015 18:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 cicRF8_-WNqn for ; Tue, 15 Sep 2015 18:30:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6FB1ACE09 for ; Tue, 15 Sep 2015 18:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150916013001.30272.30688.idtracker@ietfa.amsl.com> Date: Tue, 15 Sep 2015 18:30:01 -0700 From: IETF Secretariat Archived-At: Subject: [IPsec] Milestones changed for ipsecme WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 01:30:02 -0000 Changed milestone "IETF Last Call on null authentication", resolved as "Done", added draft-ietf-ipsecme-ikev2-null-auth to milestone. URL: https://datatracker.ietf.org/wg/ipsecme/charter/ From nobody Tue Sep 15 19:01:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360A91B30E9 for ; Tue, 15 Sep 2015 19:01:30 -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 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 dJ34KYKhQmUv for ; Tue, 15 Sep 2015 19:01:27 -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 274501B30F3 for ; Tue, 15 Sep 2015 19:01:26 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8G21Fg2002463 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Sep 2015 05:01:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8G21EmM003496; Wed, 16 Sep 2015 05:01:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22008.52586.571113.776646@fireball.acr.fi> Date: Wed, 16 Sep 2015 05:01:14 +0300 From: Tero Kivinen To: Tommy Pauly In-Reply-To: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 32 min Archived-At: Cc: IPsecME WG Subject: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 02:01:30 -0000 Tommy Pauly writes: > I wanted to get a sense of WG interest in working on a standard for running > IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks that > currently block UDP traffic. Before we made the UDP framentation document, our original plan was to run IKEv2 over TCP, just because that would solve this problem. During this process we then found out that WG wanted to standardize UDP fragmentation instead of IKEv2 over TCP. Is there really happend something that changes that? The old informal poll can be found from http://marc.info/?t=136326093500003&r=1&w=1 So how does your draft relate to the earlier ike over tcp draft? http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ike-tcp/ -- kivinen@iki.fi From nobody Tue Sep 15 20:20:52 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7836B1B3253 for ; Tue, 15 Sep 2015 20:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 3QpxVQjrKIAa for ; Tue, 15 Sep 2015 20:20:49 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B1FC1B3251 for ; Tue, 15 Sep 2015 20:20:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1442373648; x=2306287248; 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=KANHhI11BTsznCK26pKKM2iYldMgGOLGZLJubGnKFYw=; b=ewEVkuu76jAJvXUmfI0ToPkw4PMBEqZHZxUnGXUl2Xy/uQvsxPNBTRsw0jBxUr9W DGKyMryaVcWk2Cws6lcV/Jqo7WIlDYzCGRBasDkpRr5beJSJXeBnPFZCW2Revceh lvOSVwYPsQYk4f5pUNUNdi+YCSVKlsd7dprFZl6Jne/RwVgLUlp6pQVeByKO/CEG w6kKYO4bsKsiVqJJ6+wr+rYo90NjhLW3iF+8+LCXMJ2OWs5EuuzkrTvwnhTU8cXk nKerj8P682aRc+SZx62jGzOYkRPBXk2u/f++c2oxAreEVH1UoZK9CuwpRnK1sms5 rB4FjF+o3IY4/53FZpqF5A==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id C9.C2.24122.010E8F55; Tue, 15 Sep 2015 20:20:48 -0700 (PDT) X-AuditID: 11973e16-f79826d000005e3a-e3-55f8e010b2b3 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 31.02.22881.010E8F55; Tue, 15 Sep 2015 20:20:48 -0700 (PDT) Received: from [17.153.42.224] (unknown [17.153.42.224]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUR004142MNF3A0@chive.apple.com> for ipsec@ietf.org; Tue, 15 Sep 2015 20:20:48 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_FAB764B6-AE8F-474F-AF7F-4A1288FC1989" MIME-version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Tommy Pauly In-reply-to: <22008.52586.571113.776646@fireball.acr.fi> Date: Tue, 15 Sep 2015 20:20:48 -0700 Message-id: <59D64D44-FDB5-4020-9348-A955EF4B4023@apple.com> References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3094) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FAYpSvw4EeowcF/Bhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpS9G1gL5oVVzGm+xdbAeNiri5GTQ0LAROL2qfVsELaYxIV7 ELaQwF5GidkXhGBqbh45zNzFyAUU72aSWPrtKguE08Mk0fJ0PZDDwSEsICGxeU8iSAOzQJLE w4mbWUFsXgE9iUtTNjKC2MICphLXPz8Bi7MJqEgc/7aBGcTmFLCQ+H3iEguIzSKgKnHq/Q4m iDnyEr3/IXp5BWwkpp/YxQ5xXJbE21X9YIeKCChK7H6ylQniUFmJW19Xs4PcJiGwg03i7MpN 7BMYhWchuWkWkpsg4toSyxa+ZoawNSX2dy9nwRTXkOj8NpF1ASPbKkah3MTMHN3MPHO9xIKC nFS95PzcTYygeJhuJ7aD8eEqq0OMAhyMSjy8Ee3fQ4VYE8uKK3MPMUpzsCiJ8ya1/wgVEkhP LEnNTk0tSC2KLyrNSS0+xMjEwSnVwKh56Zwq87Hq6IkXe5LXs4gem7l/xQvOqD/yZ/SSFSYL dl1Pd66u+i7Lpp61/qcri9UzKYfVPjd9Z//QWZpmrbBD5PUzZ73XdvozP215qXhbkMu1ScGH Vy9y05J4BftYlwz9f8zNyxfu9t9y5sRKpTcyDXPrYtgVft8wP828oX3x1yjp829Kq5VYijMS DbWYi4oTAbs98bpoAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUi2FDMryvw4EeowbSnmhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpS9G1gL5oVVzGm+xdbAeNiri5GTQ0LAROLmkcPMELaYxIV7 69m6GLk4hAS6mSSWfrvKAuH0MEm0PF0P5HBwCAtISGzekwjSwCyQJPFw4mZWEJtXQE/i0pSN jCC2sICpxPXPT8DibAIqEse/bQBbwClgIfH7xCUWEJtFQFXi1PsdTBBz5CV6/0P08grYSEw/ sYsdxBYSyJJ4u6qfDcQWEVCU2P1kKxPEobISt76uZp/AKDALyRmzkJwBEdeWWLbwNTOErSmx v3s5C6a4hkTnt4msCxjZVjEKFKXmJFaa6SUWFOSk6iXn525iBAdwYdQOxoblVocYBTgYlXh4 I9q/hwqxJpYVV+YeYpTgYFYS4e3d/yNUiDclsbIqtSg/vqg0J7X4EONERqAvJzJLiSbnA+Mr ryTe0MTEwMTY2MzY2NzEnJbCSuK8Ca1AFwmkJ5akZqemFqQWwRzFxMEp1cAoozZfKLH8xbdl X8RfNpsyzL274p10z70tNi+tzqqdznh7/u7D+OjPK9SSiw872V26Gy/TelbtwM7NxzfcMbqR Ei/RY37r9Z6kP20z6qNd9Tt8j6jkn/e/xr/ymPJTk/zJXj7W2Y+Kbhy6s/36rgz2Fy/msE5k X9px/tS5yGOlW5JvHYva0BixU4mlOCPRUIu5qDgRACI+2yTTAgAA Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 03:20:51 -0000 --Apple-Mail=_FAB764B6-AE8F-474F-AF7F-4A1288FC1989 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Tero, I have read the previous draft for using TCP to avoid fragmentation = problems, and I believe that the new TCP-encapsulation draft is aimed at = solving a different use case with a different approach. The current standard for IKEv2 fragmentation is definitely the right = thing to do to avoid problems with networks that treat large UDP packets = badly, causing IKEv2 tunnel establishment problems. The new spec is very = specifically targeted at networks that block all UDP traffic, to be used = as a fallback mechanism only. Here=E2=80=99s a quick point-by-point comparison: draft-ietf-ipsecme-ike-tcp-01 (old draft) 1. Negotiated with an IKEv2 Notify payload. 2. IKE messages can use UDP or TCP within a single SA 3. Supports IKE packets only. 4. TLS/firewall traversal/ESP-in-TCP are non-goals. This draft was meant = to be used always, and putting all traffic over TCP or TLS had too high = overhead. draft-pauly-ipsecme-tcp-encaps-00 (new draft) 1. Non-negotiated, but pre-configured. Since the use case assumes that = all UDP is blocked, a connection must try over TCP without prior = communication if UDP gets no response. 2. All packets for a given IKE SA must use either UDP or TCP, with the = exception of migration over MOBIKE. 3. Encapsulates IKE and ESP packets, since the tunnel must also go over = TCP on a UDP-unfriendly network. 4. TLS and firewall traversal is the goal. This draft is meant to be = used only as a last resort, and details many performance considerations = to explain why the tunnel will work sufficiently, but is not ideal. I agree with the decision previously to go with IKEv2 fragmentation = rather than TCP. However, shipping clients still have serious problems = on networks that do block UDP traffic. There may always be some middle = boxes that do enough inspection and want to block IKE/IPSec traffic, = even over TCP and TLS, but the majority of cases in which IKEv2 cannot = be used will be, in our experience, solved by moving the connection to = TCP/TLS when needed. Other standards bodies, such as 3GPP, have published documents stating = that clients should do this for IWLAN, without giving specifics on how = the framing should be handled, or how it impacts the IKEv2 protocol. = See: = http://www.etsi.org/deliver/etsi_ts/133400_133499/133402/12.05.00_60/ts_13= 3402v120500p.pdf If IKEv2 servers start implementing support for TCP encapsulation based = on these documents, we may end up with diverging implementations, or = implementations that are not compatible with MOBIKE, etc. We believe = that a standard is needed to define how implementations should handle = this. Thanks, Tommy > On Sep 15, 2015, at 7:01 PM, Tero Kivinen wrote: >=20 > Tommy Pauly writes: >> I wanted to get a sense of WG interest in working on a standard for = running >> IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks = that >> currently block UDP traffic. >=20 > Before we made the UDP framentation document, our original plan was to > run IKEv2 over TCP, just because that would solve this problem. >=20 > During this process we then found out that WG wanted to standardize > UDP fragmentation instead of IKEv2 over TCP. >=20 > Is there really happend something that changes that? >=20 > The old informal poll can be found from=20 >=20 > = https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__marc.info_-3Ft-3D136= 326093500003-26r-3D1-26w-3D1&d=3DBQICAg&c=3DeEvniauFctOgLOKGJOplqw&r=3Dp3w= IGO08_H-OJhunJTPABw&m=3DYwqtMpmTqLSFY01PopC4Ane63G1nyZ04LeAcZPn94us&s=3Dui= zqLw8LM5bxVJAGGXyM2XfMCL4pT-B5pYfWxblhIEU&e=3D=20 >=20 > So how does your draft relate to the earlier ike over tcp draft?=20 >=20 > = https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__datatracker.ietf.org= _doc_draft-2Dietf-2Dipsecme-2Dike-2Dtcp_&d=3DBQICAg&c=3DeEvniauFctOgLOKGJO= plqw&r=3Dp3wIGO08_H-OJhunJTPABw&m=3DYwqtMpmTqLSFY01PopC4Ane63G1nyZ04LeAcZP= n94us&s=3Do7KJL1YNdcjmDXh8Nc2klEkemDtBi8TQ98-hMj-1q6k&e=3D=20 > --=20 > kivinen@iki.fi --Apple-Mail=_FAB764B6-AE8F-474F-AF7F-4A1288FC1989 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Tero,

I have read the previous draft for = using TCP to avoid fragmentation problems, and I believe that the new = TCP-encapsulation draft is aimed at solving a different use case with a = different approach.

The current standard for IKEv2 fragmentation is definitely = the right thing to do to avoid problems with networks that treat large = UDP packets badly, causing IKEv2 tunnel establishment problems. The new = spec is very specifically targeted at networks that block all UDP = traffic, to be used as a fallback mechanism only.
Here=E2=80=99s a quick point-by-point = comparison:

draft-ietf-ipsecme-ike-tcp-01 (old draft)
1. Negotiated with an IKEv2 Notify payload.
2. IKE messages can use UDP or TCP within a single = SA
3. Supports IKE packets only.
4. TLS/firewall traversal/ESP-in-TCP are non-goals. This = draft was meant to be used always, and putting all traffic over TCP or = TLS had too high overhead.

draft-pauly-ipsecme-tcp-encaps-00 (new = draft)
1. Non-negotiated, but pre-configured. = Since the use case assumes that all UDP is blocked, a connection must = try over TCP without prior communication if UDP gets no = response.
2. All packets for a given IKE SA must = use either UDP or TCP, with the exception of migration over = MOBIKE.
3. Encapsulates IKE and ESP packets, since = the tunnel must also go over TCP on a UDP-unfriendly network.
4. TLS and firewall traversal is the goal. This draft is = meant to be used only as a last resort, and details many performance = considerations to explain why the tunnel will work sufficiently, but is = not ideal.

I = agree with the decision previously to go with IKEv2 fragmentation rather = than TCP. However, shipping clients still have serious problems on = networks that do block UDP traffic. There may always be some middle = boxes that do enough inspection and want to block IKE/IPSec traffic, = even over TCP and TLS, but the majority of cases in which IKEv2 cannot = be used will be, in our experience, solved by moving the connection to = TCP/TLS when needed.

Other standards bodies, such as 3GPP, have published = documents stating that clients should do this for IWLAN, without giving = specifics on how the framing should be handled, or how it impacts the = IKEv2 protocol. See: http://www.etsi.org/deliver/etsi_ts/133400_133499/133402/12.05.= 00_60/ts_133402v120500p.pdf

If IKEv2 servers start implementing = support for TCP encapsulation based on these documents, we may end up = with diverging implementations, or implementations that are not = compatible with MOBIKE, etc. We believe that a standard is needed to = define how implementations should handle this.

Thanks,
Tommy

On Sep 15, 2015, at 7:01 PM, Tero Kivinen = <kivinen@iki.fi> = wrote:

Tommy Pauly writes:
I wanted to get a sense of WG interest in working on a = standard for running
IKEv2/IPSec over a TCP (or TLS/TCP) = connection to traverse networks that
currently block UDP = traffic.

Before we made the = UDP framentation document, our original plan was to
run = IKEv2 over TCP, just because that would solve this problem.

During this process we then found out that WG = wanted to standardize
UDP fragmentation instead of IKEv2 = over TCP.

Is there really happend something = that changes that?

The old informal poll = can be found from

https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__marc.info= _-3Ft-3D136326093500003-26r-3D1-26w-3D1&d=3DBQICAg&c=3DeEvniauFctO= gLOKGJOplqw&r=3Dp3wIGO08_H-OJhunJTPABw&m=3DYwqtMpmTqLSFY01PopC4Ane= 63G1nyZ04LeAcZPn94us&s=3DuizqLw8LM5bxVJAGGXyM2XfMCL4pT-B5pYfWxblhIEU&a= mp;e=3D

So how does your draft relate = to the earlier ike over tcp draft?

https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__datatrack= er.ietf.org_doc_draft-2Dietf-2Dipsecme-2Dike-2Dtcp_&d=3DBQICAg&c=3D= eEvniauFctOgLOKGJOplqw&r=3Dp3wIGO08_H-OJhunJTPABw&m=3DYwqtMpmTqLSF= Y01PopC4Ane63G1nyZ04LeAcZPn94us&s=3Do7KJL1YNdcjmDXh8Nc2klEkemDtBi8TQ98= -hMj-1q6k&e=3D
--
kivinen@iki.fi

= --Apple-Mail=_FAB764B6-AE8F-474F-AF7F-4A1288FC1989-- From nobody Wed Sep 16 00:54:57 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B3E1B386A for ; Wed, 16 Sep 2015 00:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 QroEYrGXAmqJ for ; Wed, 16 Sep 2015 00:54:54 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c: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 AE5161B3867 for ; Wed, 16 Sep 2015 00:54:53 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so61212190wic.1 for ; Wed, 16 Sep 2015 00:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=RoVTbSwYedyqCLjycKLWcgOku7PwT3Z3Yrr9MsOH8k8=; b=D9tg11T95/6BZ/yD2kF+7mI8cjhRXy/wTXloczqW/LkcnbOYhaOl+YCwHUbPgukqnB NN8lPXy3lODIqMWIuntKVcK+XN3PetFs3oG6MjzBDZexmm4S3JFzWXtqU0RXeTjiV3fL UNMupT4UblESkXTlr7plHsgJn621itXztO+zVnlV8zg//SopA0HhGm1qXEfFrKEk3PU9 wUxKhVkbxV1xY+Lpb+8wP92utMXikdJDi4cQnv84c3aQnJOQ2nWW5fLvyed0I6s9nd+c Mv9MmZUcBPYFMSoXOBnYyoyfwvLzRR63GBVhMjBnxU/FHjW87WTTp0ZIIVlBgVBv8tLI ntwA== X-Received: by 10.180.84.162 with SMTP id a2mr16759021wiz.70.1442390092231; Wed, 16 Sep 2015 00:54:52 -0700 (PDT) Received: from [192.168.0.28] ([197.237.253.28]) by smtp.gmail.com with ESMTPSA id lu5sm25129057wjb.9.2015.09.16.00.54.50 for (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 00:54:51 -0700 (PDT) From: Les Leposo Content-Type: multipart/alternative; boundary="Apple-Mail=_0FDD9D4C-814A-4CC5-BB95-765940BE76FC" Message-Id: <42B59CB1-256A-45F1-83F5-D2E371E0853F@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Date: Wed, 16 Sep 2015 10:54:40 +0300 References: To: ipsec@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [IPsec] IPsec Digest, Vol 137, Issue 6 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 07:54:56 -0000 --Apple-Mail=_0FDD9D4C-814A-4CC5-BB95-765940BE76FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Sep 16, 2015, at 6:20 AM, ipsec-request@ietf.org wrote: >=20 > Message: 4 > Date: Wed, 16 Sep 2015 05:01:14 +0300 > From: Tero Kivinen > > To: Tommy Pauly > > Cc: IPsecME WG > > Subject: [IPsec] WG Interest in TCP Encapsulation > Message-ID: <22008.52586.571113.776646@fireball.acr.fi = > > Content-Type: text/plain; charset=3Dus-ascii >=20 > Tommy Pauly writes: >> I wanted to get a sense of WG interest in working on a standard for = running >> IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks = that >> currently block UDP traffic. >=20 > Before we made the UDP framentation document, our original plan was to > run IKEv2 over TCP, just because that would solve this problem. >=20 > During this process we then found out that WG wanted to standardize > UDP fragmentation instead of IKEv2 over TCP. >=20 > Is there really happend something that changes that? >=20 > The old informal poll can be found from=20 >=20 > http://marc.info/?t=3D136326093500003&r=3D1&w=3D1 = >=20 2013 was a long time ago (in terms of technology, security and usage = trends), besides the group now seems to have broader (perhaps more = diverse) participation. imho, It=E2=80=99s time for a new poll and most probably a new/updated = draft. my $.02 --Apple-Mail=_0FDD9D4C-814A-4CC5-BB95-765940BE76FC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Sep 16, 2015, at 6:20 AM, ipsec-request@ietf.org wrote:

Message: 4
Date: Wed, 16 Sep 2015 05:01:14 = +0300
From: Tero Kivinen = <kivinen@iki.fi>
To: Tommy Pauly <tpauly@apple.com>
Cc: IPsecME WG <ipsec@ietf.org>
Subject: [IPsec]  WG = Interest in TCP Encapsulation
Message-ID: <22008.52586.571113.776646@fireball.acr.fi>
Content-Type: text/plain; = charset=3Dus-ascii

Tommy Pauly = writes:
I wanted to get a sense = of WG interest in working on a standard for running
IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse = networks that
currently block UDP traffic.

Before we made the UDP = framentation document, our original plan was to
run IKEv2 over TCP, just because = that would solve this problem.

During this process we then = found out that WG wanted to standardize
UDP fragmentation instead of = IKEv2 over TCP.

Is there really happend = something that changes that?

The old informal poll can be = found from 

http://marc.info/?t=3D136326093500003&r=3D1&w=3D1

2013 was a long time ago (in terms of technology, = security and usage trends), besides the group now seems to have broader = (perhaps more diverse) participation.
imho, It=E2=80=99s = time for a new poll and most probably a new/updated draft.

my = $.02

= --Apple-Mail=_0FDD9D4C-814A-4CC5-BB95-765940BE76FC-- From nobody Wed Sep 16 05:46:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495AD1B29FA for ; Wed, 16 Sep 2015 05:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 6bnQiuUmDYI8 for ; Wed, 16 Sep 2015 05:45:57 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c: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 2C4681B29F8 for ; Wed, 16 Sep 2015 05:45:57 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so72346963wic.1 for ; Wed, 16 Sep 2015 05:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VkOofEyiP8Of8HAXJWES3GUX5Vj3DUAZn1Ysb5d3s1o=; b=CCu7m6vPNkyoUxAcSfeD27lqVaJM2xxL9vgWXNigquKLA+/1FqaBfd9ERKpFTX6eKy ss8dyqSwv/YMiA8p3dnOFj8+R+b4ifKTmdBzIr8y/b11ezh3/hUN+rGLZKw0ODByRXcC MkxBRcanROSV5Lulmt0k5BECXjzZbHlX9ejlufnUZKvgZ9q1TllT2gWnFJ07zG1DJnmt /X3sUHnEZY1zA8zrstC+4mGjvujivNvIJEvUsWQS1nw3oCmNjMNjS1Odov/RpHc5tTXK X+nx7XX84ZpVWR01sMbKDrPtuf0hIMRra8G3sVi7gdWDvYE9cZyx0jm1AfMyBr3vWevE MV3Q== X-Received: by 10.180.20.177 with SMTP id o17mr17955634wie.93.1442407555793; Wed, 16 Sep 2015 05:45:55 -0700 (PDT) Received: from [172.24.248.153] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id h8sm4324520wib.21.2015.09.16.05.45.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 16 Sep 2015 05:45:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <22008.52586.571113.776646@fireball.acr.fi> Date: Wed, 16 Sep 2015 15:45:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.2104) Archived-At: Cc: IPsecME WG , Tommy Pauly Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 12:45:59 -0000 > On Sep 16, 2015, at 5:01 AM, Tero Kivinen wrote: >=20 > Tommy Pauly writes: >> I wanted to get a sense of WG interest in working on a standard for = running >> IKEv2/IPSec over a TCP (or TLS/TCP) connection to traverse networks = that >> currently block UDP traffic. >=20 > Before we made the UDP framentation document, our original plan was to > run IKEv2 over TCP, just because that would solve this problem. >=20 > During this process we then found out that WG wanted to standardize > UDP fragmentation instead of IKEv2 over TCP. >=20 > Is there really happend something that changes that? >=20 > The old informal poll can be found from=20 >=20 > http://marc.info/?t=3D136326093500003&r=3D1&w=3D1 >=20 > So how does your draft relate to the earlier ike over tcp draft?=20 >=20 > http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ike-tcp/ Hi, Tero At the time that we (at my suggestion) dropped the work on IKE over TCP = it was because of a conclusion we had reached: In all the cases where IKE over TCP solves your connectivity issues but = IKE fragmentation doesn=E2=80=99t, the IPsec would fail. At the time, the WG was not in favor of running the IPsec over that TCP = connection, so there seemed to be little point. This draft is proposing both IKE and ESP over the TCP connection, so the = protocol will work in situations where UDP (even with fragmentation at = the IKE rather than IP layer) fails. We=E2=80=99ve had something like this working with IKEv1 for over 10 = years. Many vendors have =E2=80=9CSSL VPN=E2=80=9D solutions that have = pretty much the same performance, scalability, and connectivity = characteristics. There=E2=80=99s ample evidence that this kind of = solution works. And although the need is slowly diminishing (more and = more public networks allow IKE and IPsec to work), there are still many = places where we still need to tunnel everything over TCP. It it hasn=E2=80=99t been clear, I am in favor of adopting this draft. Yoav From nobody Thu Sep 17 08:19:52 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679091B3822 for ; Wed, 16 Sep 2015 00:25:08 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham 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 BWO7CoNVw5a7 for ; Wed, 16 Sep 2015 00:25:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4781B381F for ; Wed, 16 Sep 2015 00:25:05 -0700 (PDT) X-AuditID: c6180641-f792c6d00000686a-0b-55f8aadb898b Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 79.49.26730.BDAA8F55; Wed, 16 Sep 2015 01:33:47 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0248.002; Wed, 16 Sep 2015 03:09:55 -0400 From: Samy Touati To: Tero Kivinen Thread-Topic: [IPsec] WG Interest in TCP Encapsulation Thread-Index: AdDwTq/Brk4ZaFDuQIKr2M3PbrgipA== Date: Wed, 16 Sep 2015 07:09:54 +0000 Message-ID: <66a50285-3a04-4b8b-99f6-d0664b69a06d@ericsson.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----8324A7AC30A5DD5BB3CDAF9894843679" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprAIsWRmVeSWpSXmKPExsUyuXRPrO7tVT9CDe42aFjs3/KCzeLo+eds FhNPHGR1YPbYevIHm8eSJT+ZPA5/XcgSwBzFZZOSmpNZllqkb5fAlXHo+RX2gidzGSt+HZnD 1sC4fSZjFyMnh4SAicSlX59ZIWwxiQv31rN1MXJxCAkcZZT4cOk6O0hCSGA5o8Sy55UgNpuA jsTlzTNYQGwRAUWJ3U+2MoHYzAL2Equab4MNFRYwlbj++QkrRI2ZxKd375ggbD2JfT9/gsVZ BFQlpu34AzafF6h3yZTjYHFGAVmJ3WevQ80Ul7j1ZD4TxHEiEg8vnmaDsEUlXj7+xwpyKLNA B6PE6pXv2SAGCUqcnPmEZQKj0Cwk/bOQ1c1CUjeLkQMoESvR/bEcol5d4s+8S8wQtqLElO6H 7BAlahLLWpVQhUFsW4n9V1cyY4qbSrw++pFxASP3KkaO0uLUstx0I8NNjMAoPCbB5riDccEn y0OMAhyMSjy8D6b8CBViTSwrrsw9xCjNwaIkzjtvxv1QIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYyr97opb1O1lnjwq3yrHFd/4pXZ29+nCdnGqrQ/yPlUus1Y0aHk1gS+wP3bJZOE78l0 TloU+CJhW7v5M57bvFyMB0LfXzEKuvayay6vatvHLRJVO8Mko7vOffUMqlkV/MbZJ3n9hdLp zItmvegsyvykUNYvrLtbMNyFbWL6zY2tEpLz/QusfiqxFGckGmoxFxUnAgAN82TzowIAAA== Archived-At: X-Mailman-Approved-At: Thu, 17 Sep 2015 08:19:50 -0700 Cc: IPsecME WG , Tommy Pauly Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2015 07:25:08 -0000 ------8324A7AC30A5DD5BB3CDAF9894843679 Content-Type: multipart/alternative; boundary=--_com.ninefolders.hd3.email_20346638796759_alt ----_com.ninefolders.hd3.email_20346638796759_alt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgVGVybywKCkZyb20gYSBnYXRld2F5IHBlcnNwZWN0aXZlIGhhdmluZyBhIHN0YW5kYXJkaXpl ZCBpbXBsZW1lbnRhdGlvbiBmcm9tIHRlcm1pbmFscyBmb3IgdGNwIGVuY2Fwc3VsYXRpb24gb2Yg aXBzZWMgaXMgc29tZXRoaW5nIHdoaWNoIGlzIG5lZWRlZC7CoApUaGUgdW50cnVzdGVkIFdpLUZp IGFyY2hpdGVjdHVyZSBkZWZpbmVkIGluIDNncHAgaXMgdXNlZCBmb3Igdm9pY2UgdHJhZmZpYywg YW5kIGlzIGJlaW5nIGRlcGxveWVkIGJ5IG11bHRpcGxlIGNhcnJpZXJzLsKgClRoZSBtb2JpbGUg ZGV2aWNlIG1heSBiZSBjb25uZWN0ZWQgdG8gbmV0d29ya3Mgb25seSBhbGxvd2luZyAid2ViIHRy YWZmaWMiIG9yIHVzaW5nIGEgd2ViIHByb3h5LCBhbmQgdGhpcyBkcmFmdCBwcm92aWRlIG1vYmls ZSBkZXZpY2VzIHdpdGggYSBzdGFuZGFyZGl6ZWQgbWV0aG9kIHRvIHN0aWxsIHVzZSBpcHNlYy7C oApUaGUgcGVyZm9ybWFuY2UgaW1wYWN0cyBvbiB0aGUgZ2F0ZXdheSDCoGFyZSBtaXRpZ2F0ZWQg d2l0aCB0aGUgb24tZGVtYW5kIHVzZSBvZiBUQ1AgZW5jYXBzdWxhdGlvbiBieSBtb2JpbGUgZGV2 aWNlcy7CoAoKVGhhbmtzClNhbXkuwqAKCgoKRnJvbTogVG9tbXkgUGF1bHkgPHRwYXVseUBhcHBs ZS5jb20+ClNlbnQ6IFNlcCAxNSwgMjAxNSA4OjIwIFBNClRvOiBUZXJvIEtpdmluZW4KQ2M6IElQ c2VjTUUgV0cKU3ViamVjdDogUmU6IFtJUHNlY10gV0cgSW50ZXJlc3QgaW4gVENQIEVuY2Fwc3Vs YXRpb24KCkhlbGxvIFRlcm8sCgpJIGhhdmUgcmVhZCB0aGUgcHJldmlvdXMgZHJhZnQgZm9yIHVz aW5nIFRDUCB0byBhdm9pZCBmcmFnbWVudGF0aW9uIHByb2JsZW1zLCBhbmQgSSBiZWxpZXZlIHRo YXQgdGhlIG5ldyBUQ1AtZW5jYXBzdWxhdGlvbiBkcmFmdCBpcyBhaW1lZCBhdCBzb2x2aW5nIGEg ZGlmZmVyZW50IHVzZSBjYXNlIHdpdGggYSBkaWZmZXJlbnQgYXBwcm9hY2guCgpUaGUgY3VycmVu dCBzdGFuZGFyZCBmb3IgSUtFdjIgZnJhZ21lbnRhdGlvbiBpcyBkZWZpbml0ZWx5IHRoZSByaWdo dCB0aGluZyB0byBkbyB0byBhdm9pZCBwcm9ibGVtcyB3aXRoIG5ldHdvcmtzIHRoYXQgdHJlYXQg bGFyZ2UgVURQIHBhY2tldHMgYmFkbHksIGNhdXNpbmcgSUtFdjIgdHVubmVsIGVzdGFibGlzaG1l bnQgcHJvYmxlbXMuIFRoZSBuZXcgc3BlYyBpcyB2ZXJ5IHNwZWNpZmljYWxseSB0YXJnZXRlZCBh dCBuZXR3b3JrcyB0aGF0IGJsb2NrIGFsbCBVRFAgdHJhZmZpYywgdG8gYmUgdXNlZCBhcyBhIGZh bGxiYWNrIG1lY2hhbmlzbSBvbmx5LgoKSGVyZeKAmXMgYSBxdWljayBwb2ludC1ieS1wb2ludCBj b21wYXJpc29uOgoKZHJhZnQtaWV0Zi1pcHNlY21lLWlrZS10Y3AtMDEgKG9sZCBkcmFmdCkKMS4g TmVnb3RpYXRlZCB3aXRoIGFuIElLRXYyIE5vdGlmeSBwYXlsb2FkLgoyLiBJS0UgbWVzc2FnZXMg Y2FuIHVzZSBVRFAgb3IgVENQIHdpdGhpbiBhIHNpbmdsZSBTQQozLiBTdXBwb3J0cyBJS0UgcGFj a2V0cyBvbmx5Lgo0LiBUTFMvZmlyZXdhbGwgdHJhdmVyc2FsL0VTUC1pbi1UQ1AgYXJlIG5vbi1n b2Fscy4gVGhpcyBkcmFmdCB3YXMgbWVhbnQgdG8gYmUgdXNlZCBhbHdheXMsIGFuZCBwdXR0aW5n IGFsbCB0cmFmZmljIG92ZXIgVENQIG9yIFRMUyBoYWQgdG9vIGhpZ2ggb3ZlcmhlYWQuCgpkcmFm dC1wYXVseS1pcHNlY21lLXRjcC1lbmNhcHMtMDAgKG5ldyBkcmFmdCkKMS4gTm9uLW5lZ290aWF0 ZWQsIGJ1dCBwcmUtY29uZmlndXJlZC4gU2luY2UgdGhlIHVzZSBjYXNlIGFzc3VtZXMgdGhhdCBh bGwgVURQIGlzIGJsb2NrZWQsIGEgY29ubmVjdGlvbiBtdXN0IHRyeSBvdmVyIFRDUCB3aXRob3V0 IHByaW9yIGNvbW11bmljYXRpb24gaWYgVURQIGdldHMgbm8gcmVzcG9uc2UuCjIuIEFsbCBwYWNr ZXRzIGZvciBhIGdpdmVuIElLRSBTQSBtdXN0IHVzZSBlaXRoZXIgVURQIG9yIFRDUCwgd2l0aCB0 aGUgZXhjZXB0aW9uIG9mIG1pZ3JhdGlvbiBvdmVyIE1PQklLRS4KMy4gRW5jYXBzdWxhdGVzIElL RSBhbmQgRVNQIHBhY2tldHMsIHNpbmNlIHRoZSB0dW5uZWwgbXVzdCBhbHNvIGdvIG92ZXIgVENQ IG9uIGEgVURQLXVuZnJpZW5kbHkgbmV0d29yay4KNC4gVExTIGFuZCBmaXJld2FsbCB0cmF2ZXJz YWwgaXMgdGhlIGdvYWwuIFRoaXMgZHJhZnQgaXMgbWVhbnQgdG8gYmUgdXNlZCBvbmx5IGFzIGEg bGFzdCByZXNvcnQsIGFuZCBkZXRhaWxzIG1hbnkgcGVyZm9ybWFuY2UgY29uc2lkZXJhdGlvbnMg dG8gZXhwbGFpbiB3aHkgdGhlIHR1bm5lbCB3aWxsIHdvcmsgc3VmZmljaWVudGx5LCBidXQgaXMg bm90IGlkZWFsLgoKSSBhZ3JlZSB3aXRoIHRoZSBkZWNpc2lvbiBwcmV2aW91c2x5IHRvIGdvIHdp dGggSUtFdjIgZnJhZ21lbnRhdGlvbiByYXRoZXIgdGhhbiBUQ1AuIEhvd2V2ZXIsIHNoaXBwaW5n IGNsaWVudHMgc3RpbGwgaGF2ZSBzZXJpb3VzIHByb2JsZW1zIG9uIG5ldHdvcmtzIHRoYXQgZG8g YmxvY2sgVURQIHRyYWZmaWMuIFRoZXJlIG1heSBhbHdheXMgYmUgc29tZSBtaWRkbGUgYm94ZXMg dGhhdCBkbyBlbm91Z2ggaW5zcGVjdGlvbiBhbmQgd2FudCB0byBibG9jayBJS0UvSVBTZWMgdHJh ZmZpYywgZXZlbiBvdmVyIFRDUCBhbmQgVExTLCBidXQgdGhlIG1ham9yaXR5IG9mIGNhc2VzIGlu IHdoaWNoIElLRXYyIGNhbm5vdCBiZSB1c2VkIHdpbGwgYmUsIGluIG91ciBleHBlcmllbmNlLCBz b2x2ZWQgYnkgbW92aW5nIHRoZSBjb25uZWN0aW9uIHRvIFRDUC9UTFMgd2hlbiBuZWVkZWQuCgpP dGhlciBzdGFuZGFyZHMgYm9kaWVzLCBzdWNoIGFzIDNHUFAsIGhhdmUgcHVibGlzaGVkIGRvY3Vt ZW50cyBzdGF0aW5nIHRoYXQgY2xpZW50cyBzaG91bGQgZG8gdGhpcyBmb3IgSVdMQU4sIHdpdGhv dXQgZ2l2aW5nIHNwZWNpZmljcyBvbiBob3cgdGhlIGZyYW1pbmcgc2hvdWxkIGJlIGhhbmRsZWQs IG9yIGhvdyBpdCBpbXBhY3RzIHRoZSBJS0V2MiBwcm90b2NvbC4gU2VlOsKgaHR0cDovL3d3dy5l dHNpLm9yZy9kZWxpdmVyL2V0c2lfdHMvMTMzNDAwXzEzMzQ5OS8xMzM0MDIvMTIuMDUuMDBfNjAv dHNfMTMzNDAydjEyMDUwMHAucGRmCgpJZiBJS0V2MiBzZXJ2ZXJzIHN0YXJ0IGltcGxlbWVudGlu ZyBzdXBwb3J0IGZvciBUQ1AgZW5jYXBzdWxhdGlvbiBiYXNlZCBvbiB0aGVzZSBkb2N1bWVudHMs IHdlIG1heSBlbmQgdXAgd2l0aCBkaXZlcmdpbmcgaW1wbGVtZW50YXRpb25zLCBvciBpbXBsZW1l bnRhdGlvbnMgdGhhdCBhcmUgbm90IGNvbXBhdGlibGUgd2l0aCBNT0JJS0UsIGV0Yy4gV2UgYmVs aWV2ZSB0aGF0IGEgc3RhbmRhcmQgaXMgbmVlZGVkIHRvIGRlZmluZSBob3cgaW1wbGVtZW50YXRp b25zIHNob3VsZCBoYW5kbGUgdGhpcy4KClRoYW5rcywKVG9tbXkKCj4gT24gU2VwIDE1LCAyMDE1 LCBhdCA3OjAxIFBNLCBUZXJvIEtpdmluZW4gPGtpdmluZW5AaWtpLmZpPiB3cm90ZToKPgo+IFRv bW15IFBhdWx5IHdyaXRlczoKPj4KPj4gSSB3YW50ZWQgdG8gZ2V0IGEgc2Vuc2Ugb2YgV0cgaW50 ZXJlc3QgaW4gd29ya2luZyBvbiBhIHN0YW5kYXJkIGZvciBydW5uaW5nCj4+IElLRXYyL0lQU2Vj IG92ZXIgYSBUQ1AgKG9yIFRMUy9UQ1ApIGNvbm5lY3Rpb24gdG8gdHJhdmVyc2UgbmV0d29ya3Mg dGhhdAo+PiBjdXJyZW50bHkgYmxvY2sgVURQIHRyYWZmaWMuCj4KPgo+IEJlZm9yZSB3ZSBtYWRl IHRoZSBVRFAgZnJhbWVudGF0aW9uIGRvY3VtZW50LCBvdXIgb3JpZ2luYWwgcGxhbiB3YXMgdG8K PiBydW4gSUtFdjIgb3ZlciBUQ1AsIGp1c3QgYmVjYXVzZSB0aGF0IHdvdWxkIHNvbHZlIHRoaXMg cHJvYmxlbS4KPgo+IER1cmluZyB0aGlzIHByb2Nlc3Mgd2UgdGhlbiBmb3VuZCBvdXQgdGhhdCBX RyB3YW50ZWQgdG8gc3RhbmRhcmRpemUKPiBVRFAgZnJhZ21lbnRhdGlvbiBpbnN0ZWFkIG9mIElL RXYyIG92ZXIgVENQLgo+Cj4gSXMgdGhlcmUgcmVhbGx5IGhhcHBlbmQgc29tZXRoaW5nIHRoYXQg Y2hhbmdlcyB0aGF0Pwo+Cj4gVGhlIG9sZCBpbmZvcm1hbCBwb2xsIGNhbiBiZSBmb3VuZCBmcm9t IAo+Cj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0Ff X21hcmMuaW5mb18tM0Z0LTNEMTM2MzI2MDkzNTAwMDAzLTI2ci0zRDEtMjZ3LTNEMSZkPUJRSUNB ZyZjPWVFdm5pYXVGY3RPZ0xPS0dKT3BscXcmcj1wM3dJR08wOF9ILU9KaHVuSlRQQUJ3Jm09WXdx dE1wbVRxTFNGWTAxUG9wQzRBbmU2M0cxbnlaMDRMZUFjWlBuOTR1cyZzPXVpenFMdzhMTTVieFZK QUdHWHlNMlhmTUNMNHBULUI1cFlmV3hibGhJRVUmZT0gCj4KPiBTbyBob3cgZG9lcyB5b3VyIGRy YWZ0IHJlbGF0ZSB0byB0aGUgZWFybGllciBpa2Ugb3ZlciB0Y3AgZHJhZnQ/IAo+Cj4gaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX2RhdGF0cmFja2Vy LmlldGYub3JnX2RvY19kcmFmdC0yRGlldGYtMkRpcHNlY21lLTJEaWtlLTJEdGNwXyZkPUJRSUNB ZyZjPWVFdm5pYXVGY3RPZ0xPS0dKT3BscXcmcj1wM3dJR08wOF9ILU9KaHVuSlRQQUJ3Jm09WXdx dE1wbVRxTFNGWTAxUG9wQzRBbmU2M0cxbnlaMDRMZUFjWlBuOTR1cyZzPW83S0pMMVlOZGNqbURY aDhOYzJrbEVrZW1EdEJpOFRROTgtaE1qLTFxNmsmZT0gCj4gLS0gCj4ga2l2aW5lbkBpa2kuZmkK Cgo= ----_com.ninefolders.hd3.email_20346638796759_alt Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1z ZXJpZjsgZm9udC1zaXplOjEyLjBwdDsgY29sb3I6IzFGNDk3RCI+PGRpdj5IaSBUZXJvLDwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+RnJvbSBhIGdhdGV3YXkgcGVyc3BlY3RpdmUgaGF2aW5nIGEg c3RhbmRhcmRpemVkIGltcGxlbWVudGF0aW9uIGZyb20gdGVybWluYWxzIGZvciB0Y3AgZW5jYXBz dWxhdGlvbiBvZiBpcHNlYyBpcyBzb21ldGhpbmcgd2hpY2ggaXMgbmVlZGVkLiZuYnNwOzwvZGl2 PjxkaXY+VGhlIHVudHJ1c3RlZCBXaS1GaSBhcmNoaXRlY3R1cmUgZGVmaW5lZCBpbiAzZ3BwIGlz IHVzZWQgZm9yIHZvaWNlIHRyYWZmaWMsIGFuZCBpcyBiZWluZyBkZXBsb3llZCBieSBtdWx0aXBs ZSBjYXJyaWVycy4mbmJzcDs8L2Rpdj48ZGl2PlRoZSBtb2JpbGUgZGV2aWNlIG1heSBiZSBjb25u ZWN0ZWQgdG8gbmV0d29ya3Mgb25seSBhbGxvd2luZyAid2ViIHRyYWZmaWMiIG9yIHVzaW5nIGEg d2ViIHByb3h5LCBhbmQgdDxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGxpbmUtaGVpZ2h0 OiAxNTAlOyI+aGlzIGRyYWZ0IHByb3ZpZGUgbW9iaWxlIGRldmljZXMgd2l0aCBhIHN0YW5kYXJk aXplZCBtZXRob2QgdG8gc3RpbGwgdXNlIGlwc2VjLiZuYnNwOzwvc3Bhbj48L2Rpdj48ZGl2PlRo ZSBwZXJmb3JtYW5jZSBpbXBhY3RzIG9uIHRoZSBnYXRld2F5ICZuYnNwO2FyZSBtaXRpZ2F0ZWQg d2l0aCB0aGUgb24tZGVtYW5kIHVzZSBvZiBUQ1AgZW5jYXBzdWxhdGlvbiBieSBtb2JpbGUgZGV2 aWNlcy4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rczwvZGl2PjxkaXY+U2Ft eS4mbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj4KPGRpdj48YnI+PC9kaXY+CjwvZGl2PjxkaXYg aWQ9InF1b3RlZF9oZWFkZXIiIHN0eWxlPSJjbGVhcjpib3RoOyI+PGJyLz48ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZiI+PGI+RnJvbTo8L2I+IFRvbW15IFBh dWx5ICZsdDt0cGF1bHlAYXBwbGUuY29tJmd0Ozxicj48Yj5TZW50OjwvYj4gU2VwIDE1LCAyMDE1 IDg6MjAgUE08YnI+PGI+VG86PC9iPiBUZXJvIEtpdmluZW48YnI+PGI+Q2M6PC9iPiBJUHNlY01F IFdHPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW0lQc2VjXSBXRyBJbnRlcmVzdCBpbiBUQ1AgRW5j YXBzdWxhdGlvbjxicj48L3NwYW4+PC9kaXY+PC9kaXY+PGJyIHR5cGU9J2F0dHJpYnV0aW9uJz48 ZGl2IGlkPSJxdW90ZWRfYm9keSI+Cgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CgoKPGRpdiBjbGFzcz0iIj5IZWxsbyBU ZXJvLDwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9 IiI+SSBoYXZlIHJlYWQgdGhlIHByZXZpb3VzIGRyYWZ0IGZvciB1c2luZyBUQ1AgdG8gYXZvaWQg ZnJhZ21lbnRhdGlvbiBwcm9ibGVtcywgYW5kIEkgYmVsaWV2ZSB0aGF0IHRoZSBuZXcgVENQLWVu Y2Fwc3VsYXRpb24gZHJhZnQgaXMgYWltZWQgYXQgc29sdmluZyBhIGRpZmZlcmVudCB1c2UgY2Fz ZSB3aXRoIGEgZGlmZmVyZW50IGFwcHJvYWNoLjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4KPC9kaXY+CjxkaXYgY2xhc3M9IiI+VGhlIGN1cnJlbnQgc3RhbmRhcmQgZm9yIElLRXYy IGZyYWdtZW50YXRpb24gaXMgZGVmaW5pdGVseSB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gdG8gYXZv aWQgcHJvYmxlbXMgd2l0aCBuZXR3b3JrcyB0aGF0IHRyZWF0IGxhcmdlIFVEUCBwYWNrZXRzIGJh ZGx5LCBjYXVzaW5nIElLRXYyIHR1bm5lbCBlc3RhYmxpc2htZW50IHByb2JsZW1zLiBUaGUgbmV3 IHNwZWMgaXMgdmVyeSBzcGVjaWZpY2FsbHkgdGFyZ2V0ZWQgYXQgbmV0d29ya3MKIHRoYXQgYmxv Y2sgYWxsIFVEUCB0cmFmZmljLCB0byBiZSB1c2VkIGFzIGEgZmFsbGJhY2sgbWVjaGFuaXNtIG9u bHkuPC9kaXY+CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0i Ij5IZXJl4oCZcyBhIHF1aWNrIHBvaW50LWJ5LXBvaW50IGNvbXBhcmlzb246PC9kaXY+CjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj48YiBjbGFzcz0iIj5k cmFmdC1pZXRmLWlwc2VjbWUtaWtlLXRjcC0wMSAob2xkIGRyYWZ0KTwvYj48L2Rpdj4KPGRpdiBj bGFzcz0iIj4xLiBOZWdvdGlhdGVkIHdpdGggYW4gSUtFdjIgTm90aWZ5IHBheWxvYWQuPC9kaXY+ CjxkaXYgY2xhc3M9IiI+Mi4gSUtFIG1lc3NhZ2VzIGNhbiB1c2UgVURQIG9yIFRDUCB3aXRoaW4g YSBzaW5nbGUgU0E8L2Rpdj4KPGRpdiBjbGFzcz0iIj4zLiBTdXBwb3J0cyBJS0UgcGFja2V0cyBv bmx5LjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPjQuIFRMUy9maXJld2FsbCB0cmF2ZXJzYWwvRVNQLWlu LVRDUCBhcmUgbm9uLWdvYWxzLiBUaGlzIGRyYWZ0IHdhcyBtZWFudCB0byBiZSB1c2VkIGFsd2F5 cywgYW5kIHB1dHRpbmcgYWxsIHRyYWZmaWMgb3ZlciBUQ1Agb3IgVExTIGhhZCB0b28gaGlnaCBv dmVyaGVhZC48L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8ZGl2IGNs YXNzPSIiPjxiIGNsYXNzPSIiPmRyYWZ0LXBhdWx5LWlwc2VjbWUtdGNwLWVuY2Fwcy0wMCAobmV3 IGRyYWZ0KTwvYj48L2Rpdj4KPGRpdiBjbGFzcz0iIj4xLiBOb24tbmVnb3RpYXRlZCwgYnV0IHBy ZS1jb25maWd1cmVkLiBTaW5jZSB0aGUgdXNlIGNhc2UgYXNzdW1lcyB0aGF0IGFsbCBVRFAgaXMg YmxvY2tlZCwgYSBjb25uZWN0aW9uIG11c3QgdHJ5IG92ZXIgVENQIHdpdGhvdXQgcHJpb3IgY29t bXVuaWNhdGlvbiBpZiBVRFAgZ2V0cyBubyByZXNwb25zZS48L2Rpdj4KPGRpdiBjbGFzcz0iIj4y LiBBbGwgcGFja2V0cyBmb3IgYSBnaXZlbiBJS0UgU0EgbXVzdCB1c2UgZWl0aGVyIFVEUCBvciBU Q1AsIHdpdGggdGhlIGV4Y2VwdGlvbiBvZiBtaWdyYXRpb24gb3ZlciBNT0JJS0UuPC9kaXY+Cjxk aXYgY2xhc3M9IiI+My4gRW5jYXBzdWxhdGVzIElLRSBhbmQgRVNQIHBhY2tldHMsIHNpbmNlIHRo ZSB0dW5uZWwgbXVzdCBhbHNvIGdvIG92ZXIgVENQIG9uIGEgVURQLXVuZnJpZW5kbHkgbmV0d29y ay48L2Rpdj4KPGRpdiBjbGFzcz0iIj40LiBUTFMgYW5kIGZpcmV3YWxsIHRyYXZlcnNhbCBpcyB0 aGUgZ29hbC4gVGhpcyBkcmFmdCBpcyBtZWFudCB0byBiZSB1c2VkIG9ubHkgYXMgYSBsYXN0IHJl c29ydCwgYW5kIGRldGFpbHMgbWFueSBwZXJmb3JtYW5jZSBjb25zaWRlcmF0aW9ucyB0byBleHBs YWluIHdoeSB0aGUgdHVubmVsIHdpbGwgd29yayBzdWZmaWNpZW50bHksIGJ1dCBpcyBub3QgaWRl YWwuPC9kaXY+CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0i Ij5JIGFncmVlIHdpdGggdGhlIGRlY2lzaW9uIHByZXZpb3VzbHkgdG8gZ28gd2l0aCBJS0V2MiBm cmFnbWVudGF0aW9uIHJhdGhlciB0aGFuIFRDUC4gSG93ZXZlciwgc2hpcHBpbmcgY2xpZW50cyBz dGlsbCBoYXZlIHNlcmlvdXMgcHJvYmxlbXMgb24gbmV0d29ya3MgdGhhdCBkbyBibG9jayBVRFAg dHJhZmZpYy4gVGhlcmUgbWF5IGFsd2F5cyBiZSBzb21lIG1pZGRsZSBib3hlcyB0aGF0IGRvIGVu b3VnaCBpbnNwZWN0aW9uIGFuZAogd2FudCB0byBibG9jayBJS0UvSVBTZWMgdHJhZmZpYywgZXZl biBvdmVyIFRDUCBhbmQgVExTLCBidXQgdGhlIG1ham9yaXR5IG9mIGNhc2VzIGluIHdoaWNoIElL RXYyIGNhbm5vdCBiZSB1c2VkIHdpbGwgYmUsIGluIG91ciBleHBlcmllbmNlLCBzb2x2ZWQgYnkg bW92aW5nIHRoZSBjb25uZWN0aW9uIHRvIFRDUC9UTFMgd2hlbiBuZWVkZWQuPC9kaXY+CjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPgo8L2Rpdj4KPGRpdiBjbGFzcz0iIj5PdGhlciBzdGFuZGFy ZHMgYm9kaWVzLCBzdWNoIGFzIDNHUFAsIGhhdmUgcHVibGlzaGVkIGRvY3VtZW50cyBzdGF0aW5n IHRoYXQgY2xpZW50cyBzaG91bGQgZG8gdGhpcyBmb3IgSVdMQU4sIHdpdGhvdXQgZ2l2aW5nIHNw ZWNpZmljcyBvbiBob3cgdGhlIGZyYW1pbmcgc2hvdWxkIGJlIGhhbmRsZWQsIG9yIGhvdyBpdCBp bXBhY3RzIHRoZSBJS0V2MiBwcm90b2NvbC4gU2VlOiZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cu ZXRzaS5vcmcvZGVsaXZlci9ldHNpX3RzLzEzMzQwMF8xMzM0OTkvMTMzNDAyLzEyLjA1LjAwXzYw L3RzXzEzMzQwMnYxMjA1MDBwLnBkZiIgY2xhc3M9IiIgdGFyZ2V0PSJfQkxBTksiPmh0dHA6Ly93 d3cuZXRzaS5vcmcvZGVsaXZlci9ldHNpX3RzLzEzMzQwMF8xMzM0OTkvMTMzNDAyLzEyLjA1LjAw XzYwL3RzXzEzMzQwMnYxMjA1MDBwLnBkZjwvYT48L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPklmIElLRXYyIHNlcnZlcnMgc3RhcnQgaW1wbGVt ZW50aW5nIHN1cHBvcnQgZm9yIFRDUCBlbmNhcHN1bGF0aW9uIGJhc2VkIG9uIHRoZXNlIGRvY3Vt ZW50cywgd2UgbWF5IGVuZCB1cCB3aXRoIGRpdmVyZ2luZyBpbXBsZW1lbnRhdGlvbnMsIG9yIGlt cGxlbWVudGF0aW9ucyB0aGF0IGFyZSBub3QgY29tcGF0aWJsZSB3aXRoIE1PQklLRSwgZXRjLiBX ZSBiZWxpZXZlIHRoYXQgYSBzdGFuZGFyZCBpcyBuZWVkZWQgdG8gZGVmaW5lCiBob3cgaW1wbGVt ZW50YXRpb25zIHNob3VsZCBoYW5kbGUgdGhpcy48L2Rpdj4KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+CjwvZGl2Pgo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4KPGRpdiBjbGFzcz0iIj5U b21teTwvZGl2Pgo8YnIgY2xhc3M9IiI+CjxkaXY+CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPgo8ZGl2IGNsYXNzPSIiPk9uIFNlcCAxNSwgMjAxNSwgYXQgNzowMSBQTSwgVGVybyBL aXZpbmVuICZsdDs8YSBocmVmPSJtYWlsdG86a2l2aW5lbkBpa2kuZmkiIGNsYXNzPSIiPmtpdmlu ZW5AaWtpLmZpPC9hPiZndDsgd3JvdGU6PC9kaXY+CjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSI+CjxkaXYgY2xhc3M9IiI+CjxkaXYgY2xhc3M9IiI+VG9tbXkgUGF1bHkgd3Jp dGVzOjxiciBjbGFzcz0iIj4KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+SSB3YW50 ZWQgdG8gZ2V0IGEgc2Vuc2Ugb2YgV0cgaW50ZXJlc3QgaW4gd29ya2luZyBvbiBhIHN0YW5kYXJk IGZvciBydW5uaW5nPGJyIGNsYXNzPSIiPgpJS0V2Mi9JUFNlYyBvdmVyIGEgVENQIChvciBUTFMv VENQKSBjb25uZWN0aW9uIHRvIHRyYXZlcnNlIG5ldHdvcmtzIHRoYXQ8YnIgY2xhc3M9IiI+CmN1 cnJlbnRseSBibG9jayBVRFAgdHJhZmZpYy48YnIgY2xhc3M9IiI+CjwvYmxvY2txdW90ZT4KPGJy IGNsYXNzPSIiPgpCZWZvcmUgd2UgbWFkZSB0aGUgVURQIGZyYW1lbnRhdGlvbiBkb2N1bWVudCwg b3VyIG9yaWdpbmFsIHBsYW4gd2FzIHRvPGJyIGNsYXNzPSIiPgpydW4gSUtFdjIgb3ZlciBUQ1As IGp1c3QgYmVjYXVzZSB0aGF0IHdvdWxkIHNvbHZlIHRoaXMgcHJvYmxlbS48YnIgY2xhc3M9IiI+ CjxiciBjbGFzcz0iIj4KRHVyaW5nIHRoaXMgcHJvY2VzcyB3ZSB0aGVuIGZvdW5kIG91dCB0aGF0 IFdHIHdhbnRlZCB0byBzdGFuZGFyZGl6ZTxiciBjbGFzcz0iIj4KVURQIGZyYWdtZW50YXRpb24g aW5zdGVhZCBvZiBJS0V2MiBvdmVyIFRDUC48YnIgY2xhc3M9IiI+CjxiciBjbGFzcz0iIj4KSXMg dGhlcmUgcmVhbGx5IGhhcHBlbmQgc29tZXRoaW5nIHRoYXQgY2hhbmdlcyB0aGF0PzxiciBjbGFz cz0iIj4KPGJyIGNsYXNzPSIiPgpUaGUgb2xkIGluZm9ybWFsIHBvbGwgY2FuIGJlIGZvdW5kIGZy b20gPGJyIGNsYXNzPSIiPgo8YnIgY2xhc3M9IiI+CjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19tYXJjLmluZm9fLTNGdC0zRDEzNjMy NjA5MzUwMDAwMy0yNnItM0QxLTI2dy0zRDEmYW1wO2Q9QlFJQ0FnJmFtcDtjPWVFdm5pYXVGY3RP Z0xPS0dKT3BscXcmYW1wO3I9cDN3SUdPMDhfSC1PSmh1bkpUUEFCdyZhbXA7bT1Zd3F0TXBtVHFM U0ZZMDFQb3BDNEFuZTYzRzFueVowNExlQWNaUG45NHVzJmFtcDtzPXVpenFMdzhMTTVieFZKQUdH WHlNMlhmTUNMNHBULUI1cFlmV3hibGhJRVUmYW1wO2U9IiBjbGFzcz0iIiB0YXJnZXQ9Il9CTEFO SyI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX21h cmMuaW5mb18tM0Z0LTNEMTM2MzI2MDkzNTAwMDAzLTI2ci0zRDEtMjZ3LTNEMSZhbXA7ZD1CUUlD QWcmYW1wO2M9ZUV2bmlhdUZjdE9nTE9LR0pPcGxxdyZhbXA7cj1wM3dJR08wOF9ILU9KaHVuSlRQ QUJ3JmFtcDttPVl3cXRNcG1UcUxTRlkwMVBvcEM0QW5lNjNHMW55WjA0TGVBY1pQbjk0dXMmYW1w O3M9dWl6cUx3OExNNWJ4VkpBR0dYeU0yWGZNQ0w0cFQtQjVwWWZXeGJsaElFVSZhbXA7ZT08L2E+ CjxiciBjbGFzcz0iIj4KPGJyIGNsYXNzPSIiPgpTbyBob3cgZG9lcyB5b3VyIGRyYWZ0IHJlbGF0 ZSB0byB0aGUgZWFybGllciBpa2Ugb3ZlciB0Y3AgZHJhZnQ/IDxiciBjbGFzcz0iIj4KPGJyIGNs YXNzPSIiPgo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cC0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGlwc2Vj bWUtMkRpa2UtMkR0Y3BfJmFtcDtkPUJRSUNBZyZhbXA7Yz1lRXZuaWF1RmN0T2dMT0tHSk9wbHF3 JmFtcDtyPXAzd0lHTzA4X0gtT0podW5KVFBBQncmYW1wO209WXdxdE1wbVRxTFNGWTAxUG9wQzRB bmU2M0cxbnlaMDRMZUFjWlBuOTR1cyZhbXA7cz1vN0tKTDFZTmRjam1EWGg4TmMya2xFa2VtRHRC aThUUTk4LWhNai0xcTZrJmFtcDtlPSIgY2xhc3M9IiIgdGFyZ2V0PSJfQkxBTksiPmh0dHBzOi8v dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19kYXRhdHJhY2tlci5p ZXRmLm9yZ19kb2NfZHJhZnQtMkRpZXRmLTJEaXBzZWNtZS0yRGlrZS0yRHRjcF8mYW1wO2Q9QlFJ Q0FnJmFtcDtjPWVFdm5pYXVGY3RPZ0xPS0dKT3BscXcmYW1wO3I9cDN3SUdPMDhfSC1PSmh1bkpU UEFCdyZhbXA7bT1Zd3F0TXBtVHFMU0ZZMDFQb3BDNEFuZTYzRzFueVowNExlQWNaUG45NHVzJmFt cDtzPW83S0pMMVlOZGNqbURYaDhOYzJrbEVrZW1EdEJpOFRROTgtaE1qLTFxNmsmYW1wO2U9PC9h Pgo8YnIgY2xhc3M9IiI+Ci0tIDxiciBjbGFzcz0iIj4KPGEgaHJlZj0ibWFpbHRvOmtpdmluZW5A aWtpLmZpIiBjbGFzcz0iIj5raXZpbmVuQGlraS5maTwvYT48YnIgY2xhc3M9IiI+CjwvZGl2Pgo8 L2Rpdj4KPC9ibG9ja3F1b3RlPgo8L2Rpdj4KPGJyIGNsYXNzPSIiPgoKCjwvZGl2Pg== ----_com.ninefolders.hd3.email_20346638796759_alt-- ------8324A7AC30A5DD5BB3CDAF9894843679 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIIdgYJKoZIhvcNAQcCoIIIZzCCCGMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCCBe0w ggXpMIID0aADAgECAhEAzxzmCopx75U64hFk/UYzGzANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQK DAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEx MTAxODMyMTRaFw0xNzExMTAxODMyMTNaMGQxETAPBgNVBAoMCEVyaWNzc29uMRQwEgYDVQQDDAtT YW15IFRvdWF0aTEnMCUGCSqGSIb3DQEJARYYc2FteS50b3VhdGlAZXJpY3Nzb24uY29tMRAwDgYD VQQFEwdsbWNzYXRvMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtTzHN2e42IspS2LT etBYT1X297J5UERFKNlGu1pG2pcGU/NBSwsizw/RDI/q+c42EkEAWzJ4usb2oO4//CLw5Foboonf 8N2qhwRx5O7gEEIjjSCt2Q7O4mToKM4xoNSTmRrF2war3mnRc3g0A9T69MD2ipYU3/l7HVnAH4z+ 95t8FrL/oeFXuc/XgWfBGBSYY6uiyLujAZckgwWVFPN4ZMdGAZJ1AgU8tTLWafREHu3stvWcVniI QoOvJVNLHfYcnW8r/Lh0zaTSDCxusleG+YY3aKtXGF6CyaxuI8i3GmXWI+LEjNeJUesb/WKnZAub l51efuDJvQ+MDA7dNJaDdQIDAQABo4IBvjCCAbowSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2Ny bC50cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUH AQEEdjB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUF BzAChjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwIwYDVR0RBBwwGoEYc2FteS50b3VhdGlAZXJpY3Nzb24uY29tMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUrvTqPsDyVm3LeP+8KcedI3WxmhIwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/Szcw DgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBCT4SQnpZQ7Ur2tRXshjkw2pJJdHA7 0enikN4bx2cLmhaRlPfS4/SVEXYMLiTRb58jD0N7/wobI7UAWSRlj5zHn21La1HIE0MtdsJutSPc kZWbguCAl9TgEIGdGIVXKhsanr107KLIyrSu+DwgxOLE5kx6JqgcVV2e3ZockG6shOGXy1O83yP3 muINapuuIdY6qtvPTUJ5zZqNPTCHIDrQLwNx07HVflUkS0G/Ac6W6qdfDnu8qAE0YAxe1dajdphQ K/c3pskR5X7M39t7TlZfnFIxOWco3N7odbZo/8fmjxxvfqtcHa1qBrLrqHz9Itfrn+r5KEMqQG/2 WUotU6XuBSuNiDQvLt0VH324IOmlLJpTOG5pWbwIKm0Vz65NcP38S6Qg3k1XmSYa3Nd/eBDM2S7x sx9gxlxqcGtB0HX7lRFCqNtPd1U7YqPag+fKFgs2rbkrNm9TU0jN95UnrJn0lM4zJgL2Xel2keiu ySOQzI9r7NOyaEZXwtnhV3BgcIPZit3D4W6awzI/3HaZUb2Cr7HbrHBQAGknGpZZd00a/waLeolL 5CvALtUt0KpNz1Jqk5dKGfWLJNNxy2iNFrTThVkUYDEIyyqHLSzxj+W0vq8imtNDvul+8WK/1hCw +XJb9mVb3gpXONrneo5d5oj6SolE/O46eq6+2jcfWcwATTGCAlEwggJNAgEBME8wOjERMA8GA1UE CgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDPHOYK inHvlTriEWT9RjMbMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMTUwOTE2MDcwOTUzWjAjBgkqhkiG9w0BCQQxFgQUy9F6Vq0fRkj7YxFW+djT cLPfy50weQYJKoZIhvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcw DQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEAMQmekOG71vV5d6T5mz6Bbp10Sr3DYPNf bO+hoiccX+nTNBEmxDNECH63CsuiUAw+qarwSVc7EsUFrtE8Pjc+lBozijW/EsJ9d5+9e3r58jJ3 Tfz7t3n7aPHcz39jZQtgLfsqr3KF9eXjIOZte8tEq2zhTlOfqVk2rIdv97iMJXV3FToi96owC/SF /qg1X5umqBZeTBh/SVwEmvOUJOct7w/VZNbN27rGiz7I9qzN4Why+p85zxPDvw0Du/m0IQkc6+VF aHYke7TijvH1MhQYUljzuKW1xdZMHpYiDTSxkICok3Z2+/dvnviLmcuWeEXuYVD8xzBMdzCz0bl4 9fy6gw== ------8324A7AC30A5DD5BB3CDAF9894843679-- From nobody Thu Sep 17 10:05:54 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5911A8F35 for ; Thu, 17 Sep 2015 10:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 rTmU8SXeNXb2 for ; Thu, 17 Sep 2015 10:05:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B98AE1ACD2F for ; Thu, 17 Sep 2015 10:05:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nH4S85Fx2z2Dt; Thu, 17 Sep 2015 19:05:44 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=cvinjwu5 X-OPENPGPKEY: Message passed unmodified 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 ye2OwoVf54YW; Thu, 17 Sep 2015 19:05:41 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 17 Sep 2015 19:05:41 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 79C128009F; Thu, 17 Sep 2015 13:05:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1442509540; bh=WlRbcE+gxLsw4B9IVkCqAOkNK6CR4o2zPalDE5zEQwM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cvinjwu5/0FJl0iYz5OJtpugr0S4ZYHW5uyFCzSm2uTLeHcCCdOPOagmPod0liGAV liVLyMD7zwH1lY7G5Dtfz3Men2OZ+iK67EKVRdEkOMb/6HZQFl0EvYlxf+bMZYZ95C qGev4jmwh5SeI442V5COUrp/RAQ5InZhxf3vHn7I= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t8HH5dwn024279; Thu, 17 Sep 2015 13:05:40 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 17 Sep 2015 13:05:39 -0400 (EDT) From: Paul Wouters To: IPsecME WG In-Reply-To: <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> Message-ID: References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: Tommy Pauly Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 17:05:53 -0000 On Wed, 16 Sep 2015, Yoav Nir wrote: > This draft is proposing both IKE and ESP over the TCP connection, so the protocol will work in situations where UDP (even with fragmentation at the IKE rather than IP layer) fails. > > We’ve had something like this working with IKEv1 for over 10 years. Many vendors have “SSL VPN” solutions that have pretty much the same performance, scalability, and connectivity characteristics. There’s ample evidence that this kind of solution works. And although the need is slowly diminishing (more and more public networks allow IKE and IPsec to work), there are still many places where we still need to tunnel everything over TCP. The real question is whether the networks that don't transport ESP or ESPinUDP block those packets on purpose or by accident. I don't think we really have any good numbers on this. If we are doing this as a "workaround" to break through the administrative boundaries, than we are going to see TCP blocked as well on those networks. And all we have gained is complexity. We'll end up playing the game of TOR. I can see some networks which legitiably block or fail to transport UDP, for instance an airplane wifi with proxy server on board for DNS and HTTP. Here, the resources are very scarce. But also, the packet loss scenario would be bad, eg when doing voice UDP over IPsec in TCP via a proxy TLS server. I did not re-read the old or read the new draft yet, but turning a UDP protocol into TCP (or even TCP in TCP) has its issues. Also TCP VPN connections can be trivially forced to close by sending a (spoofed) RST packet. So, while I am sceptical, we do see a flourishing of non-interoperable TLS based VPN's without proper specifiations that are succesful precisely because it works in both bad and administratively restricted networks. So people want to do this anyway, and if they do, we should at least try and avoid the same scattering that has happened with TLS VPN's and do it in one interoperable way for IKE and IPsec. And I would think getting the ESPinTCP will actually be the harder part to get properly supported inside the kernels. So I would reluctantly want to move forward with the idea, although I need to do more homework about the implementation details of both drafts. Paul From nobody Thu Sep 17 11:26:57 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C3C1B30D1 for ; Thu, 17 Sep 2015 11:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 8UsvkG1TDesf for ; Thu, 17 Sep 2015 11:26:51 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D891B30CE for ; Thu, 17 Sep 2015 11:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1442514410; x=2306428010; 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=q7wzv+x2PVvSzG1IjidTFPuJ024BpOmXr1rMIJMd1g8=; b=idy0FtJUQqq+8jpgr1gzYCVS+evKkTiKx9Bz90QCkvXmjCApiGmvm9Hb8HdqiyTZ /gwvP3gMORakMmn+vkVI4W372gI1nZTK1ykLULQ6Bo9nKzB860+sOzcZy5FRpgVk MYvSLgWFkJwdn27C0yVlt33HsJpgGBZmkYC2xHN6b7uTenks5KVjYCfjdfd5SYv4 OU58HIR3ebumXRGdDDnyzedB0S4q6d9eA5RQBdemtdl8QPTHbGH4mkXl3w81pExI PcNhUVPBie3SfEx8eZKjUvce9999tPBmi7RGmyCifiv9ObLE+eu8eeeRPOeiv7hZ WSnzCnR5z0gsGZzZGqySsA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 06.93.22968.AE50BF55; Thu, 17 Sep 2015 11:26:50 -0700 (PDT) X-AuditID: 11973e13-f79006d0000059b8-e6-55fb05ea1d91 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id ED.D0.22881.AE50BF55; Thu, 17 Sep 2015 11:26:50 -0700 (PDT) Received: from [17.153.41.233] (unknown [17.153.41.233]) by aniseed.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUU00N9638P3A90@aniseed.apple.com> for ipsec@ietf.org; Thu, 17 Sep 2015 11:26:50 -0700 (PDT) Sender: tpauly@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.0 \(3074\)) From: Tommy Pauly In-reply-to: Date: Thu, 17 Sep 2015 11:27:18 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.3074) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUi2FAYpfuK9Xeowbr1qhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtm/J5kLOpUrJn2bwtjAuFami5GTQ0LAROL19AtsELaYxIV7 64FsLg4hgb2MEm9OnGaDKdracY8RItHPJLG17QsThDOBSWLPrg+sXYwcHMICEhKb9ySCmMwC 6hJTpuSC9PIK6Ek0/9vLDGILC5hKXP/8hBXEZhNQkTj+bQNYnFPAUeL01NdgNouAqsTpN1cZ QWxmAXmJ3v8boWxtiSfvLoBt4hWwkfh6qgbigiuMEgsfTga7U0RAUWLSmUcsEDfLSvw8fpQd wl7CJnFlcckERpFZCNfNQnLdLCQbFjAyr2IUyk3MzNHNzDPVSywoyEnVS87P3cQICu3pdsI7 GE+vsjrEKMDBqMTDW+H2K1SINbGsuDL3EKM0B4uSOO+3CKCQQHpiSWp2ampBalF8UWlOavEh RiYOTqkGxjkNJYd2LHn96Zor84Nd31Zy9psc+N/WWzon/el3JTflnTas5r4z1GKXXDt30Tt5 6gn3R3Wp3ZuvKBku6PpXFJ3r1Mn+x/AlC1d0ekOaYuDbG1sFLM799ThbZhLjmJbyIea7JYO/ p8/GpHNnGncd/qwo/Pj5v9WzWctX6V1Q2sVy+0lsX/mSbiWW4oxEQy3mouJEAPN5xZxOAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUi2FAsrvuK9XeoweEdShb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtm/J5kLOpUrJn2bwtjAuFami5GTQ0LARGJrxz1GCFtM4sK9 9WxdjFwcQgL9TBJb274wQTgTmCT27PrA2sXIwSEsICGxeU8iiMksoC4xZUouSC+vgJ5E87+9 zCC2sICpxPXPT1hBbDYBFYnj3zaAxTkFHCVOT30NZrMIqEqcfnMVbC+zgLxE7/+NULa2xJN3 F8A28QrYSHw9VQNxwRVGiYUPJ7OB1IgIKEpMOvOIBeJmWYmfx4+yT2AUnIVw0SwkF81CMnUB I/MqRoGi1JzESjO9xIKCnFS95PzcTYzgYCyM2sHYsNzqEKMAB6MSD2+F269QIdbEsuLK3EOM EhzMSiK88xl/hwrxpiRWVqUW5ccXleakFh9iTAb6ZSKzlGhyPjBS8kriDU1MDEyMjc2Mjc1N zEkTVhLn1V77M1RIID2xJDU7NbUgtQhmCxMHp1QDo1PUJN7V7Ud8vU9/NjrntDs17f296feD 5HzT9UJzxJw9NgUukamevOovhxizZ3b51NIoLVsX1oNhS71mH1pxbOKucEv5y6WXv6zhfPsi tENk2pkLsetjMw2vK3ZzPN4ZBFSjvM5/08d/2bf+q6RUHP3W8mbKhS6FpbNS80o3X6mc3Lly flKLEktxRqKhFnNRcSIARVYN9IoCAAA= Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Sep 2015 18:26:53 -0000 Hi Paul, I encourage you to read the new draft, as I believe it addresses many of = your concerns. It covers the potential new vulnerabilities (RST), as = well as how to frame the datagrams in a stream along with an explanation = of performance concerns. It also makes it clear that TCP should only be = used when absolutely necessary, not as a default. In our own deployments around the world, there are a high number of = networks that are blocking connections by =E2=80=9Caccident", not by = policy. These include many hotel and restaurant networks. We are = interested in allowing connections to work in these networks. If a = network legitimately wants to block our traffic and is able to detect = that we are using IPSec, then I am not interested in getting into an = arms race to get around their firewalls. Some clients may have trouble putting ESP over TCP, as you mention, but = we have been able to implement this protocol successfully for both = clients and servers. This may not be a protocol that all clients end up = supporting, but those that do need TCP encapsulation should do it in a = standard fashion. As you mention, the critical point is that clients and servers will be = implementing this functionality in the near future, and we need to avoid = non-interoperable solutions. If we can standardize the way TCP = encapsulation =E2=80=9Cshould=E2=80=9D work, then IKEv2 will be able to = used in essentially all scenarios that support non-standard TLS VPN = protocols.=20 Thanks, Tommy > On Sep 17, 2015, at 10:05 AM, Paul Wouters wrote: >=20 > On Wed, 16 Sep 2015, Yoav Nir wrote: >=20 >> This draft is proposing both IKE and ESP over the TCP connection, so = the protocol will work in situations where UDP (even with fragmentation = at the IKE rather than IP layer) fails. >>=20 >> We=E2=80=99ve had something like this working with IKEv1 for over 10 = years. Many vendors have =E2=80=9CSSL VPN=E2=80=9D solutions that have = pretty much the same performance, scalability, and connectivity = characteristics. There=E2=80=99s ample evidence that this kind of = solution works. And although the need is slowly diminishing (more and = more public networks allow IKE and IPsec to work), there are still many = places where we still need to tunnel everything over TCP. >=20 > The real question is whether the networks that don't transport ESP or > ESPinUDP block those packets on purpose or by accident. I don't think > we really have any good numbers on this. >=20 > If we are doing this as a "workaround" to break through the = administrative > boundaries, than we are going to see TCP blocked as well on those > networks. And all we have gained is complexity. We'll end up playing = the > game of TOR. >=20 > I can see some networks which legitiably block or fail to transport = UDP, > for instance an airplane wifi with proxy server on board for DNS and > HTTP. Here, the resources are very scarce. But also, the packet loss > scenario would be bad, eg when doing voice UDP over IPsec in TCP via a > proxy TLS server. I did not re-read the old or read the new draft yet, > but turning a UDP protocol into TCP (or even TCP in TCP) has its = issues. >=20 > Also TCP VPN connections can be trivially forced to close by > sending a (spoofed) RST packet. >=20 > So, while I am sceptical, we do see a flourishing of non-interoperable > TLS based VPN's without proper specifiations that are succesful = precisely > because it works in both bad and administratively restricted networks. >=20 > So people want to do this anyway, and if they do, we should at least = try > and avoid the same scattering that has happened with TLS VPN's and do > it in one interoperable way for IKE and IPsec. And I would think = getting > the ESPinTCP will actually be the harder part to get properly = supported > inside the kernels. >=20 > So I would reluctantly want to move forward with the idea, although I > need to do more homework about the implementation details of both = drafts. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_ipsec&d=3DBQIGaQ&c=3DeEvniauFctOgLOKGJOplqw&r=3Dp3wIGO08_H-OJhu= nJTPABw&m=3DNS8d18flBXl5ifdG12-KKND7GHXI1pJTsHY3oN8YLqQ&s=3DQAyt5Max6LT-7y= XfOOEqnhdsFfHCwuR1Y7YO-htB98A&e=3D=20 From nobody Fri Sep 18 06:54:25 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03E91B2BDE for ; Fri, 18 Sep 2015 06:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.47 X-Spam-Level: * X-Spam-Status: No, score=1.47 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=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 GD7WR4IpYAKS for ; Fri, 18 Sep 2015 06:54:22 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 362041B2BE2 for ; Fri, 18 Sep 2015 06:54:22 -0700 (PDT) Received: by lanb10 with SMTP id b10so30817942lan.3 for ; Fri, 18 Sep 2015 06:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=8iE9aHi6KsMe8eijZWsy/WJuPR471qmyMBZaEoqDbvU=; b=qYVbSFDG2Ctdfe/orEGThNKgEYe7TTwlTH94+lpIQAjkhX7Ubg7IUSMYgMlK8iqdyR nj422qGbikOGSfhJ+aHoSRM1YRM3sUNgmko2j4g05k3Rn4cqvC7GC6U1+XvoqQpqDOR7 YOIFLArlXPq0sO1LsYUWwByNNJ9oa/oMLMh/LNbfSPsypu2Tao8bqjyTarHWwLfOnLUq 8u1gVtBSi5ljSyOHNvxV1oPr89NjL33YB1fRR6fILyrDMYFytEipIimgBFl4GqAAUvza YddOqzNGX2E0tGD4rLYHhKTfY1YZzOtARZfcR6p0a3y9snFsE3F3lB5dtwRIFDUqGhyd gH9Q== X-Received: by 10.153.7.138 with SMTP id dc10mr3192089lad.23.1442584460336; Fri, 18 Sep 2015 06:54:20 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id k15sm1393796laa.30.2015.09.18.06.54.19 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 18 Sep 2015 06:54:19 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Paul Wouters" , "IPsecME WG" References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> Date: Fri, 18 Sep 2015 16:54:08 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: Cc: Tommy Pauly Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 13:54:23 -0000 Hi Tommy, > The real question is whether the networks that don't transport ESP or > ESPinUDP block those packets on purpose or by accident. I don't think > we really have any good numbers on this. > > If we are doing this as a "workaround" to break through the administrative > boundaries, than we are going to see TCP blocked as well on those > networks. And all we have gained is complexity. We'll end up playing the > game of TOR. > > I can see some networks which legitiably block or fail to transport UDP, > for instance an airplane wifi with proxy server on board for DNS and > HTTP. Here, the resources are very scarce. But also, the packet loss > scenario would be bad, eg when doing voice UDP over IPsec in TCP via a > proxy TLS server. I did not re-read the old or read the new draft yet, > but turning a UDP protocol into TCP (or even TCP in TCP) has its issues. > > So people want to do this anyway, and if they do, we should at least try > and avoid the same scattering that has happened with TLS VPN's and do > it in one interoperable way for IKE and IPsec. And I would think getting > the ESPinTCP will actually be the harder part to get properly supported > inside the kernels. > > So I would reluctantly want to move forward with the idea, although I > need to do more homework about the implementation details of both drafts. > > Paul I tend to agree with Paul here. The question for me is - what do we want to achieve. If the purpose is to be able to work in those environments, where UDP is blocked, while TCP isn't, then we will soon end up defining IKE and ESP over HTTP(S), because it is the most "penetrating" protocol right now. Do you have any real numbers of how often such environments where UDP is blocked, but TCP (not only TCP:80) is not appear in real life? Could you estimate a percentage? So, I'm not yet convinced that it is a solution to essentially widespread problem, however if people run IKE over TCP anyway, then it is better to have some standard way to do it. The question - why do they do it and does it the only way to solve their problem. Regarding the draft. You should probably have mentioned that with IKE over TCP responder looses its ability to remain stateless and that cookies become useless and SHOULD NOT be used. Regards, Valery Smyslov. From nobody Fri Sep 18 08:06:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D971B2DD0 for ; Fri, 18 Sep 2015 08:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 SSy8GYxgYp83 for ; Fri, 18 Sep 2015 08:05:56 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 283481B2DBB for ; Fri, 18 Sep 2015 08:05:56 -0700 (PDT) Received: from [10.32.60.124] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8IF5srN050213 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Sep 2015 08:05:55 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.124] From: "Paul Hoffman" To: "IPsecME WG" Date: Fri, 18 Sep 2015 08:05:57 -0700 Message-ID: References: <20150918142727.14681.30680.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: [IPsec] Fwd: Last Call: (Minimal IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 15:06:00 -0000 Of interest to people in this WG. If you have comments on the draft, please send them to ietf@ietf.org, not on this list. --Paul Hoffman Forwarded message: > From: The IESG > To: IETF-Announce > Cc: lwip@ietf.org > Subject: Last Call: (Minimal > IKEv2) to Informational RFC > Date: Fri, 18 Sep 2015 07:27:27 -0700 > > > The IESG has received a request from the Light-Weight Implementation > Guidance WG (lwig) to consider the following document: > - 'Minimal IKEv2' > as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-10-02. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes minimal version of the Internet Key Exchange > version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for > performing mutual authentication and establishing and maintaining > Security Associations (SAs). IKEv2 includes several optional > features, which are not needed in minimal implementations. This > document describes what is required from the minimal implementation, > and also describes various optimizations which can be done. The > protocol described here is compliant with full IKEv2 with exception > that this document describes mainly shared secret authentication > (IKEv2 requires support for certificate authentication in addition to > shared secret authentication). > > This document does not update or modify RFC 7296, but provides more > compact description of the minimal version of the protocol. If this > document and RFC 7296 conflicts then RFC 7296 is the authoritative > description. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Fri Sep 18 11:28:22 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 638F01B2FF5 for ; Fri, 18 Sep 2015 11:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.734 X-Spam-Level: X-Spam-Status: No, score=0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.982, SPF_PASS=-0.001] autolearn=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 PR1Z-nCXp99M for ; Fri, 18 Sep 2015 11:28:18 -0700 (PDT) Received: from redux.ipsound.net (173-13-184-201-sfba.hfc.comcastbusiness.net [173.13.184.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205E81B2FDC for ; Fri, 18 Sep 2015 11:28:17 -0700 (PDT) Received: from bluesky.ipsound.net (unknown [192.168.10.195]) (using TLSv1.2 with cipher AES256-SHA256 (256/256 bits)) (No client certificate requested) by redux.ipsound.net (Postfix) with ESMTPS id 8388E60161; Fri, 18 Sep 2015 11:28:17 -0700 (PDT) Received: from BLUESKY.ipsound-net.local ([fe80::28a0:e0:dbbe:3d7f]) by BLUESKY.ipsound-net.local ([fe80::28a0:e0:dbbe:3d7f%10]) with mapi id 14.03.0248.002; Fri, 18 Sep 2015 11:28:17 -0700 From: Samy Touati To: Valery Smyslov Thread-Topic: [IPsec] WG Interest in TCP Encapsulation Thread-Index: AQHQ8H2lmDSk5atkTkaU8Cr2M+DqCp5BaoWAgADnkpuAAMG/gA== Date: Fri, 18 Sep 2015 18:28:16 +0000 Message-ID: References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <09BA0725365EE048BAEBFA098B4FCF8C@ipsound-net.local> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Paul Wouters , Tommy Pauly Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 18:28:19 -0000 Hi Valery, The draft doesn't prevent http encapsulation for the purpose of traversing = web proxies for example, and this would be considered one "use-case" that w= ould make use of TCP encapsulation. The draft do provide such flexibility.= =20 The objective of this proposal is to provide a standardized method to allow= the use of IPSec in environments which may not allow udp encapsulated IPSe= c traffic, and to avoid different implementations to address specific use c= ases.=20 The client would select this method only as a last resort option, so perfor= mance issues should be mitigated.=20 =20 With this capability, the mobile device can enable wifi calling in a higher= number of locations. It also allow the introduction of the wifi calling se= rvice without too much impact in some venues types.=20 Thanks Samy.=20 > On Sep 18, 2015, at 6:54 AM, Valery Smyslov wrote: >=20 > Hi Tommy,=20 >> The real question is whether the networks that don't transport ESP or >> ESPinUDP block those packets on purpose or by accident. I don't think >> we really have any good numbers on this. >> If we are doing this as a "workaround" to break through the administrati= ve >> boundaries, than we are going to see TCP blocked as well on those >> networks. And all we have gained is complexity. We'll end up playing the >> game of TOR. >> I can see some networks which legitiably block or fail to transport UDP, >> for instance an airplane wifi with proxy server on board for DNS and >> HTTP. Here, the resources are very scarce. But also, the packet loss >> scenario would be bad, eg when doing voice UDP over IPsec in TCP via a >> proxy TLS server. I did not re-read the old or read the new draft yet, >> but turning a UDP protocol into TCP (or even TCP in TCP) has its issues. >> So people want to do this anyway, and if they do, we should at least try >> and avoid the same scattering that has happened with TLS VPN's and do >> it in one interoperable way for IKE and IPsec. And I would think getting >> the ESPinTCP will actually be the harder part to get properly supported >> inside the kernels. >> So I would reluctantly want to move forward with the idea, although I >> need to do more homework about the implementation details of both drafts= . >> Paul >=20 > I to agree with Paul here.=20 > The question for me is - what do we want to achieve. If the purpose > is to be able to work in those environments, where UDP is blocked, > while TCP isn't, then we will soon end up defining IKE and ESP > over HTTP(S), because it is the most "penetrating" protocol right now. >=20 > Do you have any real numbers of how often such environments where UDP is = blocked, but TCP (not only TCP:80) is not appear in real life? Could you es= timate a percentage? >=20 > So, I'm not yet convinced that it is a solution to essentially > widespread problem, however if people run IKE over TCP anyway, then > it is better to have some standard way to do it. The question - why > do they do it and does it the only way to solve their problem. >=20 > Regarding the draft. You should probably have mentioned that with IKE ove= r TCP responder looses its ability to remain stateless and that cookies bec= ome useless and SHOULD NOT be used.=20 > Regards, > Valery Smyslov. >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Sep 18 16:44:49 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D1321A8725 for ; Fri, 18 Sep 2015 16:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 fIhenVBCzca5 for ; Fri, 18 Sep 2015 16:44:44 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE22A1A870D for ; Fri, 18 Sep 2015 16:44:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1442619884; x=2306533484; 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=cxyELPNokOl/lUbB+BOkoajbCF1gKnZEtnUQXvT/c/Q=; b=wwBgurU6oe+Ebn13aVtwiP3jy7FPK6J5XIL/vtXX/Ftd+vOT89KulEvlU/yle8FH AJGuUib5X9TdZ6ceNL2+QjtshQ1skzumbEPxS5vLFzaZ+sf+l5biZaBVOBklA5LZ MWBfZOA+LPR80dEkwc9GMTnpjacS9HxqzTNNq9L/hzprIpena12etuXxi5Da6DBk X098dXH30gafyrTqJ2QJFcL7hLTmAo9vjvn8xoRqyvWv+SOr0XpMh5m+gtM5uLzu 4nL3cIzjqNMRXa6R7daA7Skm4JaFCsMZamLgDFyxxKSHpw0Hc6L6lcJL7S+01y5w E5aA1ylAygZRJlhbYF5BXA==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 43.AB.32067.CE1ACF55; Fri, 18 Sep 2015 16:44:44 -0700 (PDT) X-AuditID: 11973e13-f79b76d000007d43-9b-55fca1ecc2d7 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id BE.CD.32123.BE1ACF55; Fri, 18 Sep 2015 16:44:44 -0700 (PDT) Received: from [17.153.43.181] by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUW00EB6CMJZJ70@cilantro.apple.com> for ipsec@ietf.org; Fri, 18 Sep 2015 16:44:43 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_806D8701-2F0B-4F9A-83C3-E60010DD7A36" MIME-version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Tommy Pauly In-reply-to: Date: Fri, 18 Sep 2015 16:44:42 -0700 Message-id: <641F9450-5BF6-43DE-A0A9-168F5022DB62@apple.com> References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> To: Valery Smyslov X-Mailer: Apple Mail (2.3094) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUi2FAYrPtm4Z9Qg2sHWSz2b3nB5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDmvH7EUnNrNWHF48WbWBsaDCxi7GDk5JARMJKZ03maHsMUk Ltxbz9bFyMUhJLCXUeL4yUUsMEU7d2xmh0hMZJK4s2kGK4Tzg1FixsReoBYODmEBCYnNexJB GpgFkiRadx1iBrF5BfQkLk3ZCLZNWMBU4vrnJ6wgNpuAisTxbxvAajgF7CWmPfgGdgWLgKpE c9M2Jog5CRJPb89ngphjI7HhQRfUdduYJC7vXw02VASo4ea2n8wQl8pK3Pq6GuxSCYEtbBKb O5czTmAUnoXkqFlIjoKIa0ssW/iaGcLWlNjfvZwFU1xDovPbRNYFjGyrGIVyEzNzdDPzTPUS CwpyUvWS83M3MYLiYrqd8A7G06usDjEKcDAq8fDu6P4TKsSaWFZcmXuIUZqDRUmc90k/UEgg PbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjIb9kM6vmsts5NvNXcGg5s//3+VF9pPfb8zVMr/5e FvX89+CM44WjG72vPbuofkXGW+tsj+b3baXJbKc1/edq1LWt2+3P7bL3+oPy/XvbHq6IszZL W6j5vTPUlKXcpCpIyK/bL2LHdg2xWK5Uf6XsvzuvC928zhGsHLjzfmay+p/SiuMJH2SUWIoz Eg21mIuKEwG10Y/MbAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrEIsWRmVeSWpSXmKPExsUi2FAspPtm4Z9Qg41qFvu3vGBzYPRYsuQn UwBjFJdNSmpOZllqkb5dAlfGnNePWApO7WasOLx4M2sD48EFjF2MnBwSAiYSO3dsZoewxSQu 3FvP1sXIxSEkMJFJ4s6mGawQzg9GiRkTe4EyHBzCAhISm/ckgjQwCyRJtO46xAxi8wroSVya shFsqLCAqcT1z09YQWw2ARWJ4982gNVwCthLTHvwDWwZi4CqRHPTNiaIOQkST2/PZ4KYYyOx 4UEX1BHbmCQu718NNlQEqOHmtp/MEJfKStz6upp9AqPALCR3zEJyB0RcW2LZwtfMELamxP7u 5SyY4hoSnd8msi5gZFvFKFCUmpNYaayXWFCQk6qXnJ+7iREcxIXBOxj/LLM6xCjAwajEw5vQ +SdUiDWxrLgy9xCjBAezkgjvhGagEG9KYmVValF+fFFpTmrxIcaJjEBvTmSWEk3OB8ZYXkm8 oYmJgYmxsZmxsbmJOS2FlcR5DZf8DhUSSE8sSc1OTS1ILYI5iomDU6qB0WnttrT7XbXb/33u CV2yZZETu19j9j6N4sOX0o6ebWxdf9bkaErjA/5GxtRsMe0TwZHLrLNmKPvrmv+uvezoY/Jx TsaLhQ/Wey9Qt816uUhOcnIGb4f/yVIesQjLnryko1P6Tu/7wXjzuf9SpuBdhm9Ff83Nzk6z vNq3Se7vZabU4FAdjQ1tSizFGYmGWsxFxYkAJBr9OdUCAAA= Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 23:44:47 -0000 --Apple-Mail=_806D8701-2F0B-4F9A-83C3-E60010DD7A36 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Valery, As Samy mentioned, this draft does allow for the traffic to looks like = HTTPS traffic (using TLS over port 443), but doesn=E2=80=99t require it. = It is about defining a standard way to add framing to IKEv2 and ESP when = put over a TCP-based stream; the applications of this may vary in = different networks in the future. You asked about how widespread this issue is. I cannot provide exact = numbers here, but on a global scale, I would estimate that around 10% of = networks that mobile customers may be using will block UDP traffic, but = allow traffic encapsulated as we define in the draft. These are most = common in hotels, restaurants, and other public networks. This is = certainly not the majority of networks, but it is still very significant = to users. These failures also account for essentially all of the IKEv2 = connection failures that we have measured. When IKEv2 over WiFi is used = as your only way to send or receive phone calls, or a device is required = by policy to use IKEv2 for all its networking connections, being on a = network that blocks this traffic means having an unusable device. = Because scenarios like this are becoming more common, we are seeing a = push to make IKEv2 compatible with these networks.=20 The primary goal of the draft is to define a standard way of framing so = we don=E2=80=99t end up with a different approach from each vendor, as = we saw in TLS VPNs. The problem is a current one that needs to be = solved, since it has high user impact. I also believe that having a = standard way to transmit IKEv2 and ESP over a stream-based protocol will = be useful going forward, and the draft specifically defines exactly what = is needed to be interoperable and functional, without creating = limitations about usage scenarios (specific port numbers, TLS = parameters, etc).=20 Thanks, Tommy > On Sep 18, 2015, at 11:28 AM, Samy Touati wrote: >=20 > Hi Valery, >=20 > The draft doesn't prevent http encapsulation for the purpose of = traversing web proxies for example, and this would be considered one = "use-case" that would make use of TCP encapsulation. The draft do = provide such flexibility.=20 >=20 > The objective of this proposal is to provide a standardized method to = allow the use of IPSec in environments which may not allow udp = encapsulated IPSec traffic, and to avoid different implementations to = address specific use cases.=20 > The client would select this method only as a last resort option, so = performance issues should be mitigated.=20 >=20 > With this capability, the mobile device can enable wifi calling in a = higher number of locations. It also allow the introduction of the wifi = calling service without too much impact in some venues types.=20 >=20 >=20 >=20 >=20 > Thanks > Samy.=20 >=20 >=20 >=20 >=20 >=20 >=20 >> On Sep 18, 2015, at 6:54 AM, Valery Smyslov > wrote: >>=20 >> Hi Tommy,=20 >>> The real question is whether the networks that don't transport ESP = or >>> ESPinUDP block those packets on purpose or by accident. I don't = think >>> we really have any good numbers on this. >>> If we are doing this as a "workaround" to break through the = administrative >>> boundaries, than we are going to see TCP blocked as well on those >>> networks. And all we have gained is complexity. We'll end up playing = the >>> game of TOR. >>> I can see some networks which legitiably block or fail to transport = UDP, >>> for instance an airplane wifi with proxy server on board for DNS and >>> HTTP. Here, the resources are very scarce. But also, the packet loss >>> scenario would be bad, eg when doing voice UDP over IPsec in TCP via = a >>> proxy TLS server. I did not re-read the old or read the new draft = yet, >>> but turning a UDP protocol into TCP (or even TCP in TCP) has its = issues. >>> So people want to do this anyway, and if they do, we should at least = try >>> and avoid the same scattering that has happened with TLS VPN's and = do >>> it in one interoperable way for IKE and IPsec. And I would think = getting >>> the ESPinTCP will actually be the harder part to get properly = supported >>> inside the kernels. >>> So I would reluctantly want to move forward with the idea, although = I >>> need to do more homework about the implementation details of both = drafts. >>> Paul >>=20 >> I to agree with Paul here.=20 >> The question for me is - what do we want to achieve. If the purpose >> is to be able to work in those environments, where UDP is blocked, >> while TCP isn't, then we will soon end up defining IKE and ESP >> over HTTP(S), because it is the most "penetrating" protocol right = now. >>=20 >> Do you have any real numbers of how often such environments where UDP = is blocked, but TCP (not only TCP:80) is not appear in real life? Could = you estimate a percentage? >>=20 >> So, I'm not yet convinced that it is a solution to essentially >> widespread problem, however if people run IKE over TCP anyway, then >> it is better to have some standard way to do it. The question - why >> do they do it and does it the only way to solve their problem. >>=20 >> Regarding the draft. You should probably have mentioned that with IKE = over TCP responder looses its ability to remain stateless and that = cookies become useless and SHOULD NOT be used.=20 >> Regards, >> Valery Smyslov. >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_ipsec&d=3DBQIFAg&c=3DeEvniauFctOgLOKGJOplqw&r=3Dp3wIGO08_H-OJhu= nJTPABw&m=3D4GK9GDAJB4AfnjxKtZO86J_C51187G2Wd6iGESlw-tc&s=3Dr-OioL-HDBAQtO= yfaWxfvw2XYMyePRHw--cSv0lCNto&e=3D = --Apple-Mail=_806D8701-2F0B-4F9A-83C3-E60010DD7A36 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Valery,

As Samy mentioned, this draft does = allow for the traffic to looks like HTTPS traffic (using TLS over port = 443), but doesn=E2=80=99t require it. It is about defining a standard = way to add framing to IKEv2 and ESP when put over a TCP-based stream; = the applications of this may vary in different networks in the = future.

You = asked about how widespread this issue is. I cannot provide exact numbers = here, but on a global scale, I would estimate that around 10% of = networks that mobile customers may be using will block UDP traffic, but = allow traffic encapsulated as we define in the draft. These are most = common in hotels, restaurants, and other public = networks.  This is certainly not the majority of networks, but = it is still very significant to users. These failures also account = for essentially all of the IKEv2 connection failures that we have = measured. When IKEv2 over WiFi is used as your only way to send or = receive phone calls, or a device is required by policy to use IKEv2 for = all its networking connections, being on a network that blocks this = traffic means having an unusable device. Because scenarios like this are = becoming more common, we are seeing a push to make IKEv2 compatible with = these networks. 

The primary goal of the draft is to define a standard way of = framing so we don=E2=80=99t end up with a different approach from each = vendor, as we saw in TLS VPNs. The problem is a current one that needs = to be solved, since it has high user impact. I also believe that having = a standard way to transmit IKEv2 and ESP over a stream-based protocol = will be useful going forward, and the draft specifically defines exactly = what is needed to be interoperable and functional, without creating = limitations about usage scenarios (specific port numbers, TLS = parameters, etc). 

Thanks,
Tommy

On = Sep 18, 2015, at 11:28 AM, Samy Touati <sato@ipsound.net> = wrote:

Hi Valery,

The draft doesn't prevent http encapsulation for = the purpose of traversing web proxies for example, and this would be = considered one "use-case" that would make use of TCP encapsulation. The = draft do provide such flexibility. 

The objective of this proposal is to = provide a standardized method to allow the use of IPSec in environments = which may not allow udp encapsulated IPSec traffic, and to avoid = different implementations to address specific use cases. 
The client would select = this method only as a last resort option, so performance issues should = be mitigated. 
With this capability, the mobile device = can enable wifi calling in a higher number of locations. It also allow = the introduction of the wifi calling service without too much impact in = some venues types. 




Thanks
Samy. 






On Sep 18, 2015, at 6:54 AM, = Valery Smyslov <svanru@gmail.com> wrote:

Hi= Tommy, 
The real question is = whether the networks that don't transport ESP or
ESPinUDP = block those packets on purpose or by accident. I don't think
we really have any good numbers on this.
If we = are doing this as a "workaround" to break through the administrative
boundaries, than we are going to see TCP blocked as well on = those
networks. And all we have gained is complexity. = We'll end up playing the
game of TOR.
I can = see some networks which legitiably block or fail to transport UDP,
for instance an airplane wifi with proxy server on board for = DNS and
HTTP. Here, the resources are very scarce. But = also, the packet loss
scenario would be bad, eg when doing = voice UDP over IPsec in TCP via a
proxy TLS server. I did = not re-read the old or read the new draft yet,
but turning = a UDP protocol into TCP (or even TCP in TCP) has its issues.
So people want to do this anyway, and if they do, we should = at least try
and avoid the same scattering that has = happened with TLS VPN's and do
it in one interoperable way = for IKE and IPsec. And I would think getting
the ESPinTCP = will actually be the harder part to get properly supported
inside the kernels.
So I would reluctantly want = to move forward with the idea, although I
need to do more = homework about the implementation details of both drafts.
Paul

I  to = agree with Paul here. 
The question = for me is - what do we want to achieve. If the purpose
is = to be able to work in those environments, where UDP is blocked,
while TCP isn't, then we will soon end up defining IKE and = ESP
over HTTP(S), because it is the most "penetrating" = protocol right now.

Do you have any real = numbers of how often such environments where UDP is blocked, but TCP = (not only TCP:80) is not appear in real life? Could you estimate a = percentage?

So, I'm not yet convinced that = it is a solution to essentially
widespread problem, = however if people run IKE over TCP anyway, then
it is = better to have some standard way to do it. The question - why
do they do it and does it the only way to solve their = problem.

Regarding the draft. You should = probably have mentioned that with IKE over TCP responder looses its = ability to remain stateless and that cookies become useless and SHOULD = NOT be used. 
Regards,
Valery Smyslov.

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_ipsec&d=3DBQIFAg&c=3DeEvniauFctOgLOKGJOplqw&= amp;r=3Dp3wIGO08_H-OJhunJTPABw&m=3D4GK9GDAJB4AfnjxKtZO86J_C51187G2Wd6i= GESlw-tc&s=3Dr-OioL-HDBAQtOyfaWxfvw2XYMyePRHw--cSv0lCNto&e=3D<= /blockquote>

= --Apple-Mail=_806D8701-2F0B-4F9A-83C3-E60010DD7A36-- From nobody Sat Sep 19 02:18:32 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 375E11B573A for ; Sat, 19 Sep 2015 02:18:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 UFPeVY9gyk77 for ; Sat, 19 Sep 2015 02:18:28 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c: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 39F2A1B573C for ; Sat, 19 Sep 2015 02:18:24 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so56161678wic.0 for ; Sat, 19 Sep 2015 02:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ozspoA4lMT9U9ypuLyfIkO+c8qpViOmLcfKAmtuWWGE=; b=pwW350UfoxhIQIPFuGXWkW7rwCOoZI2wJ3kMlWbMrG9kB2+Y00+Kfd2FMBWvf+1ZaG U/DDyfg9e9C2gbkuOpixIGqWjRSWjcxDal6sYTUcFVtjZlSnCKHX6TYEvuDpPbva352r JXn/mKkChH0w47Rq5W8lR1v70p58k9+OhIEBDjiaToSNMNTvqMn6tSYWPFk9gApo79+e Cy857mENO+Dq2Kr384pD+dM9+I8NCM2iuzFYpI3L2ckCFTh4jtPmrO26Tbn5eNFQBwL3 EkwnyYR91HNR8VgraOSh4LpxWlZ2SV/Fppo2YeZ6cRAHRn6v+6JZGjaHMWwGSmE4N4WA bXuQ== X-Received: by 10.180.23.162 with SMTP id n2mr2654585wif.8.1442654303565; Sat, 19 Sep 2015 02:18:23 -0700 (PDT) Received: from [192.168.100.103] ([41.220.113.108]) by smtp.gmail.com with ESMTPSA id ht5sm2389784wib.10.2015.09.19.02.18.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 19 Sep 2015 02:18:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Les Leposo In-Reply-To: Date: Sat, 19 Sep 2015 12:18:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ipsec@ietf.org X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2015 09:18:29 -0000 >>> The real question is whether the networks that don't transport ESP = or >>> ESPinUDP block those packets on purpose or by accident. I don't = think >>> we really have any good numbers on this. >>> If we are doing this as a "workaround" to break through the = administrative >>> boundaries, than we are going to see TCP blocked as well on those >>> networks. And all we have gained is complexity. We'll end up playing = the >>> game of TOR. >> The question for me is - what do we want to achieve. If the purpose >> is to be able to work in those environments, where UDP is blocked, >> while TCP isn't, then we will soon end up defining IKE and ESP >> over HTTP(S), because it is the most "penetrating" protocol right = now. >>=20 >> Do you have any real numbers of how often such environments where UDP = is blocked, but TCP (not only TCP:80) is not appear in real life? Could = you estimate a percentage? >>=20 Whereas it would be nice to get such info- some of the reasons why the = network is set that way could be orthogonal (or even due to = misconfiguration). Is there a threshold for which the use-case is generally acceptable? Even 1% in relation to "potential" total number of connections = (especially w.r.t growth in global IoT and smartphone connections) is = still a lot. >> So, I'm not yet convinced that it is a solution to essentially >> widespread problem, however if people run IKE over TCP anyway, then >> it is better to have some standard way to do it. The question - why >> do they do it and does it the only way to solve their problem. >>=20 As I understand, this could be classified along with the other = =E2=80=9Cmiddle-box=E2=80=9D issues that generally hinder/degrade access = to IKE/IPSec services. Therefore, I generally support solutions that get IKE/IPSEC use-case = coverage closer to 100%. But do agree that the RX processing of incoming IKE/IPSec packets, = particularly at the Kernel, needs to be looked at carefully. From nobody Mon Sep 21 12:44:13 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36FE1B34F7 for ; Mon, 21 Sep 2015 12:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 BR7Cwrz3SYGF for ; Mon, 21 Sep 2015 12:44:10 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5828D1B34EF for ; Mon, 21 Sep 2015 12:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6183; q=dns/txt; s=iport; t=1442864650; x=1444074250; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7KlyI1diIiO0nbUwB4FkvOYYgU62FvQwO2owVAKyodU=; b=MJMZE7I47d60WS+4oPqxxdRrAweYLPyOnglMDXI2XoY70kP8m7AiyVBY yzdjOauE/72Ej20Y717xqXBdnv0vdJyDUvgzVdz1flk//z7+XeOFByB5o G9lcXXZetp9pQUN7V4/CC4TtHSNquKz+PMA7UDIqiNveBSrDQV9FBY7at s=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DYAgCuXABW/5RdJa1dgySBPQa9Qw6HdAKBOTgUAQEBAQEBAYEKhCQBAQEEeRACAQgOAgEDAQIvAh8RHQgCBAENBQ6ICwMSxyQNhFgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXhnOEfYJQgiwRB4QsAQSNNoguAYJJgV2GcoFuk1uHPgEfAUOEAXGIaIEFAQEB X-IronPort-AV: E=Sophos;i="5.17,568,1437436800"; d="p7s'?scan'208";a="33941439" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP; 21 Sep 2015 19:44:09 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t8LJi93U012604 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2015 19:44:09 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Sep 2015 14:44:08 -0500 Received: from xch-aln-007.cisco.com ([173.36.7.17]) by XCH-ALN-007.cisco.com ([173.36.7.17]) with mapi id 15.00.1104.000; Mon, 21 Sep 2015 14:44:08 -0500 From: "Graham Bartlett (grbartle)" To: Tommy Pauly , Valery Smyslov Thread-Topic: [IPsec] WG Interest in TCP Encapsulation Thread-Index: AQHQ8H2pKQrcC1kmKEy2SkF3Rr1V7J5BSP2AgAEJIDyAAKBLAIAAWGkAgASEjQA= Date: Mon, 21 Sep 2015 19:44:08 +0000 Message-ID: References: <4630CF9F-9FC2-4B36-A15B-D7F66C3EB230@apple.com> <22008.52586.571113.776646@fireball.acr.fi> <841D0D8A-2262-49BE-A5FC-F3FC9B50B313@gmail.com> <641F9450-5BF6-43DE-A0A9-168F5022DB62@apple.com> In-Reply-To: <641F9450-5BF6-43DE-A0A9-168F5022DB62@apple.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.5.150821 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3525713050_4524618" MIME-Version: 1.0 Archived-At: Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] WG Interest in TCP Encapsulation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2015 19:44:11 -0000 --B_3525713050_4524618 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi >From my personal experience it=B9s not as high as 10%, but I=B9ve certainly seen a number of cases where either UDP/4500 or ESP, is blocked. (saw a timely example of this at the weekend..) cheers From: IPsec on behalf of Tommy Pauly Date: Saturday, 19 September 2015 00:44 To: Valery Smyslov Cc: IPsecME WG , Paul Wouters Subject: Re: [IPsec] WG Interest in TCP Encapsulation You asked about how widespread this issue is. I cannot provide exact numbers here, but on a global scale, I would estimate that around 10% of networks that mobile customers may be using will block UDP traffic, but allow traffic encapsulated as we define in the draft. --B_3525713050_4524618 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg8nDB Va2xrO/+qqHXJzoXCcSQCmOxaINDfkrEJ1UTkiEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTUwOTIxMTk0NDEwWjANBgkqhkiG9w0BAQEFAASCAQBlmFyx oL/1+kVz0n3a1JMw5pUqdsTe5YxYANFfmCZ75uGEPbQv2kqEnY6tnWgxMiB/c08St1t0+hjC 7Q1w300Anim6Y6kHADnw+i9xgjfqOkAHF6+qVVb2P8UPObTW+XVjBm0/gjLwdk8y0lfnX4r6 FB8qQAB59XyBKw+4Gofu7XoqNmhc1aXI4lXDMTScGbAUwHY8N/t4nfuSxtHPiyAuF/jVF8OX 9dlpX3MhcnFA1Se+6tKQVKugtOwSoI/off71GQCKSt1WpC4s6Naozp/YMerGuE/LwBRalqOX WgkmQZfxD8lQFy5NEXAqT2tbakPxf9OKDFtpyzHEUH5tWklC --B_3525713050_4524618-- From nobody Thu Sep 24 17:09:00 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9519F1B32A2 for ; Thu, 24 Sep 2015 17:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 6cFwhPXZmXD4 for ; Thu, 24 Sep 2015 17:08:57 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491CA1ACF57 for ; Thu, 24 Sep 2015 17:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1443139736; x=2307053336; 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=EUYjjUpNQp/WJZGfQ7clpCAsQTV/4W1aR6w2NuvE4qQ=; b=MDgvRBrX6pWascYR4k4htxQ3xqfl3sAlWqqLNNs+wKJ568RN0sSB6xxPCyeU6MaW W1BQIiRud5vU5OsWQWvdZOLf+uz6xP2I+9B881zzyxOyj38GwlJjlojRC04n/1TE qQtMflg/SmoQm3U4FKUIlIK8VZ6V+aD5RlCM7AGQ+QN6cm8Abnzhnr/qM45IPDsR rV8O5Qr1SOpY+5zi8my0x8808CuhNoLLVKMqeHuAgaMx8jleHbsQ3qLHwYWQGMmE /wBGd0OPpGjKBz5TnsFcgzdziMbgdAB5TUqjdw2xy+4eWQM3QXDqzETxq2l2eX3b 6GFNkvlvwz8AHKSrWWBLug==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id AB.A8.32067.89094065; Thu, 24 Sep 2015 17:08:56 -0700 (PDT) X-AuditID: 11973e13-f79b76d000007d43-4e-56049098bacf Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id C1.91.32123.89094065; Thu, 24 Sep 2015 17:08:56 -0700 (PDT) Received: from [17.153.19.246] by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NV70045XHQW8OA0@cilantro.apple.com> for ipsec@ietf.org; Thu, 24 Sep 2015 17:08:56 -0700 (PDT) Sender: tpauly@apple.com Content-type: multipart/alternative; boundary="Apple-Mail=_D63939AD-04BD-4CB9-AD5A-D911F3CAEF51" MIME-version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Tommy Pauly In-reply-to: Date: Thu, 24 Sep 2015 17:08:56 -0700 Message-id: <98913A93-A631-46B3-B2D6-706250980E82@apple.com> References: <21945.22164.460957.958095@fireball.acr.fi> <365878F7-8629-4B6F-ABB8-62C43EAD4E97@apple.com> <21948.240.780663.729327@fireball.acr.fi> To: IPsecME WG X-Mailer: Apple Mail (2.3094) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUi2FAYrDtjAkuYwam3Zhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRstHw4JTZhWvNzewNTB+1u9i5OSQEDCReDjzFguELSZx4d56 NhBbSGAvo0TH2TKYmg0X9jFDxCcySWxqqupi5AKyfzBKtKw+BtTMwSEsICGxeU8iSA2zQJLE j0d7wOp5BfQkLk3ZyAhiCwvYSqxY95UJxGYTUJE4/m0DWA0nUPzNtZtgNSwCqhIHLs9ghpij KHFwzVFWiDk2Ei9WrmaC2PuCSWLZtidge0UE5CVm3siEuFNW4tbX1ewQ9gY2ic8/0ycwCs9C ctIsJCdBxLUlli18zQxha0rs717OgimuIdH5bSLrAka2VYxCuYmZObqZeaZ6iQUFOal6yfm5 mxhBkTDdTngH4+lVVocYBTgYlXh4FVpZwoRYE8uKK3MPMUpzsCiJ8+7/yBQmJJCeWJKanZpa kFoUX1Sak1p8iJGJg1OqgdHj77Tz56ebfl57jdXlz5tgmx9n98dpH5HJvvjYd3/NC8lry2/u 3f42Ya10iEpYv7aMnVkd30Uupsxm9pOHrAokih/7as6QOrlRbUfAD0MtVWcx9eSz8+7KGz58 7X96rWa66pU1l44f5PgqslPH7efmyTfef37XYVy+cWo5n0Hfn8LNG0S6hT8osRRnJBpqMRcV JwIAz1PL4GUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUi2FAspDtjAkuYwcc3xhb7t7xgc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRstHw4JTZhWvNzewNTB+1u9i5OSQEDCR2HBhHzOELSZx4d56 NhBbSGAik8SmpqouRi4g+wejRMvqYyxdjBwcwgISEpv3JILUMAskSfx4tAesl1dAT+LSlI2M ILawgK3EinVfmUBsNgEViePfNoDVcALF31y7CVbDIqAqceDyDGaIOYoSB9ccZYWYYyPxYuVq Joi9L5gklm17ArZXREBeYuaNTIg7ZSVufV3NPoFRYBaSM2YhOQMiri2xbOFrZghbU2J/93IW THENic5vE1kXMLKtYhQoSs1JrDTWSywoyEnVS87P3cQIDt7C4B2Mf5ZZHWIU4GBU4uFVaGUJ E2JNLCuuzD3EKMHBrCTCy5AAFOJNSaysSi3Kjy8qzUktPsQ4kRHoy4nMUqLJ+cDYyiuJNzQx MTAxNjYzNjY3MaelsJI4L08g0EUC6YklqdmpqQWpRTBHMXFwSjUw7pN/9cz77zzj5s5PNWKP O2rDbBYpf9mgmtwna/n/FpOC25Hnn1Z8CouV3GEeeWaL+341rzulNnzujQ+Y9D7cOzG9oyJU de3hFCmWuWtfikaETZq3QXHLHfZon4msLOuLpIK/y3ydkLti1/SEyPaTJ/Pz8mOMHIXWZhQd kVmbFRPw1UfsTuF6JZbijERDLeai4kQAN0Ix6dECAAA= Archived-At: Cc: Paul Wouters Subject: Re: [IPsec] Split DNS in IKEv2 Configuration Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 00:08:59 -0000 --Apple-Mail=_D63939AD-04BD-4CB9-AD5A-D911F3CAEF51 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello all, Based on the conversation on the IPSec list previously about supporting = Split DNS in IKEv2, Paul and I have written up a draft to add support = for Split DNS (as well as DNSSEC) to the configuration attributes for = IKEv2. We=E2=80=99d like to get feedback from the working group about the level = of interest in this topic, and if people would like to work on adopting = it. Thanks! Tommy =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A new version of I-D, draft-pauly-ipsecme-split-dns-00.txt has been successfully submitted by Tommy Pauly and posted to the IETF repository. Name: draft-pauly-ipsecme-split-dns Revision: 00 Title: Split-DNS Configuration for IKEv2=20 Document date: 2015-09-24 Group: Individual Submission Pages: 10 URL: = https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-dns-00.txt = Status: = https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/ = Htmlized: = https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-00 = Abstract: This document defines two new Configuration Payload Attribute Types for the IKEv2 protocol that together define a set of private DNS domains which should be resolved by DNS servers reachable through an IPsec connection, while leaving all other DNS resolution unchanged. This allows for split-DNS views for multiple domains and includes support for private DNSSEC trust anchors. The information obtained via the new attribute types can be used to reconfigure a locally running DNS server with DNS forwarding for specific private domains. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org = . The IETF Secretariat --Apple-Mail=_D63939AD-04BD-4CB9-AD5A-D911F3CAEF51 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello all,

Based on the conversation on the IPSec = list previously about supporting Split DNS in IKEv2, Paul and I have = written up a draft to add support for Split DNS (as well as DNSSEC) to = the configuration attributes for IKEv2.

We=E2=80=99d like to get feedback from = the working group about the level of interest in this topic, and if = people would like to work on adopting it.

Thanks!
Tommy

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=
A = new version of I-D, draft-pauly-ipsecme-split-dns-00.txt
has= been successfully submitted by Tommy Pauly and posted to the
IETF repository.

Name: = draft-pauly-ipsecme-split-dns
Revision: 00
Title: Split-DNS Configuration for IKEv2 
Document date: 2015-09-24
Group: Individual Submission
Pages: 10
URL: =            https://www.ietf.org/internet-drafts/draft-pauly-ipsecme-split-= dns-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-pauly-ipsecme-split-dns/=
Htmlized:       https://tools.ietf.org/html/draft-pauly-ipsecme-split-dns-00


Abstract:
  This document defines two new Configuration = Payload Attribute Types
  for the IKEv2 protocol = that together define a set of private DNS
  domains which should be resolved by DNS servers = reachable through an
  IPsec connection, while = leaving all other DNS resolution unchanged.
  This= allows for split-DNS views for multiple domains and includes
  support for private DNSSEC trust anchors. =  The information obtained
  via the new = attribute types can be used to reconfigure a locally
  running DNS server with DNS forwarding for = specific private domains.




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

The IETF = Secretariat

= --Apple-Mail=_D63939AD-04BD-4CB9-AD5A-D911F3CAEF51-- From nobody Thu Sep 24 19:36:27 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FCA31B3537 for ; Thu, 24 Sep 2015 19:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 zJNh8TSEFYGR for ; Thu, 24 Sep 2015 19:36:23 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACB571B3532 for ; Thu, 24 Sep 2015 19:36:23 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nMcnG166tz9K; Fri, 25 Sep 2015 04:36:18 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=jOK23oTl X-OPENPGPKEY: Message passed unmodified 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 PTUom0Ap0pQO; Fri, 25 Sep 2015 04:36:17 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 25 Sep 2015 04:36:17 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F11958009F; Thu, 24 Sep 2015 22:36:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1443148576; bh=ZFaykAIGUJP1mP2RjjComg6b9y4yJPScnE5Ea0HHpow=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jOK23oTlDq0paaszBgydGUpfUua+9JsVICCe5qCAcWijgpZLV7CWZ6Agut6CUqTDT WQnOH8kq8Q9jVIMsRkYnpiLwvi3QcsIGqANuwuElyUTTck0x+K3faPm0SjBoIJmqi8 TRTkN03LRMN35NA83CefiAbIyAOirwfMQ4uvAHYU= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t8P2aFbA011334; Thu, 24 Sep 2015 22:36:15 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Thu, 24 Sep 2015 22:36:15 -0400 (EDT) From: Paul Wouters To: Tommy Pauly In-Reply-To: <98913A93-A631-46B3-B2D6-706250980E82@apple.com> Message-ID: References: <21945.22164.460957.958095@fireball.acr.fi> <365878F7-8629-4B6F-ABB8-62C43EAD4E97@apple.com> <21948.240.780663.729327@fireball.acr.fi> <98913A93-A631-46B3-B2D6-706250980E82@apple.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: IPsecME WG Subject: Re: [IPsec] Split DNS in IKEv2 Configuration Payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2015 02:36:25 -0000 On Thu, 24 Sep 2015, Tommy Pauly wrote: > We’d like to get feedback from the working group about the level of interest in this topic, and if people would like to work on adopting it. One item we were not sure about is the format of the INTERNAL_DNSSEC_TA. While a DS record is shorter and nicer and easier to add as configuration option, it requires the initiator to do an (insecure?) DNS request for the DNSKEY, then convert/verify it with with the DS record. It would be easier for the client to be given the DNSKEY. But DNSKEYs are much bigger and unwielding and would be pretty ugly in configuration files on the responder side. Paul From nobody Mon Sep 28 06:11:10 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFBE1A904C for ; Mon, 28 Sep 2015 06:11:08 -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 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 c8mqN8X7NOOr for ; Mon, 28 Sep 2015 06:11:07 -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 82D511A904E for ; Mon, 28 Sep 2015 06:11:07 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8SDB5XZ008862 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 28 Sep 2015 16:11:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8SDB4kM005070; Mon, 28 Sep 2015 16:11:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22025.15464.790587.801082@fireball.acr.fi> Date: Mon, 28 Sep 2015 16:11:04 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 13 min Archived-At: Subject: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 13:11:09 -0000 We did update cryptographic algorithms for ESP and AH (RFC4305->4835->7321), but we have never updated the RFC4307. I think there should be update for that document too, as it now defines following madantory to implement algorithms: 1024 MODP Group, ENCR_3DES, PRF_HMAC_SHA1, AUTH_HMAC_SHA1_96. And I think at least the 1024-bit MODP groupp, and perhaps the 3DES also should be changed to something more suitable. For exmple 2048-bit MODP group and ENCR_AES_CBC... We had this discussion about two years ago last time, but nothing came out from there (Hmm.. did I promise to do something, I hope not). Perhaps this time? https://www.ietf.org/mail-archive/web/ipsec/current/msg08597.html -- kivinen@iki.fi From nobody Mon Sep 28 07:19:28 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97461A9250 for ; Mon, 28 Sep 2015 07:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 F0YQE31Ru7ml for ; Mon, 28 Sep 2015 07:19:25 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8131A924B for ; Mon, 28 Sep 2015 07:19:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3nPmF60v44zDn7; Mon, 28 Sep 2015 16:19:22 +0200 (CEST) Authentication-Results: mx.nohats.ca; dkim=pass (1024-bit key) header.d=nohats.ca header.i=@nohats.ca header.b=cG45pr/h X-OPENPGPKEY: Message passed unmodified 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 1iZrYk9eRZ-e; Mon, 28 Sep 2015 16:19:21 +0200 (CEST) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 28 Sep 2015 16:19:21 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B8C9F80030; Mon, 28 Sep 2015 10:19:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1443449959; bh=/J/kqgQrXtpB3Nzs+F3UlZZ90yr3y+aCITe5jilqyj4=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=cG45pr/h5rCMLYUuXTp+J2dvC3iY7wv9qE7SIQ8eSUsPB3VeuLmeaXq+0Anl0wtyR SqiseAIKnOI7G34rAXk4JqdPqhejUjC7NwkNWEB8O6AmGNDb0gy4aLmFgOXp6ps8Yd Y0656/7tlrCKsjjloRMkBYKYUSgSVYcSah3GnKaM= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.15.2/8.15.2/Submit) with ESMTP id t8SEJJ5N025410; Mon, 28 Sep 2015 10:19:19 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 28 Sep 2015 10:19:19 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22025.15464.790587.801082@fireball.acr.fi> Message-ID: References: <22025.15464.790587.801082@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 14:19:27 -0000 On Mon, 28 Sep 2015, Tero Kivinen wrote: > I think there should be update for that document too, as it now > defines following madantory to implement algorithms: > > 1024 MODP Group, ENCR_3DES, PRF_HMAC_SHA1, AUTH_HMAC_SHA1_96. > > And I think at least the 1024-bit MODP groupp, and perhaps the 3DES > also should be changed to something more suitable. For exmple 2048-bit > MODP group and ENCR_AES_CBC... > Perhaps this time? It is. especially 2048 modp would be good, as most IKEv2 implementations already try that as their default group. Demoting 3des/m5/sha1 and pulling in aes_gcm and sha2 would be good I think. Paul From nobody Mon Sep 28 07:38:29 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113771A92B7 for ; Mon, 28 Sep 2015 07:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 qE4kZyrSUzPc for ; Mon, 28 Sep 2015 07:38:26 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CCD91A92E3 for ; Mon, 28 Sep 2015 07:38:26 -0700 (PDT) Received: by wiclk2 with SMTP id lk2so108492579wic.0 for ; Mon, 28 Sep 2015 07:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=x4QCpRFKSnn5MK3tgBAvoak21wOR+eT25+Q1ar+uy6g=; b=XOzAuaOrHQuZvgvO6roRml2XSIaL2gyXHmjYmiHnGyDMqfqRCGGsxABuT8WS9X3Pka 7epBRPmTe9mzC5thdcM0zdwnAnDPRP//H9ktV/Kw40d64ZZLkqteVbwSpQ+7aJhps1CH 8F8FQoDyXifL8OALcsYQ5yosZrshMtkTYCFfmmeXHPrRzNjyCYXFjrUYK47oZXK3nRIk SaoLe5F4ev+62VxkfEixIA5W47XFzJ7Fola9KsY65UWj8AoDpf6PmfchVOPSmPdAtrMf ItKOs5nmrYqQVYw9x8lkompu7aIJTT4JDqNrPKjQzNS8CsMO5JW8k5uE1/JzA6EQYYr+ okyA== X-Received: by 10.180.182.84 with SMTP id ec20mr19740007wic.42.1443451104942; Mon, 28 Sep 2015 07:38:24 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id xa5sm12012937wjc.20.2015.09.28.07.38.23 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 07:38:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <22025.15464.790587.801082@fireball.acr.fi> Date: Mon, 28 Sep 2015 17:38:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <22025.15464.790587.801082@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 14:38:28 -0000 > On Sep 28, 2015, at 4:11 PM, Tero Kivinen wrote: >=20 > We did update cryptographic algorithms for ESP and AH > (RFC4305->4835->7321), but we have never updated the RFC4307. >=20 > I think there should be update for that document too, as it now > defines following madantory to implement algorithms: >=20 > 1024 MODP Group, ENCR_3DES, PRF_HMAC_SHA1, AUTH_HMAC_SHA1_96. >=20 > And I think at least the 1024-bit MODP groupp, and perhaps the 3DES > also should be changed to something more suitable. For exmple 2048-bit > MODP group and ENCR_AES_CBC... >=20 > We had this discussion about two years ago last time, but nothing came > out from there (Hmm.. did I promise to do something, I hope not). >=20 > Perhaps this time?=20 Totally yes. Group Number Bit Length Status Defined 2 1024 MODP Group MUST- [RFC2409] MUST- This term means the same as MUST. However, we expect at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST- algorithm, it will remain at least a SHOULD or a SHOULD-. =E2=80=9CSome point=E2=80=9D has arrived, and I don=E2=80=99t think = group #2 should even be SHOULD- at this point. So what should we specify now? My opinion: DH Groups 14: MUST 19: SHOULD+ Type 1 algorithms: ENCR_AES_CBC: MUST- AES-GCM with 16 octet ICV: MUST ENCR_CHACHA20_POLY1305: SHOULD+ =20 Type 2 algorithm: PRF_HMAC_SHA1: MUST- PRF_HMAC_SHA2_256: MUST PRF_HMAC_SHA2_512: SHOULD+ =20 Type 3 algorithm: AUTH_HMAC_SHA1_96: MUST- AUTH_HMAC_SHA2_256_128: MUST AUTH_HMAC_SHA2_512_256: SHOULD+ (or maybe AUTH_AES_256_GMAC??) Yoav =20= From nobody Mon Sep 28 08:10:19 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFFB1AC40D for ; Mon, 28 Sep 2015 08:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 h6QAyv5jWiuc for ; Mon, 28 Sep 2015 08:10:17 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686991AC40B for ; Mon, 28 Sep 2015 08:10:17 -0700 (PDT) Received: from [10.32.60.125] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8SFAGZ4030004 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Sep 2015 08:10:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.125] From: "Paul Hoffman" To: ipsec@ietf.org Date: Mon, 28 Sep 2015 08:10:15 -0700 Message-ID: In-Reply-To: <22025.15464.790587.801082@fireball.acr.fi> References: <22025.15464.790587.801082@fireball.acr.fi> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 15:10:18 -0000 Sure. Someone volunteer to write up the short draft, and that author should put Jeff Schiller at the top of the acknowledgements, and send it to the WG. --Paul Hoffman From nobody Mon Sep 28 08:57:17 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 526E71ACD8F for ; Mon, 28 Sep 2015 08:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 w2HcMq0CGwzd for ; Mon, 28 Sep 2015 08:57:13 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B341ACD96 for ; Mon, 28 Sep 2015 08:57:09 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 7AC8F2002A for ; Mon, 28 Sep 2015 11:58:35 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 7D081637F8; Mon, 28 Sep 2015 11:57:08 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 67F2F637F3 for ; Mon, 28 Sep 2015 11:57:08 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: <22025.15464.790587.801082@fireball.acr.fi> References: <22025.15464.790587.801082@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 15:57:14 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > We did update cryptographic algorithms for ESP and AH > (RFC4305->4835->7321), but we have never updated the RFC4307. > I think there should be update for that document too, as it now defines > following madantory to implement algorithms: > 1024 MODP Group, ENCR_3DES, PRF_HMAC_SHA1, AUTH_HMAC_SHA1_96. > And I think at least the 1024-bit MODP groupp, and perhaps the 3DES > also should be changed to something more suitable. For exmple 2048-bit > MODP group and ENCR_AES_CBC... I guess the can-o-worms called ECDSA will show up too as a SHOULD+. Does 3DES go to MAY? Does SHA1 go to MUST-? We hadn't listed SHA2 at all before. We also have no GCM/CCM things specified. Are we obligted to list them as SHOULD+ for awhile? I think that the updates will otherwise be non-controversial. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVgljVICLcPvd0N1lAQIw1AgAiDNrjg7cDYowU/ZXG4HVr0c3IuRjmiXw zIB8/dHZKr4TIoEFLESucgVyULZDwFeXYiH5iPM4JsVElTNrJzaf2YoErA0We5x+ jE5AXP3pf1jCcAY/F0Cui7+iM4xIGKtHTZb9tGuTRoykalO+6KUhnv7uWlLKlSHh Z39QWCzCB65IJ0c4Pm7Cp/KJc5Itj3bJ+dKYhg6VtZvT+JAdXHw6UlOp8JcwhvhZ eOMXDLkO0YN7D6tDC8uLCCNuzeyRsFfGUrVu4olQ4X0iW0FmHiT8y+2zJmNvXBWb qXZDFNWTOqJHeVvxfJVe+D7cADR73a8hVTl7jSURv1j5uK+CePuZXg== =45vd -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 28 09:10:14 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AED1A1A5F for ; Mon, 28 Sep 2015 09:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 kScQfEuzYEiy for ; Mon, 28 Sep 2015 09:10:11 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8891ACDDC for ; Mon, 28 Sep 2015 09:10:11 -0700 (PDT) Received: from [10.32.60.125] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8SGAADT031945 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 28 Sep 2015 09:10:10 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.125] From: "Paul Hoffman" To: "IPsecME WG" Date: Mon, 28 Sep 2015 09:10:09 -0700 Message-ID: <188E4C05-A49E-4E5E-9372-32CB35729E2E@vpnc.org> In-Reply-To: References: <20150918142727.14681.30680.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Subject: Re: [IPsec] Last Call: (Minimal IKEv2) to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 16:10:12 -0000 Tero has updated this draft based on a lot of input so far in the IETF Last Call, particularly from Paul Wouters. The latest version is at . If you are an IKEv2 implementer, please review the draft and send comments during the IETF Last Call. --Paul Hoffman On 18 Sep 2015, at 8:05, Paul Hoffman wrote: > Of interest to people in this WG. If you have comments on the draft, > please send them to ietf@ietf.org, not on this list. > > --Paul Hoffman > > Forwarded message: > >> From: The IESG >> To: IETF-Announce >> Cc: lwip@ietf.org >> Subject: Last Call: (Minimal >> IKEv2) to Informational RFC >> Date: Fri, 18 Sep 2015 07:27:27 -0700 >> >> >> The IESG has received a request from the Light-Weight Implementation >> Guidance WG (lwig) to consider the following document: >> - 'Minimal IKEv2' >> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to >> the >> ietf@ietf.org mailing lists by 2015-10-02. Exceptionally, comments >> may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document describes minimal version of the Internet Key Exchange >> version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for >> performing mutual authentication and establishing and maintaining >> Security Associations (SAs). IKEv2 includes several optional >> features, which are not needed in minimal implementations. This >> document describes what is required from the minimal implementation, >> and also describes various optimizations which can be done. The >> protocol described here is compliant with full IKEv2 with exception >> that this document describes mainly shared secret authentication >> (IKEv2 requires support for certificate authentication in addition to >> shared secret authentication). >> >> This document does not update or modify RFC 7296, but provides more >> compact description of the minimal version of the protocol. If this >> document and RFC 7296 conflicts then RFC 7296 is the authoritative >> description. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-lwig-ikev2-minimal/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Sep 28 10:34:44 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 889501AD17F for ; Mon, 28 Sep 2015 10:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 mYUif4XKNrZS for ; Mon, 28 Sep 2015 10:34:42 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c: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 8652B1AD1D5 for ; Mon, 28 Sep 2015 10:34:34 -0700 (PDT) Received: by wicgb1 with SMTP id gb1so114288026wic.1 for ; Mon, 28 Sep 2015 10:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KpqsuRAd66m4S/TlXWBBPtnBY9E9OWACo3cl2ovhX2k=; b=RrF/JVgO4tEpDjxkRYvr+IEJ34VcNHV5mh1rUFsbSg4WknzmYBx9bweAsnfry87IcG U1CSFiurHGpAkyC7vh50IzuYTbqpmDRbea1LiSolJWrZVh6mKxaa9WpQ4m02H/ByrJDm yhonXb11pLWS/fnyTVKrVrQt4QZa1sNWTic5LSFIj5z32i2dpY9K9xH7gDVwzWVqhLF3 2YQJVqK7/cQIxODZbFyupV8QAAKb1zXgAw01me/F5ac6sTTOHsGuoWYxGKoh1jAvdMUn 2oHd0w/LQmA/0h520bBvISOiBHIVWgL5HZBRmokBXd5uepxYUQwdxR260ptqdanRTvxF tA2A== X-Received: by 10.180.219.106 with SMTP id pn10mr21351993wic.56.1443461673019; Mon, 28 Sep 2015 10:34:33 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id ew2sm19388244wic.20.2015.09.28.10.34.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 10:34:31 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <23473.1443455828@sandelman.ca> Date: Mon, 28 Sep 2015 20:34:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <341A30F0-786A-48E5-BC03-C79420E4C1B8@gmail.com> References: <22025.15464.790587.801082@fireball.acr.fi> <23473.1443455828@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 17:34:43 -0000 > On Sep 28, 2015, at 6:57 PM, Michael Richardson = wrote: >=20 >=20 > Tero Kivinen wrote: >> We did update cryptographic algorithms for ESP and AH >> (RFC4305->4835->7321), but we have never updated the RFC4307. >=20 >> I think there should be update for that document too, as it now = defines >> following madantory to implement algorithms: >=20 >> 1024 MODP Group, ENCR_3DES, PRF_HMAC_SHA1, AUTH_HMAC_SHA1_96. >=20 >> And I think at least the 1024-bit MODP groupp, and perhaps the 3DES >> also should be changed to something more suitable. For exmple = 2048-bit >> MODP group and ENCR_AES_CBC... >=20 > I guess the can-o-worms called ECDSA will show up too as a SHOULD+. Does it have to? 4307 does not mention any signature algorithms. ECDH = with NIST curves and/or the new curves might should make an appearance. > Does 3DES go to MAY? I think so. > Does SHA1 go to MUST-? >=20 > We hadn't listed SHA2 at all before. > We also have no GCM/CCM things specified. >=20 > Are we obligted to list them as SHOULD+ for awhile? I think we should reflect what is common/best practice now. AES-GCM is = now widely implemented and faster than the combination of AES-CBC and = HMAC-SHA-something. I think it=E2=80=99s a prime candidate for MUST. CTR = was always uncommon. ChaCha20+Poly1305 is so new that it can't be MUST = this iteration. Maybe next time. > I think that the updates will otherwise be non-controversial. Maybe. Yoav From nobody Mon Sep 28 12:39:34 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220FF1B2C06 for ; Mon, 28 Sep 2015 12:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 AJabXmeCWM6K for ; Mon, 28 Sep 2015 12:39:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E53001B2C03 for ; Mon, 28 Sep 2015 12:39:29 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 22AAE2002A for ; Mon, 28 Sep 2015 15:40:56 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 899D4637F8; Mon, 28 Sep 2015 15:39:28 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 702CD637F3 for ; Mon, 28 Sep 2015 15:39:28 -0400 (EDT) From: Michael Richardson To: ipsec@ietf.org In-Reply-To: References: <22025.15464.790587.801082@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 19:39:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: > =E2=80=9CSome point=E2=80=9D has arrived, and I don=E2=80=99t think g= roup #2 should even be > SHOULD- at this point. MAY or SHOULD NOT? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVgmXcICLcPvd0N1lAQIL9AgAkHTgNtFf3rQZDoEpZbxUkEGp3XRzuiyR T007/xWsB5dcaK7/cJE7bqbkC70tTZJaiZbvridR222a01u9EOiT8Ow190fmIVP2 KEXEBTt+up3qomU0o1IFg97I6Wtq3Vlx0K+pKF+aEUkNiXLnQ2Mjm3eqDLEsglom NOgutz5RTCf6BKlyS2EW7AenkefZctLNbTWgiV1B7XR4qCOvmw+HfDbgNveWmZRk YQz48K4ELRGG/xqL1pVi+mazc0GihQITT6MLI//ni34cdmcDEOnEAJg5a6OF4Zuh b01YeqfjGEf7+CLRBwK158jzmY+K8PH46DjZyRZwMso9hIAzriGLdw== =pSv4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 28 12:40:59 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C64741B2C1C for ; Mon, 28 Sep 2015 12:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham 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 sVR_SAciDhVR for ; Mon, 28 Sep 2015 12:40:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BCD41B2C23 for ; Mon, 28 Sep 2015 12:40:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F14CD2002A; Mon, 28 Sep 2015 15:42:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 62820637F8; Mon, 28 Sep 2015 15:40:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 48C1C637F3; Mon, 28 Sep 2015 15:40:48 -0400 (EDT) From: Michael Richardson To: Yoav Nir In-Reply-To: <341A30F0-786A-48E5-BC03-C79420E4C1B8@gmail.com> References: <22025.15464.790587.801082@fireball.acr.fi> <23473.1443455828@sandelman.ca> <341A30F0-786A-48E5-BC03-C79420E4C1B8@gmail.com> X-Mailer: MH-E 8.6; nmh 1.3-dev; GNU Emacs 24.4.2 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 19:40:51 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yoav Nir wrote: >> Tero Kivinen wrote: >>> We did update cryptographic algorithms for ESP and AH >>> (RFC4305->4835->7321), but we have never updated the RFC4307. >> >>> I think there should be update for that document too, as it now >>> defines following madantory to implement algorithms: >> >>> 1024 MODP Group, ENCR_3DES, PRF_HMAC_SHA1, AUTH_HMAC_SHA1_96. >> >>> And I think at least the 1024-bit MODP groupp, and perhaps the 3DES >>> also should be changed to something more suitable. For exmple >>> 2048-bit MODP group and ENCR_AES_CBC... >> >> I guess the can-o-worms called ECDSA will show up too as a SHOULD+. > Does it have to? 4307 does not mention any signature algorithms. ECDH > with NIST curves and/or the new curves might should make an appearanc= e. Sorry, that's what I meant to write, but my finger slipped. >> Does 3DES go to MAY? > I think so. >> Does SHA1 go to MUST-? >> >> We hadn't listed SHA2 at all before. We also have no GCM/CCM things >> specified. >> >> Are we obligted to list them as SHOULD+ for awhile? > I think we should reflect what is common/best practice now. AES-GCM is > now widely implemented and faster than the combination of AES-CBC and > HMAC-SHA-something. I think it=E2=80=99s a prime candidate for MUST. = CTR was > always uncommon. ChaCha20+Poly1305 is so new that it can't be MUST th= is > iteration. Maybe next time. Agreed. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVgmXwICLcPvd0N1lAQKUvAgAgEuUgpOxLXRWVFX9G9NIOdQqYz7yT3aC ESgxLm22YLr0vfsgir1vuKyc02sotSkBEJe19Hu44sDYV/+eFAsThVojEjrLtUQx 7rDxDmE2sMYCpkNcqYRFmCSVO/KRFazk337LZsXwFzxelZyw9Av0orUXLjnsq+54 tQV+qVB3gGPXrvJ7j79Bcef9tqwOgdeXZ4aLeP76SMmrfu3BVm7XBXIEr5uYJE/u 94rvRZ7FcUGz3bufQ7aRdUfKqYmORy7TmQH3dMXJYJYL+uVz65uxv+WRvn8buy1/ utoThXMV0BU25HMxlGAk/h6kmmwNdszQOC+ogrTQaFAyfdVsm5MErg== =kgxv -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Sep 28 13:42:41 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7E11B32CB for ; Mon, 28 Sep 2015 13:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 ZPVp62hIPCaE for ; Mon, 28 Sep 2015 13:42:39 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 E40681B321F for ; Mon, 28 Sep 2015 13:42:38 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so122218753wic.1 for ; Mon, 28 Sep 2015 13:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EsE0dwMsAlcFqmvtGI5jpBhkASYSdW3jIXL8MGMGBFk=; b=qGtgYTXQ4MV6qDL2zaE6vpWWafhuRKs/WOyv5MjDqB3QIui2heZADh1QGcHQ3SXYay gUhjOReRTE0h9XMj7+JF26YVGX5ChXWz5SqVpH19mGLJCPc1+vjBb878BjYtQksLZDq1 6UcBD7YPVpwUdqhx9N5bMu5uRUwAK08DaAOxA4HnRCZd0jZccZQFI9otthPaNoobDTbG ycbpMTCpUueXg7tgY1plb1kpOz3GTjImL0XucZ1Y6jONrNO0RlsVa3PupGLdDsz/iYja x60WNpG8XlrTYcwD1OhSJ6oB29fjgctT0ozJSg44CacT9+yeseeWsOlaoh7EZXT5XLl/ gcRw== X-Received: by 10.180.211.10 with SMTP id my10mr21560116wic.84.1443472957542; Mon, 28 Sep 2015 13:42:37 -0700 (PDT) Received: from [192.168.1.12] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id s9sm20221121wjy.16.2015.09.28.13.42.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Sep 2015 13:42:36 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <15683.1443469168@sandelman.ca> Date: Mon, 28 Sep 2015 23:42:31 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <64B0C0F8-2B3E-4C96-909B-F82A5E1C68D2@gmail.com> References: <22025.15464.790587.801082@fireball.acr.fi> <15683.1443469168@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2015 20:42:40 -0000 > On Sep 28, 2015, at 10:39 PM, Michael Richardson = wrote: >=20 >=20 > Yoav Nir wrote: >> =E2=80=9CSome point=E2=80=9D has arrived, and I don=E2=80=99t think = group #2 should even be >> SHOULD- at this point. >=20 > MAY or SHOULD NOT? I=E2=80=99m thinking SHOULD NOT. Everyone phased out 1024-bit RSA = signatures a few years ago. It can be argued that 1024-bit key agreement = is worse than 1024-bit signatures, because if the attacker will be able = to crack 1024-bit RSA or DH in 2018, then they can break any IKE that = they recorded today that uses the 1024-bit MODP group. OTOH knowing how = to break 1024-bit RSA in 2018 doesn=E2=80=99t help them impersonate = anyone today, so a safety margin seems more important for D-H than for = signatures. Yoav From nobody Tue Sep 29 02:15:27 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC0D21A6FFB for ; Tue, 29 Sep 2015 02:15:25 -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 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 zz78LoUsNV_l for ; Tue, 29 Sep 2015 02:15:23 -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 7E3901A6F52 for ; Tue, 29 Sep 2015 02:15:23 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8T9FJU1027277 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Sep 2015 12:15:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8T9FIkU012691; Tue, 29 Sep 2015 12:15:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22026.22182.641180.888851@fireball.acr.fi> Date: Tue, 29 Sep 2015 12:15:18 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <341A30F0-786A-48E5-BC03-C79420E4C1B8@gmail.com> References: <22025.15464.790587.801082@fireball.acr.fi> <23473.1443455828@sandelman.ca> <341A30F0-786A-48E5-BC03-C79420E4C1B8@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 27 min X-Total-Time: 30 min Archived-At: Cc: ipsec@ietf.org, Michael Richardson Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 09:15:26 -0000 Yoav Nir writes: > > Does SHA1 go to MUST-=3F > >=20 > > We hadn't listed SHA2 at all before. > > We also have no GCM/CCM things specified. > >=20 > > Are we obligted to list them as SHOULD+ for awhile=3F >=20 > I think we should reflect what is common/best practice now. AES-GCM > is now widely implemented and faster than the combination of AES-CBC > and HMAC-SHA-something. Remember that we are talking about the IKEv2 SA now, not ESP, or AH. The main reason for AES-GCM is the speed, and that that you do not need to implement HMAC based MAC. In the IKEv2 those arguments are not very valid. We do not really encrypt that much data in IKEv2 SA that speed would matter. Also we always need to have some PRF to extract the keying material from the DH output. On the other hand I have seen some questions about the suitability of the CMAC as PRFs to extract keying material (i.e as KDF). Not sure whether XCBC is any better. https://www.ietf.org/mail-archive/web/cfrg/current/msg02693.html Because of this it might be that we want to keep one HMAC based PRF as mandatory to implement anyways, thus using same HMAC for authentication does not add any code.=20 > I think it=E2=80=99s a prime candidate for MUST. CTR was always uncom= mon. The small IoT devices would most likely want to use AES-CCM based systems, mostly because they might already have that on the hardware. > ChaCha20+Poly1305 is so new that it can't be MUST this iteration. > Maybe next time. Yep.=20 > > I think that the updates will otherwise be non-controversial. So my take would be: DH group 2 1024-bit MODP =09MUST- -> MAY DH group 14 2048-bit MODP=09SHOULD+ -> MUST Not sure which elliptic curves to propose. The NIST groups 19-21 has the problem that there has been two complient ways to implement them and those two ways are not interoperable, thus they would be bad idea for mandatory to implement algorithm (i.e. they do not guarantee interoperability). Brainpool curves are not that widely implemented, and the cfrg is now working on adding another groups. Perhaps we can add those new groups as SHOULD+ in the next iteration and leave this draft as MODP only for now. IKEv2 Transform Type 1 Algorithms ENCR=5FDES=09=09=09MAY -> MUST NOT ENCR=5F3DES=09=09=09MUST- -> MAY ENCR=5FAES=5FCBC =09SHOULD+ -> MUST=20 ENCR=5FAES=5FCTR =09SHOULD -> MAY ENCR=5FCHACHA20=5FPOLY1305=09=09MAY -> SHOULD+ We could also add=20 ENCR=5FAES=5FCCM=5F8=09=09=09MAY -> SHOULD AES-GCM with a 8 octet ICV=09MAY -> SHOULD but as this is IKEv2 SA we are talking about, we can just leave them out, and say we have AES as primary algorithm and CHACHA20=5FPOLY1305 a= s backup.=20 IKEv2 Transform Type 2 Algorithms PRF=5FHMAC=5FMD5 MAY -> MAY PRF=5FHMAC=5FSHA1 MUST -> MUST- PRF=5FAES128=5FCBC SHOULD+ -> SHOULD PRF=5FHMAC=5FSHA2=5F256 MAY -> SHOULD+ IKEv2 Transform Type 3 Algorithms AUTH=5FHMAC=5FMD5=5F96 MAY -> MAY AUTH=5FHMAC=5FSHA1=5F96 MUST -> MUST- AUTH=5FAES=5FXCBC=5F96 SHOULD+ -> SHOULD AUTH=5FHMAC=5FSHA2=5F256=5F128=09 MAY -> SHOULD+ --=20 kivinen@iki.fi From nobody Tue Sep 29 04:10:01 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132891A0173 for ; Tue, 29 Sep 2015 04:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 vsAQ0eaXhk31 for ; Tue, 29 Sep 2015 04:09:58 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (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 C26E21A0161 for ; Tue, 29 Sep 2015 04:09:57 -0700 (PDT) Received: by wicfx3 with SMTP id fx3so144786733wic.1 for ; Tue, 29 Sep 2015 04:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VJECyU/DtBOHlRQxjwOeQ00RVbvDilDvyOY5EfBQKVY=; b=wnn2phfXhuSyPzrP/R03iyQCLT/6T0bn6JEIuSxOemnYJb+UU3RF7ENVOmE+f14ret uj0ECURtBpfq1MQeVSF5jYvFeym1AtE/Boh7uddYqUhMw+MBqaxKabvoyhiOG7R102hE q339LP/NVHTCLfligM/nefO9d8oGqQhKKHOi/wtaj735J/P4uugzdhhBOQOckZIbq40W Qwzg5Ppcu7Q5P277hb66B4iaTaARYHzIBbfxF9q8mPMUwopM8/xZnJVEyzbsx3qGyIzT UWdaEaCVw4CfW0iTLIyqcA1JRWDoZQ280kC10asZDG6iTAV1Gmw32q8MzMPO/sdgOmBZ IZCQ== X-Received: by 10.180.24.72 with SMTP id s8mr22954281wif.49.1443524996234; Tue, 29 Sep 2015 04:09:56 -0700 (PDT) Received: from [172.24.251.16] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id kj5sm23345713wjb.19.2015.09.29.04.09.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Sep 2015 04:09:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Yoav Nir In-Reply-To: <22026.22182.641180.888851@fireball.acr.fi> Date: Tue, 29 Sep 2015 14:09:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <67BEF329-1905-439B-A172-E10834FF46B5@gmail.com> References: <22025.15464.790587.801082@fireball.acr.fi> <23473.1443455828@sandelman.ca> <341A30F0-786A-48E5-BC03-C79420E4C1B8@gmail.com> <22026.22182.641180.888851@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.2104) Archived-At: Cc: ipsec@ietf.org, Michael Richardson Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 11:10:00 -0000 > On Sep 29, 2015, at 12:15 PM, Tero Kivinen wrote: >=20 > Yoav Nir writes: >>> Does SHA1 go to MUST-? >>>=20 >>> We hadn't listed SHA2 at all before. >>> We also have no GCM/CCM things specified. >>>=20 >>> Are we obligted to list them as SHOULD+ for awhile? >>=20 >> I think we should reflect what is common/best practice now. AES-GCM >> is now widely implemented and faster than the combination of AES-CBC >> and HMAC-SHA-something. >=20 > Remember that we are talking about the IKEv2 SA now, not ESP, or AH. >=20 > The main reason for AES-GCM is the speed, and that that you do not > need to implement HMAC based MAC. In the IKEv2 those arguments are not > very valid. We do not really encrypt that much data in IKEv2 SA that > speed would matter. This makes sense. AES-GCM is defined for IKE in RFC 5282, but if you = need to encrypt so much in IKE that AES-CBC + HMAC-SHA-something is not = fast enough, you=E2=80=99re doing it wrong regardless of how weak your = processor is.=20 > Also we always need to have some PRF to extract > the keying material from the DH output. >=20 > On the other hand I have seen some questions about the suitability of > the CMAC as PRFs to extract keying material (i.e as KDF). Not sure > whether XCBC is any better. >=20 > https://www.ietf.org/mail-archive/web/cfrg/current/msg02693.html >=20 > Because of this it might be that we want to keep one HMAC based PRF as > mandatory to implement anyways, thus using same HMAC for > authentication does not add any code.=20 I have thought about that a bit. The way the KDF is defined in IKEv2 = limits us to functions that play well with PRF+. I=E2=80=99m thinking = that we should extend or update IKE to be able to work with other KDFs = such as HKDF or SHAKE128 or Blake2 or just some some natural PRF based = on ChaCha20. But that is not for *this* iteration of 4307 even if we = started working on that tomorrow. >> I think it=E2=80=99s a prime candidate for MUST. CTR was always = uncommon. >=20 > The small IoT devices would most likely want to use AES-CCM based > systems, mostly because they might already have that on the hardware. >=20 >> ChaCha20+Poly1305 is so new that it can't be MUST this iteration. >> Maybe next time. >=20 > Yep.=20 >=20 >>> I think that the updates will otherwise be non-controversial. >=20 > So my take would be: >=20 > DH group 2 1024-bit MODP MUST- -> MAY > DH group 14 2048-bit MODP SHOULD+ -> MUST >=20 > Not sure which elliptic curves to propose. The NIST groups 19-21 has > the problem that there has been two complient ways to implement them > and those two ways are not interoperable, thus they would be bad idea > for mandatory to implement algorithm (i.e. they do not guarantee > interoperability). Is that still an issue? I thought this was a bug some years ago that = everyone had fixed, no? > Brainpool curves are not that widely implemented, > and the cfrg is now working on adding another groups. Perhaps we can > add those new groups as SHOULD+ in the next iteration and leave this > draft as MODP only for now. I don=E2=80=99t have a survey of implementations, but I think 19,20, and = 21 and more widely implemented than groups 15-18. So if somebody gets = uncomfortable with 2048 bits (see [1]) it=E2=80=99s better to recommend = that people move to an EC curve. I=E2=80=99d rather this be done with = something that=E2=80=99s well established rather than something that is = in a -00 draft submitted this month, but we should find out if interop = works right now. > IKEv2 Transform Type 1 Algorithms >=20 > ENCR_DES MAY -> MUST NOT > ENCR_3DES MUST- -> MAY > ENCR_AES_CBC SHOULD+ -> MUST=20 > ENCR_AES_CTR SHOULD -> MAY > ENCR_CHACHA20_POLY1305 MAY -> SHOULD+ >=20 > We could also add=20 >=20 > ENCR_AES_CCM_8 MAY -> SHOULD > AES-GCM with a 8 octet ICV MAY -> SHOULD >=20 > but as this is IKEv2 SA we are talking about, we can just leave them > out, and say we have AES as primary algorithm and CHACHA20_POLY1305 as > backup.=20 >=20 >=20 > IKEv2 Transform Type 2 Algorithms >=20 > PRF_HMAC_MD5 MAY -> MAY > PRF_HMAC_SHA1 MUST -> MUST- > PRF_AES128_CBC SHOULD+ -> SHOULD > PRF_HMAC_SHA2_256 MAY -> SHOULD+ >=20 >=20 > IKEv2 Transform Type 3 Algorithms >=20 > AUTH_HMAC_MD5_96 MAY -> MAY > AUTH_HMAC_SHA1_96 MUST -> MUST- > AUTH_AES_XCBC_96 SHOULD+ -> SHOULD > AUTH_HMAC_SHA2_256_128 MAY -> SHOULD+ > --=20 > kivinen@iki.fi Yoav [1] = https://mailarchive.ietf.org/arch/msg/tls/Mul0etdAxsFtpdJeBX2R-enGNN8 From nobody Tue Sep 29 05:24:15 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71C041B31FF for ; Tue, 29 Sep 2015 05:24:04 -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 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 NRbp7-Eoyb5l for ; Tue, 29 Sep 2015 05:24:03 -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 34A441B31FD for ; Tue, 29 Sep 2015 05:24:02 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.1/8.14.8) with ESMTPS id t8TCO0RC025798 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Sep 2015 15:24:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.1/8.14.8/Submit) id t8TCNxh6003913; Tue, 29 Sep 2015 15:23:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22026.33503.702948.197724@fireball.acr.fi> Date: Tue, 29 Sep 2015 15:23:59 +0300 From: Tero Kivinen To: Yoav Nir In-Reply-To: <67BEF329-1905-439B-A172-E10834FF46B5@gmail.com> References: <22025.15464.790587.801082@fireball.acr.fi> <23473.1443455828@sandelman.ca> <341A30F0-786A-48E5-BC03-C79420E4C1B8@gmail.com> <22026.22182.641180.888851@fireball.acr.fi> <67BEF329-1905-439B-A172-E10834FF46B5@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 10 min Archived-At: Cc: ipsec@ietf.org, Michael Richardson Subject: Re: [IPsec] RFC4307 update X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 12:24:04 -0000 Yoav Nir writes: > > So my take would be: > >=20 > > DH group 2 1024-bit MODP =09MUST- -> MAY > > DH group 14 2048-bit MODP=09SHOULD+ -> MUST > >=20 > > Not sure which elliptic curves to propose. The NIST groups 19-21 ha= s > > the problem that there has been two complient ways to implement the= m > > and those two ways are not interoperable, thus they would be bad id= ea > > for mandatory to implement algorithm (i.e. they do not guarantee > > interoperability). >=20 > Is that still an issue=3F I thought this was a bug some years ago tha= t > everyone had fixed, no=3F It was not really a bug. We defined ECP differently than everybody else in the RFC, and then there was errata made that completely changed the format (errata did not change the test vectors or examples). Some implementations implemented what was written in RFC, some implemented what was written in errata. Then when this was noticed, we fixed the RFC by writing a new one, but authors wanted to keep the old group numbers, which caused the problem that now we do not know whether implementation supports this new RFC, or the old RFC without errata. And those two versions do not interoperate. If we would be in perfect world where we would know that everybody uses latest versions of software, which implements latest version of rfcs, then we could ignore this. As there are still lot of people using IKEv1 which was obsoleted long ago, I assume there is still people out there using old version of ECP too. And of course there are people who are against NIST curves just in general...=20 > > Brainpool curves are not that widely implemented, > > and the cfrg is now working on adding another groups. Perhaps we ca= n > > add those new groups as SHOULD+ in the next iteration and leave thi= s > > draft as MODP only for now. >=20 > I don=E2=80=99t have a survey of implementations, but I think 19,20, = and 21 > and more widely implemented than groups 15-18. So if somebody gets > uncomfortable with 2048 bits (see [1]) it=E2=80=99s better to recomme= nd that > people move to an EC curve. I=E2=80=99d rather this be done with some= thing > that=E2=80=99s well established rather than something that is in a -0= 0 draft > submitted this month, but we should find out if interop works right > now. If people are already implementing 19-21 then there is no problem. We do not need to specify them as MUST or SHOULD or SHOULD+, and people can still use them if they feel like it. I think that when CFRG and IPsecME WG get Curve25519 etc work done, we are going to make that one as second mandatory to implement curve, i.e. then making group 19 as SHOULD- or something like that now, would not be that useful. --=20 kivinen@iki.fi From nobody Tue Sep 29 15:48:15 2015 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF8261B552F for ; Tue, 29 Sep 2015 15:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 7dkVM-ecpAj4 for ; Tue, 29 Sep 2015 15:48:13 -0700 (PDT) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD22E1B552E for ; Tue, 29 Sep 2015 15:48:13 -0700 (PDT) Received: from [10.32.60.79] (142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123]) (authenticated bits=0) by hoffman.proper.com (8.15.1/8.14.9) with ESMTPSA id t8TMmC0U087052 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 29 Sep 2015 15:48:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 142-254-17-123.dsl.dynamic.fusionbroadband.com [142.254.17.123] claimed to be [10.32.60.79] From: "Paul Hoffman" To: "IPsecME WG" Date: Tue, 29 Sep 2015 15:48:12 -0700 Message-ID: References: <20150929214646.565.41905.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Subject: [IPsec] Fwd: Last Call: (Cloning IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Sep 2015 22:48:15 -0000 Of possible interest to people here. Responses to this should go to ietf@ietf.org, not to the IPsecME WG mailing list. Forwarded message: > From: The IESG > To: IETF-Announce > Subject: Last Call: (Cloning > IKE SA in the Internet Key Exchange Protocol Version 2 (IKEv2)) to > Proposed Standard > Date: Tue, 29 Sep 2015 14:46:46 -0700 > > > The IESG has received a request from an individual submitter to > consider > the following document: > - 'Cloning IKE SA in the Internet Key Exchange Protocol Version 2 > (IKEv2)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-10-27. Exceptionally, comments may > be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document considers a VPN End User establishing an IPsec SA with > a Security Gateway using the Internet Key Exchange Protocol Version 2 > (IKEv2), where at least one of the peers has multiple interfaces or > where Security Gateway is a cluster with each node having its own IP > address. > > With the current IKEv2 protocol, the outer IP addresses of the IPsec > SA are determined by those used by IKE SA. As a result using > multiple interfaces requires to set up an IKE SA on each interface, > or on each path if both the VPN Client and the Security Gateway have > multiple interfaces. Setting each IKE SA involves authentications > which might require multiple round trips as well as activity from the > VPN End User and thus would delay the VPN establishment. In addition > multiple authentications unnecessarily increase the load on the VPN > client and the authentication infrastructure. > > This document presents the solution that allows to clone IKEv2 SA, > where an additional SA is derived from an existing one. The newly > created IKE SA is set without the IKEv2 authentication exchange. > This IKE SA can later be assigned to another interface or moved to > another cluster mode using MOBIKE protocol. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-clone-ike-sa/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > >