From nobody Sun Apr 2 13:16:41 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA79C1292C5 for ; Sun, 2 Apr 2017 13:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mck-7pocQPBe for ; Sun, 2 Apr 2017 13:16:37 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8DC12751F for ; Sun, 2 Apr 2017 13:16:36 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vx62R4TNNz24C; Sun, 2 Apr 2017 22:16:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491164191; bh=j7b66AUtTZsWVIrQaNpkOA9LoBT/xPQiSRSx7FQynUo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tBI38T1JGvtPLRpXKGcJkccETgifMfvhiqN0VzmTk1grXAs2e8L9H8virLkbFBE4E Bpd3Z6dWdfX4qNAPtk4/p/UyQqmM7s8nVd9ZjnbK7xV8r0B4I2VCRePNJtjvloQPKd ESDn93764ER+N+a4v7SnXxTC8ZJRhN1YVJsde620= 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 fs706zPVcgAJ; Sun, 2 Apr 2017 22:16:30 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 2 Apr 2017 22:16:30 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id A1C9AA69; Sun, 2 Apr 2017 16:16:29 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca A1C9AA69 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8C3DE40D3587; Sun, 2 Apr 2017 16:16:29 -0400 (EDT) Date: Sun, 2 Apr 2017 16:16:29 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: ipsec@ietf.org In-Reply-To: <22748.10958.314148.242611@fireball.acr.fi> Message-ID: References: <22748.10958.314148.242611@fireball.acr.fi> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Apr 2017 20:16:40 -0000 On Thu, 30 Mar 2017, Tero Kivinen wrote: > As discussed in the meeting, we are starting two week working group > adoptation call for the draft-mglt-ipsecme-implicit-iv. No objection to adopting, but also not very excited about it. The document uses the least unpleasant way of accomplishing its goal. In section 8, AES-CTR is listed in the text but not in the listing of new algorithms. I think it should indeed be dropped from the proposal. Section 8 should also just include the IANA table with the three new entries, filling with with [TBD] Maybe a Section clarifying the NIST/FIPS terminology would be useful, as there is a pretty big mixup with IV, ICV, Nonce and Tag :P Paul From nobody Sun Apr 2 22:48:30 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9E512940A for ; Sun, 2 Apr 2017 22:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nN_U-1E44Af for ; Sun, 2 Apr 2017 22:48:26 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 5D535120727 for ; Sun, 2 Apr 2017 22:48:26 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id z15so65922551lfd.1 for ; Sun, 02 Apr 2017 22:48:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=6bZphK200bs341bwZ9LyrlfckzinjJ3AyAN7FMc1lzc=; b=IItHkjw9N7JakkFBChXi9kv0/iF+O6wBF9rqM7HxV/cyzpTsuNCvNCSrTWnFugIrzT R4K2yfHpW7bxegSBxBH4lpSebB8dGmZwEihCcZXDPGqY4Cq0AYYNBiLq2m1M73bHsm6M B32dEdcOCMRMjJQN5lQwwVkBA+k2iUJPa+bUdov6yKeaNj0rcLWtxvXW8dk/lJwCy786 4wmWBBgwnZp+xRAIcJNLfZowdAuNieWweceFX4tLKnaEhcbKXvpY7KnSaPXXiYIxjnbC ira4l0jgUapPwibOiwFdsLLfvQSx8Y0/WZPsmPiZfQ2PJP/nLIoIHTs28vPYJG8UBI2P y6lA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=6bZphK200bs341bwZ9LyrlfckzinjJ3AyAN7FMc1lzc=; b=Uh4svirF2nbrswBoqyjULiiDMGPSTZrA/lhI3LETF2ot1D0Ig5BVbrRJUsXOwocRlg lw8MmMZGkqg3BMgLhGr5IKwKh2RuHipvaA0rWetp3igeySENIrh0E0WgdEWRHEaGbV6k tyJL0PYXauA0bcNn72VtjLNxlCDAq8gNmnl8VTg7gcPR7fS3pJMtk8Ws2DQvm+2yt5Pe ZYUwlmVhm2rgzuShgSKM/rNaa9goNLlDAp9/1+vJQaXohGA2ZVyLz7hQQtKBxeCebNhK UO4+eWr/0g0dWE9qaVKt7J3UVhI+6HOxtqAh5uZntuqdG7mdh/Y/WdCSeQfOGWosR2+H IfMQ== X-Gm-Message-State: AFeK/H3gA9udOtr6zNy4hU/j7BO9PCI69sRBHrS0YkdumT/MFJr85pAf7DlnBdKgIEFdUQ== X-Received: by 10.25.74.146 with SMTP id x140mr4945713lfa.67.1491198504346; Sun, 02 Apr 2017 22:48:24 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id i23sm2359759ljb.63.2017.04.02.22.48.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 02 Apr 2017 22:48:23 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <22748.10958.314148.242611@fireball.acr.fi> In-Reply-To: <22748.10958.314148.242611@fireball.acr.fi> Date: Mon, 3 Apr 2017 08:48:27 +0300 Message-ID: <0eff01d2ac3d$eacafdc0$c060f940$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxES+5W1JbTop1qC0PoZjr56j4AaF2VxDw Content-Language: ru Archived-At: Subject: Re: [IPsec] Starting two week working group adoptation call for draft-mglt-ipsecme-implicit-iv X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 05:48:28 -0000 I think it won't be wrong if the document is adopted. I'm not a big fan of implicit IV, but I agree that it may be useful in some cases. However there are not always obvious pitfalls that may make it insecure. I prefer to have these pitfalls been documented and explained, that's why I support adoption. Regards, Valery. > As discussed in the meeting, we are starting two week working group > adoptation call for the draft-mglt-ipsecme-implicit-iv. > > Please read the draft and send your comments to this list, and also > tell if you support adoptation of this draft as WG draft. > > The document is available at > https://datatracker.ietf.org/doc/draft-mglt-ipsecme-implicit-iv/ > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Apr 3 07:34:46 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCA11293E4 for ; Mon, 3 Apr 2017 07:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJ-wwVN3ktn3 for ; Mon, 3 Apr 2017 07:34:43 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 50CBB128CFF for ; Mon, 3 Apr 2017 07:34:43 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id z15so75506848lfd.1 for ; Mon, 03 Apr 2017 07:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=cBDA1INLYDKdm/cZnPwthRjiYq2xVFlgj+E3wq2hzCQ=; b=lhTO33ijZHMxhoPUXam561Ihz7TUBvdsbJfSC/rjInjdpmXoiR9XLd6ydTRP0jwW/q T9g3MF9Hf8HX08AJAUl5PXOAFswrK7SnJxCUCcu1XUATs8pbIsw88I4E6EvUlWEHWOZi kaN6B2g80mm+AUtf5J7CRTAYLEFiEVitsYby1d+tW8zYzbErzbo9HujLK2NmGJ894gFs UfWsCHlHEEjDgED8ZgO5WTGSW/RK0JxkRW7Cze3j8UugzuYsvmMu0jLBFAODVGHv6NCN y/hyFT0CaidW6Xo1ppTy7YmaGz+0oEj7nLUe3FfeMmny0SJetVEeWS3Ke1F3HFzNgKoR fquQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=cBDA1INLYDKdm/cZnPwthRjiYq2xVFlgj+E3wq2hzCQ=; b=PcmUf2pgXpv6wdMjoSzH4pv05z78E9u9UW34Bmagih8bPV2/hu4IVXfFvqyZgt/2+T zFot4UDS/HZU3/p6rOgc77jr8JBS3gY01l1BwkVNan435Ynz44d5zrDQIcsUoM5fg7R1 j+vXJ0N3u0182+gomcb+NOTxOcD6xH9p+QyOi/Ugxp0SQmqr/KzDNJwOJ9gTYo3KBJ5B 0A3AhBXCVF4mOlyuxckZGkE+XvUthTQKXDCHahY+cHpDSkh6UFSCL34NU5SNCHSNXez4 FKaNEVGZCG5yzD1XMRR47H4On7WpOkOOHYW2Z8DrPJ4nvHKmX4G1nyIrYn+kuahZvSyd sbaA== X-Gm-Message-State: AFeK/H3suyMc+I/29g3RP0ult9u+40ae/ub/gC01Mwwg2PKuVm0mnYLWAtfm4PT2jHcTKw== X-Received: by 10.46.8.90 with SMTP id g26mr5071964ljd.32.1491230081532; Mon, 03 Apr 2017 07:34:41 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id f72sm2609583lfk.2.2017.04.03.07.34.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 03 Apr 2017 07:34:40 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , References: <22748.16157.573889.454241@fireball.acr.fi> In-Reply-To: <22748.16157.573889.454241@fireball.acr.fi> Date: Mon, 3 Apr 2017 17:34:22 +0300 Message-ID: <0f4301d2ac87$6369b480$2a3d1d80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8qCT8+Hw Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 14:34:45 -0000 Hi, > So I have proposed earlier that we should mix the ppk to SK_d, SK_pi, > and SK_pr, i.e., something like this: > > SKEYSEED = prf(Ni | Nr, g^ir) > > {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'} > = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) > > If no PPK available, then > > SK_d = SK_d' > SK_pi = SK_pi' > SK_pr = SK_pr' > > If PPK is available then > > SK_d = prf(PPK, SK_d') > SK_pi = prf(PPK, SK_pi') > SK_pr = prf(PPK, SK_pr') > > This has the follolowing benefits. The SK_d modification will mean > that IKEv2 SA will gain protection against Quantum Resistance after > the IKEv2 SA irs rekeyed, as rekeyed SA will be using SK_d to derive > new keys. SK_d also used to derive the KEYMAT, meaning the Child SA > will gain protection. For this property it is enough to modify calculation of SK_d only. > Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the > IKEv2 authentication will fail, and we will get exactly same failure > for wrong PPK than we do with wrong shared key or digital signature > failures. This means that attacker do not gain any information which > part of the authentication failed. I'm not sure it is a good property. Sure, it gives an attacker no information about which part of authentication (signature or PPK) failed, but it gives local user no such information too. And this is really bad, because in case of authentication failure users will have hard time finding which part to blame and will most probably just switch PPK off. On the other hand, the nice property of modifying SK_pi and SK_pr is that even the initial exchange is authenticated even in case an attacker can break digital signatures on the fly (sure, she can break DH and see what is inside IKE_AUTH, but she cannot change the content unless she breaks PPK too). I think that if SK_pi and SK_pr are modified, then some information should be given to the user to help distinguish PPK errors from signature errors. For example, the Initiator can include something like N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 0) into the IKE_AUTH request, and the responder can include something like N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 1) into the IKE_AUTH response. In this case each side can verify that the other end do own and use the correct PPK before starting computationally expensive public-key operations. In case the PPK is incorrect AUTHENTICATION_FAILED notification can be sent to the peer (as with any other authentication errors), but local user will know which part of the authentication goes wrong. Or probably some new notification (e.g. WRONG_PPK) can be sent instead of (or in addition to) AUTHENTICATION_FAILED, if we want the peer to have better diagnostics. Regards, Valery. > kivinen@iki.fi From nobody Mon Apr 3 09:17:42 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D68120326 for ; Mon, 3 Apr 2017 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 THKQ5z0Zzy7N for ; Mon, 3 Apr 2017 09:17:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE19A12945A for ; Mon, 3 Apr 2017 09:17:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4116; q=dns/txt; s=iport; t=1491236257; x=1492445857; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=FH5if+AlC7Ac+fB94m9rinV+nir27Q3ZaSXRCEuDbUY=; b=NM/nWC5OgHJA98KupKWFSLtu+Yiii4C4M4jpwhW2h+OQA2DlzHHmD6jn 7jFcTlMX4W39eAmvD2Qo/n98woPFka+zMxVQpqAyRCkLUJfrJUYbK7d5u hXKma/v0SVeDtlE4+0iqzXQzO0uUecrvxYEftnirJrbpN5E6Gx9GICAPa 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQA3deJY/40NJK1UCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNUYYELB41tkVWVUoIOHwuFeAKDRj8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQEDAQE4DSUCCA8EAgEIEQQBAR8JBycLFAkIAgQBEgiKBQ6sfoM+hxgBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYZOhG+ELYYMBYkciBiLOQGKJoggkUVIkywBHzi?= =?us-ascii?q?BBVsVQYRUggV1iDiBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.36,271,1486425600"; d="scan'208";a="231879241" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2017 16:17:36 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v33GHadd003256 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Apr 2017 16:17:36 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Apr 2017 12:17:35 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Mon, 3 Apr 2017 12:17:35 -0400 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing Thread-Index: AQHSqOHRXsYj5uYL3E2R1gdN4nkGdaGz0xSw Date: Mon, 3 Apr 2017 16:17:34 +0000 Message-ID: <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> In-Reply-To: <22748.16157.573889.454241@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 16:17:41 -0000 I started editting the draft to incorporate this change, and I ran into a c= onflict with another part of the protocol: incremental rollout. I'd like s= ome quick advice about how to deal with the conflict. Here's the feature it's in conflict with: in order to support 'brown-field'= deployments (that is, an existing IKE infrastructure that people will be d= eploying this to), the current draft specifically allows an IKE implementat= ion to be in a state where it works both with peers that implement this, an= d peers that do not; the idea being that the administrator would first upgr= ade all their nodes to work in this special intermediate mode; and once the= y've done they, they then upgrade their nodes to 'do QR-only' mode. This i= s twice as much work for the administrators; however at no point of time is= any network blockage (as two peers will always be able to negotiate). Currently, whether we're using a PPK is negotiated by the N(PPK_NOTIFY) not= ifies that is sent in the first encrypted message; the responder learns whe= ther or not the initiator supports this draft (and has a PPK) by whether th= e notify is there. However, that same encrypted message includes the AUTH = payload; which is generated using the SK_pi. And, if the initiator isn't s= ure if we're using the PPK, it wouldn't know whether to use SK_pi' or prf(P= PK, SK_pi') Some obvious ways to address this: - Move the notifies to the prior messages (that is, in the clear). If we d= o this, then by the time we derive keys, we know whether we're using a PPK = (even if the responder doesn't know which one it is until it hears the init= iator's id). This would mean that anyone could tell whether the two sides = are using a PPK - Drop this intermediate mode; that is, make it determanistic to whether we= 're uisng the PPK (based on the peer identity). This would make roll-out m= ore challenging, but it would simplify the implementations. - For the initiator's AUTH payload, use SK_pi' always. However, I suspect = this would partially mess up the reason we're strirring it into SK_pi in th= e first place. Opinions? Does any other options come to mind? > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen > Sent: Wednesday, March 29, 2017 7:11 PM > To: ipsec@ietf.org > Subject: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing >=20 > So I have proposed earlier that we should mix the ppk to SK_d, SK_pi, and > SK_pr, i.e., something like this: >=20 > SKEYSEED =3D prf(Ni | Nr, g^ir) >=20 > {SK_d' | SK_ai | SK_ar | SK_ei | SK_er | SK_pi' | SK_pr'} > =3D prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr) >=20 > If no PPK available, then >=20 > SK_d =3D SK_d' > SK_pi =3D SK_pi' > SK_pr =3D SK_pr' >=20 > If PPK is available then >=20 > SK_d =3D prf(PPK, SK_d') > SK_pi =3D prf(PPK, SK_pi') > SK_pr =3D prf(PPK, SK_pr') >=20 > This has the follolowing benefits. The SK_d modification will mean that I= KEv2 > SA will gain protection against Quantum Resistance after the IKEv2 SA irs > rekeyed, as rekeyed SA will be using SK_d to derive new keys. SK_d also > used to derive the KEYMAT, meaning the Child SA will gain protection. >=20 > Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the > IKEv2 authentication will fail, and we will get exactly same failure for = wrong > PPK than we do with wrong shared key or digital signature failures. This > means that attacker do not gain any information which part of the > authentication failed. >=20 > I do so that in the early cases the PPKs are going to be configured manua= lly in > the system and there is quite big propability they being wrong, and catch= ing > the misconfigurations with proper error code is better, than just getting= the > random garbage on the Child SA data. > -- > kivinen@iki.fi >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Apr 3 10:21:38 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BE8129495 for ; Mon, 3 Apr 2017 10:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxnbfwdoGUOY for ; Mon, 3 Apr 2017 10:21:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77A4112709D for ; Mon, 3 Apr 2017 10:21:34 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vxf630NNHz1rV; Mon, 3 Apr 2017 19:21:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491240091; bh=lsXrbB2XLTQQ36vYiR8neeX7mx7Og6F40XXd4jaPVVo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=HyKD6WCXhhFkzP8JLQq1rwPFoNskjFhelPqtKo7PQcqFvEYuHiLjH/ACufGLqG0TO jWN9wcExMpdBZr4Gun7AYGv+7M3fCoiEjZnIRMiA6ccx9r5GVl0fugYtYlP0cT26s3 SiHmI40kOyyhuk2R+egwctIiMxceKj/H7wIgdank= 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 LB1GLaeDUjoo; Mon, 3 Apr 2017 19:21:28 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 3 Apr 2017 19:21:28 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 43D443943A4; Mon, 3 Apr 2017 13:21:27 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 43D443943A4 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2988840D80FD; Mon, 3 Apr 2017 13:21:27 -0400 (EDT) Date: Mon, 3 Apr 2017 13:21:26 -0400 (EDT) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" cc: Tero Kivinen , "ipsec@ietf.org" In-Reply-To: <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> Message-ID: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 17:21:37 -0000 On Mon, 3 Apr 2017, Scott Fluhrer (sfluhrer) wrote: > Some obvious ways to address this: > > - Move the notifies to the prior messages (that is, in the clear). If we do this, then by the time we derive keys, we know whether we're using a PPK (even if the responder doesn't know which one it is until it hears the initiator's id). This would mean that anyone could tell whether the two sides are using a PPK I dont like this idea very much, unless it is using ephemral IDs. I did think we wanted to add that as an option but perhaps not in this draft? > - Drop this intermediate mode; that is, make it determanistic to whether we're uisng the PPK (based on the peer identity). This would make roll-out more challenging, but it would simplify the implementations. I would think this is the obvious solution. I would not want to run a connection definition that you can connect to "with or without PPK" and run the risk of downgrade attack until the very last host has upgraded to support PPK. Paul From nobody Mon Apr 3 11:26:01 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA29F1294E2 for ; Mon, 3 Apr 2017 11:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x2gEK8GFTOb for ; Mon, 3 Apr 2017 11:25:49 -0700 (PDT) Received: from mail-in22.apple.com (mail-out22.apple.com [17.171.2.32]) (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 7E8231294C4 for ; Mon, 3 Apr 2017 11:25:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491243946; 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=aqB1DCFhR3C3sucGwjg1EXvYbnwslYGpH6xuejQHf7Y=; b=yqDlcVWtLW8hOEVIvFOeT0IbI2aFSt6HOtlzoXUhrkyyoahUzfvPULdC6jYNB4as V4i9trYRgL0okUF2HZhMqF4fpSecnNPgUqyYy+CAu4/oP5yMLoJ7xeh72UoZutBS N/hjgPdRAfoJ7eJnAHRU7x8rPlCKX+2XfrSnw5PFCi3EG0Dk/20isrV/abUmIAWj jc7cMGMhXlRXCRdlaUBC/ArPGVlzsfZPuaqdurxMi1MRu5coA0SJmJAZxfIEOdD8 E0Iy5wL66CfX5qFe1excRCt9mJ9CaDUe30xroCVMeSUSGHbLD2ebte02WutOmp2D 2r3e8TNS+loaIV/z8BcDMg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in22.apple.com (Apple Secure Mail Relay) with SMTP id 17.7E.23264.9A392E85; Mon, 3 Apr 2017 11:25:46 -0700 (PDT) X-AuditID: 11ab0216-e218d9a000005ae0-97-58e293a97095 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) by relay6.apple.com (Apple SCV relay) with SMTP id 87.77.31597.8A392E85; Mon, 3 Apr 2017 11:25:45 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from [17.153.71.197] (unknown [17.153.71.197]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONU004LLJ6WJI50@nwk-phonehomebzp-sz01.apple.com>; Mon, 03 Apr 2017 11:25:44 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> Date: Mon, 03 Apr 2017 11:25:44 -0700 Cc: Jim Schaad , Daniel Migault , "spasm@ietf.org" , IPsecME WG , "saag@ietf.org" , "tls@ietf.org" Message-id: References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> To: "curdle@ietf.org" X-Mailer: Apple Mail (2.3251) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUi2FAYpbtq8qMIg6eLOS22LpzFbDFl+h42 i9XTv7NZ7N/ygs1iSn8nk8W8a8kWn853MTqwe2ycM53N49fXq2weS5b8ZApgjuKySUnNySxL LdK3S+DKWHdpGXPBNKmKA4s+MTcwzhDtYuTkkBAwkdg4ez4jiC0ksI9R4vD+EJj4ko+/2LoY uYDixxglXmzbzgyS4BUQlPgx+R5LFyMHB7OAvMTB87IgYWYBLYnvj1pZIOoXMklsPnKNFSQh LCAt0XXhLpQdIHHxyH1mkF42oIYDa4xAwpwCfhKPLr8GK2ERUJWYvOczE8gcZoHbjBLzpq1h hdhrI/F/2SxmiEOBDjp7rATEFhFQlzhxaAcrxNGyEp+e/2QHaZYQuM4m8Wj+TrYJjMKzkNw9 C+HuWUjuXsDIvIpRODcxM0c3M8/ISC+xoCAnVS85P3cTIygqVjOJ7WC899rwEKMAB6MSD69H 96MIIdbEsuLK3EOM0hwsSuK8InfvRQgJpCeWpGanphakFsUXleakFh9iZOLglGpgVI85Zvnm Qf3Fro21ufJsll3bDSWvSr3eePS/9b8FBTsPG7/uuukyfZbULd7p11Kf6VTPj524XUWf98zB UNHEF3xpC4KTmu5uyLxfcILvsWLLVodHBxiF/9wL6pO6F/h376ceJg8RLuZL2lXec/dddWOy tDrzU31C6bar8j92vHgwsauSv255oxJLcUaioRZzUXEiAHCmXpZrAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUiON3OQXfl5EcRBo/28lpsXTiL2WLK9D1s Fqunf2ez2L/lBZvFlP5OJot515ItPp3vYnRg99g4Zzqbx6+vV9k8liz5yRTAHMVlk5Kak1mW WqRvl8CVse7SMuaCaVIVBxZ9Ym5gnCHaxcjJISFgIrHk4y+2LkYuDiGBY4wSL7ZtZwZJ8AoI SvyYfI+li5GDg1lAXuLgeVmQMLOAlsT3R60sEPULmSQ2H7nGCpIQFpCW6LpwF8oOkLh45D4z SC8bUMOBNUYgYU4BP4lHl1+DlbAIqEpM3vOZCWQOs8BtRol509awQuy1kfi/bBbYDWAHnT1W AmKLCKhLnDi0gxXiaFmJT89/sk9gFJiF5NRZCKfOQnLqAkbmVYwCRak5iZVmeokFBTmpesn5 uZsYQUHcUBi1g7FhudUhRgEORiUe3gVOjyKEWBPLiitzDzFKcDArifBemQgU4k1JrKxKLcqP LyrNSS0+xFgF9MBEZinR5HxghOWVxBuamBiYGBubGRubm5hTRVhJnDen/F6EkEB6Yklqdmpq QWoRzHImDk6pBkbZIIlSxetqol5XrE8XeD/4xmT/LPTutbxJf5alF9/Ml/V4+0f2xt412/6l L+ZecLv6VjBb+M49uV1buaZLzo3fkrpj6cbuP5Pvzmlwl3AQ3d9hp6Mfc9p37UwLbim1iyXy pf2S3C7HjCeEMOgaqVxI8jmjw297as+hwvXvel/fCL1nGMpTJ6vEUpyRaKjFXFScCADgdmvP vQIAAA== Archived-At: Subject: Re: [IPsec] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 18:25:51 -0000 Thanks for the update! I've reviewed -04 and I think the draft is ready to move forward. Regards, David Schinazi > On Mar 28, 2017, at 15:43, Daniel Migault wrote: > > Hi, > > Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday. Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. > > Yours, > Daniel > > -----Original Message----- > From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad > Sent: Tuesday, March 28, 2017 4:40 PM > To: curdle@ietf.org > Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt > > Here is the promised updated draft. > > Changes: > 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign bit in public key.) 2. Remove all of the pre-hash text except to note that it does exist. > 3. No changes to the OID arc being used despite the agreement during the meeting. After the meeting, Russ, the chairs and I had a short talk and decided that this did not need to occur. The problem was only with getting new values assigned not with the current values which were already assigned. > > That should be the final issues in the draft > > Jim > > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Tuesday, March 28, 2017 4:31 PM >> To: Jim Schaad ; Simon Josefsson >> >> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >> >> >> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been >> successfully submitted by Jim Schaad and posted to the IETF repository. >> >> Name: draft-ietf-curdle-pkix >> Revision: 04 >> Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for >> use in the Internet X.509 Public Key Infrastructure >> Document date: 2017-03-28 >> Group: curdle >> Pages: 15 >> URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt >> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ >> Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 >> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 >> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04 >> >> Abstract: >> This document specifies algorithm identifiers and ASN.1 encoding >> formats for Elliptic Curve constructs using the Curve25519 and >> Curve448 curves. The signature algorithms covered are Ed25519 and >> Ed448. The key agreement algorithm covered are X25519 and X448. The >> encoding for Public Key, Private Key and EdDSA digital signature >> structures is provided. >> >> >> >> >> 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 > > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle From nobody Mon Apr 3 13:32:26 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B628129443 for ; Mon, 3 Apr 2017 13:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 r7BJpiPHZlY6 for ; Mon, 3 Apr 2017 13:32:23 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7548412942F for ; Mon, 3 Apr 2017 13:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7074; q=dns/txt; s=iport; t=1491251543; x=1492461143; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vKiRcf0NSAyG61wpw+NytIG8jtPyQv24vdeg49BTZX0=; b=aF6i6jR5pRM6Bo4CQjO8HkuyhsmEpYEzxbXm26AyiS3Brb4MSXnm99BV Bw5Z7kZoQH/Xnmvgv1XifhrHsMbkWGE0+znoR4Jn3HioXvHN3SCC1jyMN U2Kk7ym4LPCr/xJvQk/LsgHFF4C5taMeBsFlmnjBOTdFEHC+DoM2iOpcJ c=; X-Files: smime.p7s : 4557 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D2BQAKseJY/4cNJK1dGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1SBbAeDW5tJlXGCDoYiAoNFQBcBAgEBAQEBAQFrKIUWBiNWEAIBCEI?= =?us-ascii?q?CAgIwJQIEAQ0FDg2JcqwIgiaKWgEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4Phk6CB?= =?us-ascii?q?QiCYoRHJIJvLoIxAQScbQGDe4IMjEgKgVuPV0iTLAEgATaBBVsVUgGGR3WGWYE?= =?us-ascii?q?ugQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,271,1486425600"; d="p7s'?scan'208";a="407043380" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Apr 2017 20:32:22 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v33KWMKb002294 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 3 Apr 2017 20:32:22 GMT Received: from xch-aln-007.cisco.com (173.36.7.17) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 3 Apr 2017 15:32:21 -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.1210.000; Mon, 3 Apr 2017 15:32:21 -0500 From: "Graham Bartlett (grbartle)" To: Paul Wouters , "Scott Fluhrer (sfluhrer)" CC: "ipsec@ietf.org" , Tero Kivinen Thread-Topic: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing Thread-Index: AQHSqOHRO9QvUY8azUawI4EVzWpGDKG0LagAgAAR2ACAAEYZgA== Date: Mon, 3 Apr 2017 20:32:21 +0000 Message-ID: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.64.83] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3574099939_1639150826" MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 20:32:25 -0000 --B_3574099939_1639150826 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Hi Paul Would a downgrade attack be possible if the PPK notify is included in the authentication material ? cheers On 03/04/2017, 18:21, "IPsec on behalf of Paul Wouters" wrote: I would think this is the obvious solution. I would not want to run a connection definition that you can connect to "with or without PPK" and run the risk of downgrade attack until the very last host has upgraded to support PPK. Paul --B_3574099939_1639150826 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIRyQYJKoZIhvcNAQcCoIIRujCCEbYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGggg9+MIIFbTCCBFWgAwIBAgIQDZu2aTrsxkrY+ilxZLyNgTANBgkqhkiG9w0BAQsFADBl MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGln aWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTYw NTE2MDAwMDAwWhcNMTgwNTE2MTIwMDAwWjCBkDELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNh bGlmb3JuaWExETAPBgNVBAcTCFNhbiBKb3NlMRwwGgYDVQQKExNDaXNjbyBTeXN0ZW1zLCBJ bmMuMRgwFgYDVQQDEw9HcmFoYW0gQmFydGxldHQxITAfBgkqhkiG9w0BCQEWEmdyYmFydGxl QGNpc2NvLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMqOS+hfMCqvKj+e gZdgQIEPbPvc6Mv9fJvK/hNbeOiOwBepKx73eSUh+gABrR8i7ui5/V7XlyMPg/OgQr/6UZX2 QGaqBNkiVkOqNDjwjDz6+voKVS2MNU0cCvxP5Xwb9VXgw2JzFAMMshknhP7G+9V6qxda7e5m fmBzYgCgewiITHD83tGiS/YuoOogmPfYnpQyCcnSdwj8MqnlvVfBQVdAOg+a7hv8zPcTA4mH H0Y3dqCIdNtj1QEm9D9YbDlCS1MZl/7byqLpEZA+la8Pva/r/lydbVuM7BXygqI+itXM9963 8kZim8zTh4r/wCi8uklBSeMRUHSmgocw5BpnIk8CAwEAAaOCAeswggHnMB8GA1UdIwQYMBaA FOcCI4AAT9jXvJQL2T90OUkyPIp5MB0GA1UdDgQWBBQmnj6AyXbjUyNRGN6Y2JOK17/CkzAM BgNVHRMBAf8EAjAAMB0GA1UdEQQWMBSBEmdyYmFydGxlQGNpc2NvLmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZI AYb9bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGI BgNVHR8EgYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hB MkFzc3VyZWRJRENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUH MAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2Vy dHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0B AQsFAAOCAQEAna7Ws4vfNhrcm0Od6wb6xiOBURSSXAgX7LE8chrD7UfTF+b7DKits6QY1Vvo 5s0ryCy2T4ikMMKzpAnQ9O0vvF5wbb2iF9zTyKv2M36uY6L6EbMC7QoQAihAiOGnLy4wwhsB qtoGHPL8f1ROW2xpK3twQm2jthhv7fzHRPnFFh4bwWLLISHsw7JKzaL1GuxghNr9W9CN7o2r OtnnvoSwdkPBlMmquWrUgCZ06UQfsD6nbVDvqlBlJGBsrfXk3y8yg3q+rN6LTqHccW4Rk1KS OkE8i/8NKTo8QXHSOa+jcK0o7mnjGXERklDnFGMiNVLbVhVa9CJynUpLjNct3q6+ATCCBk4w ggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcNAQELBQAwZTELMAkGA1UEBhMC VVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEk MCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEzMTEwNTEyMDAwMFoX DTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZ MBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1 cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/AJ3kb LQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAf JUXo8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ 9ZEXjsYhrTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1x GOSm4IksG/OyczzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgw BgEB/wIBADAOBgNVHQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5kaWdpY2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0 LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6 Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1s AAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQG CCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABpAHMAIABDAGUA cgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABhAGMAYwBlAHAA dABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABDAFAALwBDAFAA UwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5ACAAQQBnAHIA ZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBiAGkAbABpAHQA eQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAgAGgAZQByAGUA aQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP2Ne8lAvZ P3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcNAQEL BQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mg VgxIEM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0 k4f5lpaBVUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEy br1DDE0023vGQtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIwggO3MIIC n6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlVT MRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0z MTExMTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAX BgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQg Um9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5 cRKlrtwmlIiq9M71IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+Y MjZ2zN7dPKii72r7IfJSYd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nY Lxj+KA+zp4PWw25EwGE1lhb+WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGY M2wi6YfQMlqiuhOCEe05F52ZOnKh5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSS plazvbKX7aqn8LfFqD+VFtD/oZbrCF8Yd08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8G A1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXroq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQY MBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqGSIb3DQEBBQUAA4IBAQCiDrzf4u3w43Jz emSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwSTFjk0z2DSUVYlzVpGqhH6lbGeasS 2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJs13rsgkq6ybteL59PyvztyY1 bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLxvlBnt2y98/Efaww2BxZ/ N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76jRslbWyPpbdhAbHS oyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMYICDzCCAgsCAQEweTBlMQswCQYDVQQG EwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29t MSQwIgYDVQQDExtEaWdpQ2VydCBTSEEyIEFzc3VyZWQgSUQgQ0ECEA2btmk67MZK2PopcWS8 jYEwDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgzMWkTp5ghdK81qTnf5ktFrEd aCi9utaXO08jkqZQlNwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTcwNDAzMjAzMjE5WjANBgkqhkiG9w0BAQEFAASCAQCkVbjpyCImiTi1H1FxLaNWo7Fl E5Ck9i16sgGIwrYUhE3sLNEreaBs32w/kY+p6as4FOOuomlW3DkZoLBNhbkYK6xGoDSmqnxJ 0HVUROBitGv+ocWEfehSejh2GJBolAlxXmJqB6Ixe8YFxMoeTfw9zjrohyEGC1U9lc7wmA3Q bhmeHY2Y9ISHYu6iTlUMN+YLNNuio/hMKJnFL32D9uc1P/qAqdFQBmQ7GOoHt27wnZ+Ohjer yAwH1sUDGojuEFOomlSLSj0+CbJGBpo0VyLg6okBKAFqtcu0v+WGHGL087eTD3bdaMxS/YUU 3+IMh8R8qxxi7S6h2tyqdFPZklm5 --B_3574099939_1639150826-- From nobody Tue Apr 4 05:06:43 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77401129664 for ; Tue, 4 Apr 2017 05:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOUkhti5QrvV for ; Tue, 4 Apr 2017 05:06:40 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 0B02C12773A for ; Tue, 4 Apr 2017 05:06:38 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id h125so91206261lfe.0 for ; Tue, 04 Apr 2017 05:06:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=9T18qq4f5NtRzb4Q7VojTFJccZ7Vo0Kduzt9s/vCEdM=; b=E3I7j3ylGOXCN9JVe8lR2P14jxfcx2WHFeenO5mtvlp/Tdv4Ej2+2stJtI7+8Uw5F5 eoentWvnUyh6bUjIOg3SzKGFmYLfGgiIkHnmDYYA37+P0DuyGKXd3WVHtLXD/JXSNue4 mi5mcKrpxsoNiHGBiwP75A24m6Z6yBdBgwN32qWyTa06glGgwv6iXA4rtuSteibaM7Zx wlyT0oYJdyanNCut5KXya8F5SsgVAHeKU5zBz35hKLG3Zk1zzuZmZxsczV8YR4jgNBXS yO2Ld96iMqzTwKDPlz4DDZ0OETo4Dxi4rotMGJUJIi2ubBIlqL1jLr1UXorO9MegWuHA gdmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=9T18qq4f5NtRzb4Q7VojTFJccZ7Vo0Kduzt9s/vCEdM=; b=pV5+MRXMz6ULJlQMHe/hiDM1j8IOr5pJLE11CpXYJxj19E9uAyNIq/xUvIGXTBzBA+ yNislDbiyR5+5kG/h4iO0QWNf9CaU0k82dXDypwT/s2GaTJEXcvt7zmtkuLmsFwUS1Ql FOqkVgeIaUwKbdcdC0fyTru+pdHLqZCjv9XtlqVqCJMlbHYDtT0BtaYkDGDmBdB+hACg br0GwOEVnqw4BKyU9oNiSiKbM24BGLvtrI50tqWS6Dyqzhrpt7+vVtsBzB+Vk4+a6scH eLgLL/tnz4Uw+GUuAGusJzD06CS11cnfKE6yFfX+kU9JyuqLhd1azI4JdhSv1uNygHDF zUXw== X-Gm-Message-State: AFeK/H172VVvSZK0X54O85YULItsHxfz4ms/afCGZLvO6O7AyLgKc00IYX/fglnmgwM2Jw== X-Received: by 10.46.84.68 with SMTP id y4mr6515940ljd.129.1491307596029; Tue, 04 Apr 2017 05:06:36 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id z26sm3040086lja.28.2017.04.04.05.06.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 05:06:35 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'Tero Kivinen'" , References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> In-Reply-To: <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> Date: Tue, 4 Apr 2017 15:06:17 +0300 Message-ID: <100f01d2ad3b$ddf8ee00$99eaca00$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8gHZiixpoIbmfIA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:06:42 -0000 Hi Scott, > I started editting the draft to incorporate this change, and I ran into a conflict with another part of the > protocol: incremental rollout. I'd like some quick advice about how to deal with the conflict. > > Here's the feature it's in conflict with: in order to support 'brown-field' deployments (that is, an existing IKE > infrastructure that people will be deploying this to), the current draft specifically allows an IKE > implementation to be in a state where it works both with peers that implement this, and peers that do not; > the idea being that the administrator would first upgrade all their nodes to work in this special > intermediate mode; and once they've done they, they then upgrade their nodes to 'do QR-only' mode. > This is twice as much work for the administrators; however at no point of time is any network blockage (as > two peers will always be able to negotiate). > > Currently, whether we're using a PPK is negotiated by the N(PPK_NOTIFY) notifies that is sent in the first > encrypted message; the responder learns whether or not the initiator supports this draft (and has a PPK) > by whether the notify is there. However, that same encrypted message includes the AUTH payload; which > is generated using the SK_pi. And, if the initiator isn't sure if we're using the PPK, it wouldn't know > whether to use SK_pi' or prf(PPK, SK_pi') > > Some obvious ways to address this: > > - Move the notifies to the prior messages (that is, in the clear). If we do this, then by the time we derive > keys, we know whether we're using a PPK (even if the responder doesn't know which one it is until it hears > the initiator's id). This would mean that anyone could tell whether the two sides are using a PPK I prefer this way. In more detail: IKE_SA_INIT: Initiator: SA, KE, Ni, [N(PPK_SUPPORTED),] [V+][N+] --> PPK_SUPPORTED notification indicated that the Initiator supports PPK and is willing to use it. This notification contains no data. Responder: <-- SA, KE, Nr, [CERTREQ+,] [N(PPK_SUPPORTED),] [V+][N+] If the Responder supports PPK it will return PPK_SUPPORTED back in the IKE_SA_INIT reply. Otherwise the Responder ignores this notification and PPK is not used in the following exchange. Assuming both sides support PPK: IKE_SA_AUTH: Initiator: HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TS, TSr, N(USE_PPK)} ---> USE_PPK notification helps the Responder to select the right PPK and to ensure that the Initiator really possess the correct PPK value. Its data is computed as prf(SK_pi, Ni | Nr), where SK_pi is as in Tero's proposal (SK_pi = prf(PPK, SK_pi')). Having this notification included will solve two issues: - first, the Responder can verify that the Initiator does have the correct PPK (i.e. PPK misconfiguration errors become clear and can be distinguished from certificates configuration errors). Moreover, the Responder can verify that PPK is correct before starting computational expensive signature verification. - if PPK selection is ambiguous, this notification can help select the right PPK. This can happen in situation of PPK rollover, when old PPK is being changed with a new one, and since this cannot happen overnight, there may be some period of time when peer's account is associated with two PPKs (security officer first adds a new PPK to the server, then replaces an old PPK with the new one on the client and finally removes an old PPK from the server). Responder: <--- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr, N(USE_PPK)} USE_PPK notification data is computed as prf(SK_pr, Ni | Nr), where SK_pr is as in Tero's proposal (SK_pr = prf(PPK, SK_pr')). AUTH payload is computed as in Tero's proposal. If a host detects that it has no PPK that matches the peer's USE_PPK data, it can return either AUTHENTICATION_FAILED (this will leak no information to a passive observer of which part of authentication failed) or a new error notification WRONG_PPK (this would allow the peer to make some conscious actions to resolve the situation), or both. > - Drop this intermediate mode; that is, make it determanistic to whether we're uisng the PPK (based on the > peer identity). This would make roll-out more challenging, but it would simplify the implementations. This will make incremental introducing of PPK next to impossible. > - For the initiator's AUTH payload, use SK_pi' always. However, I suspect this would partially mess up the > reason we're strirring it into SK_pi in the first place. Agree that it would mess up the initial reason. Regards, Valery. From nobody Tue Apr 4 05:23:23 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F695129664 for ; Tue, 4 Apr 2017 05:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id foFJ5T77VSkB for ; Tue, 4 Apr 2017 05:23:20 -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 E5D5C12946A for ; Tue, 4 Apr 2017 05:23:19 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v34CNGI6003751 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Apr 2017 15:23:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v34CNGoT017936; Tue, 4 Apr 2017 15:23:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22755.36916.406796.456087@fireball.acr.fi> Date: Tue, 4 Apr 2017 15:23:16 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: In-Reply-To: <0f4301d2ac87$6369b480$2a3d1d80$@gmail.com> References: <22748.16157.573889.454241@fireball.acr.fi> <0f4301d2ac87$6369b480$2a3d1d80$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:23:22 -0000 Valery Smyslov writes: > > Modifying the SK_pi, and SK_pr will mean that if the PPK is wrong the > > IKEv2 authentication will fail, and we will get exactly same failure > > for wrong PPK than we do with wrong shared key or digital signature > > failures. This means that attacker do not gain any information which > > part of the authentication failed. > > I'm not sure it is a good property. Sure, it gives an attacker no > information about which part of authentication (signature or PPK) > failed, but it gives local user no such information too. And > this is really bad, because in case of authentication failure users > will have hard time finding which part to blame and will > most probably just switch PPK off. And if that helps, they do know that the problem was in the PPK. Also depending on the authentication algorithm there is more cases that result authentication failure and which are known to local user (i.e., expired or revoked certificates, unknown trust anchor, EAP authentication failure etc). With certificates or with EAP you should not really get failures in the AUTH calculation unless there is bug in your code, or there is attacker on the line modifying the bits. Only case where you get authentication failure which just results invalid AUTH is when you are using shared key authentication and then you do not know whether it is the shared secret or PPK which is wrong (or whether there is bug in implementation or attacker modifying the bits). Turning PPK off and retrying and see if that helps will tell you whether it is the PPK or the shared secret which is wrong, and that is quite easy way to debug issues. > On the other hand, the nice property of modifying SK_pi and SK_pr is > that even the initial exchange is authenticated even in case an > attacker can break digital signatures on the fly (sure, she can > break DH and see what is inside IKE_AUTH, but she cannot change the > content unless she breaks PPK too). Yep. > I think that if SK_pi and SK_pr are modified, then some information > should be given to the user to help distinguish PPK errors from > signature errors. For example, the Initiator can include something like > > N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 0) > > into the IKE_AUTH request, and the responder can include something like > > N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 1) > > into the IKE_AUTH response. In this case each side can verify > that the other end do own and use the correct PPK before starting > computationally expensive public-key operations. That does not help. We need to Diffie-Hellman before we can see the IKE_AUTH contents, so when we are doing that verification we have already done the expensive operations. On the other hand as this issue is not really with certificates, we are not doing actual public key operation when calculating the AUTH payload, we are simply ding the prf with shared secret. With certificates the public key used is already sent in the certificate payload inside the exchange, so it is known, and if there is problems verifying it, we know it before we end up in the AUTH calculation, and we return AUTHENTICATION_FAILED without ever calculating the AUTH payload. > In case the PPK is incorrect AUTHENTICATION_FAILED > notification can be sent to the peer (as with any other authentication > errors), but local user will know which part of the authentication goes wrong. > Or probably some new notification (e.g. WRONG_PPK) can be sent > instead of (or in addition to) AUTHENTICATION_FAILED, if we want > the peer to have better diagnostics. I do not think that is needed, and I definately do not want to tell attackers whether it was the PPK or something else that caused AUTHENTICATION_FAILED notification. It would be fine to tell that in the logs, but not on the wire. Even in the logs I do not think it is that important, as there as easy ways to debug this. -- kivinen@iki.fi From nobody Tue Apr 4 05:54:56 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E931272E1 for ; Tue, 4 Apr 2017 05:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5tXkFHW5Raz1 for ; Tue, 4 Apr 2017 05:54:54 -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 CB8FE1294A3 for ; Tue, 4 Apr 2017 05:54:50 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v34Cse8X029993 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Apr 2017 15:54:40 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v34CseSW012522; Tue, 4 Apr 2017 15:54:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22755.38800.522208.481154@fireball.acr.fi> Date: Tue, 4 Apr 2017 15:54:40 +0300 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" Cc: "ipsec\@ietf.org" In-Reply-To: <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 27 min X-Total-Time: 28 min Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 12:54:55 -0000 [Not wearing any hats] Scott Fluhrer (sfluhrer) writes: > - Move the notifies to the prior messages (that is, in the clear). > If we do this, then by the time we derive keys, we know whether > we're using a PPK (even if the responder doesn't know which one it > is until it hears the initiator's id). This would mean that anyone > could tell whether the two sides are using a PPK Currently PPK_NOTIFY is empty notification so moving that to the the IKE_SA_INIT and changing its name to PPK_SUPPORTED is fine. Sending the actual PPK identity is better done on the IKE_AUTH where it is protected by the Diffie-Hellman, meaning attacker needs to do active attack to learn it. So I think protocol should be something like Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni, N(PPK_SUPPORTED) --> <-- HDR, SAr1, KEr, Nr, N(PPK_SUPPORTED), [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, N(PPK_IDENTITY, ), TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr} Where the N(PPK_SUPPORTED) just tells that both ends support PPK, and they have at least one PPK installed. This means that incremental installation needs to be done so that all possible PPKs are always installed for each identity to the machine once, i.e., it either knows PPKs for all IDs and sends N(PPK_SUPPORTED) or it does not send N(PPK_SUPPORTED) at all. I.e., you cannot install just PPKs for half of the users and enable N(PPK_SUPPORTED). PPK will be enabled only and only if both ends send N(PPK_SUPPORTED) during the IKE_SA_INIT. Then during the IKE_AUTH the initiator picks PPK to use and sends the associated with the PPK in the N(PPK_IDENTITY, ...) notify and uses the PPK to generate the AUTH. If it only has one PPK meaning the does not have any meaning it will send it as empty. If it does not send PPK_IDENTITY at all, that means it is not using PPK even when it was enabled (this can be used for example to test whether the authentication problem is in the shared secret being wrong or in the case where the PPK is wrong). If N(PPK_IDENTITY, ) was sent by the initiator then responder will find the matching for the user specified in the IDi and will use that when calculating AUTH. The ppk_id is opaque binary string and will be be interpreted at all by the IKE, but the PPK management module might provide internal format for it. For example if the PPKs are taken from the 1GB one-time-pad file shared by the peers (one file per user), then the ppk_id could simply be 32-bit offset to the file, and the external PPK management module would keep track which of the offsets are used and which are not. If the ppk_id is not known by the responder, then it will return N(AUTHENTICATION_FAILED) error and log the error to the local log file. If EAP is used, then exchange is bit different: Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni, N(PPK_SUPPORTED) --> <-- HDR, SAr1, KEr, Nr, N(PPK_SUPPORTED), [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, N(PPK_IDENTITY, ), TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP} HDR, SK {EAP} --> <-- HDR, SK {EAP (success)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} I.e., the PPK_IDENTITY is still sent inside the first IKE_AUTH, but of course in this case the actual PPK is not used by the initiator yet. The responder will then reply with AUTH payload using the PPK, and the final exchange uses the PPK again in both ends. With EAP only authentication (RFC5998) the exchange is about same, except now we do not have "[CERT,] AUTH" in the responders first IKE_AUTH message, and the PPK is only used in the final IKE_AUTH exchange when calculating AUTH payloads. The NULL authentication (RFC7619) is logically incompatible with this (it being opportunistic and this requiring configuration), so I think we can say this will not be used with it. Or we can just say that can be used, and SK_pi are used as specified here and in the RFC7619... > - For the initiator's AUTH payload, use SK_pi' always. However, I > suspect this would partially mess up the reason we're strirring it > into SK_pi in the first place. That would be one option too. I.e., only modify SK_pr. I think it actually would be enough, as we do trust the other end to do correct things, and this would be enough to know whether peers share the same PPK. On the other hand we will end up annoying case where the initiator will know that PPK is wrong after the IKE_SA has already been properly installed on the responder, thus initiator needs to signal this with separate INFORMATIONAL exchange to the responder, and thne delete IKE SA. I think the option I explained above is better. -- kivinen@iki.fi From nobody Tue Apr 4 06:03:28 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A74126BF7 for ; Tue, 4 Apr 2017 06:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIooHYIWwwcE for ; Tue, 4 Apr 2017 06:03:25 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 F0F86128959 for ; Tue, 4 Apr 2017 06:03:21 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id z15so92571565lfd.1 for ; Tue, 04 Apr 2017 06:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=4FkpN2UGzcGRyDAV8fRU7LmJcoNx2utT7xSco22AvzU=; b=pUZXb7fk2jYQb9MZCNtO0WU9br9+yZC38RL9eov4sddanssrgSlwDbPqkepTKQ2ts2 eeBfAAphRBcgdgxdmW8wMQ2gWMC1vmjWjaSFBMdT/rPpRBxs7IFEIF4IspFW/uVLYbIw DZON4zsZepptVHFcTv39MGDL7mVENGF0cZAn3lCa7OZQNr8UEDnVIJsoNz7asbHvKZPA ppwoiGYiA8e1WFXsRBkNnZLETKTeaf3l3uWFjiY1y1ApGpQZ0r4dTDtcmTmk/Xk8hkO6 ucPTlyI4PHDZGPGVOlhvsOi9X/BIsVXPwNccZe3nNAZc6r6mJgIt/qc6b+63sdJo4uyw crgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=4FkpN2UGzcGRyDAV8fRU7LmJcoNx2utT7xSco22AvzU=; b=MSdM1BOCMFDvVw2fMYx2StytMsTq1jZy+ky1wqWLYvJ3t8haSW7C7SXXQlRCoCLo69 rnDasnD9c28Zjwxc6DPT2Sa3O2LgOqJBegx25T/sQiKiZH8wR1qmlsNfVVEc6gvKi2WU gCGSm1uZaTuIHIhvsYLihsI7wF+5sbLR1hwmAVGpvhmanCTz8iG4Pcr2LgWzOsFlX5G5 0KtWsnLLHhAscpMxkiNZQeie98l73YyIMKQ/5k7IhlvEAZM51s6//1j27fwYPrGyt260 j4qkHw67hawBLC3WYjqLegvivUNTFo/4LivJfWqpVQGR+4QkDPcX7NFBEw1PzvI4DOWH yJ3Q== X-Gm-Message-State: AFeK/H0/o03wHsHsl3ONbntINT/+zSGd+MxIpPTKc4TraA0IZmbOjgZBwKZOK9TizjHvAQ== X-Received: by 10.25.219.18 with SMTP id s18mr6667653lfg.174.1491311000103; Tue, 04 Apr 2017 06:03:20 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 193sm3014507ljj.4.2017.04.04.06.03.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 04 Apr 2017 06:03:19 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: References: <22748.16157.573889.454241@fireball.acr.fi> <0f4301d2ac87$6369b480$2a3d1d80$@gmail.com> <22755.36916.406796.456087@fireball.acr.fi> In-Reply-To: <22755.36916.406796.456087@fireball.acr.fi> Date: Tue, 4 Apr 2017 16:03:02 +0300 Message-ID: <102001d2ad43$cb065690$611303b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8gI38jSgAkBZQnigcjqBUA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 13:03:27 -0000 Hi Tero, > > I think that if SK_pi and SK_pr are modified, then some information > > should be given to the user to help distinguish PPK errors from > > signature errors. For example, the Initiator can include something like > > > > N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 0) > > > > into the IKE_AUTH request, and the responder can include something like > > > > N(PPK_INDICATOR) = prf(PPK, Ni | Nr | 1) > > > > into the IKE_AUTH response. In this case each side can verify > > that the other end do own and use the correct PPK before starting > > computationally expensive public-key operations. > > That does not help. We need to Diffie-Hellman before we can see the > IKE_AUTH contents, so when we are doing that verification we have > already done the expensive operations. Sure. > On the other hand as this issue > is not really with certificates, we are not doing actual public key > operation when calculating the AUTH payload, we are simply ding the > prf with shared secret. > > With certificates the public key used is already sent in the > certificate payload inside the exchange, so it is known, and if there > is problems verifying it, we know it before we end up in the AUTH > calculation, and we return AUTHENTICATION_FAILED without ever > calculating the AUTH payload. If PPK is used then we first verify that PPK is correct and only after that start verifying certificates and AUTH payload. In case PPK is incorrect this saves us quite a lot of computation. Regards, Valery. From nobody Tue Apr 4 08:10:26 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF1F12704B for ; Tue, 4 Apr 2017 08:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHc2sZn7zvLt for ; Tue, 4 Apr 2017 08:10:22 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B2512957A for ; Tue, 4 Apr 2017 08:10:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vyC8412D0zD0s; Tue, 4 Apr 2017 17:10:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491318612; bh=UDvzCdfDcn3GYkET/ZYeMgnu+vadllBVPddm48VBUng=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MNWe7HScbjrV+VM11ve3QiV7b3wvCThxJGrjolxtTrHKg5AWKC4i3xjhmJVRV+wCD jbbwPRFgWA/3UvkIzIDOfC1A8rVcg1SsshWpEV8k2LgL6y/taCClio5YN3rxuKi2hw yIGCjQCs5A3g2d4JaPRkgFHEtw96FIo7nUCkh9VQ= 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 vrY6z_OH9aPQ; Tue, 4 Apr 2017 17:10:10 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 4 Apr 2017 17:10:10 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7271F22709B; Tue, 4 Apr 2017 11:10:09 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7271F22709B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5E67B4001697; Tue, 4 Apr 2017 11:10:09 -0400 (EDT) Date: Tue, 4 Apr 2017 11:10:09 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: "Scott Fluhrer (sfluhrer)" , "ipsec@ietf.org" In-Reply-To: <22755.38800.522208.481154@fireball.acr.fi> Message-ID: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:10:24 -0000 On Tue, 4 Apr 2017, Tero Kivinen wrote: > N(PPK_SUPPORTED) --> > For example if the PPKs are taken from the 1GB one-time-pad file > shared by the peers (one file per user), then the ppk_id could simply > be 32-bit offset to the file, and the external PPK management module > would keep track which of the offsets are used and which are not. This is vulnerable to a DOS attack though. The attacker once inserts themselves to get IDi. Then they connect to the server often enough with increased offsets to fail authentication, depleting the one-time-pad file for the real user, who presumbly then is locked out. Not announcing PPK support would not help much, as sending obvious offsets would still be detectable. Is there a way to securely use the same OTP ofset until AUTH is successful? > The NULL authentication (RFC7619) is logically incompatible with this > (it being opportunistic and this requiring configuration), so I think > we can say this will not be used with it. Or we can just say that can > be used, and SK_pi are used as specified here and in the RFC7619... I would just say don't use both :) > That would be one option too. I.e., only modify SK_pr. I think it > actually would be enough, as we do trust the other end to do correct > things, and this would be enough to know whether peers share the same > PPK. On the other hand we will end up annoying case where the > initiator will know that PPK is wrong after the IKE_SA has already > been properly installed on the responder, thus initiator needs to > signal this with separate INFORMATIONAL exchange to the responder, and > thne delete IKE SA. I think the option I explained above is better. Not a fan of this :) Paul From nobody Tue Apr 4 08:39:42 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284C41296FD for ; Tue, 4 Apr 2017 08:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f8hvq0P2EBC for ; Tue, 4 Apr 2017 08:39:27 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 BA1F01296DB for ; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1491320364; 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=c3Ej7qso2fQl3ZbvjqAnUcD43bbgy/FW5MdFSflIKOI=; b=Az5VdoBa9xGr0geZ5oV3rxbIjbJ0MAZo0P+MLGJ3egzs0peDuIWvt/TREJhlTKjy liMh04yfEphrtXqjZazrZ68N6VM1NpUW+qfZVc1ZZOfSu1bNM4vtGpu4ituLOO+g uqWLrSzSqhMHHKPiFc+K2UjCDApqyDXgByufhpi5jDZoYP4fEZdwqP2nL7HEErHO 4KZEVvx6/FT3i5CVgTPZe8HSxxJHKUTeJuUBM5SCo4+IcLz0UqDpAklIgj7uZR8w JuPmlIbwtu+b1Z+YKeBhKIKytPQ2C/LCCMZcODiVRsWhoBGdETkx7jdzzbpat5yR 9U4EjEDs0rQ5yQy+41siOw==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 47.2D.25383.C2EB3E85; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) X-AuditID: 11973e12-003389a000006327-80-58e3be2c8244 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay2.apple.com (Apple SCV relay) with SMTP id C5.7C.06512.C2EB3E85; Tue, 4 Apr 2017 08:39:24 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FllJHYsVcP3xBGnsK7b52A)" Received: from [17.153.62.197] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ONW00H6265NOG30@nwk-mmpp-sz10.apple.com>; Tue, 04 Apr 2017 08:39:24 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <87BF9C95-B970-4579-AC73-A5E1EC7F2BF8@apple.com> Date: Tue, 04 Apr 2017 08:39:23 -0700 In-reply-to: Cc: "curdle@ietf.org" , IPsecME WG , Daniel Migault , Jim Schaad , "spasm@ietf.org" , "tls@ietf.org" , "saag@ietf.org" To: David Schinazi References: <149073663013.1172.4888065212435317707.idtracker@ietfa.amsl.com> <051401d2a80b$e9bdea90$bd39bfb0$@augustcellars.com> <2DD56D786E600F45AC6BDE7DA4E8A8C118BB7D3A@eusaamb107.ericsson.se> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUi2FDorKuz73GEwY9N0hZbF85itpgyfQ+b xerp39ks9m95wWYxpb+TyWLetWSLT+e7GB3YPTbOmc7m8evrVTaPJUt+MgUwR3HZpKTmZJal FunbJXBlNC08w1zwbjJjxbp/81gaGGc2MXYxcnBICJhI/FqR28XIxSEksJdRYuqn/axdjJxg 8d5dn5khEocYJSbufgeW4BUQlPgx+R4LiM0sECbx581Jdoiir4wSW3/1s4FMFRaQkNi8JxGk hk1AReL4tw3MEL02Em+2f2cHsYUFAiQuHrkPFmcRUJXofDcVbCangK3E8slbwBYzCzQwSbyZ /JcJJCEioCGxrWkBK8Syn4wSG3s+QJ0qK9G9cBpYh4TAdzaJNQf/s05gFJqF5NpZSK6FsLUk vj9qBYpzANnyEgfPy0KENSWe3fsEVaIt8eTdBdYFjGyrGIVyEzNzdDPzTPQSCwpyUvWS83M3 MYJiabqd0A7GU6usDjEKcDAq8fBemPE4Qog1say4MvcQozQHi5I4b8CdexFCAumJJanZqakF qUXxRaU5qcWHGJk4OKUaGHX0H9dtW+b2u3+LfH/h9ezVyQeKj1zyMd+l3N1rbTZtEd/jbRyx Dxt2f2iQTnb4/Obw/0Mr+C+y1T3O3HPRZFaID9vfyPrXdz5uS9l0KWRCqaHxl2eLS0Vml0xU 0BPe3Vrq6VkRJH/g7l3tS7cPnAuIfN/4dpNVjlCnldK8j3VXhJQsZY6GLlRiKc5INNRiLipO BAAkoxtAhgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHIsWRmVeSWpSXmKPExsUi2FBcpauz73GEwelZwhZbF85itpgyfQ+b xerp39ks9m95wWYxpb+TyWLetWSLT+e7GB3YPTbOmc7m8evrVTaPJUt+MgUwR3HZpKTmZJal FunbJXBlNC08w1zwbjJjxbp/81gaGGc2MXYxcnJICJhI9O76zNzFyMUhJHCIUWLi7nesIAle AUGJH5PvsYDYzAJhEn/enGSHKPrKKLH1Vz9bFyMHh7CAhMTmPYkgNWwCKhLHv21ghui1kXiz /Ts7iC0sECBx8ch9sDiLgKpE57upYDM5BWwllk/eAraYWaCBSeLN5L9MIAkRAQ2JbU0LWCGW /WSU2NjzgRXiVFmJ7oXTmCcw8s9CcuAsJAdC2FoS3x+1AsU5gGx5iYPnZSHCmhLP7n2CKtGW ePLuAusCRrZVjAJFqTmJlUZ6iQUFOal6yfm5mxjBwV/ovIPx2DKrQ4wCHIxKPLwXZjyOEGJN LCuuzAWGEgezkgiv/R6gEG9KYmVValF+fFFpTmrxIcaJjEBvTmSWEk3OB8ZmXkm8oYmJgYmx sZmxsbmJOS2FlcR5c8rvRQgJpCeWpGanphakFsEcxcTBKdXA6MM4uzd10kED8clhtuwcE0Tm 3l874yDPz7fiXFtj7t/5xchbnqRSZ3HiVe2sirzO+0KNblNdp/h+/rtcqLW0ifXP8l2n7GuW 5fcpXi9KSNrREhZvty6bZZNW9pL6DImZ18xPbWqdtlpPxLVrt+7lYLkuWTZp7Y0/3J0ftvzM Snsu3p3/VGepEktxRqKhFnNRcSIAtItIifECAAA= Archived-At: Subject: Re: [IPsec] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:39:29 -0000 --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I've gone through my review of the draft as well, and I think this version looks good! Thanks, Tommy > On Apr 3, 2017, at 11:25 AM, David Schinazi wrote: > > Thanks for the update! > > I've reviewed -04 and I think the draft is ready to move forward. > > Regards, > David Schinazi > > >> On Mar 28, 2017, at 15:43, Daniel Migault > wrote: >> >> Hi, >> >> Thank you Jim for the update. Here is the version resulting from the discussion we had during the WG meeting yesterday. Please review the document and provide your feed backs by April 4 so we can move the draft to the IESG. >> >> Yours, >> Daniel >> >> -----Original Message----- >> From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim Schaad >> Sent: Tuesday, March 28, 2017 4:40 PM >> To: curdle@ietf.org >> Subject: [Curdle] FW: New Version Notification for draft-ietf-curdle-pkix-04.txt >> >> Here is the promised updated draft. >> >> Changes: >> 1. Fixed an example that David Benjamin found was wrong. (Incorrect sign bit in public key.) 2. Remove all of the pre-hash text except to note that it does exist. >> 3. No changes to the OID arc being used despite the agreement during the meeting. After the meeting, Russ, the chairs and I had a short talk and decided that this did not need to occur. The problem was only with getting new values assigned not with the current values which were already assigned. >> >> That should be the final issues in the draft >> >> Jim >> >> >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Tuesday, March 28, 2017 4:31 PM >>> To: Jim Schaad ; Simon Josefsson >>> >>> Subject: New Version Notification for draft-ietf-curdle-pkix-04.txt >>> >>> >>> A new version of I-D, draft-ietf-curdle-pkix-04.txt has been >>> successfully submitted by Jim Schaad and posted to the IETF repository. >>> >>> Name: draft-ietf-curdle-pkix >>> Revision: 04 >>> Title: Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for >>> use in the Internet X.509 Public Key Infrastructure >>> Document date: 2017-03-28 >>> Group: curdle >>> Pages: 15 >>> URL: https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.txt >>> Status: https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/ >>> Htmlized: https://tools.ietf.org/html/draft-ietf-curdle-pkix-04 >>> Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04 >>> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-curdle-pkix-04 >>> >>> Abstract: >>> This document specifies algorithm identifiers and ASN.1 encoding >>> formats for Elliptic Curve constructs using the Curve25519 and >>> Curve448 curves. The signature algorithms covered are Ed25519 and >>> Ed448. The key agreement algorithm covered are X25519 and X448. The >>> encoding for Public Key, Private Key and EdDSA digital signature >>> structures is provided. >>> >>> >>> >>> >>> 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 >> >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle >> >> _______________________________________________ >> Curdle mailing list >> Curdle@ietf.org >> https://www.ietf.org/mailman/listinfo/curdle > > _______________________________________________ > Curdle mailing list > Curdle@ietf.org > https://www.ietf.org/mailman/listinfo/curdle --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
I've gone through my review of the draft as = well, and I think this version looks good!

Thanks,
Tommy

On Apr 3, 2017, at 11:25 AM, David Schinazi = <dschinazi@apple.com> wrote:

Thanks for the update!
I've reviewed -04 and I think the draft is ready = to move forward.

Regards,
David Schinazi

On Mar 28, 2017, at 15:43, = Daniel Migault <daniel.migault@ericsson.com> wrote:

Hi, 

Thank you Jim for the update. Here is the = version resulting from the discussion we had during the WG meeting = yesterday.  Please review the document and provide your feed backs = by April 4 so we can move the draft to the IESG. 

Yours, 
Daniel

-----Original = Message-----
From: Curdle [mailto:curdle-bounces@ietf.org] On Behalf Of Jim = Schaad
Sent: Tuesday, March 28, 2017 4:40 PM
To: curdle@ietf.org
Subject: [Curdle] FW: New = Version Notification for draft-ietf-curdle-pkix-04.txt

Here is the promised updated draft.

Changes:
1.  Fixed an example that David = Benjamin found was wrong.  (Incorrect sign bit in public key.) 2. =  Remove all of the pre-hash text except to note that it does = exist.
3.  No changes to the OID arc being used = despite the agreement during the meeting.  After the meeting, Russ, = the chairs and I had a short talk and decided that this did not need to = occur.  The problem was only with getting new values assigned not = with the current values which were already assigned.

That should be the final issues in the draft

Jim


-----Original Message-----
From: = internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: = Tuesday, March 28, 2017 4:31 PM
To: Jim Schaad <ietf@augustcellars.com>; Simon Josefsson 
<simon@josefsson.org>
Subject: New = Version Notification for draft-ietf-curdle-pkix-04.txt


A new version of I-D, = draft-ietf-curdle-pkix-04.txt has been 
successfully = submitted by Jim Schaad and posted to the IETF repository.

Name: draft-ietf-curdle-pkix
Revision: 04
Title: Algorithm Identifiers for = Ed25519, Ed448, X25519 and X448 for
use in the Internet = X.509 Public Key Infrastructure
Document date: = 2017-03-28
Group: curdle
Pages: 15
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-curdle-pkix-04.= txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-curdle-pkix/Htmlized:       https://tools.ietf.org/html/draft-ietf-curdle-pkix-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-curdle-pkix-04=
Diff: =           https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-curdle-pkix-04

Abstract:
 This = document specifies algorithm identifiers and ASN.1 encoding
 formats for Elliptic Curve constructs using the = Curve25519 and
 Curve448 curves.  The signature = algorithms covered are Ed25519 and
 Ed448.  The = key agreement algorithm covered are X25519 and X448.  The
 encoding for Public Key, Private Key and EdDSA digital = signature
 structures is provided.




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


_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

_______________________________________________
Curdle mailing list
Curdle@ietf.org
https://www.ietf.org/mailman/listinfo/curdle

= --Boundary_(ID_FllJHYsVcP3xBGnsK7b52A)-- From nobody Tue Apr 4 08:41:12 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA061292CE for ; Tue, 4 Apr 2017 08:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 p7wjtdZQtyYP for ; Tue, 4 Apr 2017 08:41:07 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B555112940E for ; Tue, 4 Apr 2017 08:41:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8519; q=dns/txt; s=iport; t=1491320467; x=1492530067; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tlGq4wMGWoQCQVQo/Eh0Q0S7amtpj6XPQG7L+knL2Xo=; b=WDxmHQzU4nSUW4d1cm41R27bVusnwqLl8OP5RYXWg4YkzjsgVNfo0hnY lW2LPe2DvpF+RmGrbWos1Ug2DVfhTgiVykiZr3UvcRO+gKkkxlXPPp9hH 4y2iF3CTqiTbifcjJXiCDTEVTAdGnv+QrO+h49M1J2ZcIC7QLRvodlewR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQBIveNY/4sNJK1TCRkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNUgWwHjW6RWpVTgg6GIgKDQD8YAQIBAQEBAQEBayiFFQEBAQE?= =?us-ascii?q?CAScTPwUHBAIBCBEEAQEfCQcyFAkIAgQOBQiJfgivZTqKWwEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAR2GToRvhC0ahXIBBIkjhkSNBgGSRoIGjz9IiBSLGAEfOIEFWxW?= =?us-ascii?q?FGh2BY3WGXgIFH4EKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,275,1486425600"; d="scan'208";a="226567426" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2017 15:41:06 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v34Ff6pu004621 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Apr 2017 15:41:06 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 4 Apr 2017 11:41:05 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Tue, 4 Apr 2017 11:41:05 -0400 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing Thread-Index: AQHSqOHRXsYj5uYL3E2R1gdN4nkGdaGz0xSwgAGjdQD//9ugUA== Date: Tue, 4 Apr 2017 15:41:05 +0000 Message-ID: <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> In-Reply-To: <22755.38800.522208.481154@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Apr 2017 15:41:11 -0000 Going through this suggestion (and tweaking it a bit): Pluses: - It is more flexible; in addition to supporting the fixed PPK's, it would = also allow support for one-use PPKs (as you mention), as well as being easy= to extend to handle Phillip LaFrance's PFS ideas. - Even for fixed PPK's, it makes it possible to update the PPKs in a bump-l= ess fashion. - I believe it can be made a bit more flexible than you make it out; it don= 't believe that you actually need to update every node with every PPK at th= e start. With this protocol, the initiator decides which PPK to use (and w= hether to use a PPK at all; the obvious idea would be 'if the initiator doe= sn't' send a PPK_NOTIFY message, no PPK is in use'). With this, the upgrad= e procedure becomes: Step 1: configure the PPKs and the id's on each peer. This will allow eac= h side to use this protocol if it was the responder, but not insist on it i= f it's the initiator Step 2: for each peer, configure which PPK to use (probably based on peer = identity), and make its use optional. That is, when we're initiating, we'l= l now use the PPK; however, if we're the responder, we'll use the PPK if th= e initiator asks, but not reject the SA if he doesn't Step 3: for each peer, make the use of PPK mandatory (and so if we're the = responder, when we get the initiator's identity, we see that the use of PPK= was required; if we didn't get PK_NOTIFY, we'll reject the request) Again, we don't need to upgrade the entire network at once; we could incr= ementally do this by peer-to-peer connection... Minus: - It makes roll out possible, but (as above) it's a 3 step affair, rather t= han the previous 2 step.=20 - We also need to specify the format of the ppk_id. This isn't that hard, = however we did want an updated revision Real Soon Now, and this format does= n't feel like something I want to just slap together.... Also, with the above tweak, I'm not certain what value the PPK_SUPPORTED no= tify brings to the table; you had it for the responder to signal to the ini= tiator that it's been upgraded; the above protocol has the initiator expect= ing whether specific responders are upgraded or not. It might make debuggi= ng a bit easier... Another thing to consider: what if we're the responder, and the initiator u= ses a PPK (which we have), but not the PPK we would have used if we're the = initiator. I believe that we want to accept this (even if our PPK is marke= d as mandatory); would that lead to any potential problems? Thoughts??? > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Tuesday, April 04, 2017 8:55 AM > To: Scott Fluhrer (sfluhrer) > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing >=20 > [Not wearing any hats] >=20 > Scott Fluhrer (sfluhrer) writes: > > - Move the notifies to the prior messages (that is, in the clear). > > If we do this, then by the time we derive keys, we know whether we're > > using a PPK (even if the responder doesn't know which one it is until > > it hears the initiator's id). This would mean that anyone could tell > > whether the two sides are using a PPK >=20 > Currently PPK_NOTIFY is empty notification so moving that to the the > IKE_SA_INIT and changing its name to PPK_SUPPORTED is fine. >=20 > Sending the actual PPK identity is better done on the IKE_AUTH where it i= s > protected by the Diffie-Hellman, meaning attacker needs to do active atta= ck > to learn it. >=20 > So I think protocol should be something like >=20 >=20 > Initiator Responder > ------------------------------------------------------------------- > HDR, SAi1, KEi, Ni, > N(PPK_SUPPORTED) --> > <-- HDR, SAr1, KEr, Nr, > N(PPK_SUPPORTED), [CERTREQ] > HDR, SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, > N(PPK_IDENTITY, ), > TSi, TSr} --> > <-- HDR, SK {IDr, [CERT,] AUTH, > SAr2, TSi, TSr} >=20 > Where the N(PPK_SUPPORTED) just tells that both ends support PPK, and > they have at least one PPK installed. This means that incremental install= ation > needs to be done so that all possible PPKs are always installed for each > identity to the machine once, i.e., it either knows PPKs for all IDs and = sends > N(PPK_SUPPORTED) or it does not send > N(PPK_SUPPORTED) at all. >=20 > I.e., you cannot install just PPKs for half of the users and enable > N(PPK_SUPPORTED). PPK will be enabled only and only if both ends send > N(PPK_SUPPORTED) during the IKE_SA_INIT. >=20 > Then during the IKE_AUTH the initiator picks PPK to use and sends the > associated with the PPK in the N(PPK_IDENTITY, ...) notify and u= ses > the PPK to generate the AUTH. If it only has one PPK meaning the > does not have any meaning it will send it as empty. If it does not send > PPK_IDENTITY at all, that means it is not using PPK even when it was enab= led > (this can be used for example to test whether the authentication problem = is > in the shared secret being wrong or in the case where the PPK is wrong). >=20 > If N(PPK_IDENTITY, ) was sent by the initiator then responder wil= l > find the matching for the user specified in the IDi and will use that whe= n > calculating AUTH. The ppk_id is opaque binary string and will be be > interpreted at all by the IKE, but the PPK management module might provid= e > internal format for it. >=20 > For example if the PPKs are taken from the 1GB one-time-pad file shared b= y > the peers (one file per user), then the ppk_id could simply be 32-bit off= set to > the file, and the external PPK management module would keep track which > of the offsets are used and which are not. >=20 > If the ppk_id is not known by the responder, then it will return > N(AUTHENTICATION_FAILED) error and log the error to the local log file. >=20 > If EAP is used, then exchange is bit different: >=20 >=20 > Initiator Responder > ------------------------------------------------------------------- > HDR, SAi1, KEi, Ni, > N(PPK_SUPPORTED) --> > <-- HDR, SAr1, KEr, Nr, > N(PPK_SUPPORTED), [CERTREQ] > HDR, SK {IDi, [CERTREQ,] > [IDr,] SAi2, > N(PPK_IDENTITY, ), > TSi, TSr} --> > <-- HDR, SK {IDr, [CERT,] AUTH, EAP} > HDR, SK {EAP} --> > <-- HDR, SK {EAP (success)} > HDR, SK {AUTH} --> > <-- HDR, SK {AUTH, SAr2, TSi, TSr} >=20 > I.e., the PPK_IDENTITY is still sent inside the first IKE_AUTH, but of co= urse in > this case the actual PPK is not used by the initiator yet. > The responder will then reply with AUTH payload using the PPK, and the fi= nal > exchange uses the PPK again in both ends. >=20 > With EAP only authentication (RFC5998) the exchange is about same, except > now we do not have "[CERT,] AUTH" in the responders first IKE_AUTH > message, and the PPK is only used in the final IKE_AUTH exchange when > calculating AUTH payloads. >=20 > The NULL authentication (RFC7619) is logically incompatible with this (it= being > opportunistic and this requiring configuration), so I think we can say th= is will > not be used with it. Or we can just say that can be used, and SK_pi are u= sed > as specified here and in the RFC7619... >=20 > > - For the initiator's AUTH payload, use SK_pi' always. However, I > > suspect this would partially mess up the reason we're strirring it > > into SK_pi in the first place. >=20 > That would be one option too. I.e., only modify SK_pr. I think it actuall= y > would be enough, as we do trust the other end to do correct things, and t= his > would be enough to know whether peers share the same PPK. On the other > hand we will end up annoying case where the initiator will know that PPK = is > wrong after the IKE_SA has already been properly installed on the > responder, thus initiator needs to signal this with separate INFORMATIONA= L > exchange to the responder, and thne delete IKE SA. I think the option I > explained above is better. > -- > kivinen@iki.fi From nobody Wed Apr 5 05:24:26 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DF0F126B6D for ; Wed, 5 Apr 2017 05:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SSupyY2LgMM for ; Wed, 5 Apr 2017 05:24: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 D9B04127B31 for ; Wed, 5 Apr 2017 05:24:19 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v35COB2Y000472 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Apr 2017 15:24:11 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v35COAi9003662; Wed, 5 Apr 2017 15:24:10 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22756.57834.437931.308077@fireball.acr.fi> Date: Wed, 5 Apr 2017 15:24:10 +0300 From: Tero Kivinen To: Paul Wouters Cc: "Scott Fluhrer \(sfluhrer\)" , "ipsec\@ietf.org" In-Reply-To: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 12 min X-Total-Time: 11 min Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 12:24:24 -0000 Paul Wouters writes: > On Tue, 4 Apr 2017, Tero Kivinen wrote: > > > N(PPK_SUPPORTED) --> > > > For example if the PPKs are taken from the 1GB one-time-pad file > > shared by the peers (one file per user), then the ppk_id could simply > > be 32-bit offset to the file, and the external PPK management module > > would keep track which of the offsets are used and which are not. > > This is vulnerable to a DOS attack though. The attacker once inserts > themselves to get IDi. Then they connect to the server often enough > with increased offsets to fail authentication, depleting the > one-time-pad file for the real user, who presumbly then is locked out. Nope. Like normally you are not using the data in the file unless it is properly authenticated. I.e. even if the attacker can say use PPK from offset 0x123123, the other end will not update the offset 0x123123 to be used unless the other end also proofs it knows the PPK at that offset. It is same as we do not update the ESP replay counter unless the packet actually has valid authentication token. And this was the exact issue the 802.15.4 had with encrypt only mode, i.e., with encrypt only mode there was no authentication tag, so the responder was always required to assume packet is valid, and then it updated the global frame counter of the sending device, and if attacker sent frame counter of 0xfffffffe, that effectively locked the sending device out permanently. This is the reason encrypted only mode was removed in the 802.15.4-2015.... And the real user will most likely be locked out earlier because when the attacker starts to do several tens of million IKE connections to the server the server will most likely lock the user out or add delays to connections long before the attacker is able to deplate the one time pad... > Not announcing PPK support would not help much, as sending obvious > offsets would still be detectable. Yep. > Is there a way to securely use the same OTP ofset until AUTH is > successful? Yes. This is what all OTP methods do. If you give wrong value for OTP token, they will ask the same value over and over again until you get it right. In addition to that they usually add longer and longer delays if you get it wrong several times in the row and finally lock you out. They might even give you information saying that you typed OTP response for number 15, but current response number required is 16. For example the bank in Finland which uses OTP tokens does that, but only if you give correct response to the number that was already used. They also say that if you have completely lost the number where you are, type in the last number in the list, and they will then tell you what number is the next number on the list (I assume they will then mark the last number used, and next time ask for second last number etc). > > The NULL authentication (RFC7619) is logically incompatible with this > > (it being opportunistic and this requiring configuration), so I think > > we can say this will not be used with it. Or we can just say that can > > be used, and SK_pi are used as specified here and in the RFC7619... > > I would just say don't use both :) Good. I was scared you might say, that of course we need to be able to use NULL authentication with quantum protection... -- kivinen@iki.fi From nobody Wed Apr 5 06:00:42 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A45791250B8 for ; Wed, 5 Apr 2017 06:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RzgSTyQZi-a for ; Wed, 5 Apr 2017 06:00:40 -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 D98A9128616 for ; Wed, 5 Apr 2017 06:00:38 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v35D0V36000437 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Apr 2017 16:00:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v35D0Vta022939; Wed, 5 Apr 2017 16:00:31 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22756.60015.425330.926683@fireball.acr.fi> Date: Wed, 5 Apr 2017 16:00:31 +0300 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" Cc: "ipsec\@ietf.org" In-Reply-To: <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 34 min X-Total-Time: 35 min Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:00:42 -0000 Scott Fluhrer (sfluhrer) writes: > Going through this suggestion (and tweaking it a bit): > > Pluses: > - I believe it can be made a bit more flexible than you make it out; > it don't believe that you actually need to update every node with > every PPK at the start. With this protocol, the initiator decides I did not even require that. I said you need to provide all PPKs for that one node at the same time. Or at least that I was trying to say. I can now see that my text was bit unclear. I.e., when you configure node A for PPK use, you need to give node A all the PPKs for all peers it has. I.e., the configuration loaded on the node A needs to provide all PPKs it will need. Then you can do same thing for other nodes one by one cases. I.e., you do not need to update the whole network at once, but you need to provide full configuration for the one device at the same time. After node A is configure with all PPKs, it will start sending N(PPK_SUPPORTED) notifications. If it connects to other node which has been reconfigured, then that node will also respond with N(PPK_SUPPORTED) and they will use PPK. If it connects to node which has not yet been reconfigured, then the node will not send N(PPK_SUPPORTED) and PPK will be disabled. > which PPK to use (and whether to use a PPK at all; the obvious idea > would be 'if the initiator doesn't' send a PPK_NOTIFY message, no > PPK is in use'). With this, the upgrade procedure becomes: > Step 1: configure the PPKs and the id's on each peer. This > will allow each side to use this protocol if it was the responder, > but not insist on it if it's the initiator > Step 2: for each peer, configure which PPK to use (probably > based on peer identity), and make its use optional. That is, when > we're initiating, we'll now use the PPK; however, if we're the > responder, we'll use the PPK if the initiator asks, but not reject > the SA if he doesn't > Step 3: for each peer, make the use of PPK mandatory (and so > if we're the responder, when we get the initiator's identity, we see > that the use of PPK was required; if we didn't get PK_NOTIFY, we'll > reject the request) > Again, we don't need to upgrade the entire network at once; we > could incrementally do this by peer-to-peer connection... Yes. That was there already in my proposal (but text was bit unclear). > Minus: > - It makes roll out possible, but (as above) it's a 3 step affair, > rather than the previous 2 step. Actually it is not 3 step affair, it is one step affair for each node. Step 1) Install configuration having PPKs for node A. Repeat step 1 on all other nodes, at will. Immediately when both pairs of the connections have been reconfigured they will start using PPK. If you want to change the configuration so that PPK is required then that is second reconfiguration for the whole network, but this is not something that needs to be done, as properly configured systems will always use PPK if both ends have been reconfigured to have PPKs, unless initiator explictly disables it for this connection (i.e., for example for debugging purposes). Only reason why you want to enforce the PPKs to be used always, is when you know that your attacker can already break Diffie-Hellman on real time, and can also break your authentication method in real time. Then you need to use PPK to protect the authentication, as if attacker is able to break the authentication in real time, then it can also modify the packets on the wire by removing the N(PPK_IDENTITY) or N(PPK_SUPPORTED) notifies and disabled PPK. If the authentication (and Diffie-Hellman) cannot be broken in real time then authentiation will prevent attacker disabling PPK. > - We also need to specify the format of the ppk_id. This isn't that > hard, however we did want an updated revision Real Soon Now, and > this format doesn't feel like something I want to just slap > together.... Actually for both ppk_id, and the PPK value used in the calculations, I would suggest following: Both the the ppk_id inside the N(PPK_IDENTITY) and the PPK value used in the SK_d/SK_pi/SK_pr calculations are opaque octect streams. Implementations supporting PPK, MUST support ppk_ids having length of less than 64 octets, and MAY support longer ppk_id values. The PPK itself MUST have length between 16 and 64 octets. When both ppk_id and PPK are represented in the user interface the user interface MUST allow any octet stream to be represented (i.e., it must not assume that it can safely print the ppk or ppk_id to screen without any encoding them to printable characters), and MUST provide a way to input ppk_id and PPK in base64-encoded ascii string. User interface MAY allow other formats too, like plain ASCII, UTF-8, or hex-string. This requirement is only for the user interface, if the API is used to configure the ppk_id and PPK, then direct binary representation can be used and no base64 version of the API is needed. Note, that both ppk_id and PPK are octet streams, they are not assumed to be any kind of strings, thus they do not have associated character sets, and while UTF-8 strings are valid values for them, there is no character set specific processing for them. > Also, with the above tweak, I'm not certain what value the > PPK_SUPPORTED notify brings to the table; you had it for the > responder to signal to the initiator that it's been upgraded; the > above protocol has the initiator expecting whether specific > responders are upgraded or not. It might make debugging a bit > easier... Yes. It will allow setup to be done using 1 phase protocol instead of 3 phases. I.e. as N(PPK_SUPPORTED) tells to both ends whether they have been configured with the needed information to do PPK, and after that they will know they can use PPK if they like. This is also the way we have done things with other extensions, i.e., exchange notification in the IKE_SA_INIT for supported features. > Another thing to consider: what if we're the responder, and the > initiator uses a PPK (which we have), but not the PPK we would have > used if we're the initiator. I believe that we want to accept this > (even if our PPK is marked as mandatory); would that lead to any > potential problems? I would say it depends on the PPK. If we use one-time-use PPKs, then we will reject PPKs we know have already been used earlier. If we are doing PPK rotation weekly, and other end moves to next PPK earlier than we would have, we can allow that, as there most likely are reason for that and this was caused by the adminstrator doing something. For example the previous PPK was somehow compromized or lost, and the other peer wants to move the the next one because of that. -- kivinen@iki.fi From nobody Wed Apr 5 06:33:45 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA7E128DF6; Wed, 5 Apr 2017 06:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOVe_1oqrkwO; Wed, 5 Apr 2017 06:33:43 -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 2501C1250B8; Wed, 5 Apr 2017 06:27:00 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v35DQw4U024618 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 Apr 2017 16:26:58 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v35DQw9x028191; Wed, 5 Apr 2017 16:26:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22756.61602.820418.641692@fireball.acr.fi> Date: Wed, 5 Apr 2017 16:26:58 +0300 From: Tero Kivinen To: draft-ietf-ipsecme-eddsa.all@ietf.org CC: ipsec@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 16 min Archived-At: Subject: [IPsec] draft-ietf-ipsecme-eddsa-01 pre-hash SHOULD NOT or MUST NOT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 13:33:44 -0000 Now the pre-hash algorithms are SHOULD NOT: The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph respectively) SHOULD NOT be used in IKE. I think we could say MUST NOT be used. I.e, say that pre-hash versions MUST NOT be used, and that Ed25519 and Ed448 MUST be used with "Identity" hash identifier, and none of the other currently defined signature algorithms MUST NOT use "Identity" hash... The following part of the security considerations might also need updating: On the other hand there is no good reason to pre-hash the inputs where the signature algorithm either does not require it or performs a hash internally. This sentence would indicate that if the RSA key is large enough so we can actually sign the full data without pre-hashing, that would be something we would prefer. I do not think we actually want to allow that. We should say that Identity hash identifier MUST only be used when using signature algorithms specifically supporting it. For this reason implementations SHOULD have the "Identity" value in the SIGNATURE_HASH_ALGORITHMS notification when they support EdDSA. Implementations SHOULD NOT have other hash algorithms in the notification if all signature algorithms have this property. If implementation supports EdDSA then it is policy decision whether it wants to use it, and wheter it wants ot include "Identity" as one of the hash algorithms. -- kivinen@iki.fi From nobody Wed Apr 5 08:40:19 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD83129420 for ; Wed, 5 Apr 2017 08:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUUReUZkE49h for ; Wed, 5 Apr 2017 08:40:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 775751289B5 for ; Wed, 5 Apr 2017 08:40:13 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vyqm94Hp0zCx4; Wed, 5 Apr 2017 17:40:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491406809; bh=C+oUb/qJyobbtLVK+PM/nXgyRu3RcpfhzEAIKnptEDE=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=lREX1AKiq/d/EjJmeUoinU8IkSPQPtTwgiykwGxvpcij+JQEzJBrK35Ji/tShBp6y JbddKzuxpG+wj5foDUVzll9nAHbm53zeINok9abZlS4nyFaxS0iKwIGcndqW0mmW+8 BKXmsw8WAJmdNC/Tl9rGFT0G9b91NpRUw22wZHyM= 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 JGmuOMhlrHvq; Wed, 5 Apr 2017 17:40:03 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 5 Apr 2017 17:40:03 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B77E14CA355; Wed, 5 Apr 2017 11:40:02 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B77E14CA355 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A82A240D3588; Wed, 5 Apr 2017 11:40:02 -0400 (EDT) Date: Wed, 5 Apr 2017 11:40:02 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: "Scott Fluhrer (sfluhrer)" , "ipsec@ietf.org" In-Reply-To: <22756.57834.437931.308077@fireball.acr.fi> Message-ID: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <22756.57834.437931.308077@fireball.acr.fi> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 15:40:17 -0000 On Wed, 5 Apr 2017, Tero Kivinen wrote: >> This is vulnerable to a DOS attack though. The attacker once inserts >> themselves to get IDi. Then they connect to the server often enough >> with increased offsets to fail authentication, depleting the >> one-time-pad file for the real user, who presumbly then is locked out. > > Nope. Like normally you are not using the data in the file unless it > is properly authenticated. I.e. even if the attacker can say use PPK > from offset 0x123123, the other end will not update the offset > 0x123123 to be used unless the other end also proofs it knows the PPK > at that offset. That opens up an attack where an attacker can trick you into re-using the same PPK many times. I was assuming that could be dangerous in itself? If it is not, then we should clearly explain that in the document. > And the real user will most likely be locked out earlier because when > the attacker starts to do several tens of million IKE connections to > the server the server will most likely lock the user out or add > delays to connections long before the attacker is able to deplate the > one time pad... If the attacker can lock out the real user, that is also a DOS attack :) >>> The NULL authentication (RFC7619) is logically incompatible with this >>> (it being opportunistic and this requiring configuration), so I think >>> we can say this will not be used with it. Or we can just say that can >>> be used, and SK_pi are used as specified here and in the RFC7619... >> >> I would just say don't use both :) > > Good. I was scared you might say, that of course we need to be able to > use NULL authentication with quantum protection... My intention is to create so much AUTH_NULL IKE that I really hope the TLA's cannot store all that ESP traffic to decrypt it with their fancy new quantum computer in five years :) Paul From nobody Wed Apr 5 12:30:25 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4364129439 for ; Wed, 5 Apr 2017 12:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 AnY06vKBc7Xr for ; Wed, 5 Apr 2017 12:30:23 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F94812941D for ; Wed, 5 Apr 2017 12:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2660; q=dns/txt; s=iport; t=1491420623; x=1492630223; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LIj7c5X78kUypfd60JA7HY4GQdRqTyOLRcD559X2gtA=; b=UCa9zKEBikoaadwIwi3Z9tIlN8bi0OlrQ6/bKdpw6mSLDnDM9VFsxA8N q7Ih+crrN/OmEF6HtUAQ0OzWN4tvc5HS5+64p/Vy2CKNvDZlnKGLVAyPy YpClwEGvGKDVXPmgvg+VlZ3qTYk364HnKrvniEzTMvefZBeI4vel0T3PL M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8AQBDReVY/40NJK1UCRoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYNUgXONbqcRgg6GIgKDUj8YAQIBAQEBAQEBayiFFgY6PxACAQg2EDI?= =?us-ascii?q?lAgQODYoGrVqKawEBAQEBAQEBAQEBAQEBAQEBAQEfhk6EcIQvGoVyBZxwAYoni?= =?us-ascii?q?CGCBo8/SIgVixgBHziBBVsVhxqHSQIFH4EKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,280,1488844800"; d="scan'208";a="405148908" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Apr 2017 19:30:22 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v35JUMHb027157 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Apr 2017 19:30:22 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Apr 2017 15:30:21 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Wed, 5 Apr 2017 15:30:21 -0400 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing Thread-Index: AQHSqOHRXsYj5uYL3E2R1gdN4nkGdaGz0xSwgAGjdQD//9ugUIABuFeAgAAf4QA= Date: Wed, 5 Apr 2017 19:30:21 +0000 Message-ID: <8c151b63a7aa408e9e4aee3bccbeab78@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> In-Reply-To: <22756.60015.425330.926683@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 19:30:25 -0000 Ok, I now see what part of your idea I was (sort of) trying to work around.= To make it clear to everyone, I'll spell out the problem we're trying to = address, and how your idea (with a slight addition on my part) could addres= s it. What we're talking about is "how would someone take a network that's using = the standard IKE implementation, and convert it into a network that uses IK= E+PPKs, and in a way that doesn't cause a flag day, or prevent negotiations= from happening between nodes while the upgrade is in progress. The idea is that the network admin goes through the nodes, and upgrades the= m in order; in step 0, the nodes are running standard IKE, and in the final= step, they are running the full PPK protocol (and insist on using it). Fo= r the upgrade to be bumpless, we require that any node at step i be able to= communicate (as either initiator or responder) with a node at step i-1, i = or i+1 (assuming, of course, that our security policy allows those two node= s to communicate). With your idea, there are three steps (and so the admin would update each n= ode in the network twice): - Step 0 is "never use PPKs"; we're running the standard IKE protocol. - Step 1 is "if we're the initiator, then use PPKs if the responder signale= d support for it" "if we're the responder, then signal support, and allow the use of PPKs= " - Step 2 is "insist on PPKs (and also signal support if we're the responder= )" The issue I was pondering was "what if the admin wants to update only part = of their network (say, as a test)?". As I understood your proposal, the PP= K_SUPPORT notify was always on if any PPKs were configured; indeed, from a = responder side, it has to be that (because the responder has no other conte= xt to issue it or not). However, from an initiator standpoint, it knows wh= o the responder is (or, at least, it has to; it's the one that selects whic= h PPK to use); hence, from the initiator standpoint, the PPK_SUPPORT notify= could mean "I have a PPK that I would like to use with you, are you willin= g?" With that proviso, then partial upgrades of the network can work; if an ini= tiator (in the upgraded portion) talks to a responder in an nonupgraded sec= tion (or in an independently upgraded section), it just notes it doesn't ha= ve a PPK, and so doesn't send the notify (and similarly, if it was the init= iator who wasn't upgraded, the responder performs the standard IKE protocol= , and when the responder gets the identity, it can verify whether or not it= would have expected the initiator to be upgraded). So, how does that sound? From nobody Thu Apr 6 00:53:12 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C42129436 for ; Thu, 6 Apr 2017 00:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19NocJaIHIV3 for ; Thu, 6 Apr 2017 00:53:10 -0700 (PDT) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58E312704A for ; Thu, 6 Apr 2017 00:53:09 -0700 (PDT) Received: by mail-lf0-x235.google.com with SMTP id j90so21682498lfk.2 for ; Thu, 06 Apr 2017 00:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=YFzBpN/bmFcBotLwVYTp7xsjquChJD/kr61s7JVsFTg=; b=Esx9OGjqIOoAyBVbwQ41k3bP7Ds/9NtoIBN7lObQ56WAigF6WsZoDZzfTrXk3/Inq3 FHtKHc460O4j/KQi0CHfqQwb2QZ5hmArmdfwMVzfKVaOE8mJGrqpNA8J4idCSWmJ91Tv Yltfb4X4T+qWeuXbOv70/YPdbkhLVS0n4+X03p+InBWUeChPyXyPpUmehi+vUaF/P3mK j2jGtv03EWNO51Cxhf/8B4u1AlwdkZ6Yj5SwBpAZYJZzU65yCPUmOrLYoWBOVwu/JD1T eUdhJWfh7SfrcAS4e1yewdO2OlGnnfcIhyYKyGEFopGAPtNiPsTtYRNeNpwUs2WICDI6 Ig1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=YFzBpN/bmFcBotLwVYTp7xsjquChJD/kr61s7JVsFTg=; b=ATOd/Ek5MGJuA8Fs+Psic4keJk5/jJCBFcklEeXVcQbXuGdvlYDJTOoUmOyzrfB/9X ifz7VSpTpUHxAiMBSgHmGnam8FY9zM0dHHGJV2GENcNKg7FgD7R8lAzRIIIZgHA4sW7g qUUjD1IWLmrDjPrUSXlzQvdwwBk1wDDxtyR5SIf3HoC8SBHiPAUGCZFJZVS1mmIi6WmZ usKnM2ixwqFde7TJWynIcGWAyInrelydjk4hvwCylS67ywr55OT02liiOYMoH/60yBK6 dJJl2MefnR6iQTG2Kp0ASW4rr3NCPu5AKk1yZmlOGvpVnBSpOFq6RmD9E+lW5QrCpJtc Xvng== X-Gm-Message-State: AFeK/H3Ug07gYWB7p6H4SXkDSOLWIVPNqmPqojWZc5EWh2idHkFg9fGo/d0n7kyMSibN0w== X-Received: by 10.25.125.197 with SMTP id y188mr10910335lfc.172.1491465187615; Thu, 06 Apr 2017 00:53:07 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 99sm176923ljb.23.2017.04.06.00.53.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Apr 2017 00:53:06 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Paul Wouters'" Cc: , "'Scott Fluhrer \(sfluhrer\)'" References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <22756.57834.437931.308077@fireball.acr.fi> In-Reply-To: <22756.57834.437931.308077@fireball.acr.fi> Date: Thu, 6 Apr 2017 10:52:50 +0300 Message-ID: <122b01d2aeaa$ca72cc00$5f586400$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8gHZiixpAiXmKX8CzU7COgIqJkVGoFET5yA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 07:53:11 -0000 Hi, > > > The NULL authentication (RFC7619) is logically incompatible with this > > > (it being opportunistic and this requiring configuration), so I think > > > we can say this will not be used with it. Or we can just say that can > > > be used, and SK_pi are used as specified here and in the RFC7619... > > > > I would just say don't use both :) > > Good. I was scared you might say, that of course we need to be able to > use NULL authentication with quantum protection... If both peers use NULL authentication, then there is no sense to use PPK, since it is assumed that there is no trusted relationship between them (and thus they don't share PPK). However, if NULL authentication is used by only one peer (e.g. to keep his/her anonymity), then the PPK can be used by the other side. Regards, Valery. From nobody Thu Apr 6 01:35:45 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC2E12783A for ; Thu, 6 Apr 2017 01:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6DYiFYkQECV for ; Thu, 6 Apr 2017 01:35:42 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 3B411129436 for ; Thu, 6 Apr 2017 01:35:39 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id x137so22163759lff.3 for ; Thu, 06 Apr 2017 01:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=G/alpv5HupEdPhPaXXbbuw6TPAL22zMApKm6+df1nJQ=; b=WuU+P6tzJn2W5lSy9Ib0QWXzTM74wwUnfg8A6jRvzWw+t211VVjW/tMjO7i+DHzm32 bVFj/ii4K/t/6cimMcGV822BiMZ1rJyikSm8L4H+zBd6kVgd7AsWBvDUkd7DOsxZEZYT MumCWeCmM2nNQGEtwQeWYkAR8wARTpjANyi0mVupqy36LpZQZMGkfVUZwR8auFrq4hjG LllXN07waADYeag/TUVqZuULbZVO7TDOspc9kK8ZZmIm4EaPpS0IFtmB3q2zfeStQRY5 sCSpUibdVgzApJyhTb57ZTg4o1vKGQ5erSRH8qptKTb1RwYwOOulYdkyFsU8Ax5DosNh yp7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=G/alpv5HupEdPhPaXXbbuw6TPAL22zMApKm6+df1nJQ=; b=uIgLdBe1vBp8YXsfkIlus86nBJQAD7G/b1U96XwMNgvo52fl84c2+g6QY9q5brHZAO 1EQ1zYXi8VFDr2F3K/c5KGWHQ/IX8YzVgfSfSexGImZWYPU6iAmQsHtoUq93Fiuhoh78 YhP7RKTI4dVA0Kj1d6J/XrOTnrIi3srcOrwvRSOaroRv2TTuoH8kK9hKfwHN8wJhcJW/ OGXN813nzU/XQ6Qs6Tx4UdxOJqvr63Y0W2iy0n6cNSF4M9UaHUJM8j6KbNh0wua0aK7S 64lA7sdJb+ySQzmE+BSmp4jtTyDpPfiwony60Q1UrtGPSx8Y07QhxvskKvuAeo2JmICn ZYeQ== X-Gm-Message-State: AFeK/H1i234dM/g3J9Pm1IBSywgTolDeLbltTkE4tnSYB1n/XspvUOBjA2IXLeT0JxpARg== X-Received: by 10.25.29.204 with SMTP id d195mr10702829lfd.173.1491467737404; Thu, 06 Apr 2017 01:35:37 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id m2sm189452lfg.35.2017.04.06.01.35.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Apr 2017 01:35:36 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" , "'Scott Fluhrer \(sfluhrer\)'" Cc: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> In-Reply-To: <22756.60015.425330.926683@fireball.acr.fi> Date: Thu, 6 Apr 2017 11:35:20 +0300 Message-ID: <123801d2aeb0$ba4fba30$2eef2e90$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8gHZiixpAiXmKX8CUPVhmAIASlRaoFZIlPA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 08:35:44 -0000 Hi Tero, > I.e., when you configure node A for PPK use, you need to give node A > all the PPKs for all peers it has. I.e., the configuration loaded on > the node A needs to provide all PPKs it will need. If node A is mostly an initiator (e.g. a remote access client), then it knows beforehand to whom it is trying to connect. So you may provide it only with PPKs for some nodes. Then the node A will send PPK_SUPPORTED only in case it is connecting to a peer, for which the node A has a PPK. This way you may deploy PPK incrementally or partially (only to some part of the network). For responder the situation is worse. At the moment it sends PPK_SUPPORTED it doesn't know whether it has a PPK for this particular initiator. So it must be preconfigured with PPKs for all possible initiators before starting to reply with PPK_SUPPORTED. > > - We also need to specify the format of the ppk_id. This isn't that > > hard, however we did want an updated revision Real Soon Now, and > > this format doesn't feel like something I want to just slap > > together.... > > Actually for both ppk_id, and the PPK value used in the calculations, > I would suggest following: > > Both the the ppk_id inside the N(PPK_IDENTITY) and the PPK > value used in the SK_d/SK_pi/SK_pr calculations are opaque > octect streams. Implementations supporting PPK, MUST support > ppk_ids having length of less than 64 octets, and MAY support > longer ppk_id values. The PPK itself MUST have length between > 16 and 64 octets. I'd rather add a type field to ppk_id. So the ppk_id is constructed of 2 fields: type and value. Types could be: 1. raw id 2. OTF file offset 3. PPK dependent id ... For the 3rd option the ppk_id is constructed using the PPK itself and a session parameters, e.g. ppk_id = prf(PPK, Ni | Nr). This would allow the responder to check whether PPK is correct before verifying AUTH payload. In general, having a type value would simplify PPK management in case a host have PPKs of different types and need to look them up in different storages. Regards, Valery. From nobody Thu Apr 6 01:38:05 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FCA129455 for ; Thu, 6 Apr 2017 01:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4qQvc73okKj for ; Thu, 6 Apr 2017 01:38:02 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (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 8EAC112941A for ; Thu, 6 Apr 2017 01:38:01 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id z15so22193602lfd.1 for ; Thu, 06 Apr 2017 01:38:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=rHgvxD7/qz/af3Up8MXkVdshXbXH5izE0LvS1LdR220=; b=P9xQnyY3u3ZiqknaJu0cMKGBDuBJdpv9j1pOqTO/ZR5vwSfk1U/0LCPk5hlj9BqPGb OskEJTH0c2ZwtP/8wASi+vzMMEk8S3NyWmABs96NALteUEPFC9dRfrxPhsNvJUn74eqh xWF8dzx9KnZWYdw7EMsaB/giKJ3ObqZOZsBzBFc5Q7oP+e5iOg1kOnXuW+gOXI+VYFn0 B6WzuCDnYM7fZnCvmKQMXNCvQj3y5MLm48wzlJ5MN5+1MCLDwjCP2Z8b26WaWqtNEUDg AjBzfF+Gjew6KUItlgEGRskx6MzYP9voU6RCPFkJko1ingxvHi6mrUcaCfFHA1fvUozJ mOJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=rHgvxD7/qz/af3Up8MXkVdshXbXH5izE0LvS1LdR220=; b=OTEfFrocZdKPbLWkBHbL+WX3f5p0VcuCHZXlBrk8sNj6d3TtWgMUdE6h9VvIwav2TY nUyTgviqhQNxZ+xf0dXAYT0swAXRQXMMNsvH2O+dlIu0QfIAYnvW+ECUEp8k0/w6lfsR VIUpBOprHtJXx2NWvw98kBqOW2nyxD5QdxTMjvjhmHbCsWGqvlgL0yKqIAZr8hUtISg7 fxy2nTQVkDu+SP4wt89AkVhtrTDw/OmTGgxx//CrWbqE2ztYBe6uhfrnyx3S1ln9ZrnG TI3oThNs0+gg89xa/2ekuQtcu4SATahn/Xf07FE34t7EigMsn/vXs4+0YUkBCzl52Wvd nlvg== X-Gm-Message-State: AFeK/H0UXcikIgdNGCIxmJRugd8Cg+7mS8yPR886jGdNs4zKgwQuHLvOzOiy3vS0GYWNxA== X-Received: by 10.25.22.232 with SMTP id 101mr10706848lfw.133.1491467879865; Thu, 06 Apr 2017 01:37:59 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s13sm187980ljd.3.2017.04.06.01.37.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Apr 2017 01:37:59 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'Tero Kivinen'" Cc: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <8c151b63a7aa408e9e4aee3bccbeab78@XCH-RTP-006.cisco.com> In-Reply-To: <8c151b63a7aa408e9e4aee3bccbeab78@XCH-RTP-006.cisco.com> Date: Thu, 6 Apr 2017 11:37:42 +0300 Message-ID: <123f01d2aeb1$0f3df9d0$2db9ed70$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8gHZiixpAiXmKX8CUPVhmAIASlRaApi4FwWgQY5vMA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 08:38:04 -0000 Hi Scott, > The issue I was pondering was "what if the admin wants to update only part of their network (say, as a > test)?". As I understood your proposal, the PPK_SUPPORT notify was always on if any PPKs were > configured; indeed, from a responder side, it has to be that (because the responder has no other context > to issue it or not). However, from an initiator standpoint, it knows who the responder is (or, at least, it has > to; it's the one that selects which PPK to use); hence, from the initiator standpoint, the PPK_SUPPORT > notify could mean "I have a PPK that I would like to use with you, are you willing?" > > With that proviso, then partial upgrades of the network can work; if an initiator (in the upgraded portion) > talks to a responder in an nonupgraded section (or in an independently upgraded section), it just notes it > doesn't have a PPK, and so doesn't send the notify (and similarly, if it was the initiator who wasn't > upgraded, the responder performs the standard IKE protocol, and when the responder gets the identity, it > can verify whether or not it would have expected the initiator to be upgraded). > > So, how does that sound? Indeed, this a reasonable scenario. Regards, Valery. From nobody Thu Apr 6 04:57:41 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2602126557 for ; Thu, 6 Apr 2017 04:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orS9VG-vrzfM for ; Thu, 6 Apr 2017 04:57:39 -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 974C01294C3 for ; Thu, 6 Apr 2017 04:57:27 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v36BvIrT000525 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 14:57:18 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v36BvIRi020979; Thu, 6 Apr 2017 14:57:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22758.11550.179231.408958@fireball.acr.fi> Date: Thu, 6 Apr 2017 14:57:18 +0300 From: Tero Kivinen To: Paul Wouters Cc: "Scott Fluhrer \(sfluhrer\)" , "ipsec\@ietf.org" In-Reply-To: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <22756.57834.437931.308077@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 9 min Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 11:57:41 -0000 Paul Wouters writes: > On Wed, 5 Apr 2017, Tero Kivinen wrote: > > >> This is vulnerable to a DOS attack though. The attacker once inserts > >> themselves to get IDi. Then they connect to the server often enough > >> with increased offsets to fail authentication, depleting the > >> one-time-pad file for the real user, who presumbly then is locked out. > > > > Nope. Like normally you are not using the data in the file unless it > > is properly authenticated. I.e. even if the attacker can say use PPK > > from offset 0x123123, the other end will not update the offset > > 0x123123 to be used unless the other end also proofs it knows the PPK > > at that offset. > > That opens up an attack where an attacker can trick you into re-using > the same PPK many times. I was assuming that could be dangerous in > itself? If it is not, then we should clearly explain that in the > document. How? They can trick you trying to use same PPK multiple times, but all of those tries will fail and no traffic is ever transmitted protected by that PPK, thus it does not matter. It is not dangerous to use same PPK many times. My understanding is that in most cases the PPK will be static, and will not change very often. To be able to change it often, you need some kind of protocol to distribute them, and we currently do not have one yet. The reason people might want to change PPK is to limit how much data can be decrypted if someone succesfully hacks in to one of the end points. I.e., if you have used the same PPK for last year, and then someone hacks in to your machine and steals that PPK, then they can break the Diffie-Hellman for your last years worth of traffic, and decrypt it because they know the PPK. If you change your PPK every day, and make sure that you destroy old used PPKs out from the system, then hacker will only gain one days worth of traffic they can attack on by breaking the Diffie-Hellman. This means that you should zero out the part of file containing PPK you used when that PPK is no longer needed (i.e., you move to next one), so DVD full of random stuff is not very good for distributing them. The memory sticks has same problem, as you are not sure if the data has been erased securely from the stick... > > And the real user will most likely be locked out earlier because when > > the attacker starts to do several tens of million IKE connections to > > the server the server will most likely lock the user out or add > > delays to connections long before the attacker is able to deplate the > > one time pad... > > If the attacker can lock out the real user, that is also a DOS attack :) Yep, and almost all systems do it already. I.e., if you give wrong password enough times, the account is locked for some time, and at one point they might even disable it permanently. Thats why the old admin wisdom was always to create secondary admin account with different username, and make sure nobody knows what that username is, so when someone locks your "root" account you can log in with that admin account and unlock the "root"... -- kivinen@iki.fi From nobody Thu Apr 6 05:15:44 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6301294C2 for ; Thu, 6 Apr 2017 05:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iCLcs50GTobg for ; Thu, 6 Apr 2017 05:15:40 -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 A130C129473 for ; Thu, 6 Apr 2017 05:15:28 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v36CFOcH023818 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 15:15:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v36CFOB3017411; Thu, 6 Apr 2017 15:15:24 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22758.12636.210430.597736@fireball.acr.fi> Date: Thu, 6 Apr 2017 15:15:24 +0300 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" Cc: "ipsec\@ietf.org" In-Reply-To: <8c151b63a7aa408e9e4aee3bccbeab78@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <8c151b63a7aa408e9e4aee3bccbeab78@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 12:15:42 -0000 Scott Fluhrer (sfluhrer) writes: > With your idea, there are three steps (and so the admin would update > each node in the network twice): > > - Step 0 is "never use PPKs"; we're running the standard IKE protocol. > - Step 1 is "if we're the initiator, then use PPKs if the responder > signaled support for it" > "if we're the responder, then signal support, and allow the use of PPKs" > - Step 2 is "insist on PPKs (and also signal support if we're the responder)" > > The issue I was pondering was "what if the admin wants to update > only part of their network (say, as a test)?". As I understood your > proposal, the PPK_SUPPORT notify was always on if any PPKs were > configured; indeed, from a responder side, it has to be that > (because the responder has no other context to issue it or not). > However, from an initiator standpoint, it knows who the responder is > (or, at least, it has to; it's the one that selects which PPK to > use); hence, from the initiator standpoint, the PPK_SUPPORT notify > could mean "I have a PPK that I would like to use with you, are you > willing?" Yep. > With that proviso, then partial upgrades of the network can work; if > an initiator (in the upgraded portion) talks to a responder in an > nonupgraded section (or in an independently upgraded section), it > just notes it doesn't have a PPK, and so doesn't send the notify > (and similarly, if it was the initiator who wasn't upgraded, the > responder performs the standard IKE protocol, and when the responder > gets the identity, it can verify whether or not it would have > expected the initiator to be upgraded). > > So, how does that sound? Looks good. -- kivinen@iki.fi From nobody Thu Apr 6 07:00:57 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062CC12950B for ; Thu, 6 Apr 2017 07:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BLmC69aTjsa for ; Thu, 6 Apr 2017 07:00:40 -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 F0C7B129517 for ; Thu, 6 Apr 2017 07:00:26 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v36E0Gxk025946 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 Apr 2017 17:00:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v36E0Gor017129; Thu, 6 Apr 2017 17:00:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22758.18928.748975.247483@fireball.acr.fi> Date: Thu, 6 Apr 2017 17:00:16 +0300 From: Tero Kivinen To: "Valery Smyslov" Cc: "'Scott Fluhrer \(sfluhrer\)'" , In-Reply-To: <123801d2aeb0$ba4fba30$2eef2e90$@gmail.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <123801d2aeb0$ba4fba30$2eef2e90$@gmail.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 33 min Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 14:00:43 -0000 Valery Smyslov writes: > Hi Tero, > > > I.e., when you configure node A for PPK use, you need to give node A > > all the PPKs for all peers it has. I.e., the configuration loaded on > > the node A needs to provide all PPKs it will need. > > If node A is mostly an initiator (e.g. a remote access client), > then it knows beforehand to whom it is trying to connect. So you > may provide it only with PPKs for some nodes. Then the node A > will send PPK_SUPPORTED only in case it is connecting to a peer, > for which the node A has a PPK. This way you may deploy PPK > incrementally or partially (only to some part of the network). Yes, if your setup is remote access client setup. IPsec in general is host to host, thus there is no servers and clients, and connections can be created in both direction. Actually with remote access client setup, it is enough to install PPKs to the SGW first, and then start installing PPKs to the clients as needed. Each client will typically only connect to one SGW, so they will need just one PPK installed. > For responder the situation is worse. At the moment it sends PPK_SUPPORTED > it doesn't know whether it has a PPK for this particular initiator. > So it must be preconfigured with PPKs for all possible initiators > before starting to reply with PPK_SUPPORTED. Yep, or it can also use the source ip address of the incoming packet to help here. I.e., if you have site to site mesh setup for your VPN service, then each site will have static IP-addresses, and responder can see from the IP-address whether it has PPK for the other end or not. This of course does not work with the remote access clients, or even in cases where the sites do not have fixed IP-addresses (i.e., small or home office SGWs). Anyways we do not need to specify all of these cases in the specifications, those are mostly implementation details, which each implementor can specify depending on the environment their product will be working in. We just need to understand what are the limitiations with the selected method, and in this case it is that responder needs to know from the IP-address alone whether it has the PPK it can use for the incoming connection, and from that decide whether it should or should not send PPK_SUPPORTED notify. > > Actually for both ppk_id, and the PPK value used in the calculations, > > I would suggest following: > > > > Both the the ppk_id inside the N(PPK_IDENTITY) and the PPK > > value used in the SK_d/SK_pi/SK_pr calculations are opaque > > octect streams. Implementations supporting PPK, MUST support > > ppk_ids having length of less than 64 octets, and MAY support > > longer ppk_id values. The PPK itself MUST have length between > > 16 and 64 octets. > > I'd rather add a type field to ppk_id. So the ppk_id is constructed > of 2 fields: type and value. Types could be: > 1. raw id > 2. OTF file offset > 3. PPK dependent id > ... > > For the 3rd option the ppk_id is constructed using the PPK > itself and a session parameters, e.g. ppk_id = prf(PPK, Ni | Nr). > This would allow the responder to check whether PPK is correct > before verifying AUTH payload. > > In general, having a type value would simplify PPK management in case > a host have PPKs of different types and need to look them up > in different storages. That is one possibility. Should the type be 8-bit or 16-bit? I assume the registry itself should be IANA registry with designated expert review or something like that. -- kivinen@iki.fi From nobody Thu Apr 6 07:14:47 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7BDC128616 for ; Thu, 6 Apr 2017 07:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzQC3UgwHC6I for ; Thu, 6 Apr 2017 07:14:45 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 37D5112950B for ; Thu, 6 Apr 2017 07:14:38 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id j90so27047614lfk.2 for ; Thu, 06 Apr 2017 07:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=lgHzGGvE8KsZm40bS79yWGK1DxmZKsHJHauKj8HYj4M=; b=usvYUHKmbrwC72T6Kh4h/thBqbKducjnfKwo7+OoHQYEaTZEGXXfDbmO/RAcCZ1r0V dnRQ7LNzKOu3MMnmeuzouNya7NkuQNPjR2K7aqhX+HncVtzXLvKxT3gG2aoDuqpDCqsm 51fSUAi8pgKcj6Pr58LRMobkSDqk2HL09EP0CVFWpU7Sy4dWQGq/Uk6RrKoiIz3mnRJ/ tM3TQKtm5TubD2l9VSf4GApFTNtu8QA1dI/y2OvjIkmDcDcQW32/7iyLZLl3tTblmmzp WF5o6RojwkoafbTYPBV00PsrqfWXLCuw1c+mDYefsw6d1SkX/q0qrpmYv3XrFVTTaVmM 4pTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=lgHzGGvE8KsZm40bS79yWGK1DxmZKsHJHauKj8HYj4M=; b=kl6zziGuabzqpKplmHelBrxhAXiGy83zGEhxPz3pN5gD+/ogXp0zgrGKjmn7yxiKMH L/Tqhzi9oxMYyWJtlNQ2hDmp6808qz1vzh6/Pnovb1pGqHs4ZpLoKyxxOdK1PZkTczLE OWqpAa4Y5J6NWh8ntOHLtFZze8vFADs7pJo6YAIijVwtYoLjo89hlj6O3VsGGsH/Biv8 kgSv1z5A+/kXPgQE6txW6i4ZO0dXqFZ9w6Lzpn+XhJ+qjyMYBZauZF+oJy2H4BSmQqqm HVV7zCv3FrcWast5N9/t35AinHYy1NHUK/CFHTYyTd+Gx/425iNNyCg3jYrFYXyBa2mo ZZag== X-Gm-Message-State: AFeK/H2uYt/1cdNc/ekzOgqEjKtvOfQCBpVptrf3ix6udiAGVLDMfWGKcfVuaj1rn6xpJA== X-Received: by 10.25.41.209 with SMTP id p200mr11246208lfp.55.1491488076453; Thu, 06 Apr 2017 07:14:36 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e102sm372155lfi.0.2017.04.06.07.14.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Apr 2017 07:14:35 -0700 (PDT) From: "Valery Smyslov" To: "'Tero Kivinen'" Cc: "'Scott Fluhrer \(sfluhrer\)'" , References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <123801d2aeb0$ba4fba30$2eef2e90$@gmail.com> <22758.18928.748975.247483@fireball.acr.fi> In-Reply-To: <22758.18928.748975.247483@fireball.acr.fi> Date: Thu, 6 Apr 2017 17:14:19 +0300 Message-ID: <126901d2aee0$156ba850$4042f8f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8gHZiixpAiXmKX8CUPVhmAIASlRaAmtTDmEBbLGJFKA38S+g Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 14:14:47 -0000 > > I'd rather add a type field to ppk_id. So the ppk_id is constructed > > of 2 fields: type and value. Types could be: > > 1. raw id > > 2. OTF file offset > > 3. PPK dependent id > > ... > > > > For the 3rd option the ppk_id is constructed using the PPK > > itself and a session parameters, e.g. ppk_id = prf(PPK, Ni | Nr). > > This would allow the responder to check whether PPK is correct > > before verifying AUTH payload. > > > > In general, having a type value would simplify PPK management in case > > a host have PPKs of different types and need to look them up > > in different storages. > > That is one possibility. Should the type be 8-bit or 16-bit? 8 bits seems enough, but I'd rather use 16 bits so that we (hopefully) never run out of available values. > I assume the registry itself should be IANA registry with designated expert > review or something like that. Sure. From nobody Thu Apr 6 07:29:55 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31FFC129512 for ; Thu, 6 Apr 2017 07:29:54 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uktUSZVBGIUN for ; Thu, 6 Apr 2017 07:29:52 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7876312950A for ; Thu, 6 Apr 2017 07:29:48 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id 992731F8F5; Thu, 6 Apr 2017 14:29:46 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 28FC42916; Thu, 6 Apr 2017 09:29:44 -0500 (CDT) From: Michael Richardson To: "Scott Fluhrer \(sfluhrer\)" cc: Tero Kivinen , "ipsec\@ietf.org" In-reply-to: <8c151b63a7aa408e9e4aee3bccbeab78@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <8c151b63a7aa408e9e4aee3bccbeab78@XCH-RTP-006.cisco.com> Comments: In-reply-to "Scott Fluhrer (sfluhrer)" message dated "Wed, 05 Apr 2017 19:30:21 -0000." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 Apr 2017 10:29:44 -0400 Message-ID: <10929.1491488984@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 14:29:54 -0000 --=-=-= Content-Type: text/plain Scott Fluhrer (sfluhrer) wrote: > With your idea, there are three steps (and so the admin would update > each node in the network twice): > - Step 0 is "never use PPKs"; we're running the standard IKE protocol. > - Step 1 is "if we're the initiator, then use PPKs if the responder > signaled support for it" "if we're the responder, then signal support, > and allow the use of PPKs" > - Step 2 is "insist on PPKs (and also signal > support if we're the responder)" This is a pretty normal process, yet it seems that some protocol designers often do not take this in account. I wonder if we should write this down as a BCP. {the rest of what you wrote is great} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJY5lDXAAoJEJVM4Vb9/EKQ7BsH/Ahn9AjUsoNuUpBlYEBMsQOD Pn+ZHfUWDzeu6Hz0D0J1daFV3eS+yPSkL8Bae0Z258iCvKcUGYT/gDFw/in4aNzg qnR2ItUgexIIEcxEMKfhlFjwC4LrcfOc7gWR3sWJB3H5Q8Cq7AwtqK+OtVHcnft9 FTasAmm1vqAuwxglIDMlRFvCZhJSvIVH+M0dMdMb1Nwhl1/RLs1ubfc40lGDYAxf KyUHZXherDmg6FgzajBy3lSfpPTZq9YuCZ9SOz85I9Grd1dYZrlWQlX4xFqjM+cU 7Ju+XsafONpuaiymszPuOcBnmJ1/1rPnZ54ZOwGwgwQviRFryaZes4r2r3wQsjY= =kMLC -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 6 07:58:39 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67769129457 for ; Thu, 6 Apr 2017 07:58:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFMdCkoYhgrb for ; Thu, 6 Apr 2017 07:58:35 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D277128768 for ; Thu, 6 Apr 2017 07:58:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vzQnh34vDz7r; Thu, 6 Apr 2017 16:58:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491490712; bh=TsGPXKOttsgxuqxn8F9GqU6S4w/NgKB7Lg0pbGJAMQQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LAHo0lQFkIinJ8rgW1xQF0Jk3YGG2K9xDqQ/rbkNnzE8UlJCAeFWJRiuIj8FWrUXA 2ea8kKhi5zfHcG3d1gI9j5UDX9fqnsbs5uaefc5ivDRFLZTa8TZyKiOzkU1QSvtHUP lB3Tr8ztzscM0Wj/5UFbWfUQxX73wl/2m/5sK++o= 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 XS5GiS6Z3pTG; Thu, 6 Apr 2017 16:58:30 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 6 Apr 2017 16:58:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DC9FF227094; Thu, 6 Apr 2017 10:58:28 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca DC9FF227094 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C49CE406B150; Thu, 6 Apr 2017 10:58:28 -0400 (EDT) Date: Thu, 6 Apr 2017 10:58:28 -0400 (EDT) From: Paul Wouters To: Tero Kivinen cc: Valery Smyslov , ipsec@ietf.org, "'Scott Fluhrer (sfluhrer)'" In-Reply-To: <22758.18928.748975.247483@fireball.acr.fi> Message-ID: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <123801d2aeb0$ba4fba30$2eef2e90$@gmail.com> <22758.18928.748975.247483@fireball.acr.fi> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 14:58:37 -0000 On Thu, 6 Apr 2017, Tero Kivinen wrote: >> For the 3rd option the ppk_id is constructed using the PPK >> itself and a session parameters, e.g. ppk_id = prf(PPK, Ni | Nr). >> This would allow the responder to check whether PPK is correct >> before verifying AUTH payload. >> >> In general, having a type value would simplify PPK management in case >> a host have PPKs of different types and need to look them up >> in different storages. > > That is one possibility. Should the type be 8-bit or 16-bit? I assume > the registry itself should be IANA registry with designated expert > review or something like that. I wouldn't want to broadcast my type of PPK used in IKE_INIT or IKE_AUTH, as an active attacker could then learn this information. Paul From nobody Thu Apr 6 08:06:11 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026B8128768 for ; Thu, 6 Apr 2017 08:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5EL0kNFUJsJ0 for ; Thu, 6 Apr 2017 08:06:02 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48507126BF7 for ; Thu, 6 Apr 2017 08:06:02 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id j90so28126767lfk.2 for ; Thu, 06 Apr 2017 08:06:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=ijgd7dk/W2I7qKM8DHLTNlzUtmKfoTbVD3VczciSctI=; b=tXJv80yDK6ebRg4kTvoM/KJaBiMfFWyN8Jpv+zwG1dMmc1k5LXusggbDWdK2D161o+ BJMwc+fjyJyJjjl/JUzChLLaJIkUsBnWRIW3GEFbTPX9S4x4I6Ha0VRMo3yFrzfKGlrO 1Sw2xAIeX5kW7CzyPkuknH6okWYLQ6QH/2WIgHeOAMjOEF0d5icFompZk3rjOdbdVmeB jqTxd5mUbtzmEEyaBfdgqA6tL1bWBiIorbCcUHBvNQgTKiM+1PaLlthSNKJqLiDeQ6rD FAhy4gu9wwJpov17tRy3ZIv4Tv12waElDQGS1io+d5Lb3arBUO61FIQolFUjY1nXMVsu 2eFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=ijgd7dk/W2I7qKM8DHLTNlzUtmKfoTbVD3VczciSctI=; b=AcOqIS6PigEtVSVT9BHhWR39NKv1TQkammzxpaAvGImiBbWgp6ySag7B0g6Eg52cH9 ZLTrXMUu9G55ZNG9iOJcP41essQuY5ipbub1BYqJqHhlrrIBCEMtTExew/fooRc+sIQg P1eDzpqlcJx9NYgerJV0Jbom/iX3qK5no4FVOFuI3fIugVPXdb54JE4nHEI8Cg6WBVht t3oaMZ9N2WDIOSkj7uaORq5iYDRXZIEVUsnP4jZ/CXrrPJvgD8BHi6m+zMtlHCWzozb1 SAx8v2Mn76e/zRtMwcRic7k+Cgz1Fmo4WJ+HXB4ez2XAjOUtoywVsH6RTo3ImZCL3Gcu uG3Q== X-Gm-Message-State: AFeK/H07zTba/f96qVEYB0PcA4rumjdQcVpeblji0klsSQ++rHpPFCuqlr1CLiErqGgH0g== X-Received: by 10.25.19.90 with SMTP id j87mr11471202lfi.182.1491491160247; Thu, 06 Apr 2017 08:06:00 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id s15sm386482ljd.27.2017.04.06.08.05.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 06 Apr 2017 08:05:59 -0700 (PDT) From: "Valery Smyslov" To: "'Paul Wouters'" , "'Tero Kivinen'" Cc: , "'Scott Fluhrer \(sfluhrer\)'" References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <123801d2aeb0$ba4fba30$2eef2e90$@gmail.com> <22758.18928.748975.247483@fireball.acr.fi> In-Reply-To: Date: Thu, 6 Apr 2017 18:05:43 +0300 Message-ID: <127601d2aee7$438f0310$caad0930$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8gHZiixpAiXmKX8CUPVhmAIASlRaAmtTDmEBbLGJFAJHVemmoCXE1TA= Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 15:06:04 -0000 Hi Paul, > >> For the 3rd option the ppk_id is constructed using the PPK > >> itself and a session parameters, e.g. ppk_id = prf(PPK, Ni | Nr). > >> This would allow the responder to check whether PPK is correct > >> before verifying AUTH payload. > >> > >> In general, having a type value would simplify PPK management in case > >> a host have PPKs of different types and need to look them up > >> in different storages. > > > > That is one possibility. Should the type be 8-bit or 16-bit? I assume > > the registry itself should be IANA registry with designated expert > > review or something like that. > > I wouldn't want to broadcast my type of PPK used in IKE_INIT or > IKE_AUTH, as an active attacker could then learn this information. She could learn a lot of more useful information - your identity, traffic selectors, authentication method you are using, your certificates, Configuration Attributes you request, IKE features you support etc. Among all this a type of PPK is not very interesting. Use type "opaque" if you are paranoid about that. > Paul Regards, Valery. From nobody Thu Apr 6 08:37:53 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 235A4129529 for ; Thu, 6 Apr 2017 08:37: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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY_0XgIM5lST for ; Thu, 6 Apr 2017 08:37:50 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9597C129533 for ; Thu, 6 Apr 2017 08:37:48 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [75.98.19.134]) by relay.sandelman.ca (Postfix) with ESMTPS id D82071F8F5 for ; Thu, 6 Apr 2017 15:37:44 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 5A2862916; Thu, 6 Apr 2017 10:37:42 -0500 (CDT) From: Michael Richardson To: "ipsec\@ietf.org" In-reply-to: <22756.60015.425330.926683@fireball.acr.fi> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> Comments: In-reply-to Tero Kivinen message dated "Wed, 05 Apr 2017 16:00:31 +0300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 06 Apr 2017 11:37:42 -0400 Message-ID: <22016.1491493062@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 15:37:52 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > Scott Fluhrer (sfluhrer) writes: >> Going through this suggestion (and tweaking it a bit): >> >> Pluses: - I believe it can be made a bit more flexible than you make >> it out; it don't believe that you actually need to update every node >> with every PPK at the start. With this protocol, the initiator >> decides > I did not even require that. I said you need to provide all PPKs for > that one node at the same time. Or at least that I was trying to say. > I can now see that my text was bit unclear. Why do we need to provide PPKs for all peers at the same time? > Only reason why you want to enforce the PPKs to be used always, is when > you know that your attacker can already break Diffie-Hellman on real > time, and can also break your authentication method in real time. Then > you need to use PPK to protect the authentication, as if attacker is > able to break the authentication in real time, then it can also modify > the packets on the wire by removing the N(PPK_IDENTITY) or > N(PPK_SUPPORTED) notifies and disabled PPK. If the authentication (and > Diffie-Hellman) cannot be broken in real time then authentiation will > prevent attacker disabling PPK. Agreed, but I don't think this mandates that one load all the PPKs at the same time, does it? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJY5mDGAAoJEJVM4Vb9/EKQSBsH/RDzfN/XQNgOF1NaoGL6RRAr vzNilC55eaB1Xg5I/QZ6RZ+S1or1tMBPH93qO2/t+FzS+890S3KDGhSmVW9DksCl 8OgfBh58TH8DZ/LFZEhRA56hT3dLkmPrc96fB817AKmf47kCt9sVpT9FRgevY8ZQ IihR1x1C9N6n9CL1pg+33ck0W5ziDRkiqwx2eJ1JniOr0sj/jOKw/XBlhJhKhvOa 6REfpO1171HeL3l1F0m3miabtuNrBvWk8LHRydUicjzo7mFIZeMFlkUsd2mi1vJ1 NIkXPzK4n2jnTyCmDjho3yEhYnKI7HaZPlp9+ugrZE2QrZDWvxQClxDkCNyJwAM= =riCD -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 6 20:25:20 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A328E1296B3; Thu, 6 Apr 2017 20:25:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149153551261.21946.13974373567170716742@ietfa.amsl.com> Date: Thu, 06 Apr 2017 20:25:12 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 03:25:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2) Author : Yoav Nir Filename : draft-ietf-ipsecme-eddsa-02.txt Pages : 5 Date : 2017-04-06 Abstract: This document describes the use of the Edwards-curve digital signature algorithm in the IKEv2 protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-02 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-eddsa-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-eddsa-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Apr 8 22:30:49 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1CE91292D3; Sat, 8 Apr 2017 22:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQzNuyQl7tZP; Sat, 8 Apr 2017 22:30:47 -0700 (PDT) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A89A91292F4; Sat, 8 Apr 2017 22:30:46 -0700 (PDT) Received: by mail-wr0-x231.google.com with SMTP id o21so101760730wrb.2; Sat, 08 Apr 2017 22:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Weecz2Xkss4w3SecCuOFNOXc3H+qBORJzIp2KgmyLeg=; b=qj4d+5qluDdlemc2AKc3R1GTU9avIXPzfHQfIfevXnfai+7DPZ+mHx8v/kHwb+BQ1o ymZo3eLRsB5/RGpo5Z/L6AzAU2kt+h6UTYtiZOK2DPt4T2xRm0xE3ZWSViJdWE+HFjAE 6C3XhelRy5ZcTAhJGly/tQ40u1BeYjdM9ZWd6M5qLIVHFe4XvyXlLSYr8+BF+IUP1L1P op8ueZWZ2V58cLhbEgsKSZMNX0S5KmV3ilGsmtzYqKsVMWeNYYTvejXTvJ8U+Z0TsA2y IbedldX9CpZ9Qb5TM986xXHZB9MjHzxC1fITos3mgnHjKxWtAnu3OGTwNymYVjfXVUUJ ppMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Weecz2Xkss4w3SecCuOFNOXc3H+qBORJzIp2KgmyLeg=; b=rXR7gUViyzUH/XlFiGI74g1XTRjE51gS5VaPrZWJ0RZhZLROLRxnCX1bTlcZuR/dDf AHBVHA4MdAWOMF6d/Mnyp6IlDCRVMjLKd+QZrkj/c6Xpu8hNMnVpXlXScsXj7Z9CxcKt VRgP37VPYLlw0FNP8T+9ZMq/AAJpChzTrSJZOoj54a4PUJb1QdnHex1EgcenOF1W2RIm OWqc0By8LfkRiSAUsMdbA+GvcRyHkHm3zfHm9JmVHufamzbAX8QOsa8+dLuYx5y6/GNm vi65MeAB3gFZlfdkr2p/Iqrd9lVIUl5NWXxyYm91HqSapGAyog6y0XR8gKtA0KBNjzi+ o87A== X-Gm-Message-State: AN3rC/56FIDrKxweoNKJK1cNDRBjh2NxnlCIO6tgvASfETBGCax4XRVDxGYj5/fGQZIXsg== X-Received: by 10.223.151.150 with SMTP id s22mr12188988wrb.123.1491715845117; Sat, 08 Apr 2017 22:30:45 -0700 (PDT) Received: from users-mbp.mshome.net ([176.12.184.254]) by smtp.gmail.com with ESMTPSA id m14sm12283935wrb.13.2017.04.08.22.30.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 08 Apr 2017 22:30:44 -0700 (PDT) From: Yoav Nir Message-Id: <21C127DF-D0BF-4B53-B17A-7CA0E43BB6D9@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_997B9D91-E95F-4E09-8118-78F94D9B0D52"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 9 Apr 2017 08:30:40 +0300 In-Reply-To: <22756.61602.820418.641692@fireball.acr.fi> Cc: draft-ietf-ipsecme-eddsa.all@ietf.org, ipsec@ietf.org To: Tero Kivinen References: <22756.61602.820418.641692@fireball.acr.fi> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] draft-ietf-ipsecme-eddsa-01 pre-hash SHOULD NOT or MUST NOT X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 05:30:49 -0000 --Apple-Mail=_997B9D91-E95F-4E09-8118-78F94D9B0D52 Content-Type: multipart/alternative; boundary="Apple-Mail=_23635DDA-853E-407D-87AD-E56A2F494E8B" --Apple-Mail=_23635DDA-853E-407D-87AD-E56A2F494E8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Apr 2017, at 16:26, Tero Kivinen wrote: >=20 > Now the pre-hash algorithms are SHOULD NOT: >=20 > The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph > respectively) SHOULD NOT be used in IKE. >=20 > I think we could say MUST NOT be used. As it turns out they cannot be used, because the latest CURDLE draft = removed the definitions of OIDs for the pre-hashed versions. Still, = I=E2=80=99m not comfortable proscribing one algorithm in a document = about a different (although related) algorithm. How about: OLD: The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph respectively) SHOULD NOT be used in IKE. NEW: This document describes the use of the non pre-hashed versions of Ed25519 and Ed448 only. > I.e, say that pre-hash versions MUST NOT be used, and that Ed25519 and > Ed448 MUST be used with "Identity" hash identifier, and none of the > other currently defined signature algorithms MUST NOT use "Identity" > hash.. OLD: Ed25519 and Ed448 are only defined with the Identity hash, and MUST NOT be sent to a receiver that has not indicated support for the "Identity" hash. NEW: Ed25519 and Ed448 are only defined with the Identity hash, and MUST NOT be sent to a receiver that has not indicated support for the "Identity" hash. No other signature algorithm is currently defined that should use the Identity hash, so this hash MUST NOT be used with any current algorithm. > The following part of the security considerations might also need > updating: >=20 > On the other hand there is > no good reason to pre-hash the inputs where the signature algorithm > either does not require it or performs a hash internally. >=20 > This sentence would indicate that if the RSA key is large enough so we > can actually sign the full data without pre-hashing, that would be > something we would prefer. I do not think we actually want to allow > that. We should say that Identity hash identifier MUST only be used > when using signature algorithms specifically supporting it. >=20 > For this > reason implementations SHOULD have the "Identity" value in the > SIGNATURE_HASH_ALGORITHMS notification when they support EdDSA. > Implementations SHOULD NOT have other hash algorithms in the > notification if all signature algorithms have this property. >=20 > If implementation supports EdDSA then it is policy decision whether it > wants to use it, and wheter it wants ot include "Identity" as one of > the hash algorithms. How about: 3. Security Considerations The new "Identity" value is needed only for signature algorithms that accept an arbitrary-sized input. It MUST NOT be used if none of the supported and configured algorithms have this property. On the other hand there is no good reason to pre-hash the inputs where the signature algorithm has that property. For this reason implementations MUST have the "Identity" value in the SIGNATURE_HASH_ALGORITHMS notification when EdDSA is supported and configured. Implementations SHOULD NOT have other hash algorithms in the notification if all supported and configured signature algorithms have this property. > -- > kivinen@iki.fi --Apple-Mail=_23635DDA-853E-407D-87AD-E56A2F494E8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 5 Apr 2017, at 16:26, Tero Kivinen <kivinen@iki.fi> = wrote:

Now the pre-hash algorithms are SHOULD NOT:

  The pre-hashed versions of Ed25519 and Ed448 = (Ed25519ph and Ed448ph
  respectively) SHOULD = NOT be used in IKE.

I think we could say = MUST NOT be used.

As it turns out they cannot be used, because the latest = CURDLE draft removed the definitions of OIDs for the pre-hashed = versions.  Still, I=E2=80=99m not comfortable proscribing one = algorithm in a document about a different (although related) algorithm. = How about:

OLD:
   The pre-hashed versions =
of Ed25519 and Ed448 (Ed25519ph and Ed448ph
   respectively) SHOULD NOT be used in IKE.

NEW:
   This document describes the =
use of the non pre-hashed versions of 
   Ed25519 and Ed448 only.

I.e, say that pre-hash versions MUST NOT be = used, and that Ed25519 and
Ed448 MUST be used with = "Identity" hash identifier, and none of the
other = currently defined signature algorithms MUST NOT use "Identity"
hash..

OLD:
   Ed25519 and Ed448 are only defined with the =
Identity hash, and MUST
   NOT be sent to a receiver that has not indicated support for the
   "Identity" hash.

NEW:
   Ed25519 and Ed448 are only =
defined with the Identity hash, and MUST
   NOT be sent to a receiver that has not indicated support for the
   "Identity" hash. No other signature algorithm is currently =
defined
   that should use the Identity hash, so this hash MUST NOT be =
used 
   with any current algorithm.

The following part of the security = considerations might also need
updating:

=       On the other hand there = is
  no good reason to pre-hash the inputs = where the signature algorithm
  either does not = require it or performs a hash internally.

This sentence would indicate that if the RSA key is large = enough so we
can actually sign the full data without = pre-hashing, that would be
something we would prefer. I do = not think we actually want to allow
that. We should say = that Identity hash identifier MUST only be used
when using = signature algorithms specifically supporting it.

   =           =          For this
  reason implementations SHOULD have the = "Identity" value in the
=   SIGNATURE_HASH_ALGORITHMS notification when they support = EdDSA.
  Implementations SHOULD NOT have other = hash algorithms in the
  notification if all = signature algorithms have this property.

If = implementation supports EdDSA then it is policy decision whether it
wants to use it, and wheter it wants ot include "Identity" as = one of
the hash algorithms.

How = about:

3.  = Security Considerations

   The new "Identity" value is needed only for = signature algorithms that
   accept an arbitrary-sized input.  It MUST = NOT be used if none of the
   supported and configured algorithms have this = property.  On the other
   hand there is no good reason to pre-hash the = inputs where the
   signature algorithm has = that property.  For this reason
   implementations MUST have the "Identity" value = in the
   SIGNATURE_HASH_ALGORITHMS = notification when EdDSA is supported and
   configured.  Implementations SHOULD NOT = have other hash algorithms in
   the notification if all supported and configured = signature algorithms
   have this = property.


--
kivinen@iki.fi

= --Apple-Mail=_23635DDA-853E-407D-87AD-E56A2F494E8B-- --Apple-Mail=_997B9D91-E95F-4E09-8118-78F94D9B0D52 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY6ccBAAoJELhJCxUKWMyZMK0H/1h0R+9pZVzkRn/6ixHlt0/M r3/7r6qOs/utNcBVi4g4GWJl7mkaBCSq9tKPsLofEN60g/rQlOvVLnAyjnk6o6dr oMjF8TootwURPx5SC/rmuwvqZYcMpHmBE1GhQ8WisNz/nQOswaIAUJosx1mJh801 OfGLa+P+GmpQ1d1P13zs8rUenlnCvf1h7MdDWQC9HZq3g9kBzjoR0ySPHAhw7qJU /mo4RvFxvL59vmosSX3Zny4OYS9+vuxtvzxlwh7V8AXDusto574J88Z1qm645v8r T0Rqv8p8/XJ8qRrfkc6hks/9hbM+VT111MKk+L3rYW9OV5ztwNJ5NqZPlq/jxu4= =roF4 -----END PGP SIGNATURE----- --Apple-Mail=_997B9D91-E95F-4E09-8118-78F94D9B0D52-- From nobody Mon Apr 10 02:35:26 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8D6129458 for ; Mon, 10 Apr 2017 02:35: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45SEJC5cxtOt for ; Mon, 10 Apr 2017 02:35:24 -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 D422A1293DA for ; Mon, 10 Apr 2017 02:35:23 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3A9ZJSn020562 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 Apr 2017 12:35:19 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3A9ZI4H022692; Mon, 10 Apr 2017 12:35:18 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22763.20950.565834.652180@fireball.acr.fi> Date: Mon, 10 Apr 2017 12:35:18 +0300 From: Tero Kivinen To: Michael Richardson Cc: "ipsec\@ietf.org" In-Reply-To: <22016.1491493062@dooku.sandelman.ca> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <22016.1491493062@dooku.sandelman.ca> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 09:35:26 -0000 Michael Richardson writes: > > Tero Kivinen wrote: > > Scott Fluhrer (sfluhrer) writes: > >> Going through this suggestion (and tweaking it a bit): > >> > >> Pluses: - I believe it can be made a bit more flexible than you make > >> it out; it don't believe that you actually need to update every node > >> with every PPK at the start. With this protocol, the initiator > >> decides > > > I did not even require that. I said you need to provide all PPKs for > > that one node at the same time. Or at least that I was trying to say. > > I can now see that my text was bit unclear. > > Why do we need to provide PPKs for all peers at the same time? Because responder tells that PPK is supported in the IKE_SA_INIT, and then in the IKE_AUTH the initiator will either use PPK or not. If we have responder configured so that it only has some PPKs, i.e., it has PPK for node A, but not for node B, and both of those are nodes which do not have static IP-address, then it does not know whether it should send N(PPK_SUPPORTED) in IKE_SA_INIT. If it sends N(PPK_SUPPORTED) to node B, then node B might use PPK in its IKE_AUTH AUTH payload calculation, and if responder then does not have PPK it will not be able to verify the AUTH payload and IKE_AUTH fails. Of course if responder can know whether it has PPK for the initiator based on the IP-address, then it does not need to have all PPKs for all initiators that might connect to it. Simiarly if it is only acting as iniatitor, it can always decide whether to use PPK or not. But in general case it needs to know the PPKs for all peers that could connect to it using PPK before it can start sending N(PPK_SUPPORTED). -- kivinen@iki.fi From nobody Mon Apr 10 07:59:56 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773A2129532 for ; Mon, 10 Apr 2017 07:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 dhqCeCiw9qeu for ; Mon, 10 Apr 2017 07:59:54 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39D7129501 for ; Mon, 10 Apr 2017 07:59:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3833; q=dns/txt; s=iport; t=1491836393; x=1493045993; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=BRrN3HLElTwlrm2i81x5216bXQn8KsG7REiy/9gTMTg=; b=iTZa0tTz//MiPPt6VMDmRLbqPFrKF2xSmTebxj2QjL6B2lwra2Pk61Gs mqqRM8XBHz2TfqH1zQc2aNSBxLU5QsAWoDFXK164yiokkCYueTjynLrzr S0fxqXusGT8umI3PZH3XIDWODgAFBfdP5YFyPnw7mqC4uMz73IgkD9yfe E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BAAQAjnetY/5BdJa1TAQkaAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGDU4FsB41ykUeVV4IPhiQCg2A/GAECAQEBAQEBAWsdC4UVAQEFOks?= =?us-ascii?q?EAgEIEQQBAR8QMh0IAgQRAgiKB6soimMBAQEBAQEEAQEBAQEjhlCEcIQuARqFc?= =?us-ascii?q?gWcewGKKoglggiPQkiIG4scAR84gQVbFYUZH4FjQzKHIgIFH4EKgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.37,182,1488844800"; d="scan'208";a="409110059" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2017 14:59:53 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3AExqC3028961 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 10 Apr 2017 14:59:52 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 10 Apr 2017 10:59:52 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Mon, 10 Apr 2017 10:59:52 -0400 From: "Scott Fluhrer (sfluhrer)" To: "ipsec@ietf.org" Thread-Topic: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing Thread-Index: AQHSqOHRXsYj5uYL3E2R1gdN4nkGdaGz0xSwgAGjdQD//9ugUIABuFeAgAAf4QCAB5Wj0A== Date: Mon, 10 Apr 2017 14:59:52 +0000 Message-ID: <541c1bc709fe4384b6f3e431ba08b715@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 14:59:55 -0000 I've been putting together the updates, and one question came up: what form= at should the PPK_ID field (sent be the initiator in the first encrypted me= ssage to identify the PPK it used) be? I'm thinking that an arbitrary octet string would be appropriate; it can be= distributed at the same time as the PPK data itself. In addition, one thing that we do not want to interfer with extensions to t= his proposal; for example, the discussed extension that pulls the PPKs from= a 1G one-time pad file. I believe that concept could work here; in that c= ase, the ID field would be just the PPK index (and both sides would underst= and that extension). I don't believe that IKE currently makes any assumptions that notification = data is a multiple of 4 bytes in length; is that correct? Is there anything I missed? > -----Original Message----- > From: Scott Fluhrer (sfluhrer) > Sent: Wednesday, April 05, 2017 3:30 PM > To: 'Tero Kivinen' > Cc: ipsec@ietf.org > Subject: RE: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing >=20 > Ok, I now see what part of your idea I was (sort of) trying to work aroun= d. To > make it clear to everyone, I'll spell out the problem we're trying to add= ress, > and how your idea (with a slight addition on my part) could address it. >=20 > What we're talking about is "how would someone take a network that's usin= g > the standard IKE implementation, and convert it into a network that uses > IKE+PPKs, and in a way that doesn't cause a flag day, or prevent negotiat= ions > from happening between nodes while the upgrade is in progress. >=20 > The idea is that the network admin goes through the nodes, and upgrades > them in order; in step 0, the nodes are running standard IKE, and in the = final > step, they are running the full PPK protocol (and insist on using it). F= or the > upgrade to be bumpless, we require that any node at step i be able to > communicate (as either initiator or responder) with a node at step i-1, i= or i+1 > (assuming, of course, that our security policy allows those two nodes to > communicate). >=20 > With your idea, there are three steps (and so the admin would update each > node in the network twice): >=20 > - Step 0 is "never use PPKs"; we're running the standard IKE protocol. > - Step 1 is "if we're the initiator, then use PPKs if the responder signa= led > support for it" > "if we're the responder, then signal support, and allow the use of PP= Ks" > - Step 2 is "insist on PPKs (and also signal support if we're the respond= er)" >=20 >=20 > The issue I was pondering was "what if the admin wants to update only par= t > of their network (say, as a test)?". As I understood your proposal, the > PPK_SUPPORT notify was always on if any PPKs were configured; indeed, > from a responder side, it has to be that (because the responder has no ot= her > context to issue it or not). However, from an initiator standpoint, it k= nows > who the responder is (or, at least, it has to; it's the one that selects = which > PPK to use); hence, from the initiator standpoint, the PPK_SUPPORT notify > could mean "I have a PPK that I would like to use with you, are you willi= ng?" >=20 > With that proviso, then partial upgrades of the network can work; if an > initiator (in the upgraded portion) talks to a responder in an nonupgrade= d > section (or in an independently upgraded section), it just notes it doesn= 't > have a PPK, and so doesn't send the notify (and similarly, if it was the = initiator > who wasn't upgraded, the responder performs the standard IKE protocol, > and when the responder gets the identity, it can verify whether or not it > would have expected the initiator to be upgraded). >=20 >=20 > So, how does that sound? From nobody Mon Apr 10 08:16:02 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2581242F7 for ; Mon, 10 Apr 2017 08:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8D94Bl0V3ZJx for ; Mon, 10 Apr 2017 08:15:59 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 0F63412952C for ; Mon, 10 Apr 2017 08:15:58 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id 75so12841444lfs.2 for ; Mon, 10 Apr 2017 08:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=50JQwE6o0D3mEZkON1u5uwumQcq+MXjMXeBQ1Dl3Nks=; b=JnK2qXwQWGZsdlhz4wyFecI+2u6NfjlUS0SkzoZS4gaMuOaPWLYORP6JgfO3t2XoJs tmlBaoLO2FPPtZCqMpTtK/j3aHgvau/5Pp1gHXUzZMBBJ+BYXHFIr+POrbEHObuxuDAe iphb8WMRBS7QnLAr2nTj4a1df+SEWHikVZBCx6Yp41wPZgGo3AzM1KI6gAxWk0l4U616 7S10bHnp324yK1z7LRBD5jgGjJQNSPjY5G80UmMBUX2KPYY4JDSPSUy+8Qsc7HqSQemU MIpbBodvsLxOSAmPCeGrhGPb4WMNEQkTuLMIynIkoA8k9KFa4LHKiVnAJGMytKAumZVC p7Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=50JQwE6o0D3mEZkON1u5uwumQcq+MXjMXeBQ1Dl3Nks=; b=CxGB/McK7PQsj0mx9+PWeHV3uXqEljjX2zZSvWLgSEHd4iPKYj/8EGOeaxx93tM1s5 uFB5xmaj1PbpppfnmqV3Ha8xDsxbnfHy09dq4aRhfdTLb/4booO//L8ICkthP/C5+aei T5gX4Rn+wCItBgJ5UonhnofsRmQ735/YqS4xskDixAoz58wV8T6d81l/jtYNB4ftMPoB pvTYNn/Jon8WyzuCXj2pT+O/TdooM+3f9P7pt62/qayFXdi6aHW13MhcjrRSV8ucT6Bn DdiKOVUpj7VW6n9lOv74effscBD6eSLL0RUqM4u1kGHgy9Vn0MZ3mUD7KEXNA4EZMShR LtYw== X-Gm-Message-State: AFeK/H1kiC3z7dioGsW3u0c+U03BgxLwa8zis+StqZE85fOktlT4eGOQeFLaqm7ovcYo8w== X-Received: by 10.46.9.9 with SMTP id 9mr15324146ljj.89.1491837356102; Mon, 10 Apr 2017 08:15:56 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id v30sm2930293ljd.65.2017.04.10.08.15.55 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Apr 2017 08:15:55 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <541c1bc709fe4384b6f3e431ba08b715@XCH-RTP-006.cisco.com> In-Reply-To: <541c1bc709fe4384b6f3e431ba08b715@XCH-RTP-006.cisco.com> Date: Mon, 10 Apr 2017 18:15:54 +0300 Message-ID: <14b301d2b20d$59a525c0$0cef7140$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8gHZiixpAiXmKX8CUPVhmAIASlRaAwBL16ugRQiRAA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 15:16:01 -0000 Hi Scott, > I've been putting together the updates, and one question came up: what format should the PPK_ID field > (sent be the initiator in the first encrypted message to identify the PPK it used) be? > > I'm thinking that an arbitrary octet string would be appropriate; it can be distributed at the same time as > the PPK data itself. > > In addition, one thing that we do not want to interfer with extensions to this proposal; for example, the > discussed extension that pulls the PPKs from a 1G one-time pad file. I believe that concept could work > here; in that case, the ID field would be just the PPK index (and both sides would understand that > extension). I think that it's worth to add an indication of the type of PPK_ID. I.e. the PPK_ID should consist of two fields - PPK_ID type (16 bits, managed by IANA) and PPK_ID data. That would make PPK management a bit easier - the responder would know where to look PPK for. > I don't believe that IKE currently makes any assumptions that notification data is a multiple of 4 bytes in > length; is that correct? IKEv2 makes no such assumption - notification data can be of any length. Regards, Valery. > Is there anything I missed? > > > > -----Original Message----- > > From: Scott Fluhrer (sfluhrer) > > Sent: Wednesday, April 05, 2017 3:30 PM > > To: 'Tero Kivinen' > > Cc: ipsec@ietf.org > > Subject: RE: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing > > > > Ok, I now see what part of your idea I was (sort of) trying to work around. To > > make it clear to everyone, I'll spell out the problem we're trying to address, > > and how your idea (with a slight addition on my part) could address it. > > > > What we're talking about is "how would someone take a network that's using > > the standard IKE implementation, and convert it into a network that uses > > IKE+PPKs, and in a way that doesn't cause a flag day, or prevent negotiations > > from happening between nodes while the upgrade is in progress. > > > > The idea is that the network admin goes through the nodes, and upgrades > > them in order; in step 0, the nodes are running standard IKE, and in the final > > step, they are running the full PPK protocol (and insist on using it). For the > > upgrade to be bumpless, we require that any node at step i be able to > > communicate (as either initiator or responder) with a node at step i-1, i or i+1 > > (assuming, of course, that our security policy allows those two nodes to > > communicate). > > > > With your idea, there are three steps (and so the admin would update each > > node in the network twice): > > > > - Step 0 is "never use PPKs"; we're running the standard IKE protocol. > > - Step 1 is "if we're the initiator, then use PPKs if the responder signaled > > support for it" > > "if we're the responder, then signal support, and allow the use of PPKs" > > - Step 2 is "insist on PPKs (and also signal support if we're the responder)" > > > > > > The issue I was pondering was "what if the admin wants to update only part > > of their network (say, as a test)?". As I understood your proposal, the > > PPK_SUPPORT notify was always on if any PPKs were configured; indeed, > > from a responder side, it has to be that (because the responder has no other > > context to issue it or not). However, from an initiator standpoint, it knows > > who the responder is (or, at least, it has to; it's the one that selects which > > PPK to use); hence, from the initiator standpoint, the PPK_SUPPORT notify > > could mean "I have a PPK that I would like to use with you, are you willing?" > > > > With that proviso, then partial upgrades of the network can work; if an > > initiator (in the upgraded portion) talks to a responder in an nonupgraded > > section (or in an independently upgraded section), it just notes it doesn't > > have a PPK, and so doesn't send the notify (and similarly, if it was the initiator > > who wasn't upgraded, the responder performs the standard IKE protocol, > > and when the responder gets the identity, it can verify whether or not it > > would have expected the initiator to be upgraded). > > > > > > So, how does that sound? > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Apr 10 09:54:17 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A30C8129544 for ; Mon, 10 Apr 2017 09:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9S38kLwQDQk9 for ; Mon, 10 Apr 2017 09:54:12 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F28C31294EF for ; Mon, 10 Apr 2017 09:54:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w1x9C1NV3zDZT; Mon, 10 Apr 2017 18:54:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491843247; bh=BwBq5sAhuKPo0h5dNILB+1IrU1Ks651xY6toa6VU8pM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=TAOju+fprJzB9ZPuYcr9I/DHIx3sdQDM7pJS1336kzhZH8ser6YnAG1e2alOC7CCJ tOuV/5D/vsqpCslkyWNSRe7UrE5kXwzHJs+SIBMUTyZ+KoNQ1GjBTApKtm2Uwjay5m YLhItXgT4vfkzw5rNXcCR2A0XNxMy4rEiz9WIYZ4= 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 5lGjQQ49W5wA; Mon, 10 Apr 2017 18:54:06 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 10 Apr 2017 18:54:06 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 87CDF418518; Mon, 10 Apr 2017 12:54:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 87CDF418518 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 800EC40D3585; Mon, 10 Apr 2017 12:54:05 -0400 (EDT) Date: Mon, 10 Apr 2017 12:54:05 -0400 (EDT) From: Paul Wouters To: Valery Smyslov cc: "ipsec@ietf.org WG" In-Reply-To: <14b301d2b20d$59a525c0$0cef7140$@gmail.com> Message-ID: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <541c1bc709fe4384b6f3e431ba08b715@XCH-RTP-006.cisco.com> <14b301d2b20d$59a525c0$0cef7140$@gmail.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 16:54:15 -0000 On Mon, 10 Apr 2017, Valery Smyslov wrote: > I think that it's worth to add an indication of the type of PPK_ID. I.e. the PPK_ID should consist of > two fields - PPK_ID type (16 bits, managed by IANA) and PPK_ID data. That would make PPK > management a bit easier - the responder would know where to look PPK for. Sounds good to me. Paul From nobody Tue Apr 11 07:47:52 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19405129529 for ; Tue, 11 Apr 2017 07:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 81OIW-RkgW8E for ; Tue, 11 Apr 2017 07:47:49 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A85231294F4 for ; Tue, 11 Apr 2017 07:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1127; q=dns/txt; s=iport; t=1491922069; x=1493131669; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5KijorM68DFBzfmC5JUIYOipbQGvdiIIkKt9CB/NtJw=; b=kiahK14mTJKVbRGHkM8nW1RtTf2lttdfiqlWfF7w2eP1D2b02tzjB/3U 9kMeYvcoNVTgh845s8oqArA30IxKPNA88XWRNQ1z+EAH2a9icHO9PRbEr DIyq+g9fncIlYFwtLaimH/Zh7NiJjyTOs7/4i/9nFBQ+SjRS/W1VJbjuG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAQBf6+xY/5BdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1NhgQsHjXKRTZVYgg8hC4V4AoNhPxgBAgEBAQEBAQFrKIUVAQE?= =?us-ascii?q?BAQIBAQE4NAsFBwQCAQgRBAEBAR4JBycLFAkIAgQBDQUIigAIDqsvin4BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEYBYZQhHCEKBEBhgEFnH8BklSRTUiTOAEfOH0IWxV?= =?us-ascii?q?BhFscgWN1hyeBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.37,186,1488844800"; d="scan'208";a="410690261" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Apr 2017 14:47:48 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v3BElmVO004725 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 11 Apr 2017 14:47:48 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 11 Apr 2017 10:47:47 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Tue, 11 Apr 2017 10:47:48 -0400 From: "Scott Fluhrer (sfluhrer)" To: Paul Wouters , Valery Smyslov CC: "ipsec@ietf.org WG" Thread-Topic: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing Thread-Index: AQHSqOHRXsYj5uYL3E2R1gdN4nkGdaGz0xSwgAGjdQD//9ugUIABuFeAgAAf4QCAB5Wj0IAAS/cAgAAbb4CAASs8AA== Date: Tue, 11 Apr 2017 14:47:47 +0000 Message-ID: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <541c1bc709fe4384b6f3e431ba08b715@XCH-RTP-006.cisco.com> <14b301d2b20d$59a525c0$0cef7140$@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:47:51 -0000 Paul, on a previous email, you wrote: > I wouldn't want to broadcast my type of PPK used in IKE_INIT or IKE_AUTH,= as an active attacker could then learn this information. I believe it was in this context; did you change your mind? If everyone is OK with a PPK_ID type. If everyone is, I'll put that into t= he draft... > -----Original Message----- > From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Wouters > Sent: Monday, April 10, 2017 12:54 PM > To: Valery Smyslov > Cc: ipsec@ietf.org WG > Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing >=20 > On Mon, 10 Apr 2017, Valery Smyslov wrote: >=20 > > I think that it's worth to add an indication of the type of PPK_ID. > > I.e. the PPK_ID should consist of two fields - PPK_ID type (16 bits, > > managed by IANA) and PPK_ID data. That would make PPK management a > bit easier - the responder would know where to look PPK for. >=20 > Sounds good to me. >=20 > Paul >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Apr 11 07:54:53 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561C512E855 for ; Tue, 11 Apr 2017 07:54:52 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3eiO6XPJ2cc for ; Tue, 11 Apr 2017 07:54:49 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 712CC129C52 for ; Tue, 11 Apr 2017 07:54:49 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w2VT21xkMz1kD; Tue, 11 Apr 2017 16:54:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1491922486; bh=qUzOFyGJcoEvD693XhY1UFjxySynOmlT80/OotpnhSg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=SZ1sgyNSoEU/NSP+E1KTvAuVUIN7iAti0Irynp01lDysk1WbGfMqeVfLV9sYd76aF wfYpV/8sGHqzHnd+ofcja98n5rd7vcAGgZDscU+0I64z5xIFPfEDGJH2x8bwTeBynz q+56lUu8PerN1mtWg4309CHBJKARjzKsTxJcDK/s= 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 fYwHps4uZjRr; Tue, 11 Apr 2017 16:54:44 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 11 Apr 2017 16:54:43 +0200 (CEST) Received: from [193.111.228.71] (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id ED80E418516; Tue, 11 Apr 2017 10:54:42 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca ED80E418516 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14E304) In-Reply-To: Date: Tue, 11 Apr 2017 10:54:42 -0400 Cc: Valery Smyslov , "ipsec@ietf.org WG" Content-Transfer-Encoding: quoted-printable Message-Id: <2D3370B2-2916-4DAE-A93D-3947C639C1E6@nohats.ca> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <541c1bc709fe4384b6f3e431ba08b715@XCH-RTP-006.cisco.com> <14b301d2b20d$59a525c0$0cef7140$@gmail.com> To: "Scott Fluhrer (sfluhrer)" Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:54:52 -0000 As long as there is an opaque type in the list of types, everyone can reveal= as much as they are comfortable with. Paul Sent from my iPhone > On Apr 11, 2017, at 10:47, Scott Fluhrer (sfluhrer) w= rote: >=20 > Paul, on a previous email, you wrote: >=20 >> I wouldn't want to broadcast my type of PPK used in IKE_INIT or IKE_AUTH,= as an active attacker could then learn this information. >=20 > I believe it was in this context; did you change your mind? >=20 > If everyone is OK with a PPK_ID type. If everyone is, I'll put that into t= he draft... >=20 >> -----Original Message----- >> From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Wouters >> Sent: Monday, April 10, 2017 12:54 PM >> To: Valery Smyslov >> Cc: ipsec@ietf.org WG >> Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing >>=20 >>> On Mon, 10 Apr 2017, Valery Smyslov wrote: >>>=20 >>> I think that it's worth to add an indication of the type of PPK_ID. >>> I.e. the PPK_ID should consist of two fields - PPK_ID type (16 bits, >>> managed by IANA) and PPK_ID data. That would make PPK management a >> bit easier - the responder would know where to look PPK for. >>=20 >> Sounds good to me. >>=20 >> Paul >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Apr 11 07:55:15 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F29012E8FA; Tue, 11 Apr 2017 07:55:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Wesley Eddy To: Cc: ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149192250152.15649.6637923996602707175@ietfa.amsl.com> Date: Tue, 11 Apr 2017 07:55:01 -0700 Archived-At: Subject: [IPsec] Tsvart last call review of draft-ietf-ipsecme-tcp-encaps-09 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 14:55:02 -0000 Reviewer: Wesley Eddy Review result: On the Right Track This document is clear and well-written. It can easily be implemented based on the description. There are a few additional issues that should be considered with advice to implementers in Section 12 on performance considerations: 1) Invisibility of packet loss - Inner protocols that require packet losses as a signal of congestion (e.g. TCP) will have a challenge due to not being able to see any packet losses since the outer TCP will repair them (unless sending into a full outer TCP socket buffer shows up back to the inner TCP as a packet loss?). 2) Nesting of ECN - Inner TCP connections will not be able to use effectively ECN on the portion of the path covered by the outer TCP connection. 3) Impact of congestion response on aggregate - The general "TCP in TCP" problem is mentioned, and is mostly appropriate for a single flow. If an aggregate of flows is sharing the same outer TCP connection, there may be additional concerns about how the congestion response behavior impacts an aggregate of flows, since it may cause a shared delay spike even to low-rate flows rather than distributing losses proportional to per-flow throughput. 4) Additional potential for bufferbloat - Since TCP does not bound latency, some applications in the IPsec-protected aggregate could drive latency of the shared connection up and impact the aggregate of flows that may include real-time applications. The socket buffer for the outer TCP connection might need to be limited in size to ensure some bounds? Not addressing these could lead to poor experiences in deployment, if implementations make wrong assumptions or fail to consider them. In the security considerations section, there are several RFCs on mechanisms to increase robustness to RST attacks and SYN floods that could be mentioned if it's worthwhile. From nobody Tue Apr 11 18:16:43 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FCF1242F5; Tue, 11 Apr 2017 18:16:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Mahesh Jethanandani To: Cc: ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149195980204.15766.15879884431822692645@ietfa.amsl.com> Date: Tue, 11 Apr 2017 18:16:42 -0700 Archived-At: Subject: [IPsec] Opsdir telechat review of draft-ietf-ipsecme-tcp-encaps-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 01:16:42 -0000 Reviewer: Mahesh Jethanandani Review result: Ready I have reviewed this document as part of the Operational directorate’s ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments. Document reviewed:  draft-ietf-ipsecme-tcp-encaps-09 Summary: This document defines a method for encapsulating both the IKE control messages as well as the IPSec data messages within a TCP connection. Document Status: Ready. Comments: The following comments look at the document both from an operational perspective as well as a management perspective. Operational Considerations: Operational considerations include installation and initial setup, migration path, requirements on other protocols, impact on network operations and verification of correct operation. The document has adequately addressed issues related to initial setup, migration path from using UDP over port 500, to port 4500 to using TCP. Management Considerations: Management considerations include interoperability, fault management, configuration management, accounting, performance and security. Already acknowledged that there is performance impact in carrying IKE and IPSec data messages over TCP. This includes limitation of message lengths to UDP datagram ESP payload lengths, further impacting the performance of the encapsulation method. Document talks about reconfiguration of TCP encapsulation on both the TCP Originator and TCP Responder. That includes configuration of ports the Responder will listen on. A run of idnits returns the following warnings: (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Appendix A' is mentioned on line 305, but not defined == Missing Reference: 'Section 4' is mentioned on line 363, but not defined == Missing Reference: 'ChangeCipherSpec' is mentioned on line 922, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 765, but not defined == Missing Reference: 'CERT' is mentioned on line 770, but not defined == Missing Reference: 'CP' is mentioned on line 814, but not defined Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). From nobody Wed Apr 12 13:52:43 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165F31294B2 for ; Wed, 12 Apr 2017 13:52:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.523 X-Spam-Level: X-Spam-Status: No, score=-14.523 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 0UUPG6SvPTIq for ; Wed, 12 Apr 2017 13:52:40 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9822512778E for ; Wed, 12 Apr 2017 13:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1581; q=dns/txt; s=iport; t=1492030360; x=1493239960; h=from:to:cc:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=NuG+rmSDGcf2AnWE13qqGztACbEZ+/jCJ01N31gAlZw=; b=R5LHbom3dgBrT+AIpQJw70RPec45M9FvONVsMfRf7YG+eq7FR/vQ4+AV 1qW8hvRwdRY5xoFW+YsNEWlzrPE0Wqayr5SRkiRu05PbAtsZIikgFSZAL XljgYJu9YQudl+CXC6N7DJ4rjgB5Q6OWCzlMtOPh/Vey0gx2d8zKGzxw1 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAwAWk+5Y/5pdJa1cGgEBAQECAQEBA?= =?us-ascii?q?QgBAQEBg1OBc7Ufgg+GJIQDQRYBAgEBAQEBAQFrKIUWBjo/EAIBCDYQMiUCBA4?= =?us-ascii?q?Nig6rdosQAQEBAQEBAQEBAQEBAQEBASKGUYFdgxeEM4YIBZ0KAZJXggiFLooXS?= =?us-ascii?q?JM5ASYKJ4EFWxWFGx2BY4dbgS+BDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,191,1488844800"; d="scan'208";a="235217629" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Apr 2017 20:52:39 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3CKqdmo018854 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Apr 2017 20:52:39 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 16:52:39 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Wed, 12 Apr 2017 16:52:39 -0400 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen CC: "ipsec@ietf.org" Thread-Topic: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing Thread-Index: AQHSqOHRXsYj5uYL3E2R1gdN4nkGdaGz0xSwgAGjdQD//9ugUIABuFeAgAAf4QCACx3aQA== Date: Wed, 12 Apr 2017 20:52:39 +0000 Message-ID: <10130bc78c68427eab68895806a87fdc@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 20:52:42 -0000 I've been pondering another question, and I think I'll bring it up before f= inalizing the next version of the draft. After the WG meeting, we (Tero and myself) met in the hallway and had a lit= tle chat. One of the things that I took away from it (and please correct m= e if I was wrong) was that you thought that it was important that the PPK i= tself was potentially equidistributed; for example, if it was 256 bits long= , then all possible 256 bit values were representable; after all, we are ha= ndling it the PRF as a key. On this basis, you suggested that the PPK be e= ncoded in Base64 (and converted into binary by each endpoint). Now, for the specific PRFs standardized in IKE, it's not actually that impo= rtant that all bit patterns be possible. Currently, the PRFs defined are H= MAC of various hash functions, and XCBC/CMAC (which aren't quantum safe). = The HMAC PRFs do not actually need to make the assumption that the key is e= quidistributed; it is sufficient that there are at least 2**256 possible PP= Ks (which can be ensured by simply allowing the PPK to be long enough). It would certainly be simpler to say "take the PPK as an ASCII string, and = hand it off to the PRF as the key", and skip the Base64 conversion; we migh= t want to suggest a limit on the alphabet of the PPK (as not all implementa= tion like things with, say, spaces, in them), however that's not a serious = suggestion. On the other hand, it does rather assume that any future PRF will also work= well with a non-evenly distributed key. Thoughts? From nobody Wed Apr 12 18:48:02 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7C6129468 for ; Wed, 12 Apr 2017 18:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aQBLrWVj-Bs for ; Wed, 12 Apr 2017 18:47:58 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32D01286B1 for ; Wed, 12 Apr 2017 18:47:58 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w3NwB6pRvz75w; Thu, 13 Apr 2017 03:47:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1492048074; bh=acHQajw1aW17XM39BjVhWFDM7ufVJuuB7GiAS1IPHW0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=u5GlCSXQIjcrn7gVQjse6NZvVHV+hLYScmojWgrCrji8Pu0L+fYzlXkxMq/QKsbO4 +EPgrgh7e0RNy4SFp4iQhRr+lnt4ov6/9nWCOBf9cFYG3xsPBwxlDMc+Tv3hhw0nyb PxzgTDlSV96kTopRDRyY1EG2HLweeQNQLSz8tbEc= 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 oFWBqNQNqCpg; Thu, 13 Apr 2017 03:47:53 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 13 Apr 2017 03:47:52 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8835B3531DF; Wed, 12 Apr 2017 21:47:51 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8835B3531DF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 71BF840DAA4B; Wed, 12 Apr 2017 21:47:51 -0400 (EDT) Date: Wed, 12 Apr 2017 21:47:51 -0400 (EDT) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" cc: Tero Kivinen , "ipsec@ietf.org" In-Reply-To: <10130bc78c68427eab68895806a87fdc@XCH-RTP-006.cisco.com> Message-ID: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <10130bc78c68427eab68895806a87fdc@XCH-RTP-006.cisco.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 01:48:00 -0000 On Wed, 12 Apr 2017, Scott Fluhrer (sfluhrer) wrote: > It would certainly be simpler to say "take the PPK as an ASCII string, and hand it off to the PRF as the key", and skip the Base64 conversion; we might want to suggest a limit on the alphabet of the PPK (as not all implementation like things with, say, spaces, in them), however that's not a serious suggestion. I would prefer not to add limitations to the byte stream. If someone is using an actual quantum computer entangled source, that might require additional post processing to convert it to a reduced ascii set. For our implementation, we already use a prefix to denote the type of encoding used for PSKs. And for OTP's in particular, I really do expect to point to an actual raw binary file, so needing to convert that to ascii would actually be making more work for us to implement. It would also make referring to "the offset" a little weird. Is this the number of converted-to-ascii bytes or the raw bytes offset? Paul From nobody Wed Apr 12 20:11:11 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D18C0127B73 for ; Wed, 12 Apr 2017 20:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 bF8gUUfHq0fA for ; Wed, 12 Apr 2017 20:11:08 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 739A4128D3E for ; Wed, 12 Apr 2017 20:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2526; q=dns/txt; s=iport; t=1492053068; x=1493262668; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=SlA9oJo6x9AQ3Sa4KWPaTLS6a/r8piH/4PLL3WOo15Q=; b=C4iCCt/gFa8bPW4G/Hf9dbZXA9fKcgXzQSlaekYRBzd2F057Rfn6zh2l XSy83bbPyJ4xXmsfQgvLwenVE8Lt5ATjgay2zTPH4C1Vb/2UOp61g+zc4 xl9ae82PBKespxws0HzQmqnF6+sFhpx2XjxcQ7iTyvi52IS93+XwiUJZU 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAQDx6u5Y/4UNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1OBbAeNcpFVlVmCD4YkAoQCPxgBAgEBAQEBAQFrKIUVAQEBAQI?= =?us-ascii?q?BOj8MBAIBCBEEAQEBHgkHMhQJCAIEDgUIigYIrBqLEwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2GUYR0hDOGCAWdCgGSV5FNSJM5AR84gQVbFYUZH4FjdYZmgS+BDQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.37,193,1488844800"; d="scan'208";a="411419585" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Apr 2017 03:11:08 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3D3B7jO022450 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Apr 2017 03:11:07 GMT Received: from xch-rtp-006.cisco.com (64.101.220.146) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 12 Apr 2017 23:11:06 -0400 Received: from xch-rtp-006.cisco.com ([64.101.220.146]) by XCH-RTP-006.cisco.com ([64.101.220.146]) with mapi id 15.00.1210.000; Wed, 12 Apr 2017 23:11:06 -0400 From: "Scott Fluhrer (sfluhrer)" To: Paul Wouters CC: Tero Kivinen , "ipsec@ietf.org" Thread-Topic: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing Thread-Index: AQHSqOHRXsYj5uYL3E2R1gdN4nkGdaGz0xSwgAGjdQD//9ugUIABuFeAgAAf4QCACx3aQIAAmPuA///Qp+A= Date: Thu, 13 Apr 2017 03:11:06 +0000 Message-ID: <6c03477dff2045b0948d734a9d3b01ac@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <10130bc78c68427eab68895806a87fdc@XCH-RTP-006.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 03:11:10 -0000 > -----Original Message----- > From: Paul Wouters [mailto:paul@nohats.ca] > Sent: Wednesday, April 12, 2017 9:48 PM > To: Scott Fluhrer (sfluhrer) > Cc: Tero Kivinen; ipsec@ietf.org > Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing >=20 > On Wed, 12 Apr 2017, Scott Fluhrer (sfluhrer) wrote: >=20 > > It would certainly be simpler to say "take the PPK as an ASCII string, = and > hand it off to the PRF as the key", and skip the Base64 conversion; we mi= ght > want to suggest a limit on the alphabet of the PPK (as not all implementa= tion > like things with, say, spaces, in them), however that's not a serious > suggestion. >=20 > I would prefer not to add limitations to the byte stream. If someone is u= sing > an actual quantum computer entangled source, that might require additiona= l > post processing to convert it to a reduced ascii set. I wasn't nearly as clear as I ought to have been; I made some assumptions w= ithout stating them. There are, of course, multiple possible PPK sources; one is a preconfigured= fixed value in the device; another might be values from a CD-ROM (as other= s discussed elsethread); still another might be a quantum key distribution = device. My discussion was solely about the preconfigured fixed value, and I was jus= t talking about the mapping between 'fixed value' and 'the PPK value you ha= nd to the PRF'; this fixed value will likely be configured as a string (sim= ilar to a standard preshared key), my question was the mapping of this stri= ng to a PPK value. Now, obviously, there will be other methods of generating PPKs; for those a= lternative methods, they will likely generate large (256 bit or so) uniform= random value; there may be no particular reason to impose any nontrivial m= apping there. Obviously, talking about ASCII in that context may make no s= ense whatsoever. I don't intend to talk about these alternative methods di= rectly in the draft (except to provide a hook to add them later). Does that clarify things? >=20 > For our implementation, we already use a prefix to denote the type of > encoding used for PSKs. And for OTP's in particular, I really do expect t= o point > to an actual raw binary file, so needing to convert that to ascii would a= ctually > be making more work for us to implement. >=20 > It would also make referring to "the offset" a little weird. Is this the = number > of converted-to-ascii bytes or the raw bytes offset? >=20 > Paul From nobody Wed Apr 12 20:38:32 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96613124D37 for ; Wed, 12 Apr 2017 20:38:24 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq78MJtQndB7 for ; Wed, 12 Apr 2017 20:38:22 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FD7127B73 for ; Wed, 12 Apr 2017 20:38:17 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w3RMT3zFZz33H; Thu, 13 Apr 2017 05:38:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1492054693; bh=2kWod+vXaZPXnkbf96njCwhTOWUzFTMHV0l6w6jnXxk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FemCq4leziK0nZqUDw//hz4cbZ0vXKPnQ/k4lnTVzUs1NKhTuu1gYgIhE8sI66Wx6 Zwxcl3NeInXEEbaN5ayUyLcqG6ZoJcgykS3s/BhnrQGa/Ozz5fjF09b8UwEv+lwXOn boo2N+/9ub1Ef4D2CJ9Ap8Ygk4zXYme5wBuHX0jU= 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 srMQnhCIKZM6; Thu, 13 Apr 2017 05:38:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 13 Apr 2017 05:38:10 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D564C3531DF; Wed, 12 Apr 2017 23:38:09 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D564C3531DF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C013F4161E28; Wed, 12 Apr 2017 23:38:09 -0400 (EDT) Date: Wed, 12 Apr 2017 23:38:09 -0400 (EDT) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" cc: "ipsec@ietf.org" , Tero Kivinen In-Reply-To: <6c03477dff2045b0948d734a9d3b01ac@XCH-RTP-006.cisco.com> Message-ID: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <10130bc78c68427eab68895806a87fdc@XCH-RTP-006.cisco.com> <6c03477dff2045b0948d734a9d3b01ac@XCH-RTP-006.cisco.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 03:38:25 -0000 On Thu, 13 Apr 2017, Scott Fluhrer (sfluhrer) wrote: > I wasn't nearly as clear as I ought to have been; I made some assumptions without stating them. > > There are, of course, multiple possible PPK sources; one is a preconfigured fixed value in the device; another might be values from a CD-ROM (as others discussed elsethread); still another might be a quantum key distribution device. > > My discussion was solely about the preconfigured fixed value, and I was just talking about the mapping between 'fixed value' and 'the PPK value you hand to the PRF'; this fixed value will likely be configured as a string (similar to a standard preshared key), my question was the mapping of this string to a PPK value. Right, and likely use the exact same code path as for PSK, so I think the vendors will have will interop similarly with PSK as with PPK for this use case. I really wouldn't want to have our PPK secrets to be differently configured or interpreted from out PSK secrets with respect to whether it ignores a space or not. > Now, obviously, there will be other methods of generating PPKs; for those alternative methods, they will likely generate large (256 bit or so) uniform random value; there may be no particular reason to impose any nontrivial mapping there. Obviously, talking about ASCII in that context may make no sense whatsoever. I don't intend to talk about these alternative methods directly in the draft (except to provide a hook to add them later). Right, but I think it is better to not give different formats/charsets for PPKs. Maybe note/warn the implementer for dangerous characters, but don't define a new set of valid chars for this one type of PPK. Paul ps. as for your "they will likely generate" argument, I fear that is mostly wishful thinking. As was pointed out recently, this is the stuff you find in "production quality VPN services": https://support.onevpn.com/knowledgebase/configure-l2tp-protocol-windows-10/ which says: 0- Select the radio box for “Use preshared key for authentication†and enter “123456789†And those kind of things lead to these kind of statistics: https://twitter.com/letoams/status/549654933608595457 From nobody Thu Apr 13 00:19:02 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E88B412EB95 for ; Thu, 13 Apr 2017 00:19:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.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, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=1.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCHodqXZo8pT for ; Thu, 13 Apr 2017 00:18:59 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 8E03B12EB99 for ; Thu, 13 Apr 2017 00:18:56 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id s141so25192274lfe.3 for ; Thu, 13 Apr 2017 00:18:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=uwTK8WQ0swzjXLuDYh194TMWmduk9Ql+zh2b8W8yvuE=; b=BhUuuO/y+5DYmJEqVkT0i2rtwfz5xCn66VnKaj23dCGGY5Z/7tYvVyRbhE/75AlSDU vc/xqsqVFXeKXkAQrBu8alFDCvpy3KJHlj+RD257DgMZBsKEp94v3MoeBQ3zvs7Ak3OY g6Uuobi8zZOwlQRfEXwfEs47dJeRhIQWnXR7lKRNzsiM13a0NuGoJnSGBjSzCE7R2E0d S4NB+RNLIy4M+ihV4lt04QwVgBXvCcREkEApUoQRXgLFcHa0u6d1EqpP3xviZaNT2SMp n6juOYDSUvfuyIOJtc2k9gSgPhzn+5tSqZYLQ4ef/lE0li7O4fEJACMoP+zMCy42C2Dy XK9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=uwTK8WQ0swzjXLuDYh194TMWmduk9Ql+zh2b8W8yvuE=; b=QOSxfjOJuielIVZDEQebqmPLL6QbV5rZW8UwFCi1mbrTOLJ56b+OzAoyPNZfjn1Qz0 XrNSY4iAtzaC5mk6Z65q+dTnUlNHXwFgplG4UgTU5iJQ2QBa+SbFH46InhPV4TZA0w+d mPKJftbzCIuHz2EVEXeWYHN9oYdN5kzjudmPR8X/L6YiKEK5A1HDqX/SNuk174aj5Kmk 1Xe0JSvAELqP60bOAMm/IiSpUsjEw4IsNbFo7vR8EgBuI6LVvFBue6gVyxSEge+cGlD2 vLB/uME92rDbW7VT4XlOxRIMOJTnXVId9kcvczTqnfA2Rgrqb5mOtXBYZrNcESUfWEgg xMTg== X-Gm-Message-State: AN3rC/5x3yKxre1pv1QggmHceEgobIAD0twGjVaIVXTOUgWUx1iW6nIR n45QFhIKS906iQ== X-Received: by 10.25.219.203 with SMTP id t72mr687825lfi.42.1492067934719; Thu, 13 Apr 2017 00:18:54 -0700 (PDT) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id a138sm4510742lfb.20.2017.04.13.00.18.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 13 Apr 2017 00:18:54 -0700 (PDT) From: "Valery Smyslov" To: "'Scott Fluhrer \(sfluhrer\)'" , "'Tero Kivinen'" Cc: References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <10130bc78c68427eab68895806a87fdc@XCH-RTP-006.cisco.com> In-Reply-To: <10130bc78c68427eab68895806a87fdc@XCH-RTP-006.cisco.com> Date: Thu, 13 Apr 2017 10:18:55 +0300 Message-ID: <172101d2b426$36250b40$a26f21c0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJiRAei5w1b2LMAA0HLb+2F/4gH8gHZiixpAiXmKX8CUPVhmAIASlRaAdvxjwCgUlsacA== Content-Language: ru Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 07:19:01 -0000 Hi Scott, > I've been pondering another question, and I think I'll bring it up before finalizing the next version of the > draft. > > After the WG meeting, we (Tero and myself) met in the hallway and had a little chat. One of the things > that I took away from it (and please correct me if I was wrong) was that you thought that it was important > that the PPK itself was potentially equidistributed; for example, if it was 256 bits long, then all possible 256 > bit values were representable; after all, we are handling it the PRF as a key. On this basis, you suggested > that the PPK be encoded in Base64 (and converted into binary by each endpoint). > > Now, for the specific PRFs standardized in IKE, it's not actually that important that all bit patterns be > possible. Currently, the PRFs defined are HMAC of various hash functions, and XCBC/CMAC (which aren't > quantum safe). The HMAC PRFs do not actually need to make the assumption that the key is > equidistributed; it is sufficient that there are at least 2**256 possible PPKs (which can be ensured by > simply allowing the PPK to be long enough). > > It would certainly be simpler to say "take the PPK as an ASCII string, and hand it off to the PRF as the key", > and skip the Base64 conversion; we might want to suggest a limit on the alphabet of the PPK (as not all > implementation like things with, say, spaces, in them), however that's not a serious suggestion. > > On the other hand, it does rather assume that any future PRF will also work well with a non-evenly > distributed key. > > Thoughts? I've been thinking that the protocol must not prescribe PPK format (as well as PSK format). For the protocol it is a binary string. How it is represented in GUI and in which form it is transferred from peer to peer (base64, hex, even ASCII etc.) is not a protocol's matter. E.g. I can have a hardware tokens fabricated in pairs containing the same random PPK, that is never exported from the tokens. The end user never see the PPK value. Distribution is made by physically handing over the tokens. All crypto operations with PPK are done inside token. What base 64 we are talking about in this case? Where to apply it? Regards, Valery. From nobody Thu Apr 13 04:00:28 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D698E131510 for ; Thu, 13 Apr 2017 04:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sX2NZZ4EGaGx for ; Thu, 13 Apr 2017 04:00:20 -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 CB44D13150E for ; Thu, 13 Apr 2017 04:00:16 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3DB05M2024610 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 Apr 2017 14:00:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3DB04Ch013453; Thu, 13 Apr 2017 14:00:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22767.23092.518661.543586@fireball.acr.fi> Date: Thu, 13 Apr 2017 14:00:04 +0300 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" Cc: "ipsec\@ietf.org" In-Reply-To: <10130bc78c68427eab68895806a87fdc@XCH-RTP-006.cisco.com> References: <22748.16157.573889.454241@fireball.acr.fi> <35c28486d67f45d897458a91d0b874d2@XCH-RTP-006.cisco.com> <22755.38800.522208.481154@fireball.acr.fi> <77827c4b2e8046c38f82aaffdb36d0f8@XCH-RTP-006.cisco.com> <22756.60015.425330.926683@fireball.acr.fi> <10130bc78c68427eab68895806a87fdc@XCH-RTP-006.cisco.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 21 min X-Total-Time: 21 min Archived-At: Subject: Re: [IPsec] Quantum Resistance SK_d, SK_pi, SK_pr etc mixing X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 11:00:23 -0000 Scott Fluhrer (sfluhrer) writes: > I've been pondering another question, and I think I'll bring it up > before finalizing the next version of the draft.=20 >=20 > After the WG meeting, we (Tero and myself) met in the hallway and > had a little chat. One of the things that I took away from it (and > please correct me if I was wrong) was that you thought that it was > important that the PPK itself was potentially equidistributed; for > example, if it was 256 bits long, then all possible 256 bit values > were representable; after all, we are handling it the PRF as a key. > On this basis, you suggested that the PPK be encoded in Base64 (and > converted into binary by each endpoint).=20 Actually I do not care if all possible 256-bit values can be used, but care that whatever value I get from somewhere can be used... I.e., if I have some external distribution method giving me those PPK values, I want to make sure I can configure both ends to use those values. > Now, for the specific PRFs standardized in IKE, it's not actually > that important that all bit patterns be possible. Currently, the > PRFs defined are HMAC of various hash functions, and XCBC/CMAC > (which aren't quantum safe). The HMAC PRFs do not actually need to > make the assumption that the key is equidistributed; it is > sufficient that there are at least 2**256 possible PPKs (which can > be ensured by simply allowing the PPK to be long enough). Yes. > It would certainly be simpler to say "take the PPK as an ASCII > string, and hand it off to the PRF as the key", and skip the Base64 > conversion; we might want to suggest a limit on the alphabet of the > PPK (as not all implementation like things with, say, spaces, in > them), however that's not a serious suggestion.=20 Lets say I have external method which generates me a quantum safe PPK for both ends. Now, I want to make sure I can use that PPK in both ends, and to make sure it can be used I want to make it sure that I can configure whatever PPK I get from this external thing to be used as PPK. If we use ASCII string, then I need to take my binary blob PPK and convert it to something that is representable in ascii (for example hex or base64 encoding). As my APIs etc will take PPK as binary opaque string with length, there is no point of restricting myself to just ascii strings there. It is less error prone to allow me to use the raw binary string than for example hex conversion of the binary string. For example with hex strings the result will be different depending whether I use uppercase or lower case letters. With base64 the result will be different if I make base64 string without any whitespace, or if I split base64 string to 72 character long lines. So for reading the PPK for config file and then converting it to binary will make this kind of issues disappear, and when the config file reads base64 string (or hex string) in, and then convert it to binary object it does not matter whether there is whitespaces etc in string. It also make it so that we do not need to care about the character sets. If we say PPK is string, then we need to know whether it is ASCII, iso-latin-1, iso-latin-15, utf-8 or whatever.=20 > On the other hand, it does rather assume that any future PRF will > also work well with a non-evenly distributed key. I do not really care whether the PRF works with non-evenly distributed key, I care that when I configure the same PPK in both ends, I can be sure the binary object feed to the PRF will be same. If I configure PPK to be string =09Eritt=E4inen salainen merkkijono to my system, the binary representation of that will be different depending whether my editor saved it as UTF-8 or Latin-1... If I configure my sytem to use base64 string of =09RXJpdHTkaW5lbiBzYWxhaW5lbiBtZXJra2lqb25vCg=3D=3D then both ends will convert it to binary object in same way, and it does not really matter whether the original string was in UTF-8 or latin-1 (In this case I think my system used latin-1 for it). --=20 kivinen@iki.fi From nobody Thu Apr 13 09:49:49 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36E8129AFC for ; Thu, 13 Apr 2017 09:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuAMRI-hiRob for ; Thu, 13 Apr 2017 09:49:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD510129AFE for ; Thu, 13 Apr 2017 09:49:25 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEQ66538; Thu, 13 Apr 2017 16:49:23 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Apr 2017 17:49:22 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Thu, 13 Apr 2017 09:49:17 -0700 From: Linda Dunbar To: "IPsec@ietf.org" CC: "kivinen@iki.fi" , "Waltermire, David A. (Fed)" Thread-Topic: Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? Thread-Index: AdK0dSNH/SddKvxwSfu/xc78kwOSKw== Date: Thu, 13 Apr 2017 16:49:16 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.192] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F65927260FSJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58EFAC13.01BE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c8539069d57e68e5f9f13be2145fcbdd Archived-At: Subject: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 16:49:42 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F65927260FSJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IPsec experts: As more enterprises are moving workload to 3rd party data centers (like Ama= zon AWS), the common way is to use IPSec to establish secure tunnels among = branch offices and workload hosted by the cloud data centers. Today, it is assumed that IPSec tunnel is between Data Center (say Amazon A= WS) gateway and branch office CPE. But many enterprises are worried that their workload traffic are exposed be= hind the data center gateway (e.g. in AWS data center). It would make enter= prises more comfortable to have the secure tunnels go all the way to the wo= rkload (say servers, or VMs) within the 3rd party DC. - To support this, one end point of the tunnel will be (virtual) CPE= s which has a set of workload attached (say Virtual Machines). All having = virtual IP addresses. Can IPSec (RFC 5996) support this combination? How? - Does the enterprise who lease virtual resource from 3rd party dat= a center have to have a public routable IP address to establish IPsec tunne= l between branch offices and the (virtual) gateway in the 3rd party DC? - Is there any limitation (i.e. the maximum number of IPSec sessions= ) that a server can support? - Is there any advantages of IPsec Comparing with using TLS? Does TL= S provide Tunnel mode? - I2NSF has a proposal on using Controller to manager all the IPSec = tunnels: https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-f= low-protection. What kind of issues do you see with the proposed approach? Thanks, Linda Dunbar --_000_4A95BA014132FF49AE685FAB4B9F17F65927260FSJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IPsec experts:

 

As more enterprises are moving workload to 3rd<= /sup> party data centers (like Amazon AWS), the common way is to use IPSec = to establish secure tunnels among branch offices and workload hosted by the= cloud data centers.

Today, it is assumed that IPSec tunnel is between Da= ta Center (say Amazon AWS) gateway and branch office CPE.

 

But many enterprises are worried that their workload= traffic are exposed behind the data center gateway (e.g. in AWS data cente= r). It would make enterprises more comfortable to have the secure tunnels g= o all the way to the workload (say servers, or VMs) within the 3rd party DC.

 

-       = ; To support this, one end point of the tunnel will b= e (virtual) CPEs which has a set of workload attached (say Virtual Machines= ).  All having virtual IP addresses. Can IPSec (RFC 5996) support this= combination? How?

-       = ;  Does the enterprise who lease virtual resourc= e from 3rd party data center have to have a public routable IP a= ddress to establish IPsec tunnel between branch offices and the (virtual) g= ateway in the 3rd party DC?  

-       = ; Is there any limitation (i.e. the maximum number of= IPSec sessions) that a server can support?

-       = ; Is there any advantages of IPsec Comparing with usi= ng TLS? Does TLS provide Tunnel mode?

-       = ; I2NSF has a proposal on using Controller to manager= all the IPSec tunnels: https://datatracker.ietf.org/doc/html/draft-a= bad-i2nsf-sdn-ipsec-flow-protection. What kind of issues do you = see with the proposed approach?

 

 

Thanks, Linda Dunbar

 

--_000_4A95BA014132FF49AE685FAB4B9F17F65927260FSJCEML702CHMchi_-- From nobody Thu Apr 13 12:48:17 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DDBF131617 for ; Thu, 13 Apr 2017 12:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMVnGTT5WHg4 for ; Thu, 13 Apr 2017 12:48:14 -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 555DC131615 for ; Thu, 13 Apr 2017 12:48:14 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C2AAD20558; Thu, 13 Apr 2017 16:13:00 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6C7DA636BB; Thu, 13 Apr 2017 15:48:13 -0400 (EDT) From: Michael Richardson To: "IPsec\@ietf.org" cc: Linda Dunbar In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 19:48:16 -0000 --=-=-= Content-Type: text/plain Linda Dunbar wrote: > - To support this, one end point of the tunnel will be (virtual) CPEs > which has a set of workload attached (say Virtual Machines). All having > virtual IP addresses. Can IPSec (RFC 5996) support this combination? > How? As long the branch office CPE has a public IP address, or one is willing to establish a hub system with a public IP address, all the VMs can just be considered to behind NAPT. This is done in the field regularly. Given that Amazon's IPsec tunnel end points cost extra, and sometimes have significant compatibility problems, this is often the preferred solutions regardless. > - Does the enterprise who lease virtual resource from 3rd party data > center have to have a public routable IP address to establish IPsec > tunnel between branch offices and the (virtual) gateway in the 3rd > party DC? Not always, no. > - Is there any limitation (i.e. the maximum number of IPSec sessions) > that a server can support? Depends upon ram and network speed. In general, the limits are quite high. We have configured systems with 3000 tunnels from multiply-NAT'ed IoT devices in the field. 3000 was chosen as a soft limit per gateway machine due to anticipated traffic load vs speed for virtual devices. It's WAY easier with IKEv2 and putting IPv6 inside, but many customers are afraid of this because they have little experience with IPv6. > - Is there any advantages of IPsec Comparing with using TLS? Does TLS > provide Tunnel mode? There is no IETF standard TLS-based VPN. There are dozens of proprietary stacks, including the very popular OpenVPN. > - I2NSF has a proposal on using Controller to manager all the IPSec > tunnels: > https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-protection. > What kind of issues do you see with the proposed approach? I didn't read it. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljv1f0ACgkQgItw+93Q 3WVFXwf/WyVxPuIuMHjUiFltYkc0rqZ62x8fMcXi6oaFt82sOXxCLUvYB6PtSsuY G+Fkw7LjxehNNpj96DvwQIsDpBSJoiTMq0JQMgsgNzMaFjtGRkpzXdo/YIcObU71 Eanc8pPzKumKzKACBk4ob79uOXxeg3T9guahgOsOLTiR5uxNeW1F+jI8erZ7cR6h 2ApPsH92fzKwmPQOvmVz7SjwA9kKNuc8LE/P1YtCC6R5NL7FzCB505wYaUUWxgow AoDL3NLOL9T4aw1M3SL3DY0GgmK631xosOyHWo3uDlNfG6CmfQ4peSoc2ewHqG1l Aam1gDmbxoy15uK1VoxXefZ4VSbtnQ== =tANA -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 13 14:42:20 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95E9120227 for ; Thu, 13 Apr 2017 14:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xJuxcUVou_43 for ; Thu, 13 Apr 2017 14:42:16 -0700 (PDT) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77DC812778E for ; Thu, 13 Apr 2017 14:42:16 -0700 (PDT) Received: by mail-wm0-x235.google.com with SMTP id o81so120233902wmb.1 for ; Thu, 13 Apr 2017 14:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=1NpIv1jviC4MoKTq85XAZqk8QMXfbQXFfimZhiWfyLQ=; b=J8WWajwPemym8g2g5lGcd5LcRutoaK1AIjx2e7kaju4AQ/3oSB3UGEwmDRJTPHq6Uq 1IAoyYhqYOF/hZS7URUa1VFgXARAVKqzIxj2g4QqSPaQtTS6X4xkBJwMonON+pfafRvv m5OjAbb6xt5SxBv1a53ZcKEr64u2pDBCpBbvjZZdSSPbAdWqDo6OV1YGDeV7bR/qxzYZ r/Cu8aJSiSfqDLRJgKIQVyb9Ghiwtz3xukwrbEdO5QhmptvEoRp0QBJW2wGxj3FxvL9s NWxWB+c0lYva+uepp0TG7yFAutB7Nuk/AeIr/YgGpFbvfsRLg7HCS/VbDc9ofe3PXezz cRFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=1NpIv1jviC4MoKTq85XAZqk8QMXfbQXFfimZhiWfyLQ=; b=tBAHubrQochP/oJ+z5x88mEUSlSZ4ECqEcMo8sN5W4qKhxJDfEE9z6bPe5fQXFucPT S2pMgYtdy5m73Irww+3skh7aq04Ml1V6YCfqYmR3o6KenhXlu5Rm9OkAcv5egA5usJCn SojVADWVsEOy+Wr1X1Bp40SARJpb0IqoW8QnEaRTNJ3hBjc3plr/4kpjJJxTO6+Adh1u s4uqA5WyajNhPvWeFPC7C2n2b6qKmb9ScoaG8S+0Z/yL86yBe9kXF9f4JKu7WT7BtnTd i0H6qf9EuInHJp/Asfed7jZ57q3GMYOBUxX2Xm0SNPUC7XdWPRe2kGSiTcRRrcaVA3aX rdRw== X-Gm-Message-State: AN3rC/7GQHknxw5C3oYbFfumf/+pPTSQsO1v3CNIOqLK3vUvGcrA0STL ue0kSYJAn5wx0h33qog= X-Received: by 10.28.234.144 with SMTP id g16mr5252315wmi.61.1492119734844; Thu, 13 Apr 2017 14:42:14 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id p101sm4741436wrb.64.2017.04.13.14.42.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 14:42:14 -0700 (PDT) From: Yoav Nir Message-Id: <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DDE2B76F-3EDE-4D49-8C44-0A6CC5D6EB6B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Apr 2017 00:42:11 +0300 In-Reply-To: <18474.1492112893@obiwan.sandelman.ca> Cc: "IPsec@ietf.org" , Michael Richardson To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 21:42:19 -0000 --Apple-Mail=_DDE2B76F-3EDE-4D49-8C44-0A6CC5D6EB6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi What Michael said. Additional comments within. On 13 Apr 2017, at 22:48, Michael Richardson = wrote: >=20 >=20 > Linda Dunbar wrote: >> - To support this, one end point of the tunnel will be (virtual) CPEs >> which has a set of workload attached (say Virtual Machines). All = having >> virtual IP addresses. Can IPSec (RFC 5996) support this combination? >> How? To clarify, RFC 7296 (and previously 5996) are for IKEv2, the key = exchange and authentication protocol. RFC 4301 defines IPsec. > As long the branch office CPE has a public IP address, or one is = willing to > establish a hub system with a public IP address, all the VMs can just = be > considered to behind NAPT. This is done in the field regularly. > Given that Amazon's IPsec tunnel end points cost extra, and sometimes = have > significant compatibility problems, this is often the preferred = solutions > regardless. Yeah. AWS (and Azure as well) want you to have a virtual server room in = their cloud, and you connect your IPsec to an AWS gateway in tunnel = mode. They also prefer to forego IKE=E2=80=99s ability to negotiate = tunnel selectors (the set of addresses and protocols being tunneled) and = instead negotiate universal tunnels and choose what to tunnel using = configuration. To add confusion, they call this =E2=80=9Croute-based = VPN=E2=80=9D even if you don=E2=80=99t use a routing protocol at all. There are other options with cloud providers where you can install = whatever IPsec software you want on your virtual server, but that costs = extra. >> - Does the enterprise who lease virtual resource from 3rd party data >> center have to have a public routable IP address to establish IPsec >> tunnel between branch offices and the (virtual) gateway in the 3rd >> party DC? >=20 > Not always, no. >=20 >> - Is there any limitation (i.e. the maximum number of IPSec sessions) >> that a server can support? >=20 > Depends upon ram and network speed. > In general, the limits are quite high. > We have configured systems with 3000 tunnels from multiply-NAT'ed IoT = devices > in the field. 3000 was chosen as a soft limit per gateway machine due = to > anticipated traffic load vs speed for virtual devices. >=20 > It's WAY easier with IKEv2 and putting IPv6 inside, but many customers = are > afraid of this because they have little experience with IPv6. Yeah. Gateways routinely manage thousands or tens of thousands of = tunnels on commodity hardware. Its usually the amount of IPsec traffic = that becomes the bottleneck. >> - Is there any advantages of IPsec Comparing with using TLS? Does TLS >> provide Tunnel mode? >=20 > There is no IETF standard TLS-based VPN. There are dozens of = proprietary > stacks, including the very popular OpenVPN. And all of those proprietary stacks are used primarily for the = remote-access / road-warrior scenario. Hardly anyone uses them for = site-to-site. >> - I2NSF has a proposal on using Controller to manager all the IPSec >> tunnels: >> = https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-prot= ection. >> What kind of issues do you see with the proposed approach? >=20 > I didn't read it. I did. They have two cases. In case #1 the controller provisions = credentials for IKE and entries in PAD and SPD. In case #2 you forego = IKE and have the controller provision the SAs (including keys). I especially didn=E2=80=99t like case #2. Sharing a secret key among = three entities is a bad idea. A shared authentication credential can = also be misused, but that=E2=80=99s a hard attack to mount. A shared = traffic key makes the controller a very attractive target. More in general, SDN was born in the data center. In a data center an = all-knowing controller makes sense. This is true for routing as it is = for NSFs such as firewalls, IDPs and IDSs. VPN extends the reach of the = private network to all corners of the Internet. Think of a store chain = with a CPE in every one of thousands of branches. Or a bank. The problem = there is that there is no central administrative function. Local = branches may switch ISP and renumber their network without bothering to = tell the IT people. So the model where the controller knows everything = is tough to deploy in practice. It is probably necessary to have two-way communications, where the CPE = tells the controller about its topology (how it partitions the Internet = to =E2=80=9Cin=E2=80=9D vs =E2=80=9Cout=E2=80=9D) so that the controller = can set up the appropriate SPDs. There have been several attempts at this. RFC 7018 describes = requirements, but the WG ultimately failed to publish a solution = document. There are also more recent commercial solutions sold today = under the marketing name of =E2=80=9CSD-WAN=E2=80=9D, which is sort of = like SDN if you squint hard enough. All of these have some interaction = between CPE and controllers (or hubs) which draft-abad does not. Yoav --Apple-Mail=_DDE2B76F-3EDE-4D49-8C44-0A6CC5D6EB6B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY7/CzAAoJELhJCxUKWMyZZtgH/RZU5JV3WlQ+gGWv8sUdDtZX ELRffRdBbPjvFVN1eKPinY135Q3jbYsPUvpMTPnvBaGHtVL4NUE/v8yAhD3wAJwc B6wU1PG029y3RJwXAhvVmcIhXjHVPxvZR/MRnGzmX7ludVtw1T3ipr5OYROhVASh grFfNLNykIFRsB1CW8Tt0OduWOmX8wt3LRhJLebTW0F+36hqDQ17KOv5zIyDLJ+V hzuB0hSD28PkfAfFWqxb9zjjRdacGn3I1xci/BavIhEP9HtaCabuhTM3zKcUU2cA 7PT9eNkA9RozZjrwwnsF0jbRbvWtToHBf0tSYVPtPCSZyDnEZ8Zx+an+5GFos4E= =B8t0 -----END PGP SIGNATURE----- --Apple-Mail=_DDE2B76F-3EDE-4D49-8C44-0A6CC5D6EB6B-- From nobody Thu Apr 13 15:06:47 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C47D129A9C for ; Thu, 13 Apr 2017 15:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h756pEB51TtY for ; Thu, 13 Apr 2017 15:06:44 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41381295A0 for ; Thu, 13 Apr 2017 15:06:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEQ90834; Thu, 13 Apr 2017 22:06:41 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Apr 2017 23:06:40 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML701-CHM.china.huawei.com ([169.254.3.8]) with mapi id 14.03.0235.001; Thu, 13 Apr 2017 15:06:36 -0700 From: Linda Dunbar To: Michael Richardson , "IPsec@ietf.org" Thread-Topic: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? Thread-Index: AQHStI7rHBZtgVwZo0yr+RLMn50uz6HD14iw Date: Thu, 13 Apr 2017 22:06:35 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F6592728FF@SJCEML702-CHM.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> In-Reply-To: <18474.1492112893@obiwan.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.192] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F6592728FFSJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58EFF671.012F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 99817eba1a6f6086a664b488bb9225b2 Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 22:06:46 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F6592728FFSJCEML702CHMchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Michael, Thank you very much for the detailed reply. You said: "As long the branch office CPE has a public IP address, or one is wil= ling to establish a hub system with a public IP address, all the VMs can ju= st be considered to behind NAPT. " Is the "INTERNAL_IP4_ADDRESS" in RFC5996 intended for establishing IPSec tu= nnel between remote VMs behind NAPT (all VMs have the virtual IP address)? Does the CPE (with Public IP address) still need to know the NAT public IP = address (even though the IPsec tunnel goes through the NAT to the VMs behin= d the NAT)? Possible to have one IPSec tunnel with multiple VMs end points? (i.e. 1<-> = N tunnel: A tunnel with one CPE on one end and many VMs on the other end)? Thank you. Linda -----Original Message----- From: Michael Richardson [mailto:mcr+ietf@sandelman.ca] Sent: Thursday, April 13, 2017 2:48 PM To: IPsec@ietf.org Cc: Linda Dunbar Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point be= ing (virtual) CPEs which has a set of workload attached (say Virtual Machin= es) all having virtual IP addresses? Linda Dunbar > wrot= e: > - To support this, one end point of the tunnel will be (virtual) CPEs > which has a set of workload attached (say Virtual Machines). All havi= ng > virtual IP addresses. Can IPSec (RFC 5996) support this combination? > How? As long the branch office CPE has a public IP address, or one is willing to= establish a hub system with a public IP address, all the VMs can just be considered to behind NAPT. This is done in the field regularly. Given that Amazon's IPsec tunnel end points cost extra, and sometimes have = significant compatibility problems, this is often the preferred solutions r= egardless. > - Does the enterprise who lease virtual resource from 3rd party data > center have to have a public routable IP address to establish IPsec > tunnel between branch offices and the (virtual) gateway in the 3rd > party DC? Not always, no. > - Is there any limitation (i.e. the maximum number of IPSec sessions) > that a server can support? Depends upon ram and network speed. In general, the limits are quite high. We have configured systems with 3000 tunnels from multiply-NAT'ed IoT devic= es in the field. 3000 was chosen as a soft limit per gateway machine due t= o anticipated traffic load vs speed for virtual devices. It's WAY easier with IKEv2 and putting IPv6 inside, but many customers are = afraid of this because they have little experience with IPv6. > - Is there any advantages of IPsec Comparing with using TLS? Does TLS > provide Tunnel mode? There is no IETF standard TLS-based VPN. There are dozens of proprietary s= tacks, including the very popular OpenVPN. > - I2NSF has a proposal on using Controller to manager all the IPSec > tunnels: > https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow= -protection. > What kind of issues do you see with the proposed approach? I didn't read it. -- Michael Richardson >, S= andelman Software Works -=3D IPv6 IoT consulting =3D- --_000_4A95BA014132FF49AE685FAB4B9F17F6592728FFSJCEML702CHMchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Michael,
 
Thank you very much for the detailed reply.
 
You said:
"As long the branch office= CPE has a public IP address, or one is willing to establish a hub system w= ith a public IP address, all the VMs can just be considered t= o behind NAPT. " 
 
 
Is the "INTERNAL_IP4_ADDRESS" in RFC5996 intended for establ= ishing IPSec tunnel between remote VMs behind NAPT (all VMs have the virtua= l IP address)?
Does the CPE (with Public IP address) still need to know the NAT publi= c IP address (even though the IPsec tunnel goes through the NAT to the VMs = behind the NAT)?
 
Possible to have one IPSec tunnel with multiple VMs end points? (i.e. = 1<-> N tunnel: A tunnel with one CPE  on one end and many VMs on= the other end)?
 
Thank you.
 
Linda
 
 
 
-----Original Message-----
From: Michael Richardson [mail= to:mcr+ietf@sandelman.ca]
Sent: Thursday, April 13, 2017 2:48 PM
To: IPsec@ietf.org
Cc: Linda Dunbar <linda.dunbar@huawei.com>
Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point be= ing (virtual) CPEs which has a set of workload attached (say Virtual Machin= es) all having virtual IP addresses?
 
 
Linda Dunbar <linda.dunb= ar@huawei.com> wrote:
    > - To support this, one end point of the tunnel= will be (virtual) CPEs
    > which has a set of workload attached (say Virt= ual Machines). All having
    > virtual IP addresses. Can IPSec (RFC 5996) sup= port this combination?
    > How?
 
As long the branch office CPE has a public IP address, or one is willi= ng to establish a hub system with a public IP address, all the VMs can just= be
considered to behind NAPT.   This is done in the field regul= arly.
Given that Amazon's IPsec tunnel end points cost extra, and sometimes = have significant compatibility problems, this is often the preferred soluti= ons regardless.
 
    > - Does the enterprise who lease virtual resour= ce from 3rd party data
    > center have to have a public routable IP addre= ss to establish IPsec
    > tunnel between branch offices and the (virtual= ) gateway in the 3rd
    > party DC?
 
Not always, no.
 
    > - Is there any limitation (i.e. the maximum nu= mber of IPSec sessions)
    > that a server can support?
 
Depends upon ram and network speed.
In general, the limits are quite high.
We have configured systems with 3000 tunnels from multiply-NAT'ed IoT = devices in the field.  3000 was chosen as a soft limit per gateway mac= hine due to anticipated traffic load vs speed for virtual devices.
 
It's WAY easier with IKEv2 and putting IPv6 inside, but many customers= are afraid of this because they have little experience with IPv6.
 
    > - Is there any advantages of IPsec Comparing w= ith using TLS? Does TLS
    > provide Tunnel mode?
 
There is no IETF standard TLS-based VPN.  There are dozens of pro= prietary stacks, including the very popular OpenVPN.
 
    > - I2NSF has a proposal on using Controller to = manager all the IPSec
    > tunnels:
    > What kind of issues do you see with the propos= ed approach?
 
I didn't read it.
 
 
--
Michael Richardson <mc= r+IETF@sandelman.ca>, Sandelman Software Works  -=3D IPv6 I= oT consulting =3D-
 
 
 
 
 --_000_4A95BA014132FF49AE685FAB4B9F17F6592728FFSJCEML702CHMchi_-- From nobody Thu Apr 13 15:26:41 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8D3D129548 for ; Thu, 13 Apr 2017 15:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 93uEEiuaHQcB for ; Thu, 13 Apr 2017 15:26:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8412D128AB0 for ; Thu, 13 Apr 2017 15:26:35 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEQ92185; Thu, 13 Apr 2017 22:26:33 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 13 Apr 2017 23:26:32 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML701-CHM.china.huawei.com ([169.254.3.8]) with mapi id 14.03.0235.001; Thu, 13 Apr 2017 15:26:24 -0700 From: Linda Dunbar To: Yoav Nir CC: "IPsec@ietf.org" , Michael Richardson Thread-Topic: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? Thread-Index: AQHStI7rHBZtgVwZo0yr+RLMn50uz6HESdeA//+TOiA= Date: Thu, 13 Apr 2017 22:26:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F659272932@SJCEML702-CHM.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> In-Reply-To: <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.192] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F659272932SJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.58EFFB1A.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 99817eba1a6f6086a664b488bb9225b2 Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Apr 2017 22:26:40 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F659272932SJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW9hdiwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIHJlcGx5LiBBbmQgdGhlIHZhbHVh YmxlIGNvbW1lbnRzIHRvIGRyYWZ0LWFiYWQtaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJvdGVjdGlv bi4NCg0KWW91IHNhaWQ6DQoNCiAgICAgIFllYWguIEFXUyAoYW5kIEF6dXJlIGFzIHdlbGwpIHdh bnQgeW91IHRvIGhhdmUgYSB2aXJ0dWFsIHNlcnZlciByb29tIGluIHRoZWlyIGNsb3VkLCBhbmQg eW91IGNvbm5lY3QgeW91ciBJUHNlYyB0byBhbiBBV1MgZ2F0ZXdheSBpbiB0dW5uZWwgbW9kZS4g VGhleSBhbHNvIHByZWZlciB0byBmb3JlZ28gSUtF4oCZcyBhYmlsaXR5IHRvIG5lZ290aWF0ZSB0 dW5uZWwgc2VsZWN0b3JzICh0aGUgc2V0IG9mIGFkZHJlc3NlcyBhbmQgcHJvdG9jb2xzIGJlaW5n IHR1bm5lbGVkKSBhbmQgaW5zdGVhZCBuZWdvdGlhdGUgdW5pdmVyc2FsIHR1bm5lbHMgYW5kIGNo b29zZSB3aGF0IHRvIHR1bm5lbCB1c2luZyBjb25maWd1cmF0aW9uLiBUbyBhZGQgY29uZnVzaW9u LCB0aGV5IGNhbGwgdGhpcyDigJxyb3V0ZS1iYXNlZCBWUE7igJ0gZXZlbiBpZiB5b3UgZG9u4oCZ dCB1c2UgYSByb3V0aW5nIHByb3RvY29sIGF0IGFsbC4NCg0KV2hhdCB5b3UgZGVzY3JpYmVkIGlz IHRoZSBjb21tb24gcHJhY3RpY2UgdG9kYXksIGkuZS4gIEVzdGFibGlzaGluZyBhIHR1bm5lbCAo SVBTZWMgVHVubmVsKSBiZXR3ZWVuIEFXUyBnYXRld2F5IGFuZCBDbGllbnQgQ1BFLiBUaGlzIGFw cHJvYWNoIG5vdCBvbmx5IGNvc3QgZXh0cmEsIGJ1dCBub3QgcmVhbGx5IHNlY3VyZSwgYmVjYXVz ZSB5b3VyIHRyYWZmaWMgYmVoaW5kIEFXUyBnYXRld2F5IGNhbiBleHBsb2l0ZWQgYnkgM3JkIHBh cnR5LiBDb3JyZWN0Pw0KDQpJcyB0aGVyZSBhbiBvcHRpb24gaW4gSVBTZWMgdGhhdCBhbGxvd3Mg bWUgdG8gZXN0YWJsaXNoIGEgdHVubmVsIGJldHdlZW4gbXkgQ1BFIGFuZCBteSB2aXJ0dWFsIHJl c291cmNlcyBsZWFzZWQgZnJvbSBBV1MgKGkuZS4gdHJhbnNwYXJlbnRseSBieS1wYXNzIEFXUyBn YXRld2F5KT8NCg0KWW91IGFsc28gc2FpZDoNCiAgICAgIFRoZXJlIGFyZSBvdGhlciBvcHRpb25z IHdpdGggY2xvdWQgcHJvdmlkZXJzIHdoZXJlIHlvdSBjYW4gaW5zdGFsbCB3aGF0ZXZlciBJUHNl YyBzb2Z0d2FyZSB5b3Ugd2FudCBvbiB5b3VyIHZpcnR1YWwgc2VydmVyLCBidXQgdGhhdCBjb3N0 cyBleHRyYS4NCg0KVGhlIHNvZnR3YXJlIGlzIGNvbnRyb2xsZWQgYnkgdGhlIGNsaWVudCwgY29y cmVjdD8gSWYgdGhlIGNsaWVudCBvd25zIHRoaXMgc29mdHdhcmUsIGl0IGRvZXNuJ3QgcmVhbGx5 IGNvc3QgZXh0cmEsIGRvZXMgaXQ/DQoNCkxpbmRhDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogWW9hdiBOaXIgW21haWx0bzp5bmlyLmlldGZAZ21haWwuY29tXQ0KU2VudDogVGh1 cnNkYXksIEFwcmlsIDEzLCAyMDE3IDQ6NDIgUE0NClRvOiBMaW5kYSBEdW5iYXIgPGxpbmRhLmR1 bmJhckBodWF3ZWkuY29tPg0KQ2M6IElQc2VjQGlldGYub3JnOyBNaWNoYWVsIFJpY2hhcmRzb24g PG1jcitpZXRmQHNhbmRlbG1hbi5jYT4NClN1YmplY3Q6IFJlOiBbSVBzZWNdIENhbiBJUFNlYyAo UkZDIDU5OTYpIHN1cHBvcnQgdHVubmVscyB3aXRoIGVuZCBwb2ludCBiZWluZyAodmlydHVhbCkg Q1BFcyB3aGljaCBoYXMgYSBzZXQgb2Ygd29ya2xvYWQgYXR0YWNoZWQgKHNheSBWaXJ0dWFsIE1h Y2hpbmVzKSBhbGwgaGF2aW5nIHZpcnR1YWwgSVAgYWRkcmVzc2VzPw0KDQpIaQ0KDQpXaGF0IE1p Y2hhZWwgc2FpZC4gIEFkZGl0aW9uYWwgY29tbWVudHMgd2l0aGluLg0KDQpPbiAxMyBBcHIgMjAx NywgYXQgMjI6NDgsIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPG1h aWx0bzptY3IraWV0ZkBzYW5kZWxtYW4uY2E+PiB3cm90ZToNCj4NCj4NCj4gTGluZGEgRHVuYmFy IDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbTxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+ PiB3cm90ZToNCj4+IC0gVG8gc3VwcG9ydCB0aGlzLCBvbmUgZW5kIHBvaW50IG9mIHRoZSB0dW5u ZWwgd2lsbCBiZSAodmlydHVhbCkgQ1BFcw0KPj4gd2hpY2ggaGFzIGEgc2V0IG9mIHdvcmtsb2Fk IGF0dGFjaGVkIChzYXkgVmlydHVhbCBNYWNoaW5lcykuIEFsbA0KPj4gaGF2aW5nIHZpcnR1YWwg SVAgYWRkcmVzc2VzLiBDYW4gSVBTZWMgKFJGQyA1OTk2KSBzdXBwb3J0IHRoaXMgY29tYmluYXRp b24/DQo+PiBIb3c/DQoNClRvIGNsYXJpZnksIFJGQyA3Mjk2IChhbmQgcHJldmlvdXNseSA1OTk2 KSBhcmUgZm9yIElLRXYyLCB0aGUga2V5IGV4Y2hhbmdlIGFuZCBhdXRoZW50aWNhdGlvbiBwcm90 b2NvbC4gUkZDIDQzMDEgZGVmaW5lcyBJUHNlYy4NCg0KPiBBcyBsb25nIHRoZSBicmFuY2ggb2Zm aWNlIENQRSBoYXMgYSBwdWJsaWMgSVAgYWRkcmVzcywgb3Igb25lIGlzDQo+IHdpbGxpbmcgdG8g ZXN0YWJsaXNoIGEgaHViIHN5c3RlbSB3aXRoIGEgcHVibGljIElQIGFkZHJlc3MsIGFsbCB0aGUg Vk1zIGNhbiBqdXN0IGJlDQo+IGNvbnNpZGVyZWQgdG8gYmVoaW5kIE5BUFQuICAgVGhpcyBpcyBk b25lIGluIHRoZSBmaWVsZCByZWd1bGFybHkuDQo+IEdpdmVuIHRoYXQgQW1hem9uJ3MgSVBzZWMg dHVubmVsIGVuZCBwb2ludHMgY29zdCBleHRyYSwgYW5kIHNvbWV0aW1lcw0KPiBoYXZlIHNpZ25p ZmljYW50IGNvbXBhdGliaWxpdHkgcHJvYmxlbXMsIHRoaXMgaXMgb2Z0ZW4gdGhlIHByZWZlcnJl ZA0KPiBzb2x1dGlvbnMgcmVnYXJkbGVzcy4NCg0KWWVhaC4gQVdTIChhbmQgQXp1cmUgYXMgd2Vs bCkgd2FudCB5b3UgdG8gaGF2ZSBhIHZpcnR1YWwgc2VydmVyIHJvb20gaW4gdGhlaXIgY2xvdWQs IGFuZCB5b3UgY29ubmVjdCB5b3VyIElQc2VjIHRvIGFuIEFXUyBnYXRld2F5IGluIHR1bm5lbCBt b2RlLiBUaGV5IGFsc28gcHJlZmVyIHRvIGZvcmVnbyBJS0XigJlzIGFiaWxpdHkgdG8gbmVnb3Rp YXRlIHR1bm5lbCBzZWxlY3RvcnMgKHRoZSBzZXQgb2YgYWRkcmVzc2VzIGFuZCBwcm90b2NvbHMg YmVpbmcgdHVubmVsZWQpIGFuZCBpbnN0ZWFkIG5lZ290aWF0ZSB1bml2ZXJzYWwgdHVubmVscyBh bmQgY2hvb3NlIHdoYXQgdG8gdHVubmVsIHVzaW5nIGNvbmZpZ3VyYXRpb24uIFRvIGFkZCBjb25m dXNpb24sIHRoZXkgY2FsbCB0aGlzIOKAnHJvdXRlLWJhc2VkIFZQTuKAnSBldmVuIGlmIHlvdSBk b27igJl0IHVzZSBhIHJvdXRpbmcgcHJvdG9jb2wgYXQgYWxsLg0KDQpUaGVyZSBhcmUgb3RoZXIg b3B0aW9ucyB3aXRoIGNsb3VkIHByb3ZpZGVycyB3aGVyZSB5b3UgY2FuIGluc3RhbGwgd2hhdGV2 ZXIgSVBzZWMgc29mdHdhcmUgeW91IHdhbnQgb24geW91ciB2aXJ0dWFsIHNlcnZlciwgYnV0IHRo YXQgY29zdHMgZXh0cmEuDQoNCj4+IC0gRG9lcyB0aGUgZW50ZXJwcmlzZSB3aG8gbGVhc2Ugdmly dHVhbCByZXNvdXJjZSBmcm9tIDNyZCBwYXJ0eSBkYXRhDQo+PiBjZW50ZXIgaGF2ZSB0byBoYXZl IGEgcHVibGljIHJvdXRhYmxlIElQIGFkZHJlc3MgdG8gZXN0YWJsaXNoIElQc2VjDQo+PiB0dW5u ZWwgYmV0d2VlbiBicmFuY2ggb2ZmaWNlcyBhbmQgdGhlICh2aXJ0dWFsKSBnYXRld2F5IGluIHRo ZSAzcmQNCj4+IHBhcnR5IERDPw0KPg0KPiBOb3QgYWx3YXlzLCBuby4NCj4NCj4+IC0gSXMgdGhl cmUgYW55IGxpbWl0YXRpb24gKGkuZS4gdGhlIG1heGltdW0gbnVtYmVyIG9mIElQU2VjIHNlc3Np b25zKQ0KPj4gdGhhdCBhIHNlcnZlciBjYW4gc3VwcG9ydD8NCj4NCj4gRGVwZW5kcyB1cG9uIHJh bSBhbmQgbmV0d29yayBzcGVlZC4NCj4gSW4gZ2VuZXJhbCwgdGhlIGxpbWl0cyBhcmUgcXVpdGUg aGlnaC4NCj4gV2UgaGF2ZSBjb25maWd1cmVkIHN5c3RlbXMgd2l0aCAzMDAwIHR1bm5lbHMgZnJv bSBtdWx0aXBseS1OQVQnZWQgSW9UDQo+IGRldmljZXMgaW4gdGhlIGZpZWxkLiAgMzAwMCB3YXMg Y2hvc2VuIGFzIGEgc29mdCBsaW1pdCBwZXIgZ2F0ZXdheQ0KPiBtYWNoaW5lIGR1ZSB0byBhbnRp Y2lwYXRlZCB0cmFmZmljIGxvYWQgdnMgc3BlZWQgZm9yIHZpcnR1YWwgZGV2aWNlcy4NCj4NCj4g SXQncyBXQVkgZWFzaWVyIHdpdGggSUtFdjIgYW5kIHB1dHRpbmcgSVB2NiBpbnNpZGUsIGJ1dCBt YW55IGN1c3RvbWVycw0KPiBhcmUgYWZyYWlkIG9mIHRoaXMgYmVjYXVzZSB0aGV5IGhhdmUgbGl0 dGxlIGV4cGVyaWVuY2Ugd2l0aCBJUHY2Lg0KDQpZZWFoLiBHYXRld2F5cyByb3V0aW5lbHkgbWFu YWdlIHRob3VzYW5kcyBvciB0ZW5zIG9mIHRob3VzYW5kcyBvZiB0dW5uZWxzIG9uIGNvbW1vZGl0 eSBoYXJkd2FyZS4gSXRzIHVzdWFsbHkgdGhlIGFtb3VudCBvZiBJUHNlYyB0cmFmZmljIHRoYXQg YmVjb21lcyB0aGUgYm90dGxlbmVjay4NCg0KPj4gLSBJcyB0aGVyZSBhbnkgYWR2YW50YWdlcyBv ZiBJUHNlYyBDb21wYXJpbmcgd2l0aCB1c2luZyBUTFM/IERvZXMgVExTDQo+PiBwcm92aWRlIFR1 bm5lbCBtb2RlPw0KPg0KPiBUaGVyZSBpcyBubyBJRVRGIHN0YW5kYXJkIFRMUy1iYXNlZCBWUE4u ICBUaGVyZSBhcmUgZG96ZW5zIG9mDQo+IHByb3ByaWV0YXJ5IHN0YWNrcywgaW5jbHVkaW5nIHRo ZSB2ZXJ5IHBvcHVsYXIgT3BlblZQTi4NCg0KQW5kIGFsbCBvZiB0aG9zZSBwcm9wcmlldGFyeSBz dGFja3MgYXJlIHVzZWQgcHJpbWFyaWx5IGZvciB0aGUgcmVtb3RlLWFjY2VzcyAvIHJvYWQtd2Fy cmlvciBzY2VuYXJpby4gSGFyZGx5IGFueW9uZSB1c2VzIHRoZW0gZm9yIHNpdGUtdG8tc2l0ZS4N Cg0KPj4gLSBJMk5TRiBoYXMgYSBwcm9wb3NhbCBvbiB1c2luZyBDb250cm9sbGVyIHRvIG1hbmFn ZXIgYWxsIHRoZSBJUFNlYw0KPj4gdHVubmVsczoNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYWJhZC1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9u Lg0KPj4gV2hhdCBraW5kIG9mIGlzc3VlcyBkbyB5b3Ugc2VlIHdpdGggdGhlIHByb3Bvc2VkIGFw cHJvYWNoPw0KPg0KPiBJIGRpZG4ndCByZWFkIGl0Lg0KDQpJIGRpZC4gVGhleSBoYXZlIHR3byBj YXNlcy4gSW4gY2FzZSAjMSB0aGUgY29udHJvbGxlciBwcm92aXNpb25zIGNyZWRlbnRpYWxzIGZv ciBJS0UgYW5kIGVudHJpZXMgaW4gUEFEIGFuZCBTUEQuIEluIGNhc2UgIzIgeW91IGZvcmVnbyBJ S0UgYW5kIGhhdmUgdGhlIGNvbnRyb2xsZXIgcHJvdmlzaW9uIHRoZSBTQXMgKGluY2x1ZGluZyBr ZXlzKS4NCg0KSSBlc3BlY2lhbGx5IGRpZG7igJl0IGxpa2UgY2FzZSAjMi4gU2hhcmluZyBhIHNl Y3JldCBrZXkgYW1vbmcgdGhyZWUgZW50aXRpZXMgaXMgYSBiYWQgaWRlYS4gQSBzaGFyZWQgYXV0 aGVudGljYXRpb24gY3JlZGVudGlhbCBjYW4gYWxzbyBiZSBtaXN1c2VkLCBidXQgdGhhdOKAmXMg YSBoYXJkIGF0dGFjayB0byBtb3VudC4gQSBzaGFyZWQgdHJhZmZpYyBrZXkgbWFrZXMgdGhlIGNv bnRyb2xsZXIgYSB2ZXJ5IGF0dHJhY3RpdmUgdGFyZ2V0Lg0KDQpNb3JlIGluIGdlbmVyYWwsIFNE TiB3YXMgYm9ybiBpbiB0aGUgZGF0YSBjZW50ZXIuIEluIGEgZGF0YSBjZW50ZXIgYW4gYWxsLWtu b3dpbmcgY29udHJvbGxlciBtYWtlcyBzZW5zZS4gVGhpcyBpcyB0cnVlIGZvciByb3V0aW5nIGFz IGl0IGlzIGZvciBOU0ZzIHN1Y2ggYXMgZmlyZXdhbGxzLCBJRFBzIGFuZCBJRFNzLiBWUE4gZXh0 ZW5kcyB0aGUgcmVhY2ggb2YgdGhlIHByaXZhdGUgbmV0d29yayB0byBhbGwgY29ybmVycyBvZiB0 aGUgSW50ZXJuZXQuIFRoaW5rIG9mIGEgc3RvcmUgY2hhaW4gd2l0aCBhIENQRSBpbiBldmVyeSBv bmUgb2YgdGhvdXNhbmRzIG9mIGJyYW5jaGVzLiBPciBhIGJhbmsuIFRoZSBwcm9ibGVtIHRoZXJl IGlzIHRoYXQgdGhlcmUgaXMgbm8gY2VudHJhbCBhZG1pbmlzdHJhdGl2ZSBmdW5jdGlvbi4gTG9j YWwgYnJhbmNoZXMgbWF5IHN3aXRjaCBJU1AgYW5kIHJlbnVtYmVyIHRoZWlyIG5ldHdvcmsgd2l0 aG91dCBib3RoZXJpbmcgdG8gdGVsbCB0aGUgSVQgcGVvcGxlLiBTbyB0aGUgbW9kZWwgd2hlcmUg dGhlIGNvbnRyb2xsZXIga25vd3MgZXZlcnl0aGluZyBpcyB0b3VnaCB0byBkZXBsb3kgaW4gcHJh Y3RpY2UuDQoNCkl0IGlzIHByb2JhYmx5IG5lY2Vzc2FyeSB0byBoYXZlIHR3by13YXkgY29tbXVu aWNhdGlvbnMsIHdoZXJlIHRoZSBDUEUgdGVsbHMgdGhlIGNvbnRyb2xsZXIgYWJvdXQgaXRzIHRv cG9sb2d5IChob3cgaXQgcGFydGl0aW9ucyB0aGUgSW50ZXJuZXQgdG8g4oCcaW7igJ0gdnMg4oCc b3V04oCdKSBzbyB0aGF0IHRoZSBjb250cm9sbGVyIGNhbiBzZXQgdXAgdGhlIGFwcHJvcHJpYXRl IFNQRHMuDQoNClRoZXJlIGhhdmUgYmVlbiBzZXZlcmFsIGF0dGVtcHRzIGF0IHRoaXMuIFJGQyA3 MDE4IGRlc2NyaWJlcyByZXF1aXJlbWVudHMsIGJ1dCB0aGUgV0cgdWx0aW1hdGVseSBmYWlsZWQg dG8gcHVibGlzaCBhIHNvbHV0aW9uIGRvY3VtZW50LiAgVGhlcmUgYXJlIGFsc28gbW9yZSByZWNl bnQgY29tbWVyY2lhbCBzb2x1dGlvbnMgc29sZCB0b2RheSB1bmRlciB0aGUgbWFya2V0aW5nIG5h bWUgb2Yg4oCcU0QtV0FO4oCdLCB3aGljaCBpcyBzb3J0IG9mIGxpa2UgU0ROIGlmIHlvdSBzcXVp bnQgaGFyZCBlbm91Z2guIEFsbCBvZiB0aGVzZSBoYXZlIHNvbWUgaW50ZXJhY3Rpb24gYmV0d2Vl biBDUEUgYW5kIGNvbnRyb2xsZXJzIChvciBodWJzKSB3aGljaCBkcmFmdC1hYmFkIGRvZXMgbm90 Lg0KDQpZb2F2DQoNCg0K --_000_4A95BA014132FF49AE685FAB4B9F17F659272932SJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+WW9hdiwgPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5UaGFuayB5b3UgdmVyeSBtdWNoIGZvciB0aGUgcmVwbHkuIEFuZCB0aGUgdmFsdWFi bGUgY29tbWVudHMgdG8gZHJhZnQtYWJhZC1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9u LiA8L2Rpdj4NCjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PC9hPg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+WW91IHNhaWQ6PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0i cGFkZGluZy1sZWZ0OjM2cHQ7Ij48aT5ZZWFoLiBBV1MgKGFuZCBBenVyZSBhcyB3ZWxsKSB3YW50 IHlvdSB0byBoYXZlIGEgdmlydHVhbCBzZXJ2ZXIgcm9vbSBpbiB0aGVpciBjbG91ZCwgYW5kIHlv dSBjb25uZWN0IHlvdXIgSVBzZWMgdG8gYW4gQVdTIGdhdGV3YXkgaW4gdHVubmVsIG1vZGUuIFRo ZXkgYWxzbyBwcmVmZXIgdG8gZm9yZWdvIElLReKAmXMgYWJpbGl0eSB0byBuZWdvdGlhdGUgdHVu bmVsIHNlbGVjdG9ycyAodGhlDQpzZXQgb2YgYWRkcmVzc2VzIGFuZCBwcm90b2NvbHMgYmVpbmcg dHVubmVsZWQpIGFuZCBpbnN0ZWFkIG5lZ290aWF0ZSB1bml2ZXJzYWwgdHVubmVscyBhbmQgY2hv b3NlIHdoYXQgdG8gdHVubmVsIHVzaW5nIGNvbmZpZ3VyYXRpb24uIFRvIGFkZCBjb25mdXNpb24s IHRoZXkgY2FsbCB0aGlzIOKAnHJvdXRlLWJhc2VkIFZQTuKAnSBldmVuIGlmIHlvdSBkb27igJl0 IHVzZSBhIHJvdXRpbmcgcHJvdG9jb2wgYXQgYWxsLjwvaT48L2Rpdj4NCjxkaXY+PGZvbnQgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+PC9kaXY+DQo8ZGl2PldoYXQgeW91IGRl c2NyaWJlZCBpcyB0aGUgY29tbW9uIHByYWN0aWNlIHRvZGF5LCBpLmUuICBFc3RhYmxpc2hpbmcg YSB0dW5uZWwgKElQU2VjIFR1bm5lbCkgYmV0d2VlbiBBV1MgZ2F0ZXdheSBhbmQgQ2xpZW50IENQ RS4gVGhpcyBhcHByb2FjaCBub3Qgb25seSBjb3N0IGV4dHJhLCBidXQgbm90IHJlYWxseSBzZWN1 cmUsIGJlY2F1c2UgeW91ciB0cmFmZmljIGJlaGluZCBBV1MgZ2F0ZXdheSBjYW4gZXhwbG9pdGVk IGJ5IDNyZCBwYXJ0eS4NCkNvcnJlY3Q/IDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+ SXMgdGhlcmUgYW4gb3B0aW9uIGluIElQU2VjIHRoYXQgYWxsb3dzIG1lIHRvIGVzdGFibGlzaCBh IHR1bm5lbCBiZXR3ZWVuIG15IENQRSBhbmQgbXkgdmlydHVhbCByZXNvdXJjZXMgbGVhc2VkIGZy b20gQVdTIChpLmUuIHRyYW5zcGFyZW50bHkgYnktcGFzcyBBV1MgZ2F0ZXdheSk/PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRp dj5Zb3UgYWxzbyBzYWlkOjwvZGl2Pg0KPGRpdiBzdHlsZT0icGFkZGluZy1sZWZ0OjM2cHQ7Ij48 aT5UaGVyZSBhcmUgb3RoZXIgb3B0aW9ucyB3aXRoIGNsb3VkIHByb3ZpZGVycyB3aGVyZSB5b3Ug Y2FuIGluc3RhbGwgd2hhdGV2ZXIgSVBzZWMgc29mdHdhcmUgeW91IHdhbnQgb24geW91ciB2aXJ0 dWFsIHNlcnZlciwgYnV0IHRoYXQgY29zdHMgZXh0cmEuPC9pPjwvZGl2Pg0KPGRpdiBzdHlsZT0i cGFkZGluZy1sZWZ0OjM2cHQ7Ij48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwv Zm9udD48L2Rpdj4NCjxkaXY+VGhlIHNvZnR3YXJlIGlzIGNvbnRyb2xsZWQgYnkgdGhlIGNsaWVu dCwgY29ycmVjdD8gSWYgdGhlIGNsaWVudCBvd25zIHRoaXMgc29mdHdhcmUsIGl0IGRvZXNuJ3Qg cmVhbGx5IGNvc3QgZXh0cmEsIGRvZXMgaXQ/IDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+TGluZGE8L2Rpdj4NCjxkaXY+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQoNCkZy b206IFlvYXYgTmlyIFs8YSBocmVmPSJtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbSI+bWFpbHRv OnluaXIuaWV0ZkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KDQpTZW50OiBUaHVyc2RheSwgQXByaWwg MTMsIDIwMTcgNDo0MiBQTTxicj4NCg0KVG86IExpbmRhIER1bmJhciAmbHQ7bGluZGEuZHVuYmFy QGh1YXdlaS5jb20mZ3Q7PGJyPg0KDQpDYzogSVBzZWNAaWV0Zi5vcmc7IE1pY2hhZWwgUmljaGFy ZHNvbiAmbHQ7bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSZndDs8YnI+DQoNClN1YmplY3Q6IFJl OiBbSVBzZWNdIENhbiBJUFNlYyAoUkZDIDU5OTYpIHN1cHBvcnQgdHVubmVscyB3aXRoIGVuZCBw b2ludCBiZWluZyAodmlydHVhbCkgQ1BFcyB3aGljaCBoYXMgYSBzZXQgb2Ygd29ya2xvYWQgYXR0 YWNoZWQgKHNheSBWaXJ0dWFsIE1hY2hpbmVzKSBhbGwgaGF2aW5nIHZpcnR1YWwgSVAgYWRkcmVz c2VzPzwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9u dD48L2Rpdj4NCjxkaXY+SGk8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PldoYXQgTWlj aGFlbCBzYWlkLiZuYnNwOyBBZGRpdGlvbmFsIGNvbW1lbnRzIHdpdGhpbi48L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8ZGl2Pk9uIDEzIEFwciAyMDE3LCBhdCAyMjo0OCwgTWljaGFlbCBSaWNo YXJkc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSI+bWNy JiM0MztpZXRmQHNhbmRlbG1hbi5jYTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7IDwv ZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IExpbmRhIER1bmJhciAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmxpbmRhLmR1bmJhckBodWF3ZWkuY29tIj5saW5kYS5kdW5iYXJAaHVhd2VpLmNv bTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAtIFRvIHN1cHBvcnQgdGhpcywg b25lIGVuZCBwb2ludCBvZiB0aGUgdHVubmVsIHdpbGwgYmUgKHZpcnR1YWwpIENQRXMgPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7IHdoaWNoIGhhcyBhIHNldCBvZiB3b3JrbG9hZCBhdHRhY2hlZCAoc2F5 IFZpcnR1YWwgTWFjaGluZXMpLiBBbGwgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IGhhdmluZyB2aXJ0 dWFsIElQIGFkZHJlc3Nlcy4gQ2FuIElQU2VjIChSRkMgNTk5Nikgc3VwcG9ydCB0aGlzIGNvbWJp bmF0aW9uPzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBIb3c/PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj5UbyBjbGFyaWZ5LCBSRkMgNzI5NiAoYW5kIHByZXZpb3VzbHkgNTk5NikgYXJlIGZv ciBJS0V2MiwgdGhlIGtleSBleGNoYW5nZSBhbmQgYXV0aGVudGljYXRpb24gcHJvdG9jb2wuIFJG QyA0MzAxIGRlZmluZXMgSVBzZWMuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7 IEFzIGxvbmcgdGhlIGJyYW5jaCBvZmZpY2UgQ1BFIGhhcyBhIHB1YmxpYyBJUCBhZGRyZXNzLCBv ciBvbmUgaXMgPC9kaXY+DQo8ZGl2PiZndDsgd2lsbGluZyB0byBlc3RhYmxpc2ggYSBodWIgc3lz dGVtIHdpdGggYSBwdWJsaWMgSVAgYWRkcmVzcywgYWxsIHRoZSBWTXMgY2FuIGp1c3QgYmU8L2Rp dj4NCjxkaXY+Jmd0OyBjb25zaWRlcmVkIHRvIGJlaGluZCBOQVBULiZuYnNwOyZuYnNwOyBUaGlz IGlzIGRvbmUgaW4gdGhlIGZpZWxkIHJlZ3VsYXJseS48L2Rpdj4NCjxkaXY+Jmd0OyBHaXZlbiB0 aGF0IEFtYXpvbidzIElQc2VjIHR1bm5lbCBlbmQgcG9pbnRzIGNvc3QgZXh0cmEsIGFuZCBzb21l dGltZXMgPC9kaXY+DQo8ZGl2PiZndDsgaGF2ZSBzaWduaWZpY2FudCBjb21wYXRpYmlsaXR5IHBy b2JsZW1zLCB0aGlzIGlzIG9mdGVuIHRoZSBwcmVmZXJyZWQgPC9kaXY+DQo8ZGl2PiZndDsgc29s dXRpb25zIHJlZ2FyZGxlc3MuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5ZZWFoLiBB V1MgKGFuZCBBenVyZSBhcyB3ZWxsKSB3YW50IHlvdSB0byBoYXZlIGEgdmlydHVhbCBzZXJ2ZXIg cm9vbSBpbiB0aGVpciBjbG91ZCwgYW5kIHlvdSBjb25uZWN0IHlvdXIgSVBzZWMgdG8gYW4gQVdT IGdhdGV3YXkgaW4gdHVubmVsIG1vZGUuIFRoZXkgYWxzbyBwcmVmZXIgdG8gZm9yZWdvIElLReKA mXMgYWJpbGl0eSB0byBuZWdvdGlhdGUgdHVubmVsIHNlbGVjdG9ycyAodGhlIHNldCBvZiBhZGRy ZXNzZXMgYW5kIHByb3RvY29scw0KYmVpbmcgdHVubmVsZWQpIGFuZCBpbnN0ZWFkIG5lZ290aWF0 ZSB1bml2ZXJzYWwgdHVubmVscyBhbmQgY2hvb3NlIHdoYXQgdG8gdHVubmVsIHVzaW5nIGNvbmZp Z3VyYXRpb24uIFRvIGFkZCBjb25mdXNpb24sIHRoZXkgY2FsbCB0aGlzIOKAnHJvdXRlLWJhc2Vk IFZQTuKAnSBldmVuIGlmIHlvdSBkb27igJl0IHVzZSBhIHJvdXRpbmcgcHJvdG9jb2wgYXQgYWxs LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+VGhlcmUgYXJlIG90aGVyIG9wdGlvbnMg d2l0aCBjbG91ZCBwcm92aWRlcnMgd2hlcmUgeW91IGNhbiBpbnN0YWxsIHdoYXRldmVyIElQc2Vj IHNvZnR3YXJlIHlvdSB3YW50IG9uIHlvdXIgdmlydHVhbCBzZXJ2ZXIsIGJ1dCB0aGF0IGNvc3Rz IGV4dHJhLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgLSBEb2VzIHRo ZSBlbnRlcnByaXNlIHdobyBsZWFzZSB2aXJ0dWFsIHJlc291cmNlIGZyb20gM3JkIHBhcnR5IGRh dGEgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IGNlbnRlciBoYXZlIHRvIGhhdmUgYSBwdWJsaWMgcm91 dGFibGUgSVAgYWRkcmVzcyB0byBlc3RhYmxpc2ggSVBzZWMgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 IHR1bm5lbCBiZXR3ZWVuIGJyYW5jaCBvZmZpY2VzIGFuZCB0aGUgKHZpcnR1YWwpIGdhdGV3YXkg aW4gdGhlIDNyZCA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgcGFydHkgREM/PC9kaXY+DQo8ZGl2PiZn dDsgPC9kaXY+DQo8ZGl2PiZndDsgTm90IGFsd2F5cywgbm8uPC9kaXY+DQo8ZGl2PiZndDsgPC9k aXY+DQo8ZGl2PiZndDsmZ3Q7IC0gSXMgdGhlcmUgYW55IGxpbWl0YXRpb24gKGkuZS4gdGhlIG1h eGltdW0gbnVtYmVyIG9mIElQU2VjIHNlc3Npb25zKSA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgdGhh dCBhIHNlcnZlciBjYW4gc3VwcG9ydD88L2Rpdj4NCjxkaXY+Jmd0OyA8L2Rpdj4NCjxkaXY+Jmd0 OyBEZXBlbmRzIHVwb24gcmFtIGFuZCBuZXR3b3JrIHNwZWVkLjwvZGl2Pg0KPGRpdj4mZ3Q7IElu IGdlbmVyYWwsIHRoZSBsaW1pdHMgYXJlIHF1aXRlIGhpZ2guPC9kaXY+DQo8ZGl2PiZndDsgV2Ug aGF2ZSBjb25maWd1cmVkIHN5c3RlbXMgd2l0aCAzMDAwIHR1bm5lbHMgZnJvbSBtdWx0aXBseS1O QVQnZWQgSW9UIDwvZGl2Pg0KPGRpdj4mZ3Q7IGRldmljZXMgaW4gdGhlIGZpZWxkLiZuYnNwOyAz MDAwIHdhcyBjaG9zZW4gYXMgYSBzb2Z0IGxpbWl0IHBlciBnYXRld2F5IDwvZGl2Pg0KPGRpdj4m Z3Q7IG1hY2hpbmUgZHVlIHRvIGFudGljaXBhdGVkIHRyYWZmaWMgbG9hZCB2cyBzcGVlZCBmb3Ig dmlydHVhbCBkZXZpY2VzLjwvZGl2Pg0KPGRpdj4mZ3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IEl0J3Mg V0FZIGVhc2llciB3aXRoIElLRXYyIGFuZCBwdXR0aW5nIElQdjYgaW5zaWRlLCBidXQgbWFueSBj dXN0b21lcnMgPC9kaXY+DQo8ZGl2PiZndDsgYXJlIGFmcmFpZCBvZiB0aGlzIGJlY2F1c2UgdGhl eSBoYXZlIGxpdHRsZSBleHBlcmllbmNlIHdpdGggSVB2Ni48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9k aXY+DQo8ZGl2PlllYWguIEdhdGV3YXlzIHJvdXRpbmVseSBtYW5hZ2UgdGhvdXNhbmRzIG9yIHRl bnMgb2YgdGhvdXNhbmRzIG9mIHR1bm5lbHMgb24gY29tbW9kaXR5IGhhcmR3YXJlLiBJdHMgdXN1 YWxseSB0aGUgYW1vdW50IG9mIElQc2VjIHRyYWZmaWMgdGhhdCBiZWNvbWVzIHRoZSBib3R0bGVu ZWNrLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgLSBJcyB0aGVyZSBh bnkgYWR2YW50YWdlcyBvZiBJUHNlYyBDb21wYXJpbmcgd2l0aCB1c2luZyBUTFM/IERvZXMgVExT IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBwcm92aWRlIFR1bm5lbCBtb2RlPzwvZGl2Pg0KPGRpdj4m Z3Q7IDwvZGl2Pg0KPGRpdj4mZ3Q7IFRoZXJlIGlzIG5vIElFVEYgc3RhbmRhcmQgVExTLWJhc2Vk IFZQTi4mbmJzcDsgVGhlcmUgYXJlIGRvemVucyBvZiA8L2Rpdj4NCjxkaXY+Jmd0OyBwcm9wcmll dGFyeSBzdGFja3MsIGluY2x1ZGluZyB0aGUgdmVyeSBwb3B1bGFyIE9wZW5WUE4uPC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5BbmQgYWxsIG9mIHRob3NlIHByb3ByaWV0YXJ5IHN0YWNr cyBhcmUgdXNlZCBwcmltYXJpbHkgZm9yIHRoZSByZW1vdGUtYWNjZXNzIC8gcm9hZC13YXJyaW9y IHNjZW5hcmlvLiBIYXJkbHkgYW55b25lIHVzZXMgdGhlbSBmb3Igc2l0ZS10by1zaXRlLjwvZGl2 Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgLSBJMk5TRiBoYXMgYSBwcm9wb3Nh bCBvbiB1c2luZyBDb250cm9sbGVyIHRvIG1hbmFnZXIgYWxsIHRoZSBJUFNlYzwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyB0dW5uZWxzOjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWFiYWQtaTJuc2Ytc2RuLWlwc2Vj LWZsb3ctcHJvdGVjdGlvbiI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1hYmFkLWkybnNmLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb248L2E+LjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyBXaGF0IGtpbmQgb2YgaXNzdWVzIGRvIHlvdSBzZWUgd2l0aCB0aGUgcHJvcG9z ZWQgYXBwcm9hY2g/PC9kaXY+DQo8ZGl2PiZndDsgPC9kaXY+DQo8ZGl2PiZndDsgSSBkaWRuJ3Qg cmVhZCBpdC48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkkgZGlkLiBUaGV5IGhhdmUg dHdvIGNhc2VzLiBJbiBjYXNlICMxIHRoZSBjb250cm9sbGVyIHByb3Zpc2lvbnMgY3JlZGVudGlh bHMgZm9yIElLRSBhbmQgZW50cmllcyBpbiBQQUQgYW5kIFNQRC4gSW4gY2FzZSAjMiB5b3UgZm9y ZWdvIElLRSBhbmQgaGF2ZSB0aGUgY29udHJvbGxlciBwcm92aXNpb24gdGhlIFNBcyAoaW5jbHVk aW5nIGtleXMpLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+SSBlc3BlY2lhbGx5IGRp ZG7igJl0IGxpa2UgY2FzZSAjMi4gU2hhcmluZyBhIHNlY3JldCBrZXkgYW1vbmcgdGhyZWUgZW50 aXRpZXMgaXMgYSBiYWQgaWRlYS4gQSBzaGFyZWQgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbCBj YW4gYWxzbyBiZSBtaXN1c2VkLCBidXQgdGhhdOKAmXMgYSBoYXJkIGF0dGFjayB0byBtb3VudC4g QSBzaGFyZWQgdHJhZmZpYyBrZXkgbWFrZXMgdGhlIGNvbnRyb2xsZXIgYSB2ZXJ5IGF0dHJhY3Rp dmUgdGFyZ2V0LjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+TW9yZSBpbiBnZW5lcmFs LCBTRE4gd2FzIGJvcm4gaW4gdGhlIGRhdGEgY2VudGVyLiBJbiBhIGRhdGEgY2VudGVyIGFuIGFs bC1rbm93aW5nIGNvbnRyb2xsZXIgbWFrZXMgc2Vuc2UuIFRoaXMgaXMgdHJ1ZSBmb3Igcm91dGlu ZyBhcyBpdCBpcyBmb3IgTlNGcyBzdWNoIGFzIGZpcmV3YWxscywgSURQcyBhbmQgSURTcy4gVlBO IGV4dGVuZHMgdGhlIHJlYWNoIG9mIHRoZSBwcml2YXRlIG5ldHdvcmsgdG8gYWxsIGNvcm5lcnMg b2YgdGhlIEludGVybmV0Lg0KVGhpbmsgb2YgYSBzdG9yZSBjaGFpbiB3aXRoIGEgQ1BFIGluIGV2 ZXJ5IG9uZSBvZiB0aG91c2FuZHMgb2YgYnJhbmNoZXMuIE9yIGEgYmFuay4gVGhlIHByb2JsZW0g dGhlcmUgaXMgdGhhdCB0aGVyZSBpcyBubyBjZW50cmFsIGFkbWluaXN0cmF0aXZlIGZ1bmN0aW9u LiBMb2NhbCBicmFuY2hlcyBtYXkgc3dpdGNoIElTUCBhbmQgcmVudW1iZXIgdGhlaXIgbmV0d29y ayB3aXRob3V0IGJvdGhlcmluZyB0byB0ZWxsIHRoZSBJVCBwZW9wbGUuIFNvIHRoZQ0KbW9kZWwg d2hlcmUgdGhlIGNvbnRyb2xsZXIga25vd3MgZXZlcnl0aGluZyBpcyB0b3VnaCB0byBkZXBsb3kg aW4gcHJhY3RpY2UuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JdCBpcyBwcm9iYWJs eSBuZWNlc3NhcnkgdG8gaGF2ZSB0d28td2F5IGNvbW11bmljYXRpb25zLCB3aGVyZSB0aGUgQ1BF IHRlbGxzIHRoZSBjb250cm9sbGVyIGFib3V0IGl0cyB0b3BvbG9neSAoaG93IGl0IHBhcnRpdGlv bnMgdGhlIEludGVybmV0IHRvIOKAnGlu4oCdIHZzIOKAnG91dOKAnSkgc28gdGhhdCB0aGUgY29u dHJvbGxlciBjYW4gc2V0IHVwIHRoZSBhcHByb3ByaWF0ZSBTUERzLjwvZGl2Pg0KPGRpdj4mbmJz cDs8L2Rpdj4NCjxkaXY+VGhlcmUgaGF2ZSBiZWVuIHNldmVyYWwgYXR0ZW1wdHMgYXQgdGhpcy4g UkZDIDcwMTggZGVzY3JpYmVzIHJlcXVpcmVtZW50cywgYnV0IHRoZSBXRyB1bHRpbWF0ZWx5IGZh aWxlZCB0byBwdWJsaXNoIGEgc29sdXRpb24gZG9jdW1lbnQuJm5ic3A7IFRoZXJlIGFyZSBhbHNv IG1vcmUgcmVjZW50IGNvbW1lcmNpYWwgc29sdXRpb25zIHNvbGQgdG9kYXkgdW5kZXIgdGhlIG1h cmtldGluZyBuYW1lIG9mIOKAnFNELVdBTuKAnSwgd2hpY2ggaXMgc29ydCBvZiBsaWtlDQpTRE4g aWYgeW91IHNxdWludCBoYXJkIGVub3VnaC4gQWxsIG9mIHRoZXNlIGhhdmUgc29tZSBpbnRlcmFj dGlvbiBiZXR3ZWVuIENQRSBhbmQgY29udHJvbGxlcnMgKG9yIGh1YnMpIHdoaWNoIGRyYWZ0LWFi YWQgZG9lcyBub3QuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5Zb2F2PC9kaXY+DQo8 ZGl2Pjxmb250IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250PjwvZGl2Pg0KPGRp dj48Zm9udCBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD48L2Rpdj4NCjwvc3Bh bj48L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F659272932SJCEML702CHMchi_-- From nobody Thu Apr 13 21:03:30 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997481293EE for ; Thu, 13 Apr 2017 21:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGSQv2u_XJeH for ; Thu, 13 Apr 2017 21:03:26 -0700 (PDT) Received: from mail-wr0-x22e.google.com (mail-wr0-x22e.google.com [IPv6:2a00:1450:400c:c0c::22e]) (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 B72331243F6 for ; Thu, 13 Apr 2017 21:03:25 -0700 (PDT) Received: by mail-wr0-x22e.google.com with SMTP id o21so45495661wrb.2 for ; Thu, 13 Apr 2017 21:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DjnVAAvEWY6KFvWFtDv4Dhsr3d32toOV0e1oLmILcLI=; b=VgVYpAS//Ah8SRDPBN1V3Uln6K3Mhm9dwmSfxbiiRCFwaReaQFTq7DusuXmZhsrlSU P3xc1Gp70gkSrxNTvBh7Ege6/MSlM7qVnhmVwWmQdKrgYgC6rLGM3zKnY332OZ3yiz5K RfD8+04zVUCOSHh9TZwIuWRqNqY9yGDD4bhv7nH16fndWW0wXowjKW3fGvd/FWCJyF/Q I8QugadJx33KBQWZ48CNhZRa146mFMNUU/KNDKnRV7tOewhjNeGxiHCTibWBSeDBjktt LYT7GUGkFHlc4542absa6XgVmn6rUMYaddSCl22UfDr4RaR8k88FdSINs0N7femm0zjm HtkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DjnVAAvEWY6KFvWFtDv4Dhsr3d32toOV0e1oLmILcLI=; b=CvIKY4WunwVouOcTtQD19Eovwcs3+OHINtitBLJV9vdz+eEntQkPD1SCUhDAClJkIV NNtxhiIjy4FuCYoiL2yqI0QX4hhVyGyGV97Y88EIoi9HdovHsz9EiU4YGqsLAGIYZAgg 2Orvb0USwcLGvA15l/7lwWrKKMfS1N0dKM3g+kFutrmSs4VMlYpaiP6nFbSZHUb6uW5L xoFpKQt/FynhgHagIw0vt7S/ceiPEp/5PHd5SOlmZ3WmkHtx2eJ9jgTP9H3K6d/Czdg+ jmkFM55zTx6eiXgsMRmJt9blnFLyUfsuODARNR7rerUt4N3p9xUxivCTcVN62iCnVhUn P93w== X-Gm-Message-State: AN3rC/6zh2wONlgNFivPfukGlHHmOXFPKEhW0LztYDWd/OTbifq301GJ IkyfmDsfrH0iVNugtbc= X-Received: by 10.223.160.241 with SMTP id n46mr3494080wrn.201.1492142604186; Thu, 13 Apr 2017 21:03:24 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id j32sm798926wre.67.2017.04.13.21.03.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Apr 2017 21:03:23 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1DE53DED-3D37-49DF-B144-EAF6AA782020"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 14 Apr 2017 07:03:20 +0300 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F659272932@SJCEML702-CHM.china.huawei.com> Cc: "IPsec@ietf.org" , Michael Richardson To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> <4A95BA014132FF49AE685FAB4B9F17F659272932@SJCEML702-CHM.china.huawei.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 04:03:29 -0000 --Apple-Mail=_1DE53DED-3D37-49DF-B144-EAF6AA782020 Content-Type: multipart/alternative; boundary="Apple-Mail=_E12822B8-9225-4FAD-87B4-A5336245F5E1" --Apple-Mail=_E12822B8-9225-4FAD-87B4-A5336245F5E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 14 Apr 2017, at 1:26, Linda Dunbar wrote: >=20 > Yoav, >=20 > Thank you very much for the reply. And the valuable comments to = draft-abad-i2nsf-sdn-ipsec-flow-protection. > <> > You said: >=20 > Yeah. AWS (and Azure as well) want you to have a virtual server room = in their cloud, and you connect your IPsec to an AWS gateway in tunnel = mode. They also prefer to forego IKE=E2=80=99s ability to negotiate = tunnel selectors (the set of addresses and protocols being tunneled) and = instead negotiate universal tunnels and choose what to tunnel using = configuration. To add confusion, they call this =E2=80=9Croute-based = VPN=E2=80=9D even if you don=E2=80=99t use a routing protocol at all. >=20 > What you described is the common practice today, i.e. Establishing a = tunnel (IPSec Tunnel) between AWS gateway and Client CPE. This approach = not only cost extra, but not really secure, because your traffic behind = AWS gateway can exploited by 3rd party. Correct? Yes, the cloud provider in this case has access to the plain-text. > Is there an option in IPSec that allows me to establish a tunnel = between my CPE and my virtual resources leased from AWS (i.e. = transparently by-pass AWS gateway)? Sure. IPsec can be established between any two nodes on the Internet as = long as there=E2=80=99s reachability between them. If there=E2=80=99s = only one-way reachability (say, if one is behind a NAPT) then the tunnel = has to be established one way, but after that traffic can flow in both = directions. If there=E2=80=99s no reachability (if both are behind = different NAPT) then they can=E2=80=99t communicate directly, but a = hub-and-spoke scenario where they=E2=80=99re traffic passes through a = third gateway that decrypts and re-encrypts is still possible. It=E2=80=99= s all a matter of configuration. > You also said: > There are other options with cloud providers where you can install = whatever IPsec software you want on your virtual server, but that costs = extra. >=20 > The software is controlled by the client, correct? If the client owns = this software, it doesn't really cost extra, does it? I=E2=80=99ve never actually bought cloud service, but as far as I know = getting =E2=80=9Cjust a web server=E2=80=9D or =E2=80=9Ca web server and = a database=E2=80=9D is cheaper (and scales better) then getting full = access to a Linux VM where you can install stuff. There might also be a = firewall preventing some sorts of traffic to the VM, but I don=E2=80=99t = know much about it. Yoav >=20 > Linda > -----Original Message----- > From: Yoav Nir [mailto:ynir.ietf@gmail.com = ] > Sent: Thursday, April 13, 2017 4:42 PM > To: Linda Dunbar > Cc: IPsec@ietf.org; Michael Richardson > Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end = point being (virtual) CPEs which has a set of workload attached (say = Virtual Machines) all having virtual IP addresses? >=20 > Hi >=20 > What Michael said. Additional comments within. >=20 > On 13 Apr 2017, at 22:48, Michael Richardson > wrote: > > > > > > Linda Dunbar > wrote: > >> - To support this, one end point of the tunnel will be (virtual) = CPEs > >> which has a set of workload attached (say Virtual Machines). All > >> having virtual IP addresses. Can IPSec (RFC 5996) support this = combination? > >> How? >=20 > To clarify, RFC 7296 (and previously 5996) are for IKEv2, the key = exchange and authentication protocol. RFC 4301 defines IPsec. >=20 > > As long the branch office CPE has a public IP address, or one is > > willing to establish a hub system with a public IP address, all the = VMs can just be > > considered to behind NAPT. This is done in the field regularly. > > Given that Amazon's IPsec tunnel end points cost extra, and = sometimes > > have significant compatibility problems, this is often the preferred > > solutions regardless. >=20 > Yeah. AWS (and Azure as well) want you to have a virtual server room = in their cloud, and you connect your IPsec to an AWS gateway in tunnel = mode. They also prefer to forego IKE=E2=80=99s ability to negotiate = tunnel selectors (the set of addresses and protocols being tunneled) and = instead negotiate universal tunnels and choose what to tunnel using = configuration. To add confusion, they call this =E2=80=9Croute-based = VPN=E2=80=9D even if you don=E2=80=99t use a routing protocol at all. >=20 > There are other options with cloud providers where you can install = whatever IPsec software you want on your virtual server, but that costs = extra. >=20 > >> - Does the enterprise who lease virtual resource from 3rd party = data > >> center have to have a public routable IP address to establish IPsec > >> tunnel between branch offices and the (virtual) gateway in the 3rd > >> party DC? > > > > Not always, no. > > > >> - Is there any limitation (i.e. the maximum number of IPSec = sessions) > >> that a server can support? > > > > Depends upon ram and network speed. > > In general, the limits are quite high. > > We have configured systems with 3000 tunnels from multiply-NAT'ed = IoT > > devices in the field. 3000 was chosen as a soft limit per gateway > > machine due to anticipated traffic load vs speed for virtual = devices. > > > > It's WAY easier with IKEv2 and putting IPv6 inside, but many = customers > > are afraid of this because they have little experience with IPv6. >=20 > Yeah. Gateways routinely manage thousands or tens of thousands of = tunnels on commodity hardware. Its usually the amount of IPsec traffic = that becomes the bottleneck. >=20 > >> - Is there any advantages of IPsec Comparing with using TLS? Does = TLS > >> provide Tunnel mode? > > > > There is no IETF standard TLS-based VPN. There are dozens of > > proprietary stacks, including the very popular OpenVPN. >=20 > And all of those proprietary stacks are used primarily for the = remote-access / road-warrior scenario. Hardly anyone uses them for = site-to-site. >=20 > >> - I2NSF has a proposal on using Controller to manager all the IPSec > >> tunnels: > >> = https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-prot= ection = . > >> What kind of issues do you see with the proposed approach? > > > > I didn't read it. >=20 > I did. They have two cases. In case #1 the controller provisions = credentials for IKE and entries in PAD and SPD. In case #2 you forego = IKE and have the controller provision the SAs (including keys). >=20 > I especially didn=E2=80=99t like case #2. Sharing a secret key among = three entities is a bad idea. A shared authentication credential can = also be misused, but that=E2=80=99s a hard attack to mount. A shared = traffic key makes the controller a very attractive target. >=20 > More in general, SDN was born in the data center. In a data center an = all-knowing controller makes sense. This is true for routing as it is = for NSFs such as firewalls, IDPs and IDSs. VPN extends the reach of the = private network to all corners of the Internet. Think of a store chain = with a CPE in every one of thousands of branches. Or a bank. The problem = there is that there is no central administrative function. Local = branches may switch ISP and renumber their network without bothering to = tell the IT people. So the model where the controller knows everything = is tough to deploy in practice. >=20 > It is probably necessary to have two-way communications, where the CPE = tells the controller about its topology (how it partitions the Internet = to =E2=80=9Cin=E2=80=9D vs =E2=80=9Cout=E2=80=9D) so that the controller = can set up the appropriate SPDs. >=20 > There have been several attempts at this. RFC 7018 describes = requirements, but the WG ultimately failed to publish a solution = document. There are also more recent commercial solutions sold today = under the marketing name of =E2=80=9CSD-WAN=E2=80=9D, which is sort of = like SDN if you squint hard enough. All of these have some interaction = between CPE and controllers (or hubs) which draft-abad does not. >=20 > Yoav --Apple-Mail=_E12822B8-9225-4FAD-87B4-A5336245F5E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 14 Apr 2017, at 1:26, Linda Dunbar <linda.dunbar@huawei.com> wrote:

Yoav, 
 
Thank you very much for the = reply. And the valuable comments to = draft-abad-i2nsf-sdn-ipsec-flow-protection.
 
You said:
 
Yeah. AWS (and = Azure as well) want you to have a virtual server room in their cloud, = and you connect your IPsec to an AWS gateway in tunnel mode. They also = prefer to forego IKE=E2=80=99s ability to negotiate tunnel selectors = (the set of addresses and protocols being tunneled) and instead = negotiate universal tunnels and choose what to tunnel using = configuration. To add confusion, they call this =E2=80=9Croute-based = VPN=E2=80=9D even if you don=E2=80=99t use a routing protocol at = all.
 
What you described is the = common practice today, i.e. Establishing a tunnel (IPSec Tunnel) between = AWS gateway and Client CPE. This approach not only cost extra, but not = really secure, because your traffic behind AWS gateway can exploited by = 3rd party. Correct?

Yes, the cloud provider in this case has access to the = plain-text.

Is = there an option in IPSec that allows me to establish a tunnel between my = CPE and my virtual resources leased from AWS (i.e. transparently by-pass = AWS gateway)?

Sure. IPsec can be established between any two nodes on = the Internet as long as there=E2=80=99s reachability between them. If = there=E2=80=99s only one-way reachability (say, if one is behind a NAPT) = then the tunnel has to be established one way, but after that traffic = can flow in both directions. If there=E2=80=99s no reachability (if both = are behind different NAPT) then they can=E2=80=99t communicate directly, = but a hub-and-spoke scenario where they=E2=80=99re traffic passes = through a third gateway that decrypts and re-encrypts is still possible. = It=E2=80=99s all a matter of configuration.

You also = said:
There are other options with cloud providers where you can = install whatever IPsec software you want on your virtual server, but = that costs extra.
 
The software is controlled = by the client, correct? If the client owns this software, it doesn't = really cost extra, does it?

I=E2=80=99ve never actually bought cloud service, but = as far as I know getting =E2=80=9Cjust a web server=E2=80=9D or =E2=80=9Ca= web server and a database=E2=80=9D is cheaper (and scales better) then = getting full access to a Linux VM where you can install stuff. There = might also be a firewall preventing some sorts of traffic to the VM, but = I don=E2=80=99t know much about it.

Yoav

 
Linda
-----Original Message-----
From: Yoav Nir [mailto:ynir.ietf@gmail.com] 
Sent: = Thursday, April 13, 2017 4:42 PM
To: Linda Dunbar <linda.dunbar@huawei.com>
Cc: IPsec@ietf.org; Michael = Richardson <mcr+ietf@sandelman.ca>
Subject: Re: = [IPsec] Can IPSec (RFC 5996) support tunnels with end point being = (virtual) CPEs which has a set of workload attached (say Virtual = Machines) all having virtual IP addresses?
 
Hi
 
What = Michael said.  Additional comments within.
 
On 13 Apr 2017, at 22:48, Michael = Richardson <mcr+ietf@sandelman.ca> wrote:
>
>
> = Linda Dunbar <linda.dunbar@huawei.com> wrote:
>> - To support this, one end point of the tunnel will = be (virtual) CPEs
>> which has a set of = workload attached (say Virtual Machines). All
>> having virtual IP addresses. Can IPSec (RFC 5996) = support this combination?
>> How?
 
To clarify, RFC 7296 (and = previously 5996) are for IKEv2, the key exchange and authentication = protocol. RFC 4301 defines IPsec.
 
> As long the branch office CPE has a public IP address, = or one is
> willing to establish a hub system = with a public IP address, all the VMs can just be
> considered to behind NAPT.   This is done in = the field regularly.
> Given that Amazon's IPsec = tunnel end points cost extra, and sometimes
> = have significant compatibility problems, this is often the = preferred
> solutions regardless.
 
Yeah. AWS (and Azure as well) = want you to have a virtual server room in their cloud, and you connect = your IPsec to an AWS gateway in tunnel mode. They also prefer to forego = IKE=E2=80=99s ability to negotiate tunnel selectors (the set of = addresses and protocols being tunneled) and instead negotiate universal = tunnels and choose what to tunnel using configuration. To add confusion, = they call this =E2=80=9Croute-based VPN=E2=80=9D even if you don=E2=80=99t= use a routing protocol at all.
 
There are other options with cloud providers where you can = install whatever IPsec software you want on your virtual server, but = that costs extra.
 
>> - Does the enterprise who lease virtual resource = from 3rd party data
>> center have to have a = public routable IP address to establish IPsec
>> tunnel between branch offices and the (virtual) = gateway in the 3rd
>> party DC?
>
> Not always, no.
>
>> - Is there any limitation = (i.e. the maximum number of IPSec sessions)
>> = that a server can support?
>
> Depends upon ram and network speed.
> In general, the limits are quite high.
> We have configured systems with 3000 tunnels from = multiply-NAT'ed IoT
> devices in the = field.  3000 was chosen as a soft limit per gateway 
> = machine due to anticipated traffic load vs speed for virtual = devices.
>
> It's WAY = easier with IKEv2 and putting IPv6 inside, but many customers
> are afraid of this because they have little experience = with IPv6.
 
Yeah. = Gateways routinely manage thousands or tens of thousands of tunnels on = commodity hardware. Its usually the amount of IPsec traffic that becomes = the bottleneck.
 
>> = - Is there any advantages of IPsec Comparing with using TLS? Does = TLS
>> provide Tunnel mode?
>
> There is no IETF standard = TLS-based VPN.  There are dozens of 
> = proprietary stacks, including the very popular OpenVPN.
 
And all of those proprietary = stacks are used primarily for the remote-access / road-warrior scenario. = Hardly anyone uses them for site-to-site.
 
>> - I2NSF has a proposal = on using Controller to manager all the IPSec
>>= tunnels:
>> https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipse= c-flow-protection.
>> What kind of issues = do you see with the proposed approach?
>
> I didn't read it.
 
I did. They have two cases. In case #1 the controller = provisions credentials for IKE and entries in PAD and SPD. In case #2 = you forego IKE and have the controller provision the SAs (including = keys).
 
I especially = didn=E2=80=99t like case #2. Sharing a secret key among three entities = is a bad idea. A shared authentication credential can also be misused, = but that=E2=80=99s a hard attack to mount. A shared traffic key makes = the controller a very attractive target.
 
More in general, SDN was born in = the data center. In a data center an all-knowing controller makes sense. = This is true for routing as it is for NSFs such as firewalls, IDPs and = IDSs. VPN extends the reach of the private network to all corners of the = Internet. Think of a store chain with a CPE in every one of thousands of = branches. Or a bank. The problem there is that there is no central = administrative function. Local branches may switch ISP and renumber = their network without bothering to tell the IT people. So the model = where the controller knows everything is tough to deploy in = practice.
 
It is = probably necessary to have two-way communications, where the CPE tells = the controller about its topology (how it partitions the Internet to = =E2=80=9Cin=E2=80=9D vs =E2=80=9Cout=E2=80=9D) so that the controller = can set up the appropriate SPDs.
 
There have been several attempts at this. RFC 7018 describes = requirements, but the WG ultimately failed to publish a solution = document.  There are also more recent commercial solutions sold = today under the marketing name of =E2=80=9CSD-WAN=E2=80=9D, which is = sort of like SDN if you squint hard enough. All of these have some = interaction between CPE and controllers (or hubs) which draft-abad does = not.
 
Yoav

= --Apple-Mail=_E12822B8-9225-4FAD-87B4-A5336245F5E1-- --Apple-Mail=_1DE53DED-3D37-49DF-B144-EAF6AA782020 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY8EoJAAoJELhJCxUKWMyZGaYH/1zkZ/otl2cIvNF9btXHuPDO bXvW17dV62Uv9jqQlu63juoJul9ViX/qp0twRu4lxW39zSEZQ5hKJhFPnnl2KCZ5 3SlAGHXfJly9lsg8Xtv9nX01BJTNGohoR99i4ea2v4JjhcmGteSzk0yxwsbWoCjr Uf4iOqQNLrLpLbK1FFe2YF77ElG/Sxn7c8MMiTHrHQJhdC/t8Nn59qdZwWhPeTaR S29NyRYuGlveHi+HJTMSM7l7sLgYr4/1ObHlljYfePXL3gtRUAk7dGJdBbsmlgV5 QQolMOklnWhc7Y0xHHJfSVxRNwdr9zVXjZp2QpN70koVF1T4CPj1Om6VWjd/BQE= =3ol7 -----END PGP SIGNATURE----- --Apple-Mail=_1DE53DED-3D37-49DF-B144-EAF6AA782020-- From nobody Fri Apr 14 10:05:59 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B32129514 for ; Fri, 14 Apr 2017 10:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNxeQt7MPLvi for ; Fri, 14 Apr 2017 10:05:56 -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 73CC612946C for ; Fri, 14 Apr 2017 10:05:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C5E90203B8; Fri, 14 Apr 2017 13:30:45 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5680A636BB; Fri, 14 Apr 2017 13:05:55 -0400 (EDT) From: Michael Richardson To: Linda Dunbar cc: "IPsec\@ietf.org" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6592728FF@SJCEML702-CHM.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <4A95BA014132FF49AE685FAB4B9F17F6592728FF@SJCEML702-CHM.china.huawei.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 17:05:58 -0000 --=-=-= Content-Type: text/plain mcr> As long the branch office CPE has a public IP address, or one is willing mcr> to establish a hub system with a public IP address, all the VMs can just mcr> be considered to behind NAPT. linda> Is the "INTERNAL_IP4_ADDRESS" in RFC5996 intended for establishing linda> IPSec tunnel between remote VMs behind NAPT (all VMs have the virtual linda> IP address)? This is used when transport mode is used through a NAPT. It doesn't apply to tunnel mode. linda> Does the CPE (with Public IP address) still need to know the NAT linda> public IP address (even though the IPsec tunnel goes through the NAT linda> to the VMs behind the NAT)? If I understood the question, the answer is No. linda> Possible to have one IPSec tunnel with multiple VMs end points? linda> (i.e. 1<-> N tunnel: A tunnel with one CPE on one end and many VMs on linda> the other end)? A single IPsec (4301) tunnel can service traffic between two subnets. In IKEv2, we use negotiate ranges (which is a super concept) rather than subnets. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljxAXMACgkQgItw+93Q 3WUEAggApdzi1DWbYJj5ETa6ID2prDvu8sWf4DbsayBOPMPOLcCjg2xZaGErMnmZ lw1E+9vwoTqJ4IEK5aO+8iUSaT3ZswEqtK2Nhgza81cVVbqtUKAS74KNJEZIBxYN zWT0H1mOz5N2RKOQgOAeqJzM6V9bCV2N+KqrtMT8JJ2/Fgz3jxd44TyzYQ/vdy7P pkm3CQoBM6fLD7ixv1TIYnxx53cMWyUKx/M/RhUauuLyLqh4Q998Pl3VgNgIuGjX siykek+cE4UkQG5MhDDegPtzQnxhPafF8gH3uQ9JmbGWfMhChPmHiSt2f6diKHrP t17M3WcLUH/V9S/BmAMclIobIJnEXg== =wGH4 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Apr 15 12:44:04 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D655112946E; Sat, 15 Apr 2017 12:43:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149228543583.17779.8937545848846052428@ietfa.amsl.com> Date: Sat, 15 Apr 2017 12:43:55 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Apr 2017 19:43:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet Key Exchange (IKEv2) Author : Yoav Nir Filename : draft-ietf-ipsecme-eddsa-03.txt Pages : 5 Date : 2017-04-15 Abstract: This document describes the use of the Edwards-curve digital signature algorithm in the IKEv2 protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-eddsa/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ipsecme-eddsa-03 https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-eddsa-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-eddsa-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 18 05:03:58 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 501D612EB3F for ; Tue, 18 Apr 2017 05:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SO23MKeTd1mr for ; Tue, 18 Apr 2017 05:03:48 -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 47A8612EB46 for ; Tue, 18 Apr 2017 05:03:48 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3IC3Z0d010126 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Apr 2017 15:03:35 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3IC3Yq6003667; Tue, 18 Apr 2017 15:03:34 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22774.150.371050.530876@fireball.acr.fi> Date: Tue, 18 Apr 2017 15:03:34 +0300 From: Tero Kivinen To: Michael Richardson Cc: Linda Dunbar , "IPsec\@ietf.org" In-Reply-To: <14744.1492189555@obiwan.sandelman.ca> References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <4A95BA014132FF49AE685FAB4B9F17F6592728FF@SJCEML702-CHM.china.huawei.com> <14744.1492189555@obiwan.sandelman.ca> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 6 min Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 12:03:56 -0000 Michael Richardson writes: > linda> Is the "INTERNAL_IP4_ADDRESS" in RFC5996 intended for establishing > linda> IPSec tunnel between remote VMs behind NAPT (all VMs have the virtual > linda> IP address)? > This is used when transport mode is used through a NAPT. > It doesn't apply to tunnel mode. Actually not completely accurate. It is used when the road warrior connects to the enterprise network, and wants to have IP-address assigned to it so it can have internal ip-address it can use to communicate with devices in that network. I.e., when you connect to your laptop to enterprise SGW, the SGW can assign you INTERNAL_IP4_ADDRESS of 10.0.1.22, and then you use that address as your source IP when you send packets to the enterprise network, and the SGW will take care that return packets sent to that address is deliver back to you. In that case you still use tunnel mode IPsec, as the outer IP headers of the Child SA is your outer public IP-address (or public address of your NAT box, if you are behind NAT), and the SGWs address. > linda> Possible to have one IPSec tunnel with multiple VMs end points? > linda> (i.e. 1<-> N tunnel: A tunnel with one CPE on one end and many VMs on > linda> the other end)? > > A single IPsec (4301) tunnel can service traffic between two subnets. > In IKEv2, we use negotiate ranges (which is a super concept) rather than > subnets. One IPsec tunnel goes between two hosts, so connection would be between SGW and the one VM. Inside that tunnel there can be multiple Child SAs each carrying traffic inside them as specified by the traffic selector (which could be subnet to subnet or single IP to single IP, whatever is needed). You cannot have one IPsec tunnel to be going to two different VM devices on the cloud provides side. You need to different IPsec tunnels, one for each host. -- kivinen@iki.fi From nobody Tue Apr 18 06:22:28 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E78912EBF0 for ; Tue, 18 Apr 2017 06:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hLH8qmBZW48 for ; Tue, 18 Apr 2017 06:22:25 -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 A4BF612EBED for ; Tue, 18 Apr 2017 06:22:24 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 80CC1203CA; Tue, 18 Apr 2017 09:47:27 -0400 (EDT) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CF7C6636BB; Tue, 18 Apr 2017 09:22:23 -0400 (EDT) From: Michael Richardson To: Tero Kivinen cc: Linda Dunbar , "IPsec\@ietf.org" In-Reply-To: <22774.150.371050.530876@fireball.acr.fi> References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <4A95BA014132FF49AE685FAB4B9F17F6592728FF@SJCEML702-CHM.china.huawei.com> <14744.1492189555@obiwan.sandelman.ca> <22774.150.371050.530876@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 13:22:26 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: linda> Possible to have one IPSec tunnel with multiple VMs end points? linda> (i.e. 1<-> N tunnel: A tunnel with one CPE on one end and many VMs linda> on the other end)? >> A single IPsec (4301) tunnel can service traffic between two subnets. >> In IKEv2, we use negotiate ranges (which is a super concept) rather >> than subnets. > One IPsec tunnel goes between two hosts, so connection would be between > SGW and the one VM. Inside that tunnel there can be multiple Child SAs > each carrying traffic inside them as specified by the traffic selector > (which could be subnet to subnet or single IP to single IP, whatever is > needed). > You cannot have one IPsec tunnel to be going to two different VM > devices on the cloud provides side. You need to different IPsec > tunnels, one for each host. Good point, but that's not, I think, what she was asking for. Perhaps Linda can clarify her question. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlj2Ew8ACgkQgItw+93Q 3WXtnQf+ONNiRDmWJq+TApTJIVs0RHgyOFBMPUnl8nRR7Q8D97sjBICX9qVRgkZb w3PnAIB9GtrgvZV53iXeFyLOPF+SwwN2rdETn3uUjWWGPCD6yPdwzSQmiu+CdMhY BwMOHxbWpOVafN0Dx0jQDEdZDTVSXDvACJRS6NFHsMuMWUM3YlfLdQyKcL/eqbIo 1QWi/WhHNQgs6dIU3yqWOduqRNRxcdxlqDg7uPKa3gO0+mYfSJkbpWVUaeA0hBKz ahT/drW6FBwm40kq9GQeFa5WGRkLMLiVlQZldTb7tLERlX22yCpq2/XiDtXGvcah 9TNUcAAxUuRaC5EFfcF2rUrGLXjBFw== =XMvD -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 19 11:49:10 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB91129C12; Wed, 19 Apr 2017 11:49:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149262774915.19228.16212136494185962079@ietfa.amsl.com> Date: Wed, 19 Apr 2017 11:49:09 -0700 Archived-At: Subject: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 18:49:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Postquantum Preshared Keys for IKEv2 Authors : Scott Fluhrer David McGrew Panos Kampanakis Filename : draft-fluhrer-qr-ikev2-04.txt Pages : 11 Date : 2017-04-19 Abstract: The possibility of quantum computers pose a serious challenge to cryptography algorithms widely today. IKEv2 is one example of a cryptosystem that could be broken; someone storing VPN communications today could decrypt them at a later time when a quantum computer is available. It is anticipated that IKEv2 will be extended to support quantum secure key exchange algorithms; however that is not likely to happen in the near term. To address this problem before then, this document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-fluhrer-qr-ikev2/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-fluhrer-qr-ikev2-04 https://datatracker.ietf.org/doc/html/draft-fluhrer-qr-ikev2-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-fluhrer-qr-ikev2-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Apr 20 14:40:42 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE28129C68; Thu, 20 Apr 2017 14:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1ob38RRw62Q; Thu, 20 Apr 2017 14:40:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E7EE129459; Thu, 20 Apr 2017 14:40:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFF52560; Thu, 20 Apr 2017 21:40:35 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 20 Apr 2017 22:40:34 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML701-CHM.china.huawei.com ([169.254.3.8]) with mapi id 14.03.0235.001; Thu, 20 Apr 2017 14:40:27 -0700 From: Linda Dunbar To: Yoav Nir CC: "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" Thread-Topic: sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio Thread-Index: AdK6G/pAtzEdg5HCTk+UmsKBqK3FvQ== Date: Thu, 20 Apr 2017 21:40:26 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F659275934@SJCEML702-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.188] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090204.58F92AD3.018A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: cbe01f43a73bf9dc9c90b5ce0ff06eba Archived-At: Subject: [IPsec] sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 21:40:41 -0000 WW9hdiwgDQoNCllvdSBzYWlkIHRoYXQgaXQgaXMgYSBiYWQgaWRlYSB0byBoYXZlICJzaGFyaW5n IGtleSBhbW9uZyBtdWx0aXBsZSBwb2ludHMiIGFzIGludHJvZHVjZWQgYnkgZHJhZnQtYWJhZC1p Mm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLiANCg0KSXNuJ3QgdGhlICJHcm91cCBFbmNy eXB0aW9uIEtleSIgb2YgaGF2aW5nIGEgIktleSBTZXJ2ZXIiIGRpc3RyaWJ1dGluZyB0aGUga2V5 IHRvIG11bHRpcGxlIG1lbWJlcnMgZG9pbmcgdGhlIHNhbWU/IGh0dHA6Ly93d3cuY2lzY28uY29t L2MvZGFtL2VuL3VzL3Byb2R1Y3RzL2NvbGxhdGVyYWwvc2VjdXJpdHkvZ3JvdXAtZW5jcnlwdGVk LXRyYW5zcG9ydC12cG4vR0VUVlBOX0RJR192ZXJzaW9uXzFfMF9FeHRlcm5hbC5wZGYNCg0KDQpM aW5kYQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogWW9hdiBOaXIgW21haWx0 bzp5bmlyLmlldGZAZ21haWwuY29tXSANCg0KDQo+PiAtIEkyTlNGIGhhcyBhIHByb3Bvc2FsIG9u IHVzaW5nIENvbnRyb2xsZXIgdG8gbWFuYWdlciBhbGwgdGhlIElQU2VjDQo+PiB0dW5uZWxzOg0K Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1hYmFkLWkybnNm LXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24uDQo+PiBXaGF0IGtpbmQgb2YgaXNzdWVzIGRvIHlv dSBzZWUgd2l0aCB0aGUgcHJvcG9zZWQgYXBwcm9hY2g/DQo+IA0KPiBJIGRpZG4ndCByZWFkIGl0 Lg0KDQpJIGRpZC4gVGhleSBoYXZlIHR3byBjYXNlcy4gSW4gY2FzZSAjMSB0aGUgY29udHJvbGxl ciBwcm92aXNpb25zIGNyZWRlbnRpYWxzIGZvciBJS0UgYW5kIGVudHJpZXMgaW4gUEFEIGFuZCBT UEQuIEluIGNhc2UgIzIgeW91IGZvcmVnbyBJS0UgYW5kIGhhdmUgdGhlIGNvbnRyb2xsZXIgcHJv dmlzaW9uIHRoZSBTQXMgKGluY2x1ZGluZyBrZXlzKS4NCg0KSSBlc3BlY2lhbGx5IGRpZG7igJl0 IGxpa2UgY2FzZSAjMi4gU2hhcmluZyBhIHNlY3JldCBrZXkgYW1vbmcgdGhyZWUgZW50aXRpZXMg aXMgYSBiYWQgaWRlYS4gQSBzaGFyZWQgYXV0aGVudGljYXRpb24gY3JlZGVudGlhbCBjYW4gYWxz byBiZSBtaXN1c2VkLCBidXQgdGhhdOKAmXMgYSBoYXJkIGF0dGFjayB0byBtb3VudC4gQSBzaGFy ZWQgdHJhZmZpYyBrZXkgbWFrZXMgdGhlIGNvbnRyb2xsZXIgYSB2ZXJ5IGF0dHJhY3RpdmUgdGFy Z2V0Lg0KDQpNb3JlIGluIGdlbmVyYWwsIFNETiB3YXMgYm9ybiBpbiB0aGUgZGF0YSBjZW50ZXIu IEluIGEgZGF0YSBjZW50ZXIgYW4gYWxsLWtub3dpbmcgY29udHJvbGxlciBtYWtlcyBzZW5zZS4g VGhpcyBpcyB0cnVlIGZvciByb3V0aW5nIGFzIGl0IGlzIGZvciBOU0ZzIHN1Y2ggYXMgZmlyZXdh bGxzLCBJRFBzIGFuZCBJRFNzLiBWUE4gZXh0ZW5kcyB0aGUgcmVhY2ggb2YgdGhlIHByaXZhdGUg bmV0d29yayB0byBhbGwgY29ybmVycyBvZiB0aGUgSW50ZXJuZXQuIFRoaW5rIG9mIGEgc3RvcmUg Y2hhaW4gd2l0aCBhIENQRSBpbiBldmVyeSBvbmUgb2YgdGhvdXNhbmRzIG9mIGJyYW5jaGVzLiBP ciBhIGJhbmsuIFRoZSBwcm9ibGVtIHRoZXJlIGlzIHRoYXQgdGhlcmUgaXMgbm8gY2VudHJhbCBh ZG1pbmlzdHJhdGl2ZSBmdW5jdGlvbi4gTG9jYWwgYnJhbmNoZXMgbWF5IHN3aXRjaCBJU1AgYW5k IHJlbnVtYmVyIHRoZWlyIG5ldHdvcmsgd2l0aG91dCBib3RoZXJpbmcgdG8gdGVsbCB0aGUgSVQg cGVvcGxlLiBTbyB0aGUgbW9kZWwgd2hlcmUgdGhlIGNvbnRyb2xsZXIga25vd3MgZXZlcnl0aGlu ZyBpcyB0b3VnaCB0byBkZXBsb3kgaW4gcHJhY3RpY2UuDQoNCkl0IGlzIHByb2JhYmx5IG5lY2Vz c2FyeSB0byBoYXZlIHR3by13YXkgY29tbXVuaWNhdGlvbnMsIHdoZXJlIHRoZSBDUEUgdGVsbHMg dGhlIGNvbnRyb2xsZXIgYWJvdXQgaXRzIHRvcG9sb2d5IChob3cgaXQgcGFydGl0aW9ucyB0aGUg SW50ZXJuZXQgdG8g4oCcaW7igJ0gdnMg4oCcb3V04oCdKSBzbyB0aGF0IHRoZSBjb250cm9sbGVy IGNhbiBzZXQgdXAgdGhlIGFwcHJvcHJpYXRlIFNQRHMuDQoNClRoZXJlIGhhdmUgYmVlbiBzZXZl cmFsIGF0dGVtcHRzIGF0IHRoaXMuIFJGQyA3MDE4IGRlc2NyaWJlcyByZXF1aXJlbWVudHMsIGJ1 dCB0aGUgV0cgdWx0aW1hdGVseSBmYWlsZWQgdG8gcHVibGlzaCBhIHNvbHV0aW9uIGRvY3VtZW50 LiAgVGhlcmUgYXJlIGFsc28gbW9yZSByZWNlbnQgY29tbWVyY2lhbCBzb2x1dGlvbnMgc29sZCB0 b2RheSB1bmRlciB0aGUgbWFya2V0aW5nIG5hbWUgb2Yg4oCcU0QtV0FO4oCdLCB3aGljaCBpcyBz b3J0IG9mIGxpa2UgU0ROIGlmIHlvdSBzcXVpbnQgaGFyZCBlbm91Z2guIEFsbCBvZiB0aGVzZSBo YXZlIHNvbWUgaW50ZXJhY3Rpb24gYmV0d2VlbiBDUEUgYW5kIGNvbnRyb2xsZXJzIChvciBodWJz KSB3aGljaCBkcmFmdC1hYmFkIGRvZXMgbm90Lg0KDQpZb2F2DQoNCg== From nobody Thu Apr 20 15:18:43 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38221316ED; Thu, 20 Apr 2017 15:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5QV3d1dXP2J; Thu, 20 Apr 2017 15:18:40 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::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 998AF1316EA; Thu, 20 Apr 2017 15:18:39 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id o81so3464581wmb.1; Thu, 20 Apr 2017 15:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=DmYkNeTozN6pnnuk+Jy/3P4aHP2pX/QD9fGAN5wtoy8=; b=dpcVtPH3HdA0Ond4gMcezbMpJ6H+heTM/FTx9eYYHVg8zla2TzxrfdFwDE9Q3k9wxN omxMvFtYr055Wl5zyyiUn9nS0kbsqP5Om/m3W84hYDR3ZdNXMHZKQV+MN9+bkcfMVwPT EA8gsvq0yEqEM3YABE3oZ40oIy9Ao6FD3mfHdfiEDdwLfuOULdKWJPTO1Z5aqAqUzM4d 1NDYAUr52IMb1G9hP2zT9v8dG8UtVYwCaGzrDt+p4nG6ovZgFvnzk9eUfZWmXj3ZuB0z hxKkzGGQClBRqyrEFca0veK6EB1jo/Mn51DC4YTlsX2U3698ofLbiMjWz73FUMVnRWtF 7ttg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=DmYkNeTozN6pnnuk+Jy/3P4aHP2pX/QD9fGAN5wtoy8=; b=WH5IDyoUkG613Q/XUc0QvTZo/V8FytjG1mnADamT2Rzv6XEce2sAizLQeMh3n9nhcE eppTpXn6QTF+0hPTA/Uy3+YeSCfzYlU4sKj2BsHPwt8EJyF1iCCbbQP6z5/Tc2InFAkl zLf44Patfti+1pcmt15oFkS4wtYbPhbscylitPusowWWUCiUSL/Q6Bk1wJc7cGwdTKxY 771BPcxEwHuACO+n0ZwRZdVmkbiLz5HZPd8cLNC+tt7ZAtnYfKaIRiTEC9IgUQMUXdCU n/YtrkZIdTENURefHVq0xqn6YZPIsyzhQMPZFwnHw2s1Ja1sgDP5RZmS2wF8n+GOnmnB u9Og== X-Gm-Message-State: AN3rC/7bPzlRnyL7rJzfqPkUczs60xudjfMI6NMSezAYqJ18XHtHj35n yxiabBX1z3nyXU/neKY= X-Received: by 10.28.150.213 with SMTP id y204mr5046372wmd.138.1492726718129; Thu, 20 Apr 2017 15:18:38 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e21sm598806wma.5.2017.04.20.15.18.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Apr 2017 15:18:37 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_67D4A5D1-8B9C-4E01-A715-F5A9E2B1D926"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 21 Apr 2017 01:18:34 +0300 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F659275934@SJCEML702-CHM.china.huawei.com> Cc: "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" To: Linda Dunbar References: <4A95BA014132FF49AE685FAB4B9F17F659275934@SJCEML702-CHM.china.huawei.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 22:18:42 -0000 --Apple-Mail=_67D4A5D1-8B9C-4E01-A715-F5A9E2B1D926 Content-Type: multipart/alternative; boundary="Apple-Mail=_B534950F-8117-4CBD-A0E2-9AE447916D47" --Apple-Mail=_B534950F-8117-4CBD-A0E2-9AE447916D47 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Linda > On 21 Apr 2017, at 0:40, Linda Dunbar wrote: >=20 > Yoav, >=20 > You said that it is a bad idea to have "sharing key among multiple = points" as introduced by draft-abad-i2nsf-sdn-ipsec-flow-protection. >=20 > Isn't the "Group Encryption Key" of having a "Key Server" distributing = the key to multiple members doing the same? = http://www.cisco.com/c/dam/en/us/products/collateral/security/group-encryp= ted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf = Just because Cisco do it doesn=E2=80=99t mean that it=E2=80=99s not a = bad idea. :-) GETVPN is based on GDOI (RFC 6407). GDOI is about extending IPsec to = multicast communications, where in a group of nodes a node encrypts a = multicast IPsec packet and sends it to all group members who in turn = decrypt it. For group communications sharing a key is inevitable. GETVPN extends the key server back to regular unicast IPsec. It trades = the security and robustness of pair-wise key exchange for the = operational convenience of using a single traffic key for the entire = configuration.In return for everyone using the same key, they eliminate = the need for each node to be configured with the IP address and = protected domain of every other node. Any SDN or SDN-like solution does not need to eliminate configuration as = that can be done dynamically by the controller. I don=E2=80=99t think = the trade-off that was necessary for GDOI and convenient for GETVPN has = many advantages for VPN with SDN. Yoav --Apple-Mail=_B534950F-8117-4CBD-A0E2-9AE447916D47 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Linda

On 21 Apr 2017, at 0:40, Linda = Dunbar <linda.dunbar@huawei.com> wrote:

Yoav, =

You said that it is a bad idea to have = "sharing key among multiple points" as introduced by = draft-abad-i2nsf-sdn-ipsec-flow-protection.

Isn't the "Group Encryption Key" of having a "Key Server" = distributing the key to multiple members doing the same? http://www.cisco.com/c/dam/en/us/products/collateral/security/g= roup-encrypted-transport-vpn/GETVPN_DIG_version_1_0_External.pdf

Just = because Cisco do it doesn=E2=80=99t mean that it=E2=80=99s not a bad = idea.  :-)

GETVPN is based on = GDOI (RFC 6407). GDOI is about extending IPsec to multicast = communications, where in a group of nodes a node encrypts a multicast = IPsec packet and sends it to all group members who in turn decrypt it. =  For group communications sharing a key is = inevitable.

GETVPN extends the key = server back to regular unicast IPsec. It trades the security and = robustness of pair-wise key exchange for the operational convenience of = using a single traffic key for the entire configuration.In return for = everyone using the same key, they eliminate the need for each node to be = configured with the IP address and protected domain of every other = node.

Any SDN or SDN-like solution = does not need to eliminate configuration as that can be done dynamically = by the controller. I don=E2=80=99t think the trade-off that was = necessary for GDOI and convenient for GETVPN has many advantages for VPN = with SDN.

Yoav

= --Apple-Mail=_B534950F-8117-4CBD-A0E2-9AE447916D47-- --Apple-Mail=_67D4A5D1-8B9C-4E01-A715-F5A9E2B1D926 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY+TO7AAoJELhJCxUKWMyZdMsH/1CQLGEL+m5dnIn2/RbU4G/F t7C2Y9SAQ0Il77KZU+LVM894VpX1yoOkDdZ3IRuGJa9lGsCFQ5x0k8L1kPqbAnFy b9AFR0s4OSbxkzSz4Omln8EkXDEik+cWjGiKn8KJMANqsNJxYY22OVtXHv9Y7HQn TP2QpZ26bVVhyww2nKLQXG0hMPIVBB7bcj6XBcIxBNWVp2sKAxkJHHnXfsOH1RTS ys2tE8FX2HxH+bvk3/5l62FE4R5PJ2XrpRTiAnTAcaAH+iEJUdl8jVws9moc6kQJ i7WSU7OyVPz/lOF2bCyLn1S2Rh9t4cOGGt9vrUYL6tqzEn/PJJJ4sAjLQNwhbHM= =r9u7 -----END PGP SIGNATURE----- --Apple-Mail=_67D4A5D1-8B9C-4E01-A715-F5A9E2B1D926-- From nobody Fri Apr 21 04:30:01 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0613F129BF6 for ; Fri, 21 Apr 2017 04:30:00 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uVSBPFDfhhK for ; Fri, 21 Apr 2017 04:29:57 -0700 (PDT) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA021294F4 for ; Fri, 21 Apr 2017 04:29:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id EB4C035B2; Fri, 21 Apr 2017 13:29:54 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 6SAwjlkG0ntE; Fri, 21 Apr 2017 13:29:54 +0200 (CEST) Received: from [192.168.1.16] (104.red-83-40-108.dynamicip.rima-tde.net [83.40.108.104]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon22.um.es (Postfix) with ESMTPSA id 4CBD2347C; Fri, 21 Apr 2017 13:29:51 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2359F9A4-CA7D-4599-8A80-A2D5E773618B"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail From: Gabriel Lopez In-Reply-To: <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> Date: Fri, 21 Apr 2017 13:29:50 +0200 Cc: Linda Dunbar , "IPsec@ietf.org" , Michael Richardson Message-Id: <41ECB289-C290-4A6B-A90A-8FD1D404AEC8@um.es> References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 11:30:00 -0000 --Apple-Mail=_2359F9A4-CA7D-4599-8A80-A2D5E773618B Content-Type: multipart/alternative; boundary="Apple-Mail=_A0B53633-46FA-402F-823B-92D42A43788B" --Apple-Mail=_A0B53633-46FA-402F-823B-92D42A43788B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for reading the doc, comments in line ... > El 13 abr 2017, a las 23:42, Yoav Nir escribi=C3=B3= : >=20 >>=20 >=20 >=20 >>> - I2NSF has a proposal on using Controller to manager all the IPSec >>> tunnels: >>> = https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-prot= ection = . >>> What kind of issues do you see with the proposed approach? >>=20 >> I didn't read it. >=20 > I did. They have two cases. In case #1 the controller provisions = credentials for IKE and entries in PAD and SPD. In case #2 you forego = IKE and have the controller provision the SAs (including keys). >=20 > I especially didn=E2=80=99t like case #2. Sharing a secret key among = three entities is a bad idea. A shared authentication credential can = also be misused, but that=E2=80=99s a hard attack to mount. A shared = traffic key makes the controller a very attractive target. Well, we are talking about key distribution, not key sharing. The = controller is acting a trusted key distribution center. The same problem = arises in KDCs or IdPs. In any case, we propose two cases to cover different scenarios, if = case#2 does not fit, for whatever reason, in this particular scenario, = case#1 could be used. >=20 > More in general, SDN was born in the data center. In a data center an = all-knowing controller makes sense. This is true for routing as it is = for NSFs such as firewalls, IDPs and IDSs. VPN extends the reach of the = private network to all corners of the Internet. Think of a store chain = with a CPE in every one of thousands of branches. Or a bank. The problem = there is that there is no central administrative function. Local = branches may switch ISP and renumber their network without bothering to = tell the IT people. So the model where the controller knows everything = is tough to deploy in practice. >=20 > It is probably necessary to have two-way communications, where the CPE = tells the controller about its topology (how it partitions the Internet = to =E2=80=9Cin=E2=80=9D vs =E2=80=9Cout=E2=80=9D) so that the controller = can set up the appropriate SPDs. >=20 > There have been several attempts at this. RFC 7018 describes = requirements, but the WG ultimately failed to publish a solution = document. There are also more recent commercial solutions sold today = under the marketing name of =E2=80=9CSD-WAN=E2=80=9D, which is sort of = like SDN if you squint hard enough. All of these have some interaction = between CPE and controllers (or hubs) which draft-abad does not. The doc does not preclude this communication between the CPE and the = Controller in order to allow the latter to be aware of configuration = details about the former. In fact, Netconf/yang (proposed as an example = of southbound interface in the draft) or SNMP could be used for that. We = should clarify this point in the next version (we are currently working = on it). Thanks again for you comments. Regards, Gabi. >=20 > Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_A0B53633-46FA-402F-823B-92D42A43788B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

Thanks = for reading the doc, comments in line ...

El 13 abr 2017, a las 23:42, Yoav Nir <ynir.ietf@gmail.com>= escribi=C3=B3:




- I2NSF has a proposal on using Controller to = manager all the IPSec
tunnels:
https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipse= c-flow-protection.
What kind of issues do you see with = the proposed approach?

I = didn't read it.

I did. They have two cases. In case #1 = the controller provisions credentials for IKE and entries in PAD and = SPD. In case #2 you forego IKE and have the controller provision the SAs = (including keys).

I especially = didn=E2=80=99t like case #2. Sharing a secret key among three entities = is a bad idea. A shared authentication credential can also be misused, = but that=E2=80=99s a hard attack to mount. A shared traffic key makes = the controller a very attractive target.


Well, we are talking about key distribution, not = key sharing. The controller is acting a trusted key distribution center. = The same problem arises in KDCs or IdPs.
In any case, we = propose two cases to cover different scenarios, if case#2 does not fit, = for whatever reason, in this particular scenario, case#1 could be = used. 



More in general, SDN was born in the data = center. In a data center an all-knowing controller makes sense. This is = true for routing as it is for NSFs such as firewalls, IDPs and IDSs. VPN = extends the reach of the private network to all corners of the Internet. = Think of a store chain with a CPE in every one of thousands of branches. = Or a bank. The problem there is that there is no central administrative = function. Local branches may switch ISP and renumber their network = without bothering to tell the IT people. So the model where the = controller knows everything is tough to deploy in practice.

It is probably necessary to have two-way = communications, where the CPE tells the controller about its topology = (how it partitions the Internet to =E2=80=9Cin=E2=80=9D vs =E2=80=9Cout=E2= =80=9D) so that the controller can set up the appropriate = SPDs.



There have been = several attempts at this. RFC 7018 describes requirements, but the WG = ultimately failed to publish a solution document.  There are also = more recent commercial solutions sold today under the marketing name of = =E2=80=9CSD-WAN=E2=80=9D, which is sort of like SDN if you squint hard = enough. All of these have some interaction between CPE and controllers = (or hubs) which draft-abad does not.


The doc does not preclude this communication = between the CPE and the Controller in order to allow the latter to be = aware of configuration details about the former. In fact, Netconf/yang = (proposed as an example of southbound interface in the draft) or SNMP = could be used for that. We should clarify this point in the next version = (we are currently working on it).

Thanks again for you comments.

Regards, Gabi.


Yoav

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



-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es




= --Apple-Mail=_A0B53633-46FA-402F-823B-92D42A43788B-- --Apple-Mail=_2359F9A4-CA7D-4599-8A80-A2D5E773618B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJY+e0vAAoJEMUYqoSNEZFT3i0IAJ6KvERAvnMmQ6jEGMS8Rzr+ 9nst1MoYYJazYj1BnrOWezuT0fgM8RsPqRwqtao/DO9RkZCBdlKmX11Nr3fjvF0i WfzsKju3gNnKyGnF3/Ha1Gxnrz923NnLYvGqSenAsWya2daZX8ANu55ABafsopg4 SWmr8q025A89ky1CaU9Asf93yAa66uvvy9fOs6i8srKhKLr5NuFqRZF9Pn0lPFsy b3j2nrJiZ6LLtu0+Lbwb9xyWKNoOuEwIesComdKzr9PWOiTI74/05H/mdDdHMJ6J VHsGkqKmbTsT3FmznX6fli5RfyRelJUzmnXPTSc0PE7Jj+iLw7nhTWGzMq57pJo= =d+PG -----END PGP SIGNATURE----- --Apple-Mail=_2359F9A4-CA7D-4599-8A80-A2D5E773618B-- From nobody Fri Apr 21 04:34:30 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9339F129496; Fri, 21 Apr 2017 04:34:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, ekr@rtfm.com, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149277446956.22348.5498213162159909607.idtracker@ietfa.amsl.com> Date: Fri, 21 Apr 2017 04:34:29 -0700 Archived-At: Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 99 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 11:34:29 -0000 A new meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: cfrg saag tls curdle tcpinc mile sacm Second Priority: 6tisch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Eric Rescorla Tero Kivinen David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Apr 21 10:23:21 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0C412786A; Fri, 21 Apr 2017 10:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-FETl0jMgNx; Fri, 21 Apr 2017 10:23:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4834128D19; Fri, 21 Apr 2017 10:23:15 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLM43832; Fri, 21 Apr 2017 17:23:13 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 21 Apr 2017 18:23:12 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Fri, 21 Apr 2017 10:23:09 -0700 From: Linda Dunbar To: "\"IETF Meeting Session Request Tool\"" , "session-request@ietf.org" CC: "ipsec@ietf.org" , "ipsecme-chairs@ietf.org" , "ekr@rtfm.com" , "kivinen@iki.fi" Thread-Topic: [IPsec] ipsecme - New Meeting Session Request for IETF 99 Thread-Index: AQHSupNEMtJ/9INwTk+IudyHXGtooKHQEUxg Date: Fri, 21 Apr 2017 17:23:09 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F65927614C@SJCEML702-CHM.china.huawei.com> References: <149277446956.22348.5498213162159909607.idtracker@ietfa.amsl.com> In-Reply-To: <149277446956.22348.5498213162159909607.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.188] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58FA4002.0042, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: fd4bfe332ec0d40df0a088cb621147f7 Archived-At: Subject: Re: [IPsec] ipsecme - New Meeting Session Request for IETF 99 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 17:23:20 -0000 Chairs,=20 Can you add I2NSF to the "Conflict to Avoid" list?=20 Several of us from I2NSF would like to attend IPSecme to sort out issues wi= th SDN controlled IPSec.=20 Thanks, Linda -----Original Message----- From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of "IETF Meeting Sess= ion Request Tool" Sent: Friday, April 21, 2017 6:34 AM To: session-request@ietf.org Cc: ipsec@ietf.org; ipsecme-chairs@ietf.org; ekr@rtfm.com; kivinen@iki.fi Subject: [IPsec] ipsecme - New Meeting Session Request for IETF 99 A new meeting session request has just been submitted by Tero Kivinen, a Ch= air of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Secur= ity Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid:=20 First Priority: cfrg saag tls curdle tcpinc mile sacm Second Priority: 6t= isch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Eric Rescorla Tero Kivinen David Waltermire Resources Requested: Special Requests: =20 --------------------------------------------------------- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Apr 21 12:49:38 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29471292CE; Fri, 21 Apr 2017 12:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2Liyl4VdkO6; Fri, 21 Apr 2017 12:49:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25ABC12441E; Fri, 21 Apr 2017 12:49:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DLM55728; Fri, 21 Apr 2017 19:49:30 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 21 Apr 2017 20:49:28 +0100 Received: from SJCEML702-CHM.china.huawei.com ([169.254.4.233]) by SJCEML703-CHM.china.huawei.com ([169.254.5.195]) with mapi id 14.03.0235.001; Fri, 21 Apr 2017 12:49:24 -0700 From: Linda Dunbar To: Yoav Nir CC: "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" Thread-Topic: sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio Thread-Index: AdK6G/pAtzEdg5HCTk+UmsKBqK3FvQAQr60AAB41whA= Date: Fri, 21 Apr 2017 19:49:23 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F65927632E@SJCEML702-CHM.china.huawei.com> References: <4A95BA014132FF49AE685FAB4B9F17F659275934@SJCEML702-CHM.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.188] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F65927632ESJCEML702CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.58FA624B.00AE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.233, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c8e4ccdfcb5621266ee07a2671e33a7b Archived-At: Subject: Re: [IPsec] sharing key among multiple end points vs. Group Encryption Key - draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 19:49:37 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F65927632ESJCEML702CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW9hdiwNCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBmb3IgdGhlIGRldGFpbGVkIGV4cGxhbmF0aW9u Lg0KDQpKdXN0IG91dCBvZiBjdXJpb3NpdHksIHdoYXQga2luZCBvZiDigJxzZWN1cml0eSBhbmQg cm9idXN0bmVzcyBvZiBwYWlyLXdpc2Uga2V5IGV4Y2hhbmdl4oCdIGFyZSBsb3N0IGJ5IHVzaW5n IGEgc2luZ2xlIHRyYWZmaWMga2V5IGZvciBtdWx0aXBsZSBlbmQgcG9pbnRzPw0KDQpFdmVuIHdp dGggU0ROIGFwcHJvYWNoLCBhcyBiZWluZyBwcm9wb3NlZCBieSB0aGUgZHJhZnQtYWJhZC1pMm5z Zi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLTAxLCBzb21lIGVuZCBwb2ludHMgKGkuZS4gYnJh bmNoIENQRXMpIG1heSBub3QgaGF2ZSBlbm91Z2ggcmVzb3VyY2UgdG8gbWFuYWdlIGxhcmdlIG51 bWJlciBvZiBzZWN1cml0eSBhc3NvY2lhdGlvbnMgd2l0aCBtYW55IG90aGVyIGVuZCBwb2ludHMg KGFzIGluIG1hbnkgU0QtV0FOIGJyYW5jaCB0byBicmFuY2ggZGlyZWN0IHR1bm5lbHMgdXNlIGNh c2UpLg0KDQpMaW5kYQ0KDQpGcm9tOiBZb2F2IE5pciBbbWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5j b21dDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMjAsIDIwMTcgNToxOSBQTQ0KVG86IExpbmRhIER1 bmJhciA8bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+DQpDYzogSVBzZWNAaWV0Zi5vcmc7IE1pY2hh ZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNhPjsgaTJuc2ZAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiBzaGFyaW5nIGtleSBhbW9uZyBtdWx0aXBsZSBlbmQgcG9pbnRzIHZzLiBHcm91 cCBFbmNyeXB0aW9uIEtleSAtIGRyYWZ0LWFiYWQtaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJvdGVj dGlvDQoNCkhpLCBMaW5kYQ0KDQpPbiAyMSBBcHIgMjAxNywgYXQgMDo0MCwgTGluZGEgRHVuYmFy IDxsaW5kYS5kdW5iYXJAaHVhd2VpLmNvbTxtYWlsdG86bGluZGEuZHVuYmFyQGh1YXdlaS5jb20+ PiB3cm90ZToNCg0KWW9hdiwNCg0KWW91IHNhaWQgdGhhdCBpdCBpcyBhIGJhZCBpZGVhIHRvIGhh dmUgInNoYXJpbmcga2V5IGFtb25nIG11bHRpcGxlIHBvaW50cyIgYXMgaW50cm9kdWNlZCBieSBk cmFmdC1hYmFkLWkybnNmLXNkbi1pcHNlYy1mbG93LXByb3RlY3Rpb24uDQoNCklzbid0IHRoZSAi R3JvdXAgRW5jcnlwdGlvbiBLZXkiIG9mIGhhdmluZyBhICJLZXkgU2VydmVyIiBkaXN0cmlidXRp bmcgdGhlIGtleSB0byBtdWx0aXBsZSBtZW1iZXJzIGRvaW5nIHRoZSBzYW1lPyBodHRwOi8vd3d3 LmNpc2NvLmNvbS9jL2RhbS9lbi91cy9wcm9kdWN0cy9jb2xsYXRlcmFsL3NlY3VyaXR5L2dyb3Vw LWVuY3J5cHRlZC10cmFuc3BvcnQtdnBuL0dFVFZQTl9ESUdfdmVyc2lvbl8xXzBfRXh0ZXJuYWwu cGRmDQoNCkp1c3QgYmVjYXVzZSBDaXNjbyBkbyBpdCBkb2VzbuKAmXQgbWVhbiB0aGF0IGl04oCZ cyBub3QgYSBiYWQgaWRlYS4gIDotKQ0KDQpHRVRWUE4gaXMgYmFzZWQgb24gR0RPSSAoUkZDIDY0 MDcpLiBHRE9JIGlzIGFib3V0IGV4dGVuZGluZyBJUHNlYyB0byBtdWx0aWNhc3QgY29tbXVuaWNh dGlvbnMsIHdoZXJlIGluIGEgZ3JvdXAgb2Ygbm9kZXMgYSBub2RlIGVuY3J5cHRzIGEgbXVsdGlj YXN0IElQc2VjIHBhY2tldCBhbmQgc2VuZHMgaXQgdG8gYWxsIGdyb3VwIG1lbWJlcnMgd2hvIGlu IHR1cm4gZGVjcnlwdCBpdC4gIEZvciBncm91cCBjb21tdW5pY2F0aW9ucyBzaGFyaW5nIGEga2V5 IGlzIGluZXZpdGFibGUuDQoNCkdFVFZQTiBleHRlbmRzIHRoZSBrZXkgc2VydmVyIGJhY2sgdG8g cmVndWxhciB1bmljYXN0IElQc2VjLiBJdCB0cmFkZXMgdGhlIHNlY3VyaXR5IGFuZCByb2J1c3Ru ZXNzIG9mIHBhaXItd2lzZSBrZXkgZXhjaGFuZ2UgZm9yIHRoZSBvcGVyYXRpb25hbCBjb252ZW5p ZW5jZSBvZiB1c2luZyBhIHNpbmdsZSB0cmFmZmljIGtleSBmb3IgdGhlIGVudGlyZSBjb25maWd1 cmF0aW9uLkluIHJldHVybiBmb3IgZXZlcnlvbmUgdXNpbmcgdGhlIHNhbWUga2V5LCB0aGV5IGVs aW1pbmF0ZSB0aGUgbmVlZCBmb3IgZWFjaCBub2RlIHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCB0aGUg SVAgYWRkcmVzcyBhbmQgcHJvdGVjdGVkIGRvbWFpbiBvZiBldmVyeSBvdGhlciBub2RlLg0KDQpB bnkgU0ROIG9yIFNETi1saWtlIHNvbHV0aW9uIGRvZXMgbm90IG5lZWQgdG8gZWxpbWluYXRlIGNv bmZpZ3VyYXRpb24gYXMgdGhhdCBjYW4gYmUgZG9uZSBkeW5hbWljYWxseSBieSB0aGUgY29udHJv bGxlci4gSSBkb27igJl0IHRoaW5rIHRoZSB0cmFkZS1vZmYgdGhhdCB3YXMgbmVjZXNzYXJ5IGZv ciBHRE9JIGFuZCBjb252ZW5pZW50IGZvciBHRVRWUE4gaGFzIG1hbnkgYWR2YW50YWdlcyBmb3Ig VlBOIHdpdGggU0ROLg0KDQpZb2F2DQoNCg== --_000_4A95BA014132FF49AE685FAB4B9F17F65927632ESJCEML702CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Zb2F2LA0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFuayB5b3UgdmVyeSBtdWNoIGZv ciB0aGUgZGV0YWlsZWQgZXhwbGFuYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkp1c3Qgb3V0IG9mIGN1cmlvc2l0eSwgd2hhdCBraW5kIG9mIOKAnDwv c3Bhbj48Yj48aT5zZWN1cml0eSBhbmQgcm9idXN0bmVzcyBvZiBwYWlyLXdpc2Uga2V5IGV4Y2hh bmdl4oCdPC9pPjwvYj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5hcmUgbG9zdCBi eSB1c2luZyBhIHNpbmdsZSB0cmFmZmljIGtleSBmb3IgbXVsdGlwbGUgZW5kIHBvaW50cz8gJm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FdmVuIHdpdGgg U0ROIGFwcHJvYWNoLCBhcyBiZWluZyBwcm9wb3NlZCBieSB0aGUgZHJhZnQtYWJhZC1pMm5zZi1z ZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLTAxLCBzb21lIGVuZCBwb2ludHMgKGkuZS4gYnJhbmNo IENQRXMpIG1heSBub3QgaGF2ZSBlbm91Z2ggcmVzb3VyY2UNCiB0byBtYW5hZ2UgbGFyZ2UgbnVt YmVyIG9mIHNlY3VyaXR5IGFzc29jaWF0aW9ucyB3aXRoIG1hbnkgb3RoZXIgZW5kIHBvaW50cyAo YXMgaW4gbWFueSBTRC1XQU4gYnJhbmNoIHRvIGJyYW5jaCBkaXJlY3QgdHVubmVscyB1c2UgY2Fz ZSkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxpbmRhICZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9 Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gWW9hdiBOaXIgW21haWx0bzp5bmlyLmlldGZAZ21haWwuY29t XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBBcHJpbCAyMCwgMjAxNyA1OjE5IFBNPGJy Pg0KPGI+VG86PC9iPiBMaW5kYSBEdW5iYXIgJmx0O2xpbmRhLmR1bmJhckBodWF3ZWkuY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gSVBzZWNAaWV0Zi5vcmc7IE1pY2hhZWwgUmljaGFyZHNvbiAmbHQ7 bWNyJiM0MztpZXRmQHNhbmRlbG1hbi5jYSZndDs7IGkybnNmQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBzaGFyaW5nIGtleSBhbW9uZyBtdWx0aXBsZSBlbmQgcG9pbnRzIHZzLiBH cm91cCBFbmNyeXB0aW9uIEtleSAtIGRyYWZ0LWFiYWQtaTJuc2Ytc2RuLWlwc2VjLWZsb3ctcHJv dGVjdGlvPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGks IExpbmRhPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g MjEgQXByIDIwMTcsIGF0IDA6NDAsIExpbmRhIER1bmJhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxp bmRhLmR1bmJhckBodWF3ZWkuY29tIj5saW5kYS5kdW5iYXJAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW9hdiwg PGJyPg0KPGJyPg0KWW91IHNhaWQgdGhhdCBpdCBpcyBhIGJhZCBpZGVhIHRvIGhhdmUgJnF1b3Q7 c2hhcmluZyBrZXkgYW1vbmcgbXVsdGlwbGUgcG9pbnRzJnF1b3Q7IGFzIGludHJvZHVjZWQgYnkg ZHJhZnQtYWJhZC1pMm5zZi1zZG4taXBzZWMtZmxvdy1wcm90ZWN0aW9uLg0KPGJyPg0KPGJyPg0K SXNuJ3QgdGhlICZxdW90O0dyb3VwIEVuY3J5cHRpb24gS2V5JnF1b3Q7IG9mIGhhdmluZyBhICZx dW90O0tleSBTZXJ2ZXImcXVvdDsgZGlzdHJpYnV0aW5nIHRoZSBrZXkgdG8gbXVsdGlwbGUgbWVt YmVycyBkb2luZyB0aGUgc2FtZT8NCjxhIGhyZWY9Imh0dHA6Ly93d3cuY2lzY28uY29tL2MvZGFt L2VuL3VzL3Byb2R1Y3RzL2NvbGxhdGVyYWwvc2VjdXJpdHkvZ3JvdXAtZW5jcnlwdGVkLXRyYW5z cG9ydC12cG4vR0VUVlBOX0RJR192ZXJzaW9uXzFfMF9FeHRlcm5hbC5wZGYiPg0KaHR0cDovL3d3 dy5jaXNjby5jb20vYy9kYW0vZW4vdXMvcHJvZHVjdHMvY29sbGF0ZXJhbC9zZWN1cml0eS9ncm91 cC1lbmNyeXB0ZWQtdHJhbnNwb3J0LXZwbi9HRVRWUE5fRElHX3ZlcnNpb25fMV8wX0V4dGVybmFs LnBkZjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCBiZWNhdXNlIENpc2NvIGRvIGl0IGRv ZXNu4oCZdCBtZWFuIHRoYXQgaXTigJlzIG5vdCBhIGJhZCBpZGVhLiAmbmJzcDs6LSk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R0VUVlBOIGlz IGJhc2VkIG9uIEdET0kgKFJGQyA2NDA3KS4gR0RPSSBpcyBhYm91dCBleHRlbmRpbmcgSVBzZWMg dG8gbXVsdGljYXN0IGNvbW11bmljYXRpb25zLCB3aGVyZSBpbiBhIGdyb3VwIG9mIG5vZGVzIGEg bm9kZSBlbmNyeXB0cyBhIG11bHRpY2FzdCBJUHNlYyBwYWNrZXQgYW5kIHNlbmRzIGl0IHRvIGFs bCBncm91cCBtZW1iZXJzIHdobyBpbiB0dXJuIGRlY3J5cHQgaXQuICZuYnNwO0ZvciBncm91cCBj b21tdW5pY2F0aW9ucw0KIHNoYXJpbmcgYSBrZXkgaXMgaW5ldml0YWJsZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R0VUVlBOIGV4dGVuZHMg dGhlIGtleSBzZXJ2ZXIgYmFjayB0byByZWd1bGFyIHVuaWNhc3QgSVBzZWMuIEl0IHRyYWRlcyB0 aGUgc2VjdXJpdHkgYW5kIHJvYnVzdG5lc3Mgb2YgcGFpci13aXNlIGtleSBleGNoYW5nZSBmb3Ig dGhlIG9wZXJhdGlvbmFsIGNvbnZlbmllbmNlIG9mIHVzaW5nIGEgc2luZ2xlIHRyYWZmaWMga2V5 IGZvciB0aGUgZW50aXJlIGNvbmZpZ3VyYXRpb24uSW4gcmV0dXJuIGZvciBldmVyeW9uZQ0KIHVz aW5nIHRoZSBzYW1lIGtleSwgdGhleSBlbGltaW5hdGUgdGhlIG5lZWQgZm9yIGVhY2ggbm9kZSB0 byBiZSBjb25maWd1cmVkIHdpdGggdGhlIElQIGFkZHJlc3MgYW5kIHByb3RlY3RlZCBkb21haW4g b2YgZXZlcnkgb3RoZXIgbm9kZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QW55IFNETiBvciBTRE4tbGlrZSBzb2x1dGlvbiBkb2VzIG5vdCBu ZWVkIHRvIGVsaW1pbmF0ZSBjb25maWd1cmF0aW9uIGFzIHRoYXQgY2FuIGJlIGRvbmUgZHluYW1p Y2FsbHkgYnkgdGhlIGNvbnRyb2xsZXIuIEkgZG9u4oCZdCB0aGluayB0aGUgdHJhZGUtb2ZmIHRo YXQgd2FzIG5lY2Vzc2FyeSBmb3IgR0RPSSBhbmQgY29udmVuaWVudCBmb3IgR0VUVlBOIGhhcyBt YW55IGFkdmFudGFnZXMgZm9yIFZQTiB3aXRoDQogU0ROLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb2F2PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A95BA014132FF49AE685FAB4B9F17F65927632ESJCEML702CHMchi_-- From nobody Sun Apr 23 02:34:36 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D616127843 for ; Sun, 23 Apr 2017 02:34:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkmHYlbBi-3a for ; Sun, 23 Apr 2017 02:34:32 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 4773F1200C1 for ; Sun, 23 Apr 2017 02:34:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id EB8852462; Sun, 23 Apr 2017 11:34:27 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Vja1ljFyW0Ou; Sun, 23 Apr 2017 11:34:27 +0200 (CEST) Received: from [192.168.1.35] (198.red-79-145-98.dynamicip.rima-tde.net [79.145.98.198]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon23.um.es (Postfix) with ESMTPSA id 59328235D; Sun, 23 Apr 2017 11:34:23 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> Date: Sun, 23 Apr 2017 11:34:26 +0200 Cc: Rafa Marin Lopez , Linda Dunbar , "IPsec@ietf.org" , Michael Richardson Content-Transfer-Encoding: quoted-printable Message-Id: <960CA8F1-256D-485F-91D7-20AFDB332BD5@um.es> References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 09:34:35 -0000 Hi Yoav: >>> - I2NSF has a proposal on using Controller to manager all the IPSec >>> tunnels: >>> = https://datatracker.ietf.org/doc/html/draft-abad-i2nsf-sdn-ipsec-flow-prot= ection. >>> What kind of issues do you see with the proposed approach? >>=20 >> I didn't read it. >=20 > I did. They have two cases. In case #1 the controller provisions = credentials for IKE and entries in PAD and SPD. In case #2 you forego = IKE and have the controller provision the SAs (including keys). >=20 > I especially didn=E2=80=99t like case #2. Sharing a secret key among = three entities is a bad idea. [Rafa] In my opinion, distributing key material from a trusted entity = should not be considered as a bad idea since it has been done in the = past. > A shared authentication credential can also be misused, but that=E2=80=99= s a hard attack to mount. A shared traffic key makes the controller a = very attractive target. In SDN paradigm a SDN is always attractive to attack, even without = considering key distribution. If the SDN controller is attacked it will = make the network inoperable. Thus, it is not a special issue in the = SDN-based key management. Moreover, as I mentioned in a previous e-mail = some time ago: "[Rafa] Two comments here. 1) I see the controller as a trusted entity, = otherwise it should not be trusted to any operation (not only = IPsec-related). Thus, providing keying material should not be a problem. = Even in case the NSFs negotiate keys, IKE credentials may be provided by = the controller. Moreover, with the right permissions, the controller = could access to the SAD state and observe keys there. 2) Distributing = key material will be performed over a secure channel between the = controller and the NSF, so no secret keys in clear are transmitted over = the network.=E2=80=9D Moreover the SDN controller may remove the keys immediately after they = have been installed in the NSF. >=20 > More in general, SDN was born in the data center. In a data center an = all-knowing controller makes sense. [Rafa] Therefore, case 2 would make sense there.=20 > This is true for routing as it is for NSFs such as firewalls, IDPs and = IDSs. VPN extends the reach of the private network to all corners of the = Internet. Think of a store chain with a CPE in every one of thousands of = branches. Or a bank. The problem there is that there is no central = administrative function. Local branches may switch ISP and renumber = their network without bothering to tell the IT people. So the model = where the controller knows everything is tough to deploy in practice. [Rafa] I guess, it will depend on the scenario. I remember an e-mail to = I2NSF = (https://www.ietf.org/mail-archive/web/i2nsf/current/msg01111.html) = mentioning that they were doing sort of case 2 and they would like to = have a standard way of doing it. Precisely the effort behind our I-D is = trying to provide an standard interface standard not only for case 1 = (with IKE in the NSF) but also for case 2 (no IKE in the NSF).=20 >=20 > It is probably necessary to have two-way communications, where the CPE = tells the controller about its topology (how it partitions the Internet = to =E2=80=9Cin=E2=80=9D vs =E2=80=9Cout=E2=80=9D) so that the controller = can set up the appropriate SPDs. [Rafa] I do not see a problem here. In fact, that is the assumption when = we wrote the I-D. Perhaps, we should state it in a clear form. Moreover, = between CPEs and SDN controller that manages them a security association = is required and, moreover, it is typical communication between them to = carry out this management. >=20 > There have been several attempts at this. RFC 7018 describes = requirements, but the WG ultimately failed to publish a solution = document. There are also more recent commercial solutions sold today = under the marketing name of =E2=80=9CSD-WAN=E2=80=9D, which is sort of = like SDN if you squint hard enough. All of these have some interaction = between CPE and controllers (or hubs) which draft-abad does not. [Rafa] It is not reflected explicitly (but assumed) in the draft-abad = because that happens all the time if you assume the SDN paradigm (the = discovery), so not only in the specific case of IPsec-management. The = SDN controller needs to know what CPEs are under its control. For = example in openflow you configure the device with a master SDN = controller'IP and credentials to connect to the SDN controller. In any = case, we can explicitly mention this in the I-D, no major problem. Best Regards. >=20 > Yoav >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ----------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ---------------------------------------------------------- From nobody Sun Apr 23 10:42:21 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF601289C3 for ; Sun, 23 Apr 2017 10:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCvadHvkI18T for ; Sun, 23 Apr 2017 10:42:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71360124D37 for ; Sun, 23 Apr 2017 10:42:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3w9xch17kJzD4l; Sun, 23 Apr 2017 19:42:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1492969332; bh=+CvYkggvO+sSDZT1MVZ4iNiJs4suvfC7phRFzd3ydDc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=BSYl0YtRT0pkAEQhG51FeD+3pzy8IV+k6u3+BHm4WyR5FU+IkwdKgGh8O1rOyXAtt fD8WBWRF4+yOtuXs8haZocl8JqMPsnYTEgO6q9d8PapuQN7dMEXJavTR0sXmCke2Zi 3r8aDcFJ5vfaftGQxcAhnEvVCin0jcd7jIziFaAY= 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 0LZ9lSNCzML4; Sun, 23 Apr 2017 19:42:07 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 23 Apr 2017 19:42:05 +0200 (CEST) Received: from [25.111.44.20] (unknown [24.114.76.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 4E07B70105; Sun, 23 Apr 2017 13:42:04 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4E07B70105 Content-Type: multipart/alternative; boundary=Apple-Mail-FAF45E00-2FA8-4248-AE15-4261E93214F0 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (14E304) In-Reply-To: <960CA8F1-256D-485F-91D7-20AFDB332BD5@um.es> Date: Sun, 23 Apr 2017 13:42:03 -0400 Cc: Yoav Nir , "IPsec@ietf.org" , Michael Richardson , Linda Dunbar Content-Transfer-Encoding: 7bit Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> <960CA8F1-256D-485F-91D7-20AFDB332BD5@um.es> To: Rafa Marin Lopez Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 17:42:19 -0000 --Apple-Mail-FAF45E00-2FA8-4248-AE15-4261E93214F0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Apr 23, 2017, at 05:34, Rafa Marin Lopez wrote: >=20 >> [Rafa] I guess, it will depend on the scenario. I remember an e-mail to I= 2NSF (https://www.ietf.org/mail-archive/web/i2nsf/current/msg01111.html) men= tioning that they were doing sort of case 2 and they would like to have a st= andard way of doing it. Precisely the effort behind our I-D is trying to pro= vide an standard interface standard not only for case 1 (with IKE in the NSF)= but also for case 2 (no IKE in the NSF).=20 >>=20 Don't. You will need to builtin there same security features as IKE has. Foc= us instead of implementing "minimal ikev2" https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-01 For example, most modern ciphers require timely rekeying and must never reus= e IV/counters with the same private key. Synching that across independent ho= sts is impossible. Paul= --Apple-Mail-FAF45E00-2FA8-4248-AE15-4261E93214F0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable




Sent f= rom my iPhone
On Apr 23, 2017, at 05:34, Rafa Marin Lopez <rafa@um.es> wrote:


[Rafa] I guess, it will depend o= n the scenario. I remember an e-mail to I2NSF (https://www.ietf.org/mail-a= rchive/web/i2nsf/current/msg01111.html) mentioning that they were doing s= ort of case 2 and they would like to have a standard way of doing it. Precis= ely the effort behind our I-D is trying to provide an standard interface sta= ndard not only for case 1 (with IKE in the NSF) but also for case 2 (no IKE i= n the NSF). 


Don't. You will need to bui= ltin there same security features as IKE has. Focus instead of implementing "= minimal ikev2"



For example, most modern ciphers require timely rekeying and must never re= use IV/counters with the same private key. Synching that across independent h= osts is impossible.

Paul
= --Apple-Mail-FAF45E00-2FA8-4248-AE15-4261E93214F0-- From nobody Mon Apr 24 02:21:46 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E94A3129C52; Mon, 24 Apr 2017 02:21:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: ipsec@ietf.org, ipsecme-chairs@ietf.org, ekr@rtfm.com, kivinen@iki.fi X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149302570485.25844.5000190203194778249.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 02:21:44 -0700 Archived-At: Subject: [IPsec] ipsecme - Update to a Meeting Session Request for IETF 99 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 09:21:45 -0000 An update to a meeting session request has just been submitted by Tero Kivinen, a Chair of the ipsecme working group. --------------------------------------------------------- Working Group Name: IP Security Maintenance and Extensions Area Name: Security Area Session Requester: Tero Kivinen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: cfrg saag tls curdle tcpinc mile sacm i2nsf Second Priority: 6tisch lwig ace Third Priority: uta 6lo tcpm netmod People who must be present: Eric Rescorla Tero Kivinen David Waltermire Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Apr 24 02:22:36 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20306129C36; Mon, 24 Apr 2017 02:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaoH1xUWvDQ0; Mon, 24 Apr 2017 02:22:33 -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 B665312EAF7; Mon, 24 Apr 2017 02:22:31 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3O9MN9c020747 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 24 Apr 2017 12:22:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3O9MLED028432; Mon, 24 Apr 2017 12:22:21 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22781.50125.755779.661148@fireball.acr.fi> Date: Mon, 24 Apr 2017 12:22:21 +0300 From: Tero Kivinen To: Linda Dunbar Cc: "\"IETF Meeting Session Request Tool\"" , "session-request\@ietf.org" , "ipsec\@ietf.org" , "ipsecme-chairs\@ietf.org" , "ekr\@rtfm.com" In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F65927614C@SJCEML702-CHM.china.huawei.com> References: <149277446956.22348.5498213162159909607.idtracker@ietfa.amsl.com> <4A95BA014132FF49AE685FAB4B9F17F65927614C@SJCEML702-CHM.china.huawei.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 4 min Archived-At: Subject: Re: [IPsec] ipsecme - New Meeting Session Request for IETF 99 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 09:22:35 -0000 Linda Dunbar writes: > Can you add I2NSF to the "Conflict to Avoid" list? Seems, I can't do that, when I try I get "The page you were looking for coundn't be found" error... Ah, found another route which gave me correct url. Added now... And next I need to write a ticket about the wrong url... > Several of us from I2NSF would like to attend IPSecme to sort out > issues with SDN controlled IPSec. Good. -- kivinen@iki.fi From nobody Mon Apr 24 14:37:53 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEBB120227; Mon, 24 Apr 2017 14:37:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149306986453.25885.1449670558732556919.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 14:37:44 -0700 Archived-At: Subject: [IPsec] Adam Roach's No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:37:45 -0000 Adam Roach has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Suggest expanding "IKE" and "ESP" in the Abstract on first use. The "MUST support dynamically enabling and disabling TCP" in section 8 seems unnecessarily strong. Every other normative statement in the document indicating the use of direct ESP or UDP encapsulation is only at a SHOULD level. This "MUST" is the sole statement that would make a TCP-only MOBIKE implementation noncompliant (rather than conditionally compliant), where non-MOBIKE implementations have no such restriction. Is that the intention? Section 12.2 claims that retransmission is a source of issues for delay-sensitive UDP applications. In practice, the retransmission is just fine; it's the head-of-line blocking that occurs upon packet loss that causes issues. Suggest stating issue in those terms. From nobody Mon Apr 24 14:49:52 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BFBC513185B; Mon, 24 Apr 2017 14:49:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Warren Kumari To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149307058969.14644.15446383091244476863.idtracker@ietfa.amsl.com> Date: Mon, 24 Apr 2017 14:49:49 -0700 Archived-At: Subject: [IPsec] Warren Kumari's No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 21:49:50 -0000 Warren Kumari has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please also see Mahesh Jethanandani's OpsDir review - https://www.ietf.org /mail-archive/web/ops-dir/current/msg02602.html Having run into this issue of middle boxes blocking non-UDP/non-TCP, I think that this is valuable. The document also covers a bunch of the standard operational and management considerations, and things like MTU issues, performance implications, etc.; thanks for this. One thing that I'd like to note is that this makes it significantly harder for an operator to simply block IPsec, but, well, that's kinda the point I guess... :-) I did have a number of minor questions and comments: (bikeshedding) Section 1, Bullet 2: "and ESP packets are sent out over UDP port 4500" - "sent out over" confused me (especially because ESP UDP is somewhat unusual to begin with) - perhaps "sent using UDP with source and destination port of 4500"? Section 1.2: "the role of IKE Initiator and Responder may swap for a given SA (as with IKE SA Rekeys)" -- a reference to rekeying would be good - perhaps RFC 7296 ? Section 4: The table containing "IKETCP" should be referenced (e.g: "containing the characters "IKETCP" as ASCII values (Figure 3).") Section 5: "If a Responder is configured to use TCP encapsulation, it MUST listen on the configured port(s) in case any peers will initiate new IKE sessions." s/will// (spurious will) "all of the endpoints equally support TCP encapsulation." -- what does equally" mean? All must do it, same TCP port, etc.? "MOBIKE" needs a reference. Section 11: "A network device that monitors up to the application layer will commonly expect to see HTTP traffic ..." - it might be useful to explain that this is simply an example. (the same thing happens if non-SMTP is seen on port 25, etc) From nobody Tue Apr 25 05:48:14 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B203F12EC90; Tue, 25 Apr 2017 05:48:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 05:48:12 -0700 Archived-At: Subject: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf-?= =?utf-8?q?ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 12:48:13 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This draft suggests that ports that are assigned to other services can simply be used. This is not okay. If a port is assigned to a certain service, this service and/or the respective RFC defines how this port is used. Simply changing the specified behavior by requiring a check for a magic number cannot be done without updating the RFC that the port assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as the IANA registry would need to be updated. Further, as also mentioned in the tsv-art review (Thanks Wes!), this draft does not sufficiently handle the case of TCP in TCP encapsulation. Here a copy of the tsv-art review: Reviewer: Wesley Eddy Review result: On the Right Track This document is clear and well-written. It can easily be implemented based on the description. There are a few additional issues that should be considered with advice to implementers in Section 12 on performance considerations: 1) Invisibility of packet loss - Inner protocols that require packet losses as a signal of congestion (e.g. TCP) will have a challenge due to not being able to see any packet losses since the outer TCP will repair them (unless sending into a full outer TCP socket buffer shows up back to the inner TCP as a packet loss?). 2) Nesting of ECN - Inner TCP connections will not be able to use effectively ECN on the portion of the path covered by the outer TCP connection. 3) Impact of congestion response on aggregate - The general "TCP in TCP" problem is mentioned, and is mostly appropriate for a single flow. If an aggregate of flows is sharing the same outer TCP connection, there may be additional concerns about how the congestion response behavior impacts an aggregate of flows, since it may cause a shared delay spike even to low-rate flows rather than distributing losses proportional to per-flow throughput. 4) Additional potential for bufferbloat - Since TCP does not bound latency, some applications in the IPsec-protected aggregate could drive latency of the shared connection up and impact the aggregate of flows that may include real-time applications. The socket buffer for the outer TCP connection might need to be limited in size to ensure some bounds? Not addressing these could lead to poor experiences in deployment, if implementations make wrong assumptions or fail to consider them. In the security considerations section, there are several RFCs on mechanisms to increase robustness to RST attacks and SYN floods that could be mentioned if it's worthwhile. From nobody Tue Apr 25 11:36:49 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 218671316EF; Tue, 25 Apr 2017 11:36:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP6oqxa_Ozh6; Tue, 25 Apr 2017 11:36:46 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0375A131523; Tue, 25 Apr 2017 11:36:42 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3PIa7gk028389 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 11:36:08 -0700 (PDT) From: Joe Touch To: draft-ietf-ipsecme-tcp-encaps@ietf.org, ipsec@ietf.org Cc: ipsecme-chairs@tools.ietf.org Message-ID: Date: Tue, 25 Apr 2017 11:36:06 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [IPsec] informal ports and transport review of ipsecme-chairs@tools.ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 18:36:47 -0000 Hi, all, I'm providing this feedback at the request of the ADs. The port information is based on my experience as IANA port review team lead. The transport information is based on my experience in TSV-ART. Joe ---------------- Ports issues: Every bit pattern, including those using magic numbers, is already owned and under the control of each assigned port. It is not appropriate for any new service to hijack that pattern as having a different meaning UNLESS explicitly updating the service on that port. A simple summary of what needs to change, in 2119-language: - this approach MUST NOT be described as applying to any assigned number unless also updating the associated RFC - this approach MUST NOT be described as applying to any unassigned but assignable, or reserved port - this approach MUST NOT use any existing assigned port in an example unless also updating the associated RFC (including 4500 and 443) - IMO, this is a new service that therefore MUST either request a new assignment (for TCP only) or be limited to operating only over dynamic ports, as per RFC6335 ------------------ TCP issues: This approach has issues with its use of TCP as well, as follows: - TCP MSS has nothing to do with fragmentation; it is primarily associated with IP reassembly - TCP over TCP discussion is insufficient; there are known interactions that amplify the problem far beyond either one alone --- From nobody Tue Apr 25 12:04:51 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4BF131768; Tue, 25 Apr 2017 12:04:49 -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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpLr-57LNVKs; Tue, 25 Apr 2017 12:04:47 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 977F4131761; Tue, 25 Apr 2017 12:04:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wCCM061fxzDKc; Tue, 25 Apr 2017 21:04:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1493147084; bh=f/7TNPkT13RHi2puX7OBIF8oZiIzdg5DTxTiODgRfQs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=afsrg9DsysCI6FNF4+c8yzikikRnhbRUX9ZUtzAK/xBkh8CwcE8jB26/eos2F/Y9d Fg6U7ipXoZWDohjOTDfiFT2YsY5D1axUBLhyfKHrqrC9kjrNAnjih3LHnAAEP7dqtx eKex/kdmbZC0iRHukAhpUYiiSz4LP/L0jp1ZvAD8= 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 HPYENqacLCGY; Tue, 25 Apr 2017 21:04:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 25 Apr 2017 21:04:42 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 722D4322DC7; Tue, 25 Apr 2017 15:04:41 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 722D4322DC7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6A0B640B828B; Tue, 25 Apr 2017 15:04:41 -0400 (EDT) Date: Tue, 25 Apr 2017 15:04:41 -0400 (EDT) From: Paul Wouters To: Joe Touch cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, "ipsec@ietf.org WG" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] informal ports and transport review of ipsecme-chairs@tools.ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 19:04:50 -0000 On Tue, 25 Apr 2017, Joe Touch wrote: > Ports issues: > > Every bit pattern, including those using magic numbers, is already owned and under the control of each assigned port. It is not appropriate for any new service to hijack that pattern as having a different meaning UNLESS explicitly updating the service on > that port. > > A simple summary of what needs to change, in 2119-language: > > - this approach MUST NOT be described as applying to any assigned number unless > also updating the associated RFC So it should add an Updates: RFC-3947 It's a little weird. 3947 reserved TCP 4500, but did not specify how to actually use TCP at all. It seems it was mostly preventatively reserved. > - this approach MUST NOT be described as applying to any unassigned but > assignable, or reserved port > > - this approach MUST NOT use any existing assigned port in an example unless also > updating the associated RFC (including 4500 and 443) > > - IMO, this is a new service that therefore MUST either request a new assignment (for > TCP only) or be limited to operating only over dynamic ports, as per RFC6335 This issue is really everyone circling around the elephant in the room. Part of this draft is designed to break through firewalls and middle-ware that only let out port 443 traffic unmangled. We cannot really write that we are doing this, despite everyone knowing we are doing this. Your suggestions that we need to not mention 443 without updating the RFC defining 443 is hard to meet. Not only because we'd have an IKE document updating a TLS document, but also because IANA actually has not RFC listed for the definition of port 443. I'm already a little annoyed that the draft cannot (politically) specify how to use port 443 with TLS to tunnel IKE and ESP over TCP. It will lead to interoperability issues because it is not specified. Becoming more quiet about port 443 isn't going to help anyone and will only increase the large number of incompatible SSL-VPNs out there whose main reason for existing is that IKE/IPsec cannot leave some networks unless using abusing TLS over 443. > ------------------ > TCP issues: > > This approach has issues with its use of TCP as well, as follows: > > - TCP MSS has nothing to do with fragmentation; it is primarily > associated with IP reassembly I guess that text can be fixed. > - TCP over TCP discussion is insufficient; there are known > interactions that amplify the problem far beyond either one alone The text is already basically saying "tcp over tcp is such a disaster, really try to move back to udp as soon as possible and really try that often because tcp over tcp is really really bad". I don't know why more text is needed. Paul > --- > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Tue Apr 25 13:04:40 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81727131799; Tue, 25 Apr 2017 13:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpudZEb9Hx4e; Tue, 25 Apr 2017 13:04:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0A1661317AE; Tue, 25 Apr 2017 13:04:34 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3PK3jba014021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 13:03:46 -0700 (PDT) To: Paul Wouters Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, "ipsec@ietf.org WG" References: From: Joe Touch Message-ID: Date: Tue, 25 Apr 2017 13:03:44 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [IPsec] informal ports and transport review of ipsecme-chairs@tools.ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 20:04:38 -0000 Hi, Paul, On 4/25/2017 12:04 PM, Paul Wouters wrote: > On Tue, 25 Apr 2017, Joe Touch wrote: > >> Ports issues: >> >> Every bit pattern, including those using magic numbers, is already >> owned and under the control of each assigned port. It is not >> appropriate for any new service to hijack that pattern as having a >> different meaning UNLESS explicitly updating the service on >> that port. >> >> A simple summary of what needs to change, in 2119-language: >> >> - this approach MUST NOT be described as applying to any assigned >> number unless >> also updating the associated RFC > > So it should add an Updates: RFC-3947 But also section 4 needs to be revised and the notion of the magic string completely removed. You won't need a magic string if you use an assigned port and you should NEVER be abusing (your words, below) someone else's port for your purposes. In fact, IMO, this doc should have a MUST NOT be used except with ports specifically designated. > It's a little weird. 3947 reserved TCP 4500, but did not specify how > to actually use TCP at all. It seems it was mostly preventatively > reserved. That was IANA policy before RFC6335, when we shifted to "only assign protocols actually in use". > >> - this approach MUST NOT be described as applying to any >> unassigned but >> assignable, or reserved port >> >> - this approach MUST NOT use any existing assigned port in an >> example unless also >> updating the associated RFC (including 4500 and 443) >> >> - IMO, this is a new service that therefore MUST either request a >> new assignment (for >> TCP only) or be limited to operating only over dynamic ports, as per >> RFC6335 > > This issue is really everyone circling around the elephant in the room. > Part of this draft is designed to break through firewalls and > middle-ware that only let out port 443 traffic unmangled. We cannot > really write > that we are doing this, despite everyone knowing we are doing this. > > Your suggestions that we need to not mention 443 without updating the > RFC defining 443 is hard to meet. Not only because we'd have an IKE > document updating a TLS document, but also because IANA actually has > not RFC listed for the definition of port 443. It's not listed, but it would probably be rfc2818 or one of the ones that updates that. However, I'd personally want someone involved from HTTPWG to sign off on this. > I'm already a little annoyed that the draft cannot (politically) specify > how to use port 443 with TLS to tunnel IKE and ESP over TCP. Here's the thing: You get to define your service. You do not get to define someone else's. You would be squatting (using someone else's ports for your purposes), pure and simple. I'm not sorry if that annoys you or you consider that politically incorrect. > It will > lead to interoperability issues because it is not specified. Becoming > more quiet about port 443 isn't going to help anyone It is - it protects HTTPS for the rest of us. > and will only > increase the large number of incompatible SSL-VPNs out there whose > main reason for existing is that IKE/IPsec cannot leave some networks > unless using abusing TLS over 443. You said it - abusing. The IETF should never condone that behavior in a new standard. > >> ------------------ >> TCP issues: >> >> This approach has issues with its use of TCP as well, as follows: >> >> - TCP MSS has nothing to do with fragmentation; it is primarily >> associated with IP reassembly > > I guess that text can be fixed. > >> - TCP over TCP discussion is insufficient; there are known >> interactions that amplify the problem far beyond either one alone > > The text is already basically saying "tcp over tcp is such a disaster, > really try to move back to udp as soon as possible and really try > that often because tcp over tcp is really really bad". I don't know > why more text is needed. I agree this is less important - it's basically hurting yourself. I think it's worth noting that the result is unpredictably worse than two TCPs back to back, at least, though, as a warning to designers. Joe From nobody Tue Apr 25 13:55:36 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5EC7129443; Tue, 25 Apr 2017 13:55:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149315373484.4283.11097377000445683422.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 13:55:34 -0700 Archived-At: Subject: [IPsec] Kathleen Moriarty's Yes on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 20:55:35 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for documenting this practice to improve interoperability. This practice has been in place for a while and I think this is a helpful document. I have a few comments. I think it would be good for the introduction to be more explicit on where the problem lies that has resulted in this common practice of tunneling this traffic through TCP. The following sentence could be modified: OLD: Many network middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through since they appear to be web traffic. NEW (or something along these lines): Many network edge middleboxes that filter traffic on public hotspots block all UDP traffic, including IKE and IPsec, but allow TCP connections through since they appear to be web traffic. I think it's important to note that this is happening at the edge in case that is not clear enough with the phrase "public hotspots". If it's more than the edge where this is happening, and I'm not right about this suggested change, please just say so. For section 11 - I think it's worth adding more text to hit on the concerns Warren raised in one of his comments. Here are some thoughts in case it is helpful: I agree with Warren that the result of operators not being able to identify this traffic should be mentioned, although this is tricky. The port discussion in other AD reviews and discouraging the use of 443 may change this to be identifiable traffic over TCP 4500 with the required stream prefix only for legitimate uses, or in reality, 443 if this stays undocumented because of existing implementations. Warren commented on operators not being able to detect this traffic is an important one, but I think it's fine to say the intent is to circumvent ACLs or firewall rules as opposed to avoiding detection. Then saying that avoiding detection is a result or unintended side effect. Side comment not intended for any new text: It would be good if operators observed the blocked ports (UDP 500) and figured out that they should open the port, but this has been a problem for some time and not all networks have dedicated operators (who want to fix this and similar issues) or ones with the time and skill sets to fix the problem. From nobody Tue Apr 25 13:59:52 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F4B128B8F; Tue, 25 Apr 2017 13:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v4US4GdrIE6N; Tue, 25 Apr 2017 13:59:47 -0700 (PDT) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 2324A1252BA; Tue, 25 Apr 2017 13:59:47 -0700 (PDT) Received: by mail-wm0-x241.google.com with SMTP id u65so28304375wmu.3; Tue, 25 Apr 2017 13:59:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VxK9iiQv/T/9euRhILgDYWRMRIMSmsw374v2yr+fUQI=; b=LYgGfjBdyaYrE3UVW0b6HjyRW2DrxXNMRZ3z3woh9eTlQ02judXN/Zo9MEUtZYBYg+ 81sSxbfPUCZSbGSbYCiuKUB/0XEp8zbyeSyRRmzv1J1c/HLRJWbVlQEkBuBRRwuvD7lC I7k/yi706JEw5XyfSy6gswwfnPwmWmfuwmein1SKKE+Fuc8QeFY1xHUxiGBR7kixx76E IEISu4GX2ftKpA5zqVk9qCWGAf53Tmu3MAgH3/O7bAuc9zQWZ50SLuuZnyk3WaLWtLZK bxrrGpSgwDOSjXygve2gjMTGNEsZqDmt1FPFzAhOPhE9xwMLk0elrkHfDB94vOnDm1IR dUwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VxK9iiQv/T/9euRhILgDYWRMRIMSmsw374v2yr+fUQI=; b=aPWjAr6NIqllHAoSB7oklvClL4fg8PHIZPBwfqkx9YUHddd+1MCkEh8tfkT40rvyBq DD1bvQxH4xanvmMZh2qoIKase2eYyxlp+B9vcGLQkWBruK3/kbCu8bTwM2rsYHYJ01DI t2e7HkeplXBFkKokmrdAnTwFfsyzuO5+tOdmmIVI7FJ9HQvZK9cyygJeC6IsXJtns02x VR6UG1pCa7b7FQvqXOcTmNbDjwe9j+8ncP9KJXjWKR/foweAnl8LjlyG3OH3ToTRK9e6 EPLzgoXe7M8Z9oA2c3ocL/8X4Ua2OdSk6+ElorCIiZFUKawp4K0eubktgir27Gp5XAhM N8sQ== X-Gm-Message-State: AN3rC/6TbeC936PSAge+/bPGMQXrEDeyEw+EB2UgabLU6C460bW/el0h I4AxiAle/t+E9OYmNF0= X-Received: by 10.80.169.161 with SMTP id n30mr6742675edc.81.1493153985640; Tue, 25 Apr 2017 13:59:45 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id m36sm644013edd.25.2017.04.25.13.59.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 13:59:44 -0700 (PDT) From: Yoav Nir Message-Id: <5B8CCE6E-B6DA-423B-A145-6C207B0E1C0F@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6BE99752-12DB-4DD9-BC55-A2542C5AB7A3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 25 Apr 2017 23:59:42 +0300 In-Reply-To: Cc: Paul Wouters , "ipsec@ietf.org WG" , draft-ietf-ipsecme-tcp-encaps@ietf.org To: Joe Touch References: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] informal ports and transport review of ipsecme-chairs@tools.ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 20:59:49 -0000 --Apple-Mail=_6BE99752-12DB-4DD9-BC55-A2542C5AB7A3 Content-Type: multipart/alternative; boundary="Apple-Mail=_1C03AF6A-21D0-4507-918D-82AE35727441" --Apple-Mail=_1C03AF6A-21D0-4507-918D-82AE35727441 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Joe I haven=E2=80=99t been involved with this draft, but I don=E2=80=99t = believe that last statement is correct: > On 25 Apr 2017, at 23:03, Joe Touch wrote: >=20 >>=20 >> This issue is really everyone circling around the elephant in the = room. >> Part of this draft is designed to break through firewalls and >> middle-ware that only let out port 443 traffic unmangled. We cannot >> really write >> that we are doing this, despite everyone knowing we are doing this. >>=20 >> Your suggestions that we need to not mention 443 without updating the >> RFC defining 443 is hard to meet. Not only because we'd have an IKE >> document updating a TLS document, but also because IANA actually has >> not RFC listed for the definition of port 443. >=20 > It's not listed, but it would probably be rfc2818 or one of the ones > that updates that. >=20 > However, I'd personally want someone involved from HTTPWG to sign off = on > this. >=20 >> I'm already a little annoyed that the draft cannot (politically) = specify >> how to use port 443 with TLS to tunnel IKE and ESP over TCP. >=20 > Here's the thing: >=20 > You get to define your service. >=20 > You do not get to define someone else's. >=20 > You would be squatting (using someone else's ports for your purposes), > pure and simple. I don=E2=80=99t believe that TCP port 443 on the host at 192.0.2.7 = =E2=80=9Cbelongs=E2=80=9D in any sense of the word to the HTTP working = group. While it is the default port for HTTPS, that protocol can run on any = port depending on the value in origin (RFC 6454). The draft makes it clear in section 2 that the port used is = pre-configured on both IKE initiator and IKE responder. The draft does = not assign or re-assign any ports. Yes, there is a suggestion to use port 443 because it is usable in more = networks than other ports. That is why TCP port 443 has been used by = Skype, AiCloud file sharing, Call of Duty, various =E2=80=9CSSL VPN=E2=80=9D= products and many others. They=E2=80=99ve been doing that for over a = decade. It is way too late to close the barn doors, and we don=E2=80=99t = even have the authority to do so. We can remove all references to specific ports and leave only text about = pre-configuration. IMO this amounts to a wind and a nod, because we all = know which port is going to get configured. Yoav --Apple-Mail=_1C03AF6A-21D0-4507-918D-82AE35727441 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, Joe

I = haven=E2=80=99t been involved with this draft, but I don=E2=80=99t = believe that last statement is correct:

On = 25 Apr 2017, at 23:03, Joe Touch <touch@isi.edu> wrote:


This issue is = really everyone circling around the elephant in the room.
Part of this draft is designed to break through firewalls = and
middle-ware that only let out port 443 traffic = unmangled. We cannot
really write
that we = are doing this, despite everyone knowing we are doing this.

Your suggestions that we need to not mention = 443 without updating the
RFC defining 443 is hard to meet. = Not only because we'd have an IKE
document updating a TLS = document, but also because IANA actually has
not RFC = listed for the definition of port 443.

It's not listed, but it would probably be = rfc2818 or one of the ones
that updates that.
However, I'd personally want someone involved = from HTTPWG to sign off on
this.
I'm already a little annoyed = that the draft cannot (politically) specify
how to use = port 443 with TLS to tunnel IKE and ESP over TCP.

Here's the thing:
   You get to define your = service.

   You do not get = to define someone else's.

You would be squatting (using someone else's = ports for your purposes),
pure and simple.

I don=E2=80=99= t believe that TCP port 443 on the host at 192.0.2.7 =E2=80=9Cbelongs=E2=80= =9D in any sense of the word to the HTTP working group. 

While it is the default = port for HTTPS, that protocol can run on any port depending on the value = in origin (RFC 6454).

The draft makes it clear in section 2 that the port used is = pre-configured on both IKE initiator and IKE responder. The draft does = not assign or re-assign any ports. 

Yes, there is a suggestion to use port = 443 because it is usable in more networks than other ports. That is why = TCP port 443 has been used by Skype, AiCloud file sharing, Call of Duty, = various =E2=80=9CSSL VPN=E2=80=9D products and many others. They=E2=80=99v= e been doing that for over a decade. It is way too late to close the = barn doors, and we don=E2=80=99t even have the authority to do = so. 

We = can remove all references to specific ports and leave only text about = pre-configuration. IMO this amounts to a wind and a nod, because we all = know which port is going to get configured.

Yoav





= --Apple-Mail=_1C03AF6A-21D0-4507-918D-82AE35727441-- --Apple-Mail=_6BE99752-12DB-4DD9-BC55-A2542C5AB7A3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY/7i+AAoJELhJCxUKWMyZ8DkH/0Be6utFR+ilcvwzwfSghN1D iz/ynvxYAQuVp2F6JL75w7FmuaukIsPUFuMJOe8BSoX+C8MXlZuA7BAwQNR6AZCO XT1bBBCejEz29ba9a7sk1pVTgKgkoQAroJM1XhAURKPAj5Y2Qe08jOaASucd3qoL qg8MrJqiy3XBfPqkxrpMQX9w3KIAsPWQN8cdU7AbzB3B3TBUd9JRiCTLDaK8cdpq bLRI5QJkrszB5hIU4sHz74q3v2f51uFOoA5Xb/tsOlptI5dfnu/RFjuHLakOMl6s JIvw7C75zdnJdk+dQ3fOg1Fs08+275LO3DJH9nPWOoTxdGfjjjIqnFQMT534Pcw= =hw4t -----END PGP SIGNATURE----- --Apple-Mail=_6BE99752-12DB-4DD9-BC55-A2542C5AB7A3-- From nobody Tue Apr 25 14:16:40 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAA5129353; Tue, 25 Apr 2017 14:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NtF-AkVb8B1z; Tue, 25 Apr 2017 14:16:36 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 7D7A2129443; Tue, 25 Apr 2017 14:16:19 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3PLFg2e000765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 25 Apr 2017 14:15:42 -0700 (PDT) To: Yoav Nir Cc: Paul Wouters , "ipsec@ietf.org WG" , draft-ietf-ipsecme-tcp-encaps@ietf.org References: <5B8CCE6E-B6DA-423B-A145-6C207B0E1C0F@gmail.com> From: Joe Touch Message-ID: Date: Tue, 25 Apr 2017 14:15:41 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <5B8CCE6E-B6DA-423B-A145-6C207B0E1C0F@gmail.com> Content-Type: multipart/alternative; boundary="------------6B6FE409E6222C03B7671094" Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 21:16:38 -0000 This is a multi-part message in MIME format. --------------6B6FE409E6222C03B7671094 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit First, correcting the subject line (sorry - that looks like an erroneous paste on my part). Also below... On 4/25/2017 1:59 PM, Yoav Nir wrote: > Hi, Joe > > I haven’t been involved with this draft, but I don’t believe that last > statement is correct: > >> On 25 Apr 2017, at 23:03, Joe Touch > > wrote: >> >>> >>> This issue is really everyone circling around the elephant in the room. >>> Part of this draft is designed to break through firewalls and >>> middle-ware that only let out port 443 traffic unmangled. We cannot >>> really write >>> that we are doing this, despite everyone knowing we are doing this. >>> >>> Your suggestions that we need to not mention 443 without updating the >>> RFC defining 443 is hard to meet. Not only because we'd have an IKE >>> document updating a TLS document, but also because IANA actually has >>> not RFC listed for the definition of port 443. >> >> It's not listed, but it would probably be rfc2818 or one of the ones >> that updates that. >> >> However, I'd personally want someone involved from HTTPWG to sign off on >> this. >> >>> I'm already a little annoyed that the draft cannot (politically) specify >>> how to use port 443 with TLS to tunnel IKE and ESP over TCP. >> >> Here's the thing: >> >> You get to define your service. >> >> You do not get to define someone else's. >> >> You would be squatting (using someone else's ports for your purposes), >> pure and simple. > > I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs†> in any sense of the word to the HTTP working group. Strictly, the port is assigned based on a service definition. On any given host, any user can define any port any way they see fit, e.g., they can run DNS on port 110 or IMAP on port 53. However, a new standard should never be making a change to the service defined for a port that is already assigned to another party (they can change a service they have been assigned). > While it is the default port for HTTPS, that protocol can run on any > port depending on the value in origin (RFC 6454). Yes, any protocol can run on any port number (as per above), as long as the endpoints agree. But that's not what you're talking about here - you're saying that if you get "IKETCP" on a port, then you can trust that it is your service. That's incorrect. You don't get to define the string "IKETCP" for other services. > The draft makes it clear in section 2 that the port used is > pre-configured on both IKE initiator and IKE responder. The draft does > not assign or re-assign any ports. Section 4 claims that the use of the magic string differentiates this service from the default assigned service or any other service. That's incorrect. You don't have that authority. > Yes, there is a suggestion to use port 443 because it is usable in > more networks than other ports. Again, you don't have the authority to say what "IKETCP" means on port 443. Yes, if the port is explicitly indicated, you can use whatever port you want. But you should never imply that this system should run on ports assigned to other services that are running in parallel - you do not have that authority. > That is why TCP port 443 has been used by Skype, AiCloud file sharing, > Call of Duty, various “SSL VPN†products and many others. They’ve been > doing that for over a decade. It is way too late to close the barn > doors, and we don’t even have the authority to do so. You do not have the authority to endorse or standardize this behavior either. It remains non-compliant squatting. > We can remove all references to specific ports and leave only text > about pre-configuration. IMO this amounts to a wind and a nod, because > we all know which port is going to get configured. You should be saying that the port is indicated explicitly (which is the equivalent of pairwise endpoint negotiation) or use port 4500 (or maybe get your own separate assignment). But the entire text on the magic number being appropriate when sharing an existing assignment is incorrect and needs to be removed IMO. Joe --------------6B6FE409E6222C03B7671094 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

First, correcting the subject line (sorry - that looks like an erroneous paste on my part).

Also below...


On 4/25/2017 1:59 PM, Yoav Nir wrote:
Hi, Joe

I haven’t been involved with this draft, but I don’t believe that last statement is correct:

On 25 Apr 2017, at 23:03, Joe Touch <touch@isi.edu> wrote:


This issue is really everyone circling around the elephant in the room.
Part of this draft is designed to break through firewalls and
middle-ware that only let out port 443 traffic unmangled. We cannot
really write
that we are doing this, despite everyone knowing we are doing this.

Your suggestions that we need to not mention 443 without updating the
RFC defining 443 is hard to meet. Not only because we'd have an IKE
document updating a TLS document, but also because IANA actually has
not RFC listed for the definition of port 443.

It's not listed, but it would probably be rfc2818 or one of the ones
that updates that.

However, I'd personally want someone involved from HTTPWG to sign off on
this.

I'm already a little annoyed that the draft cannot (politically) specify
how to use port 443 with TLS to tunnel IKE and ESP over TCP.

Here's the thing:

   You get to define your service.

   You do not get to define someone else's.

You would be squatting (using someone else's ports for your purposes),
pure and simple.

I don’t believe that TCP port 443 on the host at 192.0.2.7 “belongs†in any sense of the word to the HTTP working group.

Strictly, the port is assigned based on a service definition.

On any given host, any user can define any port any way they see fit, e.g., they can run DNS on port 110 or IMAP on port 53.

However, a new standard should never be making a change to the service defined for a port that is already assigned to another party (they can change a service they have been assigned).

While it is the default port for HTTPS, that protocol can run on any port depending on the value in origin (RFC 6454).

Yes, any protocol can run on any port number (as per above), as long as the endpoints agree. But that's not what you're talking about here - you're saying that if you get "IKETCP" on a port, then you can trust that it is your service.

That's incorrect. You don't get to define the string "IKETCP" for other services.

The draft makes it clear in section 2 that the port used is pre-configured on both IKE initiator and IKE responder. The draft does not assign or re-assign any ports.
Section 4 claims that the use of the magic string differentiates this service from the default assigned service or any other service. That's incorrect. You don't have that authority.

Yes, there is a suggestion to use port 443 because it is usable in more networks than other ports.
Again, you don't have the authority to say what "IKETCP" means on port 443.

Yes, if the port is explicitly indicated, you can use whatever port you want. But you should never imply that this system should run on ports assigned to other services that are running in parallel - you do not have that authority.

That is why TCP port 443 has been used by Skype, AiCloud file sharing, Call of Duty, various “SSL VPN†products and many others. They’ve been doing that for over a decade. It is way too late to close the barn doors, and we don’t even have the authority to do so.

You do not have the authority to endorse or standardize this behavior either.

It remains non-compliant squatting.

We can remove all references to specific ports and leave only text about pre-configuration. IMO this amounts to a wind and a nod, because we all know which port is going to get configured.

You should be saying that the port is indicated explicitly (which is the equivalent of pairwise endpoint negotiation) or use port 4500 (or maybe get your own separate assignment). But the entire text on the magic number being appropriate when sharing an existing assignment is incorrect and needs to be removed IMO.

Joe
--------------6B6FE409E6222C03B7671094-- From nobody Tue Apr 25 18:42:54 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C620120726; Tue, 25 Apr 2017 18:42:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 18:42:53 -0700 Archived-At: Subject: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 01:42:53 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have one (hopefully easy) point that I think needs to be fixed before progressing. Section 6, paragraph 6 says : "... if the TCP Originator stream is missing the stream prefix, or message frames are not parsable as IKE or ESP messages), it MUST close the TCP connection." IIUC, the entire point of having the stream prefix is to allow the TCP responder to demux between this protocol, and some other protocol that would normally run on that port. Saying it MUST close the TCP session seems to completely remove that value. I assume people meant to allow the respondent to delegate a stream out to some other protocol handler if the prefix is not present? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive Comments: -2: -- 2nd bullet (and elsewhere) I think this needs a discussion about how those configured ports are likely to be in the assigned range, and the likely impact. (I recognize that tunneling over a port assigned to something else is a primary reason for doing this. I'm not arguing against it; I just think the implications warrant discussion.) -- 2nd to last paragraph: "This document leaves the selection of TCP ports up to implementations." I suspect "configurable local policy" would make more sense. Leaving it up to "implementations" leaves open the chance of different implementations making non-intersecting port choices, which doesn't help interoperability. -3, first paragraph: Are people confident there will never, ever be a need to demux protocols other than IKE and ESP? If not, this approach may paint people in a corner in the future. I ask because we made similar choices with DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. See RFC7983 for a discussion. (Note that this would have been a DISCUSS point, but I think it's reasonably likely that there really won't be other protocols here. But I want to make sure people have thought about it.) -4, first paragraph: What is the expected behavior from a peers that do not support this spec when they receive a TCP stream with the magic number on a port for some other protocol? -6: First paragraph: It would be helpful to mention behavior on receipt of a stream without the magic number here. But see the DISCUSS point. -8: "... MUST support dynamically enabling and disabling TCP encapsulation..." seems unreasonably strong, especially since the requirement to try UDP before TCP is only a SHOULD. Does this contemplate situations where it might be impossible to use TCP on the after a network change? - Appendix A: Doesn't the use of the NULL cipher invalidate one of the primary reasons to use TLS? (Namely to obscure the fact that this is not HTTP, or whatever other protocol is assigned to the port?) Editorial Comments: - Please expand IKE and ESP on first mention in both the abstract and body. -3, 2nd paragraph: s/"may be able"/"is able". -3.2, " The SPI field in the ESP header MUST NOT be a zero value." Is this a new requirement for this draft? That is, does ESP otherwise allow zero value SPIs? If not, please consider dropping the MUST NOT. -5.1: "...SHOULD always attempt negotiate IKE over UDP first" This is stated several times in the draft, more than once with the SHOULD. It's better to avoid redundant 2119 keywords. -6: "... IKE Figure 1 and ESP Figure 2... ": Broken section cross-references. -10, title: Please expand DPD. -12: Several previous sections pointed to section 12 for more information about why one needed to try direct connections or UDP before TCP. But I don't find any specifics on that in this section. - Appendix A: Why is this an appendix? It contains normative text that seems central to certain use cases. I was surprised to see no discussion about using TLS in section 11, where it seemed quite relevant. From nobody Tue Apr 25 19:10:59 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8415E1317D1; Tue, 25 Apr 2017 19:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mHKh0oNRkVmC; Tue, 25 Apr 2017 19:10:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10ACD1243FE; Tue, 25 Apr 2017 19:10:48 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wCNpS4cMqz3BZ; Wed, 26 Apr 2017 04:10:40 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1493172640; bh=jO5CsFDYz7dI75KwUO2vnqD143ZA4so72ba7Rjn2m7g=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=of5GRIaZ71HgsQWegfHnYSRw9zdDkNP5Z4eEs9tgq5wQ+zRMUH7FBMjkVUeeQzx+u PRuVBPCa933UrGBt4akpmIGQD5hc8/PIia0mecNM1ABTA/OmJZqCz5R+9kSBvabJER mcYJmUTMDzArpLYYPLYdlllErYt6L2xECHcS1Rpc= 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 Sa3CtNKlRuvi; Wed, 26 Apr 2017 04:10:38 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 26 Apr 2017 04:10:38 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D2B3F322DC7; Tue, 25 Apr 2017 22:10:37 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D2B3F322DC7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B63B540C97ED; Tue, 25 Apr 2017 22:10:37 -0400 (EDT) Date: Tue, 25 Apr 2017 22:10:37 -0400 (EDT) From: Paul Wouters To: Kathleen Moriarty cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, kivinen@iki.fi In-Reply-To: <149315373484.4283.11097377000445683422.idtracker@ietfa.amsl.com> Message-ID: References: <149315373484.4283.11097377000445683422.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Kathleen Moriarty's Yes on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 02:10:50 -0000 On Tue, 25 Apr 2017, Kathleen Moriarty wrote: [ Note at least Joe Touch seemed to think I'm an author. I am not. I meant the royal "we" as in the IPsecME WG. I have a vested interest because as an implementer I want an interoperable standard for this ] > The port discussion in other AD reviews and discouraging the use of 443 may > change this to be identifiable traffic over TCP 4500 with the required > stream prefix only for legitimate uses If you insist on this, one of two things will happen: 1) The landscape stays as fragmented and non-interoperable and it will hurt IKE/IPsec and we will see more SSL VPN varients and openvpn usage. No one will implement the resulting RFC. 2) Everyone will implement draft-ietf-ipsecme-tcp-encaps-09 which will never become an RFC. > , or in reality, 443 if this stays > undocumented because of existing implementations. Warren commented on > operators not being able to detect this traffic is an important one, but > I think it's fine to say the intent is to circumvent ACLs or firewall > rules as opposed to avoiding detection. Then saying that avoiding > detection is a result or unintended side effect. Could the ADs come up with the weasel words they and Joe Touch would find acceptable? I don't get the idea there is agreement there. Paul From nobody Tue Apr 25 19:11:43 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D601317D3; Tue, 25 Apr 2017 19:11:35 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DSCHs4EE3NDn; Tue, 25 Apr 2017 19:11:33 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 B17211317D1; Tue, 25 Apr 2017 19:11:33 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id v14so30950856pfd.2; Tue, 25 Apr 2017 19:11:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=evMDVHPZgM9cttpysbB+4dbRDSmV9KQ4B9M+e7ZKOf0=; b=CJmdaQ4ld09DwG690LWXOPdr0eKVYkjGLDLXOiwrSyLzBRvAreMM74VC8p3BdiUYpd wqFB00P71YsvIPiR7RKhcH+lupk97prxJhBsdpCBqIWmoxsuXwq5JkcZ1Y6efyucMbpD vj/XhoIC4KvQMlZ4EGcSbqmvTmg4RxX8QiPc1V96tP5+/kc/KTw5OXuuTNkRj4CnlZqa DQQDOfm+g86uoEMvHQxdyP6//cEKNQI1xx45oCOaF6odP6o3g0P9jFlDS6znXK5jHhH0 ulcKXnpRGlgTn0colW18i+oUCeoJiufAjrYqXKkovKT0M5jPnpoWDG/b0UYWoEpYU1EV tmQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=evMDVHPZgM9cttpysbB+4dbRDSmV9KQ4B9M+e7ZKOf0=; b=lPznQmPMSeGz20g605toCXVk5NifEZcdKFcjBQrqKIg3ckUTp3wcPLcMWMSaPNY7Fp fO+FxA+ccfcNfVGk6eBMxKQeu4Of/7NS5K2bYjUfnc5YuVhS+sXiX5tpE+9GWMf62e7p hnvM8NvRhn5ZLPWSJ+Gh5tHn6FPLeSVdOIfGjy46QOYLzbwvtsnJ00a5369pFbgzBwsa Y9mXViHy34CDCKQtC8GGvDiz+byh+S3+0UrNB7lkP6XnEP6xANKDN0jMDXQ5gLYkffJ3 sxY+ZnZp2u1BjoUSOc8JrsBST6KqAhRqdXVtFXnINln09c+oPjnZ/1pH+gonfjdbsOSk kpxg== X-Gm-Message-State: AN3rC/7nlG+PShS8MC4QsnJRhajCEPCd2fVSSZ66jomAfx2XnapBVVtm Wc6jUfcfaC18KAzhgYONdTrdiBSXysOs X-Received: by 10.98.92.2 with SMTP id q2mr9974019pfb.244.1493172693218; Tue, 25 Apr 2017 19:11:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Tue, 25 Apr 2017 19:10:52 -0700 (PDT) In-Reply-To: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 25 Apr 2017 22:10:52 -0400 Message-ID: To: Ben Campbell Cc: The IESG , "ipsec@ietf.org" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 02:11:36 -0000 Hi Ben & others, I may be able to help on a few of these, but the editors (etc.), please correct me if necessary. On Tue, Apr 25, 2017 at 9:42 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-ipsecme-tcp-encaps-09: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > I have one (hopefully easy) point that I think needs to be fixed before > progressing. > > Section 6, paragraph 6 says : "... if the TCP Originator stream is > missing the stream prefix, or message frames are not parsable as IKE or > ESP messages), it MUST close the TCP connection." > > IIUC, the entire point of having the stream prefix is to allow the TCP > responder to demux between this protocol, and some other protocol that > would normally run on that port. Saying it MUST close the TCP session > seems to completely remove that value. I assume people meant to allow the > respondent to delegate a stream out to some other protocol handler if the > prefix is not present? > I believe that this is because there is presumed to be no other service operating on the listening port (assuming a VPN concentrator), but that's not explicitly stated either. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive Comments: > > -2: > -- 2nd bullet (and elsewhere) > I think this needs a discussion about how those configured ports are > likely to be in the assigned range, and the likely impact. (I recognize > that tunneling over a port assigned to something else is a primary reason > for doing this. I'm not arguing against it; I just think the implications > warrant discussion.) > > -- 2nd to last paragraph: "This document leaves the selection of TCP > ports up to implementations." > I suspect "configurable local policy" would make more sense. Leaving it > up to "implementations" leaves open the chance of different > implementations making non-intersecting port choices, which doesn't help > interoperability. This may go more into unexplained assumptions... the clients authorized to connect to the server would need to know the correct port to establish a session and would be given that information specific to the implementation. With this assumption, the above should be fine... but editors/AD/WG, please correct me if I am wrong. > > -3, first paragraph: > Are people confident there will never, ever be a need to demux protocols > other than IKE and ESP? If not, this approach may paint people in a > corner in the future. I ask because we made similar choices with > DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. > See RFC7983 for a discussion. (Note that this would have been a DISCUSS > point, but I think it's reasonably likely that there really won't be > other protocols here. But I want to make sure people have thought about > it.) > > -4, first paragraph: What is the expected behavior from a peers that do > not support this spec when they receive a TCP stream with the magic > number on a port for some other protocol? Maybe listing assumptions up front in the draft would help _IF_ the assumption is that the listening server is a VPN concentrator that wouldn't be listening for other services. > > -6: First paragraph: It would be helpful to mention behavior on receipt > of a stream without the magic number here. But see the DISCUSS point. > > -8: "... MUST support dynamically enabling and disabling TCP > encapsulation..." seems unreasonably strong, especially since the > requirement to try UDP before TCP is only a SHOULD. Does this contemplate > situations where it might be impossible to use TCP on the after a network > change? > > - Appendix A: Doesn't the use of the NULL cipher invalidate one of the > primary reasons to use TLS? (Namely to obscure the fact that this is not > HTTP, or whatever other protocol is assigned to the port?) Editors/AD correct me if I am wrong, but... No, if TLS is used with a NULL cipher, it'll pass inspection of a middle box validating the protocol. This doesn't need to use the cipher as it's negotiating the IPsec connection. > > Editorial Comments: > > - Please expand IKE and ESP on first mention in both the abstract and > body. These are on the list of well known acronyms: https://www.rfc-editor.org/materials/abbrev.expansion.txt > > -3, 2nd paragraph: s/"may be able"/"is able". > > -3.2, " The SPI field in the ESP header MUST NOT be a zero value." > Is this a new requirement for this draft? That is, does ESP otherwise > allow zero value SPIs? If not, please consider dropping the MUST NOT. > > -5.1: "...SHOULD always attempt negotiate IKE over UDP first" > This is stated several times in the draft, more than once with the > SHOULD. It's better to avoid redundant 2119 keywords. > > -6: "... IKE Figure 1 and ESP Figure 2... ": Broken section > cross-references. > > -10, title: Please expand DPD. > > -12: Several previous sections pointed to section 12 for more information > about why one needed to try direct connections or UDP before TCP. But I > don't find any specifics on that in this section. > > - Appendix A: Why is this an appendix? It contains normative text that > seems central to certain use cases. I was surprised to see no discussion > about using TLS in section 11, where it seemed quite relevant. > > -- Best regards, Kathleen From nobody Tue Apr 25 19:18:17 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F691317DD; Tue, 25 Apr 2017 19:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLdmykPxpo-u; Tue, 25 Apr 2017 19:18:14 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656101317D4; Tue, 25 Apr 2017 19:18:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3wCNz53BGYz14Z; Wed, 26 Apr 2017 04:18:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1493173089; bh=t1Yymrxx4StBpfXgBe6TAJr4b0tH/YjVqEqZ4RUMHYk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=rLgIoa3rmDK9ZQdW1p5IRYOiYOmLXAgx/Q9gRchPL+EVE7kksB1Or73aqjbYDK6DZ bdLsb7DlVAEdexro5ax4Iyfde3lv2pz5sM3JjdXUaEwdzjuOmv+6/dh4T8SkgdSjYC xULptgsOe2tiKia28pDjmRjbBHiCPwl40Z1ROJBY= 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 YVnR4byUENO6; Wed, 26 Apr 2017 04:18:06 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 26 Apr 2017 04:18:05 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D0DE6322DC7; Tue, 25 Apr 2017 22:18:04 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D0DE6322DC7 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id CBE5140C97ED; Tue, 25 Apr 2017 22:18:04 -0400 (EDT) Date: Tue, 25 Apr 2017 22:18:04 -0400 (EDT) From: Paul Wouters To: Kathleen Moriarty cc: Ben Campbell , "ipsec@ietf.org" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , Tero Kivinen In-Reply-To: Message-ID: References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20.999 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 02:18:15 -0000 On Tue, 25 Apr 2017, Kathleen Moriarty wrote: >> IIUC, the entire point of having the stream prefix is to allow the TCP >> responder to demux between this protocol, and some other protocol that >> would normally run on that port. Saying it MUST close the TCP session >> seems to completely remove that value. I assume people meant to allow the >> respondent to delegate a stream out to some other protocol handler if the >> prefix is not present? >> > > I believe that this is because there is presumed to be no other > service operating on the listening port (assuming a VPN concentrator), > but that's not explicitly stated either. Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of the other kinds of SSL VPNs or as the administration interface or user interface. >> -- 2nd to last paragraph: "This document leaves the selection of TCP >> ports up to implementations." >> I suspect "configurable local policy" would make more sense. Leaving it >> up to "implementations" leaves open the chance of different >> implementations making non-intersecting port choices, which doesn't help >> interoperability. > > This may go more into unexplained assumptions... the clients > authorized to connect to the server would need to know the correct > port to establish a session and would be given that information > specific to the implementation. With this assumption, the above > should be fine... but editors/AD/WG, please correct me if I am wrong. I am pretty sure what is meant is "configuration" and not "implementation". >> -4, first paragraph: What is the expected behavior from a peers that do >> not support this spec when they receive a TCP stream with the magic >> number on a port for some other protocol? > > Maybe listing assumptions up front in the draft would help _IF_ the > assumption is that the listening server is a VPN concentrator that > wouldn't be listening for other services. Support for TCP would be based on preconfiguration, so the client knows this out-of-band. It cannot be discovered during negotiation, because it is assumed the regular UDP ports are blocked, which is the only reason to attempt TCP to begin with. >> - Appendix A: Doesn't the use of the NULL cipher invalidate one of the >> primary reasons to use TLS? (Namely to obscure the fact that this is not >> HTTP, or whatever other protocol is assigned to the port?) > > Editors/AD correct me if I am wrong, but... > No, if TLS is used with a NULL cipher, it'll pass inspection of a > middle box validating the protocol. This doesn't need to use the > cipher as it's negotiating the IPsec connection. right, TLS happens to use encryption to get out, but it is not the encryption of the actual IKE/IPsec protocols, which keep using their own channel negotiations. Paul From nobody Tue Apr 25 19:27:42 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5185E1317D1; Tue, 25 Apr 2017 19:27:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlaxjdsHkyCb; Tue, 25 Apr 2017 19:27:39 -0700 (PDT) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 C7BDC1270B4; Tue, 25 Apr 2017 19:27:39 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id v1so25145908pgv.1; Tue, 25 Apr 2017 19:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sI6H/gHrTEedQ1FXvPBAeSa9+3LO8JK4AStMZt4j+o8=; b=s7zMJ2WfpR7D2F5dYnLCECjoc05RkqGOoSDHRaHD278aQNZzAbDRVzTUUukwCC+QbO mENjrsLFg/cFGQmbMegTu1dDMsX0xAE+ftn349lEsA3laSGD9Uo0/1fD1GroJxj7mMr0 gnlYSeFcIP/98B+GvpxVBcrAviGtuWF0p5An6DC3ajZH7jHpv3eqeEJtZWLDW9HyIE1x +Hank/LiqB0ZHhOspl2LFivC0czwB5FbpFGAVcYpvWTpOs7BbGzzp4qHodZnYGDvosZt VDpvKhLHEPfCLyG0OwXVn6k/Dhdva7zI7h41Y5DEI4HG5M4jpwfGrDoDdYLfT/cIMlUm kNbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sI6H/gHrTEedQ1FXvPBAeSa9+3LO8JK4AStMZt4j+o8=; b=D1i+41J8uXdjRlKP9AT2aS2WQ9zgbp1sirclyW1zqscwOnQZSgR/BEig5+iX3KVaNx hfuaKPNUz0+dWK7HBz2glN/YITzfagi+QxlbdnAMw447hbpOzLXMOLxOVso4Yiz5Sa2d 5hU0kEn+FfbbA/GVpsui82Gng/lEkOu7CnWpiGt61mQt+qLCdtBNJD4oYF/oREptd8qT uYFTIxvgqTdF76GR/f57xyAbhT4bS4h5XiL4HyVoE3NN03gtiigbXz4+ViO/jn2ZHkfO wSLIA0NglU7sMHWrXF+wVf9aBe6qLUoRPJJavSmkzLcqSs6XHvOuDSHPl1we+t4j5kXt DzfA== X-Gm-Message-State: AN3rC/6QtGucNr61A8NmB/WCOPqyuLbJCbosDTRIZWGlPJM2a/ldefQ7 x0PAmqcb8nRGqgAEnXjLxyoTiEUnIg== X-Received: by 10.99.62.68 with SMTP id l65mr29472557pga.172.1493173659378; Tue, 25 Apr 2017 19:27:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Tue, 25 Apr 2017 19:26:55 -0700 (PDT) In-Reply-To: References: <149315373484.4283.11097377000445683422.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 25 Apr 2017 22:26:55 -0400 Message-ID: To: Paul Wouters Cc: The IESG , "ipsec@ietf.org" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [IPsec] Kathleen Moriarty's Yes on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 02:27:41 -0000 Hey Paul, I'm reading through the comments and trying to think of ideas here.... and will continue to think about this a bit more, so I may have other ideas tomorrow. inline On Tue, Apr 25, 2017 at 10:10 PM, Paul Wouters wrote: > On Tue, 25 Apr 2017, Kathleen Moriarty wrote: > > [ Note at least Joe Touch seemed to think I'm an author. I am not. I > meant the royal "we" as in the IPsecME WG. I have a vested interest > because as an implementer I want an interoperable standard for this ] > >> The port discussion in other AD reviews and discouraging the use of 443 >> may >> change this to be identifiable traffic over TCP 4500 with the required >> stream prefix only for legitimate uses > > > If you insist on this, one of two things will happen: Note: I'm not insisting, but I see why other ADs are and I'm trying to think about this as I understand the reality of the situation having been responsible for these types of systems in the past. For the port 443 usage, using TLS with a NULL cipher is the recommended default in one example in the appendix. Why don't you just make this the method of connection when using 443 so that HTTP/TLS is used and then 443 is appropriate. You'd have to make this consistent throughout the draft and have agreement for this change with the WG, assuming it is ok technically. This would mean that 4500 could still use the fallback basic TCP encapsulation as the port doesn't have the same restrictions. If you are using the expected protocols (HTTP/TLS on TCP 443), it gets rid of the argument of reusing a port as you'd be using it for it's intended purpose - just encapsulating something else. > > 1) The landscape stays as fragmented and non-interoperable and it will > hurt IKE/IPsec and we will see more SSL VPN varients and openvpn > usage. No one will implement the resulting RFC. > > 2) Everyone will implement draft-ietf-ipsecme-tcp-encaps-09 which will > never become an RFC. > >> , or in reality, 443 if this stays >> undocumented because of existing implementations. Warren commented on >> operators not being able to detect this traffic is an important one, but >> I think it's fine to say the intent is to circumvent ACLs or firewall >> rules as opposed to avoiding detection. Then saying that avoiding >> detection is a result or unintended side effect. > > > Could the ADs come up with the weasel words they and Joe Touch would > find acceptable? I don't get the idea there is agreement there. I think some rewording is needed int eh document if others agree to this approach and I think they should. It limits the options for this protocol, but still allows use of 443. If you're asking about the other comment above, I can help with text, but that's just simple descriptive text to state the purpose of this more clearly and then the impact to operators (that might be the operators of the middleboxes preventing UDP 500 or might be operators at other points in the network). > > Paul -- Best regards, Kathleen From nobody Tue Apr 25 19:39:01 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71FA0131809; Tue, 25 Apr 2017 19:38:52 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtZ2nLhSVtNg; Tue, 25 Apr 2017 19:38:50 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::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 B62981273E2; Tue, 25 Apr 2017 19:38:50 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id v1so25264166pgv.1; Tue, 25 Apr 2017 19:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wzGimwhv+jKEWavo5s3Af0BYaRQpv2mVt0BsRnuWO8w=; b=XY2JMCVlNI9ClXLHt6n3a/x6Mpt8NZDYGBY+578V/ALt3wKmZVG15yw9EM+zRzu7pv ouA524A+qQ7rSOya3XsSZq3jOZK3HnvNXqKejTnVxtScsl3EjSauTYkB+sX2Uvg6c3cn QyYpi/FPQoypcIfojLz5jDbYKyis46CXr325n9vNkC5yqciw4s9VMoDNUMIXXHH10iYR 9mafVx0ZL0rzM9U+K2ZAUv5RXhnV745G+9SgOyJGUSlOcuZkB+PKiYBdDUpCmotlwHD3 EzFfrtttFEDaoTDdcthEPDAcmnldBvUaaU3dpQoCpvmxLkNympKhjBrCQOpN5CtnCVd6 fO9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wzGimwhv+jKEWavo5s3Af0BYaRQpv2mVt0BsRnuWO8w=; b=rYEXvxprxHn88NaeGLaTTz8VMqMIeJUQA9hirD3Wf4NbDbMtnG9A3p4i+ZrRWe9KM4 UZCTOT1foxllouOitOCyWuatFo20UoJ9ZGDXz33vcyCmdERvaU+C87/8YaI9MlrpDc9l I4SOePZZxQdr0dr1otvFR7qlcLJ759k2ZLtA4C0PAGQzZuzRRPHIhwuBw5/TM8uDDruH AQP35oKLYBCJ/RRUWykvMzWTlh12+LuW2puSecbphqIartit0fVo7EM87e2FDdwZjiwC cqZcT+6bvhD+mA/NHtKWD6Tc2RASALa5vNxPlKSLPo+izWRk89O1lwpqITaa+D6QzdAC JH7g== X-Gm-Message-State: AN3rC/7pHWpiPWba71/wE+NGDA567HNfOt1tTmE6zQXD2A6C1cEY7n/c YJZzo65Z2ozimvnn241MHiwLmG4w+w== X-Received: by 10.84.241.136 with SMTP id b8mr40252164pll.107.1493174330249; Tue, 25 Apr 2017 19:38:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Tue, 25 Apr 2017 19:38:09 -0700 (PDT) In-Reply-To: References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Tue, 25 Apr 2017 22:38:09 -0400 Message-ID: To: Paul Wouters Cc: Ben Campbell , "ipsec@ietf.org" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 02:38:52 -0000 Thanks for the quick response Paul, a few questions... On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters wrote: > On Tue, 25 Apr 2017, Kathleen Moriarty wrote: > >>> IIUC, the entire point of having the stream prefix is to allow the TCP >>> responder to demux between this protocol, and some other protocol that >>> would normally run on that port. Saying it MUST close the TCP session >>> seems to completely remove that value. I assume people meant to allow the >>> respondent to delegate a stream out to some other protocol handler if the >>> prefix is not present? >>> >> >> I believe that this is because there is presumed to be no other >> service operating on the listening port (assuming a VPN concentrator), >> but that's not explicitly stated either. > > > Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of > the other kinds of SSL VPNs or as the administration interface or > user interface. OK, sounds like I didn't help here, so the editors should propose text to address this gap. > >>> -- 2nd to last paragraph: "This document leaves the selection of TCP >>> ports up to implementations." >>> I suspect "configurable local policy" would make more sense. Leaving it >>> up to "implementations" leaves open the chance of different >>> implementations making non-intersecting port choices, which doesn't help >>> interoperability. >> >> >> This may go more into unexplained assumptions... the clients >> authorized to connect to the server would need to know the correct >> port to establish a session and would be given that information >> specific to the implementation. With this assumption, the above >> should be fine... but editors/AD/WG, please correct me if I am wrong. > > > I am pretty sure what is meant is "configuration" and not "implementation". Is that in response to me being wrong in my assumption or the draft should say configuration (I think it's the latter, but important to check)? > >>> -4, first paragraph: What is the expected behavior from a peers that do >>> not support this spec when they receive a TCP stream with the magic >>> number on a port for some other protocol? >> >> >> Maybe listing assumptions up front in the draft would help _IF_ the >> assumption is that the listening server is a VPN concentrator that >> wouldn't be listening for other services. > > > Support for TCP would be based on preconfiguration, so the client knows > this out-of-band. It cannot be discovered during negotiation, because > it is assumed the regular UDP ports are blocked, which is the only > reason to attempt TCP to begin with. I read the draft with this assumption in mind (see above), but this should be clarified in the document to address this question from Ben. > >>> - Appendix A: Doesn't the use of the NULL cipher invalidate one of the >>> primary reasons to use TLS? (Namely to obscure the fact that this is not >>> HTTP, or whatever other protocol is assigned to the port?) >> >> >> Editors/AD correct me if I am wrong, but... >> No, if TLS is used with a NULL cipher, it'll pass inspection of a >> middle box validating the protocol. This doesn't need to use the >> cipher as it's negotiating the IPsec connection. > > > right, TLS happens to use encryption to get out, but it is not the > encryption of the actual IKE/IPsec protocols, which keep using their > own channel negotiations. I think clarifying this further in the draft would be helpful. > > Paul -- Best regards, Kathleen From nobody Tue Apr 25 20:28:15 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79E01317DD for ; Tue, 25 Apr 2017 20:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yllmaAjSFMun for ; Tue, 25 Apr 2017 20:28:11 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7AC6124D68 for ; Tue, 25 Apr 2017 20:28:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493177291; 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=MhXYONduLqGBRQyTPb0D276pBtxLwDXWF5eMxnnvi7o=; b=VFXPxzcQ6w8QAk/OkDBKKZ4tfSizM+a9nm2PjXeAd1a721GgOX5q9100uvSmEzdg nGD2gFRSz7hdjpLIv79rzLUQDGQpVTVOkrXUR9locf9iWwBwepw1jqFgdj2SpOnl zkKVZ9vpH46G7QkI2QrE8/9DVjRbZ0/GFniAv0cZ6J4TrHHKoZ3oJUXcqGAudbD1 jT15M7PrvgrulkdVNBz+47p6gfmfYm9Wo5IEAlYThpA/ge4ijXi0DSP1gxX5xKZA BaQ/8ehfhG9h3h+cSIr0QX3EV2wUdVuOREluBMkydHkisqe3h9nkI7BFOvHicZqt XgRXIYWN6LD63nXh10jSoA==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id CA.16.08351.BC310095; Tue, 25 Apr 2017 20:28:11 -0700 (PDT) X-AuditID: 11973e16-9f9fb7000000209f-94-590013cb446b Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay2.apple.com (Apple SCV relay) with SMTP id C3.9F.07829.AC310095; Tue, 25 Apr 2017 20:28:10 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.70.191] (unknown [17.153.70.191]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOZ00F96YYX5EA0@nwk-mmpp-sz11.apple.com>; Tue, 25 Apr 2017 20:28:10 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> Date: Tue, 25 Apr 2017 20:28:09 -0700 Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, kivinen@iki.fi Content-transfer-encoding: quoted-printable Message-id: <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3424) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUi2FDorHtamCHS4OBcQYv3f84wWsz4M5HZ 4sX1j8wW+7e8YLOYOecDi8XR88/ZHNg8liz5yeRx+OtCFo+WjwtZA5ijuGxSUnMyy1KL9O0S uDJ2PcooeK9V0XAwtIHxilIXIyeHhICJxJIr/5m7GLk4hARWM0l0T5vBBpN43HiFHSJxiFFi 55+dzCAJXgFBiR+T77F0MXJwMAuoS0yZkgtRM5FJYsHMy8wgcWEBCYnNexJB4sICExglXl+b xQ7SyyagInH82wawGk4BP4lZazxBTBYBVYnL1wJAKpgF6iV+P/7GAmFrSzx5d4EVYquNxMWL i8G2Cgn4SrSccAUJiwhYSTRvf8QCcbGsxIR1m5kh7BNsEqfX601gFJ6F5OZZCDfPQrJgASPz Kkah3MTMHN3MPHO9xIKCnFS95PzcTYygCJhuJ7aD8eEqq0OMAhyMSjy8K7z+RwixJpYVV+Ye YpTmYFES51XaARQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6LV9tnGEq6RR7tXrbFVp625O szXgV/Dqndez+fXWU7KK3sv+zChotHo8IaLTqKIst+nom56ae1r5t9bOr7iyiP2GoUup9ST5 H7/7XnG+P37riHJGtp1C/fUq5WSVHW+qJsuIrU64mXv8Xsrabn2zdJN9YS8//5/x5OSLD8dZ TquV6fNlFz7mUGIpzkg01GIuKk4EAD7wN+1hAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUi2FA8W/eUMEOkwZotNhbv/5xhtJjxZyKz xYvrH5kt9m95wWYxc84HFouj55+zObB5LFnyk8nj8NeFLB4tHxeyBjBHcdmkpOZklqUW6dsl cGXsepRR8F6rouFgaAPjFaUuRk4OCQETiceNV9i7GLk4hAQOMUrs/LOTGSTBKyAo8WPyPZYu Rg4OZgF1iSlTciFqJjJJLJh5mRkkLiwgIbF5TyJIXFhgAqPE62uz2EF62QRUJI5/2wBWwyng JzFrjSeIySKgKnH5WgBIBbNAvcTvx99YIGxtiSfvLrBCbLWRuHhxMdhWIQFfiZYTriBhEQEr iebtj1ggLpaVmLBuM/MERoFZSO6chXDnLCRDFzAyr2IUKErNSaw00kssKMhJ1UvOz93ECA7Z QucdjMeWWR1iFOBgVOLhDfD4HyHEmlhWXJkLDAgOZiUR3otLgEK8KYmVValF+fFFpTmpxYcY q4A+mcgsJZqcD4ynvJJ4QxMTAxNjYzNjY3MTc6oIK4nzZp0E2iyQnliSmp2aWpBaBLOciYNT qoExucJ/p5FF4u4rh2WU3TPelCSZxmQtaw1Z+KpT+PinJL70lCTNmIPVQT90v/WpzljK67Gm TZ5h7j5J+crPq3/NPDBBhq9TRoavWnNdcs+7yXGflxcari5YnNbV4LBH6lzB1nTxZ7OmviwM idr/wPzoRyXdZ9fEVCZeTXCsjNyvp7Ov4842kyAlluKMREMt5qLiRABfSQtBtAIAAA== Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 03:28:14 -0000 > On Apr 25, 2017, at 5:48 AM, Mirja K=C3=BChlewind = wrote: >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-ipsecme-tcp-encaps-09: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > This draft suggests that ports that are assigned to other services can > simply be used. This is not okay. If a port is assigned to a certain > service, this service and/or the respective RFC defines how this port = is > used. Simply changing the specified behavior by requiring a check for = a > magic number cannot be done without updating the RFC that the port > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as > the IANA registry would need to be updated. At this point, the only portion of the document that mentions a port = other than 500 and 4500 is the appendix. We recommend that 4500 is used = as the port for TCP encapsulation. The IANA registry for 4500/tcp is = already assigned to IPSec NAT Traversal in RFC 3947; that document does = not explain how TCP is to be used, so the reference should be updated to = point to the document on TCP encapsulation. We can soften the references in the appendix to the fact that other = ports may, in fact, be used. As for the configuration, it should state = 4500 as the default, but allow peers to configure something else = out-of-band if they want to modify behavior (which is standard even in = UDP implementations of IKE). >=20 > Further, as also mentioned in the tsv-art review (Thanks Wes!), this > draft does not sufficiently handle the case of TCP in TCP = encapsulation. > Here a copy of the tsv-art review: >=20 > Reviewer: Wesley Eddy > Review result: On the Right Track >=20 > This document is clear and well-written. It can easily be implemented > based on the description. >=20 > There are a few additional issues that should be considered with > advice to implementers in Section 12 on performance considerations: > 1) Invisibility of packet loss - Inner protocols that require packet > losses as a signal of congestion (e.g. TCP) will have a challenge due > to not being able to see any packet losses since the outer TCP will > repair them (unless sending into a full outer TCP socket buffer shows > up back to the inner TCP as a packet loss?). Yes, this is definitely true. We try to capture that with the line: = "This will make loss- recovery of the inner TCP traffic less reactive and more prone to spurious retransmission timeouts." However, this can certainly be expanded upon. > 2) Nesting of ECN - Inner TCP connections will not be able to use > effectively ECN on the portion of the path covered by the outer TCP > connection. Generally, IPsec tunnels will apply RFC 6040 for translating ECN = markings between inner/outer packets. Since TCP encapsulation places the = inner IP packets in a stream, there isn't a direct mapping. An implementation could try to roughly map, but it may be best to = suggest that the ECN markings for inner and outer packets be left = separate. What is your opinion? > 3) Impact of congestion response on aggregate - The general "TCP in > TCP" problem is mentioned, and is mostly appropriate for a single > flow. If an aggregate of flows is sharing the same outer TCP > connection, there may be additional concerns about how the congestion > response behavior impacts an aggregate of flows, since it may cause a > shared delay spike even to low-rate flows rather than distributing > losses proportional to per-flow throughput. Indeed. We can add further comments to that effect. > 4) Additional potential for bufferbloat - Since TCP does not bound > latency, some applications in the IPsec-protected aggregate could > drive latency of the shared connection up and impact the aggregate of > flows that may include real-time applications. The socket buffer for > the outer TCP connection might need to be limited in size to ensure > some bounds? We can add a comment to suggest that the buffering should be limited on = the outer connection if possible. >=20 > Not addressing these could lead to poor experiences in deployment, if > implementations make wrong assumptions or fail to consider them. I do think all of these concerns go back to the overall recommendation = of "use direct ESP or UDP Encapsulation whenever possible". Anything to = help back up that point is great! Thanks, Tommy >=20 > In the security considerations section, there are several RFCs on > mechanisms to increase robustness to RST attacks and SYN floods that > could be mentioned if it's worthwhile. >=20 >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Apr 25 20:34:16 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2897129456 for ; Tue, 25 Apr 2017 20:34:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kz2HVHiQ1PAC for ; Tue, 25 Apr 2017 20:34:11 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7262E129407 for ; Tue, 25 Apr 2017 20:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493177651; 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=/hav/uP3iJoMFUdkLD+ACkpx1972TSSqV956ym3T+5M=; b=qtfumebLyPPFITfYk9WKYwIe1SG2q0SQVhJkot27h+4N2eI3UdOR3EwfwVcPuLtr qTjzNLlbugoLYMrtFjhARkBbOME9QLxdRQhJ4iOdUfTd1cdNDv0oXvaE+VU3oNy5 r/Wzsi1qT+8Bug+ngPWNt4QGMy5Yrhvx88s2TCuwEihRfOFEPCwEqgBFB5bhYiXf Iv/10SCir63ImflvGhlJybPmU3/iMFF6W5JcuB6DphE0GmvUQDA9rWgaxBnXfl66 OwzyvHYps4i/Q8n/49AbVczPFNuAFHW/WiABGS50TWa/8zu1D2O3lKaqQOxu/63x +Gcnm9uHqFf8IzgS6u44TA==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id FB.86.08351.33510095; Tue, 25 Apr 2017 20:34:11 -0700 (PDT) X-AuditID: 11973e16-efb529a00000209f-99-59001533dd20 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay5.apple.com (Apple SCV relay) with SMTP id D5.63.02326.23510095; Tue, 25 Apr 2017 20:34:11 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YMSZPLY0rYCkeXJBCA/qAQ)" Received: from [17.153.70.191] (unknown [17.153.70.191]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OOZ00846Z8Y9J20@nwk-mmpp-sz09.apple.com>; Tue, 25 Apr 2017 20:34:10 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <4888D3A6-FAC0-4DCC-AC6B-BFDFE813FCAB@apple.com> Date: Tue, 25 Apr 2017 20:34:09 -0700 In-reply-to: Cc: Yoav Nir , "ipsec@ietf.org WG" , Paul Wouters , draft-ietf-ipsecme-tcp-encaps@ietf.org To: Joe Touch References: <5B8CCE6E-B6DA-423B-A145-6C207B0E1C0F@gmail.com> X-Mailer: Apple Mail (2.3424) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUi2FAYoWssyhBpsPM6v8X7P2cYLfZvecFm 8f7WJSaLdX/mslgsPfaByYHVY+esu+weS5b8ZPLY/X4ri8f3eUwBLFFcNimpOZllqUX6dglc GdfvdTIWLLjCWDH1oFYD4+U5jF2MnBwSAiYSS/8+Ze1i5OIQEljNJDH921FWmMTVw7sZIRIH GSX+/37LDJLgFRCU+DH5HguIzSwQJjFlySKooolMEr+XvwYq4uAQFpCQ2LwnEaSGTUBF4vi3 DVC9NhINkxaBbRYGss8d7wezWQRUJT4dWwc2k1PAWmLt9w5miPkTGSU29siA2CICshIP/rxh B7GFBLqYJL4sdoM4VFZiwrrNzCA3SAjcZ5OY0bScaQKj0Cwkt85CcussoPOYBdQlpkzJhQhr Szx5d4EVwlaTWPh7EROy+AJGtlWMQrmJmTm6mXnmeokFBTmpesn5uZsYQdEz3U5sB+PDVVaH GAU4GJV4eFd4/Y8QYk0sK67MPcQozcGiJM6rtAMoJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gbHYiPVk4l796d+a5v0TPvrlSUm/yNuurw6tX3Yc40m89N7XTPoOh+nv1WbV1a36YgeO31jM +q9l079uc5MKyyNBOkqODs4efvH8Cc1/nrsGzVi7Ze9Exyfe7fzCdzMmWl+Y/PpXYvFhwan7 ORL8jzjH1/1auWBX/PGFb9Otrh5d1rjAcsOGYlUlluKMREMt5qLiRAAxxKsZfwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUi2FAcoGssyhBpMKOD1eL9nzOMFvu3vGCz eH/rEpPFuj9zWSyWHvvA5MDqsXPWXXaPJUt+Mnnsfr+VxeP7PKYAligum5TUnMyy1CJ9uwSu jOv3OhkLFlxhrJh6UKuB8fIcxi5GTg4JAROJq4d3A9lcHEICBxkl/v9+ywyS4BUQlPgx+R4L iM0sECYxZckiqKKJTBK/l78GKuLgEBaQkNi8JxGkhk1AReL4tw1QvTYSDZMWgS0QBrLPHe8H s1kEVCU+HVsHNpNTwFpi7fcOZoj5ExklNvbIgNgiArISD/68YQexhQS6mCS+LHaDOFRWYsK6 zcwTGPlnITlvFpLzZgFdxCygLjFlSi5EWFviybsLrBC2msTC34uYkMUXMLKtYhQoSs1JrDTV SywoyEnVS87P3cQIDvbCiB2M/5dZHWIU4GBU4uEN8PgfIcSaWFZcmXuIUYKDWUmE9+ISoBBv SmJlVWpRfnxRaU5q8SHGiYxAT05klhJNzgfGYl5JvKGJiYGJsbGZsbG5iTkthZXEeXNPAl0k kJ5YkpqdmlqQWgRzFBMHp1QDY8AjxbnWSrecRCpqeA7bnjnpLbZEm4nhYnHxZU7RpU+ymUu2 nDx3N0ozyOhDpKuW4LlfO47debPtuvK+af+Z5dPCLJ6uuGdh3yv3IIylTWFZgO4fuxCPP64P r5iUGr2zn7KT90bDFuaXE3M+OygbrGVNWKT1oUrlEOuc6FnM2m266sXMyhMslFiKMxINtZiL ihMBOnMHZOkCAAA= Archived-At: Subject: Re: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 03:34:14 -0000 --Boundary_(ID_YMSZPLY0rYCkeXJBCA/qAQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Apr 25, 2017, at 2:15 PM, Joe Touch wrote: >=20 > First, correcting the subject line (sorry - that looks like an = erroneous paste on my part). >=20 > Also below... >=20 > On 4/25/2017 1:59 PM, Yoav Nir wrote: >> Hi, Joe >>=20 >> I haven=E2=80=99t been involved with this draft, but I don=E2=80=99t = believe that last statement is correct: >>=20 >>> On 25 Apr 2017, at 23:03, Joe Touch > wrote: >>>=20 >>>>=20 >>>> This issue is really everyone circling around the elephant in the = room. >>>> Part of this draft is designed to break through firewalls and >>>> middle-ware that only let out port 443 traffic unmangled. We cannot >>>> really write >>>> that we are doing this, despite everyone knowing we are doing this. >>>>=20 >>>> Your suggestions that we need to not mention 443 without updating = the >>>> RFC defining 443 is hard to meet. Not only because we'd have an IKE >>>> document updating a TLS document, but also because IANA actually = has >>>> not RFC listed for the definition of port 443. >>>=20 >>> It's not listed, but it would probably be rfc2818 or one of the ones >>> that updates that. >>>=20 >>> However, I'd personally want someone involved from HTTPWG to sign = off on >>> this. >>>=20 >>>> I'm already a little annoyed that the draft cannot (politically) = specify >>>> how to use port 443 with TLS to tunnel IKE and ESP over TCP. >>>=20 >>> Here's the thing: >>>=20 >>> You get to define your service. >>>=20 >>> You do not get to define someone else's. >>>=20 >>> You would be squatting (using someone else's ports for your = purposes), >>> pure and simple. >>=20 >> I don=E2=80=99t believe that TCP port 443 on the host at 192.0.2.7 = =E2=80=9Cbelongs=E2=80=9D in any sense of the word to the HTTP working = group.=20 >=20 > Strictly, the port is assigned based on a service definition. >=20 > On any given host, any user can define any port any way they see fit, = e.g., they can run DNS on port 110 or IMAP on port 53.=20 >=20 > However, a new standard should never be making a change to the service = defined for a port that is already assigned to another party (they can = change a service they have been assigned). >=20 >> While it is the default port for HTTPS, that protocol can run on any = port depending on the value in origin (RFC 6454). >=20 > Yes, any protocol can run on any port number (as per above), as long = as the endpoints agree. But that's not what you're talking about here - = you're saying that if you get "IKETCP" on a port, then you can trust = that it is your service. >=20 > That's incorrect. You don't get to define the string "IKETCP" for = other services.=20 >=20 >> The draft makes it clear in section 2 that the port used is = pre-configured on both IKE initiator and IKE responder. The draft does = not assign or re-assign any ports.=20 > Section 4 claims that the use of the magic string differentiates this = service from the default assigned service or any other service. That's = incorrect. You don't have that authority. >=20 >> Yes, there is a suggestion to use port 443 because it is usable in = more networks than other ports. > Again, you don't have the authority to say what "IKETCP" means on port = 443.=20 >=20 > Yes, if the port is explicitly indicated, you can use whatever port = you want. But you should never imply that this system should run on = ports assigned to other services that are running in parallel - you do = not have that authority. >=20 >> That is why TCP port 443 has been used by Skype, AiCloud file = sharing, Call of Duty, various =E2=80=9CSSL VPN=E2=80=9D products and = many others. They=E2=80=99ve been doing that for over a decade. It is = way too late to close the barn doors, and we don=E2=80=99t even have the = authority to do so.=20 >=20 > You do not have the authority to endorse or standardize this behavior = either. >=20 > It remains non-compliant squatting. >=20 >> We can remove all references to specific ports and leave only text = about pre-configuration. IMO this amounts to a wind and a nod, because = we all know which port is going to get configured. >=20 > You should be saying that the port is indicated explicitly (which is = the equivalent of pairwise endpoint negotiation) or use port 4500 (or = maybe get your own separate assignment). But the entire text on the = magic number being appropriate when sharing an existing assignment is = incorrect and needs to be removed IMO. I suggest that we can: - Clarify the text in section 2 (configuration) to say that the default = port is TCP 4500, and that implementations may communicate other port = options out of band as configuration. This is done for UDP as well. This = is the "explicit" indication of the ports you mention above. - Port 443 is only mentioned in the figures for the appendix. We can = remove the mention of the port there. As for the Stream Prefix of "IKETCP", I believe that we have good = reasons to keep it even if we are only using the protocol on port 4500 = (as would be the recommended/sanctioned) method. TCP port 4500 has been = technically allocated to IPsec NAT Traversal (which TCP encapsulation = is) for a long while without a specific protocol being defined. The = concern that brought about the stream prefix was to let VPN endpoints = that may be running older non-standard protocols to recognize TCP = encapsulation in case they were already squatting on the port (4500), or = have configured TCP encapsulation to run on a port they are using for = their own custom VPN protocol. How does that sound? Thanks! Tommy >=20 > Joe > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_YMSZPLY0rYCkeXJBCA/qAQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Apr 25, 2017, at 2:15 PM, Joe Touch <touch@isi.edu> = wrote:

=20 =20

First, correcting the subject line (sorry - that looks like = an erroneous paste on my part).

Also below...


On 4/25/2017 1:59 PM, Yoav Nir = wrote:
Hi, Joe

I haven=E2=80=99t been involved with this draft, = but I don=E2=80=99t believe that last statement is correct:

On 25 Apr 2017, at 23:03, Joe Touch <touch@isi.edu> wrote:


This issue is really everyone circling around the elephant in the room.
Part of this draft is designed to break through firewalls and
middle-ware that only let out port 443 traffic unmangled. We cannot
really write
that we are doing this, despite everyone knowing we are doing this.

Your suggestions that we need to not mention 443 without updating the
RFC defining 443 is hard to meet. Not only because we'd have an IKE
document updating a TLS document, but also because IANA actually has
not RFC listed for the definition of port 443.

It's not listed, but it would probably be rfc2818 or one of the ones
that updates = that.

However, I'd personally want someone involved from HTTPWG to sign off = on
this.

I'm already = a little annoyed that the draft cannot (politically) specify
how to use port 443 with TLS to tunnel IKE and ESP over TCP.

Here's the = thing:

   You get = to define your service.

   You do = not get to define someone else's.

You would be squatting (using someone else's ports for your = purposes),
pure and = simple.

I don=E2=80=99t believe that TCP port 443 on the host at = 192.0.2.7 =E2=80=9Cbelongs=E2=80=9D in any sense of the word to the HTTP = working group.

Strictly, the port is assigned based on a service definition.

On any given host, any user can define any port any way they see fit, e.g., they can run DNS on port 110 or IMAP on port 53.

However, a new standard should never be making a change to the service defined for a port that is already assigned to another party (they can change a service they have been assigned).

While it is the default port for HTTPS, that protocol can run on any port depending on the value in origin (RFC 6454).

Yes, any protocol can run on any port number (as per above), as long as the endpoints agree. But that's not what you're talking about here - you're saying that if you get "IKETCP" on a port, then you can trust that it is your service.

That's incorrect. You don't get to define the string "IKETCP" for other services.

The draft makes it clear in section 2 that the = port used is pre-configured on both IKE initiator and IKE responder. The draft does not assign or re-assign any ports.
Section 4 claims that the use of the magic string differentiates this service from the default assigned service or any other service. That's incorrect. You don't have that authority.

Yes, there is a suggestion to use port 443 because it is usable in more networks than other ports.
Again, you don't have the authority to say what "IKETCP" means on port 443.

Yes, if the port is explicitly indicated, you can use whatever port you want. But you should never imply that this system should run on ports assigned to other services that are running in parallel - you do not have that authority.

That is why TCP port 443 has been used by Skype, AiCloud file sharing, Call of Duty, various =E2=80=9CSSL VPN=E2=80= =9D products and many others. They=E2=80=99ve been doing that for over a = decade. It is way too late to close the barn doors, and we don=E2=80=99t = even have the authority to do so.

You do not have the authority to endorse or standardize this behavior either.

It remains non-compliant squatting.

We can remove all references to specific ports and leave only text about pre-configuration. IMO this amounts to a wind and a nod, because we all know which port is going to get configured.

You should be saying that the port is indicated explicitly (which is the equivalent of pairwise endpoint negotiation) or use port 4500 (or maybe get your own separate assignment). But the entire text on the magic number being appropriate when sharing an existing assignment is incorrect and needs to be removed IMO.

I = suggest that we can:

- Clarify the = text in section 2 (configuration) to say that the default port is TCP = 4500, and that implementations may communicate other port options out of = band as configuration. This is done for UDP as well. This is the = "explicit" indication of the ports you mention above.
- Port = 443 is only mentioned in the figures for the appendix. We can remove the = mention of the port there.

As for = the Stream Prefix of "IKETCP", I believe that we have good reasons to = keep it even if we are only using the protocol on port 4500 (as would be = the recommended/sanctioned) method. TCP port 4500 has been technically = allocated to IPsec NAT Traversal (which TCP encapsulation is) for a long = while without a specific protocol being defined. The concern that = brought about the stream prefix was to let VPN endpoints that may be = running older non-standard protocols to recognize TCP encapsulation in = case they were already squatting on the port (4500), or have configured = TCP encapsulation to run on a port they are using for their own custom = VPN protocol.

How does that = sound?

Thanks!
Tommy


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

= --Boundary_(ID_YMSZPLY0rYCkeXJBCA/qAQ)-- From nobody Tue Apr 25 20:47:08 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A02A2129407; Tue, 25 Apr 2017 20:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdsEQnbSbDyL; Tue, 25 Apr 2017 20:47:04 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 638B3124217; Tue, 25 Apr 2017 20:47:04 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id m123so112913058wma.0; Tue, 25 Apr 2017 20:47:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=bJ7YBjSisMdh98RF/Jdf/XxV8b08gd+Z6utLD9SLbE4=; b=AOkbNa6XMej6blkIMO1Ar6UVbg2vDf4mIDoyL8kqkNgCFksfKJcQp438BATzHJ3vJ8 +EQYJJp+yOh6H+gVvY8hUZECYsWNqla4wjNqvIz0eGez3UUW+Ivn78GKzphxWyq55xZp qvktugwzX1nZZ5LKVDdCcYOaF5J+VoBWbBtmbGgkP9PsnJTJ5Lmpg2J32AUu//STx6IE pUIRxzwjW+crXGlBgXkcXH5BrMePEX9KwzCSvQzo7bI/2WalGUGpTDzIxv/Mp3KLaGdQ fwgDD0aTqgAGi48CYHcXa1olwKJK1g9imDfY3KkCIvy0oyz8QNnPQkHWwoo6nW9VB9ry O4sA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=bJ7YBjSisMdh98RF/Jdf/XxV8b08gd+Z6utLD9SLbE4=; b=G7jiK56ogk4A1iRN7muGtiXGKgMYhucMZLFFgCwYtZW3ettN0qoglSEqa74y+P551Y s0v21hGMR/U4KtbP9jtGkOAzeX5nO7mwrdZDY12hkpj+TDCI40r/WiQzgjwzdCBv76+i sEBlgKX9iVVmj4DDtC4AvssOlwRHJSUjuoRWaSeusEi0Ch4VaZS5gvpD3UfTiqhJotWq i0BMiH/mI3vrVLTyDw0dM+bTNQv9HgcnbQ4zO8cDWkZaLiSzrCPMjpJ9/S4w7tSxcPMS EXvn5LST0iQekjHh8RyNPhxvUW1U7bQvIPGj7ZcZjrrlSwkQVxSpwLioQuOuxhxa7xGu zEhg== X-Gm-Message-State: AN3rC/7vcbvM4Nw7BOaeaY7KNx1nfnHPI4ap+nkQ8lGvKcHiWWMeQPOd 6Fka+iuTU48mDg== X-Received: by 10.80.166.33 with SMTP id d30mr7554754edc.80.1493178422869; Tue, 25 Apr 2017 20:47:02 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id q52sm672255eda.30.2017.04.25.20.47.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Apr 2017 20:47:02 -0700 (PDT) From: Yoav Nir Message-Id: <10726000-4D7E-41C6-ACFB-8E9D0D51DB66@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9171E42D-33F5-4287-8AD4-A269FDCAE862"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 26 Apr 2017 06:46:59 +0300 In-Reply-To: Cc: Paul Wouters , "ipsec@ietf.org WG" , draft-ietf-ipsecme-tcp-encaps@ietf.org To: Joe Touch References: <5B8CCE6E-B6DA-423B-A145-6C207B0E1C0F@gmail.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 03:47:07 -0000 --Apple-Mail=_9171E42D-33F5-4287-8AD4-A269FDCAE862 Content-Type: multipart/alternative; boundary="Apple-Mail=_0EEB8389-6554-4743-9056-B888B53C4598" --Apple-Mail=_0EEB8389-6554-4743-9056-B888B53C4598 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Apr 2017, at 0:15, Joe Touch wrote: >=20 > First, correcting the subject line (sorry - that looks like an = erroneous paste on my part). >=20 > Also below... >=20 > On 4/25/2017 1:59 PM, Yoav Nir wrote: >> Hi, Joe >>=20 >> I haven=E2=80=99t been involved with this draft, but I don=E2=80=99t = believe that last statement is correct: >>=20 >>> On 25 Apr 2017, at 23:03, Joe Touch > wrote: >>>=20 >>>>=20 >>>> This issue is really everyone circling around the elephant in the = room. >>>> Part of this draft is designed to break through firewalls and >>>> middle-ware that only let out port 443 traffic unmangled. We cannot >>>> really write >>>> that we are doing this, despite everyone knowing we are doing this. >>>>=20 >>>> Your suggestions that we need to not mention 443 without updating = the >>>> RFC defining 443 is hard to meet. Not only because we'd have an IKE >>>> document updating a TLS document, but also because IANA actually = has >>>> not RFC listed for the definition of port 443. >>>=20 >>> It's not listed, but it would probably be rfc2818 or one of the ones >>> that updates that. >>>=20 >>> However, I'd personally want someone involved from HTTPWG to sign = off on >>> this. >>>=20 >>>> I'm already a little annoyed that the draft cannot (politically) = specify >>>> how to use port 443 with TLS to tunnel IKE and ESP over TCP. >>>=20 >>> Here's the thing: >>>=20 >>> You get to define your service. >>>=20 >>> You do not get to define someone else's. >>>=20 >>> You would be squatting (using someone else's ports for your = purposes), >>> pure and simple. >>=20 >> I don=E2=80=99t believe that TCP port 443 on the host at 192.0.2.7 = =E2=80=9Cbelongs=E2=80=9D in any sense of the word to the HTTP working = group. >=20 > Strictly, the port is assigned based on a service definition. >=20 > On any given host, any user can define any port any way they see fit, = e.g., they can run DNS on port 110 or IMAP on port 53. >=20 > However, a new standard should never be making a change to the service = defined for a port that is already assigned to another party (they can = change a service they have been assigned). >=20 >> While it is the default port for HTTPS, that protocol can run on any = port depending on the value in origin (RFC 6454). >=20 > Yes, any protocol can run on any port number (as per above), as long = as the endpoints agree. But that's not what you're talking about here - = you're saying that if you get "IKETCP" on a port, then you can trust = that it is your service. >=20 > That's incorrect. You don't get to define the string "IKETCP" for = other services. That I totally agree with. The purpose of the IKETCP magic string is to = demultiplex between TCP connections implementing this draft and other = TCP connections using the same port for other services, regardless of = whether those other services are defined in IANA or other squatters. I think the text in section 4 already says so, but perhaps it can be = clarified. Yoav --Apple-Mail=_0EEB8389-6554-4743-9056-B888B53C4598 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 26 Apr 2017, at 0:15, Joe Touch <touch@isi.edu> = wrote:

=20 =20

First, correcting the subject line (sorry - that looks like = an erroneous paste on my part).

Also below...


On 4/25/2017 1:59 PM, Yoav Nir = wrote:
Hi, Joe

I haven=E2=80=99t been involved with this draft, = but I don=E2=80=99t believe that last statement is correct:

On 25 Apr 2017, at 23:03, Joe Touch <touch@isi.edu> wrote:


This issue is really everyone circling around the elephant in the room.
Part of this draft is designed to break through firewalls and
middle-ware that only let out port 443 traffic unmangled. We cannot
really write
that we are doing this, despite everyone knowing we are doing this.

Your suggestions that we need to not mention 443 without updating the
RFC defining 443 is hard to meet. Not only because we'd have an IKE
document updating a TLS document, but also because IANA actually has
not RFC listed for the definition of port 443.

It's not listed, but it would probably be rfc2818 or one of the ones
that updates = that.

However, I'd personally want someone involved from HTTPWG to sign off = on
this.

I'm already = a little annoyed that the draft cannot (politically) specify
how to use port 443 with TLS to tunnel IKE and ESP over TCP.

Here's the = thing:

   You get = to define your service.

   You do = not get to define someone else's.

You would be squatting (using someone else's ports for your = purposes),
pure and = simple.

I don=E2=80=99t believe that TCP port 443 on the host at = 192.0.2.7 =E2=80=9Cbelongs=E2=80=9D in any sense of the word to the HTTP = working group.

Strictly, the port is assigned based on a service definition.

On any given host, any user can define any port any way they see fit, e.g., they can run DNS on port 110 or IMAP on port 53.

However, a new standard should never be making a change to the service defined for a port that is already assigned to another party (they can change a service they have been assigned).

While it is the default port for HTTPS, that protocol can run on any port depending on the value in origin (RFC 6454).

Yes, any protocol can run on any port number (as per above), as long as the endpoints agree. But that's not what you're talking about here - you're saying that if you get "IKETCP" on a port, then you can trust that it is your service.

That's incorrect. You don't get to define the string "IKETCP" for other services.

That I totally agree with.  The purpose of the = IKETCP magic string is to demultiplex between TCP connections = implementing this draft and other TCP connections using the same port = for other services, regardless of whether those other services are = defined in IANA or other squatters.

I = think the text in section 4 already says so, but perhaps it can be = clarified.

Yoav

= --Apple-Mail=_0EEB8389-6554-4743-9056-B888B53C4598-- --Apple-Mail=_9171E42D-33F5-4287-8AD4-A269FDCAE862 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZABg0AAoJELhJCxUKWMyZgNEH/1IItjjcTaZSlKfMw/51i675 eQC8ikcgQIVieERdofsP5AL8blxCyf8xWoCV8USqG5SEqx+i0v4of3bAC3Rd0UrP sa+v24nb+JIme/DYyDzOGg9ICVmQej8EQ3TM9T+hMlpqgNH1IdtAAHAsVydzlxus 05bdoUEyOoghBRoEv/TtOSb3piE/0Avu/KUIi6EjsumavbqG8rGJFhqnowfY4rvv Ud+yaxP1cNm7Sh+61W0ApqtRmfvAzEfrbthdYZeJmWfn9NZS3nLbyWpG6L17loNN 6JQ/d1uSWm5YrCN/IgThsz6INwsI5EYddHsVWaH1lxCncFf3K07uveDTKAeqQPQ= =XbT+ -----END PGP SIGNATURE----- --Apple-Mail=_9171E42D-33F5-4287-8AD4-A269FDCAE862-- From nobody Tue Apr 25 20:54:24 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 509171242F7; Tue, 25 Apr 2017 20:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oII1mVCUeS1O; Tue, 25 Apr 2017 20:54:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 4486A1201F8; Tue, 25 Apr 2017 20:54:20 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3Q3sI1I072403 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 25 Apr 2017 22:54:19 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Tue, 25 Apr 2017 22:54:18 -0500 Cc: Paul Wouters , "ipsec@ietf.org" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , Tero Kivinen Content-Transfer-Encoding: quoted-printable Message-Id: <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 03:54:22 -0000 > On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty = wrote: >=20 > Thanks for the quick response Paul, a few questions... >=20 > On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters wrote: >> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: >>=20 >>>> IIUC, the entire point of having the stream prefix is to allow the = TCP >>>> responder to demux between this protocol, and some other protocol = that >>>> would normally run on that port. Saying it MUST close the TCP = session >>>> seems to completely remove that value. I assume people meant to = allow the >>>> respondent to delegate a stream out to some other protocol handler = if the >>>> prefix is not present? >>>>=20 >>>=20 >>> I believe that this is because there is presumed to be no other >>> service operating on the listening port (assuming a VPN = concentrator), >>> but that's not explicitly stated either. >>=20 >>=20 >> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one = of >> the other kinds of SSL VPNs or as the administration interface or >> user interface. >=20 > OK, sounds like I didn't help here, so the editors should propose text > to address this gap. I think we are on the right track here, pending proposed text. >=20 >>=20 >>>> -- 2nd to last paragraph: "This document leaves the selection of = TCP >>>> ports up to implementations." >>>> I suspect "configurable local policy" would make more sense. = Leaving it >>>> up to "implementations" leaves open the chance of different >>>> implementations making non-intersecting port choices, which doesn't = help >>>> interoperability. >>>=20 >>>=20 >>> This may go more into unexplained assumptions... the clients >>> authorized to connect to the server would need to know the correct >>> port to establish a session and would be given that information >>> specific to the implementation. With this assumption, the above >>> should be fine... but editors/AD/WG, please correct me if I am = wrong. >>=20 >>=20 >> I am pretty sure what is meant is "configuration" and not = "implementation". >=20 > Is that in response to me being wrong in my assumption or the draft > should say configuration (I think it's the latter, but important to > check)? We are probably splitting hairs on the meaning of =E2=80=9Cimplementation=E2= =80=9D vs =E2=80=9Cconfiguration=E2=80=9D. (and maybe =E2=80=9Cdeployment=E2= =80=9D). I was thinking of =E2=80=9Cimplementation=E2=80=9D as being = what developers do, and =E2=80=9Cconfiguring/deploying=E2=80=9D as what = operators do. But I am aware that operators sometimes talk about = =E2=80=9Cimplementing=E2=80=9D a system. So my point was that I assume for purposes of interoperability that a = general purpose client or server would allow the port to be changed in = the field. >=20 >>=20 >>>> -4, first paragraph: What is the expected behavior from a peers = that do >>>> not support this spec when they receive a TCP stream with the magic >>>> number on a port for some other protocol? >>>=20 >>>=20 >>> Maybe listing assumptions up front in the draft would help _IF_ the >>> assumption is that the listening server is a VPN concentrator that >>> wouldn't be listening for other services. >>=20 >>=20 >> Support for TCP would be based on preconfiguration, so the client = knows >> this out-of-band. It cannot be discovered during negotiation, because >> it is assumed the regular UDP ports are blocked, which is the only >> reason to attempt TCP to begin with. >=20 > I read the draft with this assumption in mind (see above), but this > should be clarified in the document to address this question from Ben. Imagine a misconfigured client opening a connection to an web server on = port 80, expecting to find a VPN service. What happens? I think that a = consequence of the design approach to allow this to run over ports = assigned to other protocols is that you need to consider that sort of = thing. >>=20 >>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one of = the >>>> primary reasons to use TLS? (Namely to obscure the fact that this = is not >>>> HTTP, or whatever other protocol is assigned to the port?) >>>=20 >>>=20 >>> Editors/AD correct me if I am wrong, but... >>> No, if TLS is used with a NULL cipher, it'll pass inspection of a >>> middle box validating the protocol. This doesn't need to use the >>> cipher as it's negotiating the IPsec connection. >>=20 >>=20 >> right, TLS happens to use encryption to get out, but it is not the >> encryption of the actual IKE/IPsec protocols, which keep using their >> own channel negotiations. >=20 > I think clarifying this further in the draft would be helpful. I agree, because I=E2=80=99m still confused :-)=20 To clarify my question: Assuming the case of TLS encapsulation to the = HTTPS port across a DPI middle-box that hates that sort of thing. If TLS = uses the NULL cipher, can the middlebox not tell that the protocol over = TLS is not HTTP? (I will defer to the experts.) From nobody Wed Apr 26 02:27:03 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952051294D4; Wed, 26 Apr 2017 02:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-ku65RBGXHc; Wed, 26 Apr 2017 02:27:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EB611293FC; Wed, 26 Apr 2017 02:26:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML711-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DFN63885; Wed, 26 Apr 2017 09:26:57 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 26 Apr 2017 10:26:56 +0100 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by nkgeml414-hub.china.huawei.com (10.98.56.75) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 26 Apr 2017 17:26:52 +0800 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.150]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 26 Apr 2017 17:26:43 +0800 From: Sandeep Kampati To: Linda Dunbar , Yoav Nir CC: "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" Thread-Topic: small correction : draft-abad-i2nsf-sdn-ipsec-flow-protectio Thread-Index: AdK+blunDApn44IOSkOt8f5iV5jx0Q== Date: Wed, 26 Apr 2017 09:26:42 +0000 Message-ID: <2DA788A5A7D91747AEA54B502558D73826A6C421@DGGEMM506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.244.89] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.590067E1.018F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.150, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: ecaf94c04e6d69e3f8fb0912d258ab5a Archived-At: Subject: [IPsec] small correction : draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 09:27:01 -0000 SGkgQWxsLA0KDQpzbWFsbCBjb3JyZWN0aW9uICAgIA0KDQo4LiAgRGF0YSBtb2RlbA0KDQoJRGF0 YSBtb2RlbCBmb3IgdGhlIFNEUCBlbnRyaWVzOiAtLT4gaXQgc2hvdWxkIGJlICAgICJEYXRhIG1v ZGVsIGZvciB0aGUgU1BEIGVudHJpZXM6ICINCg0KUmVnYXJkcywNClNhbmRlZXAuaw0KDQoNCg0K From nobody Wed Apr 26 03:43:32 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88B8129B10; Wed, 26 Apr 2017 03:43: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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Phtd66q8iPk4; Wed, 26 Apr 2017 03:43:28 -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 708BC12940C; Wed, 26 Apr 2017 03:43:27 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3QAhNQq023274 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Apr 2017 13:43:23 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3QAhMsC022329; Wed, 26 Apr 2017 13:43:22 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22784.31178.211809.624272@fireball.acr.fi> Date: Wed, 26 Apr 2017 13:43:22 +0300 From: Tero Kivinen To: Paul Wouters Cc: Joe Touch , "ipsec\@ietf.org WG" , draft-ietf-ipsecme-tcp-encaps@ietf.org In-Reply-To: References: X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 50 min X-Total-Time: 28 min Archived-At: Subject: Re: [IPsec] informal ports and transport review of ipsecme-chairs@tools.ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 10:43:31 -0000 Paul Wouters writes: > On Tue, 25 Apr 2017, Joe Touch wrote: > > Every bit pattern, including those using magic numbers, is already > > owned and under the control of each assigned port. It is not > > appropriate for any new service to hijack that pattern as having a > > different meaning UNLESS explicitly updating the service on > > that port. > > > > A simple summary of what needs to change, in 2119-language: > > > > - this approach MUST NOT be described as applying to any > > assigned number unless also updating the associated RFC > > So it should add an Updates: RFC-3947 Not really. It does not update RFC3947 as it does not change the obsoleted protocol defined in the RFC3947. It does define way to extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On the other hand RFC3947 should have been obsoleted when we obsoleted IKEv1, as that document only defines how to do IKEv1 NAT traversal negotiation, and the IKEv2 NAT traversal negotation is described in main IKEv2 RFC (RFC7296). > It's a little weird. 3947 reserved TCP 4500, but did not specify how > to actually use TCP at all. It seems it was mostly preventatively > reserved. The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500 and UDP/4500 references from individual user to the RFC3947, so that IETF will have change control over the ports. I.e., those ports were allocated before RFC3947 came out, and they were used for several different non-interoperable versions of the NAT traversals, which then evolved to the standard version we define in RFC3947. We decided to reassign both TCP and UDP port 4500 to RFC3947 so it would be clear for what use they will be used. Also we commonly reserve both TCP and UDP ports for same number just in case someone defines a way to run the protocol over other transport protocol in the future... RFC3947 does not define anything over TCP/4500. Actually RFC3947 does not define anything over the UDP/4500 either, it is the RFC3948 that does that. The RFC3947 just says, we use the format defined in the RFC3948 over the UDP/4500, but is silent about the TCP/4500. RFC3947 is efficiently obsoleted, as it only defines the way to do NAT traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2 (originally RFC4306, and now RFC7296). So the RFC3947 should have been marked as obsoleted by RFC4306. I am not sure if we want to do that in this late. So my proposal is update the IANA port registry for both UDP/4500 and TCP/4500 as follows: Keyword Decimal Description Reference ------- ------- ----------- --------- ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFCXXXX] ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3948], [RFC7296] (RFCXXXX being this RFC). Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the RFC3948 actually defines the protocol used over the port. RFC3947 defines the IKEv1 negotiation over the UDP port 500 and 4500, but for IKEv2 this is already defined in the RFC7296. The RFC3947 could either be left as it is now, or marked as being obsoleted by this or RFC4306, or RFC7296 or whatever. Updating document which is effectively already obsoleted, is just wrong... -- kivinen@iki.fi From nobody Wed Apr 26 03:47:00 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FC7129AD2; Wed, 26 Apr 2017 03:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FW9K_5g67_oq; Wed, 26 Apr 2017 03:46:50 -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 681D3129421; Wed, 26 Apr 2017 03:46:49 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3QAkgT0020168 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Apr 2017 13:46:42 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3QAkgBk016801; Wed, 26 Apr 2017 13:46:42 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22784.31378.631303.102297@fireball.acr.fi> Date: Wed, 26 Apr 2017 13:46:42 +0300 From: Tero Kivinen To: Tommy Pauly Cc: , The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org In-Reply-To: <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 2 min Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 10:46:51 -0000 Tommy Pauly writes: > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This draft suggests that ports that are assigned to other services can > > simply be used. This is not okay. If a port is assigned to a certain > > service, this service and/or the respective RFC defines how this port is > > used. Simply changing the specified behavior by requiring a check for a > > magic number cannot be done without updating the RFC that the port > > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as > > the IANA registry would need to be updated. > > At this point, the only portion of the document that mentions a port > other than 500 and 4500 is the appendix. We recommend that 4500 is > used as the port for TCP encapsulation. The IANA registry for > 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947; > that document does not explain how TCP is to be used, so the > reference should be updated to point to the document on TCP > encapsulation. I already explained this in long email to the Joe and Paul, but noticed that those emails did not go to to the IESG, so this is mostly cut & paste of my previous email. This does not cover anything about using any other ports, but covers the case about the IANA allocations for TCP/4500 and UPD/4500. ---------------------------------------------------------------------- Paul Wouters writes: > On Tue, 25 Apr 2017, Joe Touch wrote: > > Every bit pattern, including those using magic numbers, is already > > owned and under the control of each assigned port. It is not > > appropriate for any new service to hijack that pattern as having a > > different meaning UNLESS explicitly updating the service on > > that port. > > > > A simple summary of what needs to change, in 2119-language: > > > > - this approach MUST NOT be described as applying to any > > assigned number unless also updating the associated RFC > > So it should add an Updates: RFC-3947 Not really. It does not update RFC3947 as it does not change the obsoleted protocol defined in the RFC3947. It does define way to extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On the other hand RFC3947 should have been obsoleted when we obsoleted IKEv1, as that document only defines how to do IKEv1 NAT traversal negotiation, and the IKEv2 NAT traversal negotation is described in main IKEv2 RFC (RFC7296). > It's a little weird. 3947 reserved TCP 4500, but did not specify how > to actually use TCP at all. It seems it was mostly preventatively > reserved. The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500 and UDP/4500 references from individual user to the RFC3947, so that IETF will have change control over the ports. I.e., those ports were allocated before RFC3947 came out, and they were used for several different non-interoperable versions of the NAT traversals, which then evolved to the standard version we define in RFC3947. We decided to reassign both TCP and UDP port 4500 to RFC3947 so it would be clear for what use they will be used. Also we commonly reserve both TCP and UDP ports for same number just in case someone defines a way to run the protocol over other transport protocol in the future... RFC3947 does not define anything over TCP/4500. Actually RFC3947 does not define anything over the UDP/4500 either, it is the RFC3948 that does that. The RFC3947 just says, we use the format defined in the RFC3948 over the UDP/4500, but is silent about the TCP/4500. RFC3947 is efficiently obsoleted, as it only defines the way to do NAT traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2 (originally RFC4306, and now RFC7296). So the RFC3947 should have been marked as obsoleted by RFC4306. I am not sure if we want to do that in this late. So my proposal is update the IANA port registry for both UDP/4500 and TCP/4500 as follows: Keyword Decimal Description Reference ------- ------- ----------- --------- ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFCXXXX] ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3948], [RFC7296] (RFCXXXX being this RFC). Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the RFC3948 actually defines the protocol used over the port. RFC3947 defines the IKEv1 negotiation over the UDP port 500 and 4500, but for IKEv2 this is already defined in the RFC7296. The RFC3947 could either be left as it is now, or marked as being obsoleted by this or RFC4306, or RFC7296 or whatever. Updating document which is effectively already obsoleted, is just wrong... -- kivinen@iki.fi From nobody Wed Apr 26 04:06:41 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380481200C5; Wed, 26 Apr 2017 04:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ltz7juduWBeE; Wed, 26 Apr 2017 04:06:31 -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 4F872120724; Wed, 26 Apr 2017 04:06:30 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3QB6SME013728 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Apr 2017 14:06:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3QB6Rb4016886; Wed, 26 Apr 2017 14:06:27 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22784.32563.870450.167881@fireball.acr.fi> Date: Wed, 26 Apr 2017 14:06:27 +0300 From: Tero Kivinen To: Ben Campbell Cc: "The IESG" , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org In-Reply-To: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 21 min X-Total-Time: 15 min Archived-At: Subject: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 11:06:32 -0000 Ben Campbell writes: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Substantive Comments: > > -3, first paragraph: > Are people confident there will never, ever be a need to demux protocols > other than IKE and ESP? If not, this approach may paint people in a > corner in the future. I ask because we made similar choices with > DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. > See RFC7983 for a discussion. (Note that this would have been a DISCUSS > point, but I think it's reasonably likely that there really won't be > other protocols here. But I want to make sure people have thought about > it.) If we ever want to run other protocols there, we still have 255 reserved values we can use as Non-ESP marker. The reason the 0x00000000 is selected as Non-ESP marker in the UDP encapsulation (and here) is because first four octets of the ESP packet are SPI, and SPI MUST NOT be zero. Also numbers from 1 to 255 are "are reserved by the Internet Assigned Numbers Authority (IANA) for future use" in the RFC4303. So if we need to run something else than IKE and ESP over that tunnel we just reserve one of the other reserved IANA numbers for it and use it as protocol marker for this new protocol. > -3.2, " The SPI field in the ESP header MUST NOT be a zero value." > Is this a new requirement for this draft? That is, does ESP otherwise > allow zero value SPIs? If not, please consider dropping the MUST NOT. RFC4303 reserves value zero for the "for local, implementation-specific use and MUST NOT be sent on the wire.". I.e., conforming ESP packet coming the to the UDP or TCP encapsulation layer cannot have SPI of zero ever. And we are not using SPI zero, we are using it as marker that this is not ESP packet, but this is IKE packet. The full text from the RFC4303 about the reserved SPI numbers is: ---------------------------------------------------------------------- 2.1. Security Parameters Index (SPI) ... The set of SPI values in the range 1 through 255 are reserved by the Internet Assigned Numbers Authority (IANA) for future use; a reserved SPI value will not normally be assigned by IANA unless the use of the assigned SPI value is specified in an RFC. The SPI value of zero (0) is reserved for local, implementation-specific use and MUST NOT be sent on the wire. (For example, a key management implementation might use the zero SPI value to mean "No Security Association Exists" during the period when the IPsec implementation has requested that its key management entity establish a new SA, but the SA has not yet been established.) -- kivinen@iki.fi From nobody Wed Apr 26 06:58:11 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF3BE129C03; Wed, 26 Apr 2017 06:58:01 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5J4XvqpXnRe; Wed, 26 Apr 2017 06:58:00 -0700 (PDT) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21BD9129BBE; Wed, 26 Apr 2017 06:58:00 -0700 (PDT) Received: by mail-pg0-x230.google.com with SMTP id 63so541241pgh.0; Wed, 26 Apr 2017 06:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=P7GuTY+tG83oGDeUdTBsJB2u8ykHcE34nKYvdnkCUGg=; b=OgLH6EPpGP4KaN6gu3cr9U3frw2xDoKnRz2uTD4zd87XdaYYJ79X2OWBEczaD/TMai fvavtvkitxrM27DpWzQrYKqB/jwea3EZl1S/pGn5pe9BMpeycZqz5967HJRgMJ+wCGZ9 ET8oUstt3sOcPGt1VRs+u0AQ7kHCPWmelEB8io5Dv3qJMIObzdT03A8TpSwJ2Plkw2U+ xLhR1aJN7WgZjW4yXFLNCN9rMIrN7Yykfqwy4j8pdpRVefBGhUSF2Wul6gzkkI2akTFY jB3I8kD6oIPtw047Tpw2E1et7OXQiY9i+1XPqfo06UbBwtIofs6UJKwx+OiQSEC6eT/X pm6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=P7GuTY+tG83oGDeUdTBsJB2u8ykHcE34nKYvdnkCUGg=; b=pAi6abbbY9LcizWTuzDxIP/OpW6uZTHie9grhQxkzxi7Z4i7XZJli8y6Q9Gh5YRsIb IDV8IMyqECyFIqRT+niCE28FQlLmU9JjWkDZgqylrANdR3SzY9HFPuGsPpi6oZ3Ik6mn P0owrerQOVeBGUzfXG2WKmoG2u5pc7u0qg49aJjU8Py/GJQWHtOBg77Vq+j4k4FqqpJL 5F86EZBWpe6np72os+3WwoFVzXeDYbHjUeUG7NiUAeZS3GLNdEUWVPyNdqPJ2n2FG35E 0gHtDCHZwI3/v3mGYPOyv80AA3CTWb0m+Mav+/hbmvLshsy5UJYENZvVlybpP3ZKJAgz sMYQ== X-Gm-Message-State: AN3rC/7dHnbYvU62ViH9TrKKnLCo6j/EXlqFPd6OL3mDUdyOj22NwGd8 HJDLnEFAMRukXzNYjshqiJcGKLBsuw== X-Received: by 10.84.194.165 with SMTP id h34mr8317255pld.129.1493215079231; Wed, 26 Apr 2017 06:57:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 06:57:18 -0700 (PDT) In-Reply-To: <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 09:57:18 -0400 Message-ID: To: Ben Campbell Cc: Paul Wouters , "ipsec@ietf.org" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , Tero Kivinen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 13:58:02 -0000 On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell wrote: > >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty wrote: >> >> Thanks for the quick response Paul, a few questions... >> >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters wrote: >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: >>> >>>>> IIUC, the entire point of having the stream prefix is to allow the TC= P >>>>> responder to demux between this protocol, and some other protocol tha= t >>>>> would normally run on that port. Saying it MUST close the TCP session >>>>> seems to completely remove that value. I assume people meant to allow= the >>>>> respondent to delegate a stream out to some other protocol handler if= the >>>>> prefix is not present? >>>>> >>>> >>>> I believe that this is because there is presumed to be no other >>>> service operating on the listening port (assuming a VPN concentrator), >>>> but that's not explicitly stated either. >>> >>> >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one o= f >>> the other kinds of SSL VPNs or as the administration interface or >>> user interface. >> >> OK, sounds like I didn't help here, so the editors should propose text >> to address this gap. > > I think we are on the right track here, pending proposed text. > >> >>> >>>>> -- 2nd to last paragraph: "This document leaves the selection of TCP >>>>> ports up to implementations." >>>>> I suspect "configurable local policy" would make more sense. Leaving = it >>>>> up to "implementations" leaves open the chance of different >>>>> implementations making non-intersecting port choices, which doesn't h= elp >>>>> interoperability. >>>> >>>> >>>> This may go more into unexplained assumptions... the clients >>>> authorized to connect to the server would need to know the correct >>>> port to establish a session and would be given that information >>>> specific to the implementation. With this assumption, the above >>>> should be fine... but editors/AD/WG, please correct me if I am wrong. >>> >>> >>> I am pretty sure what is meant is "configuration" and not "implementati= on". >> >> Is that in response to me being wrong in my assumption or the draft >> should say configuration (I think it's the latter, but important to >> check)? > > We are probably splitting hairs on the meaning of =E2=80=9Cimplementation= =E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. (and maybe =E2=80=9Cdeploymen= t=E2=80=9D). I was thinking of =E2=80=9Cimplementation=E2=80=9D as being wh= at developers do, and =E2=80=9Cconfiguring/deploying=E2=80=9D as what opera= tors do. But I am aware that operators sometimes talk about =E2=80=9Cimplem= enting=E2=80=9D a system. > > So my point was that I assume for purposes of interoperability that a gen= eral purpose client or server would allow the port to be changed in the fie= ld. > >> >>> >>>>> -4, first paragraph: What is the expected behavior from a peers that = do >>>>> not support this spec when they receive a TCP stream with the magic >>>>> number on a port for some other protocol? >>>> >>>> >>>> Maybe listing assumptions up front in the draft would help _IF_ the >>>> assumption is that the listening server is a VPN concentrator that >>>> wouldn't be listening for other services. >>> >>> >>> Support for TCP would be based on preconfiguration, so the client knows >>> this out-of-band. It cannot be discovered during negotiation, because >>> it is assumed the regular UDP ports are blocked, which is the only >>> reason to attempt TCP to begin with. >> >> I read the draft with this assumption in mind (see above), but this >> should be clarified in the document to address this question from Ben. > > Imagine a misconfigured client opening a connection to an web server on p= ort 80, expecting to find a VPN service. What happens? I think that a conse= quence of the design approach to allow this to run over ports assigned to o= ther protocols is that you need to consider that sort of thing. > >>> >>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one of th= e >>>>> primary reasons to use TLS? (Namely to obscure the fact that this is = not >>>>> HTTP, or whatever other protocol is assigned to the port?) >>>> >>>> >>>> Editors/AD correct me if I am wrong, but... >>>> No, if TLS is used with a NULL cipher, it'll pass inspection of a >>>> middle box validating the protocol. This doesn't need to use the >>>> cipher as it's negotiating the IPsec connection. >>> >>> >>> right, TLS happens to use encryption to get out, but it is not the >>> encryption of the actual IKE/IPsec protocols, which keep using their >>> own channel negotiations. >> >> I think clarifying this further in the draft would be helpful. > > I agree, because I=E2=80=99m still confused :-) > > To clarify my question: Assuming the case of TLS encapsulation to the HTT= PS port across a DPI middle-box that hates that sort of thing. If TLS uses = the NULL cipher, can the middlebox not tell that the protocol over TLS is n= ot HTTP? (I will defer to the experts.) IPsec WG participants should chime in here, Yoav may know for sure with his background, I'm sure others too. I'd guess that a DPI would not pick it up as the protocol inspection most likely assumes when it sees TLS, that the traffic is encrypted and looks no further for inspection/blocking purposes. The middleboxes that do some protocol inspection aren't like the ones from 15-20 years ago that dug into the protocol (blocking FTP commands, etc.). The use of TCP 443 for this has been in place for a decade or two, Google QUIC also uses TCP 443, and I'm sure other services do too. So tunneling does work. For purity, are we worried if this is TLS or HTTP/TLS (as the port usage specifies) or does that matter? > > --=20 Best regards, Kathleen From nobody Wed Apr 26 08:03:25 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E482412EC34; Wed, 26 Apr 2017 08:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VJTsBfzzFBO7; Wed, 26 Apr 2017 08:03:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 197FC12EC37; Wed, 26 Apr 2017 08:03:13 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QF3AOX046890 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 10:03:11 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <22784.32563.870450.167881@fireball.acr.fi> Date: Wed, 26 Apr 2017 10:03:10 -0500 Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2980CAE0-D03E-4C91-88E7-726A802F584E@nostrum.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <22784.32563.870450.167881@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:03:15 -0000 > On Apr 26, 2017, at 6:06 AM, Tero Kivinen wrote: >=20 > Ben Campbell writes: >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Substantive Comments: >>=20 >> -3, first paragraph: >> Are people confident there will never, ever be a need to demux = protocols >> other than IKE and ESP? If not, this approach may paint people in a >> corner in the future. I ask because we made similar choices with >> DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an = issue. >> See RFC7983 for a discussion. (Note that this would have been a = DISCUSS >> point, but I think it's reasonably likely that there really won't be >> other protocols here. But I want to make sure people have thought = about >> it.) >=20 > If we ever want to run other protocols there, we still have 255 > reserved values we can use as Non-ESP marker. The reason the > 0x00000000 is selected as Non-ESP marker in the UDP encapsulation (and > here) is because first four octets of the ESP packet are SPI, and SPI > MUST NOT be zero. Also numbers from 1 to 255 are "are reserved by the > Internet Assigned Numbers Authority (IANA) for future use" in the > RFC4303. >=20 > So if we need to run something else than IKE and ESP over that tunnel > we just reserve one of the other reserved IANA numbers for it and use > it as protocol marker for this new protocol.=20 Ah, I didn=E2=80=99t realize 1-255 were reserved. It might be worth a = mention that if future protocols are added, their prefixes must be = registered with IANA. (I note that 2 are registered already.) Am I correct to assume the draft did not also add a prefix for ESP is = due to performance reasons? Doing so would completely avoid any possible = collisions between the prefix value and the SPI. >=20 >> -3.2, " The SPI field in the ESP header MUST NOT be a zero value." >> Is this a new requirement for this draft? That is, does ESP otherwise >> allow zero value SPIs? If not, please consider dropping the MUST NOT. = =20 >=20 > RFC4303 reserves value zero for the "for local, > implementation-specific use and MUST NOT be sent on the wire.". >=20 > I.e., conforming ESP packet coming the to the UDP or TCP encapsulation > layer cannot have SPI of zero ever. And we are not using SPI zero, we > are using it as marker that this is not ESP packet, but this is IKE > packet. >=20 > The full text from the RFC4303 about the reserved SPI numbers is: > ---------------------------------------------------------------------- > 2.1. Security Parameters Index (SPI) > ... > The set of SPI values in the range 1 through 255 are reserved by the > Internet Assigned Numbers Authority (IANA) for future use; a = reserved > SPI value will not normally be assigned by IANA unless the use of = the > assigned SPI value is specified in an RFC. The SPI value of zero = (0) > is reserved for local, implementation-specific use and MUST NOT be > sent on the wire. (For example, a key management implementation > might use the zero SPI value to mean "No Security Association = Exists" > during the period when the IPsec implementation has requested that > its key management entity establish a new SA, but the SA has not yet > been established.) Got it. I propose the following: OLD: The SPI field in the ESP header MUST NOT be a zero value.=E2=80=9D NEW: [RFC4303] forbids a value of zero in the SPI field. > --=20 > kivinen@iki.fi From nobody Wed Apr 26 08:06:44 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2450112EC4B for ; Wed, 26 Apr 2017 08:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7i2a7Eidj5K for ; Wed, 26 Apr 2017 08:06:41 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 293BF12EC3D for ; Wed, 26 Apr 2017 08:06:18 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id u70so1726570ywe.2 for ; Wed, 26 Apr 2017 08:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QNo5DN2PFZTt9nhPD38OkOcatCtEz8GI3o+vCAjy86E=; b=YZ8XeX2lKD5VSjMWtNZoE/OTxGL8T7ocJUoniSJUZoR41GcGQz2VaiY+bzXi3lRbXJ csfAsOf5xszTEUlE0CkYgqg/OFt1ZCR6mdUWMNh4tpHtm50uuGCq0psMzQGl3m419AO6 fkerZ59/gJG5uMfvPdaDX4bK2tweF3EPpLK5TJgfcDtqU7xZr7viZrE7cymX6E1RqHtW kxRXIGrdcBIEi49Q+ahc3V4zTAy5G/lRHkzGv1+dRxHrsS4BpRRgWr0eWSUFnWD9ZgIh VKkBRoWrBJ++QtUmR/iBzYecDMyfoHf/9e1KO4lWN1V9DNY3Ghhom//VoEp/DoRlyGFE cdPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QNo5DN2PFZTt9nhPD38OkOcatCtEz8GI3o+vCAjy86E=; b=rC6x5bAVYL0PiTatnX7skR5ClOJiNW0sU5XCcvkvc7ZWDON4si/ud78wKIixEVTLq6 mTx6rJlYbw0M3R6MXR4GRaJrZSDix71GcqYK4KPdFKDwV5eOTIoLSk/GvZdmqx+bTFwC i7NSZQLmokWHGQbMH20g70JxfNMB7nb3GKMX2vTyRjhvjpgOpdH7nsGX4mHmxCTVmiEO NJH1oh/MAwV7BDh/usYj5enAIoqvYVkkPKgSj75QfgRLlOoi521gPWvDZie9RFE6vU9Z 3yp0/TkTfs/nixMag1lKml4smacoCwFZMiYdsWzbzMArMAQHAyLNJFknsm3yamHksg25 A1ig== X-Gm-Message-State: AN3rC/6cPnMQ89ZLgiJGBxXpqiiLeo9uii6mNmtx3LkFQuj1GbI0zZTB PivqtHoDY8H8BoiB3o4KkkZijqncWg== X-Received: by 10.129.95.68 with SMTP id t65mr222627ywb.74.1493219177250; Wed, 26 Apr 2017 08:06:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 26 Apr 2017 08:05:35 -0700 (PDT) In-Reply-To: References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> From: Eric Rescorla Date: Wed, 26 Apr 2017 08:05:35 -0700 Message-ID: To: Kathleen Moriarty Cc: Ben Campbell , ipsecme-chairs@ietf.org, Tero Kivinen , "ipsec@ietf.org" , The IESG , Paul Wouters , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Type: multipart/alternative; boundary=001a1147e56ea1d757054e132e7e Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:06:43 -0000 --001a1147e56ea1d757054e132e7e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell wrote: > > > >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> > >> Thanks for the quick response Paul, a few questions... > >> > >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters wrote: > >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: > >>> > >>>>> IIUC, the entire point of having the stream prefix is to allow the > TCP > >>>>> responder to demux between this protocol, and some other protocol > that > >>>>> would normally run on that port. Saying it MUST close the TCP sessi= on > >>>>> seems to completely remove that value. I assume people meant to > allow the > >>>>> respondent to delegate a stream out to some other protocol handler > if the > >>>>> prefix is not present? > >>>>> > >>>> > >>>> I believe that this is because there is presumed to be no other > >>>> service operating on the listening port (assuming a VPN concentrator= ), > >>>> but that's not explicitly stated either. > >>> > >>> > >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one > of > >>> the other kinds of SSL VPNs or as the administration interface or > >>> user interface. > >> > >> OK, sounds like I didn't help here, so the editors should propose text > >> to address this gap. > > > > I think we are on the right track here, pending proposed text. > > > >> > >>> > >>>>> -- 2nd to last paragraph: "This document leaves the selection of TC= P > >>>>> ports up to implementations." > >>>>> I suspect "configurable local policy" would make more sense. Leavin= g > it > >>>>> up to "implementations" leaves open the chance of different > >>>>> implementations making non-intersecting port choices, which doesn't > help > >>>>> interoperability. > >>>> > >>>> > >>>> This may go more into unexplained assumptions... the clients > >>>> authorized to connect to the server would need to know the correct > >>>> port to establish a session and would be given that information > >>>> specific to the implementation. With this assumption, the above > >>>> should be fine... but editors/AD/WG, please correct me if I am wrong= . > >>> > >>> > >>> I am pretty sure what is meant is "configuration" and not > "implementation". > >> > >> Is that in response to me being wrong in my assumption or the draft > >> should say configuration (I think it's the latter, but important to > >> check)? > > > > We are probably splitting hairs on the meaning of =E2=80=9Cimplementati= on=E2=80=9D vs > =E2=80=9Cconfiguration=E2=80=9D. (and maybe =E2=80=9Cdeployment=E2=80=9D)= . I was thinking of > =E2=80=9Cimplementation=E2=80=9D as being what developers do, and =E2=80= =9Cconfiguring/deploying=E2=80=9D > as what operators do. But I am aware that operators sometimes talk about > =E2=80=9Cimplementing=E2=80=9D a system. > > > > So my point was that I assume for purposes of interoperability that a > general purpose client or server would allow the port to be changed in th= e > field. > > > >> > >>> > >>>>> -4, first paragraph: What is the expected behavior from a peers tha= t > do > >>>>> not support this spec when they receive a TCP stream with the magic > >>>>> number on a port for some other protocol? > >>>> > >>>> > >>>> Maybe listing assumptions up front in the draft would help _IF_ the > >>>> assumption is that the listening server is a VPN concentrator that > >>>> wouldn't be listening for other services. > >>> > >>> > >>> Support for TCP would be based on preconfiguration, so the client kno= ws > >>> this out-of-band. It cannot be discovered during negotiation, because > >>> it is assumed the regular UDP ports are blocked, which is the only > >>> reason to attempt TCP to begin with. > >> > >> I read the draft with this assumption in mind (see above), but this > >> should be clarified in the document to address this question from Ben. > > > > Imagine a misconfigured client opening a connection to an web server on > port 80, expecting to find a VPN service. What happens? I think that a > consequence of the design approach to allow this to run over ports assign= ed > to other protocols is that you need to consider that sort of thing. > > > >>> > >>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one of > the > >>>>> primary reasons to use TLS? (Namely to obscure the fact that this i= s > not > >>>>> HTTP, or whatever other protocol is assigned to the port?) > >>>> > >>>> > >>>> Editors/AD correct me if I am wrong, but... > >>>> No, if TLS is used with a NULL cipher, it'll pass inspection of a > >>>> middle box validating the protocol. This doesn't need to use the > >>>> cipher as it's negotiating the IPsec connection. > >>> > >>> > >>> right, TLS happens to use encryption to get out, but it is not the > >>> encryption of the actual IKE/IPsec protocols, which keep using their > >>> own channel negotiations. > >> > >> I think clarifying this further in the draft would be helpful. > > > > I agree, because I=E2=80=99m still confused :-) > > > > To clarify my question: Assuming the case of TLS encapsulation to the > HTTPS port across a DPI middle-box that hates that sort of thing. If TLS > uses the NULL cipher, can the middlebox not tell that the protocol over T= LS > is not HTTP? (I will defer to the experts.) > > IPsec WG participants should chime in here, Yoav may know for sure > with his background, I'm sure others too. > > I'd guess that a DPI would not pick it up as the protocol inspection > most likely assumes when it sees TLS, that the traffic is encrypted > and looks no further for inspection/blocking purposes. The > middleboxes that do some protocol inspection aren't like the ones from > 15-20 years ago that dug into the protocol (blocking FTP commands, > etc.). > > The use of TCP 443 for this has been in place for a decade or two, > Hmm... In most cases people are tunnelling over HTTP, and due to concerns about cross-protocol attacks, I think that's a good thing. See, for instance [0] Google QUIC also uses TCP 443, and I'm sure other services do too. So > tunneling does work. > Hmm... Not to my knowledge. QUIC is UDP over 443 I believe that in cases where UDP doesn't work, Chrome falls back to HTTP/TLS/TCP. Do you have a pointer? -Ekr [0] http://www.adambarth.com/papers/2011/huang-chen-barth- rescorla-jackson.pdf > > > > > -- > > Best regards, > Kathleen > > --001a1147e56ea1d757054e132e7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:
On Tue, Apr 25, 2017 = at 11:54 PM, Ben Campbell <ben@nostrum.com> wrote:
>
>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty <kathleen.moriarty.ie= tf@gmail.com> wrote:
>>
>> Thanks for the quick response Paul, a few questions...
>>
>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters <paul@nohats.ca> wrote:
>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
>>>
>>>>> IIUC, the entire point of having the stream prefix is = to allow the TCP
>>>>> responder to demux between this protocol, and some oth= er protocol that
>>>>> would normally run on that port. Saying it MUST close = the TCP session
>>>>> seems to completely remove that value. I assume people= meant to allow the
>>>>> respondent to delegate a stream out to some other prot= ocol handler if the
>>>>> prefix is not present?
>>>>>
>>>>
>>>> I believe that this is because there is presumed to be no = other
>>>> service operating on the listening port (assuming a VPN co= ncentrator),
>>>> but that's not explicitly stated either.
>>>
>>>
>>> Vendors tend to run TLS on the IKE/IPsec machine, either to of= fer one of
>>> the other kinds of SSL VPNs or as the administration interface= or
>>> user interface.
>>
>> OK, sounds like I didn't help here, so the editors should prop= ose text
>> to address this gap.
>
> I think we are on the right track here, pending proposed text.
>
>>
>>>
>>>>> -- 2nd to last paragraph: "This document leaves t= he selection of TCP
>>>>> ports up to implementations."
>>>>> I suspect "configurable local policy" would = make more sense. Leaving it
>>>>> up to "implementations" leaves open the chan= ce of different
>>>>> implementations making non-intersecting port choices, = which doesn't help
>>>>> interoperability.
>>>>
>>>>
>>>> This may go more into unexplained assumptions... the clien= ts
>>>> authorized to connect to the server would need to know the= correct
>>>> port to establish a session and would be given that inform= ation
>>>> specific to the implementation.=C2=A0 With this assumption= , the above
>>>> should be fine... but editors/AD/WG, please correct me if = I am wrong.
>>>
>>>
>>> I am pretty sure what is meant is "configuration" an= d not "implementation".
>>
>> Is that in response to me being wrong in my assumption or the draf= t
>> should say configuration (I think it's the latter, but importa= nt to
>> check)?
>
> We are probably splitting hairs on the meaning of =E2=80=9Cimplementat= ion=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. (and maybe =E2=80=9Cdeploy= ment=E2=80=9D). I was thinking of =E2=80=9Cimplementation=E2=80=9D as being= what developers do, and =E2=80=9Cconfiguring/deploying=E2=80=9D as what op= erators do. But I am aware that operators sometimes talk about =E2=80=9Cimp= lementing=E2=80=9D a system.
>
> So my point was that I assume for purposes of interoperability that a = general purpose client or server would allow the port to be changed in the = field.
>
>>
>>>
>>>>> -4, first paragraph: What is the expected behavior fro= m a peers that do
>>>>> not support this spec when they receive a TCP stream w= ith the magic
>>>>> number on a port for some other protocol?
>>>>
>>>>
>>>> Maybe listing assumptions up front in the draft would help= _IF_ the
>>>> assumption is that the listening server is a VPN concentra= tor that
>>>> wouldn't be listening for other services.
>>>
>>>
>>> Support for TCP would be based on preconfiguration, so the cli= ent knows
>>> this out-of-band. It cannot be discovered during negotiation, = because
>>> it is assumed the regular UDP ports are blocked, which is the = only
>>> reason to attempt TCP to begin with.
>>
>> I read the draft with this assumption in mind (see above), but thi= s
>> should be clarified in the document to address this question from = Ben.
>
> Imagine a misconfigured client opening a connection to an web server o= n port 80, expecting to find a VPN service. What happens? I think that a co= nsequence of the design approach to allow this to run over ports assigned t= o other protocols is that you need to consider that sort of thing.
>
>>>
>>>>> - Appendix A: Doesn't the use of the NULL cipher i= nvalidate one of the
>>>>> primary reasons to use TLS? (Namely to obscure the fac= t that this is not
>>>>> HTTP, or whatever other protocol is assigned to the po= rt?)
>>>>
>>>>
>>>> Editors/AD correct me if I am wrong, but...
>>>> No, if TLS is used with a NULL cipher, it'll pass insp= ection of a
>>>> middle box validating the protocol.=C2=A0 This doesn't= need to use the
>>>> cipher as it's negotiating the IPsec connection.
>>>
>>>
>>> right, TLS happens to use encryption to get out, but it is not= the
>>> encryption of the actual IKE/IPsec protocols, which keep using= their
>>> own channel negotiations.
>>
>> I think clarifying this further in the draft would be helpful.
>
> I agree, because I=E2=80=99m still confused :-)
>
> To clarify my question: Assuming the case of TLS encapsulation to the = HTTPS port across a DPI middle-box that hates that sort of thing. If TLS us= es the NULL cipher, can the middlebox not tell that the protocol over TLS i= s not HTTP? (I will defer to the experts.)

IPsec WG participants should chime in here, Yoav may know for s= ure
with his background, I'm sure others too.

I'd guess that a DPI would not pick it up as the protocol inspection most likely assumes when it sees TLS, that the traffic is encrypted
and looks no further for inspection/blocking purposes.=C2=A0 The
middleboxes that do some protocol inspection aren't like the ones from<= br> 15-20 years ago that dug into the protocol (blocking FTP commands,
etc.).

The use of TCP 443 for this has been in place for a decade or two,

Hmm... In most cases people are tunnelling over= HTTP, and due to concerns
about cross-protocol attacks, I think = that's a good thing. See, for instance =C2=A0[0]


Google QUIC = also uses TCP 443, and I'm sure other services do too. So
tunneling does work.

Hmm... Not to my k= nowledge.=C2=A0 QUIC is UDP over 443 I believe that in cases
wher= e UDP doesn't work, Chrome falls back to HTTP/TLS/TCP. Do you have
a pointer?

-Ekr


<= /div>

>
<= br>

--

Best regards,
Kathleen


--001a1147e56ea1d757054e132e7e-- From nobody Wed Apr 26 08:14:12 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EC612EC6E; Wed, 26 Apr 2017 08:14:04 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OYttSbnQ8gt; Wed, 26 Apr 2017 08:14:02 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 5683312EC67; Wed, 26 Apr 2017 08:14:02 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id 194so1490189pfv.3; Wed, 26 Apr 2017 08:14:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=KCiNgg1MBkjHAUsXWspF4ck7HZQ0SbXsNNbQ/xLSj+M=; b=JikuSTomhPE2CA2IDPisX1HiOEKE31DhFYsb4wMz569lD3JDYM0UlUncdm0j2x+QcR QVdW3vpK2MjBLx++v9+O+acI9U+4a9XBwj9XU8MobjR9LAl+zR+W0KnAo84TCAD5kcnj aflryLp0y9iK0USkJMXPczwNUZLvWEXKskA4pBNo314FTC3Kzmy5tNMp72fLO4q9LE88 NDnW/384q9ecpkZLbbicd7YeauK3dNOpAdBk5Y0GnaD1RwUhzORcjb7BjTpWLhOFhRAm 8Va69BRkvxP4TZ0uCM8Dp0a2wMtH1lm/HddmUqWQSDBqQprLFvEjaPXF4LpZTah203K/ OQLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=KCiNgg1MBkjHAUsXWspF4ck7HZQ0SbXsNNbQ/xLSj+M=; b=QdiskzwDuXHpETb1ubbB1GIjAyBO5Oh3ZkbXnJUCuvoQqr6P8BnitGMvi3hLd1WTar grN+t0CIp7MjlwWoYv8MfDNnlCNs/ST8PhiDX5+BoBCNavRIz9IL01WdO/3gCIyJEmYL /ewzcJs/27n+Ecar8AAIhFU8wQxitBWnflbd6gzO3ctXxxhYCtE1in26dn8V1rowBxMv g0NKHy5D5n6siSt5oTQ8dC4qCGw8PXFtZJOG/8jmUao/ffKG3dgz9l441C6mzZvUrg8i 39+za9Cr0vUtxYt5pehmhVZcPIA+7AZAUwL6RMt/yuW6Vv9f2EdaUaqxqYneSXQO5Fl/ vdjw== X-Gm-Message-State: AN3rC/7UlUg4mIWTk/2Y4ruXVpO320tvvt0xeJU6VMg0qQN5RLTqasJV FdiKp3k9yhYzAJaWlZbUrbC2DP34vA== X-Received: by 10.84.194.165 with SMTP id h34mr325973pld.129.1493219641789; Wed, 26 Apr 2017 08:14:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Wed, 26 Apr 2017 08:13:21 -0700 (PDT) In-Reply-To: References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> From: Kathleen Moriarty Date: Wed, 26 Apr 2017 11:13:21 -0400 Message-ID: To: Eric Rescorla Cc: Ben Campbell , ipsecme-chairs@ietf.org, Tero Kivinen , "ipsec@ietf.org" , The IESG , Paul Wouters , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:14:05 -0000 On Wed, Apr 26, 2017 at 11:05 AM, Eric Rescorla wrote: > > > On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty > wrote: >> >> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell wrote: >> > >> >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty >> >> wrote: >> >> >> >> Thanks for the quick response Paul, a few questions... >> >> >> >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters wrote= : >> >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: >> >>> >> >>>>> IIUC, the entire point of having the stream prefix is to allow the >> >>>>> TCP >> >>>>> responder to demux between this protocol, and some other protocol >> >>>>> that >> >>>>> would normally run on that port. Saying it MUST close the TCP >> >>>>> session >> >>>>> seems to completely remove that value. I assume people meant to >> >>>>> allow the >> >>>>> respondent to delegate a stream out to some other protocol handler >> >>>>> if the >> >>>>> prefix is not present? >> >>>>> >> >>>> >> >>>> I believe that this is because there is presumed to be no other >> >>>> service operating on the listening port (assuming a VPN >> >>>> concentrator), >> >>>> but that's not explicitly stated either. >> >>> >> >>> >> >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer on= e >> >>> of >> >>> the other kinds of SSL VPNs or as the administration interface or >> >>> user interface. >> >> >> >> OK, sounds like I didn't help here, so the editors should propose tex= t >> >> to address this gap. >> > >> > I think we are on the right track here, pending proposed text. >> > >> >> >> >>> >> >>>>> -- 2nd to last paragraph: "This document leaves the selection of T= CP >> >>>>> ports up to implementations." >> >>>>> I suspect "configurable local policy" would make more sense. Leavi= ng >> >>>>> it >> >>>>> up to "implementations" leaves open the chance of different >> >>>>> implementations making non-intersecting port choices, which doesn'= t >> >>>>> help >> >>>>> interoperability. >> >>>> >> >>>> >> >>>> This may go more into unexplained assumptions... the clients >> >>>> authorized to connect to the server would need to know the correct >> >>>> port to establish a session and would be given that information >> >>>> specific to the implementation. With this assumption, the above >> >>>> should be fine... but editors/AD/WG, please correct me if I am wron= g. >> >>> >> >>> >> >>> I am pretty sure what is meant is "configuration" and not >> >>> "implementation". >> >> >> >> Is that in response to me being wrong in my assumption or the draft >> >> should say configuration (I think it's the latter, but important to >> >> check)? >> > >> > We are probably splitting hairs on the meaning of =E2=80=9Cimplementat= ion=E2=80=9D vs >> > =E2=80=9Cconfiguration=E2=80=9D. (and maybe =E2=80=9Cdeployment=E2=80= =9D). I was thinking of >> > =E2=80=9Cimplementation=E2=80=9D as being what developers do, and =E2= =80=9Cconfiguring/deploying=E2=80=9D as >> > what operators do. But I am aware that operators sometimes talk about >> > =E2=80=9Cimplementing=E2=80=9D a system. >> > >> > So my point was that I assume for purposes of interoperability that a >> > general purpose client or server would allow the port to be changed in= the >> > field. >> > >> >> >> >>> >> >>>>> -4, first paragraph: What is the expected behavior from a peers th= at >> >>>>> do >> >>>>> not support this spec when they receive a TCP stream with the magi= c >> >>>>> number on a port for some other protocol? >> >>>> >> >>>> >> >>>> Maybe listing assumptions up front in the draft would help _IF_ the >> >>>> assumption is that the listening server is a VPN concentrator that >> >>>> wouldn't be listening for other services. >> >>> >> >>> >> >>> Support for TCP would be based on preconfiguration, so the client >> >>> knows >> >>> this out-of-band. It cannot be discovered during negotiation, becaus= e >> >>> it is assumed the regular UDP ports are blocked, which is the only >> >>> reason to attempt TCP to begin with. >> >> >> >> I read the draft with this assumption in mind (see above), but this >> >> should be clarified in the document to address this question from Ben= . >> > >> > Imagine a misconfigured client opening a connection to an web server o= n >> > port 80, expecting to find a VPN service. What happens? I think that a >> > consequence of the design approach to allow this to run over ports ass= igned >> > to other protocols is that you need to consider that sort of thing. >> > >> >>> >> >>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one of >> >>>>> the >> >>>>> primary reasons to use TLS? (Namely to obscure the fact that this = is >> >>>>> not >> >>>>> HTTP, or whatever other protocol is assigned to the port?) >> >>>> >> >>>> >> >>>> Editors/AD correct me if I am wrong, but... >> >>>> No, if TLS is used with a NULL cipher, it'll pass inspection of a >> >>>> middle box validating the protocol. This doesn't need to use the >> >>>> cipher as it's negotiating the IPsec connection. >> >>> >> >>> >> >>> right, TLS happens to use encryption to get out, but it is not the >> >>> encryption of the actual IKE/IPsec protocols, which keep using their >> >>> own channel negotiations. >> >> >> >> I think clarifying this further in the draft would be helpful. >> > >> > I agree, because I=E2=80=99m still confused :-) >> > >> > To clarify my question: Assuming the case of TLS encapsulation to the >> > HTTPS port across a DPI middle-box that hates that sort of thing. If T= LS >> > uses the NULL cipher, can the middlebox not tell that the protocol ove= r TLS >> > is not HTTP? (I will defer to the experts.) >> >> IPsec WG participants should chime in here, Yoav may know for sure >> with his background, I'm sure others too. >> >> I'd guess that a DPI would not pick it up as the protocol inspection >> most likely assumes when it sees TLS, that the traffic is encrypted >> and looks no further for inspection/blocking purposes. The >> middleboxes that do some protocol inspection aren't like the ones from >> 15-20 years ago that dug into the protocol (blocking FTP commands, >> etc.). >> >> The use of TCP 443 for this has been in place for a decade or two, > > > Hmm... In most cases people are tunnelling over HTTP, and due to concerns > about cross-protocol attacks, I think that's a good thing. See, for insta= nce > [0] > This draft doesn't make that clear. If that is the case, then I had previously asked somewhere in this thread if they could just specify that so the proper use of 443 would be in place - ending the discussion. > >> Google QUIC also uses TCP 443, and I'm sure other services do too. So >> tunneling does work. > > > Hmm... Not to my knowledge. QUIC is UDP over 443 I believe that in cases > where UDP doesn't work, Chrome falls back to HTTP/TLS/TCP. Do you have > a pointer? No, it was sent to me in thread by a WG participant... so discard for now. > > -Ekr > > > [0] > http://www.adambarth.com/papers/2011/huang-chen-barth-rescorla-jackson.pd= f > > >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> > --=20 Best regards, Kathleen From nobody Wed Apr 26 08:19:27 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3563612EC94; Wed, 26 Apr 2017 08:19:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Alexey Melnikov To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149321995812.20766.53587085814300521.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 08:19:18 -0700 Archived-At: Subject: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:19:18 -0000 Alexey Melnikov has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 2. Configuration o Optionally, an extra framing protocol to use on top of TCP to further encapsulate the stream of IKE and IPsec packets. See Appendix A for a detailed discussion. As Appendix A just talks about TLS, why not say this here explicitly? The sentence above make it sound like this is something outside of scope for the document and Appendix A talks about generic way to encapsulate. From nobody Wed Apr 26 08:34:59 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285561300E8 for ; Wed, 26 Apr 2017 08:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Csw2wsRC1zip for ; Wed, 26 Apr 2017 08:34:50 -0700 (PDT) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (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 E3BDF12FEEB for ; Wed, 26 Apr 2017 08:34:45 -0700 (PDT) Received: by mail-yb0-x22e.google.com with SMTP id p143so1126076yba.2 for ; Wed, 26 Apr 2017 08:34:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UxIIN+JgaOYwq4vQxpSDSkMQTQYCt7DYKxadOjz2pN4=; b=z61TsUgTGcJfv5sLSTcxd7//WUFNcVHzmf1YuY37QdajcFZ0463x0BMrtro36DcMB4 zrARsM4Y8rAfE7/8u4KeE4kacOyDU2/+ybsmyUi6U1wMbP4R8J7EYKSX0gvlULMOfwLy d9qQz+JouWbbSrze/Vzo9krVxBkeo3p8O/9/65lk/3MPpV7qy5W4SNRebF3BroSK7bEx kSmj68Y9oNxvNpusoVGG/+cBnFsaY9I2LZZnx6KkYSiqqQGky3zdpUsWkLtzKDWgTkY/ yWclBPU1G9C6WgpqRSBXJwuMbDDg9milFC6HA6SsSWS785q2LNE5Oggxq8/60rndSMP3 OvRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UxIIN+JgaOYwq4vQxpSDSkMQTQYCt7DYKxadOjz2pN4=; b=mEbDI8U5oPJM1TAWSSUAYiNSGSCgwB0FhS4wNvhsNiAF1UDKUEfzGxhIoP4L7NtU6G GhG/lscGUty7jy7Ak97V0pRijkhAq5FaT8bMsvPIx9EEdU2dDOtg6jl6E5Z9t3IAeWWl aUfD+h3wO5pJD+U8WPjwXi9pzroCZ5jy/wfRYBulqAR9OcN3sm0ppKtjhHF6TxN3ZvR9 863KUcNjGl52twmFKagMat2MnXuIlyCCeh7L5AaMmjTBQXZt6jKzGTFis6Ub1kS7Xjkl ncj9SwSdVx8aPuABmOWdVjLzRObggn+Tznxq50ZiJdQC8EdiEER25FYTGECEkeuWftQa RMkw== X-Gm-Message-State: AN3rC/5kDSEO6clwlq7b62s1nUZDfq3OHPRfF3yTtd0g0YKFCejIPBdX hi2/CUA1nfyZazMrRBvWbNFJotEjWA== X-Received: by 10.37.174.24 with SMTP id a24mr358014ybj.50.1493220884971; Wed, 26 Apr 2017 08:34:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 26 Apr 2017 08:34:04 -0700 (PDT) In-Reply-To: References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> From: Eric Rescorla Date: Wed, 26 Apr 2017 08:34:04 -0700 Message-ID: To: Kathleen Moriarty Cc: Ben Campbell , ipsecme-chairs@ietf.org, Tero Kivinen , "ipsec@ietf.org" , The IESG , Paul Wouters , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Type: multipart/alternative; boundary=f403045da3586bc563054e1394bf Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:34:52 -0000 --f403045da3586bc563054e1394bf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Apr 26, 2017 at 8:13 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > On Wed, Apr 26, 2017 at 11:05 AM, Eric Rescorla wrote: > > > > > > On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty > > wrote: > >> > >> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell wrote= : > >> > > >> >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty > >> >> wrote: > >> >> > >> >> Thanks for the quick response Paul, a few questions... > >> >> > >> >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters > wrote: > >> >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: > >> >>> > >> >>>>> IIUC, the entire point of having the stream prefix is to allow t= he > >> >>>>> TCP > >> >>>>> responder to demux between this protocol, and some other protoco= l > >> >>>>> that > >> >>>>> would normally run on that port. Saying it MUST close the TCP > >> >>>>> session > >> >>>>> seems to completely remove that value. I assume people meant to > >> >>>>> allow the > >> >>>>> respondent to delegate a stream out to some other protocol handl= er > >> >>>>> if the > >> >>>>> prefix is not present? > >> >>>>> > >> >>>> > >> >>>> I believe that this is because there is presumed to be no other > >> >>>> service operating on the listening port (assuming a VPN > >> >>>> concentrator), > >> >>>> but that's not explicitly stated either. > >> >>> > >> >>> > >> >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer > one > >> >>> of > >> >>> the other kinds of SSL VPNs or as the administration interface or > >> >>> user interface. > >> >> > >> >> OK, sounds like I didn't help here, so the editors should propose > text > >> >> to address this gap. > >> > > >> > I think we are on the right track here, pending proposed text. > >> > > >> >> > >> >>> > >> >>>>> -- 2nd to last paragraph: "This document leaves the selection of > TCP > >> >>>>> ports up to implementations." > >> >>>>> I suspect "configurable local policy" would make more sense. > Leaving > >> >>>>> it > >> >>>>> up to "implementations" leaves open the chance of different > >> >>>>> implementations making non-intersecting port choices, which > doesn't > >> >>>>> help > >> >>>>> interoperability. > >> >>>> > >> >>>> > >> >>>> This may go more into unexplained assumptions... the clients > >> >>>> authorized to connect to the server would need to know the correc= t > >> >>>> port to establish a session and would be given that information > >> >>>> specific to the implementation. With this assumption, the above > >> >>>> should be fine... but editors/AD/WG, please correct me if I am > wrong. > >> >>> > >> >>> > >> >>> I am pretty sure what is meant is "configuration" and not > >> >>> "implementation". > >> >> > >> >> Is that in response to me being wrong in my assumption or the draft > >> >> should say configuration (I think it's the latter, but important to > >> >> check)? > >> > > >> > We are probably splitting hairs on the meaning of =E2=80=9Cimplement= ation=E2=80=9D vs > >> > =E2=80=9Cconfiguration=E2=80=9D. (and maybe =E2=80=9Cdeployment=E2= =80=9D). I was thinking of > >> > =E2=80=9Cimplementation=E2=80=9D as being what developers do, and > =E2=80=9Cconfiguring/deploying=E2=80=9D as > >> > what operators do. But I am aware that operators sometimes talk abou= t > >> > =E2=80=9Cimplementing=E2=80=9D a system. > >> > > >> > So my point was that I assume for purposes of interoperability that = a > >> > general purpose client or server would allow the port to be changed > in the > >> > field. > >> > > >> >> > >> >>> > >> >>>>> -4, first paragraph: What is the expected behavior from a peers > that > >> >>>>> do > >> >>>>> not support this spec when they receive a TCP stream with the > magic > >> >>>>> number on a port for some other protocol? > >> >>>> > >> >>>> > >> >>>> Maybe listing assumptions up front in the draft would help _IF_ t= he > >> >>>> assumption is that the listening server is a VPN concentrator tha= t > >> >>>> wouldn't be listening for other services. > >> >>> > >> >>> > >> >>> Support for TCP would be based on preconfiguration, so the client > >> >>> knows > >> >>> this out-of-band. It cannot be discovered during negotiation, > because > >> >>> it is assumed the regular UDP ports are blocked, which is the only > >> >>> reason to attempt TCP to begin with. > >> >> > >> >> I read the draft with this assumption in mind (see above), but this > >> >> should be clarified in the document to address this question from > Ben. > >> > > >> > Imagine a misconfigured client opening a connection to an web server > on > >> > port 80, expecting to find a VPN service. What happens? I think that= a > >> > consequence of the design approach to allow this to run over ports > assigned > >> > to other protocols is that you need to consider that sort of thing. > >> > > >> >>> > >> >>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one = of > >> >>>>> the > >> >>>>> primary reasons to use TLS? (Namely to obscure the fact that thi= s > is > >> >>>>> not > >> >>>>> HTTP, or whatever other protocol is assigned to the port?) > >> >>>> > >> >>>> > >> >>>> Editors/AD correct me if I am wrong, but... > >> >>>> No, if TLS is used with a NULL cipher, it'll pass inspection of a > >> >>>> middle box validating the protocol. This doesn't need to use the > >> >>>> cipher as it's negotiating the IPsec connection. > >> >>> > >> >>> > >> >>> right, TLS happens to use encryption to get out, but it is not the > >> >>> encryption of the actual IKE/IPsec protocols, which keep using the= ir > >> >>> own channel negotiations. > >> >> > >> >> I think clarifying this further in the draft would be helpful. > >> > > >> > I agree, because I=E2=80=99m still confused :-) > >> > > >> > To clarify my question: Assuming the case of TLS encapsulation to th= e > >> > HTTPS port across a DPI middle-box that hates that sort of thing. If > TLS > >> > uses the NULL cipher, can the middlebox not tell that the protocol > over TLS > >> > is not HTTP? (I will defer to the experts.) > >> > >> IPsec WG participants should chime in here, Yoav may know for sure > >> with his background, I'm sure others too. > >> > >> I'd guess that a DPI would not pick it up as the protocol inspection > >> most likely assumes when it sees TLS, that the traffic is encrypted > >> and looks no further for inspection/blocking purposes. The > >> middleboxes that do some protocol inspection aren't like the ones from > >> 15-20 years ago that dug into the protocol (blocking FTP commands, > >> etc.). > >> > >> The use of TCP 443 for this has been in place for a decade or two, > > > > > > Hmm... In most cases people are tunnelling over HTTP, and due to concer= ns > > about cross-protocol attacks, I think that's a good thing. See, for > instance > > [0] > > > > This draft doesn't make that clear. If that is the case, then I had > previously asked somewhere in this thread if they could just specify > that so the proper use of 443 would be in place - ending the > discussion. > Sorry, bad writing on my part. I think they're not doing that here, so we should at least ask if that's a problem (though the answer may well be "no") -Ekr > > > >> Google QUIC also uses TCP 443, and I'm sure other services do too. So > >> tunneling does work. > > > > > > Hmm... Not to my knowledge. QUIC is UDP over 443 I believe that in cas= es > > where UDP doesn't work, Chrome falls back to HTTP/TLS/TCP. Do you have > > a pointer? > > No, it was sent to me in thread by a WG participant... so discard for now= . > > > > -Ekr > > > > > > [0] > > http://www.adambarth.com/papers/2011/huang-chen-barth- > rescorla-jackson.pdf > > > > > >> > > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > >> > > > > > > -- > > Best regards, > Kathleen > --f403045da3586bc563054e1394bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 26, 2017 at 8:13 AM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:
On Wed, Apr 26, 2017 at = 11:05 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
>
> On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty
> <kathleen.moria= rty.ietf@gmail.com> wrote:
>>
>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell <ben@nostrum.com> wrote:
>> >
>> >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty
>> >> <k= athleen.moriarty.ietf@gmail.com> wrote:
>> >>
>> >> Thanks for the quick response Paul, a few questions... >> >>
>> >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters <paul@nohats.ca> wrote:
>> >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
>> >>>
>> >>>>> IIUC, the entire point of having the stream p= refix is to allow the
>> >>>>> TCP
>> >>>>> responder to demux between this protocol, and= some other protocol
>> >>>>> that
>> >>>>> would normally run on that port. Saying it MU= ST close the TCP
>> >>>>> session
>> >>>>> seems to completely remove that value. I assu= me people meant to
>> >>>>> allow the
>> >>>>> respondent to delegate a stream out to some o= ther protocol handler
>> >>>>> if the
>> >>>>> prefix is not present?
>> >>>>>
>> >>>>
>> >>>> I believe that this is because there is presumed = to be no other
>> >>>> service operating on the listening port (assuming= a VPN
>> >>>> concentrator),
>> >>>> but that's not explicitly stated either.
>> >>>
>> >>>
>> >>> Vendors tend to run TLS on the IKE/IPsec machine, eit= her to offer one
>> >>> of
>> >>> the other kinds of SSL VPNs or as the administration = interface or
>> >>> user interface.
>> >>
>> >> OK, sounds like I didn't help here, so the editors sh= ould propose text
>> >> to address this gap.
>> >
>> > I think we are on the right track here, pending proposed text= .
>> >
>> >>
>> >>>
>> >>>>> -- 2nd to last paragraph: "This document= leaves the selection of TCP
>> >>>>> ports up to implementations."
>> >>>>> I suspect "configurable local policy&quo= t; would make more sense. Leaving
>> >>>>> it
>> >>>>> up to "implementations" leaves open= the chance of different
>> >>>>> implementations making non-intersecting port = choices, which doesn't
>> >>>>> help
>> >>>>> interoperability.
>> >>>>
>> >>>>
>> >>>> This may go more into unexplained assumptions... = the clients
>> >>>> authorized to connect to the server would need to= know the correct
>> >>>> port to establish a session and would be given th= at information
>> >>>> specific to the implementation.=C2=A0 With this a= ssumption, the above
>> >>>> should be fine... but editors/AD/WG, please corre= ct me if I am wrong.
>> >>>
>> >>>
>> >>> I am pretty sure what is meant is "configuration= " and not
>> >>> "implementation".
>> >>
>> >> Is that in response to me being wrong in my assumption or= the draft
>> >> should say configuration (I think it's the latter, bu= t important to
>> >> check)?
>> >
>> > We are probably splitting hairs on the meaning of =E2=80=9Cim= plementation=E2=80=9D vs
>> > =E2=80=9Cconfiguration=E2=80=9D. (and maybe =E2=80=9Cdeployme= nt=E2=80=9D). I was thinking of
>> > =E2=80=9Cimplementation=E2=80=9D as being what developers do,= and =E2=80=9Cconfiguring/deploying=E2=80=9D as
>> > what operators do. But I am aware that operators sometimes ta= lk about
>> > =E2=80=9Cimplementing=E2=80=9D a system.
>> >
>> > So my point was that I assume for purposes of interoperabilit= y that a
>> > general purpose client or server would allow the port to be c= hanged in the
>> > field.
>> >
>> >>
>> >>>
>> >>>>> -4, first paragraph: What is the expected beh= avior from a peers that
>> >>>>> do
>> >>>>> not support this spec when they receive a TCP= stream with the magic
>> >>>>> number on a port for some other protocol?
>> >>>>
>> >>>>
>> >>>> Maybe listing assumptions up front in the draft w= ould help _IF_ the
>> >>>> assumption is that the listening server is a VPN = concentrator that
>> >>>> wouldn't be listening for other services.
>> >>>
>> >>>
>> >>> Support for TCP would be based on preconfiguration, s= o the client
>> >>> knows
>> >>> this out-of-band. It cannot be discovered during nego= tiation, because
>> >>> it is assumed the regular UDP ports are blocked, whic= h is the only
>> >>> reason to attempt TCP to begin with.
>> >>
>> >> I read the draft with this assumption in mind (see above)= , but this
>> >> should be clarified in the document to address this quest= ion from Ben.
>> >
>> > Imagine a misconfigured client opening a connection to an web= server on
>> > port 80, expecting to find a VPN service. What happens? I thi= nk that a
>> > consequence of the design approach to allow this to run over = ports assigned
>> > to other protocols is that you need to consider that sort of = thing.
>> >
>> >>>
>> >>>>> - Appendix A: Doesn't the use of the NULL= cipher invalidate one of
>> >>>>> the
>> >>>>> primary reasons to use TLS? (Namely to obscur= e the fact that this is
>> >>>>> not
>> >>>>> HTTP, or whatever other protocol is assigned = to the port?)
>> >>>>
>> >>>>
>> >>>> Editors/AD correct me if I am wrong, but...
>> >>>> No, if TLS is used with a NULL cipher, it'll = pass inspection of a
>> >>>> middle box validating the protocol.=C2=A0 This do= esn't need to use the
>> >>>> cipher as it's negotiating the IPsec connecti= on.
>> >>>
>> >>>
>> >>> right, TLS happens to use encryption to get out, but = it is not the
>> >>> encryption of the actual IKE/IPsec protocols, which k= eep using their
>> >>> own channel negotiations.
>> >>
>> >> I think clarifying this further in the draft would be hel= pful.
>> >
>> > I agree, because I=E2=80=99m still confused :-)
>> >
>> > To clarify my question: Assuming the case of TLS encapsulatio= n to the
>> > HTTPS port across a DPI middle-box that hates that sort of th= ing. If TLS
>> > uses the NULL cipher, can the middlebox not tell that the pro= tocol over TLS
>> > is not HTTP? (I will defer to the experts.)
>>
>> IPsec WG participants should chime in here, Yoav may know for sure=
>> with his background, I'm sure others too.
>>
>> I'd guess that a DPI would not pick it up as the protocol insp= ection
>> most likely assumes when it sees TLS, that the traffic is encrypte= d
>> and looks no further for inspection/blocking purposes.=C2=A0 The >> middleboxes that do some protocol inspection aren't like the o= nes from
>> 15-20 years ago that dug into the protocol (blocking FTP commands,=
>> etc.).
>>
>> The use of TCP 443 for this has been in place for a decade or two,=
>
>
> Hmm... In most cases people are tunnelling over HTTP, and due to conce= rns
> about cross-protocol attacks, I think that's a good thing. See, fo= r instance
> [0]
>

This draft doesn't make that clear.=C2=A0 If that is the ca= se, then I had
previously asked somewhere in this thread if they could just specify
that so the proper use of 443 would be in place - ending the
discussion.

Sorry, bad writing on my pa= rt. I think they're not doing that here, so we
should at leas= t ask if that's a problem (though the answer may well be
&quo= t;no")

-Ekr


>
>> Google QUIC also uses TCP 443, and I'm sure other services do = too. So
>> tunneling does work.
>
>
> Hmm... Not to my knowledge.=C2=A0 QUIC is UDP over 443 I believe that = in cases
> where UDP doesn't work, Chrome falls back to HTTP/TLS/TCP. Do you = have
> a pointer?

No, it was sent to me in thread by a WG participant... so discard fo= r now.
>
> -Ekr
>
>
> [0]
> http://www.adambarth.= com/papers/2011/huang-chen-barth-rescorla-jackson.pdf
>
>
>> >
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>



--

Best regards,
Kathleen

--f403045da3586bc563054e1394bf-- From nobody Wed Apr 26 08:35:44 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE291300E8; Wed, 26 Apr 2017 08:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QjlBh6ZQtnvZ; Wed, 26 Apr 2017 08:35:41 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BFEDC12FC17; Wed, 26 Apr 2017 08:35:41 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QFZe6U049989 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 10:35:41 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 26 Apr 2017 10:35:40 -0500 Cc: Paul Wouters , "ipsec@ietf.org" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , Tero Kivinen Content-Transfer-Encoding: quoted-printable Message-Id: <166762EE-0C66-4CB9-AB08-0FD8E15253B6@nostrum.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> To: Kathleen Moriarty X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:35:44 -0000 By the way, the DISCUSS vs COMMENT framing has gotten lost from the = thread. Only the first point was part of the DISCUSS, the rest are = non-binding comments. And I think the DISCUSS point is moving in the = right direction, pending a text proposal. Thanks! Ben. > On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty = wrote: >=20 > On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell = wrote: >>=20 >>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty = wrote: >>>=20 >>> Thanks for the quick response Paul, a few questions... >>>=20 >>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters = wrote: >>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: >>>>=20 >>>>>> IIUC, the entire point of having the stream prefix is to allow = the TCP >>>>>> responder to demux between this protocol, and some other protocol = that >>>>>> would normally run on that port. Saying it MUST close the TCP = session >>>>>> seems to completely remove that value. I assume people meant to = allow the >>>>>> respondent to delegate a stream out to some other protocol = handler if the >>>>>> prefix is not present? >>>>>>=20 >>>>>=20 >>>>> I believe that this is because there is presumed to be no other >>>>> service operating on the listening port (assuming a VPN = concentrator), >>>>> but that's not explicitly stated either. >>>>=20 >>>>=20 >>>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer = one of >>>> the other kinds of SSL VPNs or as the administration interface or >>>> user interface. >>>=20 >>> OK, sounds like I didn't help here, so the editors should propose = text >>> to address this gap. >>=20 >> I think we are on the right track here, pending proposed text. >>=20 >>>=20 >>>>=20 >>>>>> -- 2nd to last paragraph: "This document leaves the selection of = TCP >>>>>> ports up to implementations." >>>>>> I suspect "configurable local policy" would make more sense. = Leaving it >>>>>> up to "implementations" leaves open the chance of different >>>>>> implementations making non-intersecting port choices, which = doesn't help >>>>>> interoperability. >>>>>=20 >>>>>=20 >>>>> This may go more into unexplained assumptions... the clients >>>>> authorized to connect to the server would need to know the correct >>>>> port to establish a session and would be given that information >>>>> specific to the implementation. With this assumption, the above >>>>> should be fine... but editors/AD/WG, please correct me if I am = wrong. >>>>=20 >>>>=20 >>>> I am pretty sure what is meant is "configuration" and not = "implementation". >>>=20 >>> Is that in response to me being wrong in my assumption or the draft >>> should say configuration (I think it's the latter, but important to >>> check)? >>=20 >> We are probably splitting hairs on the meaning of = =E2=80=9Cimplementation=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. = (and maybe =E2=80=9Cdeployment=E2=80=9D). I was thinking of = =E2=80=9Cimplementation=E2=80=9D as being what developers do, and = =E2=80=9Cconfiguring/deploying=E2=80=9D as what operators do. But I am = aware that operators sometimes talk about =E2=80=9Cimplementing=E2=80=9D = a system. >>=20 >> So my point was that I assume for purposes of interoperability that a = general purpose client or server would allow the port to be changed in = the field. >>=20 >>>=20 >>>>=20 >>>>>> -4, first paragraph: What is the expected behavior from a peers = that do >>>>>> not support this spec when they receive a TCP stream with the = magic >>>>>> number on a port for some other protocol? >>>>>=20 >>>>>=20 >>>>> Maybe listing assumptions up front in the draft would help _IF_ = the >>>>> assumption is that the listening server is a VPN concentrator that >>>>> wouldn't be listening for other services. >>>>=20 >>>>=20 >>>> Support for TCP would be based on preconfiguration, so the client = knows >>>> this out-of-band. It cannot be discovered during negotiation, = because >>>> it is assumed the regular UDP ports are blocked, which is the only >>>> reason to attempt TCP to begin with. >>>=20 >>> I read the draft with this assumption in mind (see above), but this >>> should be clarified in the document to address this question from = Ben. >>=20 >> Imagine a misconfigured client opening a connection to an web server = on port 80, expecting to find a VPN service. What happens? I think that = a consequence of the design approach to allow this to run over ports = assigned to other protocols is that you need to consider that sort of = thing. >>=20 >>>>=20 >>>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one = of the >>>>>> primary reasons to use TLS? (Namely to obscure the fact that this = is not >>>>>> HTTP, or whatever other protocol is assigned to the port?) >>>>>=20 >>>>>=20 >>>>> Editors/AD correct me if I am wrong, but... >>>>> No, if TLS is used with a NULL cipher, it'll pass inspection of a >>>>> middle box validating the protocol. This doesn't need to use the >>>>> cipher as it's negotiating the IPsec connection. >>>>=20 >>>>=20 >>>> right, TLS happens to use encryption to get out, but it is not the >>>> encryption of the actual IKE/IPsec protocols, which keep using = their >>>> own channel negotiations. >>>=20 >>> I think clarifying this further in the draft would be helpful. >>=20 >> I agree, because I=E2=80=99m still confused :-) >>=20 >> To clarify my question: Assuming the case of TLS encapsulation to the = HTTPS port across a DPI middle-box that hates that sort of thing. If TLS = uses the NULL cipher, can the middlebox not tell that the protocol over = TLS is not HTTP? (I will defer to the experts.) >=20 > IPsec WG participants should chime in here, Yoav may know for sure > with his background, I'm sure others too. >=20 > I'd guess that a DPI would not pick it up as the protocol inspection > most likely assumes when it sees TLS, that the traffic is encrypted > and looks no further for inspection/blocking purposes. The > middleboxes that do some protocol inspection aren't like the ones from > 15-20 years ago that dug into the protocol (blocking FTP commands, > etc.). >=20 > The use of TCP 443 for this has been in place for a decade or two, > Google QUIC also uses TCP 443, and I'm sure other services do too. So > tunneling does work. >=20 > For purity, are we worried if this is TLS or HTTP/TLS (as the port > usage specifies) or does that matter? >=20 >>=20 >>=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen From nobody Wed Apr 26 08:56:30 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E586128959; Wed, 26 Apr 2017 08:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UFO0ngafCaaq; Wed, 26 Apr 2017 08:56:06 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5554013147E; Wed, 26 Apr 2017 08:55:53 -0700 (PDT) Received: from dooku.sandelman.ca (otwaon0812w-lp140-01-64-229-175-123.dsl.bell.ca [64.229.175.123]) by relay.sandelman.ca (Postfix) with ESMTPS id 2A86C1F8EE; Wed, 26 Apr 2017 15:55:52 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 3A45E598; Wed, 26 Apr 2017 11:55:51 -0400 (EDT) From: Michael Richardson To: Paul Wouters cc: Kathleen Moriarty , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , kivinen@iki.fi In-reply-to: References: <149315373484.4283.11097377000445683422.idtracker@ietfa.amsl.com> Comments: In-reply-to Paul Wouters message dated "Tue, 25 Apr 2017 22:10:37 -0400." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 26 Apr 2017 11:55:51 -0400 Message-ID: <5539.1493222151@dooku.sandelman.ca> Archived-At: Subject: Re: [IPsec] Kathleen Moriarty's Yes on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 15:56:15 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > Could the ADs come up with the weasel words they and Joe Touch would > find acceptable? I don't get the idea there is agreement there. +1. Paul speaks sense here. "What do we want!" "Secure connectivity now!" "When do we want it?" "Before IPv10 is deployed!" -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJZAMMHAAoJEJVM4Vb9/EKQmDQIAKIBsR7j0lj/6XpgSSevEU0N aaDdO5J/MbeXsPOyi5hb0NzSdCo2HkwhaZiUiupce4fXto3z2zIqo4ezsmm1LY6i tuo9Ldr4ZLrmRsfeMwjKoMb+RuAx3zY7q22JE5cf4uphWjiXh/e/APipDd96Kkb5 HIFkMtqIeduMxkJptJ3k0ShuRaOUiC00RTa/eQBYjz0sUh32QzFEq64YIqTH1EGy txbu9bdpFsBNRwhHC68IaKZ6v/yPdQzdmQMMtVcSWPHBhjk1SdBKdDca1WPRhdI3 p4XO2DS5m3q3B8EKIIsfZw5QI643VhuMQLqPznHTvW8b7qXuh5c44sxPmUDBkx4= =RrKG -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 26 10:50:29 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C92413155B for ; Wed, 26 Apr 2017 10:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsgAS0wyxmJi for ; Wed, 26 Apr 2017 10:50:26 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B22131529 for ; Wed, 26 Apr 2017 10:50:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493229026; 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=aqESiEawZYJg1NbWJOTz1uU/lIojqBTL7+p30C0ep0w=; b=L8qqq6zr0QEfmpVhgMkYjrxamzyJdgeccmO31n/MldS4QPpKaI1Yrj25n/EV2HlH E/R8FpK+5/XYbaM+HwxCCN6X7o7mV32uLsqpPP+1ELQ9Ejdgs5W4NDAawVFvhsjt OsJe629SHy1/OKLO2CGKnuzvFu09zeOWivsQU++Rt0RLg4ojRSambQKyvKl8oCgf hZuZGZH8MSjWMoiE01PKT4pFgcMUR89uMUyy6g9pKSIH+Vf9fp4bqvYn7Q2O7s3v O325XX4PxMbZKQIA/ax/F+YY4RojAdU9GanLFwXu5G5q2z9pzzLzKhaVegP6ZdPs LEErdOgYDIK0jIygpzkbTQ==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id B0.11.08351.2EDD0095; Wed, 26 Apr 2017 10:50:26 -0700 (PDT) X-AuditID: 11973e16-efb529a00000209f-dd-5900dde29cc1 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay7.apple.com (Apple SCV relay) with SMTP id F2.89.18088.1EDD0095; Wed, 26 Apr 2017 10:50:26 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_/fLRnKko+CaMApE9N6BuXA)" Received: from [17.153.87.234] (unknown [17.153.87.234]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OP100DOG2W1O960@nwk-mmpp-sz09.apple.com>; Wed, 26 Apr 2017 10:50:25 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <380A837C-3062-444A-B76F-430785AB3CD0@apple.com> Date: Wed, 26 Apr 2017 10:50:23 -0700 In-reply-to: <166762EE-0C66-4CB9-AB08-0FD8E15253B6@nostrum.com> Cc: Kathleen Moriarty , Paul Wouters , "ipsec@ietf.org" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , Tero Kivinen To: Ben Campbell References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> <166762EE-0C66-4CB9-AB08-0FD8E15253B6@nostrum.com> X-Mailer: Apple Mail (2.3424) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42IRbChM1X10lyHSYPN1MYv5nafZLd7/OcNo MePPRGaL/VtesFnMnPOBxaJhZ77F0fPP2Sze37rE5MDhsXPWXXaPJUt+Mnkc/rqQxeP7PCaP WTufsASwRnHZpKTmZJalFunbJXBlTFgyjbXg8XzGioun5zI3MP5uZexi5OSQEDCReHzxI3MX IxeHkMAaJonbmx7BJY7MuMcIkTjIKHFl/RY2kASvgKDEj8n3WEBsZoEwiZfNu9ghiiYySVyc MY2pi5GDQ1hAQmLznkSQGjYBFYnj3zYwQ/TaSBxuvQVVkiux6G0QSJhFQFVi/bUVrCA2p4C9 xIuO+WwgI5kFfjFKTLh/mQkkISKgJPG8eSsLxK5jzBK/nu9kgbhUVmLCus1gL0gI3GeTmHil kWUCo9AsJMfOQnLsLKDlzALqElOm5EKEtSWevLvACmGrSSz8vYgJWXwBI9sqRqHcxMwc3cw8 c73EgoKcVL3k/NxNjKA4m24ntoPx4SqrQ4wCHIxKPLwOGxkihVgTy4orcw8xSnOwKInzKu34 HyEkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBsWZ32cbS2m+pKnHtx5WDbnhHCYYxWmu67vTn eibKHN7Bc4fv+1yLB34BnsGWxetnb2OefzToyY3eDzLPEjTqjuUlL/gp6s8buznK2/H58v8d cl/8mjSEYxe1sDzQz9NLbd+zbOG+tCNFnVXuTywY5BbumB4QUshqd2pydptNoZ3u7AvL3CKV WIozEg21mIuKEwG8nlfJlAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCLMWRmVeSWpSXmKPExsUi2FAcoPvoLkOkwZYFHBbzO0+zW7z/c4bR YsaficwW+7e8YLOYOecDi0XDznyLo+efs1m8v3WJyYHDY+esu+weS5b8ZPI4/HUhi8f3eUwe s3Y+YQlgjeKySUnNySxLLdK3S+DKmLBkGmvB4/mMFRdPz2VuYPzdytjFyMkhIWAicWTGPSCb i0NI4CCjxJX1W9hAErwCghI/Jt9jAbGZBcIkXjbvYocomsgkcXHGNKYuRg4OYQEJic17EkFq 2ARUJI5/28AM0Wsjcbj1FlRJrsSit0EgYRYBVYn111awgticAvYSLzrms4GMZBb4xSgx4f5l JpCEiICSxPPmrSwQu44xS/x6vpMF4lJZiQnrNjNPYOSfheS+WUjumwW0j1lAXWLKlFyIsLbE k3cXWCFsNYmFvxcxIYsvYGRbxShQlJqTWGmul1hQkJOql5yfu4kRHBeFqTsYG5dbHWIU4GBU 4uF12MgQKcSaWFZcmXuIUYKDWUmE1/UIUIg3JbGyKrUoP76oNCe1+BCjNAeLkjhv7sn/EUIC 6YklqdmpqQWpRTBZJg5OqQZGw3Pcu9QcDSO/Me3p+9jKO9/B0irKYG+ICaPS3SJmFkeJwhnp q78ujdZabn00QkX4vKAY+/zO/6JCHP/f3nnFaZvzO5onfCp704GswrB9L1b2H+dcnMpyeE7h gm+Xv0tub84WuRRklXV/j5XigfXPhNMPeqxe8/XkTNuNhzea+C0vyg/zK3BVYinOSDTUYi4q TgQAO4l1AYcCAAA= Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:50:28 -0000 --Boundary_(ID_/fLRnKko+CaMApE9N6BuXA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Ben, Thanks for the comments! Your point about the line in Section 6 not = making sense is definitely a good point. How about this text (changes in = bold): If a TCP connection is being used to resume a previous IKE session, the TCP Responder can recognize the session using either the IKE SPI from an encapsulated IKE message or the ESP SPI from an encapsulated ESP message. If the session had been fully established previously, it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES message if MOBIKE is supported, or an INFORMATIONAL message (a keepalive) otherwise. [The TCP Responder MUST NOT accept any = messages for the existing IKE session on new an incoming connection unless = that connection begins with the stream prefix. If either the TCP Originator or TCP = Responder cannot parse valid IKE or ESP messages on a TCP encapsulation = connection that was started with a valid stream prefix, it MUST close the TCP = connection.] =20 If there is instead a syntax issue within an IKE message, an implementation MUST send the INVALID_SYNTAX notify payload and tear down the IKE SA as usual, rather than tearing down the TCP connection directly. Thanks, Tommy > On Apr 26, 2017, at 8:35 AM, Ben Campbell wrote: >=20 > By the way, the DISCUSS vs COMMENT framing has gotten lost from the = thread. Only the first point was part of the DISCUSS, the rest are = non-binding comments. And I think the DISCUSS point is moving in the = right direction, pending a text proposal. >=20 > Thanks! >=20 > Ben. >=20 >> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty = wrote: >>=20 >> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell = wrote: >>>=20 >>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty = wrote: >>>>=20 >>>> Thanks for the quick response Paul, a few questions... >>>>=20 >>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters = wrote: >>>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: >>>>>=20 >>>>>>> IIUC, the entire point of having the stream prefix is to allow = the TCP >>>>>>> responder to demux between this protocol, and some other = protocol that >>>>>>> would normally run on that port. Saying it MUST close the TCP = session >>>>>>> seems to completely remove that value. I assume people meant to = allow the >>>>>>> respondent to delegate a stream out to some other protocol = handler if the >>>>>>> prefix is not present? >>>>>>>=20 >>>>>>=20 >>>>>> I believe that this is because there is presumed to be no other >>>>>> service operating on the listening port (assuming a VPN = concentrator), >>>>>> but that's not explicitly stated either. >>>>>=20 >>>>>=20 >>>>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer = one of >>>>> the other kinds of SSL VPNs or as the administration interface or >>>>> user interface. >>>>=20 >>>> OK, sounds like I didn't help here, so the editors should propose = text >>>> to address this gap. >>>=20 >>> I think we are on the right track here, pending proposed text. >>>=20 >>>>=20 >>>>>=20 >>>>>>> -- 2nd to last paragraph: "This document leaves the selection of = TCP >>>>>>> ports up to implementations." >>>>>>> I suspect "configurable local policy" would make more sense. = Leaving it >>>>>>> up to "implementations" leaves open the chance of different >>>>>>> implementations making non-intersecting port choices, which = doesn't help >>>>>>> interoperability. >>>>>>=20 >>>>>>=20 >>>>>> This may go more into unexplained assumptions... the clients >>>>>> authorized to connect to the server would need to know the = correct >>>>>> port to establish a session and would be given that information >>>>>> specific to the implementation. With this assumption, the above >>>>>> should be fine... but editors/AD/WG, please correct me if I am = wrong. >>>>>=20 >>>>>=20 >>>>> I am pretty sure what is meant is "configuration" and not = "implementation". >>>>=20 >>>> Is that in response to me being wrong in my assumption or the draft >>>> should say configuration (I think it's the latter, but important to >>>> check)? >>>=20 >>> We are probably splitting hairs on the meaning of = =E2=80=9Cimplementation=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. = (and maybe =E2=80=9Cdeployment=E2=80=9D). I was thinking of = =E2=80=9Cimplementation=E2=80=9D as being what developers do, and = =E2=80=9Cconfiguring/deploying=E2=80=9D as what operators do. But I am = aware that operators sometimes talk about =E2=80=9Cimplementing=E2=80=9D = a system. >>>=20 >>> So my point was that I assume for purposes of interoperability that = a general purpose client or server would allow the port to be changed in = the field. >>>=20 >>>>=20 >>>>>=20 >>>>>>> -4, first paragraph: What is the expected behavior from a peers = that do >>>>>>> not support this spec when they receive a TCP stream with the = magic >>>>>>> number on a port for some other protocol? >>>>>>=20 >>>>>>=20 >>>>>> Maybe listing assumptions up front in the draft would help _IF_ = the >>>>>> assumption is that the listening server is a VPN concentrator = that >>>>>> wouldn't be listening for other services. >>>>>=20 >>>>>=20 >>>>> Support for TCP would be based on preconfiguration, so the client = knows >>>>> this out-of-band. It cannot be discovered during negotiation, = because >>>>> it is assumed the regular UDP ports are blocked, which is the only >>>>> reason to attempt TCP to begin with. >>>>=20 >>>> I read the draft with this assumption in mind (see above), but this >>>> should be clarified in the document to address this question from = Ben. >>>=20 >>> Imagine a misconfigured client opening a connection to an web server = on port 80, expecting to find a VPN service. What happens? I think that = a consequence of the design approach to allow this to run over ports = assigned to other protocols is that you need to consider that sort of = thing. >>>=20 >>>>>=20 >>>>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one = of the >>>>>>> primary reasons to use TLS? (Namely to obscure the fact that = this is not >>>>>>> HTTP, or whatever other protocol is assigned to the port?) >>>>>>=20 >>>>>>=20 >>>>>> Editors/AD correct me if I am wrong, but... >>>>>> No, if TLS is used with a NULL cipher, it'll pass inspection of a >>>>>> middle box validating the protocol. This doesn't need to use the >>>>>> cipher as it's negotiating the IPsec connection. >>>>>=20 >>>>>=20 >>>>> right, TLS happens to use encryption to get out, but it is not the >>>>> encryption of the actual IKE/IPsec protocols, which keep using = their >>>>> own channel negotiations. >>>>=20 >>>> I think clarifying this further in the draft would be helpful. >>>=20 >>> I agree, because I=E2=80=99m still confused :-) >>>=20 >>> To clarify my question: Assuming the case of TLS encapsulation to = the HTTPS port across a DPI middle-box that hates that sort of thing. If = TLS uses the NULL cipher, can the middlebox not tell that the protocol = over TLS is not HTTP? (I will defer to the experts.) >>=20 >> IPsec WG participants should chime in here, Yoav may know for sure >> with his background, I'm sure others too. >>=20 >> I'd guess that a DPI would not pick it up as the protocol inspection >> most likely assumes when it sees TLS, that the traffic is encrypted >> and looks no further for inspection/blocking purposes. The >> middleboxes that do some protocol inspection aren't like the ones = from >> 15-20 years ago that dug into the protocol (blocking FTP commands, >> etc.). >>=20 >> The use of TCP 443 for this has been in place for a decade or two, >> Google QUIC also uses TCP 443, and I'm sure other services do too. So >> tunneling does work. >>=20 >> For purity, are we worried if this is TLS or HTTP/TLS (as the port >> usage specifies) or does that matter? >>=20 >>>=20 >>>=20 >>=20 >>=20 >>=20 >> --=20 >>=20 >> Best regards, >> Kathleen >=20 --Boundary_(ID_/fLRnKko+CaMApE9N6BuXA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Ben,

Thanks for the = comments! Your point about the line in Section 6 not making sense is = definitely a good point. How about this text (changes in = bold):

If a TCP connection is being used to resume a previous IKE = session,
   the TCP Responder can = recognize the session using either the IKE SPI
 =  from an encapsulated IKE message or the ESP SPI from an = encapsulated
   ESP message.  If the = session had been fully established previously,
 =  it is suggested that the TCP Originator send an = UPDATE_SA_ADDRESSES
   message if MOBIKE = is supported, or an INFORMATIONAL message (a
  =  keepalive) otherwise.  [The TCP Responder MUST = NOT accept any messages
  =  for the existing IKE session on new an incoming connection unless = that connection
  =  begins with the stream prefix. If either the TCP Originator or TCP = Responder
   cannot = parse valid IKE or ESP messages on a TCP encapsulation connection
   that was started with a valid stream prefix, it = MUST close the TCP connection.]  
  =  If there is instead a syntax issue within an IKE
   message, an implementation MUST send the = INVALID_SYNTAX notify
   payload and tear = down the IKE SA as usual, rather than tearing down
   the TCP connection directly.

Thanks,
Tommy

On Apr 26, 2017, at 8:35 AM, = Ben Campbell <ben@nostrum.com> wrote:

By = the way, the DISCUSS vs COMMENT framing has gotten lost from the thread. = Only the first point was part of the DISCUSS, the rest are non-binding = comments. And I think the DISCUSS point is moving in the right = direction, pending a text proposal.

Thanks!

Ben.

On Apr 26, 2017, at 8:57 = AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell = <ben@nostrum.com> = wrote:

On Apr 25, 2017, at 9:38 = PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Thanks for the quick response Paul, a few = questions...

On Tue, Apr 25, 2017 at 10:18 = PM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 25 Apr 2017, Kathleen Moriarty = wrote:

IIUC, the entire point = of having the stream prefix is to allow the TCP
responder = to demux between this protocol, and some other protocol that
would normally run on that port. Saying it MUST close the TCP = session
seems to completely remove that value. I assume = people meant to allow the
respondent to delegate a stream = out to some other protocol handler if the
prefix is not = present?


I = believe that this is because there is presumed to be no other
service operating on the listening port (assuming a VPN = concentrator),
but that's not explicitly stated either.


Vendors tend to = run TLS on the IKE/IPsec machine, either to offer one of
the= other kinds of SSL VPNs or as the administration interface or
user interface.

OK, = sounds like I didn't help here, so the editors should propose text
to address this gap.

I think we are on the right track here, pending proposed = text.



-- 2nd to last paragraph: "This document leaves the selection = of TCP
ports up to implementations."
I = suspect "configurable local policy" would make more sense. Leaving it
up to "implementations" leaves open the chance of = different
implementations making non-intersecting port = choices, which doesn't help
interoperability.


This may go more = into unexplained assumptions... the clients
authorized to = connect to the server would need to know the correct
port = to establish a session and would be given that information
specific to the implementation.  With this assumption, = the above
should be fine... but editors/AD/WG, please = correct me if I am wrong.


I am pretty sure what is meant is "configuration" and not = "implementation".

Is that in = response to me being wrong in my assumption or the draft
should say configuration (I think it's the latter, but = important to
check)?

We are probably splitting hairs on the meaning of = =E2=80=9Cimplementation=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. = (and maybe =E2=80=9Cdeployment=E2=80=9D). I was thinking of = =E2=80=9Cimplementation=E2=80=9D as being what developers do, and = =E2=80=9Cconfiguring/deploying=E2=80=9D as what operators do. But I am = aware that operators sometimes talk about =E2=80=9Cimplementing=E2=80=9D = a system.

So my point was that I assume for = purposes of interoperability that a general purpose client or server = would allow the port to be changed in the field.



-4, first paragraph: = What is the expected behavior from a peers that do
not = support this spec when they receive a TCP stream with the magic
number on a port for some other protocol?


Maybe listing = assumptions up front in the draft would help _IF_ the
assumption is that the listening server is a VPN concentrator = that
wouldn't be listening for other services.


Support for TCP = would be based on preconfiguration, so the client knows
this= out-of-band. It cannot be discovered during negotiation, because
it is assumed the regular UDP ports are blocked, which is the = only
reason to attempt TCP to begin with.

I read the draft with this = assumption in mind (see above), but this
should be = clarified in the document to address this question from Ben.

Imagine a misconfigured client = opening a connection to an web server on port 80, expecting to find a = VPN service. What happens? I think that a consequence of the design = approach to allow this to run over ports assigned to other protocols is = that you need to consider that sort of thing.


- Appendix A: Doesn't the use of the NULL = cipher invalidate one of the
primary reasons to use TLS? = (Namely to obscure the fact that this is not
HTTP, or = whatever other protocol is assigned to the port?)


Editors/AD correct = me if I am wrong, but...
No, if TLS is used with a NULL = cipher, it'll pass inspection of a
middle box validating = the protocol.  This doesn't need to use the
cipher as = it's negotiating the IPsec connection.


right, TLS happens to use encryption to get = out, but it is not the
encryption of the actual IKE/IPsec = protocols, which keep using their
own channel = negotiations.

I think = clarifying this further in the draft would be helpful.

I agree, because I=E2=80=99m = still confused :-)

To clarify my question: = Assuming the case of TLS encapsulation to the HTTPS port across a DPI = middle-box that hates that sort of thing. If TLS uses the NULL cipher, = can the middlebox not tell that the protocol over TLS is not HTTP? (I = will defer to the experts.)

IPsec WG participants should chime in here, Yoav may know for = sure
with his background, I'm sure others too.

I'd guess that a DPI would not pick it up as = the protocol inspection
most likely assumes when it sees = TLS, that the traffic is encrypted
and looks no further = for inspection/blocking purposes.  The
middleboxes = that do some protocol inspection aren't like the ones from
15-20 years ago that dug into the protocol (blocking FTP = commands,
etc.).

The use of = TCP 443 for this has been in place for a decade or two,
Google QUIC also uses TCP 443, and I'm sure other services do = too. So
tunneling does work.

For purity, are we worried if this is TLS or HTTP/TLS (as the = port
usage specifies) or does that matter?





-- =

Best regards,
Kathleen


= --Boundary_(ID_/fLRnKko+CaMApE9N6BuXA)-- From nobody Wed Apr 26 10:59:42 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38451131525; Wed, 26 Apr 2017 10:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VYV8bhSxWNo6; Wed, 26 Apr 2017 10:59:39 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0A7F2129577; Wed, 26 Apr 2017 10:59:39 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3QHx7Ou029354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Apr 2017 10:59:08 -0700 (PDT) To: Tommy Pauly Cc: Yoav Nir , "ipsec@ietf.org WG" , Paul Wouters , draft-ietf-ipsecme-tcp-encaps@ietf.org References: <5B8CCE6E-B6DA-423B-A145-6C207B0E1C0F@gmail.com> <4888D3A6-FAC0-4DCC-AC6B-BFDFE813FCAB@apple.com> From: Joe Touch Message-ID: Date: Wed, 26 Apr 2017 10:59:07 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <4888D3A6-FAC0-4DCC-AC6B-BFDFE813FCAB@apple.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:59:40 -0000 Hi, Tommy, On 4/25/2017 8:34 PM, Tommy Pauly wrote: > I suggest that we can: > > - Clarify the text in section 2 (configuration) to say that the > default port is TCP 4500, and that implementations may communicate > other port options out of band as configuration. This is done for UDP > as well. This is the "explicit" indication of the ports you mention above. > - Port 443 is only mentioned in the figures for the appendix. We can > remove the mention of the port there. That will work. > As for the Stream Prefix of "IKETCP", I believe that we have good > reasons to keep it even if we are only using the protocol on port 4500 > (as would be the recommended/sanctioned) method. That is your decision, but IMO it is important that this ONLY helps check that you connect to a port running your service based on other information (e.g., port 4500 or port as indicated out of band). The key issue is that this doc should never claim that this text is intended to help you run this service *concurrently* with any other service on the same port. That's hijacking - because any existing service can define that string to mean whatever it wants (regardless of whether they do that now or not). > TCP port 4500 has been technically allocated to IPsec NAT Traversal > (which TCP encapsulation is) for a long while without a specific > protocol being defined. The concern that brought about the stream > prefix was to let VPN endpoints that may be running older non-standard > protocols to recognize TCP encapsulation in case they were already > squatting on the port (4500), or have configured TCP encapsulation to > run on a port they are using for their own custom VPN protocol. > > How does that sound? As a confirmation check, yes. Again, NOT to demux with legacy services. Joe From nobody Wed Apr 26 11:01:46 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E81FC13155D; Wed, 26 Apr 2017 11:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MVipdSyHKHp; Wed, 26 Apr 2017 11:01:43 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 D8AD0129577; Wed, 26 Apr 2017 11:01:43 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3QI185i029825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Apr 2017 11:01:09 -0700 (PDT) To: Yoav Nir Cc: Paul Wouters , "ipsec@ietf.org WG" , draft-ietf-ipsecme-tcp-encaps@ietf.org References: <5B8CCE6E-B6DA-423B-A145-6C207B0E1C0F@gmail.com> <10726000-4D7E-41C6-ACFB-8E9D0D51DB66@gmail.com> From: Joe Touch Message-ID: <0f2b8dad-b8a0-3c69-979d-a0ba215d9872@isi.edu> Date: Wed, 26 Apr 2017 11:01:08 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <10726000-4D7E-41C6-ACFB-8E9D0D51DB66@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [IPsec] regarding draft-ietf-ipsecme-tcp-encaps X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:01:45 -0000 On 4/25/2017 8:46 PM, Yoav Nir wrote: > ... >>> While it is the default port for HTTPS, that protocol can run on any >>> port depending on the value in origin (RFC 6454). >> >> Yes, any protocol can run on any port number (as per above), as long >> as the endpoints agree. But that's not what you're talking about here >> - you're saying that if you get "IKETCP" on a port, then you can >> trust that it is your service. >> >> That's incorrect. You don't get to define the string "IKETCP" for >> other services. > > That I totally agree with. The purpose of the IKETCP magic string is > to demultiplex between TCP connections implementing this draft and > other TCP connections using the same port for other services, > regardless of whether those other services are defined in IANA or > other squatters. Actually, this is the opposite of what is valid. Let me be clear - you can define that string to mean whatever you want WITHIN YOUR SERVICE. You CANNOT define that string as having a meaning when a port is used for other services. You cannot change other services without updating their specs (and without their permission). > I think the text in section 4 already says so, but perhaps it can be > clarified. IMO, that section needs substantial revision and must not say - or imply - what it currently says. Joe From nobody Wed Apr 26 11:07:11 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FBD113156B; Wed, 26 Apr 2017 11:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycQIKNLd93Tj; Wed, 26 Apr 2017 11:07:07 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 0271713152C; Wed, 26 Apr 2017 11:07:06 -0700 (PDT) Received: from [128.9.184.33] ([128.9.184.33]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v3QI6Ym1000726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 26 Apr 2017 11:06:35 -0700 (PDT) To: Tero Kivinen , Paul Wouters Cc: "ipsec@ietf.org WG" , draft-ietf-ipsecme-tcp-encaps@ietf.org References: <22784.31178.211809.624272@fireball.acr.fi> From: Joe Touch Message-ID: <03af92b2-914a-9f22-4746-6cb652ddcf9c@isi.edu> Date: Wed, 26 Apr 2017 11:06:34 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <22784.31178.211809.624272@fireball.acr.fi> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: Subject: Re: [IPsec] informal ports and transport review of ipsecme-chairs@tools.ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:07:09 -0000 On 4/26/2017 3:43 AM, Tero Kivinen wrote: > Paul Wouters writes: >> ... >> So it should add an Updates: RFC-3947 > Not really. ... (basically points to other more appropriate RFCs to UPDATE) I'll leave it to you and the IESG to determine what RFC this document should be updated to correctly change the definition of port 4500. ;-) > ... > >> It's a little weird. 3947 reserved TCP 4500, but did not specify how >> to actually use TCP at all. It seems it was mostly preventatively >> reserved. > The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500 > and UDP/4500 references from individual user to the RFC3947, so that > IETF will have change control over the ports. I.e., those ports were > allocated before RFC3947 came out, and they were used for several > different non-interoperable versions of the NAT traversals, which then > evolved to the standard version we define in RFC3947. We decided to > reassign both TCP and UDP port 4500 to RFC3947 so it would be clear > for what use they will be used. Also we commonly reserve both TCP and > UDP ports for same number just in case someone defines a way to run > the protocol over other transport protocol in the future... Actually, that was how IANA handled assignments in the past. Currently, if you ask for port number X on UDP, then port number X on all other transports (TCP, DCCP, SCTP) are marked "Reserved". The current assignee (e.g., for X on UDP, here) has first-priority on using that port on other transports, but that assignment typically uses the same name only where the primary difference is framing. IANA now encourages assignees to have different names for different services on different transports, even when sharing the same port number on different (see RFC7605). > ... > > So my proposal is update the IANA port registry for both UDP/4500 and > TCP/4500 as follows: > > Keyword Decimal Description Reference > ------- ------- ----------- --------- > ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFCXXXX] > ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3948], [RFC7296] > > (RFCXXXX being this RFC). Sounds good to me (again, I'll trust this group and the IESG to pick the best references) Joe From nobody Wed Apr 26 11:36:47 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A16B13158B; Wed, 26 Apr 2017 11:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rgdSlDdY31F2; Wed, 26 Apr 2017 11:36:37 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1C110131586; Wed, 26 Apr 2017 11:36:37 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QIaTlX068248 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 13:36:30 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <380A837C-3062-444A-B76F-430785AB3CD0@apple.com> Date: Wed, 26 Apr 2017 13:36:29 -0500 Cc: Kathleen Moriarty , Paul Wouters , "ipsec@ietf.org" , ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , Tero Kivinen Content-Transfer-Encoding: quoted-printable Message-Id: <834CF872-4D53-4B02-A791-4A7C77771D71@nostrum.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> <166762EE-0C66-4CB9-AB08-0FD8E15253B6@nostrum.com> <380A837C-3062-444A-B76F-430785AB3CD0@apple.com> To: Tommy Pauly X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:36:39 -0000 > On Apr 26, 2017, at 12:50 PM, Tommy Pauly wrote: >=20 > Hi Ben, >=20 > Thanks for the comments! Your point about the line in Section 6 not = making sense is definitely a good point. How about this text (changes in = bold): >=20 > If a TCP connection is being used to resume a previous IKE session, > the TCP Responder can recognize the session using either the IKE = SPI > from an encapsulated IKE message or the ESP SPI from an = encapsulated > ESP message. If the session had been fully established previously, > it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES > message if MOBIKE is supported, or an INFORMATIONAL message (a > keepalive) otherwise. [The TCP Responder MUST NOT accept any = messages > for the existing IKE session on new an incoming connection unless = that connection > begins with the stream prefix. If either the TCP Originator or TCP = Responder > cannot parse valid IKE or ESP messages on a TCP encapsulation = connection > that was started with a valid stream prefix, it MUST close the TCP = connection.] =20 > If there is instead a syntax issue within an IKE > message, an implementation MUST send the INVALID_SYNTAX notify > payload and tear down the IKE SA as usual, rather than tearing down > the TCP connection directly. >=20 > Thanks, > Tommy That looks good to me. I will clear, with the assumption this or similar = edits will make it into the draft. Thanks! Ben. >=20 >> On Apr 26, 2017, at 8:35 AM, Ben Campbell wrote: >>=20 >> By the way, the DISCUSS vs COMMENT framing has gotten lost from the = thread. Only the first point was part of the DISCUSS, the rest are = non-binding comments. And I think the DISCUSS point is moving in the = right direction, pending a text proposal. >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty = wrote: >>>=20 >>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell = wrote: >>>>=20 >>>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty = wrote: >>>>>=20 >>>>> Thanks for the quick response Paul, a few questions... >>>>>=20 >>>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters = wrote: >>>>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: >>>>>>=20 >>>>>>>> IIUC, the entire point of having the stream prefix is to allow = the TCP >>>>>>>> responder to demux between this protocol, and some other = protocol that >>>>>>>> would normally run on that port. Saying it MUST close the TCP = session >>>>>>>> seems to completely remove that value. I assume people meant to = allow the >>>>>>>> respondent to delegate a stream out to some other protocol = handler if the >>>>>>>> prefix is not present? >>>>>>>>=20 >>>>>>>=20 >>>>>>> I believe that this is because there is presumed to be no other >>>>>>> service operating on the listening port (assuming a VPN = concentrator), >>>>>>> but that's not explicitly stated either. >>>>>>=20 >>>>>>=20 >>>>>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer = one of >>>>>> the other kinds of SSL VPNs or as the administration interface or >>>>>> user interface. >>>>>=20 >>>>> OK, sounds like I didn't help here, so the editors should propose = text >>>>> to address this gap. >>>>=20 >>>> I think we are on the right track here, pending proposed text. >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>> -- 2nd to last paragraph: "This document leaves the selection = of TCP >>>>>>>> ports up to implementations." >>>>>>>> I suspect "configurable local policy" would make more sense. = Leaving it >>>>>>>> up to "implementations" leaves open the chance of different >>>>>>>> implementations making non-intersecting port choices, which = doesn't help >>>>>>>> interoperability. >>>>>>>=20 >>>>>>>=20 >>>>>>> This may go more into unexplained assumptions... the clients >>>>>>> authorized to connect to the server would need to know the = correct >>>>>>> port to establish a session and would be given that information >>>>>>> specific to the implementation. With this assumption, the above >>>>>>> should be fine... but editors/AD/WG, please correct me if I am = wrong. >>>>>>=20 >>>>>>=20 >>>>>> I am pretty sure what is meant is "configuration" and not = "implementation". >>>>>=20 >>>>> Is that in response to me being wrong in my assumption or the = draft >>>>> should say configuration (I think it's the latter, but important = to >>>>> check)? >>>>=20 >>>> We are probably splitting hairs on the meaning of = =E2=80=9Cimplementation=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. = (and maybe =E2=80=9Cdeployment=E2=80=9D). I was thinking of = =E2=80=9Cimplementation=E2=80=9D as being what developers do, and = =E2=80=9Cconfiguring/deploying=E2=80=9D as what operators do. But I am = aware that operators sometimes talk about =E2=80=9Cimplementing=E2=80=9D = a system. >>>>=20 >>>> So my point was that I assume for purposes of interoperability that = a general purpose client or server would allow the port to be changed in = the field. >>>>=20 >>>>>=20 >>>>>>=20 >>>>>>>> -4, first paragraph: What is the expected behavior from a peers = that do >>>>>>>> not support this spec when they receive a TCP stream with the = magic >>>>>>>> number on a port for some other protocol? >>>>>>>=20 >>>>>>>=20 >>>>>>> Maybe listing assumptions up front in the draft would help _IF_ = the >>>>>>> assumption is that the listening server is a VPN concentrator = that >>>>>>> wouldn't be listening for other services. >>>>>>=20 >>>>>>=20 >>>>>> Support for TCP would be based on preconfiguration, so the client = knows >>>>>> this out-of-band. It cannot be discovered during negotiation, = because >>>>>> it is assumed the regular UDP ports are blocked, which is the = only >>>>>> reason to attempt TCP to begin with. >>>>>=20 >>>>> I read the draft with this assumption in mind (see above), but = this >>>>> should be clarified in the document to address this question from = Ben. >>>>=20 >>>> Imagine a misconfigured client opening a connection to an web = server on port 80, expecting to find a VPN service. What happens? I = think that a consequence of the design approach to allow this to run = over ports assigned to other protocols is that you need to consider that = sort of thing. >>>>=20 >>>>>>=20 >>>>>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one = of the >>>>>>>> primary reasons to use TLS? (Namely to obscure the fact that = this is not >>>>>>>> HTTP, or whatever other protocol is assigned to the port?) >>>>>>>=20 >>>>>>>=20 >>>>>>> Editors/AD correct me if I am wrong, but... >>>>>>> No, if TLS is used with a NULL cipher, it'll pass inspection of = a >>>>>>> middle box validating the protocol. This doesn't need to use = the >>>>>>> cipher as it's negotiating the IPsec connection. >>>>>>=20 >>>>>>=20 >>>>>> right, TLS happens to use encryption to get out, but it is not = the >>>>>> encryption of the actual IKE/IPsec protocols, which keep using = their >>>>>> own channel negotiations. >>>>>=20 >>>>> I think clarifying this further in the draft would be helpful. >>>>=20 >>>> I agree, because I=E2=80=99m still confused :-) >>>>=20 >>>> To clarify my question: Assuming the case of TLS encapsulation to = the HTTPS port across a DPI middle-box that hates that sort of thing. If = TLS uses the NULL cipher, can the middlebox not tell that the protocol = over TLS is not HTTP? (I will defer to the experts.) >>>=20 >>> IPsec WG participants should chime in here, Yoav may know for sure >>> with his background, I'm sure others too. >>>=20 >>> I'd guess that a DPI would not pick it up as the protocol inspection >>> most likely assumes when it sees TLS, that the traffic is encrypted >>> and looks no further for inspection/blocking purposes. The >>> middleboxes that do some protocol inspection aren't like the ones = from >>> 15-20 years ago that dug into the protocol (blocking FTP commands, >>> etc.). >>>=20 >>> The use of TCP 443 for this has been in place for a decade or two, >>> Google QUIC also uses TCP 443, and I'm sure other services do too. = So >>> tunneling does work. >>>=20 >>> For purity, are we worried if this is TLS or HTTP/TLS (as the port >>> usage specifies) or does that matter? >>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> Best regards, >>> Kathleen >>=20 >=20 From nobody Wed Apr 26 11:38:06 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B069131586; Wed, 26 Apr 2017 11:37:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149323187843.2881.11864791218189918574.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 11:37:58 -0700 Archived-At: Subject: [IPsec] Ben Campbell's No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 18:37:59 -0000 Ben Campbell has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Update: Thanks for proposing text to address my DISCUSS point. I've cleared the discuss, with the assumption the proposed edit (or similar) will make it into the draft. Substantive Comments: -2: -- 2nd bullet (and elsewhere) I think this needs a discussion about how those configured ports are likely to be in the assigned range, and the likely impact. (I recognize that tunneling over a port assigned to something else is a primary reason for doing this. I'm not arguing against it; I just think the implications warrant discussion.) -- 2nd to last paragraph: "This document leaves the selection of TCP ports up to implementations." I suspect "configurable local policy" would make more sense. Leaving it up to "implementations" leaves open the chance of different implementations making non-intersecting port choices, which doesn't help interoperability. -3, first paragraph: Are people confident there will never, ever be a need to demux protocols other than IKE and ESP? If not, this approach may paint people in a corner in the future. I ask because we made similar choices with DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an issue. See RFC7983 for a discussion. (Note that this would have been a DISCUSS point, but I think it's reasonably likely that there really won't be other protocols here. But I want to make sure people have thought about it.) -4, first paragraph: What is the expected behavior from a peers that do not support this spec when they receive a TCP stream with the magic number on a port for some other protocol? -6: First paragraph: It would be helpful to mention behavior on receipt of a stream without the magic number here. But see the DISCUSS point. -8: "... MUST support dynamically enabling and disabling TCP encapsulation..." seems unreasonably strong, especially since the requirement to try UDP before TCP is only a SHOULD. Does this contemplate situations where it might be impossible to use TCP on the after a network change? - Appendix A: Doesn't the use of the NULL cipher invalidate one of the primary reasons to use TLS? (Namely to obscure the fact that this is not HTTP, or whatever other protocol is assigned to the port?) Editorial Comments: - Please expand IKE and ESP on first mention in both the abstract and body. -3, 2nd paragraph: s/"may be able"/"is able". -3.2, " The SPI field in the ESP header MUST NOT be a zero value." Is this a new requirement for this draft? That is, does ESP otherwise allow zero value SPIs? If not, please consider dropping the MUST NOT. -5.1: "...SHOULD always attempt negotiate IKE over UDP first" This is stated several times in the draft, more than once with the SHOULD. It's better to avoid redundant 2119 keywords. -6: "... IKE Figure 1 and ESP Figure 2... ": Broken section cross-references. -10, title: Please expand DPD. -12: Several previous sections pointed to section 12 for more information about why one needed to try direct connections or UDP before TCP. But I don't find any specifics on that in this section. - Appendix A: Why is this an appendix? It contains normative text that seems central to certain use cases. I was surprised to see no discussion about using TLS in section 11, where it seemed quite relevant. From nobody Wed Apr 26 12:29:35 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5F11271DF; Wed, 26 Apr 2017 12:29:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149323496621.2911.8840678484200243531.idtracker@ietfa.amsl.com> Date: Wed, 26 Apr 2017 12:29:26 -0700 Archived-At: Subject: [IPsec] Spencer Dawkins' No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:29:26 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Mirja's Discuss, and am happy with the direction that discussing is headed. From nobody Wed Apr 26 12:51:53 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715C61314CD for ; Wed, 26 Apr 2017 12:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMhPvQHwabmp for ; Wed, 26 Apr 2017 12:51:45 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8B87127909 for ; Wed, 26 Apr 2017 12:51:42 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id k11so5796832ywb.1 for ; Wed, 26 Apr 2017 12:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hDivJDFp4R6aHECWR4mHd+QqcZn4kO9q8owKa9yZ2+A=; b=cjabZy5LvEGIrqyj98SNM7DyPXO5JztBYOt8A60orAhvZdeZGSSdZtXs4Yu3rmB0w8 txpLLqBsEHSI98GWd2IQ8S1v/Bf2NHEN34DighD/bUn6KICy0+PRebz/mWqWJ0gkn+DI 4DPDCPdnwNUWf44Ux+tXBRHFbdr/ENXI/z7t5krPzjSUp3OXXwqHuGmuG+Q+YHgBHgW5 tRWOvx5hG5gkYz9gdxKtjHrtF0vUFVrdR5xk34ktqTWBn5wo8Fqsqox4aifcEQ8MJr+w 01qzS3BrJ/vaIKULwx2tbW5uM42r+kNvOmtdtvkxlRxdfDIwb8IOSHcF7WWeRshEzU9r hqXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hDivJDFp4R6aHECWR4mHd+QqcZn4kO9q8owKa9yZ2+A=; b=KBfVNemCSrZZGuPoPXU8A0bV7XBfdl+YPe2EKbo7iZ9z/DDP/+rPNQet9OepMb/Kzv y20vxWYIIBTw1IBSdovz4cdaz9eTQieI0mcjK4eI9EgqZIDkPCyUg6r6T4OiEtgpbhsX cIH/NoUJleUZ8e/ip3pQ8r1xtGl4tdL/VwXgNatVJtXsIpkqr85/RVNhr4XA+QRDfdeu hKR8ylWVYmt4YGp6SgD4Hdx9VdmiNR8e6FXUt09//N0XlRvEIvyA6Y5LVUXWl3/acLZV QvQeYnWCGWKpjcncDF4lDxrRy4BztzVe0PMUUu3c/dYXwYiDWaDyNV1hSxZxOlLnStp/ E77w== X-Gm-Message-State: AN3rC/6wWu9vC8KoRVXleiCniodgHxeZ4d2O1dGqzImX24zeHRSQ43YP JgKunR2bDp+AFsnwnEqy+HhtdG5yEg== X-Received: by 10.13.245.2 with SMTP id e2mr1387578ywf.270.1493236301977; Wed, 26 Apr 2017 12:51:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Wed, 26 Apr 2017 12:51:01 -0700 (PDT) In-Reply-To: <22784.31378.631303.102297@fireball.acr.fi> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <22784.31378.631303.102297@fireball.acr.fi> From: Eric Rescorla Date: Wed, 26 Apr 2017 12:51:01 -0700 Message-ID: To: Tero Kivinen Cc: Tommy Pauly , ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, ipsecme-chairs@ietf.org, Mirja Kuehlewind , The IESG Content-Type: multipart/alternative; boundary=94eb2c08763a589ba0054e172bb0 Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:51:46 -0000 --94eb2c08763a589ba0054e172bb0 Content-Type: text/plain; charset=UTF-8 AFAICT there are two separate issues: - The use of 4500, which, as Tero says, we can just update the registry to point to this document for. - The use of 443, which seems more complicated WRT 443, I would assert the following facts: - It's not awesome that people use 443 (though understandable because of overly-aggressive firewalls) - People aren't going to stop using 443 (because it goes through NATs well) Generally, I think it's more useful for documents to reflect reality, even if we don't like that reality, and 443 only appears in the appendix, so that seems fairly innocuous to me. Perhaps we can leave the 443 in the appendix with some note like: "Note: While port 4500 is the reserved port for this protocol, some existing implementations also use port 443. The Stream Prefix provides some mitigation against cross-protocol attacks in this case, however, the use of port 443 is NOT RECOMMENDED" What would people think about that? Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be wiggle room to specify ALPN here? Or maybe a longer prefix? -Ekr On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen wrote: > Tommy Pauly writes: > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > This draft suggests that ports that are assigned to other services can > > > simply be used. This is not okay. If a port is assigned to a certain > > > service, this service and/or the respective RFC defines how this port > is > > > used. Simply changing the specified behavior by requiring a check for a > > > magic number cannot be done without updating the RFC that the port > > > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as > > > the IANA registry would need to be updated. > > > > At this point, the only portion of the document that mentions a port > > other than 500 and 4500 is the appendix. We recommend that 4500 is > > used as the port for TCP encapsulation. The IANA registry for > > 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947; > > that document does not explain how TCP is to be used, so the > > reference should be updated to point to the document on TCP > > encapsulation. > > I already explained this in long email to the Joe and Paul, but > noticed that those emails did not go to to the IESG, so this is mostly > cut & paste of my previous email. This does not cover anything about > using any other ports, but covers the case about the IANA allocations > for TCP/4500 and UPD/4500. > > ---------------------------------------------------------------------- > Paul Wouters writes: > > On Tue, 25 Apr 2017, Joe Touch wrote: > > > Every bit pattern, including those using magic numbers, is already > > > owned and under the control of each assigned port. It is not > > > appropriate for any new service to hijack that pattern as having a > > > different meaning UNLESS explicitly updating the service on > > > that port. > > > > > > A simple summary of what needs to change, in 2119-language: > > > > > > - this approach MUST NOT be described as applying to any > > > assigned number unless also updating the associated RFC > > > > So it should add an Updates: RFC-3947 > > Not really. It does not update RFC3947 as it does not change the > obsoleted protocol defined in the RFC3947. It does define way to > extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On > the other hand RFC3947 should have been obsoleted when we obsoleted > IKEv1, as that document only defines how to do IKEv1 NAT traversal > negotiation, and the IKEv2 NAT traversal negotation is described in > main IKEv2 RFC (RFC7296). > > > It's a little weird. 3947 reserved TCP 4500, but did not specify how > > to actually use TCP at all. It seems it was mostly preventatively > > reserved. > > The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500 > and UDP/4500 references from individual user to the RFC3947, so that > IETF will have change control over the ports. I.e., those ports were > allocated before RFC3947 came out, and they were used for several > different non-interoperable versions of the NAT traversals, which then > evolved to the standard version we define in RFC3947. We decided to > reassign both TCP and UDP port 4500 to RFC3947 so it would be clear > for what use they will be used. Also we commonly reserve both TCP and > UDP ports for same number just in case someone defines a way to run > the protocol over other transport protocol in the future... > > RFC3947 does not define anything over TCP/4500. Actually RFC3947 does > not define anything over the UDP/4500 either, it is the RFC3948 that > does that. The RFC3947 just says, we use the format defined in the > RFC3948 over the UDP/4500, but is silent about the TCP/4500. > > RFC3947 is efficiently obsoleted, as it only defines the way to do NAT > traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2 > (originally RFC4306, and now RFC7296). So the RFC3947 should have been > marked as obsoleted by RFC4306. I am not sure if we want to do that in > this late. > > So my proposal is update the IANA port registry for both UDP/4500 and > TCP/4500 as follows: > > Keyword Decimal Description Reference > ------- ------- ----------- --------- > ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFCXXXX] > ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3948], [RFC7296] > > (RFCXXXX being this RFC). > > Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the > RFC3948 actually defines the protocol used over the port. RFC3947 > defines the IKEv1 negotiation over the UDP port 500 and 4500, but for > IKEv2 this is already defined in the RFC7296. > > The RFC3947 could either be left as it is now, or marked as being > obsoleted by this or RFC4306, or RFC7296 or whatever. Updating > document which is effectively already obsoleted, is just wrong... > -- > kivinen@iki.fi > > --94eb2c08763a589ba0054e172bb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
AFAICT there are two separate issues:

<= /div>
- The use of 4500, which, as Tero says, we can just update the re= gistry to point to this document for.
- The use of 443, which see= ms more complicated

WRT 443, I would assert the fo= llowing facts:

- It's not awesome that people = use 443 (though understandable because of overly-aggressive firewalls)
- People aren't going to stop using 443 (because it goes through = NATs well)

Generally, I think it's more useful= for documents to reflect reality, even if we don't like that reality,<= /div>
and 443 only appears in the appendix, so that seems fairly innocu= ous to me. Perhaps we can
leave the 443 in the appendix with some= note like:

"Note: While port 4500 is the res= erved port for this protocol, some existing implementations
also = use port 443. The Stream Prefix provides some mitigation against cross-prot= ocol
attacks in this case, however, the use of port 443 is NOT RE= COMMENDED"

What would people think about that= ?

Tommy, Tero, the stream prefix doesn't seem = totally ideal. Would there be wiggle room
to specify ALPN here? O= r maybe a longer prefix?

-Ekr

=

On Wed, Apr= 26, 2017 at 3:46 AM, Tero Kivinen <kivinen@iki.fi> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Tommy Pauly writes:
> > ------------------------------------------------------------= ----------
> > DISCUSS:
> > ------------------------------------------------------------= ----------
> >
> > This draft suggests that ports that are assigned to other service= s can
> > simply be used. This is not okay. If a port is assigned to a cert= ain
> > service, this service and/or the respective RFC defines how this = port is
> > used. Simply changing the specified behavior by requiring a check= for a
> > magic number cannot be done without updating the RFC that the por= t
> > assignment belongs to. Also for the use of 4500/tcp RFC3948 as we= ll as
> > the IANA registry would need to be updated.
>
> At this point, the only portion of the document that mentions a port > other than 500 and 4500 is the appendix. We recommend that 4500 is
> used as the port for TCP encapsulation. The IANA registry for
> 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947;
> that document does not explain how TCP is to be used, so the
> reference should be updated to point to the document on TCP
> encapsulation.

I already explained this in long email to the Joe and Paul, but
noticed that those emails did not go to to the IESG, so this is mostly
cut & paste of my previous email. This does not cover anything about using any other ports, but covers the case about the IANA allocations
for TCP/4500 and UPD/4500.

-----------------------------------------------------------------= -----
Paul Wouters writes:
> On Tue, 25 Apr 2017, Joe Touch wrote:
> > Every bit pattern, including those using magic numbers, is alread= y
> > owned and under the control of each assigned port. It is not
> > appropriate for any new service to hijack that pattern as having = a
> > different meaning UNLESS explicitly updating the service on
> > that port.
> >
> > A simple summary of what needs to change, in 2119-language:
> >
> >=C2=A0 =C2=A0 - this approach MUST NOT be described as applying to= any
> >=C2=A0 =C2=A0 =C2=A0 assigned number unless also updating the asso= ciated RFC
>
> So it should add an Updates: RFC-3947

Not really. It does not update RFC3947 as it does not change the
obsoleted protocol defined in the RFC3947. It does define way to
extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
the other hand RFC3947 should have been obsoleted when we obsoleted
IKEv1, as that document only defines how to do IKEv1 NAT traversal
negotiation, and the IKEv2 NAT traversal negotation is described in
main IKEv2 RFC (RFC7296).

> It's a little weird. 3947 reserved TCP 4500, but did not specify h= ow
> to actually use TCP at all. It seems it was mostly preventatively
> reserved.

The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500
and UDP/4500 references from individual user to the RFC3947, so that
IETF will have change control over the ports. I.e., those ports were
allocated before RFC3947 came out, and they were used for several
different non-interoperable versions of the NAT traversals, which then
evolved to the standard version we define in RFC3947. We decided to
reassign both TCP and UDP port 4500 to RFC3947 so it would be clear
for what use they will be used. Also we commonly reserve both TCP and
UDP ports for same number just in case someone defines a way to run
the protocol over other transport protocol in the future...

RFC3947 does not define anything over TCP/4500. Actually RFC3947 does
not define anything over the UDP/4500 either, it is the RFC3948 that
does that. The RFC3947 just says, we use the format defined in the
RFC3948 over the UDP/4500, but is silent about the TCP/4500.

RFC3947 is efficiently obsoleted, as it only defines the way to do NAT
traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2
(originally RFC4306, and now RFC7296). So the RFC3947 should have been
marked as obsoleted by RFC4306. I am not sure if we want to do that in
this late.

So my proposal is update the IANA port registry for both UDP/4500 and
TCP/4500 as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keyword=C2=A0 =C2=A0 =C2=A0 =C2=A0Decimal= =C2=A0 =C2=A0 Description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reference
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------=C2=A0 =C2=A0 =C2=A0 =C2=A0-------= =C2=A0 =C2=A0 -----------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipsec-nat-t=C2=A0 =C2=A04500/tcp=C2=A0 = =C2=A0IPsec NAT-Traversal=C2=A0 [RFCXXXX]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipsec-nat-t=C2=A0 =C2=A04500/udp=C2=A0 = =C2=A0IPsec NAT-Traversal=C2=A0 [RFC3948], [RFC7296]

(RFCXXXX being this RFC).

Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the
RFC3948 actually defines the protocol used over the port. RFC3947
defines the IKEv1 negotiation over the UDP port 500 and 4500, but for
IKEv2 this is already defined in the RFC7296.

The RFC3947 could either be left as it is now, or marked as being
obsoleted by this or RFC4306, or RFC7296 or whatever. Updating
document which is effectively already obsoleted, is just wrong...
--
kivinen@iki.fi


--94eb2c08763a589ba0054e172bb0-- From nobody Wed Apr 26 12:58:53 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA26127909; Wed, 26 Apr 2017 12:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SrTAxcq6r1be; Wed, 26 Apr 2017 12:58:49 -0700 (PDT) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002: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 A64D2126DED; Wed, 26 Apr 2017 12:58:49 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id 203so5899219ywe.0; Wed, 26 Apr 2017 12:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vMWt+CbFXY6IC/WUUb2YAG9w132xMdRP7fAY4yJVWHM=; b=fH/zHAMWz/il1hvvV3WZQq4HTl1kDzq2J5Flo6iLpHqD6A8QPa5OxqFIynBod3fkjy 3yRP1HbMR3PIuvFlyVkJ7SOR0kU167w08muW1q2Rmpjhl8JdrfkGEdsC6JwtrR6d/nb4 15/cbY2LyCLEK6L1ynN6T806Va39lGwv4XLptmUPeGafnJD3+aA2NPj9lOifyNDOAWvW N7mbMxCio0J+rvDoSzpnmy2b+VKTWAjwcctZrENcXNlsnETbkF287mqlNAB8BYnlsBL6 kfSGF5xWvOQoI+pYwpGAh/oFMGJkTgxjIEkLm7/E03by+jfoSuJ9Dy7g/5U0ABa9+elp nYFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vMWt+CbFXY6IC/WUUb2YAG9w132xMdRP7fAY4yJVWHM=; b=oL7e7mHbNHhuAbJUd4r7rHKWFb/gT8qVCMGbaJDKbXCjO01xMqzLVyk3ECt4qMVS+t KXP2aOXc3HEFaUUD/EeV4jXbFvMfcltQYiUCkCRXZVILSCKs0Hq3Ft8vfZk7Qu2LO/HW qD8M8oYDLHFW+6afzKu3UzK39CzoLfgc19z8772BFL0ldnHhIIhcKAlpkUJdOg2vm4q9 74HvSN9c4P7VY6AYLbFDXFELQluKpEkaBF9ia4vqMoomzWZGL2ZPuhiwlJV9tf4qfV03 cinJB59F7ZyRqGyPwgWKj+E/ErKkaWw8oCsEJAI5azR2GgAP5ksLKZlqy4Tl+6p7Ml+W IZGw== X-Gm-Message-State: AN3rC/70rwibVS4C2HFwaGxAB87pUTgLbwZ5iw+EzB6F23Mc4b8+5St9 03Yd1ndiBR7sh80kgJ17wX0TUdBAow== X-Received: by 10.13.253.67 with SMTP id n64mr1453153ywf.263.1493236728895; Wed, 26 Apr 2017 12:58:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Wed, 26 Apr 2017 12:58:48 -0700 (PDT) In-Reply-To: <834CF872-4D53-4B02-A791-4A7C77771D71@nostrum.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> <166762EE-0C66-4CB9-AB08-0FD8E15253B6@nostrum.com> <380A837C-3062-444A-B76F-430785AB3CD0@apple.com> <834CF872-4D53-4B02-A791-4A7C77771D71@nostrum.com> From: Spencer Dawkins at IETF Date: Wed, 26 Apr 2017 14:58:48 -0500 Message-ID: To: Ben Campbell Cc: Tommy Pauly , ipsecme-chairs@ietf.org, Tero Kivinen , "ipsec@ietf.org" , Kathleen Moriarty , The IESG , Paul Wouters , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Type: multipart/alternative; boundary=94eb2c06a378caa677054e174435 Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 19:58:52 -0000 --94eb2c06a378caa677054e174435 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Ben and Tommy, On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell wrote: > > > On Apr 26, 2017, at 12:50 PM, Tommy Pauly wrote: > > > > Hi Ben, > > > > Thanks for the comments! Your point about the line in Section 6 not > making sense is definitely a good point. How about this text (changes in > bold): > > > > If a TCP connection is being used to resume a previous IKE session, > > the TCP Responder can recognize the session using either the IKE SPI > > from an encapsulated IKE message or the ESP SPI from an encapsulated > > ESP message. If the session had been fully established previously, > > it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES > > message if MOBIKE is supported, or an INFORMATIONAL message (a > > keepalive) otherwise. [The TCP Responder MUST NOT accept any messag= es > > for the existing IKE session on new an incoming connection unless > that connection > > begins with the stream prefix. If either the TCP Originator or TCP > Responder > > cannot parse valid IKE or ESP messages on a TCP encapsulation > connection > > that was started with a valid stream prefix, it MUST close the TCP > connection.] > > If there is instead a syntax issue within an IKE > > message, an implementation MUST send the INVALID_SYNTAX notify > > payload and tear down the IKE SA as usual, rather than tearing down > > the TCP connection directly. > > > > Thanks, > > Tommy > > That looks good to me. I will clear, with the assumption this or similar > edits will make it into the draft. > Does *The TCP Responder MUST NOT accept any messages* * for the existing IKE session on new an incoming connection unless that connection* * begins with the stream prefix. * parse for you guys? I get stuck at "on new an incoming". Spencer > > Thanks! > > Ben. > > > > > >> On Apr 26, 2017, at 8:35 AM, Ben Campbell wrote: > >> > >> By the way, the DISCUSS vs COMMENT framing has gotten lost from the > thread. Only the first point was part of the DISCUSS, the rest are > non-binding comments. And I think the DISCUSS point is moving in the righ= t > direction, pending a text proposal. > >> > >> Thanks! > >> > >> Ben. > >> > >>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >>> > >>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell > wrote: > >>>> > >>>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >>>>> > >>>>> Thanks for the quick response Paul, a few questions... > >>>>> > >>>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters > wrote: > >>>>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: > >>>>>> > >>>>>>>> IIUC, the entire point of having the stream prefix is to allow > the TCP > >>>>>>>> responder to demux between this protocol, and some other protoco= l > that > >>>>>>>> would normally run on that port. Saying it MUST close the TCP > session > >>>>>>>> seems to completely remove that value. I assume people meant to > allow the > >>>>>>>> respondent to delegate a stream out to some other protocol > handler if the > >>>>>>>> prefix is not present? > >>>>>>>> > >>>>>>> > >>>>>>> I believe that this is because there is presumed to be no other > >>>>>>> service operating on the listening port (assuming a VPN > concentrator), > >>>>>>> but that's not explicitly stated either. > >>>>>> > >>>>>> > >>>>>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer > one of > >>>>>> the other kinds of SSL VPNs or as the administration interface or > >>>>>> user interface. > >>>>> > >>>>> OK, sounds like I didn't help here, so the editors should propose > text > >>>>> to address this gap. > >>>> > >>>> I think we are on the right track here, pending proposed text. > >>>> > >>>>> > >>>>>> > >>>>>>>> -- 2nd to last paragraph: "This document leaves the selection of > TCP > >>>>>>>> ports up to implementations." > >>>>>>>> I suspect "configurable local policy" would make more sense. > Leaving it > >>>>>>>> up to "implementations" leaves open the chance of different > >>>>>>>> implementations making non-intersecting port choices, which > doesn't help > >>>>>>>> interoperability. > >>>>>>> > >>>>>>> > >>>>>>> This may go more into unexplained assumptions... the clients > >>>>>>> authorized to connect to the server would need to know the correc= t > >>>>>>> port to establish a session and would be given that information > >>>>>>> specific to the implementation. With this assumption, the above > >>>>>>> should be fine... but editors/AD/WG, please correct me if I am > wrong. > >>>>>> > >>>>>> > >>>>>> I am pretty sure what is meant is "configuration" and not > "implementation". > >>>>> > >>>>> Is that in response to me being wrong in my assumption or the draft > >>>>> should say configuration (I think it's the latter, but important to > >>>>> check)? > >>>> > >>>> We are probably splitting hairs on the meaning of =E2=80=9Cimplement= ation=E2=80=9D vs > =E2=80=9Cconfiguration=E2=80=9D. (and maybe =E2=80=9Cdeployment=E2=80=9D)= . I was thinking of > =E2=80=9Cimplementation=E2=80=9D as being what developers do, and =E2=80= =9Cconfiguring/deploying=E2=80=9D > as what operators do. But I am aware that operators sometimes talk about > =E2=80=9Cimplementing=E2=80=9D a system. > >>>> > >>>> So my point was that I assume for purposes of interoperability that = a > general purpose client or server would allow the port to be changed in th= e > field. > >>>> > >>>>> > >>>>>> > >>>>>>>> -4, first paragraph: What is the expected behavior from a peers > that do > >>>>>>>> not support this spec when they receive a TCP stream with the > magic > >>>>>>>> number on a port for some other protocol? > >>>>>>> > >>>>>>> > >>>>>>> Maybe listing assumptions up front in the draft would help _IF_ t= he > >>>>>>> assumption is that the listening server is a VPN concentrator tha= t > >>>>>>> wouldn't be listening for other services. > >>>>>> > >>>>>> > >>>>>> Support for TCP would be based on preconfiguration, so the client > knows > >>>>>> this out-of-band. It cannot be discovered during negotiation, > because > >>>>>> it is assumed the regular UDP ports are blocked, which is the only > >>>>>> reason to attempt TCP to begin with. > >>>>> > >>>>> I read the draft with this assumption in mind (see above), but this > >>>>> should be clarified in the document to address this question from > Ben. > >>>> > >>>> Imagine a misconfigured client opening a connection to an web server > on port 80, expecting to find a VPN service. What happens? I think that a > consequence of the design approach to allow this to run over ports assign= ed > to other protocols is that you need to consider that sort of thing. > >>>> > >>>>>> > >>>>>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate one > of the > >>>>>>>> primary reasons to use TLS? (Namely to obscure the fact that thi= s > is not > >>>>>>>> HTTP, or whatever other protocol is assigned to the port?) > >>>>>>> > >>>>>>> > >>>>>>> Editors/AD correct me if I am wrong, but... > >>>>>>> No, if TLS is used with a NULL cipher, it'll pass inspection of a > >>>>>>> middle box validating the protocol. This doesn't need to use the > >>>>>>> cipher as it's negotiating the IPsec connection. > >>>>>> > >>>>>> > >>>>>> right, TLS happens to use encryption to get out, but it is not the > >>>>>> encryption of the actual IKE/IPsec protocols, which keep using the= ir > >>>>>> own channel negotiations. > >>>>> > >>>>> I think clarifying this further in the draft would be helpful. > >>>> > >>>> I agree, because I=E2=80=99m still confused :-) > >>>> > >>>> To clarify my question: Assuming the case of TLS encapsulation to th= e > HTTPS port across a DPI middle-box that hates that sort of thing. If TLS > uses the NULL cipher, can the middlebox not tell that the protocol over T= LS > is not HTTP? (I will defer to the experts.) > >>> > >>> IPsec WG participants should chime in here, Yoav may know for sure > >>> with his background, I'm sure others too. > >>> > >>> I'd guess that a DPI would not pick it up as the protocol inspection > >>> most likely assumes when it sees TLS, that the traffic is encrypted > >>> and looks no further for inspection/blocking purposes. The > >>> middleboxes that do some protocol inspection aren't like the ones fro= m > >>> 15-20 years ago that dug into the protocol (blocking FTP commands, > >>> etc.). > >>> > >>> The use of TCP 443 for this has been in place for a decade or two, > >>> Google QUIC also uses TCP 443, and I'm sure other services do too. So > >>> tunneling does work. > >>> > >>> For purity, are we worried if this is TLS or HTTP/TLS (as the port > >>> usage specifies) or does that matter? > >>> > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> > >>> Best regards, > >>> Kathleen > >> > > > > --94eb2c06a378caa677054e174435 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Ben and Tommy,

On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell <ben@nostr= um.com> wrote:

> On Apr 26, 2017, at 12:50 PM, Tommy Pauly <tpauly@apple.com> wrote:
>
> Hi Ben,
>
> Thanks for the comments! Your point about the line in Section 6 not ma= king sense is definitely a good point. How about this text (changes in bold= ):
>
> If a TCP connection is being used to resume a previous IKE session, >=C2=A0 =C2=A0 the TCP Responder can recognize the session using either = the IKE SPI
>=C2=A0 =C2=A0 from an encapsulated IKE message or the ESP SPI from an e= ncapsulated
>=C2=A0 =C2=A0 ESP message.=C2=A0 If the session had been fully establis= hed previously,
>=C2=A0 =C2=A0 it is suggested that the TCP Originator send an UPDATE_SA= _ADDRESSES
>=C2=A0 =C2=A0 message if MOBIKE is supported, or an INFORMATIONAL messa= ge (a
>=C2=A0 =C2=A0 keepalive) otherwise.=C2=A0 [The TCP Responder MUST NOT a= ccept any messages
>=C2=A0 =C2=A0 for the existing IKE session on new an incoming connectio= n unless that connection
>=C2=A0 =C2=A0 begins with the stream prefix. If either the TCP Originat= or or TCP Responder
>=C2=A0 =C2=A0 cannot parse valid IKE or ESP messages on a TCP encapsula= tion connection
>=C2=A0 =C2=A0 that was started with a valid stream prefix, it MUST clos= e the TCP connection.]
>=C2=A0 =C2=A0 If there is instead a syntax issue within an IKE
>=C2=A0 =C2=A0 message, an implementation MUST send the INVALID_SYNTAX n= otify
>=C2=A0 =C2=A0 payload and tear down the IKE SA as usual, rather than te= aring down
>=C2=A0 =C2=A0 the TCP connection directly.
>
> Thanks,
> Tommy

That looks good to me. I will clear, with the assumption this or sim= ilar edits will make it into the draft.

Does=C2=A0

The= TCP Responder MUST NOT accept any messages
=C2=A0 =C2=A0for the existing IKE session on new an incoming c= onnection unless that connection
<= b>=C2=A0 =C2=A0begins with the stream prefix.=C2=A0
parse for you guys? I get stuck at "on new an incoming&quo= t;.

Spencer
=C2=A0

Thanks!

Ben.


>
>> On Apr 26, 2017, at 8:35 AM, Ben Campbell <ben@nostrum.com> wrote:
>>
>> By the way, the DISCUSS vs COMMENT framing has gotten lost from th= e thread. Only the first point was part of the DISCUSS, the rest are non-bi= nding comments. And I think the DISCUSS point is moving in the right direct= ion, pending a text proposal.
>>
>> Thanks!
>>
>> Ben.
>>
>>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.= com> wrote:
>>>
>>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell <ben@nostrum.com> wrote:
>>>>
>>>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gma= il.com> wrote:
>>>>>
>>>>> Thanks for the quick response Paul, a few questions...=
>>>>>
>>>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters <paul@nohats.ca> wrote:
>>>>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
>>>>>>
>>>>>>>> IIUC, the entire point of having the strea= m prefix is to allow the TCP
>>>>>>>> responder to demux between this protocol, = and some other protocol that
>>>>>>>> would normally run on that port. Saying it= MUST close the TCP session
>>>>>>>> seems to completely remove that value. I a= ssume people meant to allow the
>>>>>>>> respondent to delegate a stream out to som= e other protocol handler if the
>>>>>>>> prefix is not present?
>>>>>>>>
>>>>>>>
>>>>>>> I believe that this is because there is presum= ed to be no other
>>>>>>> service operating on the listening port (assum= ing a VPN concentrator),
>>>>>>> but that's not explicitly stated either. >>>>>>
>>>>>>
>>>>>> Vendors tend to run TLS on the IKE/IPsec machine, = either to offer one of
>>>>>> the other kinds of SSL VPNs or as the administrati= on interface or
>>>>>> user interface.
>>>>>
>>>>> OK, sounds like I didn't help here, so the editors= should propose text
>>>>> to address this gap.
>>>>
>>>> I think we are on the right track here, pending proposed t= ext.
>>>>
>>>>>
>>>>>>
>>>>>>>> -- 2nd to last paragraph: "This docum= ent leaves the selection of TCP
>>>>>>>> ports up to implementations."
>>>>>>>> I suspect "configurable local policy&= quot; would make more sense. Leaving it
>>>>>>>> up to "implementations" leaves o= pen the chance of different
>>>>>>>> implementations making non-intersecting po= rt choices, which doesn't help
>>>>>>>> interoperability.
>>>>>>>
>>>>>>>
>>>>>>> This may go more into unexplained assumptions.= .. the clients
>>>>>>> authorized to connect to the server would need= to know the correct
>>>>>>> port to establish a session and would be given= that information
>>>>>>> specific to the implementation.=C2=A0 With thi= s assumption, the above
>>>>>>> should be fine... but editors/AD/WG, please co= rrect me if I am wrong.
>>>>>>
>>>>>>
>>>>>> I am pretty sure what is meant is "configurat= ion" and not "implementation".
>>>>>
>>>>> Is that in response to me being wrong in my assumption= or the draft
>>>>> should say configuration (I think it's the latter,= but important to
>>>>> check)?
>>>>
>>>> We are probably splitting hairs on the meaning of =E2=80= =9Cimplementation=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. (and maybe = =E2=80=9Cdeployment=E2=80=9D). I was thinking of =E2=80=9Cimplementation=E2= =80=9D as being what developers do, and =E2=80=9Cconfiguring/deploying=E2= =80=9D as what operators do. But I am aware that operators sometimes talk a= bout =E2=80=9Cimplementing=E2=80=9D a system.
>>>>
>>>> So my point was that I assume for purposes of interoperabi= lity that a general purpose client or server would allow the port to be cha= nged in the field.
>>>>
>>>>>
>>>>>>
>>>>>>>> -4, first paragraph: What is the expected = behavior from a peers that do
>>>>>>>> not support this spec when they receive a = TCP stream with the magic
>>>>>>>> number on a port for some other protocol?<= br> >>>>>>>
>>>>>>>
>>>>>>> Maybe listing assumptions up front in the draf= t would help _IF_ the
>>>>>>> assumption is that the listening server is a V= PN concentrator that
>>>>>>> wouldn't be listening for other services.<= br> >>>>>>
>>>>>>
>>>>>> Support for TCP would be based on preconfiguration= , so the client knows
>>>>>> this out-of-band. It cannot be discovered during n= egotiation, because
>>>>>> it is assumed the regular UDP ports are blocked, w= hich is the only
>>>>>> reason to attempt TCP to begin with.
>>>>>
>>>>> I read the draft with this assumption in mind (see abo= ve), but this
>>>>> should be clarified in the document to address this qu= estion from Ben.
>>>>
>>>> Imagine a misconfigured client opening a connection to an = web server on port 80, expecting to find a VPN service. What happens? I thi= nk that a consequence of the design approach to allow this to run over port= s assigned to other protocols is that you need to consider that sort of thi= ng.
>>>>
>>>>>>
>>>>>>>> - Appendix A: Doesn't the use of the N= ULL cipher invalidate one of the
>>>>>>>> primary reasons to use TLS? (Namely to obs= cure the fact that this is not
>>>>>>>> HTTP, or whatever other protocol is assign= ed to the port?)
>>>>>>>
>>>>>>>
>>>>>>> Editors/AD correct me if I am wrong, but... >>>>>>> No, if TLS is used with a NULL cipher, it'= ll pass inspection of a
>>>>>>> middle box validating the protocol.=C2=A0 This= doesn't need to use the
>>>>>>> cipher as it's negotiating the IPsec conne= ction.
>>>>>>
>>>>>>
>>>>>> right, TLS happens to use encryption to get out, b= ut it is not the
>>>>>> encryption of the actual IKE/IPsec protocols, whic= h keep using their
>>>>>> own channel negotiations.
>>>>>
>>>>> I think clarifying this further in the draft would be = helpful.
>>>>
>>>> I agree, because I=E2=80=99m still confused :-)
>>>>
>>>> To clarify my question: Assuming the case of TLS encapsula= tion to the HTTPS port across a DPI middle-box that hates that sort of thin= g. If TLS uses the NULL cipher, can the middlebox not tell that the protoco= l over TLS is not HTTP? (I will defer to the experts.)
>>>
>>> IPsec WG participants should chime in here, Yoav may know for = sure
>>> with his background, I'm sure others too.
>>>
>>> I'd guess that a DPI would not pick it up as the protocol = inspection
>>> most likely assumes when it sees TLS, that the traffic is encr= ypted
>>> and looks no further for inspection/blocking purposes.=C2=A0 T= he
>>> middleboxes that do some protocol inspection aren't like t= he ones from
>>> 15-20 years ago that dug into the protocol (blocking FTP comma= nds,
>>> etc.).
>>>
>>> The use of TCP 443 for this has been in place for a decade or = two,
>>> Google QUIC also uses TCP 443, and I'm sure other services= do too. So
>>> tunneling does work.
>>>
>>> For purity, are we worried if this is TLS or HTTP/TLS (as the = port
>>> usage specifies) or does that matter?
>>>
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Best regards,
>>> Kathleen
>>
>


--94eb2c06a378caa677054e174435-- From nobody Wed Apr 26 13:08:20 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8AA412EB55; Wed, 26 Apr 2017 13:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIZje87cdNmh; Wed, 26 Apr 2017 13:08:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C90501294A9; Wed, 26 Apr 2017 13:08:17 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3QK87mp077262 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 26 Apr 2017 15:08:07 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: Date: Wed, 26 Apr 2017 15:08:07 -0500 Cc: ipsecme-chairs@ietf.org, Tero Kivinen , "ipsec@ietf.org" , Kathleen Moriarty , The IESG , Paul Wouters , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly Content-Transfer-Encoding: quoted-printable Message-Id: References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> <166762EE-0C66-4CB9-AB08-0FD8E15253B6@nostrum.com> <380A837C-3062-444A-B76F-430785AB3CD0@apple.com> <834CF872-4D53-4B02-A791-4A7C77771D71@nostrum.com> To: Spencer Dawkins at IETF X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 20:08:20 -0000 > On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Ben and Tommy, >=20 > On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell wrote: >=20 > > On Apr 26, 2017, at 12:50 PM, Tommy Pauly wrote: > > > > Hi Ben, > > > > Thanks for the comments! Your point about the line in Section 6 not = making sense is definitely a good point. How about this text (changes in = bold): > > > > If a TCP connection is being used to resume a previous IKE session, > > the TCP Responder can recognize the session using either the IKE = SPI > > from an encapsulated IKE message or the ESP SPI from an = encapsulated > > ESP message. If the session had been fully established = previously, > > it is suggested that the TCP Originator send an = UPDATE_SA_ADDRESSES > > message if MOBIKE is supported, or an INFORMATIONAL message (a > > keepalive) otherwise. [The TCP Responder MUST NOT accept any = messages > > for the existing IKE session on new an incoming connection unless = that connection > > begins with the stream prefix. If either the TCP Originator or = TCP Responder > > cannot parse valid IKE or ESP messages on a TCP encapsulation = connection > > that was started with a valid stream prefix, it MUST close the = TCP connection.] > > If there is instead a syntax issue within an IKE > > message, an implementation MUST send the INVALID_SYNTAX notify > > payload and tear down the IKE SA as usual, rather than tearing = down > > the TCP connection directly. > > > > Thanks, > > Tommy >=20 > That looks good to me. I will clear, with the assumption this or = similar edits will make it into the draft. >=20 > Does=20 >=20 > The TCP Responder MUST NOT accept any messages > for the existing IKE session on new an incoming connection unless = that connection > begins with the stream prefix.=20 >=20 > parse for you guys? I get stuck at "on new an incoming=E2=80=9D. I=E2=80=99m guessing that=E2=80=99s an edit-o from. Maybe it should be = =E2=80=9Con a new incoming=E2=80=9D? >=20 > Spencer > =20 >=20 > Thanks! >=20 > Ben. >=20 >=20 > > > >> On Apr 26, 2017, at 8:35 AM, Ben Campbell wrote: > >> > >> By the way, the DISCUSS vs COMMENT framing has gotten lost from the = thread. Only the first point was part of the DISCUSS, the rest are = non-binding comments. And I think the DISCUSS point is moving in the = right direction, pending a text proposal. > >> > >> Thanks! > >> > >> Ben. > >> > >>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty = wrote: > >>> > >>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell = wrote: > >>>> > >>>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty = wrote: > >>>>> > >>>>> Thanks for the quick response Paul, a few questions... > >>>>> > >>>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters = wrote: > >>>>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: > >>>>>> > >>>>>>>> IIUC, the entire point of having the stream prefix is to = allow the TCP > >>>>>>>> responder to demux between this protocol, and some other = protocol that > >>>>>>>> would normally run on that port. Saying it MUST close the TCP = session > >>>>>>>> seems to completely remove that value. I assume people meant = to allow the > >>>>>>>> respondent to delegate a stream out to some other protocol = handler if the > >>>>>>>> prefix is not present? > >>>>>>>> > >>>>>>> > >>>>>>> I believe that this is because there is presumed to be no = other > >>>>>>> service operating on the listening port (assuming a VPN = concentrator), > >>>>>>> but that's not explicitly stated either. > >>>>>> > >>>>>> > >>>>>> Vendors tend to run TLS on the IKE/IPsec machine, either to = offer one of > >>>>>> the other kinds of SSL VPNs or as the administration interface = or > >>>>>> user interface. > >>>>> > >>>>> OK, sounds like I didn't help here, so the editors should = propose text > >>>>> to address this gap. > >>>> > >>>> I think we are on the right track here, pending proposed text. > >>>> > >>>>> > >>>>>> > >>>>>>>> -- 2nd to last paragraph: "This document leaves the selection = of TCP > >>>>>>>> ports up to implementations." > >>>>>>>> I suspect "configurable local policy" would make more sense. = Leaving it > >>>>>>>> up to "implementations" leaves open the chance of different > >>>>>>>> implementations making non-intersecting port choices, which = doesn't help > >>>>>>>> interoperability. > >>>>>>> > >>>>>>> > >>>>>>> This may go more into unexplained assumptions... the clients > >>>>>>> authorized to connect to the server would need to know the = correct > >>>>>>> port to establish a session and would be given that = information > >>>>>>> specific to the implementation. With this assumption, the = above > >>>>>>> should be fine... but editors/AD/WG, please correct me if I am = wrong. > >>>>>> > >>>>>> > >>>>>> I am pretty sure what is meant is "configuration" and not = "implementation". > >>>>> > >>>>> Is that in response to me being wrong in my assumption or the = draft > >>>>> should say configuration (I think it's the latter, but important = to > >>>>> check)? > >>>> > >>>> We are probably splitting hairs on the meaning of = =E2=80=9Cimplementation=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. = (and maybe =E2=80=9Cdeployment=E2=80=9D). I was thinking of = =E2=80=9Cimplementation=E2=80=9D as being what developers do, and = =E2=80=9Cconfiguring/deploying=E2=80=9D as what operators do. But I am = aware that operators sometimes talk about =E2=80=9Cimplementing=E2=80=9D = a system. > >>>> > >>>> So my point was that I assume for purposes of interoperability = that a general purpose client or server would allow the port to be = changed in the field. > >>>> > >>>>> > >>>>>> > >>>>>>>> -4, first paragraph: What is the expected behavior from a = peers that do > >>>>>>>> not support this spec when they receive a TCP stream with the = magic > >>>>>>>> number on a port for some other protocol? > >>>>>>> > >>>>>>> > >>>>>>> Maybe listing assumptions up front in the draft would help = _IF_ the > >>>>>>> assumption is that the listening server is a VPN concentrator = that > >>>>>>> wouldn't be listening for other services. > >>>>>> > >>>>>> > >>>>>> Support for TCP would be based on preconfiguration, so the = client knows > >>>>>> this out-of-band. It cannot be discovered during negotiation, = because > >>>>>> it is assumed the regular UDP ports are blocked, which is the = only > >>>>>> reason to attempt TCP to begin with. > >>>>> > >>>>> I read the draft with this assumption in mind (see above), but = this > >>>>> should be clarified in the document to address this question = from Ben. > >>>> > >>>> Imagine a misconfigured client opening a connection to an web = server on port 80, expecting to find a VPN service. What happens? I = think that a consequence of the design approach to allow this to run = over ports assigned to other protocols is that you need to consider that = sort of thing. > >>>> > >>>>>> > >>>>>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate = one of the > >>>>>>>> primary reasons to use TLS? (Namely to obscure the fact that = this is not > >>>>>>>> HTTP, or whatever other protocol is assigned to the port?) > >>>>>>> > >>>>>>> > >>>>>>> Editors/AD correct me if I am wrong, but... > >>>>>>> No, if TLS is used with a NULL cipher, it'll pass inspection = of a > >>>>>>> middle box validating the protocol. This doesn't need to use = the > >>>>>>> cipher as it's negotiating the IPsec connection. > >>>>>> > >>>>>> > >>>>>> right, TLS happens to use encryption to get out, but it is not = the > >>>>>> encryption of the actual IKE/IPsec protocols, which keep using = their > >>>>>> own channel negotiations. > >>>>> > >>>>> I think clarifying this further in the draft would be helpful. > >>>> > >>>> I agree, because I=E2=80=99m still confused :-) > >>>> > >>>> To clarify my question: Assuming the case of TLS encapsulation to = the HTTPS port across a DPI middle-box that hates that sort of thing. If = TLS uses the NULL cipher, can the middlebox not tell that the protocol = over TLS is not HTTP? (I will defer to the experts.) > >>> > >>> IPsec WG participants should chime in here, Yoav may know for sure > >>> with his background, I'm sure others too. > >>> > >>> I'd guess that a DPI would not pick it up as the protocol = inspection > >>> most likely assumes when it sees TLS, that the traffic is = encrypted > >>> and looks no further for inspection/blocking purposes. The > >>> middleboxes that do some protocol inspection aren't like the ones = from > >>> 15-20 years ago that dug into the protocol (blocking FTP commands, > >>> etc.). > >>> > >>> The use of TCP 443 for this has been in place for a decade or two, > >>> Google QUIC also uses TCP 443, and I'm sure other services do too. = So > >>> tunneling does work. > >>> > >>> For purity, are we worried if this is TLS or HTTP/TLS (as the port > >>> usage specifies) or does that matter? > >>> > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> > >>> Best regards, > >>> Kathleen > >> > > From nobody Wed Apr 26 14:23:51 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8386212F253 for ; Wed, 26 Apr 2017 14:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rq2FP419f70 for ; Wed, 26 Apr 2017 14:23:44 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 10E4512EB24 for ; Wed, 26 Apr 2017 14:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493241816; 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=PzhAz9E2iJZXkKxf6z5u0dx+US9VtNEvx4iSoMC7TH0=; b=Ro8PAJfHfsOtMFPGkG3pyVR2rD3FNbiBOMpx89UsJ+iUrp1m9vf4xAb08WYQIw/t UTbpLXJ+/54SdFP9CphcYNKxz5aMdvQKSmdru9RdLzN8D/hOiTBO2GWkQOOtBV4A c1Qh3yZL6z8RD12eDfcEw2sK4edPy7+ld7P7QlpZiUS+rsh5/2QPBWVE8BTqwgTG cq2qQ/v/9bALNNzS14lMcyDxD8uZMfba93j14cOhRLyMXS38iymda7dA6yj/texc K76053vuZQMrum1C6/sC1RojNk0XR4bBPti/ryZgRuYCxdn0RbNPXeHaqE74OBKV ubjVUQXBdDLcqcH19Kw8GQ==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 26.14.18640.8DF01095; Wed, 26 Apr 2017 14:23:36 -0700 (PDT) X-AuditID: 11973e12-29af39a0000048d0-3e-59010fd8eff6 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by relay2.apple.com (Apple SCV relay) with SMTP id 2B.0E.07829.8DF01095; Wed, 26 Apr 2017 14:23:36 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_wpAnkftX+j4Fe86agmrMbA)" Received: from demo-wifi.coreoutside.org ([17.227.5.3]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OP1005UVCRBA670@nwk-mmpp-sz13.apple.com>; Wed, 26 Apr 2017 14:23:36 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <9643E604-8D2E-43FF-AD63-A78E28D4FC6A@apple.com> Date: Wed, 26 Apr 2017 14:23:35 -0700 In-reply-to: Cc: Spencer Dawkins at IETF , ipsecme-chairs@ietf.org, Tero Kivinen , "ipsec@ietf.org" , Kathleen Moriarty , The IESG , Paul Wouters , draft-ietf-ipsecme-tcp-encaps@ietf.org To: Ben Campbell References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> <166762EE-0C66-4CB9-AB08-0FD8E15253B6@nostrum.com> <380A837C-3062-444A-B76F-430785AB3CD0@apple.com> <834CF872-4D53-4B02-A791-4A7C77771D71@nostrum.com> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphkeLIzCtJLcpLzFFi42IRbCh01r3BzxhpcHmmocX8ztPsFu//nGG0 mPFnIrPF/i0v2CxmzvnAYtGwM9/i6PnnbBbvb11islg2ZQ+zA6fHzll32T2WLPnJ5HH460IW j+/zmDxm7XzCEsAaxWWTkpqTWZZapG+XwJVxsGkSa8HWJ4wVZ7ufsDcwLjvE2MXIySEhYCLx +fJj5i5GLg4hgdVMEps+9LHBJK72zWeCSBxilHi4YgcLSIJXQFDix+R7QDYHB7NAmMSfRjuI mglMEi/mPWAEiQsLSEhs3pMIUs4moCJx/NsGZohWG4mfj5vZIEpyJRa9DQIJswioSty/sgbs Hk4Be4kbC6aA3cMssJ1J4uiVFlaQhIiAksTz5q0sELtWsUqcmdUJdaisRPfCaWAdEgLt7BLH bpxlmcAoNAvJrbMQboUw1SWmTMkFqWAW0JZ48u4CK4StJrHw9yImZPEFjGyrGIVyEzNzdDPz TPQSCwpyUvWS83M3MYKibbqd0A7GU6usDjEKcDAq8fC+WMcQKcSaWFZcmXuIUZqDRUmcV2XH /wghgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBYbAgqDD8T9fTErpDehcveBvSuev2e3Wxdw UaTi6IsHr/fU617eWF08TYn3sqnC3YCz2Uy7PX889Hz18Pvfp2fd3v8LY/C6xyt/K4tDNG+Z OdfMZTpHSq01Nu4WvscVvbPtmaei29MC8Y1nzxfO3GlxaPmk6JDlnRtcJTZq3uIo/yyQYH19 Y6kSS3FGoqEWc1FxIgAsMtGIlwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHIsWRmVeSWpSXmKPExsUi2FB8Q/cGP2OkwYOvEhbzO0+zW7z/c4bR YsaficwW+7e8YLOYOecDi0XDznyLo+efs1m8v3WJyWLZlD3MDpweO2fdZfdYsuQnk8fhrwtZ PL7PY/KYtfMJSwBrFJdNSmpOZllqkb5dAlfGwaZJrAVbnzBWnO1+wt7AuOwQYxcjJ4eEgInE 1b75TF2MXBxCAocYJR6u2MECkuAVEJT4MfkekM3BwSwQJvGn0Q6iZgKTxIt5DxhB4sICEhKb 9ySClLMJqEgc/7aBGaLVRuLn42Y2iJJciUVvg0DCLAKqEvevrAFbyylgL3FjwRRmkJHMAtuZ JI5eaWEFSYgIKEk8b97KArFrFavEmVmdbBCHykp0L5zGPIGRfxaS82YhnAdhqktMmZILUsEs oC3x5N0FVghbTWLh70VMyOILGNlWMQoUpeYkVhrpJRYU5KTqJefnbmIER0eh8w7GY8usDjEK cDAq8fC+WMcQKcSaWFZcmQsMIg5mJRFejZdAId6UxMqq1KL8+KLSnNTiQ4wTGYG+nMgsJZqc D4zdvJJ4QxMTAxNjYzNjY3MTc1oKK4nzznsLdJFAemJJanZqakFqEcxRTBycUg2MBak1Nku1 mi2NHqjJrxMIeNXjcp/1+X2DR0b395x14Ei80lw3oXYj16H/reI3+95rHth0cK2tT8bF9bI+ VxYJnG45EbzjTbKf1zP3M1t4H19ZdvbCCX7nkpy53z/Yr7VYyvbRRtlY30tttmngPO6euW/W vc9vu2tec7vp5TEJ52kvl5bXZ1z8rsRSnJFoqMVcVJwIAL6Oga8BAwAA Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:23:46 -0000 --Boundary_(ID_wpAnkftX+j4Fe86agmrMbA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Apr 26, 2017, at 1:08 PM, Ben Campbell wrote: >=20 >>=20 >> On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF = wrote: >>=20 >> Hi, Ben and Tommy, >>=20 >> On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell = wrote: >>=20 >>> On Apr 26, 2017, at 12:50 PM, Tommy Pauly wrote: >>>=20 >>> Hi Ben, >>>=20 >>> Thanks for the comments! Your point about the line in Section 6 not = making sense is definitely a good point. How about this text (changes in = bold): >>>=20 >>> If a TCP connection is being used to resume a previous IKE session, >>> the TCP Responder can recognize the session using either the IKE = SPI >>> from an encapsulated IKE message or the ESP SPI from an = encapsulated >>> ESP message. If the session had been fully established = previously, >>> it is suggested that the TCP Originator send an = UPDATE_SA_ADDRESSES >>> message if MOBIKE is supported, or an INFORMATIONAL message (a >>> keepalive) otherwise. [The TCP Responder MUST NOT accept any = messages >>> for the existing IKE session on new an incoming connection unless = that connection >>> begins with the stream prefix. If either the TCP Originator or TCP = Responder >>> cannot parse valid IKE or ESP messages on a TCP encapsulation = connection >>> that was started with a valid stream prefix, it MUST close the TCP = connection.] >>> If there is instead a syntax issue within an IKE >>> message, an implementation MUST send the INVALID_SYNTAX notify >>> payload and tear down the IKE SA as usual, rather than tearing = down >>> the TCP connection directly. >>>=20 >>> Thanks, >>> Tommy >>=20 >> That looks good to me. I will clear, with the assumption this or = similar edits will make it into the draft. >>=20 >> Does=20 >>=20 >> The TCP Responder MUST NOT accept any messages >> for the existing IKE session on new an incoming connection unless = that connection >> begins with the stream prefix.=20 >>=20 >> parse for you guys? I get stuck at "on new an incoming=E2=80=9D. >=20 >=20 > I=E2=80=99m guessing that=E2=80=99s an edit-o from. Maybe it should be = =E2=80=9Con a new incoming=E2=80=9D? Yes, I meant "on a new incoming connection". Sorry! Thanks, Tommy >=20 >>=20 >> Spencer >>=20 >>=20 >> Thanks! >>=20 >> Ben. >>=20 >>=20 >>>=20 >>>> On Apr 26, 2017, at 8:35 AM, Ben Campbell wrote: >>>>=20 >>>> By the way, the DISCUSS vs COMMENT framing has gotten lost from the = thread. Only the first point was part of the DISCUSS, the rest are = non-binding comments. And I think the DISCUSS point is moving in the = right direction, pending a text proposal. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>>> On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty = wrote: >>>>>=20 >>>>> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell = wrote: >>>>>>=20 >>>>>>> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty = wrote: >>>>>>>=20 >>>>>>> Thanks for the quick response Paul, a few questions... >>>>>>>=20 >>>>>>> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters = wrote: >>>>>>>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote: >>>>>>>>=20 >>>>>>>>>> IIUC, the entire point of having the stream prefix is to = allow the TCP >>>>>>>>>> responder to demux between this protocol, and some other = protocol that >>>>>>>>>> would normally run on that port. Saying it MUST close the TCP = session >>>>>>>>>> seems to completely remove that value. I assume people meant = to allow the >>>>>>>>>> respondent to delegate a stream out to some other protocol = handler if the >>>>>>>>>> prefix is not present? >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I believe that this is because there is presumed to be no = other >>>>>>>>> service operating on the listening port (assuming a VPN = concentrator), >>>>>>>>> but that's not explicitly stated either. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Vendors tend to run TLS on the IKE/IPsec machine, either to = offer one of >>>>>>>> the other kinds of SSL VPNs or as the administration interface = or >>>>>>>> user interface. >>>>>>>=20 >>>>>>> OK, sounds like I didn't help here, so the editors should = propose text >>>>>>> to address this gap. >>>>>>=20 >>>>>> I think we are on the right track here, pending proposed text. >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> -- 2nd to last paragraph: "This document leaves the selection = of TCP >>>>>>>>>> ports up to implementations." >>>>>>>>>> I suspect "configurable local policy" would make more sense. = Leaving it >>>>>>>>>> up to "implementations" leaves open the chance of different >>>>>>>>>> implementations making non-intersecting port choices, which = doesn't help >>>>>>>>>> interoperability. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This may go more into unexplained assumptions... the clients >>>>>>>>> authorized to connect to the server would need to know the = correct >>>>>>>>> port to establish a session and would be given that = information >>>>>>>>> specific to the implementation. With this assumption, the = above >>>>>>>>> should be fine... but editors/AD/WG, please correct me if I am = wrong. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> I am pretty sure what is meant is "configuration" and not = "implementation". >>>>>>>=20 >>>>>>> Is that in response to me being wrong in my assumption or the = draft >>>>>>> should say configuration (I think it's the latter, but important = to >>>>>>> check)? >>>>>>=20 >>>>>> We are probably splitting hairs on the meaning of = =E2=80=9Cimplementation=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. = (and maybe =E2=80=9Cdeployment=E2=80=9D). I was thinking of = =E2=80=9Cimplementation=E2=80=9D as being what developers do, and = =E2=80=9Cconfiguring/deploying=E2=80=9D as what operators do. But I am = aware that operators sometimes talk about =E2=80=9Cimplementing=E2=80=9D = a system. >>>>>>=20 >>>>>> So my point was that I assume for purposes of interoperability = that a general purpose client or server would allow the port to be = changed in the field. >>>>>>=20 >>>>>>>=20 >>>>>>>>=20 >>>>>>>>>> -4, first paragraph: What is the expected behavior from a = peers that do >>>>>>>>>> not support this spec when they receive a TCP stream with the = magic >>>>>>>>>> number on a port for some other protocol? >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Maybe listing assumptions up front in the draft would help = _IF_ the >>>>>>>>> assumption is that the listening server is a VPN concentrator = that >>>>>>>>> wouldn't be listening for other services. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Support for TCP would be based on preconfiguration, so the = client knows >>>>>>>> this out-of-band. It cannot be discovered during negotiation, = because >>>>>>>> it is assumed the regular UDP ports are blocked, which is the = only >>>>>>>> reason to attempt TCP to begin with. >>>>>>>=20 >>>>>>> I read the draft with this assumption in mind (see above), but = this >>>>>>> should be clarified in the document to address this question = from Ben. >>>>>>=20 >>>>>> Imagine a misconfigured client opening a connection to an web = server on port 80, expecting to find a VPN service. What happens? I = think that a consequence of the design approach to allow this to run = over ports assigned to other protocols is that you need to consider that = sort of thing. >>>>>>=20 >>>>>>>>=20 >>>>>>>>>> - Appendix A: Doesn't the use of the NULL cipher invalidate = one of the >>>>>>>>>> primary reasons to use TLS? (Namely to obscure the fact that = this is not >>>>>>>>>> HTTP, or whatever other protocol is assigned to the port?) >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Editors/AD correct me if I am wrong, but... >>>>>>>>> No, if TLS is used with a NULL cipher, it'll pass inspection = of a >>>>>>>>> middle box validating the protocol. This doesn't need to use = the >>>>>>>>> cipher as it's negotiating the IPsec connection. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> right, TLS happens to use encryption to get out, but it is not = the >>>>>>>> encryption of the actual IKE/IPsec protocols, which keep using = their >>>>>>>> own channel negotiations. >>>>>>>=20 >>>>>>> I think clarifying this further in the draft would be helpful. >>>>>>=20 >>>>>> I agree, because I=E2=80=99m still confused :-) >>>>>>=20 >>>>>> To clarify my question: Assuming the case of TLS encapsulation to = the HTTPS port across a DPI middle-box that hates that sort of thing. If = TLS uses the NULL cipher, can the middlebox not tell that the protocol = over TLS is not HTTP? (I will defer to the experts.) >>>>>=20 >>>>> IPsec WG participants should chime in here, Yoav may know for sure >>>>> with his background, I'm sure others too. >>>>>=20 >>>>> I'd guess that a DPI would not pick it up as the protocol = inspection >>>>> most likely assumes when it sees TLS, that the traffic is = encrypted >>>>> and looks no further for inspection/blocking purposes. The >>>>> middleboxes that do some protocol inspection aren't like the ones = from >>>>> 15-20 years ago that dug into the protocol (blocking FTP commands, >>>>> etc.). >>>>>=20 >>>>> The use of TCP 443 for this has been in place for a decade or two, >>>>> Google QUIC also uses TCP 443, and I'm sure other services do too. = So >>>>> tunneling does work. >>>>>=20 >>>>> For purity, are we worried if this is TLS or HTTP/TLS (as the port >>>>> usage specifies) or does that matter? >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>>=20 >>>>> Best regards, >>>>> Kathleen >>>>=20 >>>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_wpAnkftX+j4Fe86agmrMbA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable


On = Apr 26, 2017, at 1:08 PM, Ben Campbell <ben@nostrum.com> = wrote:


On Apr 26, 2017, at 2:58 PM, Spencer = Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Ben and Tommy,

On Wed, Apr = 26, 2017 at 1:36 PM, Ben Campbell <ben@nostrum.com> wrote:

On Apr 26, 2017, at = 12:50 PM, Tommy Pauly <tpauly@apple.com> wrote:

Hi= Ben,

Thanks for the comments! Your point = about the line in Section 6 not making sense is definitely a good point. = How about this text (changes in bold):

If a = TCP connection is being used to resume a previous IKE session,
  the TCP Responder can recognize the session using = either the IKE SPI
  from an encapsulated IKE = message or the ESP SPI from an encapsulated
  ESP = message.  If the session had been fully established previously,
  it is suggested that the TCP Originator send an = UPDATE_SA_ADDRESSES
  message if MOBIKE is = supported, or an INFORMATIONAL message (a
  keepalive) otherwise.  [The TCP Responder = MUST NOT accept any messages
  for the existing = IKE session on new an incoming connection unless that connection
  begins with the stream prefix. If either the TCP = Originator or TCP Responder
  cannot parse valid = IKE or ESP messages on a TCP encapsulation connection
  that was started with a valid stream prefix, it = MUST close the TCP connection.]
  If there is = instead a syntax issue within an IKE
  message, = an implementation MUST send the INVALID_SYNTAX notify
  payload and tear down the IKE SA as usual, rather = than tearing down
  the TCP connection = directly.

Thanks,
Tommy

That looks good to me. I will = clear, with the assumption this or similar edits will make it into the = draft.

Does 

The TCP Responder MUST NOT accept any messages
  for the existing IKE session on new an incoming = connection unless that connection
  begins with = the stream prefix. 

parse for you guys? I get stuck at "on new an = incoming=E2=80=9D.


I=E2=80=99m guessing that=E2=80=99s an edit-o = from. Maybe it should be =E2=80=9Con a new incoming=E2=80=9D?

Yes, I meant "on = a new incoming connection". Sorry!

Thanks,
Tommy


Spencer


Thanks!

Ben.



On Apr 26, 2017, at 8:35 AM, Ben Campbell <ben@nostrum.com> = wrote:

By the way, the DISCUSS vs COMMENT = framing has gotten lost from the thread. Only the first point was part = of the DISCUSS, the rest are non-binding comments. And I think the = DISCUSS point is moving in the right direction, pending a text = proposal.

Thanks!

Ben.

On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell = <ben@nostrum.com> = wrote:

On Apr 25, 2017, at 9:38 = PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:

Thanks for the quick response Paul, a few = questions...

On Tue, Apr 25, 2017 at 10:18 = PM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 25 Apr 2017, Kathleen Moriarty = wrote:

IIUC, the entire point = of having the stream prefix is to allow the TCP
responder = to demux between this protocol, and some other protocol that
would normally run on that port. Saying it MUST close the TCP = session
seems to completely remove that value. I assume = people meant to allow the
respondent to delegate a stream = out to some other protocol handler if the
prefix is not = present?


I = believe that this is because there is presumed to be no other
service operating on the listening port (assuming a VPN = concentrator),
but that's not explicitly stated either.


Vendors tend to = run TLS on the IKE/IPsec machine, either to offer one of
the= other kinds of SSL VPNs or as the administration interface or
user interface.

OK, = sounds like I didn't help here, so the editors should propose text
to address this gap.

I think we are on the right track here, pending proposed = text.



-- 2nd to last paragraph: "This document leaves the selection = of TCP
ports up to implementations."
I = suspect "configurable local policy" would make more sense. Leaving it
up to "implementations" leaves open the chance of = different
implementations making non-intersecting port = choices, which doesn't help
interoperability.


This may go more = into unexplained assumptions... the clients
authorized to = connect to the server would need to know the correct
port = to establish a session and would be given that information
specific to the implementation.  With this assumption, = the above
should be fine... but editors/AD/WG, please = correct me if I am wrong.


I am pretty sure what is meant is "configuration" and not = "implementation".

Is that in = response to me being wrong in my assumption or the draft
should say configuration (I think it's the latter, but = important to
check)?

We are probably splitting hairs on the meaning of = =E2=80=9Cimplementation=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. = (and maybe =E2=80=9Cdeployment=E2=80=9D). I was thinking of = =E2=80=9Cimplementation=E2=80=9D as being what developers do, and = =E2=80=9Cconfiguring/deploying=E2=80=9D as what operators do. But I am = aware that operators sometimes talk about =E2=80=9Cimplementing=E2=80=9D = a system.

So my point was that I assume for = purposes of interoperability that a general purpose client or server = would allow the port to be changed in the field.



-4, first paragraph: = What is the expected behavior from a peers that do
not = support this spec when they receive a TCP stream with the magic
number on a port for some other protocol?


Maybe listing = assumptions up front in the draft would help _IF_ the
assumption is that the listening server is a VPN concentrator = that
wouldn't be listening for other services.


Support for TCP = would be based on preconfiguration, so the client knows
this= out-of-band. It cannot be discovered during negotiation, because
it is assumed the regular UDP ports are blocked, which is the = only
reason to attempt TCP to begin with.

I read the draft with this = assumption in mind (see above), but this
should be = clarified in the document to address this question from Ben.

Imagine a misconfigured client = opening a connection to an web server on port 80, expecting to find a = VPN service. What happens? I think that a consequence of the design = approach to allow this to run over ports assigned to other protocols is = that you need to consider that sort of thing.


- Appendix A: Doesn't the use of the NULL = cipher invalidate one of the
primary reasons to use TLS? = (Namely to obscure the fact that this is not
HTTP, or = whatever other protocol is assigned to the port?)


Editors/AD correct = me if I am wrong, but...
No, if TLS is used with a NULL = cipher, it'll pass inspection of a
middle box validating = the protocol.  This doesn't need to use the
cipher as = it's negotiating the IPsec connection.


right, TLS happens to use encryption to get = out, but it is not the
encryption of the actual IKE/IPsec = protocols, which keep using their
own channel = negotiations.

I think = clarifying this further in the draft would be helpful.

I agree, because I=E2=80=99m = still confused :-)

To clarify my question: = Assuming the case of TLS encapsulation to the HTTPS port across a DPI = middle-box that hates that sort of thing. If TLS uses the NULL cipher, = can the middlebox not tell that the protocol over TLS is not HTTP? (I = will defer to the experts.)

IPsec WG participants should chime in here, Yoav may know for = sure
with his background, I'm sure others too.

I'd guess that a DPI would not pick it up as = the protocol inspection
most likely assumes when it sees = TLS, that the traffic is encrypted
and looks no further = for inspection/blocking purposes.  The
middleboxes = that do some protocol inspection aren't like the ones from
15-20 years ago that dug into the protocol (blocking FTP = commands,
etc.).

The use of = TCP 443 for this has been in place for a decade or two,
Google QUIC also uses TCP 443, and I'm sure other services do = too. So
tunneling does work.

For purity, are we worried if this is TLS or HTTP/TLS (as the = port
usage specifies) or does that matter?





--
Best regards,
Kathleen



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

= --Boundary_(ID_wpAnkftX+j4Fe86agmrMbA)-- From nobody Wed Apr 26 14:29:28 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CD0128B91 for ; Wed, 26 Apr 2017 14:29:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVFWLF-2G76N for ; Wed, 26 Apr 2017 14:29:18 -0700 (PDT) Received: from mail-in23.apple.com (mail-out23.apple.com [17.171.2.33]) (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 CDCF41279EB for ; Wed, 26 Apr 2017 14:29:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493242154; 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=cQR2+L9NFydO/ElpWXdtiHU9+IDxxM3GnaZ4RIZJQ+4=; b=4XtTXLvDXQXppsG1YGVsDFCVrN0KWCPaMdTwQUwRrBAfRovPUE/JXaPLwOwdXjbY YSi4jCxEzBB6c3w9a1TxmVSLZJW4prJAWxSo9UqM0TsixbJFsVooaJQYYjhCSCg9 O6056zfC3+nVkpgOLSJxM5nj4EDJEN71MIlATx+CKaRnoS09s76EvGkGcgmGi6uo HA4Ht9oOtI+D0xmGHUtUefWWqVE8hWXfKKeRMymsylKQTkg8ACxKsPLBm5YvKdbt 6isk0f4js4hybbhzb95zNBzf6CwRt0m2mHOlOX65lH8uDYpJ1UqqDNGA5OhsdHi/ WN+7TvpIqjGnM66okv7z0A==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in23.apple.com (Apple Secure Mail Relay) with SMTP id 32.4D.06019.92111095; Wed, 26 Apr 2017 14:29:14 -0700 (PDT) X-AuditID: 11ab0217-9d7e79a000001783-f6-590111297485 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay6.apple.com (Apple SCV relay) with SMTP id F5.4B.09762.92111095; Wed, 26 Apr 2017 14:29:13 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_WWXv1e+fY1oxKlKIq6TXeQ)" Received: from demo-wifi.coreoutside.org ([17.227.5.3]) by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OP100JYMD0OOK70@nwk-mmpp-sz09.apple.com>; Wed, 26 Apr 2017 14:29:13 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <89333EE4-4F8F-4206-AD61-6352C57AFBE7@apple.com> Date: Wed, 26 Apr 2017 14:29:12 -0700 In-reply-to: Cc: Tero Kivinen , ipsecme-chairs@ietf.org, ipsec@ietf.org, Mirja Kuehlewind , The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org To: Eric Rescorla References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <22784.31378.631303.102297@fireball.acr.fi> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FAYpaslyBhpcPivmsX7P2cYLVa8Psdu MePPRGaLF9c/Mlvs3/KCzWLmnA8sFkfPP2dzYPdYsuQnk8fhrwtZPFo+LmT1mPy4jTmAJYrL JiU1J7MstUjfLoEro2n9XLaCWzMZK15OuczawNhf38XIySEhYCJx8sl8RhBbSGANk8SJfQkw 8d+f1rF3MXIBxQ8ySty4sosVJMErICjxY/I9FhCbWSBMonnPW1aIoglMElP3bADq4OAQFpCQ 2LwnEaSGTUBF4vi3DcwgYV4BG4lfZ0RAyoUFJjBKvL42C6ycRUBV4scuLpByToFgiU8vPrOA 1DAL7GCUeHDtPxNIQkRAQeLXnxMsELu+MkpsXD+fBeJSWYnuhdOYQRISAs3sEn2fzzNPYBSa heTYWUiOhbC1JL4/agWKcwDZ8hIHz8tChDUlnt37xA5ha0s8eXeBdQEj2ypG4dzEzBzdzDwj Y73EgoKcVL3k/NxNjKCoWs0kvoPx82vDQ4wCHIxKPLwRxxgihVgTy4orcw8xSnOwKInzNu34 HyEkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcdKTnXx1VdvC0qxdF85pjjadddEh8mS0651z O9IvbJmUrrtkJ897bd7UdqdnRr6nTrnrWF26emSej8lRxis7T7Onr4m5YvtyncLdpK97JQ5/ 2xs4UU1gpXepJNesfXO+ddwvsZQ6JvTs1fPO+2rPN/yOVDoRfNB1tt8e7sYj8eEVRScP8bOG HVViKc5INNRiLipOBADXawnNiwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUi2FAcoKspyBhp8P6CisX7P2cYLVa8Psdu MePPRGaLF9c/Mlvs3/KCzWLmnA8sFkfPP2dzYPdYsuQnk8fhrwtZPFo+LmT1mPy4jTmAJYrL JiU1J7MstUjfLoEro2n9XLaCWzMZK15OuczawNhf38XIySEhYCLx+9M69i5GLg4hgYOMEjeu 7GIFSfAKCEr8mHyPBcRmFgiTaN7zlhWiaAKTxNQ9G4A6ODiEBSQkNu9JBKlhE1CROP5tAzNI mFfARuLXGRGQcmGBCYwSr6/NAitnEVCV+LGLC6ScUyBY4tOLzywgNcwCOxglHlz7zwSSEBFQ kPj15wQLxK6vjBIb189ngbhUVqJ74TTmCYz8s5DcNwvJfRC2lsT3R61AcQ4gW17i4HlZiLCm xLN7n9ghbG2JJ+8usC5gZFvFKFCUmpNYaaaXWFCQk6qXnJ+7iREcBYVROxgbllsdYhTgYFTi 4XXYyBApxJpYVlyZe4hRgoNZSYRX4yVQiDclsbIqtSg/vqg0J7X4EONERqAvJzJLiSbnA2M0 ryTe0MTEwMTY2MzY2NzEnJbCSuK8c98CXSSQnliSmp2aWpBaBHMUEwenVAMjX1q+7oZN8TJX rEQVYyoK2tWLU5a9Omjn/ufyQ9bSTKdjBpWPWPdUH7k8q8ucYzvDu2n+a6IjF7ZcbecJqjty 71eng6VxzIHTfmeXxqvuMJzu94/rnojVYe5Vb6oK2tT8HhxQNSg6cvZKWGT8me/Cm5//7/Sq ONaU8uPJ9jIDfokO2SotziglluKMREMt5qLiRAAZB1PO9QIAAA== Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 21:29:20 -0000 --Boundary_(ID_WWXv1e+fY1oxKlKIq6TXeQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT > On Apr 26, 2017, at 12:51 PM, Eric Rescorla wrote: > > AFAICT there are two separate issues: > > - The use of 4500, which, as Tero says, we can just update the registry to point to this document for. > - The use of 443, which seems more complicated > > WRT 443, I would assert the following facts: > > - It's not awesome that people use 443 (though understandable because of overly-aggressive firewalls) > - People aren't going to stop using 443 (because it goes through NATs well) > > Generally, I think it's more useful for documents to reflect reality, even if we don't like that reality, > and 443 only appears in the appendix, so that seems fairly innocuous to me. Perhaps we can > leave the 443 in the appendix with some note like: > > "Note: While port 4500 is the reserved port for this protocol, some existing implementations > also use port 443. The Stream Prefix provides some mitigation against cross-protocol > attacks in this case, however, the use of port 443 is NOT RECOMMENDED" > > What would people think about that? That sounds good to me. I think we may want to mention that the Stream Prefix is used to distinguish from any other protocols running on port 4500, etc, not really specifically to 443. > > Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be wiggle room > to specify ALPN here? Or maybe a longer prefix? The document's text regarding ALPN is in section 4: "Although some framing protocols do support negotiating inner protocols, the stream prefix should always be used in order for implementations to be as generic as possible and not rely on other framing protocols on top of TCP." The idea is that we don't want to use TLS as a wrapper whenever possible. An implementation on an IKE server may be behind a proxy or another process that's terminating the TLS or raw TCP, and passing the inner stream along. In that case, we wanted a standard way to put IKE and ESP in a stream, not relying on an outer protocol's details. I'm perfectly open to using another prefix value; if you have a suggestion for a longer value, that would be great! Thanks, Tommy > > -Ekr > > > On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen > wrote: > Tommy Pauly writes: > > > ---------------------------------------------------------------------- > > > DISCUSS: > > > ---------------------------------------------------------------------- > > > > > > This draft suggests that ports that are assigned to other services can > > > simply be used. This is not okay. If a port is assigned to a certain > > > service, this service and/or the respective RFC defines how this port is > > > used. Simply changing the specified behavior by requiring a check for a > > > magic number cannot be done without updating the RFC that the port > > > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as > > > the IANA registry would need to be updated. > > > > At this point, the only portion of the document that mentions a port > > other than 500 and 4500 is the appendix. We recommend that 4500 is > > used as the port for TCP encapsulation. The IANA registry for > > 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947; > > that document does not explain how TCP is to be used, so the > > reference should be updated to point to the document on TCP > > encapsulation. > > I already explained this in long email to the Joe and Paul, but > noticed that those emails did not go to to the IESG, so this is mostly > cut & paste of my previous email. This does not cover anything about > using any other ports, but covers the case about the IANA allocations > for TCP/4500 and UPD/4500. > > ---------------------------------------------------------------------- > Paul Wouters writes: > > On Tue, 25 Apr 2017, Joe Touch wrote: > > > Every bit pattern, including those using magic numbers, is already > > > owned and under the control of each assigned port. It is not > > > appropriate for any new service to hijack that pattern as having a > > > different meaning UNLESS explicitly updating the service on > > > that port. > > > > > > A simple summary of what needs to change, in 2119-language: > > > > > > - this approach MUST NOT be described as applying to any > > > assigned number unless also updating the associated RFC > > > > So it should add an Updates: RFC-3947 > > Not really. It does not update RFC3947 as it does not change the > obsoleted protocol defined in the RFC3947. It does define way to > extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On > the other hand RFC3947 should have been obsoleted when we obsoleted > IKEv1, as that document only defines how to do IKEv1 NAT traversal > negotiation, and the IKEv2 NAT traversal negotation is described in > main IKEv2 RFC (RFC7296). > > > It's a little weird. 3947 reserved TCP 4500, but did not specify how > > to actually use TCP at all. It seems it was mostly preventatively > > reserved. > > The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500 > and UDP/4500 references from individual user to the RFC3947, so that > IETF will have change control over the ports. I.e., those ports were > allocated before RFC3947 came out, and they were used for several > different non-interoperable versions of the NAT traversals, which then > evolved to the standard version we define in RFC3947. We decided to > reassign both TCP and UDP port 4500 to RFC3947 so it would be clear > for what use they will be used. Also we commonly reserve both TCP and > UDP ports for same number just in case someone defines a way to run > the protocol over other transport protocol in the future... > > RFC3947 does not define anything over TCP/4500. Actually RFC3947 does > not define anything over the UDP/4500 either, it is the RFC3948 that > does that. The RFC3947 just says, we use the format defined in the > RFC3948 over the UDP/4500, but is silent about the TCP/4500. > > RFC3947 is efficiently obsoleted, as it only defines the way to do NAT > traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2 > (originally RFC4306, and now RFC7296). So the RFC3947 should have been > marked as obsoleted by RFC4306. I am not sure if we want to do that in > this late. > > So my proposal is update the IANA port registry for both UDP/4500 and > TCP/4500 as follows: > > Keyword Decimal Description Reference > ------- ------- ----------- --------- > ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFCXXXX] > ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3948], [RFC7296] > > (RFCXXXX being this RFC). > > Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the > RFC3948 actually defines the protocol used over the port. RFC3947 > defines the IKEv1 negotiation over the UDP port 500 and 4500, but for > IKEv2 this is already defined in the RFC7296. > > The RFC3947 could either be left as it is now, or marked as being > obsoleted by this or RFC4306, or RFC7296 or whatever. Updating > document which is effectively already obsoleted, is just wrong... > -- > kivinen@iki.fi > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Boundary_(ID_WWXv1e+fY1oxKlKIq6TXeQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
On Apr 26, 2017, at 12:51 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

AFAICT there are two separate = issues:

- The = use of 4500, which, as Tero says, we can just update the registry to = point to this document for.
- The use of 443, which = seems more complicated

WRT 443, I would assert the following facts:

- It's not awesome that = people use 443 (though understandable because of overly-aggressive = firewalls)
- People aren't going to stop using 443 = (because it goes through NATs well)

Generally, I think it's more useful for = documents to reflect reality, even if we don't like that = reality,
and 443 only appears in the appendix, so = that seems fairly innocuous to me. Perhaps we can
leave the 443 in the appendix with some note like:

"Note: While port 4500 = is the reserved port for this protocol, some existing = implementations
also use port 443. The Stream = Prefix provides some mitigation against cross-protocol
attacks in this case, however, the use of port 443 is NOT = RECOMMENDED"
What would people think about = that?

That = sounds good to me. I think we may want to mention that the Stream Prefix = is used to distinguish from any other protocols running on port 4500, = etc, not really specifically to 443.


Tommy, Tero, the stream = prefix doesn't seem totally ideal. Would there be wiggle room
to specify ALPN here? Or maybe a longer = prefix?

The = document's text regarding ALPN is in section 4:

"Although some framing protocols do support = negotiating inner protocols, the stream prefix should always be used in = order for implementations to be as generic as possible and not rely = on other framing protocols on top of TCP."

The idea is that we don't want to use TLS as a = wrapper whenever possible. An implementation on an IKE server may be = behind a proxy or another process that's terminating the TLS or raw TCP, = and passing the inner stream along. In that case, we wanted a standard = way to put IKE and ESP in a stream, not relying on an outer protocol's = details.

I'm perfectly open to using = another prefix value; if you have a suggestion for a longer value, that = would be great!

Thanks,
Tommy


-Ekr


On Wed, = Apr 26, 2017 at 3:46 AM, Tero Kivinen <kivinen@iki.fi> wrote:
Tommy Pauly writes:
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > This draft suggests that ports that are assigned to other = services can
> > simply be used. This is not okay. If a port is assigned to a = certain
> > service, this service and/or the respective RFC defines how = this port is
> > used. Simply changing the specified behavior by requiring a = check for a
> > magic number cannot be done without updating the RFC that the = port
> > assignment belongs to. Also for the use of 4500/tcp RFC3948 as = well as
> > the IANA registry would need to be updated.
>
> At this point, the only portion of the document that mentions a = port
> other than 500 and 4500 is the appendix. We recommend that 4500 = is
> used as the port for TCP encapsulation. The IANA registry for
> 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947;
> that document does not explain how TCP is to be used, so the
> reference should be updated to point to the document on TCP
> encapsulation.

I already explained this in long email to the Joe and Paul, = but
noticed that those emails did not go to to the IESG, so this is = mostly
cut & paste of my previous email. This does not cover anything = about
using any other ports, but covers the case about the IANA allocations
for TCP/4500 and UPD/4500.

----------------------------------------------------------------------
Paul Wouters writes:
> On Tue, 25 Apr 2017, Joe Touch wrote:
> > Every bit pattern, including those using magic numbers, is = already
> > owned and under the control of each assigned port. It is = not
> > appropriate for any new service to hijack that pattern as = having a
> > different meaning UNLESS explicitly updating the service on
> > that port.
> >
> > A simple summary of what needs to change, in 2119-language:
> >
> >    - this approach MUST NOT be described as applying = to any
> >      assigned number unless also updating the = associated RFC
>
> So it should add an Updates: RFC-3947

Not really. It does not update RFC3947 as it does not change the
obsoleted protocol defined in the RFC3947. It does define way to
extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
the other hand RFC3947 should have been obsoleted when we obsoleted
IKEv1, as that document only defines how to do IKEv1 NAT traversal
negotiation, and the IKEv2 NAT traversal negotation is described in
main IKEv2 RFC (RFC7296).

> It's a little weird. 3947 reserved TCP 4500, but did not specify = how
> to actually use TCP at all. It seems it was mostly = preventatively
> reserved.

The reason RFC3947 reserved TCP/4500 was that it updated both = TCP/4500
and UDP/4500 references from individual user to the RFC3947, so that
IETF will have change control over the ports. I.e., those ports were
allocated before RFC3947 came out, and they were used for several
different non-interoperable versions of the NAT traversals, which = then
evolved to the standard version we define in RFC3947. We decided to
reassign both TCP and UDP port 4500 to RFC3947 so it would be clear
for what use they will be used. Also we commonly reserve both TCP and
UDP ports for same number just in case someone defines a way to run
the protocol over other transport protocol in the future...
=
RFC3947 does not define anything over TCP/4500. Actually RFC3947 does
not define anything over the UDP/4500 either, it is the RFC3948 that
does that. The RFC3947 just says, we use the format defined in the
RFC3948 over the UDP/4500, but is silent about the TCP/4500.

RFC3947 is efficiently obsoleted, as it only defines the way to do = NAT
traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2
(originally RFC4306, and now RFC7296). So the RFC3947 should have = been
marked as obsoleted by RFC4306. I am not sure if we want to do that = in
this late.

So my proposal is update the IANA port registry for both UDP/4500 and
TCP/4500 as follows:

         Keyword      =  Decimal    Description          = Reference
         -------      =  -------    -----------          = ---------
         ipsec-nat-t   4500/tcp  =  IPsec NAT-Traversal  [RFCXXXX]
         ipsec-nat-t   4500/udp  =  IPsec NAT-Traversal  [RFC3948], [RFC7296]

(RFCXXXX being this RFC).

Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the
RFC3948 actually defines the protocol used over the port. RFC3947
defines the IKEv1 negotiation over the UDP port 500 and 4500, but for
IKEv2 this is already defined in the RFC7296.

The RFC3947 could either be left as it is now, or marked as being
obsoleted by this or RFC4306, or RFC7296 or whatever. Updating
document which is effectively already obsoleted, is just wrong...
--
kivinen@iki.fi


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

= --Boundary_(ID_WWXv1e+fY1oxKlKIq6TXeQ)-- From nobody Wed Apr 26 18:27:16 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B958A12949E; Wed, 26 Apr 2017 18:27:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo3BzEZKTo79; Wed, 26 Apr 2017 18:27:12 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002: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 ADE781294A6; Wed, 26 Apr 2017 18:27:12 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id k11so8937589ywb.1; Wed, 26 Apr 2017 18:27:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E8wFmA7qaRmhQfSG27R0iFHBb7v/w5Or6IyQ7hu6aJQ=; b=fOk7T0YI96++iNNHZXK7mvmf/7B1rPyKrqZFFuM/MEriQJeYDup0+CW+rM+wIG9hPS E01XS9saRrEtEpf5cvIRW0i6N3YrSavzhqcqzBV2wno7g+xDUv5ptePicRbvrEpOHV8L BZSy0fIg7hiSi0h2IPy5jpIBY9W9ZZKxembidECuT4D4V333ij6o81QWcgRqKOIqhhwC NcgOWvXDmfr68y6dc0kuINNA5GeZqyzuMW/uMvtle+n/o3o8C5PLmk71d2jMh6rRdtsQ 91zrcMDHrPdXchxLavu1tlItBe9VEUE+vuIWGySAWMwG7qK9dVGZsmyR0A033oB1l9jK W3vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E8wFmA7qaRmhQfSG27R0iFHBb7v/w5Or6IyQ7hu6aJQ=; b=n2Ans5RORVe2rmo7AfpdamFNZfAEIQsVHp0G67Y3QBx9+hWHjMtvX1akMqm6M2W5bX xWRSDmV3/IZyztTp709lES1+QzuPY4T4lxCE8gvAIXlvKcni6OU0PvLfygPuQGyjyrk6 BC1CGobpyE5qcR1UvVkWadSCM0GZLlJ5Ia3Rpkym1Ebty8ly8lz3bX6rExpybHxr7p3g QStzHbor1rZO4ntze8SNUhj3RaG6lPbm1Ud+VlxCPMw3d5WF+EG25I56ttiOMFxn67lK ta4i+K4Dy20jAqGyvLOqzbheeT5gyi4WqJKu/dvcFwJpiwsfqgbSW+la1YOR9Lov9//T m7lQ== X-Gm-Message-State: AN3rC/5w40vZvfeXb5SEv+Dxu8r6LOcH5VYMSsSmEz0wGFeZVAsBTjgQ UumnaYd1a1KCWbUi/eJlmWdu1CLzMA== X-Received: by 10.13.221.208 with SMTP id g199mr2356873ywe.21.1493256431801; Wed, 26 Apr 2017 18:27:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Wed, 26 Apr 2017 18:27:11 -0700 (PDT) Received: by 10.37.161.198 with HTTP; Wed, 26 Apr 2017 18:27:11 -0700 (PDT) In-Reply-To: <9643E604-8D2E-43FF-AD63-A78E28D4FC6A@apple.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <0131E919-3B21-4211-B5ED-9B852D77CDF5@nostrum.com> <166762EE-0C66-4CB9-AB08-0FD8E15253B6@nostrum.com> <380A837C-3062-444A-B76F-430785AB3CD0@apple.com> <834CF872-4D53-4B02-A791-4A7C77771D71@nostrum.com> <9643E604-8D2E-43FF-AD63-A78E28D4FC6A@apple.com> From: Spencer Dawkins at IETF Date: Wed, 26 Apr 2017 20:27:11 -0500 Message-ID: To: Tommy Pauly Cc: Paul Wouters , iesg@ietf.org, Kathleen Moriarty , ipsecme-chairs@ietf.org, "ipsec@ietf.org" , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c06e3fa2d1d75054e1bdbd3 Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 01:27:16 -0000 --94eb2c06e3fa2d1d75054e1bdbd3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Apr 26, 2017 16:23, "Tommy Pauly" wrote: On Apr 26, 2017, at 1:08 PM, Ben Campbell wrote: On Apr 26, 2017, at 2:58 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: Hi, Ben and Tommy, On Wed, Apr 26, 2017 at 1:36 PM, Ben Campbell wrote: On Apr 26, 2017, at 12:50 PM, Tommy Pauly wrote: Hi Ben, Thanks for the comments! Your point about the line in Section 6 not making sense is definitely a good point. How about this text (changes in bold): If a TCP connection is being used to resume a previous IKE session, the TCP Responder can recognize the session using either the IKE SPI from an encapsulated IKE message or the ESP SPI from an encapsulated ESP message. If the session had been fully established previously, it is suggested that the TCP Originator send an UPDATE_SA_ADDRESSES message if MOBIKE is supported, or an INFORMATIONAL message (a keepalive) otherwise. [The TCP Responder MUST NOT accept any messages for the existing IKE session on new an incoming connection unless that connection begins with the stream prefix. If either the TCP Originator or TCP Responder cannot parse valid IKE or ESP messages on a TCP encapsulation connection that was started with a valid stream prefix, it MUST close the TCP connection.] If there is instead a syntax issue within an IKE message, an implementation MUST send the INVALID_SYNTAX notify payload and tear down the IKE SA as usual, rather than tearing down the TCP connection directly. Thanks, Tommy That looks good to me. I will clear, with the assumption this or similar edits will make it into the draft. Does The TCP Responder MUST NOT accept any messages for the existing IKE session on new an incoming connection unless that connection begins with the stream prefix. parse for you guys? I get stuck at "on new an incoming=E2=80=9D. I=E2=80=99m guessing that=E2=80=99s an edit-o from. Maybe it should be =E2= =80=9Con a new incoming=E2=80=9D? Yes, I meant "on a new incoming connection". Sorry! Thanks for clarifying. I thought I was experiencing telechat blindness ;-) Spencer Thanks, Tommy Spencer Thanks! Ben. On Apr 26, 2017, at 8:35 AM, Ben Campbell wrote: By the way, the DISCUSS vs COMMENT framing has gotten lost from the thread. Only the first point was part of the DISCUSS, the rest are non-binding comments. And I think the DISCUSS point is moving in the right direction, pending a text proposal. Thanks! Ben. On Apr 26, 2017, at 8:57 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell wrote: On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: Thanks for the quick response Paul, a few questions... On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters wrote: On Tue, 25 Apr 2017, Kathleen Moriarty wrote: IIUC, the entire point of having the stream prefix is to allow the TCP responder to demux between this protocol, and some other protocol that would normally run on that port. Saying it MUST close the TCP session seems to completely remove that value. I assume people meant to allow the respondent to delegate a stream out to some other protocol handler if the prefix is not present? I believe that this is because there is presumed to be no other service operating on the listening port (assuming a VPN concentrator), but that's not explicitly stated either. Vendors tend to run TLS on the IKE/IPsec machine, either to offer one of the other kinds of SSL VPNs or as the administration interface or user interface. OK, sounds like I didn't help here, so the editors should propose text to address this gap. I think we are on the right track here, pending proposed text. -- 2nd to last paragraph: "This document leaves the selection of TCP ports up to implementations." I suspect "configurable local policy" would make more sense. Leaving it up to "implementations" leaves open the chance of different implementations making non-intersecting port choices, which doesn't help interoperability. This may go more into unexplained assumptions... the clients authorized to connect to the server would need to know the correct port to establish a session and would be given that information specific to the implementation. With this assumption, the above should be fine... but editors/AD/WG, please correct me if I am wrong. I am pretty sure what is meant is "configuration" and not "implementation". Is that in response to me being wrong in my assumption or the draft should say configuration (I think it's the latter, but important to check)? We are probably splitting hairs on the meaning of =E2=80=9Cimplementation= =E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. (and maybe =E2=80=9Cdeployment=E2=80=9D). = I was thinking of =E2=80=9Cimplementation=E2=80=9D as being what developers do, and =E2=80=9C= configuring/deploying=E2=80=9D as what operators do. But I am aware that operators sometimes talk about =E2=80=9Cimplementing=E2=80=9D a system. So my point was that I assume for purposes of interoperability that a general purpose client or server would allow the port to be changed in the field. -4, first paragraph: What is the expected behavior from a peers that do not support this spec when they receive a TCP stream with the magic number on a port for some other protocol? Maybe listing assumptions up front in the draft would help _IF_ the assumption is that the listening server is a VPN concentrator that wouldn't be listening for other services. Support for TCP would be based on preconfiguration, so the client knows this out-of-band. It cannot be discovered during negotiation, because it is assumed the regular UDP ports are blocked, which is the only reason to attempt TCP to begin with. I read the draft with this assumption in mind (see above), but this should be clarified in the document to address this question from Ben. Imagine a misconfigured client opening a connection to an web server on port 80, expecting to find a VPN service. What happens? I think that a consequence of the design approach to allow this to run over ports assigned to other protocols is that you need to consider that sort of thing. - Appendix A: Doesn't the use of the NULL cipher invalidate one of the primary reasons to use TLS? (Namely to obscure the fact that this is not HTTP, or whatever other protocol is assigned to the port?) Editors/AD correct me if I am wrong, but... No, if TLS is used with a NULL cipher, it'll pass inspection of a middle box validating the protocol. This doesn't need to use the cipher as it's negotiating the IPsec connection. right, TLS happens to use encryption to get out, but it is not the encryption of the actual IKE/IPsec protocols, which keep using their own channel negotiations. I think clarifying this further in the draft would be helpful. I agree, because I=E2=80=99m still confused :-) To clarify my question: Assuming the case of TLS encapsulation to the HTTPS port across a DPI middle-box that hates that sort of thing. If TLS uses the NULL cipher, can the middlebox not tell that the protocol over TLS is not HTTP? (I will defer to the experts.) IPsec WG participants should chime in here, Yoav may know for sure with his background, I'm sure others too. I'd guess that a DPI would not pick it up as the protocol inspection most likely assumes when it sees TLS, that the traffic is encrypted and looks no further for inspection/blocking purposes. The middleboxes that do some protocol inspection aren't like the ones from 15-20 years ago that dug into the protocol (blocking FTP commands, etc.). The use of TCP 443 for this has been in place for a decade or two, Google QUIC also uses TCP 443, and I'm sure other services do too. So tunneling does work. For purity, are we worried if this is TLS or HTTP/TLS (as the port usage specifies) or does that matter? -- Best regards, Kathleen _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --94eb2c06e3fa2d1d75054e1bdbd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Apr 26, 2017 16:23, "Tommy Pauly" <tpauly@apple.com> wrote:


On A= pr 26, 2017, at 1:08 PM, Ben Campbell <ben@nostrum.com> wrote:


On Apr 26, 2017, at= 2:58 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wr= ote:

Hi, Ben and Tommy,

On Wed, Apr 26, 2017 at 1:36 PM, Ben = Campbell <ben@nostr= um.com> wrote:

On Apr 26, 2017, at = 12:50 PM, Tommy Pauly <tpauly@apple.com> wrote:

Hi Ben,

Thanks for the c= omments! Your point about the line in Section 6 not making sense is definit= ely a good point. How about this text (changes in bold):

If a TCP co= nnection is being used to resume a previous IKE session,
=C2=A0=C2=A0the= TCP Responder can recognize the session using either the IKE SPI
=C2=A0= =C2=A0from an encapsulated IKE message or the ESP SPI from an encapsulated<= br>=C2=A0=C2=A0ESP message.=C2=A0 If the session had been fully established= previously,
=C2=A0=C2=A0it is suggested that the TCP Originator send an= UPDATE_SA_ADDRESSES
=C2=A0=C2=A0message if MOBIKE is supported, or an I= NFORMATIONAL message (a
=C2=A0=C2=A0keepalive) otherwise. =C2=A0[The TCP= Responder MUST NOT accept any messages
=C2=A0=C2=A0for the existing IKE= session on new an incoming connection unless that connection
=C2=A0=C2= =A0begins with the stream prefix. If either the TCP Originator or TCP Respo= nder
=C2=A0=C2=A0cannot parse valid IKE or ESP messages on a TCP encapsu= lation connection
=C2=A0=C2=A0that was started with a valid stream prefi= x, it MUST close the TCP connection.]
=C2=A0=C2=A0If there is instead a = syntax issue within an IKE
=C2=A0=C2=A0message, an implementation MUST s= end the INVALID_SYNTAX notify
=C2=A0=C2=A0payload and tear down the IKE = SA as usual, rather than tearing down
=C2=A0=C2=A0the TCP connection dir= ectly.

Thanks,
Tommy

That looks good to me. I= will clear, with the assumption this or similar edits will make it into th= e draft.

Does=C2=A0

The TCP Responder MUST NOT accept any messages=C2=A0=C2=A0for the existing IKE session on new an incoming connection unl= ess that connection
=C2=A0=C2=A0begins with the stream prefix.=C2=A0

pars= e for you guys? I get stuck at "on new an incoming=E2=80=9D.


I=E2=80=99m guessing that=E2=80= =99s an edit-o from. Maybe it should be =E2=80=9Con a new incoming=E2=80=9D= ?

Yes, I meant "on a new = incoming connection". Sorry!

Thanks for clarifying. I tho= ught I was experiencing telechat blindness ;-)

<= /div>
Spencer


Thanks,<= /div>
Tommy


Spencer


Thanks!

Ben.


On Apr 26, 2017, a= t 8:35 AM, Ben Campbell <ben@nostrum.com> wrote:

By the way, the DISCUSS vs COMM= ENT framing has gotten lost from the thread. Only the first point was part = of the DISCUSS, the rest are non-binding comments. And I think the DISCUSS = point is moving in the right direction, pending a text proposal.

Tha= nks!

Ben.

On Apr 26, 2017, at 8:57 = AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell <ben@nostrum.com> wrote:

On Apr 25, 2017, at 9:38 = PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Thanks for the quick response Paul, a few questions...

On Tue,= Apr 25, 2017 at 10:18 PM, Paul Wouters <paul@nohats.ca> wrote:
On Tue, 25 Apr 2017, Kathleen Moriarty wrote:

IIUC, the entire point of having the st= ream prefix is to allow the TCP
responder to demux between this protocol= , and some other protocol that
would normally run on that port. Saying i= t MUST close the TCP session
seems to completely remove that value. I as= sume people meant to allow the
respondent to delegate a stream out to so= me other protocol handler if the
prefix is not present?


I believe that this is because there is presumed to be no other
= service operating on the listening port (assuming a VPN concentrator),
b= ut that's not explicitly stated either.


Vendors= tend to run TLS on the IKE/IPsec machine, either to offer one of
the ot= her kinds of SSL VPNs or as the administration interface or
user interfa= ce.

OK, sounds like I didn't help here, so the edit= ors should propose text
to address this gap.

I think= we are on the right track here, pending proposed text.



<= blockquote type=3D"cite">-- 2nd to last paragraph: "This document leav= es the selection of TCP
ports up to implementations."
I suspect = "configurable local policy" would make more sense. Leaving it
= up to "implementations" leaves open the chance of different
im= plementations making non-intersecting port choices, which doesn't help<= br>interoperability.


This may go more into unexplai= ned assumptions... the clients
authorized to connect to the server would= need to know the correct
port to establish a session and would be given= that information
specific to the implementation.=C2=A0 With this assump= tion, the above
should be fine... but editors/AD/WG, please correct me i= f I am wrong.


I am pretty sure what is meant is &qu= ot;configuration" and not "implementation".
=
Is that in response to me being wrong in my assumption or the draft
= should say configuration (I think it's the latter, but important to
= check)?

We are probably splitting hairs on the meaning = of =E2=80=9Cimplementation=E2=80=9D vs =E2=80=9Cconfiguration=E2=80=9D. (an= d maybe =E2=80=9Cdeployment=E2=80=9D). I was thinking of =E2=80=9Cimplement= ation=E2=80=9D as being what developers do, and =E2=80=9Cconfiguring/deploy= ing=E2=80=9D as what operators do. But I am aware that operators sometimes = talk about =E2=80=9Cimplementing=E2=80=9D a system.

So my point was = that I assume for purposes of interoperability that a general purpose clien= t or server would allow the port to be changed in the field.



-4, first paragraph: What is the expected beh= avior from a peers that do
not support this spec when they receive a TCP= stream with the magic
number on a port for some other protocol?


Maybe listing assumptions up front in the draft would help= _IF_ the
assumption is that the listening server is a VPN concentrator = that
wouldn't be listening for other services.

<= br>Support for TCP would be based on preconfiguration, so the client knows<= br>this out-of-band. It cannot be discovered during negotiation, becauseit is assumed the regular UDP ports are blocked, which is the only
reas= on to attempt TCP to begin with.

I read the draft with = this assumption in mind (see above), but this
should be clarified in the= document to address this question from Ben.

Imagine a = misconfigured client opening a connection to an web server on port 80, expe= cting to find a VPN service. What happens? I think that a consequence of th= e design approach to allow this to run over ports assigned to other protoco= ls is that you need to consider that sort of thing.


- Appendix A: Doesn't the use of the NULL cipher inval= idate one of the
primary reasons to use TLS? (Namely to obscure the fact= that this is not
HTTP, or whatever other protocol is assigned to the po= rt?)


Editors/AD correct me if I am wrong, but...No, if TLS is used with a NULL cipher, it'll pass inspection of a
m= iddle box validating the protocol.=C2=A0 This doesn't need to use thecipher as it's negotiating the IPsec connection.

=
right, TLS happens to use encryption to get out, but it is not the
e= ncryption of the actual IKE/IPsec protocols, which keep using their
own = channel negotiations.

I think clarifying this further i= n the draft would be helpful.

I agree, because I=E2=80= =99m still confused :-)

To clarify my question: Assuming the case of= TLS encapsulation to the HTTPS port across a DPI middle-box that hates tha= t sort of thing. If TLS uses the NULL cipher, can the middlebox not tell th= at the protocol over TLS is not HTTP? (I will defer to the experts.)

IPsec WG participants should chime in here, Yoav may know for= sure
with his background, I'm sure others too.

I'd guess= that a DPI would not pick it up as the protocol inspection
most likely = assumes when it sees TLS, that the traffic is encrypted
and looks no fur= ther for inspection/blocking purposes.=C2=A0 The
middleboxes that do som= e protocol inspection aren't like the ones from
15-20 years ago that= dug into the protocol (blocking FTP commands,
etc.).

The use of = TCP 443 for this has been in place for a decade or two,
Google QUIC also= uses TCP 443, and I'm sure other services do too. So
tunneling does= work.

For purity, are we worried if this is TLS or HTTP/TLS (as the= port
usage specifies) or does that matter?






--

Best regards,
Kathleen



_________________________________________= ______
IPsec mailing list<= br style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-var= iant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;= text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">IPsec@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/ipsec
=


--94eb2c06e3fa2d1d75054e1bdbd3-- From nobody Thu Apr 27 01:32:44 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBCE127097 for ; Thu, 27 Apr 2017 01:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHunOwT-QxVA for ; Thu, 27 Apr 2017 01:32:40 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1614D126B6D for ; Thu, 27 Apr 2017 01:32:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=rr7rArUzcgUqhu6bs9S4K/UKjko609N5fDi0B4qTUPEQUngQYhI5VKqO4vicYbsVfPdtepyUqi5/P6dO9fmns/Nb08ppO9UZnBssb6ASmUtyXEltQQ8zFgNbXpKfO0GgrVq+aqok9mxk1RSkvQnDSz8AcpBmvK3vKfJ0WIQYqCE=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 9662 invoked from network); 27 Apr 2017 10:32:38 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 10:32:37 +0200 To: Tommy Pauly References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, kivinen@iki.fi From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> Date: Thu, 27 Apr 2017 10:32:37 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170427083238.9653.50000@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 08:32:43 -0000 Hi Tommy, please see below, only on the first point for now. On 26.04.2017 05:28, Tommy Pauly wrote: > > >> On Apr 25, 2017, at 5:48 AM, Mirja Kühlewind wrote: >> >> Mirja Kühlewind has entered the following ballot position for >> draft-ietf-ipsecme-tcp-encaps-09: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> This draft suggests that ports that are assigned to other services can >> simply be used. This is not okay. If a port is assigned to a certain >> service, this service and/or the respective RFC defines how this port is >> used. Simply changing the specified behavior by requiring a check for a >> magic number cannot be done without updating the RFC that the port >> assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as >> the IANA registry would need to be updated. > > At this point, the only portion of the document that mentions a port other than 500 and 4500 is the appendix. We recommend that 4500 is used as the port for TCP encapsulation. The IANA registry for 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947; that document does not explain how TCP is to be used, so the reference should be updated to point to the document on TCP encapsulation. So at least section 11 talks about port 80 as well. It doesn't explicitly recommend to use it, but because it's discussed there I would say that this is implicitly the intention: "A network device that monitors up to the application layer will commonly expect to see HTTP traffic within a TCP socket running over port 80, if non-HTTP traffic is seen (such as TCP encapsulated IKE), this could be dropped by the security device." Further it's clear that the whole intention on the existence of section 4 is that you want to (mis)use ports that have been assigned for other services and are for that reason potentially not blocked. The (processing) problem here is that even if the bit pattern in section 4 is currently not used and unlikely to ever be used by the protocol that is officially assigned to the port, there is nothing that excludes a future protocol spec to use these bits (and there is also nothing that makes designer of these protocols aware that these bits are already in use by a different protocol on the same port). So the minimum you basically would need to do is to update all RFCs for protocols on ports that you may want to use (and probably also the IANA registry for these ports to add a refernce to this document) and say that it is not possible to use this bit patter for the protocol itself and all future version of it. Of course you probably would need to involve those working groups that maintain these protocols and I also not sure how happy those groups would be about such an update. I personally think that that is not a nice solution and if you e.g. want to use port 80 for IKE, you would need to define an IKE variant over HTTP/TCP. That doesn't sound great and I'm not sure if that a solution anybody would like to implement. I do see the problem you have and I understand why you selected the solution you have but that does contradict quite a bit the idea of the port registry and I don't think it's a safe and future prove solution. Even if people use this approach, I'm concern to publish it in an Standards Track RFC, but I guess that's a discussion the IESG would need to have. Mirja > > We can soften the references in the appendix to the fact that other ports may, in fact, be used. As for the configuration, it should state 4500 as the default, but allow peers to configure something else out-of-band if they want to modify behavior (which is standard even in UDP implementations of IKE). > >> >> Further, as also mentioned in the tsv-art review (Thanks Wes!), this >> draft does not sufficiently handle the case of TCP in TCP encapsulation. >> Here a copy of the tsv-art review: >> >> Reviewer: Wesley Eddy >> Review result: On the Right Track >> >> This document is clear and well-written. It can easily be implemented >> based on the description. >> >> There are a few additional issues that should be considered with >> advice to implementers in Section 12 on performance considerations: >> 1) Invisibility of packet loss - Inner protocols that require packet >> losses as a signal of congestion (e.g. TCP) will have a challenge due >> to not being able to see any packet losses since the outer TCP will >> repair them (unless sending into a full outer TCP socket buffer shows >> up back to the inner TCP as a packet loss?). > > Yes, this is definitely true. We try to capture that with the line: "This will make loss- > recovery of the inner TCP traffic less reactive and more prone to > spurious retransmission timeouts." > > However, this can certainly be expanded upon. > >> 2) Nesting of ECN - Inner TCP connections will not be able to use >> effectively ECN on the portion of the path covered by the outer TCP >> connection. > > Generally, IPsec tunnels will apply RFC 6040 for translating ECN markings between inner/outer packets. Since TCP encapsulation places the inner IP packets in a stream, there isn't a direct mapping. > > An implementation could try to roughly map, but it may be best to suggest that the ECN markings for inner and outer packets be left separate. What is your opinion? > >> 3) Impact of congestion response on aggregate - The general "TCP in >> TCP" problem is mentioned, and is mostly appropriate for a single >> flow. If an aggregate of flows is sharing the same outer TCP >> connection, there may be additional concerns about how the congestion >> response behavior impacts an aggregate of flows, since it may cause a >> shared delay spike even to low-rate flows rather than distributing >> losses proportional to per-flow throughput. > > Indeed. We can add further comments to that effect. > >> 4) Additional potential for bufferbloat - Since TCP does not bound >> latency, some applications in the IPsec-protected aggregate could >> drive latency of the shared connection up and impact the aggregate of >> flows that may include real-time applications. The socket buffer for >> the outer TCP connection might need to be limited in size to ensure >> some bounds? > > We can add a comment to suggest that the buffering should be limited on the outer connection if possible. > >> >> Not addressing these could lead to poor experiences in deployment, if >> implementations make wrong assumptions or fail to consider them. > > I do think all of these concerns go back to the overall recommendation of "use direct ESP or UDP Encapsulation whenever possible". Anything to help back up that point is great! > > Thanks, > Tommy >> >> In the security considerations section, there are several RFCs on >> mechanisms to increase robustness to RST attacks and SYN floods that >> could be mentioned if it's worthwhile. >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Apr 27 05:09:15 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4590129447; Thu, 27 Apr 2017 05:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8ooo-IEKLIF; Thu, 27 Apr 2017 05:09:12 -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 BD52C1293F5; Thu, 27 Apr 2017 05:09:11 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3RC96FP005479 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 15:09:06 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3RC95Gw002882; Thu, 27 Apr 2017 15:09:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22785.57185.696102.246674@fireball.acr.fi> Date: Thu, 27 Apr 2017 15:09:05 +0300 From: Tero Kivinen To: Ben Campbell Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org In-Reply-To: <2980CAE0-D03E-4C91-88E7-726A802F584E@nostrum.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <22784.32563.870450.167881@fireball.acr.fi> <2980CAE0-D03E-4C91-88E7-726A802F584E@nostrum.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:09:13 -0000 Ben Campbell writes: >=20 > > On Apr 26, 2017, at 6:06 AM, Tero Kivinen wrote: > >=20 > > Ben Campbell writes: > >> ------------------------------------------------------------------= ---- > >> COMMENT: > >> ------------------------------------------------------------------= ---- > >>=20 > >> Substantive Comments: > >>=20 > >> -3, first paragraph: > >> Are people confident there will never, ever be a need to demux pro= tocols > >> other than IKE and ESP=3F If not, this approach may paint people i= n a > >> corner in the future. I ask because we made similar choices with > >> DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an is= sue. > >> See RFC7983 for a discussion. (Note that this would have been a DI= SCUSS > >> point, but I think it's reasonably likely that there really won't = be > >> other protocols here. But I want to make sure people have thought = about > >> it.) > >=20 > > If we ever want to run other protocols there, we still have 255 > > reserved values we can use as Non-ESP marker. The reason the > > 0x00000000 is selected as Non-ESP marker in the UDP encapsulation (= and > > here) is because first four octets of the ESP packet are SPI, and S= PI > > MUST NOT be zero. Also numbers from 1 to 255 are "are reserved by t= he > > Internet Assigned Numbers Authority (IANA) for future use" in the > > RFC4303. > >=20 > > So if we need to run something else than IKE and ESP over that tunn= el > > we just reserve one of the other reserved IANA numbers for it and u= se > > it as protocol marker for this new protocol.=20 >=20 > Ah, I didn=E2=80=99t realize 1-255 were reserved. It might be worth a= > mention that if future protocols are added, their prefixes must be > registered with IANA. (I note that 2 are registered already.) I do not think it belongs to this document. This is not actually using reserved SPIs, but I think it should be enough to see that there is a way to extend this, but as we do not see the need for extension now, we do not need to think how we are going to do it. There are other ways of doing that extension also and everything depends what we really want to do. Trying to guess things now is not really useful. > Am I correct to assume the draft did not also add a prefix for ESP > is due to performance reasons=3F Doing so would completely avoid any > possible collisions between the prefix value and the SPI. Actually RFC3947/3948 original invented this method, and the reason we do not add prefix is to save 4 or 8 octets on every single ESP packet. The ESP header needs to be alinged to 4 or 8 octet boundary thus minimum overhead would be 4 or 8 octets (see RFC5840 for example, i.e., WESP adds extra header before ESP). There is no possibility with collisions with ESP, as ESP specifies that SPI zero is always reserved, and MUST NOT ever appear on the wire. Thus ESP packet with SPI of zero is invalid. As IKE packets are much less frequent than ESP packets (with ratio of million or billion to 1), it does not matter that we add some extra overhead to them. Also IKE payload does not need to be aligned so we can go with just 4 octets of overhead, and does not need to care about the IPv4 vs IPv6 alignment requirements. > Got it. I propose the following: >=20 > OLD: > The SPI field in the ESP header MUST NOT be a zero value.=E2=80=9D > NEW: > [RFC4303] forbids a value of zero in the SPI field. That is good change, I would recommend that authors do that change.=20 --=20 kivinen@iki.fi From nobody Thu Apr 27 05:33:55 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AF8127909; Thu, 27 Apr 2017 05:33:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lk7hqiTjlJ09; Thu, 27 Apr 2017 05:33:51 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 000021273B1; Thu, 27 Apr 2017 05:33:50 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id k11so14650940ywb.1; Thu, 27 Apr 2017 05:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rBc/TMJmCjLs7bbNanFqTcFz/eXZlYsUWXVgwfjD77o=; b=tWVvKUXzfngX12wLAeLFM2hB+cyD/ABeF7ymhDmLRe2nwtUwDXfN/m/NXHvOTKcVRu jMAZ0NH2ni/JRZ3HQz7SbVMta5rv5ib+B9RJyITUGQZ6O5khXaVYjK2rItX2enN9aho9 99Qi48tQmQuh183ED+yF48yhwIjbghz/T6gCQoKnCQgB/dsZZ7Qrci+tB1v3Y9ATh5qH EylHmK3NIeS0tHWdjUtYIFtALRYr77IsDeh9quxhBgFGJu0mNKgFILMd6fWeo1PyO/8+ 05yVpQdAPX/D/5Ihglt0YsAeL8vn/lqXeCxthyynwIrwa9dkMBTXztTC7Zn2aX27YKuz 1GJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rBc/TMJmCjLs7bbNanFqTcFz/eXZlYsUWXVgwfjD77o=; b=HvKJb0bxWtFa7BvSmsmZ0EP8Fzl7v6k9QmnR5tq/9lIPpvU+sN+qWG+rHITUb1o/os NzuachA9dxHgDuHOGHZzdbolnXTE4SUlNM9bRfCV7AWRJC8RbK2ai2RcIDhnJzQz410c 30idfHkBV203lVVb9on3Nh72kA1ICp8lcrQBe9KHE9cT1kB9L+bHXAUDgsrtCCFWjMSf H9uVVEn9Gbm2VoB/uOgjhxNfvDP9CRu1EQZQJ4DVKITzdHscfakBs8vilqD89n7BBPaf jtgi7076MJ1eOLpbwPZh3Kny1J//ex6R/qz0ix4nuh6k+wwX36iqnqMaamyAc5fkxpAV ho7A== X-Gm-Message-State: AN3rC/78v1Idg6LmiMUUiwrsskMLmJL4svrllUgVP915L34InqBxf4uN vN78W+ubtUT/SsLYyGxxM7j+HV0hFg== X-Received: by 10.129.129.197 with SMTP id r188mr4044230ywf.289.1493296430138; Thu, 27 Apr 2017 05:33:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Thu, 27 Apr 2017 05:33:49 -0700 (PDT) In-Reply-To: <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> From: Spencer Dawkins at IETF Date: Thu, 27 Apr 2017 07:33:49 -0500 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Tommy Pauly , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , Tero Kivinen Content-Type: multipart/alternative; boundary=94eb2c081298434b71054e252b56 Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:33:54 -0000 --94eb2c081298434b71054e252b56 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not my discuss, but since I'm also supposed to worry about ports :-) On Thu, Apr 27, 2017 at 3:32 AM, Mirja K=C3=BChlewind wrote: > Hi Tommy, > > please see below, only on the first point for now. > > On 26.04.2017 05:28, Tommy Pauly wrote: > >> >> >> On Apr 25, 2017, at 5:48 AM, Mirja K=C3=BChlewind = wrote: >>> >>> Mirja K=C3=BChlewind has entered the following ballot position for >>> draft-ietf-ipsecme-tcp-encaps-09: Discuss >>> >>> When responding, please keep the subject line intact and reply to all >>> email addresses included in the To and CC lines. (Feel free to cut this >>> introductory paragraph, however.) >>> >>> >>> Please refer to https://www.ietf.org/iesg/stat >>> ement/discuss-criteria.html >>> for more information about IESG DISCUSS and COMMENT positions. >>> >>> >>> The document, along with other ballot positions, can be found here: >>> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ >>> >>> >>> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> This draft suggests that ports that are assigned to other services can >>> simply be used. This is not okay. If a port is assigned to a certain >>> service, this service and/or the respective RFC defines how this port i= s >>> used. Simply changing the specified behavior by requiring a check for a >>> magic number cannot be done without updating the RFC that the port >>> assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as >>> the IANA registry would need to be updated. >>> >> >> At this point, the only portion of the document that mentions a port >> other than 500 and 4500 is the appendix. We recommend that 4500 is used = as >> the port for TCP encapsulation. The IANA registry for 4500/tcp is alread= y >> assigned to IPSec NAT Traversal in RFC 3947; that document does not expl= ain >> how TCP is to be used, so the reference should be updated to point to th= e >> document on TCP encapsulation. >> > > So at least section 11 talks about port 80 as well. It doesn't explicitly > recommend to use it, but because it's discussed there I would say that th= is > is implicitly the intention: > > "A network device that monitors up to the application layer will > commonly expect to see HTTP traffic within a TCP socket running over > port 80, if non-HTTP traffic is seen (such as TCP encapsulated IKE), > this could be dropped by the security device." > I understand Mirja's point, and I understand why the draft doesn't tie the protocol to one assigned port. > > Further it's clear that the whole intention on the existence of section 4 > is that you want to (mis)use ports that have been assigned for other > services and are for that reason potentially not blocked. > > The (processing) problem here is that even if the bit pattern in section = 4 > is currently not used and unlikely to ever be used by the protocol that i= s > officially assigned to the port, there is nothing that excludes a future > protocol spec to use these bits (and there is also nothing that makes > designer of these protocols aware that these bits are already in use by a > different protocol on the same port). So the minimum you basically would > need to do is to update all RFCs for protocols on ports that you may want > to use (and probably also the IANA registry for these ports to add a > refernce to this document) and say that it is not possible to use this bi= t > patter for the protocol itself and all future version of it. Of course yo= u > probably would need to involve those working groups that maintain these > protocols and I also not sure how happy those groups would be about such = an > update. > What I'm thinking, is that this isn't a problem we can solve, draft by draft. Assuming that https://datatracker.ietf.org/doc/rfc3986/referencedby/ is a reasonable proxy, the datatracker returns 775 documents that reference the RFC that defines the URI scheme, which includes https://tools.ietf.org/html/rfc3986#section-3.2.3, allowing the application to specify a port which (of course) could be assigned to another protocol in https://www.iana.org/assignments/service-names-port-numbers/service-names-p= ort-numbers.txt . That's a worst-case scenario, of course (some RFCs weren't deployed, some are probably obsoleted by other RFCs, etc.), but I'm betting the number of protocols with the same issue as HTTP(S) has here is somewhere in the hundreds. > > I personally think that that is not a nice solution and if you e.g. want > to use port 80 for IKE, you would need to define an IKE variant over > HTTP/TCP. That doesn't sound great and I'm not sure if that a solution > anybody would like to implement. > > I do see the problem you have and I understand why you selected the > solution you have but that does contradict quite a bit the idea of the po= rt > registry and I don't think it's a safe and future prove solution. Even if > people use this approach, I'm concern to publish it in an Standards Track > RFC, but I guess that's a discussion the IESG would need to have. So, yes, I agree with this, and suggest that we start that discussion on next week's informal telechat. But, to try to make progress on this Discuss ... The reason optional ports in URIs work, is that someone handed you a URI with that port number who has some reason to believe that the port number is OK to use with the host included in the URI. Is that a reasonable assumption about the way IPsec and IKE over TCP will be deployed? That no Initiator would assume that another host is an IKE Responder, without being configured to use that host? Curiously, Spencer > Mirja > > > >> We can soften the references in the appendix to the fact that other port= s >> may, in fact, be used. As for the configuration, it should state 4500 as >> the default, but allow peers to configure something else out-of-band if >> they want to modify behavior (which is standard even in UDP implementati= ons >> of IKE). >> >> >>> Further, as also mentioned in the tsv-art review (Thanks Wes!), this >>> draft does not sufficiently handle the case of TCP in TCP encapsulation= . >>> Here a copy of the tsv-art review: >>> >>> Reviewer: Wesley Eddy >>> Review result: On the Right Track >>> >>> This document is clear and well-written. It can easily be implemented >>> based on the description. >>> >>> There are a few additional issues that should be considered with >>> advice to implementers in Section 12 on performance considerations: >>> 1) Invisibility of packet loss - Inner protocols that require packet >>> losses as a signal of congestion (e.g. TCP) will have a challenge due >>> to not being able to see any packet losses since the outer TCP will >>> repair them (unless sending into a full outer TCP socket buffer shows >>> up back to the inner TCP as a packet loss?). >>> >> >> Yes, this is definitely true. We try to capture that with the line: "Thi= s >> will make loss- >> recovery of the inner TCP traffic less reactive and more prone to >> spurious retransmission timeouts." >> >> However, this can certainly be expanded upon. >> >> 2) Nesting of ECN - Inner TCP connections will not be able to use >>> effectively ECN on the portion of the path covered by the outer TCP >>> connection. >>> >> >> Generally, IPsec tunnels will apply RFC 6040 for translating ECN marking= s >> between inner/outer packets. Since TCP encapsulation places the inner IP >> packets in a stream, there isn't a direct mapping. >> >> An implementation could try to roughly map, but it may be best to sugges= t >> that the ECN markings for inner and outer packets be left separate. What= is >> your opinion? >> >> 3) Impact of congestion response on aggregate - The general "TCP in >>> TCP" problem is mentioned, and is mostly appropriate for a single >>> flow. If an aggregate of flows is sharing the same outer TCP >>> connection, there may be additional concerns about how the congestion >>> response behavior impacts an aggregate of flows, since it may cause a >>> shared delay spike even to low-rate flows rather than distributing >>> losses proportional to per-flow throughput. >>> >> >> Indeed. We can add further comments to that effect. >> >> 4) Additional potential for bufferbloat - Since TCP does not bound >>> latency, some applications in the IPsec-protected aggregate could >>> drive latency of the shared connection up and impact the aggregate of >>> flows that may include real-time applications. The socket buffer for >>> the outer TCP connection might need to be limited in size to ensure >>> some bounds? >>> >> >> We can add a comment to suggest that the buffering should be limited on >> the outer connection if possible. >> >> >>> Not addressing these could lead to poor experiences in deployment, if >>> implementations make wrong assumptions or fail to consider them. >>> >> >> I do think all of these concerns go back to the overall recommendation o= f >> "use direct ESP or UDP Encapsulation whenever possible". Anything to hel= p >> back up that point is great! >> >> Thanks, >> Tommy >> >>> >>> In the security considerations section, there are several RFCs on >>> mechanisms to increase robustness to RST attacks and SYN floods that >>> could be mentioned if it's worthwhile. >>> >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> > --94eb2c081298434b71054e252b56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not my discuss, but since I'm also supposed to worry a= bout ports :-)

On = Thu, Apr 27, 2017 at 3:32 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net<= /a>> wrote:
= Hi Tommy,

please see below, only on the first point for now.
On 26.04.2017 05:28, Tommy Pauly wrote:


On Apr 25, 2017, at 5:48 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net> wrote:

Mirja K=C3=BChlewind has entered the following ballot position for
draft-ietf-ipsecme-tcp-encaps-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc= /draft-ietf-ipsecme-tcp-encaps/



-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

This draft suggests that ports that are assigned to other services can
simply be used. This is not okay. If a port is assigned to a certain
service, this service and/or the respective RFC defines how this port is used. Simply changing the specified behavior by requiring a check for a
magic number cannot be done without updating the RFC that the port
assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
the IANA registry would need to be updated.

At this point, the only portion of the document that mentions a port other = than 500 and 4500 is the appendix. We recommend that 4500 is used as the po= rt for TCP encapsulation. The IANA registry for 4500/tcp is already assigne= d to IPSec NAT Traversal in RFC 3947; that document does not explain how TC= P is to be used, so the reference should be updated to point to the documen= t on TCP encapsulation.

 So at least section 11 talks about port 80 as well. It doesn't explicit= ly recommend to use it, but because it's discussed there I would say th= at this is implicitly the intention:

"A network device that monitors up to the application layer will
=C2=A0 =C2=A0commonly expect to see HTTP traffic within a TCP socket runnin= g over
=C2=A0 =C2=A0port 80, if non-HTTP traffic is seen (such as TCP encapsulated= IKE),
=C2=A0 =C2=A0this could be dropped by the security device."

I understand Mirja's point, and I understand = why the draft doesn't tie the protocol to one assigned port. =C2=A0

Further it's clear that the whole intention on the existence of section= 4 is that you want to (mis)use ports that have been assigned for other ser= vices and are for that reason potentially not blocked.

The (processing) problem here is that even if the bit pattern in section 4 = is currently not used and unlikely to ever be used by the protocol that is = officially assigned to the port, there is nothing that excludes a future pr= otocol spec to use these bits (and there is also nothing that makes designe= r of these protocols aware that these bits are already in use by a differen= t protocol on the same port). So the minimum you basically would need to do= is to update all RFCs for protocols on ports that you may want to use (and= probably also the IANA registry for these ports to add a refernce to this = document) and say that it is not possible to use this bit patter for the pr= otocol itself and all future version of it. Of course you probably would ne= ed to involve those working groups that maintain these protocols and I also= not sure how happy those groups would be about such an update.

What I'm thinking, is that this isn't a pr= oblem we can solve, draft by draft.

Assuming that= =C2=A0ht= tps://datatracker.ietf.org/doc/rfc3986/referencedby/ is a reasonable pr= oxy, the datatracker returns 775 documents that reference the RFC that defi= nes the URI scheme, which includes=C2=A0https://tools.ietf.org/html/rfc3986#section-3.2.= 3, allowing the application to specify a port which (of course) could b= e assigned to another protocol in=C2=A0https://= www.iana.org/assignments/service-names-port-numbers/service-names-port-numb= ers.txt.=C2=A0

That's a worst-case scenari= o, of course (some RFCs weren't deployed, some are probably obsoleted b= y other RFCs, etc.), but I'm betting the number of protocols with the s= ame issue as HTTP(S) has here is somewhere in the hundreds.

I personally think that that is not a nice solution and if you e.g. want to= use port 80 for IKE, you would need to define an IKE variant over HTTP/TCP= . That doesn't sound great and I'm not sure if that a solution anyb= ody would like to implement.

I do see the problem you have and I understand why you selected the solutio= n you have but that does contradict quite a bit the idea of the port regist= ry and I don't think it's a safe and future prove solution. Even if= people use this approach, I'm concern to publish it in an Standards Tr= ack RFC, but I guess that's a discussion the IESG would need to have.

So, yes, I agree with this, and suggest that= we start that discussion on next week's informal telechat.
<= br>
But, to try to make progress on this Discuss ...=C2=A0
<= div>
The reason optional ports in URIs work, is that someone = handed you a URI with that port number who has some reason to believe that = the port number is OK to use with the host included in the URI.
<= br>
Is that a reasonable assumption about the way IPsec and IKE o= ver TCP will be deployed? That no Initiator would assume that another host = is an IKE Responder, without being configured to use that host?
<= br>
Curiously,

Spencer
=C2=A0<= /div>
Mirja



We can soften the references in the appendix to the fact that other ports m= ay, in fact, be used. As for the configuration, it should state 4500 as the= default, but allow peers to configure something else out-of-band if they w= ant to modify behavior (which is standard even in UDP implementations of IK= E).


Further, as also mentioned in the tsv-art review (Thanks Wes!), this
draft does not sufficiently handle the case of TCP in TCP encapsulation. Here a copy of the tsv-art review:

Reviewer: Wesley Eddy
Review result: On the Right Track

This document is clear and well-written.=C2=A0 It can easily be implemented=
based on the description.

There are a few additional issues that should be considered with
advice to implementers in Section 12 on performance considerations:
1) Invisibility of packet loss - Inner protocols that require packet
losses as a signal of congestion (e.g. TCP) will have a challenge due
to not being able to see any packet losses since the outer TCP will
repair them (unless sending into a full outer TCP socket buffer shows
up back to the inner TCP as a packet loss?).

Yes, this is definitely true. We try to capture that with the line: "T= his will make loss-
=C2=A0 =C2=A0recovery of the inner TCP traffic less reactive and more prone= to
=C2=A0 =C2=A0spurious retransmission timeouts."

However, this can certainly be expanded upon.

2) Nesting of ECN -=C2=A0 Inner TCP connections will not be able to use
effectively ECN on the portion of the path covered by the outer TCP
connection.

Generally, IPsec tunnels will apply RFC 6040 for translating ECN markings b= etween inner/outer packets. Since TCP encapsulation places the inner IP pac= kets in a stream, there isn't a direct mapping.

An implementation could try to roughly map, but it may be best to suggest t= hat the ECN markings for inner and outer packets be left separate. What is = your opinion?

3) Impact of congestion response on aggregate - The general "TCP in TCP" problem is mentioned, and is mostly appropriate for a single
flow.=C2=A0 If an aggregate of flows is sharing the same outer TCP
connection, there may be additional concerns about how the congestion
response behavior impacts an aggregate of flows, since it may cause a
shared delay spike even to low-rate flows rather than distributing
losses proportional to per-flow throughput.

Indeed. We can add further comments to that effect.

4) Additional potential for bufferbloat - Since TCP does not bound
latency, some applications in the IPsec-protected aggregate could
drive latency of the shared connection up and impact the aggregate of
flows that may include real-time applications.=C2=A0 The socket buffer for<= br> the outer TCP connection might need to be limited in size to ensure
some bounds?

We can add a comment to suggest that the buffering should be limited on the= outer connection if possible.


Not addressing these could lead to poor experiences in deployment, if
implementations make wrong assumptions or fail to consider them.

I do think all of these concerns go back to the overall recommendation of &= quot;use direct ESP or UDP Encapsulation whenever possible". Anything = to help back up that point is great!

Thanks,
Tommy

In the security considerations section, there are several RFCs on
mechanisms to increase robustness to RST attacks and SYN floods that
could be mentioned if it's worthwhile.




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



--94eb2c081298434b71054e252b56-- From nobody Thu Apr 27 05:39:35 2017 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0607012025C; Thu, 27 Apr 2017 05:39:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benoit Claise To: "The IESG" Cc: draft-ietf-ipsecme-tcp-encaps@ietf.org, Tero Kivinen , ipsecme-chairs@ietf.org, kivinen@iki.fi, ipsec@ietf.org, mjethanandani@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149329676692.2975.9891637037370783678.idtracker@ietfa.amsl.com> Date: Thu, 27 Apr 2017 05:39:26 -0700 Archived-At: Subject: [IPsec] Benoit Claise's No Objection on draft-ietf-ipsecme-tcp-encaps-09: (with COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:39:27 -0000 Benoit Claise has entered the following ballot position for draft-ietf-ipsecme-tcp-encaps-09: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-tcp-encaps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Just sharing some random thoughts. No action is needed here. Most implementations should use TCP Encapsulation only on networks where negotiation over UDP has been attempted without receiving responses from the peer, or if a network is known to not support UDP. On one side, some companies deny IKE/IPSEC on purpose. In the future, they will just block port 4500. This document leaves the selection of TCP ports up to implementations. It is suggested to use TCP port 4500, which is allocated for IPsec NAT Traversal. Well, if any port can be used, that becomes difficult. On the other hand, just is like any tunneling mechanisms, which exist for some time already. QoS within TCP will be a real operational issues, as inner to outer ToS mapping is not possible. From nobody Thu Apr 27 05:46:56 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42CB12949D; Thu, 27 Apr 2017 05:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO9JGV7gsfDQ; Thu, 27 Apr 2017 05:46:44 -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 0559E129463; Thu, 27 Apr 2017 05:46:43 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3RCkfNx009457 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 15:46:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3RCkeQY011424; Thu, 27 Apr 2017 15:46:40 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22785.59440.657008.252746@fireball.acr.fi> Date: Thu, 27 Apr 2017 15:46:40 +0300 From: Tero Kivinen To: Eric Rescorla Cc: Tommy Pauly , ipsec@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, ipsecme-chairs@ietf.org, Mirja Kuehlewind , The IESG In-Reply-To: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <22784.31378.631303.102297@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 23 min X-Total-Time: 23 min Archived-At: Subject: Re: [IPsec] =?iso-8859-1?q?Mirja_K=FChlewind=27s_Discuss_on_draft-ie?= =?iso-8859-1?q?tf-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:46:46 -0000 Eric Rescorla writes: > AFAICT there are two separate issues: > > - The use of 4500, which, as Tero says, we can just update the registry to > point to this document for. > - The use of 443, which seems more complicated Yes. > WRT 443, I would assert the following facts: > > - It's not awesome that people use 443 (though understandable because of > overly-aggressive firewalls) > - People aren't going to stop using 443 (because it goes through NATs well) Especially as this has already been specified by the 3gpp TS.24.302 [1], [2]. One of the reasons we are doing this is that 3GPP defined how to run IPsec over TCP, and they decided to use port 443 and TLS framing for that (or HTTP proxy supporting HTTPCONNECT). I.e., they specified firewall traversal that will make TCP connection to port 443 of the ePDG address, and do normal TLS handshake over that, and then run TCP stream over that which will have IKEv2 and ESP frames similar what is defined here. When IPsec WG decided this is something that should be standardized for general use, we took that but we did not want to limit it to port 443 and TLS framing only, so we decided that we would define it mostly on port TCP/4500 without TLS. The original draft had text about the TLS in main body, but as it was moved to Appendix during the working group process. So regardless what we do here 3GPP will be running IPsec over TLS over TCP port 443 (i.e., IPsec, not HTTP inside the TLS). To be aligned with them we did for example change the length field before the messages to be 16-bit instead of original 32-bits. On the other hand we did add IKETCP stream prefix there, as that allows us to detect this is IETF version of the IPsec over TCP, not some proprietary or 3gpp method done before (just in case there are other differences we did not spot). [1] https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1073 [2] http://www.3gpp.org/ftp//Specs/archive/24_series/24.302/24302-e30.zip > Generally, I think it's more useful for documents to reflect > reality, even if we don't like that reality, and 443 only appears in > the appendix, so that seems fairly innocuous to me. Perhaps we can > leave the 443 in the appendix with some note like: This was the reason why WG originally wanted to move it to Appendix, and not remove it completely. > "Note: While port 4500 is the reserved port for this protocol, some > existing implementations also use port 443. The Stream Prefix > provides some mitigation against cross-protocol attacks in this > case, however, the use of port 443 is NOT RECOMMENDED" I think that text would be fine for me at least (but I am not author of this draft). > What would people think about that? > > Tommy, Tero, the stream prefix doesn't seem totally ideal. Would > there be wiggle room to specify ALPN here? Or maybe a longer prefix? The stream prefix is done also on the port 4500 or any other configured port, and those will not use TLS. Only the port 443 (or other configured ports defined to use TLS) will use TLS. Also the TLS wrapper before the IPsec / IKE might be completely sepearate module, and transferring things from there to IPsec module might be hard. The stream prefix is also inside the TLS wrapping (see B.1. example), i.e., it is the first bytes that come from the stream coming out from the TLS after the TLS handshake is finished. So for the IPsec module, it does not need to know whether there was TLS warpping around the TCP stream or not, it will get stream of octets starting with "IKETCP", and then followed by IKE or ESP packets. Also, note, that responder might use the fact that when new connection comes in and it starts with "IKETCP" as indication that there is no TLS wrapping around the frames, and give them directly to IPsec module. If there is something else, then it might try to do TLS handshake and if that successed, then check if inside the TLS there is "IKETCP" stream prefix and if so, then give that data to the IPsec module. This is something they could do on any port they are configured to listen, not only port 4500 or 443. Or it could be they are configured so that port 4500 is always without TLS framing, port 443 is always with TLS framing, and other configured ports have automatic TLS detection and processing enabled.... -- kivinen@iki.fi From nobody Thu Apr 27 05:52:52 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93FE1294D4 for ; Thu, 27 Apr 2017 05:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sB6SAym_E-H for ; Thu, 27 Apr 2017 05:52:34 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (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 424681294FF for ; Thu, 27 Apr 2017 05:52:21 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id p143so7623033yba.2 for ; Thu, 27 Apr 2017 05:52:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WgN4gh8UVGwVL9o99UVI04Kz+UkJWyl1mMeqf02ud2c=; b=Lc5ywob38uzyTKlWmSWzKNIXYxwzCnZoTys6lY+KI0MsDMtoNH8qazUju+HxWhL2W2 CztAfHmqrisgWWmJfaQYCv6CcvEYj15usy7KZbPsolTQvwCOo36x3bHAi9JFGshd7S9M 7Yc1TjuZwBV4S5CiJdM2S7Hb+pyhuZB7l6Udbx6ZTI3qcAaRINhInIg3H/vVPPakxGrD qNGFHL0ix0txZS9oGxQyTXMZnuRH69mR7QkK/N48PjFW5Kw05RxtdkCPQ9oOEWc/Lmj3 n8aHGn+cO7UrPO1YT28hr7S+xa8k1f01PVZ7BEJ6NUjKsUwimmiG3hvdfd0gOdHhzGlt ItJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WgN4gh8UVGwVL9o99UVI04Kz+UkJWyl1mMeqf02ud2c=; b=hZ+484U2RShTDm75j0dkofDd8m6/bW4G5mhgDSgK6fouUdYKCqyqvsGUPm7Ek1l9c5 G+lzKA0LubLvwvcIXsx6EHqJNFIYYwICgvwKaKYUFt7pGBmNKRcMHJFnb3ouHDnJMCb8 orHT/+KnD3H7D5v/12zeJ6G+sdtCAIRGL+1Nd/dF+Q4RVPx9wdQPThJFbLxgFBUJiWY3 OyFblq9DIASLUccAL/j0TI9ozZVGlJu7SE3qdSMnabkK9PiAl920C4DraY4Bq639YF47 PGYO0CbBF8QhuoyQBI5kplFedP2l68Rf+nlsMaNweR1/s1QDQzmyrFecDMvSxbyDHwxV zVeQ== X-Gm-Message-State: AN3rC/767FuZsMKS52+wqJUiZF8sHP1RTdznCSzE5YYCfirMwzsh6mFz E0kO830m0SxowWXfR3FsK6Y2+AKbvg== X-Received: by 10.37.174.24 with SMTP id a24mr4247154ybj.50.1493297540197; Thu, 27 Apr 2017 05:52:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 05:51:39 -0700 (PDT) In-Reply-To: <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> From: Eric Rescorla Date: Thu, 27 Apr 2017 05:51:39 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Tommy Pauly , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG , Tero Kivinen Content-Type: multipart/alternative; boundary=f403045da3586daa1f054e256d59 Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 12:52:36 -0000 --f403045da3586daa1f054e256d59 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BChlewind wrote: > > I do see the problem you have and I understand why you selected the > solution you have but that does contradict quite a bit the idea of the po= rt > registry and I don't think it's a safe and future prove solution. Even if > people use this approach, I'm concern to publish it in an Standards Track > RFC, but I guess that's a discussion the IESG would need to have. Mirja, I agree that this kind of port squatting is regrettable, but I also don't think it really helps to not publish RFCs that document widely used protocols because we are sad they port-squatted. I proposed a way to deal with this in an earlier e-mail. Would that be satisfactory to you. To retransmit, we add the following "Note: While port 4500 is the reserved port for this protocol, some existing implementations also use port 443. The Stream Prefix provides some mitigation against cross-protocol attacks in this case, however, the use of port 443 is NOT RECOMMENDED" We could do something similar for port 80. Would that work? -Ekr > > > Mirja > > > >> We can soften the references in the appendix to the fact that other port= s >> may, in fact, be used. As for the configuration, it should state 4500 as >> the default, but allow peers to configure something else out-of-band if >> they want to modify behavior (which is standard even in UDP implementati= ons >> of IKE). >> >> >>> Further, as also mentioned in the tsv-art review (Thanks Wes!), this >>> draft does not sufficiently handle the case of TCP in TCP encapsulation= . >>> Here a copy of the tsv-art review: >>> >>> Reviewer: Wesley Eddy >>> Review result: On the Right Track >>> >>> This document is clear and well-written. It can easily be implemented >>> based on the description. >>> >>> There are a few additional issues that should be considered with >>> advice to implementers in Section 12 on performance considerations: >>> 1) Invisibility of packet loss - Inner protocols that require packet >>> losses as a signal of congestion (e.g. TCP) will have a challenge due >>> to not being able to see any packet losses since the outer TCP will >>> repair them (unless sending into a full outer TCP socket buffer shows >>> up back to the inner TCP as a packet loss?). >>> >> >> Yes, this is definitely true. We try to capture that with the line: "Thi= s >> will make loss- >> recovery of the inner TCP traffic less reactive and more prone to >> spurious retransmission timeouts." >> >> However, this can certainly be expanded upon. >> >> 2) Nesting of ECN - Inner TCP connections will not be able to use >>> effectively ECN on the portion of the path covered by the outer TCP >>> connection. >>> >> >> Generally, IPsec tunnels will apply RFC 6040 for translating ECN marking= s >> between inner/outer packets. Since TCP encapsulation places the inner IP >> packets in a stream, there isn't a direct mapping. >> >> An implementation could try to roughly map, but it may be best to sugges= t >> that the ECN markings for inner and outer packets be left separate. What= is >> your opinion? >> >> 3) Impact of congestion response on aggregate - The general "TCP in >>> TCP" problem is mentioned, and is mostly appropriate for a single >>> flow. If an aggregate of flows is sharing the same outer TCP >>> connection, there may be additional concerns about how the congestion >>> response behavior impacts an aggregate of flows, since it may cause a >>> shared delay spike even to low-rate flows rather than distributing >>> losses proportional to per-flow throughput. >>> >> >> Indeed. We can add further comments to that effect. >> >> 4) Additional potential for bufferbloat - Since TCP does not bound >>> latency, some applications in the IPsec-protected aggregate could >>> drive latency of the shared connection up and impact the aggregate of >>> flows that may include real-time applications. The socket buffer for >>> the outer TCP connection might need to be limited in size to ensure >>> some bounds? >>> >> >> We can add a comment to suggest that the buffering should be limited on >> the outer connection if possible. >> >> >>> Not addressing these could lead to poor experiences in deployment, if >>> implementations make wrong assumptions or fail to consider them. >>> >> >> I do think all of these concerns go back to the overall recommendation o= f >> "use direct ESP or UDP Encapsulation whenever possible". Anything to hel= p >> back up that point is great! >> >> Thanks, >> Tommy >> >>> >>> In the security considerations section, there are several RFCs on >>> mechanisms to increase robustness to RST attacks and SYN floods that >>> could be mentioned if it's worthwhile. >>> >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --f403045da3586daa1f054e256d59 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BChlewind <ietf@kuehlewi= nd.net> wrote:
I do see the problem you have and I understand why you selected the solutio= n you have but that does contradict quite a bit the idea of the port regist= ry and I don't think it's a safe and future prove solution. Even if= people use this approach, I'm concern to publish it in an Standards Tr= ack RFC, but I guess that's a discussion the IESG would need to have.

Mirja,

I agree that= this kind of port squatting is regrettable, but I also don't think it = really
helps to not publish RFCs that document widely used protoc= ols because we
are sad they port-squatted.

I proposed a way to deal with this in an earlier e-mail. Would that be s= atisfactory
to you. To retransmit, we add the following=C2=A0

"Note: While por= t 4500 is the reserved port for this protocol, some existing implementation= s
also use port 443. The Stream Prefix= provides some mitigation against cross-protocol
attacks in this case, however, the use of port 443 is NOT RECOMM= ENDED"

We could do something similar for port 80.

Would = that work?

-Ekr
=C2=A0


Mirja



We can soften the references in the appendix to the fact that other ports m= ay, in fact, be used. As for the configuration, it should state 4500 as the= default, but allow peers to configure something else out-of-band if they w= ant to modify behavior (which is standard even in UDP implementations of IK= E).


Further, as also mentioned in the tsv-art review (Thanks Wes!), this
draft does not sufficiently handle the case of TCP in TCP encapsulation. Here a copy of the tsv-art review:

Reviewer: Wesley Eddy
Review result: On the Right Track

This document is clear and well-written.=C2=A0 It can easily be implemented=
based on the description.

There are a few additional issues that should be considered with
advice to implementers in Section 12 on performance considerations:
1) Invisibility of packet loss - Inner protocols that require packet
losses as a signal of congestion (e.g. TCP) will have a challenge due
to not being able to see any packet losses since the outer TCP will
repair them (unless sending into a full outer TCP socket buffer shows
up back to the inner TCP as a packet loss?).

Yes, this is definitely true. We try to capture that with the line: "T= his will make loss-
=C2=A0 =C2=A0recovery of the inner TCP traffic less reactive and more prone= to
=C2=A0 =C2=A0spurious retransmission timeouts."

However, this can certainly be expanded upon.

2) Nesting of ECN -=C2=A0 Inner TCP connections will not be able to use
effectively ECN on the portion of the path covered by the outer TCP
connection.

Generally, IPsec tunnels will apply RFC 6040 for translating ECN markings b= etween inner/outer packets. Since TCP encapsulation places the inner IP pac= kets in a stream, there isn't a direct mapping.

An implementation could try to roughly map, but it may be best to suggest t= hat the ECN markings for inner and outer packets be left separate. What is = your opinion?

3) Impact of congestion response on aggregate - The general "TCP in TCP" problem is mentioned, and is mostly appropriate for a single
flow.=C2=A0 If an aggregate of flows is sharing the same outer TCP
connection, there may be additional concerns about how the congestion
response behavior impacts an aggregate of flows, since it may cause a
shared delay spike even to low-rate flows rather than distributing
losses proportional to per-flow throughput.

Indeed. We can add further comments to that effect.

4) Additional potential for bufferbloat - Since TCP does not bound
latency, some applications in the IPsec-protected aggregate could
drive latency of the shared connection up and impact the aggregate of
flows that may include real-time applications.=C2=A0 The socket buffer for<= br> the outer TCP connection might need to be limited in size to ensure
some bounds?

We can add a comment to suggest that the buffering should be limited on the= outer connection if possible.


Not addressing these could lead to poor experiences in deployment, if
implementations make wrong assumptions or fail to consider them.

I do think all of these concerns go back to the overall recommendation of &= quot;use direct ESP or UDP Encapsulation whenever possible". Anything = to help back up that point is great!

Thanks,
Tommy

In the security considerations section, there are several RFCs on
mechanisms to increase robustness to RST attacks and SYN floods that
could be mentioned if it's worthwhile.




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


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

--f403045da3586daa1f054e256d59-- From nobody Thu Apr 27 06:01:11 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B301294CE for ; Thu, 27 Apr 2017 06:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbt0oIxPGBSC for ; Thu, 27 Apr 2017 06:01:03 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 9EF5A1294A1 for ; Thu, 27 Apr 2017 06:01:00 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id 8so7695067ybw.1 for ; Thu, 27 Apr 2017 06:01:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E3d9p2kTXDubZLBGwalP0+PEa930ut2X+8Tgg9QpC0c=; b=u9UUGwHfC617K8u2XAAsFYDQQQJIQQpCLExfuGCTnRdn/vqY4oHWnL5ELV1ctNj/8c Nw35Ygywwsr9eui8jV2UuyqvXYBK7ST+oZR0ArTaniw22yrRMgLsCYoYbZsKX9Jw2Ym1 QKMkgeSWy2v6HV8+rKldHD1JhS/7ZSkDbzRoxcVY7xDYk1i4A3BjYlN02HNeGYciPFdU InaCubI3g6qDrcKdePt8dwU/SuqTbV0tOWIUmLszHmVKwjiCUlTfDfeJqkJSL1s2QwhN B9+vg2X79Hq0PbZovZUP9SuX5+Jr0X429RESg60y31hva1blA23DdqRipxEOHwGRkACT wIEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E3d9p2kTXDubZLBGwalP0+PEa930ut2X+8Tgg9QpC0c=; b=H8ACCUy25dgP9npCxgdyO3AuT9rnra06KqZdpncLnRhDHeoSbO6myGHIJoz0AJ6CpO NUrI0h1NvQpN3m9KdPWzk3a+GTHUVuDxN8b2GIuNCwpMeaMBtszl4aeLXoVSMOWy9lrR 0v5NJNzc03vbCJ3HJAHEQjPZv0xwnM1s0GhjPZ7oPVYZTKgE5av/DhklzmuWpZT6jtJ7 B7W4WJK+JAWx0nzNpyTX7EuH/HUpvYGrdISuQFou8xuRsXRRUn1ExlQTgPwNK++0jtPC O6E6ifs7WujknReM43jqBvUrX5i+5mely8FSSplcpvgck2y7Aq10Xbuq7raccA93x4ib itGg== X-Gm-Message-State: AN3rC/4WGQr8uYUmTv9WpYY9VzRbEkS5nLV+tCVB6eLgif9OF4gRsH8u VXZCT2no7BdeMaK9SOdDkqekKh4nWQ== X-Received: by 10.37.218.145 with SMTP id n139mr4132587ybf.117.1493298059180; Thu, 27 Apr 2017 06:00:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 06:00:17 -0700 (PDT) In-Reply-To: <89333EE4-4F8F-4206-AD61-6352C57AFBE7@apple.com> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <22784.31378.631303.102297@fireball.acr.fi> <89333EE4-4F8F-4206-AD61-6352C57AFBE7@apple.com> From: Eric Rescorla Date: Thu, 27 Apr 2017 06:00:17 -0700 Message-ID: To: Tommy Pauly Cc: Tero Kivinen , ipsecme-chairs@ietf.org, ipsec@ietf.org, Mirja Kuehlewind , The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07e8205cc00f054e258ccc Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:01:09 -0000 --94eb2c07e8205cc00f054e258ccc Content-Type: text/plain; charset=UTF-8 On Wed, Apr 26, 2017 at 2:29 PM, Tommy Pauly wrote: > > On Apr 26, 2017, at 12:51 PM, Eric Rescorla wrote: > > AFAICT there are two separate issues: > > - The use of 4500, which, as Tero says, we can just update the registry to > point to this document for. > - The use of 443, which seems more complicated > > WRT 443, I would assert the following facts: > > - It's not awesome that people use 443 (though understandable because of > overly-aggressive firewalls) > - People aren't going to stop using 443 (because it goes through NATs well) > > Generally, I think it's more useful for documents to reflect reality, even > if we don't like that reality, > and 443 only appears in the appendix, so that seems fairly innocuous to > me. Perhaps we can > leave the 443 in the appendix with some note like: > > "Note: While port 4500 is the reserved port for this protocol, some > existing implementations > also use port 443. The Stream Prefix provides some mitigation against > cross-protocol > attacks in this case, however, the use of port 443 is NOT RECOMMENDED" > > > What would people think about that? > > > That sounds good to me. I think we may want to mention that the Stream > Prefix is used to distinguish from any other protocols running on port > 4500, etc, not really specifically to 443. > Good point. Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be > wiggle room > to specify ALPN here? Or maybe a longer prefix? > > > The document's text regarding ALPN is in section 4: > > "Although some framing protocols do support negotiating inner protocols, > the stream prefix should always be used in order for implementations to be > as generic as possible and not rely on other framing protocols on top of > TCP." > > The idea is that we don't want to use TLS as a wrapper whenever possible. > An implementation on an IKE server may be behind a proxy or another process > that's terminating the TLS or raw TCP, and passing the inner stream along. > In that case, we wanted a standard way to put IKE and ESP in a stream, not > relying on an outer protocol's details. > I get that, but it is a bit unfortunate to be relying on this inband signaling. > I'm perfectly open to using another prefix value; if you have a suggestion > for a longer value, that would be great! > I think I'd probably ask MT or mnot, but my instinct would be to use some randomly chosen string that started with IKETCP. E.g., IKETCP + 8ish random bytes. This just reduces the chance of any kind of accidental collision. I don't think it's a dealbreaker. -Ekr > Thanks, > Tommy > > > -Ekr > > > On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen wrote: > >> Tommy Pauly writes: >> > > ------------------------------------------------------------ >> ---------- >> > > DISCUSS: >> > > ------------------------------------------------------------ >> ---------- >> > > >> > > This draft suggests that ports that are assigned to other services can >> > > simply be used. This is not okay. If a port is assigned to a certain >> > > service, this service and/or the respective RFC defines how this port >> is >> > > used. Simply changing the specified behavior by requiring a check for >> a >> > > magic number cannot be done without updating the RFC that the port >> > > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as >> > > the IANA registry would need to be updated. >> > >> > At this point, the only portion of the document that mentions a port >> > other than 500 and 4500 is the appendix. We recommend that 4500 is >> > used as the port for TCP encapsulation. The IANA registry for >> > 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947; >> > that document does not explain how TCP is to be used, so the >> > reference should be updated to point to the document on TCP >> > encapsulation. >> >> I already explained this in long email to the Joe and Paul, but >> noticed that those emails did not go to to the IESG, so this is mostly >> cut & paste of my previous email. This does not cover anything about >> using any other ports, but covers the case about the IANA allocations >> for TCP/4500 and UPD/4500. >> >> ---------------------------------------------------------------------- >> Paul Wouters writes: >> > On Tue, 25 Apr 2017, Joe Touch wrote: >> > > Every bit pattern, including those using magic numbers, is already >> > > owned and under the control of each assigned port. It is not >> > > appropriate for any new service to hijack that pattern as having a >> > > different meaning UNLESS explicitly updating the service on >> > > that port. >> > > >> > > A simple summary of what needs to change, in 2119-language: >> > > >> > > - this approach MUST NOT be described as applying to any >> > > assigned number unless also updating the associated RFC >> > >> > So it should add an Updates: RFC-3947 >> >> Not really. It does not update RFC3947 as it does not change the >> obsoleted protocol defined in the RFC3947. It does define way to >> extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On >> the other hand RFC3947 should have been obsoleted when we obsoleted >> IKEv1, as that document only defines how to do IKEv1 NAT traversal >> negotiation, and the IKEv2 NAT traversal negotation is described in >> main IKEv2 RFC (RFC7296). >> >> > It's a little weird. 3947 reserved TCP 4500, but did not specify how >> > to actually use TCP at all. It seems it was mostly preventatively >> > reserved. >> >> The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500 >> and UDP/4500 references from individual user to the RFC3947, so that >> IETF will have change control over the ports. I.e., those ports were >> allocated before RFC3947 came out, and they were used for several >> different non-interoperable versions of the NAT traversals, which then >> evolved to the standard version we define in RFC3947. We decided to >> reassign both TCP and UDP port 4500 to RFC3947 so it would be clear >> for what use they will be used. Also we commonly reserve both TCP and >> UDP ports for same number just in case someone defines a way to run >> the protocol over other transport protocol in the future... >> >> RFC3947 does not define anything over TCP/4500. Actually RFC3947 does >> not define anything over the UDP/4500 either, it is the RFC3948 that >> does that. The RFC3947 just says, we use the format defined in the >> RFC3948 over the UDP/4500, but is silent about the TCP/4500. >> >> RFC3947 is efficiently obsoleted, as it only defines the way to do NAT >> traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2 >> (originally RFC4306, and now RFC7296). So the RFC3947 should have been >> marked as obsoleted by RFC4306. I am not sure if we want to do that in >> this late. >> >> So my proposal is update the IANA port registry for both UDP/4500 and >> TCP/4500 as follows: >> >> Keyword Decimal Description Reference >> ------- ------- ----------- --------- >> ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFCXXXX] >> ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3948], >> [RFC7296] >> >> (RFCXXXX being this RFC). >> >> Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the >> RFC3948 actually defines the protocol used over the port. RFC3947 >> defines the IKEv1 negotiation over the UDP port 500 and 4500, but for >> IKEv2 this is already defined in the RFC7296. >> >> The RFC3947 could either be left as it is now, or marked as being >> obsoleted by this or RFC4306, or RFC7296 or whatever. Updating >> document which is effectively already obsoleted, is just wrong... >> -- >> kivinen@iki.fi >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > --94eb2c07e8205cc00f054e258ccc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Apr 26, 2017 at 2:29 PM, Tommy Pauly <tpauly@apple.com><= /span> wrote:

On Apr 26= , 2017, at 12:51 PM, Eric Rescorla <ekr@rtfm.com> wrote:

AFAICT there a= re two separate issues:

- The use of 4500, which, = as Tero says, we can just update the registry to point to this document for= .
- The use of 443, which seems more complicated

WRT 443, I would assert the following facts:

<= div>- It's not awesome that people use 443 (though understandable becau= se of overly-aggressive firewalls)
- People aren't going to s= top using 443 (because it goes through NATs well)

= Generally, I think it's more useful for documents to reflect reality, e= ven if we don't like that reality,
and 443 only appears in th= e appendix, so that seems fairly innocuous to me. Perhaps we can
= leave the 443 in the appendix with some note like:

"Note: While port 4500 is the reserved port for this protocol, some e= xisting implementations
also use port 443. The Stream Prefix prov= ides some mitigation against cross-protocol
attacks in this case,= however, the use of port 443 is NOT RECOMMENDED"

What would people think about that?
<= br>
That sounds good to me. I think we may want to mention= that the Stream Prefix is used to distinguish from any other protocols run= ning on port 4500, etc, not really specifically to 443.

Good point.
=C2=A0

<= /div>
Tom= my, Tero, the stream prefix doesn't seem totally ideal. Would there be = wiggle room
to specify ALPN here? Or maybe a longer prefix?
=

The document's text= regarding ALPN is in section 4:

"Although so= me framing protocols do support negotiating inner protocols, the stream pre= fix should always be used in order for implementations to be as generic as= =C2=A0possible and not rely on other framing protocols on top of TCP."=

The idea is that we don't want to use TLS as = a wrapper whenever possible. An implementation on an IKE server may be behi= nd a proxy or another process that's terminating the TLS or raw TCP, an= d passing the inner stream along. In that case, we wanted a standard way to= put IKE and ESP in a stream, not relying on an outer protocol's detail= s.

I get that, but it is = a bit unfortunate to be relying on this inband signaling.

=C2=A0
I'm perfectly open to using another pr= efix value; if you have a suggestion for a longer value, that would be grea= t!

I think I'd probab= ly ask MT or mnot, but my instinct would be to use some randomly chosen str= ing
that started with IKETCP. E.g., IKETCP + 8ish random bytes. T= his just reduces the chance of
any kind of accidental collision. = I don't think it's a dealbreaker.

-Ekr


=C2=A0
Thanks,
Tommy<= /div>

-Ekr


On Wed, Apr 26, 2017 at 3:46 AM, Ter= o Kivinen <kivinen@iki.fi> wrote:
Tommy Pauly writes:
> > ------------------------------------------------------------= ----------
> > DISCUSS:
> > ------------------------------------------------------------= ----------
> >
> > This draft suggests that ports that are assigned to other service= s can
> > simply be used. This is not okay. If a port is assigned to a cert= ain
> > service, this service and/or the respective RFC defines how this = port is
> > used. Simply changing the specified behavior by requiring a check= for a
> > magic number cannot be done without updating the RFC that the por= t
> > assignment belongs to. Also for the use of 4500/tcp RFC3948 as we= ll as
> > the IANA registry would need to be updated.
>
> At this point, the only portion of the document that mentions a port > other than 500 and 4500 is the appendix. We recommend that 4500 is
> used as the port for TCP encapsulation. The IANA registry for
> 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947;
> that document does not explain how TCP is to be used, so the
> reference should be updated to point to the document on TCP
> encapsulation.

I already explained this in long email to the Joe and Paul, but
noticed that those emails did not go to to the IESG, so this is mostly
cut & paste of my previous email. This does not cover anything about using any other ports, but covers the case about the IANA allocations
for TCP/4500 and UPD/4500.

-----------------------------------------------------------------= -----
Paul Wouters writes:
> On Tue, 25 Apr 2017, Joe Touch wrote:
> > Every bit pattern, including those using magic numbers, is alread= y
> > owned and under the control of each assigned port. It is not
> > appropriate for any new service to hijack that pattern as having = a
> > different meaning UNLESS explicitly updating the service on
> > that port.
> >
> > A simple summary of what needs to change, in 2119-language:
> >
> >=C2=A0 =C2=A0 - this approach MUST NOT be described as applying to= any
> >=C2=A0 =C2=A0 =C2=A0 assigned number unless also updating the asso= ciated RFC
>
> So it should add an Updates: RFC-3947

Not really. It does not update RFC3947 as it does not change the
obsoleted protocol defined in the RFC3947. It does define way to
extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
the other hand RFC3947 should have been obsoleted when we obsoleted
IKEv1, as that document only defines how to do IKEv1 NAT traversal
negotiation, and the IKEv2 NAT traversal negotation is described in
main IKEv2 RFC (RFC7296).

> It's a little weird. 3947 reserved TCP 4500, but did not specify h= ow
> to actually use TCP at all. It seems it was mostly preventatively
> reserved.

The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500
and UDP/4500 references from individual user to the RFC3947, so that
IETF will have change control over the ports. I.e., those ports were
allocated before RFC3947 came out, and they were used for several
different non-interoperable versions of the NAT traversals, which then
evolved to the standard version we define in RFC3947. We decided to
reassign both TCP and UDP port 4500 to RFC3947 so it would be clear
for what use they will be used. Also we commonly reserve both TCP and
UDP ports for same number just in case someone defines a way to run
the protocol over other transport protocol in the future...

RFC3947 does not define anything over TCP/4500. Actually RFC3947 does
not define anything over the UDP/4500 either, it is the RFC3948 that
does that. The RFC3947 just says, we use the format defined in the
RFC3948 over the UDP/4500, but is silent about the TCP/4500.

RFC3947 is efficiently obsoleted, as it only defines the way to do NAT
traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2
(originally RFC4306, and now RFC7296). So the RFC3947 should have been
marked as obsoleted by RFC4306. I am not sure if we want to do that in
this late.

So my proposal is update the IANA port registry for both UDP/4500 and
TCP/4500 as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keyword=C2=A0 =C2=A0 =C2=A0 =C2=A0Decimal= =C2=A0 =C2=A0 Description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reference
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------=C2=A0 =C2=A0 =C2=A0 =C2=A0-------= =C2=A0 =C2=A0 -----------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipsec-nat-t=C2=A0 =C2=A04500/tcp=C2=A0 = =C2=A0IPsec NAT-Traversal=C2=A0 [RFCXXXX]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipsec-nat-t=C2=A0 =C2=A04500/udp=C2=A0 = =C2=A0IPsec NAT-Traversal=C2=A0 [RFC3948], [RFC7296]

(RFCXXXX being this RFC).

Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the
RFC3948 actually defines the protocol used over the port. RFC3947
defines the IKEv1 negotiation over the UDP port 500 and 4500, but for
IKEv2 this is already defined in the RFC7296.

The RFC3947 could either be left as it is now, or marked as being
obsoleted by this or RFC4306, or RFC7296 or whatever. Updating
document which is effectively already obsoleted, is just wrong...
--
kivinen@iki.fi


_______________________________________________
IPsec mailing list<= br>IPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec


--94eb2c07e8205cc00f054e258ccc-- From nobody Thu Apr 27 06:02:31 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04E61294E2 for ; Thu, 27 Apr 2017 06:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKC5ZO4myWe3 for ; Thu, 27 Apr 2017 06:02:27 -0700 (PDT) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::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 AC1141294C5 for ; Thu, 27 Apr 2017 06:02:24 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id 11so7720453yby.0 for ; Thu, 27 Apr 2017 06:02:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VRwYuY6NhQSmYWWqhdKUZTuCHPzh40SieSsfwhyU1lQ=; b=PeZBf3mZ/tMbEhnbbEmapRMD1Dp+Ci9Nn4rE2dd2u7kTfWtZ0LklTUP8ULwAiaLIPz 6DOus2Sjvnq0FcluGj5Q/MXDN8VTjunMUvIcGR4H4iRnF/lJvSBIJVUf3ljhlZ+jVORY eYXqNdzNKCPrGKPN35ppeuga3LHfawjdnrgQk8EYiuDnY+KAKTEOr48vHbax3QJiQUj4 nPO9Ls8S5fYn5g838zXfVL6tGyp0ynmfo+i413EBB4i/6GeEW7nj/swTJGhve3z00NSr TgRiaTRqLXHRhydLwCGvhZTveltBM8pIvF1jlzgiqt1AvlAAOsTeZOYY65w0yr78qxfp FfQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VRwYuY6NhQSmYWWqhdKUZTuCHPzh40SieSsfwhyU1lQ=; b=RfML6cQ5mGg5pr4PC1kvb3ZmMUuoDHXq08g/ZuE49M6R4+S/A+O+enAWGzHtEdiemI 78UnreC9K7c3C7w+pwL2Xk7TsVNEAiIwK3jAatDBvvBGFeEEuNK194JVvZ3v4aPeStv7 AO3Yg0Hnj3K32Bh1TYjv0rM1fsOYh7zZ76WBu6Jr3wKvcRcX0Al4mXOBHONATVbhJ0va 354iKAE8XYRTfQRYSZ03winb2BE5izuTjrk66Gitrrm8ihuCzHd7lGe1IDKpz4Z9/iTP oVXWwlZJVzT0o9vYfXlmYWglLwEZ07brwHGHFgCB4LVFBb8i5tgmmDg2e/lyqfddHzAk t8iw== X-Gm-Message-State: AN3rC/6e7FHHBlmse8ecIU/q/ywpqABILqeq71zXK4S6C4b14NowcpPX 0fY7oI/3NuNpRd6JXtuf6w4O4kvvBg== X-Received: by 10.37.174.24 with SMTP id a24mr4289393ybj.50.1493298143825; Thu, 27 Apr 2017 06:02:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 06:01:43 -0700 (PDT) In-Reply-To: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <22784.31378.631303.102297@fireball.acr.fi> <89333EE4-4F8F-4206-AD61-6352C57AFBE7@apple.com> From: Eric Rescorla Date: Thu, 27 Apr 2017 06:01:43 -0700 Message-ID: To: Tommy Pauly Cc: Tero Kivinen , ipsecme-chairs@ietf.org, ipsec@ietf.org, Mirja Kuehlewind , The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Type: multipart/alternative; boundary=f403045da358682222054e259187 Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:02:30 -0000 --f403045da358682222054e259187 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 27, 2017 at 6:00 AM, Eric Rescorla wrote: > > > On Wed, Apr 26, 2017 at 2:29 PM, Tommy Pauly wrote: > >> >> On Apr 26, 2017, at 12:51 PM, Eric Rescorla wrote: >> >> AFAICT there are two separate issues: >> >> - The use of 4500, which, as Tero says, we can just update the registry >> to point to this document for. >> - The use of 443, which seems more complicated >> >> WRT 443, I would assert the following facts: >> >> - It's not awesome that people use 443 (though understandable because of >> overly-aggressive firewalls) >> - People aren't going to stop using 443 (because it goes through NATs >> well) >> >> Generally, I think it's more useful for documents to reflect reality, >> even if we don't like that reality, >> and 443 only appears in the appendix, so that seems fairly innocuous to >> me. Perhaps we can >> leave the 443 in the appendix with some note like: >> >> "Note: While port 4500 is the reserved port for this protocol, some >> existing implementations >> also use port 443. The Stream Prefix provides some mitigation against >> cross-protocol >> attacks in this case, however, the use of port 443 is NOT RECOMMENDED" >> >> >> What would people think about that? >> >> >> That sounds good to me. I think we may want to mention that the Stream >> Prefix is used to distinguish from any other protocols running on port >> 4500, etc, not really specifically to 443. >> > > Good point. > > > Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be >> wiggle room >> to specify ALPN here? Or maybe a longer prefix? >> >> >> The document's text regarding ALPN is in section 4: >> >> "Although some framing protocols do support negotiating inner protocols, >> the stream prefix should always be used in order for implementations to be >> as generic as possible and not rely on other framing protocols on top of >> TCP." >> >> The idea is that we don't want to use TLS as a wrapper whenever possible. >> An implementation on an IKE server may be behind a proxy or another process >> that's terminating the TLS or raw TCP, and passing the inner stream along. >> In that case, we wanted a standard way to put IKE and ESP in a stream, not >> relying on an outer protocol's details. >> > > I get that, but it is a bit unfortunate to be relying on this inband > signaling. > Replying to myself (and in light of Benoit's comments). The advantage of ALPN is that it would let outgoing firewall devices do some kind of filtering even for the TLS traffic (which of course will not be possible if you use non-NULL ciphers which you will have to for 1.3). -Ekr > > >> I'm perfectly open to using another prefix value; if you have a >> suggestion for a longer value, that would be great! >> > > I think I'd probably ask MT or mnot, but my instinct would be to use some > randomly chosen string > that started with IKETCP. E.g., IKETCP + 8ish random bytes. This just > reduces the chance of > any kind of accidental collision. I don't think it's a dealbreaker. > > -Ekr > > > > >> Thanks, >> Tommy >> >> >> -Ekr >> >> >> On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen wrote: >> >>> Tommy Pauly writes: >>> > > ------------------------------------------------------------ >>> ---------- >>> > > DISCUSS: >>> > > ------------------------------------------------------------ >>> ---------- >>> > > >>> > > This draft suggests that ports that are assigned to other services >>> can >>> > > simply be used. This is not okay. If a port is assigned to a certain >>> > > service, this service and/or the respective RFC defines how this >>> port is >>> > > used. Simply changing the specified behavior by requiring a check >>> for a >>> > > magic number cannot be done without updating the RFC that the port >>> > > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well >>> as >>> > > the IANA registry would need to be updated. >>> > >>> > At this point, the only portion of the document that mentions a port >>> > other than 500 and 4500 is the appendix. We recommend that 4500 is >>> > used as the port for TCP encapsulation. The IANA registry for >>> > 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947; >>> > that document does not explain how TCP is to be used, so the >>> > reference should be updated to point to the document on TCP >>> > encapsulation. >>> >>> I already explained this in long email to the Joe and Paul, but >>> noticed that those emails did not go to to the IESG, so this is mostly >>> cut & paste of my previous email. This does not cover anything about >>> using any other ports, but covers the case about the IANA allocations >>> for TCP/4500 and UPD/4500. >>> >>> ---------------------------------------------------------------------- >>> Paul Wouters writes: >>> > On Tue, 25 Apr 2017, Joe Touch wrote: >>> > > Every bit pattern, including those using magic numbers, is already >>> > > owned and under the control of each assigned port. It is not >>> > > appropriate for any new service to hijack that pattern as having a >>> > > different meaning UNLESS explicitly updating the service on >>> > > that port. >>> > > >>> > > A simple summary of what needs to change, in 2119-language: >>> > > >>> > > - this approach MUST NOT be described as applying to any >>> > > assigned number unless also updating the associated RFC >>> > >>> > So it should add an Updates: RFC-3947 >>> >>> Not really. It does not update RFC3947 as it does not change the >>> obsoleted protocol defined in the RFC3947. It does define way to >>> extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On >>> the other hand RFC3947 should have been obsoleted when we obsoleted >>> IKEv1, as that document only defines how to do IKEv1 NAT traversal >>> negotiation, and the IKEv2 NAT traversal negotation is described in >>> main IKEv2 RFC (RFC7296). >>> >>> > It's a little weird. 3947 reserved TCP 4500, but did not specify how >>> > to actually use TCP at all. It seems it was mostly preventatively >>> > reserved. >>> >>> The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500 >>> and UDP/4500 references from individual user to the RFC3947, so that >>> IETF will have change control over the ports. I.e., those ports were >>> allocated before RFC3947 came out, and they were used for several >>> different non-interoperable versions of the NAT traversals, which then >>> evolved to the standard version we define in RFC3947. We decided to >>> reassign both TCP and UDP port 4500 to RFC3947 so it would be clear >>> for what use they will be used. Also we commonly reserve both TCP and >>> UDP ports for same number just in case someone defines a way to run >>> the protocol over other transport protocol in the future... >>> >>> RFC3947 does not define anything over TCP/4500. Actually RFC3947 does >>> not define anything over the UDP/4500 either, it is the RFC3948 that >>> does that. The RFC3947 just says, we use the format defined in the >>> RFC3948 over the UDP/4500, but is silent about the TCP/4500. >>> >>> RFC3947 is efficiently obsoleted, as it only defines the way to do NAT >>> traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2 >>> (originally RFC4306, and now RFC7296). So the RFC3947 should have been >>> marked as obsoleted by RFC4306. I am not sure if we want to do that in >>> this late. >>> >>> So my proposal is update the IANA port registry for both UDP/4500 and >>> TCP/4500 as follows: >>> >>> Keyword Decimal Description Reference >>> ------- ------- ----------- --------- >>> ipsec-nat-t 4500/tcp IPsec NAT-Traversal [RFCXXXX] >>> ipsec-nat-t 4500/udp IPsec NAT-Traversal [RFC3948], >>> [RFC7296] >>> >>> (RFCXXXX being this RFC). >>> >>> Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the >>> RFC3948 actually defines the protocol used over the port. RFC3947 >>> defines the IKEv1 negotiation over the UDP port 500 and 4500, but for >>> IKEv2 this is already defined in the RFC7296. >>> >>> The RFC3947 could either be left as it is now, or marked as being >>> obsoleted by this or RFC4306, or RFC7296 or whatever. Updating >>> document which is effectively already obsoleted, is just wrong... >>> -- >>> kivinen@iki.fi >>> >>> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> > --f403045da358682222054e259187 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 6:00 AM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Wed, Ap= r 26, 2017 at 2:29 PM, Tommy Pauly <tpauly@apple.com> wrote:<= br>

<= div>
On Apr 26, 2017, at 12:51 PM, Eric= Rescorla <ekr@rtfm.co= m> wrote:

AFAICT there are t= wo separate issues:

- The use of 4500, which, as T= ero says, we can just update the registry to point to this document for.
- The use of 443, which seems more complicated

=
WRT 443, I would assert the following facts:

= - It's not awesome that people use 443 (though understandable because o= f overly-aggressive firewalls)
- People aren't going to stop = using 443 (because it goes through NATs well)

Gene= rally, I think it's more useful for documents to reflect reality, even = if we don't like that reality,
and 443 only appears in the ap= pendix, so that seems fairly innocuous to me. Perhaps we can
leav= e the 443 in the appendix with some note like:

&qu= ot;Note: While port 4500 is the reserved port for this protocol, some exist= ing implementations
also use port 443. The Stream Prefix provides= some mitigation against cross-protocol
attacks in this case, how= ever, the use of port 443 is NOT RECOMMENDED"

W= hat would people think about that?

<= /div>
That sounds good to me. I think we may want to mention tha= t the Stream Prefix is used to distinguish from any other protocols running= on port 4500, etc, not really specifically to 443.

Good point.
= =C2=A0

Tommy, Tero, the stream prefix doesn't seem totally ideal. Woul= d there be wiggle room
to specify ALPN here? Or maybe a longer pr= efix?

The document= 's text regarding ALPN is in section 4:

"= Although some framing protocols do support negotiating inner protocols, the= stream prefix should always be used in order for implementations to be as = generic as=C2=A0possible and not rely on other framing protocols on top of = TCP."

The idea is that we don't want to u= se TLS as a wrapper whenever possible. An implementation on an IKE server m= ay be behind a proxy or another process that's terminating the TLS or r= aw TCP, and passing the inner stream along. In that case, we wanted a stand= ard way to put IKE and ESP in a stream, not relying on an outer protocol= 9;s details.

I get= that, but it is a bit unfortunate to be relying on this inband signaling.<= /div>

Replying to myself = (and in light of Benoit's comments).

The advan= tage of ALPN is that it would let outgoing firewall devices do some kind
of filtering even for the TLS traffic (which of course will not be = possible if you
use non-NULL ciphers which you will have to for 1= .3).

-Ekr
=C2=A0
=C2=A0
=
I'm perfectly = open to using another prefix value; if you have a suggestion for a longer v= alue, that would be great!

I think I'd probably ask MT or mnot, but my instinct would be = to use some randomly chosen string
that started with IKETCP. E.g.= , IKETCP + 8ish random bytes. This just reduces the chance of
any= kind of accidental collision. I don't think it's a dealbreaker.

-Ekr


=C2=A0
Thanks,
Tommy


-Ekr


On Wed, Apr 26, 2017 at 3:46 AM, Ter= o Kivinen <kivinen@iki.fi> wrote:
Tommy Pauly writes:
> > ------------------------------------------------------------= ----------
> > DISCUSS:
> > ------------------------------------------------------------= ----------
> >
> > This draft suggests that ports that are assigned to other service= s can
> > simply be used. This is not okay. If a port is assigned to a cert= ain
> > service, this service and/or the respective RFC defines how this = port is
> > used. Simply changing the specified behavior by requiring a check= for a
> > magic number cannot be done without updating the RFC that the por= t
> > assignment belongs to. Also for the use of 4500/tcp RFC3948 as we= ll as
> > the IANA registry would need to be updated.
>
> At this point, the only portion of the document that mentions a port > other than 500 and 4500 is the appendix. We recommend that 4500 is
> used as the port for TCP encapsulation. The IANA registry for
> 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947;
> that document does not explain how TCP is to be used, so the
> reference should be updated to point to the document on TCP
> encapsulation.

I already explained this in long email to the Joe and Paul, but
noticed that those emails did not go to to the IESG, so this is mostly
cut & paste of my previous email. This does not cover anything about using any other ports, but covers the case about the IANA allocations
for TCP/4500 and UPD/4500.

-----------------------------------------------------------------= -----
Paul Wouters writes:
> On Tue, 25 Apr 2017, Joe Touch wrote:
> > Every bit pattern, including those using magic numbers, is alread= y
> > owned and under the control of each assigned port. It is not
> > appropriate for any new service to hijack that pattern as having = a
> > different meaning UNLESS explicitly updating the service on
> > that port.
> >
> > A simple summary of what needs to change, in 2119-language:
> >
> >=C2=A0 =C2=A0 - this approach MUST NOT be described as applying to= any
> >=C2=A0 =C2=A0 =C2=A0 assigned number unless also updating the asso= ciated RFC
>
> So it should add an Updates: RFC-3947

Not really. It does not update RFC3947 as it does not change the
obsoleted protocol defined in the RFC3947. It does define way to
extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
the other hand RFC3947 should have been obsoleted when we obsoleted
IKEv1, as that document only defines how to do IKEv1 NAT traversal
negotiation, and the IKEv2 NAT traversal negotation is described in
main IKEv2 RFC (RFC7296).

> It's a little weird. 3947 reserved TCP 4500, but did not specify h= ow
> to actually use TCP at all. It seems it was mostly preventatively
> reserved.

The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500
and UDP/4500 references from individual user to the RFC3947, so that
IETF will have change control over the ports. I.e., those ports were
allocated before RFC3947 came out, and they were used for several
different non-interoperable versions of the NAT traversals, which then
evolved to the standard version we define in RFC3947. We decided to
reassign both TCP and UDP port 4500 to RFC3947 so it would be clear
for what use they will be used. Also we commonly reserve both TCP and
UDP ports for same number just in case someone defines a way to run
the protocol over other transport protocol in the future...

RFC3947 does not define anything over TCP/4500. Actually RFC3947 does
not define anything over the UDP/4500 either, it is the RFC3948 that
does that. The RFC3947 just says, we use the format defined in the
RFC3948 over the UDP/4500, but is silent about the TCP/4500.

RFC3947 is efficiently obsoleted, as it only defines the way to do NAT
traversal on IKEv1, and IKEv1 is obsoleted and replaced with IKEv2
(originally RFC4306, and now RFC7296). So the RFC3947 should have been
marked as obsoleted by RFC4306. I am not sure if we want to do that in
this late.

So my proposal is update the IANA port registry for both UDP/4500 and
TCP/4500 as follows:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Keyword=C2=A0 =C2=A0 =C2=A0 =C2=A0Decimal= =C2=A0 =C2=A0 Description=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reference
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------=C2=A0 =C2=A0 =C2=A0 =C2=A0-------= =C2=A0 =C2=A0 -----------=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ---------
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipsec-nat-t=C2=A0 =C2=A04500/tcp=C2=A0 = =C2=A0IPsec NAT-Traversal=C2=A0 [RFCXXXX]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipsec-nat-t=C2=A0 =C2=A04500/udp=C2=A0 = =C2=A0IPsec NAT-Traversal=C2=A0 [RFC3948], [RFC7296]

(RFCXXXX being this RFC).

Note, that the RFC3947 on the 4500/UDP was changed to RFC3948 as the
RFC3948 actually defines the protocol used over the port. RFC3947
defines the IKEv1 negotiation over the UDP port 500 and 4500, but for
IKEv2 this is already defined in the RFC7296.

The RFC3947 could either be left as it is now, or marked as being
obsoleted by this or RFC4306, or RFC7296 or whatever. Updating
document which is effectively already obsoleted, is just wrong...
--
kivinen@iki.fi


_______________________________________________
IPsec mailing list<= br>IPsec@ietf.orghttps://www.ietf.org/mailman/listinfo/ipsec



--f403045da358682222054e259187-- From nobody Thu Apr 27 06:49:36 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0279F1294E2 for ; Thu, 27 Apr 2017 06:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klpGs7VTNtjf for ; Thu, 27 Apr 2017 06:49:32 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05AA3127B57 for ; Thu, 27 Apr 2017 06:49:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=bJ8h4HOTbFzKD1VYQX0tiPcYp9qZbkPnixue+j61C2WMls5kyLrCgMKEEs9LZ7xXXVzV5Tv7AVE17UVK6ztxhgw5HlNwOjPN+TIZdkOjY/ZIxD5kjgVgRJykuM4/9y7NltyGDO8bw0jAG+PO7G+GSjd4jCxBTdi0WVCYnHGQomQ=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 26302 invoked from network); 27 Apr 2017 15:42:49 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 15:42:49 +0200 To: Eric Rescorla References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> Cc: ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> Date: Thu, 27 Apr 2017 15:42:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170427134249.26292.69787@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:49:34 -0000 Hi Ekr, hi all, (not sure anymore which email best to reply to but I'm using this one now to partly also reply to others). See below. On 27.04.2017 14:51, Eric Rescorla wrote: > > > On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind > wrote: > > I do see the problem you have and I understand why you selected the > solution you have but that does contradict quite a bit the idea of the > port registry and I don't think it's a safe and future prove solution. > Even if people use this approach, I'm concern to publish it in an > Standards Track RFC, but I guess that's a discussion the IESG would need > to have. > > > Mirja, > > I agree that this kind of port squatting is regrettable, but I also don't > think it really > helps to not publish RFCs that document widely used protocols because we > are sad they port-squatted. > > I proposed a way to deal with this in an earlier e-mail. Would that be > satisfactory > to you. To retransmit, we add the following > > "Note: While port 4500 is the reserved port for this protocol, some existing > implementations > also use port 443. The Stream Prefix provides some mitigation against > cross-protocol > attacks in this case, however, the use of port 443 is NOT RECOMMENDED" > > We could do something similar for port 80. > > Would that work? This already is good but I think it's not enough. As Tero noted the working group thought that they rather specify a generic scheme which I find problematic. Currently the drafts says: "This document leaves the selection of TCP ports up to implementations. It is suggested to use TCP port 4500, which is allocated for IPsec NAT Traversal." Which sounds to me like an invitation to squat on any open port regardless what the port is supposed to be used for (hoping that the magic number would avoid any collision). I don't think that a good thing to right in an RFC. Now given the text you propose above, I actually assume that the text I just cited will be removed but the whole document is written with this assumption and therefore there are a couple more places where wording probably needs to change. I do understand well the problem and that 443 is used in practice. However, to match reality I would rather like to see a document that specifies the approach of encapsulating in TLS/TCP on port 443 that is used today and pure TCP encapsulation for use with port 4500 only. Again i think that's where your proposed text is heading to but I think it needs more changes; in this case it would also make sense to add the TLS part back in the main document for 443 only. Further, I have one more question: The document is written in a way that allows the implementation of multiple services on the used port. Is that actually done in reality? If we could restrict the use of this encapsulation with servers that only are IKE servers (at least for the used port), you would actually not need the magic number anymore. I guess you can still have the magic number if you really want it because that makes it easier to distinguish valid IKE/IPSec traffic from other random traffic that might be send to this port but the other service running on this port (on other servers) does not need to know about the magic number because it is supposed to never see any IKe/IPSec TCP-encapsulated traffic. Does that make sense? Mirja > > -Ekr > > > > > Mirja > > > > We can soften the references in the appendix to the fact that other > ports may, in fact, be used. As for the configuration, it should > state 4500 as the default, but allow peers to configure something > else out-of-band if they want to modify behavior (which is standard > even in UDP implementations of IKE). > > > Further, as also mentioned in the tsv-art review (Thanks Wes!), this > draft does not sufficiently handle the case of TCP in TCP > encapsulation. > Here a copy of the tsv-art review: > > Reviewer: Wesley Eddy > Review result: On the Right Track > > This document is clear and well-written. It can easily be > implemented > based on the description. > > There are a few additional issues that should be considered with > advice to implementers in Section 12 on performance considerations: > 1) Invisibility of packet loss - Inner protocols that require packet > losses as a signal of congestion (e.g. TCP) will have a challenge due > to not being able to see any packet losses since the outer TCP will > repair them (unless sending into a full outer TCP socket buffer shows > up back to the inner TCP as a packet loss?). > > > Yes, this is definitely true. We try to capture that with the line: > "This will make loss- > recovery of the inner TCP traffic less reactive and more prone to > spurious retransmission timeouts." > > However, this can certainly be expanded upon. > > 2) Nesting of ECN - Inner TCP connections will not be able to use > effectively ECN on the portion of the path covered by the outer TCP > connection. > > > Generally, IPsec tunnels will apply RFC 6040 for translating ECN > markings between inner/outer packets. Since TCP encapsulation places > the inner IP packets in a stream, there isn't a direct mapping. > > An implementation could try to roughly map, but it may be best to > suggest that the ECN markings for inner and outer packets be left > separate. What is your opinion? > > 3) Impact of congestion response on aggregate - The general "TCP in > TCP" problem is mentioned, and is mostly appropriate for a single > flow. If an aggregate of flows is sharing the same outer TCP > connection, there may be additional concerns about how the congestion > response behavior impacts an aggregate of flows, since it may cause a > shared delay spike even to low-rate flows rather than distributing > losses proportional to per-flow throughput. > > > Indeed. We can add further comments to that effect. > > 4) Additional potential for bufferbloat - Since TCP does not bound > latency, some applications in the IPsec-protected aggregate could > drive latency of the shared connection up and impact the aggregate of > flows that may include real-time applications. The socket buffer for > the outer TCP connection might need to be limited in size to ensure > some bounds? > > > We can add a comment to suggest that the buffering should be limited > on the outer connection if possible. > > > Not addressing these could lead to poor experiences in deployment, if > implementations make wrong assumptions or fail to consider them. > > > I do think all of these concerns go back to the overall > recommendation of "use direct ESP or UDP Encapsulation whenever > possible". Anything to help back up that point is great! > > Thanks, > Tommy > > > In the security considerations section, there are several RFCs on > mechanisms to increase robustness to RST attacks and SYN floods that > could be mentioned if it's worthwhile. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > From nobody Thu Apr 27 06:50:56 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04F5129516 for ; Thu, 27 Apr 2017 06:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aa_mcjMslsCN for ; Thu, 27 Apr 2017 06:50:52 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13905129479 for ; Thu, 27 Apr 2017 06:50:52 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id 203so15760536ywe.0 for ; Thu, 27 Apr 2017 06:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b1F6i2SErwzROYJ226hV1jh/4jDL6+mlsoOUj2h74Mc=; b=iJneklI4RcGx4JNFK/qtDjVS3YVpv0rih/q8xgu056/eb2tnPLBQRYlZ3EgY1a+wgm OwuWgRfJddseylwOVEDzDJMx4Jb95qbYQxMrB0MoEyIOfjx5h9j90QI3ebCmOsEvUVcH WgcStjMNdorwYVf212VsgPf6jEdvauvOZ/x4lCXJCGphNwfPNDlNWJOyhrm9f7xjH/Bp yYPfoIPLFT4MUjGmdHnv64VDv379/xIuvuJFJ+aVN1vXcBDQIrlZ0nna35pcU6gS6esM NeFe2FqmSfVDZI6paxA0RFIVlhMa9LAkSMYr5LsKglUeZuHvdzLOJOfcwLfmnhgCLwX3 ZUJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b1F6i2SErwzROYJ226hV1jh/4jDL6+mlsoOUj2h74Mc=; b=ue95xJ9phxP11X+TFoWMsqK9IEqkMmaolmJbiE6r6KolcQBp6HzESU0ssFH1ZL79Ar +vjujMawK4EaM5mcnSsM3fyfSw4R7CqdsswQ//+ky9iML7RKJzFq4Q9z8OhedFJQQ4pz v2sTckcmasU0ZVJwUWZat7Z5vMqivJkfiA7W8CUs8QrhuUFxNGfwcgQyUR+QSG2/4qFu suEjvLZeDdpmOqZYsAnfdAke23XN/Q8aOC5acBcHedjwx7oe0XpWFkSFrHZOSgqrdqbi b7tfolRmwhj2YD+Gzvx2ePFudY6RrMqcwsOWmYMS01K+8QVi7srWW1j9VouzAwmnRKF/ Li7g== X-Gm-Message-State: AN3rC/6H9hetwNN4m9YYygzBj3dy7/T68ar8z9eRhEpEIPXwFdy9qeVz +7n/GGlzn2LNyvY1LAGy/xM5V3rppQ== X-Received: by 10.129.93.137 with SMTP id r131mr4296791ywb.312.1493301051119; Thu, 27 Apr 2017 06:50:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 06:50:10 -0700 (PDT) In-Reply-To: <4f5900d2-a795-8bb4-a89d-dad51e4a6f09@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <4f5900d2-a795-8bb4-a89d-dad51e4a6f09@kuehlewind.net> From: Eric Rescorla Date: Thu, 27 Apr 2017 06:50:10 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly Content-Type: multipart/alternative; boundary=001a114d71bab200c4054e263ee2 Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:50:54 -0000 --001a114d71bab200c4054e263ee2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2017 at 6:46 AM, Mirja K=C3=BChlewind wrote: > One more side comment on the magic number: actually the magic number make= s > it easy for network operator to identify IKE/IPSec traffic on any port an= d > block all packets that below to a flow that started with this pattern in > the first payload packet. So if you really think you need a magic number, > you should probably always encrypt it. > > My impression was that the point of this was not to evade future operators who are trying to block IKE, but merely to deal with the problem of over-aggressive middleboxes which currently block IKE, mostly accidentally. Certainly that's how we think of things over in WebRTC land. -Ekr > On 27.04.2017 15:42, Mirja K=C3=BChlewind wrote: > >> Hi Ekr, hi all, >> >> (not sure anymore which email best to reply to but I'm using this one no= w >> to >> partly also reply to others). >> >> See below. >> >> On 27.04.2017 14:51, Eric Rescorla wrote: >> >>> >>> >>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BChlewind >> > wrote: >>> >>> I do see the problem you have and I understand why you selected the >>> solution you have but that does contradict quite a bit the idea of >>> the >>> port registry and I don't think it's a safe and future prove >>> solution. >>> Even if people use this approach, I'm concern to publish it in an >>> Standards Track RFC, but I guess that's a discussion the IESG would >>> need >>> to have. >>> >>> >>> Mirja, >>> >>> I agree that this kind of port squatting is regrettable, but I also don= 't >>> think it really >>> helps to not publish RFCs that document widely used protocols because w= e >>> are sad they port-squatted. >>> >>> I proposed a way to deal with this in an earlier e-mail. Would that be >>> satisfactory >>> to you. To retransmit, we add the following >>> >>> "Note: While port 4500 is the reserved port for this protocol, some >>> existing >>> implementations >>> also use port 443. The Stream Prefix provides some mitigation against >>> cross-protocol >>> attacks in this case, however, the use of port 443 is NOT RECOMMENDED" >>> >>> We could do something similar for port 80. >>> >>> Would that work? >>> >> >> This already is good but I think it's not enough. As Tero noted the >> working >> group thought that they rather specify a generic scheme which I find >> problematic. Currently the drafts says: >> >> "This document leaves the selection of TCP ports up to >> implementations. It is suggested to use TCP port 4500, which is >> allocated for IPsec NAT Traversal." >> >> Which sounds to me like an invitation to squat on any open port regardle= ss >> what the port is supposed to be used for (hoping that the magic number >> would >> avoid any collision). I don't think that a good thing to right in an RFC= . >> >> Now given the text you propose above, I actually assume that the text I >> just >> cited will be removed but the whole document is written with this >> assumption >> and therefore there are a couple more places where wording probably need= s >> to >> change. >> >> I do understand well the problem and that 443 is used in practice. >> However, >> to match reality I would rather like to see a document that specifies th= e >> approach of encapsulating in TLS/TCP on port 443 that is used today and >> pure >> TCP encapsulation for use with port 4500 only. Again i think that's wher= e >> your proposed text is heading to but I think it needs more changes; in >> this >> case it would also make sense to add the TLS part back in the main >> document >> for 443 only. >> >> Further, I have one more question: The document is written in a way that >> allows the implementation of multiple services on the used port. Is that >> actually done in reality? If we could restrict the use of this >> encapsulation >> with servers that only are IKE servers (at least for the used port), you >> would actually not need the magic number anymore. I guess you can still >> have >> the magic number if you really want it because that makes it easier to >> distinguish valid IKE/IPSec traffic from other random traffic that might >> be >> send to this port but the other service running on this port (on other >> servers) does not need to know about the magic number because it is >> supposed >> to never see any IKe/IPSec TCP-encapsulated traffic. >> >> Does that make sense? >> >> Mirja >> >> >> >> >>> -Ekr >>> >>> >>> >>> >>> Mirja >>> >>> >>> >>> We can soften the references in the appendix to the fact that >>> other >>> ports may, in fact, be used. As for the configuration, it shoul= d >>> state 4500 as the default, but allow peers to configure somethi= ng >>> else out-of-band if they want to modify behavior (which is >>> standard >>> even in UDP implementations of IKE). >>> >>> >>> Further, as also mentioned in the tsv-art review (Thanks >>> Wes!), this >>> draft does not sufficiently handle the case of TCP in TCP >>> encapsulation. >>> Here a copy of the tsv-art review: >>> >>> Reviewer: Wesley Eddy >>> Review result: On the Right Track >>> >>> This document is clear and well-written. It can easily be >>> implemented >>> based on the description. >>> >>> There are a few additional issues that should be considered >>> with >>> advice to implementers in Section 12 on performance >>> considerations: >>> 1) Invisibility of packet loss - Inner protocols that >>> require packet >>> losses as a signal of congestion (e.g. TCP) will have a >>> challenge due >>> to not being able to see any packet losses since the outer >>> TCP will >>> repair them (unless sending into a full outer TCP socket >>> buffer shows >>> up back to the inner TCP as a packet loss?). >>> >>> >>> Yes, this is definitely true. We try to capture that with the >>> line: >>> "This will make loss- >>> recovery of the inner TCP traffic less reactive and more >>> prone to >>> spurious retransmission timeouts." >>> >>> However, this can certainly be expanded upon. >>> >>> 2) Nesting of ECN - Inner TCP connections will not be able >>> to use >>> effectively ECN on the portion of the path covered by the >>> outer TCP >>> connection. >>> >>> >>> Generally, IPsec tunnels will apply RFC 6040 for translating EC= N >>> markings between inner/outer packets. Since TCP encapsulation >>> places >>> the inner IP packets in a stream, there isn't a direct mapping. >>> >>> An implementation could try to roughly map, but it may be best = to >>> suggest that the ECN markings for inner and outer packets be le= ft >>> separate. What is your opinion? >>> >>> 3) Impact of congestion response on aggregate - The general >>> "TCP in >>> TCP" problem is mentioned, and is mostly appropriate for a >>> single >>> flow. If an aggregate of flows is sharing the same outer T= CP >>> connection, there may be additional concerns about how the >>> congestion >>> response behavior impacts an aggregate of flows, since it >>> may cause a >>> shared delay spike even to low-rate flows rather than >>> distributing >>> losses proportional to per-flow throughput. >>> >>> >>> Indeed. We can add further comments to that effect. >>> >>> 4) Additional potential for bufferbloat - Since TCP does no= t >>> bound >>> latency, some applications in the IPsec-protected aggregate >>> could >>> drive latency of the shared connection up and impact the >>> aggregate of >>> flows that may include real-time applications. The socket >>> buffer for >>> the outer TCP connection might need to be limited in size t= o >>> ensure >>> some bounds? >>> >>> >>> We can add a comment to suggest that the buffering should be >>> limited >>> on the outer connection if possible. >>> >>> >>> Not addressing these could lead to poor experiences in >>> deployment, if >>> implementations make wrong assumptions or fail to consider >>> them. >>> >>> >>> I do think all of these concerns go back to the overall >>> recommendation of "use direct ESP or UDP Encapsulation whenever >>> possible". Anything to help back up that point is great! >>> >>> Thanks, >>> Tommy >>> >>> >>> In the security considerations section, there are several >>> RFCs on >>> mechanisms to increase robustness to RST attacks and SYN >>> floods that >>> could be mentioned if it's worthwhile. >>> >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> >>> >>> >> --001a114d71bab200c4054e263ee2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 6:46 AM, Mirja K=C3=BChlewind <ietf@kuehlewi= nd.net> wrote:
One more sid= e comment on the magic number: actually the magic number makes it easy for = network operator to identify IKE/IPSec traffic on any port and block all pa= ckets that below to a flow that started with this pattern in the first payl= oad packet. So if you really think you need a magic number, you should prob= ably always encrypt it.


My impression was that the point of th= is was not to evade future operators
who are trying to block IKE,= but merely to deal with the problem of over-aggressive
middlebox= es which currently block IKE, mostly accidentally. Certainly that's how=
we think of things over in WebRTC land.

-Ekr


On 27.04.2017 15:42, Mirja K=C3=BChlewind wrote:
Hi Ekr, hi all,

(not sure anymore which email best to reply to but I'm using this one n= ow to
partly also reply to others).

See below.

On 27.04.2017 14:51, Eric Rescorla wrote:


On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net
<mailto:ietf@ku= ehlewind.net>> wrote:

=C2=A0 =C2=A0 I do see the problem you have and I understand why you select= ed the
=C2=A0 =C2=A0 solution you have but that does contradict quite a bit the id= ea of the
=C2=A0 =C2=A0 port registry and I don't think it's a safe and futur= e prove solution.
=C2=A0 =C2=A0 Even if people use this approach, I'm concern to publish = it in an
=C2=A0 =C2=A0 Standards Track RFC, but I guess that's a discussion the = IESG would need
=C2=A0 =C2=A0 to have.


Mirja,

I agree that this kind of port squatting is regrettable, but I also don'= ;t
think it really
helps to not publish RFCs that document widely used protocols because we are sad they port-squatted.

I proposed a way to deal with this in an earlier e-mail. Would that be
satisfactory
to you. To retransmit, we add the following

"Note: While port 4500 is the reserved port for this protocol, some ex= isting
implementations
also use port 443. The Stream Prefix provides some mitigation against
cross-protocol
attacks in this case, however, the use of port 443 is NOT RECOMMENDED"=

We could do something similar for port 80.

Would that work?

This already is good but I think it's not enough. As Tero noted the wor= king
group thought that they rather specify a generic scheme which I find
problematic. Currently the drafts says:

"This document leaves the selection of TCP ports up to
=C2=A0 =C2=A0 implementations.=C2=A0 It is suggested to use TCP port 4500, = which is
=C2=A0 =C2=A0 allocated for IPsec NAT Traversal."

Which sounds to me like an invitation to squat on any open port regardless<= br> what the port is supposed to be used for (hoping that the magic number woul= d
avoid any collision). I don't think that a good thing to right in an RF= C.

Now given the text you propose above, I actually assume that the text I jus= t
cited will be removed but the whole document is written with this assumptio= n
and therefore there are a couple more places where wording probably needs t= o
change.

I do understand well the problem and that 443 is used in practice. However,=
to match reality I would rather like to see a document that specifies the approach of encapsulating in TLS/TCP on port 443 that is used today and pur= e
TCP encapsulation for use with port 4500 only. Again i think that's whe= re
your proposed text is heading to but I think it needs more changes; in this=
case it would also make sense to add the TLS part back in the main document=
for 443 only.

Further, I have one more question: The document is written in a way that allows the implementation of multiple services on the used port. Is that actually done in reality? If we could restrict the use of this encapsulatio= n
with servers that only are IKE servers (at least for the used port), you would actually not need the magic number anymore. I guess you can still hav= e
the magic number if you really want it because that makes it easier to
distinguish valid IKE/IPSec traffic from other random traffic that might be=
send to this port but the other service running on this port (on other
servers) does not need to know about the magic number because it is suppose= d
to never see any IKe/IPSec TCP-encapsulated traffic.

Does that make sense?

Mirja




-Ekr




=C2=A0 =C2=A0 Mirja



=C2=A0 =C2=A0 =C2=A0 =C2=A0 We can soften the references in the appendix to= the fact that other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ports may, in fact, be used. As for the configu= ration, it should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 state 4500 as the default, but allow peers to c= onfigure something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else out-of-band if they want to modify behavio= r (which is standard
=C2=A0 =C2=A0 =C2=A0 =C2=A0 even in UDP implementations of IKE).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Further, as also mentioned in the= tsv-art review (Thanks Wes!), this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft does not sufficiently handl= e the case of TCP in TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulation.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Here a copy of the tsv-art review= :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reviewer: Wesley Eddy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Review result: On the Right Track=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This document is clear and well-w= ritten.=C2=A0 It can easily be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implemented
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 based on the description.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 There are a few additional issues= that should be considered with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 advice to implementers in Section= 12 on performance considerations:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1) Invisibility of packet loss - = Inner protocols that require packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 losses as a signal of congestion = (e.g. TCP) will have a challenge due
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to not being able to see any pack= et losses since the outer TCP will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 repair them (unless sending into = a full outer TCP socket buffer shows
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 up back to the inner TCP as a pac= ket loss?).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes, this is definitely true. We try to capture= that with the line:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "This will make loss-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recovery of the inner TCP traffic = less reactive and more prone to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spurious retransmission timeouts.&= quot;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, this can certainly be expanded upon.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Nesting of ECN -=C2=A0 Inner T= CP connections will not be able to use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 effectively ECN on the portion of= the path covered by the outer TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connection.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Generally, IPsec tunnels will apply RFC 6040 fo= r translating ECN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 markings between inner/outer packets. Since TCP= encapsulation places
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the inner IP packets in a stream, there isn'= ;t a direct mapping.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 An implementation could try to roughly map, but= it may be best to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 suggest that the ECN markings for inner and out= er packets be left
=C2=A0 =C2=A0 =C2=A0 =C2=A0 separate. What is your opinion?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Impact of congestion response = on aggregate - The general "TCP in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP" problem is mentioned, a= nd is mostly appropriate for a single
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flow.=C2=A0 If an aggregate of fl= ows is sharing the same outer TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connection, there may be addition= al concerns about how the congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 response behavior impacts an aggr= egate of flows, since it may cause a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 shared delay spike even to low-ra= te flows rather than distributing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 losses proportional to per-flow t= hroughput.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Indeed. We can add further comments to that eff= ect.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4) Additional potential for buffe= rbloat - Since TCP does not bound
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 latency, some applications in the= IPsec-protected aggregate could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 drive latency of the shared conne= ction up and impact the aggregate of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flows that may include real-time = applications.=C2=A0 The socket buffer for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the outer TCP connection might ne= ed to be limited in size to ensure
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 some bounds?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 We can add a comment to suggest that the buffer= ing should be limited
=C2=A0 =C2=A0 =C2=A0 =C2=A0 on the outer connection if possible.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Not addressing these could lead t= o poor experiences in deployment, if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementations make wrong assump= tions or fail to consider them.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I do think all of these concerns go back to the= overall
=C2=A0 =C2=A0 =C2=A0 =C2=A0 recommendation of "use direct ESP or UDP E= ncapsulation whenever
=C2=A0 =C2=A0 =C2=A0 =C2=A0 possible". Anything to help back up that p= oint is great!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tommy


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In the security considerations se= ction, there are several RFCs on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms to increase robustness= to RST attacks and SYN floods that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could be mentioned if it's wo= rthwhile.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPsec mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPsec@ietf.org <mailto:IPsec@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.iet= f.org/mailman/listinfo/ipsec
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www= .ietf.org/mailman/listinfo/ipsec>



=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 IPsec mailing list
=C2=A0 =C2=A0 IPsec@iet= f.org <mailto:IP= sec@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/ipsec
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listi= nfo/ipsec>




--001a114d71bab200c4054e263ee2-- From nobody Thu Apr 27 06:51:18 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 250D0129521 for ; Thu, 27 Apr 2017 06:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1YW4N3U8nkZ for ; Thu, 27 Apr 2017 06:51:02 -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 DF7171294F7 for ; Thu, 27 Apr 2017 06:51:01 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3RDovdd010398 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 16:50:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3RDovi2018198; Thu, 27 Apr 2017 16:50:57 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22785.63297.423256.805596@fireball.acr.fi> Date: Thu, 27 Apr 2017 16:50:57 +0300 From: Tero Kivinen To: Spencer Dawkins at IETF Cc: , Tommy Pauly , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG In-Reply-To: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 11 min X-Total-Time: 10 min Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:51:03 -0000 Spencer Dawkins at IETF writes: > The reason optional ports in URIs work, is that someone handed you a URI with > that port number who has some reason to believe that the port number is OK to > use with the host included in the URI. > > Is that a reasonable assumption about the way IPsec and IKE over TCP will be > deployed? That no Initiator would assume that another host is an IKE > Responder, without being configured to use that host? I have been using following matrix to understand the IETF security protocols: +---------------------+-----------------------+------------------+ | | "Kernel" mode | Application mode | +---------------------+-----------------------+------------------+ | Pre-configuration | IPsec | Secure Shell | | required | | | +---------------------+-----------------------+------------------+ | No per host | HIP | SSL/TLS | | pre configuration | / | | | needed / | TCPINC | | | opportunistic | | | +---------------------+-----------------------+------------------+ Kernel mode means it is implemented inside the operating system kernel or libraries, and Application mode means it is part of the application level implementation. Pre-configuration required means that both ends needs to be pre-configured to accept the connection. I.e., there is no point of trying to use ssh to connect host kivinen.iki.fi unless you have account and some method of authentication token for that host. Same with IPsec, you cannot assume that other end talks IPsec and allows you to connect unless you have pre-configured both ends to support it. Even when using opportunistic IPsec this is mostly same, there is no point of even trying to use opportunistic IPsec to www.google.com, and assume it would work. It might be that at some day we are there, and we have opportunistic IPsec installed in every single host, but we are not there now, and main use of IPsec is with pre-configuration. With HIP and TCPINC you always assume that you simply connect the other end and you do not need per host configuration. The connection either works or not, and if not you fall back to TCP (TCPINC), or just fail (with HIP adding configuration might help). With TLS you can just assume that other end allows you to connect if it supports TLS at all, and this is because everybody is "pre-configured" with same trusted anchor list, but there is no need for per-host configuration. So short answer to your question is: IPsec do require pre-configuration, so if configuration says that IP address x.y.z.0 talks IPsec over TCP on port 1234, then you do that. If there is no configuration then you usually just fail, as you do not know what authentication credentials you are supposed to use. -- kivinen@iki.fi From nobody Thu Apr 27 06:53:04 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30412129516 for ; Thu, 27 Apr 2017 06:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyX1Nzrx8LmV for ; Thu, 27 Apr 2017 06:53:01 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D90DA1294F7 for ; Thu, 27 Apr 2017 06:53:00 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=IIOXfjf+H82DDqBabakbuCjccv6FGyxEgcJAG1Tt6QSWH+fNSamNtawYPsv1R/SH4B8xdMDZe1PQQyfoX+OnmIxBT4r86/ybpdOx6j76rvZsgENhTwV0e3zt5Q5ipLbH9oNYZI26v+ls4QSYU8yNWTcGiyiYv7N+sLaQpjwG2Vk=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 26481 invoked from network); 27 Apr 2017 15:46:18 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 15:46:18 +0200 To: Eric Rescorla References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> Cc: ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <4f5900d2-a795-8bb4-a89d-dad51e4a6f09@kuehlewind.net> Date: Thu, 27 Apr 2017 15:46:17 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170427134618.26471.94961@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:53:03 -0000 One more side comment on the magic number: actually the magic number makes it easy for network operator to identify IKE/IPSec traffic on any port and block all packets that below to a flow that started with this pattern in the first payload packet. So if you really think you need a magic number, you should probably always encrypt it. On 27.04.2017 15:42, Mirja Kühlewind wrote: > Hi Ekr, hi all, > > (not sure anymore which email best to reply to but I'm using this one now to > partly also reply to others). > > See below. > > On 27.04.2017 14:51, Eric Rescorla wrote: >> >> >> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind > > wrote: >> >> I do see the problem you have and I understand why you selected the >> solution you have but that does contradict quite a bit the idea of the >> port registry and I don't think it's a safe and future prove solution. >> Even if people use this approach, I'm concern to publish it in an >> Standards Track RFC, but I guess that's a discussion the IESG would need >> to have. >> >> >> Mirja, >> >> I agree that this kind of port squatting is regrettable, but I also don't >> think it really >> helps to not publish RFCs that document widely used protocols because we >> are sad they port-squatted. >> >> I proposed a way to deal with this in an earlier e-mail. Would that be >> satisfactory >> to you. To retransmit, we add the following >> >> "Note: While port 4500 is the reserved port for this protocol, some existing >> implementations >> also use port 443. The Stream Prefix provides some mitigation against >> cross-protocol >> attacks in this case, however, the use of port 443 is NOT RECOMMENDED" >> >> We could do something similar for port 80. >> >> Would that work? > > This already is good but I think it's not enough. As Tero noted the working > group thought that they rather specify a generic scheme which I find > problematic. Currently the drafts says: > > "This document leaves the selection of TCP ports up to > implementations. It is suggested to use TCP port 4500, which is > allocated for IPsec NAT Traversal." > > Which sounds to me like an invitation to squat on any open port regardless > what the port is supposed to be used for (hoping that the magic number would > avoid any collision). I don't think that a good thing to right in an RFC. > > Now given the text you propose above, I actually assume that the text I just > cited will be removed but the whole document is written with this assumption > and therefore there are a couple more places where wording probably needs to > change. > > I do understand well the problem and that 443 is used in practice. However, > to match reality I would rather like to see a document that specifies the > approach of encapsulating in TLS/TCP on port 443 that is used today and pure > TCP encapsulation for use with port 4500 only. Again i think that's where > your proposed text is heading to but I think it needs more changes; in this > case it would also make sense to add the TLS part back in the main document > for 443 only. > > Further, I have one more question: The document is written in a way that > allows the implementation of multiple services on the used port. Is that > actually done in reality? If we could restrict the use of this encapsulation > with servers that only are IKE servers (at least for the used port), you > would actually not need the magic number anymore. I guess you can still have > the magic number if you really want it because that makes it easier to > distinguish valid IKE/IPSec traffic from other random traffic that might be > send to this port but the other service running on this port (on other > servers) does not need to know about the magic number because it is supposed > to never see any IKe/IPSec TCP-encapsulated traffic. > > Does that make sense? > > Mirja > > > >> >> -Ekr >> >> >> >> >> Mirja >> >> >> >> We can soften the references in the appendix to the fact that other >> ports may, in fact, be used. As for the configuration, it should >> state 4500 as the default, but allow peers to configure something >> else out-of-band if they want to modify behavior (which is standard >> even in UDP implementations of IKE). >> >> >> Further, as also mentioned in the tsv-art review (Thanks Wes!), this >> draft does not sufficiently handle the case of TCP in TCP >> encapsulation. >> Here a copy of the tsv-art review: >> >> Reviewer: Wesley Eddy >> Review result: On the Right Track >> >> This document is clear and well-written. It can easily be >> implemented >> based on the description. >> >> There are a few additional issues that should be considered with >> advice to implementers in Section 12 on performance considerations: >> 1) Invisibility of packet loss - Inner protocols that require packet >> losses as a signal of congestion (e.g. TCP) will have a challenge due >> to not being able to see any packet losses since the outer TCP will >> repair them (unless sending into a full outer TCP socket buffer shows >> up back to the inner TCP as a packet loss?). >> >> >> Yes, this is definitely true. We try to capture that with the line: >> "This will make loss- >> recovery of the inner TCP traffic less reactive and more prone to >> spurious retransmission timeouts." >> >> However, this can certainly be expanded upon. >> >> 2) Nesting of ECN - Inner TCP connections will not be able to use >> effectively ECN on the portion of the path covered by the outer TCP >> connection. >> >> >> Generally, IPsec tunnels will apply RFC 6040 for translating ECN >> markings between inner/outer packets. Since TCP encapsulation places >> the inner IP packets in a stream, there isn't a direct mapping. >> >> An implementation could try to roughly map, but it may be best to >> suggest that the ECN markings for inner and outer packets be left >> separate. What is your opinion? >> >> 3) Impact of congestion response on aggregate - The general "TCP in >> TCP" problem is mentioned, and is mostly appropriate for a single >> flow. If an aggregate of flows is sharing the same outer TCP >> connection, there may be additional concerns about how the congestion >> response behavior impacts an aggregate of flows, since it may cause a >> shared delay spike even to low-rate flows rather than distributing >> losses proportional to per-flow throughput. >> >> >> Indeed. We can add further comments to that effect. >> >> 4) Additional potential for bufferbloat - Since TCP does not bound >> latency, some applications in the IPsec-protected aggregate could >> drive latency of the shared connection up and impact the aggregate of >> flows that may include real-time applications. The socket buffer for >> the outer TCP connection might need to be limited in size to ensure >> some bounds? >> >> >> We can add a comment to suggest that the buffering should be limited >> on the outer connection if possible. >> >> >> Not addressing these could lead to poor experiences in deployment, if >> implementations make wrong assumptions or fail to consider them. >> >> >> I do think all of these concerns go back to the overall >> recommendation of "use direct ESP or UDP Encapsulation whenever >> possible". Anything to help back up that point is great! >> >> Thanks, >> Tommy >> >> >> In the security considerations section, there are several RFCs on >> mechanisms to increase robustness to RST attacks and SYN floods that >> could be mentioned if it's worthwhile. >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> > From nobody Thu Apr 27 06:56:57 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E33129522; Thu, 27 Apr 2017 06:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbZ0cv2tiZ81; Thu, 27 Apr 2017 06:56:54 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002: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 F39A8129516; Thu, 27 Apr 2017 06:56:53 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id 203so15852059ywe.0; Thu, 27 Apr 2017 06:56:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tw9WIqHH4Dd5Dgh4+bXtt9r3G280G2TcCQvTY5GXcfs=; b=UOlWYtoVRZPn5wuRmbYjmdH4EX+7PoxS/K7RPp1eRgGkjEzAfZcoHtLjEJBg/dMgBa HjyJTuxUbtJb7djV2BPUarggx8bCqAHeA5QGCANE4R0yrBvv4cdxIEmtly2gVGR4ncjC JvvrsyZoRV4bEKArHbsuXUO7kSaPUaB+v/s5lSNVrFmSmy2nbeZfHM6IU4cWjpyina7H L+KR2oLWy+VSsJO8/Hm7NaCAYWUUnoYSPXbo1W3VREOTuHHJWZSZ+1DO4AfX1Ls1v+Ks bgC2KEOM4FkxqHEl/X3d7fxJdy6JGI8M0FiHrOK826oDSdodIBgP45KxfnYJSlqB7aTa VkZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tw9WIqHH4Dd5Dgh4+bXtt9r3G280G2TcCQvTY5GXcfs=; b=qN7xs1s/lbODfZl6zLMLjNXdufEQr+SKRz5M+PbDnZPltGaS/RNBEd5KZzcb/rO7+i EbJGqhcIceRtDsVhy2OZFNpAkj/B1mu028sME7gPq8YH2wjdRAmNsfaoReAC6d0+X6Kz MI/Y6VpdVT4gtGSJ25m5PPl3yTvbPEXmh5Bwbbs0MDzvzq0/CwMIIpIBmeqJw8Yj/F0D fbLCESP11+YRaCDhZYN0ZTVTO6Kar8CzQm1d6wzwSloj2GAgRkJOFtAKB1LuHBoJHwoA kl2wboQxHavTdBcUgwkR0Sa1EsVgKijPRU5pEekNNwXrGrPdlDAwPFRc+neMIxEUx8MX eohA== X-Gm-Message-State: AN3rC/5tp1kXbByJiQd+JfowXSJX0TQs7pbkipe49UwSj/rnclOszGnI 1it5fVF3chJeFVMCzr7vpWazvVV0ZA== X-Received: by 10.129.62.22 with SMTP id l22mr4777776ywa.37.1493301413173; Thu, 27 Apr 2017 06:56:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Thu, 27 Apr 2017 06:56:52 -0700 (PDT) In-Reply-To: <22785.63297.423256.805596@fireball.acr.fi> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22785.63297.423256.805596@fireball.acr.fi> From: Spencer Dawkins at IETF Date: Thu, 27 Apr 2017 08:56:52 -0500 Message-ID: To: Tero Kivinen Cc: Mirja Kuehlewind , Tommy Pauly , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org, The IESG Content-Type: multipart/alternative; boundary=f403045f2d9246626d054e26545d Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 13:56:55 -0000 --f403045f2d9246626d054e26545d Content-Type: text/plain; charset=UTF-8 Tero, Top-posting, because I'm only saying "thank you, that's very helpful". Spencer On Thu, Apr 27, 2017 at 8:50 AM, Tero Kivinen wrote: > Spencer Dawkins at IETF writes: > > The reason optional ports in URIs work, is that someone handed you a URI > with > > that port number who has some reason to believe that the port number is > OK to > > use with the host included in the URI. > > > > Is that a reasonable assumption about the way IPsec and IKE over TCP > will be > > deployed? That no Initiator would assume that another host is an IKE > > Responder, without being configured to use that host? > > I have been using following matrix to understand the IETF security > protocols: > > +---------------------+-----------------------+------------------+ > | | "Kernel" mode | Application mode | > +---------------------+-----------------------+------------------+ > | Pre-configuration | IPsec | Secure Shell | > | required | | | > +---------------------+-----------------------+------------------+ > | No per host | HIP | SSL/TLS | > | pre configuration | / | | > | needed / | TCPINC | | > | opportunistic | | | > +---------------------+-----------------------+------------------+ > > Kernel mode means it is implemented inside the operating system kernel > or libraries, and Application mode means it is part of the application > level implementation. > > Pre-configuration required means that both ends needs to be > pre-configured to accept the connection. I.e., there is no point of > trying to use ssh to connect host kivinen.iki.fi unless you have > account and some method of authentication token for that host. Same > with IPsec, you cannot assume that other end talks IPsec and allows > you to connect unless you have pre-configured both ends to support it. > > Even when using opportunistic IPsec this is mostly same, there is no > point of even trying to use opportunistic IPsec to www.google.com, and > assume it would work. It might be that at some day we are there, and > we have opportunistic IPsec installed in every single host, but we are > not there now, and main use of IPsec is with pre-configuration. > > With HIP and TCPINC you always assume that you simply connect the > other end and you do not need per host configuration. The connection > either works or not, and if not you fall back to TCP (TCPINC), or just > fail (with HIP adding configuration might help). > > With TLS you can just assume that other end allows you to connect if > it supports TLS at all, and this is because everybody is > "pre-configured" with same trusted anchor list, but there is no need > for per-host configuration. > > So short answer to your question is: IPsec do require > pre-configuration, so if configuration says that IP address x.y.z.0 > talks IPsec over TCP on port 1234, then you do that. If there is no > configuration then you usually just fail, as you do not know what > authentication credentials you are supposed to use. > -- > kivinen@iki.fi > --f403045f2d9246626d054e26545d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Tero,

Top-posting, because I'm only= saying "thank you, that's very helpful".

Spencer

On Thu, Apr 27, 2017 at 8:50 AM, Tero Kivinen <= ;kivinen@iki.fi>= wrote:
Spencer Dawkins at IETF wr= ites:
> The reason optional ports in URIs work, is that someone handed you a U= RI with
> that port number who has some reason to believe that the port number i= s OK to
> use with the host included in the URI.
>
> Is that a reasonable assumption about the way IPsec and IKE over TCP w= ill be
> deployed? That no Initiator would assume that another host is an IKE > Responder, without being configured to use that host?

I have been using following matrix to understand the IETF security
protocols:

+---------------------+-----------------------+------------------= +
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0| "Kernel" mode=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Application= mode |
+---------------------+-----------------------+------------------= +
| Pre-configuration=C2=A0 =C2=A0| IPsec=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| Secure Shell=C2=A0 =C2=A0 =C2=A0|
| required=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+---------------------+-----------------------+------------------= +
| No per host=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| HIP=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| SSL/TLS=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
| pre configuration=C2=A0 =C2=A0| /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| needed /=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | TCPINC=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
| opportunistic=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+---------------------+-----------------------+------------------= +

Kernel mode means it is implemented inside the operating system kernel
or libraries, and Application mode means it is part of the application
level implementation.

Pre-configuration required means that both ends needs to be
pre-configured to accept the connection. I.e., there is no point of
trying to use ssh to connect host kivinen.iki.fi unless you have
account and some method of authentication token for that host. Same
with IPsec, you cannot assume that other end talks IPsec and allows
you to connect unless you have pre-configured both ends to support it.

Even when using opportunistic IPsec this is mostly same, there is no
point of even trying to use opportunistic IPsec to www.google.com, and
assume it would work. It might be that at some day we are there, and
we have opportunistic IPsec installed in every single host, but we are
not there now, and main use of IPsec is with pre-configuration.

With HIP and TCPINC you always assume that you simply connect the
other end and you do not need per host configuration. The connection
either works or not, and if not you fall back to TCP (TCPINC), or just
fail (with HIP adding configuration might help).

With TLS you can just assume that other end allows you to connect if
it supports TLS at all, and this is because everybody is
"pre-configured" with same trusted anchor list, but there is no n= eed
for per-host configuration.

So short answer to your question is: IPsec do require
pre-configuration, so if configuration says that IP address x.y.z.0
talks IPsec over TCP on port 1234, then you do that. If there is no
configuration then you usually just fail, as you do not know what
authentication credentials you are supposed to use.
--
kivinen@iki.fi

--f403045f2d9246626d054e26545d-- From nobody Thu Apr 27 07:03:28 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1192129512 for ; Thu, 27 Apr 2017 07:03:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9okq-bs6jXy for ; Thu, 27 Apr 2017 07:03:09 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DCC4129530 for ; Thu, 27 Apr 2017 07:03:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=M6u93yaCTqfmrfcnGULHF6oO4Xg6scOvfXMgp05Sdm/7qKrTZVLaBAt0eeQeI4jbUmcRZ09WBDI2KeeYWQe4vUGbCAmt4r6qePwUnQYciz/hhfC+FwBsL76hyAiXwndWCPHZ/HFz61uCSiv+uFsmkuHgPST1bRSIZ1ecSt4Mtn8=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 28094 invoked from network); 27 Apr 2017 16:03:05 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 16:03:05 +0200 To: Eric Rescorla References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <4f5900d2-a795-8bb4-a89d-dad51e4a6f09@kuehlewind.net> Cc: ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <2d56db7e-7ffd-0bea-a6d7-a494d9cdda4e@kuehlewind.net> Date: Thu, 27 Apr 2017 16:03:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170427140305.28084.86125@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:03:11 -0000 Yes, just saying... On 27.04.2017 15:50, Eric Rescorla wrote: > > > On Thu, Apr 27, 2017 at 6:46 AM, Mirja Kühlewind > wrote: > > One more side comment on the magic number: actually the magic number > makes it easy for network operator to identify IKE/IPSec traffic on any > port and block all packets that below to a flow that started with this > pattern in the first payload packet. So if you really think you need a > magic number, you should probably always encrypt it. > > > My impression was that the point of this was not to evade future operators > who are trying to block IKE, but merely to deal with the problem of > over-aggressive > middleboxes which currently block IKE, mostly accidentally. Certainly that's how > we think of things over in WebRTC land. > > -Ekr > > > On 27.04.2017 15 :42, Mirja Kühlewind wrote: > > Hi Ekr, hi all, > > (not sure anymore which email best to reply to but I'm using this one > now to > partly also reply to others). > > See below. > > On 27.04.2017 14 :51, Eric Rescorla wrote: > > > > On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind > > >> wrote: > > I do see the problem you have and I understand why you > selected the > solution you have but that does contradict quite a bit the > idea of the > port registry and I don't think it's a safe and future prove > solution. > Even if people use this approach, I'm concern to publish it in an > Standards Track RFC, but I guess that's a discussion the IESG > would need > to have. > > > Mirja, > > I agree that this kind of port squatting is regrettable, but I > also don't > think it really > helps to not publish RFCs that document widely used protocols > because we > are sad they port-squatted. > > I proposed a way to deal with this in an earlier e-mail. Would > that be > satisfactory > to you. To retransmit, we add the following > > "Note: While port 4500 is the reserved port for this protocol, > some existing > implementations > also use port 443. The Stream Prefix provides some mitigation against > cross-protocol > attacks in this case, however, the use of port 443 is NOT > RECOMMENDED" > > We could do something similar for port 80. > > Would that work? > > > This already is good but I think it's not enough. As Tero noted the > working > group thought that they rather specify a generic scheme which I find > problematic. Currently the drafts says: > > "This document leaves the selection of TCP ports up to > implementations. It is suggested to use TCP port 4500, which is > allocated for IPsec NAT Traversal." > > Which sounds to me like an invitation to squat on any open port > regardless > what the port is supposed to be used for (hoping that the magic > number would > avoid any collision). I don't think that a good thing to right in an RFC. > > Now given the text you propose above, I actually assume that the text > I just > cited will be removed but the whole document is written with this > assumption > and therefore there are a couple more places where wording probably > needs to > change. > > I do understand well the problem and that 443 is used in practice. > However, > to match reality I would rather like to see a document that specifies the > approach of encapsulating in TLS/TCP on port 443 that is used today > and pure > TCP encapsulation for use with port 4500 only. Again i think that's where > your proposed text is heading to but I think it needs more changes; > in this > case it would also make sense to add the TLS part back in the main > document > for 443 only. > > Further, I have one more question: The document is written in a way that > allows the implementation of multiple services on the used port. Is that > actually done in reality? If we could restrict the use of this > encapsulation > with servers that only are IKE servers (at least for the used port), you > would actually not need the magic number anymore. I guess you can > still have > the magic number if you really want it because that makes it easier to > distinguish valid IKE/IPSec traffic from other random traffic that > might be > send to this port but the other service running on this port (on other > servers) does not need to know about the magic number because it is > supposed > to never see any IKe/IPSec TCP-encapsulated traffic. > > Does that make sense? > > Mirja > > > > > -Ekr > > > > > Mirja > > > > We can soften the references in the appendix to the fact > that other > ports may, in fact, be used. As for the configuration, it > should > state 4500 as the default, but allow peers to configure > something > else out-of-band if they want to modify behavior (which > is standard > even in UDP implementations of IKE). > > > Further, as also mentioned in the tsv-art review > (Thanks Wes!), this > draft does not sufficiently handle the case of TCP in TCP > encapsulation. > Here a copy of the tsv-art review: > > Reviewer: Wesley Eddy > Review result: On the Right Track > > This document is clear and well-written. It can > easily be > implemented > based on the description. > > There are a few additional issues that should be > considered with > advice to implementers in Section 12 on performance > considerations: > 1) Invisibility of packet loss - Inner protocols that > require packet > losses as a signal of congestion (e.g. TCP) will have > a challenge due > to not being able to see any packet losses since the > outer TCP will > repair them (unless sending into a full outer TCP > socket buffer shows > up back to the inner TCP as a packet loss?). > > > Yes, this is definitely true. We try to capture that with > the line: > "This will make loss- > recovery of the inner TCP traffic less reactive and > more prone to > spurious retransmission timeouts." > > However, this can certainly be expanded upon. > > 2) Nesting of ECN - Inner TCP connections will not > be able to use > effectively ECN on the portion of the path covered by > the outer TCP > connection. > > > Generally, IPsec tunnels will apply RFC 6040 for > translating ECN > markings between inner/outer packets. Since TCP > encapsulation places > the inner IP packets in a stream, there isn't a direct > mapping. > > An implementation could try to roughly map, but it may be > best to > suggest that the ECN markings for inner and outer packets > be left > separate. What is your opinion? > > 3) Impact of congestion response on aggregate - The > general "TCP in > TCP" problem is mentioned, and is mostly appropriate > for a single > flow. If an aggregate of flows is sharing the same > outer TCP > connection, there may be additional concerns about > how the congestion > response behavior impacts an aggregate of flows, > since it may cause a > shared delay spike even to low-rate flows rather than > distributing > losses proportional to per-flow throughput. > > > Indeed. We can add further comments to that effect. > > 4) Additional potential for bufferbloat - Since TCP > does not bound > latency, some applications in the IPsec-protected > aggregate could > drive latency of the shared connection up and impact > the aggregate of > flows that may include real-time applications. The > socket buffer for > the outer TCP connection might need to be limited in > size to ensure > some bounds? > > > We can add a comment to suggest that the buffering should > be limited > on the outer connection if possible. > > > Not addressing these could lead to poor experiences > in deployment, if > implementations make wrong assumptions or fail to > consider them. > > > I do think all of these concerns go back to the overall > recommendation of "use direct ESP or UDP Encapsulation > whenever > possible". Anything to help back up that point is great! > > Thanks, > Tommy > > > In the security considerations section, there are > several RFCs on > mechanisms to increase robustness to RST attacks and > SYN floods that > could be mentioned if it's worthwhile. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > From nobody Thu Apr 27 07:10:52 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39524129535 for ; Thu, 27 Apr 2017 07:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evhyrK4kBfel for ; Thu, 27 Apr 2017 07:10:46 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 406331279EB for ; Thu, 27 Apr 2017 07:10:46 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id u70so16134975ywe.2 for ; Thu, 27 Apr 2017 07:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/JKAAaw8NrqD3B295jfj1YJHGvW2hVxIKR4qZac10yc=; b=piay+1HO+Aak31Bf1LEG7E+zUwFzqpx/o1gfWoNCramoDIoEM4rSAcuOWWLl/wmt6b 7M4X8jcC6jYxan70JFx0PzY3NB80LT7BB35lnR6bdhZ/s8fUVN549Y9okzJmTsHIgi67 v+bKUT3kFirzByq3DX5FA1kmCTp3BxNr4Wky5Dc9X7RnrubmvePhSJ7OfFfeam9HJ17Y iHjVLaSPIuLtcTSTPV0HekzrnCvGea5ZHdeiem9KWI7WsCatAzrmS8cnWJEg7DRPYl9o Ushep165KPgl74XLPoEueqWccvkhUXIKYYTnqnj3s+4XGU8mn/5d1GfJJzsykzAnzUwl HSGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/JKAAaw8NrqD3B295jfj1YJHGvW2hVxIKR4qZac10yc=; b=uRNGuorsffRspFX+W7wXmWvSZqli9Tsfl+iGAMJ5LElZe0ejn3jHIdOmwkuds0DwUL f+xQc3Fm6CQsYscHoas8nkgvZuJNpfchxFz4aysRRkhjBnXqQjsY5TcawmnOby/18Xvi BlaI2WAh4n/1cfWfbw90jzzrNelA7m81cPTTWCSZcYvvN0I6B2q1EKKRl8a36pz3NCP7 7HnNaUhF+CViDGKfcKFgOneJDixsZi6Qv+Emlh8i6nlft0HE2Lzf+LAxZx9/0vSUPh3m 2Vss0LQ5E+RVRF/jgcR5TpwTEI8pMLEODDtTLXQblqd98Fv71bapxArkRH74BxLX1Ibj A2+Q== X-Gm-Message-State: AN3rC/5wmxw7dhy/gFYg37NaStYn0oxY9E/YGLb9zzyINQ+35TXNTKLF HfOau/9IrtDPLwuisrNg/WE4rkt0iA== X-Received: by 10.129.93.137 with SMTP id r131mr4390787ywb.312.1493302245374; Thu, 27 Apr 2017 07:10:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 07:10:04 -0700 (PDT) In-Reply-To: <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> From: Eric Rescorla Date: Thu, 27 Apr 2017 07:10:04 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly Content-Type: multipart/alternative; boundary=001a114d71bae0c74a054e268547 Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:10:50 -0000 --001a114d71bae0c74a054e268547 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2017 at 6:42 AM, Mirja K=C3=BChlewind wrote: > Hi Ekr, hi all, > > (not sure anymore which email best to reply to but I'm using this one now > to partly also reply to others). > > See below. > > On 27.04.2017 14:51, Eric Rescorla wrote: > >> >> >> On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BChlewind > > wrote: >> >> I do see the problem you have and I understand why you selected the >> solution you have but that does contradict quite a bit the idea of t= he >> port registry and I don't think it's a safe and future prove solutio= n. >> Even if people use this approach, I'm concern to publish it in an >> Standards Track RFC, but I guess that's a discussion the IESG would >> need >> to have. >> >> >> Mirja, >> >> I agree that this kind of port squatting is regrettable, but I also don'= t >> think it really >> helps to not publish RFCs that document widely used protocols because we >> are sad they port-squatted. >> >> I proposed a way to deal with this in an earlier e-mail. Would that be >> satisfactory >> to you. To retransmit, we add the following >> >> "Note: While port 4500 is the reserved port for this protocol, some >> existing >> implementations >> also use port 443. The Stream Prefix provides some mitigation against >> cross-protocol >> attacks in this case, however, the use of port 443 is NOT RECOMMENDED" >> >> We could do something similar for port 80. >> >> Would that work? >> > > This already is good but I think it's not enough. As Tero noted the > working group thought that they rather specify a generic scheme which I > find problematic. Currently the drafts says: > > "This document leaves the selection of TCP ports up to > implementations. It is suggested to use TCP port 4500, which is > allocated for IPsec NAT Traversal." > > Which sounds to me like an invitation to squat on any open port regardles= s > what the port is supposed to be used for (hoping that the magic number > would avoid any collision). I don't think that a good thing to right in a= n > RFC. > Hmm... Maybe I don't understand your overall theory here. It seems like having reserved ports for protocols but letting people run them on any port they want to is kind of common practice. See, for instance: https://tools.ietf.org/html/rfc7230#section-2.7.1 " If the host identifier is provided as an IP address, the origin server is the listener (if any) on the indicated TCP port at that IP address. If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for that origin server. If the port subcomponent is empty or not given, TCP port 80 (the reserved port for WWW services) is the default." -Ekr > Now given the text you propose above, I actually assume that the text I > just cited will be removed but the whole document is written with this > assumption and therefore there are a couple more places where wording > probably needs to change. > > I do understand well the problem and that 443 is used in practice. > However, to match reality I would rather like to see a document that > specifies the approach of encapsulating in TLS/TCP on port 443 that is us= ed > today and pure TCP encapsulation for use with port 4500 only. Again i thi= nk > that's where your proposed text is heading to but I think it needs more > changes; in this case it would also make sense to add the TLS part back i= n > the main document for 443 only. > > Further, I have one more question: The document is written in a way that > allows the implementation of multiple services on the used port. Is that > actually done in reality? If we could restrict the use of this > encapsulation with servers that only are IKE servers (at least for the us= ed > port), you would actually not need the magic number anymore. I guess you > can still have the magic number if you really want it because that makes = it > easier to distinguish valid IKE/IPSec traffic from other random traffic > that might be send to this port but the other service running on this por= t > (on other servers) does not need to know about the magic number because i= t > is supposed to never see any IKe/IPSec TCP-encapsulated traffic. > > Does that make sense? > > Mirja > > > > >> -Ekr >> >> >> >> >> Mirja >> >> >> >> We can soften the references in the appendix to the fact that >> other >> ports may, in fact, be used. As for the configuration, it should >> state 4500 as the default, but allow peers to configure somethin= g >> else out-of-band if they want to modify behavior (which is >> standard >> even in UDP implementations of IKE). >> >> >> Further, as also mentioned in the tsv-art review (Thanks >> Wes!), this >> draft does not sufficiently handle the case of TCP in TCP >> encapsulation. >> Here a copy of the tsv-art review: >> >> Reviewer: Wesley Eddy >> Review result: On the Right Track >> >> This document is clear and well-written. It can easily be >> implemented >> based on the description. >> >> There are a few additional issues that should be considered >> with >> advice to implementers in Section 12 on performance >> considerations: >> 1) Invisibility of packet loss - Inner protocols that requir= e >> packet >> losses as a signal of congestion (e.g. TCP) will have a >> challenge due >> to not being able to see any packet losses since the outer >> TCP will >> repair them (unless sending into a full outer TCP socket >> buffer shows >> up back to the inner TCP as a packet loss?). >> >> >> Yes, this is definitely true. We try to capture that with the >> line: >> "This will make loss- >> recovery of the inner TCP traffic less reactive and more pron= e >> to >> spurious retransmission timeouts." >> >> However, this can certainly be expanded upon. >> >> 2) Nesting of ECN - Inner TCP connections will not be able >> to use >> effectively ECN on the portion of the path covered by the >> outer TCP >> connection. >> >> >> Generally, IPsec tunnels will apply RFC 6040 for translating ECN >> markings between inner/outer packets. Since TCP encapsulation >> places >> the inner IP packets in a stream, there isn't a direct mapping. >> >> An implementation could try to roughly map, but it may be best t= o >> suggest that the ECN markings for inner and outer packets be lef= t >> separate. What is your opinion? >> >> 3) Impact of congestion response on aggregate - The general >> "TCP in >> TCP" problem is mentioned, and is mostly appropriate for a >> single >> flow. If an aggregate of flows is sharing the same outer TC= P >> connection, there may be additional concerns about how the >> congestion >> response behavior impacts an aggregate of flows, since it ma= y >> cause a >> shared delay spike even to low-rate flows rather than >> distributing >> losses proportional to per-flow throughput. >> >> >> Indeed. We can add further comments to that effect. >> >> 4) Additional potential for bufferbloat - Since TCP does not >> bound >> latency, some applications in the IPsec-protected aggregate >> could >> drive latency of the shared connection up and impact the >> aggregate of >> flows that may include real-time applications. The socket >> buffer for >> the outer TCP connection might need to be limited in size to >> ensure >> some bounds? >> >> >> We can add a comment to suggest that the buffering should be >> limited >> on the outer connection if possible. >> >> >> Not addressing these could lead to poor experiences in >> deployment, if >> implementations make wrong assumptions or fail to consider >> them. >> >> >> I do think all of these concerns go back to the overall >> recommendation of "use direct ESP or UDP Encapsulation whenever >> possible". Anything to help back up that point is great! >> >> Thanks, >> Tommy >> >> >> In the security considerations section, there are several >> RFCs on >> mechanisms to increase robustness to RST attacks and SYN >> floods that >> could be mentioned if it's worthwhile. >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> --001a114d71bae0c74a054e268547 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 6:42 AM, Mirja K=C3=BChlewind <ietf@kuehlewi= nd.net> wrote:
Hi Ekr, hi all,

(not sure anymore which email best to reply to but I'm using this one n= ow to partly also reply to others).

See below.

On 27.04.2017 14:51, Eric Rescorla wrote:


On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net
<= span class=3D"gmail-"> <mailto:ietf@ku= ehlewind.net>> wrote:

=C2=A0 =C2=A0 I do see the problem you have and I understand why you select= ed the
=C2=A0 =C2=A0 solution you have but that does contradict quite a bit the id= ea of the
=C2=A0 =C2=A0 port registry and I don't think it's a safe and futur= e prove solution.
=C2=A0 =C2=A0 Even if people use this approach, I'm concern to publish = it in an
=C2=A0 =C2=A0 Standards Track RFC, but I guess that's a discussion the = IESG would need
=C2=A0 =C2=A0 to have.


Mirja,

I agree that this kind of port squatting is regrettable, but I also don'= ;t
think it really
helps to not publish RFCs that document widely used protocols because we are sad they port-squatted.

I proposed a way to deal with this in an earlier e-mail. Would that be
satisfactory
to you. To retransmit, we add the following

"Note: While port 4500 is the reserved port for this protocol, some ex= isting
implementations
also use port 443. The Stream Prefix provides some mitigation against
cross-protocol
attacks in this case, however, the use of port 443 is NOT RECOMMENDED"=

We could do something similar for port 80.

Would that work?

This already is good but I think it's not enough. As Tero noted the wor= king group thought that they rather specify a generic scheme which I find p= roblematic. Currently the drafts says:

"This document leaves the selection of TCP ports up to
=C2=A0 =C2=A0implementations.=C2=A0 It is suggested to use TCP port 4500, w= hich is
=C2=A0 =C2=A0allocated for IPsec NAT Traversal."

Which sounds to me like an invitation to squat on any open port regardless = what the port is supposed to be used for (hoping that the magic number woul= d avoid any collision). I don't think that a good thing to right in an = RFC.

Hmm... Maybe I don't understan= d your overall theory here. It seems like having
reserved ports f= or protocols but letting people run them on any port they want
to= is kind of common practice. See, for instance:

" =C2=A0If the host identifier is provided as an= IP address, the origin
=C2=A0 =C2=A0server is the listener (if any) on the in= dicated TCP port at that IP
=C2=A0 =C2=A0address. If host is a registered nam= e, the registered name is an
=C2=A0 =C2=A0indirect identifier for use with a n= ame resolution service, such as
=C2=A0 =C2=A0DNS, to find an address for that = origin server. If the port
=C2=A0 =C2=A0subcomponent is empty or not given, T= CP port 80 (the reserved port
=C2=A0 =C2=A0for WWW services) is the default.&q= uot;

-Ekr



Now given the text you propose above, I actually assume that the text I jus= t cited will be removed but the whole document is written with this assumpt= ion and therefore there are a couple more places where wording probably nee= ds to change.

I do understand well the problem and that 443 is used in practice. However,= to match reality I would rather like to see a document that specifies the = approach of encapsulating in TLS/TCP on port 443 that is used today and pur= e TCP encapsulation for use with port 4500 only. Again i think that's w= here your proposed text is heading to but I think it needs more changes; in= this case it would also make sense to add the TLS part back in the main do= cument for 443 only.

Further, I have one more question: The document is written in a way that al= lows the implementation of multiple services on the used port. Is that actu= ally done in reality? If we could restrict the use of this encapsulation wi= th servers that only are IKE servers (at least for the used port), you woul= d actually not need the magic number anymore. I guess you can still have th= e magic number if you really want it because that makes it easier to distin= guish valid IKE/IPSec traffic from other random traffic that might be send = to this port but the other service running on this port (on other servers) = does not need to know about the magic number because it is supposed to neve= r see any IKe/IPSec TCP-encapsulated traffic.

Does that make sense?

Mirja




-Ekr




=C2=A0 =C2=A0 Mirja



=C2=A0 =C2=A0 =C2=A0 =C2=A0 We can soften the references in the appendix to= the fact that other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ports may, in fact, be used. As for the configu= ration, it should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 state 4500 as the default, but allow peers to c= onfigure something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 else out-of-band if they want to modify behavio= r (which is standard
=C2=A0 =C2=A0 =C2=A0 =C2=A0 even in UDP implementations of IKE).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Further, as also mentioned in the= tsv-art review (Thanks Wes!), this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft does not sufficiently handl= e the case of TCP in TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulation.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Here a copy of the tsv-art review= :

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reviewer: Wesley Eddy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Review result: On the Right Track=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This document is clear and well-w= ritten.=C2=A0 It can easily be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implemented
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 based on the description.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 There are a few additional issues= that should be considered with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 advice to implementers in Section= 12 on performance considerations:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1) Invisibility of packet loss - = Inner protocols that require packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 losses as a signal of congestion = (e.g. TCP) will have a challenge due
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to not being able to see any pack= et losses since the outer TCP will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 repair them (unless sending into = a full outer TCP socket buffer shows
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 up back to the inner TCP as a pac= ket loss?).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes, this is definitely true. We try to capture= that with the line:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "This will make loss-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recovery of the inner TCP traffic = less reactive and more prone to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spurious retransmission timeouts.&= quot;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 However, this can certainly be expanded upon.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Nesting of ECN -=C2=A0 Inner T= CP connections will not be able to use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 effectively ECN on the portion of= the path covered by the outer TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connection.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Generally, IPsec tunnels will apply RFC 6040 fo= r translating ECN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 markings between inner/outer packets. Since TCP= encapsulation places
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the inner IP packets in a stream, there isn'= ;t a direct mapping.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 An implementation could try to roughly map, but= it may be best to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 suggest that the ECN markings for inner and out= er packets be left
=C2=A0 =C2=A0 =C2=A0 =C2=A0 separate. What is your opinion?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Impact of congestion response = on aggregate - The general "TCP in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP" problem is mentioned, a= nd is mostly appropriate for a single
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flow.=C2=A0 If an aggregate of fl= ows is sharing the same outer TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connection, there may be addition= al concerns about how the congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 response behavior impacts an aggr= egate of flows, since it may cause a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 shared delay spike even to low-ra= te flows rather than distributing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 losses proportional to per-flow t= hroughput.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Indeed. We can add further comments to that eff= ect.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4) Additional potential for buffe= rbloat - Since TCP does not bound
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 latency, some applications in the= IPsec-protected aggregate could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 drive latency of the shared conne= ction up and impact the aggregate of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flows that may include real-time = applications.=C2=A0 The socket buffer for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the outer TCP connection might ne= ed to be limited in size to ensure
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 some bounds?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 We can add a comment to suggest that the buffer= ing should be limited
=C2=A0 =C2=A0 =C2=A0 =C2=A0 on the outer connection if possible.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Not addressing these could lead t= o poor experiences in deployment, if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementations make wrong assump= tions or fail to consider them.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 I do think all of these concerns go back to the= overall
=C2=A0 =C2=A0 =C2=A0 =C2=A0 recommendation of "use direct ESP or UDP E= ncapsulation whenever
=C2=A0 =C2=A0 =C2=A0 =C2=A0 possible". Anything to help back up that p= oint is great!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Tommy


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In the security considerations se= ction, there are several RFCs on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mechanisms to increase robustness= to RST attacks and SYN floods that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could be mentioned if it's wo= rthwhile.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPsec mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPsec@ietf.org <mailto:IPsec@ietf.org>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.iet= f.org/mailman/listinfo/ipsec
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www= .ietf.org/mailman/listinfo/ipsec>



=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 IPsec mailing list
 =C2=A0 =C2=A0 IPsec@iet= f.org <mailto:IP= sec@ietf.org>
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinf= o/ipsec
=C2=A0 =C2=A0 <https://www.ietf.org/mailman/listi= nfo/ipsec>



--001a114d71bae0c74a054e268547-- From nobody Thu Apr 27 07:12:15 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF851279EB; Thu, 27 Apr 2017 07:12:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsisVJnmqm80; Thu, 27 Apr 2017 07:12:13 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D5F126CC7; Thu, 27 Apr 2017 07:12:12 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v3RECAgu021520 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Apr 2017 17:12:10 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v3RECAYr016572; Thu, 27 Apr 2017 17:12:10 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <22785.64570.259658.376130@fireball.acr.fi> Date: Thu, 27 Apr 2017 17:12:10 +0300 From: Tero Kivinen To: Mirja Kuehlewind Cc: Eric Rescorla , ipsecme-chairs@ietf.org, ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly In-Reply-To: <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 17 min X-Total-Time: 16 min Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:12:14 -0000 Mirja K=FChlewind writes: > > I agree that this kind of port squatting is regrettable, but I also= don't > > think it really > > helps to not publish RFCs that document widely used protocols becau= se we > > are sad they port-squatted. > > > > I proposed a way to deal with this in an earlier e-mail. Would that= be > > satisfactory > > to you. To retransmit, we add the following > > > > "Note: While port 4500 is the reserved port for this protocol, some= existing > > implementations > > also use port 443. The Stream Prefix provides some mitigation again= st > > cross-protocol > > attacks in this case, however, the use of port 443 is NOT RECOMMEND= ED" > > > > We could do something similar for port 80. > > > > Would that work=3F >=20 > This already is good but I think it's not enough. As Tero noted the w= orking=20 > group thought that they rather specify a generic scheme which I find=20= > problematic. Currently the drafts says: >=20 > "This document leaves the selection of TCP ports up to > implementations. It is suggested to use TCP port 4500, which is > allocated for IPsec NAT Traversal." >=20 > Which sounds to me like an invitation to squat on any open port regar= dless=20 > what the port is supposed to be used for (hoping that the magic numbe= r would=20 > avoid any collision). I don't think that a good thing to right in an = RFC. Note, that configurations can only use ports which are defined to be used by the responder. I.e., if the responder is configured to listen port 4500 and port 443 (with TLS wrapping), there is no point of initiator to try port 80, as it will not work. I.e., in practice this will end up the operators picking suitable number of port numbers they will configure their system to respond to, and most likely they will try to use services which are not in use normally by the responder. I.e., if the responder is running web-server, it cannot very easily also use the port 80 (or 443) for the IPsec traffic, thus it might pick ports 4500, 8000, 8080 or some other random ports which might go through the filters which are already blocking all UDP traffic, and at least port 4500 for TCP. So this is same thing we have now in web. I am quite often running web servers on random ports just because some places have had filters blocking some ports. For example one of my friends company network blocked connection to port 8080, but did not block connections to port 2020, so my web server was running (also) on that port... So unless you are saying "TCP/UDP ports on all protocols MUST NOT be configurable, and only port numbers reserved for those services are allowed" there is nothing we can really do. (and even if you say that, nothing is going to change, as people are so used to getting past stupid firewalls).=20 > Now given the text you propose above, I actually assume that the text= I just=20 > cited will be removed but the whole document is written with this ass= umption=20 > and therefore there are a couple more places where wording probably n= eeds to=20 > change. >=20 > I do understand well the problem and that 443 is used in practice. Ho= wever,=20 > to match reality I would rather like to see a document that specifies= the=20 > approach of encapsulating in TLS/TCP on port 443 that is used today a= nd pure=20 > TCP encapsulation for use with port 4500 only. Again i think that's w= here=20 > your proposed text is heading to but I think it needs more changes; i= n this=20 > case it would also make sense to add the TLS part back in the main do= cument=20 > for 443 only. This is what the document tries to say. I.e., for some ports (like 443), there might be some other framings (like TLS) in place, and for other ports there might not be. As IPsec will require pre-configuration this information which ports are used, and what framing protocol is used comes from the configuration.=20 > Further, I have one more question: The document is written in a way t= hat=20 > allows the implementation of multiple services on the used port. Is t= hat=20 > actually done in reality=3F Yes and no. There are some old IKEv1 based proprietary TCP encapsulation methods, and I think some of those might actually use port 500 and perhaps also port 4500. So vendor implementing those, might want to do multiplexing based on whether there is the stream prefix in front or not to see whether the old proprietary method is used, or the one defined in document is used. Another issue might be that the SGW terminating the TCP 443 connection, might also support some proprietary TLS VPN implementation and differntiating from that is also something I can see that vendors might want to do. So I do not know if anybody is really do it now, but I can see reasons why people might want to multiplex the proprietary things they are now running on those ports 500/4500/443 with the standard we are defining here. > If we could restrict the use of this encapsulation=20 > with servers that only are IKE servers (at least for the used port), = you=20 > would actually not need the magic number anymore. I guess you can sti= ll have=20 > the magic number if you really want it because that makes it easier t= o=20 > distinguish valid IKE/IPSec traffic from other random traffic that mi= ght be=20 > send to this port but the other service running on this port (on othe= r=20 > servers) does not need to know about the magic number because it is s= upposed=20 > to never see any IKe/IPSec TCP-encapsulated traffic. If it is operationally possible, and there is no old proprietary protocols to be supported, I would assume most implementations would not want to bother with the multiplexing different protocols on one port. I.e., new implementations and new setups will most likely then move for example the adminstative interface over https to separate IP-address, just to make sure that it is easier to implement and operate. --=20 kivinen@iki.fi From nobody Thu Apr 27 07:28:20 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A4A129687 for ; Thu, 27 Apr 2017 07:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qKvWqiahAQYi for ; Thu, 27 Apr 2017 07:28:11 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8557A1296B0 for ; Thu, 27 Apr 2017 07:27:52 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id u70so16411675ywe.2 for ; Thu, 27 Apr 2017 07:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7RMjzndP9doxVk5Bx2ZyLQKXOfl5CDLzs4Lz8l0Dfxk=; b=IgsAJAlo9IwIOXbwfGa0RfDIEamVoh/HdwHV3xapS87PeJGO3QQeV7BI0pbdkiE8YR 63rSLFAd70Dq/uDYw4sYU5xysHdrlDP9cOayD5B3cZszn6ojBoMBXB5kS6VRNfZPEApH wjne7rf2T7s5n3PY0dl510mZbEMbrzPWabVGB7t0V1VeoRFiT52GLnYPXgou3UbC1MNW BO3yQhsSb52u4ENxNZisQZkH+VU0ZQNZpVFOeXbEbdnrBrjR3aTSoD7vFlDwXQlkGKTl dlyjfHXSltGaAxSazamT0NU2FqbRnO9Ge+naXqM7X/up1oYNQ85JjgimjFKqukFod8/s 8plw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7RMjzndP9doxVk5Bx2ZyLQKXOfl5CDLzs4Lz8l0Dfxk=; b=jzksKLph8FETTA8xuwQUx6OWFDPYLMiIVVQnlibNbS1Gup88BcXbUJPy5AD6S9OQeS 5ku4Vfg4GWAwfqWzUHtdLCDn/9ljBx8kSQIKbrN6SF+cTbRRXNVJrKaoRCZS80uM+vRz yTzVclD79eqHl4K5R3n4qXQKtkOhNPlpDrwkMdpXzVLTAb68Z60V2DHsBZXnnTuHefff gqZEdwPXUflaDXSPpLlJXd+XpwbRdQbI9GIl0DU/xFu/xNbmaCLt0IGTtBYTD3sbh0+P Fd1wbQcXK3arr0Vl6OcEvHdhtt49yMHo1B+YebrbC7gkWYEHZ9GnhXIYZYnJHCFTQR3U 4WTQ== X-Gm-Message-State: AN3rC/7zs1xK6CVwSc6lldjcr7EzhsxDziOIgO0SeAWQbwgzuoaGVtuY Kv2VFFzxFEY1cSI4R+lxBBlhji9t5w== X-Received: by 10.129.95.68 with SMTP id t65mr4703034ywb.74.1493303271638; Thu, 27 Apr 2017 07:27:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.113.7 with HTTP; Thu, 27 Apr 2017 07:27:11 -0700 (PDT) In-Reply-To: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> From: Eric Rescorla Date: Thu, 27 Apr 2017 07:27:11 -0700 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly Content-Type: multipart/alternative; boundary=001a1147e56e0c5380054e26c36d Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:28:15 -0000 --001a1147e56e0c5380054e26c36d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Apr 27, 2017 at 7:21 AM, Mirja K=C3=BChlewind wrote: > See below. > > On 27.04.2017 16:10, Eric Rescorla wrote: > >> >> >> On Thu, Apr 27, 2017 at 6:42 AM, Mirja K=C3=BChlewind > > wrote: >> >> Hi Ekr, hi all, >> >> (not sure anymore which email best to reply to but I'm using this on= e >> now >> to partly also reply to others). >> >> See below. >> >> On 27.04.2017 14 :51, Eric Rescorla wrote: >> >> >> >> On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BChlewind < >> ietf@kuehlewind.net >> >> >> wrote= : >> >> I do see the problem you have and I understand why you >> selected the >> solution you have but that does contradict quite a bit the >> idea >> of the >> port registry and I don't think it's a safe and future prove >> solution. >> Even if people use this approach, I'm concern to publish it >> in an >> Standards Track RFC, but I guess that's a discussion the IES= G >> would need >> to have. >> >> >> Mirja, >> >> I agree that this kind of port squatting is regrettable, but I >> also don't >> think it really >> helps to not publish RFCs that document widely used protocols >> because we >> are sad they port-squatted. >> >> I proposed a way to deal with this in an earlier e-mail. Would >> that be >> satisfactory >> to you. To retransmit, we add the following >> >> "Note: While port 4500 is the reserved port for this protocol, >> some >> existing >> implementations >> also use port 443. The Stream Prefix provides some mitigation >> against >> cross-protocol >> attacks in this case, however, the use of port 443 is NOT >> RECOMMENDED" >> >> We could do something similar for port 80. >> >> Would that work? >> >> >> This already is good but I think it's not enough. As Tero noted the >> working group thought that they rather specify a generic scheme whic= h >> I >> find problematic. Currently the drafts says: >> >> "This document leaves the selection of TCP ports up to >> implementations. It is suggested to use TCP port 4500, which is >> allocated for IPsec NAT Traversal." >> >> Which sounds to me like an invitation to squat on any open port >> regardless what the port is supposed to be used for (hoping that the >> magic number would avoid any collision). I don't think that a good >> thing >> to right in an RFC. >> >> >> Hmm... Maybe I don't understand your overall theory here. It seems like >> having >> reserved ports for protocols but letting people run them on any port the= y >> want >> to is kind of common practice. See, for instance: >> https://tools.ietf.org/html/rfc7230#section-2.7.1 >> >> " If the host identifier is provided as an IP address, the origin >> server is the listener (if any) on the indicated TCP port at that IP >> address. If host is a registered name, the registered name is an >> indirect identifier for use with a name resolution service, such as >> DNS, to find an address for that origin server. If the port >> subcomponent is empty or not given, TCP port 80 (the reserved port >> for WWW services) is the default." >> > > This doesn't say you can/should use any port you want (it says you can us= e > another port than 80) but you should till avoid to use any other port tha= t > runs a different TCP service. > Well, that may be part of your background assumptions, but the document doesn't say that. It just tells you how to use a different port and is silent on what port you should use. -Ekr > Mirja > > > >> -Ekr >> >> >> >> Now given the text you propose above, I actually assume that the tex= t >> I >> just cited will be removed but the whole document is written with th= is >> assumption and therefore there are a couple more places where wordin= g >> probably needs to change. >> >> I do understand well the problem and that 443 is used in practice. >> However, to match reality I would rather like to see a document that >> specifies the approach of encapsulating in TLS/TCP on port 443 that = is >> used today and pure TCP encapsulation for use with port 4500 only. >> Again >> i think that's where your proposed text is heading to but I think it >> needs more changes; in this case it would also make sense to add the >> TLS >> part back in the main document for 443 only. >> >> Further, I have one more question: The document is written in a way >> that >> allows the implementation of multiple services on the used port. Is >> that >> actually done in reality? If we could restrict the use of this >> encapsulation with servers that only are IKE servers (at least for t= he >> used port), you would actually not need the magic number anymore. I >> guess >> you can still have the magic number if you really want it because th= at >> makes it easier to distinguish valid IKE/IPSec traffic from other >> random >> traffic that might be send to this port but the other service runnin= g >> on >> this port (on other servers) does not need to know about the magic >> number >> because it is supposed to never see any IKe/IPSec TCP-encapsulated >> traffic. >> >> Does that make sense? >> >> Mirja >> >> >> >> >> -Ekr >> >> >> >> >> Mirja >> >> >> >> We can soften the references in the appendix to the fact >> that >> other >> ports may, in fact, be used. As for the configuration, i= t >> should >> state 4500 as the default, but allow peers to configure >> something >> else out-of-band if they want to modify behavior (which = is >> standard >> even in UDP implementations of IKE). >> >> >> Further, as also mentioned in the tsv-art review >> (Thanks >> Wes!), this >> draft does not sufficiently handle the case of TCP i= n >> TCP >> encapsulation. >> Here a copy of the tsv-art review: >> >> Reviewer: Wesley Eddy >> Review result: On the Right Track >> >> This document is clear and well-written. It can >> easily be >> implemented >> based on the description. >> >> There are a few additional issues that should be >> considered with >> advice to implementers in Section 12 on performance >> considerations: >> 1) Invisibility of packet loss - Inner protocols tha= t >> require packet >> losses as a signal of congestion (e.g. TCP) will hav= e >> a >> challenge due >> to not being able to see any packet losses since the >> outer TCP will >> repair them (unless sending into a full outer TCP >> socket >> buffer shows >> up back to the inner TCP as a packet loss?). >> >> >> Yes, this is definitely true. We try to capture that wit= h >> the >> line: >> "This will make loss- >> recovery of the inner TCP traffic less reactive and >> more >> prone to >> spurious retransmission timeouts." >> >> However, this can certainly be expanded upon. >> >> 2) Nesting of ECN - Inner TCP connections will not = be >> able to use >> effectively ECN on the portion of the path covered b= y >> the >> outer TCP >> connection. >> >> >> Generally, IPsec tunnels will apply RFC 6040 for >> translating ECN >> markings between inner/outer packets. Since TCP >> encapsulation >> places >> the inner IP packets in a stream, there isn't a direct >> mapping. >> >> An implementation could try to roughly map, but it may b= e >> best to >> suggest that the ECN markings for inner and outer packet= s >> be left >> separate. What is your opinion? >> >> 3) Impact of congestion response on aggregate - The >> general "TCP in >> TCP" problem is mentioned, and is mostly appropriate >> for >> a single >> flow. If an aggregate of flows is sharing the same >> outer TCP >> connection, there may be additional concerns about h= ow >> the congestion >> response behavior impacts an aggregate of flows, >> since it >> may cause a >> shared delay spike even to low-rate flows rather tha= n >> distributing >> losses proportional to per-flow throughput. >> >> >> Indeed. We can add further comments to that effect. >> >> 4) Additional potential for bufferbloat - Since TCP >> does >> not bound >> latency, some applications in the IPsec-protected >> aggregate could >> drive latency of the shared connection up and impact >> the >> aggregate of >> flows that may include real-time applications. The >> socket buffer for >> the outer TCP connection might need to be limited in >> size >> to ensure >> some bounds? >> >> >> We can add a comment to suggest that the buffering shoul= d >> be >> limited >> on the outer connection if possible. >> >> >> Not addressing these could lead to poor experiences = in >> deployment, if >> implementations make wrong assumptions or fail to >> consider them. >> >> >> I do think all of these concerns go back to the overall >> recommendation of "use direct ESP or UDP Encapsulation >> whenever >> possible". Anything to help back up that point is great! >> >> Thanks, >> Tommy >> >> >> In the security considerations section, there are >> several >> RFCs on >> mechanisms to increase robustness to RST attacks and >> SYN >> floods that >> could be mentioned if it's worthwhile. >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> > >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > > >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > > >> >> >> >> --001a1147e56e0c5380054e26c36d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 7:21 AM, Mirja K=C3=BChlewind <ietf@kuehlewi= nd.net> wrote:
See below.

On 27.04.2017 16:10, Eric Rescorla wrote:


On Thu, Apr 27, 2017 at 6:42 AM, Mirja K=C3=BChlewind <ietf@kuehlewind.net
<= span class=3D""> <mailto:ietf@ku= ehlewind.net>> wrote:

=C2=A0 =C2=A0 Hi Ekr, hi all,

=C2=A0 =C2=A0 (not sure anymore which email best to reply to but I'm us= ing this one now
=C2=A0 =C2=A0 to partly also reply to others).

=C2=A0 =C2=A0 See below.

=C2=A0 =C2=A0 On 27.04.2017 14 <tel:27.04.2017%2014>:51, Eric Resco= rla wrote:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BCh= lewind <ietf@ku= ehlewind.net
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ietf@kuehlewind.net>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>>> w= rote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I do see the problem you have and= I understand why you selected the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 solution you have but that does c= ontradict quite a bit the idea
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 port registry and I don't thi= nk it's a safe and future prove
=C2=A0 =C2=A0 =C2=A0 =C2=A0 solution.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Even if people use this approach,= I'm concern to publish it in an
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Standards Track RFC, but I guess = that's a discussion the IESG
=C2=A0 =C2=A0 =C2=A0 =C2=A0 would need
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to have.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Mirja,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I agree that this kind of port squatting is reg= rettable, but I also don't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 think it really
=C2=A0 =C2=A0 =C2=A0 =C2=A0 helps to not publish RFCs that document widely = used protocols because we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 are sad they port-squatted.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 I proposed a way to deal with this in an earlie= r e-mail. Would that be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 satisfactory
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to you. To retransmit, we add the following

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "Note: While port 4500 is the reserved por= t for this protocol, some
=C2=A0 =C2=A0 =C2=A0 =C2=A0 existing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 implementations
=C2=A0 =C2=A0 =C2=A0 =C2=A0 also use port 443. The Stream Prefix provides s= ome mitigation against
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cross-protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attacks in this case, however, the use of port = 443 is NOT RECOMMENDED"

=C2=A0 =C2=A0 =C2=A0 =C2=A0 We could do something similar for port 80.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Would that work?


=C2=A0 =C2=A0 This already is good but I think it's not enough. As Tero= noted the
=C2=A0 =C2=A0 working group thought that they rather specify a generic sche= me which I
=C2=A0 =C2=A0 find problematic. Currently the drafts says:

=C2=A0 =C2=A0 "This document leaves the selection of TCP ports up to =C2=A0 =C2=A0 =C2=A0 =C2=A0implementations.=C2=A0 It is suggested to use TC= P port 4500, which is
=C2=A0 =C2=A0 =C2=A0 =C2=A0allocated for IPsec NAT Traversal."

=C2=A0 =C2=A0 Which sounds to me like an invitation to squat on any open po= rt
=C2=A0 =C2=A0 regardless what the port is supposed to be used for (hoping t= hat the
=C2=A0 =C2=A0 magic number would avoid any collision). I don't think th= at a good thing
=C2=A0 =C2=A0 to right in an RFC.


Hmm... Maybe I don't understand your overall theory here. It seems like= having
reserved ports for protocols but letting people run them on any port they w= ant
to is kind of common practice. See, for instance:
https://tools.ietf.org/html/rfc7230#section-2.= 7.1

"=C2=A0 If the host identifier is provided as an IP address, the origi= n
=C2=A0 =C2=A0server is the listener (if any) on the indicated TCP port at t= hat IP
=C2=A0 =C2=A0address. If host is a registered name, the registered name is = an
=C2=A0 =C2=A0indirect identifier for use with a name resolution service, su= ch as
=C2=A0 =C2=A0DNS, to find an address for that origin server. If the port =C2=A0 =C2=A0subcomponent is empty or not given, TCP port 80 (the reserved = port
=C2=A0 =C2=A0for WWW services) is the default."

This doesn't say you can/should use any port you want (it says you can = use another port than 80) but you should till avoid to use any other port t= hat runs a different TCP service.

Well,= that may be part of your background assumptions, but the document
doesn't say that. It just tells you how to use a different port and i= s silent on
what port you should use.

-E= kr


Mirja



-Ekr



=C2=A0 =C2=A0 Now given the text you propose above, I actually assume that = the text I
=C2=A0 =C2=A0 just cited will be removed but the whole document is written = with this
=C2=A0 =C2=A0 assumption and therefore there are a couple more places where= wording
=C2=A0 =C2=A0 probably needs to change.

=C2=A0 =C2=A0 I do understand well the problem and that 443 is used in prac= tice.
=C2=A0 =C2=A0 However, to match reality I would rather like to see a docume= nt that
=C2=A0 =C2=A0 specifies the approach of encapsulating in TLS/TCP on port 44= 3 that is
=C2=A0 =C2=A0 used today and pure TCP encapsulation for use with port 4500 = only. Again
=C2=A0 =C2=A0 i think that's where your proposed text is heading to but= I think it
=C2=A0 =C2=A0 needs more changes; in this case it would also make sense to = add the TLS
=C2=A0 =C2=A0 part back in the main document for 443 only.

=C2=A0 =C2=A0 Further, I have one more question: The document is written in= a way that
=C2=A0 =C2=A0 allows the implementation of multiple services on the used po= rt. Is that
=C2=A0 =C2=A0 actually done in reality? If we could restrict the use of thi= s
=C2=A0 =C2=A0 encapsulation with servers that only are IKE servers (at leas= t for the
=C2=A0 =C2=A0 used port), you would actually not need the magic number anym= ore. I guess
=C2=A0 =C2=A0 you can still have the magic number if you really want it bec= ause that
=C2=A0 =C2=A0 makes it easier to distinguish valid IKE/IPSec traffic from o= ther random
=C2=A0 =C2=A0 traffic that might be send to this port but the other service= running on
=C2=A0 =C2=A0 this port (on other servers) does not need to know about the = magic number
=C2=A0 =C2=A0 because it is supposed to never see any IKe/IPSec TCP-encapsu= lated traffic.

=C2=A0 =C2=A0 Does that make sense?

=C2=A0 =C2=A0 Mirja




=C2=A0 =C2=A0 =C2=A0 =C2=A0 -Ekr




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Mirja



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We can soften the r= eferences in the appendix to the fact that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ports may, in fact,= be used. As for the configuration, it should
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 state 4500 as the d= efault, but allow peers to configure something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 else out-of-band if= they want to modify behavior (which is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 standard
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 even in UDP impleme= ntations of IKE).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Furth= er, as also mentioned in the tsv-art review (Thanks
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Wes!), this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft= does not sufficiently handle the case of TCP in TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 encap= sulation.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Here = a copy of the tsv-art review:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Revie= wer: Wesley Eddy
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Revie= w result: On the Right Track

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This = document is clear and well-written.=C2=A0 It can easily be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 imple= mented
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 based= on the description.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 There= are a few additional issues that should be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 considered with
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 advic= e to implementers in Section 12 on performance
=C2=A0 =C2=A0 =C2=A0 =C2=A0 considerations:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1) In= visibility of packet loss - Inner protocols that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 require packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 losse= s as a signal of congestion (e.g. TCP) will have a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 challenge due
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to no= t being able to see any packet losses since the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 outer TCP will
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 repai= r them (unless sending into a full outer TCP socket
=C2=A0 =C2=A0 =C2=A0 =C2=A0 buffer shows
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 up ba= ck to the inner TCP as a packet loss?).


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Yes, this is defini= tely true. We try to capture that with the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 line:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "This will mak= e loss-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0recove= ry of the inner TCP traffic less reactive and more
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prone to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0spurio= us retransmission timeouts."

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 However, this can c= ertainly be expanded upon.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Ne= sting of ECN -=C2=A0 Inner TCP connections will not be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 able to use
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 effec= tively ECN on the portion of the path covered by the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 outer TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conne= ction.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Generally, IPsec tu= nnels will apply RFC 6040 for translating ECN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 markings between in= ner/outer packets. Since TCP encapsulation
=C2=A0 =C2=A0 =C2=A0 =C2=A0 places
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the inner IP packet= s in a stream, there isn't a direct mapping.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 An implementation c= ould try to roughly map, but it may be best to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 suggest that the EC= N markings for inner and outer packets be left
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 separate. What is y= our opinion?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Im= pact of congestion response on aggregate - The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 general "TCP in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 TCP&q= uot; problem is mentioned, and is mostly appropriate for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 a single
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flow.= =C2=A0 If an aggregate of flows is sharing the same outer TCP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 conne= ction, there may be additional concerns about how
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the congestion
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 respo= nse behavior impacts an aggregate of flows, since it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 may cause a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 share= d delay spike even to low-rate flows rather than
=C2=A0 =C2=A0 =C2=A0 =C2=A0 distributing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 losse= s proportional to per-flow throughput.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indeed. We can add = further comments to that effect.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4) Ad= ditional potential for bufferbloat - Since TCP does
=C2=A0 =C2=A0 =C2=A0 =C2=A0 not bound
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 laten= cy, some applications in the IPsec-protected
=C2=A0 =C2=A0 =C2=A0 =C2=A0 aggregate could
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 drive= latency of the shared connection up and impact the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 aggregate of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 flows= that may include real-time applications.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 socket buffer for
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the o= uter TCP connection might need to be limited in size
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to ensure
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 some = bounds?


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 We can add a commen= t to suggest that the buffering should be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 limited
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 on the outer connec= tion if possible.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Not a= ddressing these could lead to poor experiences in
=C2=A0 =C2=A0 =C2=A0 =C2=A0 deployment, if
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 imple= mentations make wrong assumptions or fail to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 consider them.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I do think all of t= hese concerns go back to the overall
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 recommendation of &= quot;use direct ESP or UDP Encapsulation whenever
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 possible". Any= thing to help back up that point is great!

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tommy


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In th= e security considerations section, there are several
=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFCs on
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 mecha= nisms to increase robustness to RST attacks and SYN
=C2=A0 =C2=A0 =C2=A0 =C2=A0 floods that
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 could= be mentioned if it's worthwhile.




=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _____= __________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPsec= mailing list
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPsec@ietf.org <mailt= o:IPsec@ietf.org>= ;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:IPsec@ietf.org <mailto:IPsec@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/ipsec
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mail= man/listinfo/ipsec>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<= a href=3D"https://www.ietf.org/mailman/listinfo/ipsec" rel=3D"noreferrer" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/ipsec
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mail= man/listinfo/ipsec>>



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPsec mailing list
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPsec@ietf.org <mailto:IPsec@ietf.org> <mailto:IPsec@ietf.org =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:IPsec@ietf.org>>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.iet= f.org/mailman/listinfo/ipsec
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mail= man/listinfo/ipsec>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www= .ietf.org/mailman/listinfo/ipsec
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <https://www.ietf.org/mail= man/listinfo/ipsec>>




--001a1147e56e0c5380054e26c36d-- From nobody Thu Apr 27 07:28:59 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0927129AAF for ; Thu, 27 Apr 2017 07:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4rma-6KIOR7 for ; Thu, 27 Apr 2017 07:28:55 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57CAE129A8F for ; Thu, 27 Apr 2017 07:28:13 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=TC2DANl6imeuUgszEMqHYrNIu7JSEs5rj9GQxLm/p5aq/z36DTb4HwpzAoRzdY8Yb+sz8cxXU5Qz1MsZENk1yKDmg9uN/qLc8R5kkFpiwbqN+OlImabJr1rvVO5mm28RRWMU5m83f2bcu6bQmDcfToVo/7186SnmFHoL0tFKoZY=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 29944 invoked from network); 27 Apr 2017 16:21:30 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 16:21:30 +0200 To: Eric Rescorla References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> Cc: ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Thu, 27 Apr 2017 16:21:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170427142130.29934.93297@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:28:57 -0000 See below. On 27.04.2017 16:10, Eric Rescorla wrote: > > > On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind > wrote: > > Hi Ekr, hi all, > > (not sure anymore which email best to reply to but I'm using this one now > to partly also reply to others). > > See below. > > On 27.04.2017 14 :51, Eric Rescorla wrote: > > > > On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind > >> wrote: > > I do see the problem you have and I understand why you selected the > solution you have but that does contradict quite a bit the idea > of the > port registry and I don't think it's a safe and future prove > solution. > Even if people use this approach, I'm concern to publish it in an > Standards Track RFC, but I guess that's a discussion the IESG > would need > to have. > > > Mirja, > > I agree that this kind of port squatting is regrettable, but I also don't > think it really > helps to not publish RFCs that document widely used protocols because we > are sad they port-squatted. > > I proposed a way to deal with this in an earlier e-mail. Would that be > satisfactory > to you. To retransmit, we add the following > > "Note: While port 4500 is the reserved port for this protocol, some > existing > implementations > also use port 443. The Stream Prefix provides some mitigation against > cross-protocol > attacks in this case, however, the use of port 443 is NOT RECOMMENDED" > > We could do something similar for port 80. > > Would that work? > > > This already is good but I think it's not enough. As Tero noted the > working group thought that they rather specify a generic scheme which I > find problematic. Currently the drafts says: > > "This document leaves the selection of TCP ports up to > implementations. It is suggested to use TCP port 4500, which is > allocated for IPsec NAT Traversal." > > Which sounds to me like an invitation to squat on any open port > regardless what the port is supposed to be used for (hoping that the > magic number would avoid any collision). I don't think that a good thing > to right in an RFC. > > > Hmm... Maybe I don't understand your overall theory here. It seems like having > reserved ports for protocols but letting people run them on any port they want > to is kind of common practice. See, for instance: > https://tools.ietf.org/html/rfc7230#section-2.7.1 > > " If the host identifier is provided as an IP address, the origin > server is the listener (if any) on the indicated TCP port at that IP > address. If host is a registered name, the registered name is an > indirect identifier for use with a name resolution service, such as > DNS, to find an address for that origin server. If the port > subcomponent is empty or not given, TCP port 80 (the reserved port > for WWW services) is the default." This doesn't say you can/should use any port you want (it says you can use another port than 80) but you should till avoid to use any other port that runs a different TCP service. Mirja > > -Ekr > > > > Now given the text you propose above, I actually assume that the text I > just cited will be removed but the whole document is written with this > assumption and therefore there are a couple more places where wording > probably needs to change. > > I do understand well the problem and that 443 is used in practice. > However, to match reality I would rather like to see a document that > specifies the approach of encapsulating in TLS/TCP on port 443 that is > used today and pure TCP encapsulation for use with port 4500 only. Again > i think that's where your proposed text is heading to but I think it > needs more changes; in this case it would also make sense to add the TLS > part back in the main document for 443 only. > > Further, I have one more question: The document is written in a way that > allows the implementation of multiple services on the used port. Is that > actually done in reality? If we could restrict the use of this > encapsulation with servers that only are IKE servers (at least for the > used port), you would actually not need the magic number anymore. I guess > you can still have the magic number if you really want it because that > makes it easier to distinguish valid IKE/IPSec traffic from other random > traffic that might be send to this port but the other service running on > this port (on other servers) does not need to know about the magic number > because it is supposed to never see any IKe/IPSec TCP-encapsulated traffic. > > Does that make sense? > > Mirja > > > > > -Ekr > > > > > Mirja > > > > We can soften the references in the appendix to the fact that > other > ports may, in fact, be used. As for the configuration, it should > state 4500 as the default, but allow peers to configure something > else out-of-band if they want to modify behavior (which is > standard > even in UDP implementations of IKE). > > > Further, as also mentioned in the tsv-art review (Thanks > Wes!), this > draft does not sufficiently handle the case of TCP in TCP > encapsulation. > Here a copy of the tsv-art review: > > Reviewer: Wesley Eddy > Review result: On the Right Track > > This document is clear and well-written. It can easily be > implemented > based on the description. > > There are a few additional issues that should be > considered with > advice to implementers in Section 12 on performance > considerations: > 1) Invisibility of packet loss - Inner protocols that > require packet > losses as a signal of congestion (e.g. TCP) will have a > challenge due > to not being able to see any packet losses since the > outer TCP will > repair them (unless sending into a full outer TCP socket > buffer shows > up back to the inner TCP as a packet loss?). > > > Yes, this is definitely true. We try to capture that with the > line: > "This will make loss- > recovery of the inner TCP traffic less reactive and more > prone to > spurious retransmission timeouts." > > However, this can certainly be expanded upon. > > 2) Nesting of ECN - Inner TCP connections will not be > able to use > effectively ECN on the portion of the path covered by the > outer TCP > connection. > > > Generally, IPsec tunnels will apply RFC 6040 for translating ECN > markings between inner/outer packets. Since TCP encapsulation > places > the inner IP packets in a stream, there isn't a direct mapping. > > An implementation could try to roughly map, but it may be best to > suggest that the ECN markings for inner and outer packets be left > separate. What is your opinion? > > 3) Impact of congestion response on aggregate - The > general "TCP in > TCP" problem is mentioned, and is mostly appropriate for > a single > flow. If an aggregate of flows is sharing the same outer TCP > connection, there may be additional concerns about how > the congestion > response behavior impacts an aggregate of flows, since it > may cause a > shared delay spike even to low-rate flows rather than > distributing > losses proportional to per-flow throughput. > > > Indeed. We can add further comments to that effect. > > 4) Additional potential for bufferbloat - Since TCP does > not bound > latency, some applications in the IPsec-protected > aggregate could > drive latency of the shared connection up and impact the > aggregate of > flows that may include real-time applications. The > socket buffer for > the outer TCP connection might need to be limited in size > to ensure > some bounds? > > > We can add a comment to suggest that the buffering should be > limited > on the outer connection if possible. > > > Not addressing these could lead to poor experiences in > deployment, if > implementations make wrong assumptions or fail to > consider them. > > > I do think all of these concerns go back to the overall > recommendation of "use direct ESP or UDP Encapsulation whenever > possible". Anything to help back up that point is great! > > Thanks, > Tommy > > > In the security considerations section, there are several > RFCs on > mechanisms to increase robustness to RST attacks and SYN > floods that > could be mentioned if it's worthwhile. > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > > > > > From nobody Thu Apr 27 07:39:29 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBAC129534 for ; Thu, 27 Apr 2017 07:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7KFPfxBsFhI for ; Thu, 27 Apr 2017 07:39:22 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35E65126CC7 for ; Thu, 27 Apr 2017 07:39:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=c3gJZDMJId/oNJhLXewmeTs0kjaYEmU8kuL5H8pYBqT2ewIhgdjpcVDO8owMEE7ir1//ILLTemM0INGeVKdO9P3VSz+qDBuNePr3IxEIzQpwyNs9nj1V68ukkTrIlVQ9Kihn84dzIId/bhLBo/SKFLd+oZ8n3GMB4l6ruj07dY4=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 30332 invoked from network); 27 Apr 2017 16:32:39 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 16:32:39 +0200 To: Eric Rescorla References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> Cc: ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Thu, 27 Apr 2017 16:32:39 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20170427143239.30322.69521@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 14:39:28 -0000 See below On 27.04.2017 16:27, Eric Rescorla wrote: > > "This document leaves the selection of TCP ports up to > implementations. It is suggested to use TCP port 4500, which is > allocated for IPsec NAT Traversal." > > Which sounds to me like an invitation to squat on any open port > regardless what the port is supposed to be used for (hoping that the > magic number would avoid any collision). I don't think that a > good thing > to right in an RFC. > > > Hmm... Maybe I don't understand your overall theory here. It seems > like having > reserved ports for protocols but letting people run them on any port > they want > to is kind of common practice. See, for instance: > https://tools.ietf.org/html/rfc7230#section-2.7.1 > > > " If the host identifier is provided as an IP address, the origin > server is the listener (if any) on the indicated TCP port at that IP > address. If host is a registered name, the registered name is an > indirect identifier for use with a name resolution service, such as > DNS, to find an address for that origin server. If the port > subcomponent is empty or not given, TCP port 80 (the reserved port > for WWW services) is the default." > > > This doesn't say you can/should use any port you want (it says you can > use another port than 80) but you should till avoid to use any other port > that runs a different TCP service. > > > Well, that may be part of your background assumptions, but the document > doesn't say that. It just tells you how to use a different port and is silent on > what port you should use. > That's what we have the registry for. The difference is, it's okay to use a random port (instead of one specific reserved one) but this draft explicitly is intended to use other reserved ports. Mirja From nobody Thu Apr 27 08:00:12 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE585129AD3 for ; Thu, 27 Apr 2017 08:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju44rFYppOYd for ; Thu, 27 Apr 2017 08:00:02 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 248AD129584 for ; Thu, 27 Apr 2017 07:59:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493305148; 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=Bu+V6axMUeJtAWTbjwaic1xmVtH+bNwRRF2ZhSF0tyc=; b=OrIe3oAi7NN44FXJYinN/XAozNwsjRT9jdnWD2EWBiGBUYvkncMmnjbdwrQfm6hj Po/KtzDjqZ1+syusuJRaw4CPLE3qnZu9eDdHrAuG0XR5EKGbWXHkSX+i0gjOn2+e xDeln+78Z0p5fgbfUPAMRQ6wkeBwNii+8x3Kp7YM6cs2yglEpmV4lOOej1LRgEEM lwD+4N5Jak9fxSPDIYMbI8BrwZCdvvdXMd12XMBmxw7uAMvEYO8Pu10jWO8BNknI HbDt8ga1j04znJohq54fH7/DT5ed3nopoddlwod2jHxfMDifAFlz3WuCS10Ytylq /W174iDuo4MymsfzAuzTtQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 17.9D.29279.C3702095; Thu, 27 Apr 2017 07:59:08 -0700 (PDT) X-AuditID: 11973e11-0e8b49a00000725f-d4-5902073c3380 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay5.apple.com (Apple SCV relay) with SMTP id BB.1E.02326.C3702095; Thu, 27 Apr 2017 07:59:08 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.74.134] (unknown [17.153.74.134]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OP200B9IPMKTR40@nwk-mmpp-sz11.apple.com>; Thu, 27 Apr 2017 07:59:08 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: <4f5900d2-a795-8bb4-a89d-dad51e4a6f09@kuehlewind.net> Date: Thu, 27 Apr 2017 07:59:07 -0700 Cc: Eric Rescorla , ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-transfer-encoding: quoted-printable Message-id: <8B5EDA56-CE70-4AD7-AC52-643F288482F0@apple.com> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <4f5900d2-a795-8bb4-a89d-dad51e4a6f09@kuehlewind.net> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3424) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUi2FAYoWvDzhRpcPWoocX7P2cYLVa8Psdu MePPRGaLF9c/Mlvs3/KCzWLmnA8sFkfPP2dzYPdYsuQnk8fhrwtZPFo+LmT1mPy4jTmAJYrL JiU1J7MstUjfLoErY2X/U/aCn/4VT+4sYG5gPG3dxcjJISFgIrGgcRtbFyMXh5DAaiaJl+ue s8AkHrx8zwKROMQosePIQiaQBK+AoMSPyfeAEhwczALqElOm5ELUTGSS+DLlFzNIXFhAQmLz nkSQuLDABEaJ19dmsYP0sgmoSBz/toEZxOYUcJKY9HAB2DIWAVWJYxcmgtnMAusYJT795ISw tSWevLvACjKTV8BGYtavAIhd75kknuw6DXaPiICVRPP2R1BHy0pMWLeZGaRIQuA+m0Tj0w+M ExiFZyG5exbC3bOQrFjAyLyKUSg3MTNHNzPPSC+xoCAnVS85P3cTIyhCptsJ7mA8vsrqEKMA B6MSD2/EJ8ZIIdbEsuLK3EOM0hwsSuK8yjv+RwgJpCeWpGanphakFsUXleakFh9iZOLglGpg FHORmT6nb8qBfxLO/PvTbk4wbQvcmWjd68+423D24zuHdAO1px7dfeJ1nUjU2iy5r26d4fv+ PD11+2GiVExCX1aYzdQu6ypmrr2ZE3tTw98p+5dfmt7aWNN2IOv81tOG2z3Cvvm7F/tHVpau 0VY9nC7tbKKl7MywSa5X7EKMqP7LK/3bpb8qsRRnJBpqMRcVJwIAQTE5vHECAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUi2FA8W9eGnSnS4FyfjsX7P2cYLVa8Psdu MePPRGaLF9c/Mlvs3/KCzWLmnA8sFkfPP2dzYPdYsuQnk8fhrwtZPFo+LmT1mPy4jTmAJYrL JiU1J7MstUjfLoErY2X/U/aCn/4VT+4sYG5gPG3dxcjJISFgIvHg5XuWLkYuDiGBQ4wSO44s ZAJJ8AoISvyYfA8owcHBLKAuMWVKLkTNRCaJL1N+MYPEhQUkJDbvSQSJCwtMYJR4fW0WO0gv m4CKxPFvG5hBbE4BJ4lJDxewgNgsAqoSxy5MBLOZBdYxSnz6yQlha0s8eXeBFWQmr4CNxKxf ARC73jNJPNl1GuweEQEriebtj1ggjpaVmLBuM/MERoFZSE6dhXDqLCRTFzAyr2IUKErNSaw0 1UssKMhJ1UvOz93ECA7owogdjP+XWR1iFOBgVOLhZfjAGCnEmlhWXJkLDAsOZiUR3swrQCHe lMTKqtSi/Pii0pzU4kOMVUC/TGSWEk3OB0ZbXkm8oYmJgYmxsZmxsbmJOVWElcR5V7YBbRZI TyxJzU5NLUgtglnOxMEp1cCYL2pUfLvs/vX3vx9M//Vu3tmbv2Qm/FJw31n1O9yISeXR4o0L Gh67Vn1T107J7WWSEf5wyf3hW7WLT3I27j+95/FHAfs39iedDm79sPHQvPppT5f++rAqTHty /e/+Y7OOKT8UZkpL11G6X8qTOolr2tesBOPcrA26K7YnuRuv3luvpWRkf8wmSYmlOCPRUIu5 qDgRANHWRhnDAgAA Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:00:09 -0000 > On Apr 27, 2017, at 6:46 AM, Mirja K=C3=BChlewind = wrote: >=20 > One more side comment on the magic number: actually the magic number = makes it easy for network operator to identify IKE/IPSec traffic on any = port and block all packets that below to a flow that started with this = pattern in the first payload packet. So if you really think you need a = magic number, you should probably always encrypt it. The working group determined that the point of the protocol is not to = evade any possibility for middleboxes to block the traffic, but instead = to allow connectivity through middle boxes that are essentially = 'accidentally' blocking IKE/ESP. If an operator wants to block this = traffic explicitly, that is fine. However, it is very common that = networks on public access points will block everything by default based = on what they consider to be 'web' traffic; they do not inspect more = deeply. Thanks, Tommy >=20 >=20 >=20 > On 27.04.2017 15:42, Mirja K=C3=BChlewind wrote: >> Hi Ekr, hi all, >>=20 >> (not sure anymore which email best to reply to but I'm using this one = now to >> partly also reply to others). >>=20 >> See below. >>=20 >> On 27.04.2017 14:51, Eric Rescorla wrote: >>>=20 >>>=20 >>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BChlewind = >> > wrote: >>>=20 >>> I do see the problem you have and I understand why you selected = the >>> solution you have but that does contradict quite a bit the idea = of the >>> port registry and I don't think it's a safe and future prove = solution. >>> Even if people use this approach, I'm concern to publish it in an >>> Standards Track RFC, but I guess that's a discussion the IESG = would need >>> to have. >>>=20 >>>=20 >>> Mirja, >>>=20 >>> I agree that this kind of port squatting is regrettable, but I also = don't >>> think it really >>> helps to not publish RFCs that document widely used protocols = because we >>> are sad they port-squatted. >>>=20 >>> I proposed a way to deal with this in an earlier e-mail. Would that = be >>> satisfactory >>> to you. To retransmit, we add the following >>>=20 >>> "Note: While port 4500 is the reserved port for this protocol, some = existing >>> implementations >>> also use port 443. The Stream Prefix provides some mitigation = against >>> cross-protocol >>> attacks in this case, however, the use of port 443 is NOT = RECOMMENDED" >>>=20 >>> We could do something similar for port 80. >>>=20 >>> Would that work? >>=20 >> This already is good but I think it's not enough. As Tero noted the = working >> group thought that they rather specify a generic scheme which I find >> problematic. Currently the drafts says: >>=20 >> "This document leaves the selection of TCP ports up to >> implementations. It is suggested to use TCP port 4500, which is >> allocated for IPsec NAT Traversal." >>=20 >> Which sounds to me like an invitation to squat on any open port = regardless >> what the port is supposed to be used for (hoping that the magic = number would >> avoid any collision). I don't think that a good thing to right in an = RFC. >>=20 >> Now given the text you propose above, I actually assume that the text = I just >> cited will be removed but the whole document is written with this = assumption >> and therefore there are a couple more places where wording probably = needs to >> change. >>=20 >> I do understand well the problem and that 443 is used in practice. = However, >> to match reality I would rather like to see a document that specifies = the >> approach of encapsulating in TLS/TCP on port 443 that is used today = and pure >> TCP encapsulation for use with port 4500 only. Again i think that's = where >> your proposed text is heading to but I think it needs more changes; = in this >> case it would also make sense to add the TLS part back in the main = document >> for 443 only. >>=20 >> Further, I have one more question: The document is written in a way = that >> allows the implementation of multiple services on the used port. Is = that >> actually done in reality? If we could restrict the use of this = encapsulation >> with servers that only are IKE servers (at least for the used port), = you >> would actually not need the magic number anymore. I guess you can = still have >> the magic number if you really want it because that makes it easier = to >> distinguish valid IKE/IPSec traffic from other random traffic that = might be >> send to this port but the other service running on this port (on = other >> servers) does not need to know about the magic number because it is = supposed >> to never see any IKe/IPSec TCP-encapsulated traffic. >>=20 >> Does that make sense? >>=20 >> Mirja >>=20 >>=20 >>=20 >>>=20 >>> -Ekr >>>=20 >>>=20 >>>=20 >>>=20 >>> Mirja >>>=20 >>>=20 >>>=20 >>> We can soften the references in the appendix to the fact that = other >>> ports may, in fact, be used. As for the configuration, it = should >>> state 4500 as the default, but allow peers to configure = something >>> else out-of-band if they want to modify behavior (which is = standard >>> even in UDP implementations of IKE). >>>=20 >>>=20 >>> Further, as also mentioned in the tsv-art review (Thanks = Wes!), this >>> draft does not sufficiently handle the case of TCP in TCP >>> encapsulation. >>> Here a copy of the tsv-art review: >>>=20 >>> Reviewer: Wesley Eddy >>> Review result: On the Right Track >>>=20 >>> This document is clear and well-written. It can easily = be >>> implemented >>> based on the description. >>>=20 >>> There are a few additional issues that should be = considered with >>> advice to implementers in Section 12 on performance = considerations: >>> 1) Invisibility of packet loss - Inner protocols that = require packet >>> losses as a signal of congestion (e.g. TCP) will have a = challenge due >>> to not being able to see any packet losses since the = outer TCP will >>> repair them (unless sending into a full outer TCP socket = buffer shows >>> up back to the inner TCP as a packet loss?). >>>=20 >>>=20 >>> Yes, this is definitely true. We try to capture that with the = line: >>> "This will make loss- >>> recovery of the inner TCP traffic less reactive and more = prone to >>> spurious retransmission timeouts." >>>=20 >>> However, this can certainly be expanded upon. >>>=20 >>> 2) Nesting of ECN - Inner TCP connections will not be = able to use >>> effectively ECN on the portion of the path covered by the = outer TCP >>> connection. >>>=20 >>>=20 >>> Generally, IPsec tunnels will apply RFC 6040 for translating = ECN >>> markings between inner/outer packets. Since TCP encapsulation = places >>> the inner IP packets in a stream, there isn't a direct = mapping. >>>=20 >>> An implementation could try to roughly map, but it may be = best to >>> suggest that the ECN markings for inner and outer packets be = left >>> separate. What is your opinion? >>>=20 >>> 3) Impact of congestion response on aggregate - The = general "TCP in >>> TCP" problem is mentioned, and is mostly appropriate for = a single >>> flow. If an aggregate of flows is sharing the same outer = TCP >>> connection, there may be additional concerns about how = the congestion >>> response behavior impacts an aggregate of flows, since it = may cause a >>> shared delay spike even to low-rate flows rather than = distributing >>> losses proportional to per-flow throughput. >>>=20 >>>=20 >>> Indeed. We can add further comments to that effect. >>>=20 >>> 4) Additional potential for bufferbloat - Since TCP does = not bound >>> latency, some applications in the IPsec-protected = aggregate could >>> drive latency of the shared connection up and impact the = aggregate of >>> flows that may include real-time applications. The = socket buffer for >>> the outer TCP connection might need to be limited in size = to ensure >>> some bounds? >>>=20 >>>=20 >>> We can add a comment to suggest that the buffering should be = limited >>> on the outer connection if possible. >>>=20 >>>=20 >>> Not addressing these could lead to poor experiences in = deployment, if >>> implementations make wrong assumptions or fail to = consider them. >>>=20 >>>=20 >>> I do think all of these concerns go back to the overall >>> recommendation of "use direct ESP or UDP Encapsulation = whenever >>> possible". Anything to help back up that point is great! >>>=20 >>> Thanks, >>> Tommy >>>=20 >>>=20 >>> In the security considerations section, there are several = RFCs on >>> mechanisms to increase robustness to RST attacks and SYN = floods that >>> could be mentioned if it's worthwhile. >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 27 08:08:33 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4EAD12956C for ; Thu, 27 Apr 2017 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziNANvQvUAfw for ; Thu, 27 Apr 2017 08:08:23 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 5644E129AEB for ; Thu, 27 Apr 2017 08:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493305630; 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=DLE7DZRvQQ/C1Erna150W6ZeSJ8hmN6/PEW0PJO8GPc=; b=fIFu4cH6RHWmYiavcmg/zOIwCTfuoWYH6i44toOaV/pPC3PUHerjignGJvb9l6Mc DHmoY6iqUv4QBdAuGF+kDMy4E4orsU8Mikfhu4a6owSpSbT/DxY4f7rNZlkKnNxx sPzAysr0eoh7ECmYb1Wex7wfRPixV9K2IU9uQsdbQoNQkT3/jg5qUt3GvVYECZHI mkcXSXmgAL4wPXi44NOtQl0jx0Pc3EBVOw8jC+XCj1lFzhuTcBjW6kgI4AcKYumP AUx2BWFIS1xR3NOFbd1i98fHMJg2EOk0jjvsSh1Ui/QKzAzH6TfAxJvexdfCdNgp Xy20dyELLCoxDxSQ97IdGw==; Received: from relay7.apple.com (relay7.apple.com [17.128.113.101]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 2F.8E.29279.D1902095; Thu, 27 Apr 2017 08:07:10 -0700 (PDT) X-AuditID: 11973e11-bebfb7000000725f-46-5902091d555f Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay7.apple.com (Apple SCV relay) with SMTP id 6A.FB.18088.C1902095; Thu, 27 Apr 2017 08:07:09 -0700 (PDT) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.153.74.134] (unknown [17.153.74.134]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OP20037VPZWCT00@nwk-mmpp-sz11.apple.com>; Thu, 27 Apr 2017 08:07:08 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly In-reply-to: Date: Thu, 27 Apr 2017 08:07:07 -0700 Cc: Eric Rescorla , ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-transfer-encoding: quoted-printable Message-id: References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> To: =?utf-8?Q?Mirja_K=C3=BChlewind?= X-Mailer: Apple Mail (2.3424) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi2FCYqivHyRRp8HAPp8X7P2cYLVa8Psdu MePPRGaLF9c/Mlvs3/KCzWLmnA8sFkfPP2dzYPdYsuQnk8fhrwtZPFo+LmT1mPy4jTmAJYrL JiU1J7MstUjfLoEr48/vdUwFcyUr3k3dxdbAeF2oi5GTQ0LARGJKwwVWEFtIYA2TxPTJdTDx PVO2sncxcgHFDzFKTH/VwQiS4BUQlPgx+R5LFyMHB7OAusSUKbkQNROZJO6/mcUGEhcWkJDY vCcRJC4sMIFR4vW1WewgvWwCKhLHv21gBrE5BZwkTu87ATaHRUBVYsOPXJAws8A6RolPPzkh bG2JJ+8gbuMVsJF4ev0tE8SurSwStw6fArtHRMBKonn7IxaIo2UlJqzbzAxSJCFwn03i2Ot9 7BMYhWchuXsWwt2zkOxYwMi8ilEoNzEzRzczz0gvsaAgJ1UvOT93EyMoPqbbCe5gPL7K6hCj AAejEg9vxCfGSCHWxLLiytxDjNIcLErivMo7/kcICaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRq YEydnfJ09ZXg87t1t86qbrwe4LLZ8PzGywHXsrZwP87yi7eUyj1f7cdfslBB6IPpd2POucs2 2Uk01DbPiL/K6lj/e2boupgqrs19h+fd+6a11+/+bK+rHxtvTKz9scPmzL65TZMMXbIzCuOT VWxdV6haabyP/7/jX6i8Wrvm9ki9xA8mc5UPKyuxFGckGmoxFxUnAgCxsFe/cAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUi2FA8W1eWkynSYOV/Hov3f84wWqx4fY7d YsaficwWL65/ZLbYv+UFm8XMOR9YLI6ef87mwO6xZMlPJo/DXxeyeLR8XMjqMflxG3MASxSX TUpqTmZZapG+XQJXxp/f65gK5kpWvJu6i62B8bpQFyMnh4SAicSeKVvZuxi5OIQEDjFKTH/V wQiS4BUQlPgx+R5LFyMHB7OAusSUKbkQNROZJO6/mcUGEhcWkJDYvCcRJC4sMIFR4vW1Wewg vWwCKhLHv21gBrE5BZwkTu87ATaHRUBVYsOPXJAws8A6RolPPzkhbG2JJ+8usEKstZF4ev0t E8SurSwStw6fArtHRMBKonn7IxaIo2UlJqzbzDyBUWAWklNnIZw6C8nYBYzMqxgFilJzEivN 9RILCnJS9ZLzczcxggO6MHUHY+Nyq0OMAhyMSjy8EZ8YI4VYE8uKK3OBYcHBrCTCm3kFKMSb klhZlVqUH19UmpNafIixCuiXicxSosn5wGjLK4k3NDExMDE2NjM2Njcxp4qwkjjv8jagzQLp iSWp2ampBalFMMuZODilGhjtbphEn1knM1HQcfvX3YJ3sh3KIuVbQiqfKZVbnz5lnmD05XR1 pdq28A9quVf7phxqtP7czuQ9oyVCN2xpQ9j6H6pbGb0+v17A96fxfkFhdtrPwMXTN8ivm/zx KEfAqzKNI8ddFnF5X25OdLsSXyj23ln20bKcjnCjUFMWh9z7jx6q+FyX3KPEUpyRaKjFXFSc CADHGx96wwIAAA== Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:08:25 -0000 > On Apr 27, 2017, at 7:32 AM, Mirja K=C3=BChlewind = wrote: >=20 > See below >=20 > On 27.04.2017 16:27, Eric Rescorla wrote: >>=20 >> "This document leaves the selection of TCP ports up to >> implementations. It is suggested to use TCP port 4500, = which is >> allocated for IPsec NAT Traversal." >>=20 >> Which sounds to me like an invitation to squat on any open = port >> regardless what the port is supposed to be used for = (hoping that the >> magic number would avoid any collision). I don't think = that a >> good thing >> to right in an RFC. >>=20 >>=20 >> Hmm... Maybe I don't understand your overall theory here. It = seems >> like having >> reserved ports for protocols but letting people run them on = any port >> they want >> to is kind of common practice. See, for instance: >> https://tools.ietf.org/html/rfc7230#section-2.7.1 >> >>=20 >> " If the host identifier is provided as an IP address, the = origin >> server is the listener (if any) on the indicated TCP port = at that IP >> address. If host is a registered name, the registered name = is an >> indirect identifier for use with a name resolution service, = such as >> DNS, to find an address for that origin server. If the port >> subcomponent is empty or not given, TCP port 80 (the = reserved port >> for WWW services) is the default." >>=20 >>=20 >> This doesn't say you can/should use any port you want (it says you = can >> use another port than 80) but you should till avoid to use any = other port >> that runs a different TCP service. >>=20 >>=20 >> Well, that may be part of your background assumptions, but the = document >> doesn't say that. It just tells you how to use a different port and = is silent on >> what port you should use. >>=20 >=20 > That's what we have the registry for. The difference is, it's okay to = use a random port (instead of one specific reserved one) but this draft = explicitly is intended to use other reserved ports. The only recommended port in the draft is 4500, which is what is = reserved in the registry. The use of any other port is by configuration = only. As Tero and others have explained, all IKE connections are made to = pre-known pre-configured hosts. All the IKE implementations I am aware = of allow the useable IKE ports to be customized. I'm fine removing any mention of other specific ports, even in the = appendix. However, the fact that configurations can choose what ports to = use is something that needs to be left open. The point of the port = registry is to allow devices to expect what service will be offered on a = given port when they connect. If two peers mutually decide to share = their own configuration, they can do that. Thanks, Tommy >=20 > Mirja >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Apr 27 08:21:59 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20A0E1296CD; Thu, 27 Apr 2017 08:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtlNnZBMBFc5; Thu, 27 Apr 2017 08:21:56 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (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 578C2129A9B; Thu, 27 Apr 2017 08:21:02 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id v14so29905204pfd.2; Thu, 27 Apr 2017 08:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=9EPCMnPJ3Tt4q6rNW9qRkjdiYevPkM+Z20F48SPZVsU=; b=Wy18qkDeKhHIgAMbfKOf1OwvnemnoF00W7eemSmFvJciKFWmYZ97ilXrNn3o6O24cD fTBireBpCQrV0nDt2YFQx0OgURuSAcsXnaMHcA1uJwMl+NUTN4Dhp+15PAuzxZs6s1k8 o4dHXbN0+Eury/l87L4DVoktzHbDaXfWfEUGfaXqQX7TnK80tdrkoFChT/maC3ZytPGI ExEmZxz9IngH3it6yYnNMlfTzBC9JVSLPQRmrko9ezF1CwxhOERrNteQKYPYn48ASxku xG8BNjOOFp3a1K/l9IPHqAuv7eB1KcPVHjy8mQ/MNqhE+oE4eTJf2nw1Elb42wx0r529 VQyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=9EPCMnPJ3Tt4q6rNW9qRkjdiYevPkM+Z20F48SPZVsU=; b=j3nzikQM0icM72/ZrqOldhEOhAag3hqcbhJ9/JSYOMNYmpGZtNqjEd9QLZMwSNm7Bi d2N8szOtEOLWvyzfVuvAjFNweECijbcML+djLy2mOsKCNEoJAi/K9qd2wkswLbhnxdjg amGT2X2xcbB96gOTRBnt1+12RfPEWV0wWut4Gfw5uhRSNsPtJVuAPUhn6zolFNm0IqeV 0i2VFZJ0sdplb6U11bnF8rmjAd2dWOgjT4NefQptNSzJ0/doShhkjnBpS2yLaOozNjuo LY7cZTuy9jyVYBJXJ1LFAilLQ1XB6HW0P3y1IoAtTiWbOz2tohdBt7NwhReF2lJEAN3A qDlw== X-Gm-Message-State: AN3rC/6RJBVD9juqcvPOt5k4UeYiZzNB84R+2Dd2C+Z5eK8Vyz5CLBRu IfSbcczkeLHHT8ihTkm4lPCuRUZcIA== X-Received: by 10.99.62.68 with SMTP id l65mr6335703pga.172.1493306461742; Thu, 27 Apr 2017 08:21:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.185.143 with HTTP; Thu, 27 Apr 2017 08:20:21 -0700 (PDT) In-Reply-To: <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> From: Kathleen Moriarty Date: Thu, 27 Apr 2017 11:20:21 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Eric Rescorla , ipsecme-chairs@ietf.org, Tero Kivinen , "ipsec@ietf.org" , The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:21:58 -0000 Hi Mirja, I think I can help with one of your questions. inline On Thu, Apr 27, 2017 at 9:42 AM, Mirja K=C3=BChlewind = wrote: > Hi Ekr, hi all, > > (not sure anymore which email best to reply to but I'm using this one now= to > partly also reply to others). > > See below. > > On 27.04.2017 14:51, Eric Rescorla wrote: >> >> >> >> On Thu, Apr 27, 2017 at 1:32 AM, Mirja K=C3=BChlewind > > wrote: >> >> I do see the problem you have and I understand why you selected the >> solution you have but that does contradict quite a bit the idea of t= he >> port registry and I don't think it's a safe and future prove solutio= n. >> Even if people use this approach, I'm concern to publish it in an >> Standards Track RFC, but I guess that's a discussion the IESG would >> need >> to have. >> >> >> Mirja, >> >> I agree that this kind of port squatting is regrettable, but I also don'= t >> think it really >> helps to not publish RFCs that document widely used protocols because we >> are sad they port-squatted. >> >> I proposed a way to deal with this in an earlier e-mail. Would that be >> satisfactory >> to you. To retransmit, we add the following >> >> "Note: While port 4500 is the reserved port for this protocol, some >> existing >> implementations >> also use port 443. The Stream Prefix provides some mitigation against >> cross-protocol >> attacks in this case, however, the use of port 443 is NOT RECOMMENDED" >> >> We could do something similar for port 80. >> >> Would that work? > > > This already is good but I think it's not enough. As Tero noted the worki= ng > group thought that they rather specify a generic scheme which I find > problematic. Currently the drafts says: > > "This document leaves the selection of TCP ports up to > implementations. It is suggested to use TCP port 4500, which is > allocated for IPsec NAT Traversal." > > Which sounds to me like an invitation to squat on any open port regardles= s > what the port is supposed to be used for (hoping that the magic number wo= uld > avoid any collision). I don't think that a good thing to right in an RFC. > > Now given the text you propose above, I actually assume that the text I j= ust > cited will be removed but the whole document is written with this assumpt= ion > and therefore there are a couple more places where wording probably needs= to > change. > > I do understand well the problem and that 443 is used in practice. Howeve= r, > to match reality I would rather like to see a document that specifies the > approach of encapsulating in TLS/TCP on port 443 that is used today and p= ure > TCP encapsulation for use with port 4500 only. Again i think that's where > your proposed text is heading to but I think it needs more changes; in th= is > case it would also make sense to add the TLS part back in the main docume= nt > for 443 only. > > Further, I have one more question: The document is written in a way that > allows the implementation of multiple services on the used port. Is that > actually done in reality? Well, Warren pointed out somewhere in a thread that you might have an admin interface operating through the use of port 443. From my experience, if this happens, there is a different connection method (virtual server - address/port) that allows for this to happen. I hope that is helpful. Kathleen If we could restrict the use of this encapsulation > with servers that only are IKE servers (at least for the used port), you > would actually not need the magic number anymore. I guess you can still h= ave > the magic number if you really want it because that makes it easier to > distinguish valid IKE/IPSec traffic from other random traffic that might = be > send to this port but the other service running on this port (on other > servers) does not need to know about the magic number because it is suppo= sed > to never see any IKe/IPSec TCP-encapsulated traffic. > > Does that make sense? > > Mirja > > > >> >> -Ekr >> >> >> >> >> Mirja >> >> >> >> We can soften the references in the appendix to the fact that >> other >> ports may, in fact, be used. As for the configuration, it should >> state 4500 as the default, but allow peers to configure somethin= g >> else out-of-band if they want to modify behavior (which is >> standard >> even in UDP implementations of IKE). >> >> >> Further, as also mentioned in the tsv-art review (Thanks >> Wes!), this >> draft does not sufficiently handle the case of TCP in TCP >> encapsulation. >> Here a copy of the tsv-art review: >> >> Reviewer: Wesley Eddy >> Review result: On the Right Track >> >> This document is clear and well-written. It can easily be >> implemented >> based on the description. >> >> There are a few additional issues that should be considered >> with >> advice to implementers in Section 12 on performance >> considerations: >> 1) Invisibility of packet loss - Inner protocols that requir= e >> packet >> losses as a signal of congestion (e.g. TCP) will have a >> challenge due >> to not being able to see any packet losses since the outer T= CP >> will >> repair them (unless sending into a full outer TCP socket >> buffer shows >> up back to the inner TCP as a packet loss?). >> >> >> Yes, this is definitely true. We try to capture that with the >> line: >> "This will make loss- >> recovery of the inner TCP traffic less reactive and more pron= e >> to >> spurious retransmission timeouts." >> >> However, this can certainly be expanded upon. >> >> 2) Nesting of ECN - Inner TCP connections will not be able = to >> use >> effectively ECN on the portion of the path covered by the >> outer TCP >> connection. >> >> >> Generally, IPsec tunnels will apply RFC 6040 for translating ECN >> markings between inner/outer packets. Since TCP encapsulation >> places >> the inner IP packets in a stream, there isn't a direct mapping. >> >> An implementation could try to roughly map, but it may be best t= o >> suggest that the ECN markings for inner and outer packets be lef= t >> separate. What is your opinion? >> >> 3) Impact of congestion response on aggregate - The general >> "TCP in >> TCP" problem is mentioned, and is mostly appropriate for a >> single >> flow. If an aggregate of flows is sharing the same outer TC= P >> connection, there may be additional concerns about how the >> congestion >> response behavior impacts an aggregate of flows, since it ma= y >> cause a >> shared delay spike even to low-rate flows rather than >> distributing >> losses proportional to per-flow throughput. >> >> >> Indeed. We can add further comments to that effect. >> >> 4) Additional potential for bufferbloat - Since TCP does not >> bound >> latency, some applications in the IPsec-protected aggregate >> could >> drive latency of the shared connection up and impact the >> aggregate of >> flows that may include real-time applications. The socket >> buffer for >> the outer TCP connection might need to be limited in size to >> ensure >> some bounds? >> >> >> We can add a comment to suggest that the buffering should be >> limited >> on the outer connection if possible. >> >> >> Not addressing these could lead to poor experiences in >> deployment, if >> implementations make wrong assumptions or fail to consider >> them. >> >> >> I do think all of these concerns go back to the overall >> recommendation of "use direct ESP or UDP Encapsulation whenever >> possible". Anything to help back up that point is great! >> >> Thanks, >> Tommy >> >> >> In the security considerations section, there are several RF= Cs >> on >> mechanisms to increase robustness to RST attacks and SYN >> floods that >> could be mentioned if it's worthwhile. >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> >> > --=20 Best regards, Kathleen From nobody Thu Apr 27 08:47:43 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7054129B2A for ; Thu, 27 Apr 2017 08:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKUDxc_sRjMg for ; Thu, 27 Apr 2017 08:47:40 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26169129B42 for ; Thu, 27 Apr 2017 08:46:12 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=XlTYBrJzTmhqHHP9EcFYZbEBZCRXcf9jtxCl9feWQJ8MZBF+N+Y31dmn8meTu1nHXMsxfvtIjUjeiHXwtmlypMKWGF5gI6sWsy5L1j6Y+J8tCtmTvV1tajBJUtrY5gQ4F61M+4jMX++IYzYllgxbbbysNGVIw3cs78dWB06GvPs=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 1444 invoked from network); 27 Apr 2017 17:39:29 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 27 Apr 2017 17:39:29 +0200 To: Tommy Pauly References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> Cc: Eric Rescorla , ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Thu, 27 Apr 2017 17:39:29 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170427153929.1434.4227@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-ipsecme-tcp-encaps-09=3A_=28with_DISCUSS=29?= X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 15:47:42 -0000 Hi Tommy, I think we agree. Removing the port examples is one thing but there is also wording that suggest using well-known ports which could be phrased more carefully. We discussed this today on the telechat and ekr will have another look at this. Mirja On 27.04.2017 17:07, Tommy Pauly wrote: > > >> On Apr 27, 2017, at 7:32 AM, Mirja Kühlewind wrote: >> >> See below >> >> On 27.04.2017 16:27, Eric Rescorla wrote: >>> >>> "This document leaves the selection of TCP ports up to >>> implementations. It is suggested to use TCP port 4500, which is >>> allocated for IPsec NAT Traversal." >>> >>> Which sounds to me like an invitation to squat on any open port >>> regardless what the port is supposed to be used for (hoping that the >>> magic number would avoid any collision). I don't think that a >>> good thing >>> to right in an RFC. >>> >>> >>> Hmm... Maybe I don't understand your overall theory here. It seems >>> like having >>> reserved ports for protocols but letting people run them on any port >>> they want >>> to is kind of common practice. See, for instance: >>> https://tools.ietf.org/html/rfc7230#section-2.7.1 >>> >>> >>> " If the host identifier is provided as an IP address, the origin >>> server is the listener (if any) on the indicated TCP port at that IP >>> address. If host is a registered name, the registered name is an >>> indirect identifier for use with a name resolution service, such as >>> DNS, to find an address for that origin server. If the port >>> subcomponent is empty or not given, TCP port 80 (the reserved port >>> for WWW services) is the default." >>> >>> >>> This doesn't say you can/should use any port you want (it says you can >>> use another port than 80) but you should till avoid to use any other port >>> that runs a different TCP service. >>> >>> >>> Well, that may be part of your background assumptions, but the document >>> doesn't say that. It just tells you how to use a different port and is silent on >>> what port you should use. >>> >> >> That's what we have the registry for. The difference is, it's okay to use a random port (instead of one specific reserved one) but this draft explicitly is intended to use other reserved ports. > > The only recommended port in the draft is 4500, which is what is reserved in the registry. The use of any other port is by configuration only. As Tero and others have explained, all IKE connections are made to pre-known pre-configured hosts. All the IKE implementations I am aware of allow the useable IKE ports to be customized. > > I'm fine removing any mention of other specific ports, even in the appendix. However, the fact that configurations can choose what ports to use is something that needs to be left open. The point of the port registry is to allow devices to expect what service will be offered on a given port when they connect. If two peers mutually decide to share their own configuration, they can do that. > > Thanks, > Tommy > >> >> Mirja >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Apr 27 15:30:11 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757D81296C9; Thu, 27 Apr 2017 15:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SORBS_WEB=1.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FStFqjC1Wsj5; Thu, 27 Apr 2017 15:30:06 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 7A08C129A9E; Thu, 27 Apr 2017 15:27:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 61896D00; Fri, 28 Apr 2017 00:27:01 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 5AYhHiNOXyF4; Fri, 28 Apr 2017 00:27:01 +0200 (CEST) Received: from [192.168.1.36] (148.red-88-10-88.dynamicip.rima-tde.net [88.10.88.148]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon24.um.es (Postfix) with ESMTPSA id 8AC62853; Fri, 28 Apr 2017 00:26:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rafa Marin Lopez In-Reply-To: Date: Fri, 28 Apr 2017 00:26:55 +0200 Cc: Rafa Marin Lopez , "IPsec@ietf.org" , Linda Dunbar , i2nsf@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A95BA014132FF49AE685FAB4B9F17F65927260F@SJCEML702-CHM.china.huawei.com> <18474.1492112893@obiwan.sandelman.ca> <07C6044A-255C-42AB-855B-43B4B53CB6E2@gmail.com> <960CA8F1-256D-485F-91D7-20AFDB332BD5@um.es> To: Paul Wouters X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [IPsec] Can IPSec (RFC 5996) support tunnels with end point being (virtual) CPEs which has a set of workload attached (say Virtual Machines) all having virtual IP addresses? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 22:30:09 -0000 Hi Paul: Thank you for your comments. Please, see mine inline. >>> [Rafa] I guess, it will depend on the scenario. I remember an e-mail = to I2NSF = (https://www.ietf.org/mail-archive/web/i2nsf/current/msg01111.html) = mentioning that they were doing sort of case 2 and they would like to = have a standard way of doing it. Precisely the effort behind our I-D is = trying to provide an standard interface standard not only for case 1 = (with IKE in the NSF) but also for case 2 (no IKE in the NSF).=20 >>>=20 >=20 > Don't. You will need to builtin there same security features as IKE = has. [Rafa] Yes, but in case 2 all those features (e.g. key management = operations) are in the controller but not in the NSFs. The NSFs only = implements IPsec stack and deploys, for example, a NETFCONF server for = the communication with the controller. Thus, all the key management = operations are performed in the controller in case 2 and the resulting = IPsec SAs are installed in the NSFs using, for example, NETCONF.=20 > Focus instead of implementing "minimal ikev2" >=20 > https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-01 [Rafa] Minimal IKEv2 implementation in the NSF would be case 1.=20 Nevertheless, implementing minimal ikev2 does not solve, for example, = NAT-T for case 1 so controller should do something anyway. >=20 >=20 > For example, most modern ciphers require timely rekeying and must = never reuse IV/counters with the same private key. [Rafa] Why do you imply that IV/counters will be the same with same = private key? That is not the assumption in case 2 where the controller = always generates fresh IPsec SAs. > Synching that across independent hosts is impossible. [Rafa] I do not see how it is impossible when a controller that have = access to both NSFs provides that information. If it is not impossible = when using IKEv2, it should not be impossible for case 2.=20 The point is that the result of running IKEv2 is the IPsec SAs in the = IPsec kernel of both NSFs. In case 2, that state is coming from the = controller that is performing the key management operations (generate = fresh key material, IV, etc=E2=80=A6 per each IPsec SA). The controller = has a connection with both NSFs using, for example, NETCONF. Moreover, = as I commented , you can read this e-mail = (https://www.ietf.org/mail-archive/web/i2nsf/current/msg01111.html). So = there is proof that it is working. Thus, it is more difficult to manage, yes, (in fact, we admit that in = our I-D), but not impossible.=20 In fact, I think it would be worthy if you can provide a concrete = example of that use case where both NSFs are under the same controller. = Maybe we can help you to address your concern and explain how the = operation would be in that specific case you have in mind. Best Regards and many thanks for your comments. >=20 > Paul > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ----------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ---------------------------------------------------------- From nobody Thu Apr 27 15:36:35 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD49C1298A1; Thu, 27 Apr 2017 15:36:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxIJUn901srE; Thu, 27 Apr 2017 15:36:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 84B69129506; Thu, 27 Apr 2017 15:33:03 -0700 (PDT) Received: from [10.0.1.63] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v3RMX1Ze044958 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 27 Apr 2017 17:33:02 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.63] Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Ben Campbell In-Reply-To: <22785.57185.696102.246674@fireball.acr.fi> Date: Thu, 27 Apr 2017 17:33:00 -0500 Cc: The IESG , ipsec@ietf.org, ipsecme-chairs@ietf.org, draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <18514CF6-F952-4D14-B6A2-0F3A60510100@nostrum.com> References: <149317097326.21499.1497412982831603211.idtracker@ietfa.amsl.com> <22784.32563.870450.167881@fireball.acr.fi> <2980CAE0-D03E-4C91-88E7-726A802F584E@nostrum.com> <22785.57185.696102.246674@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Apr 2017 22:36:33 -0000 > On Apr 27, 2017, at 7:09 AM, Tero Kivinen wrote: >=20 >>>> Substantive Comments: >>>>=20 >>>> -3, first paragraph: >>>> Are people confident there will never, ever be a need to demux = protocols >>>> other than IKE and ESP? If not, this approach may paint people in a >>>> corner in the future. I ask because we made similar choices with >>>> DTLS-SRTP [RFC5764] in demuxing DTLS and STUN, and it became an = issue. >>>> See RFC7983 for a discussion. (Note that this would have been a = DISCUSS >>>> point, but I think it's reasonably likely that there really won't = be >>>> other protocols here. But I want to make sure people have thought = about >>>> it.) >>>=20 >>> If we ever want to run other protocols there, we still have 255 >>> reserved values we can use as Non-ESP marker. The reason the >>> 0x00000000 is selected as Non-ESP marker in the UDP encapsulation = (and >>> here) is because first four octets of the ESP packet are SPI, and = SPI >>> MUST NOT be zero. Also numbers from 1 to 255 are "are reserved by = the >>> Internet Assigned Numbers Authority (IANA) for future use" in the >>> RFC4303. >>>=20 >>> So if we need to run something else than IKE and ESP over that = tunnel >>> we just reserve one of the other reserved IANA numbers for it and = use >>> it as protocol marker for this new protocol.=20 >>=20 >> Ah, I didn=E2=80=99t realize 1-255 were reserved. It might be worth a >> mention that if future protocols are added, their prefixes must be >> registered with IANA. (I note that 2 are registered already.) >=20 > I do not think it belongs to this document. This is not actually using > reserved SPIs, but I think it should be enough to see that there is a > way to extend this, but as we do not see the need for extension now, > we do not need to think how we are going to do it. There are other > ways of doing that extension also and everything depends what we > really want to do. >=20 > Trying to guess things now is not really useful. The reason I thought it might be worth mentioning it would be to help = prevent people from heading down a wrong path in future extensions. = I=E2=80=99m okay with leaving it out if people think the probability of = it coming up is low. From nobody Fri Apr 28 04:52:24 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E552129C39 for ; Fri, 28 Apr 2017 04:52:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=ietf@kuehlewind.net header.d=kuehlewind.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MThvnn8y8j2 for ; Fri, 28 Apr 2017 04:52:21 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81E4B129504 for ; Fri, 28 Apr 2017 04:48:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kuehlewind.net; b=fJdesWlrofq6RexRV0ddVXGwz0s+oNyNIuNUTvyBLZVbSr4fQZHesNoO8VrU8VH0dSn1yHp7gh69rbNMWZGDEe4uOj4fjP1K7XlzdmnLznO3DpAnq+ZMRzOuCG371S96Xde162waatkNR7mjQVv8VVbh5hX8sTztljwT95R2pMY=; h=Received:Received:Subject:To:References:Cc:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-PPP-Message-ID:X-PPP-Vhost; Received: (qmail 9893 invoked from network); 28 Apr 2017 13:41:35 +0200 Received: from nb-10510.ethz.ch (HELO ?82.130.103.143?) (82.130.103.143) by kuehlewind.net with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 28 Apr 2017 13:41:35 +0200 To: Tero Kivinen References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> Cc: Eric Rescorla , ipsecme-chairs@ietf.org, ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org, Tommy Pauly From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> Date: Fri, 28 Apr 2017 13:41:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <22785.64570.259658.376130@fireball.acr.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20170428114135.9883.73786@lvps83-169-45-111.dedicated.hosteurope.de> X-PPP-Vhost: kuehlewind.net Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 11:52:22 -0000 Hi Tero, a few quick replies but we also discussed this yesterday at the telechat and agreed on a way forward. On 27.04.2017 16:12, Tero Kivinen wrote: > Mirja Kühlewind writes: >>> I agree that this kind of port squatting is regrettable, but I also don't >>> think it really >>> helps to not publish RFCs that document widely used protocols because we >>> are sad they port-squatted. >>> >>> I proposed a way to deal with this in an earlier e-mail. Would that be >>> satisfactory >>> to you. To retransmit, we add the following >>> >>> "Note: While port 4500 is the reserved port for this protocol, some existing >>> implementations >>> also use port 443. The Stream Prefix provides some mitigation against >>> cross-protocol >>> attacks in this case, however, the use of port 443 is NOT RECOMMENDED" >>> >>> We could do something similar for port 80. >>> >>> Would that work? >> >> This already is good but I think it's not enough. As Tero noted the working >> group thought that they rather specify a generic scheme which I find >> problematic. Currently the drafts says: >> >> "This document leaves the selection of TCP ports up to >> implementations. It is suggested to use TCP port 4500, which is >> allocated for IPsec NAT Traversal." >> >> Which sounds to me like an invitation to squat on any open port regardless >> what the port is supposed to be used for (hoping that the magic number would >> avoid any collision). I don't think that a good thing to right in an RFC. > > Note, that configurations can only use ports which are defined to be > used by the responder. I.e., if the responder is configured to listen > port 4500 and port 443 (with TLS wrapping), there is no point of > initiator to try port 80, as it will not work. I understood this. My point breaks down to a) the case where you would use two services at the same time on the same port (see below) and b) some language changes that do favor to use 4500 where possible and not explicitly advise to use other assigned specific ports in the line of what Ekr already proposed. > > I.e., in practice this will end up the operators picking suitable > number of port numbers they will configure their system to respond to, > and most likely they will try to use services which are not in use > normally by the responder. I.e., if the responder is running > web-server, it cannot very easily also use the port 80 (or 443) for > the IPsec traffic, thus it might pick ports 4500, 8000, 8080 or some > other random ports which might go through the filters which are > already blocking all UDP traffic, and at least port 4500 for TCP. Actually this is another good point. If you have multiple open ports, you can give more advise which one to try when and in which order, e.g. always try 4500 first (first UDP then TCP which the draft I believe already says), then others. > > So this is same thing we have now in web. I am quite often running web > servers on random ports just because some places have had filters > blocking some ports. For example one of my friends company network > blocked connection to port 8080, but did not block connections to port > 2020, so my web server was running (also) on that port... > > So unless you are saying "TCP/UDP ports on all protocols MUST NOT be > configurable, and only port numbers reserved for those services are > allowed" there is nothing we can really do. > > (and even if you say that, nothing is going to change, as people are > so used to getting past stupid firewalls). > >> Now given the text you propose above, I actually assume that the text I just >> cited will be removed but the whole document is written with this assumption >> and therefore there are a couple more places where wording probably needs to >> change. >> >> I do understand well the problem and that 443 is used in practice. However, >> to match reality I would rather like to see a document that specifies the >> approach of encapsulating in TLS/TCP on port 443 that is used today and pure >> TCP encapsulation for use with port 4500 only. Again i think that's where >> your proposed text is heading to but I think it needs more changes; in this >> case it would also make sense to add the TLS part back in the main document >> for 443 only. > > This is what the document tries to say. I.e., for some ports (like > 443), there might be some other framings (like TLS) in place, and for > other ports there might not be. As IPsec will require > pre-configuration this information which ports are used, and what > framing protocol is used comes from the configuration. > >> Further, I have one more question: The document is written in a way that >> allows the implementation of multiple services on the used port. Is that >> actually done in reality? > > Yes and no. There are some old IKEv1 based proprietary TCP > encapsulation methods, and I think some of those might actually use > port 500 and perhaps also port 4500. So vendor implementing those, > might want to do multiplexing based on whether there is the stream > prefix in front or not to see whether the old proprietary method is > used, or the one defined in document is used. There is a difference of distinguishing other/old version of IKE or trying to distinguish IKE from other protocols. The point is for IKE you can define the magic number as reserved but you probably don't really want to reserve the same bits for all other protocols than you may run in parallel on the port. As long as you don't 'officially' make this reservation by updating the respective specs of other protocols, you can never be sure that there will not be a conflict in future version of these protocols. > > Another issue might be that the SGW terminating the TCP 443 > connection, might also support some proprietary TLS VPN implementation > and differntiating from that is also something I can see that vendors > might want to do. > > So I do not know if anybody is really do it now, but I can see reasons > why people might want to multiplex the proprietary things they are now > running on those ports 500/4500/443 with the standard we are defining > here. That's fine as long as the multiplexing is between version of IKE only. > >> If we could restrict the use of this encapsulation >> with servers that only are IKE servers (at least for the used port), you >> would actually not need the magic number anymore. I guess you can still have >> the magic number if you really want it because that makes it easier to >> distinguish valid IKE/IPSec traffic from other random traffic that might be >> send to this port but the other service running on this port (on other >> servers) does not need to know about the magic number because it is supposed >> to never see any IKe/IPSec TCP-encapsulated traffic. > > If it is operationally possible, and there is no old proprietary > protocols to be supported, I would assume most implementations would > not want to bother with the multiplexing different protocols on one > port. Then let's just not support this case and let's specify in the draft that you cannot run another service on the used port. > > I.e., new implementations and new setups will most likely then move > for example the adminstative interface over https to separate > IP-address, just to make sure that it is easier to implement and > operate. > From nobody Fri Apr 28 08:58:18 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB3F12EAF1; Fri, 28 Apr 2017 08:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4DwLaoojVFX; Fri, 28 Apr 2017 08:58:13 -0700 (PDT) Received: from xenon21.um.es (xenon21.um.es [155.54.212.161]) by ietfa.amsl.com (Postfix) with ESMTP id 3A02F124217; Fri, 28 Apr 2017 08:54:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon21.um.es (Postfix) with ESMTP id AA2F73FF9A; Fri, 28 Apr 2017 17:54:34 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon21.um.es Received: from xenon21.um.es ([127.0.0.1]) by localhost (xenon21.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3Z5GJ20HiB8H; Fri, 28 Apr 2017 17:54:34 +0200 (CEST) Received: from inf-205-158.inf.um.es (inf-205-158.inf.um.es [155.54.205.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm@um.es) by xenon21.um.es (Postfix) with ESMTPSA id 9C97C3F974; Fri, 28 Apr 2017 17:54:30 +0200 (CEST) From: Gabriel Lopez Message-Id: <67B6C8B8-4345-4250-A4BA-801986197A17@um.es> Content-Type: multipart/alternative; boundary="Apple-Mail=_349DA7DB-D25F-4D3A-93E3-03056F6EB44A" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 28 Apr 2017 17:54:30 +0200 In-Reply-To: <2DA788A5A7D91747AEA54B502558D73826A6C421@DGGEMM506-MBS.china.huawei.com> Cc: Linda Dunbar , Yoav Nir , "IPsec@ietf.org" , Michael Richardson , "i2nsf@ietf.org" To: Sandeep Kampati References: <2DA788A5A7D91747AEA54B502558D73826A6C421@DGGEMM506-MBS.china.huawei.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [IPsec] small correction : draft-abad-i2nsf-sdn-ipsec-flow-protectio X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 15:58:16 -0000 --Apple-Mail=_349DA7DB-D25F-4D3A-93E3-03056F6EB44A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Sandeep, > El 26 abr 2017, a las 11:26, Sandeep Kampati = escribi=C3=B3: >=20 > Hi All, >=20 > small correction =20 >=20 > 8. Data model >=20 > Data model for the SDP entries: --> it should be "Data model = for the SPD entries: =E2=80=9C Thanks. We expect to have a new version in the next days. Regards, Gabi. >=20 > Regards, > Sandeep.k >=20 >=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec ----------------------------------------------------------- Gabriel L=C3=B3pez Mill=C3=A1n Departamento de Ingenier=C3=ADa de la Informaci=C3=B3n y las = Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es --Apple-Mail=_349DA7DB-D25F-4D3A-93E3-03056F6EB44A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Sandeep,


El 26 abr 2017, a las 11:26, Sandeep Kampati <sandeepkampati@huawei.com> escribi=C3=B3:

Hi = All,

small correction    

8.  Data model

= Data model for the SDP entries: --> it should be =    "Data model for the SPD entries: = =E2=80=9C


Thanks.
We expect to have a new version in = the next days.

Regards, = Gabi.


Regards,
Sandeep.k



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

-----------------------------------------------------------
Gabriel L=C3=B3pez Mill=C3=A1n
Departamento de = Ingenier=C3=ADa de la Informaci=C3=B3n y las Comunicaciones
University of Murcia
Spain
Tel: = +34 868888504
Fax: +34 868884151
email: gabilm@um.es

= --Apple-Mail=_349DA7DB-D25F-4D3A-93E3-03056F6EB44A-- From nobody Fri Apr 28 10:09:37 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D8D12EB04 for ; Fri, 28 Apr 2017 10:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNjHcgVM3Nvt for ; Fri, 28 Apr 2017 10:09:32 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A898912EB07 for ; Fri, 28 Apr 2017 10:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1493399160; 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=YQHx1catOcDiIjFiT3nQiVQc7zuW+5l0erDBskXakf0=; b=18qpHmgDXRADLsC0Tas4rQifaaJVikrxG89XFbWDUJVd2unU4Ld1uOu8AGFlvlPP ZL4BaPSM/Hcme1s2TCt/YwmZBXfdsPcMX08b1YLs+xS+RSDUQ0zin+AhHJLiO2Kz Mj8i65NjG+SNdbUCbco7CY6/kpn2LUCFoH7nWqR/Gu3rabOVScBdQ2uk4a8oiGyU 1OojomMnBFltRLp65l1jr8qf7Tm8GBG/CJC0ALvJ0GatQdgnj6bexmwKBsmqM0zb OQkX3AsBYgwgcHdBOLyDykjsEFRZAmlP+qAmGLHi5mYzaNR3jvXoc6kA1RJvJrLb bsWJCMR4BuR6rSpxhrYwZg==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id DA.E7.08351.87673095; Fri, 28 Apr 2017 10:06:00 -0700 (PDT) X-AuditID: 11973e16-efb529a00000209f-a8-5903767862ad Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by relay4.apple.com (Apple SCV relay) with SMTP id 44.55.02523.77673095; Fri, 28 Apr 2017 10:06:00 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_+pX/zi7ggY5pUiIJs3UlHA)" Received: from [17.153.50.20] (unknown [17.153.50.20]) by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OP4007WSQ5ZG890@nwk-mmpp-sz10.apple.com>; Fri, 28 Apr 2017 10:05:59 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> Date: Fri, 28 Apr 2017 10:05:58 -0700 In-reply-to: <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> Cc: Tero Kivinen , Eric Rescorla , ipsecme-chairs@ietf.org, ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org To: =?utf-8?Q?Mirja_K=C3=BChlewind?= References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> X-Mailer: Apple Mail (2.3424) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FAYrltRxhxpsO6OmMX7P2cYLVa8Psdu MePPRGaLF9c/Mlvs3/KCzWLmnA8sFkfPP2dzYPdYsuQnk8fhrwtZPFo+LmT1mPy4jTmAJYrL JiU1J7MstUjfLoErY+7C04wF574xVdx/9ZSxgfHnXqYuRk4OCQETieU7vzF3MXJxCAmsZpI4 3zWLpYuRAyxxbXIURPwQo8T0A2vZQRp4BQQlfky+xwJiMwuESeyZfo0FoqifSeLliw1sIM3C AhISm/ckgtSwCahIHP+2gRmi10bi4uZjbCC2sECqxOv7u8DKWQRUJXYfcAAJcwo4Sfz5fZkN ZCSzwDpGie1Ht4HtFRGwkmje/ghq11xmiUPnH0F9ICsxYd1msA8kBH6zSVyYfYBpAqPQLCTH zkJy7CyghcwC6hJTpuRChLUlnry7wAphq0ks/L2ICVl8ASPbKkah3MTMHN3MPHO9xIKCnFS9 5PzcTYygqJpuJ7aD8eEqq0OMAhyMSjy8HR7MkUKsiWXFlbmHGKU5WJTEeV3jgEIC6Yklqdmp qQWpRfFFpTmpxYcYmTg4pRoYmWoqSzdM4uS1Ou+Yocr09OW0iTVyLCqOTPYyKxi1H4vYFcq3 x+reE9F9KlW0vnWDsO6MBR8+tgf2TJrv4104++n9EoFnV7p8OthSH0lpPF92RuFpVefsSR2t N2dFMa6tsrOS2db5/xXb+XeqOy9ZBXm9fT5z0krBtqnvOU/PKNvjHvjvlb2qEktxRqKhFnNR cSIAvLPiHosCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUi2FBcpVtRxhxp8OoAm8X7P2cYLVa8Psdu MePPRGaLF9c/Mlvs3/KCzWLmnA8sFkfPP2dzYPdYsuQnk8fhrwtZPFo+LmT1mPy4jTmAJYrL JiU1J7MstUjfLoErY+7C04wF574xVdx/9ZSxgfHnXqYuRg4OCQETiWuTo7oYuTiEBA4xSkw/ sJa9i5GTg1dAUOLH5HssIDazQJjEnunXWCCK+pkkXr7YwAbSLCwgIbF5TyJIDZuAisTxbxuY IXptJC5uPsYGYgsLpEq8vr8LrJxFQFVi9wEHkDCngJPEn9+X2UBGMgusY5TYfnQb2F4RASuJ 5u2PoHbNZZY4dP4RE0hCQkBWYsK6zcwTGPlnIblvFpL7ZgHtYBZQl5gyJRcirC3x5N0FVghb TWLh70VMyOILGNlWMQoUpeYkVproJRYU5KTqJefnbmIER0Fh+A7Gf8usDjEKcDAq8fB2eDBH CrEmlhVX5gIDiYNZSYQ32A4oxJuSWFmVWpQfX1Sak1p8iHEiI9CXE5mlRJPzgTGaVxJvaGJi YGJsbGZsbG5iTkthJXHeadlMkUIC6YklqdmpqQWpRTBHMXFwSjUwGqkzvLc/c6O7U8nEhzdK /+VXRiGVxvrlj+1CF+Uf1TuUX2R5zuX5yiDnTcf5t66/tCUyQGjrzdYGpa88lzbek3N7daBi pnLSo8Ay3c894Te63Lh+z1fs75mvI7bW/rrq9J5FsxbuXPDDeD/j0vYZF5aZTtzGxTPhVeCB ewtDn6R1Ms/ZbWebpsRSnJFoqMVcVJwIAD95Ju71AgAA Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 17:09:35 -0000 --Boundary_(ID_+pX/zi7ggY5pUiIJs3UlHA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hello all, Here's some proposed text for: - Clarifying the configuration model around ports - Clarifying the role of the stream prefix - Expanding the TCP performance considerations.=20 Changes are in bold. Thanks, Tommy ------- 2. Configuration One of the main reasons to use TCP encapsulation is that UDP traffic may be entirely blocked on a network. Because of this, support for TCP encapsulation is not specifically negotiated in the IKE exchange. Instead, support for TCP encapsulation must be pre-configured on both the TCP Originator and the TCP Responder. Implementations MUST support TCP encapsulation on TCP port 4500,=20 which is reserved for IPsec NAT Traversal.=20 Beyond a flag indicating support for TCP encapsulation, the = configuration defined on each peer can include the following optional parameters: o Alternate TCP ports on which the specific TCP Responder listens = for incoming connections. Note that the TCP Originator may initiate TCP connections to the TCP Responder from any local port.=20 ... 4. TCP-Encapsulated Stream Prefix Each stream of bytes used for IKE and IPsec encapsulation MUST begin with a fixed sequence of six bytes as a magic value, containing the characters "IKETCP" as ASCII values. This value is intended to = identify and validate that the TCP connection is being used for TCP = encapsulation as defined in this document, to avoid conflicts with the prevalence = of previous non-standard protocols that used TCP port 4500. This value is only = sent once,=20 by the TCP Originator only, at the beginning of any stream of IKE and = ESP messages. ... 12. Performance Considerations Several aspects of TCP encapsulation for IKE and IPsec packets may negatively impact the performance of connections within a tunnel-mode IPsec SA. Implementations should be aware of these and take these into consideration when determining when to use TCP encapsulation. Due to these performance impacts, implementations SHOULD favor using=20= direct ESP or UDP encapsulation over TCP encapsulation whenever possible. 12.1. TCP-in-TCP If the outer connection between IKE peers is over TCP, inner TCP connections may suffer effects from using TCP within TCP. Running TCP within TCP is discouraged, since the TCP algorithms generally assume that they are running over an unreliable datagram layer. If the outer (tunnel) TCP connection experiences packet loss, this = loss will be hidden from any inner TCP connections, since the outer = connection will retransmit to account for the losses. This means that loss on an = outer=20 connection will be interpreted only as delay by inner connections. = Since the outer TCP connection will deliver the inner messages in order, = any messages after a lost packet may have to wait until the loss is recovered. = This increases the burstiness of inner traffic, since a large number of inner = packets will be delivered across the tunnel at once. This effect is especially of concern when = there is a high=20 level of loss on the outer connection. TCP-in-TCP can also lead to increased buffering, or bufferbloat. This = can occur when the window size of the outer TCP connection is reduced, and becomes = smaller than the window sizes of the inner TCP connections. This can lead to packets backing = up in the outer TCP connection's send buffers. In order to limit this effect, the outer = TCP connection should have limits on its send buffer size, and on the rate at which it reduces = its window size. The inner TCP's round-trip-time estimation will also be affected by = the burstiness of the outer=20 TCP connection. This will make loss-recovery of the inner TCP = traffic less reactive and more prone to spurious retransmission timeouts. Note that any negative effects will be shared between all flows going = through the outer TCP connection. This is of particular concern for any latency-sensitive = or real-time applications=20 using the tunnel. If such traffic is using a TCP encapsulated IPsec = connection, it is recommended that the number of inner connections sharing the tunnel be limited as = much as possible. ... 12.5. Tunnelling ECN in TCP Since there is not a one-to-one mapping between outer IP packets and = inner ESP/IP messages when using TCP encapsulation, the markings for Explicit Congestion = Notification (ECN) cannot be simply mapped. However, any ECN markings on inner messages should = be preserved through the tunnel. Implementations SHOULD follow the ECN compatibility mode as described = in RFC 6040. The outer TCP connection SHOULD mark its packets as not ECN-capable, but = SHOULD NOT clear any ECN markings on inner packets. ... 14. IANA Considerations This memo includes no request to IANA. TCP port 4500 is already allocated to IPsec for NAT Traversal. This = port SHOULD be used for TCP encapsulated IKE and ESP as described in this = document. > On Apr 28, 2017, at 4:41 AM, Mirja K=C3=BChlewind = wrote: >=20 > Hi Tero, >=20 > a few quick replies but we also discussed this yesterday at the = telechat and agreed on a way forward. >=20 > On 27.04.2017 16:12, Tero Kivinen wrote: >> Mirja K=C3=BChlewind writes: >>>> I agree that this kind of port squatting is regrettable, but I also = don't >>>> think it really >>>> helps to not publish RFCs that document widely used protocols = because we >>>> are sad they port-squatted. >>>>=20 >>>> I proposed a way to deal with this in an earlier e-mail. Would that = be >>>> satisfactory >>>> to you. To retransmit, we add the following >>>>=20 >>>> "Note: While port 4500 is the reserved port for this protocol, some = existing >>>> implementations >>>> also use port 443. The Stream Prefix provides some mitigation = against >>>> cross-protocol >>>> attacks in this case, however, the use of port 443 is NOT = RECOMMENDED" >>>>=20 >>>> We could do something similar for port 80. >>>>=20 >>>> Would that work? >>>=20 >>> This already is good but I think it's not enough. As Tero noted the = working >>> group thought that they rather specify a generic scheme which I find >>> problematic. Currently the drafts says: >>>=20 >>> "This document leaves the selection of TCP ports up to >>> implementations. It is suggested to use TCP port 4500, which is >>> allocated for IPsec NAT Traversal." >>>=20 >>> Which sounds to me like an invitation to squat on any open port = regardless >>> what the port is supposed to be used for (hoping that the magic = number would >>> avoid any collision). I don't think that a good thing to right in an = RFC. >>=20 >> Note, that configurations can only use ports which are defined to be >> used by the responder. I.e., if the responder is configured to listen >> port 4500 and port 443 (with TLS wrapping), there is no point of >> initiator to try port 80, as it will not work. >=20 > I understood this. My point breaks down to a) the case where you would = use two services at the same time on the same port (see below) and b) = some language changes that do favor to use 4500 where possible and not = explicitly advise to use other assigned specific ports in the line of = what Ekr already proposed. >=20 >>=20 >> I.e., in practice this will end up the operators picking suitable >> number of port numbers they will configure their system to respond = to, >> and most likely they will try to use services which are not in use >> normally by the responder. I.e., if the responder is running >> web-server, it cannot very easily also use the port 80 (or 443) for >> the IPsec traffic, thus it might pick ports 4500, 8000, 8080 or some >> other random ports which might go through the filters which are >> already blocking all UDP traffic, and at least port 4500 for TCP. >=20 > Actually this is another good point. If you have multiple open ports, = you can give more advise which one to try when and in which order, e.g. = always try 4500 first (first UDP then TCP which the draft I believe = already says), then others. >=20 >>=20 >> So this is same thing we have now in web. I am quite often running = web >> servers on random ports just because some places have had filters >> blocking some ports. For example one of my friends company network >> blocked connection to port 8080, but did not block connections to = port >> 2020, so my web server was running (also) on that port... >>=20 >> So unless you are saying "TCP/UDP ports on all protocols MUST NOT be >> configurable, and only port numbers reserved for those services are >> allowed" there is nothing we can really do. >>=20 >> (and even if you say that, nothing is going to change, as people are >> so used to getting past stupid firewalls). >>=20 >>> Now given the text you propose above, I actually assume that the = text I just >>> cited will be removed but the whole document is written with this = assumption >>> and therefore there are a couple more places where wording probably = needs to >>> change. >>>=20 >>> I do understand well the problem and that 443 is used in practice. = However, >>> to match reality I would rather like to see a document that = specifies the >>> approach of encapsulating in TLS/TCP on port 443 that is used today = and pure >>> TCP encapsulation for use with port 4500 only. Again i think that's = where >>> your proposed text is heading to but I think it needs more changes; = in this >>> case it would also make sense to add the TLS part back in the main = document >>> for 443 only. >>=20 >> This is what the document tries to say. I.e., for some ports (like >> 443), there might be some other framings (like TLS) in place, and for >> other ports there might not be. As IPsec will require >> pre-configuration this information which ports are used, and what >> framing protocol is used comes from the configuration. >>=20 >>> Further, I have one more question: The document is written in a way = that >>> allows the implementation of multiple services on the used port. Is = that >>> actually done in reality? >>=20 >> Yes and no. There are some old IKEv1 based proprietary TCP >> encapsulation methods, and I think some of those might actually use >> port 500 and perhaps also port 4500. So vendor implementing those, >> might want to do multiplexing based on whether there is the stream >> prefix in front or not to see whether the old proprietary method is >> used, or the one defined in document is used. >=20 > There is a difference of distinguishing other/old version of IKE or = trying to distinguish IKE from other protocols. The point is for IKE you = can define the magic number as reserved but you probably don't really = want to reserve the same bits for all other protocols than you may run = in parallel on the port. As long as you don't 'officially' make this = reservation by updating the respective specs of other protocols, you can = never be sure that there will not be a conflict in future version of = these protocols. >=20 >>=20 >> Another issue might be that the SGW terminating the TCP 443 >> connection, might also support some proprietary TLS VPN = implementation >> and differntiating from that is also something I can see that vendors >> might want to do. >>=20 >> So I do not know if anybody is really do it now, but I can see = reasons >> why people might want to multiplex the proprietary things they are = now >> running on those ports 500/4500/443 with the standard we are defining >> here. >=20 > That's fine as long as the multiplexing is between version of IKE = only. >=20 >>=20 >>> If we could restrict the use of this encapsulation >>> with servers that only are IKE servers (at least for the used port), = you >>> would actually not need the magic number anymore. I guess you can = still have >>> the magic number if you really want it because that makes it easier = to >>> distinguish valid IKE/IPSec traffic from other random traffic that = might be >>> send to this port but the other service running on this port (on = other >>> servers) does not need to know about the magic number because it is = supposed >>> to never see any IKe/IPSec TCP-encapsulated traffic. >>=20 >> If it is operationally possible, and there is no old proprietary >> protocols to be supported, I would assume most implementations would >> not want to bother with the multiplexing different protocols on one >> port. >=20 > Then let's just not support this case and let's specify in the draft = that you cannot run another service on the used port. >=20 >>=20 >> I.e., new implementations and new setups will most likely then move >> for example the adminstative interface over https to separate >> IP-address, just to make sure that it is easier to implement and >> operate. >>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec = --Boundary_(ID_+pX/zi7ggY5pUiIJs3UlHA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
Hello all,

Here's some proposed text for:

- Clarifying the configuration model = around ports
- Clarifying the role of the stream = prefix
- Expanding the TCP performance = considerations. 

Changes are in bold.

Thanks,
Tommy

-------

2.  Configuration

   One of the main reasons to use TCP = encapsulation is that UDP traffic
   may = be entirely blocked on a network.  Because of this, support = for
   TCP encapsulation is not = specifically negotiated in the IKE exchange.
  =  Instead, support for TCP encapsulation must be pre-configured on = both
   the TCP Originator and the TCP = Responder.

   Implementations MUST support TCP = encapsulation on TCP port 4500, 
   which is reserved for IPsec NAT = Traversal. 

  =  Beyond a flag indicating support for TCP encapsulation, the = configuration
  =  defined on each peer can include the following optional = parameters:

   o =  Alternate TCP ports on which the specific TCP Responder listens = for
      incoming = connections.  Note that the TCP Originator may = initiate
      TCP = connections to the TCP Responder from any local = port. 

  ...

4.  TCP-Encapsulated Stream Prefix

   Each stream of bytes used = for IKE and IPsec encapsulation MUST begin
  =  with a fixed sequence of six bytes as a magic value, containing = the
   characters "IKETCP" as ASCII = values.  This value is intended to = identify
   and = validate that the TCP connection is being used for TCP = encapsulation
   as = defined in this document, to avoid conflicts with the prevalence of = previous
  =  non-standard protocols that used TCP port 4500. This value is = only sent once, 
   by the TCP = Originator only, at the beginning of any stream of IKE and ESP = messages.

...

12. =  Performance Considerations

   Several aspects of TCP encapsulation for IKE and = IPsec packets may
   negatively impact = the performance of connections within a tunnel-mode
   IPsec SA.  Implementations should be aware = of these and take these
   into = consideration when determining when to use TCP encapsulation.
   Due to these performance impacts, = implementations SHOULD favor using 
   direct ESP or UDP encapsulation over TCP = encapsulation whenever
  =  possible.


12.1.  TCP-in-TCP

   If the = outer connection between IKE peers is over TCP, inner TCP
   connections may suffer effects from using TCP = within TCP.  Running
   TCP within TCP is discouraged, since the TCP = algorithms
   generally = assume that they are running over an unreliable datagram
   layer.

  =  If the outer (tunnel) TCP connection experiences packet loss, this = loss
   will be hidden = from any inner TCP connections, since the outer connection
   will retransmit to account for the = losses. This means that loss on an outer 
   connection will be interpreted only as delay by = inner connections. Since
  =  the outer TCP connection will deliver the inner messages in = order, any messages
  =  after a lost packet may have to wait until the loss is recovered. = This increases
   the = burstiness of inner traffic, since a large number of inner packets will = be delivered
   across = the tunnel at once. This effect is especially of = concern when there is a high 
   level of loss on the outer connection.

   TCP-in-TCP = can also lead to increased buffering, or bufferbloat. This can occur = when the
   window size = of the outer TCP connection is reduced, and becomes smaller than the = window
   sizes of the = inner TCP connections. This can lead to packets backing up in the outer = TCP
   connection's = send buffers. In order to limit this effect, the outer TCP connection = should have
   limits = on its send buffer size, and on the rate at which it reduces its window = size.

   The inner TCP's round-trip-time estimation will = also be affected by the burstiness of the outer 
   TCP connection.  This will make = loss-recovery of the inner TCP traffic less reactive and more
   prone to spurious retransmission = timeouts.

   Note that any negative effects = will be shared between all flows going through the outer = TCP
  =  connection. This is of particular concern for any latency-sensitive or = real-time applications 
 =  using the tunnel. If such traffic is using = a TCP encapsulated IPsec connection, it is recommended
   that the number of inner connections sharing the tunnel be limited as much = as possible.

...

12.5.  Tunnelling ECN in TCP

  =  Since there is not a one-to-one mapping between outer IP packets = and inner ESP/IP messages
  =  when using TCP encapsulation, the markings for Explicit Congestion = Notification (ECN) cannot
  =  be simply mapped. However, any ECN markings on inner messages = should be preserved through
  =  the tunnel.

  =  Implementations SHOULD follow the ECN compatibility mode as = described in RFC 6040. The
  =  outer TCP connection SHOULD mark its packets as not ECN-capable, = but SHOULD NOT clear
  =  any ECN markings on inner packets.

...

14.  IANA Considerations

   This memo = includes no request to IANA.

   TCP port = 4500 is already allocated to IPsec for NAT Traversal.  This port = SHOULD
   be used for = TCP encapsulated IKE and ESP as described in this = document.

On Apr 28, 2017, at 4:41 AM, Mirja K=C3=BChlewi= nd <ietf@kuehlewind.net> wrote:

Hi Tero,
a few quick replies but we also discussed this = yesterday at the telechat and agreed on a way forward.
On 27.04.2017 16:12, Tero Kivinen = wrote:
Mirja K=C3=BChlewind writes:
I agree = that this kind of port squatting is regrettable, but I also don't
think it really
helps to not publish RFCs that = document widely used protocols because we
are sad they = port-squatted.

I proposed a way to deal = with this in an earlier e-mail. Would that be
satisfactory
to you. To retransmit, we add the = following

"Note: While port 4500 is the = reserved port for this protocol, some existing
implementations
also use port 443. The Stream = Prefix provides some mitigation against
cross-protocol
attacks in this case, however, the use of port 443 is NOT = RECOMMENDED"

We could do something similar = for port 80.

Would that work?

This already is good but I think = it's not enough. As Tero noted the working
group thought = that they rather specify a generic scheme which I find
problematic. Currently the drafts says:

"This document leaves the selection of TCP ports up to
   implementations.  It is suggested to = use TCP port 4500, which is
   allocated = for IPsec NAT Traversal."

Which sounds to = me like an invitation to squat on any open port regardless
what the port is supposed to be used for (hoping that the = magic number would
avoid any collision). I don't think = that a good thing to right in an RFC.

Note, that configurations can only use ports which are = defined to be
used by the responder. I.e., if the = responder is configured to listen
port 4500 and port 443 = (with TLS wrapping), there is no point of
initiator to try = port 80, as it will not work.

I understood this. My point breaks down to a) = the case where you would use two services at the same time on the same = port (see below) and b) some language changes that do favor to use 4500 = where possible and not explicitly advise to use other assigned specific = ports in the line of what Ekr already proposed.

I.e., in = practice this will end up the operators picking suitable
number of port numbers they will configure their system to = respond to,
and most likely they will try to use services = which are not in use
normally by the responder. I.e., if = the responder is running
web-server, it cannot very easily = also use the port 80 (or 443) for
the IPsec traffic, thus = it might pick ports 4500, 8000, 8080 or some
other random = ports which might go through the filters which are
already = blocking all UDP traffic, and at least port 4500 for TCP.

Actually this is another good point. If = you have multiple open ports, you can give more advise which one to try = when and in which order, e.g. always try 4500 first (first UDP then TCP = which the draft I believe already says), then others.

So this is = same thing we have now in web. I am quite often running web
servers on random ports just because some places have had = filters
blocking some ports. For example one of my friends = company network
blocked connection to port 8080, but did = not block connections to port
2020, so my web server was = running (also) on that port...

So unless = you are saying "TCP/UDP ports on all protocols MUST NOT be
configurable, and only port numbers reserved for those = services are
allowed" there is nothing we can really = do.

(and even if you say that, nothing is = going to change, as people are
so used to getting past = stupid firewalls).

Now given the text you propose above, I actually assume that = the text I just
cited will be removed but the whole = document is written with this assumption
and therefore = there are a couple more places where wording probably needs to
change.

I do understand well the = problem and that 443 is used in practice. However,
to = match reality I would rather like to see a document that specifies = the
approach of encapsulating in TLS/TCP on port 443 that = is used today and pure
TCP encapsulation for use with port = 4500 only. Again i think that's where
your proposed text = is heading to but I think it needs more changes; in this
case it would also make sense to add the TLS part back in the = main document
for 443 only.

This is what the document tries to say. I.e., for some ports = (like
443), there might be some other framings (like TLS) = in place, and for
other ports there might not be. As IPsec = will require
pre-configuration this information which = ports are used, and what
framing protocol is used comes = from the configuration.

Further, I have one more question: The document = is written in a way that
allows the implementation of = multiple services on the used port. Is that
actually done = in reality?

Yes and no. There = are some old IKEv1 based proprietary TCP
encapsulation = methods, and I think some of those might actually use
port = 500 and perhaps also port 4500. So vendor implementing those,
might want to do multiplexing based on whether there is the = stream
prefix in front or not to see whether the old = proprietary method is
used, or the one defined in document = is used.

There is a difference of = distinguishing other/old version of IKE or trying to distinguish IKE = from other protocols. The point is for IKE you can define the magic = number as reserved but you probably don't really want to reserve the = same bits for all other protocols than you may run in parallel on the = port. As long as you don't 'officially' make this reservation by = updating the respective specs of other protocols, you can never be sure = that there will not be a conflict in future version of these = protocols.


Another issue = might be that the SGW terminating the TCP 443
connection, = might also support some proprietary TLS VPN implementation
and differntiating from that is also something I can see that = vendors
might want to do.

So = I do not know if anybody is really do it now, but I can see reasons
why people might want to multiplex the proprietary things = they are now
running on those ports 500/4500/443 with the = standard we are defining
here.

That's fine as long as the multiplexing = is between version of IKE only.


If we could restrict the use of this = encapsulation
with servers that only are IKE servers (at = least for the used port), you
would actually not need the = magic number anymore. I guess you can still have
the magic = number if you really want it because that makes it easier to
distinguish valid IKE/IPSec traffic from other random traffic = that might be
send to this port but the other service = running on this port (on other
servers) does not need to = know about the magic number because it is supposed
to = never see any IKe/IPSec TCP-encapsulated traffic.

If it is operationally possible, = and there is no old proprietary
protocols to be supported, = I would assume most implementations would
not want to = bother with the multiplexing different protocols on one
port.

Then let's just not support this = case and let's specify in the draft that you cannot run another service = on the used port.


I.e., new = implementations and new setups will most likely then move
for example the adminstative interface over https to = separate
IP-address, just to make sure that it is easier = to implement and
operate.


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

= --Boundary_(ID_+pX/zi7ggY5pUiIJs3UlHA)-- From nobody Fri Apr 28 16:44:39 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FDC126E3A; Fri, 28 Apr 2017 16:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aosi0_pH2doz; Fri, 28 Apr 2017 16:44:26 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D785129489; Fri, 28 Apr 2017 16:41:43 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id k11so37783924ywb.1; Fri, 28 Apr 2017 16:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yYbWqXl1nql8i2ht1CCbjfRrGxj3oVptwVC5gbNIPR4=; b=dJW+X5GZIuzm+F5QxUZG7tgqErGZFs4pPR5X2jzOuMJVvMN9IkbNm7XzPLrYFnGeic gqfw+JTGG8AB3Gh0esg1kftyoRF2SQC+e2VqxIq1HGjrxfP+IAoUwW2M1R0AfzgKJzbu GqLjRNy2RJfvVj69NbOLbUlft4lngj1q3I/ly2G0tFgmBh6n+pi3RBDCkH352ckHcX77 9qwXrryib3GQ38HwgByJKIxL/GHCXaFCbaGXDdEvBjQYX/J2KHvubHKD+QiMt0DMVy00 H0nUpqHNnojw6IVypd2MHwfQ+vopZh+RtJDvA255WCmnUgq77zSF4Kq+yNh6ObWJ6hnp kn7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yYbWqXl1nql8i2ht1CCbjfRrGxj3oVptwVC5gbNIPR4=; b=LgHvqGc6XFNAQYapHUgPvCzCT+8dl0OaOZV+I7B3dchDGZqHL8B2gIAGgnj9RA3K+U l2RprO1tNrcJlVSbGiE3pw+Usy+C2Fzn1h6IuqyW22ne01vm/SBGRO5D/iWnJf/xW9V/ QkHbg3amW3IaCShV9VhnfFQeKVMNvo+zrAqRKT2zABnmR65WFS3uP64Lf/DLjj5pNfMC Tlm2v5HpoNGbPQDGFby7dNsS7O8T25fF/+5mDIuQU8nrckpzvSOkmZ3RHlS9ElPb4MgR mhQkH3TFc4LjAacYybAKzjQ/V+4eCZ2Sjyn9S8xYAVgwChiY9yVbCcyAGPBVVGuN+Qen Mi3A== X-Gm-Message-State: AN3rC/69ArwF3xlDODyL+hKTSzZz9cQp4hGFu+L0a2wdJ/7WplMer6dq 0cCrzVa10L+GriUI94ThVlZKVR/JiA== X-Received: by 10.129.76.148 with SMTP id z142mr12099935ywa.42.1493422902520; Fri, 28 Apr 2017 16:41:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.161.198 with HTTP; Fri, 28 Apr 2017 16:41:42 -0700 (PDT) In-Reply-To: <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> From: Spencer Dawkins at IETF Date: Fri, 28 Apr 2017 18:41:42 -0500 Message-ID: To: Tommy Pauly Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Eric Rescorla , ipsecme-chairs@ietf.org, Tero Kivinen , ipsec@ietf.org, The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org Content-Type: multipart/alternative; boundary=001a113f29229abf9b054e429d0b Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Apr 2017 23:44:28 -0000 --001a113f29229abf9b054e429d0b Content-Type: text/plain; charset=UTF-8 This is still Mirja's Discuss (which I supported), so I'll let her respond to most of Tommy's proposed text changes, but on the last one ... On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly wrote: > > 14. IANA Considerations > > This memo includes no request to IANA. > > * TCP port 4500 is already allocated to IPsec for NAT Traversal. This > port SHOULD* > * be used for TCP encapsulated IKE and ESP as described in this > document.* > With no IANA actions, the entry in https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4500 for 4500/tcp will still point to http://www.iana.org/go/rfc3947 as the reference. Should that change when this draft is published? Thanks, Spencer, who may be confused, but wanted to ask before the draft is approved --001a113f29229abf9b054e429d0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is still Mirja's Discuss (which I supported), so = I'll let her respond to most of Tommy's proposed text changes, but = on the last one ...

On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly <tpauly@apple.com> wrote:

14.=C2=A0 IANA Consideration= s

=C2=A0 =C2=A0This memo includes no request to IANA.

=C2=A0 =C2=A0TCP port 4500 is already allocated t= o IPsec for NAT Traversal.=C2=A0 This port SHOULD
=C2=A0 = =C2=A0be used for TCP encapsulated IKE and ESP as described in this documen= t.

With no IANA actio= ns, the entry in=C2=A0https://w= ww.iana.org/assignments/service-names-port-numbers/service-names-port-numbe= rs.xhtml?search=3D4500 for 4500/tcp will still point to=C2=A0http://www.iana.org/go/rfc3947 as the = reference.=C2=A0

Should that change when this draf= t is published?

Thanks,

S= pencer, who may be confused, but wanted to ask before the draft is approved=
--001a113f29229abf9b054e429d0b-- From nobody Fri Apr 28 17:12:49 2017 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F483129B5E for ; Fri, 28 Apr 2017 17:12:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzmxOFg-6QdD for ; Fri, 28 Apr 2017 17:12:45 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 14EFA129B69 for ; Fri, 28 Apr 2017 17:09: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=1493424583; 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=pwviLUhRM9fnRmnGAGC7KnMEwRN6/Jf73o3mf5i6YRc=; b=M6O1Gy71qK5EU+YXXUU+bS0e6Li5s7nL9R9VclSiGFgbgLImflED/MEIWYiF058r cti5UMjJFBk9ckWjYHiCFZMKpOtq2S21ir2UlZJtoCv1LArRVYgaitbgC9a5Vxpg zksWCTiYUY7r3ps2nW9rtpXb/2dMj95DD/GgcRLhKvaVNaWihB9pzLo9MiOlfUKM hhKhNABTgd94Tp3vVSbi9SkKt+oqoBNf7pz+xyrCjW5/fbWAlovw3mxVdhGD3AMh cWGxxVw5bBpYKOcWFPUl0bohr+my5mr2yy6bHXQa3an+Fwe5FVFgBDs7aJutJ3MN lzjqJNv/E4/Bws4x/JTLiw==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 0B.90.25795.7C9D3095; Fri, 28 Apr 2017 17:09:43 -0700 (PDT) X-AuditID: 11973e13-4cd389a0000064c3-43-5903d9c7a347 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay4.apple.com (Apple SCV relay) with SMTP id 81.C5.02523.7C9D3095; Fri, 28 Apr 2017 17:09:43 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_UX9XpZOoFTk06fHC9i9IIA)" Received: from [17.153.75.111] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0OP500CCG9S6EV20@nwk-mmpp-sz11.apple.com>; Fri, 28 Apr 2017 17:09:43 -0700 (PDT) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <853700CB-D5DD-4BC7-A1F5-5AB61330E70D@apple.com> Date: Fri, 28 Apr 2017 17:09:42 -0700 In-reply-to: Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , Eric Rescorla , ipsecme-chairs@ietf.org, IPsecME WG , The IESG , draft-ietf-ipsecme-tcp-encaps@ietf.org To: Spencer Dawkins at IETF , Tero Kivinen References: <149312449263.5884.11168631631187069210.idtracker@ietfa.amsl.com> <1CD2BB99-CDA2-472A-9833-741FB14CAE4A@apple.com> <752dde8c-0592-288e-6920-53a211834740@kuehlewind.net> <22fac532-f30b-03e3-0757-aed213e5a346@kuehlewind.net> <22785.64570.259658.376130@fireball.acr.fi> <277aa94d-5aa1-7a28-94c7-81da0966c172@kuehlewind.net> <41594727-9667-42BD-ABB1-4583A3B00EA2@apple.com> X-Mailer: Apple Mail (2.3263) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42IRbCgM1z1+kznSYPE6Q4v3f84wWqx4fY7d YsaficwWL65/ZLbYv+UFm8XMOR9YLI6ef85msWzKHmYHDo+ds+6yeyxZ8pPJ4/DXhSweLR8X snpMftzGHMAaxWWTkpqTWZZapG+XwJWxr3MSW8EMpYrb29pYGhi/yXYxcnJICJhIPFzVztrF yMUhJLCaSeLw303sMImpW88wQyQOMUqsW7GMGSTBKyAo8WPyPRYQm1kgTGLLumcsEEVfGSU+ 9vwCcjg4hAUkJDbvSQSpYRNQkTj+bQNUr43E/AtNbCC2sECqxOv7u8BsFgFVif47s4Fq2Dk4 BYIlZluBTGQWuMYoce7wN7B7RARiJG5/OcAGsWo6i8T9NasZIQ6VleheOA3sUAmBbnaJ84+W sE5gFJqF5NZZSG6FsLUkvj9qBbI5gGx5iYPnZSHCmhLP7n1ih7C1JZ68u8C6gJFtFaNQbmJm jm5mnqleYkFBTqpecn7uJkZQlE23E97BeHqV1SFGAQ5GJR7eDg/mSCHWxLLiytxDjNIcLEri vJ5xQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2MzUKTJh7VYGLvizj803lzx423V2++9OU7 d3vHJYV9fgYrHq1K6XQPaHvke+ekVG+lRHJO7tnDRbzreEvWV9hv62n3ubVqjlGP7Op/szX+ MG1z/5sUffT65XvLiyVlvN6FtKz8+t7KTjt7tQZ3h4kob8VmSY+f1c+D75RKsi2ZImGudE78 0Vw7JZbijERDLeai4kQA2L58UJMCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUi2FA8W/f4TeZIg8+XlCze/znDaLHi9Tl2 ixl/JjJbvLj+kdli/5YXbBYz53xgsTh6/jmbxbIpe5gdODx2zrrL7rFkyU8mj8NfF7J4tHxc yOox+XEbcwBrFJdNSmpOZllqkb5dAlfGvs5JbAUzlCpub2tjaWD8JtvFyMkhIWAiMXXrGeYu Ri4OIYFDjBLrVixjBknwCghK/Jh8jwXEZhYIk9iy7hkLRNFXRomPPb+AHA4OYQEJic17EkFq 2ARUJI5/2wDVayMx/0ITG4gtLJAq8fr+LjCbRUBVov/ObKAadg5OgWCJ2VYgE5kFrjFKnDv8 jR2kREQgRuL2lwNsEKums0jcX7OaEeJQWYnuhdOYJzDyz0Jy3iwk50HYWhLfH7UC2RxAtrzE wfOyEGFNiWf3PrFD2NoST95dYF3AyLaKUaAoNSex0kQvsaAgJ1UvOT93EyM4KgrDdzD+W2Z1 iFGAg1GJh7fDgzlSiDWxrLgyFxhGHMxKIrw2W4BCvCmJlVWpRfnxRaU5qcWHGCcyAj05kVlK NDkfGLN5JfGGJiYGJsbGZsbG5ibmtBRWEuedls0UKSSQnliSmp2aWpBaBHMUEwenVAPjmqVr fvuJHfnCePSChHiy+aI/71Yza9euTrl4OYBRSyBugpx/6ofohFAP/YpJG+SfOT8wb7nNY+MT P/tAP8N2lXOsb3vY1gp/vWIVsN4qZ+4k5W8vDS5t4xY+tVFQyPsMh8vD5a/LG1q3N8tnbrew NN55cJbV+Zn/lh1I/XVW0l12r9S2pM9blFiKMxINtZiLihMBWjlEm/0CAAA= Archived-At: Subject: Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Apr 2017 00:12:47 -0000 --Boundary_(ID_UX9XpZOoFTk06fHC9i9IIA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT I'll defer to Tero on this one. Tero, what do you prefer to do with the IANA Considerations text? Thanks, Tommy > On Apr 28, 2017, at 4:41 PM, Spencer Dawkins at IETF wrote: > > This is still Mirja's Discuss (which I supported), so I'll let her respond to most of Tommy's proposed text changes, but on the last one ... > > On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly > wrote: > > 14. IANA Considerations > > This memo includes no request to IANA. > > TCP port 4500 is already allocated to IPsec for NAT Traversal. This port SHOULD > be used for TCP encapsulated IKE and ESP as described in this document. > > With no IANA actions, the entry in https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4500 for 4500/tcp will still point to http://www.iana.org/go/rfc3947 as the reference. > > Should that change when this draft is published? > > Thanks, > > Spencer, who may be confused, but wanted to ask before the draft is approved --Boundary_(ID_UX9XpZOoFTk06fHC9i9IIA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
I'll defer to Tero on this one. Tero, what do = you prefer to do with the IANA Considerations text?

Thanks,
Tommy

On Apr 28, 2017, at 4:41 PM, Spencer Dawkins = at IETF <spencerdawkins.ietf@gmail.com> wrote:

This is still Mirja's Discuss (which I supported), so I'll = let her respond to most of Tommy's proposed text changes, but on the = last one ...

On Fri, Apr 28, 2017 at 12:05 PM, Tommy Pauly = <tpauly@apple.com> wrote:

14.  IANA Considerations

   This memo = includes no request to IANA.

   TCP port = 4500 is already allocated to IPsec for NAT Traversal.  This port = SHOULD
   be used for = TCP encapsulated IKE and ESP as described in this = document.

With no IANA actions, the entry = in https://www.iana.org/assignments/service-names-port-numbers/ser= vice-names-port-numbers.xhtml?search=3D4500 for 4500/tcp will still = point to http://www.iana.org/go/rfc3947 as the = reference. 

Should that change when this draft is published?

Thanks,

Spencer, who may be = confused, but wanted to ask before the draft is = approved

= --Boundary_(ID_UX9XpZOoFTk06fHC9i9IIA)--